[PATCHv5] omap3: Add basic support for 720MHz part
This patch adds support for speed enhanced variant of OMAP35x
processors. These parts allow ARM and IVA running at 720MHz
and 520MHz respectively.
These parts can be detected at runtime by reading contents of
PRODID.SKUID[3:0] at 0x4830A20C [1].
This patch specifically does following:
* Add new OPP to omap34xx_opp_def_list[] - disabled by default.
* Detect devices capable of running at new OPP.
* Enable new OPP only if device supports it.
* Check for presence of IVA before attempting to enable the
corresponding OPP.
[1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
It appears from discussions (on this patch) that a variant of
OMAP3430 supports this OPP but lacks runtime detection. This
OPP can be enabled for these device by either:
1) Setting the bit corresponding to OMAP3_HAS_720MHZ
in 'omap3_features'. (Refer changes to id.c)
2) Removing check for omap3_has_720mhz() before enabling
the OPP. (Refer changes to opp3xxx_data.c)
3) Calling opp_enable() for 720MHz/VDD1 and 520MHz/VDD2 in
the board file. (Refer changes to opp3xxx_data.c).
This should, ideally, be done before omap3_opp_init() is
called during device_initcall().
CAUTION: This should be done for identified parts only.
Else, the device could be damaged permanently.
Signed-off-by: Sanjeev Premi pr...@ti.com
Reviewed-by: G, Manjunath Kondaiah manj...@ti.com
---
Since v4:
Updated the commit text addressing comments from
Kevin Hilman (khil...@ti.com).
Since v3:
1) Minor changes to comments and braces.
Since v2:
1) pr_xxx() - dev_xxx() functions - suggested by
Manjunath (manj...@ti.com)
2) Add check for presense of IVA - earlier planned to
be in a separate patch; but we multiple discussions
on optimizations.
3) Do look-up for hwmod corresponding for iva only if
iva is present. Should save multiple strcmp()s in
_lookup().
Since v1:
1) Using opp_enable() to enable the OPP after the OPP
table has been initialized.
2) Starting at 3 levels of indent, the statements had
be broken into multiple lines for most of the code.
So, opted to create a new static that enables the
OPPs corresponding to 720MHz.
3) I have only build tested this patch - will be able
to confirm working tomorrow. With any further change,
if needed. (However, functionally nothing has changed.)
arch/arm/mach-omap2/control.h |6 +++
arch/arm/mach-omap2/id.c |5 +++
arch/arm/mach-omap2/opp3xxx_data.c| 63 -
arch/arm/plat-omap/include/plat/cpu.h |2 +
4 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f0629ae..c338466 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -365,6 +365,12 @@
#defineFEAT_NEON 0
#defineFEAT_NEON_NONE 1
+/* Product ID register */
+#define OMAP3_PRODID 0x020C
+
+/* Mask to extract SKU ID from Product ID */
+#define OMAP3_SKUID_MASK 0x0f
+#defineOMAP3_SKUID_720MHZ 0x08
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..8c4500f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -191,6 +191,10 @@ static void __init omap3_check_features(void)
if (!cpu_is_omap3505() !cpu_is_omap3517())
omap3_features |= OMAP3_HAS_IO_WAKEUP;
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+ if (status OMAP3_SKUID_720MHZ)
+ omap3_features |= OMAP3_HAS_720MHZ;
+
/*
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
@@ -445,6 +449,7 @@ static void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
OMAP3_SHOW_FEATURE(192mhz_clk);
+ OMAP3_SHOW_FEATURE(720mhz);
printk()\n);
}
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index 0486fce..cba17f7 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -17,8 +17,10 @@
* GNU General Public License for more details.
*/
#include linux/module.h
+#include linux/opp.h
#include plat/cpu.h
+#include plat/omap_device.h
#include omap_opp_data.h
@@ -33,6 +35,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(mpu, true, 55000, 127),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, 135),
+ /* MPU OPP6 */
+ OPP_INITIALIZER(mpu, false, 72000, 135),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -58,6 +62,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(iva, true, 4, 127),
/* DSP OPP5 */
Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
On Wed, Feb 9, 2011 at 6:04 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Wednesday, February 09, 2011 6:06 AM To: Nicolas Pitre Cc: Santosh Shilimkar; Russell King - ARM Linux; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels * Nicolas Pitre n...@fluxnic.net [110208 12:41]: On Tue, 8 Feb 2011, Santosh Shilimkar wrote: I think it's probably going to be better to _purposely_ break the OMAP build when it covers v6 and v7 CPUs in these kernels as I don't think it's sanely fixable given where we are. Agreed. At least making SMP unavailable when both v6 and v7 are configured should be small and good enough for 2.6.38-rc5. That's probably the best solution as then we can still do boot testing on all omap2plus_defconfig boards. Just to be clear, are we saying disable SMP from omap2plus build. If the v6, v7 is not fixable then, we also need a SMP config for OMAP. Just boot test with SMP disable config for OMAP4 is not enough. You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. Cheers ---Dave -- 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 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Wed, Feb 9, 2011 at 5:45 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Tuesday, February 08, 2011 11:11 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; Jean Pihet- XID; linux-omap@vger.kernel.org; Nicolas Pitre Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes Hi Santosh, [...] I'm still having problems testing basic power management... I'm using this config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config ... and Kevin's pm tree with my patches on top. However, even building without CONFIG_THUMB2_KERNEL, Beagle xM doesn't seem to suspend properly: Linux xm-1 2.6.38-rc2+ #19 SMP Tue Feb 8 14:02:24 GMT 2011 armv7l GNU/Linux # # [ 302.446228] SysRq : Changing Loglevel [ 302.449951] Loglevel set to 9 echo mem /sys/power/state [1] 545 # [ 306.525177] PM: Syncing filesystems ... done. [ 308.989715] mmc0: card 1234 removed # # # # # # jobs [1]+ Running echo mem /sys/power/state # The SD card gets suspended, but nothing else seems to happen, and I can't resume the system. Am I doing something wrong? MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing Ah, right -- I'll try without MMC. Thanks ---Dave -- 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 00/14] Fix issues with ARMv6+v6k+v7 kernels
-Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Wednesday, February 09, 2011 3:18 PM To: Santosh Shilimkar Cc: Tony Lindgren; Nicolas Pitre; linux-omap@vger.kernel.org; Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels On Wed, Feb 9, 2011 at 6:04 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Wednesday, February 09, 2011 6:06 AM To: Nicolas Pitre Cc: Santosh Shilimkar; Russell King - ARM Linux; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels * Nicolas Pitre n...@fluxnic.net [110208 12:41]: On Tue, 8 Feb 2011, Santosh Shilimkar wrote: I think it's probably going to be better to _purposely_ break the OMAP build when it covers v6 and v7 CPUs in these kernels as I don't think it's sanely fixable given where we are. Agreed. At least making SMP unavailable when both v6 and v7 are configured should be small and good enough for 2.6.38-rc5. That's probably the best solution as then we can still do boot testing on all omap2plus_defconfig boards. Just to be clear, are we saying disable SMP from omap2plus build. If the v6, v7 is not fixable then, we also need a SMP config for OMAP. Just boot test with SMP disable config for OMAP4 is not enough. You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. This sounds good way forward considering future OMAP architectures as well. But I let Tony comment on this idea. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
On 8 February 2011 16:47, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote: Have tested this series on OMAP4430 and OMAP3430. Don't know if it helps to push some of these patches to be part of rc cycles. At least the SMP specific fixes should get merged otherwise, builds like omap2plus_defconfig won't be running right configuration on SMP machine. It's _too_ _late_ in the rc cycle for a fix of this size. As I've said (several times) it was only possible for rc1. That boat has been missed as we're now on rc4. We could see 2.6.38 in as little as two weeks time. 27 files changed, 183 insertions(+), 197 deletions(-) is too big. There's still the outstanding question over: ARM: v6k: use CPU domain feature if we include support for arch ARMv6K Could we make the domains usage a run-time feature based on the architecture version? For ARMv7, we need to have the vectors page read-only anyway if the SWP emulation is enabled (and I posted a simple patch in a reply to your email). The issue I see is that ARM11MPCore is reported as v7 though we still use domains on this processor (we could always remove the domains if TLS register is available or use some more precise architecture version identification). -- Catalin -- 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] ARM: Define wfi() macro for v6 processors
On Tuesday 08 February 2011, Dave Martin wrote: I have a (possibly silly) question ... are the definitions in arm/system.h intended to be fully generic, or not? Some features suggest an attempt at genericness, but not everything there is generic. Maybe I have misconstrued the purpose of this header. asm/system.h contains an ill-defined set of random stuff derived from what used to be in there in the old days Linux-1.x and whatever the individual architectures added to it. There have been previous attempts to reduce the common stuff and leave only architecture-specific definitions in there, but it still contains for all architectures at least: * switch_to() * mb() and friends * cmpxchg() and friends These are hard to change, because each architecture has slightly different rules for recursive header file inclusion, so you end up breaking stuff when you touch them. The other declarations and macros are arch specific, so we could move them to a different place or change them if there is a good reason to do that. I personally think it would be good to have at least cmpxchg and everything related to it in a separate header, like a few architectures do (x86, sh, alpha, mips), but I don't see too much value in doing that just on ARM while leaving the other architectures alone. Arnd -- 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/2] omap3: beaglexm: fix DVI initialization
On Wed, 2011-02-09 at 12:23 +0530, G, Manjunath Kondaiah wrote: On Wed, Feb 9, 2011 at 1:13 AM, Ricardo Salveti de Araujo ricardo.salv...@canonical.com wrote: Function beagle_twl_gpio_setup is called after beagle_display_init, what lets reset_gpio with an invalid value at the time it request the gpio. As a side effect the DVI reset GPIO is not properly set. Also removing old code that powers down DVI in a hardcoded way, as it's not necessary anymore. Tested with Beagle-xM and C4. Surprised to see if this code works on C4 since there is gpio_request for gpio_170 in the beagle init code (linux omap master branch) which is before beagle_display_init() omap_mux_init_gpio(170, OMAP_PIN_INPUT); gpio_request(170, DVI_nPD); /* REVISIT leave DVI powered down until it's needed ... */ gpio_direction_output(170, true); The second gpio_request(for 170) should fail in beagle_display_init. Pls check and confirm. That's why this part is also removed at my patch. Cheers, -- Ricardo Salveti de Araujo -- 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/2] omap3: beaglexm: fix DVI initialization
On Wed, Feb 9, 2011 at 5:17 PM, Ricardo Salveti de Araujo ricardo.salv...@canonical.com wrote: On Wed, 2011-02-09 at 12:23 +0530, G, Manjunath Kondaiah wrote: On Wed, Feb 9, 2011 at 1:13 AM, Ricardo Salveti de Araujo ricardo.salv...@canonical.com wrote: Function beagle_twl_gpio_setup is called after beagle_display_init, what lets reset_gpio with an invalid value at the time it request the gpio. As a side effect the DVI reset GPIO is not properly set. Also removing old code that powers down DVI in a hardcoded way, as it's not necessary anymore. Tested with Beagle-xM and C4. Surprised to see if this code works on C4 since there is gpio_request for gpio_170 in the beagle init code (linux omap master branch) which is before beagle_display_init() omap_mux_init_gpio(170, OMAP_PIN_INPUT); gpio_request(170, DVI_nPD); /* REVISIT leave DVI powered down until it's needed ... */ gpio_direction_output(170, true); The second gpio_request(for 170) should fail in beagle_display_init. Pls check and confirm. That's why this part is also removed at my patch. Thanks. Changes looks fine. Reviewed-by: Manjunath G Kondaiah manj...@ti.com -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP4: PandaBoard: Adding DVI support
Adding DVI support to OMAP4 PandaBoard.
PandaBoard uses TFP410 DVI Framer chip
http://focus.ti.com/lit/ds/symlink/tfp410.pdf
The TFP410 gets its power enable and display data over GPIO lines muxed
in from OMAP4430. PandaBoard supports other LCD displays through expansion
connectors, following board rework. This will disable the DVI interface.
However, the existing mux settings remain the same
PandaBoard additionally supports display over HDMI interface. It is
mutually exclusive to display over DVI. Hence the mux settings need to be
configured seperately, as and when HDMI is enabled
Also, I2C3 bus used for reading EDID data from DVI Monitors is
registered here. Since the design is similar to BeagleBoard, the code
for the same is taken from the kernel.org commit ef48dd5cb21
(omap: Adding beagle i2c eeprom driver to read EDID)
Reviewed-by: Manjunath G Kondaiah manj...@ti.com
Reviewed-by: Anand Gadiyar gadi...@ti.com
Reviewed-by: Nishanth Menon n...@ti.com
Reviewed-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com
---
Base
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
branch master
commit 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d
tag 2.6.38-rc4
Applies over:
=
1.
v10 of OMAP2,3 DSS2 HWMOD
https://patchwork.kernel.org/patch/500191/
2.
v3 of DSS2: Generalize clock names
https://patchwork.kernel.org/patch/520191/
3.
v3 of DSS2: OMAP4 DSS HWMOD :
https://patchwork.kernel.org/patch/511211/
4.
OMAP: DSS2: Common IRQ handler for all OMAPs
https://patchwork.kernel.org/patch/526241/
5.
OMAP4: DSS2: Adding fclk support for DPI interface
https://patchwork.kernel.org/patch/529381/
6.
OMAP: DSS2: Adding dss_features for independent core clk divider
https://patchwork.kernel.org/patch/529561/
=
arch/arm/mach-omap2/board-omap4panda.c | 137 +++-
1 files changed, 136 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index e944025..b09d239 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -37,6 +37,7 @@
#include plat/common.h
#include plat/usb.h
#include plat/mmc.h
+#include plat/panel-generic-dpi.h
#include timer-gp.h
#include hsmmc.h
@@ -76,6 +77,60 @@ static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
};
+/* Display DVI */
+#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
+
+static int panda_enable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dssdev-reset_gpio, 1);
+ return 0;
+}
+
+static void panda_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dssdev-reset_gpio, 0);
+}
+
+/* Using generic display panel */
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= panda_enable_dvi,
+ .platform_disable = panda_disable_dvi,
+};
+
+struct omap_dss_device panda_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = dvi,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
+ .phy.dpi.data_lines = 24,
+ .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
+ .channel= OMAP_DSS_CHANNEL_LCD2,
+};
+
+int __init panda_dvi_init(void)
+{
+ int r;
+
+ /* Requesting TFP410 DVI GPIO and disabling it, at bootup */
+ r = gpio_request_one(panda_dvi_device.reset_gpio,
+ GPIOF_OUT_INIT_LOW, DVI PD);
+ if (r)
+ pr_err(Failed to get DVI powerdown GPIO\n);
+
+ return r;
+}
+
+static struct omap_dss_device *panda_dss_devices[] = {
+ panda_dvi_device,
+};
+
+static struct omap_dss_board_info panda_dss_data = {
+ .num_devices= ARRAY_SIZE(panda_dss_devices),
+ .devices= panda_dss_devices,
+ .default_device = panda_dvi_device,
+};
+
static void __init omap4_panda_init_irq(void)
{
omap2_init_common_infrastructure();
@@ -375,6 +430,17 @@ static struct i2c_board_info __initdata
omap4_panda_i2c_boardinfo[] = {
.platform_data = omap4_panda_twldata,
},
};
+
+/*
+ * Display monitor features are burnt in their EEPROM as EDID data. The EEPROM
+ * is connected as I2C slave device, and can be accessed at address 0x50
+ */
+static struct i2c_board_info __initdata panda_i2c_eeprom[] = {
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
+};
+
static int __init omap4_panda_i2c_init(void)
{
/*
@@ -384,13 +450,76 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(1, 400, omap4_panda_i2c_boardinfo,
ARRAY_SIZE(omap4_panda_i2c_boardinfo));
omap_register_i2c_bus(2, 400, NULL, 0);
- omap_register_i2c_bus(3, 400,
Re: [PATCH] OMAP4: PandaBoard: Adding DVI support
On Wed, Feb 9, 2011 at 7:25 PM, Raghuveer Murthy raghuveer.mur...@ti.com wrote: Adding DVI support to OMAP4 PandaBoard. PandaBoard uses TFP410 DVI Framer chip http://focus.ti.com/lit/ds/symlink/tfp410.pdf The TFP410 gets its power enable and display data over GPIO lines muxed in from OMAP4430. PandaBoard supports other LCD displays through expansion connectors, following board rework. This will disable the DVI interface. However, the existing mux settings remain the same PandaBoard additionally supports display over HDMI interface. It is mutually exclusive to display over DVI. Hence the mux settings need to be configured seperately, as and when HDMI is enabled Also, I2C3 bus used for reading EDID data from DVI Monitors is registered here. Since the design is similar to BeagleBoard, the code for the same is taken from the kernel.org commit ef48dd5cb21 (omap: Adding beagle i2c eeprom driver to read EDID) Reviewed-by: Manjunath G Kondaiah manj...@ti.com Reviewed-by: Anand Gadiyar gadi...@ti.com I've also tested it on the Panda, and gone through this and most of the other patches in the series. So if you like, you could consider this an: Acked-by: Anand Gadiyar gadi...@ti.com Reviewed-by: Nishanth Menon n...@ti.com Reviewed-by: Sumit Semwal sumit.sem...@ti.com Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com --- Base url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git branch master commit 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d tag 2.6.38-rc4 To make it easier for someone to test, I've extracted this and the 6 dependent series from patchwork, and hosted them in a branch on my devel tree. They are available against v2.6.38-rc4 here: git://dev.omapzoom.org/pub/scm/anand/linux-omap-usb.git in the display-patches-for-v2.6.38-rc4 branch if someone wants to take a look. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
On Wed, Jan 26, 2011 at 05:25:35PM +, Dave P. Martin wrote: SMP_ON_UP fixups lead to vmlinux link errors if those sections are discarded at link-time. In particular this may happen for built-in __exit stuff. This patch modifies the vmlinux linker script to reduce the amount of discarded sections, and tries to make sure that __exit sections are kept in. This is a hack and probably wrong! Further discussion is needed. Can you send the configuration which you see this problem with? I've tried to build a kernel which inlines the spinlocks, but I find that's not possible, so I'm doubting whether any fix is required for mainline. -- 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 v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. This patch set builds on recent cleanup done by the omap maintainers. All affected low-level code is now built in Thumb-2. At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome. Seems to work with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled on Beagle xM A2 and Panda A1. Thanks also to Santosh Shilimkar santosh.shilim...@ti.com for his help with testing. v3: * make SMC instruction syntax more consistent * remove do_wfi() in favour of the generic wfi() macro v4: * revert to the OMAP-specific do_wfi() implementation, pending discussion of how generic macros can/should be provided Details below. Cheers, Dave The patches can be found, along with a buildable working tree, in the following repo: git://git.linaro.org/people/dmart/linux-2.6-arm.git * arm/omap-thumb2: has the patches proposed here * arm/omap-thumb2+merged: additionally has some patches cherry- picked from other trees which are needed in order for the patches on arm/omap-thumb2 to work usefully. * dirty/arm/omap-thumb2+merged: buildable test tree, which adds 2 local patches to work around a toolchain bug. A working kernel config for this tree is here: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config : CONFIG_SMP_ON_UP=y CONFIG_THUMB2_KERNEL=y CONFIG_SERIAL_OMAP=n (to avoid garbage on xM; for Panda use console=ttyS2) (The config is derived from the linaro omap config and so turns on loads of modules -- don't feel you have to build them all...) Cherry-picked patches originated from Russell's devel tree and Tony Lindgren's omap-testing tree: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing This series also depends on one un-merged patch to generic-ise the wfi() macro: git://git.linaro.org/people/dmart/linux-2.6-arm.git arm/wfi-macro Dave Martin (5): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Thumb-2 compatibility for sram34xx.S ARM: omap3: Thumb-2 compatibility for sleep34xx.S arch/arm/mach-omap2/include/mach/omap4-common.h |4 ++ arch/arm/mach-omap2/omap-headsmp.S |2 +- arch/arm/mach-omap2/omap44xx-smc.S |8 ++-- arch/arm/mach-omap2/sleep34xx.S | 56 --- arch/arm/mach-omap2/sram34xx.S | 28 --- 5 files changed, 68 insertions(+), 30 deletions(-) -- 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 v4 1/5] ARM: omap4: Provide do_wfi() for Thumb-2
For CONFIG_THUMB2_KERNEL, the existing definition of do_wfi() will insert invalid code into the instruction stream. Any assembler which can assemble Thumb-2 is guaranteed to accept the wfi mnemonic, so for the Thumb-2 case, just use the mnemonic. The ARM case is left as-is. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/mach-omap2/include/mach/omap4-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h index 5b0270b..de441c0 100644 --- a/arch/arm/mach-omap2/include/mach/omap4-common.h +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h @@ -17,8 +17,12 @@ * wfi used in low power code. Directly opcode is used instead * of instruction to avoid mulit-omap build break */ +#ifdef CONFIG_THUMB2_KERNEL +#define do_wfi() __asm__ __volatile__ (wfi : : : memory) +#else #define do_wfi() \ __asm__ __volatile__ (.word0xe320f003 : : : memory) +#endif #ifdef CONFIG_CACHE_L2X0 extern void __iomem *l2cache_base; -- 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
[PATCH v4 3/5] ARM: omap3: Remove hand-encoded SMC instructions
For various reasons, Linux now only officially supports being built with tools which are new enough to understand the SMC instruction. Replacing the hand-encoded instructions when the mnemonic also allows for correct assembly in Thumb-2 (otherwise, the result is random data in the middle of the code). The Makefile already ensures that this file is built with a high enough gcc -march= flag (armv7-a). Signed-off-by: Dave Martin dave.mar...@linaro.org Tested-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/sleep34xx.S | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 98d8232..a05c348 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -133,7 +133,7 @@ ENTRY(save_secure_ram_context) mov r6, #0xff mcr p15, 0, r0, c7, c10, 4 @ data write barrier mcr p15, 0, r0, c7, c10, 5 @ data memory barrier - .word 0xE1600071 @ call SMI monitor (smi #1) + smc #1 @ call SMI monitor (smi #1) nop nop nop @@ -408,7 +408,7 @@ skipl2dis: adr r3, l2_inv_api_params @ r3 points to dummy parameters mcr p15, 0, r0, c7, c10, 4 @ data write barrier mcr p15, 0, r0, c7, c10, 5 @ data memory barrier - .word 0xE1600071 @ call SMI monitor (smi #1) + smc #1 @ call SMI monitor (smi #1) /* Write to Aux control register to set some bits */ mov r0, #42 @ set service ID for PPA mov r12, r0 @ copy secure Service ID in r12 @@ -419,7 +419,7 @@ skipl2dis: ldr r3, [r4, #0xBC] @ r3 points to parameters mcr p15, 0, r0, c7, c10, 4 @ data write barrier mcr p15, 0, r0, c7, c10, 5 @ data memory barrier - .word 0xE1600071 @ call SMI monitor (smi #1) + smc #1 @ call SMI monitor (smi #1) #ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE /* Restore L2 aux control register */ @@ -434,7 +434,7 @@ skipl2dis: addsr3, r3, #8 @ r3 points to parameters mcr p15, 0, r0, c7, c10, 4 @ data write barrier mcr p15, 0, r0, c7, c10, 5 @ data memory barrier - .word 0xE1600071 @ call SMI monitor (smi #1) + smc #1 @ call SMI monitor (smi #1) #endif b logic_l1_restore @@ -443,18 +443,18 @@ l2_inv_api_params: l2_inv_gp: /* Execute smi to invalidate L2 cache */ mov r12, #0x1 @ set up to invalidate L2 - .word 0xE1600070@ Call SMI monitor (smieq) + smc #0 @ Call SMI monitor (smieq) /* Write to Aux control register to set some bits */ ldr r4, scratchpad_base ldr r3, [r4,#0xBC] ldr r0, [r3,#4] mov r12, #0x3 - .word 0xE1600070 @ Call SMI monitor (smieq) + smc #0 @ Call SMI monitor (smieq) ldr r4, scratchpad_base ldr r3, [r4,#0xBC] ldr r0, [r3,#12] mov r12, #0x2 - .word 0xE1600070 @ Call SMI monitor (smieq) + smc #0 @ Call SMI monitor (smieq) logic_l1_restore: ldr r1, l2dis_3630 cmp r1, #0x1@ Test if L2 re-enable needed on 3630 -- 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
[PATCH v4 4/5] ARM: omap3: Thumb-2 compatibility for sram34xx.S
* Remove deprecated/undefined PC-relative stores * Add the required ENDPROC() directive for each ENTRY(). * .align before data words Signed-off-by: Dave Martin dave.mar...@linaro.org Tested-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/sram34xx.S | 28 1 files changed, 20 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 7f893a2..829d235 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -116,24 +116,34 @@ ENTRY(omap3_sram_configure_core_dpll) @ pull the extra args off the stack @ and store them in SRAM + +@ PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a +@ base instead. +@ Be careful not to clobber r7 when maintaing this file. + THUMB(adr r7, omap3_sram_configure_core_dpll ) + .macro strtext Rt:req, label:req + ARM( str \Rt, \label ) + THUMB(str \Rt, [r7, \label - omap3_sram_configure_core_dpll] ) + .endm + ldr r4, [sp, #52] - str r4, omap_sdrc_rfr_ctrl_0_val + strtext r4, omap_sdrc_rfr_ctrl_0_val ldr r4, [sp, #56] - str r4, omap_sdrc_actim_ctrl_a_0_val + strtext r4, omap_sdrc_actim_ctrl_a_0_val ldr r4, [sp, #60] - str r4, omap_sdrc_actim_ctrl_b_0_val + strtext r4, omap_sdrc_actim_ctrl_b_0_val ldr r4, [sp, #64] - str r4, omap_sdrc_mr_0_val + strtext r4, omap_sdrc_mr_0_val ldr r4, [sp, #68] - str r4, omap_sdrc_rfr_ctrl_1_val + strtext r4, omap_sdrc_rfr_ctrl_1_val cmp r4, #0 @ if SDRC_RFR_CTRL_1 is 0, beq skip_cs1_params @ do not use cs1 params ldr r4, [sp, #72] - str r4, omap_sdrc_actim_ctrl_a_1_val + strtext r4, omap_sdrc_actim_ctrl_a_1_val ldr r4, [sp, #76] - str r4, omap_sdrc_actim_ctrl_b_1_val + strtext r4, omap_sdrc_actim_ctrl_b_1_val ldr r4, [sp, #80] - str r4, omap_sdrc_mr_1_val + strtext r4, omap_sdrc_mr_1_val skip_cs1_params: mrc p15, 0, r8, c1, c0, 0 @ read ctrl register bic r10, r8, #0x800 @ clear Z-bit, disable branch prediction @@ -271,6 +281,7 @@ skip_cs1_prog: ldr r12, [r11] @ posted-write barrier for SDRC bx lr + .align omap3_sdrc_power: .word OMAP34XX_SDRC_REGADDR(SDRC_POWER) omap3_cm_clksel1_pll: @@ -319,6 +330,7 @@ omap3_sdrc_dlla_ctrl: .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL) core_m2_mask_val: .word 0x07FF +ENDPROC(omap3_sram_configure_core_dpll) ENTRY(omap3_sram_configure_core_dpll_sz) .word . - omap3_sram_configure_core_dpll -- 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
[PATCH v4 2/5] ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL
Code marked with ENTRY() also needs a matching ENDPROC() directive,
in order to ensure that the type and instruction set of the
symbol are correctly annotated.
ENDPROC() tags the affected symbol as a function symbol, which will
ensure that link-time fixups don't accidentally switch to the
wrong instruction set.
Signed-off-by: Dave Martin dave.mar...@linaro.org
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-headsmp.S |2 +-
arch/arm/mach-omap2/omap44xx-smc.S |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-headsmp.S
b/arch/arm/mach-omap2/omap-headsmp.S
index 6ae937a..4ee6aec 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -45,5 +45,5 @@ hold: ldr r12,=0x103
* should now contain the SVC stack for this core
*/
b secondary_startup
-END(omap_secondary_startup)
+ENDPROC(omap_secondary_startup)
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S
b/arch/arm/mach-omap2/omap44xx-smc.S
index 1980dc3..e69d37d 100644
--- a/arch/arm/mach-omap2/omap44xx-smc.S
+++ b/arch/arm/mach-omap2/omap44xx-smc.S
@@ -29,7 +29,7 @@ ENTRY(omap_smc1)
dsb
smc #0
ldmfd sp!, {r2-r12, pc}
-END(omap_smc1)
+ENDPROC(omap_smc1)
ENTRY(omap_modify_auxcoreboot0)
stmfd sp!, {r1-r12, lr}
@@ -37,7 +37,7 @@ ENTRY(omap_modify_auxcoreboot0)
dsb
smc #0
ldmfd sp!, {r1-r12, pc}
-END(omap_modify_auxcoreboot0)
+ENDPROC(omap_modify_auxcoreboot0)
ENTRY(omap_auxcoreboot_addr)
stmfd sp!, {r2-r12, lr}
@@ -45,7 +45,7 @@ ENTRY(omap_auxcoreboot_addr)
dsb
smc #0
ldmfd sp!, {r2-r12, pc}
-END(omap_auxcoreboot_addr)
+ENDPROC(omap_auxcoreboot_addr)
ENTRY(omap_read_auxcoreboot0)
stmfd sp!, {r2-r12, lr}
@@ -54,4 +54,4 @@ ENTRY(omap_read_auxcoreboot0)
smc #0
mov r0, r0, lsr #9
ldmfd sp!, {r2-r12, pc}
-END(omap_read_auxcoreboot0)
+ENDPROC(omap_read_auxcoreboot0)
--
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
[PATCH 0/2] OMAP4: enable clk32kg in TWL6030
add clk32kg to twl-regulator add clk32kg board data to Blaze and Panda Balaji T K (2): regulator: twl: add clk32kg to twl-regulator OMAP4: add clk32kg data to omap4panda and blaze board file arch/arm/mach-omap2/board-4430sdp.c| 10 ++ arch/arm/mach-omap2/board-omap4panda.c | 10 ++ drivers/mfd/twl-core.c |4 drivers/regulator/twl-regulator.c |3 ++- include/linux/i2c/twl.h|2 ++ 5 files changed, 28 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce accessory APIs for DVFS
Vishwanath Sripathy vishwanath...@ti.com writes:
[...]
+ * This is a fundamental structure used to store all the required
+ * DVFS related information for a vdd.
+ */
+struct omap_vdd_dvfs_info {
+ spinlock_t user_lock; /* spin lock */
comment redundant
I added this because checkpatch was giving a warning saying mutex added
w/o comments.
The point of the checkpatch warning is not to add just any comment. The
point is to add a *useful* comment.
It is extremely helpful to readers of code with locking to know what the
locks are intended to protect. The comment should indicate what the
lock is protecting and why.
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
[PATCH 1/2] regulator: twl: add clk32kg to twl-regulator
In OMAP4 Blaze and Panda, 32KHz clock to WLAN is supplied from Phoenix TWL6030.
The 32KHz clock state (ON/OFF) is configured in CLK32KG_CFG_[GRP, TRANS, STATE]
register. This follows the same register programming model as other regulators
in TWL6030. So add CLK32KG as pseudo regulator.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mfd/twl-core.c|4
drivers/regulator/twl-regulator.c |3 ++-
include/linux/i2c/twl.h |2 ++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index a35fa7d..7d909cc 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -864,6 +864,10 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
child = add_regulator(TWL6030_REG_VAUX3_6030, pdata-vaux3);
if (IS_ERR(child))
return PTR_ERR(child);
+
+ child = add_regulator(TWL6030_REG_CLK32KG, pdata-clk32kg);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
}
if (twl_has_bci() pdata-bci
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index bd332cf..425f1fa 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -577,7 +577,8 @@ static struct twlreg_info twl_regs[] = {
TWL6030_FIXED_LDO(VANA, 0x50, 2100, 15, 0, 0x21),
TWL6030_FIXED_LDO(VCXIO, 0x60, 1800, 16, 0, 0x21),
TWL6030_FIXED_LDO(VDAC, 0x64, 1800, 17, 0, 0x21),
- TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21)
+ TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21),
+ TWL6030_FIXED_LDO(CLK32KG, 0x8C, 1000, 48, 0, 0x21),
};
static int __devinit twlreg_probe(struct platform_device *pdev)
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 61b9609..7086e1e 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -698,6 +698,7 @@ struct twl4030_platform_data {
struct regulator_init_data *vana;
struct regulator_init_data *vcxio;
struct regulator_init_data *vusb;
+ struct regulator_init_data *clk32kg;
};
/*--*/
@@ -777,5 +778,6 @@ static inline int twl4030charger_usb_en(int enable) {
return 0; }
/* INTERNAL LDOs */
#define TWL6030_REG_VRTC 47
+#define TWL6030_REG_CLK32KG48
#endif /* End of __TWL4030_H */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP4: add clk32kg data to omap4panda and blaze board file
In Blaze and Panda, 32KHz clock - CLK32KG to WLAN is supplied
from Phoenix TWL6030.
Add CLK32KG platform data to blaze and omap4panda board file.
This patch has dependency on :-
[PATCH 1/2] regulator: twl: add clk32kg to twl-regulator
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 10 ++
arch/arm/mach-omap2/board-omap4panda.c | 10 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 1b16525..0c52901 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -475,6 +475,15 @@ static struct regulator_init_data sdp4430_vusb = {
},
};
+static struct regulator_init_data sdp4430_clk32kg = {
+ .constraints = {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
static struct twl4030_platform_data sdp4430_twldata = {
.irq_base = TWL6030_IRQ_BASE,
.irq_end= TWL6030_IRQ_END,
@@ -490,6 +499,7 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux1 = sdp4430_vaux1,
.vaux2 = sdp4430_vaux2,
.vaux3 = sdp4430_vaux3,
+ .clk32kg= sdp4430_clk32kg,
.usb= omap4_usbphy_data
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 3686533..4c38b16 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -346,6 +346,15 @@ static struct regulator_init_data omap4_panda_vusb = {
},
};
+static struct regulator_init_data omap4_panda_clk32kg = {
+ .constraints = {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
static struct twl4030_platform_data omap4_panda_twldata = {
.irq_base = TWL6030_IRQ_BASE,
.irq_end= TWL6030_IRQ_END,
@@ -361,6 +370,7 @@ static struct twl4030_platform_data omap4_panda_twldata = {
.vaux1 = omap4_panda_vaux1,
.vaux2 = omap4_panda_vaux2,
.vaux3 = omap4_panda_vaux3,
+ .clk32kg= omap4_panda_clk32kg,
.usb= omap4_usbphy_data,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulator: twl: add clk32kg to twl-regulator
On Wed, Feb 09, 2011 at 09:07:25PM +0530, Balaji T K wrote: - TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21) + TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21), + TWL6030_FIXED_LDO(CLK32KG, 0x8C, 1000, 48, 0, 0x21), It'd seem better to implement a version of this that just doesn't have the voltage readback operation rather than putting in a dummy voltage. Otherwise this looks good. -- 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] OMAP4: add clk32kg data to omap4panda and blaze board file
On Wed, Feb 09, 2011 at 09:07:31PM +0530, Balaji T K wrote:
+ .constraints = {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
Does this really support mode setting?
--
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 03/13] OMAP: Implement Basic DVFS
Vishwanath Sripathy vishwanath...@ti.com writes: This needs a comment to, but I'm not sure I understand what's going on here. What it seems like: if this device has no OPP for this voltage, just silently move on to the next device? doesn't seem quite right, but not sure I fully grok the failure modes of omap_dvfs_find_voltage() Yes, your understanding is right. omap_dvfs_find_voltage will return error if the device does not have an OPP table. Typically devices should not register with a vdd (using omap_dvfs_register_device) if it has no OPP table associated with it. So ideally we should not hit this error case. But only exception so far is SR driver. SR hwmod has vdd_name field set so as to get voltagedomain pointers. But SR does not have any opp table. So there is no harm in ignoring the error and moving to next device. And what happens when other devices add voltage domains but don't have OPP tables? The point is that this error handling is 1) difficult to understand upon first (or fifth) read and 2) very fragile with other changes. 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 v4 1/5] ARM: omap4: Provide do_wfi() for Thumb-2
On Wed, 9 Feb 2011, Dave Martin wrote: For CONFIG_THUMB2_KERNEL, the existing definition of do_wfi() will insert invalid code into the instruction stream. Any assembler which can assemble Thumb-2 is guaranteed to accept the wfi mnemonic, so for the Thumb-2 case, just use the mnemonic. The ARM case is left as-is. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/mach-omap2/include/mach/omap4-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h index 5b0270b..de441c0 100644 --- a/arch/arm/mach-omap2/include/mach/omap4-common.h +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h @@ -17,8 +17,12 @@ * wfi used in low power code. Directly opcode is used instead * of instruction to avoid mulit-omap build break Might be a good idea to fix the typo above while at it. +#ifdef CONFIG_THUMB2_KERNEL +#define do_wfi() __asm__ __volatile__ (wfi : : : memory) +#else #define do_wfi() \ __asm__ __volatile__ (.word0xe320f003 : : : memory) +#endif #ifdef CONFIG_CACHE_L2X0 extern void __iomem *l2cache_base; -- 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: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
* Santosh Shilimkar santosh.shilim...@ti.com [110209 01:59]: From: Dave Martin [mailto:dave.mar...@linaro.org] You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. This sounds good way forward considering future OMAP architectures as well. But I let Tony comment on this idea. AFAIK these issues will be hopefully sorted out by the time the next merge window opens. For the -rc cycle, disabling SMP in config if ARMv6 is selected should do the trick. 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 03/13] OMAP: Implement Basic DVFS
-Original Message- From: Kevin Hilman [mailto:khil...@ti.com] Sent: Wednesday, February 09, 2011 9:30 PM To: Vishwanath Sripathy Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath Subject: Re: [PATCH 03/13] OMAP: Implement Basic DVFS Vishwanath Sripathy vishwanath...@ti.com writes: This needs a comment to, but I'm not sure I understand what's going on here. What it seems like: if this device has no OPP for this voltage, just silently move on to the next device? doesn't seem quite right, but not sure I fully grok the failure modes of omap_dvfs_find_voltage() Yes, your understanding is right. omap_dvfs_find_voltage will return error if the device does not have an OPP table. Typically devices should not register with a vdd (using omap_dvfs_register_device) if it has no OPP table associated with it. So ideally we should not hit this error case. But only exception so far is SR driver. SR hwmod has vdd_name field set so as to get voltagedomain pointers. But SR does not have any opp table. So there is no harm in ignoring the error and moving to next device. And what happens when other devices add voltage domains but don't have OPP tables? If someone does not have a OPP table, that means it's not a scalable device, so there is no need to scale that device. Vishwa The point is that this error handling is 1) difficult to understand upon first (or fifth) read and 2) very fragile with other changes. 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 00/14] Fix issues with ARMv6+v6k+v7 kernels
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, February 09, 2011 9:54 PM To: Santosh Shilimkar Cc: Dave Martin; Nicolas Pitre; linux-omap@vger.kernel.org; Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels * Santosh Shilimkar santosh.shilim...@ti.com [110209 01:59]: From: Dave Martin [mailto:dave.mar...@linaro.org] You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. This sounds good way forward considering future OMAP architectures as well. But I let Tony comment on this idea. AFAIK these issues will be hopefully sorted out by the time the next merge window opens. For the -rc cycle, disabling SMP in config if ARMv6 is selected should do the trick. Ok. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110209 01:59]: From: Dave Martin [mailto:dave.mar...@linaro.org] You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. This sounds good way forward considering future OMAP architectures as well. But I let Tony comment on this idea. AFAIK these issues will be hopefully sorted out by the time the next merge window opens. For the -rc cycle, disabling SMP in config if ARMv6 is selected should do the trick. That's not soo easy - as we don't know in the Kconfig whether we include ARMv6 rather than ARMv6K. It's exactly the same problem I ran into which inflated the v6v7 patchset. Maybe the best thing to do is: config CPU_32v6K bool Support ARM V6K processor extensions if !SMP depends on CPU_V6 || CPU_V7 default y if SMP !(ARCH_MX3 || ARCH_OMAP2) drop the ' !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the resulting undefined instruction traps if they try to run the kernel on V6 non-K hardware. Not ideal, but I don't see any other 'simple' solution to this. -- 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 00/14] Fix issues with ARMv6+v6k+v7 kernels
On Wed, Feb 09, 2011 at 04:32:04PM +, Russell King - ARM Linux wrote: On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110209 01:59]: From: Dave Martin [mailto:dave.mar...@linaro.org] You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. This sounds good way forward considering future OMAP architectures as well. But I let Tony comment on this idea. AFAIK these issues will be hopefully sorted out by the time the next merge window opens. For the -rc cycle, disabling SMP in config if ARMv6 is selected should do the trick. That's not soo easy - as we don't know in the Kconfig whether we include ARMv6 rather than ARMv6K. It's exactly the same problem I ran into which inflated the v6v7 patchset. Maybe the best thing to do is: config CPU_32v6K bool Support ARM V6K processor extensions if !SMP depends on CPU_V6 || CPU_V7 default y if SMP !(ARCH_MX3 || ARCH_OMAP2) drop the ' !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the resulting undefined instruction traps if they try to run the kernel on V6 non-K hardware. Not ideal, but I don't see any other 'simple' solution to this. Right, this is what I propose. Merging this will cause conflicts with the v6v7 patchset. 8- Subject: [PATCH] ARM: Avoid building unsafe kernels on OMAP2 and MX3 OMAP2 (armv6) and MX3 turn off support for the V6K instructions, which when they include support for SMP kernels means that the resulting kernel is unsafe on SMP and can result in corrupted filesystems as we end up using unsafe bitops. Re-enable the use of V6K instructions on such kernels, and let such kernels running on V6 CPUs eat undefined instruction faults which will be much safer than filesystem corruption. Next merge window we can fix this properly (as it requires a much bigger set of changes.) Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 9d30c6f..c9d2d56 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -405,7 +405,7 @@ config CPU_V6 config CPU_32v6K bool Support ARM V6K processor extensions if !SMP depends on CPU_V6 || CPU_V7 - default y if SMP !(ARCH_MX3 || ARCH_OMAP2) + default y if SMP help Say Y here if your ARMv6 processor supports the 'K' extension. This enables the kernel to use some instructions not present @@ -416,7 +416,7 @@ config CPU_32v6K # ARMv7 config CPU_V7 bool Support ARM V7 processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX - select CPU_32v6K if !ARCH_OMAP2 + select CPU_32v6K select CPU_32v7 select CPU_ABRT_EV7 select CPU_PABRT_V7 -- 1.6.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulator: twl: add clk32kg to twl-regulator
On Wed, Feb 9, 2011 at 9:14 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Feb 09, 2011 at 09:07:25PM +0530, Balaji T K wrote: - TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21) + TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21), + TWL6030_FIXED_LDO(CLK32KG, 0x8C, 1000, 48, 0, 0x21), It'd seem better to implement a version of this that just doesn't have the voltage readback operation rather than putting in a dummy voltage. Otherwise this looks good. yes, will do that. -- 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 00/14] Fix issues with ARMv6+v6k+v7 kernels
On Wed, 9 Feb 2011, Russell King - ARM Linux wrote: On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110209 01:59]: From: Dave Martin [mailto:dave.mar...@linaro.org] You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. This sounds good way forward considering future OMAP architectures as well. But I let Tony comment on this idea. AFAIK these issues will be hopefully sorted out by the time the next merge window opens. For the -rc cycle, disabling SMP in config if ARMv6 is selected should do the trick. That's not soo easy - as we don't know in the Kconfig whether we include ARMv6 rather than ARMv6K. It's exactly the same problem I ran into which inflated the v6v7 patchset. Maybe the best thing to do is: config CPU_32v6K bool Support ARM V6K processor extensions if !SMP depends on CPU_V6 || CPU_V7 default y if SMP !(ARCH_MX3 || ARCH_OMAP2) drop the ' !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the resulting undefined instruction traps if they try to run the kernel on V6 non-K hardware. Not ideal, but I don't see any other 'simple' solution to this. This should be good enough. We're looking for a temporary stopgate solution to prevent people from corrupting their data, and the real fix will be available in the next kernel. Nicolas -- 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] OMAP4: add clk32kg data to omap4panda and blaze board file
On Wed, Feb 9, 2011 at 9:15 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Wed, Feb 09, 2011 at 09:07:31PM +0530, Balaji T K wrote:
+ .constraints = {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
Does this really support mode setting?
No, It didn't support mode setting.
will update valid_ops_mask for REGULATOR_CHANGE_STATUS only
and remove valid_modes_mask
--
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 v5 0/4] Introduce support for TI816X processor series
This patch set adds support for TI816X processor series. This series includes DM8168, C6A816x and AM389x devices. The details can be found at following links: http://focus.ti.com/general/docs/gencontent.tsp?contentId=77960 http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml This series is architecturally closer to the OMAP devices. Hence, these patches are being submitted on linux-omap. These patches are tested on OMAP3 EVM with multi-omap build. Note that, additional patches consisting of TI816X specific hwmods, clock data and DMTIMER changes, are required to enable successful booting on TI816X EVM. These patches will follow shortly. The TI816X support is added as part of OMAP3 variant. The approach taken is in accordance to the discussions in thread related to following post: http://www.spinics.net/lists/linux-omap/msg41505.html In addition, TI816X specific customizations/optimizations are handled as a part of build configuration CONFIG_SOC_OMAPTI816X. Discussed here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41927.html Hemant Pedanekar (4): TI816X: Update common omap platform files TI816X: Update common OMAP machine specific sources TI816X: Create board support and enable build for TI816X EVM TI816X: Add low level debug support arch/arm/mach-omap2/Kconfig| 16 +++ arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-ti8168evm.c | 57 arch/arm/mach-omap2/clock3xxx_data.c |5 ++- arch/arm/mach-omap2/common.c | 21 + arch/arm/mach-omap2/control.h |6 +++ arch/arm/mach-omap2/id.c | 33 +- arch/arm/mach-omap2/include/mach/debug-macro.S | 12 + arch/arm/mach-omap2/include/mach/entry-macro.S | 13 + arch/arm/mach-omap2/io.c | 13 +- arch/arm/mach-omap2/irq.c |5 ++- arch/arm/mach-omap2/serial.c |8 ++-- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h|1 + arch/arm/plat-omap/include/plat/common.h |1 + arch/arm/plat-omap/include/plat/cpu.h | 22 + arch/arm/plat-omap/include/plat/hardware.h |1 + arch/arm/plat-omap/include/plat/serial.h |8 +++ arch/arm/plat-omap/include/plat/ti816x.h | 27 +++ arch/arm/plat-omap/include/plat/uncompress.h |7 +++ arch/arm/plat-omap/io.c|5 ++- 21 files changed, 253 insertions(+), 10 deletions(-) create mode 100644 arch/arm/mach-omap2/board-ti8168evm.c create mode 100644 arch/arm/plat-omap/include/plat/ti816x.h -- 1.7.3.5 -- 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 v5 1/4] TI816X: Update common omap platform files
This patch updates the common platform files with TI816X support.
The approach taken in this patch is to add TI816X as part of OMAP3 variant where
the cpu class is considered as OMAP34XX and the type is TI816X. This means, both
cpu_is_omap34xx() and cpu_is_ti816x() checks return success on TI816X.
In addition, a kernel config option CONFIG_SOC_OMAPTI816X is also added under
OMAP3 to allow TI816X only build. This option leads to following main
possibilities:
1) Multi-OMAP build with CONFIG_SOC_OMAPTI816X: The kernel built only for
TI816X OMAP3 SoCs along with any other OMAP2/4 (e.g., OMAP4s). May not boot
on other OMAP3 SoCs.
2) OMAP3 only build with CONFIG_SOC_OMAPTI816X: This will build TI816X
optimized kernel. May not boot on other OMAP3 SoCs.
3) OMAP3 only, no CONFIG_SOC_OMAPTI816X: This will build kernel for all OMAP3s
except TI816X. Note that cpu_is_ti816x checks will return fail.
As mentioned above (in (1) and (2)), selecting CONFIG_SOC_OMAPTI816X skips some
configurations which are required for OMAP3XXX devices but not applicable on
TI816X devices (e.g., dpll5 setting). Hence the kernel built with
CONFIG_SOC_OMAPTI816X may not boot on those OMAP3 devices.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/Kconfig | 11 +++
arch/arm/plat-omap/include/plat/clkdev_omap.h |1 +
arch/arm/plat-omap/include/plat/clock.h |1 +
arch/arm/plat-omap/include/plat/common.h |1 +
arch/arm/plat-omap/include/plat/cpu.h | 22 ++
arch/arm/plat-omap/include/plat/hardware.h|1 +
6 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ae7f47d..0b921bc 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -72,6 +72,17 @@ config SOC_OMAP3430
default y
select ARCH_OMAP_OTG
+config SOC_OMAPTI816X
+ bool TI816X SoC family specific build of OMAP3
+ depends on ARCH_OMAP3
+ default n
+ help
+Select Y if you want a TI816X only build of OMAP3. This means the
+kernel built with this option may not boot on non TI816X OMAP3 SoCs.
+This restriction applies even for multi-omap builds. It is recommended
+to select N here if you wish to build a multi-omap kernel for booting
+on all OMAP3 based SoCs (including TI816X).
+
config OMAP_PACKAGE_ZAF
bool
diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h
b/arch/arm/plat-omap/include/plat/clkdev_omap.h
index 256ab3f..f1899a3 100644
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -38,6 +38,7 @@ struct omap_clk {
#define CK_3517(1 9)
#define CK_36XX(1 10) /* 36xx/37xx-specific clocks */
#define CK_443X(1 11)
+#define CK_TI816X (1 12)
#define CK_34XX(CK_3430ES1 | CK_3430ES2PLUS)
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 8eb0ada..d43e623 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -53,6 +53,7 @@ struct clkops {
#define RATE_IN_3430ES2PLUS(1 3)/* 3430 ES = 2 rates only */
#define RATE_IN_36XX (1 4)
#define RATE_IN_4430 (1 5)
+#define RATE_IN_TI816X (1 6)
#define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X)
#define RATE_IN_34XX (RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS)
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 29b2afb..1dd97e7 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -66,6 +66,7 @@ void omap2_set_globals_242x(void);
void omap2_set_globals_243x(void);
void omap2_set_globals_3xxx(void);
void omap2_set_globals_443x(void);
+void omap2_set_globals_ti816x(void);
/* These get called from omap2_set_globals_(), do not call these */
void omap2_set_globals_tap(struct omap_globals *);
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 73d91ee..ee18ae0 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -105,6 +105,12 @@ static inline int is_omap ##subclass (void)
\
return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0; \
}
+#define IS_TI_SUBCLASS(subclass, id) \
+static inline int is_ti ##subclass (void) \
+{ \
+ return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0; \
+}
+
IS_OMAP_CLASS(7xx, 0x07)
IS_OMAP_CLASS(15xx, 0x15)
IS_OMAP_CLASS(16xx, 0x16)
@@ -118,6 +124,8 @@ IS_OMAP_SUBCLASS(343x, 0x343)
IS_OMAP_SUBCLASS(363x, 0x363)
IS_OMAP_SUBCLASS(443x, 0x443)
+IS_TI_SUBCLASS(816x, 0x816)
+
#define cpu_is_omap7xx() 0
#define
[PATCH v5 2/4] TI816X: Update common OMAP machine specific sources
This patch updates the common machine specific source files with support for
TI816X.
The approach taken is to have TI816X only build for OMAP3 when
CONFIG_SOC_OMAPTI816X is defined.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |5 +++-
arch/arm/mach-omap2/common.c | 21 +++
arch/arm/mach-omap2/control.h |6
arch/arm/mach-omap2/id.c | 33 ++-
arch/arm/mach-omap2/include/mach/entry-macro.S | 13 +
arch/arm/mach-omap2/io.c | 13 -
arch/arm/mach-omap2/irq.c |5 +++-
arch/arm/mach-omap2/serial.c |8 +++---
arch/arm/plat-omap/include/plat/ti816x.h | 27 +++
arch/arm/plat-omap/io.c|5 +++-
10 files changed, 126 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/ti816x.h
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 403a4a1..f14d986 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3471,6 +3471,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_omap3630()) {
cpu_mask = (RATE_IN_34XX | RATE_IN_36XX);
cpu_clkflg = CK_36XX;
+ } else if (cpu_is_ti816x()) {
+ cpu_mask = RATE_IN_TI816X;
+ cpu_clkflg = CK_TI816X;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
@@ -3550,7 +3553,7 @@ int __init omap3xxx_clk_init(void)
/*
* Lock DPLL5 and put it in autoidle.
*/
- if (omap_rev() = OMAP3430_REV_ES2_0)
+ if (!cpu_is_ti816x() (omap_rev() = OMAP3430_REV_ES2_0))
omap3_clk_lock_dpll5();
/* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index d5eaee3..48de451 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -108,6 +108,27 @@ void __init omap3_map_io(void)
omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
+
+/*
+ * Adjust TAP register base such that omap3_check_revision accesses the correct
+ * TI816X register for checking device ID (it adds 0x204 to tap base while
+ * TI816X DEVICE ID register is at offset 0x600 from control base).
+ */
+#define TI816X_TAP_BASE(TI816X_CTRL_BASE + \
+ TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals ti816x_globals = {
+ .class = OMAP343X_CLASS,
+ .tap= OMAP2_L4_IO_ADDRESS(TI816X_TAP_BASE),
+ .ctrl = TI816X_CTRL_BASE,
+ .prm= TI816X_PRCM_BASE,
+ .cm = TI816X_PRCM_BASE,
+};
+
+void __init omap2_set_globals_ti816x(void)
+{
+ __omap2_set_globals(ti816x_globals);
+}
#endif
#if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f0629ae..c2804c1 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -52,6 +52,9 @@
#define OMAP343X_CONTROL_PADCONFS_WKUP 0xa00
#define OMAP343X_CONTROL_GENERAL_WKUP 0xa60
+/* TI816X spefic control submodules */
+#define TI816X_CONTROL_DEVCONF 0x600
+
/* Control register offsets - read/write with omap_ctrl_{read,write}{bwl}() */
#define OMAP2_CONTROL_SYSCONFIG(OMAP2_CONTROL_INTERFACE + 0x10)
@@ -241,6 +244,9 @@
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK0x254
+/* TI816X CONTROL_DEVCONF register offsets */
+#define TI816X_CONTROL_DEVICE_ID (TI816X_CONTROL_DEVCONF + 0x000)
+
/*
* REVISIT: This list of registers is not comprehensive - there are more
* that should be added.
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..5c25f1b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -191,12 +191,19 @@ static void __init omap3_check_features(void)
if (!cpu_is_omap3505() !cpu_is_omap3517())
omap3_features |= OMAP3_HAS_IO_WAKEUP;
+ omap3_features |= OMAP3_HAS_SDRC;
+
/*
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
}
+static void __init ti816x_check_features(void)
+{
+ omap3_features = OMAP3_HAS_NEON;
+}
+
static void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
@@ -287,6 +294,20 @@ static void __init omap3_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
}
break;
+ case 0xb81e:
+ omap_chip.oc = CHIP_IS_TI816X;
+
+ switch (rev) {
+ case 0:
+ omap_revision = TI8168_REV_ES1_0;
+
[PATCH v5 3/4] TI816X: Create board support and enable build for TI816X EVM
This patch adds minimal support and build configuration for TI816X EVM.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-ti8168evm.c | 57 +
3 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-ti8168evm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0b921bc..032903d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -305,6 +305,11 @@ config MACH_OMAP_3630SDP
default y
select OMAP_PACKAGE_CBP
+config MACH_TI8168EVM
+ bool TI8168 Evaluation Module
+ depends on ARCH_OMAP3
+ default y
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9eeabaf..a9e3974 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -224,6 +224,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) +=
board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
hsmmc.o
+obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
# Platform specific device init code
usbfs-$(CONFIG_ARCH_OMAP_OTG) := usb-fs.o
obj-y += $(usbfs-m) $(usbfs-y)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
new file mode 100644
index 000..191e176
--- /dev/null
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -0,0 +1,57 @@
+/*
+ * Code for TI8168 EVM.
+ *
+ * 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 linux/kernel.h
+#include linux/init.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/irqs.h
+#include plat/board.h
+#include plat/common.h
+
+static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
+};
+
+static void __init ti8168_evm_init_irq(void)
+{
+ omap_board_config = ti8168_evm_config;
+ omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(NULL, NULL);
+ omap_init_irq();
+}
+
+static void __init ti8168_evm_init(void)
+{
+ omap_serial_init();
+}
+
+static void __init ti8168_evm_map_io(void)
+{
+ omap2_set_globals_ti816x();
+ omap34xx_map_common_io();
+}
+
+MACHINE_START(TI8168EVM, ti8168evm)
+ /* Maintainer: Texas Instruments */
+ .boot_params= 0x8100,
+ .map_io = ti8168_evm_map_io,
+ .init_irq = ti8168_evm_init_irq,
+ .timer = omap_timer,
+ .init_machine = ti8168_evm_init,
+MACHINE_END
--
1.7.3.5
--
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 v5 4/4] TI816X: Add low level debug support
This patch adds support for low level debugging on TI816X boards. Currently the
support for UART3 console on TI816X EVM is added.
Signed-off-by: Hemant Pedanekar hema...@ti.com
---
arch/arm/mach-omap2/include/mach/debug-macro.S | 12
arch/arm/plat-omap/include/plat/serial.h |8
arch/arm/plat-omap/include/plat/uncompress.h |7 +++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 6a4d413..e1b0f17 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -69,6 +69,12 @@ omap_uart_lsr: .word 0
beq 34f @ configure OMAP3UART4
cmp \rp, #OMAP4UART4@ only on 44xx
beq 44f @ configure OMAP4UART4
+ cmp \rp, #TI816XUART1 @ ti816x UART offsets different
+ beq 81f @ configure UART1
+ cmp \rp, #TI816XUART2 @ ti816x UART offsets different
+ beq 82f @ configure UART2
+ cmp \rp, #TI816XUART3 @ ti816x UART offsets different
+ beq 83f @ configure UART3
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART
@@ -91,6 +97,12 @@ omap_uart_lsr: .word 0
b 98f
44:mov \rp, #UART_OFFSET(OMAP4_UART4_BASE)
b 98f
+81:mov \rp, #UART_OFFSET(TI816X_UART1_BASE)
+ b 98f
+82:mov \rp, #UART_OFFSET(TI816X_UART2_BASE)
+ b 98f
+83:mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
+ b 98f
95:ldr \rp, =ZOOM_UART_BASE
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index cec5d56..4102bf4 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -51,6 +51,11 @@
#define OMAP4_UART3_BASE 0x4802
#define OMAP4_UART4_BASE 0x4806e000
+/* TI816X serial ports */
+#define TI816X_UART1_BASE 0x4802
+#define TI816X_UART2_BASE 0x48022000
+#define TI816X_UART3_BASE 0x48024000
+
/* External port on Zoom2/3 */
#define ZOOM_UART_BASE 0x1000
#define ZOOM_UART_VIRT 0xfa40
@@ -81,6 +86,9 @@
#define OMAP4UART2 OMAP2UART2
#define OMAP4UART3 43
#define OMAP4UART4 44
+#define TI816XUART181
+#define TI816XUART282
+#define TI816XUART383
#define ZOOM_UART 95 /* Only on zoom2/3 */
/* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
b/arch/arm/plat-omap/include/plat/uncompress.h
index ad98b85..30b891c 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -93,6 +93,10 @@ static inline void flush(void)
#define DEBUG_LL_ZOOM(mach)\
_DEBUG_LL_ENTRY(mach, ZOOM_UART_BASE, ZOOM_PORT_SHIFT, ZOOM_UART)
+#define DEBUG_LL_TI816X(p, mach) \
+ _DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT, \
+ TI816XUART##p)
+
static inline void __arch_decomp_setup(unsigned long arch_id)
{
int port = 0;
@@ -166,6 +170,9 @@ static inline void __arch_decomp_setup(unsigned long
arch_id)
DEBUG_LL_ZOOM(omap_zoom2);
DEBUG_LL_ZOOM(omap_zoom3);
+ /* TI8168 base boards using UART3 */
+ DEBUG_LL_TI816X(3, ti8168evm);
+
} while (0);
}
--
1.7.3.5
--
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 00/14] Fix issues with ARMv6+v6k+v7 kernels
* Nicolas Pitre nicolas.pi...@linaro.org [110209 08:44]: On Wed, 9 Feb 2011, Russell King - ARM Linux wrote: On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110209 01:59]: From: Dave Martin [mailto:dave.mar...@linaro.org] You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. This sounds good way forward considering future OMAP architectures as well. But I let Tony comment on this idea. AFAIK these issues will be hopefully sorted out by the time the next merge window opens. For the -rc cycle, disabling SMP in config if ARMv6 is selected should do the trick. That's not soo easy - as we don't know in the Kconfig whether we include ARMv6 rather than ARMv6K. It's exactly the same problem I ran into which inflated the v6v7 patchset. Maybe the best thing to do is: config CPU_32v6K bool Support ARM V6K processor extensions if !SMP depends on CPU_V6 || CPU_V7 default y if SMP !(ARCH_MX3 || ARCH_OMAP2) drop the ' !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the resulting undefined instruction traps if they try to run the kernel on V6 non-K hardware. Not ideal, but I don't see any other 'simple' solution to this. This should be good enough. We're looking for a temporary stopgate solution to prevent people from corrupting their data, and the real fix will be available in the next kernel. OK. This patch will be needed anyways for the real fixes. And no temporary apply-undo type patching needed. The only drawback is that omap2420 and 2430 won't boot with omap2plus_defconfig, but that will be only for a few weeks. Acked-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 v2 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
* Mark Brown broo...@opensource.wolfsonmicro.com [110201 13:25]: On Tue, Feb 01, 2011 at 07:53:26PM +0200, Jarkko Nikula wrote: Mark, Liam: is it ok if the 12/13 goes together with rest of the set via linux-omap when ready? I already acked it. OK assuming the next series is OK I'll queue it. Still need Paul's ack on the hwmod name addition. 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: ARM Architecture and GENERIC_CMOS_UPDATE
* Grant Erickson maratho...@gmail.com [110202 08:56]: On 2/1/11 2:32 PM, Tony Lindgren wrote: * Grant Erickson maratho...@gmail.com [110128 16:34]: The long-term solution probably involves adding a function pointer member field for each machine description with a generic, default function that does something akin to the above board-specific approach. Comments welcomed. Maybe ask about that on LKML and LAKML? There may be some rtc related changes queued up too.. 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 v5 0/5] omap: mailbox: hwmod support
* Omar Ramirez Luna omar.rami...@ti.com [110202 11:37]: Mailbox hwmod support for OMAP 2,3,4. Hiroshi, any comments on these? 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] OMAP4: PandaBoard: Adding DVI support
On Wed, Feb 9, 2011 at 8:08 AM, Gadiyar, Anand gadi...@ti.com wrote: On Wed, Feb 9, 2011 at 7:25 PM, Raghuveer Murthy raghuveer.mur...@ti.com wrote: Adding DVI support to OMAP4 PandaBoard. PandaBoard uses TFP410 DVI Framer chip http://focus.ti.com/lit/ds/symlink/tfp410.pdf The TFP410 gets its power enable and display data over GPIO lines muxed in from OMAP4430. PandaBoard supports other LCD displays through expansion connectors, following board rework. This will disable the DVI interface. However, the existing mux settings remain the same PandaBoard additionally supports display over HDMI interface. It is mutually exclusive to display over DVI. Hence the mux settings need to be configured seperately, as and when HDMI is enabled Also, I2C3 bus used for reading EDID data from DVI Monitors is registered here. Since the design is similar to BeagleBoard, the code for the same is taken from the kernel.org commit ef48dd5cb21 (omap: Adding beagle i2c eeprom driver to read EDID) Reviewed-by: Manjunath G Kondaiah manj...@ti.com Reviewed-by: Anand Gadiyar gadi...@ti.com I've also tested it on the Panda, and gone through this and most of the other patches in the series. So if you like, you could consider this an: Acked-by: Anand Gadiyar gadi...@ti.com Reviewed-by: Nishanth Menon n...@ti.com Reviewed-by: Sumit Semwal sumit.sem...@ti.com Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com --- Base url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git branch master commit 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d tag 2.6.38-rc4 To make it easier for someone to test, I've extracted this and the 6 dependent series from patchwork, and hosted them in a branch on my devel tree. They are available against v2.6.38-rc4 here: git://dev.omapzoom.org/pub/scm/anand/linux-omap-usb.git in the display-patches-for-v2.6.38-rc4 branch if someone wants to take a look. These work great on my Panda A1, (mainline 2.6.38-rc4 base) haven't seen any regressions on my Beagle C4 with the same patchset/image.. Regards, -- Robert Nelson http://www.rcn-ee.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 v6 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
* Kevin Hilman khil...@ti.com [110204 14:27]: Govindraj.R govindraj.r...@ti.com writes: Changes invloves: 1) Addition of hwmod data for omap2/3/4. 2) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 3) Runtime Conversion of McSPI driver. Changes from v5: --- Rebased on top of 2.6.38-rc3 as per Kevin's comments. http://www.spinics.net/lists/arm-kernel/msg112112.html Thanks. Reviewed-by: Kevin Hilman khil...@ti.com Thanks everybody, will queue. 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] ARM: omap1/nokia770: mark some functions __init
* Uwe Kleine-König u.kleine-koe...@pengutronix.de [110208 01:58]: On Thu, Feb 03, 2011 at 09:15:08AM +0100, Uwe Kleine-König wrote: Hey Tony, this patch below is now 4 months old and I didn't get any feedback. (Though I somehow missed to cc linux-omap@vger.kernel.org before, sorry for that.) Sorry I must have missed those. There are two more patches in this thread that are not yet applied/commented. Should I resend? ping Well I usually purge my mailing list archives after about a month or so. Can you please resend or bounce the thread to me? 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
[PATCH 1/4] ARM: omap1/nokia770: mark some functions __init
These are only called from omap_nokia770_init which is in .init.text, too.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/mach-omap1/board-nokia770.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index d21f09d..cfd0849 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -115,7 +115,7 @@ static struct mipid_platform_data
nokia770_mipid_platform_data = {
.shutdown = mipid_shutdown,
};
-static void mipid_dev_init(void)
+static void __init mipid_dev_init(void)
{
const struct omap_lcd_config *conf;
@@ -126,7 +126,7 @@ static void mipid_dev_init(void)
}
}
-static void ads7846_dev_init(void)
+static void __init ads7846_dev_init(void)
{
if (gpio_request(ADS7846_PENDOWN_GPIO, ADS7846 pendown) 0)
printk(KERN_ERR can't get ads7846 pen down GPIO\n);
@@ -170,7 +170,7 @@ static struct hwa742_platform_data
nokia770_hwa742_platform_data = {
.te_connected = 1,
};
-static void hwa742_dev_init(void)
+static void __init hwa742_dev_init(void)
{
clk_add_alias(hwa_sys_ck, NULL, bclk, NULL);
omapfb_set_ctrl_platform_data(nokia770_hwa742_platform_data);
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: omap: move omap_get_config et al. to .init.text
All callers of these functions live in .init.text, so these can go there,
too. There they must not be exported anymore, this is no problem though,
as all callers are always built-in.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/plat-omap/common.c |6 ++
arch/arm/plat-omap/include/plat/board.h |4 ++--
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index f047318..30c698e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -49,17 +49,15 @@ static const void *get_config(u16 tag, size_t len, int
skip, size_t *len_out)
return kinfo-data;
}
-const void *__omap_get_config(u16 tag, size_t len, int nr)
+const void *__init __omap_get_config(u16 tag, size_t len, int nr)
{
return get_config(tag, len, nr, NULL);
}
-EXPORT_SYMBOL(__omap_get_config);
-const void *omap_get_var_config(u16 tag, size_t *len)
+const void *__init omap_get_var_config(u16 tag, size_t *len)
{
return get_config(tag, NO_LENGTH_CHECK, 0, len);
}
-EXPORT_SYMBOL(omap_get_var_config);
void __init omap_reserve(void)
{
diff --git a/arch/arm/plat-omap/include/plat/board.h
b/arch/arm/plat-omap/include/plat/board.h
index 3cf4fa2..97126df 100644
--- a/arch/arm/plat-omap/include/plat/board.h
+++ b/arch/arm/plat-omap/include/plat/board.h
@@ -151,14 +151,14 @@ struct omap_board_config_kernel {
const void *data;
};
-extern const void *__omap_get_config(u16 tag, size_t len, int nr);
+extern const void *__init __omap_get_config(u16 tag, size_t len, int nr);
#define omap_get_config(tag, type) \
((const type *) __omap_get_config((tag), sizeof(type), 0))
#define omap_get_nr_config(tag, type, nr) \
((const type *) __omap_get_config((tag), sizeof(type), (nr)))
-extern const void *omap_get_var_config(u16 tag, size_t *len);
+extern const void *__init omap_get_var_config(u16 tag, size_t *len);
extern struct omap_board_config_kernel *omap_board_config;
extern int omap_board_config_size;
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: omap: move omap_board_config_kernel to .init.data
This variable is only assigned in __init functions and never used later.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/plat-omap/common.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 30c698e..d9f10a3 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -24,10 +24,11 @@
#define NO_LENGTH_CHECK 0x
-struct omap_board_config_kernel *omap_board_config;
+struct omap_board_config_kernel *omap_board_config __initdata;
int omap_board_config_size;
-static const void *get_config(u16 tag, size_t len, int skip, size_t *len_out)
+static const void *__init get_config(u16 tag, size_t len,
+ int skip, size_t *len_out)
{
struct omap_board_config_kernel *kinfo = NULL;
int i;
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] wip: fix section mismatches in omap1_defconfig
after these changes omap1_defconfig and omap2plus_defconfig don't have any
section mismatches any more, making it plausible that the patches earlier
in this series are OK.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
arch/arm/mach-omap1/board-ams-delta.c |4 ++--
arch/arm/mach-omap1/board-fsample.c |2 +-
drivers/usb/otg/isp1301_omap.c|2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 22cc8c8..560e33f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -175,7 +175,7 @@ static struct omap_usb_config ams_delta_usb_config
__initdata = {
.pins[0]= 2,
};
-static struct omap_board_config_kernel ams_delta_config[] = {
+static struct omap_board_config_kernel ams_delta_config[] __initdata = {
{ OMAP_TAG_LCD, ams_delta_lcd_config },
};
@@ -259,7 +259,7 @@ static int ams_delta_camera_power(struct device *dev, int
power)
#define ams_delta_camera_power NULL
#endif
-static struct soc_camera_link __initdata ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink = {
.bus_id = 0,/* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = ams_delta_camera_board_info[0],
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 0efb9db..6b98eef 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -291,7 +291,7 @@ static struct omap_lcd_config fsample_lcd_config __initdata
= {
.ctrl_name = internal,
};
-static struct omap_board_config_kernel fsample_config[] = {
+static struct omap_board_config_kernel fsample_config[] __initdata = {
{ OMAP_TAG_LCD, fsample_lcd_config },
};
diff --git a/drivers/usb/otg/isp1301_omap.c b/drivers/usb/otg/isp1301_omap.c
index e00fa1b..8c6fdef 100644
--- a/drivers/usb/otg/isp1301_omap.c
+++ b/drivers/usb/otg/isp1301_omap.c
@@ -1510,7 +1510,7 @@ isp1301_start_hnp(struct otg_transceiver *dev)
/*-*/
-static int __init
+static int __devinit
isp1301_probe(struct i2c_client *i2c, const struct i2c_device_id *id)
{
int status;
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/13] OMAP: hwmod: Add member 'name' to omap_hwmod_addr_space struct
On Mon, 31 Jan 2011, Kishon Vijay Abraham I wrote: Adds a structure member 'name' to 'omap_hwmod_addr_space' structure. The drivers can use platform_get_resource_byname() to get resource of type 'IORESOURCE_MEM' by name so that it need not rely on the order to get the proper resource. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Acked-by: Paul Walmsley p...@pwsan.com -- although, please update the patch description as Kevin requested. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap1/nokia770: mark some functions __init
* Tony Lindgren t...@atomide.com [110209 11:26]: * Uwe Kleine-König u.kleine-koe...@pengutronix.de [110208 01:58]: There are two more patches in this thread that are not yet applied/commented. Should I resend? Thanks Uwe, I've applied them into devel-cleanup branch for the next merge window. 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] OMAP4: PandaBoard: Adding DVI support
On Wed, Feb 9, 2011 at 1:07 PM, Robert Nelson robertcnel...@gmail.com wrote: On Wed, Feb 9, 2011 at 8:08 AM, Gadiyar, Anand gadi...@ti.com wrote: On Wed, Feb 9, 2011 at 7:25 PM, Raghuveer Murthy raghuveer.mur...@ti.com wrote: Adding DVI support to OMAP4 PandaBoard. PandaBoard uses TFP410 DVI Framer chip http://focus.ti.com/lit/ds/symlink/tfp410.pdf The TFP410 gets its power enable and display data over GPIO lines muxed in from OMAP4430. PandaBoard supports other LCD displays through expansion connectors, following board rework. This will disable the DVI interface. However, the existing mux settings remain the same PandaBoard additionally supports display over HDMI interface. It is mutually exclusive to display over DVI. Hence the mux settings need to be configured seperately, as and when HDMI is enabled Also, I2C3 bus used for reading EDID data from DVI Monitors is registered here. Since the design is similar to BeagleBoard, the code for the same is taken from the kernel.org commit ef48dd5cb21 (omap: Adding beagle i2c eeprom driver to read EDID) Reviewed-by: Manjunath G Kondaiah manj...@ti.com Reviewed-by: Anand Gadiyar gadi...@ti.com I've also tested it on the Panda, and gone through this and most of the other patches in the series. So if you like, you could consider this an: Acked-by: Anand Gadiyar gadi...@ti.com Reviewed-by: Nishanth Menon n...@ti.com Reviewed-by: Sumit Semwal sumit.sem...@ti.com Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com --- Base url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git branch master commit 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d tag 2.6.38-rc4 To make it easier for someone to test, I've extracted this and the 6 dependent series from patchwork, and hosted them in a branch on my devel tree. They are available against v2.6.38-rc4 here: git://dev.omapzoom.org/pub/scm/anand/linux-omap-usb.git in the display-patches-for-v2.6.38-rc4 branch if someone wants to take a look. These work great on my Panda A1, (mainline 2.6.38-rc4 base) haven't seen any regressions on my Beagle C4 with the same patchset/image.. for the panda patches: Tested-by: Robert Nelson robertcnel...@gmail.com -- Robert Nelson http://www.rcn-ee.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 v5 1/4] TI816X: Update common omap platform files
Hi, * Hemant Pedanekar hema...@ti.com [110209 08:54]: 1) Multi-OMAP build with CONFIG_SOC_OMAPTI816X: The kernel built only for TI816X OMAP3 SoCs along with any other OMAP2/4 (e.g., OMAP4s). May not boot on other OMAP3 SoCs. This option does not sound right. For the multi-omap builds we need to have the system working for all the processors, there should not be any reason not to have things working. Do you have some example in mind where other omaps break? If so, we should just fix that issue. 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 v5 2/4] TI816X: Update common OMAP machine specific sources
* Hemant Pedanekar hema...@ti.com [110209 08:54]:
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -121,6 +121,16 @@ static struct map_desc omap243x_io_desc[] __initdata = {
#endif
#ifdef CONFIG_ARCH_OMAP3
+#ifdef CONFIG_SOC_OMAPTI816X
+static struct map_desc omap34xx_io_desc[] __initdata = {
+ {
+ .virtual= L4_34XX_VIRT,
+ .pfn= __phys_to_pfn(L4_34XX_PHYS),
+ .length = L4_34XX_SIZE,
+ .type = MT_DEVICE
+ },
+};
+#else
Ah maybe you mean this else here? This would certainly break things for other
omap3 processors..
static struct map_desc omap34xx_io_desc[] __initdata = {
{
.virtual= L3_34XX_VIRT,
@@ -175,6 +185,7 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
#endif
};
#endif
+#endif
#ifdef CONFIG_ARCH_OMAP4
static struct map_desc omap44xx_io_desc[] __initdata = {
{
..because the omap34xx_io_desc[] will be missing all the other entries.
We should just have separate struct map_desc omapti816x_io_desc[] then.
Maybe have a common struct map_desc omap3_io_desc[] and then separate
omap3xxx_io_desc and omapti816x_io_desc?
Let me know if you know of other places where compiling in ti816x
and other omap3 processors would cause issues, sounds like these should
be very easy to sort out considering we already support quite a few
omap variants.
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 v5 2/4] TI816X: Update common OMAP machine specific sources
* Tony Lindgren t...@atomide.com [110209 17:45]: We should just have separate struct map_desc omapti816x_io_desc[] then. Maybe have a common struct map_desc omap3_io_desc[] and then separate omap3xxx_io_desc and omapti816x_io_desc? Oh and this will work just fine for map_io without having cpu_is_omap macros working yet because we call set_globals from the board file with the processor class data. 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: [RFT/RFC/PATCH 00/13] CBUS meets GENIRQ
* Felipe Balbi ba...@ti.com [110203 02:20]:
Hi Tony,
When you have some extra time, could you run these on N810
to check whether I'm on the right path ? After these patches
all CBUS drivers are using standard request_threaded_irq()
calls. It's one step closer into getting those in mainline.
Cool sorry it took a while, this is starting to look like
it will be pretty close to be posted for merging :)
I guess we should move files around to have:
drivers/mfd/cbus-retu.c
drivers/mfd/cbus-tahvo.c
drivers/rtc/rtc-cbus-retu.c
...
Anything else remaining to do?
Also the following patch was needed to get this to boot
with interrupts working. Maybe you have a better plan
for getting the retu irq_base?
Anyways, since n8x0 boots and stays up, we know it's
working, so I've pushed them all to the cbus branch.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Wed, 9 Feb 2011 18:36:16 -0800
Subject: [PATCH] cbus: Fix nested interrupts for retu
We need to add the retu irq base number to the interrupt
number for children.
This could be done by passing the interrupt base for
children in platform_data also I guess.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/cbus/retu-headset.c
+++ b/drivers/cbus/retu-headset.c
@@ -258,7 +258,7 @@ static int __init retu_headset_probe(struct platform_device
*pdev)
setup_timer(hs-detect_timer, retu_headset_detect_timer,
(unsigned long) hs);
- r = request_threaded_irq(RETU_INT_HOOK, NULL,
+ r = request_threaded_irq(CBUS_RETU_IRQ_BASE + RETU_INT_HOOK, NULL,
retu_headset_hook_interrupt, 0, hookdet, hs);
if (r != 0) {
dev_err(pdev-dev, hookdet IRQ not available\n);
@@ -290,7 +290,7 @@ static int retu_headset_remove(struct platform_device *pdev)
device_remove_file(pdev-dev, dev_attr_enable_det);
retu_headset_disable(hs);
retu_headset_det_disable(hs);
- free_irq(RETU_INT_HOOK, hs);
+ free_irq(CBUS_RETU_IRQ_BASE + RETU_INT_HOOK, hs);
input_unregister_device(hs-idev);
input_free_device(hs-idev);
--- a/drivers/cbus/retu-pwrbutton.c
+++ b/drivers/cbus/retu-pwrbutton.c
@@ -83,7 +83,7 @@ static int __init retubutton_probe(struct platform_device
*pdev)
goto err0;
}
- pwr-irq = RETU_INT_PWR;
+ pwr-irq = CBUS_RETU_IRQ_BASE + RETU_INT_PWR;
platform_set_drvdata(pdev, pwr);
ret = request_threaded_irq(pwr-irq, NULL, retubutton_irq, 0,
--- a/drivers/cbus/retu-rtc.c
+++ b/drivers/cbus/retu-rtc.c
@@ -88,15 +88,15 @@ static int retu_rtc_init_irq(struct retu_rtc *rtc)
{
int ret;
- ret = request_threaded_irq(RETU_INT_RTCS, NULL, retu_rtc_interrupt,
+ ret = request_threaded_irq(CBUS_RETU_IRQ_BASE + RETU_INT_RTCS, NULL,
retu_rtc_interrupt,
0, RTCS, rtc);
if (ret != 0)
return ret;
- ret = request_threaded_irq(RETU_INT_RTCA, NULL, retu_rtc_interrupt,
+ ret = request_threaded_irq(CBUS_RETU_IRQ_BASE + RETU_INT_RTCA, NULL,
retu_rtc_interrupt,
0, RTCA, rtc);
if (ret != 0) {
- free_irq(RETU_INT_RTCS, rtc);
+ free_irq(CBUS_RETU_IRQ_BASE + RETU_INT_RTCS, rtc);
return ret;
}
@@ -235,8 +235,8 @@ static int __init retu_rtc_probe(struct platform_device
*pdev)
return 0;
err2:
- free_irq(RETU_INT_RTCS, rtc);
- free_irq(RETU_INT_RTCA, rtc);
+ free_irq(CBUS_RETU_IRQ_BASE + RETU_INT_RTCS, rtc);
+ free_irq(CBUS_RETU_IRQ_BASE + RETU_INT_RTCA, rtc);
err1:
kfree(rtc);
@@ -249,8 +249,8 @@ static int __devexit retu_rtc_remove(struct platform_device
*pdev)
{
struct retu_rtc *rtc = platform_get_drvdata(pdev);
- free_irq(RETU_INT_RTCS, rtc);
- free_irq(RETU_INT_RTCA, rtc);
+ free_irq(CBUS_RETU_IRQ_BASE + RETU_INT_RTCS, rtc);
+ free_irq(CBUS_RETU_IRQ_BASE + RETU_INT_RTCA, rtc);
rtc_device_unregister(rtc-rtc);
kfree(rtc);
--
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 v5 2/4] TI816X: Update common OMAP machine specific sources
Tony Lindgren wrote on Thursday, February 10, 2011 7:18 AM: * Tony Lindgren t...@atomide.com [110209 17:45]: We should just have separate struct map_desc omapti816x_io_desc[] then. Maybe have a common struct map_desc omap3_io_desc[] and then separate omap3xxx_io_desc and omapti816x_io_desc? Oh and this will work just fine for map_io without having cpu_is_omap macros working yet because we call set_globals from the board file with the processor class data. Tony So probably I need to create another function (ti816x_map_common_io()) to map just the L4 slow region and call it from board file (after set globals) as distinguishing between OMAP3xxx and TI816X is not possible at that time inside omap34xx_map_common_io() as they both have same class. Does this approach look ok? Thanks. 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
Re: [PATCH v5 0/5] omap: mailbox: hwmod support
On Thu, Feb 3, 2011 at 12:57 AM, Omar Ramirez Luna omar.rami...@ti.com wrote: Mailbox hwmod support for OMAP 2,3,4. This was tested on OMAP3 (3430, 3630), minor testing was made on OMAP4. No testing on OMAP2 since I don't have the hardware. Highlights from v5 include the comments received from previous version v4[1]. Benoit Cousson (1): OMAP4: hwmod data: add mailbox data Felipe Contreras (2): OMAP3: hwmod data: add mailbox data OMAP: mailbox: build device using omap_device/omap_hwmod Omar Ramirez Luna (1): OMAP: mailbox: use runtime pm for clk and sysc handling omar ramirez (1): OMAP2: hwmod data: add mailbox data arch/arm/mach-omap2/devices.c | 98 +--- arch/arm/mach-omap2/mailbox.c | 67 ++- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 74 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 73 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 72 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 67 +++ 6 files changed, 308 insertions(+), 143 deletions(-) Boot tested mainline v2.6.38-rc4 along with this 5 patch series on Omap 2420,2430 SDPs. Tested-by: Sourav Poddarsourav.pod...@ti.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 v5 0/5] omap: mailbox: hwmod support
From: ext Tony Lindgren t...@atomide.com Subject: Re: [PATCH v5 0/5] omap: mailbox: hwmod support Date: Wed, 9 Feb 2011 10:32:19 -0800 * Omar Ramirez Luna omar.rami...@ti.com [110202 11:37]: Mailbox hwmod support for OMAP 2,3,4. Hiroshi, any comments on these? Well, I haven't followed hwmod much. If Kevin is ok, ok for me. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] OMAP2PLUS: clocks: Align DSS clock names and roles
On Mon, 31 Jan 2011, Sumit Semwal wrote: Currently, clock database has dev, clock-name tuples for DSS2. Because of this, the clock names are different across different OMAP platforms. This patch aligns the DSS2 clock names and roles across OMAP 2420, 2430, 3xxx, 44xx platforms in the clock databases, hwmod databases for opt-clocks, and DSS clock handling. This ensures that clk_get/put/enable/disable APIs in DSS can use uniform role names. Signed-off-by: Sumit Semwal sumit.sem...@ti.com Based on a quick glance, this is Acked-by: Paul Walmsley p...@pwsan.com Tomi or Tony, feel free to take this - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-omap tree
Hi! I am not able to find linux-omap tree on git.kernel.org. But linux-omap-pm is present. Something might have gone wrong while maintaining the tree. Is there any other place where the tree is being mirrored? -Thanks, Mayuresh -- 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-omap tree
Mayuresh, Can you try this link: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Regards, Keerthy On Thu, Feb 10, 2011 at 11:57 AM, Janorkar, Mayuresh ma...@ti.com wrote: Hi! I am not able to find linux-omap tree on git.kernel.org. But linux-omap-pm is present. Something might have gone wrong while maintaining the tree. Is there any other place where the tree is being mirrored? -Thanks, Mayuresh -- 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 -- Regards and Thanks, Keerthy -- 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-omap tree
Thanks Keerthy that link is working fine. My concern was that on git.kernel.org (Main Page) I am unable to find linux-omap. -Thanks, Mayuresh -Original Message- From: J, KEERTHY Sent: Thursday, February 10, 2011 12:13 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org Subject: Re: linux-omap tree Mayuresh, Can you try this link: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Regards, Keerthy On Thu, Feb 10, 2011 at 11:57 AM, Janorkar, Mayuresh ma...@ti.com wrote: Hi! I am not able to find linux-omap tree on git.kernel.org. But linux-omap-pm is present. Something might have gone wrong while maintaining the tree. Is there any other place where the tree is being mirrored? -Thanks, Mayuresh -- 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 -- Regards and Thanks, Keerthy -- 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-omap tree
On Thu, Feb 10, 2011 at 13:18, Janorkar, Mayuresh ma...@ti.com wrote: Thanks Keerthy that link is working fine. My concern was that on git.kernel.org (Main Page) I am unable to find linux-omap. http://git.kernel.org/?s=omap - viola Linux-omap is there http://git.kernel.org/?s=linux-omap - linux-omap not matched I just think we are catching gitweb on kernel.org at a bad time :( 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
