RE: [RFC] Common mechanism to identify Si revision
-Original Message- From: Olof Johansson [mailto:o...@lixom.net] Sent: Sunday, September 06, 2009 6:17 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [RFC] Common mechanism to identify Si revision On Thu, Sep 03, 2009 at 04:14:28PM +0530, Premi, Sanjeev wrote: Hi, Currently there are multiple mechanisms for identifying the si revisions. Most places the comparison is against omap_rev() as a whole number. Example: arch/arm/mach-omap2/board-3430sdp.c:695:if (omap_rev() OMAP3430_REV_ES1_0) arch/arm/mach-omap2/board-3430sdp.c:728:if (omap_rev() OMAP3430_REV_ES1_0) Then, there are custom macros. Example (cpu.h): #define CHIP_GE_OMAP3430ES3_1 (CHIP_IS_OMAP3430ES3_1) #define CHIP_GE_OMAP3430ES3 (CHIP_IS_OMAP3430ES3_0 | \ CHIP_GE_OMAP3430ES3_1) #define CHIP_GE_OMAP3430ES2 (CHIP_IS_OMAP3430ES2 | \ CHIP_GE_OMAP3430ES3) The problem with comparing against a whole number is that comparison is invalid for another processor series. E.g. OMAP3430 and OMAP3517. Here, I am proposing a common mechanism to identify the si revision; that focuses on the revision bits alone. (See code below) The usage would then be (example): if (omap_rev() OMAP3430_REV_ES1_0) To if (cpu_is_omap34xx() OMAP_REV_GT(OMAP_ES_1_0) What's the purpose of most of these checks in the first place? I can see two immediate needs: 1) To check for various errata and do appropriate workarounds [sp] I believe the only need would be to make easy check if the version has multiple errata fixes and/or enhancements. And, of course, a verbose information to user who may not have (and may not need) information of all the errata/enhancements. Today, there are multiple ways of doing the same thing... Each way builds upon minor issues in the existing one; but adds its own. 2) To check if the current chip has a certain feature Both of these could just as well be abstracted away such that you use tests on the form: if (OMAP_HAS_ERRATA_FOO) ... or: if (OMAP_FEATURE_FOO) ... And then move the actual checking of a feature into the header file where the errata/feature setups are defined. [sp I have submitted a patch that takes the first step toward this: http://marc.info/?l=linux-omapm=125050987112798w=2 ...still waiting to hear from Tony on this. There's two major benefits to this: 1) Readability. No need to sit and look up in a manual why there's a check for version X here. (and/or no need to add a specific comment about it). 2) Keeping changes centralized. If there's a new revision or chip, there's just one header file to update, not 20 different source files. For example, a bunch of the checks in pm34xx.c would be nicer to have as: if (OMAP_HAS_USBHOST()) [sp] Can you look and comment on this discussion as well: http://marc.info/?l=linux-omapm=125017671720718w=2 Best regards, Sanjeev Then the current settings. -Olof -- 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] ARM: OMAP3: evm: initialize vmmc and vmmc_aux regulators
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-omap3evm.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 35f6075..ce755c3 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -27,6 +27,8 @@
#include linux/i2c/twl4030.h
#include linux/usb/otg.h
+#include linux/regulator/machine.h
+
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -92,6 +94,44 @@ static inline void __init omap3evm_init_smc911x(void)
gpio_direction_input(OMAP3EVM_ETHR_GPIO_IRQ);
}
+static struct regulator_consumer_supply omap3evm_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+static struct regulator_consumer_supply omap3evm_vsim_supply = {
+ .supply = vmmc_aux,
+};
+
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
+static struct regulator_init_data omap3evm_vmmc1 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3evm_vmmc1_supply,
+};
+
+/* VSIM for MMC1 pins DAT4..DAT7 (2 mA, plus card == max 50 mA) */
+static struct regulator_init_data omap3evm_vsim = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 300,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3evm_vsim_supply,
+};
+
static struct twl4030_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -134,6 +174,10 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
mmc[0].gpio_cd = gpio + 0;
twl4030_mmc_init(mmc);
+ /* link regulators to MMC adapters */
+ omap3evm_vmmc1_supply.dev = mmc[0].dev;
+ omap3evm_vsim_supply.dev = mmc[0].dev;
+
/*
* Most GPIOs are for USB OTG. Some are mostly sent to
* the P2 connector; notably LEDA for the LCD backlight.
@@ -199,6 +243,8 @@ static struct twl4030_platform_data omap3evm_twldata = {
.madc = omap3evm_madc_data,
.usb= omap3evm_usb_data,
.gpio = omap3evm_gpio_data,
+ .vmmc1 = omap3evm_vmmc1,
+ .vsim = omap3evm_vsim,
};
static struct i2c_board_info __initdata omap3evm_i2c_boardinfo[] = {
--
1.6.0.6
--
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/1] DSPBRIDGE: don't use potential invalid pointer
From: Andy Shevchenko ext-andriy.shevche...@nokia.com Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com --- drivers/dsp/bridge/rmgr/proc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index 832930e..52e2d54 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -323,6 +323,7 @@ PROC_Attach(u32 uProcessor, OPTIONAL CONST struct DSP_PROCESSORATTRIN *pAttrIn, PROC_Attach: Could not allocate storage for notification \n); MEM_FreeObject(pProcObject); + goto func_end; } #ifndef RES_CLEANUP_DISABLE spin_lock(pr_ctxt-proc_list_lock); -- 1.5.6.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 8/10] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
Hi Subbu,
From: ext C.A, Subramaniam subramaniam...@ti.com
Subject: [PATCH 8/10] omap mailbox: OMAP4-Mailbox - Adds code changes to
support OMAP4 mailbox.
Date: Fri, 4 Sep 2009 13:48:11 +0200
From eeaa22aff9df8027f91884ee78328028bd5a6782 Mon Sep 17 00:00:00 2001
From: C A Subramaniam subramaniam...@ti.com
Date: Thu, 3 Sep 2009 17:53:27 +0530
Subject: [PATCH 8/10] omap mailbox: OMAP4-Mailbox - Adds code changes to
support OMAP4 mailbox.
This patch adds code changes in the mailbox driver module to
add support for OMAP4 mailbox.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: C A Subramaniam subramaniam...@ti.com
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 156
+
1 files changed, 125 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 6f71f37..4ab3e1d 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -18,21 +18,36 @@
#include mach/mailbox.h
#include mach/irqs.h
+#define DRV_NAME omap2-mailbox
+
#define MAILBOX_REVISION 0x000
#define MAILBOX_SYSCONFIG0x010
#define MAILBOX_SYSSTATUS0x014
#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
#define MAILBOX_FIFOSTATUS(m)(0x080 + 4 * (m))
#define MAILBOX_MSGSTATUS(m) (0x0c0 + 4 * (m))
+
+#ifdef CONFIG_ARCH_OMAP4
+#define MAILBOX_IRQSTATUS(u) (0x104 + 10 * (u))
+#define MAILBOX_IRQENABLE(u) (0x108 + 10 * (u))
+#define MAILBOX_IRQENABLE_CLR(u) (0x10c + 10 * (u))
+#else
#define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u))
#define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u))
+#endif
-#define MAILBOX_IRQ_NEWMSG(u)(1 (2 * (u)))
-#define MAILBOX_IRQ_NOTFULL(u) (1 (2 * (u) + 1))
+#define MAILBOX_IRQ_NEWMSG(m)(1 (2 * (m)))
+#define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1))
+#ifdef CONFIG_ARCH_OMAP4
+#define MBOX_REG_SIZE0x130
+#else
#define MBOX_REG_SIZE0x120
+#endif
+
#define MBOX_NR_REGS (MBOX_REG_SIZE / sizeof(u32))
+
static void __iomem *mbox_base;
struct omap_mbox2_fifo {
@@ -49,9 +64,13 @@ struct omap_mbox2_priv {
u32 newmsg_bit;
u32 notfull_bit;
u32 ctx[MBOX_NR_REGS];
+#ifdef CONFIG_ARCH_OMAP4
+ unsigned long irqdisable;
+#endif
};
static struct clk *mbox_ick_handle;
+static int mbox_configured;
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq);
@@ -70,31 +89,37 @@ static inline void mbox_write_reg(u32 val, size_t ofs)
static int omap2_mbox_startup(struct omap_mbox *mbox)
{
unsigned int l;
+ if (!mbox_configured) {
I think that this kind of checking can be done in omap_mbox_get() in
plat-omap/mailbox.c and it would be more logical since
mach-omap2/mailbox.c is supposed to provide quite bacic feature
simply which omap mailbox h/w has. So keeing this code simple, but
adding some logic onto omap_mbox_get() would make sense.
+ mbox_ick_handle = clk_get(NULL, mailboxes_ick);
+ if (IS_ERR(mbox_ick_handle)) {
+ printk(KERN_ERR Could not get mailboxes_ick\n);
+ return -ENODEV;
+ }
+ clk_enable(mbox_ick_handle);
- mbox_ick_handle = clk_get(NULL, mailboxes_ick);
- if (IS_ERR(mbox_ick_handle)) {
- printk(Could not get mailboxes_ick\n);
- return -ENODEV;
- }
- clk_enable(mbox_ick_handle);
-
- l = mbox_read_reg(MAILBOX_REVISION);
- pr_info(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l 0x0f));
-
- /* set smart-idle autoidle */
- l = mbox_read_reg(MAILBOX_SYSCONFIG);
- l |= 0x0011;
- mbox_write_reg(l, MAILBOX_SYSCONFIG);
+ l = mbox_read_reg(MAILBOX_REVISION);
+ pr_info(omap mailbox rev %d.%d\n, (l 0xf0) 4,
+ (l 0x0f));
+ /* set smart-idle autoidle */
+ l = mbox_read_reg(MAILBOX_SYSCONFIG);
+ l |= 0x0011;
+ mbox_write_reg(l, MAILBOX_SYSCONFIG);
+ }
+ mbox_configured++;
omap2_mbox_enable_irq(mbox, IRQ_RX);
return 0;
}
static void omap2_mbox_shutdown(struct omap_mbox *mbox)
-{
- clk_disable(mbox_ick_handle);
- clk_put(mbox_ick_handle);
+{if (mbox_configured 0)
+ mbox_configured--;
+ if (!mbox_configured) {
+ clk_disable(mbox_ick_handle);
+ clk_put(mbox_ick_handle);
+ mbox_ick_handle = NULL;
+ }
}
/* Mailbox FIFO handle functions */
@@ -123,7 +148,7 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
Re: [PATCH 1/10] omap mailbox: OMAP4-Mailbox - Add build specific changes to support OMAP4 mailbox.
From: ext C.A, Subramaniam subramaniam...@ti.com Subject: RE: [PATCH 1/10] omap mailbox: OMAP4-Mailbox - Add build specific changes to support OMAP4 mailbox. Date: Mon, 7 Sep 2009 10:27:22 +0200 Signed-off-by: C A Subramaniam subramaniam...@ti.com Signed-off-by: Ramesh Gupta G grgu...@ti.com --- arch/arm/mach-omap2/Makefile |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 735bae5..4bb426d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -39,6 +39,10 @@ endif obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o +# MAILBOX I think that the above line is not necessary since the module names are enough self-explanatory, a little bit nitpicky, though I have followed the existing convention present in the Makefile (Power management, clock framework,etc.) as follows: # Power Management ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_PM_DEBUG)+= pm-debug.o endif # Clock framework obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o Please let me know if you still believe that the line needs to be removed. I understand that you followed kind of convention, but I still think that these comments don't make so much sense since these module names are apparently enough self-explanatory. -- 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/10] omap mailbox: OMAP4-Mailbox - Add build specific changes to support OMAP4 mailbox.
Hi Hiroshi, -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Monday, September 07, 2009 2:03 PM To: C.A, Subramaniam Cc: linux-omap@vger.kernel.org; t...@atomide.com; r...@arm.linux.org.uk; Kanigeri, Hari; Gupta, Ramesh Subject: Re: [PATCH 1/10] omap mailbox: OMAP4-Mailbox - Add build specific changes to support OMAP4 mailbox. From: ext C.A, Subramaniam subramaniam...@ti.com Subject: RE: [PATCH 1/10] omap mailbox: OMAP4-Mailbox - Add build specific changes to support OMAP4 mailbox. Date: Mon, 7 Sep 2009 10:27:22 +0200 Signed-off-by: C A Subramaniam subramaniam...@ti.com Signed-off-by: Ramesh Gupta G grgu...@ti.com --- arch/arm/mach-omap2/Makefile |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 735bae5..4bb426d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -39,6 +39,10 @@ endif obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o +# MAILBOX I think that the above line is not necessary since the module names are enough self-explanatory, a little bit nitpicky, though I have followed the existing convention present in the Makefile (Power management, clock framework,etc.) as follows: # Power Management ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2)+= pm24xx.o obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3)+= pm34xx.o sleep34xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o endif # Clock framework obj-$(CONFIG_ARCH_OMAP2)+= clock24xx.o obj-$(CONFIG_ARCH_OMAP3)+= clock34xx.o Please let me know if you still believe that the line needs to be removed. I understand that you followed kind of convention, but I still think that these comments don't make so much sense since these module names are apparently enough self-explanatory. Sure! I can remove that. I will send a patch with the changes you had mentioned.-- 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/10] omap mailbox: OMAP4 - Add resources and mailbox register base address for OMAP4 mailbox
Hi Hiroshi,
-Original Message-
From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
Sent: Saturday, September 05, 2009 3:06 PM
To: C.A, Subramaniam
Cc: linux-omap@vger.kernel.org; t...@atomide.com;
r...@arm.linux.org.uk; Kanigeri, Hari; Gupta, Ramesh
Subject: Re: [PATCH 2/10] omap mailbox: OMAP4 - Add resources
and mailbox register base address for OMAP4 mailbox
Hi Subramaniam,
From: ext C.A, Subramaniam subramaniam...@ti.com
Subject: [PATCH 2/10] omap mailbox: OMAP4 - Add resources and
mailbox register base address for OMAP4 mailbox
Date: Fri, 4 Sep 2009 13:47:43 +0200
From 80e74ada510bace7208d59c0f912f9b1077efb45 Mon Sep 17
00:00:00 2001
From: C A Subramaniam subramaniam...@ti.com
Date: Wed, 2 Sep 2009 17:58:57 +0530
Subject: [PATCH 2/10] omap mailbox: OMAP4 - Add resources
and mailbox
register base address for OMAP4 mailbox
This patch adds resource information of mailbox driver for
OMAP4 mailbox module. Register base address also added
Signed-off-by: C A Subramaniam subramaniam...@ti.com
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
arch/arm/mach-omap2/devices.c | 20
+++-
arch/arm/plat-omap/include/mach/omap44xx.h |2 ++
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c index 894cc35..711ed6a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -136,8 +136,11 @@ static inline void omap_init_camera(void)
#if defined(CONFIG_OMAP_MBOX_FWK) ||
defined(CONFIG_OMAP_MBOX_FWK_MODULE)
+#ifdef CONFIG_ARCH_OMAP4
+#define MBOX_REG_SIZE 0x130
+#else
#define MBOX_REG_SIZE 0x120
-
+#endif
I'm not sure if it is still valid or not to support multiple OMAP
architecture(OMAP1/2/3/4?) with a single vmlinux binary, but
the above modification will break this feature.
If it is still valid, I think that the above should be
modified, for example, with using embedded constant values,
like other device resources and the rousources should be
ifded'ed with architecture #:
I think it is better to #ifdef for each architecture like you have suggested.
#ifdef CONFIG_ARCH_OMAP2
static struct resource omap2_mbox_resources[] = {
{
.start = OMAP24XX_MAILBOX_BASE,
.end= OMAP24XX_MAILBOX_BASE +
OMAP2_MBOX_REG_SIZE - 1,
#endif
#ifdef CONFIG_ARCH_OMAP3
@@ -166,6 +169,18 @@ static struct resource
omap3_mbox_resources[] = {
},
};
#endif
#ifdef CONFIG_ARCH_OMAP4
#define OMAP4_MBOX_REG_SIZE 0x130
static struct resource omap4_mbox_resources[] = {
{
.start = OMAP44XX_MAILBOX_BASE,
.end= OMAP44XX_MAILBOX_BASE +
OMAP4_MBOX_REG_SIZE - 1,
.flags = IORESOURCE_MEM,
},
{
.start = INT_44XX_MAIL_U0_MPU,
.flags = IORESOURCE_IRQ,
},
};
#endif
+
static struct platform_device mbox_device = {
.name = omap2-mailbox,
.id = -1,
@@ -179,6 +194,9 @@ static inline void omap_init_mbox(void)
} else if (cpu_is_omap3430()) {
mbox_device.num_resources =
ARRAY_SIZE(omap3_mbox_resources);
mbox_device.resource = omap3_mbox_resources;
+ } else if (cpu_is_omap44xx()) {
+ mbox_device.num_resources =
ARRAY_SIZE(omap4_mbox_resources);
+ mbox_device.resource = omap4_mbox_resources;
} else {
pr_err(%s: platform not supported\n, __func__);
return;
diff --git a/arch/arm/plat-omap/include/mach/omap44xx.h
b/arch/arm/plat-omap/include/mach/omap44xx.h
index 52f2f85..6a545d3 100644
--- a/arch/arm/plat-omap/include/mach/omap44xx.h
+++ b/arch/arm/plat-omap/include/mach/omap44xx.h
@@ -44,5 +44,7 @@
#define OMAP44XX_WKUPGEN_BASE 0x48281000
#define OMAP44XX_VA_WKUPGEN_BASE
IO_ADDRESS(OMAP44XX_WKUPGEN_BASE)
+#define OMAP44xx_MAILBOX_BASE (L4_44XX_BASE + 0xF4000)
From naming consistency, can the above be, OMAP44XX_MAILBOX_BASE ?
I agree. I will incoprporate this change and send a patch.
+
#endif /* __ASM_ARCH_OMAP44XX_H */
--
1.5.3.2
--
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 10/10] omap mailbox: OMAP4 Mailbox-driver Patch to support tasklet implementation
From: ext C.A, Subramaniam subramaniam...@ti.com
Subject: [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver Patch to support
tasklet implementation
Date: Fri, 4 Sep 2009 13:48:45 +0200
From e759173e77f73fabce5177b4f685df20b16c6922 Mon Sep 17 00:00:00 2001
From: C A Subramaniam subramaniam...@ti.com
Date: Thu, 3 Sep 2009 17:42:35 +0530
Subject: [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver Patch to support
tasklet
implementation
This patch uses a tasklet implementation for
sending mailbox messages.
Signed-off-by: C A Subramaniam subramaniam...@ti.com
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 43 ++-
arch/arm/plat-omap/include/mach/mailbox.h | 16 +-
arch/arm/plat-omap/mailbox.c | 80
++---
3 files changed, 81 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 52a1670..45aea98 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -236,6 +237,17 @@ static struct omap_mbox_ops omap2_mbox_ops = {
.restore_ctx= omap2_mbox_restore_ctx,
};
+
+static struct omap_mbox_task omap_mbox_1_tasklet = {
+ .arg= NULL,
+};
+
+static struct omap_mbox_task omap_mbox_2_tasklet = {
+ .arg= NULL,
+};
As I described in the comment on [PATCH 8/10], I think that it would
be better to keep mach-omap2/mailbox.c simple and to add some
additional logic on plat-omap/mailbox.c.
Would it be possbile to move this tasklet implementation to
plat-omap/mailbox.c?
+
+
+
/*
* MAILBOX 0: ARM - DSP,
* MAILBOX 1: ARM - DSP.
@@ -272,6 +284,7 @@ struct omap_mbox mbox_1_info = {
.name = mailbox-1,
.ops= omap2_mbox_ops,
.priv = omap2_mbox_1_priv,
+ .tx_tasklet = omap_mbox_1_tasklet,
};
EXPORT_SYMBOL(mbox_1_info);
#else
@@ -305,8 +318,10 @@ struct omap_mbox mbox_2_info = {
.name = mailbox-2,
.ops= omap2_mbox_ops,
.priv = omap2_mbox_2_priv,
+ .tx_tasklet = omap_mbox_2_tasklet,
};
EXPORT_SYMBOL(mbox_2_info);
+
#endif
diff --git a/arch/arm/plat-omap/include/mach/mailbox.h
b/arch/arm/plat-omap/include/mach/mailbox.h
index bf06953..5271345 100644
--- a/arch/arm/plat-omap/include/mach/mailbox.h
+++ b/arch/arm/plat-omap/include/mach/mailbox.h
@@ -28,8 +28,10 @@ struct omap_mbox_ops {
int (*fifo_empty)(struct omap_mbox *mbox);
int (*fifo_full)(struct omap_mbox *mbox);
/* irq */
- void(*enable_irq)(struct omap_mbox *mbox, omap_mbox_irq_t
irq);
- void(*disable_irq)(struct omap_mbox *mbox, omap_mbox_irq_t
irq);
+ void(*enable_irq)(struct omap_mbox *mbox,
+ omap_mbox_irq_t irq);
+ void(*disable_irq)(struct omap_mbox *mbox,
+ omap_mbox_irq_t irq);
void(*ack_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
int (*is_irq)(struct omap_mbox *mbox, omap_mbox_irq_t irq);
/* ctx */
@@ -45,12 +47,22 @@ struct omap_mbox_queue {
struct omap_mbox*mbox;
};
+struct omap_mbox_task{
+ spinlock_t lock;
+ struct tasklet_struct *t;
+ mbox_msg_t msg;
+ void*arg;
+};
+
+
struct omap_mbox {
char*name;
unsigned intirq;
struct omap_mbox_queue *txq, *rxq;
+ struct omap_mbox_task *tx_tasklet;
+
struct omap_mbox_ops*ops;
mbox_msg_t seq_snd, seq_rcv;
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 84cf6af..b5e53d4 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -63,60 +63,49 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
/*
* message sender
*/
-static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
+static void __mbox_msg_send(unsigned long tx)
{
+ struct omap_mbox_task *tx_data = (struct omap_mbox_task *)tx;
+ struct omap_mbox *mbox = (struct omap_mbox *)tx_data-arg;
+ mbox_msg_t msg = tx_data-msg;
int ret = 0, i = 1000;
while (mbox_fifo_full(mbox)) {
- if (mbox-ops-type == OMAP_MBOX_TYPE2)
- return -1;
- if (--i == 0)
- return -1;
+ if (mbox-ops-type == OMAP_MBOX_TYPE2) {
+ printk(KERN_ERR Invalid mailbox type\n);
+ return ;
+ }
+ if (--i == 0) {
+ printk(KERN_ERR Time out writing to mailbox\n);
+ return ;
+ }
udelay(1);
}
mbox_fifo_write(mbox, msg);
- return ret;
-}
-
-struct
Re: [RFC] Common mechanism to identify Si revision
Hi, On Mon, Sep 07, 2009 at 11:33:32AM +0530, Premi, Sanjeev wrote: What's the purpose of most of these checks in the first place? I can see two immediate needs: 1) To check for various errata and do appropriate workarounds [sp] I believe the only need would be to make easy check if the version has multiple errata fixes and/or enhancements. And, of course, a verbose information to user who may not have (and may not need) information of all the errata/enhancements. Today, there are multiple ways of doing the same thing... Each way builds upon minor issues in the existing one; but adds its own. Yeah, ok. I was just fearing that this added ES-level checking would be used to clutter up the code with extra testing instead of hiding it away in header files. But it seems like most of it is covered already. 2) To check if the current chip has a certain feature Both of these could just as well be abstracted away such that you use tests on the form: if (OMAP_HAS_ERRATA_FOO) ... or: if (OMAP_FEATURE_FOO) ... And then move the actual checking of a feature into the header file where the errata/feature setups are defined. [sp I have submitted a patch that takes the first step toward this: http://marc.info/?l=linux-omapm=125050987112798w=2 ...still waiting to hear from Tony on this. Looks good. I didn't subscribe to linux-omap until recently so I don't have the original emails (and thus can't comment on them), but my only feedback is that it really doesn't belong in /proc/cpuinfo whether a SoC has SGX on-chip or not. It'd be better to move that information somewhere else. Keep in mind that adding information to a /proc file means that you are changing an API that we would need to live with forever. There's two major benefits to this: 1) Readability. No need to sit and look up in a manual why there's a check for version X here. (and/or no need to add a specific comment about it). 2) Keeping changes centralized. If there's a new revision or chip, there's just one header file to update, not 20 different source files. For example, a bunch of the checks in pm34xx.c would be nicer to have as: if (OMAP_HAS_USBHOST()) [sp] Can you look and comment on this discussion as well: http://marc.info/?l=linux-omapm=125017671720718w=2 I think it is a great step in the right direction. My only concern is that the usage conventions are confusing: OMAP3_HAS_FEATURE(neon, NEON) Just seeing that, what is the difference between neon and NEON? Also, it always requires two consecutive calls to check for a feature (get the flags, then check the mask). I would personally prefer to keep a global that is initialized early in boot (called __omap_features or so -- the __-prefix would indicate that it is not for direct use in code), then have OMAP3_HAS_FEATURE() just look at that value instead of having it passed in. It's not like it changes during runtime anyway. It can be debated if the format should then be OMAP3_HAS_FEATURE_SGX or OMAP3_HAS_FEATURE(SGX), but either is fine with me. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Common mechanism to identify Si revision
On Sep 7, 2009, at 8:02 AM, Premi, Sanjeev wrote:
I think it is a great step in the right direction. My only concern is
that the usage conventions are confusing:
OMAP3_HAS_FEATURE(neon, NEON)
[sp] This is only used to declare a function that would translate to:
unsigned int omap3_has_neon(void)
{
return (omap_features OMAP_HAS_NEON);
}
EXPORT_SYMBOL(omap3_has_neon);
A user would always do something like:
if (omap_has_neon())
do_neon_specific_stuff();
Ok, all is well then. :)
-Olof
--
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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Tue, Aug 18, 2009 at 08:31:49AM +0530, Rabin Vincent wrote:
Here's a fixed version:
And here's my revised version with these fixes in. I changed the
while loop to a do..while loop instead (since we will always have
at least one memory bank, it's pointless doing that test for the
first iteration.)
Acks and tested-bys would be useful please.
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 376be1a..cefedf0 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -218,7 +218,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
*
* page_to_pfn(page) convert a struct page * to a PFN number
* pfn_to_page(pfn) convert a _valid_ PFN number to struct page *
- * pfn_valid(pfn) indicates whether a PFN number is valid
*
* virt_to_page(k)convert a _valid_ virtual address to struct page *
* virt_addr_valid(k) indicates whether a virtual address is valid
@@ -227,10 +226,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
#define ARCH_PFN_OFFSETPHYS_PFN_OFFSET
-#ifndef CONFIG_SPARSEMEM
-#define pfn_valid(pfn) ((pfn) = PHYS_PFN_OFFSET (pfn)
(PHYS_PFN_OFFSET + max_mapnr))
-#endif
-
#define virt_to_page(kaddr)pfn_to_page(__pa(kaddr) PAGE_SHIFT)
#define virt_addr_valid(kaddr) ((unsigned long)(kaddr) = PAGE_OFFSET
(unsigned long)(kaddr) (unsigned long)high_memory)
@@ -247,18 +242,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
#define arch_pfn_to_nid(pfn) PFN_TO_NID(pfn)
#define arch_local_page_offset(pfn, nid) LOCAL_MAP_NR((pfn) PAGE_SHIFT)
-#define pfn_valid(pfn) \
- ({ \
- unsigned int nid = PFN_TO_NID(pfn); \
- int valid = nid MAX_NUMNODES; \
- if (valid) {\
- pg_data_t *node = NODE_DATA(nid); \
- valid = (pfn - node-node_start_pfn) \
- node-node_spanned_pages; \
- } \
- valid; \
- })
-
#define virt_to_page(kaddr)\
(ADDR_TO_MAPBASE(kaddr) + LOCAL_MAP_NR(kaddr))
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index 9c746af..3a32af4 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -194,6 +194,10 @@ typedef unsigned long pgprot_t;
typedef struct page *pgtable_t;
+#ifndef CONFIG_SPARSEMEM
+extern int pfn_valid(unsigned long);
+#endif
+
#include asm/memory.h
#endif /* !__ASSEMBLY__ */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8277802..2542583 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -15,6 +15,7 @@
#include linux/mman.h
#include linux/nodemask.h
#include linux/initrd.h
+#include linux/sort.h
#include linux/highmem.h
#include asm/mach-types.h
@@ -334,12 +335,43 @@ static void __init bootmem_free_node(int node, struct
meminfo *mi)
free_area_init_node(node, zone_size, start_pfn, zhole_size);
}
+#ifndef CONFIG_SPARSEMEM
+int pfn_valid(unsigned long pfn)
+{
+ struct meminfo *mi = meminfo;
+ unsigned int left = 0, right = mi-nr_banks;
+
+ do {
+ unsigned int mid = (right + left) / 2;
+ struct membank *bank = mi-bank[mid];
+
+ if (pfn bank_pfn_start(bank))
+ right = mid;
+ else if (pfn = bank_pfn_end(bank))
+ left = mid + 1;
+ else
+ return 1;
+ } while (left right);
+ return 0;
+}
+EXPORT_SYMBOL(pfn_valid);
+#endif
+
+static int __init meminfo_cmp(const void *_a, const void *_b)
+{
+ const struct membank *a = _a, *b = _b;
+ long cmp = bank_pfn_start(a) - bank_pfn_start(b);
+ return cmp 0 ? -1 : cmp 0 ? 1 : 0;
+}
+
void __init bootmem_init(void)
{
struct meminfo *mi = meminfo;
unsigned long memend_pfn = 0;
int node, initrd_node;
+ sort(mi-bank, mi-nr_banks, sizeof(mi-bank[0]), meminfo_cmp, NULL);
+
/*
* Locate which node contains the ramdisk image, if any.
*/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] OMAP3 : PM : Handle variable length OPP tables
Hi all,
There is no generic function to translate an OPP to FREQ and vice versa.
Came across the problem while trying to submit a follow-up to earlier
patch for change in mpurate via bootargs.
The function get_opp in resource34xx.c, but it is always called with an
explicit addition of MAX_VDDn_OPP e.g.
opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk-rate);
opp = get_opp(l3_opps + MAX_VDD2_OPP, clk-rate);
This is 'addition' is required as there is no encapsulation of the
MIN and MAX VDDs associated to the table.
The patch below fixes this issue; buy creating a 'table' object with
necessary information. It can also help in getting rid of the
empty {0, 0, 0} at index 0 of each OPP table.
At the moment, it does not break any functionality in resource34xx.c;
migration to this encapsulation can be taken as next step.
This code is bare 'git-diff' for early comments. Formal patch to follow...
Best regards,
Sanjeev
diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h
b/arch/arm/plat-omap/include/mach/omap-pm.h
index 583e540..2357784 100644
--- a/arch/arm/plat-omap/include/mach/omap-pm.h
+++ b/arch/arm/plat-omap/include/mach/omap-pm.h
@@ -33,6 +33,20 @@ struct omap_opp {
u16 vsel;
};
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
+
extern struct omap_opp *mpu_opps;
extern struct omap_opp *dsp_opps;
extern struct omap_opp *l3_opps;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fec7d00..c90b1af 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -33,6 +33,7 @@
#include mach/powerdomain.h
#include mach/resource.h
#include mach/omap34xx.h
+#include mach/omap-pm.h
#include prm-regbits-34xx.h
#include pm.h
@@ -281,3 +282,50 @@ static int __init omap_pm_init(void)
return error;
}
late_initcall(omap_pm_init);
+
+/*
+ * Get frequency corresponding to an OPP
+ */
+int opp_to_freq(unsigned int* freq, struct omap_opp_table* table, u8 opp)
+{
+int i, found=0;
+
+if (table table-opps) {
+for (i=table-min; table-opps[i].opp_id = table-max; i++)
+if (table-opps[i].opp_id == opp) {
+found = 1;
+break;
+}
+
+if (found) {
+*freq = table-opps[i].rate;
+return 1;
+}
+}
+
+return 0;
+}
+
+/*
+ * Get OPP corresponding to a frequency
+ */
+int freq_to_opp(u8* opp, struct omap_opp_table* table, unsigned long freq)
+{
+int i, found=0;
+
+if (table table-opps) {
+for (i=table-min; table-opps[i].opp_id = table-max; i++)
+if (table-opps[i].rate == freq) {
+found = 1;
+break;
+}
+
+if (found) {
+*opp = table-opps[i].opp_id;
+return 1;
+}
+}
+
+return 0;
+}
+
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send
On Fri, Sep 04, 2009 at 05:18:04PM +0530, C.A, Subramaniam wrote: @@ -114,7 +114,6 @@ int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg, void* arg) } tx_data-msg = msg; - tx_data-arg = arg; What about also removing 'arg' from struct omap_msg_tx_data ? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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 8/10] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
On Fri, Sep 04, 2009 at 05:18:11PM +0530, C.A, Subramaniam wrote:
@@ -70,31 +89,37 @@ static inline void mbox_write_reg(u32 val, size_t ofs)
static int omap2_mbox_startup(struct omap_mbox *mbox)
{
unsigned int l;
+ if (!mbox_configured) {
+ mbox_ick_handle = clk_get(NULL, mailboxes_ick);
+ if (IS_ERR(mbox_ick_handle)) {
+ printk(KERN_ERR Could not get mailboxes_ick\n);
+ return -ENODEV;
+ }
+ clk_enable(mbox_ick_handle);
- mbox_ick_handle = clk_get(NULL, mailboxes_ick);
- if (IS_ERR(mbox_ick_handle)) {
- printk(Could not get mailboxes_ick\n);
- return -ENODEV;
- }
- clk_enable(mbox_ick_handle);
-
- l = mbox_read_reg(MAILBOX_REVISION);
- pr_info(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l 0x0f));
-
- /* set smart-idle autoidle */
- l = mbox_read_reg(MAILBOX_SYSCONFIG);
- l |= 0x0011;
- mbox_write_reg(l, MAILBOX_SYSCONFIG);
+ l = mbox_read_reg(MAILBOX_REVISION);
+ pr_info(omap mailbox rev %d.%d\n, (l 0xf0) 4,
+ (l 0x0f));
+ /* set smart-idle autoidle */
+ l = mbox_read_reg(MAILBOX_SYSCONFIG);
+ l |= 0x0011;
+ mbox_write_reg(l, MAILBOX_SYSCONFIG);
+ }
+ mbox_configured++;
I assume you're doing this because this function can be called multiple
times. What protects this against races?
omap2_mbox_enable_irq(mbox, IRQ_RX);
return 0;
}
static void omap2_mbox_shutdown(struct omap_mbox *mbox)
-{
- clk_disable(mbox_ick_handle);
- clk_put(mbox_ick_handle);
+{if (mbox_configured 0)
+ mbox_configured--;
+ if (!mbox_configured) {
+ clk_disable(mbox_ick_handle);
+ clk_put(mbox_ick_handle);
+ mbox_ick_handle = NULL;
+ }
Same concern - what protects mbox_configured and the associated code against
races?
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
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 8/10] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.
Hi Russell,
Yes, that needs to be taken care of. Hiroshi has suggested that we move this
logic into the omap_mbox_get() function.
Will add code to protect from races conditions while making the change.
Thank you and Regards
Subbu
-Original Message-
From: Russell King [mailto:r...@arm.linux.org.uk]
Sent: Monday, September 07, 2009 8:35 PM
To: C.A, Subramaniam
Cc: linux-omap@vger.kernel.org; t...@atomide.com;
hiroshi.d...@nokia.com; Kanigeri, Hari; Gupta, Ramesh
Subject: Re: [PATCH 8/10] omap mailbox: OMAP4-Mailbox - Adds
code changes to support OMAP4 mailbox.
On Fri, Sep 04, 2009 at 05:18:11PM +0530, C.A, Subramaniam wrote:
@@ -70,31 +89,37 @@ static inline void mbox_write_reg(u32
val, size_t
ofs) static int omap2_mbox_startup(struct omap_mbox *mbox) {
unsigned int l;
+ if (!mbox_configured) {
+ mbox_ick_handle = clk_get(NULL, mailboxes_ick);
+ if (IS_ERR(mbox_ick_handle)) {
+ printk(KERN_ERR Could not get
mailboxes_ick\n);
+ return -ENODEV;
+ }
+ clk_enable(mbox_ick_handle);
- mbox_ick_handle = clk_get(NULL, mailboxes_ick);
- if (IS_ERR(mbox_ick_handle)) {
- printk(Could not get mailboxes_ick\n);
- return -ENODEV;
- }
- clk_enable(mbox_ick_handle);
-
- l = mbox_read_reg(MAILBOX_REVISION);
- pr_info(omap mailbox rev %d.%d\n, (l 0xf0) 4, (l
0x0f));
-
- /* set smart-idle autoidle */
- l = mbox_read_reg(MAILBOX_SYSCONFIG);
- l |= 0x0011;
- mbox_write_reg(l, MAILBOX_SYSCONFIG);
+ l = mbox_read_reg(MAILBOX_REVISION);
+ pr_info(omap mailbox rev %d.%d\n, (l 0xf0) 4,
+ (l 0x0f));
+ /* set smart-idle autoidle */
+ l = mbox_read_reg(MAILBOX_SYSCONFIG);
+ l |= 0x0011;
+ mbox_write_reg(l, MAILBOX_SYSCONFIG);
+ }
+ mbox_configured++;
I assume you're doing this because this function can be
called multiple times. What protects this against races?
omap2_mbox_enable_irq(mbox, IRQ_RX);
return 0;
}
static void omap2_mbox_shutdown(struct omap_mbox *mbox) -{
- clk_disable(mbox_ick_handle);
- clk_put(mbox_ick_handle);
+{ if (mbox_configured 0)
+ mbox_configured--;
+ if (!mbox_configured) {
+ clk_disable(mbox_ick_handle);
+ clk_put(mbox_ick_handle);
+ mbox_ick_handle = NULL;
+ }
Same concern - what protects mbox_configured and the
associated code against races?
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
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 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send
Hi Russell, 'arg' is used later in Patch 10, as part of the tasklet implementation, for writing messages to the mailbox. Should I be removing it in patch 6 and introduce it only for the tasklet implementation? Thank you and regards Subbu -Original Message- From: Russell King [mailto:r...@arm.linux.org.uk] Sent: Monday, September 07, 2009 8:33 PM To: C.A, Subramaniam Cc: linux-omap@vger.kernel.org; t...@atomide.com; hiroshi.d...@nokia.com; Kanigeri, Hari; Gupta, Ramesh Subject: Re: [PATCH 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send On Fri, Sep 04, 2009 at 05:18:04PM +0530, C.A, Subramaniam wrote: @@ -114,7 +114,6 @@ int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg, void* arg) } tx_data-msg = msg; - tx_data-arg = arg; What about also removing 'arg' from struct omap_msg_tx_data ? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send
Subbu, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of C.A, Subramaniam Sent: Monday, September 07, 2009 9:03 PM To: Russell King Cc: linux-omap@vger.kernel.org; t...@atomide.com; hiroshi.d...@nokia.com; Kanigeri, Hari; Gupta, Ramesh Subject: RE: [PATCH 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send Hi Russell, 'arg' is used later in Patch 10, as part of the tasklet implementation, for writing messages to the mailbox. Should I be removing it in patch 6 and introduce it only for the tasklet implementation? Avoid top posting !! -- 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 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send
Santhosh, -Original Message- From: Shilimkar, Santosh Sent: Monday, September 07, 2009 9:08 PM To: C.A, Subramaniam; Russell King Cc: linux-omap@vger.kernel.org; t...@atomide.com; hiroshi.d...@nokia.com; Kanigeri, Hari; Gupta, Ramesh Subject: RE: [PATCH 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send Subbu, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of C.A, Subramaniam Sent: Monday, September 07, 2009 9:03 PM To: Russell King Cc: linux-omap@vger.kernel.org; t...@atomide.com; hiroshi.d...@nokia.com; Kanigeri, Hari; Gupta, Ramesh Subject: RE: [PATCH 6/10] omap mailbox: remove unnecessary arg for omap_mbox_msg_send Hi Russell, 'arg' is used later in Patch 10, as part of the tasklet implementation, for writing messages to the mailbox. Should I be removing it in patch 6 and introduce it only for the tasklet implementation? Avoid top posting !! Thank you for pointing that out. Sorry for the confusion! Thank you and Regards Subbu-- 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] [ARM] omap850: Add missing CPU defines
* OMAP1 platform GPIO was not working correctly on omap850 due to missing
OMAP850
method checks. This is now correctly implemented and working.
* A #if statement in common.c was excluding code for omap730 and 15xx, and
should
have also been excluding the code for omap850. This is now fixed.
* omap850 mux was being done differently/incorrectly for omap850. This is now
fixed.
* INT_IH2_IRQ was not being defined for omap850, causing interrupts to not work
on omap850. This is now fixed.
Reported-by:
Cory Maccarrone darkstar6...@gmail.com
Alistair Buxton a.j.bux...@gmail.com
Angelo Arrifano mik...@gmail.com
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/mux.c | 14 ++
arch/arm/plat-omap/common.c |4 ++--
arch/arm/plat-omap/gpio.c |2 +-
arch/arm/plat-omap/include/mach/entry-macro.S |2 ++
4 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index 721e0d9..78cd6b7 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -75,6 +75,10 @@ MUX_CFG_850(AA17_850_USB_DM, 2, 21,0, 20, 0,
0)
MUX_CFG_850(W16_850_USB_PU_EN, 2, 25,0, 24, 0, 0)
MUX_CFG_850(W17_850_USB_VBUSI, 2, 29,0, 28, 0, 0)
};
+#define OMAP850_PINS_SZARRAY_SIZE(omap850_pins)
+#else
+#define omap850_pins NULL
+#define OMAP850_PINS_SZ0
#endif
#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
@@ -439,10 +443,6 @@ int __init_or_module omap1_cfg_reg(const struct pin_config
*cfg)
cfg-pull_name, cfg-pull_reg, pull_orig, pull);
}
-#ifdef CONFIG_ARCH_OMAP850
- omap_mux_register(omap850_pins, ARRAY_SIZE(omap850_pins));
-#endif
-
#endif
#ifdef CONFIG_OMAP_MUX_ERRORS
@@ -460,6 +460,12 @@ int __init omap1_mux_init(void)
arch_mux_cfg.cfg_reg= omap1_cfg_reg;
}
+ if (cpu_is_omap850()) {
+ arch_mux_cfg.pins = omap850_pins;
+ arch_mux_cfg.size = OMAP850_PINS_SZ;
+ arch_mux_cfg.cfg_reg = omap1_cfg_reg;
+ }
+
if (cpu_is_omap15xx() || cpu_is_omap16xx()) {
arch_mux_cfg.pins = omap1xxx_pins;
arch_mux_cfg.size = OMAP1XXX_PINS_SZ;
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index a6fa786..d076cc1 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -92,7 +92,7 @@ EXPORT_SYMBOL(omap_get_var_config);
#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
-#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX))
+#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850) ||
defined(CONFIG_ARCH_OMAP15XX))
#include linux/clocksource.h
@@ -207,7 +207,7 @@ static int __init omap_init_clocksource_32k(void)
}
arch_initcall(omap_init_clocksource_32k);
-#endif /* !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX)) */
+#endif /* !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850) ||
defined(CONFIG_ARCH_OMAP15XX)) */
/* Global address base setup code */
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 7c70a6a..91ab375 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1659,7 +1659,7 @@ static int __init _omap_gpio_init(void)
__raw_writew(0x, bank-base +
OMAP1610_GPIO_IRQSTATUS1);
__raw_writew(0x0014, bank-base +
OMAP1610_GPIO_SYSCONFIG);
}
- if (cpu_is_omap7xx() bank-method == METHOD_GPIO_730) {
+ if (cpu_is_omap7xx() (bank-method == METHOD_GPIO_730 ||
bank-method == METHOD_GPIO_850)) {
__raw_writel(0x, bank-base +
OMAP730_GPIO_INT_MASK);
__raw_writel(0x, bank-base +
OMAP730_GPIO_INT_STATUS);
diff --git a/arch/arm/plat-omap/include/mach/entry-macro.S
b/arch/arm/plat-omap/include/mach/entry-macro.S
index a559299..19c3198 100644
--- a/arch/arm/plat-omap/include/mach/entry-macro.S
+++ b/arch/arm/plat-omap/include/mach/entry-macro.S
@@ -22,6 +22,8 @@
#error FIXME: OMAP730 doesn't support multiple-OMAP
#elif defined(CONFIG_ARCH_OMAP730)
#define INT_IH2_IRQINT_730_IH2_IRQ
+#elif defined(CONFIG_ARCH_OMAP850)
+#define INT_IH2_IRQ INT_850_IH2_IRQ
#elif defined(CONFIG_ARCH_OMAP15XX)
#define INT_IH2_IRQINT_1510_IH2_IRQ
#elif defined(CONFIG_ARCH_OMAP16XX)
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: OMAP3: Beagleboard: Fix EHCI initialization
On Sep 1, 2009, at 5:55 PM, Steve Sakoman wrote: Enable USB power, use correct gpio for usb_ehci_init Signed-off-by: Steve Sakoman st...@sakoman.com Tested-by: Eric Witcher ewitc...@mindspring.com This patch worked at commit 3dff8750255bf5a1e9a69931b1d8739a65a933d0 of linux-omap-2.6.git master I also needed [PATCH 4/8] ehci: fix phy_reset init in ehci probe [PATCH] omapfb: Reorder Register_framebuffer call to get a clean boot. Build configuration was omap3_beagle_defconfig. --- arch/arm/mach-omap2/board-omap3beagle.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 07aee90..65934ea 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -161,7 +161,7 @@ static int beagle_twl_gpio_setup(struct device *dev, /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */ gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR); - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; @@ -412,7 +412,8 @@ static void __init omap3_beagle_init(void) gpio_direction_output(170, true); usb_musb_init(); - usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61); + usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, false, true, + -EINVAL, 147); omap3beagle_flash_init(); /* Ensure SDRC pins are mux'd for self-refresh */ -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/3] USB: musb: omap: Fix wrong xceivr passing to twl4030
Vikram, -Original Message- From: Pandita, Vikram Sent: Saturday, September 05, 2009 4:35 AM To: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org; davi...@pacbell.net; Gupta, Ajay Kumar; Gadiyar, Anand; felipe.ba...@nokia.com; Pandita, Vikram Subject: [PATCH 2/3] USB: musb: omap: Fix wrong xceivr passing to twl4030 Wrong pointer was getting passed to twl4030 transceiver. Call path is: otg_set_suspend - twl4030_set_suspend drivers/usb/otg/twl4030-usb.c: twl4030_set_suspend() uses: struct twl4030_usb *twl = xceiv_to_twl(x); and xceiv_to_twl is container_of() So the same pointer needs to be passed to otg_set_suspend() as has been used for otg_set_transceiver. A crash is seen without this patch, as twl pointer access is worng musb-xceiv is also taken from otg_get_transceiver() in musb_platform_init(). So this patch is not required. -Ajay Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- drivers/usb/musb/omap2430.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index b957575..ea7a798 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -269,7 +269,7 @@ int musb_platform_suspend(struct musb *musb) l |= ENABLEWAKEUP; /* enable wakeup */ omap_writel(l, OTG_SYSCONFIG); - otg_set_suspend(musb-xceiv, 1); + otg_set_suspend(otg_get_transceiver(), 1); if (musb-set_clock) musb-set_clock(musb-clock, 0); @@ -286,7 +286,7 @@ int musb_platform_resume(struct musb *musb) if (!musb-clock) return 0; - otg_set_suspend(musb-xceiv, 0); + otg_set_suspend(otg_get_transceiver(), 0); if (musb-set_clock) musb-set_clock(musb-clock, 1); -- 1.6.3.3.334.g916e1 -- 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
