[PATCH V4] OMAP3+: SR Layer Cleanup
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.
Tested on OMAP3630 SDP and OMAP4430 SDP Board
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Acked by: Nishanth Menon n...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
V4:
Fixed comments like checking for NULL pointers
and following conventions in naming the instances
recommended by Todd Poynor and Benoit Cousson.
V3:
Changed the Subject and Rephrased Commit log as reviewed
by Nishanth Menon.
V2:
Rebased on latest 'pm-wip/voltdm_a' branch.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
arch/arm/mach-omap2/smartreflex.h| 10 ++
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 -
5 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3cd91ac..b1b11de 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2904,6 +2905,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_smartreflex_dev_attr sr1_dev_attr = {
+ .sensor_voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
/* SR2 */
+static struct omap_smartreflex_dev_attr sr2_dev_attr = {
+ .sensor_voltdm_name= core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3e88dd3..78b6860 100644
---
Re: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs
On Thu, May 12, 2011 at 4:58 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 05/12/11 13:49, Premi, Sanjeev wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Munegowda, Keshava Sent: Wednesday, May 11, 2011 7:35 PM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs [snip]...[snip] --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -27,7 +27,7 @@ #include linux/gpio.h #include plat/usb.h -#define USBHS_DRIVER_NAME usbhs-omap +#define USBHS_DRIVER_NAME usbhs_omap #define OMAP_EHCI_DEVICE ehci-omap #define OMAP_OHCI_DEVICE ohci-omap3 [sp] Shouldn't we be consistent in using minus/dash and underscore in the device names? Also, can't we avoid once again changing the clock names (at least for a while...)? Is that really necessary? Can't hwmod use current clock names? Because, Linus is sooo happy each time he sees that kind of changes This was actually earlier comment saying use _ as the convention for hwmod and runtime pm. only usbhs_omap uses the hwmod; the ehci and ohci drivers are children of usbhsh and they get the data from usbhs. Hence the older name of ehci and ochi drivers are retained as it is. if it is really needed, to change ehci and ohci driver names , then i can make it as another patch. -- Regards, Igor. -- 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 v10 3/7] MFD: TWL4030: Modifying the macro name Main_Ref to all caps
Hi Tony, On Thu, May 12, 2011 at 4:12 PM, Tony Lindgren t...@atomide.com wrote: * Lesly A M lesl...@ti.com [110506 06:14]: Modifying the macro name Main_Ref to all caps(MAIN_REF). This may get counted as crazy churn patch.. Please provide some reason for doing this in the patch description. I will update the change logs. Explained in Chapter 12 Documentation/CodingStyle. As per coding-style the macro name should be capitalized. So modifying the macro name Main_Ref to all caps(MAIN_REF). 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: [RESEND PATCH 0/4] omap: merge IGEP v2 and v3
Hi Mike, 2011/5/12 Mike Rapoport m...@compulab.co.il: Hi Tony, I'm resending this with the correct arm-linux mailing list cc'ed.. Just discard the first set, sorry for the noise... This is yet another attempt to reduce code duplication in the board files :) Only build tested, since I don't have the hardware, so I belive an Ack from Enric is required. Against which tree is based your work ? Cheers, Enric Mike Rapoport (4): omap: igep0020: name refactoring for future merge with IGEP3 omap: igep0020: minor refactoring omap: igep0020: add support for IGEP3 omap: drop board-igep0030.c arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-omap2/Makefile | 2 - arch/arm/mach-omap2/board-igep0020.c | 286 +- arch/arm/mach-omap2/board-igep0030.c | 438 -- 4 files changed, 174 insertions(+), 553 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-igep0030.c -- 1.7.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] Consolidate SRAM support
On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: This version fixes the davinci pm free, and adds updates for the davinci pcm driver. As I don't know what's happening with Jean's patch tweaking the genpool allocator, I've kept my version. Sorry I do not get the question. The latest changes I submitted have been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the PM code functions to SRAM' [1] . Thanks for that! This change is only about the simple linear SRAM allocator, not the genpool allocator. This still suffers from the only one region per pvpool problem which I believe Jean's patch doesn't suffer. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6338bdc8305b27688a7feb8689e4ccfd42f0292 Regards, Jean -- 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 v10 4/7] MFD: TWL4030: power scripts for OMAP3 boards
Hi Tony,
On Thu, May 12, 2011 at 4:26 PM, Tony Lindgren t...@atomide.com wrote:
* Lesly A M lesl...@ti.com [110506 06:14]:
Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset.
TWL4030 power scripts which can be used by different OMAP3 boards
with the power companion chip (TWL4030 series).
The twl4030 generic script can be used by any board file to update
the power data in twl4030_platform_data.
Since the TWL4030 power script has dependency with APIs in twl4030-power.c
removing the __init for these APIs.
For more information please see:
http://omapedia.org/wiki/TWL4030_power_scripts
Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/mach-omap2/devices.c | 15 ++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/twl4030-power.c | 31 ++--
drivers/mfd/twl4030-script-omap.c | 373
++
include/linux/i2c/twl.h | 41 -
7 files changed, 454 insertions(+), 19 deletions(-)
create mode 100644 drivers/mfd/twl4030-script-omap.c
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 076db52..d9b9858 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -184,6 +184,7 @@ CONFIG_TWL4030_WATCHDOG=y
CONFIG_MENELAUS=y
CONFIG_TWL4030_CORE=y
CONFIG_TWL4030_POWER=y
+CONFIG_TWL4030_SCRIPT=m
CONFIG_REGULATOR=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_REGULATOR_TPS65023=y
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 7b85585..7653329 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -329,6 +329,20 @@ static void omap_init_audio(void)
static inline void omap_init_audio(void) {}
#endif
+#ifdef CONFIG_ARCH_OMAP3
+static struct platform_device omap_twl4030_script = {
+ .name = twl4030_script,
+ .id = -1,
+};
+
+static void omap_init_twl4030_script(void)
+{
+ platform_device_register(omap_twl4030_script);
+}
+#else
+static inline void omap_init_twl4030_script(void) {}
+#endif
This should be if defined(CONFIG_TWL4030_SCRIPT) ||
defined(CONFIG_TWL4030_SCRIPT_MODULE) instead. And you should
probably only enable it based on some board specific flag.
Ok
#if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
#include plat/mcspi.h
@@ -691,6 +705,7 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_vout();
+ omap_init_twl4030_script();
return 0;
}
The changes above probably also conflict with what I have
in devel-cleanup branch. So maybe split it so I can take this
part?
Ok, I will split this change to a separate patch.
Also, please note that patches touching arch/arm/*omap*/
files should also be sent with linux-arm-kernel list Cc'd.
Ok
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: [RESEND PATCH 0/4] omap: merge IGEP v2 and v3
Hi Enric, On Fri, May 13, 2011 at 09:27:18AM +0200, Enric Balletb?? i Serra wrote: Hi Mike, 2011/5/12 Mike Rapoport m...@compulab.co.il: Hi Tony, I'm resending this with the correct arm-linux mailing list cc'ed.. Just discard the first set, sorry for the noise... This is yet another attempt to reduce code duplication in the board files :) Only build tested, since I don't have the hardware, so I belive an Ack from Enric is required. Against which tree is based your work ? It's based on devel-cleaup branch in Tony's linux-omap tree. Cheers, Enric Mike Rapoport (4): ??omap: igep0020: name refactoring for future merge with IGEP3 ??omap: igep0020: minor refactoring ??omap: igep0020: add support for IGEP3 ??omap: drop board-igep0030.c ??arch/arm/mach-omap2/Kconfig ?? ?? ?? ?? ??| ?? ??1 + ??arch/arm/mach-omap2/Makefile ?? ?? ?? ?? | ?? ??2 - ??arch/arm/mach-omap2/board-igep0020.c | ??286 +- ??arch/arm/mach-omap2/board-igep0030.c | ??438 -- ??4 files changed, 174 insertions(+), 553 deletions(-) ??delete mode 100644 arch/arm/mach-omap2/board-igep0030.c -- 1.7.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/5] arm: omap: usb: device name change for the clk names of usbhs
-Original Message- From: Munegowda, Keshava Sent: Friday, May 13, 2011 12:04 PM To: Igor Grinberg Cc: Premi, Sanjeev; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: Re: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs On Thu, May 12, 2011 at 4:58 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 05/12/11 13:49, Premi, Sanjeev wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Munegowda, Keshava Sent: Wednesday, May 11, 2011 7:35 PM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs [snip]...[snip] --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -27,7 +27,7 @@ #include linux/gpio.h #include plat/usb.h -#define USBHS_DRIVER_NAME usbhs-omap +#define USBHS_DRIVER_NAME usbhs_omap #define OMAP_EHCI_DEVICE ehci-omap #define OMAP_OHCI_DEVICE ohci-omap3 [sp] Shouldn't we be consistent in using minus/dash and underscore in the device names? Also, can't we avoid once again changing the clock names (at least for a while...)? Is that really necessary? Can't hwmod use current clock names? Because, Linus is sooo happy each time he sees that kind of changes This was actually earlier comment saying use _ as the convention for hwmod and runtime pm. only usbhs_omap uses the hwmod; the ehci and ohci drivers are children of usbhsh and they get the data from usbhs. Hence the older name of ehci and ochi drivers are retained as it is. if it is really needed, to change ehci and ohci driver names , then i can make it as another patch. [sp] A common convetion helps. Another patch will definitely help usability. ~sanjeev -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] Consolidate SRAM support
On Fri, May 13, 2011 at 09:30:14AM +0200, Jean Pihet wrote: On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: This version fixes the davinci pm free, and adds updates for the davinci pcm driver. As I don't know what's happening with Jean's patch tweaking the genpool allocator, I've kept my version. Sorry I do not get the question. The latest changes I submitted have been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the PM code functions to SRAM' [1] . Thanks for that! This change is only about the simple linear SRAM allocator, not the genpool allocator. The wrong Jean! I meant Jean-Christophe PLAGNIOL-VILLARD. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] Consolidate SRAM support
Russell, On 5/12/2011 11:15 PM, Russell King - ARM Linux wrote: On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote: This is work in progress. Tried this patch on OMAP and found couple of issues. 1. Compilation break. Below is the fix for the same. diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index 68f57ff..78d1af4 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -75,6 +75,7 @@ static unsigned long omap_sram_start; static unsigned long omap_sram_base; static unsigned long omap_sram_size; +static unsigned long omap_sram_ceil; /* * Depending on the target RAMFS firewall setup, the public usable amount of -- 1.6.0.4 2. The boot takes data abort while allocating memory for struct pv_pool. Here is the back-trace. I haven't debugged it further though. -000|NSR:0x0010(asm) --|exception -001|kmem_cache_alloc_trace(size = 0x0C, cachep = 0x0, flags = 0x80D0) -002|pv_pool_create(addr = 0xFE40, phys = 0x4020, len = 0x0001, min_alloc_order = 0x3) -003|omap_sram_init() -004|paging_init(?) -005|setup_arch(cmdline_p = 0xC058BFE4) -006|start_kernel() -007|NSR:0x8000803C(asm) ---|end of frame | Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] Consolidate SRAM support
On Fri, May 13, 2011 at 11:11 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, May 13, 2011 at 09:30:14AM +0200, Jean Pihet wrote: On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: This version fixes the davinci pm free, and adds updates for the davinci pcm driver. As I don't know what's happening with Jean's patch tweaking the genpool allocator, I've kept my version. Sorry I do not get the question. The latest changes I submitted have been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the PM code functions to SRAM' [1] . Thanks for that! This change is only about the simple linear SRAM allocator, not the genpool allocator. The wrong Jean! I meant Jean-Christophe PLAGNIOL-VILLARD. Ok, sorry about that! Regards, Jean -- 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/5] arm: omap: usb: device name change for the clk names of usbhs
On Fri, May 13, 2011 at 2:35 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Munegowda, Keshava Sent: Friday, May 13, 2011 12:04 PM To: Igor Grinberg Cc: Premi, Sanjeev; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: Re: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs On Thu, May 12, 2011 at 4:58 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 05/12/11 13:49, Premi, Sanjeev wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Munegowda, Keshava Sent: Wednesday, May 11, 2011 7:35 PM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs [snip]...[snip] --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -27,7 +27,7 @@ #include linux/gpio.h #include plat/usb.h -#define USBHS_DRIVER_NAME usbhs-omap +#define USBHS_DRIVER_NAME usbhs_omap #define OMAP_EHCI_DEVICE ehci-omap #define OMAP_OHCI_DEVICE ohci-omap3 [sp] Shouldn't we be consistent in using minus/dash and underscore in the device names? Also, can't we avoid once again changing the clock names (at least for a while...)? Is that really necessary? Can't hwmod use current clock names? Because, Linus is sooo happy each time he sees that kind of changes This was actually earlier comment saying use _ as the convention for hwmod and runtime pm. only usbhs_omap uses the hwmod; the ehci and ohci drivers are children of usbhsh and they get the data from usbhs. Hence the older name of ehci and ochi drivers are retained as it is. if it is really needed, to change ehci and ohci driver names , then i can make it as another patch. [sp] A common convetion helps. Another patch will definitely help usability. ~sanjeev sure, I will send ASAP. -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2: Simultaneous DSI and DPI panels
Hi, On Friday 13 May 2011 12:46 AM, Juha Kuikka wrote: Hello, I was wondering if it would be possible to run DPI and DSI interfaces simultaneously with OMAP3 (DM3730). Limitations: - DSI would have to be in video mode (data to DSI phy through video port with H/VSYNC signaling, OMAP_DSS_PARALLELMODE_BYPASS) - DSI PLL would need to be used for clock source - Both the DPI and DSI panels would have to accept identical clocking (PCLK, blanking intervals etc). - Data lane # must match. - And of course same data would go to both I realize the current SW does not support this, but I'm more wondering if it is possible from the HW point of view because it seems to me that data out from DISPC is pretty much identical in both cases. I don't think this is possible on OMAP3, there is one LCD manager in OMAP3 which can either feed pixels to DPI or DSI. The only way you could run 2 panels is by routing LCD manager's content to DPI, and use DSI's capability to do a system DMA directly and send the data to the panel(bypassing DISPC), I don't think the system DMA method will work with a video mode panel, only command mode panels will do here. Archit - Juha -- 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 v1] omap: usbhs: Fixed the crash during rmmod of ehci and ohci
On Wed, May 11, 2011 at 06:20:41PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The disableing of clocks and freeing GPIO are changed to fix the occurence of the crash of rmmod of ehci and ohci drivers. The GPIOs should be freed after the spin locks are unlocked. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com should this go via Samuel ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] arm: omap: usb: Runtime PM support for EHCI and OHCI drivers
Hi, On Wed, May 11, 2011 at 07:34:31PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. Keshava Munegowda (5): arm: omap: usb: ehci and ohci hwmod structures for omap3 and omap4 arm: omap: usb: register hwmods of usbhs arm: omap: usb: device name change for the clk names of usbhs arm: omap: usb: Runtime PM support arm: omap: usb: global Suspend and resume support of ehci and ohci arch/arm/mach-omap2/clock3xxx_data.c | 28 ++-- arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 184 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 153 ++ arch/arm/mach-omap2/usb-host.c | 99 drivers/mfd/omap-usb-host.c| 236 +--- same for this series. Part goes through linux-omap and part via mfd tree ? -- balbi signature.asc Description: Digital signature
Re: DSS2: Simultaneous DSI and DPI panels
On Fri, 2011-05-13 at 16:14 +0530, Archit Taneja wrote: Hi, On Friday 13 May 2011 12:46 AM, Juha Kuikka wrote: Hello, I was wondering if it would be possible to run DPI and DSI interfaces simultaneously with OMAP3 (DM3730). Limitations: - DSI would have to be in video mode (data to DSI phy through video port with H/VSYNC signaling, OMAP_DSS_PARALLELMODE_BYPASS) - DSI PLL would need to be used for clock source - Both the DPI and DSI panels would have to accept identical clocking (PCLK, blanking intervals etc). - Data lane # must match. - And of course same data would go to both I realize the current SW does not support this, but I'm more wondering if it is possible from the HW point of view because it seems to me that data out from DISPC is pretty much identical in both cases. I don't think this is possible on OMAP3, there is one LCD manager in OMAP3 which can either feed pixels to DPI or DSI. The only way you could run 2 panels is by routing LCD manager's content to DPI, and use DSI's capability to do a system DMA directly and send the data to the panel(bypassing DISPC), I don't think the system DMA method will work with a video mode panel, only command mode panels will do here. Yes, that is correct. DPI + DSI command mode would work, although in that case the DSI panel would be driven by CPU or sDMA, both of which are not very good at the job. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
* Vladimir Zapolskiy vzapols...@gmail.com [110512 17:35]: This mass change reduces homogeneous data chunks along clock definitions. No semantical difference is added to the change, and still it could be introduced easily. Signed-off-by: Vladimir Zapolskiy vzapols...@gmail.com --- arch/arm/mach-omap2/clock44xx_data.c | 3313 +- 1 files changed, 848 insertions(+), 2465 deletions(-) Hehehe, the diffstat certainly looks good :) This would be best done for all of them using some perl/sed/python script. And could be done for the hwmod data too. Do you already have something like that available? Paul and Benoit, what's your take on doing something like this? I'd assume updating your data generation scripts would be trivial? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated mach-types update
* Tony Lindgren t...@atomide.com [110324 10:57]:
* Russell King - ARM Linux li...@arm.linux.org.uk [110320 04:39]:
On Sun, Mar 20, 2011 at 11:03:22AM +, Russell King - ARM Linux wrote:
Note that OMAP references machine_is_omap2evm() yet this has never been
merged.
arch/arm/plat-omap/include/plat/uncompress.h:
DEBUG_LL_OMAP2(1, omap2evm);
so this entry needs to be removed.
Hmm looks like we have LCD support and ASoC support for it, but no
board :)
Anybody working with this board?
If so, please send patches for the related board-*.c support ASAP.
Otherwise let's plan on deleting the related support.
No patches, so let's remove it. Here's the patch to do that,
I'm planning to add this to my devel-cleanup branch.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 13 May 2011 04:41:32 -0700
Subject: [PATCH] omap: Remove support for omap2evm
The board support has never been merged for it as noticed
by Russell King li...@arm.linux.org.uk. So let's remove the
related dead code.
Cc: linux-fb...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
b/arch/arm/plat-omap/include/plat/uncompress.h
index 30b891c..2b576f1 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -129,7 +129,6 @@ static inline void __arch_decomp_setup(unsigned long
arch_id)
DEBUG_LL_OMAP1(3, sx1);
/* omap2 based boards using UART1 */
- DEBUG_LL_OMAP2(1, omap2evm);
DEBUG_LL_OMAP2(1, omap_2430sdp);
DEBUG_LL_OMAP2(1, omap_apollon);
DEBUG_LL_OMAP2(1, omap_h4);
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 49226a1..25db556 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -30,7 +30,6 @@ objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o
-objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
diff --git a/drivers/video/omap/lcd_omap2evm.c
b/drivers/video/omap/lcd_omap2evm.c
deleted file mode 100644
index 7e7a65c..000
--- a/drivers/video/omap/lcd_omap2evm.c
+++ /dev/null
@@ -1,192 +0,0 @@
-/*
- * LCD panel support for the MISTRAL OMAP2EVM board
- *
- * Author: Arun C arunedar...@mistralsolutions.com
- *
- * Derived from drivers/video/omap/lcd_omap3evm.c
- * Derived from drivers/video/omap/lcd-apollon.c
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/gpio.h
-#include linux/i2c/twl.h
-
-#include plat/mux.h
-#include asm/mach-types.h
-
-#include omapfb.h
-
-#define LCD_PANEL_ENABLE_GPIO 154
-#define LCD_PANEL_LR 128
-#define LCD_PANEL_UD 129
-#define LCD_PANEL_INI 152
-#define LCD_PANEL_QVGA 148
-#define LCD_PANEL_RESB 153
-
-#define TWL_LED_LEDEN 0x00
-#define TWL_PWMA_PWMAON0x00
-#define TWL_PWMA_PWMAOFF 0x01
-
-static unsigned int bklight_level;
-
-static int omap2evm_panel_init(struct lcd_panel *panel,
- struct omapfb_device *fbdev)
-{
- gpio_request(LCD_PANEL_ENABLE_GPIO, LCD enable);
- gpio_request(LCD_PANEL_LR, LCD lr);
- gpio_request(LCD_PANEL_UD, LCD ud);
- gpio_request(LCD_PANEL_INI, LCD ini);
- gpio_request(LCD_PANEL_QVGA, LCD qvga);
- gpio_request(LCD_PANEL_RESB, LCD resb);
-
- gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(LCD_PANEL_RESB, 1);
- gpio_direction_output(LCD_PANEL_INI, 1);
- gpio_direction_output(LCD_PANEL_QVGA, 0);
- gpio_direction_output(LCD_PANEL_LR, 1);
- gpio_direction_output(LCD_PANEL_UD, 1);
-
- twl_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
- twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
- twl_i2c_write_u8(TWL4030_MODULE_PWMA, 0x02,
Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
On Fri, May 13, 2011 at 2:30 PM, Tony Lindgren t...@atomide.com wrote: * Vladimir Zapolskiy vzapols...@gmail.com [110512 17:35]: This mass change reduces homogeneous data chunks along clock definitions. No semantical difference is added to the change, and still it could be introduced easily. Signed-off-by: Vladimir Zapolskiy vzapols...@gmail.com --- arch/arm/mach-omap2/clock44xx_data.c | 3313 +- 1 files changed, 848 insertions(+), 2465 deletions(-) Hehehe, the diffstat certainly looks good :) This would be best done for all of them using some perl/sed/python script. And could be done for the hwmod data too. Do you already have something like that available? Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact if nobody has serious objections about the nature of the change itself, then I'd like to continue with similar modifications for other OMAP specific massive data files, hopefully there is a lot of redundant data to eliminate :) I can try to do that starting from writing the script for automation, though I don't have a strong feeling that it's a straightforward task, and preprocessed code check and/or runtime check might be preferable. Paul and Benoit, what's your take on doing something like this? I'd assume updating your data generation scripts would be trivial? With best wishes, Vladimir -- 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] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
On 11/05/11 14:55, Premi, Sanjeev wrote: Current checks for cpu type were too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi pr...@ti.com cc: Mark Brown broo...@opensource.wolfsonmicro.com cc: Liam Girdwood l...@ti.com cc: Jarkko Nikula jhnik...@gmail.com --- Changes in v4: Reposting after validating that patch still applies cleanly on linux-omap master [46966f1] Changed the subject as suggested by Jarkko. Since the subject has changed, i have omitted v4. Changes in v3:: None. Reposting[1] after subscribing to alsa-devel list Changes in v2: 1) Added one more check to the changes. 2) Updated commit message to use plurals. Applied. Thanks Liam -- 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: Updated mach-types update
On Fri, 13 May 2011 04:54:07 -0700 Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [110324 10:57]: * Russell King - ARM Linux li...@arm.linux.org.uk [110320 04:39]: On Sun, Mar 20, 2011 at 11:03:22AM +, Russell King - ARM Linux wrote: Note that OMAP references machine_is_omap2evm() yet this has never been merged. arch/arm/plat-omap/include/plat/uncompress.h: DEBUG_LL_OMAP2(1, omap2evm); so this entry needs to be removed. Hmm looks like we have LCD support and ASoC support for it, but no board :) Anybody working with this board? If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support. No patches, so let's remove it. Here's the patch to do that, I'm planning to add this to my devel-cleanup branch. Remove also from sound/soc/omap/Kconfig as well. You could put my ack for sound/soc/omap part but remember cc also Mark and Liam. Acked-by: Jarkko Nikula jhnik...@gmail.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] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
Tony Lindgren t...@atomide.com writes: * Vladimir Zapolskiy vzapols...@gmail.com [110512 17:35]: This mass change reduces homogeneous data chunks along clock definitions. No semantical difference is added to the change, and still it could be introduced easily. Signed-off-by: Vladimir Zapolskiy vzapols...@gmail.com --- arch/arm/mach-omap2/clock44xx_data.c | 3313 +- 1 files changed, 848 insertions(+), 2465 deletions(-) Hehehe, the diffstat certainly looks good :) This would be best done for all of them using some perl/sed/python script. And could be done for the hwmod data too. Do you already have something like that available? Paul and Benoit, what's your take on doing something like this? I'd assume updating your data generation scripts would be trivial? Can this be reposted to the list? I didn't receive the original, and don't see it in the l-o or l-a-k archives. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
Hi Vladimir, Could you please re-send your original patch? For some reason I cannot find it in any mailing list so far. Maybe it is due to its size. On 5/13/2011 2:08 PM, Vladimir Zapolskiy wrote: On Fri, May 13, 2011 at 2:30 PM, Tony Lindgrent...@atomide.com wrote: * Vladimir Zapolskiyvzapols...@gmail.com [110512 17:35]: This mass change reduces homogeneous data chunks along clock definitions. No semantical difference is added to the change, and still it could be introduced easily. Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com --- arch/arm/mach-omap2/clock44xx_data.c | 3313 +- 1 files changed, 848 insertions(+), 2465 deletions(-) Hehehe, the diffstat certainly looks good :) This would be best done for all of them using some perl/sed/python script. And could be done for the hwmod data too. Do you already have something like that available? Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/7] MFD: TWL4030: Fix for the TWL4030 sleep/wakeup sequence
Lesly A M lesl...@ti.com writes:
Only configure sleep script when the flag is TWL4030_SLEEP_SCRIPT.
Adding the missing brackets for fixing the issue.
Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Kevin Hilman khil...@ti.com
---
drivers/mfd/twl4030-power.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 6fed964..97f54ce 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -447,12 +447,13 @@ static int __init load_twl4030_script(struct
twl4030_script *tscript,
if (err)
goto out;
}
- if (tscript-flags TWL4030_SLEEP_SCRIPT)
+ if (tscript-flags TWL4030_SLEEP_SCRIPT) {
if (order)
pr_warning(TWL4030: Bad order of scripts (sleep \
script before wakeup) Leads to boot\
failure on some boards\n);
err = twl4030_config_sleep_sequence(address);
+ }
out:
return err;
}
--
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:pm: Fix boot-time errors with debugfs disabled
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Friday, May 13, 2011 12:46 AM To: Menon, Nishanth Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled [sp] Last I tried, with Vishwa's dvfs branch on panda without voltage registrations, things could crash :( if I get some time I will try to port Vishwa's series onto kevin's branch as well and test and provide any patches necessary. [sp] I can try this on Panda. Will be able to get one tomorrow. Tested same uImage on Panda as well. Just pasting the top header here... [0.00] Linux version 2.6.39-rc4-13782-gd695569-dirty (premi@mylinux) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #6 SMP Thu May 12 21:40:58 IST 2011 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] Truncating RAM at 8000-bfff to -afff (vmalloc region overlap). [0.00] OMAP4430 ES2.1 ~sanjeev [snip]...[snip] -- 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: !CONFIG_OMAP_32K_TIMER on OMAP4/panda
Hi Hemant, Pedanekar, Hemant hema...@ti.com writes: Hello, linux-omap-ow...@vger.kernel.org wrote on Saturday, May 07, 2011 10:21 PM: On a linux-next kernel built for the Pandaboard, disabling CONFIG_OMAP_32K_TIMER makes the kernel use the gptimer as the clocksource, but this appears to be non-functional. Judging from the all-zeros printk timings and the fact the sleep 1 hangs indefinitely, it looks like the clocksource reads are always zero. Boot log below and .config attached. Ideas? [0.00] Linux version 2.6.39-rc6-next-20110506+ (rabin@debian) [...] [0.00] Freeing init memory: 112K This looks similar to the issue I observed on TI816X with 32K timer disabled. I have created following patch (currently a tempfix) for making timekeeping work with MPU timer selected (other option is to use .flags = HWMOD_INIT_NO_RESET in hwmod data for the timer used as clocksource): commit 77cce922c00ced4407776cc0a1d84cee40b7da90 Author: Hemant Pedanekar hema...@ti.com Date: Thu Apr 28 12:59:24 2011 +0530 dmtimer: Initialize the hwmod for timer used as clocksource Since dmtimer driver still doesn't use hwmods, the 2nd timer used as clocksource is not set up. The driver will never be the one to init the hwmod, it's up to device level code to do that, so your approach is the right one. This results into timekeepoing failure when the timer used as clocksource gets reset during hwmod setup. To prevent this, explicitly call omap_hwmod_setup_one() for timer used as clocksource. Note that is is aplpicable when NOT using 32k timer which is the case for typo: applicable TI816X. For other configurations, this code will not be executed unless 32K timer is explicitly disabled. Also, you can fix up this changelog to say it's not only for 816x, but for any case where the MPU timer is the clocksource. Signed-off-by: Hemant Pedanekar hema...@ti.com diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c index 3b9cf85..290fbfa 100644 --- a/arch/arm/mach-omap2/timer-gp.c +++ b/arch/arm/mach-omap2/timer-gp.c @@ -229,6 +229,11 @@ static void __init omap2_gp_clocksource_init(void) %s: failed to request dm-timer\n; static char err2[] __initdata = KERN_ERR %s: can't register clocksource!\n; + char clocksource_hwmod_name[8]; /* 8 = sizeof(timerXX0) */ + + /* XXX: This may not be always true, we might get different timer */ + sprintf(clocksource_hwmod_name, timer%d, gptimer_id + 1); Do you have ideas to make an upstream fix for this? As you already notied, this can't work in the general case (and will fail today on beagle where gptimer_id gets set to 12.) Kevin + omap_hwmod_setup_one(clocksource_hwmod_name); gpt = omap_dm_timer_request(); if (!gpt) Hemant-- 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] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
* Cousson, Benoit b-cous...@ti.com [110513 15:18]: Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Sounds like the important thing to consider here is how these macros should be set up considering the upcoming generic clock framework and device tree changes. So let's wait a few days for comments from Benoit and Paul on the format for the macros so we don't need to redo them again later. Of course there might be other things to consider too.. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
Tony Lindgren t...@atomide.com writes: * Cousson, Benoit b-cous...@ti.com [110513 15:18]: Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Sounds like the important thing to consider here is how these macros should be set up considering the upcoming generic clock framework and device tree changes. So let's wait a few days for comments from Benoit and Paul on the format for the macros so we don't need to redo them again later. Of course there might be other things to consider too.. ... like readability. After seeing the patch (thanks Benoit), I think this is bad tradeoff between readability and lines-of-code. Personally, I don't think we should be trading readability for diffstat goodness. I have a strong dislike for these multi-line macros, but it's up to Paul/Benoit to decide how this should look. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
* Kevin Hilman khil...@ti.com [110513 16:12]: Tony Lindgren t...@atomide.com writes: * Cousson, Benoit b-cous...@ti.com [110513 15:18]: Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Sounds like the important thing to consider here is how these macros should be set up considering the upcoming generic clock framework and device tree changes. So let's wait a few days for comments from Benoit and Paul on the format for the macros so we don't need to redo them again later. Of course there might be other things to consider too.. ... like readability. After seeing the patch (thanks Benoit), I think this is bad tradeoff between readability and lines-of-code. Personally, I don't think we should be trading readability for diffstat goodness. I have a strong dislike for these multi-line macros, but it's up to Paul/Benoit to decide how this should look. Despite having few hard-to-read multi-line macros, this can be used to make the actual data entries more readable. The same way as REGULATOR_SUPPLY, OMAP3_MUX, etc. 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: [PATCH] OMAP3: set the core dpll clk rate in its set_rate function.
* Paul Walmsley p...@pwsan.com [110513 05:13]: On Mon, 9 May 2011, Avinash.H.M wrote: The debug l3_ick/rate is not displaying the actual rate of the clock in hardware. This is because, the core dpll set_rate function doesn't update the clk.rate. After fixing, the l3_ick/rate is displaying proper values. Signed-off-by: Shweta Gulati shweta.gul...@ti.com Signed-off-by: Avinash.H.M avinas...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Paul Wamsley p...@pwsan.com Acked-by: Paul Walmsley p...@pwsan.com Thanks, let's see if we can get this into an -rc. Might be out of time as we still should have this sit in for-next too. Anyways, adding into devel-fixes. 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: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
On 5/13/2011 3:16 PM, Hilman, Kevin wrote: Tony Lindgrent...@atomide.com writes: * Cousson, Benoitb-cous...@ti.com [110513 15:18]: Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Sounds like the important thing to consider here is how these macros should be set up considering the upcoming generic clock framework and device tree changes. So let's wait a few days for comments from Benoit and Paul on the format for the macros so we don't need to redo them again later. Of course there might be other things to consider too.. ... like readability. After seeing the patch (thanks Benoit), I think this is bad tradeoff between readability and lines-of-code. Personally, I don't think we should be trading readability for diffstat goodness. I have a strong dislike for these multi-line macros, but it's up to Paul/Benoit to decide how this should look. I'm sharing the same concern and after seeing the patch, I do thing as well that the readability is badly impacted. My other concern is that these macros are too low level and does not bring a real abstraction of clock nodes. Any change to the clock structure we will have to do in the near future with the common clock fmwk will probably have an impact on this file. So if we want to reduce the file size using that kind of approach, we'd better provide improved macros that will help hiding some implementation details. It will ease the transition to the common clock fmwk. Last but not least, since we do want to move this file to DT ASAP, is it worth it? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: Remove support for omap2evm (Re: Updated mach-types update)
* Jarkko Nikula jhnik...@gmail.com [110513 05:15]:
On Fri, 13 May 2011 04:54:07 -0700
Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [110324 10:57]:
* Russell King - ARM Linux li...@arm.linux.org.uk [110320 04:39]:
On Sun, Mar 20, 2011 at 11:03:22AM +, Russell King - ARM Linux
wrote:
Note that OMAP references machine_is_omap2evm() yet this has never been
merged.
arch/arm/plat-omap/include/plat/uncompress.h:
DEBUG_LL_OMAP2(1, omap2evm);
so this entry needs to be removed.
Hmm looks like we have LCD support and ASoC support for it, but no
board :)
Anybody working with this board?
If so, please send patches for the related board-*.c support ASAP.
Otherwise let's plan on deleting the related support.
No patches, so let's remove it. Here's the patch to do that,
I'm planning to add this to my devel-cleanup branch.
Remove also from sound/soc/omap/Kconfig as well. You could put my
ack for sound/soc/omap part but remember cc also Mark and Liam.
Thanks, here's the updated patch.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 13 May 2011 04:41:32 -0700
Subject: [PATCH] omap: Remove support for omap2evm
The board support has never been merged for it as noticed
by Russell King li...@arm.linux.org.uk. So let's remove the
related dead code.
Cc: linux-fb...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood l...@ti.com
Cc: Paul Mundt let...@linux-sh.org
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
b/arch/arm/plat-omap/include/plat/uncompress.h
index 30b891c..2b576f1 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -129,7 +129,6 @@ static inline void __arch_decomp_setup(unsigned long
arch_id)
DEBUG_LL_OMAP1(3, sx1);
/* omap2 based boards using UART1 */
- DEBUG_LL_OMAP2(1, omap2evm);
DEBUG_LL_OMAP2(1, omap_2430sdp);
DEBUG_LL_OMAP2(1, omap_apollon);
DEBUG_LL_OMAP2(1, omap_h4);
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 49226a1..25db556 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -30,7 +30,6 @@ objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o
-objs-y$(CONFIG_MACH_OMAP2EVM) += lcd_omap2evm.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
diff --git a/drivers/video/omap/lcd_omap2evm.c
b/drivers/video/omap/lcd_omap2evm.c
deleted file mode 100644
index 7e7a65c..000
--- a/drivers/video/omap/lcd_omap2evm.c
+++ /dev/null
@@ -1,192 +0,0 @@
-/*
- * LCD panel support for the MISTRAL OMAP2EVM board
- *
- * Author: Arun C arunedar...@mistralsolutions.com
- *
- * Derived from drivers/video/omap/lcd_omap3evm.c
- * Derived from drivers/video/omap/lcd-apollon.c
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/gpio.h
-#include linux/i2c/twl.h
-
-#include plat/mux.h
-#include asm/mach-types.h
-
-#include omapfb.h
-
-#define LCD_PANEL_ENABLE_GPIO 154
-#define LCD_PANEL_LR 128
-#define LCD_PANEL_UD 129
-#define LCD_PANEL_INI 152
-#define LCD_PANEL_QVGA 148
-#define LCD_PANEL_RESB 153
-
-#define TWL_LED_LEDEN 0x00
-#define TWL_PWMA_PWMAON0x00
-#define TWL_PWMA_PWMAOFF 0x01
-
-static unsigned int bklight_level;
-
-static int omap2evm_panel_init(struct lcd_panel *panel,
- struct omapfb_device *fbdev)
-{
- gpio_request(LCD_PANEL_ENABLE_GPIO, LCD enable);
- gpio_request(LCD_PANEL_LR, LCD lr);
- gpio_request(LCD_PANEL_UD, LCD ud);
- gpio_request(LCD_PANEL_INI, LCD ini);
- gpio_request(LCD_PANEL_QVGA, LCD qvga);
-
Re: [PATCH v2 1/4] MFD: TWL6025: add phoenix lite support to twl6030
Hi Graeme, On Thu, May 12, 2011 at 02:27:55PM +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. Patch applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin Sent: Friday, May 13, 2011 6:46 PM To: Tony Lindgren Cc: Cousson, Benoit; Vladimir Zapolskiy; Paul Walmsley; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor. Tony Lindgren t...@atomide.com writes: * Cousson, Benoit b-cous...@ti.com [110513 15:18]: Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Sounds like the important thing to consider here is how these macros should be set up considering the upcoming generic clock framework and device tree changes. So let's wait a few days for comments from Benoit and Paul on the format for the macros so we don't need to redo them again later. Of course there might be other things to consider too.. ... like readability. After seeing the patch (thanks Benoit), I think this is bad tradeoff between readability and lines-of-code. Personally, I don't think we should be trading readability for diffstat goodness. I have a strong dislike for these multi-line macros, but it's up to Paul/Benoit to decide how this should look. [sp] Was the patch posted again? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] MFD: TWL6030: fix irq definitions
Hi Graeme On Thu, May 12, 2011 at 02:27:56PM +0100, Graeme Gregory wrote: 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. Thanks, patch applied as well. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: Updated mach-types update
On Fri, 2011-05-13 at 04:54 -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [110324 10:57]: * Russell King - ARM Linux li...@arm.linux.org.uk [110320 04:39]: On Sun, Mar 20, 2011 at 11:03:22AM +, Russell King - ARM Linux wrote: Note that OMAP references machine_is_omap2evm() yet this has never been merged. arch/arm/plat-omap/include/plat/uncompress.h: DEBUG_LL_OMAP2(1, omap2evm); so this entry needs to be removed. Hmm looks like we have LCD support and ASoC support for it, but no board :) Anybody working with this board? If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support. No patches, so let's remove it. Here's the patch to do that, I'm planning to add this to my devel-cleanup branch. For removing the lcd driver: Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
On 5/13/2011 4:48 PM, Premi, Sanjeev wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin Sent: Friday, May 13, 2011 6:46 PM To: Tony Lindgren Cc: Cousson, Benoit; Vladimir Zapolskiy; Paul Walmsley; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor. Tony Lindgrent...@atomide.com writes: * Cousson, Benoitb-cous...@ti.com [110513 15:18]: Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Sounds like the important thing to consider here is how these macros should be set up considering the upcoming generic clock framework and device tree changes. So let's wait a few days for comments from Benoit and Paul on the format for the macros so we don't need to redo them again later. Of course there might be other things to consider too.. ... like readability. After seeing the patch (thanks Benoit), I think this is bad tradeoff between readability and lines-of-code. Personally, I don't think we should be trading readability for diffstat goodness. I have a strong dislike for these multi-line macros, but it's up to Paul/Benoit to decide how this should look. [sp] Was the patch posted again? The patch size is 100k, so it will be rejected by most mailing list. I've just sent you the patch directly. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] perf: export power_start and power_end tracepoints
Adding l-o and linux-pm MLs. The original post is at http://www.spinics.net/lists/kernel/msg1186554.html On Fri, May 13, 2011 at 4:48 PM, Ingo Molnar mi...@elte.hu wrote: * jean.pi...@newoldbits.com jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com If used in a module both tracepoints need to be exported by the kernel. but it's not used by any module in the kernel AFAICS, so why is this needed? Not currently, that is why the error went unnoticed. I think it is better to fix it now than later. I am working on a plan to clean-up and isolate the OMAP PM code from the core code and to provide the PM functionality as a module. This effort is part of the 'remove the crazy ARM churn' from the kernel. Thanks, Jean Thanks, Ingo -- 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] arch/arm/mach-omap1/dma.c: Invert calls to platform_device_put and platform_device_del
From: Julia Lawall ju...@diku.dk
Platform_device_del should be called before platform_device_put, as
platform_device_put can delete the structure.
Additionally, improve the error handling code for the call to ioremap, so
that it calls platform_device_put.
The semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression e1,e2;
@@
*platform_device_put(e1);
... when != e1 = e2
*platform_device_del(e1);
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
Is an ioremap needed also? Not clear, because dma_base i a global variable.
arch/arm/mach-omap1/dma.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index d855934..f5a5220 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -284,14 +284,15 @@ static int __init omap1_system_dma_init(void)
dma_base = ioremap(res[0].start, resource_size(res[0]));
if (!dma_base) {
pr_err(%s: Unable to ioremap\n, __func__);
- return -ENODEV;
+ ret = -ENODEV;
+ goto exit_device_put;
}
ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
if (ret) {
dev_err(pdev-dev, %s: Unable to add resources for %s%d\n,
__func__, pdev-name, pdev-id);
- goto exit_device_del;
+ goto exit_device_put;
}
p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
@@ -299,7 +300,7 @@ static int __init omap1_system_dma_init(void)
dev_err(pdev-dev, %s: Unable to allocate 'p' for %s\n,
__func__, pdev-name);
ret = -ENOMEM;
- goto exit_device_put;
+ goto exit_device_del;
}
d = kzalloc(sizeof(struct omap_dma_dev_attr), GFP_KERNEL);
@@ -380,10 +381,10 @@ exit_release_d:
kfree(d);
exit_release_p:
kfree(p);
-exit_device_put:
- platform_device_put(pdev);
exit_device_del:
platform_device_del(pdev);
+exit_device_put:
+ platform_device_put(pdev);
return ret;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
On Fri, May 13, 2011 at 5:24 PM, Cousson, Benoit b-cous...@ti.com wrote: On 5/13/2011 3:16 PM, Hilman, Kevin wrote: Tony Lindgrent...@atomide.com writes: * Cousson, Benoitb-cous...@ti.com [110513 15:18]: Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Sounds like the important thing to consider here is how these macros should be set up considering the upcoming generic clock framework and device tree changes. So let's wait a few days for comments from Benoit and Paul on the format for the macros so we don't need to redo them again later. Of course there might be other things to consider too.. ... like readability. After seeing the patch (thanks Benoit), I think this is bad tradeoff between readability and lines-of-code. Personally, I don't think we should be trading readability for diffstat goodness. I have a strong dislike for these multi-line macros, but it's up to Paul/Benoit to decide how this should look. I'm sharing the same concern and after seeing the patch, I do thing as well that the readability is badly impacted. There always shall be a price, from my side I've tried to lessen it as much as possible. My other concern is that these macros are too low level and does not bring a real abstraction of clock nodes. Any change to the clock structure we will have to do in the near future with the common clock fmwk will probably have an impact on this file. Right, but without this change the impact won't be less. In the best case later for structural changes it might be simpler and less error-prone to modify one macro definition instead of hundreds LOCs. So if we want to reduce the file size using that kind of approach, we'd better provide improved macros that will help hiding some implementation details. It will ease the transition to the common clock fmwk. Certainly I'd be glad to get any recommendations about potential improvement in the change, but for that case I've found quite efficient to exploit C preprocessor for potential removing thousands LOCs without a semantic loss or even change. A word about my motivation, I'm just willing to reduce arch/arm/* overall size to approach productive ARM/Linux development and integration again. At the moment `du -sb arch/arm/* | sort -n | tail -n1` gives me mach-omap2 as the best candidate to spend some free time with. And that change was such an attempt, hopefully not completely fruitless and not the last one :) Last but not least, since we do want to move this file to DT ASAP, is it worth it? With best wishes, Vladimir -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] OMAP: twl4030-power: In remove script check the error condition after i2cwrite
Hi Lesly, On Wed, May 04, 2011 at 05:38:53PM +0530, Lesly Arackal Manuel wrote: From: Lesly A M lesl...@ti.com Fixing the error condition check in twl4030 remove script function. Due to some typo in commit ID: 11a441ce82d6ffecfd39b324024de0cd630b36c1 Thanks, patch applied. Cheers, Samuel -- Intel Open Source Technology Centre http://oss.intel.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 v10 1/7] MFD: TWL4030: Fix for the TWL4030 sleep/wakeup sequence
Hi Lesly, On Fri, May 06, 2011 at 06:47:07PM +0530, Lesly A M wrote: Only configure sleep script when the flag is TWL4030_SLEEP_SCRIPT. Adding the missing brackets for fixing the issue. This is already upstream. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 v10 2/7] MFD: TWL4030: Correct the warning print during script loading
Hi Lesly, On Fri, May 06, 2011 at 06:47:08PM +0530, Lesly A M wrote: Correcting the if condition check for printing the warning, if wakeup script is not updated before updating the sleep script. Since the flag 'order' is set to '1' while updating the wakeup script for P1P2, the condition checking for printing the warning should be if(!order) (ie: print the warning if wakeup script is not updated before updating the sleep script) This one is already applied to my for-next. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 v10 3/7] MFD: TWL4030: Modifying the macro name Main_Ref to all caps
Hi Lesly, On Fri, May 06, 2011 at 06:47:09PM +0530, Lesly A M wrote: Modifying the macro name Main_Ref to all caps(MAIN_REF). This one is already on my for-next branch. I'll update the Changelog accordingly. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 v10 5/7] MFD: TWL4030: TWL version checking
Hi Lesly, On Fri, May 06, 2011 at 06:47:11PM +0530, Lesly A M wrote: Added API to get the TWL5030 Si version from the IDCODE register. It is used for enabling the workaround for TWL erratum 27. This one is also already applied. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 v2] MFD: twl4030-codec: Update e-mail address
Hi Peter, On Tue, May 10, 2011 at 08:59:23AM +0300, Peter Ujfalusi wrote: Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Patch applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 v10 4/7] MFD: TWL4030: power scripts for OMAP3 boards
Hi Lesly, On Fri, May 06, 2011 at 06:47:10PM +0530, Lesly A M wrote: Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset. TWL4030 power scripts which can be used by different OMAP3 boards with the power companion chip (TWL4030 series). The twl4030 generic script can be used by any board file to update the power data in twl4030_platform_data. Since the TWL4030 power script has dependency with APIs in twl4030-power.c removing the __init for these APIs. For more information please see: http://omapedia.org/wiki/TWL4030_power_scripts I understand you guys are trying to keep the arch/arm stats to a sane level, but I don't see why this driver should be under drivers/mfd/. I'm usually flexible about what goes into drivers/mfd, but this one seems out of context to me. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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
[PM-WIP_CPUFREQ][PATCH 0/5] Cleanups for cpufreq
Hi, a few cleanups for cpufreq to include a couple of bugfixes we found as part of dvfs testing and code review. Testing done: OMAP4SDP4430 - I think the only major platform would be omap2 - but I doubt it was functional previously - if someone has a chance to give it a whirl, please do, as I dont have access to an OMAP2 platform atm :(. Applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git branch: pm-wip/cpufreq Nishanth Menon (5): OMAP2+: cpufreq: free up table on exit OMAP2+: cpufreq: handle invalid cpufreq table OMAP2+: cpufreq: minor comment cleanup OMAP2: cpufreq: use clk_init_cpufreq_table if OPPs not available OMAP2+: cpufreq: use cpufreq_frequency_table_target arch/arm/mach-omap2/omap2plus-cpufreq.c | 56 +-- 1 files changed, 45 insertions(+), 11 deletions(-) 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
[PM-WIP-CPUFREQ][PATCH 1/5] OMAP2+: cpufreq: free up table on exit
freq_table allocated by opp_init_cpufreq_table in omap_cpu_init
needs to be freed in omap_cpu_exit.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index d53ce23..e38ebb8 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -26,6 +26,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/opp.h
+#include linux/slab.h
#include linux/cpu.h
#include asm/system.h
@@ -216,6 +217,8 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
clk_exit_cpufreq_table(freq_table);
+ kfree(freq_table);
+ freq_table = NULL;
clk_put(mpu_clk);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP-CPUFREQ][PATCH 4/5] OMAP2: cpufreq: use clk_init_cpufreq_table if OPPs not available
OMAP2 does not use OPP tables at the moment for DVFS. Currently,
we depend on opp table initialization to give us the freq_table,
which makes sense for OMAP3+. for OMAP2, we should be using
clk_init_cpufreq_table - so if the opp based frequency table
initilization fails, fall back to clk_init_cpufreq_table to give
us the table.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 45f1e9e..854f4b3 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -180,7 +180,13 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
pr_warning(%s: unable to get the mpu device\n, __func__);
return -EINVAL;
}
- opp_init_cpufreq_table(mpu_dev, freq_table);
+
+ /*
+* if we dont get cpufreq table using opp, use traditional omap2 lookup
+* as a fallback
+*/
+ if (opp_init_cpufreq_table(mpu_dev, freq_table))
+ clk_init_cpufreq_table(freq_table);
if (freq_table) {
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
@@ -188,6 +194,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
cpufreq_frequency_table_get_attr(freq_table,
policy-cpu);
} else {
+ clk_exit_cpufreq_table(freq_table);
WARN(true, %s: fallback to clk_round(freq_table=%d)\n,
__func__, result);
kfree(freq_table);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP-CPUFREQ][PATCH 3/5] OMAP2+: cpufreq: minor comment cleanup
this should probably get squashed in.. Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/omap2plus-cpufreq.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c index 6e3666a..45f1e9e 100644 --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c @@ -84,8 +84,10 @@ static int omap_target(struct cpufreq_policy *policy, if (is_smp() (num_online_cpus() NR_CPUS)) return ret; - /* Ensure desired rate is within allowed range. Some govenors -* (ondemand) will just pass target_freq=0 to get the minimum. */ + /* +* Ensure desired rate is within allowed range. Some govenors +* (ondemand) will just pass target_freq=0 to get the minimum. +*/ if (target_freq policy-min) target_freq = policy-min; if (target_freq policy-max) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP-CPUFREQ][PATCH 5/5] OMAP2+: cpufreq: use cpufreq_frequency_table_target
Use cpufreq_frequency_table_target for finding the proper target
instead of seeing if the frequency requested is divisible alone.
if we have a frequency table, we should restrict ourselves to
selecting the approved frequencies alone and only in the case
where the frequency table is not available should we attempt at
closest roundable clock frequency.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 34 +-
1 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 854f4b3..688c5bc 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -77,24 +77,38 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
- int i, ret = 0;
+ unsigned int i;
+ int ret = 0;
struct cpufreq_freqs freqs;
/* Changes not allowed until all CPUs are online */
if (is_smp() (num_online_cpus() NR_CPUS))
return ret;
- /*
-* Ensure desired rate is within allowed range. Some govenors
-* (ondemand) will just pass target_freq=0 to get the minimum.
-*/
- if (target_freq policy-min)
- target_freq = policy-min;
- if (target_freq policy-max)
- target_freq = policy-max;
+ if (freq_table) {
+ cpufreq_frequency_table_target(policy, freq_table, target_freq,
+ relation, i);
+ freqs.new = freq_table[i].frequency;
+ } else {
+ /*
+* Ensure desired rate is within allowed range. Some govenors
+* (ondemand) will just pass target_freq=0 to get the minimum.
+*/
+ if (target_freq policy-min)
+ target_freq = policy-min;
+ if (target_freq policy-max)
+ target_freq = policy-max;
+
+ freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
+ }
+ if (!freqs.new) {
+ for_each_cpu(i, policy-cpus)
+ pr_err(%s:cpu%d no match for freq %d\n, __func__,
+ i, target_freq);
+ return -EINVAL;
+ }
freqs.old = omap_getspeed(policy-cpu);
- freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
freqs.cpu = policy-cpu;
if (freqs.old == freqs.new)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP-CPUFREQ][PATCH 2/5] OMAP2+: cpufreq: handle invalid cpufreq table
Handle the case when cpufreq_frequency_table_cpuinfo fails. freq_table
that we passed failed the internal test of cpufreq generic driver,
so we should'nt be using the freq_table as such. Instead, warn and
fallback to clock functions for validation and operation.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index e38ebb8..6e3666a 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -182,10 +182,18 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
if (freq_table) {
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
- if (!result)
+ if (!result) {
cpufreq_frequency_table_get_attr(freq_table,
policy-cpu);
- } else {
+ } else {
+ WARN(true, %s: fallback to clk_round(freq_table=%d)\n,
+ __func__, result);
+ kfree(freq_table);
+ freq_table = NULL;
+ }
+ }
+
+ if (!freq_table) {
policy-cpuinfo.min_freq = clk_round_rate(mpu_clk, 0) / 1000;
policy-cpuinfo.max_freq = clk_round_rate(mpu_clk,
VERY_HI_RATE) / 1000;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagleboardxm 2.6.39rc4 mcbsp problems.
On Thu, May 12, 2011 at 10:59 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On Thursday 12 May 2011 21:43:20 Steve Calfee wrote: Since it is set to 0xF0F, doesn't this set it as master? Sorry, that is correct, McBSP is configured as msater. Also, spelunking the kernel sources, I cannot seem to find the source for mcbsp_data-regs -- do you know where it gets set initially? They configured within sound/soc/omap/omap-pcm.c Have you configured the clk source, and divider correctly for McBSP port from the machine driver (with snd_soc_dai_set_sysclk)? Hi, Thanks for the suggestions. I think I have it correct. I was able to load the original sound/soc/beagleboard.c and the codec/twl4030 and play a wav file. I have been copying that to try and get my new codec driver to work. One immediate difference is that the system sets up the twl4030 as the master i2s device on the bus. So I changed my codec over to do that too. Now the mcbsp register dump matches the working setup. I put in a few debug statements. It appears that my DMA never gets started. I know it can work with a different machine and codec driver, but not mine. I don't see any explicit DMA init, but that must be the problem. Any more ideas? Thanks, Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
