* [PATCH v2 2/2] mtd: sh_flctl: Add device tree support
From: Bastian Hecht @ 2012-10-09 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349776729-9311-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>
---
v2: added dmas and dma-names fields to the bindings. These are not used yet
but are added for completing the bindings and will be needed later.
.../devicetree/bindings/mtd/flctl-nand.txt | 49 +++++++++++
drivers/mtd/nand/sh_flctl.c | 92 ++++++++++++++++++--
2 files changed, 134 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..427f46d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/flctl-nand.txt
@@ -0,0 +1,49 @@
+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
+
+Optional properties:
+- dmas: DMA specifier(s)
+- dma-names: name for each DMA specifier. Valid names are
+ "data_tx", "data_rx", "ecc_tx", "ecc_rx"
+
+The DMA fields are not used yet in the driver but are listed here for
+completing the bindings.
+
+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>;
+
+ dmas = <&dmac 1 /* data_tx */
+ &dmac 2;> /* data_rx */
+ dma-names = "data_tx", "data_rx";
+
+ 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 1105fbb..02ff9d1 100644
--- a/drivers/mtd/nand/sh_flctl.c
+++ b/drivers/mtd/nand/sh_flctl.c
@@ -29,6 +29,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>
@@ -1021,6 +1024,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;
@@ -1030,12 +1100,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) {
@@ -1067,6 +1132,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;
@@ -1109,7 +1184,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;
@@ -1143,6 +1220,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 v2 1/2] mtd: sh_flctl: Add DMA capabilty
From: Bastian Hecht @ 2012-10-09 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349776729-9311-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>
Reviewed-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
v2: added missing header complete.h and removed double tab.
drivers/mtd/nand/sh_flctl.c | 175 +++++++++++++++++++++++++++++++++++++++++-
include/linux/mtd/sh_flctl.h | 12 +++
2 files changed, 184 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
index 4fbfe96..1105fbb 100644
--- a/drivers/mtd/nand/sh_flctl.c
+++ b/drivers/mtd/nand/sh_flctl.c
@@ -23,11 +23,15 @@
#include <linux/module.h>
#include <linux/kernel.h>
+#include <linux/completion.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 +110,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 +343,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 +425,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 +463,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 +1095,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 +1114,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 +1128,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 v2 0/2] Add DMA and device tree support to the flash controller FLCTL
From: Bastian Hecht @ 2012-10-09 9:58 UTC (permalink / raw)
To: linux-arm-kernel
changelog v2: - cosmetic fixes in patch 1
- added dmas and dma-names field in patch 2
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 3/7] ARM: tegra30: cpuidle: add LP2 driver for secondary CPUs
From: Lorenzo Pieralisi @ 2012-10-09 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349774337.16173.8.camel@jlo-ubuntu-64.nvidia.com>
On Tue, Oct 09, 2012 at 10:18:57AM +0100, Joseph Lo wrote:
> On Tue, 2012-10-09 at 16:38 +0800, Lorenzo Pieralisi wrote:
> > On Tue, Oct 09, 2012 at 05:13:15AM +0100, Joseph Lo wrote:
> >
> > [...]
> >
> > > > > +ENTRY(tegra_flush_l1_cache)
> > > > > + stmfd sp!, {r4-r5, r7, r9-r11, lr}
> > > > > + dmb @ ensure ordering
> > > > > +
> > > > > + /* Disable the data cache */
> > > > > + mrc p15, 0, r2, c1, c0, 0
> > > > > + bic r2, r2, #CR_C
> > > > > + dsb
> > > > > + mcr p15, 0, r2, c1, c0, 0
> > > > > +
> > > > > + /* Flush data cache */
> > > > > + mov r10, #0
> > > > > +#ifdef CONFIG_PREEMPT
> > > > > + save_and_disable_irqs_notrace r9 @ make cssr&csidr read atomic
> > > > > +#endif
> > > > > + mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr
> > > > > + isb @ isb to sych the new cssr&csidr
> > > > > + mrc p15, 1, r1, c0, c0, 0 @ read the new csidr
> > > > > +#ifdef CONFIG_PREEMPT
> > > > > + restore_irqs_notrace r9
> > > > > +#endif
> > > > > + and r2, r1, #7 @ extract the length of the cache lines
> > > > > + add r2, r2, #4 @ add 4 (line length offset)
> > > > > + ldr r4, =0x3ff
> > > > > + ands r4, r4, r1, lsr #3 @ find maximum number on the way size
> > > > > + clz r5, r4 @ find bit position of way size increment
> > > > > + ldr r7, =0x7fff
> > > > > + ands r7, r7, r1, lsr #13 @ extract max number of the index size
> > > > > +loop2:
> > > > > + mov r9, r4 @ create working copy of max way size
> > > > > +loop3:
> > > > > + orr r11, r10, r9, lsl r5 @ factor way and cache number into r11
> > > > > + orr r11, r11, r7, lsl r2 @ factor index number into r11
> > > > > + mcr p15, 0, r11, c7, c14, 2 @ clean & invalidate by set/way
> > > > > + subs r9, r9, #1 @ decrement the way
> > > > > + bge loop3
> > > > > + subs r7, r7, #1 @ decrement the index
> > > > > + bge loop2
> > > > > +finished:
> > > > > + mov r10, #0 @ swith back to cache level 0
> > > > > + mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr
> > > > > + dsb
> > > > > + isb
> > > >
> > > > This code is already in the kernel in cache-v7.S, please use that.
> > > > We are just adding the new LoUIS API that probably does what you
> > > > want, even though for Tegra, that is an A9 based platform I fail to
> > > > understand why Level of Coherency differs from L1.
> > > >
> > > > Can you explain to me please why Level of Coherency (LoC) is != from L1
> > > > on Tegra ?
> > > >
> > >
> > > Thanks for introducing the new LoUIS cache API. Did LoUIS been changed
> > > by other HW? I checked the new LoUIS API. If LoUIS == 0, it means inner
> > > shareable then it do nothing just return. But I need to flush L1 data
> > > cache here to sync the coherency before CPU be power gated. And disable
> > > data cache before flush is needed.
> >
> > I understand that, that's why I am asking. To me LoUIS and LoC should
> > both be the same for A9 based platforms and they should both represent
> > a cache level that *includes* L1.
> >
> > Can you provide me with the CLIDR value for Tegra3 please ?
> >
>
> I just checked the CLIDR of both Tegra20 and Tegra30. It's 0x09200003.
> It looks I can use this new LoUIS api, right? :)
You do not have to, since LoUIS == LoC, but that would be appreciated.
If you execute:
v7_flush_dcache_all
That would do the same thing on current Tegra(s).
If you want to reuse the same code for future A15/A7 processors then yes,
v7_flush_dcache_louis
is what you want to call, and that works for current Tegra(s) as well since,
as I mentioned LoUIS == LoC there.
Overall, using the new LoUIS API for single core shutdown is the best
option, since it should work for current and future cores.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH 3/7] ARM: tegra30: cpuidle: add LP2 driver for secondary CPUs
From: Joseph Lo @ 2012-10-09 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009083804.GA11840@e102568-lin.cambridge.arm.com>
On Tue, 2012-10-09 at 16:38 +0800, Lorenzo Pieralisi wrote:
> On Tue, Oct 09, 2012 at 05:13:15AM +0100, Joseph Lo wrote:
>
> [...]
>
> > > > +ENTRY(tegra_flush_l1_cache)
> > > > + stmfd sp!, {r4-r5, r7, r9-r11, lr}
> > > > + dmb @ ensure ordering
> > > > +
> > > > + /* Disable the data cache */
> > > > + mrc p15, 0, r2, c1, c0, 0
> > > > + bic r2, r2, #CR_C
> > > > + dsb
> > > > + mcr p15, 0, r2, c1, c0, 0
> > > > +
> > > > + /* Flush data cache */
> > > > + mov r10, #0
> > > > +#ifdef CONFIG_PREEMPT
> > > > + save_and_disable_irqs_notrace r9 @ make cssr&csidr read atomic
> > > > +#endif
> > > > + mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr
> > > > + isb @ isb to sych the new cssr&csidr
> > > > + mrc p15, 1, r1, c0, c0, 0 @ read the new csidr
> > > > +#ifdef CONFIG_PREEMPT
> > > > + restore_irqs_notrace r9
> > > > +#endif
> > > > + and r2, r1, #7 @ extract the length of the cache lines
> > > > + add r2, r2, #4 @ add 4 (line length offset)
> > > > + ldr r4, =0x3ff
> > > > + ands r4, r4, r1, lsr #3 @ find maximum number on the way size
> > > > + clz r5, r4 @ find bit position of way size increment
> > > > + ldr r7, =0x7fff
> > > > + ands r7, r7, r1, lsr #13 @ extract max number of the index size
> > > > +loop2:
> > > > + mov r9, r4 @ create working copy of max way size
> > > > +loop3:
> > > > + orr r11, r10, r9, lsl r5 @ factor way and cache number into r11
> > > > + orr r11, r11, r7, lsl r2 @ factor index number into r11
> > > > + mcr p15, 0, r11, c7, c14, 2 @ clean & invalidate by set/way
> > > > + subs r9, r9, #1 @ decrement the way
> > > > + bge loop3
> > > > + subs r7, r7, #1 @ decrement the index
> > > > + bge loop2
> > > > +finished:
> > > > + mov r10, #0 @ swith back to cache level 0
> > > > + mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr
> > > > + dsb
> > > > + isb
> > >
> > > This code is already in the kernel in cache-v7.S, please use that.
> > > We are just adding the new LoUIS API that probably does what you
> > > want, even though for Tegra, that is an A9 based platform I fail to
> > > understand why Level of Coherency differs from L1.
> > >
> > > Can you explain to me please why Level of Coherency (LoC) is != from L1
> > > on Tegra ?
> > >
> >
> > Thanks for introducing the new LoUIS cache API. Did LoUIS been changed
> > by other HW? I checked the new LoUIS API. If LoUIS == 0, it means inner
> > shareable then it do nothing just return. But I need to flush L1 data
> > cache here to sync the coherency before CPU be power gated. And disable
> > data cache before flush is needed.
>
> I understand that, that's why I am asking. To me LoUIS and LoC should
> both be the same for A9 based platforms and they should both represent
> a cache level that *includes* L1.
>
> Can you provide me with the CLIDR value for Tegra3 please ?
>
I just checked the CLIDR of both Tegra20 and Tegra30. It's 0x09200003.
It looks I can use this new LoUIS api, right? :)
I will give it a try and update to next version. Thanks.
> >
> > I can tell you the sequence that why we just do L1 data cache flush
> > here. Maybe I need to change the comment to "flush to point of
> > coherency" not "level of coherency".
> >
> > For secondary CPUs:
> > * after cpu_suspend
> > * disable data cache and flush L1 data cache
> ^(1)
> > * Turn off SMP coherency
> ^(2)
>
> Two steps above, one assembly function, no access to any data whatsoever
> please.
>
OK. Will do this and update to next version.
> > * power gate CPU
> >
> > For CPU0:
> > * outer_disable (flush and disable L2)
>
> I guess L2 cannot be retained on Tegra ?
>
Yes.
I will give it a test and update later.
Thanks,
Joseph
^ permalink raw reply
* [PATCH 1/6] ARM: bcm476x: Add infrastructure
From: Arnd Bergmann @ 2012-10-09 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121007015405.958959522@gmail.com>
Hi Domenico,
Your series looks very nice, thanks for the contribution!
Stephen has already covered everything I would have commented and
more, except for one thing that I found:
On Sunday 07 October 2012, Domenico Andreoli wrote:
> Index: b/arch/arm/boot/dts/bcm476x.dtsi
> ===================================================================
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm476x.dtsi
> @@ -0,0 +1,31 @@
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + compatible = "brcm,bcm476x";
> + model = "Broadcom BCM476x";
> +
> ...
> + vic0: interrupt-controller at 80000 {
> + compatible = "brcm,bcm476x-pl192", "arm,pl192-vic", "arm,primecell";
> + reg = <0x80000 0x1000>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
I suppose that the name of the soc is not actually "bcm476x" but you
are in fact referring to the family including bcm4760 and bcm4761.
The convention in the device tree is to always use specific product
numbers, rather than wildcards. If one of the two has a superset of
the hardware of the other, I would recommend you pick that number
in the device tree and in the drivers, and for the other one, you
just mark them as compatible to both of them.
Arnd
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for arm64 [ver #2]
From: David Howells @ 2012-10-09 9:15 UTC (permalink / raw)
To: linux-arm-kernel
Can you merge the following branch into the arm64 tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-arm64-20121009
for you to fetch changes up to a24b2da6de9a44f395c67219d300de21f66d0da3:
UAPI: (Scripted) Disintegrate arch/arm64/include/asm (2012-10-09 09:46:34 +0100)
----------------------------------------------------------------
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate arch/arm64/include/asm
arch/arm64/include/asm/Kbuild | 2 -
arch/arm64/include/asm/hwcap.h | 22 +----
arch/arm64/include/asm/ptrace.h | 88 +------------------
arch/arm64/include/asm/sigcontext.h | 40 +--------
arch/arm64/include/asm/stat.h | 5 +-
arch/arm64/include/asm/unistd.h | 8 +-
arch/arm64/include/uapi/asm/Kbuild | 14 +++
arch/arm64/include/{ => uapi}/asm/auxvec.h | 0
arch/arm64/include/{ => uapi}/asm/bitsperlong.h | 0
arch/arm64/include/{ => uapi}/asm/byteorder.h | 0
arch/arm64/include/{ => uapi}/asm/fcntl.h | 0
arch/arm64/include/uapi/asm/hwcap.h | 39 +++++++++
arch/arm64/include/{ => uapi}/asm/param.h | 0
arch/arm64/include/uapi/asm/ptrace.h | 110 ++++++++++++++++++++++++
arch/arm64/include/{ => uapi}/asm/setup.h | 0
arch/arm64/include/uapi/asm/sigcontext.h | 57 ++++++++++++
arch/arm64/include/{ => uapi}/asm/siginfo.h | 0
arch/arm64/include/{ => uapi}/asm/signal.h | 0
arch/arm64/include/uapi/asm/stat.h | 16 ++++
arch/arm64/include/{ => uapi}/asm/statfs.h | 0
arch/arm64/include/uapi/asm/unistd.h | 16 ++++
21 files changed, 257 insertions(+), 160 deletions(-)
rename arch/arm64/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/arm64/include/{ => uapi}/asm/bitsperlong.h (100%)
rename arch/arm64/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/arm64/include/{ => uapi}/asm/fcntl.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/hwcap.h
rename arch/arm64/include/{ => uapi}/asm/param.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/ptrace.h
rename arch/arm64/include/{ => uapi}/asm/setup.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/sigcontext.h
rename arch/arm64/include/{ => uapi}/asm/siginfo.h (100%)
rename arch/arm64/include/{ => uapi}/asm/signal.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/stat.h
rename arch/arm64/include/{ => uapi}/asm/statfs.h (100%)
create mode 100644 arch/arm64/include/uapi/asm/unistd.h
.
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for arm [ver #2]
From: David Howells @ 2012-10-09 9:15 UTC (permalink / raw)
To: linux-arm-kernel
Can you merge the following branch into the arm tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-arm-20121009
for you to fetch changes up to 86418cab1bb1aa591d48ea51d67aeb54f30732d1:
UAPI: (Scripted) Disintegrate arch/arm/include/asm (2012-10-09 09:46:32 +0100)
----------------------------------------------------------------
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate arch/arm/include/asm
arch/arm/include/asm/Kbuild | 2 -
arch/arm/include/asm/hwcap.h | 27 +-
arch/arm/include/asm/ptrace.h | 126 +-------
arch/arm/include/asm/setup.h | 172 +---------
arch/arm/include/asm/signal.h | 127 +-------
arch/arm/include/asm/swab.h | 37 +--
arch/arm/include/asm/unistd.h | 440 +------------------------
arch/arm/include/uapi/asm/Kbuild | 16 +
arch/arm/include/{ => uapi}/asm/a.out.h | 0
arch/arm/include/{ => uapi}/asm/byteorder.h | 0
arch/arm/include/{ => uapi}/asm/fcntl.h | 0
arch/arm/include/uapi/asm/hwcap.h | 29 ++
arch/arm/include/{ => uapi}/asm/ioctls.h | 0
arch/arm/include/{ => uapi}/asm/kvm_para.h | 0
arch/arm/include/{ => uapi}/asm/mman.h | 0
arch/arm/include/{ => uapi}/asm/posix_types.h | 0
arch/arm/include/uapi/asm/ptrace.h | 137 ++++++++
arch/arm/include/uapi/asm/setup.h | 187 +++++++++++
arch/arm/include/{ => uapi}/asm/sigcontext.h | 0
arch/arm/include/uapi/asm/signal.h | 127 ++++++++
arch/arm/include/{ => uapi}/asm/stat.h | 0
arch/arm/include/{ => uapi}/asm/statfs.h | 0
arch/arm/include/uapi/asm/swab.h | 53 +++
arch/arm/include/uapi/asm/unistd.h | 450 ++++++++++++++++++++++++++
24 files changed, 1005 insertions(+), 925 deletions(-)
rename arch/arm/include/{ => uapi}/asm/a.out.h (100%)
rename arch/arm/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/arm/include/{ => uapi}/asm/fcntl.h (100%)
create mode 100644 arch/arm/include/uapi/asm/hwcap.h
rename arch/arm/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/arm/include/{ => uapi}/asm/kvm_para.h (100%)
rename arch/arm/include/{ => uapi}/asm/mman.h (100%)
rename arch/arm/include/{ => uapi}/asm/posix_types.h (100%)
create mode 100644 arch/arm/include/uapi/asm/ptrace.h
create mode 100644 arch/arm/include/uapi/asm/setup.h
rename arch/arm/include/{ => uapi}/asm/sigcontext.h (100%)
create mode 100644 arch/arm/include/uapi/asm/signal.h
rename arch/arm/include/{ => uapi}/asm/stat.h (100%)
rename arch/arm/include/{ => uapi}/asm/statfs.h (100%)
create mode 100644 arch/arm/include/uapi/asm/swab.h
create mode 100644 arch/arm/include/uapi/asm/unistd.h
.
^ permalink raw reply
* [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
From: Péter Ujfalusi @ 2012-10-09 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008173557.10603.18539.stgit@muffinssi>
On 10/08/2012 07:35 PM, Tony Lindgren wrote:
> - omap-dma.c and omap-pcm.c can test the arch locally as
> omap1 and omap2 cannot be compiled together because of
> conflicting compiler flags
> sound/soc/omap/omap-pcm.c | 9 +++++++--
Tony: is this going to be included in 3.7?
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
^ permalink raw reply
* Problem with 64-bit registers on i.MX53
From: Uwe Kleine-König @ 2012-10-09 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008171011.GA4625@n2100.arm.linux.org.uk>
Hello,
On Mon, Oct 08, 2012 at 06:10:11PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 08, 2012 at 06:01:24PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 08, 2012 at 06:08:41PM +0200, Michael Olbrich wrote:
> You may also like to try the patch below... it will probably fix your
> problem.
>
> diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
> index a7aadbd..6a6f1e4 100644
> --- a/arch/arm/include/asm/vfpmacros.h
> +++ b/arch/arm/include/asm/vfpmacros.h
> @@ -28,7 +28,7 @@
> ldr \tmp, =elf_hwcap @ may not have MVFR regs
> ldr \tmp, [\tmp, #0]
> tst \tmp, #HWCAP_VFPv3D16
> - ldceq p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
> + ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
> addne \base, \base, #32*4 @ step over unused register space
> #else
> VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0
> @@ -52,7 +52,7 @@
> ldr \tmp, =elf_hwcap @ may not have MVFR regs
> ldr \tmp, [\tmp, #0]
> tst \tmp, #HWCAP_VFPv3D16
> - stceq p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
> + stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
According to the ARMARM for v7-A and v7-R (ARM DDI 0406B errata 2010 Q2)
the syntax is "STC{L}<c> ...", with a note "The pre-UAL syntax STC<c>L
is equivalent to STCL<c>.". Maybe the UAL-syntax should better be used?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Problem with 64-bit registers on i.MX53
From: Michael Olbrich @ 2012-10-09 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008175052.GG2302@linaro.org>
On Mon, Oct 08, 2012 at 06:50:52PM +0100, Dave Martin wrote:
> On Mon, Oct 08, 2012 at 06:10:11PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 08, 2012 at 06:01:24PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Oct 08, 2012 at 06:08:41PM +0200, Michael Olbrich wrote:
> > > > I have a problem that looks like that 64-bit registers (I think) are not
> > > > saved/restored correctly on a context switch. I've reduced it to the
> > > > following test case:
> > > >
> > > > - Latest Linux mainline kernel (v3.6-8559-ge9eca4d)
> > > > v3.5 is also affected
> > > > - imx_v6_v7_defconfig
> > > > - arch/arm/boot/dts/imx53-evk.dts
> > > >
> > > > The following test program is compiled with "-mcpu=cortex-a8 -mfpu=neon
> > > > -O2".
> > > > ------------------------>8--------------------------------
> > > > #include <inttypes.h>
> > > > #include <assert.h>
> > > >
> > > > volatile int x = 2;
> > > > volatile int64_t y = 2;
> > > >
> > > > int main() {
> > > > volatile int a = 0;
> > > > volatile int64_t b = 0;
> > > > while (1) {
> > > > a = (a + x) % (1 << 30);
> > > > b = (b + y) % (1 << 30);
> > > > assert(a == b);
> > > > }
> > > > }
> > > > ------------------------>8--------------------------------
> > > > The ".. (b + y) .." should result in "vadd.i64 d19, d18, d16" or
> > > > something like that.
>
> Just for my curiosity, can you let me know what compiler version you're
> using and the disassembly? I'm actually a little surprised to see
> NEON code being generated here,
Im using oselas.toolchain which includes a gcc-linaro-4.6-2011.11. It
generates quite a bit of NEON code actually. I originally tracked down the
issue to a commit in libxcb: "xcb_in: Use 64-bit sequence numbers
internally everywhere.". The compiler generated NEON code to calculate
sequence numbers...
Regards,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Vaibhav Hiremath @ 2012-10-09 8:57 UTC (permalink / raw)
To: linux-arm-kernel
With recent changes in omap gpmc driver code, in case of DT
boot mode, where bootloader does not configure gpmc cs space
will result into kernel BUG() inside gpmc_mem_init() function,
as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
gpmc_config7[0].baseaddress is set to '0' on reset.
This use-case is applicable for any board/EVM which doesn't have
any peripheral connected to gpmc cs0, for example BeagleXM and
BeagleBone, so DT boot mode fails.
This patch adds of_have_populated_dt() check before creating
device, so that for DT boot mode, gpmc probe will not be called
which is expected behavior, as gpmc is not supported yet from DT.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Afzal Mohammed <afzal@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc Paul Walmsley <paul@pwsan.com>
---
This should go in for rc1, as this breaks AM33xx boot.
arch/arm/mach-omap2/gpmc.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..c68f9e1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -981,6 +981,10 @@ static int __init omap_gpmc_init(void)
struct platform_device *pdev;
char *oh_name = "gpmc";
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
oh = omap_hwmod_lookup(oh_name);
if (!oh) {
pr_err("Could not look up %s\n", oh_name);
--
1.7.0.4
^ permalink raw reply related
* Problem with 64-bit registers on i.MX53
From: Michael Olbrich @ 2012-10-09 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008171011.GA4625@n2100.arm.linux.org.uk>
On Mon, Oct 08, 2012 at 06:10:11PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 08, 2012 at 06:01:24PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 08, 2012 at 06:08:41PM +0200, Michael Olbrich wrote:
> > > I have a problem that looks like that 64-bit registers (I think) are not
> > > saved/restored correctly on a context switch. I've reduced it to the
> > > following test case:
> > >
> > > - Latest Linux mainline kernel (v3.6-8559-ge9eca4d)
> > > v3.5 is also affected
> > > - imx_v6_v7_defconfig
> > > - arch/arm/boot/dts/imx53-evk.dts
> > >
> > > The following test program is compiled with "-mcpu=cortex-a8 -mfpu=neon
> > > -O2".
> > > ------------------------>8--------------------------------
> > > #include <inttypes.h>
> > > #include <assert.h>
> > >
> > > volatile int x = 2;
> > > volatile int64_t y = 2;
> > >
> > > int main() {
> > > volatile int a = 0;
> > > volatile int64_t b = 0;
> > > while (1) {
> > > a = (a + x) % (1 << 30);
> > > b = (b + y) % (1 << 30);
> > > assert(a == b);
> > > }
> > > }
> > > ------------------------>8--------------------------------
> > > The ".. (b + y) .." should result in "vadd.i64 d19, d18, d16" or
> > > something like that.
> >
> > Hmm.
> >
> > Can you send me the output of 'grep ^Features /proc/cpuinfo' please?
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
> You may also like to try the patch below... it will probably fix your
> problem.
This does indeed fix my problem. Is this a real fix or just a test to
narrow down the issue? I don't really understand what it does.
If it is a real fix,
Tested-By: Michael Olbrich <m.olbrich@pengutronix.de>
Regards,
Michael
> diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
> index a7aadbd..6a6f1e4 100644
> --- a/arch/arm/include/asm/vfpmacros.h
> +++ b/arch/arm/include/asm/vfpmacros.h
> @@ -28,7 +28,7 @@
> ldr \tmp, =elf_hwcap @ may not have MVFR regs
> ldr \tmp, [\tmp, #0]
> tst \tmp, #HWCAP_VFPv3D16
> - ldceq p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
> + ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
> addne \base, \base, #32*4 @ step over unused register space
> #else
> VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0
> @@ -52,7 +52,7 @@
> ldr \tmp, =elf_hwcap @ may not have MVFR regs
> ldr \tmp, [\tmp, #0]
> tst \tmp, #HWCAP_VFPv3D16
> - stceq p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
> + stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
> addne \base, \base, #32*4 @ step over unused register space
> #else
> VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 3/7] ARM: tegra30: cpuidle: add LP2 driver for secondary CPUs
From: Lorenzo Pieralisi @ 2012-10-09 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349755995.15153.145.camel@jlo-ubuntu-64.nvidia.com>
On Tue, Oct 09, 2012 at 05:13:15AM +0100, Joseph Lo wrote:
[...]
> > > +ENTRY(tegra_flush_l1_cache)
> > > + stmfd sp!, {r4-r5, r7, r9-r11, lr}
> > > + dmb @ ensure ordering
> > > +
> > > + /* Disable the data cache */
> > > + mrc p15, 0, r2, c1, c0, 0
> > > + bic r2, r2, #CR_C
> > > + dsb
> > > + mcr p15, 0, r2, c1, c0, 0
> > > +
> > > + /* Flush data cache */
> > > + mov r10, #0
> > > +#ifdef CONFIG_PREEMPT
> > > + save_and_disable_irqs_notrace r9 @ make cssr&csidr read atomic
> > > +#endif
> > > + mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr
> > > + isb @ isb to sych the new cssr&csidr
> > > + mrc p15, 1, r1, c0, c0, 0 @ read the new csidr
> > > +#ifdef CONFIG_PREEMPT
> > > + restore_irqs_notrace r9
> > > +#endif
> > > + and r2, r1, #7 @ extract the length of the cache lines
> > > + add r2, r2, #4 @ add 4 (line length offset)
> > > + ldr r4, =0x3ff
> > > + ands r4, r4, r1, lsr #3 @ find maximum number on the way size
> > > + clz r5, r4 @ find bit position of way size increment
> > > + ldr r7, =0x7fff
> > > + ands r7, r7, r1, lsr #13 @ extract max number of the index size
> > > +loop2:
> > > + mov r9, r4 @ create working copy of max way size
> > > +loop3:
> > > + orr r11, r10, r9, lsl r5 @ factor way and cache number into r11
> > > + orr r11, r11, r7, lsl r2 @ factor index number into r11
> > > + mcr p15, 0, r11, c7, c14, 2 @ clean & invalidate by set/way
> > > + subs r9, r9, #1 @ decrement the way
> > > + bge loop3
> > > + subs r7, r7, #1 @ decrement the index
> > > + bge loop2
> > > +finished:
> > > + mov r10, #0 @ swith back to cache level 0
> > > + mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr
> > > + dsb
> > > + isb
> >
> > This code is already in the kernel in cache-v7.S, please use that.
> > We are just adding the new LoUIS API that probably does what you
> > want, even though for Tegra, that is an A9 based platform I fail to
> > understand why Level of Coherency differs from L1.
> >
> > Can you explain to me please why Level of Coherency (LoC) is != from L1
> > on Tegra ?
> >
>
> Thanks for introducing the new LoUIS cache API. Did LoUIS been changed
> by other HW? I checked the new LoUIS API. If LoUIS == 0, it means inner
> shareable then it do nothing just return. But I need to flush L1 data
> cache here to sync the coherency before CPU be power gated. And disable
> data cache before flush is needed.
I understand that, that's why I am asking. To me LoUIS and LoC should
both be the same for A9 based platforms and they should both represent
a cache level that *includes* L1.
Can you provide me with the CLIDR value for Tegra3 please ?
>
> I can tell you the sequence that why we just do L1 data cache flush
> here. Maybe I need to change the comment to "flush to point of
> coherency" not "level of coherency".
>
> For secondary CPUs:
> * after cpu_suspend
> * disable data cache and flush L1 data cache
^(1)
> * Turn off SMP coherency
^(2)
Two steps above, one assembly function, no access to any data whatsoever
please.
> * power gate CPU
>
> For CPU0:
> * outer_disable (flush and disable L2)
I guess L2 cannot be retained on Tegra ?
> * cpu_suspend
> * disable data cache and flush L1 data cache
> * Turn off SMP coherency
> * Turn off MMU
> * shut off the CPU rail
>
> So we only do flush to PoC.
>
> And changing the sequence of secondary CPUs to belows maybe more
> suitable?
Yes, basically because the net effect should be identical.
Lorenzo
> * after cpu_suspend
> * disable data cache and call to v7_flush_dcache_all
> * Turn off SMP coherency
> * power gate CPU
>
^ permalink raw reply
* [PATCH] ARM: EXYNOS5: Remove wrongly placed usb2.0 PHY_CFG definition from PMU_REG
From: Jingoo Han @ 2012-10-09 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349443590-29901-1-git-send-email-gautam.vivek@samsung.com>
On Friday, October 05, 2012 10:27 PM Vivek Gautam wrote
>
> EXYNOS5_USB_CFG macro should actually point to USB20PHY_CFG
> system register (base addr + 0x230). It's wrongly placed in regs-pmu.
> Actual register at offset 0x230 in PMU is SEQ_TRANSITION4.
>
> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
As you mentioned, this definition is wrong.
So, it should be removed.
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
> ---
> arch/arm/mach-exynos/include/mach/regs-pmu.h | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
> index d4e392b..70b2795 100644
> --- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
> +++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
> @@ -230,8 +230,6 @@
>
> /* For EXYNOS5 */
>
> -#define EXYNOS5_USB_CFG S5P_PMUREG(0x0230)
> -
> #define EXYNOS5_AUTO_WDTRESET_DISABLE S5P_PMUREG(0x0408)
> #define EXYNOS5_MASK_WDTRESET_REQUEST S5P_PMUREG(0x040C)
>
> --
> 1.7.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos5250: Enabling ohci-exynos driver
From: Jingoo Han @ 2012-10-09 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349431818-15639-3-git-send-email-gautam.vivek@samsung.com>
On Friday, October 05, 2012 7:10 PM Vivek Gautam wrote
>
> Adding OHCI device tree node for Exynos5250 along with
> the device base address.
>
> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
It looks good. Also I have tested this patch with Exynos5250.
Acked-by: Jingoo Han <jg1.han@samsung.com>
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 15 +++++++++++++++
> arch/arm/boot/dts/exynos5250.dtsi | 6 ++++++
> arch/arm/mach-exynos/include/mach/map.h | 1 +
> arch/arm/mach-exynos/mach-exynos5-dt.c | 2 ++
> 4 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> index 56e35c7..bff10a8 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -23,3 +23,18 @@ Example:
> interrupts = <0 71 0>;
> samsung,vbus-gpio = <&gpx2 6 1 3 3>;
> };
> +
> +OHCI
> +Required properties:
> + - compatible: should be "samsung,exynos-ohci" for USB 2.0
> + OHCI companion controller in host mode.
> + - reg: physical base address of the controller and length of memory mapped
> + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Example:
> + ohci {
> + compatible = "samsung,exynos-ohci";
> + reg = <0x12120000 0x100>;
> + interrupts = <0 71 0>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index 73ea844..bcdfbe2 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -224,6 +224,12 @@
> interrupts = <0 71 0>;
> };
>
> + ohci {
> + compatible = "samsung,exynos-ohci";
> + reg = <0x12120000 0x100>;
> + interrupts = <0 71 0>;
> + };
> +
> amba {
> #address-cells = <1>;
> #size-cells = <1>;
> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
> index 825fe40..cfede1f 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -196,6 +196,7 @@
> #define EXYNOS4_PA_OHCI 0x12590000
> #define EXYNOS4_PA_HSPHY 0x125B0000
> #define EXYNOS5_PA_EHCI 0x12110000
> +#define EXYNOS5_PA_OHCI 0x12120000
> #define EXYNOS4_PA_MFC 0x13400000
>
> #define EXYNOS4_PA_UART 0x13800000
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index 6d950d7b..e6c2144 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -74,6 +74,8 @@ static const struct of_dev_auxdata exynos5250_auxdata_lookup[] __initconst = {
> "exynos-gsc.3", NULL),
> OF_DEV_AUXDATA("samsung,exynos-ehci", EXYNOS5_PA_EHCI,
> "s5p-ehci", NULL),
> + OF_DEV_AUXDATA("samsung,exynos-ohci", EXYNOS5_PA_OHCI,
> + "exynos-ohci", NULL),
> {},
> };
>
> --
> 1.7.6.5
^ permalink raw reply
* [PATCH 1/2] ARM: Exynos5250: Enabling ehci-s5p driver
From: Jingoo Han @ 2012-10-09 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349431818-15639-2-git-send-email-gautam.vivek@samsung.com>
On Friday, October 05, 2012 7:10 PM Vivek Gautam wrote
>
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
It looks good. Also I have tested this patch with Exynos5250.
Acked-by: Jingoo Han <jg1.han@samsung.com>
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 25 ++++++++++++++++++++
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +++
> arch/arm/boot/dts/exynos5250.dtsi | 6 ++++
> arch/arm/mach-exynos/include/mach/map.h | 1 +
> arch/arm/mach-exynos/mach-exynos5-dt.c | 2 +
> 5 files changed, 38 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> new file mode 100644
> index 0000000..56e35c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -0,0 +1,25 @@
> +Samsung Exynos SoC USB controller
> +
> +The USB devices interface with USB controllers on Exynos SOCs.
> +The device node has following properties.
> +
> +EHCI
> +Required properties:
> + - compatible: should be "samsung,exynos-ehci" for USB 2.0
> + EHCI controller in host mode.
> + - reg: physical base address of the controller and length of memory mapped
> + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Optional properties:
> + - samsung,vbus-gpio: if present, specifies the GPIO that
> + needs to be pulled up for the bus to be powered.
> +
> +Example:
> +
> + ehci {
> + compatible = "samsung,exynos-ehci";
> + reg = <0x12110000 0x100>;
> + interrupts = <0 71 0>;
> + samsung,vbus-gpio = <&gpx2 6 1 3 3>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index a352df4..089576b 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -166,4 +166,8 @@
> spi_2: spi at 12d40000 {
> status = "disabled";
> };
> +
> + ehci {
> + samsung,vbus-gpio = <&gpx2 6 1 3 3>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index dddfd6e..73ea844 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -218,6 +218,12 @@
> #size-cells = <0>;
> };
>
> + ehci {
> + compatible = "samsung,exynos-ehci";
> + reg = <0x12110000 0x100>;
> + interrupts = <0 71 0>;
> + };
> +
> amba {
> #address-cells = <1>;
> #size-cells = <1>;
> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
> index 8480849..825fe40 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -195,6 +195,7 @@
> #define EXYNOS4_PA_EHCI 0x12580000
> #define EXYNOS4_PA_OHCI 0x12590000
> #define EXYNOS4_PA_HSPHY 0x125B0000
> +#define EXYNOS5_PA_EHCI 0x12110000
> #define EXYNOS4_PA_MFC 0x13400000
>
> #define EXYNOS4_PA_UART 0x13800000
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index fee9dcd..6d950d7b 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -72,6 +72,8 @@ static const struct of_dev_auxdata exynos5250_auxdata_lookup[] __initconst = {
> "exynos-gsc.2", NULL),
> OF_DEV_AUXDATA("samsung,exynos5-gsc", EXYNOS5_PA_GSC3,
> "exynos-gsc.3", NULL),
> + OF_DEV_AUXDATA("samsung,exynos-ehci", EXYNOS5_PA_EHCI,
> + "s5p-ehci", NULL),
> {},
> };
>
> --
> 1.7.6.5
^ permalink raw reply
* [PATCH] ARM: imx: clk-imx27: Fix divider width field
From: Sascha Hauer @ 2012-10-09 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349749200-8332-1-git-send-email-festevam@gmail.com>
On Mon, Oct 08, 2012 at 11:20:00PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> As per mx27 reference manual, H264DIV and SSI2DIV are 6-bit wide fields in
> register PCDR0.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks
Sascha
> ---
> arch/arm/mach-imx/clk-imx27.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> index 3b6b640..366e5d5 100644
> --- a/arch/arm/mach-imx/clk-imx27.c
> +++ b/arch/arm/mach-imx/clk-imx27.c
> @@ -109,7 +109,7 @@ int __init mx27_clocks_init(unsigned long fref)
> clk[per3_div] = imx_clk_divider("per3_div", "mpll_main2", CCM_PCDR1, 16, 6);
> clk[per4_div] = imx_clk_divider("per4_div", "mpll_main2", CCM_PCDR1, 24, 6);
> clk[vpu_sel] = imx_clk_mux("vpu_sel", CCM_CSCR, 21, 1, vpu_sel_clks, ARRAY_SIZE(vpu_sel_clks));
> - clk[vpu_div] = imx_clk_divider("vpu_div", "vpu_sel", CCM_PCDR0, 10, 3);
> + clk[vpu_div] = imx_clk_divider("vpu_div", "vpu_sel", CCM_PCDR0, 10, 6);
> clk[usb_div] = imx_clk_divider("usb_div", "spll", CCM_CSCR, 28, 3);
> clk[cpu_sel] = imx_clk_mux("cpu_sel", CCM_CSCR, 15, 1, cpu_sel_clks, ARRAY_SIZE(cpu_sel_clks));
> clk[clko_sel] = imx_clk_mux("clko_sel", CCM_CCSR, 0, 5, clko_sel_clks, ARRAY_SIZE(clko_sel_clks));
> @@ -121,7 +121,7 @@ int __init mx27_clocks_init(unsigned long fref)
> clk[ssi1_sel] = imx_clk_mux("ssi1_sel", CCM_CSCR, 22, 1, ssi_sel_clks, ARRAY_SIZE(ssi_sel_clks));
> clk[ssi2_sel] = imx_clk_mux("ssi2_sel", CCM_CSCR, 23, 1, ssi_sel_clks, ARRAY_SIZE(ssi_sel_clks));
> clk[ssi1_div] = imx_clk_divider("ssi1_div", "ssi1_sel", CCM_PCDR0, 16, 6);
> - clk[ssi2_div] = imx_clk_divider("ssi2_div", "ssi2_sel", CCM_PCDR0, 26, 3);
> + clk[ssi2_div] = imx_clk_divider("ssi2_div", "ssi2_sel", CCM_PCDR0, 26, 6);
> clk[clko_en] = imx_clk_gate("clko_en", "clko_div", CCM_PCCR0, 0);
> clk[ssi2_ipg_gate] = imx_clk_gate("ssi2_ipg_gate", "ipg", CCM_PCCR0, 0);
> clk[ssi1_ipg_gate] = imx_clk_gate("ssi1_ipg_gate", "ipg", CCM_PCCR0, 1);
> --
> 1.7.9.5
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Single zImage and A15/LPAE
From: Arnd Bergmann @ 2012-10-09 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1210082201470.16518@xanadu.home>
On Monday 08 October 2012 22:18:24 Nicolas Pitre wrote:
> On Mon, 8 Oct 2012, Stephen Warren wrote:
>
> > I'm curious what the single-zImage story is for Cortex A15 CPUs with
> > LPAE extensions; IIRC, LPAE entails a different page table format and so
> > isn't going to co-exist in the same zImage as non-LPAE
>
> LPAE vs non LPAE is an even more invasive change than ARMv6+ vs pre
> ARMv6 support. So no, I don't think we'll ever support LPAE and non
> LPAE configs in the same kernel binary.
>
> > (although doesn't x86 support that now; I though separate
> > LPAE/non-LPAE kernels went away there?)
>
> I don't think so. At least Ubuntu apparently still carries a PAE and
> non PAE kernel packages. Fedora doesn't, probably because they decided
> not to support non PAE capable machines anymore. We certainly cannot
> make this choice on ARM yet.
Fedora 18 still has both PAE and non-PAE kernels. I would really hope
they could give up the PAE version in favor of a 64 bit kernel in
the 32 bit distro, but it seems none of the big distros trust the
compat code enough yet. On x86, the number of 32 bit machines still
running with more than 3GB of RAM installed should be very marginal
now, most people running the PAE kernel actually have 64 bit capable
CPUs and have some legacy 32 bit applications that are easier to
run with a 32 bit user space.
Maybe we get to the same point on ARM in some 10 years, but for
the forseeable future, Cortex-a15 machines with lots of RAM will
be very real and we need to have separate kernels for those.
Arnd
^ permalink raw reply
* [PATCH] video: imxfb: Do not crash on reboot
From: Uwe Kleine-König @ 2012-10-09 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349703336-8105-1-git-send-email-fabio.estevam@freescale.com>
On Mon, Oct 08, 2012 at 10:35:36AM -0300, Fabio Estevam wrote:
> Issuing a "reboot" command after the LCD times out causes the following
> warnings:
>
> Requesting system reboot
> ------------[ cut here ]------------
> WARNING: at drivers/clk/clk.c:471 clk_disable+0x24/0x50()
> Modules linked in:
> [<c001ad90>] (unwind_backtrace+0x0/0xf4) from [<c0025aac>] (warn_slowpath_common+0x48/0x60)
> [<c0025aac>] (warn_slowpath_common+0x48/0x60) from [<c0025ae0>] (warn_slowpath_null+0x1c/0x24)
> [<c0025ae0>] (warn_slowpath_null+0x1c/0x24) from [<c03960a0>] (clk_disable+0x24/0x50)
> [<c03960a0>] (clk_disable+0x24/0x50) from [<c02695a0>] (imxfb_disable_controller+0x48/0x7c)
> [<c02695a0>] (imxfb_disable_controller+0x48/0x7c) from [<c029d838>] (platform_drv_shutdown+0x18/0x1c)
> [<c029d838>] (platform_drv_shutdown+0x18/0x1c) from [<c02990fc>] (device_shutdown+0x48/0x14c)
> [<c02990fc>] (device_shutdown+0x48/0x14c) from [<c003d09c>] (kernel_restart_prepare+0x2c/0x3c)
> [<c003d09c>] (kernel_restart_prepare+0x2c/0x3c) from [<c003d0e4>] (kernel_restart+0xc/0x48)
> [<c003d0e4>] (kernel_restart+0xc/0x48) from [<c003d1e8>] (sys_reboot+0xc0/0x1bc)
> [<c003d1e8>] (sys_reboot+0xc0/0x1bc) from [<c0014ca0>] (ret_fast_syscall+0x0/0x2c)
> ---[ end trace da6b502ca79c854f ]---
> ------------[ cut here ]------------
> WARNING: at drivers/clk/clk.c:380 clk_unprepare+0x1c/0x2c()
> Modules linked in:
> [<c001ad90>] (unwind_backtrace+0x0/0xf4) from [<c0025aac>] (warn_slowpath_common+0x48/0x60)
> [<c0025aac>] (warn_slowpath_common+0x48/0x60) from [<c0025ae0>] (warn_slowpath_null+0x1c/0x24)
> [<c0025ae0>] (warn_slowpath_null+0x1c/0x24) from [<c0396338>] (clk_unprepare+0x1c/0x2c)
> [<c0396338>] (clk_unprepare+0x1c/0x2c) from [<c02695a8>] (imxfb_disable_controller+0x50/0x7c)
> [<c02695a8>] (imxfb_disable_controller+0x50/0x7c) from [<c029d838>] (platform_drv_shutdown+0x18/0x1c)
> [<c029d838>] (platform_drv_shutdown+0x18/0x1c) from [<c02990fc>] (device_shutdown+0x48/0x14c)
> [<c02990fc>] (device_shutdown+0x48/0x14c) from [<c003d09c>] (kernel_restart_prepare+0x2c/0x3c)
> [<c003d09c>] (kernel_restart_prepare+0x2c/0x3c) from [<c003d0e4>] (kernel_restart+0xc/0x48)
> [<c003d0e4>] (kernel_restart+0xc/0x48) from [<c003d1e8>] (sys_reboot+0xc0/0x1bc)
> [<c003d1e8>] (sys_reboot+0xc0/0x1bc) from [<c0014ca0>] (ret_fast_syscall+0x0/0x2c)
> ---[ end trace da6b502ca79c8550 ]---
> ------------[ cut here ]------------
>
> This happens because "reboot" triggers imxfb_shutdown(), which calls
> imxfb_disable_controller with the clocks already disabled.
>
> To prevent this, add a clock enabled status so that we can check if the clocks
> are enabled before disabling them.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> drivers/video/imxfb.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index f3363b2..6acf98a 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -134,6 +134,7 @@ struct imxfb_info {
> struct clk *clk_ipg;
> struct clk *clk_ahb;
> struct clk *clk_per;
> + int enabled;
I didn't really know the driver, but I wonder if the name "enabled" is a
tad too generic. Maybe better "clks_enabled"?
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [alsa-devel] [PATCH v2 1/2] ARM: imx: clk: Split SSI clock into 'ipg' and 'per'
From: Sascha Hauer @ 2012-10-09 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Beug=Db4_dW9ziNs-M=wUizrRSrDXMAXi0CXpUO1Nvzw@mail.gmail.com>
On Tue, Oct 09, 2012 at 01:21:10AM -0300, Fabio Estevam wrote:
> Sascha,
>
> On Mon, Oct 8, 2012 at 8:47 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > Hi Sascha,
> >
> > On Mon, Oct 8, 2012 at 6:44 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> >> I am not sure it's good to work around that issue in the ssi driver. We
> >> could also just enable the clock in the clk driver as it seems to be a
> >> ccm related issue.
> >
> > Yes, it would be better if we could fix this in clk-imx27 instead, but
> > I was not able to provide such fix yet.
>
> The ssi1_sel clock is defined as:
>
> clk[ssi1_sel] = imx_clk_mux("ssi1_sel", CCM_CSCR, 22, 1, ssi_sel_clks,
> ARRAY_SIZE(ssi_sel_clks));
>
> ,where ssi_sel_clks is:
> static const char *ssi_sel_clks[] = { "spll", "mpll", }
>
> ,which matches with the mx27 reference manual.
>
> How do we tell the clk api to select spll or mpll as the source for ssi_sel?
>
> I understand how to do this from register level, but not from the api.
In the clk driver you can do a clk_set_parent(clk[ssi1_sel], clk[mpll]);
I wonder what the parent setting has to do with this problem. Could you
come up with a minimum patch to clk-imx27.c which fixes the problem?
Then we can discuss afterwards how to integrate it properly (or not the
least dirty).
Right now the clk framework has been succesful in turning the clk mess
into a proper tree. There currently is no API to manipulate that tree
in a non painful way. That would be the next steps.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: pxa: Fix build error caused by sram.h rename
From: Mark Brown @ 2012-10-09 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vcenespj.fsf@octavius.laptop.org>
On Sat, Oct 06, 2012 at 07:38:16AM -0400, Chris Ball wrote:
> Commit 293b2da1b61 ("ARM: pxa: move platform_data definitions")
> renamed arch/arm/mach-mmp/include/mach/sram.h to
> include/linux/platform_data/dma-mmp_tdma.h, but didn't update
> mmp-pcm.c which uses the header. Fix the build error.
Applied, thanks.
^ permalink raw reply
* [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
From: Jarkko Nikula @ 2012-10-09 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008173557.10603.18539.stgit@muffinssi>
On Mon, 08 Oct 2012 10:35:57 -0700
Tony Lindgren <tony@atomide.com> wrote:
> - omap-dma.c and omap-pcm.c can test the arch locally as
> omap1 and omap2 cannot be compiled together because of
> conflicting compiler flags
...
> sound/soc/omap/omap-pcm.c | 9 +++++++--
Build tested above for omap1 and omap2+.
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
^ permalink raw reply
* [PATCH] ARM: sort select statements alphanumerically
From: Barry Song @ 2012-10-09 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1TKX8k-0006QP-M5@rmk-PC.arm.linux.org.uk>
2012/10/7 Russell King <rmk+kernel@arm.linux.org.uk>:
> As suggested by Andrew Morton:
>
> This is a pet peeve of mine. Any time there's a long list of items
> (header file inclusions, kconfig entries, array initalisers, etc) and
> someone wants to add a new item, they *always* go and stick it at the
> end of the list.
> ...
> Guys, don't do this. Either put the new item into a randomly-chosen
> position or, probably better, alphanumerically sort the list.
>
> For this reason it looks like approximately 0% of the patchset will
> apply, sorry.
>
> lets sort all our select statements alphanumerically. This commit was
> created by the following script:
>
> #!/usr/bin/perl
> while (<>) {
> while (/\\\s*$/) {
> $_ .= <>;
> }
> undef %selects if /^\s*config\s+/;
> if (/^\s+select\s+(\w+).*/) {
> if (defined($selects{$1})) {
> if ($selects{$1} eq $_) {
> print STDERR "Warning: removing duplicated $1 entry\n";
> } else {
> print STDERR "Error: $1 differently selected\n".
> "\tOld: $selects{$1}\n".
> "\tNew: $_\n";
> exit 1;
> }
> }
> $selects{$1} = $_;
> next;
> }
> if (%selects and (/^\s*$/ or /^\s+help/)) {
> foreach $k (sort (keys %selects)) {
> print "$selects{$k}";
> }
> undef %selects;
> }
> print;
> }
> if (%selects) {
> foreach $k (sort (keys %selects)) {
> print "$selects{$k}";
> }
> }
>
> It found two duplicates:
>
> Warning: removing duplicated S5P_SETUP_MIPIPHY entry
> Warning: removing duplicated HARDIRQS_SW_RESEND entry
>
> and they are identical duplicates, hence the shrinkage in the diffstat
> of two lines.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Changes in CSR prima2 arch look fine,
Acked-by: Barry Song <Baohua.Song@csr.com>
BTW, i have a bundle of patches coming for new Marco platform which
will also change the Kconfig.
> ---
> This commit is likely to change as we get closer to the end of the merge
> window, as other changes get merged into Linus' tree. I will be refreshing
> this from time to time, and keeping it out of linux-next, as it will cause
> more pain than its worth to put it into linux-next.
>
> Anyone who wants to give this a review to check that it's correct are welcome,
> but I don't think it would be appropriate to collect attributation tags for
> it, as this won't be the final patch.
>
> This patch is intentionally broken to prevent Linus from applying it - this
> is information only!
>
> Anyone who wants to apply it can do so by first running this patch through:
>
> sed 's/^-- /@@ /'
>
> arch/arm/Kconfig | 399 ++++++++++++++++++-------------------
> arch/arm/common/Kconfig | 4 +-
> arch/arm/mach-at91/Kconfig | 26 ++--
> arch/arm/mach-clps711x/Kconfig | 4 +-
> arch/arm/mach-davinci/Kconfig | 16 +-
> arch/arm/mach-exynos/Kconfig | 181 +++++++++---------
> arch/arm/mach-footbridge/Kconfig | 8 +-
> arch/arm/mach-h720x/Kconfig | 2 +-
> arch/arm/mach-imx/Kconfig | 120 ++++++------
> arch/arm/mach-ixp4xx/Kconfig | 2 +-
> arch/arm/mach-mmp/Kconfig | 6 +-
> arch/arm/mach-msm/Kconfig | 28 ++--
> arch/arm/mach-nomadik/Kconfig | 4 +-
> arch/arm/mach-omap1/Kconfig | 8 +-
> arch/arm/mach-omap2/Kconfig | 68 +++---
> arch/arm/mach-prima2/Kconfig | 2 +-
-barry
^ permalink raw reply
* [PATCH] ARM: tegra: cpuidle: replace LP3 with ARM_CPUIDLE_WFI_STATE
From: Joseph Lo @ 2012-10-09 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5072FD25.2020600@wwwdotorg.org>
Hi Stephen,
Thanks for your review.
On Tue, 2012-10-09 at 00:19 +0800, Stephen Warren wrote:
> On 10/08/2012 04:24 AM, Joseph Lo wrote:
> > The Tegra CPU idle LP3 state is doing ARM WFI only. So it's same with
> > the common ARM_CPUIDLE_WFI_STATE. Using it to replace LP3 now.
>
> Hmm. This changes the exit_latency/target_residency fields of the
> cpuidle state definition from 10 to 1, and also replaces
> tegra_idle_enter_lp3() with just a dsb/wfi as far as I can tell. What
> are the implications of removing the irq/fiq_disable/enable and
> ktim-related code? It might be worth explaining why this change is valid
> in the commit description.
> --
There were some histories about the latency. The legacy LP3 mode called
to "tegra_cpu_wfi". This func was been removed. We called to
"cpu_do_idle" right now. In the old "tegra_cpu_wfi", we did back up the
current flow controller register and set up flow controller to CPU_WFE
state. It did wait for CPU running to WFI and clock gate it externally.
We need a time duration to make flow controller to do that.
When any event or interrupt been triggered, it resume the CPU clock. And
CPU runs after WFI and restore the flow controller. We found this may
hurt performance, so we drop that. The latency is not true anymore.
Now we just using WFI to enter low-power CPU standby state where most
clocks gated.
About the missing irq/fiq disable/enable call, we enable the
"en_core_tk_irqen" in this patch. That means we enable time keeping and
irq enabling in the core cpuidle code. So the cpuidle enter code will
use the "cpuidle_wrap_enter" in "drivers/cpuidle/cpuidle.c".
After merging these concepts, I think we can use the common
ARM_CPUIDLE_WFI_STATE to replace the current LP3 code.
Thanks,
Joseph
^ 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