Re: [PATCH 4/6] omap iommu: simple virtual address space management
Hi Russell,
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [PATCH 4/6] omap iommu: simple virtual address space management
Date: Sat, 16 May 2009 11:22:48 +0200
On Tue, May 05, 2009 at 03:47:06PM +0300, Hiroshi DOYU wrote:
+int ioremap_page(unsigned long virt, unsigned long phys, unsigned int
mtype)
+{
+ const struct mem_type *type;
+
+ type = get_mem_type(mtype);
+ if (!type)
+ return -EINVAL;
I think it would make more sense to move this lookup into the caller
for this - you're going to be making quite a lot of calls into
ioremap_page() so you really don't want to be doing the same lookup
every time.
+/* map 'sglist' to a contiguous mpu virtual area and return 'va' */
+static void *vmap_sg(const struct sg_table *sgt)
+{
+ u32 va;
+ size_t total;
+ unsigned int i;
+ struct scatterlist *sg;
+ struct vm_struct *new;
+
+ total = sgtable_len(sgt);
+ if (!total)
+ return ERR_PTR(-EINVAL);
+
+ new = __get_vm_area(total, VM_IOREMAP, VMALLOC_START, VMALLOC_END);
+ if (!new)
+ return ERR_PTR(-ENOMEM);
+ va = (u32)new-addr;
In other words, move it here.
Right. In this change for better performance, I have to expose struct
mem_type and get_mem_type() a bit more as below. Is this change
acceptable, or do you have a better idea?
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 85a49e2..ad1cbc4 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -77,8 +77,17 @@ extern void __iounmap(volatile void __iomem *addr);
/*
* external interface to remap single page with appropriate type
*/
+struct mem_type {
+ unsigned int prot_pte;
+ unsigned int prot_l1;
+ unsigned int prot_sect;
+ unsigned int domain;
+};
+
+const struct mem_type *get_mem_type(unsigned int type);
+
extern int ioremap_page(unsigned long virt, unsigned long phys,
- unsigned int mtype);
+ const struct mem_type *mtype);
/*
* Bad read/write accesses...
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 8441351..0ab75c6 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -110,15 +110,10 @@ static int remap_area_pages(unsigned long start, unsigned
long pfn,
return err;
}
-int ioremap_page(unsigned long virt, unsigned long phys, unsigned int mtype)
+int ioremap_page(unsigned long virt, unsigned long phys,
+const struct mem_type *mtype)
{
- const struct mem_type *type;
-
- type = get_mem_type(mtype);
- if (!type)
- return -EINVAL;
-
- return remap_area_pages(virt, __phys_to_pfn(phys), PAGE_SIZE, type);
+ return remap_area_pages(virt, __phys_to_pfn(phys), PAGE_SIZE, mtype);
}
EXPORT_SYMBOL(ioremap_page);
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index 5d9f539..57f10aa 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -16,15 +16,6 @@ static inline pmd_t *pmd_off_k(unsigned long virt)
return pmd_off(pgd_offset_k(virt), virt);
}
-struct mem_type {
- unsigned int prot_pte;
- unsigned int prot_l1;
- unsigned int prot_sect;
- unsigned int domain;
-};
-
-const struct mem_type *get_mem_type(unsigned int type);
-
#endif
struct map_desc;
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index a539051..020f5af 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -167,6 +167,11 @@ static void *vmap_sg(const struct sg_table *sgt)
unsigned int i;
struct scatterlist *sg;
struct vm_struct *new;
+ const struct mem_type *mtype;
+
+ mtype = get_mem_type(MT_DEVICE);
+ if (!type)
+ return -EINVAL;
total = sgtable_len(sgt);
if (!total)
@@ -187,7 +192,7 @@ static void *vmap_sg(const struct sg_table *sgt)
BUG_ON(bytes != PAGE_SIZE);
- err = ioremap_page(va, pa, MT_DEVICE);
+ err = ioremap_page(va, pa, mtype);
if (err)
goto err_out;
--
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
Has anyone tried android BT HSP/HFP on Zoom2 beta board?
Hi there, See title. I think one of the hardest work to do is figuring out how to route digital audio from GSM modem to Omap processor via McBsp3. Could anyone give me some points? Thanks, Wang, Husheng -- 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][RFC] McSPI Slave and DMA,FIFO support
- Original Message -
From: Kevin Hilman khil...@deeprootsystems.com
Subject: Re: [PATCH][RFC] McSPI Slave and DMA,FIFO support
Hemanth V heman...@ti.com writes:
This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.
FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.
These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.
Signed-off-by: Hemanth V heman...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 19 +
arch/arm/mach-omap2/devices.c | 16 +
arch/arm/mach-omap2/mux.c | 11
arch/arm/plat-omap/include/mach/mcspi.h | 13 +
arch/arm/plat-omap/include/mach/mux.h |7
drivers/spi/omap2_mcspi.c | 353
6 files changed, 379 insertions(+), 40 deletions(-)
I think you should break this up into a series:
1) SPI driver changes (which could go upstream after review/approval)
2) mux changes
3) OMAP init changes (devices.c)
4) SDP changes, which are debug only
Where (2) and (3) could probably be combined.
Yes, will create a series of 3 patches.
Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2009-05-14
12:38:50.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2009-05-14
19:48:35.0 +0530
@@ -228,6 +228,13 @@
.single_channel = 1, /* 0: slave, 1: master */
};
+#ifdef CONFIG_SPI_DEBUG
+static struct omap2_mcspi_device_config dummy_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1, /* 0: slave, 1: master */
+};
+#endif
+
static struct spi_board_info sdp3430_spi_board_info[] __initdata = {
[0] = {
/*
@@ -242,6 +249,18 @@
.irq = 0,
.platform_data = tsc2046_config,
},
+#ifdef CONFIG_SPI_DEBUG
+ [1] = {
+ /* SPI test driver attached to SPI2 controller by
+ * default
+ */
+ .modalias = spitst,
+ .bus_num = 2,
+ .chip_select = 0,
+ .max_speed_hz = 150,
+ .controller_data = dummy_mcspi_config,
+ },
+#endif
};
static struct platform_device sdp3430_lcd_device = {
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-14
12:38:50.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-15
16:53:38.0
+0530
@@ -257,8 +257,12 @@
#define OMAP2_MCSPI3_BASE 0x480b8000
#define OMAP2_MCSPI4_BASE 0x480ba000
+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE 1
+
If these are to be 'mode' flags for 'struct
omap2_mcspi_platform_config' then they should be part of mcspi.h, not
defined here.
Will move them to mcspi.h
static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+ .force_cs_mode = 1,
};
static struct resource omap2_mcspi1_resources[] = {
@@ -281,6 +285,10 @@
static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+ .mode = OMAP2_MCSPI_MASTER,
+ .dma_mode = 1,
+ .force_cs_mode = 0,
+ .fifo_depth = 0,
Setting these init values to zero is redundant.
This is to serve as an easy reference for someone trying to enable these
features.
};
static struct resource omap2_mcspi2_resources[] = {
@@ -351,6 +359,14 @@
static void omap_init_mcspi(void)
{
+
+ if (cpu_is_omap3430()) {
+ omap_cfg_reg(AA3_3430_McSPI2_CLK);
+ omap_cfg_reg(Y2_3430_McSPI2_SIMO);
+ omap_cfg_reg(Y3_3430_McSPI2_SOMI);
+ omap_cfg_reg(Y4_3430_McSPI2_CS0);
+ }
+
platform_device_register(omap2_mcspi1);
platform_device_register(omap2_mcspi2);
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
Index: linux-omap-2.6/arch/arm/mach-omap2/mux.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/mux.c 2009-05-14
12:38:50.0
+0530
+++ linux-omap-2.6/arch/arm/mach-omap2/mux.c 2009-05-15
16:18:41.0 +0530
@@ -486,6 +486,17 @@
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+
+/* McSPI */
+MUX_CFG_34XX(AA3_3430_McSPI2_CLK, 0x1d6,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX(Y2_3430_McSPI2_SIMO, 0x1d8,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX(Y3_3430_McSPI2_SOMI, 0x1da,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX(Y4_3430_McSPI2_CS0, 0x1dc,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h
2009-05-14
Re: [PATCH][RFC] McSPI Slave and DMA,FIFO support
- Original Message -
From: Gadiyar, Anand gadi...@ti.com
To: V, Hemanth heman...@ti.com; Kevin Hilman
khil...@deeprootsystems.com
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-14
12:38:50.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-15
16:53:38.0 +0530
snip
};
static struct resource omap2_mcspi2_resources[] = {
@@ -351,6 +359,14 @@
static void omap_init_mcspi(void)
{
+
+ if (cpu_is_omap3430()) {
+ omap_cfg_reg(AA3_3430_McSPI2_CLK);
+ omap_cfg_reg(Y2_3430_McSPI2_SIMO);
+ omap_cfg_reg(Y3_3430_McSPI2_SOMI);
+ omap_cfg_reg(Y4_3430_McSPI2_CS0);
+ }
+
This will change the mux mode for these pads for all OMAP3 boards,
even if they do not wish to use McSPI2. In particular, Beagleboard
will be affected as it uses HSUSB on Port2 and these pads overlap.
I could add an option like below to plat-omap/Kconfig under
OMAP Feature Selections. Kevin, Your thoughts on this
config OMAP3430_ENABLE_SPI2_PIN_MUX
bool Enable SPI2 pin mux configuration for OMAP3430
depends on ARCH_OMAP3430
default n
help
Enable pin mux for SPI2 on OMAP3430 platform. Note
that the same pins are used for EHCI port2 operation. Hence
enabling this option effectively disables EHCI port 2 usage.
--
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 0/3] omap3-iommu: cleanups and remote registration
On Mon, May 18, 2009 at 8:16 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration Date: Sat, 16 May 2009 20:32:10 +0200 On Sat, May 16, 2009 at 7:36 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Sat, May 16, 2009 at 01:05:47PM +0300, Felipe Contreras wrote: This patch series cleanups up a bit the opap3-iommu device registration and then allows registration from other parts of the code. Currently the iva2 code (tidspbridge) is not using iommu, therefore it can't be used as-is with the current omap iommu. By allowing devies to be registered externaly (either isp, or iva2) this problem goes away. Hmm, so does this mean that the iommu patchset is going to grow by three patches? Hope not. This series has been posted for a long time and I want to get this in this time with minor fixes. I hope Hiroshi integrates my patches. I think that the problem of yours is that it's not necesary to allow device registration around kernel anywhere by omap_iommu_add() at all, but enough only in omap3-iommu.c. Since eventually tidspbridge will use this iommu framework, no need for this flexibility. Keeping same kind of device registration in one place is good thing from SoC perspective. So I want to avoid adding unnecessary flexibility to the code. I'll follow Russell's call, anyway. The first patch has nothing to do with omap_iommu_add, it's just cleanups, and you haven't provided any valid reason to reject them. The rest of the patches are *necessary* as of right now. IMHO iommu should not be merged in it's current state because it will break tidspbridge. Maybe after tidspbridge has been fully converted to use iommu. I think there will probably be a conversion period where the tidspbridge will use iommu optionally, in that period iommu would need to be patched and add a #ifdef MPU_BRIDGE_IOMMU, that would be ugly. Also you haven't answered my questions: what happens if you disable MPU_BRIDGE? What's the point of iommu to register the iva2 iommu device? My patches solves all of those issues. -- Felipe Contreras -- 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 0/3] omap3-iommu: cleanups and remote registration
On Mon, May 18, 2009 at 8:33 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration Date: Mon, 18 May 2009 08:16:27 +0300 (EEST) From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration Date: Sat, 16 May 2009 20:32:10 +0200 On Sat, May 16, 2009 at 7:36 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Sat, May 16, 2009 at 01:05:47PM +0300, Felipe Contreras wrote: This patch series cleanups up a bit the opap3-iommu device registration and then allows registration from other parts of the code. Currently the iva2 code (tidspbridge) is not using iommu, therefore it can't be used as-is with the current omap iommu. By allowing devies to be registered externaly (either isp, or iva2) this problem goes away. Hmm, so does this mean that the iommu patchset is going to grow by three patches? Hope not. This series has been posted for a long time and I want to get this in this time with minor fixes. I hope Hiroshi integrates my patches. I think that the problem of yours is that it's not necesary to allow device registration around kernel anywhere by omap_iommu_add() at all, but enough only in omap3-iommu.c. Since eventually tidspbridge will use this iommu framework, no need for this flexibility. Keeping same kind of device registration in one place is good thing from SoC perspective. So I want to avoid adding unnecessary flexibility to the code. I'll follow Russell's call, anyway. The other thing is about introducing a new structure type, struct iommu_device. I don't want to define new structure type just for this device registration. Since device registration part is kind of conventional one in kernel, I want to keep things simple/conventional as much as possible. It is an *internal* structure, just like you local 'omap3_iommu_pdata' nobody has not know about it outside omap3-iommu.c. The exported function is: struct platform_device *omap_iommu_add(const char *name); Nothing custom there. -- Felipe Contreras -- 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 1/3] omap3-iommu: reorganize
On Sat, May 16, 2009 at 01:05:48PM +0300, Felipe Contreras wrote:
+struct iommu_device {
+ resource_size_t base;
+ resource_size_t irq;
+ struct iommu_platform_data pdata;
+ struct resource res[2];
};
The data which is needed per device is:
- base address
- IRQ (no need for this to be resource_size_t - int will do)
- platform data
There's no need for that res[2] being there.
@@ -63,23 +51,35 @@ static int __init omap3_iommu_init(void)
for (i = 0; i NR_IOMMU_DEVICES; i++) {
struct platform_device *pdev;
+ const struct iommu_device *d = devices[i];
+ struct resource res[] = {
+ { .flags = IORESOURCE_MEM },
+ { .flags = IORESOURCE_IRQ },
+ };
This initialization doesn't buy you anything, in fact quite the opposite.
The compiler actually interprets this as:
static struct resource __initial_res[] = {
{ .flags = IORESOURCE_MEM },
{ .flags = IORESOURCE_IRQ },
};
...
for () {
struct resource res[...];
memcpy(res, __initial_res, sizeof(__initial_res));
+
+ res[0].start = d-base;
+ res[0].end = d-base + MMU_REG_SIZE - 1;
+
+ res[1].start = d-irq;
It would be far better to initialize the flags element here for both.
And please also set res[1].end as I did in my patch.
+
+ err = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
if (err)
goto err_out;
- err = platform_device_add_data(pdev, omap3_iommu_pdata[i],
-sizeof(omap3_iommu_pdata[0]));
+
+ err = platform_device_add_data(pdev, d-pdata,
sizeof(d-pdata));
This will fail checkpatch.
--
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: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap platform common sources.
Russell,
+static const char *omap4_dm_source_names[] __initdata = {
+ sys_ck,
+ omap_32k_fck,
+ NULL
+};
+static struct clk **omap4_dm_source_clocks[2];
Umm. struct clk **[2].
+static const int dm_timer_count = ARRAY_SIZE(omap4_dm_timers);
+
#else
#error OMAP architecture not supported!
@@ -461,7 +508,8 @@ __u32
omap_dm_timer_modify_idlect_mask(__u32 inputmask)
}
EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
-#elif defined(CONFIG_ARCH_OMAP2) || defined (CONFIG_ARCH_OMAP3)
+#elif defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
+ defined(CONFIG_ARCH_OMAP4)
struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
{
@@ -705,6 +753,10 @@ int __init omap_dm_timer_init(void)
dm_timers = omap3_dm_timers;
dm_source_names = (char **)omap3_dm_source_names;
dm_source_clocks = (struct clk
**)omap3_dm_source_clocks;
+ } else if (cpu_is_omap44xx()) {
+ dm_timers = omap4_dm_timers;
+ dm_source_names = (char **)omap4_dm_source_names;
+ dm_source_clocks = (struct clk
**)omap4_dm_source_clocks;
which then gets casted to a struct clk **. These are two different
objects. I don't think someone quite understood what they were
doing here and threw a cast in to shut up the compiler warning:
warning: assignment from incompatible pointer type
This is *very* wrong and is a prime example of why casts are _bad_
news. This cast is saying THERE IS A BUG HERE in 100ft
high letters.
What you want is:
static struct clk *omap4_dm_source_clocks[2];
...
dm_source_clocks = omap4_dm_source_clocks;
This is because struct clk *[] is equivalent to struct clk **.
(remember that arrays are handled in C as a pointer to the first
array element.)
OK. I will fix this for OMAP4 now. Will create patch for OMAP2/3 bit later.
As for the pointer to the array of names, why can't this be declared
const and therefore that cast be removed?
I am sorry but didn't get this point.
dm_source_names = (char **)omap4_dm_source_names;
In this 'omap4_dm_source_names' is already const. The problem is
dm_source_names is declared as 'char ** ' and hence compiler cribs for right
reasons without cast.
Did you mean don't declare 'omap4_dm_source_name' as const ?
TTOTD: Casts are bad news. It's far better to have stuff correctly
typed in the first place.
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: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap platform common sources.
On Mon, May 18, 2009 at 05:37:24PM +0530, Shilimkar, Santosh wrote: As for the pointer to the array of names, why can't this be declared const and therefore that cast be removed? I am sorry but didn't get this point. dm_source_names = (char **)omap4_dm_source_names; In this 'omap4_dm_source_names' is already const. The problem is dm_source_names is declared as 'char ** ' and hence compiler cribs for right reasons without cast. Did you mean don't declare 'omap4_dm_source_name' as const ? No, I'm saying dm_source_names should also be const. -- 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 3/3] Regulator: Added board-dependent code for TPS65023
-Original Message-
From: Mark Brown [mailto:broo...@sirena.org.uk]
Sent: Saturday, May 09, 2009 1:45 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; l...@slimlogic.co.uk
Subject: Re: [PATCH 3/3] Regulator: Added board-dependent code for
TPS65023
On Fri, May 08, 2009 at 08:42:16PM +0530, Anuj Aggarwal wrote:
Added OMAP3 EVM specific code for TPS65023 in pmic.c file.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
CCing in Liam again.
---
drivers/regulator/pmic.c | 92
++
1 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/pmic.c b/drivers/regulator/pmic.c
index 36ed341..6e7276a 100644
--- a/drivers/regulator/pmic.c
+++ b/drivers/regulator/pmic.c
@@ -29,6 +29,96 @@
/*
* Definitions specific to TPS65023
*/
+#if defined(CONFIG_OMAP3EVM_TPS65023)
+/* MPU voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_mpu_consumers = {
+ .supply = vdd1,
+};
This comes back to my questions about pmic.c but I'd expect this all to
appear in the OMAP3 EVM code.
[Aggarwal, Anuj] Same reason given in my other email. Just to avoid duplication
of the code, I have created this file and moved all the code from board-*.c to
this place.
The same file will be populated for other PMICs, coming on OMAP based platforms
in future.
+
+/* CORE voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_core_consumers = {
+ .supply = vdd2,
+};
+
+/* SRAM/MEM/WKUP_BG voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_vdds_consumers = {
+ .supply = vdds,
+};
+
+/* DPLL voltage regulator of LDO type */
+struct regulator_consumer_supply tps65023_dpll_consumers = {
+ .supply = dpll,
+};
+
+/* MMC voltage regulator of LDO type */
+struct regulator_consumer_supply tps65023_mmc_consumers = {
+ .supply = mmc,
+};
+
+struct regulator_init_data tps65023_regulator_data[] = {
+ {
+ .constraints = {
+ .min_uV = 80,
+ .max_uV = 160,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_mpu_consumers,
+ },
+ {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 330,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_core_consumers,
+ },
+ {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 330,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_vdds_consumers,
+ },
+ {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 315,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_dpll_consumers,
+ },
+ {
+ .constraints = {
+ .min_uV = 105,
+ .max_uV = 330,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_mmc_consumers,
+ },
+};
+
+static struct i2c_board_info __initdata board_tps65023_instances[] = {
+ {
+ I2C_BOARD_INFO(tps65023, 0x48),
+ .flags = I2C_CLIENT_WAKE,
+ .platform_data = tps65023_regulator_data[0],
+ },
+};
+#endif
static int flag_pmic_twl4030;
static int flag_pmic_tps6235x;
@@ -96,6 +186,8 @@ int pmic_init(void)
#if defined(CONFIG_OMAP3EVM_TPS65023)
/* do stuff specific to TPS65023 */
+ omap_register_i2c_bus(1, 400, board_tps65023_instances,
+ ARRAY_SIZE(board_tps65023_instances));
#endif
return 0;
--
1.6.2.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
--
You grabbed my hand and we fell into it, like a daydream - or a fever.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: This allows devices to be registered only when they are used. The current dsp-bridge driver for example is not using iommu so registering the iommu iva2 device would conflict. By allowing remote registration the dsp-bridge can decide when the iommu iva2 device is registered. I don't think that this is a good idea - what happens if two people call omap_iommu_add() for the same IOMMU device independently? Hmm, right, some extra checks would be needed to see if the device is already registered and then increase some refcount. That's more complicated that I was hoping for. The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. The bridgedriver is expected to move and use iommu eventually, but not right now, so I guess the iva2 device should be registered only if MPU_BRIDGE_IOMMU is defined. But then what's the point of having the isp iommu device if the camera driver is disabled? Wouldn't that be wasting resources? Then if CAMERA is not defined the isp device should not be registered either. And finally if none of the two are enabled then you don't really iommu. By having omap_iommu_add all the dependencies would be handled automatically, right? 'modprobe bridgedriver' would load iommu. -- Felipe Contreras -- 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 1/3] omap3-iommu: reorganize
On Mon, May 18, 2009 at 3:07 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sat, May 16, 2009 at 01:05:48PM +0300, Felipe Contreras wrote:
+struct iommu_device {
+ resource_size_t base;
+ resource_size_t irq;
+ struct iommu_platform_data pdata;
+ struct resource res[2];
};
The data which is needed per device is:
- base address
- IRQ (no need for this to be resource_size_t - int will do)
- platform data
There's no need for that res[2] being there.
Right, I was using 'res' but not any more; I forgot to remove it.
So resource_size_t is ok for 'base'?
@@ -63,23 +51,35 @@ static int __init omap3_iommu_init(void)
for (i = 0; i NR_IOMMU_DEVICES; i++) {
struct platform_device *pdev;
+ const struct iommu_device *d = devices[i];
+ struct resource res[] = {
+ { .flags = IORESOURCE_MEM },
+ { .flags = IORESOURCE_IRQ },
+ };
This initialization doesn't buy you anything, in fact quite the opposite.
The compiler actually interprets this as:
static struct resource __initial_res[] = {
{ .flags = IORESOURCE_MEM },
{ .flags = IORESOURCE_IRQ },
};
...
for () {
struct resource res[...];
memcpy(res, __initial_res, sizeof(__initial_res));
+
+ res[0].start = d-base;
+ res[0].end = d-base + MMU_REG_SIZE - 1;
+
+ res[1].start = d-irq;
It would be far better to initialize the flags element here for both.
And please also set res[1].end as I did in my patch.
I think I saw that res initialization somewhere and I found it much
easier to read.
Ok. Will do.
+
+ err = platform_device_add_resources(pdev, res,
ARRAY_SIZE(res));
if (err)
goto err_out;
- err = platform_device_add_data(pdev, omap3_iommu_pdata[i],
- sizeof(omap3_iommu_pdata[0]));
+
+ err = platform_device_add_data(pdev, d-pdata,
sizeof(d-pdata));
This will fail checkpatch.
I'll make sure it passes.
Cheers.
--
Felipe Contreras
--
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 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote: On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. The bridgedriver is expected to move and use iommu eventually, but not right now, so I guess the iva2 device should be registered only if MPU_BRIDGE_IOMMU is defined. But then what's the point of having the isp iommu device if the camera driver is disabled? Wouldn't that be wasting resources? Then if CAMERA is not defined the isp device should not be registered either. So have something like: config OMAP_IOMMU tristate and then have both MPU_BRIDGE_IOMMU and the camera support (and whatever else) select it. That way, you only end up with the IOMMU support code built into the kernel if you have users of it. These low-level internal services drivers really don't need to be publically visible in the configuration system. As for the run-time size, that's truely minimal. And finally if none of the two are enabled then you don't really iommu. By having omap_iommu_add all the dependencies would be handled automatically, right? 'modprobe bridgedriver' would load iommu. Think about it - the dependencies _already_ have to be there to use the iommu services. -- 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/3] Regulator: Add pmic.c file to regulator framework
On Mon, May 18, 2009 at 05:50:31PM +0530, Aggarwal, Anuj wrote: The kernel already provides facilities for detecting the presence of devices. In cases where it is possible to do a generic check for a [Aggarwal, Anuj] In my opinion, it would not be a good idea to probe for several PMICs, on all the buses present in the system. It can be simplified by probing only the ones which are relevant for this device. The point here is that the kernel already provides for doing device enumeration of all kinds, both static and dynamic, and that adding this file doesn't add anything except copying of the code from arch/arm into drivers/regulator. Another thing here is that the code appears to assume that there will be only one regulator device in the system which isn't always true. Some designs will use a series of discrete regulators rather than integrated chips while others will use several integrated PMICs for reasons such as ease of layout or power distribution. [Aggarwal, Anuj] Can you explain this, I didn't get that much? Instead of having a single PMIC with multiple regulator outputs a system may choose to have several regulators. One way this can happen is that some manufacturers produce simple discrete regulator chips which produce only a single output - typically several of these would be needed in a system. Another approach which cause this to come up some systems use is to have more than one PMIC, for example having one PMIC for the main application processor and a second PMIC providing supplies used by a coprocessor. This can avoid electrical issues by allowing shorter tracks for the regulated supplies and simplifying routing. [Aggarwal, Anuj] You are right, the primary purpose of this patch is to avoid duplication of PMIC code, common to many OMAP platforms and I believe this is a simpler and cleaner approach. Instead of keeping this file in the drivers/regulator folder, we can move it to arch/arm/mach-omap2 folder. This sounds like a good approach. -- 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/6] omap iommu: simple virtual address space management
On Mon, May 18, 2009 at 09:31:26AM +0300, Hiroshi DOYU wrote: Right. In this change for better performance, I have to expose struct mem_type and get_mem_type() a bit more as below. Is this change acceptable, or do you have a better idea? You don't need to expose struct mem_type at all. You only need to tell the compiler that it exists and is valid by: struct mem_type; Then you can use it in function prototypes without complaint. I'd also prefer to hide ioremap_page() and get_mem_type() outside of the normal Linux headers - maybe in asm/mach/map.h. -- 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core linux-omap PM code with mainline. This
code has evolved and been used for a while the linux-omap tree, but
the attempt here is to finally get this into mainline.
Following this will be a series of patches from the 'PM branch' of the
linux-omap tree to add full PM hardware support from the linux-omap
tree.
Much of this PM core code was written by Jouni Hogander with
significant contributions from Paul Walmsley as well as many others
from Nokia, Texas Instruments and linux-omap community.
Overall comment, I think we need to rework the idle support code so
that enable_hlt/disable_hlt can be used even when pm_idle has been
overridden, rather than OMAP going off and inventing its own mechanisms.
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
new file mode 100644
index 000..2a2d1a3
--- /dev/null
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -0,0 +1,557 @@
+/*
+ * OMAP2 Power Management Routines
+ *
+ * Copyright (C) 2005 Texas Instruments, Inc.
+ * Copyright (C) 2006-2008 Nokia Corporation
+ *
+ * Written by:
+ * Richard Woodruff r-woodru...@ti.com
+ * Tony Lindgren
+ * Juha Yrjola
+ * Amit Kucheria amit.kuche...@nokia.com
+ * Igor Stoppa igor.sto...@nokia.com
+ *
+ * Based on pm.c for omap1
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/suspend.h
+#include linux/sched.h
+#include linux/proc_fs.h
+#include linux/interrupt.h
+#include linux/sysfs.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/time.h
+
+#include asm/mach/time.h
+#include asm/mach/irq.h
+#include asm/mach-types.h
+
+#include mach/irqs.h
+#include mach/clock.h
+#include mach/sram.h
+#include mach/control.h
+#include mach/gpio.h
Should be linux/gpio.h
+/*
+ * Note that you can use clock_event_device-min_delta_ns if you want to
+ * avoid reprogramming timer too often when using CONFIG_NO_HZ.
+ */
+static void omap2_pm_idle(void)
+{
+ local_irq_disable();
+ local_fiq_disable();
+
+ if (!omap2_can_sleep()) {
+ if (!atomic_read(sleep_block) omap2_irq_pending())
+ goto out;
+ omap2_enter_mpu_retention();
+ goto out;
+ }
+
+ if (omap2_irq_pending())
+ goto out;
+
+ omap2_enter_full_retention();
+
+out:
+ local_fiq_enable();
+ local_irq_enable();
+}
It's totally unclear what the comment above the function has to do with
the function itself.
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
new file mode 100644
index 000..0fb6bec
--- /dev/null
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -0,0 +1,607 @@
+/*
+ * OMAP3 Power Management Routines
+ *
+ * Copyright (C) 2006-2008 Nokia Corporation
+ * Tony Lindgren t...@atomide.com
+ * Jouni Hogander
+ *
+ * Copyright (C) 2005 Texas Instruments, Inc.
+ * Richard Woodruff r-woodru...@ti.com
+ *
+ * Based on pm.c for omap1
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/pm.h
+#include linux/suspend.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/list.h
+#include linux/err.h
+
+#include mach/gpio.h
Should be linux/gpio.h
+static void omap3_pm_idle(void)
+{
+ local_irq_disable();
+ local_fiq_disable();
+
+ if (!omap3_can_sleep())
+ goto out;
+
+ if (omap_irq_pending())
+ goto out;
So what happens if an IRQ becomes pending at this precise point?
+
+ omap_sram_idle();
+
+out:
+ local_fiq_enable();
+ local_irq_enable();
+}
+ /* IRQ mode */
+ bicr0, r7, #0x1F
+ orrr0, r0, #0x12
+ msrcpsr, r0 /*go into IRQ mode*/
+ ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM*/
+ movsp, r4 /*update the SP */
+ movlr, r5 /*update the LR */
+ msrspsr, r6 /*update the SPSR */
+
+ /* ABORT mode */
+ bicr0, r7, #0x1F
+ orrr0, r0, #0x17
+ msrcpsr, r0 /* go into ABORT mode */
+ ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM */
+ movsp, r4 /*update the SP */
+ movlr, r5 /*update the LR */
+ msrspsr, r6 /*update the SPSR */
+
+ /* UNDEEF mode */
+ bicr0, r7, #0x1F
+ orrr0, r0, #0x1B
+ msrcpsr, r0 /*go into UNDEF mode */
+ ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM */
+ movsp, r4 /*update the SP*/
+ movlr, r5
Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 14:11:13 +0200 On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: This allows devices to be registered only when they are used. The current dsp-bridge driver for example is not using iommu so registering the iommu iva2 device would conflict. By allowing remote registration the dsp-bridge can decide when the iommu iva2 device is registered. I don't think that this is a good idea - what happens if two people call omap_iommu_add() for the same IOMMU device independently? The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. How about the attached patch? I think this is enough. 0001-omap-iommu-disable-iva2-iommu-device-registration-i.patch Description: Binary data
Re: [PATCH 5/6] omap iommu: entries for Kconfig and Makefile
On Tue, May 05, 2009 at 03:47:11PM +0300, Hiroshi DOYU wrote: +config OMAP_IOMMU + tristate IOMMU support + depends on ARCH_OMAP + default n default n is the default whatever. There's no need for the depends line either - the whole file is protected by an if ARCH_OMAP..endif encapsulation. -- 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 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 04:21:19PM +0300, Felipe Contreras wrote: On Mon, May 18, 2009 at 4:02 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote: On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. The bridgedriver is expected to move and use iommu eventually, but not right now, so I guess the iva2 device should be registered only if MPU_BRIDGE_IOMMU is defined. But then what's the point of having the isp iommu device if the camera driver is disabled? Wouldn't that be wasting resources? Then if CAMERA is not defined the isp device should not be registered either. So have something like: config OMAP_IOMMU tristate and then have both MPU_BRIDGE_IOMMU and the camera support (and whatever else) select it. That way, you only end up with the IOMMU support code built into the kernel if you have users of it. These low-level internal services drivers really don't need to be publically visible in the configuration system. Yeap, that needs to be done too. As for the run-time size, that's truely minimal. I thought creating iommu devices involved some kind of overhead, allocating some resources probably. That's why the iva2 iommu device conflicts with tidspbridge custom mmu. I believe I've already said how to handle that - in fact it's in the quoted messages at the top of this mail. And finally if none of the two are enabled then you don't really iommu. By having omap_iommu_add all the dependencies would be handled automatically, right? 'modprobe bridgedriver' would load iommu. Think about it - the dependencies _already_ have to be there to use the iommu services. Ok, yes, for iommu, but not for omap3-iommu which is a separate module. That is a point, but I think it's a relatively minor one. We could get around that by ensuring that omap3-iommu is always built-in if we have the possibility of iommu support, and leave iommu as a module. -- 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 0/3] omap3-iommu: cleanups and remote registration
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration Date: Mon, 18 May 2009 13:48:09 +0200 On Mon, May 18, 2009 at 8:16 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration Date: Sat, 16 May 2009 20:32:10 +0200 On Sat, May 16, 2009 at 7:36 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Sat, May 16, 2009 at 01:05:47PM +0300, Felipe Contreras wrote: This patch series cleanups up a bit the opap3-iommu device registration and then allows registration from other parts of the code. Currently the iva2 code (tidspbridge) is not using iommu, therefore it can't be used as-is with the current omap iommu. By allowing devies to be registered externaly (either isp, or iva2) this problem goes away. Hmm, so does this mean that the iommu patchset is going to grow by three patches? Hope not. This series has been posted for a long time and I want to get this in this time with minor fixes. I hope Hiroshi integrates my patches. I think that the problem of yours is that it's not necesary to allow device registration around kernel anywhere by omap_iommu_add() at all, but enough only in omap3-iommu.c. Since eventually tidspbridge will use this iommu framework, no need for this flexibility. Keeping same kind of device registration in one place is good thing from SoC perspective. So I want to avoid adding unnecessary flexibility to the code. I'll follow Russell's call, anyway. The first patch has nothing to do with omap_iommu_add, it's just cleanups, and you haven't provided any valid reason to reject them. Your code doesn't work since the other members of struct resource haven't been initilialized like: + memset(res, 0, sizeof(res)); Please refer to: http://marc.info/?l=linux-omapm=124263966231599w=2 The rest of the patches are *necessary* as of right now. IMHO iommu should not be merged in it's current state because it will break tidspbridge. Maybe after tidspbridge has been fully converted to use iommu. I think there will probably be a conversion period where the tidspbridge will use iommu optionally, in that period iommu would need to be patched and add a #ifdef MPU_BRIDGE_IOMMU, that would be ugly. How about: http://lists.arm.linux.org.uk/lurker/attach/3...@20090518.133533.487a3dd4.attach Also you haven't answered my questions: what happens if you disable MPU_BRIDGE? What's the point of iommu to register the iva2 iommu device? enough small to ignore. My patches solves all of those issues. -- Felipe Contreras -- 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 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 4:35 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 14:11:13 +0200 On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: This allows devices to be registered only when they are used. The current dsp-bridge driver for example is not using iommu so registering the iommu iva2 device would conflict. By allowing remote registration the dsp-bridge can decide when the iommu iva2 device is registered. I don't think that this is a good idea - what happens if two people call omap_iommu_add() for the same IOMMU device independently? The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. How about the attached patch? I think this is enough. That wouldn't work when bridgedriver moves to iommu, how about: +#if !defined(CONFIG_MPU_BRIDGE) !defined(CONFIG_OMAP_DSP_MODULE) +#if defined(CONFIG_MPU_BRIDGE_IOMMU) -- Felipe Contreras -- 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 3/3] omap3-iommu: remote registration
From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 16:35:33 +0300 (EEST) From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 14:11:13 +0200 On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: This allows devices to be registered only when they are used. The current dsp-bridge driver for example is not using iommu so registering the iommu iva2 device would conflict. By allowing remote registration the dsp-bridge can decide when the iommu iva2 device is registered. I don't think that this is a good idea - what happens if two people call omap_iommu_add() for the same IOMMU device independently? The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. How about the attached patch? I think this is enough. Oops, CONFIG_NAME was wrong. Attached new one. 0001-omap-iommu-disable-iva2-iommu-device-registration-i.patch Description: Binary data
Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 15:52:59 +0200 On Mon, May 18, 2009 at 4:35 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 14:11:13 +0200 On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: This allows devices to be registered only when they are used. The current dsp-bridge driver for example is not using iommu so registering the iommu iva2 device would conflict. By allowing remote registration the dsp-bridge can decide when the iommu iva2 device is registered. I don't think that this is a good idea - what happens if two people call omap_iommu_add() for the same IOMMU device independently? The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. How about the attached patch? I think this is enough. That wouldn't work when bridgedriver moves to iommu, how about: +#if !defined(CONFIG_MPU_BRIDGE) !defined(CONFIG_OMAP_DSP_MODULE) +#if defined(CONFIG_MPU_BRIDGE_IOMMU) Just now I read Russell's proposal. This would be better. Agreed. How about Hari? I think that he's been working on this for a while -- 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 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 4:40 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, May 18, 2009 at 04:21:19PM +0300, Felipe Contreras wrote: On Mon, May 18, 2009 at 4:02 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote: On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. The bridgedriver is expected to move and use iommu eventually, but not right now, so I guess the iva2 device should be registered only if MPU_BRIDGE_IOMMU is defined. But then what's the point of having the isp iommu device if the camera driver is disabled? Wouldn't that be wasting resources? Then if CAMERA is not defined the isp device should not be registered either. So have something like: config OMAP_IOMMU tristate and then have both MPU_BRIDGE_IOMMU and the camera support (and whatever else) select it. That way, you only end up with the IOMMU support code built into the kernel if you have users of it. These low-level internal services drivers really don't need to be publically visible in the configuration system. Yeap, that needs to be done too. As for the run-time size, that's truely minimal. I thought creating iommu devices involved some kind of overhead, allocating some resources probably. That's why the iva2 iommu device conflicts with tidspbridge custom mmu. I believe I've already said how to handle that - in fact it's in the quoted messages at the top of this mail. And finally if none of the two are enabled then you don't really iommu. By having omap_iommu_add all the dependencies would be handled automatically, right? 'modprobe bridgedriver' would load iommu. Think about it - the dependencies _already_ have to be there to use the iommu services. Ok, yes, for iommu, but not for omap3-iommu which is a separate module. That is a point, but I think it's a relatively minor one. We could get around that by ensuring that omap3-iommu is always built-in if we have the possibility of iommu support, and leave iommu as a module. You mean omap3-iommu will be built-in in the iommu module? That looks ok to me, *if* it's true that iommu devices don't waste any significant resources if nobody is using them. -- Felipe Contreras -- 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 3/6] omap iommu: omap3 iommu device registration
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
Date: Sat, 16 May 2009 11:55:14 +0200
On Sat, May 16, 2009 at 10:20:36AM +0100, Russell King - ARM Linux wrote:
This looks all very convoluted. Why not do something like:
static unsigned long iommu_base[] = {
OMAP3_MMU1_BASE,
OMAP3_MMU2_BASE,
};
static int iommu_irq[] = {
OMAP3_MMU1_IRQ,
OMAP3_MMU2_IRQ,
};
BTW, both of these can be __initdata.
Attached the updated one.
From 2bfdb4130433708dc04e1c30aa5099d48de408e0 Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU hiroshi.d...@nokia.com
Date: Wed, 28 Jan 2009 21:32:04 +0200
Subject: [PATCH 3/6] omap iommu: omap3 iommu device registration
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/omap3-iommu.c | 103 +
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap3-iommu.c
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
new file mode 100644
index 000..91ee38a
--- /dev/null
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -0,0 +1,103 @@
+/*
+ * omap iommu: omap3 device registration
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/platform_device.h
+
+#include mach/iommu.h
+
+#define OMAP3_MMU1_BASE0x480bd400
+#define OMAP3_MMU2_BASE0x5d00
+#define OMAP3_MMU1_IRQ 24
+#define OMAP3_MMU2_IRQ 28
+
+
+static unsigned long iommu_base[] __initdata = {
+ OMAP3_MMU1_BASE,
+ OMAP3_MMU2_BASE,
+};
+
+static int iommu_irq[] __initdata = {
+ OMAP3_MMU1_IRQ,
+ OMAP3_MMU2_IRQ,
+};
+
+static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
+ {
+ .name = isp,
+ .nr_tlb_entries = 8,
+ .clk_name = cam_ick,
+ },
+ {
+ .name = iva2,
+ .nr_tlb_entries = 32,
+ .clk_name = iva2_ck,
+ },
+};
+#define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
+
+static struct platform_device *omap3_iommu_pdev[NR_IOMMU_DEVICES];
+
+static int __init omap3_iommu_init(void)
+{
+ int i, err;
+
+ for (i = 0; i NR_IOMMU_DEVICES; i++) {
+ struct platform_device *pdev;
+ struct resource res[2];
+
+ pdev = platform_device_alloc(omap-iommu, i);
+ if (!pdev) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ memset(res, 0, sizeof(res));
+ res[0].start = iommu_base[i];
+ res[0].end = iommu_base[i] + MMU_REG_SIZE - 1;
+ res[0].flags = IORESOURCE_MEM;
+ res[1].start = res[1].end = iommu_irq[i];
+ res[1].flags = IORESOURCE_IRQ;
+
+ err = platform_device_add_resources(pdev, res,
+ ARRAY_SIZE(res));
+ if (err)
+ goto err_out;
+ err = platform_device_add_data(pdev, omap3_iommu_pdata[i],
+ sizeof(omap3_iommu_pdata[0]));
+ if (err)
+ goto err_out;
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_out;
+ omap3_iommu_pdev[i] = pdev;
+ }
+ return 0;
+
+err_out:
+ while (i--)
+ platform_device_put(omap3_iommu_pdev[i]);
+ return err;
+}
+module_init(omap3_iommu_init);
+
+static void __exit omap3_iommu_exit(void)
+{
+ int i;
+
+ for (i = 0; i NR_IOMMU_DEVICES; i++)
+ platform_device_unregister(omap3_iommu_pdev[i]);
+}
+module_exit(omap3_iommu_exit);
+
+MODULE_AUTHOR(Hiroshi DOYU);
+MODULE_DESCRIPTION(omap iommu: omap3 device registration);
+MODULE_LICENSE(GPL v2);
--
1.6.0.4
[PATCH] usb: disable OTG AUTOIDLE only with omap3430
Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG register prevents the device from going into retention. This is a workaround (by Richard Woodruff/TI), as his comment : A new MUSB bug which is a match to data below was identified very recently (on hardware and in simulation). This bug is in 3430 and not 3630. As a priority test (and as new default) you should have engineers disable autoidle for MUSB block. This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen ext-niilo.1.minkki...@nokia.com --- drivers/usb/musb/omap2430.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 901dffd..396fc6d 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -241,7 +241,12 @@ int __init musb_platform_init(struct musb *musb) l = ~AUTOIDLE; /* disable auto idle */ l = ~NOIDLE; /* remove possible noidle */ l |= SMARTIDLE; /* enable smart idle */ - l |= AUTOIDLE; /* enable auto idle */ + /* +* MUSB AUTOIDLE don't work in 3430. +* Workaround by Richard Woodruff/TI +*/ + if (!cpu_is_omap3430()) + l |= AUTOIDLE; /* enable auto idle */ omap_writel(l, OTG_SYSCONFIG); l = omap_readl(OTG_INTERFSEL); -- 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: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap platform common sources.
* Shilimkar, Santosh santosh.shilim...@ti.com [090516 13:04]:
Thanks Russell for scanning all the patches minutely !!
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Saturday, May 16, 2009 3:24 PM
To: Shilimkar, Santosh
Cc: linux-arm-ker...@lists.arm.linux.org.uk;
linux-omap@vger.kernel.org
Subject: Re: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap
platform common sources.
On Thu, May 07, 2009 at 11:59:13AM +0530, Santosh Shilimkar wrote:
@@ -309,3 +313,26 @@ void __init omap2_set_globals_343x(void)
}
#endif
+#if defined(CONFIG_ARCH_OMAP4)
+static struct omap_globals *omap4_globals;
+
+static void __init __omap4_set_globals(void)
+{
+ omap2_set_globals_tap(omap4_globals);
+ omap2_set_globals_control(omap4_globals);
+}
+static struct omap_globals omap443x_globals = {
+ .class = OMAP443X_CLASS,
+ .tap= OMAP2_IO_ADDRESS(0x4830A000),
+ .ctrl = OMAP2_IO_ADDRESS(OMAP443X_CTRL_BASE),
+ .prm= OMAP2_IO_ADDRESS(OMAP4430_PRM_BASE),
+ .cm = OMAP2_IO_ADDRESS(OMAP4430_CM_BASE),
+};
+
+void __init omap2_set_globals_443x(void)
+{
+ omap4_globals = omap443x_globals;
+ __omap4_set_globals();
Hmm, confused. omap4_globals is a static variable, and
__omap4_set_globals
is a static function. The only user of omap4_globals is
__omap4_set_globals.
It looks to me like the only purpose of omap4_globals is to pass a
structure to __omap4_set_globals. Why not use a function
argument instead?
Indeed. Actually I just more or less followed what is done for OMAP2/OMAP3
here. I will clean this for OMAP4.
Tony,
We may want to clean up this for OMAP2/OMAP3 as well. Can we add this to the
clean up patches planned if any. I can create the patch.
Sure, please post that patch for review.
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: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap platform common sources.
is a static function. The only user of omap4_globals is __omap4_set_globals. It looks to me like the only purpose of omap4_globals is to pass a structure to __omap4_set_globals. Why not use a function argument instead? Indeed. Actually I just more or less followed what is done for OMAP2/OMAP3 here. I will clean this for OMAP4. Tony, We may want to clean up this for OMAP2/OMAP3 as well. Can we add this to the clean up patches planned if any. I can create the patch. Sure, please post that patch for review. OK 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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote: stanley.miao stanley.m...@windriver.com writes: Looks like you used the CodeSourcery 2007q3 toolchain. This had been reported earlier. Switching to 2008q3 works. Yeah, Now the kernel booted. it's compiler's problem. I was bitten by the same problem few weeks ago. Any chance of getting a warning/error if using 2007q3 compiler until the problem is fixed? Is there any way of detecting the 2007q3 compiler? With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ to identify the three digit version number. I don't know, most probably not. But Jon Hunter investigated the issue and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html So maybe we can fix or workaround this. -- Kalle Valo -- 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_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote: stanley.miao stanley.m...@windriver.com writes: Looks like you used the CodeSourcery 2007q3 toolchain. This had been reported earlier. Switching to 2008q3 works. Yeah, Now the kernel booted. it's compiler's problem. I was bitten by the same problem few weeks ago. Any chance of getting a warning/error if using 2007q3 compiler until the problem is fixed? Is there any way of detecting the 2007q3 compiler? With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ to identify the three digit version number. I don't know, most probably not. But Jon Hunter investigated the issue and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html So maybe we can fix or workaround this. Why does this change anything? FRAME_POINTERS seems to be enabled anyway (and should be given the Kconfig setup we have.) -- 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] omap3-iommu: reorganize
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
How about this?
arch/arm/mach-omap2/omap3-iommu.c | 53 ++---
1 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
index 91ee38a..50bd445 100644
--- a/arch/arm/mach-omap2/omap3-iommu.c
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -14,32 +14,30 @@
#include mach/iommu.h
-#define OMAP3_MMU1_BASE0x480bd400
-#define OMAP3_MMU2_BASE0x5d00
-#define OMAP3_MMU1_IRQ 24
-#define OMAP3_MMU2_IRQ 28
-
-
-static unsigned long iommu_base[] __initdata = {
- OMAP3_MMU1_BASE,
- OMAP3_MMU2_BASE,
-};
-
-static int iommu_irq[] __initdata = {
- OMAP3_MMU1_IRQ,
- OMAP3_MMU2_IRQ,
+struct iommu_device {
+ resource_size_t base;
+ int irq;
+ struct iommu_platform_data pdata;
};
-static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
+static struct iommu_device devices[] __initdata = {
{
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
+ .base = 0x480bd400,
+ .irq = 24,
+ .pdata = {
+ .name = isp,
+ .nr_tlb_entries = 8,
+ .clk_name = cam_ick,
+ },
},
{
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
+ .base = 0x5d00,
+ .irq = 28,
+ .pdata = {
+ .name = iva2,
+ .nr_tlb_entries = 32,
+ .clk_name = iva2_ck,
+ },
},
};
#define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
@@ -52,6 +50,7 @@ static int __init omap3_iommu_init(void)
for (i = 0; i NR_IOMMU_DEVICES; i++) {
struct platform_device *pdev;
+ const struct iommu_device *d = devices[i];
struct resource res[2];
pdev = platform_device_alloc(omap-iommu, i);
@@ -60,19 +59,19 @@ static int __init omap3_iommu_init(void)
goto err_out;
}
- memset(res, 0, sizeof(res));
- res[0].start = iommu_base[i];
- res[0].end = iommu_base[i] + MMU_REG_SIZE - 1;
+ memset(res, 0, sizeof(res));
+ res[0].start = d-base;
+ res[0].end = d-base + MMU_REG_SIZE - 1;
res[0].flags = IORESOURCE_MEM;
- res[1].start = res[1].end = iommu_irq[i];
+ res[1].start = res[1].end = d-irq;
res[1].flags = IORESOURCE_IRQ;
err = platform_device_add_resources(pdev, res,
ARRAY_SIZE(res));
if (err)
goto err_out;
- err = platform_device_add_data(pdev, omap3_iommu_pdata[i],
- sizeof(omap3_iommu_pdata[0]));
+ err = platform_device_add_data(pdev, d-pdata,
+ sizeof(d-pdata));
if (err)
goto err_out;
err = platform_device_add(pdev);
--
1.6.3.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 01/11] OMAP2/3: PM: push core PM code from linux-omap
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core linux-omap PM code with mainline. This
code has evolved and been used for a while the linux-omap tree, but
the attempt here is to finally get this into mainline.
Following this will be a series of patches from the 'PM branch' of the
linux-omap tree to add full PM hardware support from the linux-omap
tree.
Much of this PM core code was written by Jouni Hogander with
significant contributions from Paul Walmsley as well as many others
from Nokia, Texas Instruments and linux-omap community.
Overall comment, I think we need to rework the idle support code so
that enable_hlt/disable_hlt can be used even when pm_idle has been
overridden, rather than OMAP going off and inventing its own mechanisms.
Would adding:
if (hlt_counter)
cpu_relax();
to the beginning of omap*_pm_idle functions be sufficient? That will
at least allow the hlt stuff to behave as expected.
The only thing the OMAP /sys/power/sleep_while_idle hook adds to this
functionality is the ability to control this from sysfs.
Any objections to /sys/power/enable_hlt?
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
new file mode 100644
index 000..2a2d1a3
--- /dev/null
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -0,0 +1,557 @@
+/*
+ * OMAP2 Power Management Routines
+ *
+ * Copyright (C) 2005 Texas Instruments, Inc.
+ * Copyright (C) 2006-2008 Nokia Corporation
+ *
+ * Written by:
+ * Richard Woodruff r-woodru...@ti.com
+ * Tony Lindgren
+ * Juha Yrjola
+ * Amit Kucheria amit.kuche...@nokia.com
+ * Igor Stoppa igor.sto...@nokia.com
+ *
+ * Based on pm.c for omap1
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/suspend.h
+#include linux/sched.h
+#include linux/proc_fs.h
+#include linux/interrupt.h
+#include linux/sysfs.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/time.h
+
+#include asm/mach/time.h
+#include asm/mach/irq.h
+#include asm/mach-types.h
+
+#include mach/irqs.h
+#include mach/clock.h
+#include mach/sram.h
+#include mach/control.h
+#include mach/gpio.h
Should be linux/gpio.h
Ack
+/*
+ * Note that you can use clock_event_device-min_delta_ns if you want to
+ * avoid reprogramming timer too often when using CONFIG_NO_HZ.
+ */
+static void omap2_pm_idle(void)
+{
+local_irq_disable();
+local_fiq_disable();
+
+if (!omap2_can_sleep()) {
+if (!atomic_read(sleep_block) omap2_irq_pending())
+goto out;
+omap2_enter_mpu_retention();
+goto out;
+}
+
+if (omap2_irq_pending())
+goto out;
+
+omap2_enter_full_retention();
+
+out:
+local_fiq_enable();
+local_irq_enable();
+}
It's totally unclear what the comment above the function has to do with
the function itself.
Indeed. Will be removed.
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
new file mode 100644
index 000..0fb6bec
--- /dev/null
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -0,0 +1,607 @@
+/*
+ * OMAP3 Power Management Routines
+ *
+ * Copyright (C) 2006-2008 Nokia Corporation
+ * Tony Lindgren t...@atomide.com
+ * Jouni Hogander
+ *
+ * Copyright (C) 2005 Texas Instruments, Inc.
+ * Richard Woodruff r-woodru...@ti.com
+ *
+ * Based on pm.c for omap1
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/pm.h
+#include linux/suspend.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/list.h
+#include linux/err.h
+
+#include mach/gpio.h
Should be linux/gpio.h
Ack
+static void omap3_pm_idle(void)
+{
+local_irq_disable();
+local_fiq_disable();
+
+if (!omap3_can_sleep())
+goto out;
+
+if (omap_irq_pending())
+goto out;
So what happens if an IRQ becomes pending at this precise point?
Then it gets missed this time, and will be triggered upon wakeup. If
it's a wakeup-capable interrupt, then it will wake the system
immediately.
In subsequent series of the PM branch, this will be going away in
favor of using the [enable|disable]_irq_wake() and the lazy IRQ
disabling features.
+
+omap_sram_idle();
+
+out:
+local_fiq_enable();
+local_irq_enable();
+}
+/* IRQ mode */
+bicr0, r7, #0x1F
+orrr0, r0, #0x12
+msrcpsr, r0 /*go into IRQ mode*/
+ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM*/
+movsp, r4 /*update
Re: [PATCH 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Mon, May 18, 2009 at 10:00:44AM -0700, Kevin Hilman wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote: This patch is to sync the core linux-omap PM code with mainline. This code has evolved and been used for a while the linux-omap tree, but the attempt here is to finally get this into mainline. Following this will be a series of patches from the 'PM branch' of the linux-omap tree to add full PM hardware support from the linux-omap tree. Much of this PM core code was written by Jouni Hogander with significant contributions from Paul Walmsley as well as many others from Nokia, Texas Instruments and linux-omap community. Overall comment, I think we need to rework the idle support code so that enable_hlt/disable_hlt can be used even when pm_idle has been overridden, rather than OMAP going off and inventing its own mechanisms. Would adding: if (hlt_counter) cpu_relax(); to the beginning of omap*_pm_idle functions be sufficient? That will at least allow the hlt stuff to behave as expected. Yes, but the comment was also directed at the other functions which increment/decrement that atomic_t variable to enable/disable sleep mode. The only thing the OMAP /sys/power/sleep_while_idle hook adds to this functionality is the ability to control this from sysfs. Any objections to /sys/power/enable_hlt? That seems to be rather dangerous, even with your atomic based code which bugs if the count goes below zero. The problem here is that such an interface is extremely fragile. Consider what happens if a program disables HLT, and then gets killed off for some reason. How does this reference get balanced again? I think a better solution would be a char device driver which has to be kept open as long as a reference is held. When userspace closes it (be that because the program has exited, been killed, etc) you can drop any pending references. -- 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
[ adding Richard W. to To: since he can probably shed some light here ]
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core linux-omap PM code with mainline. This
code has evolved and been used for a while the linux-omap tree, but
the attempt here is to finally get this into mainline.
[...]
[excerpt of sleep34xx.S]
+/* IRQ mode */
+bicr0, r7, #0x1F
+orrr0, r0, #0x12
+msrcpsr, r0 /*go into IRQ mode*/
+ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM*/
+movsp, r4 /*update the SP */
+movlr, r5 /*update the LR */
+msrspsr, r6 /*update the SPSR */
+
+/* ABORT mode */
+bicr0, r7, #0x1F
+orrr0, r0, #0x17
+msrcpsr, r0 /* go into ABORT mode */
+ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM */
+movsp, r4 /*update the SP */
+movlr, r5 /*update the LR */
+msrspsr, r6 /*update the SPSR */
+
+/* UNDEEF mode */
+bicr0, r7, #0x1F
+orrr0, r0, #0x1B
+msrcpsr, r0 /*go into UNDEF mode */
+ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM */
+movsp, r4 /*update the SP*/
+movlr, r5 /*update the LR*/
+msrspsr, r6 /*update the SPSR*/
+
+/* SYSTEM (USER) mode */
+bicr0, r7, #0x1F
+orrr0, r0, #0x1F
+msrcpsr, r0 /*go into USR mode */
+ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM*/
+movsp, r4 /*update the SP */
+movlr, r5 /*update the LR */
+msrspsr, r6 /*update the SPSR */
+msrcpsr, r7 /*back to original mode*/
There is a function which re-initializes the abort mode registers already -
cpu_init(). Please use that if possible instead.
Upon a quick glance, using cpu_init() would not cover all the things
that this code does. cpu_init() only handles the init of sp for the
various modes, where this code saves/resores all the banked registers:
sp, lr and spsr as well as r8-r12 of FIQ mode.
The question in my mind however is whether the lr and spsr need to be
saved/restored? Do we really need to preserve the context of these
handlers across idle? Presumably we should not hit idle/suspend in
the middle of one of these handlers, so do we need to save anything
other than the stp? Maybe Richard can shed some light here as to why
that was added.
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] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote: stanley.miao stanley.m...@windriver.com writes: Looks like you used the CodeSourcery 2007q3 toolchain. This had been reported earlier. Switching to 2008q3 works. Yeah, Now the kernel booted. it's compiler's problem. I was bitten by the same problem few weeks ago. Any chance of getting a warning/error if using 2007q3 compiler until the problem is fixed? Is there any way of detecting the 2007q3 compiler? With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ to identify the three digit version number. I don't know, most probably not. But Jon Hunter investigated the issue and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html So maybe we can fix or workaround this. Why does this change anything? FRAME_POINTERS seems to be enabled anyway (and should be given the Kconfig setup we have.) See the 'depends on' line in lib/Kconfig.debug. The result is that without the patch from Jon, even if you have CONFIG_FRAME_POINTERS=y in your .config, it gets dropped if the arch doesn't set CONFIG_ARCH_WANT_FRAME_POINTERS. 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Mon, May 18, 2009 at 10:00:44AM -0700, Kevin Hilman wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote: This patch is to sync the core linux-omap PM code with mainline. This code has evolved and been used for a while the linux-omap tree, but the attempt here is to finally get this into mainline. Following this will be a series of patches from the 'PM branch' of the linux-omap tree to add full PM hardware support from the linux-omap tree. Much of this PM core code was written by Jouni Hogander with significant contributions from Paul Walmsley as well as many others from Nokia, Texas Instruments and linux-omap community. Overall comment, I think we need to rework the idle support code so that enable_hlt/disable_hlt can be used even when pm_idle has been overridden, rather than OMAP going off and inventing its own mechanisms. Would adding: if (hlt_counter) cpu_relax(); to the beginning of omap*_pm_idle functions be sufficient? That will at least allow the hlt stuff to behave as expected. Yes, but the comment was also directed at the other functions which increment/decrement that atomic_t variable to enable/disable sleep mode. Ah, right. The sleep_block stuff is only used in OMAP2, we don't use that anymore in OMAP3. In fact, even OMAP2 users of this should be updated to use the OMAP PM layer, so I'll just drop the sleep_block hooks. The only thing the OMAP /sys/power/sleep_while_idle hook adds to this functionality is the ability to control this from sysfs. Any objections to /sys/power/enable_hlt? That seems to be rather dangerous, even with your atomic based code which bugs if the count goes below zero. Atomic sleep_block code to be removed. The problem here is that such an interface is extremely fragile. Consider what happens if a program disables HLT, and then gets killed off for some reason. How does this reference get balanced again? I think a better solution would be a char device driver which has to be kept open as long as a reference is held. When userspace closes it (be that because the program has exited, been killed, etc) you can drop any pending references. OK, this interface is not intended for users/applications. It is intended only for OMAP PM developers who are developing the PM code and want to prevent idle for various reasons during development. It is not intended for productions systems. What about leaving /sys/power/sleep_while_idle but only if CONFIG_PM_DEBUG=y? 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Mon, May 18, 2009 at 10:08:36AM -0700, Kevin Hilman wrote: [ adding Richard W. to To: since he can probably shed some light here ] Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote: This patch is to sync the core linux-omap PM code with mainline. This code has evolved and been used for a while the linux-omap tree, but the attempt here is to finally get this into mainline. [...] Upon a quick glance, using cpu_init() would not cover all the things that this code does. cpu_init() only handles the init of sp for the various modes, where this code saves/resores all the banked registers: sp, lr and spsr as well as r8-r12 of FIQ mode. It doesn't touch sp, lr and spsr for the other modes because there's no requirement to do so. Think about it for a moment. Is there any point to saving LR and SPSR for the abort, FIQ and IRQ modes? No - LR and SPSR are overwritten by the hardware immediately upon entry to the relevent mode via an exception. What about SP? We use SP in the vector entry code, and we need to ensure that this is re-initialized. We never change their value, so we know that these are constant, and therefore if we initialize them once we can repeat the same initialization to restore their values when those values are lost. This is precisely what cpu_init() does. As for FIQ r8-r12, yes this is missing, and it's something that needs to be handled by _every_ platform which puts the CPU into low power state, be that PXA, S3C2410, and so forth. We have code to allow the FIQ vector to be managed, and as yet those architectures which do support sleep modes don't use FIQ mode, hence why there's nothing for it yet. Feel free to add the necessary suspend/resume code to (eg) arch/arm/kernel/fiq.c to fill this hole though. Lastly is system mode. The kernel doesn't use system mode, and this mode doesn't exist in all CPUs (its marked as unpredictable on many older CPUs.) We need a _generic_ extension to support that mode _if_ it is used. Presently it is not used, and so we simply don't bother saving those registers. The question in my mind however is whether the lr and spsr need to be saved/restored? Do we really need to preserve the context of these handlers across idle? Idle is called essentially in process context, with the exception that it's SVC mode rather than user mode. That means no exception handlers will be running. So I think you'll find cpu_init() does everything you require. -- 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] usb: disable OTG AUTOIDLE only with omap3430
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen Sent: Monday, May 18, 2009 9:54 AM Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG register prevents the device from going into retention. This is a workaround (by Richard Woodruff/TI), as his comment : A new MUSB bug which is a match to data below was identified very recently (on hardware and in simulation). This bug is in 3430 and not 3630. As a priority test (and as new default) you should have engineers disable autoidle for MUSB block. This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen ext-niilo.1.minkki...@nokia.com Signed-off-by: Richard Woodruff r-woodru...@ti.com Yes this is needed for 34xx. Side note is this cost around 1mW of power during active mode of MUSB. When device is not active cost is not significant. System impact depends on duty cycle of MUSB in usecase. Regards, Richard W. -- 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 08/11] ARM: OMAP2/3: GPIO: do not attempt to wake-enable
Hi Kevin,
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/gpio.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index d3fa41e..210a1c0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -921,13 +921,10 @@ static int _set_gpio_wakeup(struct gpio_bank *bank,
int gpio, int enable)
case METHOD_MPUIO:
case METHOD_GPIO_1610:
spin_lock_irqsave(bank-lock, flags);
- if (enable) {
+ if (enable)
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
- } else {
- disable_irq_wake(bank-irq);
+ else
bank-suspend_wakeup = ~(1 gpio);
- }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
@@ -940,13 +937,10 @@ static int _set_gpio_wakeup(struct gpio_bank *bank,
int gpio, int enable)
return -EINVAL;
}
spin_lock_irqsave(bank-lock, flags);
- if (enable) {
+ if (enable)
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
- } else {
- disable_irq_wake(bank-irq);
+ else
bank-suspend_wakeup = ~(1 gpio);
- }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
I have been looking into an issue that appears to be related to this. I have
the following questions with regard to this patch.
1). Although, I agree with the above change was there any reason why we did not
add some code to set/clear the appropriate bit in the WKUENA register in this
function? If this function is called via a call to set_irq_wake it will not
modify the WKUENA register. Therefore, we were thinking of something along the
lines of:
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 17d7afe..895c548 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -941,10 +941,13 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
return -EINVAL;
}
spin_lock_irqsave(bank-lock, flags);
- if (enable)
+ if (enable) {
bank-suspend_wakeup |= (1 gpio);
- else
+ __raw_writel(1 gpio, bank-base +
OMAP24XX_GPIO_SETWKUENA);
+ } else {
+ __raw_writel(1 gpio, bank-base +
OMAP24XX_GPIO_CLEARWKUENA);
bank-suspend_wakeup = ~(1 gpio);
+ }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
2). We have found that a call to request_irq results in a call to the function
set_24xx_gpio_triggering() (for OMAP3430). In addition to configuring the
triggering for a given GPIO, this function is also programming the WKUENA
register. Hence, the wake-up enable is enabled for GPIO without calling
set_irq_wake().
I am not sure if this is the intended behaviour or if drivers should explicitly
be calling set_irq_wake to enable/disable the wake-up.
The other problem with this is that once request_irq is called for a gpio, then
even if we call disable_irq the wake-up event is not cleared. So this means
that a gpio event will still wake-up the device without the gpio being enabled
and because the gpio is disabled the event will never be cleared and hence will
prevent retention.
So should the wake-up event only be enabled/disabled by a call to
set_irq_wake() or should we make sure that calling disable_irq in turn calls
gpio_mask_irq and make sure this clears the wake-up event?
Cheers
Jon
--
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 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Mon, May 18, 2009 at 02:04:19PM -0500, Woodruff, Richard wrote:
cpu_init() is not yet accessible at the point this code is running.
Not at that _exact_ point, but there's no need what so ever for it
to be at that exact point. There's nothing stopping a call to
cpu_init() happening later. Much later.
You could reduce the context perhaps trying to optimize to what the
Linux-ARM implementation is today or do a more generic save like is
there now.
This code is copied into place from the .S code into SRAM. Its
position independent and is not linked for this address. If you want
to call functions outside of it you need to manually setup linkage.
I wouldn't want to.
Calling functions on the way _UP_ from wake is NOT easy (like the one
you propose) as the MMU is not yet enabled. The MMU is enabled only
below this. Calling cpu_init() is not do able here. Even if you
dress up the calling pointer to the physical address, it won't work
as cpu_init() makes a global variable dereferences (smp_processor_id
stacks[]).
As long as IRQs and FIQs are disabled, you are in a 100% predictable
environment.
1. No IRQ or FIQ will be entered; if they are the CPU is buggy.
2. No data or prefetch abort will be entered _unless_ you purposely
access some non-present memory (and you're not exactly going to
start paging memory in with IRQs disabled.)
So restoring the abort and IRQ mode register state is just plain not
necessary in your SRAM code.
Let's look at the code. Here are the pertinent bits from Kevin's patch:
static void omap3_pm_idle(void)
{
local_irq_disable();
local_fiq_disable();
omap_sram_idle();
local_fiq_enable();
local_irq_enable();
}
static void omap_sram_idle(void)
{
_omap_sram_idle(NULL, save_state);
}
_omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
omap34xx_cpu_suspend_sz);
pm_idle = omap3_pm_idle;
_omap_sram_idle() is the assembly code we're discussing, and here we're
referring to its version in SRAM. From the above code, we can clearly
see that this is entered with FIQs and IRQs disabled. So everything
inside omap_sram_idle() is running in a well defined environment provided
prefetch and data aborts don't happen.
There is nothing stopping this from becoming:
static void omap3_pm_idle(void)
{
local_irq_disable();
local_fiq_disable();
omap_sram_idle();
+ cpu_init();
local_fiq_enable();
local_irq_enable();
}
and having the saving of IRQ, FIQ and abort mode registers removed
from the SRAM code.
Other SoCs do precisely this - let's look at PXA:
pxa_cpu_pm_fns-enter(state);
cpu_init();
The call to the enter method essentially calls the core specific suspend
function (eg, pxa25x_cpu_suspend()), which is an assembly function which
ultimately ends up powering down the core resulting in full loss of state
in the CPU. We seem to be able to avoid having to save the exception mode
registers there.
The same thing is done with sa11x0 and Samsung SoCs.
I don't see any reason for OMAP to be special in this regard.
--
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 01/11] OMAP2/3: PM: push core PM code from linux-omap
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, May 18, 2009 3:25 PM The call to the enter method essentially calls the core specific suspend function (eg, pxa25x_cpu_suspend()), which is an assembly function which ultimately ends up powering down the core resulting in full loss of state in the CPU. We seem to be able to avoid having to save the exception mode registers there. The same thing is done with sa11x0 and Samsung SoCs. I don't see any reason for OMAP to be special in this regard. The code flow is: - Wakeup event - ARM reboots and uses SOC mask ROM context restore helper - Mask ROM code jump to restore pointers with MMU OFF. - Restore code resets ARM CortexA8 state -*- Trustzone SMI calls are made to restore some secure state - Jump back from SRAM to C code The dangling question to me is if any of the cpu state is needed by the trustzone monitor code as a precondition. The doc's I have led me to believe its ok, but I've not verified this. Regards, Richard W. -- 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Mon, May 18, 2009 at 03:47:31PM -0500, Woodruff, Richard wrote: The code flow is: - Wakeup event - ARM reboots and uses SOC mask ROM context restore helper - Mask ROM code jump to restore pointers with MMU OFF. - Restore code resets ARM CortexA8 state -*- Trustzone SMI calls are made to restore some secure state - Jump back from SRAM to C code The dangling question to me is if any of the cpu state is needed by the trustzone monitor code as a precondition. The doc's I have led me to believe its ok, but I've not verified this. There shouldn't be - it would be _really_ silly if the trustzone monitor had pre-requisits for the exception mode registers. There's no way that Linux's use of the exception mode registers is anywhere near the same as other OSes, and Linux's use of the exception mode registers has changed over time anyway. We make no promise that we'll keep the way we're using these registers today either. So there are no external guarantees about what useful state the kernel puts into these registers. Having external code rely on some state there would itself be broken. There's also the problem that if there was a dependency on the insecure exception mode registers from within the trusted environment, that'd surely be a rather big security problem in itself. -- 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/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
Hi,
Few comments below.
* Mikkel Christensen m...@ti.com [090515 14:17]:
This patch creates the minimal OMAP3 Zoom2 board support.
Signed-off-by: Mikkel Christensen m...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/board-zoom2-debugboard.c | 161
++
arch/arm/mach-omap2/board-zoom2.c| 107 +
2 files changed, 268 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom2-debugboard.c
create mode 100644 arch/arm/mach-omap2/board-zoom2.c
diff --git a/arch/arm/mach-omap2/board-zoom2-debugboard.c
b/arch/arm/mach-omap2/board-zoom2-debugboard.c
new file mode 100644
index 000..e5686e8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom2-debugboard.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Mikkel Christensen m...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/serial_8250.h
+#include linux/smsc911x.h
+
+#include mach/gpio.h
+#include mach/gpmc.h
+
+#define ZOOM2_SMSC911X_CS7
+#define ZOOM2_SMSC911X_GPIO 158
+#define ZOOM2_QUADUART_CS3
+#define ZOOM2_QUADUART_GPIO 102
+#define QUART_CLK1843200
+#define DEBUG_BASE 0x0800
+#define ZOOM2_ETHR_START DEBUG_BASE
+
+static struct resource zoom2_smsc911x_resources[] = {
+ [0] = {
+ .start = ZOOM2_ETHR_START,
+ .end= ZOOM2_ETHR_START + SZ_4K,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
+static struct smsc911x_platform_config zoom2_smsc911x_config = {
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = SMSC911X_USE_32BIT,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
+static struct platform_device zoom2_smsc911x_device = {
+ .name = smsc911x,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(zoom2_smsc911x_resources),
+ .resource = zoom2_smsc911x_resources,
+ .dev= {
+ .platform_data = zoom2_smsc911x_config,
+ },
+};
+
+static inline void __init zoom2_init_smsc911x(void)
+{
+ int eth_cs;
+ unsigned long cs_mem_base;
+ int eth_gpio = 0;
+
+ eth_cs = ZOOM2_SMSC911X_CS;
+
+ if (gpmc_cs_request(eth_cs, SZ_16M, cs_mem_base) 0) {
+ printk(KERN_ERR Failed to request GPMC mem for smsc911x\n);
+ return;
+ }
+
+ zoom2_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ zoom2_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ eth_gpio = ZOOM2_SMSC911X_GPIO;
+
+ zoom2_smsc911x_resources[1].start = OMAP_GPIO_IRQ(eth_gpio);
+
+ if (gpio_request(eth_gpio, smsc911x irq) 0) {
+ printk(KERN_ERR Failed to request GPIO%d for smsc911x IRQ\n,
+ eth_gpio);
+ return;
+ }
+ gpio_direction_input(eth_gpio);
+}
+
+static struct plat_serial8250_port serial_platform_data[] = {
+ {
+ .mapbase= 0x1000,
+ .irq= OMAP_GPIO_IRQ(102),
+ .flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
+ .iotype = UPIO_MEM,
+ .regshift = 1,
+ .uartclk= QUART_CLK,
+ }, {
+ .flags = 0
+ }
+};
+
+static struct platform_device zoom2_debugboard_serial_device = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_PLATFORM1,
+ .dev= {
+ .platform_data = serial_platform_data,
+ },
+};
+
+static inline void __init zoom2_init_quaduart(void)
+{
+ int quart_cs;
+ unsigned long cs_mem_base;
+ int quart_gpio = 0;
+
+ quart_cs = ZOOM2_QUADUART_CS;
+
+ if (gpmc_cs_request(quart_cs, SZ_1M, cs_mem_base) 0) {
+ printk(KERN_ERR Failed to request GPMC mem
+ for Quad UART(TL16CP754C)\n);
+ return;
+ }
+
+ quart_gpio = ZOOM2_QUADUART_GPIO;
+
+ if (gpio_request(quart_gpio, TL16CP754C GPIO) 0) {
+ printk(KERN_ERR Failed to request GPIO%d for TL16CP754C\n,
+ quart_gpio);
+ return;
+ }
+ gpio_direction_input(quart_gpio);
+}
+
+static inline int omap_zoom2_debugboard_detect(void)
+{
+ int debug_board_detect = 0;
+
+ debug_board_detect = ZOOM2_SMSC911X_GPIO;
+
+ if (gpio_request(debug_board_detect, Zoom2 debug board detect) 0) {
+
RE: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
Tony
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Hi,
Few comments below.
* Mikkel Christensen m...@ti.com [090515 14:17]:
This patch creates the minimal OMAP3 Zoom2 board support.
Signed-off-by: Mikkel Christensen m...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/board-zoom2-debugboard.c | 161
++
arch/arm/mach-omap2/board-zoom2.c| 107 +
2 files changed, 268 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom2-debugboard.c
create mode 100644 arch/arm/mach-omap2/board-zoom2.c
snip
+
+zoom2_init_smsc911x();
+zoom2_init_quaduart();
+return platform_add_devices(zoom2_devices, ARRAY_SIZE(zoom2_devices));
+}
+arch_initcall(omap_zoom2_debugboard_init);
Please just move all the related functions to board-zoom2.c. I don't see any
reason to have a separate file for the debugboard features. The runtime
detection
should do the trick.
Two reasons for keeping a separate debug board.
a) debug board is detachable in h/w and hence we thought its better to keep the
s/w also that way
The quart chip on debug bard is a quard-uart and can support 4 different
console outputs.
All those we thought of adding in future.
b) we took reference from board-rx51-peripherals.c wherein some parts of the
board file can be moved out to a new file
If you still think we need to merge, then let us know.
We are open to suggestions/changes.
Also, the arch_initcall() above is wrong, it runs for all the boards and
platforms compiled in even if they are not zoom2 boards.
Other than, looks OK to me, so we might be able to get this into mainline
this merge window.
Regards,
Tony
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
new file mode 100644
index 000..5a656b3
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Mikkel Christensen m...@ti.com
+ *
+ * Modified from mach-omap2/board-ldp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include mach/gpio.h
+#include mach/common.h
+#include mach/usb.h
+
+#include mmc-twl4030.h
+
+static void __init omap_zoom2_init_irq(void)
+{
+omap2_init_common_hw(NULL);
+omap_init_irq();
+omap_gpio_init();
+}
+
+static struct omap_uart_config zoom2_uart_config __initdata = {
+.enabled_uarts = ((1 0) | (1 1) | (1 2)),
+};
+
+static struct omap_board_config_kernel zoom2_config[] __initdata = {
+{ OMAP_TAG_UART,zoom2_uart_config },
+};
+
+static struct twl4030_gpio_platform_data zoom2_gpio_data = {
+.gpio_base = OMAP_MAX_GPIO_LINES,
+.irq_base = TWL4030_GPIO_IRQ_BASE,
+.irq_end= TWL4030_GPIO_IRQ_END,
+};
+
+static struct twl4030_platform_data zoom2_twldata = {
+.irq_base = TWL4030_IRQ_BASE,
+.irq_end= TWL4030_IRQ_END,
+
+/* platform_data for children goes here */
+.gpio = zoom2_gpio_data,
+};
+
+static struct i2c_board_info __initdata zoom2_i2c_boardinfo[] = {
+{
+I2C_BOARD_INFO(twl4030, 0x48),
+.flags = I2C_CLIENT_WAKE,
+.irq = INT_34XX_SYS_NIRQ,
+.platform_data = zoom2_twldata,
+},
+};
+
+static int __init omap_i2c_init(void)
+{
+omap_register_i2c_bus(1, 2600, zoom2_i2c_boardinfo,
+ARRAY_SIZE(zoom2_i2c_boardinfo));
+omap_register_i2c_bus(2, 400, NULL, 0);
+omap_register_i2c_bus(3, 400, NULL, 0);
+return 0;
+}
+
+static struct twl4030_hsmmc_info mmc[] __initdata = {
+{
+.mmc= 1,
+.wires = 4,
+.gpio_cd= -EINVAL,
+.gpio_wp= -EINVAL,
+},
+{} /* Terminator */
+};
+
+static void __init omap_zoom2_init(void)
+{
+omap_i2c_init();
+omap_board_config = zoom2_config;
+omap_board_config_size = ARRAY_SIZE(zoom2_config);
+omap_serial_init();
+twl4030_mmc_init(mmc);
+usb_musb_init();
+}
+
+static void __init omap_zoom2_map_io(void)
+{
+omap2_set_globals_343x();
+omap2_map_common_io();
+}
+
+MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board)
+.phys_io= 0x4800,
+.io_pg_offst= ((0xd800) 18) 0xfffc,
+.boot_params= 0x8100,
+.map_io = omap_zoom2_map_io,
+.init_irq = omap_zoom2_init_irq,
+.init_machine = omap_zoom2_init,
+.timer = omap_timer,
+MACHINE_END
--
1.5.4.3
--
To unsubscribe from
Re: [PATCH] OMAP: Remove IRQ hardcoding from serial.c
* Shilimkar, Santosh santosh.shilim...@ti.com [090513 07:53]: Tony, Any comments on this patch. http://patchwork.kernel.org/patch/19161/ We should just set the interrupts etc dynamically using the cpu_is_omap() functions. 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
slap corruption
Hi everyone, We have been looking into the Slab Corruption error and we have found the problem occurs after an application has been terminated abnormally, e.g. Using CTL-C or Segmentation Fault or kill. The issue is observed not only for DMM test cases but for others test cases that don't use DMM. The problem is reported by 'slab.c' when a slab object which is inactive, it supposed to be filled with POISON_FREE (6b) and has some 00 within the object, this seems to be corrupted. Slab corruption: size-64 start=c6bc71e0, len=64 3Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. 3Last user: [bf063464]Last user: [bf063464](MEM_Free+0x9c/0xe0 [bridgedriv er])(MEM_Free+0x9c/0xe0 [bridgedriver]) 3010:010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 00 00 00 00 it seems it is not being freed correctly, because instead of being filled only with 6b it has 00 maybe other process is overwriting it. Does anyone have any idea of what can be happening? Regards, Fernando. -- 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: Remove IRQ hardcoding from serial.c
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, May 19, 2009 3:16 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: Remove IRQ hardcoding from serial.c * Shilimkar, Santosh santosh.shilim...@ti.com [090513 07:53]: Tony, Any comments on this patch. http://patchwork.kernel.org/patch/19161/ We should just set the interrupts etc dynamically using the cpu_is_omap() functions. That's indeed a good idea. But then are we going to remove this information from platform structures. If not then hardcoding is still bad and should be removed. 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
MMC card corruption during suspend/resume operation
Hi, I have a problem with my TI OMAP 3503 platform, where the microSD card that I have, gets corrupted during a suspend/resume operation. Do the existing power management drivers, cleanly unmount/ mount the mmc card during a suspend/resume operation? I am using the TI OMAP linux 2.6.29 kernel version, with the android-2.6.29 kernel updates. I have installed Doing a search for the mmc card corruption issues, it would appear that a lot of people are facing the same issues on other platforms as well. It appears to be a platform issue for both the older 1.1 and 1.5 android versions. http://forum.xda-developers.com/archive/index.php/t-495899.html http://androidforums.com/updates-cupcakes/5202-did-cupcake-eat-my-sd-card.html http://forums.t-mobile.com/tmbl/board/message?board.id=Android3message.id=10928 The problem might be because of the application or system not cleanly un-mounting the mmc card, thus causing it to get corrupted, e.g during a suspend/resume operation. So, I thought I'd ask if the existing power management drivers do a clean mount/unmount when it does a suspend/resume operation. Best regards, Elvis -- 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 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On
Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it is
the userspace app responsability to check the value again, to confirm how many
of the requested buffers are actually available.
Regards,
Sergio--
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 3/3] OMAP2/3 V4L2 Display Driver
Hi Sergio,
Thank you for your explanation . I learned much from that.
Cheers,
Nate
On Tue, May 19, 2009 at 2:22 PM, Aguirre Rodriguez, Sergio Alberto
saagui...@ti.com wrote:
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it
is the userspace app responsability to check the value again, to confirm how
many of the requested buffers are actually available.
Regards,
Sergio
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.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 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
-Original Message-
From: Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, May 19, 2009 10:52 AM
To: Dongsoo, Nathaniel Kim; Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
[Shah, Hardik] Rotation requires the VRFB contexts and limited number of
contexts are available. So maximum number of buffers is fixed to 4 when
rotation is enabled.
Thanks,
Hardik
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it
is the userspace app responsability to check the value again, to confirm how
many of the requested buffers are actually available.
Regards,
Sergio
--
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 3/3] OMAP2/3 V4L2 Display Driver
Hi Hardik,
According to earlier mail from Sergio, I could be noticed that it is
totally ok to restrict number of buffers by driver. As matter of fact,
I was always considering about the H/W restriction and could find the
answer from his mail.
By the way, thank you for your answer.
Cheers,
Nate
On Tue, May 19, 2009 at 2:28 PM, Shah, Hardik hardik.s...@ti.com wrote:
Hi Nate,
-Original Message-
From: Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, May 19, 2009 10:52 AM
To: Dongsoo, Nathaniel Kim; Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
R;
Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
[Shah, Hardik] Rotation requires the VRFB contexts and limited number of
contexts are available. So maximum number of buffers is fixed to 4 when
rotation is enabled.
Thanks,
Hardik
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it
is the userspace app responsability to check the value again, to confirm how
many of the requested buffers are actually available.
Regards,
Sergio
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.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 01/11] OMAP2/3: PM: push core PM code from linux-omap
Kevin Hilman wrote: The problem here is that such an interface is extremely fragile. Consider what happens if a program disables HLT, and then gets killed off for some reason. How does this reference get balanced again? I think a better solution would be a char device driver which has to be kept open as long as a reference is held. When userspace closes it (be that because the program has exited, been killed, etc) you can drop any pending references. OK, this interface is not intended for users/applications. It is intended only for OMAP PM developers who are developing the PM code and want to prevent idle for various reasons during development. It is not intended for productions systems. What about leaving /sys/power/sleep_while_idle but only if CONFIG_PM_DEBUG=y? Sounds like debugfs is the good place for this then. -- 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
