* [PATCH v5 12/15] OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART
From: Govindraj.R @ 2011-09-21 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316607232-21709-1-git-send-email-govindraj.raja@ti.com>
From: Jon Hunter <jon-hunter@ti.com>
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
The secound timeout, RX_TIMEOUT, is a timeout after which the
DMA will be stopped if no more data is received. To make this
clearer, rename rx_timeout as rx_poll_rate and rename the
function serial_omap_rx_timeout() to serial_omap_rxdma_poll().
The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is
used to indicate when the DMA for UART can be stopped if no more
data is received. The value is a global definition that is applied
to all instances of the UART.
Each UART may be used for a different purpose and so the timeout
required may differ. Make this value configurable for each UART so
that this value can be optimised for power savings.
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
This patch is derived from a custom 2.6.35 kernel
Available here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;
h=b47839fb84e68333ea29a327cf5aa694b71be7d6;
hp=f62f570e8580507be48ad004defc2ec714b6e05d
arch/arm/mach-omap2/serial.c | 5 ++++-
arch/arm/plat-omap/include/plat/omap-serial.h | 3 ++-
drivers/tty/serial/omap-serial.c | 15 ++++++++-------
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0e45d9a..57d063a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -53,13 +53,15 @@
static u8 num_uarts;
-#define DEFAULT_RXDMA_TIMEOUT 1 /* RX DMA polling rate (us) */
+#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
#define DEFAULT_RXDMA_BUFSIZE 4096 /* RX DMA buffer size */
+#define DEFAULT_RXDMA_TIMEOUT (3 * HZ)/* RX DMA timeout (jiffies) */
static struct omap_uart_port_info omap_serial_default_info[] = {
{
.dma_enabled = 0,
.dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ .dma_rx_poll_rate = DEFAULT_RXDMA_POLLRATE,
.dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
.autosuspend_timeout = DEFAULT_AUTOSUSPEND_DELAY,
},
@@ -338,6 +340,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
pdata->set_force_idle = omap_uart_set_forceidle;
pdata->dma_enabled = info->dma_enabled;
pdata->dma_rx_buf_size = info->dma_rx_buf_size;
+ pdata->dma_rx_poll_rate = info->dma_rx_poll_rate;
pdata->dma_rx_timeout = info->dma_rx_timeout;
pdata->autosuspend_timeout = info->autosuspend_timeout;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index a40a41a..28abc6b 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -51,7 +51,6 @@
#define OMAP_UART_DMA_CH_FREE -1
-#define RX_TIMEOUT (3 * HZ)
#define OMAP_MAX_HSUART_PORTS 4
#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
@@ -67,6 +66,7 @@ struct omap_uart_port_info {
unsigned int dma_rx_buf_size;
unsigned int dma_rx_timeout;
unsigned int autosuspend_timeout;
+ unsigned int dma_rx_poll_rate;
void (*enable_wakeup)(struct platform_device *, bool);
u32 (*get_context_loss_count)(struct device *);
@@ -95,6 +95,7 @@ struct uart_omap_dma {
/* timer to poll activity on rx dma */
struct timer_list rx_timer;
unsigned int rx_buf_size;
+ unsigned int rx_poll_rate;
unsigned int rx_timeout;
};
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 15e0655..64e4ab5 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -47,7 +47,7 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
static void uart_tx_dma_callback(int lch, u16 ch_status, void *data);
-static void serial_omap_rx_timeout(unsigned long uart_no);
+static void serial_omap_rxdma_poll(unsigned long uart_no);
static int serial_omap_start_rxdma(struct uart_omap_port *up);
static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
@@ -542,7 +542,7 @@ static int serial_omap_startup(struct uart_port *port)
(dma_addr_t *)&(up->uart_dma.tx_buf_dma_phys),
0);
init_timer(&(up->uart_dma.rx_timer));
- up->uart_dma.rx_timer.function = serial_omap_rx_timeout;
+ up->uart_dma.rx_timer.function = serial_omap_rxdma_poll;
up->uart_dma.rx_timer.data = up->pdev->id;
/* Currently the buffer size is 4KB. Can increase it */
up->uart_dma.rx_buf = dma_alloc_coherent(NULL,
@@ -1147,7 +1147,7 @@ static int serial_omap_resume(struct device *dev)
return 0;
}
-static void serial_omap_rx_timeout(unsigned long uart_no)
+static void serial_omap_rxdma_poll(unsigned long uart_no)
{
struct uart_omap_port *up = ui[uart_no];
unsigned int curr_dma_pos, curr_transmitted_size;
@@ -1157,9 +1157,9 @@ static void serial_omap_rx_timeout(unsigned long uart_no)
if ((curr_dma_pos == up->uart_dma.prev_rx_dma_pos) ||
(curr_dma_pos == 0)) {
if (jiffies_to_msecs(jiffies - up->port_activity) <
- RX_TIMEOUT) {
+ up->uart_dma.rx_timeout) {
mod_timer(&up->uart_dma.rx_timer, jiffies +
- usecs_to_jiffies(up->uart_dma.rx_timeout));
+ usecs_to_jiffies(up->uart_dma.rx_poll_rate));
} else {
serial_omap_stop_rxdma(up);
up->ier |= (UART_IER_RDI | UART_IER_RLSI);
@@ -1188,7 +1188,7 @@ static void serial_omap_rx_timeout(unsigned long uart_no)
}
} else {
mod_timer(&up->uart_dma.rx_timer, jiffies +
- usecs_to_jiffies(up->uart_dma.rx_timeout));
+ usecs_to_jiffies(up->uart_dma.rx_poll_rate));
}
up->port_activity = jiffies;
}
@@ -1227,7 +1227,7 @@ static int serial_omap_start_rxdma(struct uart_omap_port *up)
/* FIXME: Cache maintenance needed here? */
omap_start_dma(up->uart_dma.rx_dma_channel);
mod_timer(&up->uart_dma.rx_timer, jiffies +
- usecs_to_jiffies(up->uart_dma.rx_timeout));
+ usecs_to_jiffies(up->uart_dma.rx_poll_rate));
up->uart_dma.rx_dma_used = true;
return ret;
}
@@ -1364,6 +1364,7 @@ static int serial_omap_probe(struct platform_device *pdev)
up->use_dma = 1;
up->uart_dma.rx_buf_size = omap_up_info->dma_rx_buf_size;
up->uart_dma.rx_timeout = omap_up_info->dma_rx_timeout;
+ up->uart_dma.rx_poll_rate = omap_up_info->dma_rx_poll_rate;
spin_lock_init(&(up->uart_dma.tx_lock));
spin_lock_init(&(up->uart_dma.rx_lock));
up->uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 13/15] OMAP2+: UART: Take console_lock in suspend path if not taken
From: Govindraj.R @ 2011-09-21 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316607232-21709-1-git-send-email-govindraj.raja@ti.com>
In suspend path the console_lock is taken by uart_port_suspend
however when no_console_suspend is used console_lock is not taken.
During system wide suspend omap_pwr_domain hooks cut all
clocks that are left enabled. So its unsafe to proceed printing after
clocks are cut by pwr_domain hooks. Also pm_runtime will be disabled after
dpm_suspend devices happens. So buffer all prints in suspend path by taking
console_lock and print them back safely after power domain hooks re-enable
clocks back.
Use CONFIG_SERIAL_OMAP_CONSOLE macro check to take console_lock since
console ops are available only if omap console is defined.
omap-serial can be built as module without console support.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
arch/arm/plat-omap/include/plat/omap-serial.h | 1 +
drivers/tty/serial/omap-serial.c | 20 ++++++++++++++++++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index 28abc6b..de8de87 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -126,6 +126,7 @@ struct uart_omap_port {
u32 context_loss_cnt;
u8 wakeups_enabled;
u32 errata;
+ u8 console_locked;
};
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 64e4ab5..92a1f10 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1133,8 +1133,15 @@ static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
- if (up)
+ if (up) {
uart_suspend_port(&serial_omap_reg, &up->port);
+#ifdef CONFIG_SERIAL_OMAP_CONSOLE
+ if (up->port.line == up->port.cons->index &&
+ !is_console_locked())
+ up->console_locked = console_trylock();
+#endif
+ }
+
return 0;
}
@@ -1142,8 +1149,17 @@ static int serial_omap_resume(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
- if (up)
+ if (up) {
uart_resume_port(&serial_omap_reg, &up->port);
+#ifdef CONFIG_SERIAL_OMAP_CONSOLE
+ if (up->port.line == up->port.cons->index &&
+ up->console_locked) {
+ console_unlock();
+ up->console_locked = 0;
+ }
+#endif
+ }
+
return 0;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 14/15] OMAP2+: UART: Enable back uart clocks with runtime API for early console
From: Govindraj.R @ 2011-09-21 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316607232-21709-1-git-send-email-govindraj.raja@ti.com>
For the early console probing we had avoided hwmod reset and idling
and uart was idled using hwmod API and enabled back using omap_device API
after omap_device registration.
Now since we are using runtime API's to enable back uart move hwmod idling and
use runtime API to enable back UART.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
arch/arm/mach-omap2/serial.c | 26 ++++++++----------------
arch/arm/plat-omap/include/plat/omap-serial.h | 1 +
drivers/tty/serial/omap-serial.c | 1 +
3 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 57d063a..87696bf 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -24,13 +24,11 @@
#include <linux/delay.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
-#include <linux/console.h>
#include <plat/omap-serial.h>
#include <plat/common.h>
#include <plat/board.h>
#include <plat/dma.h>
-#include <plat/omap_hwmod.h>
#include <plat/omap_device.h>
#include <plat/omap-pm.h>
@@ -244,10 +242,16 @@ static void omap_uart_set_forceidle(struct platform_device *pdev)
omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_FORCE);
}
+static void omap_uart_hwmod_idle(struct platform_device *pdev)
+{
+ struct omap_device *od = to_omap_device(pdev);
+
+ omap_hwmod_idle(od->hwmods[0]);
+}
+
#else
static void omap_uart_set_forceidle(struct platform_device *pdev) {}
-static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
-{}
+static void omap_uart_hwmod_idle(struct platform_device *pdev) {}
#endif /* CONFIG_PM */
struct omap_hwmod *omap_uart_hwmod_lookup(int num)
@@ -338,6 +342,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
pdata->enable_wakeup = omap_uart_enable_wakeup;
pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count;
pdata->set_force_idle = omap_uart_set_forceidle;
+ pdata->hwmod_idle = omap_uart_hwmod_idle;
pdata->dma_enabled = info->dma_enabled;
pdata->dma_rx_buf_size = info->dma_rx_buf_size;
pdata->dma_rx_poll_rate = info->dma_rx_poll_rate;
@@ -356,19 +361,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
- console_lock(); /* in case the earlycon is on the UART */
-
- /*
- * Because of early UART probing, UART did not get idled
- * on init. Now that omap_device is ready, ensure full idle
- * before doing omap_device_enable().
- */
- omap_hwmod_idle(oh);
-
- omap_device_enable(pdev);
-
- console_unlock();
-
if ((cpu_is_omap34xx() && bdata->pads))
device_init_wakeup(&pdev->dev, true);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index de8de87..800f215 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -71,6 +71,7 @@ struct omap_uart_port_info {
void (*enable_wakeup)(struct platform_device *, bool);
u32 (*get_context_loss_count)(struct device *);
void (*set_force_idle)(struct platform_device *);
+ void (*hwmod_idle)(struct platform_device *);
};
struct uart_omap_dma {
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 92a1f10..8125a89 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1394,6 +1394,7 @@ static int serial_omap_probe(struct platform_device *pdev)
pm_runtime_irq_safe(&pdev->dev);
if (device_may_wakeup(&pdev->dev)) {
pm_runtime_enable(&pdev->dev);
+ omap_up_info->hwmod_idle(pdev);
pm_runtime_get_sync(&pdev->dev);
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 15/15] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
From: Govindraj.R @ 2011-09-21 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316607232-21709-1-git-send-email-govindraj.raja@ti.com>
If OMAP UART is used as console uart and debug is enabled,
avoid gating of uart clocks to print all debug prints.
If uart clocks are gated then the debug prints from omap_device
framework or hwmod framework can cause uart to enter recursive pm_runtime calls,
which can cause a deadlock over power lock usage.
For example: Say, uart clocks are cut and we get a print from omap_device_disable
stating disabling uart clocks. This print calls omap_uart driver console_write
which will call runtime API get_sync which means we enter from runtime API put
context to runtime API get context.
--> runtime put (take power lock)
--> print disabling uart clocks
--> call uart console write
--> call get_sync (try to take power lock)
Also any clock enable API call from uart driver should not call any uart
operation until clocks are enabled back. Like get_sync having debug print
calling uart console write even before clocks are enabled.
So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used
in debug mode. If so, do not set device_may_wakeup. This will prevent
pm_runtime_enable in uart driver probe and will avoid uart clock gating.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
More details on this topic and experiments done listed here:
http://www.spinics.net/lists/linux-serial/msg04128.html
arch/arm/mach-omap2/serial.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 87696bf..3d92b77f 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -266,8 +266,24 @@ struct omap_hwmod *omap_uart_hwmod_lookup(int num)
return oh;
}
+static int uart_debug;
+
+char *cmdline_find_option(char *str)
+{
+ extern char *saved_command_line;
+
+ return strstr(saved_command_line, str);
+}
+
static int __init omap_serial_early_init(void)
{
+ if (cmdline_find_option("debug") &&
+ cmdline_find_option(OMAP_SERIAL_NAME)) {
+ uart_debug = true;
+ pr_info("OMAP UART used as console in debug mode"
+ " uart clocks will not be gated");
+ }
+
do {
struct omap_hwmod *oh;
@@ -361,7 +377,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
- if ((cpu_is_omap34xx() && bdata->pads))
+ if ((cpu_is_omap34xx() && bdata->pads) && !uart_debug)
device_init_wakeup(&pdev->dev, true);
kfree(pdata);
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 1/2] mmc: sdhci-s3c: add default controller configuration
From: Chris Ball @ 2011-09-21 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002501cc784d$1618f110$424ad330$%kim@samsung.com>
Hi,
On Wed, Sep 21 2011, Kukjin Kim wrote:
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>
> Hi Chris,
>
> This is ok to me. Could you please pick this up in your tree so that I can
> pick 2nd patch up in my tree.
>
> As you know, this patch has no dependency with patch2/2 so that you can
> handle without any conflicts.
Thanks, pushed to mmc-next for 3.2.
I've been waiting for kernel.org to come back up, but I think later
today I'll just move mmc-next to git://dev.laptop.org/users/cjb/mmc,
so this will be available in linux-next soon.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH] gpio/mxc: make it work with imx6q
From: Shawn Guo @ 2011-09-21 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920130508.GE2962@pulham.picochip.com>
On Tue, Sep 20, 2011 at 02:05:09PM +0100, Jamie Iles wrote:
> Hi Shawn,
>
> On Mon, Sep 19, 2011 at 05:10:32PM +0800, Shawn Guo wrote:
> > The imx6q is a Cortex-A9 Quad Core SoC, which has GIC as the primary
> > interrupt controller. GIC requires gpio irq handler to signal EOI,
> > otherwise system will hang whenever there is a gpio irq triggered.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > ---
> > drivers/gpio/gpio-mxc.c | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> > index 4340aca..00b4c9c 100644
> > --- a/drivers/gpio/gpio-mxc.c
> > +++ b/drivers/gpio/gpio-mxc.c
> > @@ -233,6 +233,9 @@ static void mx3_gpio_irq_handler(u32 irq, struct irq_desc *desc)
> > u32 irq_stat;
> > struct mxc_gpio_port *port = irq_get_handler_data(irq);
> >
> > + if (desc->irq_data.chip->irq_eoi)
> > + desc->irq_data.chip->irq_eoi(&desc->irq_data);
> > +
> > irq_stat = readl(port->base + GPIO_ISR) & readl(port->base + GPIO_IMR);
> >
> > mxc_gpio_irq_handler(port, irq_stat);
> > --
> > 1.7.4.1
>
> Could this make use of the chained_irq_enter/chained_irq_exit functions
> added in 10a8c38 (ARM: 6806/1: irq: introduce entry and exit functions
> for chained handlers)?
>
Yes. Will respin the patch to use it.
Thanks for the point, Jamie.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 3/3] net/fec: add imx6q enet support
From: Wolfram Sang @ 2011-09-21 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921115821.GF28907@S2100-06.ap.freescale.net>
On Wed, Sep 21, 2011 at 07:58:22PM +0800, Shawn Guo wrote:
> On Wed, Sep 21, 2011 at 01:32:39PM +0200, Wolfram Sang wrote:
> >
> > > +/* Controller has GBIT support */
> > > +#define FEC_QUIRK_HAS_GBIT (1 << 3)
> >
> > Heh, this is not really a quirk, but a nice feature :) I think we can
> > drop QUIRK if we see driver_data more as "flags" instead of "quirks"?
> > Minor, though.
> >
> As you have told, all these FEC_QUIRK_* are just flags actually. The
> name was pick to keep the consistency, as they are all used for the
> same purpose.
I think introducing FEC_FEATURE_HAS_GBIT would be consistent enough, but
as I said, I don't mind much.
> > Also minor, but the patch looks like a good oportunity to start
> > replacing magic values with proper defines?
> >
> There are already so many magic numbers. It really deserves a separated
> patch.
That is the other possibility, yes. Which sadly never happened.
> I heard that Uwe had a plan to do that some time ago. He gives up
> now? :)
I don't know about this case. Also, it is not about blaming here. It is
totally okay for you to say that you don't want to change your patch to
start replacing the magic values. I mainly wanted to point out the
oportunity here.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110921/780cd0f7/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/2] mmc: sdhci-s3c: add default controller configuration
From: Kukjin Kim @ 2011-09-21 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2boue6qcl.fsf@bob.laptop.org>
Chris Ball wrote:
>
> Hi,
>
> On Wed, Sep 21 2011, Kukjin Kim wrote:
> > Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> >
> > Hi Chris,
> >
> > This is ok to me. Could you please pick this up in your tree so that I
can
> > pick 2nd patch up in my tree.
> >
> > As you know, this patch has no dependency with patch2/2 so that you can
> > handle without any conflicts.
>
> Thanks, pushed to mmc-next for 3.2.
>
Thanks!
> I've been waiting for kernel.org to come back up, but I think later
Yeah, I know...
> today I'll just move mmc-next to git://dev.laptop.org/users/cjb/mmc,
> so this will be available in linux-next soon.
>
Yes, I also moved my tree to git://github.com/kgene/linux-samsung.git...
Anyway, thanks for your information.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 2/7] s3c-adc: describe features via quirk constants
From: Kukjin Kim @ 2011-09-21 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109182243.40440.heiko@sntech.de>
Heiko St?bner wrote:
>
> The adc blocks of S3C2410 through S5P have a multitude of
> quirks, i.e. moved bits or whole new registers.
>
> This patch tries to describe these individual features
> through constants which can be used to describe an adc.
>
> As SoCs sometimes share only some of these quirks defining
> TYPE_ADCVx values for each one wouldn't scale well when
> adding more variants.
>
Hi Heiko,
I don't have idea we really need to use QUIRK in this case...as I know, the
QUIRK is used on other situation...
In addition, the TYPE_ADCVx can support each Samsung SoCs' ADC...but I need
to check again.
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> arch/arm/plat-samsung/adc.c | 29 +++++++++++++++++++++++++++++
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
> index ee8deef..b209d58 100644
> --- a/arch/arm/plat-samsung/adc.c
> +++ b/arch/arm/plat-samsung/adc.c
> @@ -45,6 +45,35 @@ enum s3c_cpu_type {
> TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
> };
>
> +/*
> + * Resolution of the ADC - 10 or 12 bit
> + */
/* ... */
> +#define S3C_ADC_QUIRK_10BIT 0
> +#define S3C_ADC_QUIRK_12BIT (1<<0)
According to coding style, should be added blank around <<.
> +
> +/*
> + * 12bit ADC can switch resolution between 10 bit and 12 bit
> + * ADCCON bit 03 for S3C2416
> + * ADCCON bit 16 for S3C64XX and up
> + */
> +#define S3C_ADC_QUIRK_RESSEL03 (1<<1)
> +#define S3C_ADC_QUIRK_RESSEL16 (1<<2)
Same as above.
> +
> +/*
> + * Input channel select can either be in
> + * - reg ADCCON, bit for S3C24XX and S3C64XX
> + * - reg base+0x18 for 2443/2416/2450
> + * - reg base+0x1C for S5P
> + */
> +#define S3C_ADC_QUIRK_MUXADCCON (1<<3)
> +#define S3C_ADC_QUIRK_MUX18 (1<<4)
> +#define S3C_ADC_QUIRK_MUX1C (1<<5)
Same.
> +
> +/*
> + * CLRINT register on S3C64xx
> + */
/* ... */
> +#define S3C_ADC_QUIRK_CLRINT (1<<6)
Same.
> +
> struct s3c_adc_client {
> struct platform_device *pdev;
> struct list_head pend;
> --
> 1.7.2.3
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 0/5] S5P64X0 PM Support
From: Kukjin Kim @ 2011-09-21 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1313144787-30666-1-git-send-email-a.kesavan@samsung.com>
Abhilash Kesavan wrote:
>
> The patchset adds Power Mangement support for S5P64X0. The first
> four patches lay the groundwork for adding PM support, while the
> final patch adds the SoC specific PM code.
> Tested using external interrupts as wake-up sources on SMDK6440
> and SMDK6450.
>
> Abhilash Kesavan (5):
> ARM: S5P: Make the common S5P PM code conditionally compile
> ARM: SAMSUNG: Make the sleep code common for S3C64XX and newer SoCs
> ARM: S5P64X0: Add pm save/restore functions for GPIO banks
> ARM: S5P64X0: Fix incorrect serial clock name
> ARM: S5P64X0: Add Power Management support
>
> arch/arm/Kconfig | 2 +-
> arch/arm/mach-exynos4/Kconfig | 2 +
> arch/arm/mach-exynos4/Makefile | 2 +-
> arch/arm/mach-exynos4/sleep.S | 54 ------
> arch/arm/mach-s3c64xx/Kconfig | 1 +
> arch/arm/mach-s3c64xx/Makefile | 1 -
> arch/arm/mach-s3c64xx/sleep.S | 72 --------
> arch/arm/mach-s5p64x0/Kconfig | 4 +
> arch/arm/mach-s5p64x0/Makefile | 1 +
> arch/arm/mach-s5p64x0/clock-s5p6440.c | 2 +-
> arch/arm/mach-s5p64x0/clock-s5p6450.c | 2 +-
> arch/arm/mach-s5p64x0/gpiolib.c | 1 +
> arch/arm/mach-s5p64x0/include/mach/map.h | 1 +
> arch/arm/mach-s5p64x0/include/mach/pm-core.h | 117 +++++++++++++
> arch/arm/mach-s5p64x0/include/mach/regs-clock.h | 33 ++++
> arch/arm/mach-s5p64x0/include/mach/regs-gpio.h | 19 ++
> arch/arm/mach-s5p64x0/init.c | 2 +-
> arch/arm/mach-s5p64x0/irq-eint.c | 2 +
> arch/arm/mach-s5p64x0/irq-pm.c | 92 ++++++++++
> arch/arm/mach-s5p64x0/pm.c | 204
> +++++++++++++++++++++++
> arch/arm/mach-s5pv210/Kconfig | 2 +
> arch/arm/mach-s5pv210/Makefile | 2 +-
> arch/arm/mach-s5pv210/sleep.S | 52 ------
> arch/arm/plat-s5p/Kconfig | 6 +
> arch/arm/plat-s5p/Makefile | 3 +-
> arch/arm/plat-samsung/Kconfig | 7 +
> arch/arm/plat-samsung/Makefile | 1 +
> arch/arm/plat-samsung/sleep.S | 80 +++++++++
> drivers/gpio/gpio-plat-samsung.c | 4 +-
> 29 files changed, 583 insertions(+), 188 deletions(-)
> delete mode 100644 arch/arm/mach-exynos4/sleep.S
> delete mode 100644 arch/arm/mach-s3c64xx/sleep.S
> create mode 100644 arch/arm/mach-s5p64x0/include/mach/pm-core.h
> create mode 100644 arch/arm/mach-s5p64x0/irq-pm.c
> create mode 100644 arch/arm/mach-s5p64x0/pm.c
> delete mode 100644 arch/arm/mach-s5pv210/sleep.S
> create mode 100644 arch/arm/plat-samsung/sleep.S
>
> --
> 1.7.4.1
Hi Abhilash,
As I know, you need to rebase this series based on latest for-next.
Please re-submit this series...and I agree with Russell's suggestion on
patch 2/5.
But it's enough to use s3c64xx_smdk_leds_resume() firstly not common smdk
now.
Of course, we need to do it later ;)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Marek Szyprowski @ 2011-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGtgfvbKdjiLpjFxArSVKFeb-GUdmNhN0ra0codPogvbUA@mail.gmail.com>
Hello,
On Wednesday, September 14, 2011 11:53 PM Rob Clark wrote:
> On Wed, Sep 14, 2011 at 2:57 AM, Thomas Hellstrom <thomas@shipmail.org> wrote:
(snipped)
> > Yes, that is true. A root client may be assumed to have AUTH permissions,
> > but the inverse does not hold, meaning that an AUTH client may *not* be
> > assumed to have root permissions. I think there is a ROOT_ONLY ioctl flag
> > for that.
> >
> > The problem I'm seeing compared to other drivers is the following:
> >
> > Imagine for example that you have a disc driver that allocates temporary
> > memory out of the same DMA pool as the DRM driver.
> >
> > Now you have a video player that is a DRM client. It contains a security
> > flaw and is compromized by somebody trying to play a specially crafted video
> > stream. The video player starts to allocate gem buffers until it receives an
> > -ENOMEM. Then it stops allocating and does nothing.
> >
> > Now the system tries an important disc access (paging for example). This
> > fails, because the video player has exhausted all DMA memory and the disc
> > driver fails to allocate.
> >
> > The system is dead.
> >
> > The point is:
> >
> > If there is a chance that other drivers will use the same DMA/CMA pool as
> > the DRM driver, DRM must leave enough DMA/CMA memory for those drivers to
> > work.
>
> ah, ok, I get your point
>
> > The difference compared to other drm drivers:
> >
> > There are other drm drivers that work the same way, with a static allocator.
> > For example "via" and "sis". But those drivers completely claim the
> > resources they are using. Nobody else is expected to use VRAM / AGP.
> >
> > In the Samsung case, it's not clear to me whether the DMA/CMA pool *can* be
> > shared with other devices.
> > If it is, IMHO you must implement an allocation limit in DRM, if not, the
> > driver should probably be safe.
>
> It is possible to create a device private CMA pool.. although OTOH it
> might be desirable to let some other drivers (like v4l2) use buffers
> from the same pool..
Creating a device private CMA pool doesn't prevent other drivers to access
memory from it if there is a way to pass a buffer to them (i.e. using
dma_buf method). However the driver must be able to address that memory.
CMA private pools were designed mainly to resolve the problem that some
weird hardware can access certain types of buffers only at particular
memory address ranges which matches particular memory bank.
> I'm not entirely sure what will happen w/ dma_alloc_coherent, etc, if
> the global CMA pool is exhausted.
>
> Marek? I guess you know what would happen?
The allocation will simply fail and dma_alloc_coherent will return NULL.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Shawn Guo @ 2011-09-21 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921121159.GG1966@pengutronix.de>
On Wed, Sep 21, 2011 at 02:11:59PM +0200, Wolfram Sang wrote:
> On Wed, Sep 21, 2011 at 08:03:42PM +0800, Shawn Guo wrote:
> > On Wed, Sep 21, 2011 at 01:25:55PM +0200, Wolfram Sang wrote:
> > > Hi Shawn,
> > >
> > > On Wed, Sep 21, 2011 at 07:10:30PM +0800, Shawn Guo wrote:
> > > > FEC can work without a phy reset on some platforms, which means not
> > > > very platform necessarily have a phy-reset gpio encoded in device tree.
> > > > So it makes more sense to have the phy-reset-gpio request failure as
> > > > a debug message rather than a warning.
> > >
> > > Or remove it entirely?
> > >
> > I would like to keep it. When people want to debug at this point, they
> > do not need to type the debug message.
>
> I just think the message might be confusing in case you don't need the
> gpio, because then failing is expected behaviour. For those platforms,
> it is not even an error then, so you must drop returning the error. To
> be very precise, you should check of_get_named_gpio() and return if no
> gpio is specified. Then, you can distinguish that case from problems
> when getting the GPIO.
>
The whole fec_reset_phy() should not be a show-stopper failure. Even
on platforms that have the gpio, FEC can work without resetting the
phy in FEC driver for some cases, for example, boot loader has done it.
It might be good enough to give a warning message rather than getting
the probe fail.
> > > I also wanted to suggested to drop returning the error code, since it is
> > > not an error anymore, strictly speaking. Then I noticed that the caller
> > > does not check the error code. So, this could be added or turn the
> > > function to void?
> > >
> > To me, keep the return value as integer is more scalable. Someday,
> > someone need to add more stuff in the function, or want to improve
> > the caller to check return value, it plays.
>
> I agree that keeping it int is way better. But why not add it now to
> keep things proper and tested? If this patch gets accepted as it is and
> later someone else will add error checking to the caller, your platform
> will lose FEC support as a regression.
>
Again, fec_reset_phy() failure is not a show-stopper. We might not
want to make the probe fail because of that.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH V2 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310
From: Tomasz Stanislawski @ 2011-09-21 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <004901cc7856$d7ee21d0$87ca6570$%kim@samsung.com>
On 09/21/2011 02:06 PM, Kukjin Kim wrote:
> Hatim Ali wrote:
>> Add support for TVOUT on SMDKV310 board.
>>
>> Signed-off-by: Hatim Ali<hatim.rv@samsung.com>
>> ---
>> Changes since V1:
>> Incorporated changes as suggested by Tomasz Stanislawski
>> - Added GPIO settings for hot-plug detection.
>> - Added setting hdmi and mixer's parent for TV power domain.
>>
>> arch/arm/mach-exynos4/Kconfig | 2 ++
>> arch/arm/mach-exynos4/mach-smdkv310.c | 25
>> +++++++++++++++++++++++++
>> 2 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
>> index 3b594fe..0bf0fe04 100644
>> --- a/arch/arm/mach-exynos4/Kconfig
>> +++ b/arch/arm/mach-exynos4/Kconfig
>> @@ -131,6 +131,7 @@ config MACH_SMDKV310
>> select S3C_DEV_RTC
>> select S3C_DEV_WDT
>> select S3C_DEV_I2C1
>> + select S5P_DEV_I2C_HDMIPHY
>> select S5P_DEV_MFC
>> select S3C_DEV_HSMMC
>> select S3C_DEV_HSMMC1
>> @@ -140,6 +141,7 @@ config MACH_SMDKV310
>> select EXYNOS4_DEV_AHCI
>> select SAMSUNG_DEV_KEYPAD
>> select EXYNOS4_DEV_PD
>> + select S5P_DEV_TV
>> select SAMSUNG_DEV_PWM
>> select EXYNOS4_DEV_SYSMMU
>> select EXYNOS4_SETUP_FIMD0
>> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
>> exynos4/mach-smdkv310.c
>> index 7ce4d8b..50de270 100644
>> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
>> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
>> @@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[]
>> __initdata = {
>> &s3c_device_hsmmc2,
>> &s3c_device_hsmmc3,
>> &s3c_device_i2c1,
>> + &s5p_device_i2c_hdmiphy,
>> &s3c_device_rtc,
>> &s3c_device_wdt,
>> &exynos4_device_ac97,
>> @@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[]
>> __initdata = {
>> &smdkv310_lcd_lte480wv,
>> &smdkv310_smsc911x,
>> &exynos4_device_ahci,
>> + &s5p_device_hdmi,
>> + &s5p_device_mixer,
>> };
>>
>> static void __init smdkv310_smsc911x_init(void)
>> @@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data
>> smdkv310_bl_data = {
>> .pwm_period_ns = 1000,
>> };
>>
>> +static void s5p_tv_setup(void)
>> +{
>> + int ret;
>> +
>> + /* direct HPD to HDMI chip */
>> + ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
>> +
>> + if (!ret) {
Maybe we should generate WARN_ON(1) here. Failure of gpio request
indicate that
board was configued not correctly.
>> + gpio_direction_input(EXYNOS4_GPX3(7));
>> + s3c_gpio_cfgpin_range(EXYNOS4_GPX3(7),
>> + 1, S3C_GPIO_SFN(3));
> Why do you use 's3c_gpio_cfgpin_range()' for just one gpio pin not range...?
>
>> + } else
>> + pr_err("Failed to request gpio for hpd: %d\n", ret);
> According to coding style, should be added { and } around above.
>
>> +
>> + /* setup dependencies between TV devices */
>> + s5p_device_hdmi.dev.parent =&exynos4_device_pd[PD_TV].dev;
>> + s5p_device_mixer.dev.parent =&exynos4_device_pd[PD_TV].dev;
>> +}
>> +
>> static void __init smdkv310_map_io(void)
>> {
>> s5p_init_io(NULL, 0, S5P_VA_CHIPID);
>> @@ -327,6 +349,9 @@ static void __init smdkv310_machine_init(void)
>> samsung_bl_set(&smdkv310_bl_gpio_info,&smdkv310_bl_data);
>> s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
>>
>> + s5p_tv_setup();
>> + s5p_i2c_hdmiphy_set_platdata(NULL);
>> +
>> platform_add_devices(smdkv310_devices,
>> ARRAY_SIZE(smdkv310_devices));
>> s5p_device_mfc.dev.parent =&exynos4_device_pd[PD_MFC].dev;
>> }
>> --
>> 1.7.2.3
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim<kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>
^ permalink raw reply
* [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Wolfram Sang @ 2011-09-21 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921124423.GI28907@S2100-06.ap.freescale.net>
> > I agree that keeping it int is way better. But why not add it now to
> > keep things proper and tested? If this patch gets accepted as it is and
> > later someone else will add error checking to the caller, your platform
> > will lose FEC support as a regression.
> >
> Again, fec_reset_phy() failure is not a show-stopper. We might not
> want to make the probe fail because of that.
That would be an argument to make the function returning void?
Well, I still think something like
/* No phy reset configured */
if (phy_reset == -ENODEV)
return 0;
might be cleaner, yet I don't have the setup to test such an approach.
So, I'll be quiet now and hope for no problems.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110921/1320571c/attachment.sig>
^ permalink raw reply
* [PATCH V5 0/6] ARM: S5P64X0: Add Framebuffer support
From: Ajay kumar @ 2011-09-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <004a01cc7857$d0d8aa90$7289ffb0$%kim@samsung.com>
Hi Kukjin,
On Wed, Sep 21, 2011 at 5:43 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Ajay Kumar wrote:
>>
>> ?The patches are created against "for-next" branch of Kukjin Kim's tree
> at:
>> ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>
>> ?Changes since V1:
>> ? ? ? - Remove mach/regs-fb.h, instead use plat/regs-fb.h.
>> ? ? ? - Add common pdata for FB and LCD in SMDK6440 and SMDK6450.
>> ? ? ? - Modify names(s5p-->smdk), max_bpp and refresh rate.
>> ? ? ? - Modify variable name(cfg-->chipid).
>> ? ? ? - Use __raw_readl, __raw_writel instead of readl and writel.
>>
>> ?Changes since V2:
>> ? ? ? -Change name of the config-COMMON_FB to SMDK64X0_COMMON_FB.
>> ? ? ? -Change filename common-fb.h to smdk64x0-common-fb.h.
>> ? ? ? -Change filename common-fb.c to smdk64x0-common-fb.c.
>>
>> ?Changes since V3:
>> ? ? ? -Add FB and LCD plat-data in corresponding machine files
>> ? ? ? ?instead of creating common file smdk64x0-common-fb.c.
>> ? ? ? -Modify name S5P64X0_SETUP_FB to S5P64X0_SETUP_FB_24BPP.
>> ? ? ? -Modify file name setup-fb.c to setup-fb-24bpp.c.
>> ? ? ? -Move SPCON settings to machine file.
>> ? ? ? -Use soc_is_s5p6440()/soc_is_s5p6450() to check CPU ID.
>>
>> ?Changes since V4:
>> ? ? ? -Removed refresh rate from plat data(s3c_fb_pd_win)
>> ? ? ? -Fixed complation warning:"function declaration isn't a prototype"
>> ? ? ? ?for s5p6440_set_lcd_interface() and s5p6450_set_lcd_interface().
>>
>>
>> ? These patches have dependency on the patch:
>> ? "ARM: S5P64X0: Fix mask value for S5P64X0 CPU IDs",
>> ? at http://www.spinics.net/lists/arm-kernel/msg138990.html
>>
>> o To Kukjin,
>> ? [PATCH RESEND V5 1/6] video: s3c-fb: Add S5P64X0 specific
>> s3c_fb_driverdata
>> ? [PATCH RESEND V5 2/6] ARM: S5P64X0: Add register base and IRQ for
>> Framebuffer
>> ? [PATCH RESEND V5 3/6] ARM: S5P64X0: Set s3c_device_fb name
>> ? [PATCH RESEND V5 4/6] ARM: S5P64X0: Add GPIO setup for LCD
>> ? [PATCH V5 5/6]ARM: S5P6440: Add LCD-LTE480 and enable Framebuffer
>> support
>> ? [PATCH V5 6/6]ARM: S5P6450: Add LCD-LTE480 and enable Framebuffer
>> support
>>
>> ?arch/arm/mach-s5p64x0/Kconfig ? ? ? ? ? ? ? ? ?| ? 10 +++
>> ?arch/arm/mach-s5p64x0/Makefile ? ? ? ? ? ? ? ? | ? ?1 +
>> ?arch/arm/mach-s5p64x0/cpu.c ? ? ? ? ? ? ? ? ? ?| ? ?3 +
>> ?arch/arm/mach-s5p64x0/include/mach/irqs.h ? ? ?| ? ?4 +
>> ?arch/arm/mach-s5p64x0/include/mach/map.h ? ? ? | ? ?3 +
>> ?arch/arm/mach-s5p64x0/include/mach/regs-gpio.h | ? ?4 +
>> ?arch/arm/mach-s5p64x0/mach-smdk6440.c ? ? ? ? ?| ? 74
>> +++++++++++++++++++++++
>> ?arch/arm/mach-s5p64x0/mach-smdk6450.c ? ? ? ? ?| ? 75
>> ++++++++++++++++++++++++
>> ?arch/arm/mach-s5p64x0/setup-fb-24bpp.c ? ? ? ? | ? 29 +++++++++
>> ?arch/arm/plat-samsung/include/plat/fb.h ? ? ? ?| ? ?7 ++
>> ?drivers/video/s3c-fb.c ? ? ? ? ? ? ? ? ? ? ? ? | ? 27 +++++++++
>> ?11 files changed, 237 insertions(+), 0 deletions(-)
>> ?create mode 100644 arch/arm/mach-s5p64x0/setup-fb-24bpp.c
>
> Looks ok to me, will apply.
>
> But as I said, the 'video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata'
> should be sent to Florian's tree.
Yes. This patch was submitted to fbdev mailing list and Florian has
already accepted it. Here is the link:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/065154.html
> I think, it's enough to re-send it to Florian Tobias Schandina.
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Ajay
^ permalink raw reply
* [PATCH 2/7] s3c-adc: describe features via quirk constants
From: Heiko Stübner @ 2011-09-21 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <005801cc785a$7e46a310$7ad3e930$%kim@samsung.com>
Hi,
Am Mittwoch, 21. September 2011, 14:32:14 schrieben Sie:
> Heiko St?bner wrote:
> > The adc blocks of S3C2410 through S5P have a multitude of
> > quirks, i.e. moved bits or whole new registers.
> >
> > This patch tries to describe these individual features
> > through constants which can be used to describe an adc.
> >
> > As SoCs sometimes share only some of these quirks defining
> > TYPE_ADCVx values for each one wouldn't scale well when
> > adding more variants.
>
> Hi Heiko,
>
> I don't have idea we really need to use QUIRK in this case...as I know, the
> QUIRK is used on other situation...
>
> In addition, the TYPE_ADCVx can support each Samsung SoCs' ADC...but I need
> to check again.
The current types could not support the features of the 2443 and 2416/2450 - I
checked the datasheets.
The mux register in base+0x18 does not exist on any of the current platforms.
Also the bit 3 in ADCCON to select the resolution is specific to the 2416/2450
(see comments above constants and quirk definitions in patches 6 and 7).
So to support these SoCs would require the definition of two new types.
Including these new types in the existing conditionals would introduce a lot
of statements like
if ( (TYPE_X || TYPE_Y) && !TYPE_Z)
In my opinion testing for specific features also describes the difference
between implementations better if one reads the code later on.
I will change the styling of the "<<"s but am wondering why checkpatch did not
complain, i.e. it complains for all other whitespace mistakes one can make but
not these.
Heiko
>
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> >
> > arch/arm/plat-samsung/adc.c | 29 +++++++++++++++++++++++++++++
> > 1 files changed, 29 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
> > index ee8deef..b209d58 100644
> > --- a/arch/arm/plat-samsung/adc.c
> > +++ b/arch/arm/plat-samsung/adc.c
> > @@ -45,6 +45,35 @@ enum s3c_cpu_type {
> >
> > TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
> >
> > };
> >
> > +/*
> > + * Resolution of the ADC - 10 or 12 bit
> > + */
>
> /* ... */
>
> > +#define S3C_ADC_QUIRK_10BIT 0
> > +#define S3C_ADC_QUIRK_12BIT (1<<0)
>
> According to coding style, should be added blank around <<.
>
> > +
> > +/*
> > + * 12bit ADC can switch resolution between 10 bit and 12 bit
> > + * ADCCON bit 03 for S3C2416
> > + * ADCCON bit 16 for S3C64XX and up
> > + */
> > +#define S3C_ADC_QUIRK_RESSEL03 (1<<1)
> > +#define S3C_ADC_QUIRK_RESSEL16 (1<<2)
>
> Same as above.
>
> > +
> > +/*
> > + * Input channel select can either be in
> > + * - reg ADCCON, bit for S3C24XX and S3C64XX
> > + * - reg base+0x18 for 2443/2416/2450
> > + * - reg base+0x1C for S5P
> > + */
> > +#define S3C_ADC_QUIRK_MUXADCCON (1<<3)
> > +#define S3C_ADC_QUIRK_MUX18 (1<<4)
> > +#define S3C_ADC_QUIRK_MUX1C (1<<5)
>
> Same.
>
> > +
> > +/*
> > + * CLRINT register on S3C64xx
> > + */
>
> /* ... */
>
> > +#define S3C_ADC_QUIRK_CLRINT (1<<6)
>
> Same.
>
> > +
> >
> > struct s3c_adc_client {
> >
> > struct platform_device *pdev;
> > struct list_head pend;
> >
> > --
> > 1.7.2.3
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH V2 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310
From: Sylwester Nawrocki @ 2011-09-21 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316583860-32510-2-git-send-email-hatim.rv@samsung.com>
Hi Hatim,
On 09/21/2011 07:44 AM, Hatim Ali wrote:
> Add support for TVOUT on SMDKV310 board.
>
> Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> ---
...
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c
> index 7ce4d8b..50de270 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[] __initdata = {
> &s3c_device_hsmmc2,
> &s3c_device_hsmmc3,
> &s3c_device_i2c1,
> + &s5p_device_i2c_hdmiphy,
> &s3c_device_rtc,
> &s3c_device_wdt,
> &exynos4_device_ac97,
> @@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[] __initdata = {
> &smdkv310_lcd_lte480wv,
> &smdkv310_smsc911x,
> &exynos4_device_ahci,
> + &s5p_device_hdmi,
> + &s5p_device_mixer,
> };
>
> static void __init smdkv310_smsc911x_init(void)
> @@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data smdkv310_bl_data = {
> .pwm_period_ns = 1000,
> };
>
> +static void s5p_tv_setup(void)
> +{
> + int ret;
> +
> + /* direct HPD to HDMI chip */
> + ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
> +
> + if (!ret) {
> + gpio_direction_input(EXYNOS4_GPX3(7));
Since you're probably going to be reworking this anyway, I think gpio_request_one
could be used here for simplicity.
--
Regards,
Sylwester
^ permalink raw reply
* [V3 0/4] ARM: mmp: Add mmc support on pxa910 DKB board
From: Jun Nie @ 2011-09-21 13:07 UTC (permalink / raw)
To: linux-arm-kernel
This patchset add mmc support on PXA910 DKB board.
It is similiar with V2 in Apr, just align with modified sdhci-pxav2
version driver.
Jun Nie (4):
ARM: mmp: add pxa910 mmc resource
ARM: mmp: append mmc 2v8 regulator on dkb board
ARM: mmp: support sd card on pxa910 dkb board
ARM: mmp: support emmc on dkb board
arch/arm/mach-mmp/include/mach/mfp-pxa910.h | 15 ++++
arch/arm/mach-mmp/include/mach/pxa910.h | 15 ++++
arch/arm/mach-mmp/include/mach/regs-apmu.h | 1 +
arch/arm/mach-mmp/pxa910.c | 9 +++
arch/arm/mach-mmp/ttc_dkb.c | 100 +++++++++++++++++++++++++++
5 files changed, 140 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH] mmc: check SDIO card wake up during suspending
From: Jun Nie @ 2011-09-21 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316610446-24183-1-git-send-email-njun@marvell.com>
It is possible that SDIO card issue card interrupt to wake up
system just after SDIO func driver and SDIO card firmware commit
suspend state, while system is still in suspending process and
mmc interrupt is not release yet.
Interrupt storm may happen if func driver does not notify firmware
to clear the wake up source. If func driver issue SDIO bus transaction
to have firmware clear the source and driver try to handle the wake
up event, system may enter suspend before all transaction done.
In this case, SDIO card will not enter lower power mode never. But
system can not be wake up for only card insert/remove/interrupt irq are
listed in wake up source in SD spec. Data/command done irq can
not wake up system.
This patch check SDIO card interrupt and stop system suspend if there
are card interrupt after func driver suspend.
Signed-off-by: Jun Nie <njun@marvell.com>
---
drivers/mmc/core/sdio.c | 14 ++++++++++++++
drivers/mmc/core/sdio_irq.c | 5 +++++
drivers/mmc/host/sdhci.c | 14 +++++++++++++-
include/linux/mmc/card.h | 2 ++
include/linux/mmc/sdio_func.h | 2 ++
5 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index c3ad105..48a4106 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -584,6 +584,14 @@ static int mmc_sdio_suspend(struct mmc_host *host)
for (i = 0; i < host->card->sdio_funcs; i++) {
struct sdio_func *func = host->card->sdio_func[i];
+ /* cancel suspend once we detect external wake up source */
+ if (host->card->pending_interrupt) {
+ host->card->pending_interrupt = 0;
+ err = -EBUSY;
+ printk(KERN_ALERT "%s: wake up event after device suspended\n",
+ mmc_hostname(host));
+ break;
+ }
if (func && sdio_func_present(func) && func->dev.driver) {
const struct dev_pm_ops *pmops = func->dev.driver->pm;
if (!pmops || !pmops->suspend || !pmops->resume) {
@@ -593,10 +601,15 @@ static int mmc_sdio_suspend(struct mmc_host *host)
err = pmops->suspend(&func->dev);
if (err)
break;
+ else
+ /* It is prefer that func driver set it in its
+ suspend function with mmc_claim_host */
+ func->suspended = true;
}
}
while (err && --i >= 0) {
struct sdio_func *func = host->card->sdio_func[i];
+ func->suspended = false;
if (func && sdio_func_present(func) && func->dev.driver) {
const struct dev_pm_ops *pmops = func->dev.driver->pm;
pmops->resume(&func->dev);
@@ -639,6 +652,7 @@ static int mmc_sdio_resume(struct mmc_host *host)
*/
for (i = 0; !err && i < host->card->sdio_funcs; i++) {
struct sdio_func *func = host->card->sdio_func[i];
+ func->suspended = false;
if (func && sdio_func_present(func) && func->dev.driver) {
const struct dev_pm_ops *pmops = func->dev.driver->pm;
err = pmops->resume(&func->dev);
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index bb192f9..2665974 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -49,6 +49,11 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
mmc_card_id(card));
ret = -EINVAL;
} else if (func->irq_handler) {
+ if (func->suspended) {
+ card->pending_interrupt = true;
+ printk(KERN_WARNING "%s: IRQ that arrives in suspend mode"
+ " mode\n", sdio_func_id(func));
+ }
func->irq_handler(func);
count++;
} else {
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 782c0ee..670c141 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -24,6 +24,7 @@
#include <linux/leds.h>
#include <linux/mmc/host.h>
+#include <linux/mmc/card.h>
#include "sdhci.h"
@@ -1631,7 +1632,7 @@ out:
int sdhci_suspend_host(struct sdhci_host *host, pm_message_t state)
{
- int ret;
+ int ret = 0;
sdhci_disable_card_detection(host);
@@ -1644,6 +1645,14 @@ int sdhci_suspend_host(struct sdhci_host *host, pm_message_t state)
if (host->vmmc)
ret = regulator_disable(host->vmmc);
+ if (host->mmc->card && host->mmc->card->pending_interrupt) {
+ DBG("*** %s wake up event after suspend, resuming to handle it\n",
+ mmc_hostname(host->mmc));
+ host->mmc->card->pending_interrupt = 0;
+ sdhci_resume_host(host);
+ ret = -EBUSY;
+ }
+
return ret;
}
@@ -1659,6 +1668,9 @@ int sdhci_resume_host(struct sdhci_host *host)
return ret;
}
+ if (host->mmc->card && host->mmc->card->pending_interrupt)
+ host->mmc->card->pending_interrupt = 0;
+
if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
if (host->ops->enable_dma)
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 8ce0827..2252fe2 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -146,6 +146,8 @@ struct mmc_card {
struct sdio_func_tuple *tuples; /* unknown common tuples */
struct dentry *debugfs_root;
+ /* external interrupt arrived after sdio function suspended */
+ u32 pending_interrupt;
};
#define mmc_card_mmc(c) ((c)->type == MMC_TYPE_MMC)
diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
index 31baaf8..5c1c462 100644
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -59,6 +59,8 @@ struct sdio_func {
const char **info; /* info strings */
struct sdio_func_tuple *tuples;
+
+ int suspended; /* SDIO function driver state */
};
#define sdio_func_present(f) ((f)->state & SDIO_STATE_PRESENT)
--
1.7.0.4
^ permalink raw reply related
* [PATCH] spi: Fix builderror in spi-pl022.c
From: Russell King - ARM Linux @ 2011-09-21 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbsUMCvBofKjExiB2wCbK9CwpcXr5xmShJ4SHEGAAH4Bw@mail.gmail.com>
On Tue, Sep 20, 2011 at 10:45:41PM +0200, Linus Walleij wrote:
> On Mon, Sep 5, 2011 at 2:45 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Sun, Aug 28, 2011 at 9:26 PM, Peter Huewe <peterhuewe@gmx.de> wrote:
> >
> >> This patch fixes a build error, introduced by commit (67fc8b9f, "PM: add
> >> runtime PM support to core Primecell driver") which unfortunately was a little
> >> bit incomplete and did contain a typo (11 instead of 22).
> >> I'm not sure how this patch could have been tested back then, if it
> >> doesn't even compile ;)
> >
> > Grant can you please apply this patch? Right now linux-next is
> > breaking because of this missing patch...
>
> Ping on this... ignore if it's been picked already.
Isn't it already fixed? I've had this in my tree for quite some time
(since 5th September) which should also be in linux-next.
b21c57c ARM: 7079/1: spi: Fix builderror in spi-pl022.c
612f2eb PM: add runtime PM support to MMCI
67fc8b9 PM: add runtime PM support to core Primecell driver
^ permalink raw reply
* [PATCH 2/8] mm: alloc_contig_freed_pages() added
From: Michal Nazarewicz @ 2011-09-21 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315505152.3114.9.camel@nimitz>
On Thu, 08 Sep 2011 20:05:52 +0200, Dave Hansen <dave@linux.vnet.ibm.com>
wrote:
> On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote:
>> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned
>> long end,
>> + gfp_t flag)
>> +{
>> + unsigned long pfn = start, count;
>> + struct page *page;
>> + struct zone *zone;
>> + int order;
>> +
>> + VM_BUG_ON(!pfn_valid(start));
>> + zone = page_zone(pfn_to_page(start));
>
> This implies that start->end are entirely contained in a single zone.
> What enforces that?
In case of CMA, the __cma_activate_area() function from 6/8 has the check:
151 VM_BUG_ON(!pfn_valid(pfn));
152 VM_BUG_ON(page_zone(pfn_to_page(pfn)) !=
zone);
This guarantees that CMA will never try to call alloc_contig_freed_pages()
on a region that spans multiple regions.
> If some higher layer enforces that, I think we probably need at least
> a VM_BUG_ON() in here and a comment about who enforces it.
Agreed.
>> + spin_lock_irq(&zone->lock);
>> +
>> + page = pfn_to_page(pfn);
>> + for (;;) {
>> + VM_BUG_ON(page_count(page) || !PageBuddy(page));
>> + list_del(&page->lru);
>> + order = page_order(page);
>> + zone->free_area[order].nr_free--;
>> + rmv_page_order(page);
>> + __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
>> + pfn += 1 << order;
>> + if (pfn >= end)
>> + break;
>> + VM_BUG_ON(!pfn_valid(pfn));
>> + page += 1 << order;
>> + }
> This 'struct page *'++ stuff is OK, but only for small, aligned areas.
> For at least some of the sparsemem modes (non-VMEMMAP), you could walk
> off of the end of the section_mem_map[] when you cross a MAX_ORDER
> boundary. I'd feel a little bit more comfortable if pfn_to_page() was
> being done each time, or only occasionally when you cross a section
> boundary.
I'm fine with that. I've used pointer arithmetic for performance reasons
but if that may potentially lead to bugs then obviously pfn_to_page()
should
be used.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +-----<email/xmpp: mnazarewicz@google.com>-----ooO--(_)--Ooo--
^ permalink raw reply
* [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Shawn Guo @ 2011-09-21 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921125905.GI1966@pengutronix.de>
On Wed, Sep 21, 2011 at 02:59:05PM +0200, Wolfram Sang wrote:
> > > I agree that keeping it int is way better. But why not add it now to
> > > keep things proper and tested? If this patch gets accepted as it is and
> > > later someone else will add error checking to the caller, your platform
> > > will lose FEC support as a regression.
> > >
> > Again, fec_reset_phy() failure is not a show-stopper. We might not
> > want to make the probe fail because of that.
>
> That would be an argument to make the function returning void?
>
Hmm, it seems to be. Ok, will send v3 to return void.
Regards,
Shawn
> Well, I still think something like
>
> /* No phy reset configured */
> if (phy_reset == -ENODEV)
> return 0;
>
> might be cleaner, yet I don't have the setup to test such an approach.
>
> So, I'll be quiet now and hope for no problems.
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [GIT PULL] davinci fixes for v3.2 merge window
From: Nori, Sekhar @ 2011-09-21 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202210.08714.arnd@arndb.de>
Hi Arnd,
On Wed, Sep 21, 2011 at 01:40:08, Arnd Bergmann wrote:
> Hi Sekhar,
>
> Looking at the patches, they seem to be more of the cleanup category,
> so I think I'd apply them to the next/cleanup branch instead of
> the next/fixes branch. Does that make sense?
Okay. Thanks for pulling them in.
Regards,
Sekhar
^ permalink raw reply
* [PATCH] gpio/mxc: add chained_irq_enter/exit() to mx3_gpio_irq_handler()
From: Shawn Guo @ 2011-09-21 13:24 UTC (permalink / raw)
To: linux-arm-kernel
The mx3_gpio_irq_handler() is also called on imx6q which has GIC as
the primary interrupt controller. As GIC implements the fasteoi flow
control, we need to add chained_irq_enter/exit() to
mx3_gpio_irq_handler() for signaling EOI, otherwise system will hang
whenever there is a gpio irq triggered.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
This is the second post of '[PATCH] gpio/mxc: make it work with imx6q'
to adopt the point given by Jamie.
drivers/gpio/gpio-mxc.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 4340aca..82f7b65 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -30,6 +30,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <asm-generic/bug.h>
+#include <asm/mach/irq.h>
enum mxc_gpio_hwtype {
IMX1_GPIO, /* runs on i.mx1 */
@@ -232,10 +233,15 @@ static void mx3_gpio_irq_handler(u32 irq, struct irq_desc *desc)
{
u32 irq_stat;
struct mxc_gpio_port *port = irq_get_handler_data(irq);
+ struct irq_chip *chip = irq_get_chip(irq);
+
+ chained_irq_enter(chip, desc);
irq_stat = readl(port->base + GPIO_ISR) & readl(port->base + GPIO_IMR);
mxc_gpio_irq_handler(port, irq_stat);
+
+ chained_irq_exit(chip, desc);
}
/* MX2 has one interrupt *for all* gpio ports */
--
1.7.4.1
^ permalink raw reply related
* [PATCH] ARM: vexpress: initial device tree support
From: Rob Herring @ 2011-09-21 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316596786-2539-1-git-send-email-dave.martin@linaro.org>
Dave,
On 09/21/2011 04:19 AM, Dave Martin wrote:
> This patch implements initial support for booting using a flattened
> device tree on the Versatile Express platform.
>
> Eventually, it should be possible to present a single, core-tile-
> independent board, but in this transitional patch the baseboard +
> Cortex-A9x4 core tile combination is the only directly supported
> platform, since the implementation is not yet fully generic.
>
> For now, clocks and timers are not handled via the device tree.
> Implementation of these can follow in later patches.
>
> Thanks to Lorenzo Pieralisi, Grant Likely and Pawe? Moll for their
> help and contributions.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> Acked-by: Pawe? Moll <Pawel.Moll@arm.com>
> ---
>
> There are some outstanding issues which need to be discussed, listed
> below.
>
> * This patch is not currently based on the GIC bindings being
> discussed by Rob Herring et al. Once that discussion reaches a
> conclusion, it should be straightforward to rebase onto the result.
>
> * The following added bindings are not present upstream and need
> documentation / discussion:
>
> * arm,vexpress -- the global board binding for all platform
> combinations using the Versatile Express motherboard.
>
> * arm,vexpress-v2p-ca9 -- the specific binding for the Versatile
> Express motherboard with Cortex-A9x4 core tile installed. It
> is only mentioned as the most-specific match in vexpress-v2p-
> ca9.dts
>
> Since it's intended that the motherboard code should be fully
> generic, and because no other core tiles are upstream yet,
> perhaps we can get rid of this binding right away.
>
> * edid -- It should be possible to have a fairly generic binding
> for EDID interfaces, but none seems to exist yet. Discussion
> is needed regarding what form this should take.
>
> This might more appropriately be called "ddc" (or some
> variation on that), since EDID seems only to describe the
> format of the ID data retrievable via this interface; not the
> interface itself.
>
> * arm,vexpress-flash -- Needed because of the requirement to
> provide the physmap_flash driver with a special .set_vpp
> handler.
>
> * idt,89hpes32h8 -- This is the IDT 89HPES32H8 PCI express
> interconnect switch. This isn't needed for the Versatile
> Express to work, but would be needed if using PCI-e peripherals
> for real. I expect that more driver support needs to go
> upstream before this is actually usable.
>
> * nxp,isp1761 -- The driver support for this is already upstream
> (with some minor issues for ARM support).
>
> * arm,amba-bus -- widely used by other boards and patchsets, but
> seems not to be documented.
>
This should be dropped. There's not really any bus component to an amba
bus. All the probing info is within the primecell peripherals.
> * The following bindings for ARM primecell peripherals are used
> elsewhere but not documented. They should be pretty simple and
> uncontraversial.
> * arm,pl031
> * arm,pl041
> * arm,pl050
> * arm,pl180
> * arm,sp805
>
Plus pl011, pl010, sp804, pl022, pl061
> Rob Herring suggested documenting simple bindings for these
> (and others) along with his initial amba device tree probe
> patches, but these bindings don't seem to be documented
> upstream for now.
>
pl330 went the other route with a file for itself. That may be better to
avoid conflicts. But yes, ARM should document all their peripherals. ;)
I'll do the ones on highbank if you want to do the rest on VExp.
>
> * Shawn Guo's smsc911x patch is needed for Ethernet to work. This is
> headed upstream but not yet in mainline. It is available in -next.
>
> * Minor patches are needed to the isp1760 and pata_generic drivers,
> to allow OF-based initialisation across a wider group of
> architectures. These are being discussed independently, but are
> not yet accepted for merging upstream.
>
> * Most core-tile peripherals are currently not described in the core-
> tile device tree fragment. This is a lower-priority issue since
> the motherboard code already autodetects the core-tile (though only
> one core-tile is fully upstream at the moment).
>
> * Static peripheral mappings are not yet handled in a generic way in
> the board support code. This is a prerequisite for supporting
> multiple core-tiles int the same kernel. It well need to get fixed
> later, when extra core tile support is merged (or before).
>
> Pawe? Moll is looking into this separately.
>
> * The Kconfig logic for ensuring that at least one boot protocol and
> at least one core tile are selected is a bit ugly. Suggestions for
> improving this are certainly welcome.
>
> arch/arm/Kconfig | 1 +
> arch/arm/boot/dts/vexpress-v2m-legacy.dtsi | 163 ++++++++++++++++++++++++++++
> arch/arm/boot/dts/vexpress-v2p-ca9.dts | 80 ++++++++++++++
> arch/arm/configs/vexpress_defconfig | 1 +
> arch/arm/mach-vexpress/Kconfig | 45 ++++++++-
> arch/arm/mach-vexpress/ct-ca9x4.c | 7 ++
> arch/arm/mach-vexpress/v2m.c | 54 +++++++++-
> 7 files changed, 349 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca9.dts
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5ebc5d9..a6e90d5 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -282,6 +282,7 @@ config ARCH_VERSATILE
>
> config ARCH_VEXPRESS
> bool "ARM Ltd. Versatile Express family"
> + select ARCH_VEXPRESS_SANE_CONFIG
> select ARCH_WANT_OPTIONAL_GPIOLIB
> select ARM_AMBA
> select ARM_TIMER_SP804
> diff --git a/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi b/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> new file mode 100644
> index 0000000..fd6e4e4
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> @@ -0,0 +1,163 @@
> +// ARM Ltd. Versatile Express Motherboard V2M-P1 (HBI-0190D)
> +// Legacy memory map
Not sure, but C++ style comments are probably frowned upon in dts too.
> +
> +/ {
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + serial3 = &uart3;
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + };
> +
> + motherboard {
> + compatible = "simple-bus";
> + #address-cells = <2>; // SMB chipselect number and offset
> + #size-cells = <1>;
> + #interrupt-cells = <1>;
> +
> + flash at 0,00000000 {
> + compatible = "arm,vexpress-flash", "cfi-flash";
> + reg = <0 0x00000000 0x04000000
> + 1 0x00000000 0x04000000>;
> + bank-width = <4>;
> + };
> +
> + psram at 2,00000000 {
> + compatible = "mtd-ram";
> + reg = <2 0x00000000 0x02000000>;
> + bank-width = <4>;
> + };
> +
> + ethernet at 3,02000000 {
> + compatible = "smsc,lan9118", "smsc,lan9115";
> + reg = <3 0x02000000 0x10000>;
> + reg-io-width = <4>;
> + interrupts = <15>;
> + smsc,irq-active-high;
> + smsc,irq-push-pull;
> + };
> +
> + usb at 3,03000000 {
> + compatible = "nxp,usb-isp1761";
> + reg = <3 0x03000000 0x20000>;
> + interrupts = <16>;
> + port1-otg;
> + };
> +
> + peripherals at 7,00000000 {
> + compatible = "arm,amba-bus", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 7 0 0x20000>;
> +
> + // PCI-E I2C bus
> + i2c0: i2c at 02000 {
> + compatible = "arm,versatile-i2c";
> + reg = <0x02000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pcie-switch at 60 {
> + compatible = "idt,89hpes32h8";
> + reg = <0x60>;
> + };
> + };
> +
> + aaci at 04000 {
> + compatible = "arm,pl041", "arm,primecell";
> + reg = <0x04000 0x1000>;
> + interrupts = <11>;
> + };
> +
> + mmci at 05000 {
> + compatible = "arm,pl180", "arm,primecell";
> + reg = <0x05000 0x1000>;
> + interrupts = <9 10>;
> + };
> +
> + kmi at 06000 {
> + compatible = "arm,pl050", "arm,primecell";
> + reg = <0x06000 0x1000>;
> + interrupts = <12>;
> + };
> +
> + kmi at 07000 {
> + compatible = "arm,pl050", "arm,primecell";
> + reg = <0x07000 0x1000>;
> + interrupts = <13>;
> + };
> +
> + uart0: uart at 09000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x09000 0x1000>;
> + interrupts = <5>;
> + };
> +
> + uart1: uart at 0a000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0a000 0x1000>;
> + interrupts = <6>;
> + };
> +
> + uart2: uart at 0b000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0b000 0x1000>;
> + interrupts = <7>;
> + };
> +
> + uart3: uart at 0c000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0c000 0x1000>;
> + interrupts = <8>;
> + };
> +
> + wdt at 0f000 {
> + compatible = "arm,sp805", "arm,primecell";
> + reg = <0x0f000 0x1000>;
> + interrupts = <0>;
> + };
> +
> + // Timer init is hardcoded in v2m_timer_init(), for now.
> + // timer at 11000 {
> + // compatible = "arm,arm-sp804";
arm,sp804 is more consistent. I believe the sp804 does have the periphid
registers, so arm,primecell should also be added.
> + // reg = <0x11000 0x1000>;
> + // interrupts = <2>;
> + // };
> +
> + // timer at 12000 {
> + // compatible = "arm,arm-sp804";
> + // reg = <0x12000 0x1000>;
> + // };
Just because Linux is not using it, doesn't mean you should comment it out.
> +
> + // DVI I2C bus (DDC)
> + i2c1: i2c at 16000 {
> + compatible = "arm,versatile-i2c";
> + reg = <0x16000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + edid at 50 {
> + compatible = "edid";
> + reg = <0x50>;
> + };
> + };
> +
> + rtc at 17000 {
> + compatible = "arm,pl031", "arm,primecell";
> + reg = <0x017000 0x1000>;
> + interrupts = <4>;
> + };
> +
> + compact-flash at 1a000 {
> + compatible = "ata-generic";
> + reg = <0x1a000 0x100
> + 0x1a100 0xf00>;
> + reg-shift = <2>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> new file mode 100644
> index 0000000..059be97
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> @@ -0,0 +1,80 @@
> +// ARM Ltd. Versatile Express Corex-A9 (Quad Core) Core Tile V2P-CA9 (HBI-0191B)
> +
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + model = "ARM Versatile Express (Cortex-A9 Quad Core Tile)";
> + compatible = "arm,vexpress-v2p-ca9", "arm,vexpress";
> + interrupt-parent = <&intc>;
> +
> + memory {
> + device_type = "memory";
> + reg = <0x60000000 0x40000000>;
> + };
> +
> + intc: interrupt-controller at 1e001000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <2>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0x1e001000 0x1000>,
> + <0x1e000100 0x100>;
> + };
Is this really all by itself? It should be in the sub-tree of the
appropriate bus.
You need an "interrupt-parent;" line so the parent is not itself.
> +
> + motherboard {
> + ranges = <0 0 0x40000000 0x04000000
> + 1 0 0x44000000 0x04000000
> + 2 0 0x48000000 0x04000000
> + 3 0 0x4c000000 0x04000000
> + 7 0 0x10000000 0x00020000>;
> +
> + interrupt-map-mask = <0 0 63>;
> + interrupt-map = <0 0 0 &intc 32 8
> + 0 0 1 &intc 33 4
> + 0 0 2 &intc 34 4
> + 0 0 3 &intc 35 4
> + 0 0 4 &intc 36 4
> + 0 0 5 &intc 37 4
> + 0 0 6 &intc 38 4
> + 0 0 7 &intc 39 4
> + 0 0 8 &intc 40 4
> + 0 0 9 &intc 41 4
> + 0 0 10 &intc 42 4
> + 0 0 11 &intc 43 4
> + 0 0 12 &intc 44 4
> + 0 0 13 &intc 45 4
> + 0 0 14 &intc 46 4
> + 0 0 15 &intc 47 4
> + 0 0 16 &intc 48 4
> + 0 0 17 &intc 49 4
> + 0 0 18 &intc 50 4
> + 0 0 19 &intc 51 4
> + 0 0 20 &intc 52 4
> + 0 0 21 &intc 53 4
> + 0 0 22 &intc 54 4
> + 0 0 23 &intc 55 4
> + 0 0 24 &intc 56 4
> + 0 0 25 &intc 57 4
> + 0 0 26 &intc 58 4
> + 0 0 27 &intc 59 4
> + 0 0 28 &intc 60 4
> + 0 0 29 &intc 61 4
> + 0 0 30 &intc 62 4
> + 0 0 31 &intc 63 4
> + 0 0 32 &intc 64 4
> + 0 0 33 &intc 65 4
> + 0 0 34 &intc 66 4
> + 0 0 35 &intc 67 4
> + 0 0 36 &intc 68 4
> + 0 0 37 &intc 69 4
> + 0 0 38 &intc 70 4
> + 0 0 39 &intc 71 4
> + 0 0 40 &intc 72 4
> + 0 0 41 &intc 73 4
> + 0 0 42 &intc 74 4>;
> + };
> +};
> +
> +/include/ "vexpress-v2m-legacy.dtsi"
> diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig
> index f2de51f..6c3c5f6 100644
> --- a/arch/arm/configs/vexpress_defconfig
> +++ b/arch/arm/configs/vexpress_defconfig
> @@ -22,6 +22,7 @@ CONFIG_MODULE_UNLOAD=y
> # CONFIG_IOSCHED_DEADLINE is not set
> # CONFIG_IOSCHED_CFQ is not set
> CONFIG_ARCH_VEXPRESS=y
> +CONFIG_ARCH_VEXPRESS_ATAGS=y
> CONFIG_ARCH_VEXPRESS_CA9X4=y
> # CONFIG_SWP_EMULATE is not set
> CONFIG_SMP=y
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index 9311484..ea64630 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -1,12 +1,55 @@
> menu "Versatile Express platform type"
> depends on ARCH_VEXPRESS
>
> +# ARCH_VEXPRESS ensures a sane minimal config is selected by selecting
> +# ARCH_VEXPRESS_SANE_CONFIG.
> +# Extend the logic here when adding new core tiles.
> +
> +config ARCH_VEXPRESS_SANE_CONFIG
> + bool
> + select ARCH_VEXPRESS_CA9X4
> + select ARCH_VEXPRESS_ATAGS if !ARCH_VEXPRESS_DT
> +
> +
> +comment "At least one boot type must be selected"
> +
> +config ARCH_VEXPRESS_ATAGS
> + bool "Boot via ATAGs"
> + default y
> + help
> + This option enables support for the board using the standard
> + ATAGs boot protocol.
> +
> + If your bootloader supports FDT-based booting and you do not
> + intend ever to boot via the traditional ATAGs method, you can say
> + N here.
> +
> +config ARCH_VEXPRESS_DT
> + bool "Boot via Device Tree"
> + select USE_OF
> + help
> + This option enables support for the board, and enables booting
> + via a Flattened Device Tree provided by the bootloader.
> +
> + If your bootloader supports FDT-based booting, you can say Y
> + here, otherwise, say N.
> +
> +
> +# Core Tile support options
> +
> +comment "At least one core tile must be selected"
> +
> config ARCH_VEXPRESS_CA9X4
> - bool "Versatile Express Cortex-A9x4 tile"
> + bool "Versatile Express Cortex-A9x4 Core Tile"
> + default y
> select CPU_V7
> select ARM_GIC
> select ARM_ERRATA_720789
> select ARM_ERRATA_751472
> select ARM_ERRATA_753970
> + help
> + Include support for the Cortex-A9x4 Core Tile (HBI-0191B).
> +
> + If unsure, say Y.
>
> endmenu
> diff --git a/arch/arm/mach-vexpress/ct-ca9x4.c b/arch/arm/mach-vexpress/ct-ca9x4.c
> index bfd32f5..e2fe2c9 100644
> --- a/arch/arm/mach-vexpress/ct-ca9x4.c
> +++ b/arch/arm/mach-vexpress/ct-ca9x4.c
> @@ -9,6 +9,7 @@
> #include <linux/amba/bus.h>
> #include <linux/amba/clcd.h>
> #include <linux/clkdev.h>
> +#include <linux/irqdomain.h>
>
> #include <asm/hardware/arm_timer.h>
> #include <asm/hardware/cache-l2x0.h>
> @@ -59,10 +60,16 @@ static void __init ct_ca9x4_map_io(void)
> iotable_init(ct_ca9x4_io_desc, ARRAY_SIZE(ct_ca9x4_io_desc));
> }
>
> +static const struct of_device_id gic_of_match[] __initconst = {
> + { .compatible = "arm,cortex-a9-gic", },
> + {}
> +};
> +
> static void __init ct_ca9x4_init_irq(void)
> {
> gic_init(0, 29, MMIO_P2V(A9_MPCORE_GIC_DIST),
> MMIO_P2V(A9_MPCORE_GIC_CPU));
> + irq_domain_generate_simple(gic_of_match, A9_MPCORE_GIC_DIST, 0);
> }
>
> #if 0
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 9e6b93b..6defce6 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -6,6 +6,8 @@
> #include <linux/amba/mmci.h>
> #include <linux/io.h>
> #include <linux/init.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/ata_platform.h>
> #include <linux/smsc911x.h>
> @@ -118,7 +120,7 @@ int v2m_cfg_read(u32 devfn, u32 *data)
> return !!(val & SYS_CFG_ERR);
> }
>
> -
> +#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
> static struct resource v2m_pcie_i2c_resource = {
> .start = V2M_SERIAL_BUS_PCI,
> .end = V2M_SERIAL_BUS_PCI + SZ_4K - 1,
> @@ -200,6 +202,7 @@ static struct platform_device v2m_usb_device = {
> .num_resources = ARRAY_SIZE(v2m_usb_resources),
> .dev.platform_data = &v2m_usb_config,
> };
> +#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
>
> static void v2m_flash_set_vpp(struct platform_device *pdev, int on)
> {
> @@ -211,6 +214,7 @@ static struct physmap_flash_data v2m_flash_data = {
> .set_vpp = v2m_flash_set_vpp,
> };
>
> +#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
> static struct resource v2m_flash_resources[] = {
> {
> .start = V2M_NOR0,
> @@ -254,6 +258,7 @@ static struct platform_device v2m_cf_device = {
> .num_resources = ARRAY_SIZE(v2m_pata_resources),
> .dev.platform_data = &v2m_pata_data,
> };
> +#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
>
> static unsigned int v2m_mmci_status(struct device *dev)
> {
> @@ -265,6 +270,7 @@ static struct mmci_platform_data v2m_mmci_data = {
> .status = v2m_mmci_status,
> };
>
> +#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
> static AMBA_DEVICE(aaci, "mb:aaci", V2M_AACI, NULL);
> static AMBA_DEVICE(mmci, "mb:mmci", V2M_MMCI, &v2m_mmci_data);
> static AMBA_DEVICE(kmi0, "mb:kmi0", V2M_KMI0, NULL);
> @@ -288,6 +294,7 @@ static struct amba_device *v2m_amba_devs[] __initdata = {
> &wdt_device,
> &rtc_device,
> };
> +#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
>
>
> static long v2m_osc_round(struct clk *clk, unsigned long rate)
> @@ -415,6 +422,8 @@ static void __init v2m_init_irq(void)
> ct_desc->init_irq();
> }
>
> +
> +#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
> static void __init v2m_init(void)
> {
> int i;
> @@ -443,3 +452,46 @@ MACHINE_START(VEXPRESS, "ARM-Versatile Express")
> .timer = &v2m_timer,
> .init_machine = v2m_init,
> MACHINE_END
> +#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
> +
> +#ifdef CONFIG_ARCH_VEXPRESS_DT
> +struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
> + OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash", &v2m_flash_data),
> + OF_DEV_AUXDATA("arm,primecell", V2M_AACI, "mb:aaci", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_WDT, "mb:wdt", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
> + OF_DEV_AUXDATA("arm,primecell", V2M_KMI0, "mb:kmi0", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_KMI1, "mb:kmi1", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_UART0, "mb:uart0", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_UART1, "mb:uart1", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_UART2, "mb:uart2", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_UART3, "mb:uart3", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_RTC, "mb:rtc", NULL),
> + {}
> +};
> +
> +static void __init v2m_dt_init(void)
> +{
> + of_platform_populate(NULL, of_default_bus_match_table,
> + v2m_dt_auxdata_lookup, NULL);
> +
> + pm_power_off = v2m_power_off;
> + arm_pm_restart = v2m_restart;
> +
> + ct_desc->init_tile();
> +}
> +
> +static const char *v2m_dt_match[] __initconst = {
> + "arm,vexpress",
> + NULL,
> +};
> +
> +DT_MACHINE_START(VEXPRESS_DT, "ARM Versatile Express")
> + .map_io = v2m_map_io,
> + .init_early = v2m_init_early,
> + .init_irq = v2m_init_irq,
> + .timer = &v2m_timer,
> + .init_machine = v2m_dt_init,
> + .dt_compat = v2m_dt_match,
> +MACHINE_END
> +#endif /* CONFIG_ARCH_VEXPRESS_DT */
All the ifdefs are really ugly. Most people are creating new board_dt.c
file and copying over pieces they need. Once DT support is on par with
the old file, the old file can be deleted.
Rob
^ permalink raw reply
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