[PATCH 0/5] OMAP: DSS: fixes for rc
Some small fixes to OMAP DSS for the next rc. I will send a pull request to Paul Mundt soon if there are no problems with the patches. Note that DSS doesn't still work for OMAP4. It needs a clock patch which has been discussed on l-o, and Paul Walmsley will handle that patch. Tomi Archit Taneja (1): OMAP: DSS2: Fix: Return correct lcd clock source for OMAP2/3 Tomi Valkeinen (4): OMAP: DSS2: DSI: fix use_sys_clk highfreq OMAP: DSS2: DSI: fix dsi_dump_clocks() OMAP: DSS2: DSI: Fix DSI PLL power bug OMAP: DSS2: fix panel Kconfig dependencies drivers/video/omap2/displays/Kconfig |9 + drivers/video/omap2/dss/dsi.c | 14 +- drivers/video/omap2/dss/dss.c | 10 -- drivers/video/omap2/dss/dss_features.c |2 +- drivers/video/omap2/dss/dss_features.h |2 ++ 5 files changed, 25 insertions(+), 12 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 1/5] OMAP: DSS2: DSI: fix use_sys_clk highfreq
use_sys_clk and highfreq fields in dsi.current_cinfo were never set. Luckily they weren't used anywhere so it didn't cause any problems. This patch fixes those fields and they are now set at the same time as the rest of the fields. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dsi.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index 0a7f1a4..8604153 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -1276,6 +1276,9 @@ int dsi_pll_set_clock_div(struct dsi_clock_info *cinfo) DSSDBGF(); + dsi.current_cinfo.use_sys_clk = cinfo-use_sys_clk; + dsi.current_cinfo.highfreq = cinfo-highfreq; + dsi.current_cinfo.fint = cinfo-fint; dsi.current_cinfo.clkin4ddr = cinfo-clkin4ddr; dsi.current_cinfo.dsi_pll_hsdiv_dispc_clk = -- 1.7.1 -- 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/5] OMAP: DSS2: DSI: fix dsi_dump_clocks()
On OMAP4, reading DSI_PLL_CONFIGURATION2 register requires the L3 clock
(CIO_CLK_ICG) to PLL. Currently dsi_dump_clocks() tries to read that
register without enabling the L3 clock, leading to crash if DSI is not
in use.
The status of the bit being read from DSI_PLL_CONFIGURATION2 is
available from dsi_clock_info-use_sys_clk, so we can avoid the whole
problem by just using that.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8604153..1464ac4 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1491,7 +1491,6 @@ void dsi_pll_uninit(void)
void dsi_dump_clocks(struct seq_file *s)
{
- int clksel;
struct dsi_clock_info *cinfo = dsi.current_cinfo;
enum dss_clk_source dispc_clk_src, dsi_clk_src;
@@ -1500,13 +1499,10 @@ void dsi_dump_clocks(struct seq_file *s)
enable_clocks(1);
- clksel = REG_GET(DSI_PLL_CONFIGURATION2, 11, 11);
-
seq_printf(s, - DSI PLL -\n);
seq_printf(s, dsi pll source = %s\n,
- clksel == 0 ?
- dss_sys_clk : pclkfree);
+ cinfo-use_sys_clk ? dss_sys_clk : pclkfree);
seq_printf(s, Fint\t\t%-16luregn %u\n, cinfo-fint, cinfo-regn);
--
1.7.1
--
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/5] OMAP: DSS2: Fix: Return correct lcd clock source for OMAP2/3
From: Archit Taneja arc...@ti.com
dss.lcd_clk_source is set to the default value DSS_CLK_SRC_FCK at dss_init.
For OMAP2 and OMAP3, the dss.lcd_clk_source should always be the same as
dss.dispc_clk_source. The function dss_get_lcd_clk_source() always returns the
default value DSS_CLK_SRC_FCK for OMAP2/3. This leads to wrong clock dumps when
dispc_clk_source is not DSS_CLK_SRC_FCK.
Correct this function to always return dss.dispc_clk_source for OMAP2/3.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 3f1fee6..c3b48a0 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -385,8 +385,14 @@ enum dss_clk_source dss_get_dsi_clk_source(void)
enum dss_clk_source dss_get_lcd_clk_source(enum omap_channel channel)
{
- int ix = channel == OMAP_DSS_CHANNEL_LCD ? 0 : 1;
- return dss.lcd_clk_source[ix];
+ if (dss_has_feature(FEAT_LCD_CLK_SRC)) {
+ int ix = channel == OMAP_DSS_CHANNEL_LCD ? 0 : 1;
+ return dss.lcd_clk_source[ix];
+ } else {
+ /* LCD_CLK source is the same as DISPC_FCLK source for
+* OMAP2 and OMAP3 */
+ return dss.dispc_clk_source;
+ }
}
/* calculate clock rates using dividers in cinfo */
--
1.7.1
--
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/5] OMAP: DSS2: DSI: Fix DSI PLL power bug
OMAP3630 has a HW bug causing DSI PLL power command POWER_ON_DIV (0x3)
to not work properly. The bug prevents us from enabling DSI PLL power
only to HS divider block.
This patch adds a dss feature for the bug and converts POWER_ON_DIV
requests to POWER_ON_ALL (0x2).
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |5 +
drivers/video/omap2/dss/dss_features.c |2 +-
drivers/video/omap2/dss/dss_features.h |2 ++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1464ac4..cbd9ca4 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1059,6 +1059,11 @@ static int dsi_pll_power(enum dsi_pll_power_state state)
{
int t = 0;
+ /* DSI-PLL power command 0x3 is not working */
+ if (dss_has_feature(FEAT_DSI_PLL_PWR_BUG)
+ state == DSI_PLL_POWER_ON_DIV)
+ state = DSI_PLL_POWER_ON_ALL;
+
REG_FLD_MOD(DSI_CLK_CTRL, state, 31, 30); /* PLL_PWR_CMD */
/* PLL_PWR_STATUS */
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index aa16222..8c50e18 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -271,7 +271,7 @@ static struct omap_dss_features omap3630_dss_features = {
FEAT_LCDENABLESIGNAL | FEAT_PCKFREEENABLE |
FEAT_PRE_MULT_ALPHA | FEAT_FUNCGATED |
FEAT_ROWREPEATENABLE | FEAT_LINEBUFFERSPLIT |
- FEAT_RESIZECONF,
+ FEAT_RESIZECONF | FEAT_DSI_PLL_PWR_BUG,
.num_mgrs = 2,
.num_ovls = 3,
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index 12e9c4e..37922ce 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -40,6 +40,8 @@ enum dss_feat_id {
/* Independent core clk divider */
FEAT_CORE_CLK_DIV = 1 11,
FEAT_LCD_CLK_SRC= 1 12,
+ /* DSI-PLL power command 0x3 is not working */
+ FEAT_DSI_PLL_PWR_BUG= 1 13,
};
/* DSS register field id */
--
1.7.1
--
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 5/5] OMAP: DSS2: fix panel Kconfig dependencies
All DPI panels were missing dependency to OMAP2_DSS_DPI. Add the dependency. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/displays/Kconfig |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig index d18ad6b..609a280 100644 --- a/drivers/video/omap2/displays/Kconfig +++ b/drivers/video/omap2/displays/Kconfig @@ -3,6 +3,7 @@ menu OMAP2/3 Display Device Drivers config PANEL_GENERIC_DPI tristate Generic DPI Panel + depends on OMAP2_DSS_DPI help Generic DPI panel driver. Supports DVI output for Beagle and OMAP3 SDP. @@ -11,20 +12,20 @@ config PANEL_GENERIC_DPI config PANEL_LGPHILIPS_LB035Q02 tristate LG.Philips LB035Q02 LCD Panel - depends on OMAP2_DSS SPI + depends on OMAP2_DSS_DPI SPI help LCD Panel used on the Gumstix Overo Palo35 config PANEL_SHARP_LS037V7DW01 tristate Sharp LS037V7DW01 LCD Panel -depends on OMAP2_DSS +depends on OMAP2_DSS_DPI select BACKLIGHT_CLASS_DEVICE help LCD Panel used in TI's SDP3430 and EVM boards config PANEL_NEC_NL8048HL11_01B tristate NEC NL8048HL11-01B Panel - depends on OMAP2_DSS + depends on OMAP2_DSS_DPI help This NEC NL8048HL11-01B panel is TFT LCD used in the Zoom2/3/3630 sdp boards. @@ -37,7 +38,7 @@ config PANEL_TAAL config PANEL_TPO_TD043MTEA1 tristate TPO TD043MTEA1 LCD Panel -depends on OMAP2_DSS SPI +depends on OMAP2_DSS_DPI SPI help LCD Panel used in OMAP3 Pandora -- 1.7.1 -- 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] OMAP: iommu flush page table entries from L1 and L2 cache
On Fri, Apr 15, 2011 at 11:24:16AM +0900, KyongHo Cho wrote: That means we need to translate logical to physical address and it is sometimes not trivial. What do you mean sometimes not trivial ? The DMA does nothing more than virt_to_phys(virt) to get the physical address. It's _that_ simple. If virt_to_phys(virt) is likely to fail, there's protection in the DMA API to BUG_ON() in that case. Finally, the kernel will contain many similar routines that do same thing. So when we get coherent DMA, you won't care that the DMA API functions start doing nothing with caches? -- 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] OMAP: iommu flush page table entries from L1 and L2 cache
Russell, On Thu, Apr 14, 2011 at 5:30 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote: From: Ramesh Gupta grgu...@ti.com This patch is to flush the iommu page table entries from L1 and L2 caches using dma_map_single. This also simplifies the implementation by removing the functions flush_iopgd_range/flush_iopte_range. No. This usage is just wrong. If you're going to use the DMA API then unmap it, otherwise the DMA API debugging will go awol. Thank you for the comments, this particular memory is always a write from the A9 for MMU programming and only read from the slave processor, that is the reason for not calling the unmap. I can re-look into the changes to call unmap in a proper way as this impacts the DMA API. Are there any other ways to perform only flush the memory from L1/L2 caches? regards Ramesh Gupta G -- 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] Consolidate SRAM support
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
Let's unify this before we have additional SoCs re-implementing this
obviously common functionality themselves.
Unfortunately, we end up with code growth through doing this, but that
will become a win when we have another SoC using this (which I know
there's at least one in the pipeline).
One of the considerations here is that we can easily convert sram-pool.c
to hook into device tree stuff, which can tell the sram allocator:
- physical address of sram
- size of sram
- allocation granularity
and then we just need to ensure that it is appropriately mapped.
This uses the physical address, and unlike Davinci's dma address usage,
it always wants to have the physical address, and will always return
the corresponding physical address when passed that pointer.
OMAP could probably do with some more work to make the omapfb and other
allocations use the sram allocator, rather than hooking in before the
sram allocator is initialized - and then further cleanups so that we
have an initialization function which just does
sram_create(phys, size)
virt = map sram(phys, size)
create sram pool(virt, phys, size, min_alloc_order)
Another question is whether we should allow multiple SRAM pools or not -
this code does allow multiple pools, but so far we only have one pool
per SoC. Overdesign? Maybe, but it prevents SoCs wanting to duplicate
it if they want to partition the SRAM, or have peripheral-local SRAMs.
Lastly, uio_pruss should probably take the SRAM pool pointer via
platform data so that it doesn't have to include Davinci specific
includes.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/Kconfig|2 +
arch/arm/common/Kconfig |4 ++
arch/arm/common/Makefile|1 +
arch/arm/common/sram-pool.c | 69 +++
arch/arm/include/asm/sram-pool.h| 20
arch/arm/mach-davinci/da850.c |2 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/common.h |2 +-
arch/arm/mach-davinci/include/mach/sram.h | 13 +
arch/arm/mach-davinci/pm.c | 12 +
arch/arm/mach-davinci/sram.c| 42 +++--
arch/arm/plat-omap/include/plat/sram.h | 17 ---
arch/arm/plat-omap/sram.c | 34 +-
drivers/uio/uio_pruss.c |8 ++-
17 files changed, 141 insertions(+), 93 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b9f78b..5c3401c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -850,6 +850,7 @@ config ARCH_DAVINCI
bool TI DaVinci
select GENERIC_CLOCKEVENTS
select ARCH_REQUIRE_GPIOLIB
+ select ARM_SRAM_POOL
select ZONE_DMA
select HAVE_IDE
select CLKDEV_LOOKUP
@@ -863,6 +864,7 @@ config ARCH_OMAP
select HAVE_CLK
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
+ select ARM_SRAM_POOL
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index ea5ee4d..ddbd20b 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -39,3 +39,7 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config ARM_SRAM_POOL
+ bool
+ select GENERIC_ALLOCATOR
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e7521bca..b79ad68 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_ARCH_IXP23XX)+= uengine.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_COMMON_CLKDEV)+= clkdev.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_ARM_SRAM_POOL)+= sram-pool.o
diff --git a/arch/arm/common/sram-pool.c b/arch/arm/common/sram-pool.c
new file mode 100644
index 000..9ff1466
--- /dev/null
+++ b/arch/arm/common/sram-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified SRAM allocator, based on mach-davinci/sram.c, which was
+ * Copyright (C) 2009 David Brownell.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include linux/dma-mapping.h
+#include linux/genalloc.h
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+
+#include asm/sram-pool.h
+
+struct sram_pool {
+ struct gen_pool *genpool;
+ void
Re: [PATCH] Fixed gpio polarity of gpio USB-phy reset.
On Thu, Apr 14, 2011 at 3:32 AM, Felipe Balbi ba...@ti.com wrote: On Thu, Apr 14, 2011 at 09:31:43AM +0200, Juergen Kilb wrote: With commit 19403165 a main part of ehci-omap.c moved to drivers/mfd/omap-usb-host.c created by commit 17cdd29d. Due to this reorganisation the polarity used to reset the external USB phy changed and USB host doesn't recognize any devices. Signed-off-by: Juergen Kilb j.k...@phytec.de Judging by how ehci-omap.c was before moving the code: Acked-by: Felipe Balbi ba...@ti.com This fixes the issue on Overo: Tested-by: Steve Sakoman st...@sakoman.com Steve -- 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: omap2: mtd split nand_scan in ident and tail
Am Donnerstag, den 14.04.2011, 11:15 +0200 schrieb Jan Weitzel:
nand_scan calls nand_scan_ident and nand_scan_tail, setting values like
oobvail
according to ecc.layout. If we change the layout afterwards values are wrong.
Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
drivers/mtd/nand/omap2.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index da9a351..288423f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1073,9 +1073,9 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
*/
- if (nand_scan(info-mtd, 1)) {
+ if (nand_scan_ident(info-mtd, 1, NULL)) {
info-nand.options ^= NAND_BUSWIDTH_16;
- if (nand_scan(info-mtd, 1)) {
+ if (nand_scan_ident(info-mtd, 1, NULL)) {
err = -ENXIO;
goto out_release_mem_region;
}
@@ -1101,6 +1101,12 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.ecc.layout = omap_oobinfo;
}
+ /* second phase scan */
+ if (nand_scan_tail(info-mtd)) {
+ err = -ENXIO;
+ goto out_release_mem_region;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err 0)
So no comments? Is any rework needed? Without this patch I am not able
to mount partions with OMAP_ECC_HAMMING_CODE_HW_ROMCODE.
Regards, Jan
--
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: Code for v2.6.39 merge window frozen, patches archived
On Wed, 13 Apr 2011 17:34:24 +0300 (EEST) Aaro Koskinen aaro.koski...@nokia.com wrote: Aaro, you mentioned to me that reverting commit 6d7d0ae51574943bf571d269da3243257a2d15db helps too? With the device tree append patch reverting commit d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting 6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging.. Yes, with -rc1, reverting also 6d7d0ae51574943bf571d269da3243257a2d15db (ARM: 6750/1: improvements to compressed/head.S) helps. I haven't tried with newer kernels. Same note here from -rc3. For me it was enough to revert 6d7d0ae51574943bf571d269da3243257a2d15db. I was struggling with some of my own configs that didn't boot on Nokia N900 and config differences between working one and not working looked like a random. E.g. if one config had CONFIG_KALLSYMS_ALL=y, it didn't boot but booted if CONFIG_DEBUG_SPINLOCK=y was also enabled and so forth. CONFIG_KERNEL_LZMA=y either didn't make it booting. But revert made those unworking configs booting. -- Jarkko -- 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: [RFC PATCH] Consolidate SRAM support
Russell, On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. It's more than that. Several i.MX chips use plat-mxc/iram_alloc.c. lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1 user). Both are doing a copy the suspend code to IRAM and run it which may also be a good thing to have generic code for. Several i.MX chips also need to run from IRAM for suspend. Rob -- 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: [RFC PATCH] Consolidate SRAM support
Hi Russel, Just small comment, On Fri, Apr 15, 2011 at 08:06:07AM -0500, Russell King wrote: diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index a3f50b3..3588749 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -75,7 +75,6 @@ static unsigned long omap_sram_start; static unsigned long omap_sram_base; static unsigned long omap_sram_size; -static unsigned long omap_sram_ceil; I think you missed one occurrence of omap_sram_ceil at omap3_sram_restore_context. Probably you have compile-tested w/o CONFIG_PM? All best, -- Eduardo Valentin -- 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/2] MTD: s3c2410_nand: Add option to disable hw ECC at runtime
On Thu, 2011-04-14 at 16:48 +0200, Lars-Peter Clausen wrote: On 04/14/2011 02:08 PM, Artem Bityutskiy wrote: On Tue, 2011-04-12 at 21:47 +0200, Lars-Peter Clausen wrote: From: Holger Freyther ze...@openmoko.org This patch adds a flag to the s3c2410_nand platform data, which configures whether hardware ECC is used. Currently it is only possible to decide whether hw ECC should be used or not at compile time through a config option. But if you want to build a kernel which runs on multiple devices you might have a configuration where some devices require hw ECC and some devices which want software ECC. Signed-off-by: Lars-Peter Clausen l...@metafoo.de Extending platform data is kind of vetoed in arm tree, I do not think the MTD tree can take these changes. That is not my understanding of the situation. But what do you suggest as an alternative for fixing this issue? Well, I got this understanding by talking to the OMAP maintainer and by chatting with rmk. But I might be wrong. So the understanding is that board data extending is banned, at least for a while. And the arm world has to consolidate and probably switch to the DT tree approach. This would be painful, this would make some vendors to return to behind the curtains, so this would be a step back in the short run. But in a couple of years this would be resolved, may be under Linaro's aegis, and then the arm world would make 2 steps forward, so that previous step back would be compensated in the longer run. But! I'm just an small MTD guy, so I might be mistaken. Of course if you make your board file changes be merged via the corresponding arm sub-tree - go ahead send your MTD driver updates! This is I guess the answer to your what do you suggest question. CCing the arm lists so that people could correct me. Here is the beginning of the thread: http://lists.infradead.org/pipermail/linux-mtd/2011-April/034866.html -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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: omap2: mtd split nand_scan in ident and tail
On Fri, 2011-04-15 at 15:34 +0200, Jan Weitzel wrote:
Am Donnerstag, den 14.04.2011, 11:15 +0200 schrieb Jan Weitzel:
nand_scan calls nand_scan_ident and nand_scan_tail, setting values like
oobvail
according to ecc.layout. If we change the layout afterwards values are
wrong.
Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
drivers/mtd/nand/omap2.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index da9a351..288423f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1073,9 +1073,9 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
*/
- if (nand_scan(info-mtd, 1)) {
+ if (nand_scan_ident(info-mtd, 1, NULL)) {
info-nand.options ^= NAND_BUSWIDTH_16;
- if (nand_scan(info-mtd, 1)) {
+ if (nand_scan_ident(info-mtd, 1, NULL)) {
err = -ENXIO;
goto out_release_mem_region;
}
@@ -1101,6 +1101,12 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.ecc.layout = omap_oobinfo;
}
+ /* second phase scan */
+ if (nand_scan_tail(info-mtd)) {
+ err = -ENXIO;
+ goto out_release_mem_region;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err 0)
So no comments? Is any rework needed? Without this patch I am not able
to mount partions with OMAP_ECC_HAMMING_CODE_HW_ROMCODE.
Sorry, I missed this patch. Could you please update the commit message
and make it more verbose and state clearly:
1. which problem you solve
2. how you solve it
3. why is this the right solution
Thanks!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
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: [RFC PATCH] Consolidate SRAM support
On Fri, 2011-04-15 at 08:39 -0500, Rob Herring wrote: lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1 user). Both are doing a copy the suspend code to IRAM and run it which may also be a good thing to have generic code for. Several i.MX chips also need to run from IRAM for suspend. There will be similar patches for my lpc2k architecture once it gets accepted, a common interface would be _very_ beneficial IMHO. Regards, Ithamar. -- 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: [RFC PATCH] Consolidate SRAM support
On Friday 15 April 2011 15:39:55 Rob Herring wrote: On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. It's more than that. Several i.MX chips use plat-mxc/iram_alloc.c. There are also non-ARM systems doing something like that, arch/blackfin/mm/sram-alloc.c comes to mind. On powerpc, the ppc7410 also has this feature in hardware, but I believe it was never supported in mainline Linux. How about putting sram-pool.c into the top-level mm/ directory and sram-pool.h into include/linux? They seem to be completely generic to me, aside from the dependency on asm/fncpy.h which should probably remain arch specific. As long as CONFIG_ARM_SRAM_POOL (or perhaps just CONFIG_SRAM_POOL) is selected only by platforms that support it, the dependency should not hurt. Arnd -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 04:52:38PM +0300, Eduardo Valentin wrote: Hi Russel, Just small comment, On Fri, Apr 15, 2011 at 08:06:07AM -0500, Russell King wrote: diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index a3f50b3..3588749 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -75,7 +75,6 @@ static unsigned long omap_sram_start; static unsigned long omap_sram_base; static unsigned long omap_sram_size; -static unsigned long omap_sram_ceil; I think you missed one occurrence of omap_sram_ceil at omap3_sram_restore_context. Probably you have compile-tested w/o CONFIG_PM? I built OMAP2 only, which did have CONFIG_PM=y. Welcome to the problems of ifdef'ing code. -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 04:40:00PM +0200, Arnd Bergmann wrote: On Friday 15 April 2011 15:39:55 Rob Herring wrote: On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. It's more than that. Several i.MX chips use plat-mxc/iram_alloc.c. There are also non-ARM systems doing something like that, arch/blackfin/mm/sram-alloc.c comes to mind. On powerpc, the ppc7410 also has this feature in hardware, but I believe it was never supported in mainline Linux. Yes, but there's some horrible bits out there. PPC is one of them which looks like it doesn't lend itself to consolidating with this kind of implementation. How about putting sram-pool.c into the top-level mm/ directory and sram-pool.h into include/linux? They seem to be completely generic to me, aside from the dependency on asm/fncpy.h which should probably remain arch specific. I've thought about lib - but first lets see whether other architectures want to use it first. I've asked the sh folk off-list about this and waiting for a reply. Blackfin and PPC look horrible to sort out though, so they can come at a later date if they so wish. -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 9:26 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Apr 15, 2011 at 04:40:00PM +0200, Arnd Bergmann wrote: On Friday 15 April 2011 15:39:55 Rob Herring wrote: On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. It's more than that. Several i.MX chips use plat-mxc/iram_alloc.c. There are also non-ARM systems doing something like that, arch/blackfin/mm/sram-alloc.c comes to mind. On powerpc, the ppc7410 also has this feature in hardware, but I believe it was never supported in mainline Linux. Yes, but there's some horrible bits out there. PPC is one of them which looks like it doesn't lend itself to consolidating with this kind of implementation. How about putting sram-pool.c into the top-level mm/ directory and sram-pool.h into include/linux? They seem to be completely generic to me, aside from the dependency on asm/fncpy.h which should probably remain arch specific. I've thought about lib - but first lets see whether other architectures want to use it first. I've asked the sh folk off-list about this and waiting for a reply. Blackfin and PPC look horrible to sort out though, so they can come at a later date if they so wish. Yes, once the infrastructure is in place, powerpc can do its own migration to the new code. I vote for putting it in lib at the outset. g. -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 04:50:49PM +0200, Detlef Vollmann wrote: I'd love to have the mapping inside the create pool, but that might not be possible in general. No, think about it. What if you need to map the RAM area with some special attributes - eg, where ioremap() doesn't work. Eg, OMAP you need SRAM mapped as normal memory, except for OMAP34xx where it must be mapped normal memory non-cacheable. It's best to leave the mapping to the architecture. Another question is whether we should allow multiple SRAM pools or not - this code does allow multiple pools, but so far we only have one pool per SoC. Overdesign? Maybe, but it prevents SoCs wanting to duplicate it if they want to partition the SRAM, or have peripheral-local SRAMs. Having the option to partition the SRAM is probably useful. What I'm missing is sram_pool_add: on AT91SAM9G20 you have two banks of SRAM, and you might want to combine them into a single pool. Do you already combine them into a single pool, or is this a wishlist? I'm really not interested in sorting out peoples wishlist items in the process of consolidation. Second point is that you'll notice that the code converts to a phys address using this: phys = phys_base + (virt - virt_base). As soon as we start allowing multiple regions of SRAM, it becomes impossible to provide the phys address without a lot more complexity. arch/arm/common/sram-pool.c | 69 +++ arch/arm/include/asm/sram-pool.h| 20 Waht is ARM specific about this code? Why not put it into lib/ and include/linux, respectively? Nothing, but this is the first stage of consolidation of this code. I'm not trying to consolidate the universe down to one implementation here - that's going to take _far_ too much effort in one go, and from my previous experiences interacting with other arch maintainers, that's the way to get precisely nothing done. In my experience, arch maintainers tend to object to each others patches, and the net result is no forward progress. See dma_mmap API as a brilliant example of that - the lack of which contines to cause problems for drivers many years after I initially tried (and gave up) trying to get agreement on that. So, let's do what we can to consolidate our stuff and if we get some agreement from other arch maintainers, look towards moving it out. Moving stuff out once its properly modularized is trivial. -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote: Yes, once the infrastructure is in place, powerpc can do its own migration to the new code. I vote for putting it in lib at the outset. I don't agree with stuffing non-arch directories with code which people haven't already agreed should be shared. As I've already said, in my experience it's hard to get agreement in the first place and even when you can the API generally needs to be changed from what you first think would be reasonable. So, lets wait to see whether the SH folk reply. -- 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 v2] OMAP: iovmm: fix SW flags passed by user
Hi Hiroshi, On Fri, Mar 25, 2011 at 3:04 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: Commit d038aee24dcd5a2a0d8547f5396f67ae9698ac8e omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag, changes iovmm to receive flags specified by user, however the upper 16 bits of the flags are wiped by iovmm itself. This fixes IOVMF_DA_FIXED flags from being lost, and lets the user map its desired device addresses. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- v2: Include missing reference (commit and name) to patch in description. If no comments, could you ack this patch? Regards, Omar -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 08:39:55AM -0500, Rob Herring wrote: Russell, On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. It's more than that. Several i.MX chips use plat-mxc/iram_alloc.c. Hmm, that's nice - except for one issue. According to my grep of arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything in the MX stuff use iram_alloc.c, or is it dead code left over from a previous experiment? The commit says: ARM: imx: Add iram allocator functions Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR. The allocation size is 4KB multiples to guarantee alignment. The idea for these functions is for i.MX platforms to use them to dynamically allocate IRAM usage. Applies on 2.6.36-rc7 lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1 user). Both are doing a copy the suspend code to IRAM and run it which may also be a good thing to have generic code for. Several i.MX chips also need to run from IRAM for suspend. We have support for copying functions to other bits of memory and getting the Thumb-ness right - see asm/fncpy.h. So that's a separate patch to convert them over. -- 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: [RFC PATCH] Consolidate SRAM support
Le 15/04/2011 16:50, Detlef Vollmann : On 04/15/11 15:06, Russell King - ARM Linux wrote: This is work in progress. Thanks, very useful. [..] Another question is whether we should allow multiple SRAM pools or not - this code does allow multiple pools, but so far we only have one pool per SoC. Overdesign? Maybe, but it prevents SoCs wanting to duplicate it if they want to partition the SRAM, or have peripheral-local SRAMs. Having the option to partition the SRAM is probably useful. What I'm missing is sram_pool_add: on AT91SAM9G20 you have two banks of SRAM, and you might want to combine them into a single pool. In fact on at91sam9g20 (and some other at91) you can use the mirroring of the SRAM until next bank... so you end up with a single pool. Base @ sram1 base - sram0 size size = sram 0 size + sram 1 size Best regards, -- Nicolas Ferre -- 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: [RFC PATCH] Consolidate SRAM support
Hi Russell, -Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel- boun...@lists.infradead.org] On Behalf Of Russell King - ARM Linux Sent: Friday, April 15, 2011 11:04 AM To: Rob Herring Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [RFC PATCH] Consolidate SRAM support On Fri, Apr 15, 2011 at 08:39:55AM -0500, Rob Herring wrote: Russell, On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. It's more than that. Several i.MX chips use plat-mxc/iram_alloc.c. Hmm, that's nice - except for one issue. According to my grep of arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything in the MX stuff use iram_alloc.c, or is it dead code left over from a previous experiment? This function will be used for suspend code in the mx5x series. I just got done submitting a series of patches to Sascha for a simple suspend that does not need running code out of IRAM yet. The next set of suspend patches will be using these iram functions. The commit says: ARM: imx: Add iram allocator functions Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR. The allocation size is 4KB multiples to guarantee alignment. The idea for these functions is for i.MX platforms to use them to dynamically allocate IRAM usage. Applies on 2.6.36-rc7 lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1 user). Both are doing a copy the suspend code to IRAM and run it which may also be a good thing to have generic code for. Several i.MX chips also need to run from IRAM for suspend. We have support for copying functions to other bits of memory and getting the Thumb-ness right - see asm/fncpy.h. So that's a separate patch to convert them over. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote: Hmm, that's nice - except for one issue. According to my grep of arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything in the MX stuff use iram_alloc.c, or is it dead code left over from a previous experiment? This function will be used for suspend code in the mx5x series. I just got done submitting a series of patches to Sascha for a simple suspend that does not need running code out of IRAM yet. The next set of suspend patches will be using these iram functions. Okay, so does iram_alloc() need to return a dma_addr_t or a phys_addr_t ? Are you dealing with physical addresses for it or DMA addresses? -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 05:20:45PM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote:
Hmm, that's nice - except for one issue. According to my grep of
arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything in
the MX stuff use iram_alloc.c, or is it dead code left over from a
previous experiment?
This function will be used for suspend code in the mx5x series. I just
got done submitting a series of patches to Sascha for a simple suspend
that does not need running code out of IRAM yet. The next set of suspend
patches will be using these iram functions.
Okay, so does iram_alloc() need to return a dma_addr_t or a phys_addr_t ?
Are you dealing with physical addresses for it or DMA addresses?
And another question: why does iram_alloc() return a void __iomem * for
the virtual address, and the physical address via a pointer argument.
However, iram_free() take an unsigned long for the address.
It seems rather inconsistent that the parameter for free is returned via
a pointer argument.
If I convert this to sram-pool, can we change this to:
static inline void *iram_alloc(size_t size, phys_addr_t *phys_addr)
{
return sram_pool_alloc(iram_pool, size, phys_addr);
}
static void iram_free(void *addr, size_t size)
{
sram_pool_free(iram_pool, addr, size);
}
and:
int __init iram_init(unsigned long base, unsigned long size)
becomes:
int __init iram_init(phys_addr_t base, size_t size)
?
--
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/5] OMAP: DSS: fixes for rc
On Fri, Apr 15, 2011 at 1:11 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Some small fixes to OMAP DSS for the next rc. I will send a pull request to Paul Mundt soon if there are no problems with the patches. Tested on Overo (both 35XX and 37XX versions). This patch series fixes the earlier issue of no video output on 37XX boards. Tested-by: Steve Sakoman st...@sakoman.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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 08:12:07PM +0200, Detlef Vollmann wrote: Second point is that you'll notice that the code converts to a phys address using this: phys = phys_base + (virt - virt_base). As soon as we start allowing multiple regions of SRAM, it becomes impossible to provide the phys address without a lot more complexity. Yes, I understand that. This either requires some intrusive changes to gen_pool code or quite some additional code in sram_pool_alloc. It would require sram_pool to track each individual buffer alongside the similar tracking that gen_pool does, and then look up the returned address to find out which buffer it corresponds with. As it looks though, this functionality isn't required on AT91. So lets not complicate the code unless we know we have to. While the alloc/free API is such that it'll be able to cope if we have to add it later - the initialization will have to become a little more complex. And then I start to wonder if gen_pool should just be extended for the phys address. -- 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: [RFC PATCH] Consolidate SRAM support
On 14:06 Fri 15 Apr , Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
Let's unify this before we have additional SoCs re-implementing this
obviously common functionality themselves.
Unfortunately, we end up with code growth through doing this, but that
will become a win when we have another SoC using this (which I know
there's at least one in the pipeline).
One of the considerations here is that we can easily convert sram-pool.c
to hook into device tree stuff, which can tell the sram allocator:
- physical address of sram
- size of sram
- allocation granularity
and then we just need to ensure that it is appropriately mapped.
This uses the physical address, and unlike Davinci's dma address usage,
it always wants to have the physical address, and will always return
the corresponding physical address when passed that pointer.
OMAP could probably do with some more work to make the omapfb and other
allocations use the sram allocator, rather than hooking in before the
sram allocator is initialized - and then further cleanups so that we
have an initialization function which just does
sram_create(phys, size)
virt = map sram(phys, size)
create sram pool(virt, phys, size, min_alloc_order)
Another question is whether we should allow multiple SRAM pools or not -
this code does allow multiple pools, but so far we only have one pool
per SoC. Overdesign? Maybe, but it prevents SoCs wanting to duplicate
it if they want to partition the SRAM, or have peripheral-local SRAMs.
Lastly, uio_pruss should probably take the SRAM pool pointer via
platform data so that it doesn't have to include Davinci specific
includes.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Hi,
I also work on it for at91
and already have some patch in the mm for this
[PATCH] genalloc: add support to specify the physical address
so now you can do this
as I do on at91 will send the patch after
static struct map_desc at91sam9g20_sram_desc[] __initdata = {
{
.virtual= AT91_IO_VIRT_BASE - AT91SAM9G20_SRAM_SIZE,
.pfn= __phys_to_pfn(AT91SAM9G20_SRAM_BASE),
.length = AT91SAM9G20_SRAM_SIZE,
.type = MT_DEVICE,
}
};
sram_pool = gen_pool_create(2, -1);
gen_pool_add_virt(sram_pool, io_desc-virtual
__pfn_to_phys(io_desc-pfn),
io_desc-length, -1)
and to get the physical address
phys = gen_pool_virt_to_phys(sram_pool, virt);
Best Resgards,
J.
--
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: [RFC PATCH] Consolidate SRAM support
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, April 15, 2011 11:59 AM
To: Nguyen Dinh-R00091
Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com; Tony
Lindgren; Sekhar Nori; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 05:20:45PM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote:
Hmm, that's nice - except for one issue. According to my grep of
arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything in
the MX stuff use iram_alloc.c, or is it dead code left over from a
previous experiment?
This function will be used for suspend code in the mx5x series. I just
got done submitting a series of patches to Sascha for a simple suspend
that does not need running code out of IRAM yet. The next set of suspend
patches will be using these iram functions.
Okay, so does iram_alloc() need to return a dma_addr_t or a phys_addr_t ?
Are you dealing with physical addresses for it or DMA addresses?
And another question: why does iram_alloc() return a void __iomem * for
the virtual address, and the physical address via a pointer argument.
However, iram_free() take an unsigned long for the address.
Yes, should just be a void *iram_alloc().
It seems rather inconsistent that the parameter for free is returned via
a pointer argument.
If I convert this to sram-pool, can we change this to:
static inline void *iram_alloc(size_t size, phys_addr_t *phys_addr)
{
return sram_pool_alloc(iram_pool, size, phys_addr);
}
static void iram_free(void *addr, size_t size)
{
sram_pool_free(iram_pool, addr, size);
}
and:
int __init iram_init(unsigned long base, unsigned long size)
becomes:
int __init iram_init(phys_addr_t base, size_t size)
?
--
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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 07:20:12PM +, Nguyen Dinh-R00091 wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, April 15, 2011 11:59 AM
To: Nguyen Dinh-R00091
Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com; Tony
Lindgren; Sekhar Nori; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 05:20:45PM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote:
Hmm, that's nice - except for one issue. According to my grep of
arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything in
the MX stuff use iram_alloc.c, or is it dead code left over from a
previous experiment?
This function will be used for suspend code in the mx5x series. I just
got done submitting a series of patches to Sascha for a simple suspend
that does not need running code out of IRAM yet. The next set of suspend
patches will be using these iram functions.
Okay, so does iram_alloc() need to return a dma_addr_t or a phys_addr_t ?
Are you dealing with physical addresses for it or DMA addresses?
And another question: why does iram_alloc() return a void __iomem * for
the virtual address, and the physical address via a pointer argument.
However, iram_free() take an unsigned long for the address.
Yes, should just be a void *iram_alloc().
Thanks. As you didn't comment against the change below, I'm going to
assume that you're happy with it. It means that the usage changes from:
unsigned long dma;
void __iomem *addr = iram_alloc(SZ_4K, dma);
...
iram_free(dma, SZ_4K);
to:
phys_addr_t phys;
void *addr = iram_alloc(SZ_4K, phys);
...
iram_free(addr, SZ_4K);
It seems rather inconsistent that the parameter for free is returned via
a pointer argument.
If I convert this to sram-pool, can we change this to:
static inline void *iram_alloc(size_t size, phys_addr_t *phys_addr)
{
return sram_pool_alloc(iram_pool, size, phys_addr);
}
static void iram_free(void *addr, size_t size)
{
sram_pool_free(iram_pool, addr, size);
}
and:
int __init iram_init(unsigned long base, unsigned long size)
becomes:
int __init iram_init(phys_addr_t base, size_t size)
?
--
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: [RFC PATCH] Consolidate SRAM support
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, April 15, 2011 2:40 PM
To: Nguyen Dinh-R00091
Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com; Tony
Lindgren; Sekhar Nori; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 07:20:12PM +, Nguyen Dinh-R00091 wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, April 15, 2011 11:59 AM
To: Nguyen Dinh-R00091
Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com; Tony
Lindgren; Sekhar Nori;
linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 05:20:45PM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote:
Hmm, that's nice - except for one issue. According to my grep of
arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything
in
the MX stuff use iram_alloc.c, or is it dead code left over from a
previous experiment?
This function will be used for suspend code in the mx5x series. I just
got done submitting a series of patches to Sascha for a simple suspend
that does not need running code out of IRAM yet. The next set of suspend
patches will be using these iram functions.
Okay, so does iram_alloc() need to return a dma_addr_t or a phys_addr_t ?
Are you dealing with physical addresses for it or DMA addresses?
And another question: why does iram_alloc() return a void __iomem * for
the virtual address, and the physical address via a pointer argument.
However, iram_free() take an unsigned long for the address.
Yes, should just be a void *iram_alloc().
Thanks. As you didn't comment against the change below, I'm going to
assume that you're happy with it. It means that the usage changes from:
Sorry...yes, your proposal looks fine.
Thanks,
Dinh
unsigned long dma;
void __iomem *addr = iram_alloc(SZ_4K, dma);
...
iram_free(dma, SZ_4K);
to:
phys_addr_t phys;
void *addr = iram_alloc(SZ_4K, phys);
...
iram_free(addr, SZ_4K);
It seems rather inconsistent that the parameter for free is returned via
a pointer argument.
If I convert this to sram-pool, can we change this to:
static inline void *iram_alloc(size_t size, phys_addr_t *phys_addr)
{
return sram_pool_alloc(iram_pool, size, phys_addr);
}
static void iram_free(void *addr, size_t size)
{
sram_pool_free(iram_pool, addr, size);
}
and:
int __init iram_init(unsigned long base, unsigned long size)
becomes:
int __init iram_init(phys_addr_t base, size_t size)
?
--
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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 10:11:07PM +0200, Uwe Kleine-König wrote: On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. I havn't checked the details, but maybe the code in arch/arm/plat-mxc/iram_alloc.c could be migrated to your approach, too? Its already in there now that I have replies from Nguyen Dinh. It looks like this presently: arch/arm/plat-mxc/Kconfig |2 +- arch/arm/plat-mxc/include/mach/iram.h | 24 +++-- arch/arm/plat-mxc/iram_alloc.c | 50 +--- and if we get rid of the iram_alloc/iram_free wrappers around the sram_pool (now pv_pool) alloc/free in iram.h, in the same way I've done for Davinci, then we get less new additions too. -- 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: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 09:19:25PM +0100, Russell King - ARM Linux wrote: On Fri, Apr 15, 2011 at 10:11:07PM +0200, Uwe Kleine-König wrote: On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. I havn't checked the details, but maybe the code in arch/arm/plat-mxc/iram_alloc.c could be migrated to your approach, too? Its already in there now that I have replies from Nguyen Dinh. It looks like this presently: arch/arm/plat-mxc/Kconfig |2 +- arch/arm/plat-mxc/include/mach/iram.h | 24 +++-- arch/arm/plat-mxc/iram_alloc.c | 50 +--- and if we get rid of the iram_alloc/iram_free wrappers around the sram_pool (now pv_pool) alloc/free in iram.h, in the same way I've done for Davinci, then we get less new additions too. Great! Thanks, Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: [RFC PATCH] Consolidate SRAM support
Hi Russell, [CC Paul Mundt] On Sat, Apr 16, 2011 at 12:41 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote: Yes, once the infrastructure is in place, powerpc can do its own migration to the new code. I vote for putting it in lib at the outset. I don't agree with stuffing non-arch directories with code which people haven't already agreed should be shared. As I've already said, in my experience it's hard to get agreement in the first place and even when you can the API generally needs to be changed from what you first think would be reasonable. So, lets wait to see whether the SH folk reply. The SH arch is using NUMA for on-chip SRAM on some CPUs, but for SH-Mobile ARM we have no software support at this point. The SH/ARM hardware has a bunch of different on-chip memories in place, and they all have individual power management support through both clock gating and power domains. I assume other vendors have similar setups. I'd like to have some refcounting in place for the SRAM code if possible, which would trickle down to runtime pm get/put which in turn would allow us to control the power dynamically. Not sure how easy that would be to accomplish though. Paul may have some ideas on how to share the code between ARM and SH. Thanks, / magnus -- 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
