Re: [PATCH] arm: omap1/2/3/4: convert clocksource to a platform_driver
Hi, On Tue, Apr 06, 2010 at 12:57:16AM +0200, ext Kevin Hilman wrote: What' you've created is not a generic clocksource driver but one that can only work with the 32k sync timer. so I achieved my goal, which was to convert *32k-sync timer* into a platform_driver. If you're going to create a generic driver, it should be generic enough to work with any timer source: 32k, timer GP, off-chip RTC, etc. To do this, it would need a generic read function passed in with the platform_device. yeah, I don't really see what you're trying to do. IMO we should just register all clocksources to the kernel but it doesn't mean they have to all come from the same platform_driver. The driver I wrote is for the 32k-sync timer, gp timers, mpu-timer they all would have to be converted. I really don't see the point in having all clocksources as one unique driver since the kernel is (or should be) smart enough to choose the best one for us at runtime. If you really want one driver that would cope with all clocksources, be my guest, but IMO, that's not the way to go. It would also need a more generic way of handling clock names and frequencies. Currently the clock rate is hard-coded to 32kHz. clk_get_rate() should be used in a generic driver. but that's what 32k-sync timer uses, right ? for anything else, then it would need more thinking. -- balbi -- 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: Add I2C bus 1 initialisation for OMAP2430
On Tue, Apr 06, 2010 at 08:23:33AM +0200, ext Viral Mehta wrote:
Initialize isp1301 FS USB transceiver and
add I2C bus1 initialization code for OMAP2430
Signed-off-by: Viral Mehta viral.me...@lntinfotech.com
this should go through linux-omap
---
arch/arm/mach-omap2/board-2430sdp.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 01d113f..346e1d2 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -174,9 +174,17 @@ static struct i2c_board_info __initdata
sdp2430_i2c_boardinfo[] = {
},
};
+static struct i2c_board_info __initdata sdp2430_i2c1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(isp1301_omap, 0x2D),
+ .flags = I2C_CLIENT_WAKE,
+ .irq = OMAP_GPIO_IRQ(78),
+ },
+}
static int __init omap2430_i2c_init(void)
{
- omap_register_i2c_bus(1, 400, NULL, 0);
+ omap_register_i2c_bus(1, 100, sdp2430_i2c1_boardinfo,
+ ARRAY_SIZE(sdp2430_i2c1_boardinfo));
omap_register_i2c_bus(2, 2600, sdp2430_i2c_boardinfo,
ARRAY_SIZE(sdp2430_i2c_boardinfo));
return 0;
--
1.6.6
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
__
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
--
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: Add OHCI USB platform init for OMAP2430
On Tue, Apr 06, 2010 at 08:25:25AM +0200, ext Viral Mehta wrote:
Add platform init code for OHCI USB on OMAP2430
Signed-off-by: Viral Mehta viral.me...@lntinfotech.com
this one too
---
arch/arm/mach-omap2/board-2430sdp.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 346e1d2..047d5ae 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -206,6 +206,15 @@ static struct omap_musb_board_data musb_board_data = {
.mode = MUSB_OTG,
.power = 100,
};
+static struct omap_usb_config sdp2430_usb_config __initdata = {
+ .otg= 1,
+#ifdef CONFIG_USB_GADGET_OMAP
+ .hmc_mode = 0x0,
+#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
+ .hmc_mode = 0x1,
+#endif
+ .pins[0]= 3,
+}
static void __init omap_2430sdp_init(void)
{
@@ -216,6 +225,7 @@ static void __init omap_2430sdp_init(void)
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
omap_serial_init();
omap2_hsmmc_init(mmc);
+ omap_usb_init(sdp2430_usb_config);
usb_musb_init(musb_board_data);
board_smc91x_init();
--
1.6.6
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
__
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
--
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: select ARCH_OMAP_OTG for OMAP2430
On Tue, Apr 06, 2010 at 08:26:30AM +0200, ext Viral Mehta wrote: Configuration for OMAP2430 should select ARCH_OMAP_OTG just like it is done for OMAP2420 Signed-off-by: Viral Mehta viral.me...@lntinfotech.com and this --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a8a3d1e..8f9d9c9 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -10,6 +10,7 @@ config ARCH_OMAP2420 config ARCH_OMAP2430 bool OMAP2430 support depends on ARCH_OMAP2 + select ARCH_OMAP_OTG config ARCH_OMAP3430 bool OMAP3430 support -- 1.6.6 This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- balbi -- 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: GPIO: Fix OMAP4 GPIO reg access issues
Tony,
If there are no review comments, can you please push this patch?
-V Charulatha
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, March 22, 2010 8:08 PM
To: linux-omap@vger.kernel.org
Cc: Varadarajan, Charulatha
Subject: [PATCH] OMAP: GPIO: Fix OMAP4 GPIO reg access issues
Access to some of the OMAP4 GPIO registers are not properly handled.
This patch fixes it.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/plat-omap/gpio.c | 61 +++-
1 files changed, 55 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 76a347b..3a9891c 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -137,7 +137,11 @@
#define OMAP4_GPIO_IRQSTATUSCLR1 0x0040
#define OMAP4_GPIO_IRQWAKEN0 0x0044
#define OMAP4_GPIO_IRQWAKEN1 0x0048
-#define OMAP4_GPIO_SYSSTATUS 0x0104
+#define OMAP4_GPIO_SYSSTATUS 0x0114
+#define OMAP4_GPIO_IRQENABLE10x011c
+#define OMAP4_GPIO_WAKE_EN 0x0120
+#define OMAP4_GPIO_IRQSTATUS20x0128
+#define OMAP4_GPIO_IRQENABLE20x012c
#define OMAP4_GPIO_CTRL 0x0130
#define OMAP4_GPIO_OE0x0134
#define OMAP4_GPIO_DATAIN0x0138
@@ -148,6 +152,10 @@
#define OMAP4_GPIO_FALLINGDETECT 0x014c
#define OMAP4_GPIO_DEBOUNCENABLE 0x0150
#define OMAP4_GPIO_DEBOUNCINGTIME0x0154
+#define OMAP4_GPIO_CLEARIRQENABLE1 0x0160
+#define OMAP4_GPIO_SETIRQENABLE1 0x0164
+#define OMAP4_GPIO_CLEARWKUENA 0x0180
+#define OMAP4_GPIO_SETWKUENA 0x0184
#define OMAP4_GPIO_CLEARDATAOUT 0x0190
#define OMAP4_GPIO_SETDATAOUT0x0194
/*
@@ -591,12 +599,16 @@ static int _get_gpio_dataout(struct gpio_bank *bank, int
gpio)
reg += OMAP7XX_GPIO_DATA_OUTPUT;
break;
#endif
-#ifdef CONFIG_ARCH_OMAP2PLUS
+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
case METHOD_GPIO_24XX:
- case METHOD_GPIO_44XX:
reg += OMAP24XX_GPIO_DATAOUT;
break;
#endif
+#ifdef CONFIG_ARCH_OMAP4
+ case METHOD_GPIO_44XX:
+ reg += OMAP4_GPIO_DATAOUT;
+ break;
+#endif
default:
return -EINVAL;
}
@@ -1200,11 +1215,17 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
#endif
if (!cpu_class_is_omap1()) {
if (!bank-mod_usage) {
+ void __iomem *reg = bank-base;
u32 ctrl;
- ctrl = __raw_readl(bank-base + OMAP24XX_GPIO_CTRL);
- ctrl = 0xFFFE;
+
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ reg += OMAP24XX_GPIO_CTRL;
+ else if (cpu_is_omap44xx())
+ reg += OMAP4_GPIO_CTRL;
+ ctrl = __raw_readl(reg);
/* Module is enabled, clocks are not gated */
- __raw_writel(ctrl, bank-base + OMAP24XX_GPIO_CTRL);
+ ctrl = 0xFFFE;
+ __raw_writel(ctrl, reg);
}
bank-mod_usage |= 1 offset;
}
@@ -1226,22 +1247,34 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
__raw_writel(1 offset, reg);
}
#endif
-#ifdef CONFIG_ARCH_OMAP2PLUS
- if ((bank-method == METHOD_GPIO_24XX) ||
- (bank-method == METHOD_GPIO_44XX)) {
+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
+ if (bank-method == METHOD_GPIO_24XX) {
/* Disable wake-up during idle for dynamic tick */
void __iomem *reg = bank-base + OMAP24XX_GPIO_CLEARWKUENA;
__raw_writel(1 offset, reg);
}
#endif
+#ifdef CONFIG_ARCH_OMAP4
+ if (bank-method == METHOD_GPIO_44XX) {
+ /* Disable wake-up during idle for dynamic tick */
+ void __iomem *reg = bank-base + OMAP4_GPIO_IRQWAKEN0;
+ __raw_writel(1 offset, reg);
+ }
+#endif
if (!cpu_class_is_omap1()) {
bank-mod_usage = ~(1 offset);
if (!bank-mod_usage) {
+ void __iomem *reg = bank-base;
u32 ctrl;
- ctrl = __raw_readl(bank-base + OMAP24XX_GPIO_CTRL);
+
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ reg += OMAP24XX_GPIO_CTRL;
+ else if (cpu_is_omap44xx())
+ reg += OMAP4_GPIO_CTRL;
+ ctrl = __raw_readl(reg);
/* Module is disabled, clocks are gated */
ctrl |= 1;
- __raw_writel(ctrl, bank-base +
Re: [PATCH 0/5] OMAP: RX51: Add LCD Panel Support for N900
Hi Roger, Roger Quadros roger.quad...@nokia.com writes: These patches get the N900 LCD panel working. Apply's cleanly on 2.6.34-rc2 Pre-requisites: https://patchwork.kernel.org/patch/86318/ https://patchwork.kernel.org/patch/86319/ https://patchwork.kernel.org/patch/86320/ First, thanks for pushing the missing bits for N900 hardware support upstream! I wanted to give your patches a try and test a l-o kernel on my N900 (I know I won't have full hardware support ... at the moment). Using current l-o tree with your 5 panel patches and the 3 you link on patchwork, I initially ended up with a kernel panic in omap3_onenand_write_bufferram() (i.e. unrelated to your patches). With http://patchwork.ozlabs.org/patch/48337/ (mtd: OneNAND: OMAP3: unmap correct DMA buffer), I am able to get the official Nokia /sbin/preinit called: then, getbootstate reports a malfunction but AFAICT, the panel is working ok. If there are additional patches I should be aware of regarding N900 support, I am also interested. Cheers, a+ -- 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: USB on omap2430
Felipe Balbi wrote: On Mon, Apr 05, 2010 at 07:32:06PM +0530, Viral Mehta wrote: After adding the above code, isp1301's probe is called but that fails before it does otg_set_transceiver() And I am debugging further on that path. ok, cool. When you get that done, please send a cleaned up diff with your signed-off-by line so it can be integrated. I continued debugging further. It fails during USB initialisation. More specifically, in omap_otg_init() function in arch/arm/plat-omap/usb.c It gives a crash dump on the first line itself syscon = omap_readl(OTG_SYSCON_1) 0x; without the crash itself, it's pretty difficult to help. It could even be just a missing clk_enable(). Although I believe that code shouldn't be running for 2430, only for 2420. Can you try the patch below: Apart from that, can I submit the 3 patches that we discussed earlier ? (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg25932.html) These will not make FS USB functional on OMAP2430 but these changes are anyway necessary. clean those patches first. And I'd like someone else with the 2430sdp board to test it before I add my SOB. I dug up a 2430 board (VG5.0.1 - a later version than Viral's) , but these patches don't work for me. I also found the board schematics. Looks like there are different versions of the 2430 SDP, each with different layouts and components for the USBtransceivers. I believe there's no one-size fits all. I think the best bet is to go with Viral's patch series, as long as they work for him - don't think anyone else is using the 2430SDP these days. We can fix up as and when required. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP: RX51: Add LCD Panel Support for N900
Hi, ext Arnaud Ebalard wrote: Hi Roger, Roger Quadros roger.quad...@nokia.com writes: These patches get the N900 LCD panel working. Apply's cleanly on 2.6.34-rc2 Pre-requisites: https://patchwork.kernel.org/patch/86318/ https://patchwork.kernel.org/patch/86319/ https://patchwork.kernel.org/patch/86320/ First, thanks for pushing the missing bits for N900 hardware support upstream! I wanted to give your patches a try and test a l-o kernel on my N900 (I know I won't have full hardware support ... at the moment). Using current l-o tree with your 5 panel patches and the 3 you link on patchwork, I initially ended up with a kernel panic in omap3_onenand_write_bufferram() (i.e. unrelated to your patches). With http://patchwork.ozlabs.org/patch/48337/ (mtd: OneNAND: OMAP3: unmap correct DMA buffer), I am able to get the official Nokia /sbin/preinit called: then, getbootstate reports a malfunction but AFAICT, the panel is working ok. The getbootstate malfunction is expected as there is no support for it yet in mainline. But you should get to shell without that. You could hack the startup script to spawn a getty on ttyS2. This should get you to shell. so in /sbin/preinit, in start_shell() -/sbin/getty 115200 ttyS0 -n -l /bin/sh +/sbin/getty 115200 ttyS2 -n -l /bin/sh cheers, -roger -- 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
[PM-WIP-OPP][PATCH] OMAP3 PM: Fix issue with opp_find_freq_floor
opp_find_freq_floor should return the lower enabled* OPP from a starting freq from a start opp list. But current code returns next lower opp. This patch fixes this issue. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c index bb8120e..13da451 --- a/arch/arm/plat-omap/opp.c +++ b/arch/arm/plat-omap/opp.c @@ -208,7 +208,7 @@ struct omap_opp *opp_find_freq_floor(enum opp_t opp_type, unsigned long *freq) *freq = prev_opp-rate; - return oppl; + return prev_opp; } /* wrapper to reuse converting opp_def to opp struct */ -- 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
[PM-WIP-OPP][PATCH] OMAP3630 PM: Update for OPP 1GHz
It is found that system is not very stable with current 1GHz OPP configuration
(a...@1g, i...@880m, v...@1.31v) and it has been recommended to
use below configuration for stable 1GHz OPP.
(a...@1g, i...@800m, v...@1.35v).
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
index c453ec5..189c42e
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -82,7 +82,7 @@ static struct omap_opp_def __initdata
omap36xx_mpu_rate_table[] = {
/* OPP3 - OPP-Turbo */
OMAP_OPP_DEF(false, 8, 126),
/* OPP4 - OPP-SB */
- OMAP_OPP_DEF(false, 10, 131),
+ OMAP_OPP_DEF(false, 10, 135),
/* Terminator */
OMAP_OPP_DEF(0, 0, 0)
};
@@ -104,7 +104,7 @@ static struct omap_opp_def __initdata
omap36xx_dsp_rate_table[] = {
/* OPP3 - OPP-Turbo */
OMAP_OPP_DEF(false, 66000, 126),
/* OPP4 - OPP-SB */
- OMAP_OPP_DEF(false, 87500, 131),
+ OMAP_OPP_DEF(false, 8, 135),
/* Terminator */
OMAP_OPP_DEF(0, 0, 0)
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP: Flash device support 3630 sdp board
Sukumar Ghorai (2): OMAP3630SDP: Add support for Flash OMAP3630SDP: enable Flash device support arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-3630sdp.c | 111 + arch/arm/mach-omap2/board-sdp-flash.c |2 + arch/arm/configs/omap_3630sdp_defconfig | 77 ++- -- 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] OMAP3630SDP: Add support for Flash
Add support for NAND, OneNAND, NOR on OMAP 3630-sdp board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-3630sdp.c | 111 +
arch/arm/mach-omap2/board-sdp-flash.c |2 +
3 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..0cf463c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -133,6 +133,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3) +=
board-zoom3.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
+ board-sdp-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 504d2bd..a2ce116 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -22,9 +22,11 @@
#include plat/usb.h
#include mach/board-zoom.h
+#include mach/board-sdp.h
#include mux.h
#include sdram-hynix-h8mbx00u0mer-0em.h
+extern void sdp_flash_init(struct flash_partitions[]);
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
@@ -93,12 +95,121 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+static struct mtd_partition sdp_nor_partitions[] = {
+ /* bootloader (U-Boot, etc) in first sector */
+ {
+ .name = Bootloader-NOR,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ /* bootloader params in the next sector */
+ {
+ .name = Params-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K,
+ .mask_flags = 0,
+ },
+ /* kernel */
+ {
+ .name = Kernel-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ .mask_flags = 0
+ },
+ /* file system */
+ {
+ .name = Filesystem-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0
+ }
+};
+
+static struct mtd_partition sdp_onenand_partitions[] = {
+ {
+ .name = X-Loader-OneNAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot Environment-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 1 * (64 * 2048),
+ },
+ {
+ .name = Kernel-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 16 * (64 * 2048),
+ },
+ {
+ .name = File System-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct mtd_partition sdp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 6 * (64 * 2048),
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 40 * (64 * 2048),
+ },
+ {
+ .name = File System - NAND,
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND, /* Offset =
[PATCH 2/2] OMAP3630SDP: enable Flash device support
update config file to support for NAND, OneNAND, NOR on OMAP 3630-sdp board. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- --- arch/arm/configs/omap_3630sdp_defconfig | 77 ++- 1 files changed, 76 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_3630sdp_defconfig b/arch/arm/configs/omap_3630sdp_defconfig index 609f348..a623927 100644 --- a/arch/arm/configs/omap_3630sdp_defconfig +++ b/arch/arm/configs/omap_3630sdp_defconfig @@ -461,7 +461,82 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y -# CONFIG_MTD is not set +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +# CONFIG_MTD_TESTS is not set +CONFIG_MTD_CONCAT=y +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_REDBOOT_PARTS is not set +CONFIG_MTD_CMDLINE_PARTS=y +# CONFIG_MTD_AFS_PARTS is not set +# CONFIG_MTD_AR7_PARTS is not set +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set +# CONFIG_SSFDC is not set +# CONFIG_MTD_OOPS is not set + +# +# RAM/ROM/Flash chip drivers +# +CONFIG_MTD_CFI=y +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_GEN_PROBE=y +# CONFIG_MTD_CFI_ADV_OPTIONS is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +CONFIG_MTD_CFI_INTELEXT=y +# CONFIG_MTD_CFI_AMDSTD is not set +# CONFIG_MTD_CFI_STAA is not set +CONFIG_MTD_CFI_UTIL=y +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +CONFIG_MTD_PHYSMAP=y +# CONFIG_MTD_PHYSMAP_COMPAT is not set +# CONFIG_MTD_ARM_INTEGRATOR is not set +# CONFIG_MTD_PLATRAM is not set + +CONFIG_MTD_NAND=y +# CONFIG_MTD_NAND_VERIFY_WRITE is not set +# CONFIG_MTD_NAND_ECC_SMC is not set +# CONFIG_MTD_NAND_MUSEUM_IDS is not set +# CONFIG_MTD_NAND_GPIO is not set +CONFIG_MTD_NAND_OMAP2=y +CONFIG_MTD_NAND_OMAP_PREFETCH=y +# CONFIG_MTD_NAND_OMAP_PREFETCH_DMA is not set +CONFIG_MTD_NAND_IDS=y +# CONFIG_MTD_NAND_DISKONCHIP is not set +# CONFIG_MTD_NAND_NANDSIM is not set +# CONFIG_MTD_NAND_PLATFORM is not set +# CONFIG_MTD_ALAUDA is not set +CONFIG_MTD_ONENAND=y +# CONFIG_MTD_ONENAND_VERIFY_WRITE is not set +# CONFIG_MTD_ONENAND_GENERIC is not set +CONFIG_MTD_ONENAND_OMAP2=y +# CONFIG_MTD_ONENAND_OTP is not set +# CONFIG_MTD_ONENAND_2X_PROGRAM is not set +# CONFIG_MTD_ONENAND_SIM is not set # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_COW_COMMON is not set -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3630SDP: Add support for Flash
On Tue, Apr 6, 2010 at 5:59 PM, Sukumar Ghorai s-gho...@ti.com wrote: Add support for NAND, OneNAND, NOR on OMAP 3630-sdp board. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- Feel free to add my acked-by: Acked-by: Vimal Singh vimal.neww...@gmail.com Regards, Vimal -- 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 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
-Original Message-
From: Premi, Sanjeev
Sent: Monday, April 05, 2010 6:39 PM
To: Sripathy, Vishwanath; Paul Walmsley
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Sripathy, Vishwanath
Sent: Monday, April 05, 2010 5:23 PM
To: Paul Walmsley
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, April 05, 2010 4:44 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass
Clock Divider
On Mon, 5 Apr 2010, Sripathy, Vishwanath wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
On Thu, 1 Apr 2010, Vishwanath BS wrote:
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-
omap2/clock3xxx_data.c
index d5153b6..d8e57a6
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
sdrc_ick_p = clk_get(NULL, sdrc_ick);
arm_fck_p = clk_get(NULL, arm_fck);
+ /* Set the bypass clock dividers for DPLL1 and DPLL2 */
+ if (cpu_is_omap3630()) {
+ clk_set_rate(dpll1_fck, 4/2);
+ clk_set_rate(dpll2_fck, 4/2);
+ } else {
+ clk_set_rate(dpll1_fck, 33200/4);
+ clk_set_rate(dpll2_fck, 33200/4);
+ }
This code is highly OPP-specific. Why is this code needed here?
Shouldn't the code in resource34xx.c be sufficient?
Code in resource34xx.c will be executed only when DVFS is
executed.
However above code makes sure that initial values of Bypass clock
dividers are good. This will ensure that even if DVFS is disabled,
IVA/MPU are never overclocked when they enter bypass mode.
My point is that you don't know how the bootloader has
configured the
system at the point when this code executes. You don't
know what voltage
level VDD1 and VDD2 are at; you don't know what state the
clock tree is
in. You only know this when you change OPPs. And the
selection of the
OPP at startup is use-case dependent.
May be I can move this code to init_opp?
I have been trying to find a good place for the same myself. Though,
my reason is different. The default kernel boots with the OPP3 for
OMAP34xx; but when mpurate is used to set 720; I feel sometimes the
boot may fail if the voltage isn't right.
I thought uboot would have set the right voltage while setting the MPU rate.
Isn't that true?
The voltage does stabilize when smartrelex reflex is initialized.
Why do you have dependency on SR for voltage stabilization? You can set the
right voltage even w/o SR (via VP). SR is only for optimizing Voltage for a
given OPP.
Regards
Vishwa
I was trying to move smartreflex above in the init sequence; after
i2c has been initialized.
Comments/ thoughts?
Best regards,
Sanjeev
So as far as I can tell, this code shouldn't be there. If
you want to do
something like this, then you should add some generic way
(e.g., a kernel
command line parameter) to set the VDD1 and VDD2 OPPs at boot.
- Paul
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap1/2/3/4: convert clocksource to a platform_driver
On Tue, Apr 06, 2010 at 04:43:52PM +0200, ext Kevin Hilman wrote: so I achieved my goal, which was to convert *32k-sync timer* into a platform_driver. OK, then I misunderstood your goal. Based on $SUBJECT, I thought you were trying to create a generic clocksource driver. ok, so it was my bad on the subject choice, maybe something like arm: omap1/2/3/4: convert 32k-sync timer driver into a platform_driver would've been better. Sorry for the confusion, np. Sorry for the bad $SUBJECT -- balbi -- 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: [PM-WIP-OPP][PATCH] OMAP3630 PM: Update for OPP 1GHz
Sripathy, Vishwanath had written, on 04/06/2010 01:06 PM, the following:
It is found that system is not very stable with current 1GHz OPP configuration
(a...@1g, i...@880m, v...@1.31v) and it has been recommended to
use below configuration for stable 1GHz OPP.
(a...@1g, i...@800m, v...@1.35v).
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
index c453ec5..189c42e
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -82,7 +82,7 @@ static struct omap_opp_def __initdata
omap36xx_mpu_rate_table[] = {
/* OPP3 - OPP-Turbo */
OMAP_OPP_DEF(false, 8, 126),
/* OPP4 - OPP-SB */
- OMAP_OPP_DEF(false, 10, 131),
+ OMAP_OPP_DEF(false, 10, 135),
/* Terminator */
OMAP_OPP_DEF(0, 0, 0)
};
@@ -104,7 +104,7 @@ static struct omap_opp_def __initdata
omap36xx_dsp_rate_table[] = {
/* OPP3 - OPP-Turbo */
OMAP_OPP_DEF(false, 66000, 126),
/* OPP4 - OPP-SB */
- OMAP_OPP_DEF(false, 87500, 131),
+ OMAP_OPP_DEF(false, 8, 135),
/* Terminator */
OMAP_OPP_DEF(0, 0, 0)
};
Acked-by: Nishanth Menon n...@ti.com
--
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: [PATCHv2 0/3] OMAP: DSS2: Allow us to use SDI
hi Tomi, Valkeinen Tomi (Nokia-D/Helsinki) wrote: Hi, On Wed, 2010-03-17 at 13:35 +0100, Quadros Roger (Nokia-D/Helsinki) wrote: SDI now makes use of vdds_sdi regulator supply. DPI can now be disabled on systems that don't have it changes since v1: - Incorporated review comments - no more omap3xx checks for regulator enable/disable in SDI - Added Kconfig option to enable/disable DPI Roger Quadros (3): OMAP: DSS2: Add Kconfig option for DPI display type OMAP: DSS2: Remove redundant enable/disable calls from SDI OMAP: DSS2: Use vdds_sdi regulator supply in SDI I think this patch set looks ok. Thanks! Tomi Ps. I took the liberty of removing an extra #include plat/cpu.h What is the status of this patch set? Is it supposed to go into your tree or Tony's tree? cheers -roger -- 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: [PM-WIP-OPP][PATCH] OMAP3 PM: Fix issue with opp_find_freq_floor
Sripathy, Vishwanath had written, on 04/06/2010 12:56 PM, the following: opp_find_freq_floor should return the lower enabled* OPP from a starting freq from a start opp list. But current code returns next lower opp. This patch fixes this issue. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c index bb8120e..13da451 --- a/arch/arm/plat-omap/opp.c +++ b/arch/arm/plat-omap/opp.c @@ -208,7 +208,7 @@ struct omap_opp *opp_find_freq_floor(enum opp_t opp_type, unsigned long *freq) *freq = prev_opp-rate; - return oppl; + return prev_opp; } Thanks. yep. since we return *freq with the right rate, we should point also to the right opp. Acked-by: Nishanth Menon n...@ti.com -- 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] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Tuesday, April 06, 2010 12:01 AM To: Madhusudhan Cc: m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh'; t...@atomide.com; svenk...@ti.com; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance. Hi, On Mon, Apr 05, 2010 at 12:19:29PM -0500, Madhusudhan wrote: Since the first if command already checks for the 8-bit the second check like = 4 is definitely not readable in my opinion. how come ??? Functionally do you see anything wrong with this patch?? functionally no, but (hypothetical situation) and if on omap4/5/6/whatever, omap controller supports a bigger bus width then you'll have to add a line like: + if (mmc_slot(host).wires == 16) + mmc-caps |= (MMC_CAP_16_BIT_DATA | MMC_CAP_8_BIT_DATA | + MMC_CAP_4_BIT_DATA); - if (mmc_slot(host).wires == 8) + else if (mmc_slot(host).wires == 8) do you see the problem ?? In my opinion it doesn't scale well. The point we should note here is that MMC spec supports a max bus width of 8-bit. So anything beyond 8-bit is not in the picture as of today. But, my bad on miss interpreting the snippet Felipe sent earlier. if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; I missed the fact that you removed the setting of 4-bit from the first check. I am okay with the above snippet as it is a trivial change that we are trying to patch here which fixes an important issue. Regards, Madhu -- balbi -- 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] OMAP: Fix for bus width which improves SD card's peformance.
On Tue, Apr 06, 2010 at 06:16:01PM +0200, ext Madhusudhan wrote: -Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Tuesday, April 06, 2010 12:01 AM To: Madhusudhan Cc: m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh'; t...@atomide.com; svenk...@ti.com; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance. Hi, On Mon, Apr 05, 2010 at 12:19:29PM -0500, Madhusudhan wrote: Since the first if command already checks for the 8-bit the second check like = 4 is definitely not readable in my opinion. how come ??? Functionally do you see anything wrong with this patch?? functionally no, but (hypothetical situation) and if on omap4/5/6/whatever, omap controller supports a bigger bus width then you'll have to add a line like: + if (mmc_slot(host).wires == 16) + mmc-caps |= (MMC_CAP_16_BIT_DATA | MMC_CAP_8_BIT_DATA | + MMC_CAP_4_BIT_DATA); - if (mmc_slot(host).wires == 8) + else if (mmc_slot(host).wires == 8) do you see the problem ?? In my opinion it doesn't scale well. The point we should note here is that MMC spec supports a max bus width of 8-bit. So anything beyond 8-bit is not in the picture as of today. in that case, the code could be: WARN_ON(mmc_slot(host).wires 8); if (mmc_slot(host).wires == 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
-Original Message-
From: Muralidharan Karicheri [mailto:mkarich...@gmail.com]
Sent: Saturday, April 03, 2010 1:33 AM
To: Hiremath, Vaibhav
Cc: linux-me...@vger.kernel.org; Karicheri, Muralidharan;
mche...@redhat.com; linux-omap@vger.kernel.org; t...@atomide.com
Subject: Re: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver
on top of DSS2
Vaibhav,
I have some comments on this patch. Please address them.
[Hiremath, Vaibhav] Thanks Murali, I really appreciate your comments here.
Please find response below -
+
+#include asm/processor.h
Add a line here??
+#include plat/dma.h
+#include plat/vram.h
+#include plat/vrfb.h
+#include plat/display.h
+
+#include omap_voutlib.h
+#include omap_voutdef.h
+
+MODULE_AUTHOR(Texas Instruments);
+MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
+MODULE_LICENSE(GPL);
+
+
+/* Driver Configuration macros */
+#define VOUT_NAME omap_vout
+
+enum omap_vout_channels {
+ OMAP_VIDEO1 = 0,
Why do we have to initialize this to 0. It always start with a value 0
by default.
+ OMAP_VIDEO2,
+};
+
+enum dma_channel_state {
+ DMA_CHAN_NOT_ALLOTED = 0,
Ditto.
+ DMA_CHAN_ALLOTED,
+};
+
+#define QQVGA_WIDTH160
+#define QQVGA_HEIGHT 120
+
+/* Max Resolution supported by the driver */
+#define VID_MAX_WIDTH 1280/* Largest width */
+#define VID_MAX_HEIGHT 720 /* Largest height */
+
-
+
+module_param(debug, bool, S_IRUGO);
+MODULE_PARM_DESC(debug, Debug level (0-1));
+
+/* Local Helper functions */
+static void omap_vout_isr(void *arg, unsigned int irqstatus);
+static void omap_vout_cleanup_device(struct omap_vout_device *vout);
+
Is there a reason why you need these prototypes? I think we could
remove these prototypes and move the function ahead in the file before
it is called.
[Hiremath, Vaibhav] Do you see any harm with this? I think its only
implementation part. But still I will incorporate in next version.
+/* list of image formats supported by OMAP2 video pipelines */
+const static struct v4l2_fmtdesc omap_formats[] = {
+ {
+ /* Note: V4L2 defines RGB565 as:
+*
+* Byte 0Byte 1
+* g2 g1 g0 r4 r3 r2 r1 r0 b4 b3 b2 b1 b0 g5 g4 g3
+*
+* We interpret RGB565 as:
+*
+* Byte 0Byte 1
+* g2 g1 g0 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4 g3
+*/
+ .description = RGB565, le,
+ .pixelformat = V4L2_PIX_FMT_RGB565,
+ },
+ {
+ /* Note: V4L2 defines RGB32 as: RGB-8-8-8-8 we use
+* this for RGB24 unpack mode, the last 8 bits are
ignored
+* */
+ .description = RGB32, le,
+ .pixelformat = V4L2_PIX_FMT_RGB32,
+ },
+ {
+ /* Note: V4L2 defines RGB24 as: RGB-8-8-8 we use
+*this for RGB24 packed mode
+*
+*/
+ .description = RGB24, le,
+ .pixelformat = V4L2_PIX_FMT_RGB24,
+ },
+ {
+ .description = YUYV (YUV 4:2:2), packed,
+ .pixelformat = V4L2_PIX_FMT_YUYV,
+ },
+ {
+ .description = UYVY, packed,
+ .pixelformat = V4L2_PIX_FMT_UYVY,
+ },
+};
+
+#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
+
+/*
+ * Allocate buffers
+ */
--
+
+/*
+ * omap_vout_uservirt_to_phys: This inline function is used to convert
user
+ * space virtual address to physical address.
+ */
+static u32 omap_vout_uservirt_to_phys(u32 virtp)
+{
+ unsigned long physp = 0;
+ struct vm_area_struct *vma;
+ struct mm_struct *mm = current-mm;
+
+ vma = find_vma(mm, virtp);
+ /* For kernel direct-mapped memory, take the easy way */
+ if (virtp = PAGE_OFFSET) {
+ physp = virt_to_phys((void *) virtp);
+ } else if (vma (vma-vm_flags VM_IO)
+vma-vm_pgoff) {
+ /* this will catch, kernel-allocated,
+ mmaped-to-usermode addresses */
+ physp = (vma-vm_pgoff PAGE_SHIFT) + (virtp - vma-
vm_start);
+ } else {
+ /* otherwise, use get_user_pages() for general userland
pages */
+ int res, nr_pages = 1;
+ struct page *pages;
+ down_read(current-mm-mmap_sem);
+
+ res = get_user_pages(current, current-mm, virtp,
nr_pages,
+ 1, 0, pages, NULL);
+
RE: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, March 23, 2010 10:27 AM To: Pais, Allen Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Pandita, Vikram Subject: Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3 * Pais, Allen allen.p...@ti.com [100322 22:42]: With this patch[DEBUG_LL + earlyprintk], I still haven't been able to boot the kernel. Is it working on your side. The commit am using is : a842b5f9ce70e1b738eabb4d719860070180ed1c I think you will also need the 3630 serial fixes series posted recently. I just merged those into omap-fixes-for-linus (and master) branch(es). Maybe give it a try with at commit b3c7740a120c8a7775cb63b4d094466da5c01692 + this patch? Thanks, I'll pull in those fixes. I believe the mux errors are fixed. Have a look at http://dev.omapzoom.org/?p=manju/kernel-omap3- dev.git;a=commit;h=3499f5023ee90dc6ee3868a3147b87fe22a1d9b7 Patch must have been missed some how. OK, we really should get fixes like that to mainline kernel ASAP to avoid duplicating the effort. Hi, Without doing cherry-pick of above patch url (that Allen mentioned), there's an error when trying to get uart4_[i,f]ck clocks during bootup. Is this patch being pushed anywhere already? IMHO, at least it should be on omap-testing, but ideally on omap-fixes-for-linus branch. What do you think? Regards, Sergio Then at least one issue remains for zoom3 to be usable.. I'm getting tons of MMC errors trying to mount root on it: mmcblk1: error -110 transferring data, sector 2097024, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2097024 ... Any ideas if that's fixed somewhere also? 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 -- 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] OMAP: Fix for bus width which improves SD card's peformance.
Felipe Balbi had written, on 04/06/2010 11:32 AM, the following:
On Tue, Apr 06, 2010 at 06:16:01PM +0200, ext Madhusudhan wrote:
-Original Message-
From: Felipe Balbi [mailto:m...@felipebalbi.com]
Sent: Tuesday, April 06, 2010 12:01 AM
To: Madhusudhan
Cc: m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh';
t...@atomide.com; svenk...@ti.com; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; jarkko.lavi...@nokia.com
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's
peformance.
Hi,
On Mon, Apr 05, 2010 at 12:19:29PM -0500, Madhusudhan wrote:
Since the first if command already checks for the 8-bit the second check
like = 4 is definitely not readable in my opinion.
how come ???
Functionally do you see anything wrong with this patch??
functionally no, but (hypothetical situation) and if on
omap4/5/6/whatever, omap controller supports a bigger bus width then
you'll have to add a line like:
+ if (mmc_slot(host).wires == 16)
+ mmc-caps |= (MMC_CAP_16_BIT_DATA | MMC_CAP_8_BIT_DATA |
+ MMC_CAP_4_BIT_DATA);
- if (mmc_slot(host).wires == 8)
+ else if (mmc_slot(host).wires == 8)
do you see the problem ?? In my opinion it doesn't scale well.
The point we should note here is that MMC spec supports a max bus width of
8-bit. So anything beyond 8-bit is not in the picture as of today.
in that case, the code could be:
WARN_ON(mmc_slot(host).wires 8);
if (mmc_slot(host).wires == 8)
mmc-caps |= MMC_CAP_8_BIT_DATA;
if (mmc_slot(host).wires = 4)
mmc-caps |= MMC_CAP_4_BIT_DATA;
some reasons why i love switch statements ;) since I dont expect other
than precisely 4 and 8 (do we expect 5,6,7 - i might be wrong).. but if
it is so, wont the following be better?
switch (mmc_slot(host).wires)
{
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* fall thru*/
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
default:
WARN(bad width);
}
--
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] OMAP: Fix for bus width which improves SD card's peformance.
On Tue, Apr 06, 2010 at 06:55:03PM +0200, ext Nishanth Menon wrote:
some reasons why i love switch statements ;) since I dont expect other
than precisely 4 and 8 (do we expect 5,6,7 - i might be wrong).. but if
it is so, wont the following be better?
switch (mmc_slot(host).wires)
{
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* fall thru*/
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
default:
WARN(bad width);
}
I like that, but I remember Madhu (or someone else) saying he thinks
it's less readable this way. Go figure...
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Initial change for merge of new board
Hi all, I'm beginning to merge some of the changes for my new board. These include: * Adding macros to compute the ACTIM values for the SDRAM timings, eliminating magic numbers. The original authors may want to verify their timings were converted correctly. * Adding the ability to use the clock API to select the divider for sys_clkout2 * Making the GPRC timing API aware of the time-granularity flag Let me know if there are any comments or questions. Cheers, Laine Walker-Avina PASCO scientific Laine Walker-Avina (5): OMAP: Add in helper macros for the SDRAM timings OMAP: Convert the sdram-*.h timings to use the SDRAM timing macros OMAP: Add SDRAM timings for Micron mt46h16m32lf-6 OMAP: Add support for setting the divider for sys_clkout2 using clk_set_rate OMAP: Make set_gpmc_timing_reg aware of the TIMEPARAGRANULARITY flag arch/arm/mach-omap2/clock3xxx_data.c |1 + arch/arm/mach-omap2/gpmc.c | 14 +++- arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 44 - arch/arm/mach-omap2/sdram-micron-mt46h16m32lf-6.h | 67 arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h | 44 - arch/arm/mach-omap2/sdram-numonyx-m65kam.h | 52 +-- .../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 50 +-- arch/arm/plat-omap/include/plat/sdrc.h | 23 +++ 8 files changed, 220 insertions(+), 75 deletions(-) create mode 100644 arch/arm/mach-omap2/sdram-micron-mt46h16m32lf-6.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
[PATCH 1/5] OMAP: Add in helper macros for the SDRAM timings
Signed-off-by: Laine Walker-Avina lwalk...@ieee.org
---
arch/arm/plat-omap/include/plat/sdrc.h | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/sdrc.h
b/arch/arm/plat-omap/include/plat/sdrc.h
index 7b76f50..c74d1e7 100644
--- a/arch/arm/plat-omap/include/plat/sdrc.h
+++ b/arch/arm/plat-omap/include/plat/sdrc.h
@@ -124,6 +124,29 @@ struct omap_sdrc_params {
u32 mr;
};
+/* Helper macros and defines for the omap_sdrc_params registers */
+#define ACTIM_TRFC(a) (((a) 0x1f)27)
+#define ACTIM_TRC(a) (((a) 0x1f)22)
+#define ACTIM_TRAS(a) (((a) 0xf)18)
+#define ACTIM_TRP(a) (((a) 0x3)15)
+#define ACTIM_TRCD(a) (((a) 0x3)12)
+#define ACTIM_TRRD(a) (((a) 0x3)9)
+#define ACTIM_TDPL(a) (((a) 0x3)6)
+#define ACTIM_TDAL(a) (((a) 0x1f)0)
+
+#define ACTIM_TWTR(a) (((a) 0x3)16)
+#define ACTIM_TCKE(a) (((a) 0x7)12)
+#define ACTIM_TXP(a) (((a) 0x7)8)
+#define ACTIM_TXSR(a) (((a) 0xff)0)
+
+#define RFR_CTRL_ARCV(a) (((a) 0x)8)
+#define RFR_CTRL_ARE(a)(((a) 0x3)0)
+
+#define MR_WBST(a) (((a) 0x1)9)
+#define MR_CASL(a) (((a) 0x7)4)
+#define MR_BL(a) (((a) 0x7)0)
+
+
void __init omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
int omap2_sdrc_get_params(unsigned long r,
--
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
[PATCH 2/5] OMAP: Convert the sdram-*.h timings to use the SDRAM timing macros
Signed-off-by: Laine Walker-Avina lwalk...@ieee.org
---
arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 44 +++--
arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h | 44 +++--
arch/arm/mach-omap2/sdram-numonyx-m65kam.h | 52
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 50 ---
4 files changed, 119 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
b/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
index 8bfaf34..2e6a606 100644
--- a/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
+++ b/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
@@ -17,31 +17,43 @@
static struct omap_sdrc_params h8mbx00u0mer0em_sdrc_params[] = {
[0] = {
.rate= 2,
- .actim_ctrla = 0xa2e1b4c6,
- .actim_ctrlb = 0x0002131c,
- .rfr_ctrl= 0x0005e601,
- .mr = 0x0032,
+ .actim_ctrla = ACTIM_TRFC(20) | ACTIM_TRC(11) | ACTIM_TRAS(8) |
+ ACTIM_TRP(3) | ACTIM_TRCD(3) | ACTIM_TRRD(2) |
ACTIM_TDPL(3) |
+ ACTIM_TDAL(6),
+ .actim_ctrlb = ACTIM_TWTR(2) | ACTIM_TCKE(1) | ACTIM_TXP(3) |
+ ACTIM_TXSR(28),
+ .rfr_ctrl= RFR_CTRL_ARCV(1510) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(3) | MR_BL(2),
},
[1] = {
.rate= 16600,
- .actim_ctrla = 0x629db4c6,
- .actim_ctrlb = 0x00012214,
- .rfr_ctrl= 0x0004dc01,
- .mr = 0x0032,
+ .actim_ctrla = ACTIM_TRFC(12) | ACTIM_TRC(10) | ACTIM_TRAS(7) |
+ ACTIM_TRP(3) | ACTIM_TRCD(3) | ACTIM_TRRD(2) |
ACTIM_TDPL(3) |
+ ACTIM_TDAL(6),
+ .actim_ctrlb = ACTIM_TWTR(1) | ACTIM_TCKE(2) | ACTIM_TXP(2) |
+ ACTIM_TXSR(20),
+ .rfr_ctrl= RFR_CTRL_ARCV(1244) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(3) | MR_BL(2),
},
[2] = {
.rate= 1,
- .actim_ctrla = 0x51912284,
- .actim_ctrlb = 0x0002120e,
- .rfr_ctrl= 0x0002d101,
- .mr = 0x0022,
+ .actim_ctrla = ACTIM_TRFC(10) | ACTIM_TRC(6) | ACTIM_TRAS(4) |
+ ACTIM_TRP(2) | ACTIM_TRCD(2) | ACTIM_TRRD(1) |
ACTIM_TDPL(2) |
+ ACTIM_TDAL(4),
+ .actim_ctrlb = ACTIM_TWTR(2) | ACTIM_TCKE(1) | ACTIM_TXP(2) |
+ ACTIM_TXSR(14),
+ .rfr_ctrl= RFR_CTRL_ARCV(721) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(2) | MR_BL(2),
},
[3] = {
.rate= 8300,
- .actim_ctrla = 0x31512283,
- .actim_ctrlb = 0x0001220a,
- .rfr_ctrl= 0x00025501,
- .mr = 0x0022,
+ .actim_ctrla = ACTIM_TRFC(6) | ACTIM_TRC(5) | ACTIM_TRAS(4) |
+ ACTIM_TRP(2) | ACTIM_TRCD(2) | ACTIM_TRRD(1) |
ACTIM_TDPL(2) |
+ ACTIM_TDAL(3),
+ .actim_ctrlb = ACTIM_TWTR(1) | ACTIM_TCKE(2) | ACTIM_TXP(2) |
+ ACTIM_TXSR(10),
+ .rfr_ctrl= RFR_CTRL_ARCV(597) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(2) | MR_BL(2),
},
[4] = {
.rate= 0
diff --git a/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
b/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
index a391b49..00accf2 100644
--- a/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
+++ b/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
@@ -21,31 +21,43 @@
static struct omap_sdrc_params mt46h32m32lf6_sdrc_params[] = {
[0] = {
.rate= 16600,
- .actim_ctrla = 0x9a9db4c6,
- .actim_ctrlb = 0x00011217,
- .rfr_ctrl= 0x0004dc01,
- .mr = 0x0032,
+ .actim_ctrla = ACTIM_TRFC(19) | ACTIM_TRC(10) | ACTIM_TRAS(7) |
+ ACTIM_TRP(3) | ACTIM_TRCD(3) | ACTIM_TRRD(2) |
ACTIM_TDPL(3) |
+ ACTIM_TDAL(6),
+ .actim_ctrlb = ACTIM_TWTR(1) | ACTIM_TCKE(1) | ACTIM_TXP(2) |
+ ACTIM_TXSR(23),
+ .rfr_ctrl= RFR_CTRL_ARCV(1244) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(3) | MR_BL(2),
},
[1] = {
.rate= 165941176,
- .actim_ctrla = 0x9a9db4c6,
- .actim_ctrlb = 0x00011217,
- .rfr_ctrl= 0x0004dc01,
- .mr = 0x0032,
+ .actim_ctrla = ACTIM_TRFC(19) | ACTIM_TRC(10) | ACTIM_TRAS(7) |
+
[PATCH 3/5] OMAP: Add SDRAM timings for Micron mt46h16m32lf-6
Signed-off-by: Laine Walker-Avina lwalk...@ieee.org
---
arch/arm/mach-omap2/sdram-micron-mt46h16m32lf-6.h | 67 +
1 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/sdram-micron-mt46h16m32lf-6.h
diff --git a/arch/arm/mach-omap2/sdram-micron-mt46h16m32lf-6.h
b/arch/arm/mach-omap2/sdram-micron-mt46h16m32lf-6.h
new file mode 100644
index 000..5e7c3e8
--- /dev/null
+++ b/arch/arm/mach-omap2/sdram-micron-mt46h16m32lf-6.h
@@ -0,0 +1,67 @@
+/*
+ * SDRC register values for the Micron MT46H16M32LF-6
+ *
+ * Copyright (C) 2010 PASCO scientifc
+ *
+ * Laine Walker-Avina
+ *
+ * Based on the file for the Micron MT46H32M32LF-6 by Paul Walmsley
+ *
+ * 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.
+ */
+
+#ifndef ARCH_ARM_MACH_OMAP2_SDRAM_MICRON_MT46H16M32LF
+#define ARCH_ARM_MACH_OMAP2_SDRAM_MICRON_MT46H16M32LF
+
+#include plat/sdrc.h
+
+/* Micron MT46H16M32LF-6 */
+static struct omap_sdrc_params mt46h16m32lf6_sdrc_params[] = {
+ [0] = {
+ .rate= 16600,
+ .actim_ctrla = ACTIM_TRFC(17) | ACTIM_TRC(10) | ACTIM_TRAS(7) |
+ ACTIM_TRP(3) | ACTIM_TRCD(3) | ACTIM_TRRD(2) |
ACTIM_TDPL(3) |
+ ACTIM_TDAL(6),
+ .actim_ctrlb = ACTIM_TWTR(2) | ACTIM_TCKE(1) | ACTIM_TXP(1) |
+ ACTIM_TXSR(20),
+ .rfr_ctrl= RFR_CTRL_ARCV(1244) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(3) | MR_BL(2),
+ },
+ [1] = {
+ .rate= 165941176,
+ .actim_ctrla = ACTIM_TRFC(17) | ACTIM_TRC(10) | ACTIM_TRAS(7) |
+ ACTIM_TRP(3) | ACTIM_TRCD(3) | ACTIM_TRRD(2) |
ACTIM_TDPL(3) |
+ ACTIM_TDAL(6),
+ .actim_ctrlb = ACTIM_TWTR(2) | ACTIM_TCKE(1) | ACTIM_TXP(1) |
+ ACTIM_TXSR(20),
+ .rfr_ctrl= RFR_CTRL_ARCV(1244) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(3) | MR_BL(2),
+ },
+ [2] = {
+ .rate= 8300,
+ .actim_ctrla = ACTIM_TRFC(9) | ACTIM_TRC(5) | ACTIM_TRAS(4) |
+ ACTIM_TRP(2) | ACTIM_TRCD(2) | ACTIM_TRRD(1) |
ACTIM_TDPL(2) |
+ ACTIM_TDAL(3),
+ .actim_ctrlb = ACTIM_TWTR(1) | ACTIM_TCKE(1) | ACTIM_TXP(1) |
+ ACTIM_TXSR(10),
+ .rfr_ctrl= RFR_CTRL_ARCV(597) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(3) | MR_BL(2),
+ },
+ [3] = {
+ .rate= 82970588,
+ .actim_ctrla = ACTIM_TRFC(10) | ACTIM_TRC(5) | ACTIM_TRAS(4) |
+ ACTIM_TRP(2) | ACTIM_TRCD(2) | ACTIM_TRRD(1) |
ACTIM_TDPL(2) |
+ ACTIM_TDAL(3),
+ .actim_ctrlb = ACTIM_TWTR(1) | ACTIM_TCKE(1) | ACTIM_TXP(2) |
+ ACTIM_TXSR(12),
+ .rfr_ctrl= RFR_CTRL_ARCV(597) | RFR_CTRL_ARE(1),
+ .mr = MR_WBST(0) | MR_CASL(3) | MR_BL(2),
+ },
+ [4] = {
+ .rate= 0
+ },
+};
+
+#endif
--
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
[PATCH 4/5] OMAP: Add support for setting the divider for sys_clkout2 using clk_set_rate
Signed-off-by: Laine Walker-Avina lwalk...@ieee.org
---
arch/arm/mach-omap2/clock3xxx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d5153b6..2a62779 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -,6 +,7 @@ static struct clk sys_clkout2 = {
.clksel_mask= OMAP3430_CLKOUT2_DIV_MASK,
.clksel = sys_clkout2_clksel,
.recalc = omap2_clksel_recalc,
+ .set_rate = omap2_clksel_set_rate,
};
/* CM OUTPUT CLOCKS */
--
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
[PATCH 5/5] OMAP: Make set_gpmc_timing_reg aware of the TIMEPARAGRANULARITY flag
Signed-off-by: Laine Walker-Avina lwalk...@ieee.org
---
arch/arm/mach-omap2/gpmc.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..9fa80e3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -171,12 +171,15 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
#endif
{
u32 l;
- int ticks, mask, nr_bits;
+ int ticks, mask, nr_bits, para_gran;
+
+ para_gran = (gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1)
+ GPMC_CONFIG1_TIME_PARA_GRAN ? 2 : 1);
if (time == 0)
ticks = 0;
else
- ticks = gpmc_ns_to_ticks(time);
+ ticks = gpmc_ns_to_ticks(time/para_gran);
nr_bits = end_bit - st_bit + 1;
if (ticks = 1 nr_bits) {
#ifdef DEBUG
@@ -191,8 +194,8 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit,
int end_bit,
#ifdef DEBUG
printk(KERN_INFO
GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n,
- cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000,
- (l st_bit) mask, time);
+ cs, name, ticks, gpmc_get_fclk_period() * para_gran *
+ ticks / 1000, (l st_bit) mask, time);
#endif
l = ~(mask st_bit);
l |= ticks st_bit;
@@ -231,6 +234,9 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
{
int div;
u32 l;
+#ifdef DEBUG
+ printk(KERN_INFO GPMC_FCLK: %ld\n, gpmc_get_fclk_period());
+#endif
div = gpmc_cs_calc_divider(cs, t-sync_clk);
if (div 0)
--
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/5] OMAP: Add in helper macros for the SDRAM timings
On Tue, Apr 06, 2010 at 06:51:04PM +0200, ext Laine Walker-Avina wrote:
Signed-off-by: Laine Walker-Avina lwalk...@ieee.org
---
arch/arm/plat-omap/include/plat/sdrc.h | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/sdrc.h
b/arch/arm/plat-omap/include/plat/sdrc.h
index 7b76f50..c74d1e7 100644
--- a/arch/arm/plat-omap/include/plat/sdrc.h
+++ b/arch/arm/plat-omap/include/plat/sdrc.h
@@ -124,6 +124,29 @@ struct omap_sdrc_params {
u32 mr;
};
+/* Helper macros and defines for the omap_sdrc_params registers */
+#define ACTIM_TRFC(a) (((a) 0x1f)27)
you need to add more spacing in all these macros, something like:
#define ACTIM_TRFC(a) (((a) 0x1f) 27)
similar to all others.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] OMAP: Add in helper macros for the SDRAM timings
On Tue, Apr 6, 2010 at 10:17 AM, Felipe Balbi felipe.ba...@nokia.com wrote: +/* Helper macros and defines for the omap_sdrc_params registers */ +#define ACTIM_TRFC(a) Â Â Â Â Â (((a) 0x1f)27) you need to add more spacing in all these macros, something like: #define ACTIM_TRFC(a) Â Â Â Â Â (((a) 0x1f) 27) similar to all others. -- balbi I'll do it, however checkpatch.pl didn't flag that as a warning. -- Laine Walker-Avina Firmware Engineer PASCO scientific -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] OMAP: Add in helper macros for the SDRAM timings
On Tue, Apr 06, 2010 at 07:26:48PM +0200, ext Laine Walker-Avina wrote: I'll do it, however checkpatch.pl didn't flag that as a warning. I guess you need to call it with --strict :-) -- balbi -- 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 v2 1/5] OMAP: Add in helper macros for the SDRAM timings
Signed-off-by: Laine Walker-Avina lwalk...@ieee.org
---
arch/arm/plat-omap/include/plat/sdrc.h | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/sdrc.h
b/arch/arm/plat-omap/include/plat/sdrc.h
index 7b76f50..c74d1e7 100644
--- a/arch/arm/plat-omap/include/plat/sdrc.h
+++ b/arch/arm/plat-omap/include/plat/sdrc.h
@@ -124,6 +124,29 @@ struct omap_sdrc_params {
u32 mr;
};
+/* Helper macros and defines for the omap_sdrc_params registers */
+#define ACTIM_TRFC(a) (((a) 0x1f) 27)
+#define ACTIM_TRC(a) (((a) 0x1f) 22)
+#define ACTIM_TRAS(a) (((a) 0xf) 18)
+#define ACTIM_TRP(a) (((a) 0x3) 15)
+#define ACTIM_TRCD(a) (((a) 0x3) 12)
+#define ACTIM_TRRD(a) (((a) 0x3) 9)
+#define ACTIM_TDPL(a) (((a) 0x3) 6)
+#define ACTIM_TDAL(a) (((a) 0x1f) 0)
+
+#define ACTIM_TWTR(a) (((a) 0x3) 16)
+#define ACTIM_TCKE(a) (((a) 0x7) 12)
+#define ACTIM_TXP(a) (((a) 0x7) 8)
+#define ACTIM_TXSR(a) (((a) 0xff) 0)
+
+#define RFR_CTRL_ARCV(a) (((a) 0x) 8)
+#define RFR_CTRL_ARE(a)(((a) 0x3) 0)
+
+#define MR_WBST(a) (((a) 0x1) 9)
+#define MR_CASL(a) (((a) 0x7) 4)
+#define MR_BL(a) (((a) 0x7) 0)
+
+
void __init omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
int omap2_sdrc_get_params(unsigned long r,
--
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
[PATCH 0/3] DSPBRIDGE: Cleanup hw directory and module parameter
From 4fb9fc015cea65dcd47172a8b180f380fe86be46 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo x0095...@ti.com Date: Tue, 30 Mar 2010 22:03:27 -0600 Subject: [PATCH] DSPBRIDGE: Cleanup hw directory and module parameter This patches does a clenaup of unused module paremeters and also a clenaup in hw directory. Fernando Guzman Lugo (3): DSPBRIDGE: remove unused module parameters DSPBRIDGE: remove HW_DSPSS_BootModeSet function DSPBRIDGE: remove hw_prcm module and related functions arch/arm/mach-omap2/dspbridge.c|9 +- arch/arm/plat-omap/include/dspbridge/cfgdefs.h |2 - arch/arm/plat-omap/include/dspbridge/host_os.h |8 + drivers/dsp/bridge/Makefile|2 +- drivers/dsp/bridge/hw/IPIAccInt.h | 26 - drivers/dsp/bridge/hw/IVA2RegAcM.h | 26 - drivers/dsp/bridge/hw/PRCMAccInt.h | 303 drivers/dsp/bridge/hw/PRCMRegAcM.h | 615 drivers/dsp/bridge/hw/hw_dspssC64P.c | 47 -- drivers/dsp/bridge/hw/hw_dspssC64P.h | 37 -- drivers/dsp/bridge/hw/hw_prcm.c| 161 -- drivers/dsp/bridge/hw/hw_prcm.h| 156 -- drivers/dsp/bridge/rmgr/drv.c | 14 - drivers/dsp/bridge/rmgr/drv_interface.c| 24 +- drivers/dsp/bridge/wmd/_tiomap.h |4 + drivers/dsp/bridge/wmd/tiomap3430.c| 176 +++- drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 57 +-- drivers/dsp/bridge/wmd/tiomap_io.c | 15 +- 18 files changed, 116 insertions(+), 1566 deletions(-) delete mode 100644 drivers/dsp/bridge/hw/IPIAccInt.h delete mode 100644 drivers/dsp/bridge/hw/IVA2RegAcM.h delete mode 100644 drivers/dsp/bridge/hw/PRCMAccInt.h delete mode 100644 drivers/dsp/bridge/hw/PRCMRegAcM.h delete mode 100644 drivers/dsp/bridge/hw/hw_dspssC64P.c delete mode 100644 drivers/dsp/bridge/hw/hw_dspssC64P.h delete mode 100644 drivers/dsp/bridge/hw/hw_prcm.c delete mode 100644 drivers/dsp/bridge/hw/hw_prcm.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
[PATCH 1/3] DSPBRIDGE: remove unused module parameters
From 0923c8f7c0cca3a2d308d673092adcc4de74088b Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Sat, 27 Mar 2010 02:01:20 -0600
Subject: [PATCH] DSPBRIDGE: remove unused module parameters
This patch removes unused module parameters:
-phys_mempool_base
-phys_mempool_base
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/rmgr/drv_interface.c | 24 +++-
1 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 5f01ab9..3d22f8c 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -88,8 +88,6 @@ static s32 driver_major;
static char *base_img;
char *iva_img;
static s32 shm_size = 0x50;/* 5 MB */
-static u32 phys_mempool_base;
-static u32 phys_mempool_size;
static int tc_wordswapon; /* Default value is always false */
#ifdef CONFIG_BRIDGE_RECOVERY
#define REC_TIMEOUT 5000 /*recovery timeout in msecs */
@@ -133,13 +131,6 @@ MODULE_PARM_DESC(base_img, DSP base image, default =
NULL);
module_param(shm_size, int, 0);
MODULE_PARM_DESC(shm_size, shm size, default = 4 MB, minimum = 64 KB);
-module_param(phys_mempool_base, uint, 0);
-MODULE_PARM_DESC(phys_mempool_base,
-Physical memory pool base passed to driver);
-
-module_param(phys_mempool_size, uint, 0);
-MODULE_PARM_DESC(phys_mempool_size,
-Physical memory pool size passed to driver);
module_param(tc_wordswapon, int, 0);
MODULE_PARM_DESC(tc_wordswapon, TC Word Swap Option. default = 0);
@@ -316,18 +307,9 @@ static int __devinit omap34_xx_bridge_probe(struct
platform_device *pdev)
}
dev_dbg(bridge, %s: requested shm_size = 0x%x\n, __func__, shm_size);
- if (pdata-phys_mempool_base pdata-phys_mempool_size) {
- phys_mempool_base = pdata-phys_mempool_base;
- phys_mempool_size = pdata-phys_mempool_size;
- }
-
- dev_dbg(bridge, %s: phys_mempool_base = 0x%x \n, __func__,
- phys_mempool_base);
-
- dev_dbg(bridge, %s: phys_mempool_size = 0x%x\n, __func__,
- phys_mempool_base);
- if ((phys_mempool_base 0x0) (phys_mempool_size 0x0))
- mem_ext_phys_pool_init(phys_mempool_base, phys_mempool_size);
+ if ((pdata-phys_mempool_base 0) (pdata-phys_mempool_size 0))
+ mem_ext_phys_pool_init(pdata-phys_mempool_base,
+ pdata-phys_mempool_size);
if (tc_wordswapon) {
dev_dbg(bridge, %s: TC Word Swap is enabled\n, __func__);
reg_set_value(TCWORDSWAP, (u8 *) tc_wordswapon,
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] DSPBRIDGE: remove HW_DSPSS_BootModeSet function
From 4cc1e01fbd78fcf8084b75566a750a3c88fc5dc6 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo x0095...@ti.com Date: Sat, 27 Mar 2010 21:22:29 -0600 Subject: [PATCH] DSPBRIDGE: remove HW_DSPSS_BootModeSet function This patch removes HW_DSPSS_BootModeSet function and uses kernel functions instead, also remove all the files related. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- drivers/dsp/bridge/Makefile |2 +- drivers/dsp/bridge/hw/IPIAccInt.h | 26 - drivers/dsp/bridge/hw/IVA2RegAcM.h | 26 - drivers/dsp/bridge/hw/hw_dspssC64P.c| 47 --- drivers/dsp/bridge/hw/hw_dspssC64P.h| 37 drivers/dsp/bridge/wmd/tiomap3430.c | 27 +++-- drivers/dsp/bridge/wmd/tiomap3430_pwr.c |1 - 7 files changed, 12 insertions(+), 154 deletions(-) delete mode 100644 drivers/dsp/bridge/hw/IPIAccInt.h delete mode 100644 drivers/dsp/bridge/hw/IVA2RegAcM.h delete mode 100644 drivers/dsp/bridge/hw/hw_dspssC64P.c delete mode 100644 drivers/dsp/bridge/hw/hw_dspssC64P.h diff --git a/drivers/dsp/bridge/Makefile b/drivers/dsp/bridge/Makefile index ce85ba6..1350362 100644 --- a/drivers/dsp/bridge/Makefile +++ b/drivers/dsp/bridge/Makefile @@ -15,7 +15,7 @@ librmgr = rmgr/dbdcd.o rmgr/disp.o rmgr/drv.o rmgr/mgr.o rmgr/node.o \ rmgr/nldr.o rmgr/drv_interface.o libdload = dynload/cload.o dynload/getsection.o dynload/reloc.o \ dynload/tramp.o -libhw = hw/hw_prcm.o hw/hw_dspssC64P.o hw/hw_mmu.o +libhw = hw/hw_prcm.o hw/hw_mmu.o bridgedriver-objs = $(libgen) $(libservices) $(libwmd) $(libpmgr) $(librmgr) \ $(libdload) $(libhw) diff --git a/drivers/dsp/bridge/hw/IPIAccInt.h b/drivers/dsp/bridge/hw/IPIAccInt.h deleted file mode 100644 index 644fd0d..000 --- a/drivers/dsp/bridge/hw/IPIAccInt.h +++ /dev/null @@ -1,26 +0,0 @@ -/* - * IPIAccInt.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * Copyright (C) 2005-2006 Texas Instruments, Inc. - * - * This package 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. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -#ifndef _IPI_ACC_INT_H -#define _IPI_ACC_INT_H - -/* Bitfield mask and offset declarations */ -#define SYSC_IVA2BOOTMOD_OFFSET 0x404 -#define SYSC_IVA2BOOTADDR_OFFSET0x400 -#define SYSC_IVA2BOOTADDR_MASK 0xfc00 - -#endif /* _IPI_ACC_INT_H */ -/* EOF */ diff --git a/drivers/dsp/bridge/hw/IVA2RegAcM.h b/drivers/dsp/bridge/hw/IVA2RegAcM.h deleted file mode 100644 index 181374f..000 --- a/drivers/dsp/bridge/hw/IVA2RegAcM.h +++ /dev/null @@ -1,26 +0,0 @@ -/* - * IVA1RegAcM.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * Copyright (C) 2005-2006 Texas Instruments, Inc. - * - * This package 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. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -#ifndef _IVA2_REG_ACM_H -#define _IVA2_REG_ACM_H - -#include GlobalTypes.h -#include EasiGlobal.h - -#define SYSC_IVA2BOOTMOD_OFFSET0x404 -#define SYSC_IVA2BOOTADDR_OFFSET 0x400 - -#endif diff --git a/drivers/dsp/bridge/hw/hw_dspssC64P.c b/drivers/dsp/bridge/hw/hw_dspssC64P.c deleted file mode 100644 index 89e9316..000 --- a/drivers/dsp/bridge/hw/hw_dspssC64P.c +++ /dev/null @@ -1,47 +0,0 @@ -/* - * hw_dspss64P.c - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * API definitions to configure DSP Subsystem modules like IPI - * - * Copyright (C) 2005-2006 Texas Instruments, Inc. - * - * This package 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. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -/* PROJECT SPECIFIC INCLUDE FILES */ -#include GlobalTypes.h -#include linux/io.h -#include hw_defs.h -#include hw_dspssC64P.h -#include IVA2RegAcM.h -#include IPIAccInt.h - -/* HW FUNCTIONS */ -hw_status hw_dspss_boot_mode_set(const void __iomem *baseAddress, -enum hw_dspsysc_boot_mode_t bootMode, -
RE: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
Vaibhav,
[Hiremath, Vaibhav] Thanks Murali, I really appreciate your comments here.
Please find response below -
You had responded only to some comments. Can I assume that you are taking care
of the other comments as well? I have also asked Hans to provide
his comments since this is a new driver that he might have to approve. Did he
review the code in the past?
-Murali
+
+#include asm/processor.h
Add a line here??
+#include plat/dma.h
+#include plat/vram.h
+#include plat/vrfb.h
+#include plat/display.h
+
+#include omap_voutlib.h
+#include omap_voutdef.h
+
+MODULE_AUTHOR(Texas Instruments);
+MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
+MODULE_LICENSE(GPL);
+
+
+/* Driver Configuration macros */
+#define VOUT_NAME omap_vout
+
+enum omap_vout_channels {
+ OMAP_VIDEO1 = 0,
Why do we have to initialize this to 0. It always start with a value 0
by default.
+ OMAP_VIDEO2,
+};
+
+enum dma_channel_state {
+ DMA_CHAN_NOT_ALLOTED = 0,
Ditto.
+ DMA_CHAN_ALLOTED,
+};
+
+#define QQVGA_WIDTH160
+#define QQVGA_HEIGHT 120
+
+/* Max Resolution supported by the driver */
+#define VID_MAX_WIDTH 1280/* Largest width */
+#define VID_MAX_HEIGHT 720 /* Largest height */
+
-
+
+module_param(debug, bool, S_IRUGO);
+MODULE_PARM_DESC(debug, Debug level (0-1));
+
+/* Local Helper functions */
+static void omap_vout_isr(void *arg, unsigned int irqstatus);
+static void omap_vout_cleanup_device(struct omap_vout_device *vout);
+
Is there a reason why you need these prototypes? I think we could
remove these prototypes and move the function ahead in the file before
it is called.
[Hiremath, Vaibhav] Do you see any harm with this? I think its only
implementation part. But still I will incorporate in next version.
+/* list of image formats supported by OMAP2 video pipelines */
+const static struct v4l2_fmtdesc omap_formats[] = {
+ {
+ /* Note: V4L2 defines RGB565 as:
+*
+* Byte 0Byte 1
+* g2 g1 g0 r4 r3 r2 r1 r0 b4 b3 b2 b1 b0 g5 g4
g3
+*
+* We interpret RGB565 as:
+*
+* Byte 0Byte 1
+* g2 g1 g0 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4
g3
+*/
+ .description = RGB565, le,
+ .pixelformat = V4L2_PIX_FMT_RGB565,
+ },
+ {
+ /* Note: V4L2 defines RGB32 as: RGB-8-8-8-8 we use
+* this for RGB24 unpack mode, the last 8 bits are
ignored
+* */
+ .description = RGB32, le,
+ .pixelformat = V4L2_PIX_FMT_RGB32,
+ },
+ {
+ /* Note: V4L2 defines RGB24 as: RGB-8-8-8 we use
+*this for RGB24 packed mode
+*
+*/
+ .description = RGB24, le,
+ .pixelformat = V4L2_PIX_FMT_RGB24,
+ },
+ {
+ .description = YUYV (YUV 4:2:2), packed,
+ .pixelformat = V4L2_PIX_FMT_YUYV,
+ },
+ {
+ .description = UYVY, packed,
+ .pixelformat = V4L2_PIX_FMT_UYVY,
+ },
+};
+
+#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
+
+/*
+ * Allocate buffers
+ */
--
+
+/*
+ * omap_vout_uservirt_to_phys: This inline function is used to convert
user
+ * space virtual address to physical address.
+ */
+static u32 omap_vout_uservirt_to_phys(u32 virtp)
+{
+ unsigned long physp = 0;
+ struct vm_area_struct *vma;
+ struct mm_struct *mm = current-mm;
+
+ vma = find_vma(mm, virtp);
+ /* For kernel direct-mapped memory, take the easy way */
+ if (virtp = PAGE_OFFSET) {
+ physp = virt_to_phys((void *) virtp);
+ } else if (vma (vma-vm_flags VM_IO)
+vma-vm_pgoff) {
+ /* this will catch, kernel-allocated,
+ mmaped-to-usermode addresses */
+ physp = (vma-vm_pgoff PAGE_SHIFT) + (virtp - vma-
vm_start);
+ } else {
+ /* otherwise, use get_user_pages() for general userland
pages */
+ int res, nr_pages = 1;
+ struct page *pages;
+ down_read(current-mm-mmap_sem);
+
+ res = get_user_pages(current, current-mm, virtp,
nr_pages,
+ 1, 0, pages, NULL);
+ up_read(current-mm-mmap_sem);
+
+ if (res == nr_pages) {
+ physp = __pa(page_address(pages[0]) +
+
Re: [PM-WIP-OPP][PATCH] OMAP3 PM: Fix issue with opp_find_freq_floor
Nishanth Menon n...@ti.com writes: Sripathy, Vishwanath had written, on 04/06/2010 12:56 PM, the following: opp_find_freq_floor should return the lower enabled* OPP from a starting freq from a start opp list. But current code returns next lower opp. This patch fixes this issue. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c index bb8120e..13da451 --- a/arch/arm/plat-omap/opp.c +++ b/arch/arm/plat-omap/opp.c @@ -208,7 +208,7 @@ struct omap_opp *opp_find_freq_floor(enum opp_t opp_type, unsigned long *freq) *freq = prev_opp-rate; - return oppl; +return prev_opp; } Thanks. yep. since we return *freq with the right rate, we should point also to the right opp. Acked-by: Nishanth Menon n...@ti.com Thanks, pushed to pm-wip-opp 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: [PM-WIP-OPP][PATCH] OMAP3630 PM: Update for OPP 1GHz
Nishanth Menon n...@ti.com writes:
Sripathy, Vishwanath had written, on 04/06/2010 01:06 PM, the following:
It is found that system is not very stable with current 1GHz OPP
configuration (a...@1g, i...@880m, v...@1.31v) and it has been
recommended to use below configuration for stable 1GHz OPP. (a...@1g,
i...@800m, v...@1.35v).
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
index c453ec5..189c42e
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -82,7 +82,7 @@ static struct omap_opp_def __initdata
omap36xx_mpu_rate_table[] = {
/* OPP3 - OPP-Turbo */
OMAP_OPP_DEF(false, 8, 126),
/* OPP4 - OPP-SB */
-OMAP_OPP_DEF(false, 10, 131),
+OMAP_OPP_DEF(false, 10, 135),
/* Terminator */
OMAP_OPP_DEF(0, 0, 0)
};
@@ -104,7 +104,7 @@ static struct omap_opp_def __initdata
omap36xx_dsp_rate_table[] = {
/* OPP3 - OPP-Turbo */
OMAP_OPP_DEF(false, 66000, 126),
/* OPP4 - OPP-SB */
-OMAP_OPP_DEF(false, 87500, 131),
+OMAP_OPP_DEF(false, 8, 135),
/* Terminator */
OMAP_OPP_DEF(0, 0, 0)
};
Acked-by: Nishanth Menon n...@ti.com
Thanks, pushed to pm-wip-opp
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: [ASK] OMAP 3430 LDP Trouble
if NAND support is currently missing for OMAP3430 LDP,,how i boot my
ldp again like before?...any idea?
best regards,
Aldyth M
On 4/5/10, Vimal Singh vimal.neww...@gmail.com wrote:
AFAIK, NAND support is currently missing for OMAP3430 LDP boards in LO.
-Vimal
On Sun, Apr 4, 2010 at 9:34 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
Aldyth,
1. Do you mean that NAND boot is not working?
2. Does MMC/SD boot working? If yes, boot the platform from MMC/SD using
the latest x-loade/ u-boot and flush the same binaries to NAND using the
following commands.
mmcinit 0
nand unlock 8 8
nand erase 8 8
fatload mmc 0 8000 u-boot.bin
nand write.i 8000 8 ${filesize}
nand unlock 0 8
nand erase 0 8
fatload mmc 0 8000 MLO
nand write.i 8000 0 ${filesize}
Regards,
Ghorai
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tar Gz
Sent: 2010-04-04 11:13
To: linux-omap
Subject: [ASK] OMAP 3430 LDP Trouble
Hi all,
i'm sorry if my english too bad
I try to porting linux to omap 3430 LDP..but my board have trouble
after i running this command:
nand ecc sw
nand unlock 8 8
nand erase 8 8
nand ecc hw
nand unlock 0 8
nand erase 0 8
and if i try to turn on my board, BT led [blue led] always on and my
minicom can't show anything...and i forget to setting the enviroment
variable mmcinit..
my question is, how to make my board can run normally like before?
best regards,
Aldyth M
--
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
--
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
--
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: [ASK] OMAP 3430 LDP Trouble
Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ASK] OMAP 3430 LDP Trouble
Gadiyar, Anand wrote: Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing Or this one: http://omappedia.org/wiki/Zoom_Flashing#Serial_Boot_Procedure -- 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] [PATCH v4 2/5] omap3: pm: Using separate clk/volt setup_time for RET and OFF states
Lesly A M lesl...@ti.com writes:
This patch will use separate clk/volt setup_time for RET and OFF state,
also create separate copies of vc parameters for each Si in voltage.c.
Updates the clksetup time from board file, since clksetup time depends on
the OSC/XTAL used on the board. Re-programing the setup time according
to the target state of CORE power domain.
The voltsetup2 is used only when the device exits sys_off mode
(with PRM_VOLTCTRL[3]SEL_OFF set to 1).
Changed vdd0_/vdd1_ to vdd1_/vdd2_ in prcm vc setuptime structure.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/board-3430sdp.c | 28 +++
arch/arm/mach-omap2/board-3630sdp.c | 15
arch/arm/mach-omap2/board-zoom2.c | 15
arch/arm/mach-omap2/board-zoom3.c | 15
arch/arm/mach-omap2/pm.h| 17
arch/arm/mach-omap2/pm34xx.c| 14 +++-
arch/arm/mach-omap2/voltage.c | 150
++-
arch/arm/mach-omap2/voltage.h | 30 +++
8 files changed, 209 insertions(+), 75 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 6ee9f20..4439813 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -77,21 +77,16 @@ static struct cpuidle_params omap3_cpuidle_params_table[]
= {
{1, 1, 3, 30},
};
-/* FIXME: These are not the optimal setup values to be used on 3430sdp*/
-static struct prm_setup_vc omap3_setuptime_table = {
- .clksetup = 0xff,
- .voltsetup_time1 = 0xfff,
- .voltsetup_time2 = 0xfff,
- .voltoffset = 0xff,
- .voltsetup2 = 0xff,
- .vdd0_on = 0x30,
- .vdd0_onlp = 0x20,
- .vdd0_ret = 0x1e,
- .vdd0_off = 0x00,
- .vdd1_on = 0x2c,
- .vdd1_onlp = 0x20,
- .vdd1_ret = 0x1e,
- .vdd1_off = 0x00,
+/* CLKSETUP TIME which depends on the OSC/XTAL used on the board */
+static struct prm_setup_vc omap3_setuptime = {
+ /* CLK SETUPTIME for RET */
+ .ret = {
+ .clksetup = 0x1,
+ },
+ /* CLK SETUPTIME for OFF */
+ .off = {
+ .clksetup = 0x14A,
+ },
};
static int board_keymap[] = {
@@ -345,7 +340,6 @@ static void __init omap_3430sdp_init_irq(void)
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
- omap_voltage_init_vc(omap3_setuptime_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
omap_init_irq();
@@ -895,6 +889,8 @@ static struct omap_musb_board_data musb_board_data = {
static void __init omap_3430sdp_init(void)
{
+ omap_voltage_init_vc(omap3_setuptime);
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 3937a47..d04987d 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -25,6 +25,19 @@
#include mux.h
#include sdram-hynix-h8mbx00u0mer-0em.h
+#include voltage.h
+
+/* CLKSETUP TIME which depends on the OSC/XTAL used on the board */
+static struct prm_setup_vc omap3_setuptime = {
+ /* CLK SETUPTIME for RET */
+ .ret = {
+ .clksetup = 0x1,
+ },
+ /* CLK SETUPTIME for OFF */
+ .off = {
+ .clksetup = 0x14A,
+ },
+};
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
@@ -96,6 +109,8 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init omap_sdp_init(void)
{
+ omap_voltage_init_vc(omap3_setuptime);
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index a2cdfdd..37f43dd 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -26,6 +26,19 @@
#include mux.h
#include sdram-micron-mt46h32m32lf-6.h
#include omap3-opp.h
+#include voltage.h
+
+/* CLKSETUP TIME which depends on the OSC/XTAL used on the board */
+static struct prm_setup_vc omap3_setuptime = {
+ /* CLK SETUPTIME for RET */
+ .ret = {
+ .clksetup = 0x1,
+ },
+ /* CLK SETUPTIME for OFF */
+ .off = {
+ .clksetup = 0x14A,
+ },
+};
static void __init omap_zoom2_init_irq(void)
{
@@ -81,6 +94,8 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init omap_zoom2_init(void)
{
+ omap_voltage_init_vc(omap3_setuptime);
+
Re: [ASK] OMAP 3430 LDP Trouble
yes, i can't boot from nand because i erase it and i can't boot from my sd card.. okey i will try boot from serial..hope this help best regards, Aldyth M On 4/7/10, Gadiyar, Anand gadi...@ti.com wrote: Gadiyar, Anand wrote: Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing Or this one: http://omappedia.org/wiki/Zoom_Flashing#Serial_Boot_Procedure -- 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: [ASK] OMAP 3430 LDP Trouble
i don't know, i'm forget to setting up my environment variable mmcinit or my sd card can't booting / bootablebut if i'm boot from nadn and can enter prompt, my ldp board can read my sd card...can load kernel from my sd card best regards, Aldyth M On 4/7/10, Gary Thomas g...@mlbassoc.com wrote: On 04/06/2010 02:27 PM, Tar Gz wrote: yes, i can't boot from nand because i erase it and i can't boot from my sd card.. Why can't you boot from the SD card? okey i will try boot from serial..hope this help best regards, Aldyth M On 4/7/10, Gadiyar, Anandgadi...@ti.com wrote: Gadiyar, Anand wrote: Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing -- 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: [PATCH 0/5] OMAP: RX51: Add LCD Panel Support for N900
Hi, Roger Quadros roger.quad...@nokia.com writes: These patches get the N900 LCD panel working. Apply's cleanly on 2.6.34-rc2 Pre-requisites: https://patchwork.kernel.org/patch/86318/ https://patchwork.kernel.org/patch/86319/ https://patchwork.kernel.org/patch/86320/ First, thanks for pushing the missing bits for N900 hardware support upstream! I wanted to give your patches a try and test a l-o kernel on my N900 (I know I won't have full hardware support ... at the moment). Using current l-o tree with your 5 panel patches and the 3 you link on patchwork, I initially ended up with a kernel panic in omap3_onenand_write_bufferram() (i.e. unrelated to your patches). With http://patchwork.ozlabs.org/patch/48337/ (mtd: OneNAND: OMAP3: unmap correct DMA buffer), I am able to get the official Nokia /sbin/preinit called: then, getbootstate reports a malfunction but AFAICT, the panel is working ok. The getbootstate malfunction is expected as there is no support for it yet in mainline. But you should get to shell without that. You could hack the startup script to spawn a getty on ttyS2. This should get you to shell. so in /sbin/preinit, in start_shell() -/sbin/getty 115200 ttyS0 -n -l /bin/sh +/sbin/getty 115200 ttyS2 -n -l /bin/sh For the records, just in case someone wants to do the same, I had to use: /sbin/getty 115200 tty0 -n -l /bin/sh I also had to set CONFIG_KEYBOARD_TWL4030 to get the keyboard working. Any reason for that option not be enabled by default in rx51_defconfig? Additionally, after something like 25 seconds, the screen goes black and the device stops. Any clue? Can be panel realted? Cheers, a+ -- 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: [ASK] OMAP 3430 LDP Trouble
On 04/06/2010 02:40 PM, Tar Gz wrote: i don't know, i'm forget to setting up my environment variable mmcinit or my sd card can't booting / bootablebut if i'm boot from nadn and can enter prompt, my ldp board can read my sd card...can load kernel from my sd card You'll be much better off figuring out how to boot from the SD card. There are many how to documents on this for the OMAP - just follow the cookbook. Then you'll have the pieces you need to repair your NAND copy and move on. On 4/7/10, Gary Thomasg...@mlbassoc.com wrote: On 04/06/2010 02:27 PM, Tar Gz wrote: yes, i can't boot from nand because i erase it and i can't boot from my sd card.. Why can't you boot from the SD card? okey i will try boot from serial..hope this help best regards, Aldyth M On 4/7/10, Gadiyar, Anandgadi...@ti.com wrote: Gadiyar, Anand wrote: Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing -- 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 -- 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: [ASK] OMAP 3430 LDP Trouble
i try following the procedure..start from make partitions using fdisk...everything is ok but if i'm booting from my ldp it's doesn't work...i don't know what's problem about my sd card?...ldp can support my sd card or not?...i'm using v-gen, using transcend same too.. best regards, Aldyth M On 4/7/10, Gary Thomas g...@mlbassoc.com wrote: On 04/06/2010 02:40 PM, Tar Gz wrote: i don't know, i'm forget to setting up my environment variable mmcinit or my sd card can't booting / bootablebut if i'm boot from nadn and can enter prompt, my ldp board can read my sd card...can load kernel from my sd card You'll be much better off figuring out how to boot from the SD card. There are many how to documents on this for the OMAP - just follow the cookbook. Then you'll have the pieces you need to repair your NAND copy and move on. On 4/7/10, Gary Thomasg...@mlbassoc.com wrote: On 04/06/2010 02:27 PM, Tar Gz wrote: yes, i can't boot from nand because i erase it and i can't boot from my sd card.. Why can't you boot from the SD card? okey i will try boot from serial..hope this help best regards, Aldyth M On 4/7/10, Gadiyar, Anandgadi...@ti.com wrote: Gadiyar, Anand wrote: Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing -- 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 -- 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
[PATCH] OMAP: omap_device: add omap_device_has_lost_context()
Add new function omap_device_has_lost_context() as a simple check
to be used after omap_device_enable() to determine if device has
lost context (and thus needs context restore.)
Motivation: Currently, each driver needs to read the context-loss
count before suspend, and again upon resume to determine if
device context needs to be restored. Rather than duplicating
this process across all drivers, move it into omap_device. After
omap_device_enable(), omap_device_has_lost_context() can be called
to determine if context was lost.
The hard work is done inside the powerdomain layer where a simple flag
is checked. The flag is cleared in the pre-transition call back,
and conditionally set post-transition based on either an off-mode
transition or a memory or logic off transition.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomain.c | 11 +++-
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/include/plat/powerdomain.h |2 +-
arch/arm/plat-omap/omap_device.c | 29 +
4 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9a0fb38..ac54607 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -145,15 +145,19 @@ static void _update_logic_membank_counters(struct
powerdomain *pwrdm)
prev_logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
if ((pwrdm-pwrsts_logic_ret == PWRSTS_OFF_RET)
- (prev_logic_pwrst == PWRDM_POWER_OFF))
+ (prev_logic_pwrst == PWRDM_POWER_OFF)) {
pwrdm-ret_logic_off_counter++;
+ pwrdm-lost_context = true;
+ }
for (i = 0; i pwrdm-banks; i++) {
prev_mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
if ((pwrdm-pwrsts_mem_ret[i] == PWRSTS_OFF_RET)
- (prev_mem_pwrst == PWRDM_POWER_OFF))
+ (prev_mem_pwrst == PWRDM_POWER_OFF)) {
pwrdm-ret_mem_off_counter[i]++;
+ pwrdm-lost_context = true;
+ }
}
}
@@ -176,6 +180,8 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
prev = pwrdm_read_prev_pwrst(pwrdm);
if (pwrdm-state != prev)
pwrdm-state_counter[prev]++;
+ if (prev == PWRDM_POWER_OFF)
+ pwrdm-lost_context = true;
if (prev == PWRDM_POWER_RET)
_update_logic_membank_counters(pwrdm);
break;
@@ -197,6 +203,7 @@ static int _pwrdm_pre_transition_cb(struct powerdomain
*pwrdm, void *unused)
{
pwrdm_clear_all_prev_pwrst(pwrdm);
_pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
+ pwrdm-lost_context = false;
return 0;
}
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 3694b62..b6ef94c 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -79,6 +79,7 @@ struct omap_device {
int omap_device_enable(struct platform_device *pdev);
int omap_device_idle(struct platform_device *pdev);
int omap_device_shutdown(struct platform_device *pdev);
+bool omap_device_has_lost_context(struct platform_device *pdev);
/* Core code interface */
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index d82b2c0..bd5ab48 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -102,7 +102,7 @@ struct powerdomain {
unsigned state_counter[PWRDM_MAX_PWRSTS];
unsigned ret_logic_off_counter;
unsigned ret_mem_off_counter[PWRDM_MAX_MEM_BANKS];
-
+ bool lost_context;
#ifdef CONFIG_PM_DEBUG
s64 timer;
s64 state_timer[PWRDM_MAX_PWRSTS];
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 5904358..0340b40 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -84,6 +84,7 @@
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/powerdomain.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -579,6 +580,34 @@ int omap_device_shutdown(struct platform_device *pdev)
}
/**
+ * omap_device_has_lost_context() - check if omap_device has lost context
+ * @od: struct omap_device *
+ *
+ * When an omap_device has been deactivated via omap_device_idle() or
+ * omap_device_shutdown() and then (re)activated using omap_device_enable()
+ * This function should be used to determine if the omap_device has
+ * lost context (due to an off-mode transistion)
+ */
+bool omap_device_has_lost_context(struct platform_device *pdev)
+{
+ struct omap_device *od;
+
Re: [PATCH v4 0/5] omap3: pm: Update TRITON power scripts and making it generic
Lesly A M lesl...@ti.com writes: This series of patch implements a updated TRITON power scripts. Also moving the sleep, wakeup warm_reset sequence to a generic script file, which can be used by different OMAP3 board with the power companion chip TWL4030. This patch series is based off Kevin's tree origin/pm branch. Hmm, I don't think so. It appears to be based off of Thara's SR series. 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: [RFC/PATCH 2/3] arm: omap1: remove dead code from timer32k.c
Felipe Balbi felipe.ba...@nokia.com writes:
Trivial patch, no functional changes
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap1/timer32k.c | 15 ---
1 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 9ad1185..20cfbcc 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -68,12 +68,6 @@ struct sys_timer omap_timer;
*
---
*/
-#if defined(CONFIG_ARCH_OMAP16XX)
-#define TIMER_32K_SYNCHRONIZED 0xfffbc410
-#else
-#error OMAP 32KHz timer does not currently work on 15XX!
-#endif
-
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
#define OMAP1_32K_TIMER_CR 0x08
@@ -150,15 +144,6 @@ static struct clock_event_device clockevent_32k_timer = {
.set_mode = omap_32k_timer_set_mode,
};
-/*
- * The 32KHz synchronized timer is an additional timer on 16xx.
- * It is always running.
- */
-static inline unsigned long omap_32k_sync_timer_read(void)
-{
- return omap_readl(TIMER_32K_SYNCHRONIZED);
-}
-
static irqreturn_t omap_32k_timer_interrupt(int irq, void *dev_id)
{
struct clock_event_device *evt = clockevent_32k_timer;
--
1.7.0.rc0.33.g7c3932
--
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
--
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] arm: omap1/2/3/4: convert clocksource to a platform_driver
Felipe Balbi felipe.ba...@nokia.com writes:
Convert the omap32k clocksource driver into a platform_driver
and while at that, also remove the ifdeferry around the code.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
This looks mostly good to me. One cosmetic request.
There is some standardized naming happening for devices based on
Benoits work of auto-generating hwmod data. As part of this, this
device will now be called counter_32k instead of '32k sync timer'
since it's just a simple counter and nobody really knew what the 'sync'
was intended to mean. To that end, renaming things to use counter_32k
instead of sync timer would be helpful.
[...]
+static struct resource omap_32k_resources[] = {
+ {
+ .start = -EINVAL, /* gets changed later */
+ .end= -EINVAL, /* gets changed later */
It's more common to just not assign these and leave them as zero.
+ .flags = IORESOURCE_MEM,
+ },
+};
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 5/8] OMAP2PLUS:GPIO:Add OMAP2PLUS specific gpio support
Tony Lindgren t...@atomide.com writes:
* Charulatha V ch...@ti.com [100331 05:15]:
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,36 @@
+/*
+ * gpio.c - OMAP2PLUS architecture specific common gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@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 mach/gpio.h
Should be include linux/gpio.h
+void __init omap_gpio_early_init(void)
+{
+struct platform_device **pdev;
+int no_of_dev;
+
+if (cpu_is_omap24xx()) {
+omap2_gpio_init_data();
+no_of_dev = omap2_early_init_gpio(pdev);
+} else if (cpu_is_omap34xx()) {
+omap3_gpio_init_data();
+no_of_dev = omap3_early_init_gpio(pdev);
+} else if (cpu_is_omap44xx()) {
+omap4_gpio_init_data();
+no_of_dev = omap4_early_init_gpio(pdev);
+} else
+return;
+
+early_platform_add_devices(pdev, no_of_dev);
+early_platform_driver_register_all(earlygpio);
+early_platform_driver_probe(earlygpio, no_of_dev, 0);
+}
diff --git a/arch/arm/mach-omap2/include/mach/gpio.h
b/arch/arm/mach-omap2/include/mach/gpio.h
index d2d9d17..3a0fcb1 100644
--- a/arch/arm/mach-omap2/include/mach/gpio.h
+++ b/arch/arm/mach-omap2/include/mach/gpio.h
@@ -115,4 +115,5 @@ extern void omap4_gpio_init_data(void);
extern int omap2_early_init_gpio(struct platform_device ***pdev);
extern int omap3_early_init_gpio(struct platform_device ***pdev);
extern int omap4_early_init_gpio(struct platform_device ***pdev);
+extern void __init omap_gpio_early_init(void);
#endif
Uhh, is this some April fool's day joke? :)
To me it looks like you have no need for ***pdev, just swap the init
code around so the omap specific code calls omap_gpio_init with the
platform data.
Or better yet, just use hwmod + omap_device for early platform_devices
and drop this patch entirely.
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 7/8] OMAP2PLUS:GPIO:Move gpio_init from board files to init_common_hw
Charulatha V ch...@ti.com writes: This is preparation for early platform device implementation for GPIO in OMAP2PLUS. This patch moves initialization of gpio from board files to omap2_init_common_hw API in io.c Why? Not a helpful description. 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 0/8 RFC] OMAP: GPIO: Split OMAP1 and OMAP2PLUS
Charulatha V ch...@ti.com writes: This patch series is in preparation to adapt GPIO to HWMOD FW. It creates OMAP architecture specific gpio files to handle SoC specific gpio_init. The common plat-omap/gpio.c handles all common GPIO APIs. OMAP2PLUS GPIO module is implemented as early platform device and OMAP1 GPIO is still handled in old way via gpio_init from board files. Save/restore context, gpio_prepare_for_retention and gpio_resume_after_retention APIs are also handled in plat-omap layer. These APIs are currently not used in OMAP1, but still they might become common for different OMAP architectures in the future. Hence they are handled in plat-omap layer. If they need to be moved to mach-omap2 layer, additional patches may be sent during next version of this patch series. This patch series is generated on top of linux-omap-2.6 branch: master and tested on 3430SDP, 4430SDP zoom3. I have many problems with this series, but without going into the specifics of each patch, I have a big problem with the general approach being taken here. You say this is in preparation for adaptation to hwmod, but in fact, this series is duplicating a lot of the work you would get for free by starting with hwmod. You're generating a bunch of code that will be completely thrown away with a hwmod conversion. Instead, you should *start* by using hwmod + omap_device to generate the platform_devices for you. Doing this, you will drop patches 2, 3 and 4 entirely (they are mostly identical anyways, except for the search-and-replace) and also eliminate the need for patch 5. What is needed here is a way to introduce the platform_device conversion without introducing signifcant functional changes at the same time. Here's a proposal to do that, and which should also be considerably easier to review for sanity: - use hwmod + omap_device to generate (early) platform_devices - modify plat-omap/gpio.c to use base addr and IRQ from platform_device - modify plat-omap/gpio.c to get clocks based on 'struct device' For an example, you can see the pm-wip/hwmods branch in my tree for how this was done for UART and the pm-wip/mmc branch for how this was done for MMC. 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 5/5] OMAP: Make set_gpmc_timing_reg aware of the TIMEPARAGRANULARITY flag
Laine Walker-Avina lwalk...@ieee.org writes: Signed-off-by: Laine Walker-Avina lwalk...@ieee.org All of the patches in this series should have a more descriptive changelog. Typically that means answering why? to the subject, and for more complicated series, also answering how? [...] +#ifdef DEBUG + printk(KERN_INFO GPMC_FCLK: %ld\n, gpmc_get_fclk_period()); +#endif should just use pr_debug(...) 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: GPIO: Fix OMAP4 GPIO reg access issues
Charulatha V ch...@ti.com writes: Access to some of the OMAP4 GPIO registers are not properly handled. This patch fixes it. Tested on... ? Signed-off-by: Charulatha V ch...@ti.com --- arch/arm/plat-omap/gpio.c | 61 +++- 1 files changed, 55 insertions(+), 12 deletions(-) diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index 76a347b..3a9891c 100644 --- a/arch/arm/plat-omap/gpio.c +++ b/arch/arm/plat-omap/gpio.c @@ -137,7 +137,11 @@ #define OMAP4_GPIO_IRQSTATUSCLR1 0x0040 #define OMAP4_GPIO_IRQWAKEN0 0x0044 #define OMAP4_GPIO_IRQWAKEN1 0x0048 -#define OMAP4_GPIO_SYSSTATUS 0x0104 +#define OMAP4_GPIO_SYSSTATUS 0x0114 +#define OMAP4_GPIO_IRQENABLE10x011c +#define OMAP4_GPIO_WAKE_EN 0x0120 +#define OMAP4_GPIO_IRQSTATUS20x0128 +#define OMAP4_GPIO_IRQENABLE20x012c #define OMAP4_GPIO_CTRL 0x0130 #define OMAP4_GPIO_OE0x0134 #define OMAP4_GPIO_DATAIN0x0138 @@ -148,6 +152,10 @@ #define OMAP4_GPIO_FALLINGDETECT 0x014c #define OMAP4_GPIO_DEBOUNCENABLE 0x0150 #define OMAP4_GPIO_DEBOUNCINGTIME0x0154 +#define OMAP4_GPIO_CLEARIRQENABLE1 0x0160 +#define OMAP4_GPIO_SETIRQENABLE1 0x0164 +#define OMAP4_GPIO_CLEARWKUENA 0x0180 +#define OMAP4_GPIO_SETWKUENA 0x0184 #define OMAP4_GPIO_CLEARDATAOUT 0x0190 [...] @@ -1570,9 +1603,14 @@ static int gpio_is_input(struct gpio_bank *bank, int mask) reg += OMAP7XX_GPIO_DIR_CONTROL; break; case METHOD_GPIO_24XX: - case METHOD_GPIO_44XX: reg += OMAP24XX_GPIO_OE; break; + case METHOD_GPIO_44XX: + reg += OMAP4_GPIO_OE; + break; + default: + WARN_ON(1); + return -EINVAL; If you add a WARN, please add a helpful string. Otherwise, this looks OK to me. Acked-by: Kevin Hilman khil...@deeprootsystems.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 v3] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Tuesday, April 06, 2010 11:57 AM
To: ext Nishanth Menon
Cc: Balbi Felipe (Nokia-D/Helsinki); Chikkature Rajashekar, Madhusudhan;
m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh'; t...@atomide.com;
S, Venkatraman; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
Lavinen Jarkko (Nokia-D/Helsinki)
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's
peformance.
On Tue, Apr 06, 2010 at 06:55:03PM +0200, ext Nishanth Menon wrote:
some reasons why i love switch statements ;) since I dont expect other
than precisely 4 and 8 (do we expect 5,6,7 - i might be wrong).. but if
it is so, wont the following be better?
switch (mmc_slot(host).wires)
{
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* fall thru*/
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
default:
WARN(bad width);
}
I like that, but I remember Madhu (or someone else) saying he thinks
it's less readable this way. Go figure...
Well, I did not comment on the usage of switch here. Note we only need to
handle 8-bit and 4-bit.The board files need not setup 8-bit or 4-bit if the
configuration of that board is 1-bit. The driver will still work in 1-bit
mode which would mean there is nothing to do in default case and should not
err out.
Regards,
Madhu
--
balbi
--
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] OMAP: Fix for bus width which improves SD card's peformance.
Chikkature Rajashekar, Madhusudhan had written, on 04/06/2010 06:23 PM,
the following:
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Tuesday, April 06, 2010 11:57 AM
To: ext Nishanth Menon
Cc: Balbi Felipe (Nokia-D/Helsinki); Chikkature Rajashekar, Madhusudhan;
m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh'; t...@atomide.com;
S, Venkatraman; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
Lavinen Jarkko (Nokia-D/Helsinki)
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's
peformance.
On Tue, Apr 06, 2010 at 06:55:03PM +0200, ext Nishanth Menon wrote:
some reasons why i love switch statements ;) since I dont expect other
than precisely 4 and 8 (do we expect 5,6,7 - i might be wrong).. but if
it is so, wont the following be better?
switch (mmc_slot(host).wires)
{
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* fall thru*/
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
default:
WARN(bad width);
}
I like that, but I remember Madhu (or someone else) saying he thinks
it's less readable this way. Go figure...
Well, I did not comment on the usage of switch here. Note we only need to
handle 8-bit and 4-bit.The board files need not setup 8-bit or 4-bit if the
configuration of that board is 1-bit. The driver will still work in 1-bit
mode which would mean there is nothing to do in default case and should not
err out.
check the attachment out.. hope that takes care of it.. just as a
reference alone ofcourse..
--
Regards,
Nishanth Menon
From 09b55eb33749d308586c19485bf1e1723009fc9a Mon Sep 17 00:00:00 2001
From: kishore kadiyala kishorek.kadiy...@gmail.com
Date: Wed, 31 Mar 2010 07:03:01 +
Subject: [PATCH Vn] OMAP: Fix for bus width which improves SD card's peformance.
This patch improves low speeds for SD cards.
OMAP-MMC controller's can support maximum bus width of '8'.
when bus width is mentioned as 8 in controller data,the SD
stack will check whether bus width is 4 and if not it will
set bus width to 1 and there by degrading performance.
This patch fixes the issue and improves the performance of
SD cards.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Tested-by: Jarkko Nikula jhnik...@gmail.com
---
NM Note:
Completely untested/unreviewed.. just holding on to
what was in https://patchwork.kernel.org/patch/89898/
with my suggested mods
drivers/mmc/host/omap_hsmmc.c | 32 +---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 83f0aff..89e26bc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2091,10 +2091,36 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_WAIT_WHILE_BUSY;
- if (mmc_slot(host).wires = 8)
+ switch(mmc_slot(host).wires) {
+ case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
- else if (mmc_slot(host).wires = 4)
- mmc-caps |= MMC_CAP_4_BIT_DATA;
+ /* Fall through */
+ case 4:
+ mmc-caps |= MMC_CAP_8_BIT_DATA;
+ break;
+ case 1:
+ /*
+ * I will still survive with this config.. but warn
+ * if the board file was goofed up
+ */
+ dev_warn(mmc_dev(host-mmc), Using potentially
+unoptimal 1bit config\n);
+ break;
+ default:
+ /* Completely unexpected.. dont wanna croak and die */
+ dev_crit(mmc_dev(host-mmc), Unknown width %d
+used!\n,mmc_slot(host).wires);
+ mmc_host_disable(host-mmc);
+ if (host-got_dbclk) {
+ clk_disable(host-dbclk);
+ clk_put(host-dbclk);
+ }
+ clk_disable(host-iclk);
+ clk_put(host-iclk);
+ clk_put(host-fclk);
+ goto err1;
+
+ }
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
--
1.6.3.3
RE: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Tuesday, April 06, 2010 6:39 PM
To: Chikkature Rajashekar, Madhusudhan
Cc: felipe.ba...@nokia.com; m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal
Singh'; t...@atomide.com; S, Venkatraman; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; 'Lavinen Jarkko (Nokia-D/Helsinki)'
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's
peformance.
Chikkature Rajashekar, Madhusudhan had written, on 04/06/2010 06:23 PM,
the following:
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Tuesday, April 06, 2010 11:57 AM
To: ext Nishanth Menon
Cc: Balbi Felipe (Nokia-D/Helsinki); Chikkature Rajashekar,
Madhusudhan;
m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh';
t...@atomide.com;
S, Venkatraman; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org;
Lavinen Jarkko (Nokia-D/Helsinki)
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD
card's
peformance.
On Tue, Apr 06, 2010 at 06:55:03PM +0200, ext Nishanth Menon wrote:
some reasons why i love switch statements ;) since I dont expect other
than precisely 4 and 8 (do we expect 5,6,7 - i might be wrong).. but
if
it is so, wont the following be better?
switch (mmc_slot(host).wires)
{
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* fall thru*/
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
default:
WARN(bad width);
}
I like that, but I remember Madhu (or someone else) saying he thinks
it's less readable this way. Go figure...
Well, I did not comment on the usage of switch here. Note we only need
to
handle 8-bit and 4-bit.The board files need not setup 8-bit or 4-bit if
the
configuration of that board is 1-bit. The driver will still work in 1-
bit
mode which would mean there is nothing to do in default case and should
not
err out.
check the attachment out.. hope that takes care of it.. just as a
reference alone ofcourse..
Nope. The default case is wrong. The assumption followed by controller
drivers is that if the board file says 4-bit or 8-bit set the capabilities
otherwise don't do any thing. The host will continue to work in 1-bit mode
which is a must. Your patch violates that (can not design a board without
connecting one data line at least :))
Also you can not say 1-bit is non-optimal because the board file dictates
the configuration based on what it is capable of. Why through a warning?
It is subjective.
Regards,
Madhu
--
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] OMAP: Fix for bus width which improves SD card's peformance.
Chikkature Rajashekar, Madhusudhan had written, on 04/06/2010 07:16 PM,
the following:
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Tuesday, April 06, 2010 6:39 PM
To: Chikkature Rajashekar, Madhusudhan
Cc: felipe.ba...@nokia.com; m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal
Singh'; t...@atomide.com; S, Venkatraman; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; 'Lavinen Jarkko (Nokia-D/Helsinki)'
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's
peformance.
Chikkature Rajashekar, Madhusudhan had written, on 04/06/2010 06:23 PM,
the following:
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Tuesday, April 06, 2010 11:57 AM
To: ext Nishanth Menon
Cc: Balbi Felipe (Nokia-D/Helsinki); Chikkature Rajashekar,
Madhusudhan;
m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh';
t...@atomide.com;
S, Venkatraman; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org;
Lavinen Jarkko (Nokia-D/Helsinki)
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD
card's
peformance.
On Tue, Apr 06, 2010 at 06:55:03PM +0200, ext Nishanth Menon wrote:
some reasons why i love switch statements ;) since I dont expect other
than precisely 4 and 8 (do we expect 5,6,7 - i might be wrong).. but
if
it is so, wont the following be better?
switch (mmc_slot(host).wires)
{
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* fall thru*/
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
default:
WARN(bad width);
}
I like that, but I remember Madhu (or someone else) saying he thinks
it's less readable this way. Go figure...
Well, I did not comment on the usage of switch here. Note we only need
to
handle 8-bit and 4-bit.The board files need not setup 8-bit or 4-bit if
the
configuration of that board is 1-bit. The driver will still work in 1-
bit
mode which would mean there is nothing to do in default case and should
not
err out.
check the attachment out.. hope that takes care of it.. just as a
reference alone ofcourse..
Nope. The default case is wrong. The assumption followed by controller
drivers is that if the board file says 4-bit or 8-bit set the capabilities
otherwise don't do any thing. The host will continue to work in 1-bit mode
which is a must. Your patch violates that (can not design a board without
connecting one data line at least :))
Also you can not say 1-bit is non-optimal because the board file dictates
the configuration based on what it is capable of. Why through a warning?
It is subjective.
Point noted. try n++:
switch(mmc_slot(host).wires) {
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* Fall through */
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
case 0:
/* assuming nothing was given by board, use 1 */
case 1:
/* nothing to crib here */
break;
default:
/* Completely unexpected.. try 1 bit instead */
dev_crit(mmc_dev(host-mmc), Invalid width %d
used! using 1 instead\n,
mmc_slot(host).wires);
}
note: we should crib if the board file made a mistake here.. say it gave
10 wire or so.. I agree that we can recover by stepping back to 1 bit
mode.. but we gotta tell the log that something aint right..
--
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] OMAP: GPIO: Fix OMAP4 GPIO reg access issues
From: Kevin Hilman [khil...@deeprootsystems.com] Sent: Wednesday, April 07, 2010 4:21 AM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: GPIO: Fix OMAP4 GPIO reg access issues Charulatha V ch...@ti.com writes: Access to some of the OMAP4 GPIO registers are not properly handled. This patch fixes it. Tested on... ? Tested on 3430SDP and 4430SDP. Signed-off-by: Charulatha V ch...@ti.com --- [...] @@ -1570,9 +1603,14 @@ static int gpio_is_input(struct gpio_bank *bank, int mask) reg += OMAP7XX_GPIO_DIR_CONTROL; break; case METHOD_GPIO_24XX: - case METHOD_GPIO_44XX: reg += OMAP24XX_GPIO_OE; break; + case METHOD_GPIO_44XX: + reg += OMAP4_GPIO_OE; + break; + default: + WARN_ON(1); + return -EINVAL; If you add a WARN, please add a helpful string. Added this WARN in the same way as in other functions of the same file. Otherwise, this looks OK to me. Acked-by: Kevin Hilman khil...@deeprootsystems.com Thanks.-- 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
linux-omap-pm troubles on Gumstix Overo
Hey there, My name's Peter and I'm working with the linux-omap-pm kernel on the Gumstix Overo board for an academic project. Back when the linux-omap-pm branch was still on 2.6.33-rc8, I could compile and run the kernel on the Overo without any problems. Suspend to memory (via mem /sys/power/state) worked just fine. Unfortunately, ever since 2.6.34-rcX releases started coming out, I have been running into problems: First of all, I was under the impression that omap3_pm_defconfig was supposed to more-or-less work out of the box. This has not been the case, as when I try to compile: make ARCH=arm omap3_pm_defconfig make ARCH=arm -j4 uImage CROSS_COMPILE=/opt/arm-2009q3/bin/arm-none-linux-gnueabi- I get these error messages back. arch/arm/mach-omap2/omap44xx-smc.S: Assembler messages: arch/arm/mach-omap2/omap44xx-smc.S:30: Error: missing expression -- `smc' make[1]: *** [arch/arm/mach-omap2/omap44xx-smc.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Fortunately, this is solved by using menuconfig and un-checking the OMAP4 in System Type (this shouldn't affect anything, as the Overo is using the OMAP3...) Unfortunately, after building that, when I try to boot the Overo, this is as far as it gets: ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.34-rc3-09551-gb301cc7 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1994520 Bytes = 1.9 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. I have no idea if it simply hangs here, or it is working and simply not printing anything to the serial console. (If it helps at all, the processor *seems* warm, but I cannot be sure of this). To see if the problem can be solved by going back to 2.6.33, I do a git checkout of the corresponding branch: git checkout -b stable v2.6.33 I compile with the attached .config file, and the overo boots up just fine (though at some point in the process modprobe complains to me about omaplfb not found...) However, now when I try to suspend, I get this: r...@overo:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.01 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 109.004 msecs PM: late suspend of devices complete after 0.274 msecs Class driver suspend failed for cpu0 PM: early resume of devices complete after 0.030 msecs PM: resume of devices complete after 343.597 msecs Restarting tasks ... done. The Class driver suspend failed for cpu0 is what concerns me, and I've tried a lot of stuff and have remained unable to get suspend working again. To summarize, my questions are: 1. Why do the 2.6.34-rcX kernels stop at Uncompressing Linux... done, booting the kernel.? 2. Why does the 2.6.33 kernel fail to suspend with Class driver suspend failed for cpu0? Did I incorrectly perform the git checkout, or did I misconfigure something? 3. And finally, for my future work, since I am interested in power management, is there a possible solution to suspending to disk? (Perhaps termed hibernate) I would greatly appreciate any pointers in the right direction so I can get this working again. Thanks a lot for your time and attention. Peter Tseng # # Automatically generated make config: don't edit # Linux kernel version: 2.6.33 # Thu Mar 18 00:59:57 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_OPROFILE_ARMV7=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set # CONFIG_TINY_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y
[PATCH 2/2] Setup LCD reset for Devkit8000
This patch corrects the LCD reset pin config
Original code from early devkit8000 patch sets the TWL4030 GPIO_1
to EHCI_nOC and TWL4030_GPIO_MAX+1 to ledA. Indeed these two pins
are both LCD_PWREN. Setup the lcd reset_gpio properly so it can be
disabled when other display is turned on.
Signed-off-by: Kan-Ru Chen ka...@0xlab.org
---
arch/arm/mach-omap2/board-devkit8000.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 2e7a539..b744433 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -135,11 +135,15 @@ static int devkit8000_panel_enable_lcd(struct
omap_dss_device *dssdev)
twl_i2c_write_u8(TWL4030_MODULE_GPIO, 0x80, REG_GPIODATADIR1);
twl_i2c_write_u8(TWL4030_MODULE_LED, 0x0, 0x0);
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 0);
}
static int devkit8000_panel_enable_dvi(struct omap_dss_device *dssdev)
@@ -177,9 +181,10 @@ static struct regulator_consumer_supply
devkit8000_vsim_supply = {
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
- .driver_name= innolux_at_panel,
+ .driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
+ .reset_gpio = -EINVAL, /* will be replaced */
.platform_enable= devkit8000_panel_enable_lcd,
.platform_disable = devkit8000_panel_disable_lcd,
};
@@ -275,20 +280,15 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
devkit8000_vmmc1_supply.dev = mmc[0].dev;
devkit8000_vsim_supply.dev = mmc[0].dev;
- /* REVISIT: need ehci-omap hooks for external VBUS
-* power switch and overcurrent detect
-*/
-
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
-
- /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */
- gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR);
- gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
-
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+/* gpio + 1 is LCD_PWREN (out, active low) */
+ devkit8000_lcd_device.reset_gpio = gpio + 1;
+ gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN);
+ /* Disable until needed */
+ gpio_direction_output(devkit8000_lcd_device.reset_gpio, 1);
+
/* gpio + 7 is DVI_PUD (out, active low) */
devkit8000_dvi_device.reset_gpio = gpio + 7;
gpio_request(devkit8000_dvi_device.reset_gpio, DVI_PUD);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Enable DVI-D output for Devkit8000
This patch corrects the DVI-D output setup of Devkit8000
Devkit8000 has different DVI reset pin with the BeagleBoard. On Devkit8000
the TWL4030 GPIO_7 is assigned to do the job.
Signed-off-by: Kan-Ru Chen ka...@0xlab.org
---
arch/arm/mach-omap2/board-devkit8000.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 5bfc13b..2e7a539 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -141,13 +141,18 @@ static int devkit8000_panel_enable_lcd(struct
omap_dss_device *dssdev)
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
}
+
static int devkit8000_panel_enable_dvi(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_dvi(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 0);
}
static int devkit8000_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -183,6 +188,7 @@ static struct omap_dss_device devkit8000_dvi_device = {
.driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
+ .reset_gpio = -EINVAL, /* will be replaced */
.platform_enable= devkit8000_panel_enable_dvi,
.platform_disable = devkit8000_panel_disable_dvi,
};
@@ -283,6 +289,12 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ /* gpio + 7 is DVI_PUD (out, active low) */
+ devkit8000_dvi_device.reset_gpio = gpio + 7;
+ gpio_request(devkit8000_dvi_device.reset_gpio, DVI_PUD);
+ /* Disable until needed */
+ gpio_direction_output(devkit8000_dvi_device.reset_gpio, 1);
+
return 0;
}
@@ -303,7 +315,7 @@ static struct regulator_consumer_supply
devkit8000_vpll2_supplies[] = {
.dev= devkit8000_lcd_device.dev,
},
{
- .supply = vdss_dsi,
+ .supply = vdds_dsi,
.dev= devkit8000_dss_device.dev,
}
};
@@ -665,12 +677,6 @@ static void __init devkit8000_init(void)
devkit8000_ads7846_init();
- omap_mux_init_gpio(170, OMAP_PIN_INPUT);
-
- gpio_request(170, DVI_nPD);
- /* REVISIT leave DVI powered down until it's needed ... */
- gpio_direction_output(170, true);
-
usb_musb_init(musb_board_data);
usb_ehci_init(ehci_pdata);
devkit8000_flash_init();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ASK] OMAP 3430 LDP Trouble
On Wed, Apr 7, 2010 at 1:19 AM, Gadiyar, Anand gadi...@ti.com wrote: Gadiyar, Anand wrote: Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? You can still have x-loader and u-boot on NAND (flash them from u-boot prompt, once you get booted up by any other method. for example serial boot as mentioned by Anand) and use NFS filesystem to work with. NAND driver support is missing in kernel, so, you will not be able to see/mount NAND partitions from kernel. -- Regards, Vimal Singh snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing Or this one: http://omappedia.org/wiki/Zoom_Flashing#Serial_Boot_Procedure -- 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: [PATCHv2 0/3] OMAP: DSS2: Allow us to use SDI
Hi, On Tue, 2010-04-06 at 18:03 +0200, Quadros Roger (Nokia-D/Helsinki) wrote: hi Tomi, Valkeinen Tomi (Nokia-D/Helsinki) wrote: Hi, On Wed, 2010-03-17 at 13:35 +0100, Quadros Roger (Nokia-D/Helsinki) wrote: SDI now makes use of vdds_sdi regulator supply. DPI can now be disabled on systems that don't have it changes since v1: - Incorporated review comments - no more omap3xx checks for regulator enable/disable in SDI - Added Kconfig option to enable/disable DPI Roger Quadros (3): OMAP: DSS2: Add Kconfig option for DPI display type OMAP: DSS2: Remove redundant enable/disable calls from SDI OMAP: DSS2: Use vdds_sdi regulator supply in SDI I think this patch set looks ok. Thanks! Tomi Ps. I took the liberty of removing an extra #include plat/cpu.h What is the status of this patch set? Is it supposed to go into your tree or Tony's tree? I applied the patches to my tree yesterday. Sorry it took so long. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP: RX51: Add LCD Panel Support for N900
On Tue, 2010-04-06 at 22:41 +0200, ext Arnaud Ebalard wrote: For the records, just in case someone wants to do the same, I had to use: /sbin/getty 115200 tty0 -n -l /bin/sh I also had to set CONFIG_KEYBOARD_TWL4030 to get the keyboard working. Any reason for that option not be enabled by default in rx51_defconfig? Additionally, after something like 25 seconds, the screen goes black and the device stops. Any clue? Can be panel realted? I'm guessing here, but it could be the HW watchdog kicking in if by device stops you mean that serial etc also stops. Although it should reboot, not stop... Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
