Re: [PATCH 4/4] omap: musb: introduce default baord config
On 04/27/11 07:23, Oleg Drokin wrote:
Hello!
On Apr 24, 2011, at 6:09 PM, Mike Rapoport wrote:
-void __init usb_musb_init(struct omap_musb_board_data *board_data)
+static struct omap_musb_board_data musb_default_board_data = {
+.interface_type = MUSB_INTERFACE_ULPI,
+.mode = MUSB_OTG,
In fact can you make it more generic with ifdefs like this?
(since there are tons of boards taht are client only or would like to be
compiled in some other way):
I didn't want to change current functionality. The purpose of this patch is to
reduce amount of code shared among board files.
If certain board needs mode other than OTG it can still pass musb_board_data.
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
+.power = 100,
+};
+
Thanks!
Bye,
Oleg
--
Sincerely yours,
Mike.
--
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: Fix bad SP address after relocating kernel
* Nicolas Pitre nicolas.pi...@linaro.org [110426 14:28]: On Tue, 26 Apr 2011, Tony Lindgren wrote: Otherwise cache_clean_flush can overwrite some of the relocated area depending on where the kernel image gets loaded. This fixes booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db (ARM: 6750/1: improvements to compressed/head.S). Gh. Indeed. Thanks to Aaro Koskinen aaro.koski...@nokia.com for debugging the address of the relocated area that gets corrupted, and to Nicolas Pitre nicolas.pi...@linaro.org for the other uncompress related fixes. Signed-off-by: Tony Lindgren t...@atomide.com I think there could be a better fix yet. Could you test this patch: Cool that works too and avoids using the stack, so that's a better fix: Tested-by: Tony Lindgren t...@atomide.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] omap:usb: fixing ehci phy gpio values for omap3
Hi, On Wed, Apr 27, 2011 at 11:22:03AM +0530, Munegowda, Keshava wrote: Dumb q2: is'nt it better to introduce polarity e.g. pdata-ehci_data-reset_gpio_polarity etc? this will allow board files to describe polarity of pin information to driver which can then be Phy and any board specific mods(e.g. inverter on the line) independent completely.. yes, I am thinking of doing it; since it requires modification of all board files; I will send this an another separate patch. Sure, for next merge window. -- 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:usb: fixing ehci phy gpio values for omap3
On Wed, Apr 27, 2011 at 1:28 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Apr 27, 2011 at 11:22:03AM +0530, Munegowda, Keshava wrote: Dumb q2: is'nt it better to introduce polarity e.g. pdata-ehci_data-reset_gpio_polarity etc? this will allow board files to describe polarity of pin information to driver which can then be Phy and any board specific mods(e.g. inverter on the line) independent completely.. yes, I am thinking of doing it; since it requires modification of all board files; I will send this an another separate patch. Sure, for next merge window. -- balbi yes balbi, I will do this patch after the rebaseing and validating the runtime pm patches to latest mainline kernel keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add basic devices support for Nook Color
On 04/27/11 04:52, gr...@linuxhacker.ru wrote:
From: Oleg Drokin gr...@linuxhacker.ru
MMC/SD interface, i2c, usb.
You should have added these at the first patch instead of Android devices.
---
arch/arm/configs/encore-nookcolor-defconfig | 2015
+++
The defconfig should be a separate patch. You should rather add encore board
options to omap2plus_defconfig.
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3encore.c | 325 +-
drivers/mfd/twl-core.c |6 +
The TWL updates should be in a separate patch
4 files changed, 2343 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/configs/encore-nookcolor-defconfig
[ snip ]
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 207f372..b894777 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -189,7 +189,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
hsmmc.o
-obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
+obj-$(CONFIG_MACH_ENCORE)+= board-omap3encore.o \
+hsmmc.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
diff --git a/arch/arm/mach-omap2/board-omap3encore.c
b/arch/arm/mach-omap2/board-omap3encore.c
index 9a00d6b..055549b 100644
--- a/arch/arm/mach-omap2/board-omap3encore.c
+++ b/arch/arm/mach-omap2/board-omap3encore.c
@@ -24,6 +24,7 @@
#include linux/clk.h
#include linux/spi/spi.h
+#include linux/i2c/twl.h
#include linux/interrupt.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
@@ -33,6 +34,7 @@
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include linux/mmc/host.h
#include plat/mcspi.h
#include mach/gpio.h
@@ -48,21 +50,80 @@
#include plat/sram.h
#include plat/display.h
+#include plat/mmc.h
#include plat/omap-serial.h
#include plat/system.h
#include mux.h
+#include hsmmc.h
#include prcm-common.h
#include sdram-hynix-h8mbx00u0mer-0em.h
#include media/v4l2-int-device.h
+#ifndef CONFIG_TWL4030_CORE
+#error no power companion board defined!
+#endif
+
Board should boot even when CONFIG_TWL4030_CORE is not defined, so drop it.
#ifdef CONFIG_ANDROID_RAM_CONSOLE
#include linux/bootmem.h
#endif
+static int encore_twl4030_keymap[] = {
+ KEY(0, 0, KEY_HOME),
+ KEY(0, 1, KEY_VOLUMEUP),
+ KEY(0, 2, KEY_VOLUMEDOWN),
+ 0
+};
+
+static struct matrix_keymap_data encore_twl4030_keymap_data = {
+ .keymap = encore_twl4030_keymap,
+ .keymap_size= ARRAY_SIZE(encore_twl4030_keymap),
+};
+
+static struct twl4030_keypad_data encore_kp_twl4030_data = {
+ .rows = 8,
+ .cols = 8,
+ .keymap_data= encore_twl4030_keymap_data,
+ .rep= 1,
+};
+
+// HOME key code for HW EVT2A
no C++ comments
+static struct gpio_keys_button encore_gpio_buttons[] = {
+ {
+ .code = KEY_POWER,
+ .gpio = 14,
+ .desc = POWER,
+ .active_low = 0,
+ .wakeup = 1,
+ },
+ {
+ .code = KEY_HOME,
+ .gpio = 48,
+ .desc = HOME,
+ .active_low = 1,
+ .wakeup = 1,
+ },
+};
+
+static struct gpio_keys_platform_data encore_gpio_key_info = {
+ .buttons= encore_gpio_buttons,
+ .nbuttons = ARRAY_SIZE(encore_gpio_buttons),
+// .rep= 1,/* auto-repeat */
ditto
+};
+
+static struct platform_device encore_keys_gpio = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = encore_gpio_key_info,
+ },
+};
+
+#define t2_out(c, r, v) twl_i2c_write_u8(c, r, v)
why is t2_out needed here?
+
/* Use address that is most likely unused and untouched by u-boot */
#define ENCORE_RAM_CONSOLE_START 0x8e00
#define ENCORE_RAM_CONSOLE_SIZE (0x2)
@@ -84,20 +145,262 @@ static struct platform_device encore_ram_console_device
= {
static struct platform_device *encore_devices[] __initdata = {
encore_ram_console_device,
+ encore_keys_gpio,
};
static void __init omap_encore_init_early(void)
{
-printk(in early ini\n);
omap2_init_common_infrastructure();
omap2_init_common_devices(h8mbx00u0mer0em_sdrc_params,
Re: [PATCH 1/2] Initial BN Nook Color (Encore) support
On 04/27/11 04:52, gr...@linuxhacker.ru wrote:
From: Oleg Drokin gr...@linuxhacker.ru
Just bare-bones board file that has only serial console working.
---
arch/arm/mach-omap2/Kconfig|5 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3encore.c| 152
arch/arm/plat-omap/include/plat/board-encore.h | 76
arch/arm/plat-omap/include/plat/uncompress.h |1 +
arch/arm/tools/mach-types |2 +-
6 files changed, 236 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3encore.c
create mode 100644 arch/arm/plat-omap/include/plat/board-encore.h
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..5370561 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO
for full description please see the products webpage at
http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit
+config MACH_ENCORE
+bool Barnes Noble Encore (Nook Color)
+depends on ARCH_OMAP3
+select OMAP_PACKAGE_CBP
+
config MACH_OVERO
bool Gumstix Overo board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..207f372 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -189,6 +189,7 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
hsmmc.o
+obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
diff --git a/arch/arm/mach-omap2/board-omap3encore.c
b/arch/arm/mach-omap2/board-omap3encore.c
new file mode 100644
index 000..9a00d6b
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3encore.c
@@ -0,0 +1,152 @@
+/*
+ *
+ * Copyright (C) 2008 Texas Instruments Inc.
+ * Vikram Pandita vikram.pand...@ti.com
+ *
+ * Modified from mach-omap2/board-ldp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Apri 2011 Oleg Drokin gr...@linuxhacker.ru - Port to 2.6.39
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/input.h
+#include linux/gpio_keys.h
+#include linux/workqueue.h
+#include linux/err.h
+#include linux/clk.h
+
+#include linux/spi/spi.h
+#include linux/interrupt.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/dma-mapping.h
+#include plat/board-encore.h
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/mcspi.h
+#include mach/gpio.h
+#include plat/board.h
+#include plat/common.h
+#include plat/gpmc.h
+#include plat/usb.h
+#include plat/mux.h
+
+#include asm/system.h // For system_serial_high system_serial_low
No C++ comments, please.
+#include asm/io.h
+#include asm/delay.h
+#include plat/sram.h
+
+#include plat/display.h
+#include plat/omap-serial.h
+
+#include plat/system.h
+
+#include mux.h
+#include prcm-common.h
+
+#include sdram-hynix-h8mbx00u0mer-0em.h
+
+#include media/v4l2-int-device.h
Please check what header files are actually required and drop the rest...
+#ifdef CONFIG_ANDROID_RAM_CONSOLE
+#include linux/bootmem.h
+#endif
AFAIK, there's no CONFIG_ANDROID_ in the kernel
+/* Use address that is most likely unused and untouched by u-boot */
+#define ENCORE_RAM_CONSOLE_START 0x8e00
+#define ENCORE_RAM_CONSOLE_SIZE (0x2)
+
+static struct resource encore_ram_console_resource[] = {
+{
+.start = ENCORE_RAM_CONSOLE_START,
+.end= ENCORE_RAM_CONSOLE_START + ENCORE_RAM_CONSOLE_SIZE - 1,
+.flags = IORESOURCE_MEM,
+}
+};
+
+static struct platform_device encore_ram_console_device = {
+.name = ram_console,
+.id = 0,
+.num_resources = ARRAY_SIZE(encore_ram_console_resource),
+.resource = encore_ram_console_resource,
+};
and there's no ram_console driver as well.
I don't think it'd make sense to register ram_console device at all.
+static struct platform_device *encore_devices[] __initdata = {
+ encore_ram_console_device,
+};
+
+static void __init omap_encore_init_early(void)
+{
+printk(in early ini\n);
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(h8mbx00u0mer0em_sdrc_params,
+
[PATCH v2 4/4] omap: musb: introduce default board config
Most boards use exactly the same configuration for musb initialization.
Create a default that can be shared amount different boards.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
Fixed spelling in $SUBJ, thanks to Felipe Contreras
arch/arm/mach-omap2/board-2430sdp.c |7 +--
arch/arm/mach-omap2/board-3430sdp.c |8 +---
arch/arm/mach-omap2/board-cm-t35.c |8 +---
arch/arm/mach-omap2/board-devkit8000.c |8 +---
arch/arm/mach-omap2/board-igep0020.c |8 +---
arch/arm/mach-omap2/board-igep0030.c |8 +---
arch/arm/mach-omap2/board-ldp.c |8 +---
arch/arm/mach-omap2/board-omap3beagle.c |8 +---
arch/arm/mach-omap2/board-omap3pandora.c |8 +---
arch/arm/mach-omap2/board-omap3stalker.c |8 +---
arch/arm/mach-omap2/board-omap3touchbook.c |8 +---
arch/arm/mach-omap2/board-overo.c|8 +---
arch/arm/mach-omap2/board-rm680.c|8 +---
arch/arm/mach-omap2/board-zoom-peripherals.c |8 +---
arch/arm/mach-omap2/usb-musb.c | 14 +-
15 files changed, 27 insertions(+), 98 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 99b3f2d..a8810f8 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -208,11 +208,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
static struct omap_usb_config sdp2430_usb_config __initdata = {
.otg= 1,
#ifdef CONFIG_USB_GADGET_OMAP
@@ -246,7 +241,7 @@ static void __init omap_2430sdp_init(void)
omap2_usbfs_init(sdp2430_usb_config);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP);
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index b12400e..951e585 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -810,12 +810,6 @@ static struct flash_partitions sdp_flash_partitions[] = {
},
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static void __init omap_3430sdp_init(void)
{
int gpio_pendown;
@@ -832,7 +826,7 @@ static void __init omap_3430sdp_init(void)
gpio_pendown = SDP3430_TS_GPIO_IRQ_SDPV1;
omap_ads7846_init(1, gpio_pendown, 310, NULL);
board_serial_init();
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 1a9e6be..286da17 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -651,12 +651,6 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static struct omap_board_config_kernel cm_t35_config[] __initdata = {
};
@@ -673,7 +667,7 @@ static void __init cm_t35_init(void)
cm_t35_init_led();
cm_t35_init_display();
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index e7dc057..405542a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -509,12 +509,6 @@ static struct platform_device *devkit8000_devices[]
__initdata = {
omap_dm9000_dev,
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
@@ -698,7 +692,7 @@ static void __init devkit8000_init(void)
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
ARRAY_SIZE(devkit8000_nand_partitions));
diff --git a/arch/arm/mach-omap2/board-igep0020.c
[PATCH 2/4] MFD: TWL6030: fix irq definitions
The charger fault IRQs from the twl will in future patches be handled
by a seperate IRQ handler in the charger driver than the general charger
IRQ. Give them different IRQ numbers now to allow the charger driver to
be merged in the future.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/twl6030-irq.c |4 ++--
include/linux/i2c/twl.h |1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index dfbae34..eb3b5f8 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -76,8 +76,8 @@ static int twl6030_interrupt_mapping[24] = {
USBOTG_INTR_OFFSET, /* Bit 18 ID */
USB_PRES_INTR_OFFSET, /* Bit 19 VBUS*/
CHARGER_INTR_OFFSET,/* Bit 20 CHRG_CTRL */
- CHARGER_INTR_OFFSET,/* Bit 21 EXT_CHRG*/
- CHARGER_INTR_OFFSET,/* Bit 22 INT_CHRG*/
+ CHARGERFAULT_INTR_OFFSET, /* Bit 21 EXT_CHRG*/
+ CHARGERFAULT_INTR_OFFSET, /* Bit 22 INT_CHRG*/
RSV_INTR_OFFSET,/* Bit 23 Reserved*/
};
/*--*/
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index f85f0ed..4323d3a 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -91,6 +91,7 @@
#define BCI_INTR_OFFSET2
#define MADC_INTR_OFFSET 3
#define USB_INTR_OFFSET4
+#define CHARGERFAULT_INTR_OFFSET 5
#define BCI_PRES_INTR_OFFSET 9
#define USB_PRES_INTR_OFFSET 10
#define RTC_INTR_OFFSET11
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] USB: TWL6025 allow different regulator name
The twl6025 uses a different regulator for USB than the 6030 so select
the correct regulator name depending on the subclass of device.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/usb/otg/twl6030-usb.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6e920de..3d82419 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -190,6 +190,12 @@ static int twl6030_phy_suspend(struct otg_transceiver *x,
int suspend)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
+ char *regulator_name;
+
+ if (twl_features() TWL6025_SUBCLASS)
+ regulator_name = ldousb;
+ else
+ regulator_name = vusb;
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -200,7 +206,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, vusb);
+ twl-usb3v3 = regulator_get(twl-dev, regulator_name);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Add support for twl6025 PMIC
This patch series starts to add support for the twl6025 chip to the twl driver. This series contains patches for the MFD device and the regulator device to support the twl6025. Graeme -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] REGULATOR: TWL6025: add support to twl-regulator
Adding support for the twl6025. Major difference in the twl6025 is the
group functionality has been removed from the chip so this affects how
regulators are enabled and disabled.
The names of the regulators also changed.
The DCDCs of the 6025 are software controllable as well.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/regulator/twl-regulator.c | 447 ++---
1 files changed, 412 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 2a808c2..c08a0de 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -51,6 +51,8 @@ struct twlreg_info {
u16 min_mV;
u16 max_mV;
+ u8 flags;
+
/* used by regulator core */
struct regulator_desc desc;
};
@@ -70,6 +72,7 @@ struct twlreg_info {
#define VREG_TRANS 1
#define VREG_STATE 2
#define VREG_VOLTAGE 3
+#define VREG_VOLTAGE_DCDC 4
/* TWL6030 Misc register offsets */
#define VREG_BC_ALL1
#define VREG_BC_REF2
@@ -87,6 +90,17 @@ struct twlreg_info {
#define TWL6030_CFG_STATE_APP(v) (((v) TWL6030_CFG_STATE_APP_MASK) \
TWL6030_CFG_STATE_APP_SHIFT)
+/* Flags for DCDC Voltage reading */
+#define DCDC_OFFSET_EN BIT(0)
+#define DCDC_EXTENDED_EN BIT(1)
+
+/* twl6025 SMPS EPROM values */
+#define TWL6030_SMPS_OFFSET0xB0
+#define TWL6030_SMPS_MULT 0xB3
+#define SMPS_MULTOFFSET_SMPS4 BIT(0)
+#define SMPS_MULTOFFSET_VIOBIT(1)
+#define SMPS_MULTOFFSET_SMPS3 BIT(6)
+
static inline int
twlreg_read(struct twlreg_info *info, unsigned slave_subgp, unsigned offset)
{
@@ -144,11 +158,14 @@ static int twl6030reg_is_enabled(struct regulator_dev
*rdev)
struct twlreg_info *info = rdev_get_drvdata(rdev);
int grp, val;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(twl_features() TWL6025_SUBCLASS)) {
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- grp = P1_GRP_6030;
+ grp = P1_GRP_6030;
+ } else
+ grp = 1;
val = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_STATE);
val = TWL6030_CFG_STATE_APP(val);
@@ -159,19 +176,22 @@ static int twl6030reg_is_enabled(struct regulator_dev
*rdev)
static int twlreg_enable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int grp;
- int ret;
+ int grp = 0;
+ int ret = 0;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(twl_class_is_6030() (twl_features() TWL6025_SUBCLASS))) {
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- if (twl_class_is_4030())
- grp |= P1_GRP_4030;
- else
- grp |= P1_GRP_6030;
+ if (twl_class_is_4030())
+ grp |= P1_GRP_4030;
+ else
+ grp |= P1_GRP_6030;
- ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER,
+ VREG_GRP, grp);
+ }
if (!ret twl_class_is_6030())
ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
@@ -186,29 +206,34 @@ static int twlreg_enable(struct regulator_dev *rdev)
static int twlreg_disable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int grp;
- int ret;
-
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
-
- /* For 6030, set the off state for all grps enabled */
- if (twl_class_is_6030()) {
- ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
- (grp (P1_GRP_6030 | P2_GRP_6030 | P3_GRP_6030))
- TWL6030_CFG_STATE_GRP_SHIFT |
- TWL6030_CFG_STATE_OFF);
+ int grp = 0;
+ int ret = 0;
+
+ if (!(twl_class_is_6030() (twl_features() TWL6025_SUBCLASS))) {
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
+
+ /* For 6030, set the off state for all grps enabled */
+ if
[PATCH 1/4] MFD: TWL6025: add phoenix lite support to twl6030
Phoenix Lite is based on the twl6030 family of PMICs. It has mostly the
same feature set of twl6030 but with small changes. The codec block has
also been removed. It also has a new charger block and new features in
its ADC block. VUSB handling also differs.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/twl-core.c | 103 ++-
include/linux/i2c/twl.h | 38 +-
2 files changed, 130 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 960b5be..6b9562a 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -198,6 +198,7 @@
#define TWL6030_BASEADD_GASGAUGE 0x00C0
#define TWL6030_BASEADD_PIH0x00D0
#define TWL6030_BASEADD_CHARGER0x00E0
+#define TWL6025_BASEADD_CHARGER0x00DA
/* subchip/slave 2 0x4A - DFT */
#define TWL6030_BASEADD_DIEID 0x00C0
@@ -236,6 +237,17 @@ unsigned int twl_rev(void)
}
EXPORT_SYMBOL(twl_rev);
+/* Export a function so child drivers of this mfd can tell which subclass
+ * of the chip is being used. eg regulator needs to know that it is a
+ * 6025 variant.
+ */
+static unsigned int twl_feat;
+unsigned int twl_features(void)
+{
+ return twl_feat;
+}
+EXPORT_SYMBOL(twl_features);
+
/* Structure for each TWL4030/TWL6030 Slave */
struct twl_client {
struct i2c_client *client;
@@ -328,6 +340,7 @@ static struct twl_mapping twl6030_map[] = {
{ SUB_CHIP_ID0, TWL6030_BASEADD_RTC },
{ SUB_CHIP_ID0, TWL6030_BASEADD_MEM },
+ { SUB_CHIP_ID1, TWL6025_BASEADD_CHARGER },
};
/*--*/
@@ -685,9 +698,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
}
if (twl_has_usb() pdata-usb twl_class_is_6030()) {
- static struct regulator_consumer_supply usb3v3 = {
- .supply = vusb,
- };
+ static struct regulator_consumer_supply usb3v3;
+ int regulator;
if (twl_has_regulator()) {
/* this is a template that gets copied */
@@ -700,8 +712,15 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
| REGULATOR_CHANGE_STATUS,
};
- child = add_regulator_linked(TWL6030_REG_VUSB,
- usb_fixed, usb3v3, 1);
+ if (features TWL6025_SUBCLASS) {
+ usb3v3.supply = ldousb;
+ regulator = TWL6025_REG_LDOUSB;
+ } else {
+ usb3v3.supply = vusb;
+ regulator = TWL6030_REG_VUSB;
+ }
+ child = add_regulator_linked(regulator, usb_fixed,
+ usb3v3, 1);
if (IS_ERR(child))
return PTR_ERR(child);
}
@@ -718,7 +737,15 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
/* we need to connect regulators to this transceiver */
if (twl_has_regulator() child)
usb3v3.dev = child;
+ } else if (twl_has_regulator() twl_class_is_6030()) {
+ if (features TWL6025_SUBCLASS)
+ child = add_regulator(TWL6025_REG_LDOUSB,
+ pdata-ldousb);
+ else
+ child = add_regulator(TWL6030_REG_VUSB, pdata-vusb);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
}
if (twl_has_watchdog() twl_class_is_4030()) {
@@ -828,7 +855,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
}
/* twl6030 regulators */
- if (twl_has_regulator() twl_class_is_6030()) {
+ if (twl_has_regulator() twl_class_is_6030()
+ !(features TWL6025_SUBCLASS)) {
child = add_regulator(TWL6030_REG_VMMC, pdata-vmmc);
if (IS_ERR(child))
return PTR_ERR(child);
@@ -841,10 +869,6 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6030_REG_VANA, pdata-vana);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
child = add_regulator(TWL6030_REG_VCXIO, pdata-vcxio);
if (IS_ERR(child))
return PTR_ERR(child);
@@ -870,6 +894,62 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
Re: [PATCH 1/4] MFD: TWL6025: add phoenix lite support to twl6030
On Wed, Apr 27, 2011 at 10:39:48AM +0100, Graeme Gregory wrote:
Phoenix Lite is based on the twl6030 family of PMICs. It has mostly the
same feature set of twl6030 but with small changes. The codec block has
also been removed. It also has a new charger block and new features in
its ADC block. VUSB handling also differs.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/twl-core.c | 103
++-
include/linux/i2c/twl.h | 38 +-
2 files changed, 130 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 960b5be..6b9562a 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -198,6 +198,7 @@
#define TWL6030_BASEADD_GASGAUGE 0x00C0
#define TWL6030_BASEADD_PIH 0x00D0
#define TWL6030_BASEADD_CHARGER 0x00E0
+#define TWL6025_BASEADD_CHARGER 0x00DA
/* subchip/slave 2 0x4A - DFT */
#define TWL6030_BASEADD_DIEID0x00C0
@@ -236,6 +237,17 @@ unsigned int twl_rev(void)
}
EXPORT_SYMBOL(twl_rev);
+/* Export a function so child drivers of this mfd can tell which subclass
+ * of the chip is being used. eg regulator needs to know that it is a
+ * 6025 variant.
+ */
+static unsigned int twl_feat;
+unsigned int twl_features(void)
+{
+ return twl_feat;
+}
+EXPORT_SYMBOL(twl_features);
Why do you need other parts of the stack to access features ? It would
be better to use features to initialize proper fields in the TWL
structure and use that for runtime checking.
@@ -328,6 +340,7 @@ static struct twl_mapping twl6030_map[] = {
{ SUB_CHIP_ID0, TWL6030_BASEADD_RTC },
{ SUB_CHIP_ID0, TWL6030_BASEADD_MEM },
+ { SUB_CHIP_ID1, TWL6025_BASEADD_CHARGER },
};
/*--*/
@@ -685,9 +698,8 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
}
if (twl_has_usb() pdata-usb twl_class_is_6030()) {
- static struct regulator_consumer_supply usb3v3 = {
- .supply = vusb,
- };
+ static struct regulator_consumer_supply usb3v3;
+ int regulator;
if (twl_has_regulator()) {
/* this is a template that gets copied */
@@ -700,8 +712,15 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
| REGULATOR_CHANGE_STATUS,
};
- child = add_regulator_linked(TWL6030_REG_VUSB,
- usb_fixed, usb3v3, 1);
+ if (features TWL6025_SUBCLASS) {
+ usb3v3.supply = ldousb;
+ regulator = TWL6025_REG_LDOUSB;
+ } else {
+ usb3v3.supply = vusb;
+ regulator = TWL6030_REG_VUSB;
+ }
that's just a name. Why don't you use the same name for both variants ?
@@ -718,7 +737,15 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
/* we need to connect regulators to this transceiver */
if (twl_has_regulator() child)
usb3v3.dev = child;
+ } else if (twl_has_regulator() twl_class_is_6030()) {
+ if (features TWL6025_SUBCLASS)
+ child = add_regulator(TWL6025_REG_LDOUSB,
+ pdata-ldousb);
+ else
+ child = add_regulator(TWL6030_REG_VUSB, pdata-vusb);
see, then you need to add more fields to the platform_data structure
just because of a string.
@@ -1093,6 +1173,8 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
}
+ twl_feat = id-driver_data;
NACK. Avoid globals as much as possible.
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 0c0d1ae..f85f0ed 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -698,7 +703,21 @@ struct twl4030_platform_data {
struct regulator_init_data *vana;
struct regulator_init_data *vcxio;
struct regulator_init_data *vusb;
- struct regulator_init_data *clk32kg;
+ struct regulator_init_data *clk32kg;
here you converted TABs into spaces. Fix it.
+ /* TWL6025 LDO regulators */
+ struct regulator_init_data *ldo1;
+ struct regulator_init_data *ldo2;
+ struct regulator_init_data *ldo3;
+ struct regulator_init_data *ldo4;
+ struct regulator_init_data *ldo5;
+ struct regulator_init_data
Re: [PATCH 3/4] REGULATOR: TWL6025: add support to twl-regulator
Hi,
On Wed, Apr 27, 2011 at 10:39:50AM +0100, Graeme Gregory wrote:
Adding support for the twl6025. Major difference in the twl6025 is the
group functionality has been removed from the chip so this affects how
regulators are enabled and disabled.
The names of the regulators also changed.
The DCDCs of the 6025 are software controllable as well.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/regulator/twl-regulator.c | 447
++---
1 files changed, 412 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 2a808c2..c08a0de 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -144,11 +158,14 @@ static int twl6030reg_is_enabled(struct regulator_dev
*rdev)
struct twlreg_info *info = rdev_get_drvdata(rdev);
int grp, val;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(twl_features() TWL6025_SUBCLASS)) {
instead, why don't you pass some flag as platform_data to this driver,
which gets used to initialize a fiel in struct twlreg_info, then you use
that to do the checking.
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- grp = P1_GRP_6030;
+ grp = P1_GRP_6030;
+ } else
+ grp = 1;
if one branch has {} add it to both.
--
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 4/4] USB: TWL6025 allow different regulator name
Hi, On Wed, Apr 27, 2011 at 10:39:51AM +0100, Graeme Gregory wrote: The twl6025 uses a different regulator for USB than the 6030 so select the correct regulator name depending on the subclass of device. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk I don't see the point of this patch. It's just a string. Use the same name and add a comment saying that on datasheet/TRM/documentation the name LDO is actually referred to as LDOUSB. It's the same functionality anyway. -- 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 3/4] REGULATOR: TWL6025: add support to twl-regulator
On Wed, Apr 27, 2011 at 10:39:50AM +0100, Graeme Gregory wrote:
+ switch (info-flags) {
+ case 0:
+ if (index == 0)
+ voltage = 0;
+ else if (index 58)
+ voltage = (60 + (12500 * (index - 1)));
+ else if (index == 58)
+ voltage = 1350 * 1000;
+ else if (index == 59)
+ voltage = 1500 * 1000;
+ else if (index == 60)
+ voltage = 1800 * 1000;
+ else if (index == 61)
+ voltage = 1900 * 1000;
+ else if (index == 62)
+ voltage = 2100 * 1000;
This reads like a switch statement with a default: case to me.
+static int twl6030dcdc_get_voltage(struct regulator_dev *rdev)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+ int vsel = twlreg_read(info, TWL_MODULE_PM_RECEIVER,
+ VREG_VOLTAGE_DCDC);
+ int voltage = 0;
+
+ if (vsel 0)
+ return vsel;
+ switch (info-flags) {
This should just call list_voltage() to do the mapping into a voltage or
better yet should be converted into a get_voltage_sel() which will mean
that the core can call list_voltage() for you. Either way you save
duplicating the code to map from selector to voltage.
--
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: [Regression?] Removed regulator support in ehci-omap
On 12:07 Sun 24 Apr , Keshava Munegowda wrote: I have posted the patches on April 22, 2011. If possible I request you to test this. Hi, Keshava! Sorry for delay - it took some time to find _where_ exactly you have posted the patch (thanks to Alan for giving the link). Anyway, it[1] seems to work as advertised (I also applied GPIO polarity fix [2] and board file patch[3], all on top of 2.6.39-rc4) - at least stuff in /sys/class/regulator looks right, and USB devices are detected. There's probably something still missing in the board file, as USB detection starts to work only if I booted TI's kernel (that came with board) before trying patched 2.6.39-rc4, but I hope that this isn't connected to this regulators issue. [1] http://www.spinics.net/lists/linux-usb/msg45618.html [2] https://lkml.org/lkml/2011/4/14/45 [3] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commitdiff;h=2ec611981ad76256d5034ae36708d807142bed1c -- Best regards, Dmitry MAD Artamonow -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] mtd: nand: Fix bad block identification issue
Commit e0b58d0 (mtd: nand: add -badblockbits for minimum number of set bits in bad block byte) by Maxim Levitsky added badblockbits to nand_chip to specify minimum number of set bits in bad block byte. The patch initialized badblockbits to 8 in nand_base.c, but later the initialization line got removed by commit c7b28e2(mtd: nand: refactor BB marker detection). After this all NAND drivers with NAND_SKIP_BBTSCAN are forced to initialize it to 8. Otherwise bad block identification will fail. As a result, mounting of empty jffs2 file system on omap3evm (having bad blocks) failed giving the following error message - mount: mounting /dev/mtdblock4 on /tmp failed: Input/output error This patch solves the above issue for omap by initialising badblockbits. We are working further on this to find a generic fix to the problem in nand_base.c. Signed-off-by: Saxena, Parth parth.sax...@ti.com Signed-off-by: Basheer, Mansoor Ahamed mansoor.aha...@ti.com --- drivers/mtd/nand/omap2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 454f90c..350c77f 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1005,6 +1005,8 @@ static int __devinit omap_nand_probe(struct platform_device *pdev) info-nand.options = pdata-devsize; info-nand.options |= NAND_SKIP_BBTSCAN; + info-nand.badblockbits = 8; + /* NAND write protect off */ gpmc_cs_configure(info-gpmc_cs, GPMC_CONFIG_WP, 0); -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
* Nicolas Pitre nicolas.pi...@linaro.org [110421 06:18]: On Thu, 21 Apr 2011, Tony Lindgren wrote: Otherwise we end up overwriting ourselves. This fixes booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db (ARM: 6750/1: improvements to compressed/head.S). Signed-off-by: Tony Lindgren t...@atomide.com I don't understand why this is needed. The copy loop is explicitly copying from the end going backward exactly to cope with this possibility. This one is starting to make sense now too after the stack corrupting the image issue is out of the way :) We can't overwrite the running code when relocating only a small amount, say 0x100 or so. There's no need to relocate all the way past the compressed kernel, we just need to relocate past the size of the code in head.o. Updated patch below using the GOT end instead of the compressed image end. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Wed, 27 Apr 2011 02:06:13 -0700 Subject: [PATCH] ARM: Fix relocation to move past the running code Otherwise we end up overwriting ourselves partially when relocating less than size of the running code in head.S. Without this patch, a system will not boot if the compressed image load address is slightly less than where the compressed image gets relocated. For example, using mkimage to set the load address to something like zreladdr + uncompressed image size - 0x100 will make the system hang without this patch. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -286,6 +286,7 @@ dtb_check_done: * r5 = start of this image * r9 = size of decompressed image * r10 = end of this image, including bss/stack/malloc space if non XIP + * r12 = GOT end, corrupted if relocating * We basically want: * r4 - 16k page directory = r10 - OK * r4 + image length = r5 - OK @@ -297,11 +298,20 @@ dtb_check_done: cmp r10, r5 bls wont_overwrite + /* +* Check if the relocate address overlaps the running code in +* head.S. In that case we need to relocate past the code +* to avoid overwriting some of the running code. +*/ + add r12, r12, r5@ use GOT end for upper limit + cmp r10, r12@ relocating less than GOT end? + mov r10, r12@ if so, relocate past GOT end + /* * Relocate ourselves past the end of the decompressed kernel. * r5 = start of this image * r6 = _edata - * r10 = end of the decompressed kernel + * r10 = end of the decompressed kernel or end of GOT end if larger * Because we always copy ahead, we need to do it from the end and go * backward in case the source and destination overlap. */ -- 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: Fix relocation if image end past uncompressed kernel end
* Tony Lindgren t...@atomide.com [110427 05:44]: * Nicolas Pitre nicolas.pi...@linaro.org [110421 06:18]: On Thu, 21 Apr 2011, Tony Lindgren wrote: Otherwise we end up overwriting ourselves. This fixes booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db (ARM: 6750/1: improvements to compressed/head.S). Signed-off-by: Tony Lindgren t...@atomide.com I don't understand why this is needed. The copy loop is explicitly copying from the end going backward exactly to cope with this possibility. This one is starting to make sense now too after the stack corrupting the image issue is out of the way :) We can't overwrite the running code when relocating only a small amount, say 0x100 or so. There's no need to relocate all the way past the compressed kernel, we just need to relocate past the size of the code in head.o. Updated patch below using the GOT end instead of the compressed image end. Oops, the mov should be movle of course. Updated patch below. Tony From: Tony Lindgren t...@atomide.com Date: Wed, 27 Apr 2011 02:06:13 -0700 Subject: [PATCH] ARM: Fix relocation to move past the running code Otherwise we end up overwriting ourselves partially when relocating less than size of the running code in head.S. Without this patch, a system will not boot if the compressed image load address is slightly less than where the compressed image gets relocated. For example, using mkimage to set the load address to something like zreladdr + uncompressed image size - 0x100 will make the system hang without this patch. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -286,6 +286,7 @@ dtb_check_done: * r5 = start of this image * r9 = size of decompressed image * r10 = end of this image, including bss/stack/malloc space if non XIP + * r12 = GOT end, corrupted if relocating * We basically want: * r4 - 16k page directory = r10 - OK * r4 + image length = r5 - OK @@ -297,11 +298,20 @@ dtb_check_done: cmp r10, r5 bls wont_overwrite + /* +* Check if the relocate address overlaps the running code in +* head.S. In that case we need to relocate past the code +* to avoid overwriting some of the running code. +*/ + add r12, r12, r5@ use GOT end for upper limit + cmp r10, r12@ relocating less than GOT end? + movle r10, r12@ if so, relocate past GOT end + /* * Relocate ourselves past the end of the decompressed kernel. * r5 = start of this image * r6 = _edata - * r10 = end of the decompressed kernel + * r10 = end of the decompressed kernel or end of GOT end if larger * Because we always copy ahead, we need to do it from the end and go * backward in case the source and destination overlap. */ -- 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 v9 4/9] OMAP3: PM: TWL4030 power scripts for OMAP3 boards
Hi Tony, On Mon, Apr 18, 2011 at 6:28 PM, Tony Lindgren t...@atomide.com wrote: * Manuel, Lesly Arackal lesl...@ti.com [110418 15:52]: To me it seems this should go into drivers/mfd instead. The script may contain omap specific values, but can be a loadable driver module. - subsys_initcall(twl_init) - twl_probe() - twl4030_power_init() - load_twl4030_script() #to copy this script data to the PM IC. Since this is getting called from a subsys initcall, not sure whether we can make this scripts as loadable module. AFAIK it does not need to do anything that early. Maybe take a look at initialing it later? The loading of script data configuration of resource is one time process, later HW will take care(executing the sequence in TWL based on sys_offmode, clk_req, ...signal states) So any specific reason for making this twl script as loadable module? Thanks regards, Lesly -- 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 v9 4/9] OMAP3: PM: TWL4030 power scripts for OMAP3 boards
* Manuel, Lesly Arackal lesl...@ti.com [110427 05:55]: Hi Tony, On Mon, Apr 18, 2011 at 6:28 PM, Tony Lindgren t...@atomide.com wrote: * Manuel, Lesly Arackal lesl...@ti.com [110418 15:52]: To me it seems this should go into drivers/mfd instead. The script may contain omap specific values, but can be a loadable driver module. - subsys_initcall(twl_init) - twl_probe() - twl4030_power_init() - load_twl4030_script() #to copy this script data to the PM IC. Since this is getting called from a subsys initcall, not sure whether we can make this scripts as loadable module. AFAIK it does not need to do anything that early. Maybe take a look at initialing it later? The loading of script data configuration of resource is one time process, later HW will take care(executing the sequence in TWL based on sys_offmode, clk_req, ...signal states) So any specific reason for making this twl script as loadable module? Because it should all be just a regular device driver living under drivers/. You can still pass the platform data to it, there should not be any need to initialize this earlier. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
2011/4/26 Tony Lindgren t...@atomide.com: * Linus Walleij linus.wall...@linaro.org [110423 01:32]: Since you'll probably be dependent on stuff happening in my patches to move stuff into drivers/gpio I'll be happy to carry the patches in my gpio-consolidation branch with Tony's ACKs if need be. Sounds good to me. I've just posted a patch series that moves our two GPIO drivers to drivers/gpio, they should serve as good inspiration... Tell me if I can help out, stack patches on top of this series and I'll carry them. Yours, Linus Walleij -- 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: omap2plus: GPIO cleanup mach-omap2/*
* Igor Grinberg grinb...@compulab.co.il [110427 02:02]: use gpio_request_one|array() instead of multiple gpiolib calls, remove unneeded variables, etc. Great :) 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
[PATCH] usb: musb: omap2430: Fix retention idle on musb peripheral only boards
Recent runtime pm and hwmod conversions for 2.6.39 broke the musb peripheral
mode OMAP retention idle on boards where the board mode in struct
musb_hdrc_platform_data is set to MUSB_PERIPHERAL.
These conversions changed the way how the OTG_SYSCONFIG register is
configured and used in runtime. Before 2.6.39 smart standby/idle modes were
activated statically in OTG_SYSCONFIG. Those modes allow that the musb is
able to idle when peripheral device is not connected to host.
In 2.6.39 the OTG_SYSCONFIG is updated runtime depending on VBUS status.
No standby/idle modes are used when device is connected and force
standby/idle when disconnected.
Unfortunately VBUS disconnect event that handles the disconnect case lets
the peripheral musb to idle only when board mode is MUSB_OTG. Fix this by
checking the peripheral mode also.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
For 2.6.39 as this fixes the PM regression on those OMAP3 boards that use
musb in peripheral mode only.
---
drivers/usb/musb/omap2430.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 57a27fa..e9e60b6 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -270,7 +270,7 @@ static int musb_otg_notifications(struct notifier_block *nb,
DBG(4, VBUS Disconnect\n);
#ifdef CONFIG_USB_GADGET_MUSB_HDRC
- if (is_otg_enabled(musb))
+ if (is_otg_enabled(musb) || is_peripheral_enabled(musb))
if (musb-gadget_driver)
#endif
{
--
1.7.4.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 FOR 2.6.39] omap: iommu: Return IRQ_HANDLED in fault handler when no fault occured
The iommu shares an interrupt line with the OMAP3 ISP. The iommu interrupt handler must check the fault status and return IRQ_HANDLED when no fault occured. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- arch/arm/plat-omap/iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) The OMAP3 ISP IOMMU got broken in 2.6.39-rc1 by commit d594f1f31afe13edd8c02f3854a65cc58cfb3b74 Author: David Cohen daco...@gmail.com Date: Wed Feb 16 19:35:51 2011 + omap: IOMMU: add support to callback during fault handling Add support to register an isr for IOMMU fault situations and adapt it to allow such (*isr)() to be used as fault callback. Drivers using IOMMU module might want to be informed when errors happen in order to debug it or react. Signed-off-by: David Cohen daco...@gmail.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com This patch fixes it and should be pushed to mainline in 2.6.39. The OMAP3 ISP driver, new in 2.6.39, would otherwise be totally broken until 2.6.40. diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 8a51fd5..34fc31e 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -793,6 +793,8 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) clk_enable(obj-clk); errs = iommu_report_fault(obj, da); clk_disable(obj-clk); + if (errs == 0) + return IRQ_HANDLED; /* Fault callback or TLB/PTE Dynamic loading */ if (obj-isr !obj-isr(obj, da, errs, obj-isr_priv)) -- Regards, Laurent Pinchart -- 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 v9 6/9] MFD: TWL4030: workaround changes for TWL4030 Erratum 27
Hi Samuel, On Tue, Apr 26, 2011 at 3:43 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Lesly, On Thu, Apr 14, 2011 at 05:57:54PM +0530, Lesly A M wrote: Workaround for TWL5030 Silicon Errata 27 28: 27 - VDD1, VDD2, may have glitches when their output value is updated. 28 - VDD1 and / or VDD2 DCDC clock may stop working when internal clock is switched from internal to external. Erratum 27: If the DCDC regulators is running on their internal oscillator, negative glitches may occur on VDD1, VDD2 output when voltage is changed. The OMAP device may reboot if the VDD1 or VDD2 go below the core minimum operating voltage. WORKAROUND Set up the TWL5030 DC-DC power supplies to use the HFCLKIN instead of the internal oscillator. Erratum 28: VDD1/VDD2 clock system may hang during switching the clock source from internal oscillator to external. VDD1/VDD2 output voltages may collapse if clock stops. WORKAROUND If HFCLK is disabled in OFFMODE, modify the sleep/wakeup sequence and setuptimes to make sure the switching will happen only when HFCLKIN is stable. Also use the TWL5030 watchdog to safeguard the first switching from internal oscillator to HFCLKIN during the TWL5030 init. IMPACT power sequence is changed. sleep/wakeup time values will be changed. The workaround changes are called from twl4030_power_init(), since we have to make some i2c_read calls to check the TWL4030 version the i2c will not be initialized in the early stage. This workaround is required for TWL5030 Silicon version less than ES1.2 The power script setup time changes are recommended by TI HW team. http://omapedia.org/wiki/TWL4030_power_scripts Changes taken from TWL4030 Erratum 27 workaround patch by Nishanth Menon. This patch and the following one depend on patch#4. Please re-send it once you agreed with Tony about where it should go. I will make the changes for Tony's comments and repost the patches. Thanks Regards, Lesly A 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
Re: [Regression?] Removed regulator support in ehci-omap
On Wed, Apr 27, 2011 at 5:21 PM, Dmitry Artamonow mad_s...@inbox.ru wrote: On 12:07 Sun 24 Apr , Keshava Munegowda wrote: I have posted the patches on April 22, 2011. If possible I request you to test this. Hi, Keshava! Sorry for delay - it took some time to find _where_ exactly you have posted the patch (thanks to Alan for giving the link). Anyway, it[1] seems to work as advertised (I also applied GPIO polarity fix [2] and board file patch[3], all on top of 2.6.39-rc4) - at least stuff in /sys/class/regulator looks right, and USB devices are detected. There's probably something still missing in the board file, as USB detection starts to work only if I booted TI's kernel (that came with board) before trying patched 2.6.39-rc4, but I hope that this isn't connected to this regulators issue. [1] http://www.spinics.net/lists/linux-usb/msg45618.html [2] https://lkml.org/lkml/2011/4/14/45 [3] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commitdiff;h=2ec611981ad76256d5034ae36708d807142bed1c -- Best regards, Dmitry MAD Artamonow I think I am missing something here! In which platform are you testing? keshava munegowda -- 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] mtd: nand: Fix bad block identification issue
Brian, did you really intend to remove badblockbits? Maybe it should go back to nand_base.c? On Wed, Apr 27, 2011 at 3:09 PM, Saxena, Parth parth.sax...@ti.com wrote: Commit e0b58d0 (mtd: nand: add -badblockbits for minimum number of set bits in bad block byte) by Maxim Levitsky added badblockbits to nand_chip to specify minimum number of set bits in bad block byte. The patch initialized badblockbits to 8 in nand_base.c, but later the initialization line got removed by commit c7b28e2(mtd: nand: refactor BB marker detection). After this all NAND drivers with NAND_SKIP_BBTSCAN are forced to initialize it to 8. Otherwise bad block identification will fail. As a result, mounting of empty jffs2 file system on omap3evm (having bad blocks) failed giving the following error message - mount: mounting /dev/mtdblock4 on /tmp failed: Input/output error This patch solves the above issue for omap by initialising badblockbits. We are working further on this to find a generic fix to the problem in nand_base.c. Signed-off-by: Saxena, Parth parth.sax...@ti.com Signed-off-by: Basheer, Mansoor Ahamed mansoor.aha...@ti.com --- drivers/mtd/nand/omap2.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 454f90c..350c77f 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1005,6 +1005,8 @@ static int __devinit omap_nand_probe(struct platform_device *pdev) info-nand.options = pdata-devsize; info-nand.options |= NAND_SKIP_BBTSCAN; + info-nand.badblockbits = 8; + /* NAND write protect off */ gpmc_cs_configure(info-gpmc_cs, GPMC_CONFIG_WP, 0); -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: omap2plus: GPIO cleanup mach-omap2/*
On Wed, Apr 27, 2011 at 5:01 PM, Tony Lindgren t...@atomide.com wrote: * Igor Grinberg grinb...@compulab.co.il [110427 02:02]: use gpio_request_one|array() instead of multiple gpiolib calls, remove unneeded variables, etc. Great :) I think this does conflict with Mike's omap: cleanup board files series though. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add basic devices support for Nook Color
Hello!
Thanks for the feedback.
On Apr 27, 2011, at 4:49 AM, Mike Rapoport wrote:
MMC/SD interface, i2c, usb.
You should have added these at the first patch instead of Android devices.
So, basically you want all board file changes to come as a single patch, right?
---
arch/arm/configs/encore-nookcolor-defconfig | 2015
+++
The defconfig should be a separate patch. You should rather add encore board
options to omap2plus_defconfig.
Hm, ok.
+static struct i2c_board_info __initdata encore_i2c_bus2_info[] = {
+};
+
+
+static struct omap_musb_board_data musb_board_data = {
+.interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
+.mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+.mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+.mode = MUSB_PERIPHERAL,
+#endif
This kind of ifdefery is handled inside the musb driver. I'd set the mode to
MUSB_OTG unless you want to explicitly limit it to HOST or PERIPHERAL
Actually it's not.
If I set MUSB_OTG here and then I choose PERIPHERAL mode in the kernel config,
the musb transceiver code will complain about board file and kernel config
mismatch.
The Nook Color is advertised as peripheral device, but OTG must be working too
(not totally working at this point) I think there is value to be able to
configure it
in two different modes.
Bye,
Oleg--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] hwmods: Integrate TI816X hwmods
This patch integrates TI816X hwmods into hwmods framework.
Note that a TI816X specific function ti816x_cm_wait_module_ready() is added to
wait for module to become ready since corresponding OMAP2/3 function
omap2_cm_wait_module_ready() cannot be used as there are no IDLEST registers in
TI816X.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
This patch depends on following patch set:
TI816X: prcm: Add module and register offsets
TI816X: clock: Add clock data
TI816X: clock: Add clockdomains and powerdomains data
clock: Integrate TI816X clock data into OMAP clock framework
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/cm2xxx_3xxx.h|1 +
arch/arm/mach-omap2/cm816x.c | 55 ++
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap_hwmod.c | 11 -
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
6 files changed, 68 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/cm816x.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ace5e4e..640294e 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -80,6 +80,7 @@ endif
obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o \
vc3xxx_data.o vp3xxx_data.o
+obj-$(CONFIG_SOC_OMAPTI816X) += cm816x.o
# XXX The presence of cm2xxx_3xxx.o on the line below is temporary and
# will be removed once the OMAP4 part of the codebase is converted to
# use OMAP4-specific PRCM functions.
@@ -149,6 +150,7 @@ obj-$(CONFIG_SOC_OMAP2430) += opp2430_data.o
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
+obj-$(CONFIG_SOC_OMAPTI816X) += omap_hwmod_816x_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
# EMU peripherals
diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.h
b/arch/arm/mach-omap2/cm2xxx_3xxx.h
index 11401c1..47f824a 100644
--- a/arch/arm/mach-omap2/cm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/cm2xxx_3xxx.h
@@ -122,6 +122,7 @@ extern void omap3xxx_cm_clkdm_disable_hwsup(s16 module, u32
mask);
extern void omap3xxx_cm_clkdm_force_sleep(s16 module, u32 mask);
extern void omap3xxx_cm_clkdm_force_wakeup(s16 module, u32 mask);
+extern int ti816x_cm_wait_module_ready(void __iomem *clkctrl_reg);
extern void ti816x_cm_clkdm_enable_hwsup(s16 inst, u16 clkdm, u32 mask);
extern void ti816x_cm_clkdm_disable_hwsup(s16 inst, u16 clkdm, u32 mask);
extern void ti816x_cm_clkdm_force_sleep(s16 inst, u16 clkdm, u32 mask);
diff --git a/arch/arm/mach-omap2/cm816x.c b/arch/arm/mach-omap2/cm816x.c
new file mode 100644
index 000..ec5b478
--- /dev/null
+++ b/arch/arm/mach-omap2/cm816x.c
@@ -0,0 +1,55 @@
+/*
+ * TI816X CM module functions
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Based on arch/arm/mach-omap2/cm4xxx.c, original copyright follows:
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * 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.
+ */
+#include linux/delay.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/io.h
+
+#include plat/common.h
+
+#include cm.h
+#include cm-regbits-816x.h
+
+/**
+ * ti816x_cm_wait_module_ready - wait for a module to be in 'func' state
+ * @clkctrl_reg: CLKCTRL module address
+ *
+ * Wait for the module IDLEST to be functional. If the idle state is in any
+ * the non functional state (trans, idle or disabled), module and thus the
+ * sysconfig cannot be accessed and will probably lead to an imprecise
+ * external abort
+ *
+ * Module idle state:
+ * 0x0 func: Module is fully functional, including OCP
+ * 0x1 trans:Module is performing transition: wakeup, or sleep, or sleep
+ * abortion
+ * 0x2 idle: Module is in Idle mode (only OCP part). It is functional if
+ * using separate functional clock
+ * 0x3 disabled: Module is disabled and cannot be accessed
+ *
+ */
+int ti816x_cm_wait_module_ready(void __iomem *clkctrl_reg)
+{
+ int i = 0;
+
+ if (!clkctrl_reg)
+ return 0;
+
+ omap_test_timeout((
+ ((__raw_readl(clkctrl_reg) TI816X_IDLEST_MASK) == 0)),
+ MAX_MODULE_READY_TIME, i);
+
+ return (i MAX_MODULE_READY_TIME) ? 0 : -EBUSY;
+}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 441e79d..e4e8500 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -366,6 +366,7 @@ void __init omap2_init_common_infrastructure(void)
[PATCH 1/2] TI816X: Add minimal hwmod data
This patch adds minimum required hwmod data (e.g., UARTs) for bootup of TI816X.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
This patch depends on following patch set:
[PATCH 1/4] TI816X: prcm: Add module and register offsets
[PATCH 2/4] TI816X: clock: Add clock data
[PATCH 3/4] TI816X: clock: Add clockdomains and powerdomains data
[PATCH 4/4] clock: Integrate TI816X clock data into OMAP clock framework
arch/arm/mach-omap2/omap_hwmod_816x_data.c | 636
1 files changed, 636 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_816x_data.c
diff --git a/arch/arm/mach-omap2/omap_hwmod_816x_data.c
b/arch/arm/mach-omap2/omap_hwmod_816x_data.c
new file mode 100644
index 000..edfa7f4
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_816x_data.c
@@ -0,0 +1,636 @@
+/*
+ * omap_hwmod_ti816x_data.c - hardware modules data for TI816X chips
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include plat/omap_hwmod.h
+#include mach/irqs.h
+#include plat/cpu.h
+#include plat/dma.h
+#include plat/serial.h
+#include plat/l4_3xxx.h
+#include plat/ti816x.h
+
+#include omap_hwmod_common_data.h
+
+#include control.h
+#include cm816x.h
+#include cm-regbits-816x.h
+
+/*
+ * TI816X hardware modules integration data
+ */
+
+static struct omap_hwmod ti816xx_mpu_hwmod;
+static struct omap_hwmod ti816x_l3_slow_hwmod;
+static struct omap_hwmod ti816x_l4_slow_hwmod;
+
+/* L3 SLOW - L4_SLOW Peripheral interface */
+static struct omap_hwmod_ocp_if ti816x_l3_slow__l4_slow = {
+ .master = ti816x_l3_slow_hwmod,
+ .slave = ti816x_l4_slow_hwmod,
+ .user = OCP_USER_MPU,
+};
+
+/* MPU - L3 SLOW interface */
+static struct omap_hwmod_ocp_if ti816x_mpu__l3_slow = {
+ .master = ti816xx_mpu_hwmod,
+ .slave = ti816x_l3_slow_hwmod,
+ .user = OCP_USER_MPU,
+};
+
+/* Slave interfaces on the L3 SLOW interconnect */
+static struct omap_hwmod_ocp_if *ti816x_l3_slow_slaves[] = {
+ ti816x_mpu__l3_slow,
+};
+
+/* Master interfaces on the L3 SLOW interconnect */
+static struct omap_hwmod_ocp_if *ti816x_l3_slow_masters[] = {
+ ti816x_l3_slow__l4_slow,
+};
+
+/* L3 SLOW */
+static struct omap_hwmod ti816x_l3_slow_hwmod = {
+ .name = l3_slow,
+ .class = l3_hwmod_class,
+ .masters= ti816x_l3_slow_masters,
+ .masters_cnt= ARRAY_SIZE(ti816x_l3_slow_masters),
+ .slaves = ti816x_l3_slow_slaves,
+ .slaves_cnt = ARRAY_SIZE(ti816x_l3_slow_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+ .flags = HWMOD_NO_IDLEST,
+};
+
+static struct omap_hwmod ti816x_uart1_hwmod;
+static struct omap_hwmod ti816x_uart2_hwmod;
+static struct omap_hwmod ti816x_uart3_hwmod;
+
+/* L4 SLOW - UART1 interface */
+static struct omap_hwmod_addr_space ti816x_uart1_addr_space[] = {
+ {
+ .pa_start = TI816X_UART1_BASE,
+ .pa_end = TI816X_UART1_BASE + SZ_8K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if ti816x_l4_slow__uart1 = {
+ .master = ti816x_l4_slow_hwmod,
+ .slave = ti816x_uart1_hwmod,
+ .clk= uart1_ick,
+ .addr = ti816x_uart1_addr_space,
+ .addr_cnt = ARRAY_SIZE(ti816x_uart1_addr_space),
+ .user = OCP_USER_MPU,
+};
+
+/* L4 SLOW - UART2 interface */
+static struct omap_hwmod_addr_space ti816x_uart2_addr_space[] = {
+ {
+ .pa_start = TI816X_UART2_BASE,
+ .pa_end = TI816X_UART2_BASE + SZ_8K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if ti816x_l4_slow__uart2 = {
+ .master = ti816x_l4_slow_hwmod,
+ .slave = ti816x_uart2_hwmod,
+ .clk= uart2_ick,
+ .addr = ti816x_uart2_addr_space,
+ .addr_cnt = ARRAY_SIZE(ti816x_uart2_addr_space),
+ .user = OCP_USER_MPU,
+};
+
+/* L4 SLOW - UART3 interface */
+static struct omap_hwmod_addr_space ti816x_uart3_addr_space[] = {
+ {
+ .pa_start = TI816X_UART3_BASE,
+ .pa_end = TI816X_UART3_BASE + SZ_8K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if ti816x_l4_slow__uart3 = {
+ .master =
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 12:49, Colin Cross ccr...@google.com wrote: +l-o I'm a little confused about the design for this, and OPP as well. OPP matches a struct device * and a frequency to a voltage, which is not a generically useful pairing, as far as I can tell. On Tegra, it is quite possible for a single device to have multiple clocks that each have different voltage requirements, for example the display block can have an interface clock as well as a pixel clock. Simplifying this to dev + freq = voltage seems very OMAP specific, and will be difficult or impossible to adapt to Tegra. We have the same requirements as well(iclk,fclk,pixclk etc..)! We group them under voltage domains in OMAP ;). if your issue was a ability to have a single freq to a OPP, it is upto SoC to do the proper mapping. Concept of an OPP still remains consistent - which is for a voltage, there is only so much freq you can drive that specific module to. Moreover, from a silicon perspective, there is always a simple link from a single frequency to a minimum voltage for a given circuit. There is no need to group them into OPPs, which seem to have a group of clocks and their frequencies that map to a single voltage. That is an artifact of the way TI specifies voltages. I don't think DVFS is even the right place for any sort of governor. DVFS is very simple - to increase to a specific clock speed, the voltage must be immediately be raised, with minimum or no delay, to a specified value that is specific to that clock. When the frequency is lowered, the voltage should be decreased. There is a tiny bit of policy to determine when to delay dropping the voltage in case the frequency will immediately be raised again, but nowhere near the complexity of what is shown here. I proposed in a different thread on LKML that DVFS be handled within the generic clock implementation. Platforms would register a regulator and a table of voltages for each struct clock that required DVFS, and the voltages would be changed on normal clk_* requests. This maintains compatibility with existing clk_* calls. It is upto SoC frameworks to implement the transitions. E.g. lets look at scalability: How'd the mechanism proposed work with temperature variances: Example: I dont want to hit 1.5GHz if temp 70C - wont it be an SoC specific hack I'd need to introduce? All OPP framework does is store that maps, and leaves it to users to choose regulators, clock framework variances, SoC temperature sensors or what ever mechanisms they choose to allow through a transition. There is a place for a GPU, etc., frequency governor, but it is a completely separate issue from DVFS, and should not be mixed in. I could have a GPU that is not voltage scalable, but could still benefit from lowering the frequency when it is not in use. A devfreq interface sounds perfect for this, as long as it only ends up calling clk_* functions, and those functions handle getting the voltage correct. Regards, Nishanth Menon PS: https://lists.linux-foundation.org/pipermail/linux-pm/2011-April/031113.html for start of thread -- 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: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 11:07 AM, Menon, Nishanth n...@ti.com wrote:
On Wed, Apr 27, 2011 at 12:49, Colin Cross ccr...@google.com wrote:
+l-o
I'm a little confused about the design for this, and OPP as well. OPP
matches a struct device * and a frequency to a voltage, which is not a
generically useful pairing, as far as I can tell. On Tegra, it is
quite possible for a single device to have multiple clocks that each
have different voltage requirements, for example the display block can
have an interface clock as well as a pixel clock. Simplifying this to
dev + freq = voltage seems very OMAP specific, and will be difficult
or impossible to adapt to Tegra.
We have the same requirements as well(iclk,fclk,pixclk etc..)! We
group them under voltage domains in OMAP ;). if your issue was a
ability to have a single freq to a OPP, it is upto SoC to do the
proper mapping. Concept of an OPP still remains consistent - which is
for a voltage, there is only so much freq you can drive that specific
module to.
No, that is still wrong. You don't drive a module at a frequency, you
drive a clock. You can't map struct device * 1-1 to a clock. Look at
omap2_set_init_voltage:
static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
struct device *dev) {
clk = clk_get(NULL, clk_name);
freq = clk-rate;
opp = opp_find_freq_ceil(dev, freq);
...
}
Now what happens if I have a dev with two frequencies,
Moreover, from a silicon perspective, there is always a simple link
from a single frequency to a minimum voltage for a given circuit.
There is no need to group them into OPPs, which seem to have a group
of clocks and their frequencies that map to a single voltage. That is
an artifact of the way TI specifies voltages.
I don't think DVFS is even the right place for any sort of governor.
DVFS is very simple - to increase to a specific clock speed, the
voltage must be immediately be raised, with minimum or no delay, to a
specified value that is specific to that clock. When the frequency is
lowered, the voltage should be decreased. There is a tiny bit of
policy to determine when to delay dropping the voltage in case the
frequency will immediately be raised again, but nowhere near the
complexity of what is shown here.
I proposed in a different thread on LKML that DVFS be handled within
the generic clock implementation. Platforms would register a
regulator and a table of voltages for each struct clock that required
DVFS, and the voltages would be changed on normal clk_* requests.
This maintains compatibility with existing clk_* calls.
It is upto SoC frameworks to implement the transitions. E.g. lets look
at scalability: How'd the mechanism proposed work with temperature
variances: Example: I dont want to hit 1.5GHz if temp 70C - wont it
be an SoC specific hack I'd need to introduce?
All OPP framework does is store that maps, and leaves it to users to
choose regulators, clock framework variances, SoC temperature sensors
or what ever mechanisms they choose to allow through a transition.
There is a place for a GPU, etc., frequency governor, but it is a
completely separate issue from DVFS, and should not be mixed in. I
could have a GPU that is not voltage scalable, but could still benefit
from lowering the frequency when it is not in use. A devfreq
interface sounds perfect for this, as long as it only ends up calling
clk_* functions, and those functions handle getting the voltage
correct.
Regards,
Nishanth Menon
PS:
https://lists.linux-foundation.org/pipermail/linux-pm/2011-April/031113.html
for start of thread
--
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: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
(sorry, missent the earlier one)
On Wed, Apr 27, 2011 at 11:07 AM, Menon, Nishanth n...@ti.com wrote:
On Wed, Apr 27, 2011 at 12:49, Colin Cross ccr...@google.com wrote:
+l-o
I'm a little confused about the design for this, and OPP as well. OPP
matches a struct device * and a frequency to a voltage, which is not a
generically useful pairing, as far as I can tell. On Tegra, it is
quite possible for a single device to have multiple clocks that each
have different voltage requirements, for example the display block can
have an interface clock as well as a pixel clock. Simplifying this to
dev + freq = voltage seems very OMAP specific, and will be difficult
or impossible to adapt to Tegra.
We have the same requirements as well(iclk,fclk,pixclk etc..)! We
group them under voltage domains in OMAP ;). if your issue was a
ability to have a single freq to a OPP, it is upto SoC to do the
proper mapping. Concept of an OPP still remains consistent - which is
for a voltage, there is only so much freq you can drive that specific
module to.
No, that is still wrong. You don't drive a module at a frequency, you
drive a clock. You can't map struct device * 1-1 to a clock. Look at
omap2_set_init_voltage:
static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
struct device *dev) {
...
clk = clk_get(NULL, clk_name);
freq = clk-rate;
opp = opp_find_freq_ceil(dev, freq);
...
}
What happens if I have a dev with two frequencies? I can only pass a
dev into opp. It makes infinitely more sense to pass in a clock:
opp_find_freq_ceil(clk, freq).
It is upto SoC frameworks to implement the transitions. E.g. lets look
at scalability: How'd the mechanism proposed work with temperature
variances: Example: I dont want to hit 1.5GHz if temp 70C - wont it
be an SoC specific hack I'd need to introduce?
No, because you're putting it in the wrong place, that is a policy
decision. Handle it in the clock framework, or handle it in the
device driver. That's a bad example either way - what happens if you
are already at 1.5GHz when the temperature crosses 70C? You need an
interrupt that tells you the temperature is too high, and than needs
to affect a policy decision at a much higher level than dvfs.
All OPP framework does is store that maps, and leaves it to users to
choose regulators, clock framework variances, SoC temperature sensors
or what ever mechanisms they choose to allow through a transition.
I understand its just a map, but its a map between two things that
don't have a direct mapping in many SoCs. I think if you changed
every usage of struct dev * in opp to struct clk *, it would make much
more sense. There is already a mapping from struct dev * to struct
clk *, its called clk_get, and it takes a second parameter to allow
devices to have multiple clocks.
--
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: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 13:29, Colin Cross ccr...@google.com wrote:
On Wed, Apr 27, 2011 at 11:07 AM, Menon, Nishanth n...@ti.com wrote:
On Wed, Apr 27, 2011 at 12:49, Colin Cross ccr...@google.com wrote:
+l-o
I'm a little confused about the design for this, and OPP as well. OPP
matches a struct device * and a frequency to a voltage, which is not a
generically useful pairing, as far as I can tell. On Tegra, it is
quite possible for a single device to have multiple clocks that each
have different voltage requirements, for example the display block can
have an interface clock as well as a pixel clock. Simplifying this to
dev + freq = voltage seems very OMAP specific, and will be difficult
or impossible to adapt to Tegra.
We have the same requirements as well(iclk,fclk,pixclk etc..)! We
group them under voltage domains in OMAP ;). if your issue was a
ability to have a single freq to a OPP, it is upto SoC to do the
proper mapping. Concept of an OPP still remains consistent - which is
for a voltage, there is only so much freq you can drive that specific
module to.
No, that is still wrong. You don't drive a module at a frequency, you
drive a clock. You can't map struct device * 1-1 to a clock. Look at
Agreed, module runs on clocks - Lets say n clocks provide a module
it's functionality.
omap2_set_init_voltage:
static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
struct device *dev) {
clk = clk_get(NULL, clk_name);
freq = clk-rate;
opp = opp_find_freq_ceil(dev, freq);
...
}
Now what happens if I have a dev with two frequencies,
we do have it - it depends on what the OPP table represents. we do
have modules which have both interface and functional clocks on OMAP
as well. for a module(represented by struct device *) which has n
clocks, choose the scheme of representation of clock that depends on
voltage for the module.
in the example you provided the display block can have an interface
clock as well as a pixel clock - I suppose you mean:
{.pclk = x, .iclk = y, .v = z}
The question I'd ask is this : for a voltage z, is the dependency on
pclk or iclk? I can expect a dependency of pclk to iclk requirement
(considering pixel clock drives an external display for example). the
table reduces to just
{.iclk = y, .v = z} and a different table that has divisor for .iclk
to pclk which is SoC based.
OPP table is just a storage and retrieval mechanism, it is upto SoC
frameworks to choose the most adequate of solutions - e.g. OMAP has
omap_device, hwmod and a clock framework for more intricate control to
work in conjunction with cpuidle frameworks as well.
There is cross domain dependency which OMAP (yet to be pushed to
mainline) has - example: when OMAP4's MPUs are at a certain OPP, L3
(OMAP's SoC bus) needs to be at least a certain OPP - these are
framework which may be very custom to OMAP itself.
---
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: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 11:48 AM, Menon, Nishanth n...@ti.com wrote:
On Wed, Apr 27, 2011 at 13:29, Colin Cross ccr...@google.com wrote:
On Wed, Apr 27, 2011 at 11:07 AM, Menon, Nishanth n...@ti.com wrote:
On Wed, Apr 27, 2011 at 12:49, Colin Cross ccr...@google.com wrote:
+l-o
I'm a little confused about the design for this, and OPP as well. OPP
matches a struct device * and a frequency to a voltage, which is not a
generically useful pairing, as far as I can tell. On Tegra, it is
quite possible for a single device to have multiple clocks that each
have different voltage requirements, for example the display block can
have an interface clock as well as a pixel clock. Simplifying this to
dev + freq = voltage seems very OMAP specific, and will be difficult
or impossible to adapt to Tegra.
We have the same requirements as well(iclk,fclk,pixclk etc..)! We
group them under voltage domains in OMAP ;). if your issue was a
ability to have a single freq to a OPP, it is upto SoC to do the
proper mapping. Concept of an OPP still remains consistent - which is
for a voltage, there is only so much freq you can drive that specific
module to.
No, that is still wrong. You don't drive a module at a frequency, you
drive a clock. You can't map struct device * 1-1 to a clock. Look at
Agreed, module runs on clocks - Lets say n clocks provide a module
it's functionality.
omap2_set_init_voltage:
static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
struct device *dev) {
clk = clk_get(NULL, clk_name);
freq = clk-rate;
opp = opp_find_freq_ceil(dev, freq);
...
}
Now what happens if I have a dev with two frequencies,
we do have it - it depends on what the OPP table represents. we do
have modules which have both interface and functional clocks on OMAP
as well. for a module(represented by struct device *) which has n
clocks, choose the scheme of representation of clock that depends on
voltage for the module.
in the example you provided the display block can have an interface
clock as well as a pixel clock - I suppose you mean:
{.pclk = x, .iclk = y, .v = z}
The question I'd ask is this : for a voltage z, is the dependency on
pclk or iclk? I can expect a dependency of pclk to iclk requirement
(considering pixel clock drives an external display for example). the
table reduces to just
{.iclk = y, .v = z} and a different table that has divisor for .iclk
to pclk which is SoC based.
No, there can be voltage requirements on both, and the higher voltage
requirement of the two must be used.
OPP table is just a storage and retrieval mechanism, it is upto SoC
frameworks to choose the most adequate of solutions - e.g. OMAP has
omap_device, hwmod and a clock framework for more intricate control to
work in conjunction with cpuidle frameworks as well.
There is cross domain dependency which OMAP (yet to be pushed to
mainline) has - example: when OMAP4's MPUs are at a certain OPP, L3
(OMAP's SoC bus) needs to be at least a certain OPP - these are
framework which may be very custom to OMAP itself.
---
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: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, 27 Apr 2011, Menon, Nishanth wrote: On Wed, Apr 27, 2011 at 12:49, Colin Cross ccr...@google.com wrote: I proposed in a different thread on LKML that DVFS be handled within the generic clock implementation. Platforms would register a regulator and a table of voltages for each struct clock that required DVFS, and the voltages would be changed on normal clk_* requests. This maintains compatibility with existing clk_* calls. It is upto SoC frameworks to implement the transitions. E.g. lets look at scalability: How'd the mechanism proposed work with temperature variances: Example: I dont want to hit 1.5GHz if temp 70C - wont it be an SoC specific hack I'd need to introduce? Why is limiting the max core frequency depending on temperature a SoC specific problem ? Everyone wants to do that. x86 does it in hardware / SMM, other architectures want the kernel to take care of it. So the decision is simple. Something wants to set core freq to 1.5 GHz, so it calls clk_set_rate() and there we consult the DVFS code first to validate that setting. If it can be set, fine, then DVFS will set the voltages _before_ we change the frequency or it will simply veto the change because one of the preliminaries for such a change is not given. Please stop thinking that your SoC is sooo special. It's NOT. The HW concepts are quite similar all over the place, they are just named differently and use different IP blocks with slightly different functionality, but the problems are not unique to a particular SoC at all. All OPP framework does is store that maps, and leaves it to users to choose regulators, clock framework variances, SoC temperature sensors or what ever mechanisms they choose to allow through a transition. That's how it's implemented, but that does not say that the design is correct and usable for more than the usecase it was modeled after. We are looking into a common clock framework, which abstracts out the duplicated functionality of the various implementations and reduces them to the real thing: hardware drivers. So we really need to look into that DVFS problem as well, simply because it is tightly coupled and not a complete separate entity. And looking at the struct clk disaster we really don't want another incarnation in terms of DVFS where we end up with the same decision functions in various SoCs over and over. Thanks, tglx
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, 27 Apr 2011, Menon, Nishanth wrote: OPP table is just a storage and retrieval mechanism, it is upto SoC frameworks to choose the most adequate of solutions - e.g. OMAP has omap_device, hwmod and a clock framework for more intricate control to work in conjunction with cpuidle frameworks as well. Can you please stop thinking about OMAP for a minute? A clock framework is nothing SoC specific. A framework is an abstraction of common HW functionality, which implements general functionality and relies on the HW specific part to configure it and to provide access to the hardware itself. clocks are ordered as trees in HW, simply because you cannot have a clock consumer be driven by more than one active clock at the same time. A clock consumer may select a different clock producer, but that merily changes the tree structure nothing else. So why should every SoC implement it's own (different buggy) version of tree handling and call it framework? Yes, I know you might argue that some devices need two clocks enabled to be functional. That's correct, but coupling those clocks at the framework level is the wrong thing to do. If a device needs both an interface clock and a separate interconnect clock to work, then it needs to enable both clocks and become a consumer of them. There is cross domain dependency which OMAP (yet to be pushed to mainline) has - example: when OMAP4's MPUs are at a certain OPP, L3 (OMAP's SoC bus) needs to be at least a certain OPP - these are framework which may be very custom to OMAP itself. Wrong again. That's not a framework when you hack SoC specific decision functions into it. It's the OMAP internal hackery to make stuff work, but that's far from a framework. What you are describing is a restriction which can be expressed in tables or rules which are fed into a general framework. Look at generic irqs, generic timekeeping, generic clockevents and tons of other real frameworks in the kernel. They abstract out concepts and provide generic interfaces rather than claiming that the problem is unique to a particular piece of silicon. Forget OMAP implementation details for a while, sit back and look at the big picture. Thanks, tglx -- 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: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 12:26 PM, Thomas Gleixner t...@linutronix.de wrote: Forget OMAP implementation details for a while, sit back and look at the big picture. Here's my proposal for DVFS: - DVFS is implemented in drivers/clk/dvfs.c, and is called by the common clock implementation to adjust the voltages, if necessary, on regular clk_* calls. - Platform code provides mappings in the form (clk, regulator, max frequency, min voltage) to the dvfs code. - Everything that is in OPP today gets converted to helper functions inside the dvfs implementation, and is never called from SoC code (except to pass tables at init), or from drivers. - OPP can be recreated in the future as a upper level policy manager for clocks that need to move together, if that is ever necessary. It would not know anything about voltages. - A few common policy implementations need to be added to the common clock implementation, like temperature limits. For Tegra: - DVFS continues to be accessed by calling clk_* functions For OMAP: - DVFS is triggered by hwmod through clk_* functions. Any cross-arch driver can continue to call clk_* functions. OPP currently has opp_enable and opp_disable functions. I don't understand why these are needed, they are only used at init time to determine available voltages, which could be handled by never passing unavailable voltages to the dvfs implementation. -- 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
[ANN] gst-dsp 0.9.0 released
Hi,
gst-dsp is a GStreamer plug-in to utilize Texas Intruments' DSP
algorithms for OMAP3 platforms using the tidspbridge driver.
This is a major release, many features have been implemented:
* Huge reorganization
* Support for IPP (image post-processor)
* Support for AAC decoder
* Support for VPP (video post-processor)
* Huge optimization for video encoders
* Improvements on caps negotiation
* Improvements on H.264 keyframe generation
* Improvements on hang detection
* Memory leaks fixed
* Fixes for WMV
* H.264 encoder tuning
* Support for gtk-doc
* Fix for JPEG encoder
Again, we have a lot of contributors. Thanks to everyone!
You can download the tarball from the usual place:
http://code.google.com/p/gst-dsp/downloads/list
And here's the amazing shortlog:
Arvind Gupta (2):
base: USN socket node interface changes
vdec: initialize the frame index for WMV
Elamparithi Shanmugam (19):
ipp: scaffold element
ipp: socket-node creation
ipp: add algo initialization
base: add some vmethods
ipp: add pipe init
ipp: add pipe deinit
ipp: add buffer processing
ipp: add error handling mechanism
ipp: add dmm_buffer_begin/end
ipp: add yuv420p to yuv422i conversion
ipp: add chroma suppression
ipp: add EENF
ipp: add dynamic parameter support for eenf
ipp: add YUV420p input support
ipp: update colour format in sink capability.
ipp: overwrite input buffer
ipp: fix to exit gracefully if error occurs
ipp: check for valid height and width value
venc: use 4 output buffers
Felipe Contreras (96):
build: use newer DSP API
venc: fix bitrate caping
Fix clang warnings
bridge: fix dsp_wait_for_events() for DSP_API 2
vdec: trivial cleanup
venc: move level fetching to setcaps()
venc: properly check for H.264 stream-format
venc: only strip sps/pps when marked as keyframe
h264enc: remove 'bytestream' property
venc: store level
venc: send max-bitrate to the sn instead of bitrate
venc: general cleanups
venc: unref caps after gst_pad_set_caps()
base: remove warning for empty buffer
build: make SN_API=2 the default
vdec: shuffle h264
vdec,venc: get rid of foo_data
vdec,venc: move profile_id selection to the args func
vdec,venc: reorganize arg_data stuff
vdec: create separate extra_data() handlers
base: introduce td_codec structure
vdec: reorganize into td_codec
venc: reorganize into td_codec
venc: fix compilation warnings
Make global gstdsp_set_codec_data_caps()
Create tidsp library, and split codecs
tidsp: generic cleanups
tidsp: h264enc: remove dead code
parse: properly update crop framesize
plugin: set a sane source package
Add gtk-doc
build: include tidsp dir on dependencies
tidsp: h.264 dec: trivial fix for I420
base: refactor ts_array/event_array
base: also use buffer durations
Rename 'id' to 'index'
base: decouple stream id from port index
vpp: add scaffold
vpp: add codec info
vpp: improve output framesize negotiation
Fix compilation warnings
tidsp: fix JPEG encoder for old SN
base: export send_buffer()
Get rid of gstdsp_send_buffer()
ipp: add vmethods' scaffolds
ipp: trivial cleanups
ipp: refactor get_yuvc_params()
ipp: add INTERNAL_FORMAT define
ipp: add support for older SN
ipp: move eenf params to ipp structure
ipp: fix the port allocation
ipp: trivial cleanups
ipp: reset semaphore correctly
ipp: fix memleak on errors
ipp: cleanup reset()
ipp: trivial cleanups
ipp: cleanup error handling
ipp: detect fatal errors
Trivial cleanup
base: trivial cleanup
base: introduce td_buffer
base: reorganize td_buffer stuff a bit
base: add port to td_buffer
base: trivial improvements in send_buffer()
Use td_buffer in {send,recv}_cb
base: use td_buffer in the queues
base: use td_buffer in send_buffer()
ipp: fix td_buffer handling
base: reorganize send_buffer()
Move 'user_data' field from dmm_buffer to td_buffer
Move 'used' field from dmm_buffer to td_buffer
Move 'keyframe' field from dmm_buffer to td_buffer
base: remove 'used' field in td_buffer
Fix gtk-doc stuff for ipp
Trivial cleanups
Add conditional compiling checks for caps_to_str
build: improve build for c99
tidsp: h264dec: trivial cleanup
base: trivial cleanup
Add new gst-dsp-buffer
venc: increase number of output buffers for JPEG
Add option to reuse output buffers
base: don't flush initial pinned buffer
base: don't flush last pinned buffer
base: trivial cleanup in send_buffer()
{h264,mp4v}enc: enable buffer recycling
sem: add new
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
On Wed, 27 Apr 2011, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [110427 05:44]: We can't overwrite the running code when relocating only a small amount, say 0x100 or so. There's no need to relocate all the way past the compressed kernel, we just need to relocate past the size of the code in head.o. Updated patch below using the GOT end instead of the compressed image end. Oops, the mov should be movle of course. Updated patch below. This is wrong. You're using r12 before it is fixed up with the proper offset. And this could simply be fixed with a big enough constant like this: diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 8dab5e3..71fc1d9 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -250,8 +250,11 @@ restart: adr r0, LC0 * Because we always copy ahead, we need to do it from the end and go * backward in case the source and destination overlap. */ - /* Round up to next 256-byte boundary. */ - add r10, r10, #256 + /* +* Round to a 256-byte boundary on the next page. This +* avoids overwriting ourself if the offset is small. +*/ + add r10, r10, #4096 bic r10, r10, #255 sub r9, r6, r5 @ size to copy -- 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] mtd: nand: Fix bad block identification issue
Hi, On 4/27/2011 8:45 AM, Grazvydas Ignotas wrote: Brian, did you really intend to remove badblockbits? Maybe it should go back to nand_base.c? No, I had no intention of the sorts! It surely should not have been removed in the first place. I will ack a patch to revert it, or next time I'm at my work machine I'll write one myself. As a defense for myself...I think I was relatively new to git + kernel hacking at the time I sent this patch. Sorry for the messup. On Wed, Apr 27, 2011 at 3:09 PM, Saxena, Parth parth.sax...@ti.com wrote: Commit e0b58d0 (mtd: nand: add -badblockbits for minimum number of set bits in bad block byte) by Maxim Levitsky added badblockbits to nand_chip to specify minimum number of set bits in bad block byte. The patch initialized badblockbits to 8 in nand_base.c, but later the initialization line got removed by commit c7b28e2(mtd: nand: refactor BB marker detection). After this all NAND drivers with NAND_SKIP_BBTSCAN are forced to initialize it to 8. Otherwise bad block identification will fail. Brian -- 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: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Thu, Apr 28, 2011 at 3:37 AM, Colin Cross ccr...@google.com wrote:
(sorry, missent the earlier one)
On Wed, Apr 27, 2011 at 11:07 AM, Menon, Nishanth n...@ti.com wrote:
On Wed, Apr 27, 2011 at 12:49, Colin Cross ccr...@google.com wrote:
+l-o
I'm a little confused about the design for this, and OPP as well. OPP
matches a struct device * and a frequency to a voltage, which is not a
generically useful pairing, as far as I can tell. On Tegra, it is
quite possible for a single device to have multiple clocks that each
have different voltage requirements, for example the display block can
have an interface clock as well as a pixel clock. Simplifying this to
dev + freq = voltage seems very OMAP specific, and will be difficult
or impossible to adapt to Tegra.
We have the same requirements as well(iclk,fclk,pixclk etc..)! We
group them under voltage domains in OMAP ;). if your issue was a
ability to have a single freq to a OPP, it is upto SoC to do the
proper mapping. Concept of an OPP still remains consistent - which is
for a voltage, there is only so much freq you can drive that specific
module to.
No, that is still wrong. You don't drive a module at a frequency, you
drive a clock. You can't map struct device * 1-1 to a clock. Look at
omap2_set_init_voltage:
static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
struct device *dev) {
...
clk = clk_get(NULL, clk_name);
freq = clk-rate;
opp = opp_find_freq_ceil(dev, freq);
...
}
What happens if I have a dev with two frequencies? I can only pass a
dev into opp. It makes infinitely more sense to pass in a clock:
opp_find_freq_ceil(clk, freq).
What one instance of DVFS (devfreq) controls are clocks and
regulators. (a device may have multiple regulators as well as multiple
clocks)
What one instance of DVFS (devfreq) monitors (device load and/or
temperature) is a device that uses the clocks and regulators.
If we focus on the things that are controlled by DVFS, connecting DVFS
with clock seems fine; however, DVFS's decision is based on the status
of the device and the decision (monitoring result) configures a set of
clocks and regulators. The clocks are not configured independently
from others if the clocks are used by a DVFS-capable device. The
frequency/voltage pair (OPP in this patch) associated with a device
becomes a representative value of a specific configuration that
configures the set of clocks and regulators.
This is quite similar with CPUFREQ. CPUFREQ provides a single
frequency value as a result of monitoring; however the machine's
cpufreq driver may set multiple clocks and multiple voltage regulators
based on the representative value (which is usually the core clock)
although the cpufreq driver may need to control many more clocks with
different frequencies.
With multiple clocks of a device, if there is a clock that is required
to be set independently from the representative clock with DVFS, it
means that the DVFS monitoring result (load/temperature) is not a
scalar value but a vector (multi-dimensional value). That implies that
we need to monitor different and independent values, which in turn,
implies that we need separated devices. Note that the DVFS monitor
result from load and temperature combined is not a multi-dimensional
value because the temperature limits maximum possible frequency or
voltage and the load gives preferred lower bound of frequency that
can be overridden by the limit set by temperature.
Therefore, having one DVFS per clock where multiple clocks are
attached to a device will create multiple monitors that monitor the
same object(device behavior) with same metrics (load and temperature).
Besides, the reason I've started with target callback, not clk and
regulator names or pointers is that a device may have multiple clks
and regulators and the OPP may only show the representative
clock/regulators as CPUFREQ does. Especially when the order of
transitions of those multiple clocks and regulators matter (if they
are in a single device, it sometimes does), running a DVFS per clock,
not per device, will be bothersome if not disasterous.
It is upto SoC frameworks to implement the transitions. E.g. lets look
at scalability: How'd the mechanism proposed work with temperature
variances: Example: I dont want to hit 1.5GHz if temp 70C - wont it
be an SoC specific hack I'd need to introduce?
No, because you're putting it in the wrong place, that is a policy
decision. Handle it in the clock framework, or handle it in the
device driver. That's a bad example either way - what happens if you
are already at 1.5GHz when the temperature crosses 70C? You need an
interrupt that tells you the temperature is too high, and than needs
to affect a policy decision at a much higher level than dvfs.
All OPP framework does is store that maps, and leaves it to users to
choose regulators, clock
