RE: [PATCH RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, January 25, 2011 10:28 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc * Ghorai, Sukumar s-gho...@ti.com [110122 09:53]: I think I've commented on this before, but why don't you make gpmc_init a subsys_initcall? There should be no reason to call this earlier. If something does not work because of that, then that issue must be fixed. [Ghorai] You suggested the same in previous v5 and v6; and I mentioned the issues [1] that - nand_init()called before subsys_initcall(gpmc_init); Let me know if I am missing anything again. There should not be any need to call nand_init early either. We want to initialize as much as possible late so we have proper console error messages. [Ghorai] thanks... changed to postcore_initcall() and it solved the problem I mentioned earlier. And it simplifies the overall modification in different board files. postcore_initcall(gpmc_init); Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] ASoC: DMIC: Adding the OMAP DMIC driver
snip
+
+static int omap_dmic_set_dai_sysclk(struct snd_soc_dai *dai,
+ int clk_id, unsigned int freq,
+ int dir)
+{
+ struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
+ struct clk *dmic_clk, *parent_clk;
+ int ret = 0;
+
+ dmic_clk = clk_get(NULL, dmic_fck);
It is preferred to use device pointer. instead of NULL.
(Applicable elsewhere)
+ if (IS_ERR(dmic_clk))
+ return -ENODEV;
+
+ switch (clk_id) {
+ case OMAP_DMIC_SYSCLK_PAD_CLKS:
+ parent_clk = clk_get(NULL, pad_clks_ck);
+ if (IS_ERR(parent_clk)) {
+ ret = -ENODEV;
+ goto err_par;
+ }
+ break;
+ case OMAP_DMIC_SYSCLK_SLIMBLUS_CLKS:
+ parent_clk = clk_get(NULL, slimbus_clk);
+ if (IS_ERR(parent_clk)) {
+ ret = -ENODEV;
+ goto err_par;
+ }
+ break;
+ case OMAP_DMIC_SYSCLK_SYNC_MUX_CLKS:
+ parent_clk = clk_get(NULL, dmic_sync_mux_ck);
+ if (IS_ERR(parent_clk)) {
+ ret = -ENODEV;
+ goto err_par;
+ }
+ break;
+ default:
+ dev_err(dai-dev, clk_id not supported %d\n, clk_id);
+ ret = -EINVAL;
+ goto err_par;
+ }
+
+ if (dmic-sysclk != clk_id) {
+ /* reparent not allowed if a stream is ongoing */
+ if (dmic-active 1) {
+ ret = -EBUSY;
+ goto err_busy;
+ }
+
+ /* disable clock while reparenting */
+ if (dmic-active == 1)
+ pm_runtime_put_sync(dmic-dev);
+
+ ret = clk_set_parent(dmic_clk, parent_clk);
+
+ if (dmic-active == 1)
+ pm_runtime_get_sync(dmic-dev);
+
+ dmic-sysclk = clk_id;
+ }
+
+ dmic-clk_freq = clk_get_rate(dmic_clk);
+
+err_busy:
+ clk_put(parent_clk);
+err_par:
+ clk_put(dmic_clk);
+
+ return ret;
+}
+
snip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Thu, 2011-01-27 at 18:59 +, Russell King - ARM Linux wrote: On Thu, Jan 27, 2011 at 06:14:56PM +, Catalin Marinas wrote: On 17 January 2011 19:24, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. (sorry, I'm well behind list messages, didn't reply earlier) Does it mean that we get domains enabled even for ARMv7 when ARMv6 is built in the same kernel? The side effect is that user read-only addresses are writable by the kernel and SWP emulation no longer works. It means that a kernel with ARMv6 through to ARMv7 will have CPU domains enabled. So maybe we want: config CPU_32v6 select CPU_USE_DOMAINS if !CPU_V6K MMU instead? Does this mean that we could still configure a kernel to run on CPU_V6 with domains disabled? The vectors page becomes read-only and setting the TLS would fail. My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. We could change early_trap_init() to always use the vectors_page rather than the high mapping and determine at run-time (patch the code) whether set_pte_ext sets R/W kernel permissions for RO user pages. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: Does this mean that we could still configure a kernel to run on CPU_V6 with domains disabled? The vectors page becomes read-only and setting the TLS would fail. Yes it will, so that's not acceptable either. My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We could change early_trap_init() to always use the vectors_page rather than the high mapping and determine at run-time (patch the code) whether set_pte_ext sets R/W kernel permissions for RO user pages. With aliasing caches that becomes much more difficult. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 0/7] nand prefetch-irq support and ecc layout chanage
The following set of patches applies on linux-2.6. The main motivations behind this patch series are - 1. support NAND I/O in irq mode. 2. support of different ECC schema. 3. also add support ecc layout as like in romcode ecc layout, but not enabled v9: gpmc_init() changed to postcore_initcall(gpmc_init); v8: free_irq() added; used timeout for while(tight loop) And resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41614.html v7: NAND type (x16 or x8) is board specific and not omap specific; this passed form board file. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41469.html v6: configurable transfer type from board file; #define irq number used for nand-irq http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39397.html v5: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35860.html This address the input as to support the irq_chained in GPMC. And resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35848.html v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34882.html and resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (7): omap3630: nand: fix device size to work in polled mode omap3: nand: configurable transfer type per board omap: gpmc: enable irq mode in gpmc omap3: nand: prefetch in irq mode support omap3: nand: configurable fifo threshold to gain the throughput omap3: nand: ecc layout select from board file omap3: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-3630sdp.c|3 +- arch/arm/mach-omap2/board-flash.c | 13 +- arch/arm/mach-omap2/board-flash.h |4 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-zoom.c |5 +- arch/arm/mach-omap2/gpmc-nand.c|7 +- arch/arm/mach-omap2/gpmc.c | 56 +- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h | 18 ++- arch/arm/plat-omap/include/plat/irqs.h |9 +- arch/arm/plat-omap/include/plat/nand.h | 11 + drivers/mtd/nand/Kconfig | 17 -- drivers/mtd/nand/omap2.c | 367 14 files changed, 386 insertions(+), 130 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 1/7] omap3630: nand: fix device size to work in polled mode
zoom3 and 3630-sdp having the x16 nand device.
This patch configure gpmc as x16 and select the currect function in driver
for polled mode (without prefetch enable) transfer.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-3630sdp.c |3 ++-
arch/arm/mach-omap2/board-flash.c | 10 ++
arch/arm/mach-omap2/board-flash.h |4 ++--
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-zoom.c|5 +++--
arch/arm/mach-omap2/gpmc-nand.c |7 +--
drivers/mtd/nand/omap2.c|2 +-
8 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index d4e41ef..8fb5f43 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -813,7 +813,7 @@ static void __init omap_3430sdp_init(void)
omap_serial_init();
usb_musb_init(musb_board_data);
board_smc91x_init();
- board_flash_init(sdp_flash_partitions, chip_sel_3430);
+ board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 6264564..b4ca7fc 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -11,6 +11,7 @@
#include linux/platform_device.h
#include linux/input.h
#include linux/gpio.h
+#include linux/mtd/nand.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -209,7 +210,7 @@ static void __init omap_sdp_init(void)
zoom_peripherals_init();
zoom_display_init();
board_smc91x_init();
- board_flash_init(sdp_flash_partitions, chip_sel_sdp);
+ board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
}
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index fd38c05..f6b7253 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -139,11 +139,13 @@ static struct omap_nand_platform_data board_nand_data = {
};
void
-__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs)
+__init board_nand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs, int nand_type)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
- board_nand_data.nr_parts= nr_parts;
+ board_nand_data.nr_parts= nr_parts;
+ board_nand_data.devsize = nand_type;
gpmc_nand_init(board_nand_data);
}
@@ -194,7 +196,7 @@ unmap:
* @return - void.
*/
void board_flash_init(struct flash_partitions partition_info[],
- char chip_sel_board[][GPMC_CS_NUM])
+ char chip_sel_board[][GPMC_CS_NUM], int nand_type)
{
u8 cs = 0;
u8 norcs = GPMC_CS_NUM + 1;
@@ -250,5 +252,5 @@ void board_flash_init(struct flash_partitions
partition_info[],
in GPMC\n);
else
board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs);
+ partition_info[2].nr_parts, nandcs, nand_type);
}
diff --git a/arch/arm/mach-omap2/board-flash.h
b/arch/arm/mach-omap2/board-flash.h
index 69befe0..c240a3f 100644
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -25,6 +25,6 @@ struct flash_partitions {
};
extern void board_flash_init(struct flash_partitions [],
- char chip_sel[][GPMC_CS_NUM]);
+ char chip_sel[][GPMC_CS_NUM], int nand_type);
extern void board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs);
+ u8 nr_parts, u8 cs, int nand_type);
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index e5dc748..d986d32 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -434,7 +434,7 @@ static void __init omap_ldp_init(void)
omap_serial_init();
usb_musb_init(musb_board_data);
board_nand_init(ldp_nand_partitions,
- ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS);
+ ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS, 0);
omap2_hsmmc_init(mmc);
/* link regulators to MMC adapters */
diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
index e26754c..0242611 100644
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -16,6 +16,7 @@
#include linux/input.h
#include linux/gpio.h
#include
[PATCH v9 2/7] omap3: nand: configurable transfer type per board
nand transfer type (sDMA, Polled, prefetch) can be select from board file,
enabling all transfer type in driver, by default.
this helps in multi-omap build and to select different transfer type for
different board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |7 +++
drivers/mtd/nand/Kconfig | 17 --
drivers/mtd/nand/omap2.c | 94
3 files changed, 41 insertions(+), 77 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..78c0bdb 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -10,6 +10,12 @@
#include linux/mtd/partitions.h
+enum nand_io {
+ NAND_OMAP_PREFETCH_POLLED = 0, /* prefetch polled mode, default */
+ NAND_OMAP_POLLED, /* polled mode, without prefetch */
+ NAND_OMAP_PREFETCH_DMA /* prefetch enabled sDMA mode */
+};
+
struct omap_nand_platform_data {
unsigned intoptions;
int cs;
@@ -20,6 +26,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index c895922..178e200 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -106,23 +106,6 @@ config MTD_NAND_OMAP2
help
Support for NAND flash on Texas Instruments OMAP2 and OMAP3
platforms.
-config MTD_NAND_OMAP_PREFETCH
- bool GPMC prefetch support for NAND Flash device
- depends on MTD_NAND_OMAP2
- default y
- help
-The NAND device can be accessed for Read/Write using GPMC PREFETCH
engine
-to improve the performance.
-
-config MTD_NAND_OMAP_PREFETCH_DMA
- depends on MTD_NAND_OMAP_PREFETCH
- bool DMA mode
- default n
- help
-The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
-or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
-
config MTD_NAND_IDS
tristate
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7c04cd6..60bac8e 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -96,27 +96,6 @@
static const char *part_probes[] = { cmdlinepart, NULL };
#endif
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
-static int use_prefetch = 1;
-
-/* modprobe ... use_prefetch=0 etc */
-module_param(use_prefetch, bool, 0);
-MODULE_PARM_DESC(use_prefetch, enable/disable use of PREFETCH);
-
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
-static int use_dma = 1;
-
-/* modprobe ... use_dma=0 etc */
-module_param(use_dma, bool, 0);
-MODULE_PARM_DESC(use_dma, enable/disable use of DMA);
-#else
-static const int use_dma;
-#endif
-#else
-const int use_prefetch;
-static const int use_dma;
-#endif
-
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -324,7 +303,6 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
/*
* omap_nand_dma_cb: callback on the completion of dma transfer
* @lch: logical channel
@@ -426,14 +404,6 @@ out_copy:
: omap_write_buf8(mtd, (u_char *) addr, len);
return 0;
}
-#else
-static void omap_nand_dma_cb(int lch, u16 ch_status, void *data) {}
-static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
- unsigned int len, int is_write)
-{
- return 0;
-}
-#endif
/**
* omap_read_buf_dma_pref - read data from NAND controller into buffer
@@ -842,28 +812,13 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.chip_delay = 50;
}
- if (use_prefetch) {
-
+ switch (pdata-xfer_type) {
+ case NAND_OMAP_PREFETCH_POLLED:
info-nand.read_buf = omap_read_buf_pref;
info-nand.write_buf = omap_write_buf_pref;
- if (use_dma) {
- err = omap_request_dma(OMAP24XX_DMA_GPMC, NAND,
- omap_nand_dma_cb, info-comp, info-dma_ch);
- if (err 0) {
- info-dma_ch = -1;
- printk(KERN_WARNING DMA request failed.
-Non-dma data transfer mode\n);
- } else {
- omap_set_dma_dest_burst_mode(info-dma_ch,
- OMAP_DMA_DATA_BURST_16);
-
[PATCH v9 3/7] omap: gpmc: enable irq mode in gpmc
add support the irq mode in GPMC.
gpmc_init() function move after omap_init_irq() as it has dependecy on irq.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 45 +--
arch/arm/mach-omap2/io.c |2 -
arch/arm/plat-omap/include/plat/gpmc.h |5 +++-
arch/arm/plat-omap/include/plat/irqs.h |9 +-
4 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1b7b3e7..382dea8 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
*/
#undef DEBUG
+#include linux/irq.h
#include linux/kernel.h
#include linux/init.h
#include linux/err.h
@@ -22,6 +23,7 @@
#include linux/spinlock.h
#include linux/io.h
#include linux/module.h
+#include linux/interrupt.h
#include asm/mach-types.h
#include plat/gpmc.h
@@ -100,6 +102,8 @@ static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
+static irqreturn_t gpmc_handle_irq(int irq, void *dev);
+
static void gpmc_write_reg(int idx, u32 val)
{
__raw_writel(val, gpmc_base + idx);
@@ -497,6 +501,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
u32 regval = 0;
switch (cmd) {
+ case GPMC_ENABLE_IRQ:
+ gpmc_write_reg(GPMC_IRQENABLE, wval);
+ break;
+
case GPMC_SET_IRQ_STATUS:
gpmc_write_reg(GPMC_IRQSTATUS, wval);
break;
@@ -678,9 +686,10 @@ static void __init gpmc_mem_init(void)
}
}
-void __init gpmc_init(void)
+static int __init gpmc_init(void)
{
- u32 l;
+ u32 l, irq;
+ int cs, ret = -EINVAL;
char *ck = NULL;
if (cpu_is_omap24xx()) {
@@ -698,7 +707,7 @@ void __init gpmc_init(void)
}
if (WARN_ON(!ck))
- return;
+ return ret;
gpmc_l3_clk = clk_get(NULL, ck);
if (IS_ERR(gpmc_l3_clk)) {
@@ -723,6 +732,36 @@ void __init gpmc_init(void)
l |= (0x02 3) | (1 0);
gpmc_write_reg(GPMC_SYSCONFIG, l);
gpmc_mem_init();
+
+ /* initalize the irq_chained */
+ irq = OMAP_GPMC_IRQ_BASE;
+ for (cs = 0; cs GPMC_CS_NUM; cs++) {
+ set_irq_handler(irq, handle_simple_irq);
+ set_irq_flags(irq, IRQF_VALID);
+ irq++;
+ }
+
+ ret = request_irq(INT_34XX_GPMC_IRQ,
+ gpmc_handle_irq, IRQF_SHARED, gpmc, gpmc_base);
+ if (ret)
+ pr_err(gpmc: irq-%d could not claim: err %d\n,
+ INT_34XX_GPMC_IRQ, ret);
+ return ret;
+}
+postcore_initcall(gpmc_init);
+
+static irqreturn_t gpmc_handle_irq(int irq, void *dev)
+{
+ u8 cs;
+
+ if (irq != INT_34XX_GPMC_IRQ)
+ return IRQ_HANDLED;
+ /* check cs to invoke the irq */
+ cs = ((gpmc_read_reg(GPMC_PREFETCH_CONFIG1)) CS_NUM_SHIFT) 0x7;
+ if (OMAP_GPMC_IRQ_BASE+cs = OMAP_GPMC_IRQ_END)
+ generic_handle_irq(OMAP_GPMC_IRQ_BASE+cs);
+
+ return IRQ_HANDLED;
}
#ifdef CONFIG_ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e66687b..b60287c 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -30,7 +30,6 @@
#include plat/sram.h
#include plat/sdrc.h
-#include plat/gpmc.h
#include plat/serial.h
#include clock2xxx.h
@@ -408,7 +407,6 @@ void __init omap2_init_common_devices(struct
omap_sdrc_params *sdrc_cs0,
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
}
- gpmc_init();
omap_irq_base_init();
}
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 85ded59..9c060da 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -41,6 +41,8 @@
#define GPMC_NAND_ADDRESS 0x000b
#define GPMC_NAND_DATA 0x000c
+#define GPMC_ENABLE_IRQ0x000d
+
/* ECC commands */
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
@@ -78,6 +80,8 @@
#define WR_RD_PIN_MONITORING 0x0060
#define GPMC_PREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
#define GPMC_PREFETCH_STATUS_COUNT(val)(val 0x3fff)
+#define GPMC_IRQ_FIFOEVENTENABLE 0x01
+#define GPMC_IRQ_COUNT_EVENT 0x02
/*
* Note that all values in this struct are in nanoseconds except sync_clk
@@ -135,7 +139,6 @@ extern int gpmc_prefetch_enable(int cs, int dma_mode,
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
-extern void gpmc_init(void);
extern int gpmc_read_status(int cmd);
extern int gpmc_cs_configure(int cs, int cmd, int wval);
extern int gpmc_nand_read(int cs, int cmd);
diff --git
[PATCH v9 6/7] omap3: nand: ecc layout select from board file
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |1 +
arch/arm/plat-omap/include/plat/gpmc.h |6 ++
arch/arm/plat-omap/include/plat/nand.h |2 ++
drivers/mtd/nand/omap2.c | 26 +++---
4 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 1964509..a768198 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -148,6 +148,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index a243463..773351b 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -86,6 +86,12 @@
#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
#define PREFETCH_FIFOTHRESHOLD(val)((val) 8)
+enum omap_ecc {
+ /* 1-bit ecc: stored at end of spare area */
+ OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
+ OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
+};
+
/*
* Note that all values in this struct are in nanoseconds except sync_clk
* (which is in picoseconds), while the register values are in gpmc_fck cycles.
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index ae5e053..d86d1ec 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include plat/gpmc.h
#include linux/mtd/partitions.h
enum nand_io {
@@ -31,6 +32,7 @@ struct omap_nand_platform_data {
enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
+ enum omap_ecc ecc_opt;
};
/* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f1648fd..6d4a42e 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -626,8 +626,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
return 0;
}
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
/**
* gen_true_ecc - This function will generate true ECC value
* @ecc_buf: buffer to store ecc code
@@ -847,8 +845,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
gpmc_enable_hwecc(info-gpmc_cs, mode, dev_width, info-nand.ecc.size);
}
-#endif
-
/**
* omap_wait - wait until the command is done
* @mtd: MTD device structure
@@ -1038,17 +1034,17 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.verify_buf = omap_verify_buf;
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
- info-nand.ecc.bytes= 3;
- info-nand.ecc.size = 512;
- info-nand.ecc.calculate= omap_calculate_ecc;
- info-nand.ecc.hwctl= omap_enable_hwecc;
- info-nand.ecc.correct = omap_correct_data;
- info-nand.ecc.mode = NAND_ECC_HW;
-
-#else
- info-nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+ /* selsect the ecc type */
+ if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
+ info-nand.ecc.mode = NAND_ECC_SOFT;
+ else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) {
+ info-nand.ecc.bytes= 3;
+ info-nand.ecc.size = 512;
+ info-nand.ecc.calculate= omap_calculate_ecc;
+ info-nand.ecc.hwctl= omap_enable_hwecc;
+ info-nand.ecc.correct = omap_correct_data;
+ info-nand.ecc.mode = NAND_ECC_HW;
+ }
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 7/7] omap3: nand: making ecc layout as compatible with romcode ecc
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.
This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.
This patch does not enables this feature by default and need to pass from
board file to enable for any board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/plat-omap/include/plat/gpmc.h |2 +
drivers/mtd/nand/omap2.c | 37 +++-
2 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 773351b..12b3161 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -90,6 +90,8 @@ enum omap_ecc {
/* 1-bit ecc: stored at end of spare area */
OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
+ /* 1-bit ecc: stored at begining of spare area as romcode */
+ OMAP_ECC_HAMMING_CODE_HW_ROMCODE, /* gpmc method romcode layout */
};
/*
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 6d4a42e..4e33972 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -98,6 +98,20 @@
static const char *part_probes[] = { cmdlinepart, NULL };
#endif
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+ .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
+
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -914,6 +928,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_info *info;
struct omap_nand_platform_data *pdata;
int err;
+ int i, offset;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1037,7 +1052,8 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
/* selsect the ecc type */
if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
info-nand.ecc.mode = NAND_ECC_SOFT;
- else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) {
+ else if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) ||
+ (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE)) {
info-nand.ecc.bytes= 3;
info-nand.ecc.size = 512;
info-nand.ecc.calculate= omap_calculate_ecc;
@@ -1057,6 +1073,25 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
}
+ /* rom code layout */
+ if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE) {
+
+ if (info-nand.options NAND_BUSWIDTH_16)
+ offset = 2;
+ else {
+ offset = 1;
+ info-nand.badblock_pattern = bb_descrip_flashbased;
+ }
+ omap_oobinfo.eccbytes = 3 * (info-mtd.oobsize/16);
+ for (i = 0; i omap_oobinfo.eccbytes; i++)
+ omap_oobinfo.eccpos[i] = i+offset;
+
+ omap_oobinfo.oobfree-offset = offset + omap_oobinfo.eccbytes;
+ omap_oobinfo.oobfree-length = info-mtd.oobsize -
+ (offset + omap_oobinfo.eccbytes);
+
+ info-nand.ecc.layout = omap_oobinfo;
+ }
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 5/7] omap3: nand: configurable fifo threshold to gain the throughput
Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
drivers/mtd/nand/omap2.c | 22 ++
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 382dea8..6741743 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -60,7 +60,6 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
-#define PREFETCH_FIFOTHRESHOLD (0x40 8)
#define CS_NUM_SHIFT 24
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
@@ -606,15 +605,19 @@ EXPORT_SYMBOL(gpmc_nand_write);
/**
* gpmc_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
* @dma_mode: dma mode enable (1) or disable (0)
* @u32_count: number of bytes to be transferred
* @is_write: prefetch read(0) or write post(1) mode
*/
-int gpmc_prefetch_enable(int cs, int dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
{
- if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ pr_err(gpmc: fifo threshold is not supported\n);
+ return -1;
+ } else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
/* Set the amount of bytes to be prefetched */
gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
@@ -622,7 +625,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
* enable the engine. Set which cs is has requested for.
*/
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs CS_NUM_SHIFT) |
- PREFETCH_FIFOTHRESHOLD |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode DMA_MPU_MODE) |
(0x1 is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 9c060da..a243463 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)((val) 8)
+
/*
* Note that all values in this struct are in nanoseconds except sync_clk
* (which is in picoseconds), while the register values are in gpmc_fck cycles.
@@ -134,7 +137,7 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index fbe8414..f1648fd 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -244,7 +244,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -289,7 +290,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -345,8 +347,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
int ret;
unsigned long tim, limit;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a
[PATCH v9 4/7] omap3: nand: prefetch in irq mode support
This patch enable prefetch-irq mode for nand transfer(read, write)
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |2 +
arch/arm/plat-omap/include/plat/nand.h |4 +-
drivers/mtd/nand/omap2.c | 198 ++--
3 files changed, 194 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index f6b7253..1964509 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -16,6 +16,7 @@
#include linux/platform_device.h
#include linux/mtd/physmap.h
#include linux/io.h
+#include plat/irqs.h
#include plat/gpmc.h
#include plat/nand.h
@@ -147,6 +148,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
#else
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 78c0bdb..ae5e053 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -13,7 +13,8 @@
enum nand_io {
NAND_OMAP_PREFETCH_POLLED = 0, /* prefetch polled mode, default */
NAND_OMAP_POLLED, /* polled mode, without prefetch */
- NAND_OMAP_PREFETCH_DMA /* prefetch enabled sDMA mode */
+ NAND_OMAP_PREFETCH_DMA, /* prefetch enabled sDMA mode */
+ NAND_OMAP_PREFETCH_IRQ /* prefetch enabled irq mode */
};
struct omap_nand_platform_data {
@@ -26,6 +27,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ int gpmc_irq;
enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 60bac8e..fbe8414 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -11,6 +11,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/delay.h
+#include linux/interrupt.h
#include linux/jiffies.h
#include linux/sched.h
#include linux/mtd/mtd.h
@@ -24,6 +25,7 @@
#include plat/nand.h
#defineDRIVER_NAME omap2-nand
+#defineOMAP_NAND_TIMEOUT_MS5000
#define NAND_Ecc_P1e (1 0)
#define NAND_Ecc_P2e (1 1)
@@ -108,6 +110,13 @@ struct omap_nand_info {
unsigned long phys_base;
struct completion comp;
int dma_ch;
+ int gpmc_irq;
+ enum {
+ OMAP_NAND_IO_READ = 0, /* read */
+ OMAP_NAND_IO_WRITE, /* write */
+ } iomode;
+ u_char *buf;
+ int buf_len;
};
/**
@@ -267,9 +276,10 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
{
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
- uint32_t pref_count = 0, w_count = 0;
+ uint32_t w_count = 0;
int i = 0, ret = 0;
u16 *p;
+ unsigned long tim, limit;
/* take care of subpage writes */
if (len % 2 != 0) {
@@ -295,9 +305,12 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
iowrite16(*p++, info-nand.IO_ADDR_W);
}
/* wait for data to flushed-out before reset the prefetch */
- do {
- pref_count = gpmc_read_status(GPMC_PREFETCH_COUNT);
- } while (pref_count);
+ tim = 0;
+ limit = (loops_per_jiffy *
+ msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
+ while (gpmc_read_status(GPMC_PREFETCH_COUNT) (tim++ limit))
+ cpu_relax();
+
/* disable and stop the PFPW engine */
gpmc_prefetch_reset(info-gpmc_cs);
}
@@ -326,11 +339,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
{
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
- uint32_t prefetch_status = 0;
enum dma_data_direction dir = is_write ? DMA_TO_DEVICE :
DMA_FROM_DEVICE;
dma_addr_t dma_addr;
int ret;
+ unsigned long tim, limit;
/* The fifo depth is 64 bytes. We have a sync at each frame and frame
* length is 64 bytes.
@@ -376,7 +389,7 @@ static
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
From: Rajendra Nayak rna...@ti.com Enable all DPLL autoidle at boot on OMAP4. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c index e8cb32f..e5c59a0 100644 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void) clkdev_add(c-lk); clk_register(c-lk.clk); omap2_init_clk_clkdm(c-lk.clk); + if (c-lk.clk-dpll_data) + omap3_dpll_allow_idle(c-lk.clk); } recalculate_root_clocks(); -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] omap4: prcm: Few dpll, clockdomain and powerdomain updates
The series mainly contains dpll initialisation, CPUx clock domain offset fix, addiing INACTIVE power domain state and fixing logic flag for IVAHD and ABE power domains. The series is boot tested on OMAP4430 SDP. The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5: Linus Torvalds (1): Linux 2.6.38-rc2 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git omap4_prcm_misc Rajendra Nayak (3): omap4: dpll: Enable all DPLL autoidle at boot omap4: dpll: Add dpll api to control GATE_CTRL omap4: dpll: Enable auto gate control for all MX postdividers Santosh Shilimkar (3): omap4: powerdomain: Add supported INACTIVE power state omap4: prcm: Fix the CPUx clockdomain offsets omap4: powerdomain: Use intended PWRSTS_* flags instead of values arch/arm/mach-omap2/clock.h |3 ++ arch/arm/mach-omap2/clock44xx_data.c| 24 +++ arch/arm/mach-omap2/dpll3xxx.c | 43 +++ arch/arm/mach-omap2/powerdomain.h | 12 +++ arch/arm/mach-omap2/powerdomains44xx_data.c | 30 +- arch/arm/mach-omap2/prcm_mpu44xx.h |4 +- arch/arm/plat-omap/include/plat/clock.h |1 + 7 files changed, 100 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base. The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power domain control register Fix the same. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/prcm_mpu44xx.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h index 729a644..3300ff6 100644 --- a/arch/arm/mach-omap2/prcm_mpu44xx.h +++ b/arch/arm/mach-omap2/prcm_mpu44xx.h @@ -38,8 +38,8 @@ #define OMAP4430_PRCM_MPU_CPU1_INST0x0800 /* PRCM_MPU clockdomain register offsets (from instance start) */ -#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x -#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x +#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0018 +#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0018 /* -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
IVAHD and ABE power domain logic state is populated using directly
value instead of the capability flags.
Fix the same.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 96cde98..daee255 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -80,7 +80,7 @@ static struct powerdomain abe_44xx_pwrdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_RET_INA_ON,
- .pwrsts_logic_ret = PWRDM_POWER_OFF,
+ .pwrsts_logic_ret = PWRSTS_OFF,
.banks= 2,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_RET, /* aessmem */
@@ -227,7 +227,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_RET_INA_ON,
- .pwrsts_logic_ret = PWRDM_POWER_OFF,
+ .pwrsts_logic_ret = PWRSTS_OFF,
.banks= 4,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* hwa_mem */
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] omap4: dpll: Enable auto gate control for all MX postdividers
From: Rajendra Nayak rna...@ti.com
Enable auto/hw gate control for all dpll MX postdividers.
This requires the corresponding CLOCK_MX_IDLE_CONTROL to
be populated for all respective clock nodes.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e5c59a0..0f06dd2 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -329,6 +329,7 @@ static struct clk dpll_abe_m2x2_ck = {
.clksel = dpll_abe_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
.clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -396,6 +397,7 @@ static struct clk dpll_abe_m3x2_ck = {
.clksel = dpll_abe_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M3_DPLL_ABE,
.clksel_mask= OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -466,6 +468,7 @@ static struct clk dpll_core_m6x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M6_DPLL_CORE,
.clksel_mask= OMAP4430_HSDIVIDER_CLKOUT3_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -496,6 +499,7 @@ static struct clk dpll_core_m2_ck = {
.clksel = dpll_core_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_CORE,
.clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -516,6 +520,7 @@ static struct clk dpll_core_m5x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_CORE,
.clksel_mask= OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -582,6 +587,7 @@ static struct clk dpll_core_m4x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M4_DPLL_CORE,
.clksel_mask= OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -607,6 +613,7 @@ static struct clk dpll_abe_m2_ck = {
.clksel = dpll_abe_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
.clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -633,6 +640,7 @@ static struct clk dpll_core_m7x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M7_DPLL_CORE,
.clksel_mask= OMAP4430_HSDIVIDER_CLKOUT4_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -705,6 +713,7 @@ static struct clk dpll_iva_m4x2_ck = {
.clksel = dpll_iva_m4x2_div,
.clksel_reg = OMAP4430_CM_DIV_M4_DPLL_IVA,
.clksel_mask= OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -717,6 +726,7 @@ static struct clk dpll_iva_m5x2_ck = {
.clksel = dpll_iva_m4x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
.clksel_mask= OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
@@ -765,6 +775,7 @@ static struct clk dpll_mpu_m2_ck = {
.clksel = dpll_mpu_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_MPU,
.clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops= clkops_null,
.recalc = omap2_clksel_recalc,
[PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
On OMAP4, one can explicitly program INACTIVE as the power state of
the logic area inside the power domain. Techincally PD state programmed
to ON and if all the clock domains within the PD are idled, is equivalent
tp PD programmed to INACTIVE and all the clock domains within the PD are
idled. There won't be any power difference in above two.
Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
targeted state and also there is some additional latancy involved
with PD INACTIVE vs PD ON, it's better to support it as an explcit
PD state.
This patch adds the support to allow explicit PD INACTIVE
programming if supported.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.h | 12
arch/arm/mach-omap2/powerdomains44xx_data.c | 26 +-
2 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index c66431e..0e15ca7 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -46,6 +46,18 @@
#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 PWRDM_POWER_ON))
+#define PWRSTS_RET_INA_ON ((1 PWRDM_POWER_RET) | \
+(1 PWRDM_POWER_INACTIVE) | \
+(1 PWRDM_POWER_ON))
+
+#define PWRSTS_OFF_INA_ON ((1 PWRDM_POWER_OFF) | \
+(1 PWRDM_POWER_INACTIVE) | \
+(1 PWRDM_POWER_ON))
+
+#define PWRSTS_OFF_RET_INA_ON ((1 PWRDM_POWER_OFF) | \
+(1 PWRDM_POWER_RET) | \
+(1 PWRDM_POWER_INACTIVE) | \
+(1 PWRDM_POWER_ON))
/* Powerdomain flags */
#define PWRDM_HAS_HDWR_SAR (1 0) /* hardware save-and-restore support */
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 26d7641..96cde98 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_RET_ON,
+ .pwrsts = PWRSTS_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 5,
.pwrsts_mem_ret = {
@@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_GFX_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_ON,
+ .pwrsts = PWRSTS_OFF_INA_ON,
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* gfx_mem */
@@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_ABE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRDM_POWER_OFF,
.banks= 2,
.pwrsts_mem_ret = {
@@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_DSS_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF,
.banks= 1,
.pwrsts_mem_ret = {
@@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_TESLA_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 3,
.pwrsts_mem_ret = {
@@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRCM_MPU_CPU0_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
.pwrsts_mem_ret = {
@@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRCM_MPU_CPU1_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts
[PATCH 5/6] omap4: dpll: Add dpll api to control GATE_CTRL
From: Rajendra Nayak rna...@ti.com
On OMAP4, the dpll post divider outputs (MX outputs)
provide a way to allow/deny autoidle.
Allowing autoidle would mean that the hw would autogate
this clock when there is no dependency for it.
Denying idle would mean that this clock output will be
forced to stay enabled.
Add dpll api's to read/allow/deny idle control.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock.h |3 ++
arch/arm/mach-omap2/dpll3xxx.c | 43 +++
arch/arm/plat-omap/include/plat/clock.h |1 +
3 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 896584e..19617f0 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -65,6 +65,9 @@ u32 omap3_dpll_autoidle_read(struct clk *clk);
int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate);
int omap3_noncore_dpll_enable(struct clk *clk);
void omap3_noncore_dpll_disable(struct clk *clk);
+int omap4_dpllmx_gatectrl_read(struct clk *clk);
+void omap4_dpllmx_allow_gatectrl(struct clk *clk);
+void omap4_dpllmx_deny_gatectrl(struct clk *clk);
#ifdef CONFIG_OMAP_RESET_CLOCKS
void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f77022b..4ce06d5 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,11 +34,14 @@
#include clock.h
#include cm2xxx_3xxx.h
#include cm-regbits-34xx.h
+#include cm-regbits-44xx.h
/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
#define DPLL_AUTOIDLE_DISABLE 0x0
#define DPLL_AUTOIDLE_LOW_POWER_STOP 0x1
+#define DPLL_GATECTRL_DISABLE 0x0
+
#define MAX_DPLL_WAIT_TRIES100
/* Private functions */
@@ -612,3 +615,43 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
rate = clk-parent-rate * 2;
return rate;
}
+
+int omap4_dpllmx_gatectrl_read(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk-flags CLOCK_MX_IDLE_CONTROL) || !clk-clksel_reg)
+ return -EINVAL;
+
+ v = __raw_readl(clk-clksel_reg);
+ v = OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v = __ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+
+ return v;
+}
+
+void omap4_dpllmx_allow_gatectrl(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk-flags CLOCK_MX_IDLE_CONTROL) || !clk-clksel_reg)
+ return;
+
+ v = __raw_readl(clk-clksel_reg);
+ v = ~OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v |= __ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+ __raw_writel(v, clk-clksel_reg);
+}
+
+void omap4_dpllmx_deny_gatectrl(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk-flags CLOCK_MX_IDLE_CONTROL) || !clk-clksel_reg)
+ return;
+
+ v = __raw_readl(clk-clksel_reg);
+ v = ~OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v |= DPLL_GATECTRL_DISABLE
__ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+ __raw_writel(v, clk-clksel_reg);
+}
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 8eb0ada..2937f5d 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -177,6 +177,7 @@ struct dpll_data {
#define CLOCK_NO_IDLE_PARENT (1 2)
#define ENABLE_ON_INIT (1 3)/* Enable upon framework init */
#define INVERT_ENABLE (1 4)/* 0 enables, 1 disables */
+#define CLOCK_MX_IDLE_CONTROL (1 5)
/**
* struct clk - OMAP struct clk
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). What about a kernel covering ARMv6 too? Writing to an aliased mapping of the vectors page (as required for TLS emulation) will require additional cache maintainence on every context switch. 1. SWP emulation requires domain support turned off 2. We can't turn domains off without creating a vectors page alias 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches without additional cache maintainence. I don't think overloading the context switch with yet more conditionals based on yet more TLS combinations is a practical solution. So, ARMv6 TLS emulation, and SWP emulation are incompatible with each other. So either we don't have the SWP instruction at all on ARMv6+, or we have it enabled in hardware, or we don't and use the emulation where possible. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: hwmod: Do not expect an entry in clkdev to add alias for opt_clks
The _add_optional_clock_alias function expects an entry
already existing in the clkdev table in the form of
dev-id=NULL, con-id=role which might not be the case
always.
Instead, just check if an entry already exists in clkdev
in the dev-id=dev_name, con-id=role form, else go ahead
and add one.
Remove any assumption of an entry already existing in clkdev
table in any form.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/plat-omap/omap_device.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 57adb27..80d4f35 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -83,9 +83,11 @@
#include linux/err.h
#include linux/io.h
#include linux/clk.h
+#include linux/clkdev.h
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/clock.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -244,7 +246,7 @@ static inline struct omap_device *_find_by_pdev(struct
platform_device *pdev)
*
* For every optional clock present per hwmod per omap_device, this function
* adds an entry in the clocks list of the form dev-id=dev_name, con-id=role
- * if an entry is already present in it with the form dev-id=NULL,
con-id=role
+ * if it does not exist already.
*
* The function is called from inside omap_device_build_ss(), after
* omap_device_register.
@@ -258,21 +260,32 @@ static void _add_optional_clock_alias(struct omap_device
*od,
struct omap_hwmod *oh)
{
int i;
+ struct clk_lookup *l;
+ struct omap_hwmod_opt_clk *oc;
for (i = 0; i oh-opt_clks_cnt; i++) {
- struct omap_hwmod_opt_clk *oc;
- int r;
+ struct clk *r;
oc = oh-opt_clks[i];
if (!oc-_clk)
continue;
- r = clk_add_alias(oc-role, dev_name(od-pdev.dev),
- (char *)oc-clk, od-pdev.dev);
- if (r)
+ r = clk_get_sys(dev_name(od-pdev.dev), oc-role);
+ if (!IS_ERR(r))
+ continue; /* clkdev entry exists */
+
+ r = omap_clk_get_by_name((char *)oc-clk);
+ if (IS_ERR(r)) {
pr_err(omap_device: %s: clk_add_alias for %s failed\n,
dev_name(od-pdev.dev), oc-role);
+ continue;
+ }
+
+ l = clkdev_alloc(r, oc-role, dev_name(od-pdev.dev));
+ if (!l)
+ return;
+ clkdev_add(l);
}
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 00/18] OMAP2,3: hwmod DSS Adaptation
On Tue, 2011-01-25 at 09:03 -0800, ext Tony Lindgren wrote: * Kevin Hilman khil...@ti.com [110124 13:56]: Sumit Semwal sumit.sem...@ti.com writes: v10 of the patch series corrects return-error handling from platform_request_irq() based on comments from Sergei Shtylyov and Russell King. [https://patchwork.kernel.org/patch/497911/] Tony, Assuming Tomi is OK with this series, I think these are ready to go into omap-testing for some broader testing. I can merge in Tomi's branch for testing once Tomi is happy with them. I've applied the patch set to my tree: git://gitorious.org/linux-omap-dss2/linux.git master It compiles, but due to this being my last day in Nokia, I don't have equipment to test it. It's also missing my signed-offs. I haven't been able to review the latest versions of the patch set, so these patches may not be the final versions. However, everything looked pretty good a few versions ago, so I don't expect any bigger changes. It's up to Tony if he wants to merge the branch, even if it may not be the very final version. I will get back to these patches when my situation clears up, which may take a bit over a week or so. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, 2011-01-28 at 11:06 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). What about a kernel covering ARMv6 too? Writing to an aliased mapping of the vectors page (as required for TLS emulation) will require additional cache maintainence on every context switch. With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. So you may have people taking an Ubuntu filesystem (v7 only) and a pre-built OMAP image with TLS emulation even on Cortex-A8 and things won't work as expected. On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO and use the TLS register. The only other place where this matters on ARMv7 is early_trap_init() but it's easily fixable on this architecture. 1. SWP emulation requires domain support turned off Not necessarily - it requires RO user pages to be kernel RO (though this feature came with the domains removal patch). 2. We can't turn domains off without creating a vectors page alias Correct. 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches without additional cache maintainence. Correct. I don't think overloading the context switch with yet more conditionals based on yet more TLS combinations is a practical solution. Yet another run-time code patching for the TLS, though it gets a bit complex. But we may need to solve it for the v7 filesystem case I mentioned above. So, ARMv6 TLS emulation, and SWP emulation are incompatible with each other. Yes. So either we don't have the SWP instruction at all on ARMv6+, or we have it enabled in hardware, or we don't and use the emulation where possible. If we can't sort out TLS register setting on v6+v7 kernels (I think we should), then we must have the SWP instruction enabled (no emulation). Which gets us back to the SWP_EMULATE depend on (CPU_V7 !CPU_V6). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] omap4: prcm: Few dpll, clockdomain and powerdomain updates
-Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Friday, January 28, 2011 4:35 PM To: linux-omap@vger.kernel.org Cc: khil...@ti.com; p...@pwsan.com; b-cous...@ti.com; rna...@ti.com; linux-arm-ker...@lists.infradead.org; Santosh Shilimkar Subject: [PATCH 0/6] omap4: prcm: Few dpll, clockdomain and powerdomain updates The series mainly contains dpll initialisation, CPUx clock domain offset fix, addiing INACTIVE power domain state and fixing logic flag for IVAHD and ABE power domains. The series is boot tested on OMAP4430 SDP. The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5: Linus Torvalds (1): Linux 2.6.38-rc2 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux- 2.6.git omap4_prcm_misc With corrected git URL: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4_prcm_misc Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 11:06 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). What about a kernel covering ARMv6 too? Writing to an aliased mapping of the vectors page (as required for TLS emulation) will require additional cache maintainence on every context switch. With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. That's not a problem, because you wouldn't run ARMv7 optimized userspace on an ARMv6 CPU. That's not what this whole exercise is about. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, 2011-01-28 at 13:05 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. That's not a problem, because you wouldn't run ARMv7 optimized userspace on an ARMv6 CPU. That's not what this whole exercise is about. But you can run ARMv7 optimised userspace on ARMv7 CPU with a kernel image compiled for v6+v7. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 11:06 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). What about a kernel covering ARMv6 too? Writing to an aliased mapping of the vectors page (as required for TLS emulation) will require additional cache maintainence on every context switch. With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. So you may have people taking an Ubuntu filesystem (v7 only) and a pre-built OMAP image with TLS emulation even on Cortex-A8 and things won't work as expected. You're really making a mountain out of TLS. If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built, we will use the TLS register if that's available on the hardware. If it isn't, we will write the TLS value directly to virtual 0x0ffc. So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware TLS register, and your v7 optimized binaries which access the TLS register directly will work. Same for v6k. For v6, you won't be able to run v7 optimized binaries on that hardware anyway, because it doesn't have the TLS register, and as such the instructions which access it will fault. That's true whether you have a v6 only kernel or a v6+v6k+v7 kernel. What we're discussing has nothing at all to do with getting v7 binaries running on v6 hardware. That's just not going to happen. On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO and use the TLS register. The only other place where this matters on ARMv7 is early_trap_init() but it's easily fixable on this architecture. That's pointless. There's no could map the vectors page - set_pte_ext() doesn't know what's the vectors page and what isn't. It's about how set_pte_ext() maps pages which are marked with just L_PTE_USER. All L_PTE_USER pages get mapped as user read-only. Whether they get mapped SVC read-only or SVC read-write depends on whether we support domains. Without domains, they're mapped SVC read-write, and we need to use the ldrt/strt instructions. With domains, they're mapped SVC read-only, and we no longer need the ldrt/strt instructions. 1. SWP emulation requires domain support turned off Not necessarily - it requires RO user pages to be kernel RO (though this feature came with the domains removal patch). Yes it does because without domains, we need user pages to be kernel read-only, which also makes the vectors page kernel read-only. 2. We can't turn domains off without creating a vectors page alias Correct. 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches without additional cache maintainence. Correct. I don't think overloading the context switch with yet more conditionals based on yet more TLS combinations is a practical solution. Yet another run-time code patching for the TLS, though it gets a bit complex. It _already_ is complex. We don't need any more complexity there. Have a look in asm/tls.h to see that there's already four different cases we have to consider. But we may need to solve it for the v7 filesystem case I mentioned above. No we don't. We're already selecting the code appropriately from four different cases for the supported processor types. We don't need maybe the vectors page is read-only introducing another two cases with complex cache flushing and location of the vectors page, and we certainly don't need this complication at runtime. If we can't sort out TLS register setting on v6+v7 kernels (I think we should), then we must have the SWP instruction enabled (no emulation). Which gets us back to the SWP_EMULATE depend on (CPU_V7 !CPU_V6). That I think is the
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 01:10:56PM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 13:05 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. That's not a problem, because you wouldn't run ARMv7 optimized userspace on an ARMv6 CPU. That's not what this whole exercise is about. But you can run ARMv7 optimised userspace on ARMv7 CPU with a kernel image compiled for v6+v7. Yes. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] omap1: remove duplicated #include
Remove duplicated #include('s) in
arch/arm/mach-omap1/time.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
arch/arm/mach-omap1/time.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index f83fc33..6885d2f 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -44,7 +44,6 @@
#include linux/clocksource.h
#include linux/clockchips.h
#include linux/io.h
-#include linux/sched.h
#include asm/system.h
#include mach/hardware.h
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: mach-omap2: mux: free allocated memory on error exit
Free allocated memory on error exit.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/mux.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index df8d2f2..18aea0c 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -1000,6 +1000,7 @@ int __init omap_mux_init(const char *name, u32 flags,
if (!partition-base) {
pr_err(%s: Could not ioremap mux partition at 0x%08x\n,
__func__, partition-phys);
+ kfree(partition);
return -ENODEV;
}
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, 2011-01-28 at 13:21 +, Russell King - ARM Linux wrote:
On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote:
With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
v6 is compiled in? If that's the case, we may have a problem - I talked
to the toolchain guys and it looks like code optimised for ARMv7 reads
the TLS register directly without going through the kuser helper. So you
may have people taking an Ubuntu filesystem (v7 only) and a pre-built
OMAP image with TLS emulation even on Cortex-A8 and things won't work as
expected.
You're really making a mountain out of TLS.
Not really, just asking for clarification as I haven't checked all your
patches recently.
If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built,
we will use the TLS register if that's available on the hardware. If it
isn't, we will write the TLS value directly to virtual 0x0ffc.
So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware
TLS register, and your v7 optimized binaries which access the TLS register
directly will work. Same for v6k.
Great.
What we're discussing has nothing at all to do with getting v7 binaries
running on v6 hardware. That's just not going to happen.
I wasn't suggesting this. That's not easily possible.
On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors
page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO
and use the TLS register. The only other place where this matters on
ARMv7 is early_trap_init() but it's easily fixable on this architecture.
That's pointless. There's no could map the vectors page - set_pte_ext()
doesn't know what's the vectors page and what isn't. It's about how
set_pte_ext() maps pages which are marked with just L_PTE_USER.
What I meant is that we leave cpu_v6_set_pte_ext as it is (with R/W
kernel access for RO user pages) and always mark such pages kernel RO in
cpu_v7_set_pte_ext. See patch at the end of this email.
1. SWP emulation requires domain support turned off
Not necessarily - it requires RO user pages to be kernel RO (though this
feature came with the domains removal patch).
Yes it does because without domains, we need user pages to be kernel
read-only, which also makes the vectors page kernel read-only.
But even with domains we can make user pages kernel RO for ARMv7 only.
The only use which SWP_EMULATE gets us then is detecting userspace
programs which use the SWP instruction - and that can only happen on
a V7-only or v6k+v7 targetted kernel.
In some MP hardware configurations, SWP may not ensure atomicity across
all the CPUs. Exclusives would ensure this behaviour.
The patch below allows domains to be enabled on ARMv7 and also use SWP
emulation (tested on VE + A9 with domains enabled):
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..6e0b349 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long
vectors)
void __init early_trap_init(void)
{
-#if defined(CONFIG_CPU_USE_DOMAINS)
- unsigned long vectors = CONFIG_VECTORS_BASE;
-#else
- unsigned long vectors = (unsigned long)vectors_page;
-#endif
+ unsigned long vectors;
extern char __stubs_start[], __stubs_end[];
extern char __vectors_start[], __vectors_end[];
extern char __kuser_helper_start[], __kuser_helper_end[];
int kuser_sz = __kuser_helper_end - __kuser_helper_start;
/*
+* On ARMv7, user RO pages are mapped as kernel RO.
+*/
+ if (cpu_architecture() = 7)
+ vectors = (unsigned long)vectors_page;
+ else
+ vectors = CONFIG_VECTORS_BASE;
+
+ /*
* Copy the vectors, stubs and kuser helpers (in entry-armv.S)
* into the vector page, mapped at 0x, and ensure these
* are visible to the instruction stream.
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0c1172b..5f51592 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
tst r1, #L_PTE_USER
orrne r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
- @ allow kernel read/write access to read-only user pages
- tstne r3, #PTE_EXT_APX
- bicne r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
-#endif
tst r1, #L_PTE_XN
orrne r3, r3, #PTE_EXT_XN
--
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: mach-omap2: voltage: debugfs: fix memory leak
The temporary string holding the directory name to be created should
be released.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/voltage.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index ed6079c..12be525 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -471,6 +471,7 @@ static void __init vdd_debugfs_init(struct omap_vdd_info
*vdd)
strcat(name, vdd-voltdm.name);
vdd-debug_dir = debugfs_create_dir(name, voltage_dir);
+ kfree(name);
if (IS_ERR(vdd-debug_dir)) {
pr_warning(%s: Unable to create debugfs directory for
vdd_%s\n, __func__, vdd-voltdm.name);
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
* Catalin Marinas catalin.mari...@arm.com [110128 07:11]: On Fri, 2011-01-28 at 13:21 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. So you may have people taking an Ubuntu filesystem (v7 only) and a pre-built OMAP image with TLS emulation even on Cortex-A8 and things won't work as expected. You're really making a mountain out of TLS. Not really, just asking for clarification as I haven't checked all your patches recently. If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built, we will use the TLS register if that's available on the hardware. If it isn't, we will write the TLS value directly to virtual 0x0ffc. So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware TLS register, and your v7 optimized binaries which access the TLS register directly will work. Same for v6k. Great. Yes AFAIK we sorted out the TLS issue already a while back for v6+v6k+v7. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc
* Ghorai, Sukumar s-gho...@ti.com [110128 00:14]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, January 25, 2011 10:28 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc * Ghorai, Sukumar s-gho...@ti.com [110122 09:53]: I think I've commented on this before, but why don't you make gpmc_init a subsys_initcall? There should be no reason to call this earlier. If something does not work because of that, then that issue must be fixed. [Ghorai] You suggested the same in previous v5 and v6; and I mentioned the issues [1] that - nand_init()called before subsys_initcall(gpmc_init); Let me know if I am missing anything again. There should not be any need to call nand_init early either. We want to initialize as much as possible late so we have proper console error messages. [Ghorai] thanks... changed to postcore_initcall() and it solved the problem I mentioned earlier. And it simplifies the overall modification in different board files. postcore_initcall(gpmc_init); OK great. I will check the order of initcalls anyways over next few weeks, so whatever works for the initcall is fine for now. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] omap4: board-omap4panda: Initialise the serial pads
Sricharan wrote:
Use the mux framework to initialise the serial pads.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 72
+++-
1 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b43e3ff..9688ea9 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -370,13 +370,83 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+ { .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ .flags = OMAP_DEVICE_PAD_REMUX_IDLE,
+ .idle = OMAP_MUX_MODE7,
+ },
+ { .name = uart2_rts.uart2_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart2_rx.uart2_rx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ { .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad serial3_pads[] __initdata = {
+ { .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ { .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart3_rx_irrx.uart3_rx_irrx,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad serial4_pads[] __initdata = {
+ { .name = uart4_rx.uart4_rx,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart4_tx.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_board_data serial2_data = {
+ .id = 1,
+ .pads = serial2_pads,
+ .pads_cnt = ARRAY_SIZE(serial2_pads),
+};
+
+static struct omap_board_data serial3_data = {
+ .id = 2,
+ .pads = serial3_pads,
+ .pads_cnt = ARRAY_SIZE(serial3_pads),
+};
+
+static struct omap_board_data serial4_data = {
+ .id = 3,
+ .pads = serial4_pads,
+ .pads_cnt = ARRAY_SIZE(serial4_pads),
+};
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init_port(serial2_data);
+ omap_serial_init_port(serial3_data);
+ omap_serial_init_port(serial4_data);
+}
#else
#define board_muxNULL
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init();
+}
#endif
static void __init omap4_panda_init(void)
You are changing the behavior with this patch.
Original code configured all 4 UARTs, while it
appears that your patch changes this to skip UART1.
This is not explained in the changelog. Is this
a deliberate change? Why would you want to do this?
- Anand
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/5] omap2+: mux: Seperate the pads of a hwmod as static and dynamic.
sricharan wrote: 1) All the pads of a hwmod for the device are classified as static/dynamic. If a pad requires remuxing during the device transitions between enable/idle transitions then it is added to the dynamic list, static otherwise. 2) Both the static/dynamic pads of a hwmod are initialised when the device gets enabled. When the device transitions between enable/idle the dynamic pads are remuxed and static pads are skipped. 3) When the driver gets removed both the static and the dynamic pads are muxed to safe mode as default. I haven't taken a look at the code. I do have a few concerns (which may really be non-issues, but I'm pointing them out anyway): - Not all pads have a safe mode. --- And why would you want statically muxed pads to be remuxed into safe mode anyway? What is the advantage of such a change, as against leaving them in a functional mode? - Many signals are muxed on more than one pad. - Many peripherals need pads to be configured in different mux modes depending on the way a board is wired up. With this, moving pad info to hwmod databases does not sound useful to me. Maybe I do not understand the need for this change, in place of what we have today. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] nohz/sched: delay going tickless when CPU is loaded
From: Nicole Chalhoub n-chalh...@ti.com
One criterion of C-states selection is based on the load factor. High
load prevents deep C-states. The load is evaluated and updated at
each scheduler tick, and thus not updated when in tickless mode. As a
result, the CPU load calculated on the tick just before entering
tickless is used for idle decisions.
When a high load is evaluated on a tick happening on a burst of
activity, this load value is kept until the next tick, which could
take few ms to happen if going tickless.
This patch ensures that the load is taken into consideration before
going tickless. Rather than going tickless and entering a shallow
sleep state, the decison to go tickless is slightly delayed so that
the idle governor will tend to favor deeper sleep states.
Delaying NOHZ decisions until the load is zero improved the load
estimation on our ARM/OMAP4 platform where HZ =128 and increased the
time spent in deep C-states (~50% of idle time in C-states deeper than
C1). A power saving of ~20mA at battery level is observed during MP3
playback on OMAP4/Blaze board.
Signed-off-by: Nicole Chalhoub n-chalh...@ti.com
Signed-off-by: Vincent Bour v-b...@ti.com
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Thomas Gleixner t...@linutronix.de
[khil...@ti.com: minor edits/changes to changelog]
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies to v2.6.38-rc2
kernel/time/tick-sched.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 3e216e0..96cb512 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -325,7 +325,7 @@ void tick_nohz_stop_sched_tick(int inidle)
} while (read_seqretry(xtime_lock, seq));
if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu) ||
- arch_needs_cpu(cpu)) {
+ arch_needs_cpu(cpu) || this_cpu_load()) {
next_jiffies = last_jiffies + 1;
delta_jiffies = 1;
} else {
--
1.7.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3630: PM: don't warn the user with a trace in case of PM34XX_ERRATUM
Ricardo Salveti de Araujo ricardo.salv...@canonical.com writes:
In case in user has a OMAP3630 ES1.2 the kernel should warn the user
about the ERRATUM, but using printk instead of WARN_ON is already
enough, as there is nothing else the user can do besides changing the
board.
I agree, it doesn't need a full backtrace.
Minor comment below...
Signed-off-by: Ricar
do Salveti de Araujo ricardo.salv...@canonical.com
---
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f7b22a1..abb9be0 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -464,7 +464,7 @@ void omap_init_power_states(void)
if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
omap3_power_states[OMAP3_STATE_C7].valid = 0;
cpuidle_params_table[OMAP3_STATE_C7].valid = 0;
- WARN_ONCE(1, %s: core off state C7 disabled due to i583\n,
+ printk(KERN_WARNING %s: core off state C7 disabled due to
i583\n,
__func__);
Please use pr_warn() instead.
}
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a4aa192..983b543 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -927,7 +927,7 @@ void omap3_pm_off_mode_enable(int enable)
pwrst-pwrdm == core_pwrdm
state == PWRDM_POWER_OFF) {
pwrst-next_state = PWRDM_POWER_RET;
- WARN_ONCE(1,
+ printk(KERN_WARNING
%s: Core OFF disabled due to errata i583\n,
__func__);
ditto
} else {
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: mach-omap2: voltage: debugfs: fix memory leak
Aaro Koskinen aaro.koski...@nokia.com writes:
The temporary string holding the directory name to be created should
be released.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
Thanks, queuing in pm-fixes for 2.6.38.
Kevin
---
arch/arm/mach-omap2/voltage.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index ed6079c..12be525 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -471,6 +471,7 @@ static void __init vdd_debugfs_init(struct omap_vdd_info
*vdd)
strcat(name, vdd-voltdm.name);
vdd-debug_dir = debugfs_create_dir(name, voltage_dir);
+ kfree(name);
if (IS_ERR(vdd-debug_dir)) {
pr_warning(%s: Unable to create debugfs directory for
vdd_%s\n, __func__, vdd-voltdm.name);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regulator question regarding I2C devices
I have a tsc2004 touch controller on I2C3 that is powered by vaux1, and since
its probed I have to turn the power on before it can be probed. I've created:
static struct regulator_consumer_supply dm3730logic_vaux1_supply = {
.supply= vaux1,
};
/* VAUX1 for touch chip */
static struct regulator_init_data dm3730logic_vaux1 = {
.constraints = {
.min_uV= 300,
.max_uV= 300,
.apply_uV= true,
.valid_modes_mask= REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
.valid_ops_mask= REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies= 1,
.consumer_supplies= dm3730logic_vaux1_supply,
};
and listed it in the twldata initializer
.vaux1= dm3730logic_vaux1,
But it never gets enabled... How can I tell the kernel to turn the regulator
on?
If I try to call regulator_get() right before the call to omap_register_i2c_bus
for I2C3, regulator_get returns a NULL due to regulator_map_list being empty.
If I look in sys/class/regulator I see VAUX1 listed (as regulator.4), but there
are no users.
Any suggestions on how I can turn on vaux1 so the tsc2004 touch controller is
visible to by the I2C system?
Thanks in advance!
--
Peter Barada
peter.bar...@logicpd.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] OMAP3: Add voltage dependency table for VDD1.
Hi Vishwa,
Vishwanath BS vishwanath...@ti.com writes:
From: Thara Gopinath th...@ti.com
In OMAP3, for perfomrance reasons when VDD1 is at voltage above
1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
patch introduce this cross VDD dependency for OMAP3 VDD1.
Signed-off-by: Thara Gopinath th...@ti.com
As you are now on the delivery path, your signoff should be here as
well.
Some initial tests on 34xx turned up errors when trying to scale
voltage:
omap_voltage_get_voltdata: Unable to match the current voltage with the
voltagetable for vdd_core
First, this error message wasn't very useful since I had no idea what
the current voltage was. Also, current voltage probably isn't the
right word since to me, current voltage means the one currently set.
This is actually the target voltage that is being looked up.
In any case, root cause below...
This patch has checkpatch warnings for line over 80 chars. It is not fixed for
code readability.
OK, this can either be left out, or added below the '---' as it's not
needed in the final git history.
---
arch/arm/mach-omap2/voltage.c | 42 +++-
1 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 92fe20d..8881c0c 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -191,6 +191,39 @@ static struct omap_volt_data
omap44xx_vdd_core_volt_data[] = {
VOLT_DATA_DEFINE(0, 0, 0, 0),
};
+/* OMAP 3430 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP1_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP50_UV},
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP2_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP50_UV},
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP3_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP4_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP5_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
This 34xx table has 4430 OPP voltages for CORE, which are clearly not
right. 34xx has 3 CORE voltages to pick from, so I'm not sure which
ones are right
Please update this with the correct 34xx voltages and also validate on
34xx also.
Thanks,
Kevin
+static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
+ {
+ .name = core,
+ .dep_table = omap34xx_vdd1_vdd2_data,
+ },
+};
+
+/* OMAP 3630 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap36xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = OMAP3630_VDD_MPU_OPP50_UV, .dep_vdd_volt =
OMAP3630_VDD_CORE_OPP50_UV},
+ {.main_vdd_volt = OMAP3630_VDD_MPU_OPP100_UV, .dep_vdd_volt =
OMAP3630_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = OMAP3630_VDD_MPU_OPP120_UV, .dep_vdd_volt =
OMAP3630_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = OMAP3630_VDD_MPU_OPP1G_UV, .dep_vdd_volt =
OMAP3630_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
+
+static struct omap_vdd_dep_info omap36xx_vdd1_dep_info[] = {
+ {
+ .name = core,
+ .dep_table = omap36xx_vdd1_vdd2_data,
+ },
+};
+
static struct dentry *voltage_dir;
/* Init function pointers */
@@ -696,10 +729,15 @@ static int __init omap3_vdd_data_configure(struct
omap_vdd_info *vdd)
}
if (!strcmp(vdd-voltdm.name, mpu)) {
- if (cpu_is_omap3630())
+ if (cpu_is_omap3630()) {
vdd-volt_data = omap36xx_vddmpu_volt_data;
- else
+ vdd-dep_vdd_info = omap36xx_vdd1_dep_info;
+ vdd-nr_dep_vdd = ARRAY_SIZE(omap36xx_vdd1_dep_info);
+ } else {
vdd-volt_data = omap34xx_vddmpu_volt_data;
+ vdd-dep_vdd_info = omap34xx_vdd1_dep_info;
+ vdd-nr_dep_vdd = ARRAY_SIZE(omap34xx_vdd1_dep_info);
+ }
vdd-vp_reg.tranxdone_status = OMAP3430_VP1_TRANXDONE_ST_MASK;
vdd-vc_reg.cmdval_reg = OMAP3_PRM_VC_CMD_VAL_0_OFFSET;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ARM Architecture and GENERIC_CMOS_UPDATE
Is there any reason, to date, that the ARM architecture has not had the following kernel configuration option? config GENERIC_CMOS_UPDATE def_bool y Regards, Grant -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
