[PATCH_v2] watchdog: Convert twl4030_wdt to watchdog core
Convert the twl4030_wdt watchdog driver to watchdog core.
While at there use devm_kzalloc and set the default timeout in order to be
able test this driver with a simple shell script.
Signed-off-by: Jarkko Nikula jarkko.nik...@jollamobile.com
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
---
v2:
- select WATCHDOG_CORE in Kconfig was accidentally put to to OMAP_WATCHDOG
instead of TWL4030_WATCHDOG. Thanks to Aaro Koskinen aaro.koski...@iki.fi
for noticing.
- Added Aaro's Tested-by
---
drivers/watchdog/Kconfig |1 +
drivers/watchdog/twl4030_wdt.c | 183
2 files changed, 35 insertions(+), 149 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 53d7571..89a4140 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -300,6 +300,7 @@ config COH901327_WATCHDOG
config TWL4030_WATCHDOG
tristate TWL4030 Watchdog
depends on TWL4030_CORE
+ select WATCHDOG_CORE
help
Support for TI TWL4030 watchdog. Say 'Y' here to enable the
watchdog timer support for TWL4030 chips.
diff --git a/drivers/watchdog/twl4030_wdt.c b/drivers/watchdog/twl4030_wdt.c
index 249f113..71c283a 100644
--- a/drivers/watchdog/twl4030_wdt.c
+++ b/drivers/watchdog/twl4030_wdt.c
@@ -22,26 +22,12 @@
#include linux/types.h
#include linux/slab.h
#include linux/kernel.h
-#include linux/fs.h
#include linux/watchdog.h
#include linux/platform_device.h
-#include linux/miscdevice.h
-#include linux/uaccess.h
#include linux/i2c/twl.h
#define TWL4030_WATCHDOG_CFG_REG_OFFS 0x3
-#define TWL4030_WDT_STATE_OPEN 0x1
-#define TWL4030_WDT_STATE_ACTIVE 0x8
-
-static struct platform_device *twl4030_wdt_dev;
-
-struct twl4030_wdt {
- struct miscdevice miscdev;
- int timer_margin;
- unsigned long state;
-};
-
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, Watchdog cannot be stopped once started
@@ -53,171 +39,71 @@ static int twl4030_wdt_write(unsigned char val)
TWL4030_WATCHDOG_CFG_REG_OFFS);
}
-static int twl4030_wdt_enable(struct twl4030_wdt *wdt)
+static int twl4030_wdt_start(struct watchdog_device *wdt)
{
- return twl4030_wdt_write(wdt-timer_margin + 1);
+ return twl4030_wdt_write(wdt-timeout + 1);
}
-static int twl4030_wdt_disable(struct twl4030_wdt *wdt)
+static int twl4030_wdt_stop(struct watchdog_device *wdt)
{
return twl4030_wdt_write(0);
}
-static int twl4030_wdt_set_timeout(struct twl4030_wdt *wdt, int timeout)
-{
- if (timeout 0 || timeout 30) {
- dev_warn(wdt-miscdev.parent,
- Timeout can only be in the range [0-30] seconds);
- return -EINVAL;
- }
- wdt-timer_margin = timeout;
- return twl4030_wdt_enable(wdt);
-}
-
-static ssize_t twl4030_wdt_write_fop(struct file *file,
- const char __user *data, size_t len, loff_t *ppos)
+static int twl4030_wdt_set_timeout(struct watchdog_device *wdt,
+ unsigned int timeout)
{
- struct twl4030_wdt *wdt = file-private_data;
-
- if (len)
- twl4030_wdt_enable(wdt);
-
- return len;
-}
-
-static long twl4030_wdt_ioctl(struct file *file,
- unsigned int cmd, unsigned long arg)
-{
- void __user *argp = (void __user *)arg;
- int __user *p = argp;
- int new_margin;
- struct twl4030_wdt *wdt = file-private_data;
-
- static const struct watchdog_info twl4030_wd_ident = {
- .identity = TWL4030 Watchdog,
- .options = WDIOF_SETTIMEOUT,
- .firmware_version = 0,
- };
-
- switch (cmd) {
- case WDIOC_GETSUPPORT:
- return copy_to_user(argp, twl4030_wd_ident,
- sizeof(twl4030_wd_ident)) ? -EFAULT : 0;
-
- case WDIOC_GETSTATUS:
- case WDIOC_GETBOOTSTATUS:
- return put_user(0, p);
-
- case WDIOC_KEEPALIVE:
- twl4030_wdt_enable(wdt);
- break;
-
- case WDIOC_SETTIMEOUT:
- if (get_user(new_margin, p))
- return -EFAULT;
- if (twl4030_wdt_set_timeout(wdt, new_margin))
- return -EINVAL;
- return put_user(wdt-timer_margin, p);
-
- case WDIOC_GETTIMEOUT:
- return put_user(wdt-timer_margin, p);
-
- default:
- return -ENOTTY;
- }
-
+ wdt-timeout = timeout;
return 0;
}
-static int twl4030_wdt_open(struct inode *inode, struct file *file)
-{
- struct twl4030_wdt *wdt = platform_get_drvdata(twl4030_wdt_dev);
-
- /* /dev/watchdog can only be opened once */
- if (test_and_set_bit(0, wdt-state))
- return -EBUSY;
-
- wdt-state |= TWL4030_WDT_STATE_ACTIVE;
-
Re: [PATCH 07/17] Input: omap-keypad: Remove dependencies to mach includes
Hi,
On Mon, Sep 10, 2012 at 10:30:59PM -0700, Tony Lindgren wrote:
We can't build CONFIG_ARCH_OMAP1 set with ARCH_OMAP2PLUS because
of different compiler flags needed, so we can define omap_kp_24xx()
instead of using cpu_is_omap24xx(). This way we can remove
depency to plat and mach headers which is needed for ARM common
zImage support.
Also remove INT_KEYBOARD by using omap_kp-irq.
Note that this patch depends on an earlier patch
ARM: OMAP: Move gpio.h to include/linux/platform_data.
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: linux-in...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/input/keyboard/omap-keypad.c | 34
++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/input/keyboard/omap-keypad.c
b/drivers/input/keyboard/omap-keypad.c
index a0222db..171d739 100644
--- a/drivers/input/keyboard/omap-keypad.c
+++ b/drivers/input/keyboard/omap-keypad.c
@@ -35,16 +35,19 @@
#include linux/mutex.h
#include linux/errno.h
#include linux/slab.h
-#include asm/gpio.h
+#include linux/gpio.h
+#include linux/platform_data/gpio-omap.h
#include plat/keypad.h
-#include plat/menelaus.h
-#include asm/irq.h
-#include mach/hardware.h
-#include asm/io.h
-#include plat/mux.h
#undef NEW_BOARD_LEARNING_MODE
+#ifdef CONFIG_ARCH_OMAP1
+#define omap_kp_24xx() 0
+#else
+#define omap_kp_24xx() 1
+#endif
I would rather use revision detection or different driver names (if
revision register is broken).
+static struct omap_kp *omap_kp;
please don't. This will prevent multiple instances of this driver. Even
though I don't think we will ever have an omap with multiple keypad
instances, it's still not a good practice IMHO.
Also, this ends up being hidden (if you have a better work let me
know) in most functions since they either pass omap_kp as argument or
define a local omap_kp variable.
Sourav, is the revision register on this IP working fine across multiple
OMAPs ?
static void omap_kp_tasklet(unsigned long);
static void omap_kp_timer(unsigned long);
@@ -99,7 +102,7 @@ static irqreturn_t omap_kp_interrupt(int irq, void *dev_id)
struct omap_kp *omap_kp = dev_id;
/* disable keyboard interrupt and schedule for handling */
- if (cpu_is_omap24xx()) {
+ if (omap_kp_24xx()) {
int i;
for (i = 0; i omap_kp-rows; i++) {
@@ -134,7 +137,7 @@ static void omap_kp_scan_keypad(struct omap_kp *omap_kp,
unsigned char *state)
int col = 0;
/* read the keypad status */
- if (cpu_is_omap24xx()) {
+ if (omap_kp_24xx()) {
/* read the keypad status */
for (col = 0; col omap_kp-cols; col++) {
set_col_gpio_val(omap_kp, ~(1 col));
@@ -222,7 +225,7 @@ static void omap_kp_tasklet(unsigned long data)
mod_timer(omap_kp_data-timer, jiffies + delay);
} else {
/* enable interrupts */
- if (cpu_is_omap24xx()) {
+ if (omap_kp_24xx()) {
int i;
for (i = 0; i omap_kp_data-rows; i++)
enable_irq(gpio_to_irq(row_gpios[i]));
@@ -253,9 +256,9 @@ static ssize_t omap_kp_enable_store(struct device *dev,
struct device_attribute
mutex_lock(kp_enable_mutex);
if (state != kp_enable) {
if (state)
- enable_irq(INT_KEYBOARD);
+ enable_irq(omap_kp-irq);
else
- disable_irq(INT_KEYBOARD);
+ disable_irq(omap_kp-irq);
GREAT!! :-)
kp_enable = state;
}
mutex_unlock(kp_enable_mutex);
@@ -286,7 +289,6 @@ static int omap_kp_resume(struct platform_device *dev)
static int __devinit omap_kp_probe(struct platform_device *pdev)
{
- struct omap_kp *omap_kp;
I don't see the point for that global omap_kp, actually ...
struct input_dev *input_dev;
struct omap_kp_platform_data *pdata = pdev-dev.platform_data;
int i, col_idx, row_idx, irq_idx, ret;
@@ -314,7 +316,7 @@ static int __devinit omap_kp_probe(struct platform_device
*pdev)
omap_kp-input = input_dev;
/* Disable the interrupt for the MPUIO keyboard */
- if (!cpu_is_omap24xx())
+ if (!omap_kp_24xx())
omap_writew(1, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
if (pdata-delay)
@@ -328,7 +330,7 @@ static int __devinit omap_kp_probe(struct platform_device
*pdev)
omap_kp-rows = pdata-rows;
omap_kp-cols = pdata-cols;
- if (cpu_is_omap24xx()) {
+ if (omap_kp_24xx()) {
/* Cols: outputs */
for (col_idx = 0; col_idx omap_kp-cols; col_idx++) {
if (gpio_request(col_gpios[col_idx], omap_kp_col)
0) {
@@ -394,7 +396,7 @@ static int __devinit
Re: [PATCH 12/17] ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ
On Mon, Sep 10, 2012 at 10:31:11PM -0700, Tony Lindgren wrote: Remove hardcoded IRQs in irqs.h and related files as these are no longer needed. Signed-off-by: Tony Lindgren t...@atomide.com Finally, great work Tony :-) FWIW: Reviewed-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/common.h|3 arch/arm/mach-omap2/include/mach/irqs.h |2 arch/arm/plat-omap/Kconfig |1 arch/arm/plat-omap/include/plat/irqs-44xx.h | 144 - arch/arm/plat-omap/include/plat/irqs.h | 183 --- drivers/media/video/omap/omap_vout.c|1 drivers/media/video/omap3isp/isp.c |2 drivers/power/avs/smartreflex.c |2 drivers/staging/tidspbridge/core/wdt.c |2 9 files changed, 10 insertions(+), 330 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/irqs-44xx.h diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 7e60a69..4cdb08c 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -26,12 +26,13 @@ #define __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H #ifndef __ASSEMBLER__ +#include linux/irq.h #include linux/delay.h #include linux/i2c/twl.h #include plat/common.h #include asm/proc-fns.h -#define OMAP_INTC_START 0 +#define OMAP_INTC_START NR_IRQS #ifdef CONFIG_SOC_OMAP2420 extern void omap242x_map_common_io(void); diff --git a/arch/arm/mach-omap2/include/mach/irqs.h b/arch/arm/mach-omap2/include/mach/irqs.h index 44dab77..ba5282c 100644 --- a/arch/arm/mach-omap2/include/mach/irqs.h +++ b/arch/arm/mach-omap2/include/mach/irqs.h @@ -1,5 +1,3 @@ /* * arch/arm/mach-omap2/include/mach/irqs.h */ - -#include plat/irqs.h diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index dd36eba..d15a4a6 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -25,6 +25,7 @@ config ARCH_OMAP2PLUS bool TI OMAP2/3/4 select CLKDEV_LOOKUP select GENERIC_IRQ_CHIP + select SPARSE_IRQ select OMAP_DM_TIMER select USE_OF select PROC_DEVICETREE if PROC_FS diff --git a/arch/arm/plat-omap/include/plat/irqs-44xx.h b/arch/arm/plat-omap/include/plat/irqs-44xx.h deleted file mode 100644 index 518322c..000 --- a/arch/arm/plat-omap/include/plat/irqs-44xx.h +++ /dev/null @@ -1,144 +0,0 @@ -/* - * OMAP4 Interrupt lines definitions - * - * Copyright (C) 2009-2010 Texas Instruments, Inc. - * - * Santosh Shilimkar (santosh.shilim...@ti.com) - * Benoit Cousson (b-cous...@ti.com) - * - * This file is automatically generated from the OMAP hardware databases. - * We respectfully ask that any modifications to this file be coordinated - * with the public linux-omap@vger.kernel.org mailing list and the - * authors above to ensure that the autogeneration scripts are kept - * up-to-date with the file contents. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#ifndef __ARCH_ARM_MACH_OMAP2_OMAP44XX_IRQS_H -#define __ARCH_ARM_MACH_OMAP2_OMAP44XX_IRQS_H - -/* OMAP44XX IRQs numbers definitions */ -#define OMAP44XX_IRQ_LOCALTIMER 29 -#define OMAP44XX_IRQ_LOCALWDT30 - -#define OMAP44XX_IRQ_GIC_START 32 - -#define OMAP44XX_IRQ_PL310 (0 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_CTI0(1 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_CTI1(2 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_ELM (4 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SYS_1N (7 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SECURITY_EVENTS (8 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_L3_DBG (9 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_L3_APP (10 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_PRCM(11 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_0 (12 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_1 (13 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_2 (14 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_3 (15 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP4 (16 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP1 (17 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SR_MCU (18 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SR_CORE (19 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPMC(20 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GFX (21 + OMAP44XX_IRQ_GIC_START) -#define
[PATCH] arm/dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Applies on
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 8a780b2..bdc21f1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -302,6 +302,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x4;
+ };
};
};
};
--
1.7.9.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 07/17] Input: omap-keypad: Remove dependencies to mach includes
* Felipe Balbi ba...@ti.com [120910 23:02]:
+#ifdef CONFIG_ARCH_OMAP1
+#define omap_kp_24xx() 0
+#else
+#define omap_kp_24xx() 1
+#endif
I would rather use revision detection or different driver names (if
revision register is broken).
Hmm actually looks like we can actually remove all the omap2+
support as we no longer have any users for this one. I think I
already converted the last one to matrix-keypad a while back.
+static struct omap_kp *omap_kp;
please don't. This will prevent multiple instances of this driver. Even
though I don't think we will ever have an omap with multiple keypad
instances, it's still not a good practice IMHO.
Also, this ends up being hidden (if you have a better work let me
know) in most functions since they either pass omap_kp as argument or
define a local omap_kp variable.
Yeah good point, I'll update that and remove the omap2+ support
for this driver.
Sourav, is the revision register on this IP working fine across multiple
OMAPs ?
Sounds like no need for that, as we're no longer using this for
omap2+..
@@ -253,9 +256,9 @@ static ssize_t omap_kp_enable_store(struct device *dev,
struct device_attribute
mutex_lock(kp_enable_mutex);
if (state != kp_enable) {
if (state)
- enable_irq(INT_KEYBOARD);
+ enable_irq(omap_kp-irq);
else
- disable_irq(INT_KEYBOARD);
+ disable_irq(omap_kp-irq);
GREAT!! :-)
Heh yeah that nice way to do it :)
static int __devinit omap_kp_probe(struct platform_device *pdev)
{
- struct omap_kp *omap_kp;
I don't see the point for that global omap_kp, actually ...
Yes you're right. Will send an updated one tomorrow.
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] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120908 01:20]: Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Fixes non critical is fine. No major issue without these patches. 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
[PATCH] mtd: nand: omap2: fix error path
Let probe return error value if gpmc terminal
count interrupt could not be obtained
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi,
My commit (now in l-o/devel-gpmc),
bd4156f mtd: nand: omap2: use gpmc provided irqs
did not propogate error code properly due to
which this fix was required.
But this has not been mentioned in commit message
as it is not yet in mainline.
Regards
Afzal
drivers/mtd/nand/omap2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 337cf0a..27293e3 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1404,6 +1404,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-gpmc_irq_count = platform_get_irq(pdev, 1);
if (info-gpmc_irq_count = 0) {
dev_err(pdev-dev, error getting count irq\n);
+ err = -ENODEV;
goto out_release_mem_region;
}
err = request_irq(info-gpmc_irq_count, omap_nand_irq,
--
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] mtd: nand: omap2: fix error path
+Tony
On Tue, Sep 11, 2012 at 11:58:54, Mohammed, Afzal wrote:
Let probe return error value if gpmc terminal
count interrupt could not be obtained
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi,
My commit (now in l-o/devel-gpmc),
bd4156f mtd: nand: omap2: use gpmc provided irqs
did not propogate error code properly due to
which this fix was required.
But this has not been mentioned in commit message
as it is not yet in mainline.
Regards
Afzal
drivers/mtd/nand/omap2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 337cf0a..27293e3 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1404,6 +1404,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-gpmc_irq_count = platform_get_irq(pdev, 1);
if (info-gpmc_irq_count = 0) {
dev_err(pdev-dev, error getting count irq\n);
+ err = -ENODEV;
goto out_release_mem_region;
}
err = request_irq(info-gpmc_irq_count, omap_nand_irq,
--
1.7.0.4
Re: [PATCH 00/29] Move OMAP2+ over to use COMMON clock
Hi Rajendra, A CCF testing branch has been built here. The base is v3.6-rc5, plus the most recent version of the Common Clock Framework preparation patches that you posted to the list, [PATCH v4 0/3] Prepare for OMAP2+ movement to Common Clk, but updated to take RMK's feedback into account. Then the 'clk-next-omap-3.6-rc3' branch from your repo at 'git://github.com/rrnayak/linux.git' was added. Then some patches to drop the old arch/arm/mach-omap2/clock*_data.c files were added. This branch was then run through checkpatch.pl, and all of the parenthesis alignment warnings have been fixed. I don't know what to do about these crazy DECLARE_CLK_* macros; they have so many arguments that they are basically impossible to read. Mike and I discussed converting them into C99 structure initializers with named fields, but am not sure if it's a readability advantage; it's probably going to be write-only data either way. I've reflowed many of them to save diffstat but there are quite a few more to go. The branch was then built with a set of testing Kconfigs. Here's what was found: (these are still being investigated) - The OMAP4-only testconfig and rmk's OMAP4430-SDP Kconfigs failed: undefined reference to `omap2_clkt_iclk_allow_idle': http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/omap4_testconfig/ http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap4430_sdp_oldconfig/ - RMK's OMAP3430-LDP Kconfig failed with a whole set of warnings: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap3430_ldp_oldconfig/ The kernel built with omap2plus_defconfig was then booted on several OMAP2+ boards. Here's what was found: - The kernel wouldn't boot on either the 3517EVM nor CM-T3517 boards. This turned out to be due to some missing AM35XX clkdev aliases, the lack of which cause the CCF code to panic. The patch that adds the OMAP3 data has been updated to fix that bug and an HSOTGUSB clkdev alias bug that was found by visual inspection. - The 3730 Beagle XM issued a warning and stack trace upon boot. Debugging with Mike, this turned out to be due to a bug in the modified omap2_init_clksel_parent() function: it returned a register bitfield rather than an array index. The patch that modifies this function was then updated to fix the bug. - The 2420 N800 seems to have some kind of MMC-related problem that prevents it from booting. Still looking into this: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/2420n800/2420n800_log.txt Then the branch was PM-tested to determine whether it can suspend and serial-resume properly, and whether dynamic idle works. These tests didn't go so well: - 3530ES3 Beagleboard here was able to enter retention-idle suspend, and leave it with serial wakeup, but the CORE powerdomain never entered a low-power state. Dynamic retention-idle with serial wakeup never resumed, and the test stopped there: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3530es3beagle/3530es3beagle_log.txt - 37xx EVM and 3730 Beagle XM fared better; they made it through the whole test program, but the CORE powerdomain also never entered a low-power state: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/37xxevm/37xxevm_log.txt http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3730beaglexm/3730beaglexm_log.txt - 4430ES2 Panda never made past the first retention-idle suspend: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/4430es2panda/4430es2panda_log.txt Could you please take a look and see if you can identify why the patches aren't passing the tests? I can't send these upstream until they pass the PM tests. This testing branch can be found at the branch named common_clk_testing_devel_3.7 of git://git.pwsan.com/linux-2.6 The testbed reports from this branch can be found here: http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/ And the baseline test reports from v3.6-rc5 can be found here: http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/ - 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: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120908 01:20]: Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Fixes non critical is fine. No major issue without these patches. There's an ordering constraint though: Santosh's patch needs to go in first, then mine. - 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 v2 0/2] ARM: dts: AM33xx: Correct gpio labels to match docs
On Tue, Sep 11, 2012 at 01:15:10, Porter, Matt wrote: Changes since v1: - Series now applies on top of Anil's AM33XX DTS series This series applies on top of the for_3.7/dts/ branch and Anil's [v7,2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone patch that is part of the overall series adding led and pinctrl DTS data for AM33xx. It is intended to correct the current labeling of gpios in the DTS before too many more drivers are submitted for AM33xx that have gpios not matching the docs. Matt Porter (2): ARM: dts: AM33XX: fix gpio node numbering to match hardware ARM: dts: AM33XX: adjust leds to use the corrected gpio label I have tested this series on BeagleBone, also validated LED functionality. Tested-Acked-By: Vaibhav Hiremath hvaib...@ti.com Thanks, Vaibhav arch/arm/boot/dts/am335x-bone.dts |8 arch/arm/boot/dts/am33xx.dtsi |8 2 files changed, 8 insertions(+), 8 deletions(-) -- 1.7.9.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 v3 10/10] mtd: nand: omap2: use gpmc provided irqs
Hi Tony, On Tue, Sep 11, 2012 at 11:12:27, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120910 22:36]: I was not careful enough, sorry. Thanks for fixing it. Another hunk as follows would also be required for error path even though compiler didn't complain. Not sure whether you can fixup or I should post as a separate patch. Oh OK, please just post a separate patch as I've already pushed it out. I have posted a separate patch, please consider for inclusion in your tree. BTW, you original commit that fixes the compiler warning has some strange characters. Regards Afzal
Re: [PATCH] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, Sep 11, 2012 at 12:07 PM, Paul Walmsley p...@pwsan.com wrote: On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120908 01:20]: Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Fixes non critical is fine. No major issue without these patches. There's an ordering constraint though: Santosh's patch needs to go in first, then mine. Its other way round ;-) Mine I created after applying your change. 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
[PATCH] spi: omap2-mcspi: Cleanup the omap2_mcspi_txrx_dma function
Currently in omap2_mcspi_txrx_dma the tx and the rx support is
interleaved. Make the rx related code in omap2_mcspi_rx_dma
and the tx related code omap2_mcspi_tx_dma and call the functions.
While at it remove the braces in the if statements which has only
one line.
Also fix [foo * bar to foo *bar] warn for the rx and tx variables.
Only a cleanup no functional change.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 256 +++--
1 files changed, 144 insertions(+), 112 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 1c1dd34..dd8fc88 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -315,49 +315,27 @@ static void omap2_mcspi_tx_callback(void *data)
omap2_mcspi_set_dma_req(spi, 0, 0);
}
-static unsigned
-omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
+static void omap2_mcspi_tx_dma(struct spi_device *spi,
+ struct spi_transfer *xfer,
+ struct dma_slave_config cfg)
{
struct omap2_mcspi *mcspi;
- struct omap2_mcspi_cs *cs = spi-controller_state;
struct omap2_mcspi_dma *mcspi_dma;
unsigned intcount;
- int word_len, element_count;
- int elements = 0;
- u32 l;
u8 * rx;
const u8* tx;
void __iomem*chstat_reg;
- struct dma_slave_config cfg;
- enum dma_slave_buswidth width;
- unsigned es;
+ struct omap2_mcspi_cs *cs = spi-controller_state;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
- l = mcspi_cached_chconf0(spi);
+ count = xfer-len;
+ rx = xfer-rx_buf;
+ tx = xfer-tx_buf;
chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
- if (cs-word_len = 8) {
- width = DMA_SLAVE_BUSWIDTH_1_BYTE;
- es = 1;
- } else if (cs-word_len = 16) {
- width = DMA_SLAVE_BUSWIDTH_2_BYTES;
- es = 2;
- } else {
- width = DMA_SLAVE_BUSWIDTH_4_BYTES;
- es = 4;
- }
-
- memset(cfg, 0, sizeof(cfg));
- cfg.src_addr = cs-phys + OMAP2_MCSPI_RX0;
- cfg.dst_addr = cs-phys + OMAP2_MCSPI_TX0;
- cfg.src_addr_width = width;
- cfg.dst_addr_width = width;
- cfg.src_maxburst = 1;
- cfg.dst_maxburst = 1;
-
- if (xfer-tx_buf mcspi_dma-dma_tx) {
+ if (mcspi_dma-dma_tx) {
struct dma_async_tx_descriptor *tx;
struct scatterlist sg;
@@ -368,7 +346,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
sg_dma_len(sg) = xfer-len;
tx = dmaengine_prep_slave_sg(mcspi_dma-dma_tx, sg, 1,
- DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (tx) {
tx-callback = omap2_mcspi_tx_callback;
tx-callback_param = spi;
@@ -377,8 +355,50 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
/* FIXME: fall back to PIO? */
}
}
+ dma_async_issue_pending(mcspi_dma-dma_tx);
+ omap2_mcspi_set_dma_req(spi, 0, 1);
- if (xfer-rx_buf mcspi_dma-dma_rx) {
+ wait_for_completion(mcspi_dma-dma_tx_completion);
+ dma_unmap_single(mcspi-dev, xfer-tx_dma, count,
+DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) 0)
+ dev_err(spi-dev, TXS timed out\n);
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) 0)
+ dev_err(spi-dev, EOT timed out\n);
+ }
+}
+
+static unsigned
+omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer,
+ struct dma_slave_config cfg,
+ unsigned es)
+{
+ struct omap2_mcspi *mcspi;
+ struct omap2_mcspi_dma *mcspi_dma;
+ unsigned intcount;
+ u32 l;
+ int elements = 0;
+ int word_len, element_count;
+ struct omap2_mcspi_cs *cs = spi-controller_state;
+ mcspi = spi_master_get_devdata(spi-master);
+ mcspi_dma = mcspi-dma_channels[spi-chip_select];
+ count = xfer-len;
+ word_len = cs-word_len;
+ l = mcspi_cached_chconf0(spi);
+
+ if (word_len = 8)
+
Re: [PATCH] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:07 PM, Paul Walmsley p...@pwsan.com wrote: On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120908 01:20]: Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Fixes non critical is fine. No major issue without these patches. There's an ordering constraint though: Santosh's patch needs to go in first, then mine. Its other way round ;-) Mine I created after applying your change. The problem is that if my patch is applied first, then there will be a point after my patch where the AUXCOREBOOT1 register won't be saved, which might break PM. So the patches may need to be updated. - 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 V3 0/8] ARM: OMAP4: Add PMU Support
Jon, On Mon, Sep 10, 2012 at 8:53 PM, Jon Hunter jon-hun...@ti.com wrote: This series adds PMU support for OMAP4 devices. This is based upon Will Deacons series [1] and re-based upon the latest arm-soc next/cleanup branch (3.6-rc3) that includes Will's series. It has been re-based upon this series because of the dependency on Sudeep KarkadaNagesha's change (ARM: pmu: remove arm_pmu_type enumeration) [2] that modifies the OMAP PMU code. This series is also dependent upon some clock fixes for OMAP3 [3] and OMAP4 [4] for PMU to operate correctly on OMAP3 and OMAP4. This series also converts OMAP2/3 devices to use HWMOD to create the PMU device and add a new file to mach-omap2 directory called pmu.c where the PMU devices are created. Testing: - Verified that PMU is working on OMAP2420 H4, OMAP3430 Beagle Board, OMAP4430 Panda and OMAP4460 Panda. - Tested on the above boards with CPU-idle enabled to ensure that PMU is working with power management. For OMAP3430 verified that CORE retention state is entered again after stopping PMU events. V3 changes: - Will Deacon has taken the PMU runtime PM adaption patch in his series and so not included here [1]. - Dropped my fix for managing the EMU power domain on OMAP4 in favour of Paul's implementation [4]. Paul is planning to submit for v3.7. - Added HWMOD data for OMAP3 DEBUG sub-system. The DEBUG sub-system was always being enabled on OMAP3 devices when using PMU and hence, hinding the fact that PMU is dependent upon the DEBUG sub-system on OMAP3 for it to work. [1] git://git.kernel.org/pub/sicm/linux/kernel/git/will/linux.git perf/updates [2] http://www.spinics.net/lists/arm-kernel/msg188726.html [3] http://marc.info/?l=linux-omapm=134333691309305w=2 [4] http://marc.info/?l=linux-arm-kernelm=134383567112518w=2 Cc: Ming Lei ming@canonical.com Cc: Will Deacon will.dea...@arm.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Jon Hunter (6): ARM: OMAP3: Add debugss HWMOD data ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS ARM: OMAP2+: PMU: Add runtime PM support ARM: OMAP4: Enable PMU for OMAP4460/70 ARM: OMAP2+: PMU: Add QoS constraint Ming Lei (2): ARM: OMAP4430: Create PMU device via HWMOD ARM: OMAP4: Route PMU IRQs to CTI IRQs Thanks for persisting with the PMU series and great work to get it working across almost all OMAPs supporting PMU. I have acked few patches already from the series. Just quickly rescanned full series and also tried it on OMAP4 SDP. PMU counters seems to work fine with it. Feel free to add my ack for the entire series. Acked-by: Santosh Shilimkar santosh.shilim...@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] omap-i2c: fix incorrect log message when using a device tree
Hello Wolfram, When booting using a device tree, the adapter number is dynamically assigned after the log message is sent. This patch modifies the log message to get a correct adapter id. Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo). Thanks for the fix. Tested successfully on OMAP4 SDP DT boot as well. [0.00] Linux version 3.6.0-rc3-00030-g491038d (bcousson@lnwes3201) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #6 SMP Fri Aug 31 13:50:48 CEST 2012 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 SDP board ... [0.667205] omap_i2c i2c.15: bus 0 rev2.4.0 at 400 kHz ... [0.768341] omap_i2c i2c.16: bus 1 rev2.4.0 at 400 kHz [0.783905] omap_i2c i2c.17: bus 2 rev2.4.0 at 400 kHz [0.799530] omap_i2c i2c.18: bus 3 rev2.4.0 at 400 kHz Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Tested-by: Benoit Cousson b-cous...@ti.com and Acked-by: Benoit Cousson b-cous...@ti.com Regards, Benoit Was this patch picked-up by the i2c-embedded subsystem? Thank you. Regards, Florian -- 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: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, Sep 11, 2012 at 12:13 PM, Paul Walmsley p...@pwsan.com wrote: On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:07 PM, Paul Walmsley p...@pwsan.com wrote: On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120908 01:20]: Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Fixes non critical is fine. No major issue without these patches. There's an ordering constraint though: Santosh's patch needs to go in first, then mine. Its other way round ;-) Mine I created after applying your change. The problem is that if my patch is applied first, then there will be a point after my patch where the AUXCOREBOOT1 register won't be saved, which might break PM. So the patches may need to be updated. Good point. It's trivial to re-order them. Tony, Updated patches in the end of the email. Also attached. Regards Santosh From 4e1da2a44d92b956c3a740f5af6a45ff1c2dc294 Mon Sep 17 00:00:00 2001 From: Paul Walmsley p...@pwsan.com Date: Tue, 11 Sep 2012 12:43:18 +0530 Subject: [PATCH 2/2] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write The wakeupgen context-save code reads and stores the AUXCOREBOOT0 and AUXCOREBOOT1 register contents twice. This seems like a waste of time, so, remove the duplicates. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap-wakeupgen.c |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index c3795c2..567f672 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -233,12 +233,6 @@ static inline void omap4_irq_save_context(void) __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); /* Save SyncReq generation logic */ - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); - __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET); - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); - __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); - - /* Save SyncReq generation logic */ val = __raw_readl(wakeupgen_base + OMAP_PTMSYNCREQ_MASK); __raw_writel(val, sar_base + PTMSYNCREQ_MASK_OFFSET); val = __raw_readl(wakeupgen_base + OMAP_PTMSYNCREQ_EN); -- 1.7.9.5 From 6e3b8a3f6ec231f588b860d87b7a80f6ba38ce98 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Thu, 6 Sep 2012 11:51:34 +0530 Subject: [PATCH 1/2] ARM: OMAP4: wakeupgen: Fix the typo in AUXCOREBOOT register save The wakeupgen context-save code reads AUXCOREBOOT0 register instead of AUXCOREBOOT1 register contents while saving AUXCOREBOOT1. Fix the same. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-wakeupgen.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index 05fdebf..c3795c2 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -229,7 +229,7 @@ static inline void omap4_irq_save_context(void) /* Save AuxBoot* registers */ val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET); - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); + val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_1); __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); /* Save SyncReq generation logic */ -- 1.7.9.5 0002-ARM-OMAP4-wakeupgen-remove-duplicate-AUXCOREBOOT-rea.patch Description: Binary data 0001-ARM-OMAP4-wakeupgen-Fix-the-typo-in-AUXCOREBOOT-regi.patch Description: Binary data
Re: [PATCH] ARM: OMAP2+: mux: add support for PAD wakeup event handler
On Tue, Sep 11, 2012 at 12:09 AM, Tony Lindgren t...@atomide.com wrote: * Ruslan Bilovol ruslan.bilo...@ti.com [120910 03:39]: OMAP mux now parses active wakeup events from pad registers and calls corresponding handler, if handler is not registered - corresponding hwmod ISRs once a wakeup is detected. This is useful for cases when routing wakeups to corresponding hwmod ISRs complicates those ISRs handlers (for example, ISR handler may not know who the interrupt source is) The mux code in arch/arm/mach-omap2 will be going away and replaced by device tree based pinctrl-single. Thanks tony when is this device tree based pinctrl-single will be available in mainline? regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Hi Tero, Paul, After discussion with Paul at LPC I produced a new version that we are now internally reviewing. Paul, what is your plan? Regards, Jean On Mon, Sep 10, 2012 at 5:09 PM, Tero Kristo t-kri...@ti.com wrote: On Thu, 2012-08-16 at 11:20 +0530, Shilimkar, Santosh wrote: Paul, On Thu, Aug 16, 2012 at 6:18 AM, Paul Walmsley p...@pwsan.com wrote: Hi Santosh, On Wed, 15 Aug 2012, Shilimkar, Santosh wrote: On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet jean.pi...@newoldbits.com wrote: I didn't find any mention here about why are we going in this path and not in the direction proposed in another RFC [1] I have already given my comments[2] against the introduction of another PD layer which can be avoided easily as demonstrated by the RFC[1]. The comments are still applicable for this series too. We really need to reduce OMAP specific framework overhead and move towards more generic PM frameworks. For me, this series is a step back-ward from that direction. Am really sorry for being critical again but I remain unconvinced about this series and the problem it is trying to solve. May be you have valid reasons not to follow the approach in [1] and in that case, it will be good to clarify that so that some of us get to know your rationale. I've asked Jean to handle the work of evaluating and/or integrating any feedback from you and Rajendra into this series. Jean, has this latest series fully considered those issues? Or are there still some areas of misalignment / lack of clarity? Thanks for the information. The main objection to this series was to not add un-necessary glue layer which still remains. From our discussion in past on and off list, your main intention for such a series was - 1. Need a way to support OSWR. - OSWR by definition is a RET with configurable logic and memory states. Its a true power state from PD point of view and its not a logical state. Now since we have agreed to make the OSWR as a static definition (in all products so far OSWR is used as a static definition with logic lost, memory retained kind of configuration.) - The above requirement can be easily fixed by adding the OSWR as an additional basic power state as demonstrated in RFC. - There is no need to add another glue layer for above. 2. Locking so that the low level APIs don't race and henec abstracting the exported API to 1 or 2 and making rest as private functions. -- Even before this series, except low level PM code, only one common API was used to set the PD low power state. int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst) -- Once we make OSWR as basic power state, we also avoid usage of pwrdm_set_logic_retst() API. -- We implement lock at this API and export only above API + may be omap_get_pwrdm_state() kind of API based on need. -- This solves the second requirement too. Even if we have more requirement, they can be addressed too without need of another layer. If you look at the diffstat alone between two approaches, it is evident how small piece of code is needed to support above. Am not too much into the lines of code but basic objection we have is not to add another glue layer. Thinking bit loud, for the logical layer for power domain we should move towards common device power domain APIs and if needed add/enhance them to support OMAP. drivers/base/power/domain.c May be this though is bit premature but the intetion is to move towards generic linux framework. Anyway. If there's a problem with this process, it sounds like you, Rajendra, Jean, Benoît and I should schedule some time to talk over the same issues that you discussed with me on the phone. Perhaps next week? We can surely do a call if needed. But the comments given so far and the RFC makes things more or less clear the contention point against the $subject series. What is the latest status with this set? This is kind of blocking the omap4 core retention feature also as I am supposed to put the patches on top of this set. Do we have a consensus which way this set should evolve? Or, should I just base the core retention patches on top of baseline and forget about the functional power states for now? -Tero -- 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/dts: omap: Add omap-usb2 dt data
Hi Kishon,
On 09/11/2012 08:12 AM, Kishon Vijay Abraham I wrote:
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.
Could you add more details about the omap-usb2?
You must update the Documentation binding with that compatible name.
Is it already part of the driver serie? The MUSB driver is referring to
ti,musb-omap2430 only.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Applies on
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 8a780b2..bdc21f1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -302,6 +302,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
There is no ocp2scp_usb_phy in the current omap4.dtsi?
What base did you used?
You have to use lo/devel-dt branch as a base. All the latest DTS patches
an in there for 3.7.
Regards,
Benoit
+ usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x4;
+ };
};
};
};
--
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/dts: omap: Add omap-usb2 dt data
Hi, On Tue, Sep 11, 2012 at 1:53 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Kishon, On 09/11/2012 08:12 AM, Kishon Vijay Abraham I wrote: Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is connected to ocp2scp, omap-usb2 dt data is added as a child node of ocp2scp. Could you add more details about the omap-usb2? I think information about omap-usb2 driver is added in *usb: phy: add a new driver for omap usb2 phy.*. Do you want the same thing to be added here? You must update the Documentation binding with that compatible name. Yes. It's part of *usb: phy: add a new driver for omap usb2 phy.* Is it already part of the driver serie? The MUSB driver is referring to ti,musb-omap2430 only. Will correct the Documentation for MUSB. Thanks Kishon -- 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/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi,
On Mon, Sep 10, 2012 at 10:13 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control
module,
omap2430 will handle the register writes to control module by itself.
So
a new address space to represent this control module register is added
to usb_otg_hs.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.
Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.
this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.
Tony, can I get your Acked-by to this patch so I can take it together
with the rest of the series ? Thanks
ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
to merge it into your tree once I apply.
It would be best if this got acked by Benoit and Paul as they may
have some other patches queued up. I'll ack if they ack ;)
Benoit, care to ack this patch ???
Gosh, that's hard to ack something like that :-)
btw, that's not different than what's already in tree, the only
difference is that now hwmod knows about it...
But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.
Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.
sure, that's doable... Kishon, can you do this ASAP ? I want to send my
pull requests tomorrow at the latest.
Sure. Will send now.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
With pinctrl-single,bits it is possible to update just part of the register
within the pinctrl-single,function-mask area.
This is useful when one register configures mmore than one pin's mux.
pinctrl-single,bits takes three parameters:
reg offset, value, sub-mask
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hello Tony, Linus,
Changes since v1:
- Added boolean for the pinctrl-single: pinctrl-single,bit-per-mux
When this is set the it indicates that the area contains registers which
changes mux for multible pins.
- Documentation updated reflecting this change (with example for this type)
Regards,
Peter
.../devicetree/bindings/pinctrl/pinctrl-single.txt | 41 +--
drivers/pinctrl/pinctrl-single.c | 46 +-
2 files changed, 74 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5187f0d..2c81e45 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -14,10 +14,12 @@ Optional properties:
- pinctrl-single,function-off : function off mode for disabled state if
available and same for all registers; if not specified, disabling of
pin functions is ignored
+- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
+ more than one pin
-This driver assumes that there is only one register for each pin,
-and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt
-document in this directory.
+This driver assumes that there is only one register for each pin (unless the
+pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
+specified in the pinctrl-bindings.txt document in this directory.
The pin configuration nodes for pinctrl-single are specified as pinctrl
register offset and value pairs using pinctrl-single,pins. Only the bits
@@ -31,6 +33,15 @@ device pinctrl register, and 0x118 contains the desired
value of the
pinctrl register. See the device example and static board pins example
below for more information.
+In case when one register changes more than one pin's mux the
+pinctrl-single,bits need to be used which takes three parameters:
+
+ pinctrl-single,bits = 0xdc 0x18, 0xff;
+
+Where 0xdc is the offset from the pinctrl register base address for the
+device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
+be used when applying this change to the register.
+
Example:
/* SoC common file */
@@ -55,6 +66,15 @@ pmx_wkup: pinmux@4a31e040 {
pinctrl-single,function-mask = 0x;
};
+control_devconf0: pinmux@48002274 {
+ compatible = pinctrl-single;
+ reg = 0x48002274 4; /* Single register */
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x5F;
+};
/* board specific .dts file */
@@ -87,6 +107,21 @@ pmx_wkup: pinmux@4a31e040 {
};
};
+control_devconf0 {
+ mcbsp1_pins: pinmux_mcbsp1_pins {
+ pinctrl-single,bits =
+ 0x00 0x18 0x18 /* FSR/CLKR signal from FSX/CLKX pin */
+ ;
+ };
+
+ mcbsp2_clks_pins: pinmux_mcbsp2_clks_pins {
+ pinctrl-single,bits =
+ 0x00 0x40 0x40 /* McBSP2 CLKS from McBSP_CLKS pin */
+ ;
+ };
+
+};
+
uart2 {
pinctrl-names = default;
pinctrl-0 = uart2_pins;
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 3508631..759b5a6 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -26,7 +26,8 @@
#include core.h
#define DRIVER_NAMEpinctrl-single
-#define PCS_MUX_NAME pinctrl-single,pins
+#define PCS_MUX_PINS_NAME pinctrl-single,pins
+#define PCS_MUX_BITS_NAME pinctrl-single,bits
#define PCS_REG_NAME_LEN ((sizeof(unsigned long) * 2) + 1)
#define PCS_OFF_DISABLED ~0U
@@ -54,6 +55,7 @@ struct pcs_pingroup {
struct pcs_func_vals {
void __iomem *reg;
unsigned val;
+ unsigned mask;
};
/**
@@ -139,6 +141,7 @@ struct pcs_device {
unsigned fshift;
unsigned foff;
unsigned fmax;
+ bool bits_per_mux;
struct pcs_name *names;
struct pcs_data pins;
struct radix_tree_root pgtree;
@@ -332,12 +335,17 @@ static int pcs_enable(struct pinctrl_dev *pctldev,
unsigned fselector,
for (i = 0; i func-nvals; i++) {
struct pcs_func_vals *vals;
- unsigned val;
+ unsigned val, mask;
vals = func-vals[i];
val = pcs-read(vals-reg);
- val = ~pcs-fmask;
- val |= (vals-val pcs-fmask);
+
[PATCH v2 0/3] omap: musb: Add device tree support
This patch series adds device tree support for MUSB. The glue layer is now made to write to mailbox register (present in control module) instead of calling phy layer to write to mailbox register. Writing to mailbox register notifies the core of events like device connect/disconnect. Changes from v1: * Added a comment in hwmod data to remove the control module data from otg_hs once control driver is in place. * Fixed the omap-usb Documentation to the correct compatible value (Should be ti,omap4-musb or ti,omap3-musb) Previously these patches were part of [PATCH v7 0/7] omap: musb: Add device tree support This patch series was created to contain only the *musb* part and it also has one hwmod patch. This patch series was created on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb Kishon Vijay Abraham I (3): arm: omap: hwmod: add a new addr space in otg for writing to control module usb: musb: omap: write directly to mailbox instead of using phy usb: musb: omap: Add device tree support for omap musb glue Documentation/devicetree/bindings/usb/omap-usb.txt | 33 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++ drivers/usb/musb/omap2430.c| 106 ++-- drivers/usb/musb/omap2430.h|9 ++ 4 files changed, 147 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt -- 1.7.9.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 v2 2/3] usb: musb: omap: write directly to mailbox instead of using phy
The glue layer should directly write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 52 +--
drivers/usb/musb/omap2430.h |9
2 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 02c39a7..f4d9503 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -45,6 +45,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -52,6 +53,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue-control_otghs)
+ writel(val, glue-control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -247,6 +268,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -262,7 +284,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (musb-gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -275,7 +298,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -292,7 +316,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
- usb_phy_shutdown(musb-xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -367,6 +392,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -376,7 +402,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -395,7 +422,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -405,11 +433,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
- if (glue-status != OMAP_MUSB_UNKNOWN)
-
[PATCH v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 33
drivers/usb/musb/omap2430.c| 54
2 files changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..29a043e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,omap4-musb or ti,omap3-musb
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f4d9503..d96873b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -470,8 +471,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -501,6 +505,42 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+ .compatible = ti,omap4-musb
+ },
+ {
+ .compatible = ti,omap3-musb
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap2430_id_table);
[PATCH v2 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..3c19120 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,12 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ /* XXX: Remove this once control module driver is in place */
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.9.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 v2 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
On 09/11/2012 11:09 AM, Kishon Vijay Abraham I wrote:
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..3c19120 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,12 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ /* XXX: Remove this once control module driver is in place */
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/13] usb: musb: adding multi instance support
Hi, On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote: This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to felipe/master [1] branch + Vaibhav baseport patches on his tree at [4] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [2] + Damodar's recent patch at [3] + Ajay's Damodar's patches at [5] and [6] included in this series 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary 2. http://marc.info/?l=linux-usbm=134070369306112w=2 3. http://marc.info/?l=linux-usbm=134200284230689w=2 4. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging 5. http://marc.info/?l=linux-usbm=134200285530701w=2 6. http://marc.info/?l=linux-usbm=134208820028625w=2 Changes from v8: - included Sergei's comment, removing underscore in device tree file - removed duplicated signoff from patches Changes from v7: - patches rebased on felipe/master branch verified - included additional two patches 0001 0002 as part of this series which are already submitted [5] [6] Changes from v6: - Removed parent_pdev to get glue and used dev_get_getdrv() as per Felipe's comment - use pr_debug() instead of pr_info() as per Felipe's comment Changes from v5: - Removed musb-id as per Felipe's comment - used nop_ida as per Felipe's comment Changes from v4: - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() - Fixed Felipe's comment on using dev_set_mask() Changes from v3: - Fixed Kishon's comment on removing id from phy struct and removing unneeded #else part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the ti string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] I tried appliying this, but this doesn't apply. Please rebase on my musb branch. Unfortunately there's no time anymore to wait otherwise the entire musb branch will miss this merge window. I'm sorry -- balbi signature.asc Description: Digital signature
Re: [PATCH] omap-i2c: fix incorrect log message when using a device tree
On Friday 31 August 2012 04:32 PM, Florian Vaussard wrote: When booting using a device tree, the adapter number is dynamically assigned after the log message is sent. This patch modifies the log message to get a correct adapter id. Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo). Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Looks good to me. Acked-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 5d19a49..136b4fe 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1064,9 +1064,6 @@ omap_i2c_probe(struct platform_device *pdev) goto err_unuse_clocks; } - dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id, - dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed); - adap = dev-adapter; i2c_set_adapdata(adap, dev); adap-owner = THIS_MODULE; @@ -1084,6 +1081,9 @@ omap_i2c_probe(struct platform_device *pdev) goto err_free_irq; } + dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, adap-nr, + dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed); + of_i2c_register_devices(adap); pm_runtime_put(dev-dev); -- 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] ARM: OMAP5: Enable arch timer support
Benoit,
On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote:
[...]
Silly question: Don't we have one arch-timer per CPU?
It is per CPU just like A9 TWD
Shouldn't we have two nodes then?
I need to check this but arch timer DT node should be same
as the twd DT node. May be one node with reference to
each CPU node should do but am not too sure about the DT
nodes and how all that work.
Here is an updated patch based on our discussion. Thanks for comments.
Let me know if you are ok with this version.
From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 13 Aug 2012 14:39:03 +0530
Subject: [PATCH] ARM: OMAP5: Enable arch timer support
Enable Cortex A15 generic timer support for OMAP5 based SOCs.
The CPU local timers run on the free running real time counter clock.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 12
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/timer.c |7 +++
3 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..7b986ed 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,9 +33,21 @@
cpus {
cpu@0 {
compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /* 14th PPI IRQ, active low level-sensitive */
+ interrupts = 1 14 0x308;
+ clock-frequency = 6144000;
+ };
};
cpu@1 {
compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /* 14th PPI IRQ, active low level-sensitive */
+ interrupts = 1 14 0x308;
+ clock-frequency = 6144000;
+ };
};
};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2120f90..53fb77c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -73,6 +73,7 @@ config SOC_OMAP5
select ARM_GIC
select HAVE_SMP
select SOC_HAS_REALTIME_COUNTER
+ select ARM_ARCH_TIMER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8f5b88b..46982d0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -41,6 +41,7 @@
#include plat/dmtimer.h
#include asm/smp_twd.h
#include asm/sched_clock.h
+#include asm/arch_timer.h
#include common.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
@@ -481,9 +482,15 @@ OMAP_SYS_TIMER(4)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_timer_init(void)
{
+ int err;
+
omap2_gp_clockevent_init(1, OMAP4_CLKEV_SOURCE);
omap2_clocksource_init(2, OMAP4_MPU_SOURCE);
realtime_counter_init();
+
+ err = arch_timer_of_register();
+ if (err)
+ pr_err(%s: arch_timer_register failed %d\n, __func__, err);
}
OMAP_SYS_TIMER(5)
#endif
--
1.7.9.5
0001-ARM-OMAP5-Enable-arch-timer-support.patch
Description: Binary data
[PATCHv7 00/23]I2C big cleanup
Changes since v1:
- removed tabification on patch 6/17
- removed dev_err() which was introduced on patch 09/17
Changes since v2:
- do not set full fifo depth in the RDR interrupt.
- some changelog updates.
- rebase to the Wolfram's tree.
Changes since v3:
- Remove a redundant read of status register
- Read the dev-buf_len variable instead of the register
as the information of the remaining bytes is there.
Changes since v4:
- Ack the arbitration lost.
- Rebase to the i2c-embedded/for-next branch.
Changes since v5:
- Rebase to latest mainline
- Added some more cleanup patches so as have a consolidated series.
Changes since v6:
- Fix comments on setting the pdev to NULL.
- Trivial changelog update
Previous discussions can be found here
http://www.spinics.net/lists/linux-i2c/msg09482.html
This is the cleanup only series.
Tested on omap4sdp and 3430sdp.
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://gitorious.org/linus-tree/linus-tree.git for_3.7/i2c/big_cleanup
Felipe Balbi (22):
i2c: omap: switch to devm_* API
i2c: omap: simplify num_bytes handling
i2c: omap: decrease indentation level on data handling
i2c: omap: add blank lines
i2c: omap: simplify omap_i2c_ack_stat()
i2c: omap: split out [XR]DR and [XR]RDY
i2c: omap: improve i462 errata handling
i2c: omap: re-factor receive/transmit data loop
i2c: omap: switch over to do {} while loop
i2c: omap: ack IRQ in parts
i2c: omap: switch to platform_get_irq()
i2c: omap: bus: add a receiver flag
i2c: omap: simplify errata check
i2c: omap: always return IRQ_HANDLED
i2c: omap: simplify IRQ exit path
i2c: omap: resize fifos before each message
i2c: omap: get rid of the complete label
i2c: omap: always return IRQ_HANDLED
i2c: omap: switch to threaded IRQ support
i2c: omap: remove unnecessary pm_runtime_suspended check
i2c: omap: switch over to autosuspend API
i2c: omap: sanitize exit path
Shubhrajyoti D (1):
i2c: omap: remove redundant status read
drivers/i2c/busses/i2c-omap.c | 442 +
1 files changed, 271 insertions(+), 171 deletions(-)
--
1.7.5.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
[PATCHv7 05/23] i2c: omap: simplify omap_i2c_ack_stat()
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Code snippet (extremely simplified):
if (stat NACK) {
...
omap_i2c_ack_stat(dev, stat NACK);
}
if (stat RDR) {
...
omap_i2c_ack_stat(dev, stat RDR);
}
and so on. The tricky place is only WRT errata handling, for example:
if (*stat (NACK | AL)) {
omap_i2c_ack_stat(dev, *stat (XRDY | XDR));
...
}
but in this case, the errata says we must clear XRDY and XDR if that
errata triggers, so if they just got enabled or not, it doesn't matter.
Another tricky place is RDR | RRDY (likewise for XDR | XRDY):
if (stat (RDR | RRDY)) {
...
omap_i2c_ack_stat(dev, stat (RDR | RRDY));
}
again here there will be no issues because those IRQs never fire
simultaneously and one will only after after we have handled the
previous, that's because the same FIFO is used anyway and we won't shift
data into FIFO until we tell the IP hey, I'm done with the FIFO, you
can shift more data
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
[Added the explaination from the discurssion to the commit logs]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 30ea63c..f24eae9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -731,7 +731,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev, u16
*stat, int *err)
while (--timeout !(*stat OMAP_I2C_STAT_XUDF)) {
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -792,10 +792,11 @@ complete:
*/
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -842,8 +843,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -890,8 +891,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
1.7.5.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
[PATCHv7 06/23] i2c: omap: split out [XR]DR and [XR]RDY
From: Felipe Balbi ba...@ti.com
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an unncessary register
read since dev-fifo_len will always contain the
correct amount of data to be transferred.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 126 ++---
1 files changed, 92 insertions(+), 34 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f24eae9..815577b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -801,36 +801,62 @@ complete:
return IRQ_HANDLED;
}
- if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
+ if (dev-fifo_size)
+ num_bytes = dev-buf_len;
+
+ while (num_bytes--) {
+ if (!dev-buf_len) {
+ dev_err(dev-dev,
+ RDR IRQ while no data
+requested\n);
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev-buf++ = w;
+ dev-buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
+ }
+
if (dev-errata I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
- if (dev-fifo_size) {
- if (stat OMAP_I2C_STAT_RRDY)
- num_bytes = dev-fifo_size;
- else/* read RXSTAT on RDR interrupt */
- num_bytes = (omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG)
-8) 0x3F;
- }
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+ continue;
+ }
+
+ if (stat OMAP_I2C_STAT_RRDY) {
+ u8 num_bytes = 1;
+
+ if (dev-fifo_size)
+ num_bytes = dev-fifo_size;
+
while (num_bytes--) {
if (!dev-buf_len) {
- if (stat OMAP_I2C_STAT_RRDY)
- dev_err(dev-dev,
+ dev_err(dev-dev,
RRDY IRQ while no data
-requested\n);
- if (stat OMAP_I2C_STAT_RDR)
- dev_err(dev-dev,
- RDR IRQ while no data
-requested\n);
+requested\n);
break;
}
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev-buf++ = w;
dev-buf_len--;
+
/*
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
@@ -843,36 +869,68 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
- OMAP_I2C_STAT_RDR));
+
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RRDY);
continue;
}
- if (stat (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
+
[PATCHv7 04/23] i2c: omap: add blank lines
From: Felipe Balbi ba...@ti.com
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0dd647a..30ea63c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -786,6 +786,7 @@ complete:
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
}
+
/*
* ProDB0017052: Clear ARDY bit twice
*/
@@ -798,6 +799,7 @@ complete:
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
+
if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
@@ -844,6 +846,7 @@ complete:
stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
continue;
}
+
if (stat (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
u8 num_bytes = 1;
if (dev-fifo_size) {
@@ -891,10 +894,12 @@ complete:
stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
continue;
}
+
if (stat OMAP_I2C_STAT_ROVR) {
dev_err(dev-dev, Receive overrun\n);
dev-cmd_err |= OMAP_I2C_STAT_ROVR;
}
+
if (stat OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
dev-cmd_err |= OMAP_I2C_STAT_XUDF;
--
1.7.5.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
[PATCHv7 03/23] i2c: omap: decrease indentation level on data handling
From: Felipe Balbi ba...@ti.com
The patch intends to decrease the indentation level on the
data handling
by using the fact that else of if (dev-buf_len) is same as
if (!dev-buf_len)
if (dev-buf_len) {
aaa;
} else {
bbb;
break;
}
to
if (!dev-buf_len) {
bbb;
break;
}
aaa;
Hence no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 63 -
1 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 236cb38..0dd647a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -813,22 +813,7 @@ complete:
8) 0x3F;
}
while (num_bytes--) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev-buf_len) {
- *dev-buf++ = w;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- } else {
+ if (!dev-buf_len) {
if (stat OMAP_I2C_STAT_RRDY)
dev_err(dev-dev,
RRDY IRQ while no data
@@ -839,6 +824,21 @@ complete:
requested\n);
break;
}
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev-buf++ = w;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
}
omap_i2c_ack_stat(dev,
stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
@@ -855,22 +855,7 @@ complete:
0x3F;
}
while (num_bytes--) {
- w = 0;
- if (dev-buf_len) {
- w = *dev-buf++;
- dev-buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- w |= *dev-buf++ 8;
- dev-buf_len--;
- }
- }
- } else {
+ if (!dev-buf_len) {
if (stat OMAP_I2C_STAT_XRDY)
dev_err(dev-dev,
XRDY IRQ while no
@@ -882,6 +867,20 @@ complete:
break;
}
+ w = *dev-buf++;
+ dev-buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+
[PATCHv7 13/23] i2c: omap: simplify errata check
From: Felipe Balbi ba...@ti.com omap_i2c_dev is allocated with kzalloc(), so we need not initialize b_hw to zero. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 3be147a..7918e48 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1095,9 +1095,7 @@ omap_i2c_probe(struct platform_device *pdev) dev-fifo_size = (dev-fifo_size / 2); - if (dev-rev = OMAP_I2C_REV_ON_3630_4430) - dev-b_hw = 0; /* Disable hardware fixes */ - else + if (dev-rev OMAP_I2C_REV_ON_3630_4430) dev-b_hw = 1; /* Enable hardware fixes */ /* calculate wakeup latency constraint for MPU */ -- 1.7.5.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
[PATCHv7 07/23] i2c: omap: improve i462 errata handling
From: Felipe Balbi ba...@ti.com
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Also since we are waiting for XUDF(Transmitter underflow) just before
writing data lets not flag the underflow.
This is anyways going to go once we write
the data.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 43
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 815577b..fb57221 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -725,27 +725,30 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev)
{
unsigned long timeout = 1;
+ u16 stat;
- while (--timeout !(*stat OMAP_I2C_STAT_XUDF)) {
- if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+ do {
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ if (stat OMAP_I2C_STAT_XUDF)
+ break;
+
+ if (stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- return -ETIMEDOUT;
+ return -EIO;
}
cpu_relax();
- *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
+ } while (--timeout);
if (!timeout) {
dev_err(dev-dev, timeout waiting on XUDF bit\n);
return 0;
}
- *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
@@ -903,9 +906,16 @@ complete:
}
}
- if ((dev-errata I2C_OMAP_ERRATA_I462)
- errata_omap3_i462(dev, stat, err))
- goto complete;
+ if (dev-errata I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret 0)
+ goto complete;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
@@ -943,9 +953,16 @@ complete:
}
}
- if ((dev-errata I2C_OMAP_ERRATA_I462)
- errata_omap3_i462(dev, stat, err))
- goto complete;
+ if (dev-errata I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret 0)
+ goto complete;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
--
1.7.5.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
[PATCHv7 10/23] i2c: omap: ack IRQ in parts
From: Felipe Balbi ba...@ti.com
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi ba...@ti.com
[Ack the stat OMAP_I2C_STAT_AL in case of arbitration lost]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4045134..bac1f11 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -850,21 +850,19 @@ omap_i2c_isr(int this_irq, void *dev_id)
}
complete:
- /*
-* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
-* acked after the data operation is complete.
-* Ref: TRM SWPU114Q Figure 18-31
-*/
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat
- ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
-
- if (stat OMAP_I2C_STAT_NACK)
+ if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
+ }
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
/*
@@ -941,12 +939,18 @@ complete:
if (stat OMAP_I2C_STAT_ROVR) {
dev_err(dev-dev, Receive overrun\n);
- dev-cmd_err |= OMAP_I2C_STAT_ROVR;
+ err |= OMAP_I2C_STAT_ROVR;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
if (stat OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
- dev-cmd_err |= OMAP_I2C_STAT_XUDF;
+ err |= OMAP_I2C_STAT_XUDF;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
} while (stat);
--
1.7.5.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
[PATCHv7 09/23] i2c: omap: switch over to do {} while loop
From: Felipe Balbi ba...@ti.com
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2c7d7cc..4045134 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -827,20 +827,28 @@ omap_i2c_isr(int this_irq, void *dev_id)
struct omap_i2c_dev *dev = dev_id;
u16 bits;
u16 stat;
- int err, count = 0;
+ int err = 0, count = 0;
if (pm_runtime_suspended(dev-dev))
return IRQ_NONE;
- bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- while ((stat = (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG))) bits) {
+ do {
+ bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ stat = bits;
+
+ if (!stat) {
+ /* my work here is done */
+ return IRQ_HANDLED;
+ }
+
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
dev_warn(dev-dev, Too much work in one IRQ\n);
- break;
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
- err = 0;
complete:
/*
* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
@@ -940,7 +948,7 @@ complete:
dev_err(dev-dev, Transmit underflow\n);
dev-cmd_err |= OMAP_I2C_STAT_XUDF;
}
- }
+ } while (stat);
return count ? IRQ_HANDLED : IRQ_NONE;
}
--
1.7.5.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
[PATCHv7 11/23] i2c: omap: switch to platform_get_irq()
From: Felipe Balbi ba...@ti.com
that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index bac1f11..0da8169 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -993,11 +993,12 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq;
+ struct resource *mem;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
irq_handler_t isr;
+ int irq;
int r;
/* NOTE: driver uses the static register mapping */
@@ -1006,10 +1007,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev_err(pdev-dev, no mem resource?\n);
return -ENODEV;
}
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
dev_err(pdev-dev, no irq resource?\n);
- return -ENODEV;
+ return irq;
}
dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
@@ -1043,7 +1045,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev-dev = pdev-dev;
- dev-irq = irq-start;
+ dev-irq = irq;
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
--
1.7.5.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
[PATCHv7 14/23] i2c: omap: always return IRQ_HANDLED
From: Felipe Balbi ba...@ti.com
Always return IRQ_HANDLED otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi ba...@ti.com
[Trivial changes to commitlogs]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7918e48..96fd528 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -962,7 +962,7 @@ complete:
}
} while (stat);
- return count ? IRQ_HANDLED : IRQ_NONE;
+ return IRQ_HANDLED;
}
static const struct i2c_algorithm omap_i2c_algo = {
--
1.7.5.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
[PATCHv7 08/23] i2c: omap: re-factor receive/transmit data loop
From: Felipe Balbi ba...@ti.com
re-factor the common parts to a separate function,
so that code is easier to read and understand.
No functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 204
1 files changed, 82 insertions(+), 122 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fb57221..2c7d7cc 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -752,12 +752,81 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_receive_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_rdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev-buf_len) {
+ dev_err(dev-dev, %s without data,
+ is_rdr ? RDR : RRDY);
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev-buf++ = w;
+ dev-buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ }
+ }
+ }
+}
+
+static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_xdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev-buf_len) {
+ dev_err(dev-dev, %s without data,
+ is_xdr ? XDR : XRDY);
+ break;
+ }
+
+ w = *dev-buf++;
+ dev-buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev-buf_len) {
+ w |= *dev-buf++ 8;
+ dev-buf_len--;
+ }
+ }
+
+ if (dev-errata I2C_OMAP_ERRATA_I462) {
+ int ret;
+
+ ret = errata_omap3_i462(dev);
+ if (ret 0)
+ return ret;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
+ }
+
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
u16 bits;
- u16 stat, w;
+ u16 stat;
int err, count = 0;
if (pm_runtime_suspended(dev-dev))
@@ -810,30 +879,7 @@ complete:
if (dev-fifo_size)
num_bytes = dev-buf_len;
- while (num_bytes--) {
- if (!dev-buf_len) {
- dev_err(dev-dev,
- RDR IRQ while no data
-requested\n);
- break;
- }
-
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- *dev-buf++ = w;
- dev-buf_len--;
-
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev-flags
- OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
- }
- }
+ omap_i2c_receive_data(dev, num_bytes, true);
if (dev-errata I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
@@ -848,77 +894,22 @@ complete:
if (dev-fifo_size)
num_bytes = dev-fifo_size;
- while (num_bytes--) {
- if (!dev-buf_len) {
- dev_err(dev-dev,
- RRDY IRQ while no data
-requested\n);
- break;
- }
-
-
[PATCHv7 01/23] i2c: omap: switch to devm_* API
From: Felipe Balbi ba...@ti.com
that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 41 -
1 files changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d19a49..2d9b03c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -943,7 +943,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
@@ -962,17 +962,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
- if (!ioarea) {
- dev_err(pdev-dev, I2C region already claimed\n);
- return -EBUSY;
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev-base = devm_request_and_ioremap(pdev-dev, mem);
+ if (!dev-base) {
+ dev_err(pdev-dev, I2C region already claimed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -995,11 +994,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
@@ -1057,7 +1051,8 @@ omap_i2c_probe(struct platform_device *pdev)
isr = (dev-rev OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
omap_i2c_isr;
- r = request_irq(dev-irq, isr, IRQF_NO_SUSPEND, pdev-name, dev);
+ r = devm_request_irq(pdev-dev, dev-irq, isr, IRQF_NO_SUSPEND,
+pdev-name, dev);
if (r) {
dev_err(dev-dev, failure requesting irq %i\n, dev-irq);
@@ -1081,7 +1076,7 @@ omap_i2c_probe(struct platform_device *pdev)
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
- goto err_free_irq;
+ goto err_unuse_clocks;
}
of_i2c_register_devices(adap);
@@ -1090,18 +1085,12 @@ omap_i2c_probe(struct platform_device *pdev)
return 0;
-err_free_irq:
- free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1109,12 +1098,10 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
int ret;
platform_set_drvdata(pdev, NULL);
- free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
ret = pm_runtime_get_sync(pdev-dev);
if (IS_ERR_VALUE(ret))
@@ -1123,10 +1110,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.5.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
[PATCHv7 16/23] i2c: omap: resize fifos before each message
From: Felipe Balbi ba...@ti.com
This patch will try to avoid the usage of
draining feature by reconfiguring the FIFO
the start condition of each message based
on the message's size.
By doing that, we will be better utilizing
the FIFO when doing big transfers.
While at that also drop the now unneeded
check for dev-buf_len as we always know
the amount of data to be transmitted.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 83 +
1 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4af123f..f33bc5a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -193,6 +193,7 @@ struct omap_i2c_dev {
u8 *regs;
size_t buf_len;
struct i2c_adapter adapter;
+ u8 threshold;
u8 fifo_size; /* use as flag and value
* fifo_size==0 implies no fifo
* if set, should be trsh+1
@@ -418,13 +419,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
- if (dev-fifo_size) {
- /* Note: setup required fifo size - 1. RTRSH and XTRSH */
- buf = (dev-fifo_size - 1) 8 | OMAP_I2C_BUF_RXFIF_CLR |
- (dev-fifo_size - 1) | OMAP_I2C_BUF_TXFIF_CLR;
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
- }
-
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
@@ -462,6 +456,45 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
+{
+ u16 buf;
+
+ if (dev-flags OMAP_I2C_FLAG_NO_FIFO)
+ return;
+
+ /*
+* Set up notification threshold based on message size. We're doing
+* this to try and avoid draining feature as much as possible. Whenever
+* we have big messages to transfer (bigger than our total fifo size)
+* then we might use draining feature to transfer the remaining bytes.
+*/
+
+ dev-threshold = clamp(size, (u8) 1, dev-fifo_size);
+
+ buf = omap_i2c_read_reg(dev, OMAP_I2C_BUF_REG);
+
+ if (is_rx) {
+ /* Clear RX Threshold */
+ buf = ~(0x3f 8);
+ buf |= ((dev-threshold - 1) 8) | OMAP_I2C_BUF_RXFIF_CLR;
+ } else {
+ /* Clear TX Threshold */
+ buf = ~0x3f;
+ buf |= (dev-threshold - 1) | OMAP_I2C_BUF_TXFIF_CLR;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
+
+ if (dev-rev OMAP_I2C_REV_ON_3630_4430)
+ dev-b_hw = 1; /* Enable hardware fixes */
+
+ /* calculate wakeup latency constraint for MPU */
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-latency = (100 * dev-threshold) /
+ (1000 * dev-speed / 8);
+}
+
/*
* Low level master read/write transaction.
*/
@@ -478,6 +511,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (msg-len == 0)
return -EINVAL;
+ dev-receiver = !!(msg-flags I2C_M_RD);
+ omap_i2c_resize_fifo(dev, msg-len, dev-receiver);
+
omap_i2c_write_reg(dev, OMAP_I2C_SA_REG, msg-addr);
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
@@ -493,7 +529,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
- dev-receiver = !!(msg-flags I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -760,12 +795,6 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
*dev, u8 num_bytes,
u16 w;
while (num_bytes--) {
- if (!dev-buf_len) {
- dev_err(dev-dev, %s without data,
- is_rdr ? RDR : RRDY);
- break;
- }
-
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev-buf++ = w;
dev-buf_len--;
@@ -775,10 +804,8 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
*dev, u8 num_bytes,
* omap4 is 8 bit wide
*/
if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev-buf_len) {
- *dev-buf++ = w 8;
- dev-buf_len--;
- }
+ *dev-buf++ = w 8;
+ dev-buf_len--;
}
}
}
[PATCHv7 19/23] i2c: omap: always return IRQ_HANDLED
From: Felipe Balbi ba...@ti.com
even if our clocks are disabled, we still
handled the IRQ, so we should return IRQ_HANDLED.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 498a462..4a696bd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -862,7 +862,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
int err = 0, count = 0;
if (pm_runtime_suspended(dev-dev))
- return IRQ_NONE;
+ return IRQ_HANDLED;
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
--
1.7.5.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
[PATCHv7 20/23] i2c: omap: switch to threaded IRQ support
From: Felipe Balbi ba...@ti.com
for OMAP2, we can easily switch over to threaded
IRQs on the I2C driver. This will allow us to
spend less time in hardirq context.
Signed-off-by: Felipe Balbi ba...@ti.com
[Trivial formating changes]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 43 +++-
1 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4a696bd..e391370 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -176,6 +176,7 @@ enum {
#define I2C_OMAP_ERRATA_I462 (1 1)
struct omap_i2c_dev {
+ spinlock_t lock; /* IRQ synchronization */
struct device *dev;
void __iomem*base; /* virtual */
int irq;
@@ -854,9 +855,30 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev
*dev, u8 num_bytes,
}
static irqreturn_t
-omap_i2c_isr(int this_irq, void *dev_id)
+omap_i2c_isr(int irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
+ irqreturn_t ret = IRQ_HANDLED;
+ u16 mask;
+ u16 stat;
+
+ spin_lock(dev-lock);
+ mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+
+ if (stat mask)
+ ret = IRQ_WAKE_THREAD;
+
+ spin_unlock(dev-lock);
+
+ return ret;
+}
+
+static irqreturn_t
+omap_i2c_isr_thread(int this_irq, void *dev_id)
+{
+ struct omap_i2c_dev *dev = dev_id;
+ unsigned long flags;
u16 bits;
u16 stat;
int err = 0, count = 0;
@@ -864,6 +886,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (pm_runtime_suspended(dev-dev))
return IRQ_HANDLED;
+ spin_lock_irqsave(dev-lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
@@ -877,6 +900,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (!stat) {
/* my work here is done */
+ spin_unlock_irqrestore(dev-lock, flags);
return IRQ_HANDLED;
}
@@ -985,6 +1009,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
out:
omap_i2c_complete_cmd(dev, err);
+ spin_unlock_irqrestore(dev-lock, flags);
+
return IRQ_HANDLED;
}
@@ -1028,7 +1054,6 @@ omap_i2c_probe(struct platform_device *pdev)
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
- irq_handler_t isr;
int irq;
int r;
@@ -1078,6 +1103,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq;
+ spin_lock_init(dev-lock);
+
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
@@ -1130,10 +1157,14 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
- isr = (dev-rev OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
- omap_i2c_isr;
- r = devm_request_irq(pdev-dev, dev-irq, isr, IRQF_NO_SUSPEND,
-pdev-name, dev);
+ if (dev-rev OMAP_I2C_OMAP1_REV_2)
+ r = devm_request_irq(pdev-dev, dev-irq, omap_i2c_omap1_isr,
+ IRQF_NO_SUSPEND, pdev-name, dev);
+ else
+ r = devm_request_threaded_irq(pdev-dev, dev-irq,
+ omap_i2c_isr, omap_i2c_isr_thread,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
+ pdev-name, dev);
if (r) {
dev_err(dev-dev, failure requesting irq %i\n, dev-irq);
--
1.7.5.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
[PATCHv7 12/23] i2c: omap: bus: add a receiver flag
From: Felipe Balbi ba...@ti.com
that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.
Signed-off-by: Felipe Balbi ba...@ti.com
[Remove unnecessary braces]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0da8169..3be147a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -199,6 +199,7 @@ struct omap_i2c_dev {
*/
u8 rev;
unsignedb_hw:1; /* bad h/w fixes */
+ unsignedreceiver:1; /* true when we're in receiver
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
u16 scllstate;
@@ -492,6 +493,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
+ dev-receiver = !!(msg-flags I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -837,6 +839,12 @@ omap_i2c_isr(int this_irq, void *dev_id)
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
stat = bits;
+ /* If we're in receiver mode, ignore XDR/XRDY */
+ if (dev-receiver)
+ stat = ~(OMAP_I2C_STAT_XDR | OMAP_I2C_STAT_XRDY);
+ else
+ stat = ~(OMAP_I2C_STAT_RDR | OMAP_I2C_STAT_RRDY);
+
if (!stat) {
/* my work here is done */
return IRQ_HANDLED;
--
1.7.5.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
[PATCHv7 18/23] i2c: omap: remove redundant status read
Remove the redundant read of the status register. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 5d4bad4..498a462 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -946,7 +946,6 @@ omap_i2c_isr(int this_irq, void *dev_id) num_bytes = dev-buf_len; ret = omap_i2c_transmit_data(dev, num_bytes, true); - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); if (ret 0) goto out; @@ -962,7 +961,6 @@ omap_i2c_isr(int this_irq, void *dev_id) num_bytes = dev-threshold; ret = omap_i2c_transmit_data(dev, num_bytes, false); - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); if (ret 0) goto out; -- 1.7.5.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
[PATCHv7 21/23] i2c: omap: remove unnecessary pm_runtime_suspended check
From: Felipe Balbi ba...@ti.com
before starting any messages we call pm_runtime_get_sync()
which will make sure that by the time we program a transfer
and our IRQ handler gets called, we're not suspended
anymore.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e391370..6d38a57 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -883,9 +883,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
- if (pm_runtime_suspended(dev-dev))
- return IRQ_HANDLED;
-
spin_lock_irqsave(dev-lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
--
1.7.5.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
[PATCHv7 23/23] i2c: omap: sanitize exit path
From: Felipe Balbi ba...@ti.com
move the goto out label one line down, so that
it can be used when stat is read as zero. All
other exits, can be done with a break statement.
While at that, also break out as soon as we
complete draining IRQ, since at that time
we know we transferred everything there was
to be transferred.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 122f517..b149e32 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -901,27 +901,26 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (!stat) {
/* my work here is done */
- spin_unlock_irqrestore(dev-lock, flags);
- return IRQ_HANDLED;
+ goto out;
}
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
dev_warn(dev-dev, Too much work in one IRQ\n);
- goto out;
+ break;
}
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- goto out;
+ break;
}
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- goto out;
+ break;
}
/*
@@ -934,7 +933,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
- goto out;
+ break;
}
if (stat OMAP_I2C_STAT_RDR) {
@@ -949,7 +948,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
i2c_omap_errata_i207(dev, stat);
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
- continue;
+ break;
}
if (stat OMAP_I2C_STAT_RRDY) {
@@ -972,10 +971,10 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
ret = omap_i2c_transmit_data(dev, num_bytes, true);
if (ret 0)
- goto out;
+ break;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
- continue;
+ break;
}
if (stat OMAP_I2C_STAT_XRDY) {
@@ -987,7 +986,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
ret = omap_i2c_transmit_data(dev, num_bytes, false);
if (ret 0)
- goto out;
+ break;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
@@ -997,19 +996,20 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
dev_err(dev-dev, Receive overrun\n);
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
- goto out;
+ break;
}
if (stat OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
- goto out;
+ break;
}
} while (stat);
-out:
omap_i2c_complete_cmd(dev, err);
+
+out:
spin_unlock_irqrestore(dev-lock, flags);
return IRQ_HANDLED;
--
1.7.5.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
[PATCHv7 22/23] i2c: omap: switch over to autosuspend API
From: Felipe Balbi ba...@ti.com
this helps us reduce unnecessary pm transitions
in case we have another i2c message starting soon.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6d38a57..122f517 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,6 +55,9 @@
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
+/* timeout for pm runtime autosuspend */
+#define OMAP_I2C_PM_TIMEOUT1000/* ms */
+
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
OMAP_I2C_REV_REG = 0,
@@ -645,7 +648,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
omap_i2c_wait_for_bb(dev);
out:
- pm_runtime_put(dev-dev);
+ pm_runtime_mark_last_busy(dev-dev);
+ pm_runtime_put_autosuspend(dev-dev);
return r;
}
@@ -1113,6 +1117,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev-dev);
+ pm_runtime_set_autosuspend_delay(dev-dev, OMAP_I2C_PM_TIMEOUT);
+ pm_runtime_use_autosuspend(dev-dev);
+
r = pm_runtime_get_sync(dev-dev);
if (IS_ERR_VALUE(r))
goto err_free_mem;
@@ -1190,7 +1197,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
- pm_runtime_put(dev-dev);
+ pm_runtime_mark_last_busy(dev-dev);
+ pm_runtime_put_autosuspend(dev-dev);
return 0;
--
1.7.5.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
[PATCHv7 15/23] i2c: omap: simplify IRQ exit path
From: Felipe Balbi ba...@ti.com
instead of having multiple return points, use
a goto statement to make that clearer.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 96fd528..4af123f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -853,24 +853,21 @@ omap_i2c_isr(int this_irq, void *dev_id)
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
dev_warn(dev-dev, Too much work in one IRQ\n);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
complete:
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
/*
@@ -883,8 +880,7 @@ complete:
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat OMAP_I2C_STAT_RDR) {
@@ -949,19 +945,19 @@ complete:
dev_err(dev-dev, Receive overrun\n);
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
if (stat OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
+ goto out;
}
} while (stat);
+out:
+ omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
--
1.7.5.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
[PATCHv7 17/23] i2c: omap: get rid of the complete label
From: Felipe Balbi ba...@ti.com
we can ack stat and complete the command from
the errata handling itself.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f33bc5a..5d4bad4 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -775,6 +775,17 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
if (stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ if (stat OMAP_I2C_STAT_NACK) {
+ dev-cmd_err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ }
+
+ if (stat OMAP_I2C_STAT_AL) {
+ dev_err(dev-dev, Arbitration lost\n);
+ dev-cmd_err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ }
+
return -EIO;
}
@@ -875,7 +886,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
goto out;
}
-complete:
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
@@ -938,7 +948,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, true);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret 0)
- goto complete;
+ goto out;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
continue;
@@ -954,7 +964,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, false);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret 0)
- goto complete;
+ goto out;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
--
1.7.5.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
[PATCHv7 02/23] i2c: omap: simplify num_bytes handling
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes
If the fifo is disabled or fifo_size is 0 the num_bytes
is set to 1. Else it is set to fifo_size or in case of a
draining interrupt the remaining bytes in the buff stat.
So the zero check is redundant and can be safely optimised.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2d9b03c..236cb38 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -812,8 +812,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
8) 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
if (dev-buf_len) {
*dev-buf++ = w;
@@ -855,8 +854,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = 0;
if (dev-buf_len) {
w = *dev-buf++;
--
1.7.5.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 00/29] Move OMAP2+ over to use COMMON clock
On 9/11/2012 12:05 PM, Paul Walmsley wrote:
Hi Rajendra,
A CCF testing branch has been built here. The base is v3.6-rc5, plus the
most recent version of the Common Clock Framework preparation patches that
you posted to the list, [PATCH v4 0/3] Prepare for OMAP2+ movement to
Common Clk, but updated to take RMK's feedback into account. Then the
'clk-next-omap-3.6-rc3' branch from your repo at
'git://github.com/rrnayak/linux.git' was added. Then some patches to drop
the old arch/arm/mach-omap2/clock*_data.c files were added.
This branch was then run through checkpatch.pl, and all of the parenthesis
alignment warnings have been fixed. I don't know what to do about these
crazy DECLARE_CLK_* macros; they have so many arguments that they are
basically impossible to read. Mike and I discussed converting them
into C99 structure initializers with named fields, but am not sure if it's
a readability advantage; it's probably going to be write-only data
either way. I've reflowed many of them to save diffstat but there are
quite a few more to go.
The branch was then built with a set of testing Kconfigs. Here's what was
found: (these are still being investigated)
- The OMAP4-only testconfig and rmk's OMAP4430-SDP Kconfigs failed:
undefined reference to `omap2_clkt_iclk_allow_idle':
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/omap4_testconfig/
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap4430_sdp_oldconfig/
- RMK's OMAP3430-LDP Kconfig failed with a whole set of warnings:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/build/rmk_omap3430_ldp_oldconfig/
The kernel built with omap2plus_defconfig was then booted on several
OMAP2+ boards. Here's what was found:
- The kernel wouldn't boot on either the 3517EVM nor CM-T3517 boards.
This turned out to be due to some missing AM35XX clkdev aliases, the
lack of which cause the CCF code to panic. The patch that adds the
OMAP3 data has been updated to fix that bug and an HSOTGUSB clkdev
alias bug that was found by visual inspection.
- The 3730 Beagle XM issued a warning and stack trace upon boot.
Debugging with Mike, this turned out to be due to a bug in the
modified omap2_init_clksel_parent() function: it returned a register
bitfield rather than an array index. The patch that modifies this
function was then updated to fix the bug.
- The 2420 N800 seems to have some kind of MMC-related problem
that prevents it from booting. Still looking into this:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/2420n800/2420n800_log.txt
Then the branch was PM-tested to determine whether it can suspend and
serial-resume properly, and whether dynamic idle works. These tests
didn't go so well:
- 3530ES3 Beagleboard here was able to enter retention-idle
suspend, and leave it with serial wakeup, but the CORE powerdomain never
entered a low-power state. Dynamic retention-idle with serial wakeup
never resumed, and the test stopped there:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3530es3beagle/3530es3beagle_log.txt
- 37xx EVM and 3730 Beagle XM fared better; they made it through the whole
test program, but the CORE powerdomain also never entered a low-power
state:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/37xxevm/37xxevm_log.txt
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/3730beaglexm/3730beaglexm_log.txt
- 4430ES2 Panda never made past the first retention-idle suspend:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/boot/4430es2panda/4430es2panda_log.txt
Could you please take a look and see if you can identify why the patches
aren't passing the tests? I can't send these upstream until they pass the
PM tests.
This testing branch can be found at the branch named
common_clk_testing_devel_3.7 of git://git.pwsan.com/linux-2.6
The testbed reports from this branch can be found here:
http://www.pwsan.com/omap/testlogs/common_clk_testing_devel_3.7/20120911000742/
And the baseline test reports from v3.6-rc5 can be found here:
http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/
I tried this branch on BeagleBone platform and needs one small typo
correction in hwmod data patch (submitted earlier, which you are going
to queue it)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index de7a3ab..767a77d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1441,7 +1441,7 @@ static struct omap_hwmod am33xx_mmc2_hwmod = {
.clkdm_name = l3s_clkdm,
Re: [PATCH v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
On 9/11/2012 2:39 PM, Kishon Vijay Abraham I wrote:
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 33
drivers/usb/musb/omap2430.c| 54
2 files changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..29a043e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,omap4-musb or ti,omap3-musb
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
reg and interrupt properties are missing here.
I would encourage to specify reg and interrupt properties in every
node getting newly added to the OMAP DTS files.
Thanks,
Vaibhav
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f4d9503..d96873b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -470,8 +471,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -501,6 +505,42 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef
[PATCH v9 0/3] GPMC driver conversion
Hi, Basic gpmc driver conversion series. Driver that is now created out of gpmc code is a simple one, it handles tasks that were earlier executed by gpmc_init. Now instead of relying on cpu_is_* checks, it obtains resources and clk handle in the standard Linux way. The existing gpmc interface works as was without this series. HWMOD patch also has been brought into this series back with v7 series As this creates only a basic driver, further gpmc driver work can be based over this, while having a driver first in place. This series is based on l-o/testing-cleanup as on 11-Sep-12, i.e. over commit, e274bffb ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 It is available @git://gitorious.org/x0148406-public/linux-kernel.git gpmc-drv-v9 This series has been tested on omap3evm (rev G). GPMC (General Purpose Memory Controller) in brief: GPMC is an unified memory controller dedicated to interfacing external memory devices like Asynchronous SRAM like memories and application specific integrated circuit devices. Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash Pseudo-SRAM devices GPMC details can be referred in AM335X Technical Reference Manual @ http://www.ti.com/lit/pdf/spruh73 Regards Afzal v9: 3xxx gpmc clock domain as core_l3_clkdm Lower case hex numbers v8: Use feature flag to decide whether wr_access and wr_data_mux_bus timings has to be configured (PATCH 3/3) v7: Create a simple driver that gets resources clk the standard Linux way Pull in HMWOD patch back into this series v6: Capability flag added that stores features based on revision Macros used for finding revision Return value from memory setup function corrected Comments added to clarify handling of device type, size Bool type time setting patch removed as has been taken care in [2] Handle variable number of waitpin Warn if driver is unable to configure interrupt Enhance some of commit messages Handle shared writeprotect case Fix a bug in gpmc_create_device Get clk from hwmod Remove unwanted code v5: Make this a purely driver conversion series, i.e. gpmc-mtd interactions has been made as a separate series, so is adding hwmod entry for OMAP2/3. And modifying gpmc peripheral platform initialization has been separated out of this series, so is migrating boards to use new driver interface. GPMC driver conversion which was done in a few patches in v4 has been tranformed to series of small patches. Also care has been taken care that old interface will not break with any of these patches, so both interfaces can coexist. This helps in converting boards one-by-one gradually. Acquiring CS has been thrown out. And conclusive comments on v4 has been addressed. v4: Handle wait pin (except for interrupts), enhance configuration timing interface of GPMC to take care of all boards. Dynamic allocation of interrupt instead of static. Convert remaining peripherals to work with GPMC driver. Handle acquiring NAND CS#, adapt to HWMOD, update HWMOD OMAP2/3 entries, other minor commenst on v3. v3: Single device structure passed from platform for peripherals using multiple CS instead of using multiple device structure having a few redundant data, handle interrupts, GPMC NAND handling by GPMC NAND driver instead of GPMC driver v2: Avoid code movement that kept similar code together (for easy review) Afzal Mohammed (3): ARM: OMAP2/3: hwmod data: add gpmc ARM: OMAP2+: gpmc: Adapt to HWMOD ARM: OMAP2+: gpmc: minimal driver support arch/arm/mach-omap2/gpmc.c | 193 +++- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 44 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 ++ arch/arm/mach-omap2/omap_hwmod_common_data.h |1 + arch/arm/mach-omap2/prcm-common.h |2 + 7 files changed, 280 insertions(+), 50 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 v9 1/3] ARM: OMAP2/3: hwmod data: add gpmc
Add gpmc hwmod and associated interconnect data
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 44 -
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
arch/arm/mach-omap2/prcm-common.h |2 +
6 files changed, 136 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 4e81637..5fcd225 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -535,6 +535,15 @@ static struct omap_hwmod_addr_space
omap2420_counter_32k_addrs[] = {
{ }
};
+static struct omap_hwmod_addr_space omap2420_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6800a000,
+ .pa_end = 0x6800afff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
.master = omap2xxx_l4_wkup_hwmod,
.slave = omap2xxx_counter_32k_hwmod,
@@ -543,6 +552,14 @@ static struct omap_hwmod_ocp_if
omap2420_l4_wkup__counter_32k = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if omap2420_l3__gpmc = {
+ .master = omap2xxx_l3_main_hwmod,
+ .slave = omap2xxx_gpmc_hwmod,
+ .clk= core_l3_ck,
+ .addr = omap2420_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -586,6 +603,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__msdi1,
omap2420_l4_core__hdq1w,
omap2420_l4_wkup__counter_32k,
+ omap2420_l3__gpmc,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index ceb23c3..a560563 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -887,6 +887,15 @@ static struct omap_hwmod_addr_space
omap2430_counter_32k_addrs[] = {
{ }
};
+static struct omap_hwmod_addr_space omap2430_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6e00,
+ .pa_end = 0x6e000fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
.master = omap2xxx_l4_wkup_hwmod,
.slave = omap2xxx_counter_32k_hwmod,
@@ -895,6 +904,14 @@ static struct omap_hwmod_ocp_if
omap2430_l4_wkup__counter_32k = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if omap2430_l3__gpmc = {
+ .master = omap2xxx_l3_main_hwmod,
+ .slave = omap2xxx_gpmc_hwmod,
+ .clk= core_l3_ck,
+ .addr = omap2430_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -945,6 +962,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
omap2430_l4_core__mcbsp5,
omap2430_l4_core__hdq1w,
omap2430_l4_wkup__counter_32k,
+ omap2430_l3__gpmc,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index ceb3052..d848c7a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -173,6 +173,26 @@ struct omap_hwmod_class omap2xxx_mcspi_class = {
};
/*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2xxx_gpmc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2xxx_gpmc_hwmod_class = {
+ .name = gpmc,
+ .sysc = omap2xxx_gpmc_sysc,
+};
+
+/*
* IP blocks
*/
@@ -724,7 +744,6 @@ struct omap_hwmod omap2xxx_mcspi2_hwmod = {
.dev_attr = omap_mcspi2_dev_attr,
};
-
static struct omap_hwmod_class omap2xxx_counter_hwmod_class = {
.name = counter,
};
@@ -743,3 +762,26 @@ struct omap_hwmod
[PATCH v9 2/3] ARM: OMAP2+: gpmc: Adapt to HWMOD
Create API for platforms to adapt GPMC to HWMOD
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 055ae8b..5462666 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -31,10 +31,13 @@
#include plat/cpu.h
#include plat/gpmc.h
#include plat/sdrc.h
+#include plat/omap_device.h
#include soc.h
#include common.h
+#defineDEVICE_NAME omap-gpmc
+
/* GPMC register offsets */
#define GPMC_REVISION 0x00
#define GPMC_SYSCONFIG 0x10
@@ -898,6 +901,25 @@ static int __init gpmc_init(void)
}
postcore_initcall(gpmc_init);
+static int __init omap_gpmc_init(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ char *oh_name = gpmc;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ pdev = omap_device_build(DEVICE_NAME, -1, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
+
+ return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
+}
+postcore_initcall(omap_gpmc_init);
+
static irqreturn_t gpmc_handle_irq(int irq, void *dev)
{
int i;
--
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 v9 3/3] ARM: OMAP2+: gpmc: minimal driver support
Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 171 +++-
1 files changed, 122 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5462666..a628fdc 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -24,6 +24,7 @@
#include linux/io.h
#include linux/module.h
#include linux/interrupt.h
+#include linux/platform_device.h
#include asm/mach-types.h
#include plat/gpmc.h
@@ -86,6 +87,12 @@
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
+#defineGPMC_REVISION_MAJOR(l) ((l 4) 0xf)
+#defineGPMC_REVISION_MINOR(l) (l 0xf)
+
+#defineGPMC_HAS_WR_ACCESS 0x1
+#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+
/* XXX: Only NAND irq has been considered,currently these are the only ones
used
*/
#defineGPMC_NR_IRQ 2
@@ -131,7 +138,10 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
-
+static struct device *gpmc_dev;
+static int gpmc_irq;
+static resource_size_t phys_base, mem_size;
+static unsigned gpmc_capability;
static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
@@ -321,10 +331,10 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
- if (cpu_is_omap34xx()) {
+ if (gpmc_capability GPMC_HAS_WR_DATA_MUX_BUS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+ if (gpmc_capability GPMC_HAS_WR_ACCESS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
- }
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
@@ -434,6 +444,19 @@ static int gpmc_cs_insert_mem(int cs, unsigned long base,
unsigned long size)
return r;
}
+static int gpmc_cs_delete_mem(int cs)
+{
+ struct resource *res = gpmc_cs_mem[cs];
+ int r;
+
+ spin_lock(gpmc_mem_lock);
+ r = release_resource(gpmc_cs_mem[cs]);
+ res-start = res-end = 0;
+ spin_unlock(gpmc_mem_lock);
+
+ return r;
+}
+
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
struct resource *res = gpmc_cs_mem[cs];
@@ -770,7 +793,7 @@ static void gpmc_irq_noop(struct irq_data *data) { }
static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
-static int gpmc_setup_irq(int gpmc_irq)
+static int gpmc_setup_irq(void)
{
int i;
u32 regval;
@@ -814,7 +837,37 @@ static int gpmc_setup_irq(int gpmc_irq)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, gpmc, NULL);
}
-static void __init gpmc_mem_init(void)
+static __exit int gpmc_free_irq(void)
+{
+ int i;
+
+ if (gpmc_irq)
+ free_irq(gpmc_irq, NULL);
+
+ for (i = 0; i GPMC_NR_IRQ; i++) {
+ irq_set_handler(gpmc_client_irq[i].irq, NULL);
+ irq_set_chip(gpmc_client_irq[i].irq, no_irq_chip);
+ irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
+ }
+
+ irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
+
+ return 0;
+}
+
+static void __devexit gpmc_mem_exit(void)
+{
+ int cs;
+
+ for (cs = 0; cs GPMC_CS_NUM; cs++) {
+ if (!gpmc_cs_mem_enabled(cs))
+ continue;
+ gpmc_cs_delete_mem(cs);
+ }
+
+}
+
+static void __devinit gpmc_mem_init(void)
{
int cs;
unsigned long boot_rom_space = 0;
@@ -841,65 +894,85 @@ static void __init gpmc_mem_init(void)
}
}
-static int __init gpmc_init(void)
+static __devinit int gpmc_probe(struct platform_device *pdev)
{
u32 l;
- int ret = -EINVAL;
- int gpmc_irq;
- char *ck = NULL;
-
- if (cpu_is_omap24xx()) {
- ck = core_l3_ck;
- if (cpu_is_omap2420())
- l = OMAP2420_GPMC_BASE;
- else
- l = OMAP34XX_GPMC_BASE;
- gpmc_irq = 20 + OMAP_INTC_START;
- } else if (cpu_is_omap34xx()) {
- ck = gpmc_fck;
- l = OMAP34XX_GPMC_BASE;
- gpmc_irq = 20 + OMAP_INTC_START;
- } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
- /* Base address and irq number are same for OMAP4/5 */
- ck = gpmc_ck;
- l = OMAP44XX_GPMC_BASE;
- gpmc_irq = 20 + OMAP44XX_IRQ_GIC_START;
- }
+ struct resource *res;
- if (WARN_ON(!ck))
- return ret;
+ res =
Re: [PATCH v2] watchdog: omap_wdt: convert to new watchdog core
On Saturday 08 September 2012 11:34 PM, Aaro Koskinen wrote:
-static struct platform_device *omap_wdt_dev;
-
static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, initial watchdog timeout (in seconds));
-static unsigned int wdt_trgr_pattern = 0x1234;
-static DEFINE_SPINLOCK(wdt_lock);
-
you may want to describe this more.
struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
- int omap_wdt_users;
+ boolomap_wdt_users;
struct resource *mem;
- struct miscdevice omap_wdt_miscdev;
+ int wdt_trgr_pattern;
+ struct mutexlock; /* to avoid races with PM */
};
--
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 v8 2/3] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Jon, On Thu, Sep 06, 2012 at 01:25:23, Hunter, Jon wrote: Nit-pick, I see some devices writing the above as ... WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name); return IS_ERR(pdev) ? PTR_ERR(pdev) : 0; Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Thanks for your reviews, updated series has been posted Regards Afzal
Re: [PATCHv7 00/23]I2C big cleanup
On Tuesday 11 September 2012 03:11 PM, Shubhrajyoti D wrote:
Changes since v1:
- removed tabification on patch 6/17
- removed dev_err() which was introduced on patch 09/17
Changes since v2:
- do not set full fifo depth in the RDR interrupt.
- some changelog updates.
- rebase to the Wolfram's tree.
Changes since v3:
- Remove a redundant read of status register
- Read the dev-buf_len variable instead of the register
as the information of the remaining bytes is there.
Changes since v4:
- Ack the arbitration lost.
- Rebase to the i2c-embedded/for-next branch.
Changes since v5:
- Rebase to latest mainline
- Added some more cleanup patches so as have a consolidated series.
Changes since v6:
- Fix comments on setting the pdev to NULL.
- Trivial changelog update
Previous discussions can be found here
http://www.spinics.net/lists/linux-i2c/msg09482.html
Also this gives better performance
With the patches:
Performance counter stats for '/build/i2c/bin/i2cdump -y -f 1 0x48
b':
78.796376 task-clock#0.453 CPUs
utilized
516 context-switches #0.007
M/sec
0 CPU-migrations#0.000
K/sec
114 page-faults #0.001 M/sec
0.174011183 seconds time elapsed
Without the patches
Performance counter stats for '/build/i2c/bin/i2cdump -y -f 1 0x48
b':
123.504640 task-clock#0.049 CPUs
utilized
337 context-switches #0.003
M/sec
0 CPU-migrations#0.000
K/sec
144 page-faults #0.001
M/sec
2.534424040 seconds time elapsed
The auto suspend is probably the one :-)
This is the cleanup only series.
Tested on omap4sdp and 3430sdp.
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://gitorious.org/linus-tree/linus-tree.git for_3.7/i2c/big_cleanup
Felipe Balbi (22):
i2c: omap: switch to devm_* API
i2c: omap: simplify num_bytes handling
i2c: omap: decrease indentation level on data handling
i2c: omap: add blank lines
i2c: omap: simplify omap_i2c_ack_stat()
i2c: omap: split out [XR]DR and [XR]RDY
i2c: omap: improve i462 errata handling
i2c: omap: re-factor receive/transmit data loop
i2c: omap: switch over to do {} while loop
i2c: omap: ack IRQ in parts
i2c: omap: switch to platform_get_irq()
i2c: omap: bus: add a receiver flag
i2c: omap: simplify errata check
i2c: omap: always return IRQ_HANDLED
i2c: omap: simplify IRQ exit path
i2c: omap: resize fifos before each message
i2c: omap: get rid of the complete label
i2c: omap: always return IRQ_HANDLED
i2c: omap: switch to threaded IRQ support
i2c: omap: remove unnecessary pm_runtime_suspended check
i2c: omap: switch over to autosuspend API
i2c: omap: sanitize exit path
Shubhrajyoti D (1):
i2c: omap: remove redundant status read
drivers/i2c/busses/i2c-omap.c | 442
+
1 files changed, 271 insertions(+), 171 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 v9 00/13] usb: musb: adding multi instance support
Hi, On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote: This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to felipe/master [1] branch + Vaibhav baseport patches on his tree at [4] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [2] + Damodar's recent patch at [3] + Ajay's Damodar's patches at [5] and [6] included in this series 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary 2. http://marc.info/?l=linux-usbm=134070369306112w=2 3. http://marc.info/?l=linux-usbm=134200284230689w=2 4. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-stagi ng 5. http://marc.info/?l=linux-usbm=134200285530701w=2 6. http://marc.info/?l=linux-usbm=134208820028625w=2 Changes from v8: - included Sergei's comment, removing underscore in device tree file - removed duplicated signoff from patches Changes from v7: - patches rebased on felipe/master branch verified - included additional two patches 0001 0002 as part of this series which are already submitted [5] [6] Changes from v6: - Removed parent_pdev to get glue and used dev_get_getdrv() as per Felipe's comment - use pr_debug() instead of pr_info() as per Felipe's comment Changes from v5: - Removed musb-id as per Felipe's comment - used nop_ida as per Felipe's comment Changes from v4: - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() - Fixed Felipe's comment on using dev_set_mask() Changes from v3: - Fixed Kishon's comment on removing id from phy struct and removing unneeded #else part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the ti string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] I tried appliying this, but this doesn't apply. Please rebase on my musb branch. Unfortunately there's no time anymore to wait otherwise the entire musb branch will miss this merge window. I'm sorry Felipe, patch set is ready, I will re-send the patches shortly by today. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 0/3] GPMC driver conversion
Hi Tony, On Sat, Sep 08, 2012 at 03:40:34, Tony Lindgren wrote: Great, this all looks good to me. I suggest that on top of this we add minimal devicetree binding that does not even attempt to deal with the timings yet. Then once the minimal devicetree binding is in place, we can call the current GPMC timing functions using the compatible flags and auxdata in the gpmc.c driver. That way we get all the legacy boards booting with GPMC support for smsc911x etc, and can even remove some less used board-*.c files. Thanks. I agree with your suggestion and would be proceeding so as to achieve minimal devicetree support. And a newer version of this series has been posted. Then we just add the generic GPMC timings when we're happy with those. Meanwhile can you send me the gpmc debug logs for n800 where tusb patch on generic timing was causing the hang along with logs without the culprit tusb patch so that we could arrive at generic gpmc timings. Regards Afzal
Re: [balbi-usb:master 33/36] drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from constant value (24000000 becomes 0)
On Mon, Sep 10, 2012 at 07:05:15PM +0200, Sebastian Andrzej Siewior wrote:
On 09/10/2012 06:40 PM, Fengguang Wu wrote:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
head: d9c88901337158c9f253a7de58a10b5125d61d26
commit: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f [33/36] usb: gadget: remove
usb_gadget_controller_number()
All sparse warnings:
Once again, thank you.
You are welcome!
drivers/usb/gadget/f_acm.c:287:9: sparse: advancing past deep designator
drivers/usb/gadget/f_obex.c:60:9: sparse: advancing past deep designator
drivers/usb/gadget/f_serial.c:134:9: sparse: advancing past deep
designator
drivers/usb/gadget/serial.c:66:9: sparse: advancing past deep designator
I don't get these. The purpose is an all NULL terminating entry. Could
this be a sparse bug or is the [] / {} switch not really good C code?
http://marc.info/?l=linux-sparsem=130673652023059w=4
According to Dan's explanations, I'll filter out these warnings in future.
+ drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from
constant value (2400 becomes 0)
I've sent a patch for this.
Thank you!
Fengguang
--
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 3/3] usb: musb: omap: Add device tree support for omap musb glue
Hi,
On Tue, Sep 11, 2012 at 3:23 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 9/11/2012 2:39 PM, Kishon Vijay Abraham I wrote:
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 33
drivers/usb/musb/omap2430.c| 54
2 files changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..29a043e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,omap4-musb or ti,omap3-musb
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
reg and interrupt properties are missing here.
I would encourage to specify reg and interrupt properties in every
node getting newly added to the OMAP DTS files.
Sure. will add that in my next version.
Thanks
Kishon
--
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: dts: AM33XX: fix gpio node numbering to match hardware
On Tue, Sep 11, 2012 at 04:57:08AM +, Hiremath, Vaibhav wrote:
On Mon, Sep 10, 2012 at 21:50:20, Porter, Matt wrote:
On AM33xx, the datasheet and TRM refer to four GPIO instances that
are 0-based, GPIO0-3.
Thanks Matt,
I think Anil labeled it as gpio1-4 due to hwmod naming convention, as you
can not have gpioo id = 0 (refer to arch/arm/mach-omap2/gpio.c).
Right, and that convention originally came from the assumption that
everything would be 1-based like OMAP3/4.
But in case of DT we should simply follow TRM/Spec, as naming convention is
based on base-addr and not id, so your patch looks good me.
Yes, my biggest concern here was the coming frustration that the end
user or system integrator would have with these labels not matching
the docs that have been around for a year. It would be !sane to have
somebody look at a schematic and then write their dts with a value that
doesn't match the h/w. That would run counter to the fundamental
requirement that DT is a description of the hardware. The user led patch
was already the first example of that where the comments mentioned gpio1
in the pinmux data but the data referenced the gpio2 label.
-Matt
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..1369bfc 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -62,7 +62,7 @@
reg = 0x4820 0x1000;
};
- gpio1: gpio@44e07000 {
+ gpio0: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
gpio-controller;
@@ -74,7 +74,7 @@
interrupts = 96;
};
- gpio2: gpio@4804c000 {
+ gpio1: gpio@4804c000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio2;
gpio-controller;
@@ -86,7 +86,7 @@
interrupts = 98;
};
- gpio3: gpio@481ac000 {
+ gpio2: gpio@481ac000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio3;
gpio-controller;
@@ -98,7 +98,7 @@
interrupts = 32;
};
- gpio4: gpio@481ae000 {
+ gpio3: gpio@481ae000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
gpio-controller;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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/dts: Add omap3-beagle.dts
Hi Jon,
On 09/11/2012 12:57 AM, Jon Hunter wrote:
Add a minimal dts for original OMAP3430/3530 version of the Beagle board. This
version of the Beagle board has 256MB of DDR and features the same TWL4030
power management IC (PMIC) as the Beagle board XM.
Thanks for the patch.
Given that the Beagle and Beagle-XM boards use the same PMIC, move the
definition of the VSIM regulator into the TWL4030.dtsi file so that we do not
need to duplicate in the Beagle board dts file.
Good, catch, regulator definition has indeed nothing to do outside the
twl4030.dtsi.
This has been boot tested on an OMAP3530 Beagle board and verifing that the
SD/MMC interface is working with a SD card.
This patch is generated on top of Tony's patch for adding the Beagle board XM
dts file [1].
Tony has just updated his devel-dt with the DTS series I pushed plus the
beagle-xm introduction, so I'm gonna put this one on top and built a
for_3.7/dts_part2 branch sinec there are a couplf of USB / AM33xx pending.
Thanks,
Benoit
[1] http://marc.info/?l=linux-omapm=134695790516943w=2
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 -
arch/arm/boot/dts/omap3-beagle.dts| 46
+
arch/arm/boot/dts/twl4030.dtsi|6 +
arch/arm/mach-omap2/Makefile.boot |3 ++-
4 files changed, 54 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index df6d485..ef2c711 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -26,12 +26,6 @@
reg = 0x48;
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
-
- vsim: regulator-vsim {
- compatible = ti,twl4030-vsim;
- regulator-min-microvolt = 180;
- regulator-max-microvolt = 300;
- };
};
};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
new file mode 100644
index 000..90790d9
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
2012?
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI OMAP3 BeagleBoard;
+ compatible = ti,omap3-beagle, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ff00017..c5337d4 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,12 @@
regulator-max-microvolt = 315;
};
+ vsim: regulator-vsim {
+ compatible = ti,twl4030-vsim;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 300;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
diff --git a/arch/arm/mach-omap2/Makefile.boot
b/arch/arm/mach-omap2/Makefile.boot
index 0e602b7..a469a55 100644
--- a/arch/arm/mach-omap2/Makefile.boot
+++ b/arch/arm/mach-omap2/Makefile.boot
@@ -3,7 +3,8 @@ params_phys-y := 0x8100
initrd_phys-y:= 0x8080
dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb
-dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle-xm.dtb omap3-evm.dtb
+dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-beagle-xm.dtb \
+omap3-evm.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-var_som.dtb omap4-sdp.dtb
dtb-$(CONFIG_SOC_OMAP5) += omap5-evm.dtb
--
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: dts: AM33XX: fix gpio node numbering to match hardware
On Tue, Sep 11, 2012 at 16:59:05, Porter, Matt wrote:
On Tue, Sep 11, 2012 at 04:57:08AM +, Hiremath, Vaibhav wrote:
On Mon, Sep 10, 2012 at 21:50:20, Porter, Matt wrote:
On AM33xx, the datasheet and TRM refer to four GPIO instances that
are 0-based, GPIO0-3.
Thanks Matt,
I think Anil labeled it as gpio1-4 due to hwmod naming convention, as you
can not have gpioo id = 0 (refer to arch/arm/mach-omap2/gpio.c).
Right, and that convention originally came from the assumption that
everything would be 1-based like OMAP3/4.
But in case of DT we should simply follow TRM/Spec, as naming convention is
based on base-addr and not id, so your patch looks good me.
Yes, my biggest concern here was the coming frustration that the end
user or system integrator would have with these labels not matching
the docs that have been around for a year. It would be !sane to have
somebody look at a schematic and then write their dts with a value that
doesn't match the h/w. That would run counter to the fundamental
requirement that DT is a description of the hardware. The user led patch
was already the first example of that where the comments mentioned gpio1
in the pinmux data but the data referenced the gpio2 label.
I understand and your patch is already fixing the biggest concern here,
right.
Thanks,
Vaibhav
-Matt
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..1369bfc 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -62,7 +62,7 @@
reg = 0x4820 0x1000;
};
- gpio1: gpio@44e07000 {
+ gpio0: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
gpio-controller;
@@ -74,7 +74,7 @@
interrupts = 96;
};
- gpio2: gpio@4804c000 {
+ gpio1: gpio@4804c000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio2;
gpio-controller;
@@ -86,7 +86,7 @@
interrupts = 98;
};
- gpio3: gpio@481ac000 {
+ gpio2: gpio@481ac000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio3;
gpio-controller;
@@ -98,7 +98,7 @@
interrupts = 32;
};
- gpio4: gpio@481ae000 {
+ gpio3: gpio@481ae000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
gpio-controller;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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 00/21] OMAP UART Patches
On Sunday 09 September 2012 12:34 AM, Felipe Balbi wrote: In addition, IMO, if this was only tested on Panda (as suggested by earlier cover letters), it really should not have been merged until it got some broader testing. Shubhro's got his Tested-by tag. I believe he tested on beagleboard and omap4sdp. Shubhro, can you confirm which platforms you tested the UART patches ? cheers Felipe I had boot tested on omap3sdp and onap4 sdp and did pm testing on both with omap3 hitting off. -- 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 15/17] ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+
Hi Tony, As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watch...@vger.kernel.org Cc: Wim Van Sebroeck w...@iguana.be Acked-by for the watchdog part. Kind regards, Wim. -- 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
[Help]: Omap-serial: UART DMA Engine
Hi Russell, I am currently working on implementing DMA Engine for omap serial driver. Came to know from santosh that you had suggested that certain modification need to be done in the tty core layer, which I am unaware of. Can you please explain what sort of changes need to be done? -- 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 3/3] usb: musb: omap: Add device tree support for omap musb glue
On Tue, Sep 11, 2012 at 16:54:37, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Tue, Sep 11, 2012 at 3:23 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 9/11/2012 2:39 PM, Kishon Vijay Abraham I wrote:
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 33
drivers/usb/musb/omap2430.c| 54
2 files changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..29a043e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,omap4-musb or ti,omap3-musb
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type
of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
reg and interrupt properties are missing here.
I would encourage to specify reg and interrupt properties in every
node getting newly added to the OMAP DTS files.
Sure. will add that in my next version.
I saw there is some discussion going-on for which baseline to use, so make
sure that you test the patches on top of below patch (already available in
linux-omap/devel-dt)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013
Thanks,
Vaibhav
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/13] usb: musb: adding multi instance support
On Tue, Sep 11, 2012 at 10:45:44AM +, B, Ravi wrote: Hi, On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote: This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to felipe/master [1] branch + Vaibhav baseport patches on his tree at [4] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [2] + Damodar's recent patch at [3] + Ajay's Damodar's patches at [5] and [6] included in this series 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary 2. http://marc.info/?l=linux-usbm=134070369306112w=2 3. http://marc.info/?l=linux-usbm=134200284230689w=2 4. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-stagi ng 5. http://marc.info/?l=linux-usbm=134200285530701w=2 6. http://marc.info/?l=linux-usbm=134208820028625w=2 Changes from v8: - included Sergei's comment, removing underscore in device tree file - removed duplicated signoff from patches Changes from v7: - patches rebased on felipe/master branch verified - included additional two patches 0001 0002 as part of this series which are already submitted [5] [6] Changes from v6: - Removed parent_pdev to get glue and used dev_get_getdrv() as per Felipe's comment - use pr_debug() instead of pr_info() as per Felipe's comment Changes from v5: - Removed musb-id as per Felipe's comment - used nop_ida as per Felipe's comment Changes from v4: - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() - Fixed Felipe's comment on using dev_set_mask() Changes from v3: - Fixed Kishon's comment on removing id from phy struct and removing unneeded #else part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the ti string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] I tried appliying this, but this doesn't apply. Please rebase on my musb branch. Unfortunately there's no time anymore to wait otherwise the entire musb branch will miss this merge window. I'm sorry Felipe, patch set is ready, I will re-send the patches shortly by today. Thanks a lot. So I'll wait for a few more hours before sending out my musb pull request ;-) -- balbi signature.asc Description: Digital signature
RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
+ Andrew, On Thu, Sep 06, 2012 at 20:12:07, Cousson, Benoit wrote: On 09/05/2012 04:41 PM, Hiremath, Vaibhav wrote: ... There are other patches which are pending, arm/dts: AM33XX: Convert all hex numbers to lower-case https://patchwork.kernel.org/patch/1377351/ arm/dts: AM33XX: Specify reg and interrupt property for all nodes https://patchwork.kernel.org/patch/1377361/ OK, so these ones are fine, you should just rebase them because theyu are conflicting with patches already inside lo/devel-dt Probably your Ack is required for, ARM: AM33XX: clock: Add dcan clock aliases for device-tree https://patchwork.kernel.org/patch/1377061/ Paul already queued this one so it is fine. RTC: I am not sure how to deal with RTC DT support, as I understand the list is very unresponsive there. OK, so I did have the same issue for TWL RTC since the maintainer is no longer very active. In that case you should go through Andrew Morton. Andrew, Can you please merge these omap-rtc patches, there are no review comments so far and I believe it should be safe now to merge. Thanks, Vaiibhav Regards, Benoit http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg23253.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 v9 00/13] usb: musb: adding multi instance support
On Fri, Aug 31, 2012 at 04:39:46PM +0530, Ravi Babu wrote: This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to felipe/master [1] branch + Vaibhav baseport patches on his tree at [4] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [2] + Damodar's recent patch at [3] + Ajay's Damodar's patches at [5] and [6] included in this series 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary 2. http://marc.info/?l=linux-usbm=134070369306112w=2 3. http://marc.info/?l=linux-usbm=134200284230689w=2 4. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-sta gi ng 5. http://marc.info/?l=linux-usbm=134200285530701w=2 6. http://marc.info/?l=linux-usbm=134208820028625w=2 Changes from v8: - included Sergei's comment, removing underscore in device tree file - removed duplicated signoff from patches Changes from v7: - patches rebased on felipe/master branch verified - included additional two patches 0001 0002 as part of this series which are already submitted [5] [6] Changes from v6: - Removed parent_pdev to get glue and used dev_get_getdrv() as per Felipe's comment - use pr_debug() instead of pr_info() as per Felipe's comment Changes from v5: - Removed musb-id as per Felipe's comment - used nop_ida as per Felipe's comment Changes from v4: - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() - Fixed Felipe's comment on using dev_set_mask() Changes from v3: - Fixed Kishon's comment on removing id from phy struct and removing unneeded #else part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the ti string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] I tried appliying this, but this doesn't apply. Please rebase on my musb branch. Unfortunately there's no time anymore to wait otherwise the entire musb branch will miss this merge window. I'm sorry Felipe, patch set is ready, I will re-send the patches shortly by today. Thanks a lot. So I'll wait for a few more hours before sending out my musb pull request ;-) Thanks Felipe, these v9 patches are created on felipe/master branch. Now working on, to rebase on felipe/musb branch, will try to provide by end of today. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: Add omap3-beagle.dts
On 09/11/2012 01:29 PM, Benoit Cousson wrote: Hi Jon, On 09/11/2012 12:57 AM, Jon Hunter wrote: Add a minimal dts for original OMAP3430/3530 version of the Beagle board. This version of the Beagle board has 256MB of DDR and features the same TWL4030 power management IC (PMIC) as the Beagle board XM. Thanks for the patch. Given that the Beagle and Beagle-XM boards use the same PMIC, move the definition of the VSIM regulator into the TWL4030.dtsi file so that we do not need to duplicate in the Beagle board dts file. Good, catch, regulator definition has indeed nothing to do outside the twl4030.dtsi. This has been boot tested on an OMAP3530 Beagle board and verifing that the SD/MMC interface is working with a SD card. This patch is generated on top of Tony's patch for adding the Beagle board XM dts file [1]. Tony has just updated his devel-dt with the DTS series I pushed plus the beagle-xm introduction, so I'm gonna put this one on top and built a for_3.7/dts_part2 branch sinec there are a couplf of USB / AM33xx pending. OK, so in fact, it does not apply very well due to all the changes I introduced in my for_3.7/dts pull and then the beagle is now missing all the LEDs support recently added. So you should refresh that patch taking the latest devel-dt branch as a base and copying the latest beagle-xm.dts file. diff --git a/arch/arm/mach-omap2/Makefile.boot b/arch/arm/mach-omap2/Makefile.boot index 0e602b7..a469a55 100644 --- a/arch/arm/mach-omap2/Makefile.boot +++ b/arch/arm/mach-omap2/Makefile.boot @@ -3,7 +3,8 @@ params_phys-y:= 0x8100 initrd_phys-y := 0x8080 dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb -dtb-$(CONFIG_ARCH_OMAP3)+= omap3-beagle-xm.dtb omap3-evm.dtb +dtb-$(CONFIG_ARCH_OMAP3)+= omap3-beagle.dtb omap3-beagle-xm.dtb \ + omap3-evm.dtb You'd better duplicate the whole line like it is done for OMAP4 instead of using the \ +dtb-$(CONFIG_ARCH_OMAP3) += omap3-evm.dtb Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/21] OMAP UART Patches
On Tue, Sep 11, 2012 at 05:01:06PM +0530, Shubhrajyoti wrote: On Sunday 09 September 2012 12:34 AM, Felipe Balbi wrote: In addition, IMO, if this was only tested on Panda (as suggested by earlier cover letters), it really should not have been merged until it got some broader testing. Shubhro's got his Tested-by tag. I believe he tested on beagleboard and omap4sdp. Shubhro, can you confirm which platforms you tested the UART patches ? cheers Felipe I had boot tested on omap3sdp and onap4 sdp and did pm testing on both with omap3 hitting off. Thanks ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCHv7 00/23]I2C big cleanup
Hi, On Tue, Sep 11, 2012 at 03:48:34PM +0530, Shubhrajyoti wrote: On Tuesday 11 September 2012 03:11 PM, Shubhrajyoti D wrote: Changes since v1: - removed tabification on patch 6/17 - removed dev_err() which was introduced on patch 09/17 Changes since v2: - do not set full fifo depth in the RDR interrupt. - some changelog updates. - rebase to the Wolfram's tree. Changes since v3: - Remove a redundant read of status register - Read the dev-buf_len variable instead of the register as the information of the remaining bytes is there. Changes since v4: - Ack the arbitration lost. - Rebase to the i2c-embedded/for-next branch. Changes since v5: - Rebase to latest mainline - Added some more cleanup patches so as have a consolidated series. Changes since v6: - Fix comments on setting the pdev to NULL. - Trivial changelog update Previous discussions can be found here http://www.spinics.net/lists/linux-i2c/msg09482.html Also this gives better performance With the patches: Performance counter stats for '/build/i2c/bin/i2cdump -y -f 1 0x48 b': 78.796376 task-clock#0.453 CPUs utilized 516 context-switches #0.007 M/sec 0 CPU-migrations#0.000 K/sec 114 page-faults #0.001 M/sec 0.174011183 seconds time elapsed Without the patches Performance counter stats for '/build/i2c/bin/i2cdump -y -f 1 0x48 b': 123.504640 task-clock#0.049 CPUs utilized 337 context-switches #0.003 M/sec 0 CPU-migrations#0.000 K/sec 144 page-faults #0.001 M/sec 2.534424040 seconds time elapsed The auto suspend is probably the one :-) Awesome, I didn't go as far as checking performance counters :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] omap: remoteproc: set bootaddr support
Hi Juan, On Wed, Aug 15, 2012 at 6:25 PM, Juan Gutierrez jgutier...@ti.com wrote: Some remote processors (like Omap4's DSP) need to explicitly set a boot address from which they start executing code when taken out of reset. Support for this has been added to remoteproc code through a set_bootaddr function in the platform data which, if needed, must be set according to the backend rproc. For omap4's dsp we can use the next control funtion: .set_bootaddr = omap_ctrl_write_dsp_boot_addr Signed-off-by: Juan Gutierrez jgutier...@ti.com Applied with slight changes to the commit log. Thanks! Ohad. -- 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 00/16] ARM: big platform data header rename
As we discussed at the ARM mini summit in San Diego, we are
going to move all platform specific header files that are used
in drivers out of the mach-* directories, at least for those
platforms that we want to have in a multiplatform kernel.
A big step in this direction is to move all the platform_data
definitions into include/linux/platform_data/. This takes
care of about a third of the header files in question and
should be relatively uncontroversial.
I changed the file names after the rename to be
include/linux/${subsystem}-${driver}.h where possible, to
have a more consistent naming there.
I would like to merge the series through the arm-soc tree
as an early branch so other branches can be based on top
or merge this branch into the other one to avoid conflicts.
Platform maintainers: please provide ACKs so I can take
it into the for-next branch as a stable sub-branch.
Driver maintainers: There should be nothing controversial
here, just a heads-up so you know that some one-line changes
are coming through the arm-soc tree that might cause an
occasional merge conflict. I've put a lot of people on
bcc in this mail so they know what the individual ones are
about. If you have specific comments, please reply on the
patches you are Cc'd on.
Arnd
Arnd Bergmann (16):
ARM: at91: move platform_data definitions
ARM: davinci: move platform_data definitions
ARM: ep93xx: move platform_data definitions
ARM: imx: move platform_data definitions
ARM: msm: move platform_data definitions
ARM: netx: move platform_data definitions
ARM: pxa: move platform_data definitions
ARM: sa1100: move platform_data definitions
ARM: tegra: move platform_data definitions
ARM: vt8500: move platform_data definitions
ARM: w90x900: move platform_data definitions
ARM: nomadik: move platform_data definitions
ARM: omap: move platform_data definitions
ARM: orion: move platform_data definitions
ARM: samsung: move platform_data definitions
ARM: spear: move platform_data definitions
Documentation/spi/ep93xx_spi |2 +-
arch/arm/mach-at91/at91sam9g45_devices.c |2 +-
arch/arm/mach-at91/at91sam9rl_devices.c|2 +-
arch/arm/mach-at91/include/mach/at_hdmac.h | 61 ---
arch/arm/mach-at91/include/mach/atmel-mci.h|2 +-
arch/arm/mach-davinci/aemif.c |2 +-
arch/arm/mach-davinci/board-da830-evm.c|8 +-
arch/arm/mach-davinci/board-da850-evm.c|6 +-
arch/arm/mach-davinci/board-dm355-evm.c|8 +-
arch/arm/mach-davinci/board-dm355-leopard.c|8 +-
arch/arm/mach-davinci/board-dm365-evm.c|8 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 10 +-
arch/arm/mach-davinci/board-dm646x-evm.c |6 +-
arch/arm/mach-davinci/board-mityomapl138.c |4 +-
arch/arm/mach-davinci/board-neuros-osd2.c |8 +-
arch/arm/mach-davinci/board-sffsdr.c |4 +-
arch/arm/mach-davinci/davinci.h|4 +-
arch/arm/mach-davinci/devices.c|4 +-
arch/arm/mach-davinci/dm355.c |4 +-
arch/arm/mach-davinci/dm365.c |6 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/aemif.h | 36
arch/arm/mach-davinci/include/mach/asp.h | 137 ---
arch/arm/mach-davinci/include/mach/da8xx.h | 10 +-
arch/arm/mach-davinci/include/mach/i2c.h | 26 ---
arch/arm/mach-davinci/include/mach/keyscan.h | 42 -
arch/arm/mach-davinci/include/mach/mmc.h | 39 -
arch/arm/mach-davinci/include/mach/nand.h | 90 --
arch/arm/mach-davinci/include/mach/spi.h | 89 --
arch/arm/mach-davinci/include/mach/tnetv107x.h |4 +-
arch/arm/mach-davinci/include/mach/usb.h | 59 ---
arch/arm/mach-davinci/usb.c|2 +-
arch/arm/mach-dove/common.c|2 +-
arch/arm/mach-ep93xx/core.c|6 +-
arch/arm/mach-ep93xx/dma.c |2 +-
arch/arm/mach-ep93xx/edb93xx.c |4 +-
arch/arm/mach-ep93xx/include/mach/dma.h| 93 ---
arch/arm/mach-ep93xx/include/mach/ep93xx_keypad.h | 35
arch/arm/mach-ep93xx/include/mach/ep93xx_spi.h | 29
arch/arm/mach-ep93xx/include/mach/fb.h | 56 ---
arch/arm/mach-ep93xx/simone.c |2 +-
arch/arm/mach-ep93xx/snappercl15.c |2 +-
arch/arm/mach-ep93xx/vision_ep9307.c |4 +-
arch/arm/mach-exynos/dev-audio.c |2 +-
arch/arm/mach-exynos/dev-ohci.c|2 +-
arch/arm/mach-exynos/include/mach/ohci.h | 21
Re: Seeking clarity on IRQCHIP_MASK_ON_SUSPEND
On Tue, 11 Sep 2012, NeilBrown wrote: On Mon, 10 Sep 2012 12:28:35 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: You might be looking for a different functionality. Can you explain what you need? I want as particular GPIO interrupt to be masked before entering suspend. I produced code to get the -suspend() callback to perform this masking. Another developer (Santosh) felt that IRQCHIP_MASK_ON_SUSPEND was the preferred way to do this and on the surface this looks like it should be correct. However it doesn't work as explained previously. I want a resolution to this difference of opinion that doesn't just sweep the issue under that carpet but provides a clear answer to this sort of issue. My current opinion is that IRQCHIP_MASK_ON_SUSPEND should be discarded. The patch which introduced it says: Rather than working around this in the affected interrupt chip implementations we can solve this elegant in the core code itself. It appears that the solution in core code, while elegant, is wrong. It happens too late to be generally usable. It is easy enough to handle this Sigh. The flag was invented with the semantics to keep the current check for any interrupt pending functionality alive and then mask it right before going down, so only the designated wakeup interrupts can wake the device. That was the result of the discussion back then and that was what the developer wanted to achieve with his driver suspend hackery. issue in the interrupt chip drivers so maybe that is the best place to handle it. And have the same keep track of wakeup interrupts code over and over in the drivers. The the very least I think we need a big comment saying the IRQCHIP_MASK_ON_SUSPEND can only be used for irqchips which can always be programmed, even when they are suspended from an runtime-PM perspective, and that those chips must handle masking in their 'suspend' callback. Sigh, no. Either we make IRQCHIP_MASK_ON_SUSPEND into an implementation which masks the interrupts early, if the existing users find this acceptable or have a separate IRQCHIP_MASK_BEFORE_SUSPEND flag. This GPIO driver at hand is probably not the last one which requires this and we really want to do stuff in the core code instead of having random implementations of the same stuff all over the place. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/16] ARM: omap: move platform_data definitions
Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Benoît Cousson b-cous...@ti.com Cc: Dmitry Torokhov dmitry.torok...@gmail.com Cc: David Woodhouse dw...@infradead.org Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Ohad Ben-Cohen o...@wizery.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Omar Ramirez Luna omar.rami...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Jarkko Nikula jarkko.nik...@bitmer.com Cc: Liam Girdwood l...@ti.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com Cc: Jean Pihet j-pi...@ti.com Cc: J Keerthy j-keer...@ti.com Cc: linux-omap@vger.kernel.org --- arch/arm/mach-omap1/board-ams-delta.c |2 +- arch/arm/mach-omap1/board-fsample.c|2 +- arch/arm/mach-omap1/board-h2.c |2 +- arch/arm/mach-omap1/board-h3.c |2 +- arch/arm/mach-omap1/board-htcherald.c |2 +- arch/arm/mach-omap1/board-innovator.c |2 +- arch/arm/mach-omap1/board-nokia770.c |4 ++-- arch/arm/mach-omap1/board-osk.c|2 +- arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c|2 +- arch/arm/mach-omap1/board-perseus2.c |2 +- arch/arm/mach-omap1/board-sx1.c|2 +- arch/arm/mach-omap1/mcbsp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |4 ++-- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |4 ++-- arch/arm/mach-omap2/board-flash.c |4 ++-- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-n8x0.c |4 ++-- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |4 ++-- arch/arm/mach-omap2/board-omap3pandora.c |4 ++-- arch/arm/mach-omap2/board-omap3stalker.c |4 ++-- arch/arm/mach-omap2/board-omap3touchbook.c |4 ++-- arch/arm/mach-omap2/board-overo.c |4 ++-- arch/arm/mach-omap2/board-rm680.c |2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++-- arch/arm/mach-omap2/board-rx51-video.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom-display.c |2 +- arch/arm/mach-omap2/common-board-devices.c |4 ++-- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/dsp.c |2 +- arch/arm/mach-omap2/gpmc-nand.c|2 +- arch/arm/mach-omap2/gpmc-onenand.c |2 +- arch/arm/mach-omap2/mcbsp.c|2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++-- arch/arm/mach-omap2/voltage.h |2 +- arch/arm/plat-omap/common.c|2 +- drivers/input/keyboard/omap-keypad.c |2 +- drivers/mtd/nand/omap2.c |2 +- drivers/mtd/onenand/omap2.c|2 +- drivers/remoteproc/omap_remoteproc.c |2 +-
[PATCH 13/16] ARM: omap: move platform_data definitions
Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Benoît Cousson b-cous...@ti.com Cc: Dmitry Torokhov dmitry.torok...@gmail.com Cc: David Woodhouse dw...@infradead.org Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Ohad Ben-Cohen o...@wizery.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Omar Ramirez Luna omar.rami...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Jarkko Nikula jarkko.nik...@bitmer.com Cc: Liam Girdwood l...@ti.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com Cc: Jean Pihet j-pi...@ti.com Cc: J Keerthy j-keer...@ti.com Cc: linux-omap@vger.kernel.org --- arch/arm/mach-omap1/board-ams-delta.c |2 +- arch/arm/mach-omap1/board-fsample.c|2 +- arch/arm/mach-omap1/board-h2.c |2 +- arch/arm/mach-omap1/board-h3.c |2 +- arch/arm/mach-omap1/board-htcherald.c |2 +- arch/arm/mach-omap1/board-innovator.c |2 +- arch/arm/mach-omap1/board-nokia770.c |4 ++-- arch/arm/mach-omap1/board-osk.c|2 +- arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c|2 +- arch/arm/mach-omap1/board-perseus2.c |2 +- arch/arm/mach-omap1/board-sx1.c|2 +- arch/arm/mach-omap1/mcbsp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |4 ++-- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |4 ++-- arch/arm/mach-omap2/board-flash.c |4 ++-- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-n8x0.c |4 ++-- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |4 ++-- arch/arm/mach-omap2/board-omap3pandora.c |4 ++-- arch/arm/mach-omap2/board-omap3stalker.c |4 ++-- arch/arm/mach-omap2/board-omap3touchbook.c |4 ++-- arch/arm/mach-omap2/board-overo.c |4 ++-- arch/arm/mach-omap2/board-rm680.c |2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++-- arch/arm/mach-omap2/board-rx51-video.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom-display.c |2 +- arch/arm/mach-omap2/common-board-devices.c |4 ++-- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/dsp.c |2 +- arch/arm/mach-omap2/gpmc-nand.c|2 +- arch/arm/mach-omap2/gpmc-onenand.c |2 +- arch/arm/mach-omap2/mcbsp.c|2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++-- arch/arm/mach-omap2/voltage.h |2 +- arch/arm/plat-omap/common.c|2 +- drivers/input/keyboard/omap-keypad.c |2 +- drivers/mtd/nand/omap2.c |2 +- drivers/mtd/onenand/omap2.c|2 +- drivers/remoteproc/omap_remoteproc.c |2 +-
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
Hi Arnd, On 09/11/2012 03:59 PM, Arnd Bergmann wrote: Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Benoît Cousson b-cous...@ti.com Cc: Dmitry Torokhov dmitry.torok...@gmail.com Cc: David Woodhouse dw...@infradead.org Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Ohad Ben-Cohen o...@wizery.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Omar Ramirez Luna omar.rami...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Jarkko Nikula jarkko.nik...@bitmer.com Cc: Liam Girdwood l...@ti.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com Cc: Jean Pihet j-pi...@ti.com Cc: J Keerthy j-keer...@ti.com Cc: linux-omap@vger.kernel.org --- arch/arm/mach-omap1/board-ams-delta.c |2 +- arch/arm/mach-omap1/board-fsample.c|2 +- arch/arm/mach-omap1/board-h2.c |2 +- arch/arm/mach-omap1/board-h3.c |2 +- arch/arm/mach-omap1/board-htcherald.c |2 +- arch/arm/mach-omap1/board-innovator.c |2 +- arch/arm/mach-omap1/board-nokia770.c |4 ++-- arch/arm/mach-omap1/board-osk.c|2 +- arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c|2 +- arch/arm/mach-omap1/board-perseus2.c |2 +- arch/arm/mach-omap1/board-sx1.c|2 +- arch/arm/mach-omap1/mcbsp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |4 ++-- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |4 ++-- arch/arm/mach-omap2/board-flash.c |4 ++-- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-n8x0.c |4 ++-- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |4 ++-- arch/arm/mach-omap2/board-omap3pandora.c |4 ++-- arch/arm/mach-omap2/board-omap3stalker.c |4 ++-- arch/arm/mach-omap2/board-omap3touchbook.c |4 ++-- arch/arm/mach-omap2/board-overo.c |4 ++-- arch/arm/mach-omap2/board-rm680.c |2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++-- arch/arm/mach-omap2/board-rx51-video.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom-display.c |2 +- arch/arm/mach-omap2/common-board-devices.c |4 ++-- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/dsp.c |2 +- arch/arm/mach-omap2/gpmc-nand.c|2 +- arch/arm/mach-omap2/gpmc-onenand.c |2 +- arch/arm/mach-omap2/mcbsp.c|2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |4 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++-- arch/arm/mach-omap2/voltage.h |2 +- arch/arm/plat-omap/common.c|2 +- drivers/input/keyboard/omap-keypad.c |2 +- drivers/mtd/nand/omap2.c |2 +-
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
Arnd, On Tue, Sep 11, 2012 at 6:32 PM, Arnd Bergmann a...@arndb.de wrote: Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann a...@arndb.de [...] 81 files changed, 87 insertions(+), 87 deletions(-) rename arch/arm/plat-omap/include/plat/mcbsp.h = include/linux/platform_data/dsp-mcbsp.h (100%) rename arch/arm/plat-omap/include/plat/dsp.h = include/linux/platform_data/dsp-omap.h (100%) rename arch/arm/plat-omap/include/plat/keypad.h = include/linux/platform_data/keypad-omap.h (100%) rename arch/arm/plat-omap/include/plat/lcd_mipid.h = include/linux/platform_data/lcd-mipid.h (100%) rename arch/arm/plat-omap/include/plat/nand.h = include/linux/platform_data/mtd-nand-omap2.h (100%) rename arch/arm/plat-omap/include/plat/onenand.h = include/linux/platform_data/mtd-onenand-omap2.h (100%) rename arch/arm/plat-omap/include/plat/remoteproc.h = include/linux/platform_data/remoteproc-omap.h (100%) rename arch/arm/plat-omap/include/plat/voltage.h = include/linux/platform_data/smartreflex-omap.h (100%) rename arch/arm/plat-omap/include/plat/mcspi.h = include/linux/platform_data/spi-omap2-mcspi.h (100%) Just curious to know how you came with some of the above header names ? plat/mcbsp --- dsp-mcbsp.h There is no connection of DSP with McBSP. omap-mcbsp.h would been a better name. plat/nand.h -- /mtd-nand-omap2.h plat/onenand.h -- /mtd-onenand-omap2.h May be omap-nand.h and omap-onenand.h plat/mcspi.h--spi-omap2-mcspi.h May be omap-spi.h 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 13/16] ARM: omap: move platform_data definitions
On Tuesday 11 September 2012, Shilimkar, Santosh wrote: Just curious to know how you came with some of the above header names ? plat/mcbsp --- dsp-mcbsp.h There is no connection of DSP with McBSP. omap-mcbsp.h would been a better name. This one was a mistake on my side, as Tony and Peter already pointed out. How about asoc-mcbsp.h or asoc-omap-mcbsp.h? plat/nand.h -- /mtd-nand-omap2.h plat/onenand.h -- /mtd-onenand-omap2.h May be omap-nand.h and omap-onenand.h plat/mcspi.h--spi-omap2-mcspi.h May be omap-spi.h As I wrote in the introductory mail, I tried to always prefix the file names with the subsystem, followed by the name of the driver, in order to standardize on just one set of rules. The drivers implementing the three headers above are: drivers/mtd/nand/omap2.c drivers/mtd/onenand/omap2.c drivers/spi/spi-omap2-mcspi.c so these all seem appropriate. 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 13/16] ARM: omap: move platform_data definitions
On Tue, Sep 11, 2012 at 7:47 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 11 September 2012, Shilimkar, Santosh wrote: Just curious to know how you came with some of the above header names ? plat/mcbsp --- dsp-mcbsp.h There is no connection of DSP with McBSP. omap-mcbsp.h would been a better name. This one was a mistake on my side, as Tony and Peter already pointed out. How about asoc-mcbsp.h or asoc-omap-mcbsp.h? After re-reading the cover-letter and your below response, 'asoc-omap-mcbsp.h' seems to be fine. plat/nand.h -- /mtd-nand-omap2.h plat/onenand.h -- /mtd-onenand-omap2.h May be omap-nand.h and omap-onenand.h plat/mcspi.h--spi-omap2-mcspi.h May be omap-spi.h As I wrote in the introductory mail, I tried to always prefix the file names with the subsystem, followed by the name of the driver, in order to standardize on just one set of rules. Just read that now. The drivers implementing the three headers above are: drivers/mtd/nand/omap2.c drivers/mtd/onenand/omap2.c drivers/spi/spi-omap2-mcspi.c so these all seem appropriate. Sorry I missed the subsystem prefix point. These names seems to be fine then. 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
[PATCH V2] arm/dts: Add omap3-beagle.dts
Add a minimal dts for original OMAP3430/3530 version of the Beagle board. This
version of the Beagle board has 256MB of DDR and features the same TWL4030
power management IC (PMIC) as the Beagle board XM.
Given that the Beagle and Beagle-XM boards use the same PMIC, move the
definition of the VSIM regulator into the TWL4030.dtsi file so that we do not
need to duplicate in the Beagle board dts file.
This has been boot tested on an OMAP3530 Beagle board and verifing that the
SD/MMC interface is working with a SD card.
This patch is generated on top of Tony Lindgren's devel-dt branch [1].
V2 changes
- Rebased upon of devel-dt
- Corrected copyright date in omap3-beagle.dts file
- Added LED support after verifing that Beagle and Beagle XM have the same LED
configuration
[1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ---
arch/arm/boot/dts/omap3-beagle.dts| 67 +
arch/arm/boot/dts/twl4030.dtsi|6 +++
arch/arm/mach-omap2/Makefile.boot |3 +-
4 files changed, 75 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index c38cf76..3705a81 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -55,12 +55,6 @@
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
- vsim: regulator-vsim {
- compatible = ti,twl4030-vsim;
- regulator-min-microvolt = 180;
- regulator-max-microvolt = 300;
- };
-
twl_audio: audio {
compatible = ti,twl4030-audio;
codec {
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
new file mode 100644
index 000..f624dc8
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - 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 version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI OMAP3 BeagleBoard;
+ compatible = ti,omap3-beagle, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ leds {
+ compatible = gpio-leds;
+ pmu_stat {
+ label = beagleboard::pmu_stat;
+ gpios = twl_gpio 19 0; /* LEDB */
+ };
+
+ heartbeat {
+ label = beagleboard::usr0;
+ gpios = gpio5 22 0; /* 150 - D6 LED */
+ linux,default-trigger = heartbeat;
+ };
+
+ mmc {
+ label = beagleboard::usr1;
+ gpios = gpio5 21 0; /* 149 - D7 LED */
+ linux,default-trigger = mmc0;
+ };
+ };
+
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ff00017..c5337d4 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,12 @@
regulator-max-microvolt = 315;
};
+ vsim: regulator-vsim {
+ compatible = ti,twl4030-vsim;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 300;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
diff --git a/arch/arm/mach-omap2/Makefile.boot
b/arch/arm/mach-omap2/Makefile.boot
index be0fe92..384005a 100644
--- a/arch/arm/mach-omap2/Makefile.boot
+++ b/arch/arm/mach-omap2/Makefile.boot
@@ -3,7 +3,8 @@ params_phys-y := 0x8100
initrd_phys-y := 0x8080
dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb
-dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle-xm.dtb omap3-evm.dtb
omap3-tobi.dtb
+dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-beagle-xm.dtb
+dtb-$(CONFIG_ARCH_OMAP3) += omap3-evm.dtb omap3-tobi.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb
dtb-$(CONFIG_ARCH_OMAP4) +=
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
On 9/11/2012 7:54 PM, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 7:47 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 11 September 2012, Shilimkar, Santosh wrote: Just curious to know how you came with some of the above header names ? plat/mcbsp --- dsp-mcbsp.h There is no connection of DSP with McBSP. omap-mcbsp.h would been a better name. This one was a mistake on my side, as Tony and Peter already pointed out. How about asoc-mcbsp.h or asoc-omap-mcbsp.h? After re-reading the cover-letter and your below response, 'asoc-omap-mcbsp.h' seems to be fine. Note that mcbsp is also applicable to Davinci family of devices. Thanks, Vaibhav plat/nand.h -- /mtd-nand-omap2.h plat/onenand.h -- /mtd-onenand-omap2.h May be omap-nand.h and omap-onenand.h plat/mcspi.h--spi-omap2-mcspi.h May be omap-spi.h As I wrote in the introductory mail, I tried to always prefix the file names with the subsystem, followed by the name of the driver, in order to standardize on just one set of rules. Just read that now. The drivers implementing the three headers above are: drivers/mtd/nand/omap2.c drivers/mtd/onenand/omap2.c drivers/spi/spi-omap2-mcspi.c so these all seem appropriate. Sorry I missed the subsystem prefix point. These names seems to be fine then. Regards Santosh ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] staging: omap-thermal: Correct checkpatch.pl warnings
From: J Keerthy j-keer...@ti.com
Removes checkpatch warnings on omap-bandgap.c.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index c556abb..9ef44ea 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -1037,20 +1037,20 @@ static int omap_bandgap_save_ctxt(struct omap_bandgap
*bg_ptr)
if (OMAP_BANDGAP_HAS(bg_ptr, MODE_CONFIG))
rval-bg_mode_ctrl = omap_bandgap_readl(bg_ptr,
-
tsr-bgap_mode_ctrl);
+ tsr-bgap_mode_ctrl);
if (OMAP_BANDGAP_HAS(bg_ptr, COUNTER))
rval-bg_counter = omap_bandgap_readl(bg_ptr,
-
tsr-bgap_counter);
+ tsr-bgap_counter);
if (OMAP_BANDGAP_HAS(bg_ptr, TALERT)) {
rval-bg_threshold = omap_bandgap_readl(bg_ptr,
-
tsr-bgap_threshold);
+ tsr-bgap_threshold);
rval-bg_ctrl = omap_bandgap_readl(bg_ptr,
- tsr-bgap_mask_ctrl);
+ tsr-bgap_mask_ctrl);
}
if (OMAP_BANDGAP_HAS(bg_ptr, TSHUT_CONFIG))
rval-tshut_threshold = omap_bandgap_readl(bg_ptr,
-
tsr-tshut_threshold);
+ tsr-tshut_threshold);
}
return 0;
@@ -1074,8 +1074,9 @@ static int omap_bandgap_restore_ctxt(struct omap_bandgap
*bg_ptr)
if (val == 0) {
if (OMAP_BANDGAP_HAS(bg_ptr, TSHUT_CONFIG))
- omap_bandgap_writel(bg_ptr,
rval-tshut_threshold,
-
tsr-tshut_threshold);
+ omap_bandgap_writel(bg_ptr,
+ rval-tshut_threshold,
+ tsr-tshut_threshold);
/* Force immediate temperature measurement and update
* of the DTEMP field
*/
--
1.7.7.1.488.ge8e1c
--
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] staging: omap-thermal: improve conf data handling and initialization
While registering the thermal zone, it is required to have the cooling
devices already setup, so that the .bind callback can succeed.
Due to that, the driver code needs to be reorganized so that we first
setup the cooling devices then the zones. This way we cope with the
right thermal framework initialization sequence.
This patch changes the order of the thermal zone initialization,
so that we create it only when the cooling devices are available.
It also adds some defensive checks for the config data, so that
the callbacks are ready for calls when the data is still not
initialized.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c|6 ++--
drivers/staging/omap-thermal/omap-thermal-common.c | 38 +---
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 9ef44ea..ff93c15 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -953,12 +953,12 @@ int __devinit omap_bandgap_probe(struct platform_device
*pdev)
for (i = 0; i bg_ptr-conf-sensor_count; i++) {
char *domain;
+ if (bg_ptr-conf-sensors[i].register_cooling)
+ bg_ptr-conf-sensors[i].register_cooling(bg_ptr, i);
+
domain = bg_ptr-conf-sensors[i].domain;
if (bg_ptr-conf-expose_sensor)
bg_ptr-conf-expose_sensor(bg_ptr, i, domain);
-
- if (bg_ptr-conf-sensors[i].register_cooling)
- bg_ptr-conf-sensors[i].register_cooling(bg_ptr, i);
}
/*
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
index d156424..46ee0a9 100644
--- a/drivers/staging/omap-thermal/omap-thermal-common.c
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -77,10 +77,16 @@ static inline int omap_thermal_get_temp(struct
thermal_zone_device *thermal,
unsigned long *temp)
{
struct omap_thermal_data *data = thermal-devdata;
- struct omap_bandgap *bg_ptr = data-bg_ptr;
- struct omap_temp_sensor *s = bg_ptr-conf-sensors[data-sensor_id];
+ struct omap_bandgap *bg_ptr;
+ struct omap_temp_sensor *s;
int ret, tmp, pcb_temp, slope, constant;
+ if (!data)
+ return 0;
+
+ bg_ptr = data-bg_ptr;
+ s = bg_ptr-conf-sensors[data-sensor_id];
+
ret = omap_bandgap_read_temperature(bg_ptr, data-sensor_id, tmp);
if (ret)
return ret;
@@ -227,21 +233,37 @@ static struct thermal_zone_device_ops omap_thermal_ops = {
.get_crit_temp = omap_thermal_get_crit_temp,
};
-int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
- char *domain)
+static struct omap_thermal_data
+*omap_thermal_build_data(struct omap_bandgap *bg_ptr, int id)
{
struct omap_thermal_data *data;
data = devm_kzalloc(bg_ptr-dev, sizeof(*data), GFP_KERNEL);
if (!data) {
dev_err(bg_ptr-dev, kzalloc fail\n);
- return -ENOMEM;
+ return NULL;
}
data-sensor_id = id;
data-bg_ptr = bg_ptr;
data-mode = THERMAL_DEVICE_ENABLED;
INIT_WORK(data-thermal_wq, omap_thermal_work);
+ return data;
+}
+
+int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain)
+{
+ struct omap_thermal_pdata pdata;
+
+ data = omap_bandgap_get_sensor_data(bg_ptr, id);
+
+ if (!data)
+ data = omap_thermal_build_pdata(bg_ptr, id);
+
+ if (!data)
+ return -EINVAL;
+
/* TODO: remove TC1 TC2 */
/* Create thermal zone */
data-omap_thermal = thermal_zone_device_register(domain,
@@ -335,6 +357,11 @@ int omap_thermal_register_cpu_cooling(struct omap_bandgap
*bg_ptr, int id)
int tab_size, ret;
data = omap_bandgap_get_sensor_data(bg_ptr, id);
+ if (!data)
+ data = omap_thermal_build_pdata(bg_ptr, id);
+
+ if (!data)
+ return -EINVAL;
ret = omap_thermal_build_cpufreq_clip(bg_ptr, tab_ptr, tab_size);
if (ret 0) {
@@ -351,6 +378,7 @@ int omap_thermal_register_cpu_cooling(struct omap_bandgap
*bg_ptr, int id)
return PTR_ERR(data-cool_dev);
}
bg_ptr-conf-sensors[id].cooling_data.freq_clip_count = tab_size;
+ omap_bandgap_set_sensor_data(bg_ptr, id, data);
return 0;
}
--
1.7.7.1.488.ge8e1c
--
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] staging: omap-thermal: fix polling period settings
While registering the omap thermal zones we need to
properly specify TC1 and TC2, as long as the proper
passive polling period and monitor period.
This patch fixes the parameters passed while registering
the thermal zone.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-thermal-common.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
index 0675a5e..d156424 100644
--- a/drivers/staging/omap-thermal/omap-thermal-common.c
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -246,7 +246,9 @@ int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr,
int id,
/* Create thermal zone */
data-omap_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, omap_thermal_ops,
- 0, FAST_TEMP_MONITORING_RATE, 0, 0);
+ 1, 2, /*TODO: remove this when FW allows */
+ FAST_TEMP_MONITORING_RATE,
+ FAST_TEMP_MONITORING_RATE);
if (IS_ERR_OR_NULL(data-omap_thermal)) {
dev_err(bg_ptr-dev, thermal zone device is NULL\n);
return PTR_ERR(data-omap_thermal);
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] staging: omap-thermal: clean-ups and fixes
Hello Greg, Here are some patches to clean the omap-thermal driver code a bit. There are 2 fixes as well related to registration to thermal fw. These patches are based on staging-next tree. They are also available here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/omap-thermal-fixes All best, Eduardo Valentin (3): staging: omap-thermal: remove checkpatch.pl warnings on data files staging: omap-thermal: fix polling period settings staging: omap-thermal: improve conf data handling and initialization J Keerthy (1): staging: omap-thermal: Correct checkpatch.pl warnings drivers/staging/omap-thermal/omap-bandgap.c| 21 drivers/staging/omap-thermal/omap-thermal-common.c | 42 +-- drivers/staging/omap-thermal/omap4-thermal.c | 54 ++-- drivers/staging/omap-thermal/omap5-thermal.c | 38 +++--- 4 files changed, 93 insertions(+), 62 deletions(-) -- 1.7.7.1.488.ge8e1c -- 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] staging: omap-thermal: remove checkpatch.pl warnings on data files
Simple checkpatch.pl clean ups.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap4-thermal.c | 54 +-
drivers/staging/omap-thermal/omap5-thermal.c | 38 +-
2 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap4-thermal.c
b/drivers/staging/omap-thermal/omap4-thermal.c
index fa9dbcd..04c02b6 100644
--- a/drivers/staging/omap-thermal/omap4-thermal.c
+++ b/drivers/staging/omap-thermal/omap4-thermal.c
@@ -77,15 +77,15 @@ const struct omap_bandgap_data omap4430_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = omap4430_mpu_temp_sensor_registers,
- .ts_data = omap4430_mpu_temp_sensor_data,
- .domain = cpu,
- .slope = 0,
- .constant = 2,
- .slope_pcb = 0,
- .constant_pcb = 2,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = omap4430_mpu_temp_sensor_registers,
+ .ts_data = omap4430_mpu_temp_sensor_data,
+ .domain = cpu,
+ .slope = 0,
+ .constant = 2,
+ .slope_pcb = 0,
+ .constant_pcb = 2,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
@@ -215,15 +215,15 @@ const struct omap_bandgap_data omap4460_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = omap4460_mpu_temp_sensor_registers,
- .ts_data = omap4460_mpu_temp_sensor_data,
- .domain = cpu,
- .slope = OMAP_GRADIENT_SLOPE_4460,
- .constant = OMAP_GRADIENT_CONST_4460,
- .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4460,
- .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4460,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = omap4460_mpu_temp_sensor_registers,
+ .ts_data = omap4460_mpu_temp_sensor_data,
+ .domain = cpu,
+ .slope = OMAP_GRADIENT_SLOPE_4460,
+ .constant = OMAP_GRADIENT_CONST_4460,
+ .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4460,
+ .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4460,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
@@ -244,15 +244,15 @@ const struct omap_bandgap_data omap4470_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = omap4460_mpu_temp_sensor_registers,
- .ts_data = omap4460_mpu_temp_sensor_data,
- .domain = cpu,
- .slope = OMAP_GRADIENT_SLOPE_4470,
- .constant = OMAP_GRADIENT_CONST_4470,
- .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4470,
- .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4470,
- .register_cooling = omap_thermal_register_cpu_cooling,
- .unregister_cooling =
omap_thermal_unregister_cpu_cooling,
+ .registers = omap4460_mpu_temp_sensor_registers,
+ .ts_data = omap4460_mpu_temp_sensor_data,
+ .domain = cpu,
+ .slope = OMAP_GRADIENT_SLOPE_4470,
+ .constant = OMAP_GRADIENT_CONST_4470,
+ .slope_pcb = OMAP_GRADIENT_SLOPE_W_PCB_4470,
+ .constant_pcb = OMAP_GRADIENT_CONST_W_PCB_4470,
+ .register_cooling = omap_thermal_register_cpu_cooling,
+ .unregister_cooling = omap_thermal_unregister_cpu_cooling,
},
},
.sensor_count = 1,
diff --git a/drivers/staging/omap-thermal/omap5-thermal.c
b/drivers/staging/omap-thermal/omap5-thermal.c
index 0658af2..2f3a498 100644
--- a/drivers/staging/omap-thermal/omap5-thermal.c
+++ b/drivers/staging/omap-thermal/omap5-thermal.c
@@ -268,29 +268,29 @@ const struct omap_bandgap_data omap5430_data = {
.remove_sensor = omap_thermal_remove_sensor,
.sensors = {
{
- .registers = omap5430_mpu_temp_sensor_registers,
- .ts_data = omap5430_mpu_temp_sensor_data,
- .domain = cpu,
-
[PATCH v10 2/5] usb: musb: kill global and static for multi instance
From: Ajay Kumar Gupta ajay.gu...@ti.com
Moved global variable musb_debugfs_root and static variable
old_state to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable orig_dma_mask and filled the
dev-dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/musb_core.c| 22 +++---
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c |8 +++-
3 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 61b64fc..bb56a0e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/idr.h
+#include linux/dma-mapping.h
#include musb_core.h
@@ -1797,10 +1798,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb-xceiv-state != old_state) {
- old_state = musb-xceiv-state;
+ if (musb-xceiv-state != musb-xceiv_old_state) {
+ musb-xceiv_old_state = musb-xceiv-state;
sysfs_notify(musb-controller-kobj, NULL, mode);
}
}
@@ -2060,11 +2060,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -2083,10 +2078,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev-dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status 0)
iounmap(base);
@@ -2096,7 +2087,8 @@ static int __devinit musb_probe(struct platform_device
*pdev)
static int __devexit musb_remove(struct platform_device *pdev)
{
- struct musb *musb = dev_to_musb(pdev-dev);
+ struct device *dev = pdev-dev;
+ struct musb *musb = dev_to_musb(dev);
void __iomem*ctrl_base = musb-ctrl_base;
/* this gets called on rmmod.
@@ -2109,9 +2101,9 @@ static int __devexit musb_remove(struct platform_device
*pdev)
musb_free(musb);
iounmap(ctrl_base);
- device_init_wakeup(pdev-dev, 0);
+ device_init_wakeup(dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev-dev.dma_mask = orig_dma_mask;
+ dma_set_mask(dev, *dev-parent-dma_mask);
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index a69ffd6..c158aac 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -437,6 +437,10 @@ struct musb {
#ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
#endif
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..1d6e8af 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s-private;
@@ -241,7 +239,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *file;
int ret;
- root = debugfs_create_dir(musb, NULL);
+ root = debugfs_create_dir(dev_name(musb-controller), NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
@@ -261,7 +259,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb-debugfs_root = root;
return 0;
@@ -274,5 +272,5 @@ err0:
void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
{
- debugfs_remove_recursive(musb_debugfs_root);
+ debugfs_remove_recursive(musb-debugfs_root);
}
--
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 v10 5/5] usb: musb: dsps: remove explicit NOP device creation
From: Ajay Kumar Gupta ajay.gu...@ti.com As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index b8aecbb..2785e28 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -376,8 +376,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb-mregs += wrp-musb_core_offset; - /* NOP driver needs change if supporting dual instance */ - usb_nop_xceiv_register(); + /* Get the NOP PHY */ musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 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
