RE: [PATCHv2 1/1] omap: Ptr isr_reg tracked as NULL was dereferenced
On Wed, 2010-10-13 at 16:09 +0400, Evgeny Kuznetsov wrote:
On Wed, 2010-10-13 at 17:20 +0530, ext Varadarajan, Charulatha wrote:
snip
From: Evgeny Kuznetsov ext-eugeny.kuznet...@nokia.com
Value of isr_reg pointer is depend on configuration and GPIO method.
Potentially it may have NULL value and it is dereferenced later
in code. If pointer is NULL there is some kernel issue.
Can you elaborate?
isr_reg should not be NULL. But if it is NULL then there is kernel
bug. And WARN_ON() used to show it.
I did not see this bug, this is potentially may happen.
Warning and exit from function are added in this case.
Also compilation check is added for correct architecture
configuration.
Signed-off-by: Evgeny Kuznetsov ext-eugeny.kuznet...@nokia.com
---
arch/arm/plat-omap/gpio.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index c05c653..d04913c 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1318,6 +1318,23 @@ static void gpio_irq_handler(unsigned int irq,
struct irq_desc *desc)
if (bank-method == METHOD_GPIO_44XX)
isr_reg = bank-base + OMAP4_GPIO_IRQSTATUS0;
#endif
+
+#if !defined(CONFIG_ARCH_OMAP1)\
+ !defined(CONFIG_ARCH_OMAP15XX)\
+ !defined(CONFIG_ARCH_OMAP16XX)\
+ !defined(CONFIG_ARCH_OMAP730) \
+ !defined(CONFIG_ARCH_OMAP850) \
+ !defined(CONFIG_ARCH_OMAP2) \
+ !defined(CONFIG_ARCH_OMAP3) \
+ !defined(CONFIG_ARCH_OMAP4)
+
+#error Incorrect arch configuration
This is not required. If the architecture is not one of the above
mentioned, gpio_irq_handler() will not be used/called at all.
This could be removed.
Also all the possible gpio methods for a given OMAP architecture are
already considered with #ifdefs and (bank-method) checks in
gpio_irq_handler().
It is not cover all cased, e.g. for OMAP4 arch:
#if defined(CONFIG_ARCH_OMAP4)
if (bank-method == METHOD_GPIO_44XX)
isr_reg = bank-base + OMAP4_GPIO_IRQSTATUS0;
#endif
.
If (bank-method != METHOD_GPIO_44XX) then isr_reg will be NULL.
This should not happen, but potentially may have place.
When would it fail? If it is CONFIG_ARCH_OMAP4, the gpio method can
only be METHOD_GPIO_44XX. Else if it is for some other OMAP architecture,
the gpio_method is similarly taken care. So this cannot happen.
This is similar check as e.g. in _enable_gpio_irqbank() there default
case for bank-methos switch is WARN_ON(1).
Just to warn in case.
Hi Tony,
It is not a bug fix, it is just check to prevent potential issues. Used
to warn in case of bug and prevent kernel oops. Check added only here
(not all gpio code cleanup) since here it could cause kernel opps.
Would you apply patch if I will leave only if condition section in
patch?
if (WARN_ON(!isr_reg))
goto exit;
If yes, I'll resend v3 patch.
Thanks,
Regards,
Evgeny
+
+#endif
+
+ if (WARN_ON(!isr_reg))
+ goto exit;
For the above mentioned reason, this isr_reg would be non-NULL. Have
you observed this error anytime?
I did not see this bug, this is potentially may happen.
Also, the omap-gpio code has similar code spread all over and has to be
anyway cleaned-up. Is there any reason why gpio_irq_handler() alone is
addressed in this patch?
Here isr_reg is used later in code and may cause oops if it is NULL.
+
while(1) {
u32 isr_saved, level_mask = 0;
u32 enabled;
@@ -1377,6 +1394,7 @@ static void gpio_irq_handler(unsigned int irq,
struct irq_desc *desc)
configured, we must unmask the bank interrupt only after
handler(s) are executed in order to avoid spurious bank
interrupt */
+exit:
if (!unmasked)
desc-chip-unmask(irq);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
On Thursday 14 October 2010 17:51:15 ext Varadarajan, Charulatha wrote: Yes, this need to be fixed, but it can be done later, it does not need to be part of the hwmod series. Okay. This problem there for a long time, and so far no one complained, or fixed it. Probably there are no users for pollread/write at all, but I would not remove the functionality. It is better to fix them later. 2. DMA transfers would also not work as it requires a patch similar to [y]. Well, this patch was sent in 2008. nowdays we moved the OMAP audio support to ASoC, and there are no 'legacy' ALSA arm/omap drivers anymore. In ASoC the cpu_dai and the platform drivers are separate things. This allows us to use the same platform driver (omap-pcm) for McBSp, McPDM (and in theory we could have OMAP2 EAC) cpu_dai drivers without duplicating code. As a note: most of the features this patch was trying to implement is already done for the ASoC implementation, but if there is need for new features, it has to be done using the ASoC framework. If we do this, would it not contradict the idea of keeping the door open for others to use the McBSP ports? Why? If you add support for different sample formats to ASoC, it will not change anything. If other users should be allowed to use McBSP ports, it is good to have DMA support in plat-omap/mcbsp.c itself and modify the asoc implementation to take advantage of the proposed new mcbsp design. If agreed, this shall be addressed later. Please let me know your thoughts on this. What I mean is that later we could add DMA transfer functionality if there is a need, but at the moment I don't see any reason to do that. Also moving the DMA functionality to plat-omap/mcbsp.c would require quite a big change in there, and as well in the ASoC code. On top of that we will broke the sound/soc/omap/omap-pcm.c to be McBSP independent, and that is one of the main points here. We are using omap-pcm.c with McBSP and McPDM dai drivers. That has to remain the same. In the future we can implement DMA transfer capabilities to mcbsp. I would not do this as part of hwmod either. I think such an extension to the current McBSP code is only needed if/when we have other users for McBSP than audio. Coming back to the original question. Either we need to fix the broken legacy mcbsp driver or move the omap-mcbsp driver completely to asoc layer. What do you say? I would keep the partitioning same as it is now. Okay. If there is a reason we can add bus driver functionality to McBSP, Can you elaborate? mcbsp driver is already following platform bus device model. I meant adding DMA functionality to McBSP. I would not worry about this at this time. but at the moment there is no need for that. For testing any changes in mcbsp driver (including hwmod), we are relying on internal patches (dma/pollmode patches). Instead, if mcbsp dma support is available in the driver itself, it would be useful for bug fixing/development activities. You should use audio (ASoC) for verification, for example Beagle, or other board. I would say that the audio support is solid on OMAP platforms, and that is the main thing which must work after hwmod conversion. -- Péter -- 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: Difference between twl4030_hsmmc_info and omap_mmc_platform_data
Hi Elvis, On Thu, 2010-10-14 at 23:48 +0200, ext Elvis Dowson wrote: I'm trying to bring up a TI WL1271 wlan module connected to MMC2 controller of a TI OMAP 3530 processor. Some weeks ago I have sent a patch to linux-omap and linux-wireless mailing lists to add support for the wl1271 expansion card on the Beagle board. It was not accepted because of two things: first I had hardcoded the board configuration file, so that it would only work with wl1271 (and not with other expansion boards); second the expansion card should be detected by using the EEPROM connected to the i2c lines in the expansion board, but at the moment Beagle people do this kind of detection in the bootloader and not in the kernel Anyways, the patch I sent works at least with the wl1271 daugther card from CircuitCo, if you just want to try it out. https://patchwork.kernel.org/patch/201572/ -- Cheers, Luca. -- 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
[Added craneboard support 0/1]
From: Srinath srin...@mistralsolutions.com This series adds support for the AM3517/05 based craneboard. We are a team of engineers working at Mistral Solutions and will be sending patches to support this board. Request you to review and accept these patches. Added board file for AM3517/05 craneboard Srinath (1): Added-craneboard-basic-support arch/arm/configs/omap2plus_defconfig|1 + arch/arm/mach-omap2/Kconfig |6 +++ arch/arm/mach-omap2/Makefile|2 + arch/arm/mach-omap2/board-am3517crane.c | 68 +++ 4 files changed, 77 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-am3517crane.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: rx51: mark reserved memory earlier
So that omap_vram_set_sdram_vram() is called before
omap_vram_reserve_sdram_memblock().
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/board-rx51.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index a58e8cb..861079b 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -144,17 +144,22 @@ static void __init rx51_init(void)
static void __init rx51_map_io(void)
{
omap2_set_globals_3xxx();
- rx51_video_mem_init();
omap34xx_map_common_io();
}
+static void __init rx51_reserve(void)
+{
+ rx51_video_mem_init();
+ omap_reserve();
+}
+
MACHINE_START(NOKIA_RX51, Nokia RX-51 board)
/* Maintainer: Lauri Leukkunen lauri.leukku...@nokia.com */
.phys_io= 0x4800,
.io_pg_offst= ((0xfa00) 18) 0xfffc,
.boot_params= 0x8100,
.map_io = rx51_map_io,
- .reserve= omap_reserve,
+ .reserve= rx51_reserve,
.init_irq = rx51_init_irq,
.init_machine = rx51_init,
.timer = omap_timer,
--
1.7.3.1.2.g7fe2b
--
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 2/2] omap: rx51: mark reserved memory earlier
On Fri, Oct 15, 2010 at 3:46 PM, Felipe Contreras felipe.contre...@gmail.com wrote: So that omap_vram_set_sdram_vram() is called before omap_vram_reserve_sdram_memblock(). I actually didn't test this (my battery died). But the previous one works with CONFIG_OMAP2_VRAM_SIZE=6. -- 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: [Added craneboard support 0/1]
srin...@mistralsolutions.com had written, on 10/15/2010 05:27 AM, the following: From: Srinath srin...@mistralsolutions.com This series adds support for the AM3517/05 based craneboard. We are a team of engineers working at Mistral Solutions and will be sending patches to support this board. Request you to review and accept these patches. Added board file for AM3517/05 craneboard Srinath (1): Added-craneboard-basic-support arch/arm/configs/omap2plus_defconfig|1 + arch/arm/mach-omap2/Kconfig |6 +++ arch/arm/mach-omap2/Makefile|2 + arch/arm/mach-omap2/board-am3517crane.c | 68 +++ 4 files changed, 77 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-am3517crane.c Few suggestions: Please read: http://omapedia.org/wiki/Releasing_to_Linux_kernel_using_patches_and_emails http://elinux.org/Git_usage on how to generate patches and post them for example this covering letter is completely unnecessary, the patch1 $subject should have been: OMAP: AM3517/05: board: Add craneboard support All this info that you put in covering letter should have been part of the patch - remember to add a link to craneboard - most of us might not be aware of this board at all. this is the information that will be stored in git commit log for ever+ it has to also flow down from linux-omap down to linux-arm, lkml etc.. imagine yourself being a developer for ppc/intel processor and looking at this patch - the commit message and $subject should explain to them as well.. more as part of patch 1 review comments. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] video: omap: vram: remove from normal memory
So that we can ioremap happily.
Cc: Tomi Valkeinen tomi.valkei...@nokia.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/video/omap2/vram.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index f6fdc20..1a99777 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
}
} else {
paddr = memblock_alloc_base(size, PAGE_SIZE,
MEMBLOCK_REAL_LIMIT);
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
}
omap_vram_add_region(paddr, size);
--
1.7.3.1.2.g7fe2b
--
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: [Added craneboard support 1/1] Added-craneboard-basic-support
srin...@mistralsolutions.com had written, on 10/15/2010 05:27 AM, the
following:
$subject - suggest changes as previously posted.
From: Srinath srin...@mistralsolutions.com
Add information in commit message
Signed-off-by: Srinath srin...@mistralsolutions.com
---
arch/arm/configs/omap2plus_defconfig|1 +
arch/arm/mach-omap2/Kconfig |6 +++
arch/arm/mach-omap2/Makefile|2 +
arch/arm/mach-omap2/board-am3517crane.c | 68 +++
4 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-am3517crane.c
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index ccedde1..8c93f86 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -40,6 +40,7 @@ CONFIG_MACH_OMAP_LDP=y
CONFIG_MACH_OVERO=y
CONFIG_MACH_OMAP3EVM=y
CONFIG_MACH_OMAP3517EVM=y
+CONFIG_MACH_CRANEBOARD=y
CONFIG_MACH_OMAP3_PANDORA=y
CONFIG_MACH_OMAP3_TOUCHBOOK=y
CONFIG_MACH_OMAP_3430SDP=y
Tony can comment if he'd like this in the patch or not - given Linus's
ARM defconfig anger.. :)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..f4cf968 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -174,6 +174,12 @@ config MACH_OMAP3517EVM
default y
select OMAP_PACKAGE_CBB
+config MACH_CRANEBOARD
+ bool AM3517/05 CRANE board
+ depends on ARCH_OMAP3
+ default y
I am guessing default y is a copy of the rest of the Kconfig..
+ select OMAP_PACKAGE_CBB
+
config MACH_OMAP3_PANDORA
bool OMAP3 Pandora
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7352412..f885037 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -170,6 +170,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) +=
board-omap4panda.o \
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
+obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
+
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
hsmmc.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
new file mode 100644
index 000..c9390ce
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -0,0 +1,68 @@
+/*
+ * linux/arch/arm/mach-omap2/board-am3517crane.c
+ *
+ * Copyright (C) 2010 Mistral Solutions Pvt Ltd. www.mistralsolutions.com
+ * Author: R.Srinath srin...@mistralsolutions.com
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/usb.h
Do you need all these headers? I don't see the usage of usb or anything
below - please have just the necessary ones.
+
+/*
+ * Board initialization
+ */
minor comment:
/* Board initialization */
+static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
+};
+
+static struct platform_device *am3517_crane_devices[] __initdata = {
+};
+
+static void __init am3517_crane_init_irq(void)
+{
+ omap_board_config = am3517_crane_config;
+ omap_board_config_size = ARRAY_SIZE(am3517_crane_config);
+
+ omap2_init_common_hw(NULL, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static void __init am3517_crane_init(void)
+{
+ platform_add_devices(am3517_crane_devices,
+ ARRAY_SIZE(am3517_crane_devices));
+ omap_serial_init();
no basic muxing etc?
+}
+
+MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD)
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xd800) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap3_map_io,
+ .reserve= omap_reserve,
+ .init_irq = am3517_crane_init_irq,
+ .init_machine = am3517_crane_init,
+ .timer = omap_timer,
+MACHINE_END
--
Regards,
Nishanth Menon
--
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] omap4: pandaboard: fix up mmc card detect logic
For MMC1 Controller, card detect interrupt source is
twl6030 which is non-gpio. The card detect call back function provides
card present/absent status by reading MMC Control register present
on twl6030. This functionality was introduced in mfd tree on
track to kernel.org
Sync pandaboard to the same and make mmc work.
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Depends on
http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-2.6.git;a=commitdiff;h=1bf5197061a4aec99e9fd4f92d4a543310f83585;hp=0c9b33e5a23e2053165c9e303b3a3cf1b2b8
This patch probably should be squashed to that.
arch/arm/mach-omap2/board-omap4panda.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a9d8a19..47cc8d2 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -160,10 +160,19 @@ static int omap4_twl6030_hsmmc_late_init(struct device
*dev)
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev-platform_data;
+ if (!pdata) {
+ dev_err(dev, %s: NULL platform data\n, __func__);
+ return -EINVAL;
+ }
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
- pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
- MMCDETECT_INTR_OFFSET;
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+if (ret)
+ dev_err(dev, %s: Error card detect config(%d)\n,
+ __func__, ret);
+else
+ pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+ }
return ret;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: pandaboard: fix up mmc card detect logic
Menon, Nishanth had written, on 10/15/2010 08:24 AM, the following:
For MMC1 Controller, card detect interrupt source is
twl6030 which is non-gpio. The card detect call back function provides
card present/absent status by reading MMC Control register present
on twl6030. This functionality was introduced in mfd tree on
track to kernel.org
Sync pandaboard to the same and make mmc work.
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Depends on
http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-2.6.git;a=commitdiff;h=1bf5197061a4aec99e9fd4f92d4a543310f83585;hp=0c9b33e5a23e2053165c9e303b3a3cf1b2b8
This patch probably should be squashed to that.
Note to Tony/Sameo:
I generated this patch for linux-omap after cherry picking the above
patch. reason being:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=refs/heads/omap-for-linus
has fixes we need for Pandaboard
I am at a loss however which tree this patch might be carried on..
arch/arm/mach-omap2/board-omap4panda.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a9d8a19..47cc8d2 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -160,10 +160,19 @@ static int omap4_twl6030_hsmmc_late_init(struct device
*dev)
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev-platform_data;
+ if (!pdata) {
+ dev_err(dev, %s: NULL platform data\n, __func__);
+ return -EINVAL;
+ }
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
- pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
- MMCDETECT_INTR_OFFSET;
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+if (ret)
+ dev_err(dev, %s: Error card detect config(%d)\n,
+ __func__, ret);
+else
+ pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+ }
return ret;
}
--
Regards,
Nishanth Menon
--
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 02/11] OMAP3: PM: Adding voltage driver support for OMAP3
Hi Paul, On 9/30/2010 7:39 PM, Paul Walmsley wrote: Hi Benoît, Thara, On Wed, 29 Sep 2010, Kevin Hilman wrote: Also, I'm still seeing this on boot: omap_hwmod: sr1_fck: missing clockdomain for sr1_fck. omap_hwmod: sr2_fck: missing clockdomain for sr2_fck. We need a final solution for this problem as a prerequisite for this series as well. I guess we need to figure out the appropriate clockdomains for sr1_fck and sr2_fck. Probably the strictly correct thing to do, vis-a-vis the hardware, is to place them into their own SmartReflex clockdomain/powerdomain. But the PRCM doesn't export separate control registers for those, and as I understand it, that clockdomain/powerdomain follows the CORE clockdomains/powerdomain. More or less. In theory the smartreflex power domain goes to OFF only when the device goes to OFF. In device RET the SR power domain is still active. That's why the FCLK is marked as always ON. Another option would be to place them into the WKUP clockdomain. The source of these functional clocks in SR_ALWON_FCLK which in turn is generated by the PRM from SYS_CLK. But that won't increment the CORE clockdomains' use-counter when the SR functional clocks are running, which seems desirable if the SmartReflex clockdomain/powerdomain really does follow CORE. So it seems to me that the best thing to do might be to place these clocks into the CORE_L4 clockdomain. But perhaps you might have a different view? That's should be the proper place, but after several discussion with Vincent then Leo, it appears that the gating of the CORE_L4 interface clock is triggered by a transition of the WKUP clock domain to idle... Yeah, that's a mess... that IP does not follow any PRCM standard :-) Originally I thought the SR_EN bits were located in the wkup register because Vincent was too lazy to create a new register for these 2 bits :-). But in fact because of that hidden dependency with the wkup, it is almost normal to put these bits there. Bottom-line is that we should tie them to the wkup_clkdm. Another important point we already discussed a little bit, but that will require more thoughts, is that the clock domain definition is first: quite fuzzy and then does not belong do the clock itself, but to the modules that are sharing the same interface clock. It means that some clocks will not belong to any clock domains, and this is fine. On OMAP4, that definition is clearly tied to the modules, and thus should be an hwmod attribute more than a clock node attribute. Regards, Benoit -- 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/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
On Fri, Oct 15, 2010 at 09:51:09AM +0300, Jarkko Nikula wrote: So things can get complicated if trying to implement generic transfer API to general purpose block like McBSP compared to some dedicated block where transfer setup is always more or less the same. I tend to agree. Experience with some of the other platforms suggests that doing the abstracted API for data transfers doesn't save you that much unless the hardware is really hard to manage and so needs lots of code that can be factored out from the leaf drivers. -- 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: hmwod: Update the sysc_cache in case module context is lost
Shilimkar, Santosh santosh.shilim...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 15, 2010 3:44 AM
To: Nayak, Rajendra
Cc: linux-omap@vger.kernel.org; Paul Walmsley; Cousson, Benoit; Shilimkar,
Santosh
Subject: Re: [PATCH] OMAP: hmwod: Update the sysc_cache in case module
context is lost
Rajendra Nayak rna...@ti.com writes:
Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).
Shouldn't the driver for each IP be responsible for restoring it's
register contents after context loss, including it's SYSC?
Seems to me that if SYSC is lost, it means the driver's save/restore
is buggy.
I am glad you asked this question. I had a same argument with Benoit
that driver anyway does context save restore for other registers and
it can do SYSC as well.
But Benoit's point was that sysconfig is a part of the PRCM located
in the IP, but this is purely TI implementation specific. The same
IP in another platform will not have this sysconfig entry. That's why
its important to hide them from the driver
OK, but this patch still doesn't address the real problem. Namely, that
*somebody* needs to save/restore the SYSC reg for the IP.
Otherwise, all this patch does is refresh the _sysc_cache with
completely unknown contents. It also somewhat defeats the purpose of
having a cache. If you're going to read SYSC in order to determine
whether or not you can avoid a write, you might as well just blindly
write.
One option to fix the save/restore would be that TI specific context
save/restore could be done in the device layer by adding some additional
save/restore do the functions calling omap_device_[idle|enable].
IOW, most devices just call omap_device directly by doing something like:
struct omap_device_pm_latency omap_wdt_latency[] = {
[0] = {
.deactivate_func = omap_device_idle_hwmods,
.activate_func = omap_device_enable_hwmods,
.flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
But these [de]activate functions can be anything, and could be made into
functions that do some additional save/restore and then call
omap_device_*
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: [Added craneboard support 1/1] Added-craneboard-basic-support
* srin...@mistralsolutions.com srin...@mistralsolutions.com [101015 03:30]: From: Srinath srin...@mistralsolutions.com Signed-off-by: Srinath srin...@mistralsolutions.com --- arch/arm/configs/omap2plus_defconfig|1 + arch/arm/mach-omap2/Kconfig |6 +++ arch/arm/mach-omap2/Makefile|2 + arch/arm/mach-omap2/board-am3517crane.c | 68 +++ 4 files changed, 77 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-am3517crane.c Looks like you're missing the entry in uncompress.h for the uart? To low-level debug, enable CONFIG_DEBUG_LL and CONFIG_EARLY_PRINTK, then have earlyprintk in your kernel cmdline. 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: [RFC][PATCH 2/2] OMAP4: PRCM: Fix usage of prm/cm accessor api's for OMAP4
Hi Paul, On 10/14/2010 8:44 PM, Paul Walmsley wrote: Hello Rajendra, On Tue, 10 Aug 2010, Rajendra Nayak wrote: OMAP's have always had PRCM split into PRM for power and reset management and CM for clock management. In OMAP4 the split (physically) is not very straight forward and there are instances of clock management control registers in PRM and vice versa. However it still makes sense, even on OMAP4 to logically split PRCM into PRM and CM for better understanding and to avoid adding additonal complexity in higher level frameworks which rely on the accessor api;s to do the low level register accesses. Hence this patch makes sure that any clock management code can use the cm_read/write* accessor apis (without knowing the physical split) and power and reset management code can use prm_read/write* accessor api;s. To do this the submodule offsets within PRM/CM1 and CM2 have additonal info embedded in them specifying what base address to use while trying to access registers in the given submodule. The 16 bit signed submodule offset is defined for OMAP4 as Bit 15 |Bit 14:13 |Bit 12:0 Sign bit|base identifier|submodule offset from base The concern that I have with embedding multiple parameters into a single parameter is that it seems like a hack. Why not add an extra parameter for the base identifier, rather than packing it into an existing parameter? The primary constraint that lead us to that proposal was to minimize the impact on the existing code and API for previous OMAPs. That was clearly the goal #1. The other one was the relative simplicity of the implementation. The user of these OMAP4430__MOD macros does not have to care if this is a real offset or just an id. I am not necessarily opposed to your patch as it exists. But I would like to hear your opinions first on separating out the base identifier parameter as a separate function parameter, and then adding an extra field for it into any data structure that would need it. Could you write briefly if you see any significant advantages/disadvantages to that approach? The disadvantage is the relative complexity for the caller of this API, that will have to know what partition should be used. It is fine if the caller is the powerdomain or clockdomain fmwk, but what about all the other callers we have here and there? When we looked at that in Bangalore, we realized that a bunch of code is using these prm/cm APIs. Maybe some cleanup can be done, like in the save / restore part, but we still have some user of that. For the moment, I do not really see any advantage of such approach. The partitioning is changing on every OMAPs, so we do have to abstract that. If it is not done at that level, we will have to define another API on top of that to do exactly the same job. Regards, Benoit For older OMAP's the base identifier is always set to 0. Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Paul Walmsleyp...@pwsan.com Cc: Benoit Coussonb-cous...@ti.com --- arch/arm/mach-omap2/cm.h |4 +- arch/arm/mach-omap2/prcm-common.h | 58 --- arch/arm/mach-omap2/prcm.c| 68 ++-- arch/arm/mach-omap2/prm.h |4 +- 4 files changed, 105 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index a02ca30..7b7ef09 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -23,9 +23,9 @@ #define OMAP34XX_CM_REGADDR(module, reg) \ OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE + (module) + (reg)) #define OMAP44XX_CM1_REGADDR(module, reg) \ - OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + (module) + (reg)) + OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + ((module) (MOD_MASK)) + (reg)) #define OMAP44XX_CM2_REGADDR(module, reg) \ - OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + (module) + (reg)) + OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + ((module) (MOD_MASK)) + (reg)) #include cm44xx.h diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 995b7ed..b93d33e 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -57,10 +57,26 @@ #define BITFIELD(l_bit, u_bit)\ (BITS(u_bit) ~((BITS(l_bit)) 1)) -/* OMAP44XX specific module offsets */ +/* + * OMAP44XX specific module offsets + * The 16 bit submodule offset is defined for OMAP4 as + *Bit 15 |Bit 14:13 |Bit 12:0 + *Sign bit |base identifier|submodule offset from base + */ -/* CM1 instances */ +#define DEFAULT_BASE 0x0 +#define PRM_BASE 0x1 +#define PRCM_MPU_BASE 0x2 +#define CM2_BASE 0x3 +#define BASE_ID_SHIFT 13 +#define MOD_MASK ((1 BASE_ID_SHIFT)-1)
RE: [PATCHv3 00/11] staging tidspbridge: iommu migration
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Thursday, October 14, 2010 7:27 AM To: Guzman Lugo, Fernando Cc: gre...@suse.de; felipe.contre...@nokia.com; ameya.pala...@nokia.com; Menon, Nishanth; hiroshi.d...@nokia.com; o...@wizery.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCHv3 00/11] staging tidspbridge: iommu migration On Tue, Oct 12, 2010 at 5:39 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Oct 11, 2010 at 6:03 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Tue, Oct 5, 2010 at 11:35 PM, Fernando Guzman Lugo x0095...@ti.com wrote: This set of patches remove the dspbridge custom mmu implementation and use iommu module instead. I have tried this, it works for simple tests, but not real use-cases. I applied all your iommu patches. How did you test this? Have you applied: - scatterlist: define SG chain for arm architecture - iovmm: replace __iounmap with omap_iounmap - iovmm: add superpages support to fixed da address - iovmm: IVA2 MMU range is from 0x1100 to 0x - iovmm: no gap checking for fixed address Yes. Also make sure your baseline have this patch: - omap:iommu-load cam register before flushing the entry Huh? That's not even in v2.6.36-rc7, in which baseline is this supposed to be in? Anyway, I'll try adding that. That's is in latest Hiroshi's tree and it is really needed, Otherwise You will have wrong traslations which can cause unexpected behavior. Now I applied that, still fails. What kind of error are you getting? Node allocation failing IIRC. Is it falling to map the Heap?? I mean you see this trace? if (status) pr_err(%s: Failed to map memory for Heap: 0x%x\n, __func__, status); Otherwise, I don't see how that fail is related with iommu changes. Nope. I don't have a complete framework to test MM testcases at this moment See: http://felipec.wordpress.com/2010/10/08/my-arm-development-notes/ I even prepared a tarball so you just need to extract it on your device. It's not difficult to test this with GStreamer, and I don't see how you can be confident that they indeed work without testing some real use-cases. Anyway, I'll try that missing patch. Most of time real use-cases are not so stressing like testcases We can make to test under real stress in order to find out corner cases. However when I test it was pretty stable and just few erros because staging Does not have latest mailbox patches. Also I test in a .35 version of staging. So now I am using a branch with all new patches and I will recheck and test Again any possible issue. Also I will look at your gstreamer fail too. Well, in my experience it's the other way around, the stress test-cases don't catch the errors that happen on real use-case scenarios, no matter how extensive they are. This is a good example. I am facing some unstability with the latest bridge merge. I am looing into That once it is stable I wil check you testcase too to confirm everything is Working fine. Thanks, Fernando. 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: [PATCHv3 00/11] staging tidspbridge: iommu migration
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Friday, October 15, 2010 11:28 AM To: Guzman Lugo, Fernando Cc: gre...@suse.de; felipe.contre...@nokia.com; ameya.pala...@nokia.com; Menon, Nishanth; hiroshi.d...@nokia.com; o...@wizery.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCHv3 00/11] staging tidspbridge: iommu migration On Fri, Oct 15, 2010 at 7:21 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: Well, in my experience it's the other way around, the stress test-cases don't catch the errors that happen on real use-case scenarios, no matter how extensive they are. This is a good example. I am facing some unstability with the latest bridge merge. I am looing into That once it is stable I wil check you testcase too to confirm everything is Working fine. If you want I can provide my working branch on top of .36-rc8 with next-staging merged. If I revert your patches, it works fine. That could be interested. Can you send me the link? Regards, Fernando. -- 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: [PATCHv3 00/11] staging tidspbridge: iommu migration
On Fri, Oct 15, 2010 at 7:21 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: Well, in my experience it's the other way around, the stress test-cases don't catch the errors that happen on real use-case scenarios, no matter how extensive they are. This is a good example. I am facing some unstability with the latest bridge merge. I am looing into That once it is stable I wil check you testcase too to confirm everything is Working fine. If you want I can provide my working branch on top of .36-rc8 with next-staging merged. If I revert your patches, it works fine. -- 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: [PATCHv3 00/11] staging tidspbridge: iommu migration
On Fri, Oct 15, 2010 at 7:53 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: If you want I can provide my working branch on top of .36-rc8 with next-staging merged. If I revert your patches, it works fine. That could be interested. Can you send me the link? There you go: git://gitorious.org/~felipec/linux-omap/felipec.git (fc-dsp-work) HEAD works, HEAD^ doesn't. -- 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
Camera/ISP questions
Sorry for cross-posting, but I'm not sure where best to get help :-( I'm working on an OMAP/3530 board (similar to the BeagleBoard, but of local design). I'm using the 2.6.32+ kernel from Angstrom which has the DVSDK support, including ISP camera support using V4L2. My camera is NTSC or PAL composite input through a TVP5150m1 decoder into the ISP, using 8 bit BT-656 data. This mostly works, but I'm suffering some strange problems. My queries to the TI forums have not yielded any [useful] feedback, so I'm hoping someone on these lists can help. I'm wondering if the BT-656 data from the TVP5150m1 device is compatible with the ISP, based on the comments in TRM 12.1.1 which implies that interlaced data is not supported via BT-656 and I'm pretty sure the data from the TVP _is_ interlaced since it came from an interlaced TV/video camera. Of course, I could be reading this incorrectly... My problem is the raw data from the ISP (UYVY422, grabbed using gstreamer v4l2src (*)) does not seem to be quite right. If I just look at it, e.g. gst-launch v4l2src ! 'video/x-raw-yuv,width=720,height=576,format=(fourcc)UYVY' ! \ ffmpegcolorspace ! 'video/x-raw-yuv,format=(fourcc)YV12' ! xvimagesink the images will tear and streak if there is any motion. Sometimes, there are ghosts (faded after-images) left behind that last for many seconds. Eventually, they will clear up, especially if the image becomes more static. If I try to do much more processing of these images, e.g. encode them into some compressed format like H264, the results are horrible. (*) I also wrote a very simple program to grab the data from the camera instead of using gstreamer v4l2src. This produces the same poorly constructed UYVY stream, so I don't think the problem is in the v4l2src component (but it _could_ be in the v4l2 kernel code, but it doesn't really do anything with the camera data except for managing the DMA+buffers) I created a known data source (not from the camera interface), using ffmpeg to produce a UYVY422 data file from an MP4 that I know looks good. I used this to test the back-end of the pipeline. It does not suffer these problems, even when the image has lots of motion. What leads me to think this is all about the camera/ISP path is that if I introduce a scaling component, I get even stranger results. For example, this pipeline gst-launch v4l2src always-copy=FALSE ! video/x-raw-yuv,width=720,height=576 ! \ TIVidResize name=qos-scaler contiguousInputFrame=TRUE ! \ 'video/x-raw-yuv,format=(fourcc)UYVY,width=320,height=240' ! ffmpegcolorspace ! 'video/x-raw-yuv,format=(fourcc)YV12' ! xvimagesink often has a Venetian-blind look - alternating good data with dark grey bars (that seem to have the desired data underneath). The image tearing and ghosting is much exaggerated. Running that same pipeline with the known good UYVY data file does not exhibit these behaviours. Does anyone have any ideas what might be causing these problems? Ever seen such before? Any ideas what I can look at or, if necessary, a better place to ask? I'm pretty sure I'm up against hardware problems (could be the design, could be the driver or configuration). If anyone has ideas or can help and need to see any of these data, I'll gladly provide them. Thanks for any help/ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2 broken with 36-rc1
On Wed, Aug 25, 2010 at 11:09 AM, Tomi Valkeinen
tomi.valkei...@nokia.com wrote:
On Mon, 2010-08-23 at 10:51 +0200, ext Mike Rapoport wrote:
Tomi Valkeinen wrote:
On Mon, 2010-08-23 at 09:19 +0200, ext Mike Rapoport wrote:
Tomi Valkeinen wrote:
I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
works, but not N900...
May it be that 3430SDP uses SRAM for the framebuffer? Or reserves
framebuffer
memory from the RAM that is not managed by the kernel, e.g with something
like
mem=RAM size - fb size vram=fb size,0x8.. ?
No, SRAM cannot be used on OMAP3s, as SRAM is too small to hold a
framebuffer. And no, I don't think it's reserving it from RAM not
managed by the kernel.
The N900 only sets omap_vram_sdram_{start,size} in rx51_video_mem_init.
I think that it should also call omap_vram_reserve_sdram_memblock():
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 5a1005b..fdfe844 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -101,6 +101,7 @@ void __init rx51_video_mem_init(void)
*/
omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
+ omap_vram_reserve_sdram_memblock();
}
But omap_vram_reserve_sdram_memblock() is called automatically from
arch/arm/plat-omap/common.c. rx51_video_mem_init() should have been
called before that happens. Has the call order changed, so that
omap_vram_reserve_sdram_memblock() is called first, and
rx51_video_mem_init() only after that?
That is indeed the case, -reserve() is now called way earlier in the
boot process, before early param, and before -map_io(), which is a
good thing, because now -reserve() can take away the memory from the
kernel.
I'm sending the patches that fix this for me, you would also need:
http://article.gmane.org/gmane.linux.kernel/1047146
--
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
