* [PATCH] ARM: SAMSUNG: Add naming of s3c64xx-spi devices
From: Heiko Stübner @ 2012-10-02 12:43 UTC (permalink / raw)
To: linux-arm-kernel
Commit a5238e360b71 (spi: s3c64xx: move controller information into driver
data) introduced separate device names for the different subtypes of the
spi controller but forgot to set these in the relevant machines.
To fix this introduce a s3c64xx_spi_setname function and populate all
Samsung arches with the correct names. The function resides in a new
header, as the s3c64xx-spi.h contains driver platform data and should
therefore at some later point move out of the Samsung include dir.
Tested on a s3c2416-based machine.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Cc: stable at vger.kernel.org
---
arch/arm/mach-exynos/common.c | 5 ++++
arch/arm/mach-s3c24xx/s3c2416.c | 2 +
arch/arm/mach-s3c24xx/s3c2443.c | 4 +++
arch/arm/mach-s5p64x0/common.c | 3 ++
arch/arm/mach-s5pc100/common.c | 3 ++
arch/arm/mach-s5pv210/common.c | 3 ++
arch/arm/plat-samsung/include/plat/spi-core.h | 30 +++++++++++++++++++++++++
7 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-samsung/include/plat/spi-core.h
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 4eb39cd..3e02ae6 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -47,6 +47,7 @@
#include <plat/fimc-core.h>
#include <plat/iic-core.h>
#include <plat/tv-core.h>
+#include <plat/spi-core.h>
#include <plat/regs-serial.h>
#include "common.h"
@@ -346,6 +347,8 @@ static void __init exynos4_map_io(void)
s5p_fb_setname(0, "exynos4-fb");
s5p_hdmi_setname("exynos4-hdmi");
+
+ s3c64xx_spi_setname("exynos4210-spi");
}
static void __init exynos5_map_io(void)
@@ -366,6 +369,8 @@ static void __init exynos5_map_io(void)
s3c_i2c0_setname("s3c2440-i2c");
s3c_i2c1_setname("s3c2440-i2c");
s3c_i2c2_setname("s3c2440-i2c");
+
+ s3c64xx_spi_setname("exynos4210-spi");
}
static void __init exynos4_init_clocks(int xtal)
diff --git a/arch/arm/mach-s3c24xx/s3c2416.c b/arch/arm/mach-s3c24xx/s3c2416.c
index 20507c7..a24960c 100644
--- a/arch/arm/mach-s3c24xx/s3c2416.c
+++ b/arch/arm/mach-s3c24xx/s3c2416.c
@@ -61,6 +61,7 @@
#include <plat/nand-core.h>
#include <plat/adc-core.h>
#include <plat/rtc-core.h>
+#include <plat/spi-core.h>
static struct map_desc s3c2416_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
@@ -147,6 +148,7 @@ void __init s3c2416_map_io(void)
/* initialize device information early */
s3c2416_default_sdhci0();
s3c2416_default_sdhci1();
+ s3c64xx_spi_setname("s3c2443-spi");
iotable_init(s3c2416_iodesc, ARRAY_SIZE(s3c2416_iodesc));
}
diff --git a/arch/arm/mach-s3c24xx/s3c2443.c b/arch/arm/mach-s3c24xx/s3c2443.c
index ab648ad..165b6a6 100644
--- a/arch/arm/mach-s3c24xx/s3c2443.c
+++ b/arch/arm/mach-s3c24xx/s3c2443.c
@@ -43,6 +43,7 @@
#include <plat/nand-core.h>
#include <plat/adc-core.h>
#include <plat/rtc-core.h>
+#include <plat/spi-core.h>
static struct map_desc s3c2443_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
@@ -100,6 +101,9 @@ void __init s3c2443_map_io(void)
s3c24xx_gpiocfg_default.set_pull = s3c2443_gpio_setpull;
s3c24xx_gpiocfg_default.get_pull = s3c2443_gpio_getpull;
+ /* initialize device information early */
+ s3c64xx_spi_setname("s3c2443-spi");
+
iotable_init(s3c2443_iodesc, ARRAY_SIZE(s3c2443_iodesc));
}
diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
index 6e6a0a9..111e404 100644
--- a/arch/arm/mach-s5p64x0/common.c
+++ b/arch/arm/mach-s5p64x0/common.c
@@ -44,6 +44,7 @@
#include <plat/sdhci.h>
#include <plat/adc-core.h>
#include <plat/fb-core.h>
+#include <plat/spi-core.h>
#include <plat/gpio-cfg.h>
#include <plat/regs-irqtype.h>
#include <plat/regs-serial.h>
@@ -179,6 +180,7 @@ void __init s5p6440_map_io(void)
/* initialize any device information early */
s3c_adc_setname("s3c64xx-adc");
s3c_fb_setname("s5p64x0-fb");
+ s3c64xx_spi_setname("s5p64x0-spi");
s5p64x0_default_sdhci0();
s5p64x0_default_sdhci1();
@@ -193,6 +195,7 @@ void __init s5p6450_map_io(void)
/* initialize any device information early */
s3c_adc_setname("s3c64xx-adc");
s3c_fb_setname("s5p64x0-fb");
+ s3c64xx_spi_setname("s5p64x0-spi");
s5p64x0_default_sdhci0();
s5p64x0_default_sdhci1();
diff --git a/arch/arm/mach-s5pc100/common.c b/arch/arm/mach-s5pc100/common.c
index 6219086..cc6e561 100644
--- a/arch/arm/mach-s5pc100/common.c
+++ b/arch/arm/mach-s5pc100/common.c
@@ -45,6 +45,7 @@
#include <plat/fb-core.h>
#include <plat/iic-core.h>
#include <plat/onenand-core.h>
+#include <plat/spi-core.h>
#include <plat/regs-serial.h>
#include <plat/watchdog-reset.h>
@@ -165,6 +166,8 @@ void __init s5pc100_map_io(void)
s3c_onenand_setname("s5pc100-onenand");
s3c_fb_setname("s5pc100-fb");
s3c_cfcon_setname("s5pc100-pata");
+
+ s3c64xx_spi_setname("s5pc100-spi");
}
void __init s5pc100_init_clocks(int xtal)
diff --git a/arch/arm/mach-s5pv210/common.c b/arch/arm/mach-s5pv210/common.c
index 4c9e902..a0c50ef 100644
--- a/arch/arm/mach-s5pv210/common.c
+++ b/arch/arm/mach-s5pv210/common.c
@@ -43,6 +43,7 @@
#include <plat/iic-core.h>
#include <plat/keypad-core.h>
#include <plat/tv-core.h>
+#include <plat/spi-core.h>
#include <plat/regs-serial.h>
#include "common.h"
@@ -196,6 +197,8 @@ void __init s5pv210_map_io(void)
/* setup TV devices */
s5p_hdmi_setname("s5pv210-hdmi");
+
+ s3c64xx_spi_setname("s5pv210-spi");
}
void __init s5pv210_init_clocks(int xtal)
diff --git a/arch/arm/plat-samsung/include/plat/spi-core.h b/arch/arm/plat-samsung/include/plat/spi-core.h
new file mode 100644
index 0000000..0b9428a
--- /dev/null
+++ b/arch/arm/plat-samsung/include/plat/spi-core.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2012 Heiko Stuebner <heiko@sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PLAT_S3C_SPI_CORE_H
+#define __PLAT_S3C_SPI_CORE_H
+
+/* These functions are only for use with the core support code, such as
+ * the cpu specific initialisation code
+ */
+
+/* re-define device name depending on support. */
+static inline void s3c64xx_spi_setname(char *name)
+{
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+ s3c64xx_device_spi0.name = name;
+#endif
+#ifdef CONFIG_S3C64XX_DEV_SPI1
+ s3c64xx_device_spi1.name = name;
+#endif
+#ifdef CONFIG_S3C64XX_DEV_SPI2
+ s3c64xx_device_spi2.name = name;
+#endif
+}
+
+#endif /* __PLAT_S3C_SPI_CORE_H */
--
1.7.2.3
^ permalink raw reply related
* How many cores does the ARM branch support?
From: Arnd Bergmann @ 2012-10-02 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002043106.GD21233@work1>
On Tuesday 02 October 2012, Michelle Konzack wrote:
> I have gotten a new gadget which run only with 700MHz but has 32 cores.
> Support 16 GE Interfaces a 50 Gbit universal interface and 4 PCIe ports,
> SATA HDD and much more...
>
> ...and yes, this ARM microcontroller is a telecommunications controller.
>
> However, I have the Evaluation Kit and a PCIe graphiccard and now
> installed Debian ARMEL. Unfortunately I get only 2 cores working...
>
> What must I do to get the other 30 cores?
You have to be a little more specific with the configuration. The mainline
kernel supports no hardware that have more than 4 cores at the moment, so
whatever kernel you are running already has to have some out of tree patches
on it. The system you describe sounds interesting enough to make everyone
want to have another look, but there is no point without looking at those
patches first. Could you upload them to a public git tree?
I suspect that the system you have actually has 16 dual-core systems on
a chip (or on a board), so you could run up to 16 separate instances of
Linux on it, but not a single instance that sees all the cores.
Arnd
^ permalink raw reply
* [PATCH 11/12] pinctrl: samsung: use __devinit section for init code
From: Linus Walleij @ 2012-10-02 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210021152.30099.arnd@arndb.de>
On Tue, Oct 2, 2012 at 1:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 01 October 2012, Linus Walleij wrote:
>> On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> > The samsung pinctrl driver has a probe function that is
>> > __devinit and that calls a lot of other functions that are
>> > marked __init, which kbuild complains about.
>> >
>> > Marking everything __devinit means that the code does not
>> > discarded when CONFIG_HOTPLUG is set, which is a little
>> > more wasteful, but also more consistent
>> >
>> > Without this patch, building exynos_defconfig results in:
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> I think the Samsing pinctrl driver has landed into next from some
>> branch in ARM SoC so you probably know better than me
>> where this thing should be merged...
>>
>
> Sorry, I was too late for this one. Can you pick it up now that the
> driver is merged?
Sure I've queued it for my -rc fixes.
Thanks,
Linus Walleij
^ permalink raw reply
* [PATCH 08/10] ARM: ux500: Stop calling the UIB init function when using Device Tree
From: Linus Walleij @ 2012-10-02 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002121533.GA26783@gmail.com>
On Tue, Oct 2, 2012 at 2:15 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Tue, 02 Oct 2012, Linus Walleij wrote:
>
>> On Tue, Oct 2, 2012 at 10:13 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > As there will be a Device Tree created for the UIBs, there is no
>> > need to call the UIB initiation functions. Each device will be
>> > detailed and registered from the Device Tree instead.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> Acked-by, but...
>>
>> > - .init_late = ux500_init_late,
>> > + .init_late = NULL,
>>
>> Why even define it?
>
> More to show that we're _intentionally_ not using it.
>
> I'm happy to remove if it offends you? :)
No, I was just asking. I did ACK it...
Thanks,
Linus Walleij
^ permalink raw reply
* [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
From: Mark Brown @ 2012-10-02 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002124321.GD30762@arwen.pp.htv.fi>
On Tue, Oct 02, 2012 at 03:43:22PM +0300, Felipe Balbi wrote:
> BTW, OTOH writing all children into the DT actually describes the HW,
> no ? And depending on the device I feel it'd be better to write that
Well, it depends on the hardware. Some hardware has a bunch of nice,
neat IPs which can usefully be reproduced and which map sensibly onto OS
abstractions but a lot of it doesn't and frequently the abstractions
which Linux wants to use don't bear a huge resemblance to the hardware
(and Linux's ideas can change over time, as with the clock API being
factored out for example).
> data to DT. Think of twlxxxx (TI's PMICs), we might have completely
> unrelated drivers using one of TWL's GPIO lines as an interrupt source.
> If that particular children isn't listed in DT, it can't be used as an
> interrupt-parent, right ?
You can have the interrupt controller there without having to list every
IP in the device, just make the parent device the interrupt controller
to DT.
^ permalink raw reply
* [PATCH 0/2] Add DMA and device tree support to the flash controller FLCTL
From: Bastian Hecht @ 2012-10-02 13:12 UTC (permalink / raw)
To: linux-arm-kernel
This mini-series consists of 2 separately posted patch-sets that shrunk
to one patch each. It adds DMA support for the data part (not ECC) as
well as device tree support to the FLCTL flash controller.
As the 2nd patch is based on the 1st, I've decided to
collect them here to avoid any confusion.
The first set contained
[PATCH 1/2] mtd: sh_flctl: Setup and release DMA channels
[PATCH 2/2] mtd: sh_flctl: Use DMA for data fifo FLTDFIFO when available
and was merged after 2 reviews to
[PATCH] mtd: sh_flctl: Add DMA capabilty (same patch as in here)
The second set contained
[PATCH 1/3] mtd: sh_flctl: Probe SNAND_E flag from NAND chip
[PATCH 2/3] mtd: sh_flctl: Add device tree support
[PATCH 3/3] mtd: sh_flctl: Add sh7372 device tree config
and is merged here to
mtd: sh_flctl: Add device tree support
Patch 1 can be omitted as SNAND_E is handled in the FLCTL source anyway
correctly in set_cmd_regs() and the flag can be removed from existing board
codes without this patch.
Patch 2 without patch 3 may be confusing so I merged them too. Documentation
is added as well.
I've added linux-arm-kernel at lists.infradead.org as recipient for the
device tree part.
The patchset is based on
l2-mtd git://git.infradead.org/users/dedekind/l2-mtd.git
with reverted commit e26c113b4130aefa1d8446602bb5b05cfd646bfe.
Bastian Hecht (2):
mtd: sh_flctl: Add DMA capabilty
mtd: sh_flctl: Add device tree support
.../devicetree/bindings/mtd/flctl-nand.txt | 37 +++
drivers/mtd/nand/sh_flctl.c | 266 +++++++++++++++++++-
include/linux/mtd/sh_flctl.h | 12 +
3 files changed, 305 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/flctl-nand.txt
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/2] mtd: sh_flctl: Add DMA capabilty
From: Bastian Hecht @ 2012-10-02 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349183522-15321-1-git-send-email-hechtb@gmail.com>
The code probes if DMA channels can get allocated and tears them down at
removal/failure if needed.
If available it uses them to transfer the data part (not ECC). On
failure we fall back to PIO mode.
Based on Guennadi Liakhovetski's code from the sh_mmcif driver.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
drivers/mtd/nand/sh_flctl.c | 174 +++++++++++++++++++++++++++++++++++++++++-
include/linux/mtd/sh_flctl.h | 12 +++
2 files changed, 183 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
index 4fbfe96..0fead2a 100644
--- a/drivers/mtd/nand/sh_flctl.c
+++ b/drivers/mtd/nand/sh_flctl.c
@@ -24,10 +24,13 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/delay.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
+#include <linux/sh_dma.h>
#include <linux/slab.h>
#include <linux/string.h>
@@ -106,6 +109,84 @@ static void wait_completion(struct sh_flctl *flctl)
writeb(0x0, FLTRCR(flctl));
}
+static void flctl_dma_complete(void *param)
+{
+ struct sh_flctl *flctl = param;
+
+ complete(&flctl->dma_complete);
+}
+
+static void flctl_release_dma(struct sh_flctl *flctl)
+{
+ if (flctl->chan_fifo0_rx) {
+ dma_release_channel(flctl->chan_fifo0_rx);
+ flctl->chan_fifo0_rx = NULL;
+ }
+ if (flctl->chan_fifo0_tx) {
+ dma_release_channel(flctl->chan_fifo0_tx);
+ flctl->chan_fifo0_tx = NULL;
+ }
+}
+
+static void flctl_setup_dma(struct sh_flctl *flctl)
+{
+ dma_cap_mask_t mask;
+ struct dma_slave_config cfg;
+ struct platform_device *pdev = flctl->pdev;
+ struct sh_flctl_platform_data *pdata = pdev->dev.platform_data;
+ int ret;
+
+ if (!pdata)
+ return;
+
+ if (pdata->slave_id_fifo0_tx <= 0 || pdata->slave_id_fifo0_rx <= 0)
+ return;
+
+ /* We can only either use DMA for both Tx and Rx or not use it@all */
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+
+ flctl->chan_fifo0_tx = dma_request_channel(mask, shdma_chan_filter,
+ (void *)pdata->slave_id_fifo0_tx);
+ dev_dbg(&pdev->dev, "%s: TX: got channel %p\n", __func__,
+ flctl->chan_fifo0_tx);
+
+ if (!flctl->chan_fifo0_tx)
+ return;
+
+ memset(&cfg, 0, sizeof(cfg));
+ cfg.slave_id = pdata->slave_id_fifo0_tx;
+ cfg.direction = DMA_MEM_TO_DEV;
+ cfg.dst_addr = (dma_addr_t)FLDTFIFO(flctl);
+ cfg.src_addr = 0;
+ ret = dmaengine_slave_config(flctl->chan_fifo0_tx, &cfg);
+ if (ret < 0)
+ goto err;
+
+ flctl->chan_fifo0_rx = dma_request_channel(mask, shdma_chan_filter,
+ (void *)pdata->slave_id_fifo0_rx);
+ dev_dbg(&pdev->dev, "%s: RX: got channel %p\n", __func__,
+ flctl->chan_fifo0_rx);
+
+ if (!flctl->chan_fifo0_rx)
+ goto err;
+
+ cfg.slave_id = pdata->slave_id_fifo0_rx;
+ cfg.direction = DMA_DEV_TO_MEM;
+ cfg.dst_addr = 0;
+ cfg.src_addr = (dma_addr_t)FLDTFIFO(flctl);
+ ret = dmaengine_slave_config(flctl->chan_fifo0_rx, &cfg);
+ if (ret < 0)
+ goto err;
+
+ init_completion(&flctl->dma_complete);
+
+ return;
+
+err:
+ flctl_release_dma(flctl);
+}
+
static void set_addr(struct mtd_info *mtd, int column, int page_addr)
{
struct sh_flctl *flctl = mtd_to_flctl(mtd);
@@ -261,6 +342,70 @@ static void wait_wecfifo_ready(struct sh_flctl *flctl)
timeout_error(flctl, __func__);
}
+static int flctl_dma_fifo0_transfer(struct sh_flctl *flctl, unsigned long *buf,
+ int len, enum dma_data_direction dir)
+{
+ struct dma_async_tx_descriptor *desc = NULL;
+ struct dma_chan *chan;
+ enum dma_transfer_direction tr_dir;
+ dma_addr_t dma_addr;
+ dma_cookie_t cookie = -EINVAL;
+ uint32_t reg;
+ int ret;
+
+ if (dir == DMA_FROM_DEVICE) {
+ chan = flctl->chan_fifo0_rx;
+ tr_dir = DMA_DEV_TO_MEM;
+ } else {
+ chan = flctl->chan_fifo0_tx;
+ tr_dir = DMA_MEM_TO_DEV;
+ }
+
+ dma_addr = dma_map_single(chan->device->dev, buf, len, dir);
+
+ if (dma_addr)
+ desc = dmaengine_prep_slave_single(chan, dma_addr, len,
+ tr_dir, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+
+ if (desc) {
+ reg = readl(FLINTDMACR(flctl));
+ reg |= DREQ0EN;
+ writel(reg, FLINTDMACR(flctl));
+
+ desc->callback = flctl_dma_complete;
+ desc->callback_param = flctl;
+ cookie = dmaengine_submit(desc);
+
+ dma_async_issue_pending(chan);
+ } else {
+ /* DMA failed, fall back to PIO */
+ flctl_release_dma(flctl);
+ dev_warn(&flctl->pdev->dev,
+ "DMA failed, falling back to PIO\n");
+ ret = -EIO;
+ goto out;
+ }
+
+ ret =
+ wait_for_completion_timeout(&flctl->dma_complete,
+ msecs_to_jiffies(3000));
+
+ if (ret <= 0) {
+ chan->device->device_control(chan, DMA_TERMINATE_ALL, 0);
+ dev_err(&flctl->pdev->dev, "wait_for_completion_timeout\n");
+ }
+
+out:
+ reg = readl(FLINTDMACR(flctl));
+ reg &= ~DREQ0EN;
+ writel(reg, FLINTDMACR(flctl));
+
+ dma_unmap_single(chan->device->dev, dma_addr, len, dir);
+
+ /* ret > 0 is success */
+ return ret;
+}
+
static void read_datareg(struct sh_flctl *flctl, int offset)
{
unsigned long data;
@@ -279,11 +424,20 @@ static void read_fiforeg(struct sh_flctl *flctl, int rlen, int offset)
len_4align = (rlen + 3) / 4;
+ /* initiate DMA transfer */
+ if (flctl->chan_fifo0_rx && rlen >= 32 &&
+ flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_DEV_TO_MEM) > 0)
+ goto convert; /* DMA success */
+
+ /* do polling transfer */
for (i = 0; i < len_4align; i++) {
wait_rfifo_ready(flctl);
buf[i] = readl(FLDTFIFO(flctl));
- buf[i] = be32_to_cpu(buf[i]);
}
+
+convert:
+ for (i = 0; i < len_4align; i++)
+ buf[i] = be32_to_cpu(buf[i]);
}
static enum flctl_ecc_res_t read_ecfiforeg
@@ -308,13 +462,23 @@ static enum flctl_ecc_res_t read_ecfiforeg
static void write_fiforeg(struct sh_flctl *flctl, int rlen, int offset)
{
int i, len_4align;
- unsigned long *data = (unsigned long *)&flctl->done_buff[offset];
+ unsigned long *buf = (unsigned long *)&flctl->done_buff[offset];
void *fifo_addr = (void *)FLDTFIFO(flctl);
len_4align = (rlen + 3) / 4;
+
+ for (i = 0; i < len_4align; i++)
+ buf[i] = cpu_to_be32(buf[i]);
+
+ /* initiate DMA transfer */
+ if (flctl->chan_fifo0_tx && rlen >= 32 &&
+ flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_MEM_TO_DEV) > 0)
+ return; /* DMA success */
+
+ /* do polling transfer */
for (i = 0; i < len_4align; i++) {
wait_wfifo_ready(flctl);
- writel(cpu_to_be32(data[i]), fifo_addr);
+ writel(buf[i], fifo_addr);
}
}
@@ -930,6 +1094,8 @@ static int __devinit flctl_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
pm_runtime_resume(&pdev->dev);
+ flctl_setup_dma(flctl);
+
ret = nand_scan_ident(flctl_mtd, 1, NULL);
if (ret)
goto err_chip;
@@ -947,6 +1113,7 @@ static int __devinit flctl_probe(struct platform_device *pdev)
return 0;
err_chip:
+ flctl_release_dma(flctl);
pm_runtime_disable(&pdev->dev);
free_irq(irq, flctl);
err_flste:
@@ -960,6 +1127,7 @@ static int __devexit flctl_remove(struct platform_device *pdev)
{
struct sh_flctl *flctl = platform_get_drvdata(pdev);
+ flctl_release_dma(flctl);
nand_release(&flctl->mtd);
pm_runtime_disable(&pdev->dev);
free_irq(platform_get_irq(pdev, 0), flctl);
diff --git a/include/linux/mtd/sh_flctl.h b/include/linux/mtd/sh_flctl.h
index 01e4b15..e98fe7e 100644
--- a/include/linux/mtd/sh_flctl.h
+++ b/include/linux/mtd/sh_flctl.h
@@ -20,6 +20,7 @@
#ifndef __SH_FLCTL_H__
#define __SH_FLCTL_H__
+#include <linux/completion.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/partitions.h>
@@ -107,6 +108,7 @@
#define ESTERINTE (0x1 << 24) /* ECC error interrupt enable */
#define AC1CLR (0x1 << 19) /* ECC FIFO clear */
#define AC0CLR (0x1 << 18) /* Data FIFO clear */
+#define DREQ0EN (0x1 << 16) /* FLDTFIFODMA Request Enable */
#define ECERB (0x1 << 9) /* ECC error */
#define STERB (0x1 << 8) /* Status error */
#define STERINTE (0x1 << 4) /* Status error enable */
@@ -138,6 +140,8 @@ enum flctl_ecc_res_t {
FL_TIMEOUT
};
+struct dma_chan;
+
struct sh_flctl {
struct mtd_info mtd;
struct nand_chip chip;
@@ -161,6 +165,11 @@ struct sh_flctl {
unsigned hwecc:1; /* Hardware ECC (0 = disabled, 1 = enabled) */
unsigned holden:1; /* Hardware has FLHOLDCR and HOLDEN is set */
unsigned qos_request:1; /* QoS request to prevent deep power shutdown */
+
+ /* DMA related objects */
+ struct dma_chan *chan_fifo0_rx;
+ struct dma_chan *chan_fifo0_tx;
+ struct completion dma_complete;
};
struct sh_flctl_platform_data {
@@ -170,6 +179,9 @@ struct sh_flctl_platform_data {
unsigned has_hwecc:1;
unsigned use_holden:1;
+
+ unsigned int slave_id_fifo0_tx;
+ unsigned int slave_id_fifo0_rx;
};
static inline struct sh_flctl *mtd_to_flctl(struct mtd_info *mtdinfo)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] mtd: sh_flctl: Add device tree support
From: Bastian Hecht @ 2012-10-02 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349183522-15321-1-git-send-email-hechtb@gmail.com>
The flctl can now be probed via device tree setup in addition to the
existing platform data way.
SoC specific setup data is set in the .data member of the OF match, so
kept within the driver itself, while board/user specific setup - like
partitioning - is taken from the device tree.
Actual configuration is added for the SoC sh7372.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
.../devicetree/bindings/mtd/flctl-nand.txt | 37 ++++++++
drivers/mtd/nand/sh_flctl.c | 92 ++++++++++++++++++--
2 files changed, 122 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/flctl-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/flctl-nand.txt b/Documentation/devicetree/bindings/mtd/flctl-nand.txt
new file mode 100644
index 0000000..f615031
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/flctl-nand.txt
@@ -0,0 +1,37 @@
+FLCTL NAND controller
+
+Required properties:
+- compatible : "renesas,shmobile-flctl-sh7372"
+- reg : Address range of the FLCTL
+- interrupts : flste IRQ number
+- nand-bus-width : bus width to NAND chip
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+ flctl at e6a30000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "renesas,shmobile-flctl-sh7372";
+ reg = <0xe6a30000 0x100>;
+ interrupts = <0x0d80>;
+
+ nand-bus-width = <16>;
+
+ system at 0 {
+ label = "system";
+ reg = <0x0 0x8000000>;
+ };
+
+ userdata at 8000000 {
+ label = "userdata";
+ reg = <0x8000000 0x10000000>;
+ };
+
+ cache at 18000000 {
+ label = "cache";
+ reg = <0x18000000 0x8000000>;
+ };
+ };
diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
index 0fead2a..4c7e542 100644
--- a/drivers/mtd/nand/sh_flctl.c
+++ b/drivers/mtd/nand/sh_flctl.c
@@ -28,6 +28,9 @@
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_mtd.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/sh_dma.h>
@@ -1020,6 +1023,73 @@ static irqreturn_t flctl_handle_flste(int irq, void *dev_id)
return IRQ_HANDLED;
}
+#ifdef CONFIG_OF
+struct flctl_soc_config {
+ unsigned long flcmncr_val;
+ unsigned has_hwecc:1;
+ unsigned use_holden:1;
+};
+
+static struct flctl_soc_config flctl_sh7372_config = {
+ .flcmncr_val = CLK_16B_12L_4H | TYPESEL_SET | SHBUSSEL,
+ .has_hwecc = 1,
+ .use_holden = 1,
+};
+
+static const struct of_device_id of_flctl_match[] = {
+ { .compatible = "renesas,shmobile-flctl-sh7372",
+ .data = &flctl_sh7372_config },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_flctl_match);
+
+static struct sh_flctl_platform_data *flctl_parse_dt(struct device *dev)
+{
+ const struct of_device_id *match;
+ struct flctl_soc_config *config;
+ struct sh_flctl_platform_data *pdata;
+ struct device_node *dn = dev->of_node;
+ int ret;
+
+ match = of_match_device(of_flctl_match, dev);
+ if (match)
+ config = (struct flctl_soc_config *)match->data;
+ else {
+ dev_err(dev, "%s: no OF configuration attached\n", __func__);
+ return NULL;
+ }
+
+ pdata = devm_kzalloc(dev, sizeof(struct sh_flctl_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ dev_err(dev, "%s: failed to allocate config data\n", __func__);
+ return NULL;
+ }
+
+ /* set SoC specific options */
+ pdata->flcmncr_val = config->flcmncr_val;
+ pdata->has_hwecc = config->has_hwecc;
+ pdata->use_holden = config->use_holden;
+
+ /* parse user defined options */
+ ret = of_get_nand_bus_width(dn);
+ if (ret == 16)
+ pdata->flcmncr_val |= SEL_16BIT;
+ else if (ret != 8) {
+ dev_err(dev, "%s: invalid bus width\n", __func__);
+ return NULL;
+ }
+
+ return pdata;
+}
+#else /* CONFIG_OF */
+#define of_flctl_match NULL
+static struct sh_flctl_platform_data *flctl_parse_dt(struct device *dev)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
static int __devinit flctl_probe(struct platform_device *pdev)
{
struct resource *res;
@@ -1029,12 +1099,7 @@ static int __devinit flctl_probe(struct platform_device *pdev)
struct sh_flctl_platform_data *pdata;
int ret = -ENXIO;
int irq;
-
- pdata = pdev->dev.platform_data;
- if (pdata == NULL) {
- dev_err(&pdev->dev, "no platform data defined\n");
- return -EINVAL;
- }
+ struct mtd_part_parser_data ppdata = {};
flctl = kzalloc(sizeof(struct sh_flctl), GFP_KERNEL);
if (!flctl) {
@@ -1066,6 +1131,16 @@ static int __devinit flctl_probe(struct platform_device *pdev)
goto err_flste;
}
+ if (pdev->dev.of_node)
+ pdata = flctl_parse_dt(&pdev->dev);
+ else
+ pdata = pdev->dev.platform_data;
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "no setup data defined\n");
+ return -EINVAL;
+ }
+
platform_set_drvdata(pdev, flctl);
flctl_mtd = &flctl->mtd;
nand = &flctl->chip;
@@ -1108,7 +1183,9 @@ static int __devinit flctl_probe(struct platform_device *pdev)
if (ret)
goto err_chip;
- mtd_device_register(flctl_mtd, pdata->parts, pdata->nr_parts);
+ ppdata.of_node = pdev->dev.of_node;
+ ret = mtd_device_parse_register(flctl_mtd, NULL, &ppdata, pdata->parts,
+ pdata->nr_parts);
return 0;
@@ -1142,6 +1219,7 @@ static struct platform_driver flctl_driver = {
.driver = {
.name = "sh_flctl",
.owner = THIS_MODULE,
+ .of_match_table = of_flctl_match,
},
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH] pinctrl/nomadik: support other alternate-C functions
From: Linus Walleij @ 2012-10-02 13:37 UTC (permalink / raw)
To: linux-arm-kernel
From: Jean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
Upgrade nomadik pinctrl driver to enable selection of other
alternate-C[1-4] functions on some specific ux500 SoC pins.
Handling of those functions is done thanks to PRCM GPIOCR
registers. This was previously managed in PRCMU driver and
it was not really convenient. Idea is to provide a common
way to control all alternate functions.
Note that this improvement does not support the old-fashioned way
used to control nomadik pins, namely the "nmk_config_pin()" function
and its derivatives.
Signed-off-by: Jean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
Reviewed-by: Philippe Langlais <philippe.langlais@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/plat-nomadik/include/plat/gpio-nomadik.h | 6 +
arch/arm/plat-nomadik/include/plat/pincfg.h | 2 +
drivers/pinctrl/pinctrl-nomadik-db8500.c | 289 +++++++++++++++++-
drivers/pinctrl/pinctrl-nomadik-db8540.c | 344 +++++++++++++++++++---
drivers/pinctrl/pinctrl-nomadik.c | 101 ++++++-
drivers/pinctrl/pinctrl-nomadik.h | 78 +++++
6 files changed, 773 insertions(+), 47 deletions(-)
diff --git a/arch/arm/plat-nomadik/include/plat/gpio-nomadik.h b/arch/arm/plat-nomadik/include/plat/gpio-nomadik.h
index 826de74..c08a54d 100644
--- a/arch/arm/plat-nomadik/include/plat/gpio-nomadik.h
+++ b/arch/arm/plat-nomadik/include/plat/gpio-nomadik.h
@@ -45,6 +45,12 @@
#define NMK_GPIO_ALT_B 2
#define NMK_GPIO_ALT_C (NMK_GPIO_ALT_A | NMK_GPIO_ALT_B)
+#define NMK_GPIO_ALT_CX_SHIFT 2
+#define NMK_GPIO_ALT_C1 ((1<<NMK_GPIO_ALT_CX_SHIFT) | NMK_GPIO_ALT_C)
+#define NMK_GPIO_ALT_C2 ((2<<NMK_GPIO_ALT_CX_SHIFT) | NMK_GPIO_ALT_C)
+#define NMK_GPIO_ALT_C3 ((3<<NMK_GPIO_ALT_CX_SHIFT) | NMK_GPIO_ALT_C)
+#define NMK_GPIO_ALT_C4 ((4<<NMK_GPIO_ALT_CX_SHIFT) | NMK_GPIO_ALT_C)
+
/* Pull up/down values */
enum nmk_gpio_pull {
NMK_GPIO_PULL_NONE,
diff --git a/arch/arm/plat-nomadik/include/plat/pincfg.h b/arch/arm/plat-nomadik/include/plat/pincfg.h
index 9c949c7..3b8ec60 100644
--- a/arch/arm/plat-nomadik/include/plat/pincfg.h
+++ b/arch/arm/plat-nomadik/include/plat/pincfg.h
@@ -25,6 +25,8 @@
* bit 19..20 - SLPM direction
* bit 21..22 - SLPM Value (if output)
* bit 23..25 - PDIS value (if input)
+ * bit 26 - Gpio mode
+ * bit 27 - Sleep mode
*
* to facilitate the definition, the following macros are provided
*
diff --git a/drivers/pinctrl/pinctrl-nomadik-db8500.c b/drivers/pinctrl/pinctrl-nomadik-db8500.c
index ec6209d..debaa75b 100644
--- a/drivers/pinctrl/pinctrl-nomadik-db8500.c
+++ b/drivers/pinctrl/pinctrl-nomadik-db8500.c
@@ -725,10 +725,10 @@ static const struct nmk_pingroup nmk_db8500_groups[] = {
DB8500_PIN_GROUP(spi0_c_1, NMK_GPIO_ALT_C),
DB8500_PIN_GROUP(usbsim_c_2, NMK_GPIO_ALT_C),
DB8500_PIN_GROUP(i2c3_c_2, NMK_GPIO_ALT_C),
- /* Other alt C1 column, these are still configured as alt C */
- DB8500_PIN_GROUP(kp_oc1_1, NMK_GPIO_ALT_C),
- DB8500_PIN_GROUP(spi2_oc1_1, NMK_GPIO_ALT_C),
- DB8500_PIN_GROUP(spi2_oc1_2, NMK_GPIO_ALT_C),
+ /* Other alt C1 column */
+ DB8500_PIN_GROUP(kp_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(spi2_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(spi2_oc1_2, NMK_GPIO_ALT_C1),
};
/* We use this macro to define the groups applicable to a function */
@@ -860,6 +860,284 @@ static const struct nmk_function nmk_db8500_functions[] = {
FUNCTION(spi2),
};
+static const struct prcm_gpiocr_altcx_pin_desc db8500_altcx_pins[] = {
+ PRCM_GPIOCR_ALTCX(23, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_CLK_a */
+ true, PRCM_IDX_GPIOCR1, 7, /* SBAG_CLK_a */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(24, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE or U2_RXD ??? */
+ true, PRCM_IDX_GPIOCR1, 7, /* SBAG_VAL_a */
+ true, PRCM_IDX_GPIOCR1, 10, /* STM_MOD_CMD0 */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(25, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_DAT_a[0] */
+ true, PRCM_IDX_GPIOCR1, 7, /* SBAG_D_a[0] */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(26, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_DAT_a[1] */
+ true, PRCM_IDX_GPIOCR1, 7, /* SBAG_D_a[1] */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(27, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_DAT_a[2] */
+ true, PRCM_IDX_GPIOCR1, 7, /* SBAG_D_a[2] */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(28, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_DAT_a[3] */
+ true, PRCM_IDX_GPIOCR1, 7, /* SBAG_D_a[3] */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(29, false, 0, 0,
+ false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 10, /* STM_MOD_CMD0 */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(30, false, 0, 0,
+ false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 10, /* STM_MOD_CMD0 */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(31, false, 0, 0,
+ false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 10, /* STM_MOD_CMD0 */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(32, false, 0, 0,
+ false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 10, /* STM_MOD_CMD0 */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(68, true, PRCM_IDX_GPIOCR1, 18, /* REMAP_SELECT_ON */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(69, true, PRCM_IDX_GPIOCR1, 18, /* REMAP_SELECT_ON */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(70, true, PRCM_IDX_GPIOCR1, 5, /* PTM_A9_D23 */
+ true, PRCM_IDX_GPIOCR2, 2, /* DBG_ETM_R4_CMD0 */
+ true, PRCM_IDX_GPIOCR1, 11, /* STM_MOD_CMD1 */
+ true, PRCM_IDX_GPIOCR1, 8 /* SBAG_CLK */
+ ),
+ PRCM_GPIOCR_ALTCX(71, true, PRCM_IDX_GPIOCR1, 5, /* PTM_A9_D22 */
+ true, PRCM_IDX_GPIOCR2, 2, /* DBG_ETM_R4_CMD0 */
+ true, PRCM_IDX_GPIOCR1, 11, /* STM_MOD_CMD1 */
+ true, PRCM_IDX_GPIOCR1, 8 /* SBAG_D3 */
+ ),
+ PRCM_GPIOCR_ALTCX(72, true, PRCM_IDX_GPIOCR1, 5, /* PTM_A9_D21 */
+ true, PRCM_IDX_GPIOCR2, 2, /* DBG_ETM_R4_CMD0 */
+ true, PRCM_IDX_GPIOCR1, 11, /* STM_MOD_CMD1 */
+ true, PRCM_IDX_GPIOCR1, 8 /* SBAG_D2 */
+ ),
+ PRCM_GPIOCR_ALTCX(73, true, PRCM_IDX_GPIOCR1, 5, /* PTM_A9_D20 */
+ true, PRCM_IDX_GPIOCR2, 2, /* DBG_ETM_R4_CMD0 */
+ true, PRCM_IDX_GPIOCR1, 11, /* STM_MOD_CMD1 */
+ true, PRCM_IDX_GPIOCR1, 8 /* SBAG_D1 */
+ ),
+ PRCM_GPIOCR_ALTCX(74, true, PRCM_IDX_GPIOCR1, 5, /* PTM_A9_D19 */
+ true, PRCM_IDX_GPIOCR2, 2, /* DBG_ETM_R4_CMD0 */
+ true, PRCM_IDX_GPIOCR1, 11, /* STM_MOD_CMD1 */
+ true, PRCM_IDX_GPIOCR1, 8 /* SBAG_D0 */
+ ),
+ PRCM_GPIOCR_ALTCX(75, true, PRCM_IDX_GPIOCR1, 5, /* PTM_A9_D18 */
+ true, PRCM_IDX_GPIOCR2, 2, /* DBG_ETM_R4_CMD0 */
+ true, PRCM_IDX_GPIOCR1, 0, /* DBG_UARTMOD_CMD0 */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(76, true, PRCM_IDX_GPIOCR1, 5, /* PTM_A9_D17 */
+ true, PRCM_IDX_GPIOCR2, 2, /* DBG_ETM_R4_CMD0 */
+ true, PRCM_IDX_GPIOCR1, 0, /* DBG_UARTMOD_CMD0 */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(77, true, PRCM_IDX_GPIOCR1, 5, /* PTM_A9_D16 */
+ true, PRCM_IDX_GPIOCR2, 2, /* DBG_ETM_R4_CMD0 */
+ false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 8 /* SBAG_VAL */
+ ),
+ PRCM_GPIOCR_ALTCX(86, true, PRCM_IDX_GPIOCR1, 12, /* KP_O3 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(87, true, PRCM_IDX_GPIOCR1, 12, /* KP_O2 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(88, true, PRCM_IDX_GPIOCR1, 12, /* KP_I3 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(89, true, PRCM_IDX_GPIOCR1, 12, /* KP_I2 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(90, true, PRCM_IDX_GPIOCR1, 12, /* KP_O1 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(91, true, PRCM_IDX_GPIOCR1, 12, /* KP_O0 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(92, true, PRCM_IDX_GPIOCR1, 12, /* KP_I1 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(93, true, PRCM_IDX_GPIOCR1, 12, /* KP_I0 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(96, true, PRCM_IDX_GPIOCR2, 3, /* RF_INT */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(97, true, PRCM_IDX_GPIOCR2, 1, /* RF_CTRL */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(151, false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_CTL */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS17 */
+ ),
+ PRCM_GPIOCR_ALTCX(152, true, PRCM_IDX_GPIOCR1, 4, /* Hx_CLK */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_CLK */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS16 */
+ ),
+ PRCM_GPIOCR_ALTCX(153, true, PRCM_IDX_GPIOCR1, 1, /* UARTMOD_CMD1 */
+ true, PRCM_IDX_GPIOCR1, 14, /* PTM_A9_D15 */
+ true, PRCM_IDX_GPIOCR1, 19, /* DBG_ETM_R4_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS15 */
+ ),
+ PRCM_GPIOCR_ALTCX(154, true, PRCM_IDX_GPIOCR1, 1, /* UARTMOD_CMD1 */
+ true, PRCM_IDX_GPIOCR1, 14, /* PTM_A9_D14 */
+ true, PRCM_IDX_GPIOCR1, 19, /* DBG_ETM_R4_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS14 */
+ ),
+ PRCM_GPIOCR_ALTCX(155, true, PRCM_IDX_GPIOCR1, 13, /* STM_MOD_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 14, /* PTM_A9_D13 */
+ true, PRCM_IDX_GPIOCR1, 19, /* DBG_ETM_R4_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS13 */
+ ),
+ PRCM_GPIOCR_ALTCX(156, true, PRCM_IDX_GPIOCR1, 13, /* STM_MOD_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 14, /* PTM_A9_D12 */
+ true, PRCM_IDX_GPIOCR1, 19, /* DBG_ETM_R4_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS12 */
+ ),
+ PRCM_GPIOCR_ALTCX(157, true, PRCM_IDX_GPIOCR1, 13, /* STM_MOD_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 14, /* PTM_A9_D11 */
+ true, PRCM_IDX_GPIOCR1, 19, /* DBG_ETM_R4_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS11 */
+ ),
+ PRCM_GPIOCR_ALTCX(158, true, PRCM_IDX_GPIOCR1, 13, /* STM_MOD_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 14, /* PTM_A9_D10 */
+ true, PRCM_IDX_GPIOCR1, 19, /* DBG_ETM_R4_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS10 */
+ ),
+ PRCM_GPIOCR_ALTCX(159, true, PRCM_IDX_GPIOCR1, 13, /* STM_MOD_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 14, /* PTM_A9_D9 */
+ true, PRCM_IDX_GPIOCR1, 19, /* DBG_ETM_R4_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS9 */
+ ),
+ PRCM_GPIOCR_ALTCX(160, false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 14, /* PTM_A9_D8 */
+ true, PRCM_IDX_GPIOCR1, 19, /* DBG_ETM_R4_CMD2 */
+ true, PRCM_IDX_GPIOCR1, 25 /* HW_OBS8 */
+ ),
+ PRCM_GPIOCR_ALTCX(161, true, PRCM_IDX_GPIOCR1, 4, /* Hx_GPIO7 */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_D7 */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 24 /* HW_OBS7 */
+ ),
+ PRCM_GPIOCR_ALTCX(162, true, PRCM_IDX_GPIOCR1, 4, /* Hx_GPIO6 */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_D6 */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 24 /* HW_OBS6 */
+ ),
+ PRCM_GPIOCR_ALTCX(163, true, PRCM_IDX_GPIOCR1, 4, /* Hx_GPIO5 */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_D5 */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 24 /* HW_OBS5 */
+ ),
+ PRCM_GPIOCR_ALTCX(164, true, PRCM_IDX_GPIOCR1, 4, /* Hx_GPIO4 */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_D4 */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 24 /* HW_OBS4 */
+ ),
+ PRCM_GPIOCR_ALTCX(165, true, PRCM_IDX_GPIOCR1, 4, /* Hx_GPIO3 */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_D3 */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 24 /* HW_OBS3 */
+ ),
+ PRCM_GPIOCR_ALTCX(166, true, PRCM_IDX_GPIOCR1, 4, /* Hx_GPIO2 */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_D2 */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 24 /* HW_OBS2 */
+ ),
+ PRCM_GPIOCR_ALTCX(167, true, PRCM_IDX_GPIOCR1, 4, /* Hx_GPIO1 */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_D1 */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 24 /* HW_OBS1 */
+ ),
+ PRCM_GPIOCR_ALTCX(168, true, PRCM_IDX_GPIOCR1, 4, /* Hx_GPIO0 */
+ true, PRCM_IDX_GPIOCR1, 6, /* PTM_A9_D0 */
+ true, PRCM_IDX_GPIOCR1, 15, /* DBG_ETM_R4_CMD1*/
+ true, PRCM_IDX_GPIOCR1, 24 /* HW_OBS0 */
+ ),
+ PRCM_GPIOCR_ALTCX(170, true, PRCM_IDX_GPIOCR2, 2, /* RF_INT */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(171, true, PRCM_IDX_GPIOCR2, 0, /* RF_CTRL */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(215, true, PRCM_IDX_GPIOCR1, 23, /* SPI2_TXD */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(216, true, PRCM_IDX_GPIOCR1, 23, /* SPI2_FRM */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(217, true, PRCM_IDX_GPIOCR1, 23, /* SPI2_CLK */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(218, true, PRCM_IDX_GPIOCR1, 23, /* SPI2_RXD */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+};
+
+static const u16 db8500_prcm_gpiocr_regs[] = {
+ [PRCM_IDX_GPIOCR1] = 0x138,
+ [PRCM_IDX_GPIOCR2] = 0x574,
+};
+
static const struct nmk_pinctrl_soc_data nmk_db8500_soc = {
.gpio_ranges = nmk_db8500_ranges,
.gpio_num_ranges = ARRAY_SIZE(nmk_db8500_ranges),
@@ -869,6 +1147,9 @@ static const struct nmk_pinctrl_soc_data nmk_db8500_soc = {
.nfunctions = ARRAY_SIZE(nmk_db8500_functions),
.groups = nmk_db8500_groups,
.ngroups = ARRAY_SIZE(nmk_db8500_groups),
+ .altcx_pins = db8500_altcx_pins,
+ .npins_altcx = ARRAY_SIZE(db8500_altcx_pins),
+ .prcm_gpiocr_registers = db8500_prcm_gpiocr_regs,
};
void __devinit
diff --git a/drivers/pinctrl/pinctrl-nomadik-db8540.c b/drivers/pinctrl/pinctrl-nomadik-db8540.c
index 3daf665..52fc301 100644
--- a/drivers/pinctrl/pinctrl-nomadik-db8540.c
+++ b/drivers/pinctrl/pinctrl-nomadik-db8540.c
@@ -778,50 +778,50 @@ static const struct nmk_pingroup nmk_db8540_groups[] = {
DB8540_PIN_GROUP(spi0_c_1, NMK_GPIO_ALT_C),
DB8540_PIN_GROUP(i2c3_c_1, NMK_GPIO_ALT_C),
- /* Other alt C1 column, these are still configured as alt C */
- DB8540_PIN_GROUP(spi3_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(stmape_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(u2_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(remap0_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(remap1_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modobsrefclk_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modobspwrctrl_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modobsclkout_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(moduart1_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modprcmudbg_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modobsresout_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modaccgpo_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(kp_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modxmip_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(i2c6_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(u2txrx_oc1_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(u2ctsrts_oc1_1, NMK_GPIO_ALT_C),
+ /* Other alt C1 column */
+ DB8540_PIN_GROUP(spi3_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(stmape_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(u2_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(remap0_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(remap1_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(modobsrefclk_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(modobspwrctrl_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(modobsclkout_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(moduart1_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(modprcmudbg_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(modobsresout_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(modaccgpo_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(kp_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(modxmip_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(i2c6_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(u2txrx_oc1_1, NMK_GPIO_ALT_C1),
+ DB8540_PIN_GROUP(u2ctsrts_oc1_1, NMK_GPIO_ALT_C1),
- /* Other alt C2 column, these are still configured as alt C */
- DB8540_PIN_GROUP(sbag_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(hxclk_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modaccuart_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(stmmod_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(moduartstmmux_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(hxgpio_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(sbag_oc2_2, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modobsservice_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(moduart0_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(stmape_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(u2_oc2_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modxmip_oc2_1, NMK_GPIO_ALT_C),
+ /* Other alt C2 column */
+ DB8540_PIN_GROUP(sbag_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(hxclk_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(modaccuart_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(stmmod_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(moduartstmmux_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(hxgpio_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(sbag_oc2_2, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(modobsservice_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(moduart0_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(stmape_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(u2_oc2_1, NMK_GPIO_ALT_C2),
+ DB8540_PIN_GROUP(modxmip_oc2_1, NMK_GPIO_ALT_C2),
- /* Other alt C3 column, these are still configured as alt C */
- DB8540_PIN_GROUP(modaccgpo_oc3_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(tpui_oc3_1, NMK_GPIO_ALT_C),
+ /* Other alt C3 column */
+ DB8540_PIN_GROUP(modaccgpo_oc3_1, NMK_GPIO_ALT_C3),
+ DB8540_PIN_GROUP(tpui_oc3_1, NMK_GPIO_ALT_C3),
- /* Other alt C4 column, these are still configured as alt C */
- DB8540_PIN_GROUP(hwobs_oc4_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(moduart1txrx_oc4_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(moduart1rtscts_oc4_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modaccuarttxrx_oc4_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(modaccuartrtscts_oc4_1, NMK_GPIO_ALT_C),
- DB8540_PIN_GROUP(stmmod_oc4_1, NMK_GPIO_ALT_C),
+ /* Other alt C4 column */
+ DB8540_PIN_GROUP(hwobs_oc4_1, NMK_GPIO_ALT_C4),
+ DB8540_PIN_GROUP(moduart1txrx_oc4_1, NMK_GPIO_ALT_C4),
+ DB8540_PIN_GROUP(moduart1rtscts_oc4_1, NMK_GPIO_ALT_C4),
+ DB8540_PIN_GROUP(modaccuarttxrx_oc4_1, NMK_GPIO_ALT_C4),
+ DB8540_PIN_GROUP(modaccuartrtscts_oc4_1, NMK_GPIO_ALT_C4),
+ DB8540_PIN_GROUP(stmmod_oc4_1, NMK_GPIO_ALT_C4),
};
@@ -981,6 +981,265 @@ static const struct nmk_function nmk_db8540_functions[] = {
FUNCTION(usb)
};
+static const struct prcm_gpiocr_altcx_pin_desc db8540_altcx_pins[] = {
+ PRCM_GPIOCR_ALTCX(8, true, PRCM_IDX_GPIOCR1, 20, /* SPI3_CLK */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(9, true, PRCM_IDX_GPIOCR1, 20, /* SPI3_RXD */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(10, true, PRCM_IDX_GPIOCR1, 20, /* SPI3_FRM */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(11, true, PRCM_IDX_GPIOCR1, 20, /* SPI3_TXD */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(23, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_CLK_a */
+ true, PRCM_IDX_GPIOCR2, 10, /* SBAG_CLK_a */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(24, true, PRCM_IDX_GPIOCR3, 30, /* U2_RXD_g */
+ true, PRCM_IDX_GPIOCR2, 10, /* SBAG_VAL_a */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(25, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_DAT_a[0] */
+ true, PRCM_IDX_GPIOCR2, 10, /* SBAG_D_a[0] */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(26, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_DAT_a[1] */
+ true, PRCM_IDX_GPIOCR2, 10, /* SBAG_D_a[1] */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(27, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_DAT_a[2] */
+ true, PRCM_IDX_GPIOCR2, 10, /* SBAG_D_a[2] */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(28, true, PRCM_IDX_GPIOCR1, 9, /* STMAPE_DAT_a[3] */
+ true, PRCM_IDX_GPIOCR2, 10, /* SBAG_D_a[3] */
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(64, true, PRCM_IDX_GPIOCR1, 15, /* MODOBS_REFCLK_REQ */
+ false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_CTL */
+ true, PRCM_IDX_GPIOCR2, 23 /* HW_OBS_APE_PRCMU[17] */
+ ),
+ PRCM_GPIOCR_ALTCX(65, true, PRCM_IDX_GPIOCR1, 19, /* MODOBS_PWRCTRL0 */
+ true, PRCM_IDX_GPIOCR1, 24, /* Hx_CLK */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_CLK */
+ true, PRCM_IDX_GPIOCR2, 24 /* HW_OBS_APE_PRCMU[16] */
+ ),
+ PRCM_GPIOCR_ALTCX(66, true, PRCM_IDX_GPIOCR1, 15, /* MODOBS_CLKOUT1 */
+ false, 0, 0,
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[15] */
+ true, PRCM_IDX_GPIOCR2, 25 /* HW_OBS_APE_PRCMU[15] */
+ ),
+ PRCM_GPIOCR_ALTCX(67, true, PRCM_IDX_GPIOCR1, 1, /* MODUART1_TXD_a */
+ true, PRCM_IDX_GPIOCR1, 6, /* MODACCUART_TXD_a */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[14] */
+ true, PRCM_IDX_GPIOCR2, 26 /* HW_OBS_APE_PRCMU[14] */
+ ),
+ PRCM_GPIOCR_ALTCX(70, true, PRCM_IDX_GPIOCR3, 6, /* MOD_PRCMU_DEBUG[17] */
+ true, PRCM_IDX_GPIOCR1, 10, /* STMMOD_CLK_b */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[13] */
+ true, PRCM_IDX_GPIOCR2, 27 /* HW_OBS_APE_PRCMU[13] */
+ ),
+ PRCM_GPIOCR_ALTCX(71, true, PRCM_IDX_GPIOCR3, 6, /* MOD_PRCMU_DEBUG[16] */
+ true, PRCM_IDX_GPIOCR1, 10, /* STMMOD_DAT_b[3] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[12] */
+ true, PRCM_IDX_GPIOCR2, 27 /* HW_OBS_APE_PRCMU[12] */
+ ),
+ PRCM_GPIOCR_ALTCX(72, true, PRCM_IDX_GPIOCR3, 6, /* MOD_PRCMU_DEBUG[15] */
+ true, PRCM_IDX_GPIOCR1, 10, /* STMMOD_DAT_b[2] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[11] */
+ true, PRCM_IDX_GPIOCR2, 27 /* HW_OBS_APE_PRCMU[11] */
+ ),
+ PRCM_GPIOCR_ALTCX(73, true, PRCM_IDX_GPIOCR3, 6, /* MOD_PRCMU_DEBUG[14] */
+ true, PRCM_IDX_GPIOCR1, 10, /* STMMOD_DAT_b[1] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[10] */
+ true, PRCM_IDX_GPIOCR2, 27 /* HW_OBS_APE_PRCMU[10] */
+ ),
+ PRCM_GPIOCR_ALTCX(74, true, PRCM_IDX_GPIOCR3, 6, /* MOD_PRCMU_DEBUG[13] */
+ true, PRCM_IDX_GPIOCR1, 10, /* STMMOD_DAT_b[0] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[9] */
+ true, PRCM_IDX_GPIOCR2, 27 /* HW_OBS_APE_PRCMU[9] */
+ ),
+ PRCM_GPIOCR_ALTCX(75, true, PRCM_IDX_GPIOCR1, 12, /* MODOBS_RESOUT0_N */
+ true, PRCM_IDX_GPIOCR2, 1, /* MODUART_STMMUX_RXD_b */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[8] */
+ true, PRCM_IDX_GPIOCR2, 28 /* HW_OBS_APE_PRCMU[8] */
+ ),
+ PRCM_GPIOCR_ALTCX(76, true, PRCM_IDX_GPIOCR3, 7, /* MOD_PRCMU_DEBUG[12] */
+ true, PRCM_IDX_GPIOCR1, 25, /* Hx_GPIO[7] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[7] */
+ true, PRCM_IDX_GPIOCR2, 29 /* HW_OBS_APE_PRCMU[7] */
+ ),
+ PRCM_GPIOCR_ALTCX(77, true, PRCM_IDX_GPIOCR3, 7, /* MOD_PRCMU_DEBUG[11] */
+ true, PRCM_IDX_GPIOCR1, 25, /* Hx_GPIO[6] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[6] */
+ true, PRCM_IDX_GPIOCR2, 29 /* HW_OBS_APE_PRCMU[6] */
+ ),
+ PRCM_GPIOCR_ALTCX(78, true, PRCM_IDX_GPIOCR3, 7, /* MOD_PRCMU_DEBUG[10] */
+ true, PRCM_IDX_GPIOCR1, 25, /* Hx_GPIO[5] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[5] */
+ true, PRCM_IDX_GPIOCR2, 29 /* HW_OBS_APE_PRCMU[5] */
+ ),
+ PRCM_GPIOCR_ALTCX(79, true, PRCM_IDX_GPIOCR3, 7, /* MOD_PRCMU_DEBUG[9] */
+ true, PRCM_IDX_GPIOCR1, 25, /* Hx_GPIO[4] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[4] */
+ true, PRCM_IDX_GPIOCR2, 29 /* HW_OBS_APE_PRCMU[4] */
+ ),
+ PRCM_GPIOCR_ALTCX(80, true, PRCM_IDX_GPIOCR1, 26, /* MODACC_GPO[0] */
+ true, PRCM_IDX_GPIOCR1, 25, /* Hx_GPIO[3] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[3] */
+ true, PRCM_IDX_GPIOCR2, 30 /* HW_OBS_APE_PRCMU[3] */
+ ),
+ PRCM_GPIOCR_ALTCX(81, true, PRCM_IDX_GPIOCR2, 17, /* MODACC_GPO[1] */
+ true, PRCM_IDX_GPIOCR1, 25, /* Hx_GPIO[2] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[2] */
+ true, PRCM_IDX_GPIOCR2, 30 /* HW_OBS_APE_PRCMU[2] */
+ ),
+ PRCM_GPIOCR_ALTCX(82, true, PRCM_IDX_GPIOCR3, 8, /* MOD_PRCMU_DEBUG[8] */
+ true, PRCM_IDX_GPIOCR1, 25, /* Hx_GPIO[1] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[1] */
+ true, PRCM_IDX_GPIOCR2, 31 /* HW_OBS_APE_PRCMU[1] */
+ ),
+ PRCM_GPIOCR_ALTCX(83, true, PRCM_IDX_GPIOCR3, 8, /* MOD_PRCMU_DEBUG[7] */
+ true, PRCM_IDX_GPIOCR1, 25, /* Hx_GPIO[0] */
+ true, PRCM_IDX_GPIOCR1, 2, /* TPIU_D[0] */
+ true, PRCM_IDX_GPIOCR2, 31 /* HW_OBS_APE_PRCMU[0] */
+ ),
+ PRCM_GPIOCR_ALTCX(84, true, PRCM_IDX_GPIOCR3, 9, /* MOD_PRCMU_DEBUG[6] */
+ true, PRCM_IDX_GPIOCR1, 8, /* SBAG_CLK_b */
+ true, PRCM_IDX_GPIOCR1, 3, /* TPIU_D[23] */
+ true, PRCM_IDX_GPIOCR1, 16 /* MODUART1_RXD_b */
+ ),
+ PRCM_GPIOCR_ALTCX(85, true, PRCM_IDX_GPIOCR3, 9, /* MOD_PRCMU_DEBUG[5] */
+ true, PRCM_IDX_GPIOCR1, 8, /* SBAG_D_b[3] */
+ true, PRCM_IDX_GPIOCR1, 3, /* TPIU_D[22] */
+ true, PRCM_IDX_GPIOCR1, 16 /* MODUART1_TXD_b */
+ ),
+ PRCM_GPIOCR_ALTCX(86, true, PRCM_IDX_GPIOCR3, 9, /* MOD_PRCMU_DEBUG[0] */
+ true, PRCM_IDX_GPIOCR2, 18, /* STMAPE_DAT_b[0] */
+ true, PRCM_IDX_GPIOCR1, 14, /* TPIU_D[25] */
+ true, PRCM_IDX_GPIOCR1, 11 /* STMMOD_DAT_c[0] */
+ ),
+ PRCM_GPIOCR_ALTCX(87, true, PRCM_IDX_GPIOCR3, 0, /* MODACC_GPO_a[5] */
+ true, PRCM_IDX_GPIOCR2, 3, /* U2_RXD_c */
+ true, PRCM_IDX_GPIOCR1, 4, /* TPIU_D[24] */
+ true, PRCM_IDX_GPIOCR1, 21 /* MODUART_STMMUX_RXD_c */
+ ),
+ PRCM_GPIOCR_ALTCX(151, true, PRCM_IDX_GPIOCR1, 18, /* REMAP0 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(152, true, PRCM_IDX_GPIOCR1, 18, /* REMAP1 */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(153, true, PRCM_IDX_GPIOCR3, 2, /* KP_O_b[6] */
+ true, PRCM_IDX_GPIOCR1, 8, /* SBAG_D_b[2] */
+ true, PRCM_IDX_GPIOCR1, 3, /* TPIU_D[21] */
+ true, PRCM_IDX_GPIOCR1, 0 /* MODUART1_RTS */
+ ),
+ PRCM_GPIOCR_ALTCX(154, true, PRCM_IDX_GPIOCR3, 2, /* KP_I_b[6] */
+ true, PRCM_IDX_GPIOCR1, 8, /* SBAG_D_b[1] */
+ true, PRCM_IDX_GPIOCR1, 3, /* TPIU_D[20] */
+ true, PRCM_IDX_GPIOCR1, 0 /* MODUART1_CTS */
+ ),
+ PRCM_GPIOCR_ALTCX(155, true, PRCM_IDX_GPIOCR3, 3, /* KP_O_b[5] */
+ true, PRCM_IDX_GPIOCR1, 8, /* SBAG_D_b[0] */
+ true, PRCM_IDX_GPIOCR1, 3, /* TPIU_D[19] */
+ true, PRCM_IDX_GPIOCR1, 5 /* MODACCUART_RXD_c */
+ ),
+ PRCM_GPIOCR_ALTCX(156, true, PRCM_IDX_GPIOCR3, 3, /* KP_O_b[4] */
+ true, PRCM_IDX_GPIOCR1, 8, /* SBAG_VAL_b */
+ true, PRCM_IDX_GPIOCR1, 3, /* TPIU_D[18] */
+ true, PRCM_IDX_GPIOCR1, 5 /* MODACCUART_TXD_b */
+ ),
+ PRCM_GPIOCR_ALTCX(157, true, PRCM_IDX_GPIOCR3, 4, /* KP_I_b[5] */
+ true, PRCM_IDX_GPIOCR1, 23, /* MODOBS_SERVICE_N */
+ true, PRCM_IDX_GPIOCR1, 3, /* TPIU_D[17] */
+ true, PRCM_IDX_GPIOCR1, 14 /* MODACCUART_RTS */
+ ),
+ PRCM_GPIOCR_ALTCX(158, true, PRCM_IDX_GPIOCR3, 4, /* KP_I_b[4] */
+ true, PRCM_IDX_GPIOCR2, 0, /* U2_TXD_c */
+ true, PRCM_IDX_GPIOCR1, 3, /* TPIU_D[16] */
+ true, PRCM_IDX_GPIOCR1, 14 /* MODACCUART_CTS */
+ ),
+ PRCM_GPIOCR_ALTCX(159, true, PRCM_IDX_GPIOCR3, 5, /* KP_O_b[3] */
+ true, PRCM_IDX_GPIOCR3, 10, /* MODUART0_RXD */
+ true, PRCM_IDX_GPIOCR1, 4, /* TPIU_D[31] */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(160, true, PRCM_IDX_GPIOCR3, 5, /* KP_I_b[3] */
+ true, PRCM_IDX_GPIOCR3, 10, /* MODUART0_TXD */
+ true, PRCM_IDX_GPIOCR1, 4, /* TPIU_D[30] */
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(161, true, PRCM_IDX_GPIOCR3, 9, /* MOD_PRCMU_DEBUG[4] */
+ true, PRCM_IDX_GPIOCR2, 18, /* STMAPE_CLK_b */
+ true, PRCM_IDX_GPIOCR1, 4, /* TPIU_D[29] */
+ true, PRCM_IDX_GPIOCR1, 11 /* STMMOD_CLK_c */
+ ),
+ PRCM_GPIOCR_ALTCX(162, true, PRCM_IDX_GPIOCR3, 9, /* MOD_PRCMU_DEBUG[3] */
+ true, PRCM_IDX_GPIOCR2, 18, /* STMAPE_DAT_b[3] */
+ true, PRCM_IDX_GPIOCR1, 4, /* TPIU_D[28] */
+ true, PRCM_IDX_GPIOCR1, 11 /* STMMOD_DAT_c[3] */
+ ),
+ PRCM_GPIOCR_ALTCX(163, true, PRCM_IDX_GPIOCR3, 9, /* MOD_PRCMU_DEBUG[2] */
+ true, PRCM_IDX_GPIOCR2, 18, /* STMAPE_DAT_b[2] */
+ true, PRCM_IDX_GPIOCR1, 4, /* TPIU_D[27] */
+ true, PRCM_IDX_GPIOCR1, 11 /* STMMOD_DAT_c[2] */
+ ),
+ PRCM_GPIOCR_ALTCX(164, true, PRCM_IDX_GPIOCR3, 9, /* MOD_PRCMU_DEBUG[1] */
+ true, PRCM_IDX_GPIOCR2, 18, /* STMAPE_DAT_b[1] */
+ true, PRCM_IDX_GPIOCR1, 4, /* TPIU_D[26] */
+ true, PRCM_IDX_GPIOCR1, 11 /* STMMOD_DAT_c[1] */
+ ),
+ PRCM_GPIOCR_ALTCX(204, true, PRCM_IDX_GPIOCR2, 2, /* U2_RXD_f */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(205, true, PRCM_IDX_GPIOCR2, 2, /* U2_TXD_f */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(206, true, PRCM_IDX_GPIOCR2, 2, /* U2_CTSn_b */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+ PRCM_GPIOCR_ALTCX(207, true, PRCM_IDX_GPIOCR2, 2, /* U2_RTSn_b */
+ false, 0, 0,
+ false, 0, 0,
+ false, 0, 0
+ ),
+};
+
+static const u16 db8540_prcm_gpiocr_regs[] = {
+ [PRCM_IDX_GPIOCR1] = 0x138,
+ [PRCM_IDX_GPIOCR2] = 0x574,
+ [PRCM_IDX_GPIOCR3] = 0x2bc,
+};
+
static const struct nmk_pinctrl_soc_data nmk_db8540_soc = {
.gpio_ranges = nmk_db8540_ranges,
.gpio_num_ranges = ARRAY_SIZE(nmk_db8540_ranges),
@@ -990,6 +1249,9 @@ static const struct nmk_pinctrl_soc_data nmk_db8540_soc = {
.nfunctions = ARRAY_SIZE(nmk_db8540_functions),
.groups = nmk_db8540_groups,
.ngroups = ARRAY_SIZE(nmk_db8540_groups),
+ .altcx_pins = db8540_altcx_pins,
+ .npins_altcx = ARRAY_SIZE(db8540_altcx_pins),
+ .prcm_gpiocr_registers = db8540_prcm_gpiocr_regs,
};
void __devinit
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 6030a51..67a5ef6 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -30,6 +30,7 @@
#include <linux/pinctrl/pinconf.h>
/* Since we request GPIOs from ourself */
#include <linux/pinctrl/consumer.h>
+#include <linux/mfd/dbx500-prcmu.h>
#include <asm/mach/irq.h>
@@ -237,6 +238,89 @@ nmk_gpio_disable_lazy_irq(struct nmk_gpio_chip *nmk_chip, unsigned offset)
dev_dbg(nmk_chip->chip.dev, "%d: clearing interrupt mask\n", gpio);
}
+static void nmk_prcm_altcx_set_mode(struct nmk_pinctrl *npct,
+ unsigned offset, unsigned alt_num)
+{
+ int i;
+ u16 reg;
+ u8 bit;
+ u8 alt_index;
+ const struct prcm_gpiocr_altcx_pin_desc *pin_desc;
+ const u16 *gpiocr_regs;
+
+ if (alt_num > PRCM_IDX_GPIOCR_ALTC_MAX) {
+ dev_err(npct->dev, "PRCM GPIOCR: alternate-C%i is invalid\n",
+ alt_num);
+ return;
+ }
+
+ for (i = 0 ; i < npct->soc->npins_altcx ; i++) {
+ if (npct->soc->altcx_pins[i].pin == offset)
+ break;
+ }
+ if (i == npct->soc->npins_altcx) {
+ dev_dbg(npct->dev, "PRCM GPIOCR: pin %i is not found\n",
+ offset);
+ return;
+ }
+
+ pin_desc = npct->soc->altcx_pins + i;
+ gpiocr_regs = npct->soc->prcm_gpiocr_registers;
+
+ /*
+ * If alt_num is NULL, just clear current ALTCx selection
+ * to make sure we come back to a pure ALTC selection
+ */
+ if (!alt_num) {
+ for (i = 0 ; i < PRCM_IDX_GPIOCR_ALTC_MAX ; i++) {
+ if (pin_desc->altcx[i].used == true) {
+ reg = gpiocr_regs[pin_desc->altcx[i].reg_index];
+ bit = pin_desc->altcx[i].control_bit;
+ if (prcmu_read(reg) & BIT(bit)) {
+ prcmu_write_masked(reg, BIT(bit), 0);
+ dev_dbg(npct->dev,
+ "PRCM GPIOCR: pin %i: alternate-C%i has been disabled\n",
+ offset, i+1);
+ }
+ }
+ }
+ return;
+ }
+
+ alt_index = alt_num - 1;
+ if (pin_desc->altcx[alt_index].used == false) {
+ dev_warn(npct->dev,
+ "PRCM GPIOCR: pin %i: alternate-C%i does not exist\n",
+ offset, alt_num);
+ return;
+ }
+
+ /*
+ * Check if any other ALTCx functions are activated on this pin
+ * and disable it first.
+ */
+ for (i = 0 ; i < PRCM_IDX_GPIOCR_ALTC_MAX ; i++) {
+ if (i == alt_index)
+ continue;
+ if (pin_desc->altcx[i].used == true) {
+ reg = gpiocr_regs[pin_desc->altcx[i].reg_index];
+ bit = pin_desc->altcx[i].control_bit;
+ if (prcmu_read(reg) & BIT(bit)) {
+ prcmu_write_masked(reg, BIT(bit), 0);
+ dev_dbg(npct->dev,
+ "PRCM GPIOCR: pin %i: alternate-C%i has been disabled\n",
+ offset, i+1);
+ }
+ }
+ }
+
+ reg = gpiocr_regs[pin_desc->altcx[alt_index].reg_index];
+ bit = pin_desc->altcx[alt_index].control_bit;
+ dev_dbg(npct->dev, "PRCM GPIOCR: pin %i: alternate-C%i has been selected\n",
+ offset, alt_index+1);
+ prcmu_write_masked(reg, BIT(bit), BIT(bit));
+}
+
static void __nmk_config_pin(struct nmk_gpio_chip *nmk_chip, unsigned offset,
pin_cfg_t cfg, bool sleep, unsigned int *slpmregs)
{
@@ -1441,7 +1525,7 @@ static int nmk_pmx_enable(struct pinctrl_dev *pctldev, unsigned function,
* IOFORCE will switch *all* ports to their sleepmode setting to as
* to avoid glitches. (Not just one port!)
*/
- glitch = (g->altsetting == NMK_GPIO_ALT_C);
+ glitch = ((g->altsetting & NMK_GPIO_ALT_C) == NMK_GPIO_ALT_C);
if (glitch) {
spin_lock_irqsave(&nmk_gpio_slpm_lock, flags);
@@ -1491,8 +1575,21 @@ static int nmk_pmx_enable(struct pinctrl_dev *pctldev, unsigned function,
*/
nmk_gpio_disable_lazy_irq(nmk_chip, bit);
- __nmk_gpio_set_mode_safe(nmk_chip, bit, g->altsetting, glitch);
+ __nmk_gpio_set_mode_safe(nmk_chip, bit,
+ (g->altsetting & NMK_GPIO_ALT_C), glitch);
clk_disable(nmk_chip->clk);
+
+ /*
+ * Call PRCM GPIOCR config function in case ALTC
+ * has been selected:
+ * - If selection is a ALTCx, some bits in PRCM GPIOCR registers
+ * must be set.
+ * - If selection is pure ALTC and previous selection was ALTCx,
+ * then some bits in PRCM GPIOCR registers must be cleared.
+ */
+ if ((g->altsetting & NMK_GPIO_ALT_C) == NMK_GPIO_ALT_C)
+ nmk_prcm_altcx_set_mode(npct, g->pins[i],
+ g->altsetting >> NMK_GPIO_ALT_CX_SHIFT);
}
/* When all pins are successfully reconfigured we get here */
diff --git a/drivers/pinctrl/pinctrl-nomadik.h b/drivers/pinctrl/pinctrl-nomadik.h
index 5c99f1c..eef316e 100644
--- a/drivers/pinctrl/pinctrl-nomadik.h
+++ b/drivers/pinctrl/pinctrl-nomadik.h
@@ -8,6 +8,78 @@
#define PINCTRL_NMK_DB8500 1
#define PINCTRL_NMK_DB8540 2
+#define PRCM_GPIOCR_ALTCX(pin_num,\
+ altc1_used, altc1_ri, altc1_cb,\
+ altc2_used, altc2_ri, altc2_cb,\
+ altc3_used, altc3_ri, altc3_cb,\
+ altc4_used, altc4_ri, altc4_cb)\
+{\
+ .pin = pin_num,\
+ .altcx[PRCM_IDX_GPIOCR_ALTC1] = {\
+ .used = altc1_used,\
+ .reg_index = altc1_ri,\
+ .control_bit = altc1_cb\
+ },\
+ .altcx[PRCM_IDX_GPIOCR_ALTC2] = {\
+ .used = altc2_used,\
+ .reg_index = altc2_ri,\
+ .control_bit = altc2_cb\
+ },\
+ .altcx[PRCM_IDX_GPIOCR_ALTC3] = {\
+ .used = altc3_used,\
+ .reg_index = altc3_ri,\
+ .control_bit = altc3_cb\
+ },\
+ .altcx[PRCM_IDX_GPIOCR_ALTC4] = {\
+ .used = altc4_used,\
+ .reg_index = altc4_ri,\
+ .control_bit = altc4_cb\
+ },\
+}
+
+/**
+ * enum prcm_gpiocr_reg_index
+ * Used to reference an PRCM GPIOCR register address.
+ */
+enum prcm_gpiocr_reg_index {
+ PRCM_IDX_GPIOCR1,
+ PRCM_IDX_GPIOCR2,
+ PRCM_IDX_GPIOCR3
+};
+/**
+ * enum prcm_gpiocr_altcx_index
+ * Used to reference an Other alternate-C function.
+ */
+enum prcm_gpiocr_altcx_index {
+ PRCM_IDX_GPIOCR_ALTC1,
+ PRCM_IDX_GPIOCR_ALTC2,
+ PRCM_IDX_GPIOCR_ALTC3,
+ PRCM_IDX_GPIOCR_ALTC4,
+ PRCM_IDX_GPIOCR_ALTC_MAX,
+};
+
+/**
+ * struct prcm_gpio_altcx - Other alternate-C function
+ * @used: other alternate-C function availability
+ * @reg_index: PRCM GPIOCR register index used to control the function
+ * @control_bit: PRCM GPIOCR bit used to control the function
+ */
+struct prcm_gpiocr_altcx {
+ bool used:1;
+ u8 reg_index:2;
+ u8 control_bit:5;
+} __packed;
+
+/**
+ * struct prcm_gpio_altcx_pin_desc - Other alternate-C pin
+ * @pin: The pin number
+ * @altcx: array of other alternate-C[1-4] functions
+ */
+struct prcm_gpiocr_altcx_pin_desc {
+ unsigned short pin;
+ struct prcm_gpiocr_altcx altcx[PRCM_IDX_GPIOCR_ALTC_MAX];
+};
+
/**
* struct nmk_function - Nomadik pinctrl mux function
* @name: The name of the function, exported to pinctrl core.
@@ -50,6 +122,9 @@ struct nmk_pingroup {
* @nfunction: The number of entries in @functions.
* @groups: An array describing all pin groups the pin SoC supports.
* @ngroups: The number of entries in @groups.
+ * @altcx_pins: The pins that support Other alternate-C function on this SoC
+ * @npins_altcx: The number of Other alternate-C pins
+ * @prcm_gpiocr_registers: The array of PRCM GPIOCR registers on this SoC
*/
struct nmk_pinctrl_soc_data {
struct pinctrl_gpio_range *gpio_ranges;
@@ -60,6 +135,9 @@ struct nmk_pinctrl_soc_data {
unsigned nfunctions;
const struct nmk_pingroup *groups;
unsigned ngroups;
+ const struct prcm_gpiocr_altcx_pin_desc *altcx_pins;
+ unsigned npins_altcx;
+ const u16 *prcm_gpiocr_registers;
};
#ifdef CONFIG_PINCTRL_STN8815
--
1.7.11.3
^ permalink raw reply related
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Daniel Mack @ 2012-10-02 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ACACE.4030308@ti.com>
On 02.10.2012 13:06, Sekhar Nori wrote:
> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>> On 02.10.2012 11:37, Mark Brown wrote:
>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>
>>>> I also agree that ifdef is not a good solution.
>>>> It is better to have this information passed as device_data and via DT it can
>>>> be decided based on the compatible property for the device.
>>>
>>> That's not really the problem here - the problem is that the APIs used
>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>> or other platforms. The SRAM code needs to move to a standard API.
>>
>> What about following Matt Porter's idea and ignore the SRAM code
>> entirely and port the entire PCM code to generic dmaengine code first?
>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>> might give that a try in near future.
>>
>> Later on, the SRAM ping-pong code can get added back using genalloc
>> functions, as Sekhar proposed. That needs to be done by someone who has
>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>
> We cannot "get rid" of SRAM code and add it back "later". It is required
> for most DaVinci parts. The SRAM code can be converted to use genalloc
> (conversion should be straightforward and I can help test it) and the
> code that uses SRAM can probably keep using the private EDMA API till
> the dmaengine EDMA driver has cyclic DMA support. Matt has already
> posted patches to move private EDMA APIs to a common location. That
> should keep AM335x build from breaking. Is this something that is feasible?
Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.
I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.
Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.
Is there a better way that I miss?
Daniel
^ permalink raw reply
* [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
From: Felipe Balbi @ 2012-10-02 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002125819.GY4360@opensource.wolfsonmicro.com>
Hi,
On Tue, Oct 02, 2012 at 01:58:20PM +0100, Mark Brown wrote:
> On Tue, Oct 02, 2012 at 03:43:22PM +0300, Felipe Balbi wrote:
>
> > BTW, OTOH writing all children into the DT actually describes the HW,
> > no ? And depending on the device I feel it'd be better to write that
>
> Well, it depends on the hardware. Some hardware has a bunch of nice,
> neat IPs which can usefully be reproduced and which map sensibly onto OS
> abstractions but a lot of it doesn't and frequently the abstractions
> which Linux wants to use don't bear a huge resemblance to the hardware
> (and Linux's ideas can change over time, as with the clock API being
> factored out for example).
>
> > data to DT. Think of twlxxxx (TI's PMICs), we might have completely
> > unrelated drivers using one of TWL's GPIO lines as an interrupt source.
>
> > If that particular children isn't listed in DT, it can't be used as an
> > interrupt-parent, right ?
>
> You can have the interrupt controller there without having to list every
> IP in the device, just make the parent device the interrupt controller
> to DT.
fair enough, thanks ;-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121002/af2ffe1c/attachment.sig>
^ permalink raw reply
* [PATCH v2 RESEND 2/2] ARM: local timers: add timer support using IO mapped register
From: Lorenzo Pieralisi @ 2012-10-02 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002112704.GA2410@linaro.org>
On Tue, Oct 02, 2012 at 12:27:04PM +0100, Dave Martin wrote:
> On Fri, Sep 28, 2012 at 06:15:53PM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Sep 28, 2012 at 04:57:46PM +0100, Dave Martin wrote:
[...]
> > There must be a common way for all devices to link to the topology, though.
> >
> > The topology must be descriptive enough to cater for all required cases
> > and that's what Mark with PMU and all of us are trying to come up with, a solid
> > way to represent with DT the topology of current and future ARM systems.
> >
> > First idea I implemented and related LAK posting:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html
> >
> > Are "cluster" nodes really needed or "cpu" nodes are enough ? I do not
> > know, let's get this discussion started, that's all I need.
>
> One thing which now occurs to me on this point it that if we want to describe
> the CCI properly in the DT (yes) then we need a way to describe the mapping
> between clusters and CCI slave ports. Currently that knowledge just has to
> be a hard-coded hack somewhere: it's not probeable at all.
That's definitely a good point. We can still define CCI ports as belonging
to a range of CPUs, but that's a bit of a stretch IMHO.
> I'm not sure how we do that, or how we describe the cache topology, without
> the clusters being explicit in the DT
>
> ...unless you already have ideas ?
Either we define the cluster node explicitly or we can always see it as a
collection of CPUs, ie phandles to "cpu" nodes. That's what the decision
we have to make is all about. I think that describing it explicitly make
sense, but we need to check all possible use cases to see if that's
worthwhile.
Lorenzo
^ permalink raw reply
* [PATCH 2/2] mtd: sh_flctl: Add device tree support
From: Arnd Bergmann @ 2012-10-02 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349183522-15321-3-git-send-email-hechtb@gmail.com>
On Tuesday 02 October 2012, Bastian Hecht wrote:
> +Required properties:
> +- compatible : "renesas,shmobile-flctl-sh7372"
> +- reg : Address range of the FLCTL
> +- interrupts : flste IRQ number
> +- nand-bus-width : bus width to NAND chip
> +
> +The device tree may optionally contain sub-nodes describing partitions of the
> +address space. See partition.txt for more detail.
> +
> +Example:
> +
> + flctl at e6a30000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "renesas,shmobile-flctl-sh7372";
> + reg = <0xe6a30000 0x100>;
> + interrupts = <0x0d80>;
> +
> + nand-bus-width = <16>;
> +
> + system at 0 {
> + label = "system";
> + reg = <0x0 0x8000000>;
> + };
> +
> + userdata at 8000000 {
> + label = "userdata";
> + reg = <0x8000000 0x10000000>;
> + };
> +
> + cache at 18000000 {
> + label = "cache";
> + reg = <0x18000000 0x8000000>;
> + };
> + };
Since you are also adding dma-engine support, I would suggest you specify
a "dmas" and "dma-names" property as well, so the device can find the
right dma channel. The code might not do that yet while you're still
sorting out the dependencies (and the sh dmaengine code is not yet
converted to DT), but I think it would be good to nail down the binding
for this device.
Arnd
^ permalink raw reply
* [PATCH 1/2] mtd: sh_flctl: Add DMA capabilty
From: Guennadi Liakhovetski @ 2012-10-02 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349183522-15321-2-git-send-email-hechtb@gmail.com>
On Tue, 2 Oct 2012, Bastian Hecht wrote:
> The code probes if DMA channels can get allocated and tears them down at
> removal/failure if needed.
> If available it uses them to transfer the data part (not ECC). On
> failure we fall back to PIO mode.
>
> Based on Guennadi Liakhovetski's code from the sh_mmcif driver.
>
> Signed-off-by: Bastian Hecht <hechtb@gmail.com>
Looks mostly good to me, just a couple of cosmetic remarks below. They are
not critical, so, I won't be upset, if you fix them later:-) In any case
Reviewed-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> drivers/mtd/nand/sh_flctl.c | 174 +++++++++++++++++++++++++++++++++++++++++-
> include/linux/mtd/sh_flctl.h | 12 +++
> 2 files changed, 183 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
> index 4fbfe96..0fead2a 100644
> --- a/drivers/mtd/nand/sh_flctl.c
> +++ b/drivers/mtd/nand/sh_flctl.c
> @@ -24,10 +24,13 @@
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/delay.h>
> +#include <linux/dmaengine.h>
> +#include <linux/dma-mapping.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> +#include <linux/sh_dma.h>
> #include <linux/slab.h>
> #include <linux/string.h>
>
> @@ -106,6 +109,84 @@ static void wait_completion(struct sh_flctl *flctl)
> writeb(0x0, FLTRCR(flctl));
> }
>
> +static void flctl_dma_complete(void *param)
> +{
> + struct sh_flctl *flctl = param;
> +
> + complete(&flctl->dma_complete);
I think I mentioned in the first review, that it is good to include
headers everywhere, where they are needed and not rely on pulling them in
via other headers. So, it would be good to also include complete.h here
directly.
[snip]
> @@ -308,13 +462,23 @@ static enum flctl_ecc_res_t read_ecfiforeg
> static void write_fiforeg(struct sh_flctl *flctl, int rlen, int offset)
> {
> int i, len_4align;
> - unsigned long *data = (unsigned long *)&flctl->done_buff[offset];
> + unsigned long *buf = (unsigned long *)&flctl->done_buff[offset];
> void *fifo_addr = (void *)FLDTFIFO(flctl);
>
> len_4align = (rlen + 3) / 4;
> +
> + for (i = 0; i < len_4align; i++)
> + buf[i] = cpu_to_be32(buf[i]);
indentation ran away here.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 2/2] mtd: sh_flctl: Add device tree support
From: Guennadi Liakhovetski @ 2012-10-02 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210021354.01247.arnd@arndb.de>
Hi Arnd
On Tue, 2 Oct 2012, Arnd Bergmann wrote:
> On Tuesday 02 October 2012, Bastian Hecht wrote:
> > +Required properties:
> > +- compatible : "renesas,shmobile-flctl-sh7372"
> > +- reg : Address range of the FLCTL
> > +- interrupts : flste IRQ number
> > +- nand-bus-width : bus width to NAND chip
> > +
> > +The device tree may optionally contain sub-nodes describing partitions of the
> > +address space. See partition.txt for more detail.
> > +
> > +Example:
> > +
> > + flctl at e6a30000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "renesas,shmobile-flctl-sh7372";
> > + reg = <0xe6a30000 0x100>;
> > + interrupts = <0x0d80>;
> > +
> > + nand-bus-width = <16>;
> > +
> > + system at 0 {
> > + label = "system";
> > + reg = <0x0 0x8000000>;
> > + };
> > +
> > + userdata at 8000000 {
> > + label = "userdata";
> > + reg = <0x8000000 0x10000000>;
> > + };
> > +
> > + cache at 18000000 {
> > + label = "cache";
> > + reg = <0x18000000 0x8000000>;
> > + };
> > + };
>
> Since you are also adding dma-engine support, I would suggest you specify
> a "dmas" and "dma-names" property as well, so the device can find the
> right dma channel. The code might not do that yet while you're still
> sorting out the dependencies (and the sh dmaengine code is not yet
> converted to DT), but I think it would be good to nail down the binding
> for this device.
Have DMA DT bindings been accepted yet, are they fixed? Wouldn't it be
better to wait until patches appear in a tree, at least with high
probability heading towards the mainline, or have they already?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH v2 RESEND 2/2] ARM: local timers: add timer support using IO mapped register
From: Dave Martin @ 2012-10-02 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002134444.GB28600@e102568-lin.cambridge.arm.com>
On Tue, Oct 02, 2012 at 02:44:44PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 02, 2012 at 12:27:04PM +0100, Dave Martin wrote:
> > On Fri, Sep 28, 2012 at 06:15:53PM +0100, Lorenzo Pieralisi wrote:
> > > On Fri, Sep 28, 2012 at 04:57:46PM +0100, Dave Martin wrote:
>
> [...]
>
> > > There must be a common way for all devices to link to the topology, though.
> > >
> > > The topology must be descriptive enough to cater for all required cases
> > > and that's what Mark with PMU and all of us are trying to come up with, a solid
> > > way to represent with DT the topology of current and future ARM systems.
> > >
> > > First idea I implemented and related LAK posting:
> > >
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html
> > >
> > > Are "cluster" nodes really needed or "cpu" nodes are enough ? I do not
> > > know, let's get this discussion started, that's all I need.
> >
> > One thing which now occurs to me on this point it that if we want to describe
> > the CCI properly in the DT (yes) then we need a way to describe the mapping
> > between clusters and CCI slave ports. Currently that knowledge just has to
> > be a hard-coded hack somewhere: it's not probeable at all.
>
> That's definitely a good point. We can still define CCI ports as belonging
> to a range of CPUs, but that's a bit of a stretch IMHO.
>
> > I'm not sure how we do that, or how we describe the cache topology, without
> > the clusters being explicit in the DT
> >
> > ...unless you already have ideas ?
>
> Either we define the cluster node explicitly or we can always see it as a
> collection of CPUs, ie phandles to "cpu" nodes. That's what the decision
> we have to make is all about. I think that describing it explicitly make
> sense, but we need to check all possible use cases to see if that's
> worthwhile.
How is the cache topology described today (forgive my laziness in not
answering this question for myself)? The issues are somewhat similar.
I still have some misgivings about describing clusters in terms of sets of
CPUs. For example, when we boot up a cluster, we have to set up ... the
cluster. This is a distinct thing which we must set up in addition to
any of the actual CPUs.
There is a strict child/parent relationship between clusters and CPUs, so
a tree of nodes does seem the most natural description ... but I'm not
aware of all the background to this discussion.
Cheers
---Dave
^ permalink raw reply
* [PATCH v6 3/5] watchdog: at91sam9_wdt: add device tree support
From: Fabio Porcedda @ 2012-10-02 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001130658.GG11837@lunn.ch>
On Mon, Oct 1, 2012 at 3:06 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, Oct 01, 2012 at 02:54:55PM +0200, Fabio Porcedda wrote:
>> On Mon, Oct 1, 2012 at 2:48 PM, Fabio Porcedda <fabio.porcedda@gmail.com> wrote:
>> > On Mon, Oct 1, 2012 at 2:45 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> >> On Mon, Oct 01, 2012 at 02:24:39PM +0200, Fabio Porcedda wrote:
>> >>> Tested on an at91sam9260 board (evk-pro3)
>> >>>
>> >>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>> >>> ---
>> >>> .../devicetree/bindings/watchdog/atmel-wdt.txt | 19 +++++++++++++++++++
>> >>> drivers/watchdog/at91sam9_wdt.c | 21 +++++++++++++++++++++
>> >>> 2 files changed, 40 insertions(+)
>> >>> create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>> >>>
>> >>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>> >>> new file mode 100644
>> >>> index 0000000..65c1755
>> >>> --- /dev/null
>> >>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>> >>> @@ -0,0 +1,19 @@
>> >>> +* Atmel Watchdog Timers
>> >>> +
>> >>> +** at91sam9-wdt
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: must be "atmel,at91sam9260-wdt".
>> >>> +- reg: physical base address of the controller and length of memory mapped
>> >>> + region.
>> >>> +
>> >>> +Optional properties:
>> >>> +- timeout: contains the watchdog timeout in seconds.
>> >>> +
>> >>> +Example:
>> >>> +
>> >>> + watchdog at fffffd40 {
>> >>> + compatible = "atmel,at91sam9260-wdt";
>> >>> + reg = <0xfffffd40 0x10>;
>> >>> + timeout = <10>;
>> >>> + };
>> >>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
>> >>> index 05e1be8..c9e6bfa 100644
>> >>> --- a/drivers/watchdog/at91sam9_wdt.c
>> >>> +++ b/drivers/watchdog/at91sam9_wdt.c
>> >>> @@ -32,6 +32,7 @@
>> >>> #include <linux/timer.h>
>> >>> #include <linux/bitops.h>
>> >>> #include <linux/uaccess.h>
>> >>> +#include <linux/of.h>
>> >>>
>> >>> #include "at91sam9_wdt.h"
>> >>>
>> >>> @@ -254,6 +255,14 @@ static struct miscdevice at91wdt_miscdev = {
>> >>> .fops = &at91wdt_fops,
>> >>> };
>> >>>
>> >>> +static inline void __init at91wdt_probe_dt(struct device_node *node)
>> >>> +{
>> >>> + if (!node)
>> >>> + return;
>> >>> +
>> >>> + of_property_read_u32(node, "timeout", &heartbeat);
>> >>> +}
>> >>> +
>> >>
>> >> In patch #1 you add a function to do this, and then you don't make use
>> >> of it here ?
>> >>
>> >> Or am i missing something?
>> >
>> > I'm using it on the patch #2 for the orion_wdt driver.
>> > Do you think it's better to join the #1 and the #2 patch?
>> >
>> > Best regards
>> > --
>> > Fabio Porcedda
>>
>> I'm sorry, only now i understand your question.
>> The at91sam9_wdt driver don't use the watchdog core framework si i
>> can't use that function cleanly.
>
>> The patch #1 and #2 are for introducing the same property as the
>> at91sam9_wdt driver.
>
> So maybe split this up into two different patchsets. One patchset to
> add the helper function, and the use of this helper to all watchdog
> divers that can use it. I think the following drivers should be
> modified:
>
> orion_wdt.c
> pnx4008_wdt.c
> s3c2410_wdt.c
>
> In a second patchset, convert the AT91SAM9 driver over to the watchdog
> core framework, and then use the helper function.
I was thinking to add a more generic helper function like this:
static inline void watchdog_get_dttimeout(struct device_node *node,
u32 *timeout)
{
if (node)
of_property_read_u32(node, "timeout", &wdd->timeout);
}
This way i can use this helper function in the at91sam9_wdt driver too.
What do you think?
Best regards
--
Fabio Porcedda
^ permalink raw reply
* [PATCH] arm: include linux/sched.h in syscall.h
From: Wade Farnsworth @ 2012-10-02 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002122124.GB11278@mudshark.cambridge.arm.com>
Hi Will,
Will Deacon wrote:
> Hi Wade,
>
> On Mon, Oct 01, 2012 at 09:10:08PM +0100, Wade Farnsworth wrote:
>> task_thread_info() is defined in linux/sched.h. Explicitly include this
>> file in arch/arm/include/asm/syscall.h. This fixes an lttng-modules compile error.
>
> Can you be more specific about the error? From your description, it sounds
> like it should be fixed in lttng rather than here.
>
> Cheers,
>
> Will
My apologies for the lack of clarity.
My syscall tracing patch introduces a compile bug in lttng-modules when
the latter calls syscall_get_nr(), similar to the following:
<path-to-linux>/arch/arm/include/asm/syscall.h:21:2: error: implicit
declaration of function 'task_thread_info'
[-Werror=implicit-function-declaration]
The issue is that we are using task_thread_info() in the
syscall_get_nr() function in asm/syscall.h, but not explicitly including
sched.h from this file, so we can expect this bug might surface any time
that syscall_get_nr() is called.
Hopefully that clarifies things somewhat.
Thanks,
Wade
>
>> Signed-off-by: Wade Farnsworth<wade_farnsworth@mentor.com>
>> ---
>> arch/arm/include/asm/syscall.h | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/syscall.h b/arch/arm/include/asm/syscall.h
>> index c334a23..fce38a6 100644
>> --- a/arch/arm/include/asm/syscall.h
>> +++ b/arch/arm/include/asm/syscall.h
>> @@ -8,6 +8,7 @@
>> #define _ASM_ARM_SYSCALL_H
>>
>> #include<linux/err.h>
>> +#include<linux/sched.h>
>>
>> extern const unsigned long sys_call_table[];
>>
>> --
>> 1.7.0.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
^ permalink raw reply
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Ben Gardiner @ 2012-10-02 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ACC77.9090604@ti.com>
On Tue, Oct 2, 2012 at 7:13 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On 10/1/2012 7:20 PM, Ben Gardiner wrote:
>> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote:
>>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>>>> Hi Matt,
>>>>
>>>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>>>>> L3RAM (shared SRAM) is needed for use by several drivers.
>>>>> This creates a genalloc pool and a hook for the platform code
>>>>> to provide the struct gen_pool * in platform data.
>>>>>
>>>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>>>
>>>> I am not sure if any of the DaVinci devices have a need to allocate from
>>>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>>>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>>>> if there is much point in trying to allocate from there.
>>>>
>>>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>>>> allocation on DA850 makes sense for your case? If yes, can you repost
>>>> with Ben's patch included in your series instead of this patch? I would
>>>> prefer that over creating a new pool for shared RAM.
>>>
>>> Hrm, I did look at Ben's earlier patch. The reason I added a separate
>>> pool mostly was so I didn't have to touch the PM code at all. That can
>>> continue using the private SRAM API with the ARM RAM as it is now. The
>>> idea here was to allow that to be separate since no other bus masters
>>> can access the ARM RAM anyway and do something that didn't require
>>> regression testing PM. Also, I figured there's really no reason to use
>>> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
>>> and working fine for that use case.
>>> [...]
>>
>> I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
>> you said, Sekhar) in any fashion is preferable to moving suspend
>> support into shared RAM. There is more of it (128K on L138) but also
>> more pressure on allocations there since there are more clients.
>
> There is where I would like to see more information on who the potential
> clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
> there should be more than enough for PM, Audio and PRU. I haven't
> checked the PM code size lately but it should be fairly small and I can
> check the actual number if that helps. So, adding a new pool just to
> save on those bytes doesn't sound like helping a lot.
Good points. I suppose that the list would decrease also on L138 if
davinci-pcm ping-pong buffers were removed from SRAM.
>> I appreciate that you are trying to preserve prior efforts in
>> attempted merging of SRAM support -- thank you for that; however, that
>> patch [1] was just an import of Subashish Ghosh's patch [2] -- I
>> chose _that_ implementation option then mainly because I imagined it
>> would be the least risky to get accepted upstream and not because of
>> any particular technical merits.
>
> Its not a question of prior effort since Matt has already put in the
> effort too. I am yet unconvinced that we need to add support to manage
> two blocks of SoC internal RAM on DA850 in the kernel today. That's all.
Understood. Thank you, Sekhar.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
^ permalink raw reply
* [PATCH] arm: include linux/sched.h in syscall.h
From: Will Deacon @ 2012-10-02 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506B0BB0.5060707@mentor.com>
On Tue, Oct 02, 2012 at 04:43:44PM +0100, Wade Farnsworth wrote:
> > On Mon, Oct 01, 2012 at 09:10:08PM +0100, Wade Farnsworth wrote:
> >> task_thread_info() is defined in linux/sched.h. Explicitly include this
> >> file in arch/arm/include/asm/syscall.h. This fixes an lttng-modules compile error.
> >
> > Can you be more specific about the error? From your description, it sounds
> > like it should be fixed in lttng rather than here.
> >
> My apologies for the lack of clarity.
>
> My syscall tracing patch introduces a compile bug in lttng-modules when
> the latter calls syscall_get_nr(), similar to the following:
>
> <path-to-linux>/arch/arm/include/asm/syscall.h:21:2: error: implicit
> declaration of function 'task_thread_info'
> [-Werror=implicit-function-declaration]
>
> The issue is that we are using task_thread_info() in the
> syscall_get_nr() function in asm/syscall.h, but not explicitly including
> sched.h from this file, so we can expect this bug might surface any time
> that syscall_get_nr() is called.
>
> Hopefully that clarifies things somewhat.
Yep, thanks. Your patch sounds like the right thing to do, but please
include the compiler error in your commit log.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v7 0/3] watchdog: at91sam9_wdt: add device tree support
From: Fabio Porcedda @ 2012-10-02 16:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This patchset is for adding device tree support to the
at91sam9_wdt driver.
Another patchset will follow to add the new "timeout" binding to the
watchdog framework, at91sam9_wdt driver and to all the relevant drivers.
Changes:
v7:
- split the patchset
- remove timeout binding
v6:
- add watchdog core proprty timeout binding
- add as example to the orion_wdt driver the new timeout binding
v5:
- split dts commit in two, one for socs and one for boards.
v4:
- use "atmel,at91sam9260-wdt" as compatible
v3:
- add heartbeat option
- default disabled for all the soc, enable only for evk-pro3 board
- add at91sam9263 and at91sam9g45 soc
v2:
- add missing to and cc addresses
Fabio Porcedda (3):
watchdog: at91sam9_wdt: add device tree support
ARM: at91/dts: add at91sam9_wdt driver to at91sam926x, at91sam9g45
ARM: at91/dts: evk-pro3: enable watchdog
Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 15 +++++++++++++++
arch/arm/boot/dts/at91sam9260.dtsi | 6 ++++++
arch/arm/boot/dts/at91sam9263.dtsi | 6 ++++++
arch/arm/boot/dts/at91sam9g45.dtsi | 6 ++++++
arch/arm/boot/dts/evk-pro3.dts | 4 ++++
drivers/watchdog/at91sam9_wdt.c | 11 +++++++++++
6 files changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
--
1.7.11.3
^ permalink raw reply
* [PATCH v7 1/3] watchdog: at91sam9_wdt: add device tree support
From: Fabio Porcedda @ 2012-10-02 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349193662-23482-1-git-send-email-fabio.porcedda@gmail.com>
Tested on an at91sam9260 board (evk-pro3)
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | 15 +++++++++++++++
drivers/watchdog/at91sam9_wdt.c | 11 +++++++++++
2 files changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
new file mode 100644
index 0000000..2957ebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
@@ -0,0 +1,15 @@
+* Atmel Watchdog Timers
+
+** at91sam9-wdt
+
+Required properties:
+- compatible: must be "atmel,at91sam9260-wdt".
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+Example:
+
+ watchdog at fffffd40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffd40 0x10>;
+ };
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index 05e1be8..6dad954 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -32,6 +32,7 @@
#include <linux/timer.h>
#include <linux/bitops.h>
#include <linux/uaccess.h>
+#include <linux/of.h>
#include "at91sam9_wdt.h"
@@ -302,11 +303,21 @@ static int __exit at91wdt_remove(struct platform_device *pdev)
return res;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id at91_wdt_dt_ids[] = {
+ { .compatible = "atmel,at91sam9260-wdt" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, at91_wdt_dt_ids);
+#endif
+
static struct platform_driver at91wdt_driver = {
.remove = __exit_p(at91wdt_remove),
.driver = {
.name = "at91_wdt",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(at91_wdt_dt_ids),
},
};
--
1.7.11.3
^ permalink raw reply related
* [PATCH v7 2/3] ARM: at91/dts: add at91sam9_wdt driver to at91sam926x, at91sam9g45
From: Fabio Porcedda @ 2012-10-02 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349193662-23482-1-git-send-email-fabio.porcedda@gmail.com>
Tested on an at91sam9260 board (evk-pro3).
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
arch/arm/boot/dts/at91sam9260.dtsi | 6 ++++++
arch/arm/boot/dts/at91sam9263.dtsi | 6 ++++++
arch/arm/boot/dts/at91sam9g45.dtsi | 6 ++++++
3 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index 7c95f76..7612193 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -236,6 +236,12 @@
trigger-external;
};
};
+
+ watchdog at fffffd40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffd40 0x10>;
+ status = "disabled";
+ };
};
nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index 195019b..d822240 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -185,6 +185,12 @@
interrupts = <24 4 2>;
status = "disabled";
};
+
+ watchdog at fffffd40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffd40 0x10>;
+ status = "disabled";
+ };
};
nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 63751b1..df998ab 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -242,6 +242,12 @@
trigger-value = <0x6>;
};
};
+
+ watchdog at fffffd40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffd40 0x10>;
+ status = "disabled";
+ };
};
nand0: nand at 40000000 {
--
1.7.11.3
^ permalink raw reply related
* [PATCH v7 3/3] ARM: at91/dts: evk-pro3: enable watchdog
From: Fabio Porcedda @ 2012-10-02 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349193662-23482-1-git-send-email-fabio.porcedda@gmail.com>
Tested on evk-pro3.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
arch/arm/boot/dts/evk-pro3.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/evk-pro3.dts b/arch/arm/boot/dts/evk-pro3.dts
index b7354e6..ce959ee 100644
--- a/arch/arm/boot/dts/evk-pro3.dts
+++ b/arch/arm/boot/dts/evk-pro3.dts
@@ -26,6 +26,10 @@
atmel,vbus-gpio = <&pioC 5 0>;
status = "okay";
};
+
+ watchdog at fffffd40 {
+ status = "okay";
+ };
};
usb0: ohci at 00500000 {
--
1.7.11.3
^ permalink raw reply related
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Matt Porter @ 2012-10-02 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ABBCF.8010009@ti.com>
On Tue, Oct 02, 2012 at 03:32:55PM +0530, Sekhar Nori wrote:
> On 10/1/2012 6:02 PM, Matt Porter wrote:
> > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >> Hi Matt,
> >>
> >> On 9/29/2012 1:07 AM, Matt Porter wrote:
> >>> L3RAM (shared SRAM) is needed for use by several drivers.
> >>> This creates a genalloc pool and a hook for the platform code
> >>> to provide the struct gen_pool * in platform data.
> >>>
> >>> Signed-off-by: Matt Porter <mporter@ti.com>
> >>
> >> I am not sure if any of the DaVinci devices have a need to allocate from
> >> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> >> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> >> if there is much point in trying to allocate from there.
> >>
> >> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> >> allocation on DA850 makes sense for your case? If yes, can you repost
> >> with Ben's patch included in your series instead of this patch? I would
> >> prefer that over creating a new pool for shared RAM.
> >
> > Hrm, I did look at Ben's earlier patch. The reason I added a separate
> > pool mostly was so I didn't have to touch the PM code at all. That can
> > continue using the private SRAM API with the ARM RAM as it is now. The
>
> But you dont have to touch the PM code. PM code can continue using SRAM
> API. I have verified in the past that PM can work using shared RAM.
>
> > idea here was to allow that to be separate since no other bus masters
> > can access the ARM RAM anyway and do something that didn't require
> > regression testing PM. Also, I figured there's really no reason to use
> > even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> > and working fine for that use case.
>
> I see no reason why PM would break with shared RAM. I have not even seen
> reports of shared RAM being short of size so we need to save space by
> having PM code in ARM RAM. I can test the changes before the code is
> committed and it will get tested in linux-next as well.
Ok, sounds good to me.
> > The other thing is that Ben's patch needs to be rewritten to at least
> > have the hook I added so we can provide the gen_pool in platform data.
> > If you prefer this path still, I can add the needed hook on top of his
> > original patch. Ultimately, I only *need* genalloc support for the
> > shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> > happy with any way to get at it.
>
> Right, I prefer just adding the hook so that genalloc can be used along
> with SRAM API.
Ok.
> > Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> > remove the private SRAM API usage from the davinci ASoC driver too.
>
> Audio can use the shared RAM too. And once all users of the SRAM API are
> gone, only the hook to help pass the gen_pool as platform data needs to
> remain.
Right, I think we are on the same page now. I'll post an update to Ben's
original patch with required gen_pool hook for pdata use.
I noticed the beginning of DT support for davinci and the DT-based
genalloc driver, https://patchwork.kernel.org/patch/1421961/, fits
into that well.
-Matt
^ 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