Re: [PATCH F 10/12] OMAP2/3 clock: omap2_clk_enable(): fix logic
Hi Russell, On Sat, 31 Jan 2009, Russell King - ARM Linux wrote: On Wed, Jan 28, 2009 at 12:35:28PM -0700, Paul Walmsley wrote: Rearrange the parent clock enable status check code so it actually makes sense. No functional change. I don't think there's anything gained from introducing the additional 'parent_ret' variable. I thought it made the code slightly easier to understand; but, am not attached to it. Please let me know if you'd like me to send a version of the patch without it, - 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 F 12/12] OMAP2/3 McBSP: add temporary clockdomain fix for McBSP virtual clocks
Hi Russell, On Sat, 31 Jan 2009, Russell King - ARM Linux wrote: On Wed, Jan 28, 2009 at 12:35:33PM -0700, Paul Walmsley wrote: The McBSP driver uses virtual clocks to handle enabling and disabling its hardware clocks. These virtual clocks have no associated clockdomain. After commit 60b8b431e47d8c5b8c02a2e4fa9af388aae20790, this prevents the McBSP clocks from registering correctly. Resolve this for the short term by using virt_opp_clkdm for these clocks. These McBSP virtual clocks should be removed, but such a fix would require significant changes to the McBSP drivers that would require testing on OMAP1, 2, and 3 platforms. With either my clkdev patches or the spinlock fixing for mcbsp, this patch seems to be redundant. Indeed. It was included so the patch set would work if your tree didn't have Stanley's McBSP patch applied; I don't think it's made it up to mainline. - 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] OMAP: MMC: recover from transfer failures
Tony,
Has this patch been applied to the linux-omap tree? Does it need to go the
patchwork?
Cf. http://marc.info/?l=linux-omapm=123141577308177w=2
Regards,
Jean
On Thursday 08 January 2009 12:49:19 Jean Pihet wrote:
Thanks for the suggestion, it works great (stress tested) and is a cleaner
fix.
Here is a patch the latest linux-omap-2.6 tree. Is this OK?
Regards,
Jean
From d143f6b2e705aa4e9d2b032097fd1c82f8163262 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Thu, 8 Jan 2009 12:35:21 +0100
Subject: [PATCH] OMAP: MMC: recover from transfer failures
Timeouts during a command that has a data phase can result in the
next command issued after the command that failed not being processed,
i.e. no interrupt ever occurs to indicate the command has completed.
This failure can result in a deadlock.
This patch resets the data state machine to clear the error in
case of a command timeout.
Tested on OMAP3430 chip and intensive MMC/SD device removal while
transferring data.
Signed-off-by: Andy Lowe al...@mvista.com
Signed-off-by: Jean Pihet jpi...@mvista.com
Signed-off-by: Adrian Hunter ext-adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d5c1e9d..97150c0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -464,8 +464,15 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
}
end_cmd = 1;
}
- if (host-data)
+ if (host-data) {
mmc_dma_cleanup(host);
+ OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base,
+ SYSCTL) | SRD);
+ while (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+ ;
+ }
}
if ((status DATA_TIMEOUT) ||
(status DATA_CRC)) {
--
1.5.4.4.21.gc4a6c
On Thursday 08 January 2009 10:02:24 Adrian Hunter wrote:
Why not do the reset in mmc_omap_irq() like the other resets?
e.g.
static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
...
if ((status CMD_TIMEOUT) ||
(status CMD_CRC)) {
if (host-cmd) {
if (status CMD_TIMEOUT) {
OMAP_HSMMC_WRITE(host-base,
SYSCTL, OMAP_HSMMC_READ(host-base, SYSCTL) | SRC); while
(OMAP_HSMMC_READ(host-base, SYSCTL) SRC) ;
host-cmd-error = -ETIMEDOUT;
} else {
host-cmd-error = -EILSEQ;
}
end_cmd = 1;
}
- if (host-data)
+ if (host-data) {
mmc_dma_cleanup(host);
+ OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base,
+ SYSCTL) | SRD);
+ while (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+ ;
+ }
}
if ((status DATA_TIMEOUT) ||
(status DATA_CRC)) {
RE: [PATCH] I2C: OMAP: Include OMAP_I2C_SYSC_REG in save and restore
Hi,
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
@@ -300,14 +302,15 @@ static int omap_i2c_init(struct omap_i2c
} else if (dev-rev = OMAP_I2C_REV_ON_3430) {
u32 v;
This local variable is left unused, so you will get a compiler warning.
- v = SYSC_AUTOIDLE_MASK;
- v |= SYSC_ENAWAKEUP_MASK;
- v |= (SYSC_IDLEMODE_SMART
+ dev-syscstate = SYSC_AUTOIDLE_MASK;
+ dev-syscstate |= SYSC_ENAWAKEUP_MASK;
+ dev-syscstate |= (SYSC_IDLEMODE_SMART
__ffs(SYSC_SIDLEMODE_MASK));
- v |= (SYSC_CLOCKACTIVITY_FCLK
+ dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
__ffs(SYSC_CLOCKACTIVITY_MASK));
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
The variable v, holds the value to be written to OMAP_I2C_SYSC_REG. I
compiled the code for omap_3430sdp_defconfig, and received no compiler warning.
-Jagadeesh
--
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] I2C: OMAP: Add missing wakeup events
Hi, Is it a necesary bugfix, or should it wait for the next merge window? You can line it up for the next merge window. -Jagadeesh -- 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/1] Do a warm reboot instead of a cold reboot
This patch makes arch_reset do a warm reboot instead of a cold reboot. This is necessary because otherwise the system does not reboot reliably when disabling CLKEN in retention. Note : Unfortuately this breaks retention :( IVA2, PER and CORE don't go to retention after reboot. Peter 'p2' De Schrijver (1): Do a soft reboot instead of a cold boot arch/arm/mach-omap2/prcm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Do a warm reboot instead of a cold boot
This patch makes omap_prcm_arch_reset do a warm reboot instead of a cold boot Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com --- arch/arm/mach-omap2/prcm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index c64b668..b405e01 100644 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -135,7 +135,7 @@ void omap_prcm_arch_reset(char mode) else WARN_ON(1); - prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL); + prm_set_mod_reg_bits(OMAP_RST_GS, prcm_offs, RM_RSTCTRL); } static inline u32 __omap_prcm_read(void __iomem *base, s16 module, u16 reg) -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM][PATCH] ISP: Fix printk's error messages.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH] ISP: Fix printk's error messages.
This patch adds CRLF characters to some printk's.
Added 'ISP_ERR' at beginning of message a thats how other printks are formated
in
this module.
Reported-by: Alexey Klimov klimov.li...@gmail.com
Signed-off-by: Dominic Curran dcur...@ti.com
---
drivers/media/video/isp/isp.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: omapzoom04/drivers/media/video/isp/isp.c
===
--- omapzoom04.orig/drivers/media/video/isp/isp.c
+++ omapzoom04/drivers/media/video/isp/isp.c
@@ -1175,13 +1175,14 @@ u32 isp_buf_allocation(void)
buff_addr = (void *) vmalloc(ISP_BUFFER_MAX_SIZE);
if (!buff_addr) {
- printk(KERN_ERR Cannot allocate memory );
+ printk(KERN_ERR ISP_ERR: Cannot allocate
+ ISP_WORKAROUND memory\n);
return -ENOMEM;
}
sglist_alloc = videobuf_vmalloc_to_sg(buff_addr, ISP_BUFFER_MAX_PAGES);
if (!sglist_alloc) {
- printk(KERN_ERR videobuf_vmalloc_to_sg error);
+ printk(KERN_ERR ISP_ERR: videobuf_vmalloc_to_sg failed\n);
return -ENOMEM;
}
num_sc = dma_map_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES, 1);
@@ -1196,7 +1197,7 @@ u32 isp_buf_mmap(void)
{
buff_addr_mapped = ispmmu_map_sg(sglist_alloc, ISP_BUFFER_MAX_PAGES);
if (!buff_addr_mapped) {
- printk(KERN_ERR ispmmu_map_sg mapping failed );
+ printk(KERN_ERR ISP_ERR: ispmmu_map_sg mapping failed\n);
return -ENOMEM;
}
isppreview_set_outaddr(buff_addr_mapped);
--
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: new PM branch available
Hi Kevin, Hello, The latest PM branch is now available[1]. I've done basic testing of retention and off-mode (suspend and dynamic idle) on Beagle and custom HW. My SDP has something still keeping CORE active that others have not seen, but I have yet to debug. Any other reports from SDP testing would be appreciated. Notable changes/updates - rebased on latest clock updates and fixes from Paul - clockfw pre- and post- notifiers - DVFS for VDD2 I tried it on a beagleboard last night, but couldn't get even static retention to work. Some domains (core, per, dss) stay on, but even mpu and neon don't go to retention. They only go to inactive. So could you send your .config file ? Which rootfs are you using, I'm using debian, so maybe something keeps the CPU busy. Are you using NAND or MMC to store your rootfs ? Which beagle HW rev do you have ? I'm testing on a B5 board. And which u-boot are you using ? Thanks, Peter. -- goa is a state of mind -- 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-fixes] OMAP2/3: GPIO: remove recursion in IRQ wakeup path
Kevin Hilman khil...@deeprootsystems.com writes:
Now that the generic IRQ and GPIO frameworks are used for enabling and
disabling GPIO IRQ wakeup sources, there is no longer a need to call
[enable|disable]_irq_wake() in the low-level code. Doing so results
in recursive calls to [enable|disable]_irq_wake().
This was discovered in the suspend/resume path on OMAP3/Beagle using
the gpio-keys driver which disables/re-enables GPIO IRQ wakeups in the
suspend/resume path.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Tony,
Not sure if it's too late, but this could go into omap-fixes too.
Kevin
---
arch/arm/plat-omap/gpio.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f856a90..798a8cd 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -837,13 +837,10 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
case METHOD_MPUIO:
case METHOD_GPIO_1610:
spin_lock_irqsave(bank-lock, flags);
- if (enable) {
+ if (enable)
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
- } else {
- disable_irq_wake(bank-irq);
+ else
bank-suspend_wakeup = ~(1 gpio);
- }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
@@ -856,13 +853,10 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
return -EINVAL;
}
spin_lock_irqsave(bank-lock, flags);
- if (enable) {
+ if (enable)
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
- } else {
- disable_irq_wake(bank-irq);
+ else
bank-suspend_wakeup = ~(1 gpio);
- }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
--
1.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MMC: recover from transfer failures
Hi,
* Jean Pihet jpi...@mvista.com [090202 00:46]:
Tony,
Has this patch been applied to the linux-omap tree? Does it need to go the
patchwork?
Cf. http://marc.info/?l=linux-omapm=123141577308177w=2
I'm not applying MMC patches, we need to move that discussion to LKML
and keep Pierre involved.
Jarkko Lavinen was planning to set up a git branch against the mainline
tree for the omap mmc patches, so until we have that, let's just let the
patches float on the list for a while.
But yeah, if you want patchwork to pick up your patch so it does not
get lost, just please resend it to the linux-omap list and it should
get automatically picked up by patchwork.
Regards,
Tony
Regards,
Jean
On Thursday 08 January 2009 12:49:19 Jean Pihet wrote:
Thanks for the suggestion, it works great (stress tested) and is a cleaner
fix.
Here is a patch the latest linux-omap-2.6 tree. Is this OK?
Regards,
Jean
From d143f6b2e705aa4e9d2b032097fd1c82f8163262 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Thu, 8 Jan 2009 12:35:21 +0100
Subject: [PATCH] OMAP: MMC: recover from transfer failures
Timeouts during a command that has a data phase can result in the
next command issued after the command that failed not being processed,
i.e. no interrupt ever occurs to indicate the command has completed.
This failure can result in a deadlock.
This patch resets the data state machine to clear the error in
case of a command timeout.
Tested on OMAP3430 chip and intensive MMC/SD device removal while
transferring data.
Signed-off-by: Andy Lowe al...@mvista.com
Signed-off-by: Jean Pihet jpi...@mvista.com
Signed-off-by: Adrian Hunter ext-adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d5c1e9d..97150c0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -464,8 +464,15 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
}
end_cmd = 1;
}
- if (host-data)
+ if (host-data) {
mmc_dma_cleanup(host);
+ OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base,
+ SYSCTL) | SRD);
+ while (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+ ;
+ }
}
if ((status DATA_TIMEOUT) ||
(status DATA_CRC)) {
--
1.5.4.4.21.gc4a6c
On Thursday 08 January 2009 10:02:24 Adrian Hunter wrote:
Why not do the reset in mmc_omap_irq() like the other resets?
e.g.
static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
...
if ((status CMD_TIMEOUT) ||
(status CMD_CRC)) {
if (host-cmd) {
if (status CMD_TIMEOUT) {
OMAP_HSMMC_WRITE(host-base,
SYSCTL, OMAP_HSMMC_READ(host-base, SYSCTL) | SRC); while
(OMAP_HSMMC_READ(host-base, SYSCTL) SRC) ;
host-cmd-error = -ETIMEDOUT;
} else {
host-cmd-error = -EILSEQ;
}
end_cmd = 1;
}
- if (host-data)
+ if (host-data) {
mmc_dma_cleanup(host);
+ OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base,
+ SYSCTL) | SRD);
+ while (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+ ;
+ }
}
if ((status DATA_TIMEOUT) ||
(status DATA_CRC)) {
--
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: new PM branch available
Hi Peter, Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: Hi Kevin, Hello, The latest PM branch is now available[1]. I've done basic testing of retention and off-mode (suspend and dynamic idle) on Beagle and custom HW. My SDP has something still keeping CORE active that others have not seen, but I have yet to debug. Any other reports from SDP testing would be appreciated. Notable changes/updates - rebased on latest clock updates and fixes from Paul - clockfw pre- and post- notifiers - DVFS for VDD2 I tried it on a beagleboard last night, but couldn't get even static retention to work. Some domains (core, per, dss) stay on, but even mpu and neon don't go to retention. They only go to inactive. A first guess: this sounds like CONFIG_OMAP_RESET_CLOCKS=y is missing from your .config. The MPU/NEON going active but not RET is an indication to me that some fclk is active so that the fclk check in omap3_can_sleep() fails, so a WFI is never attempted. That's shy Personally, I'm thinking we should totally drop this fclk check. I see no reason not to attempt a WFI, even if there are active fclks. So could you send your .config file ? Attached. Which rootfs are you using, I'm using debian, so maybe something keeps the CPU busy. Are you using NAND or MMC to store your rootfs ? I'm using rootfs on MMC and have tested with busybox-only, debian and OE rootfs. With debian and OE, I usually boot a minimal rootfs, before a full userland comes up. With debian, I changed my /etc/init.d/rcS to start initlevel 1 instead of 'S'. Which beagle HW rev do you have ? I'm testing on a B5 board. I have a rev B4. And which u-boot are you using ? I'm using the u-boot from Steve Sakoman's tree[1]. That helped a lot in my initial Beagle testing, but I think the kernel should reset the IVA and D2D now which is the domains that I was having problems with before, so I think that the out of the box u-boot should work fine. Kevin [1] http://elinux.org/BeagleBoard#U-Boot # # Automatically generated make config: don't edit # Linux kernel version: 2.6.28-omap1 # Mon Feb 2 11:17:18 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_OPROFILE_ARMV7=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set
Re: new PM branch available
Kevin Hilman khil...@deeprootsystems.com writes: Hi Peter, Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: Hi Kevin, Hello, The latest PM branch is now available[1]. I've done basic testing of retention and off-mode (suspend and dynamic idle) on Beagle and custom HW. My SDP has something still keeping CORE active that others have not seen, but I have yet to debug. Any other reports from SDP testing would be appreciated. Notable changes/updates - rebased on latest clock updates and fixes from Paul - clockfw pre- and post- notifiers - DVFS for VDD2 I tried it on a beagleboard last night, but couldn't get even static retention to work. Some domains (core, per, dss) stay on, but even mpu and neon don't go to retention. They only go to inactive. A first guess: this sounds like CONFIG_OMAP_RESET_CLOCKS=y is missing from your .config. The MPU/NEON going active but not RET is an indication to me that some fclk is active so that the fclk check in omap3_can_sleep() fails, so a WFI is never attempted. That's shy Personally, I'm thinking we should totally drop this fclk check. I see no reason not to attempt a WFI, even if there are active fclks. So could you send your .config file ? Attached. Which rootfs are you using, I'm using debian, so maybe something keeps the CPU busy. Are you using NAND or MMC to store your rootfs ? I'm using rootfs on MMC and have tested with busybox-only, debian and OE rootfs. With debian and OE, I usually boot a minimal rootfs, before a full userland comes up. With debian, I changed my /etc/init.d/rcS to start initlevel 1 instead of 'S'. Which beagle HW rev do you have ? I'm testing on a B5 board. I have a rev B4. And which u-boot are you using ? I'm using the u-boot from Steve Sakoman's tree[1]. That helped a lot in my initial Beagle testing, but I think the kernel should reset the IVA and D2D now which is the domains that I was having problems with before, so I think that the out of the box u-boot should work fine. Kevin [1] http://elinux.org/BeagleBoard#U-Boot One other thing... to fix the noise about unbalanced IRQs upon GPIO resume, you also need my patch posted to l-o recently: [PATCH omap-fixes] OMAP2/3: GPIO: remove recursion in IRQ wakeup path Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dspgateway linux-omap branch
* Siarhei Siamashka siarhei.siamas...@gmail.com [090201 15:51]: Hello all, I wonder about the status of dspgateway branch. It does not compile cleanly for n770_defconfig confuguration. Applying patches 'USB: omap1 ohci buildfix (otg related)', 'drivers/usb/core/hub.c: fix CONFIG_USB_OTG=y build' and 'ARM: OMAP: Remove unused platform devices, v3' makes it compile, but the resulting kernel does not boot on Nokia 770. The same boot problem also affects 'origin/omap-fixes' branch. Git HEAD seems to compile and boot fine on Nokia 770, and dspgateway patch can be applied to it. But unfortunately 'demo_console' test application does not work (dsp task gets loaded or is at least reported to be loaded, but 'demo_console' arm side program gets stuck and does not show anything). The last kernel version which has dspgateway in more or less working on Nokia 770 seems to be 2.6.27-omap1 (aic23 and sound related stuff has problems, but can be disabled). Maybe some of the more recent kernels are fine too, but I did not find the exact point where it got broken yet. Are there any ideas how to bring dspgateway branch into a better shape? Sounds like these should get fixed if I rebase it onto something else. Any preferences onto which commit to rebase it on? Or if you or somebody is interested in maintaining a git branch for the dspgateway patches, I can just mirror it in the linux-omap tree. 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 v2 0/2] OMAP 2/3 GPIO fixes for idling debounce clocks
Kevin Hilman khil...@deeprootsystems.com writes: [updated since v1: also works for retention/off when idle by masking off GPIO clocks in the 'fclks_active' check.] This series against the current PM branch is to add support for auto-disabling GPIO debounce clocks when the system is idle. Without this, any platform using the GPIO debounce feature will not go into retention since the GPIO debounce clocks are still active. This is needed particularily on OMAP3EVM which sets up the debounce clocks for the touchscreen GPIO. Kevin Hilman (2): OMAP2/3: GPIO: generalize prepare for idle OMAP3: GPIO: disable GPIO debounce clocks on idle arch/arm/mach-omap2/pm24xx.c |4 ++-- arch/arm/mach-omap2/pm34xx.c | 14 -- arch/arm/plat-omap/gpio.c | 27 +-- arch/arm/plat-omap/include/mach/gpio.h |4 ++-- 4 files changed, 33 insertions(+), 16 deletions(-) Pushing this series to PM branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Adding and building TPS6235x based PR785 board support
On Mon, Feb 02, 2009 at 09:22:30AM +0530, Pillai, Manikandan wrote: Ditto. It's important to remember that this I2C driver is going to be used by all OMAP systems using I2C - patching in ifdefs for setting up each board isn't going to scale, they would end up obscuring the code for the I2C controller itself. [Pillai, Manikandan] I can move this to board-omap3evm.c. I shall be using static struct platform_device omap_i2c_devices[] as extern in board-omap3evm.c to register the child platform device. I'm not sure what devices you're registering as children here but note that consumers do not need to be children of the regulator in the device tree. -- 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] I2C: OMAP: Include OMAP_I2C_SYSC_REG in save and restore
Hello,
ext Pakaravoor, Jagadeesh wrote:
From: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Save and restore should include OMAP_I2C_SYSC_REG.
Signed-off-by: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
CC: Jouni Hogander jouni.hogan...@nokia.com
---
Index: linux-omap-2.6/drivers/i2c/busses/i2c-omap.c
===
--- linux-omap-2.6.orig/drivers/i2c/busses/i2c-omap.c 2009-01-22
12:11:12.0 +0530
+++ linux-omap-2.6/drivers/i2c/busses/i2c-omap.c2009-01-22
12:44:12.202367296 +0530
@@ -182,6 +182,7 @@ struct omap_i2c_dev {
u16 scllstate;
u16 sclhstate;
u16 bufstate;
+ u16 syscstate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -240,6 +241,7 @@ static void omap_i2c_unidle(struct omap_
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
}
dev-idle = 0;
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
@@ -300,14 +302,15 @@ static int omap_i2c_init(struct omap_i2c
} else if (dev-rev = OMAP_I2C_REV_ON_3430) {
u32 v;
This local variable is left unused, so you will get a compiler warning.
- v = SYSC_AUTOIDLE_MASK;
- v |= SYSC_ENAWAKEUP_MASK;
- v |= (SYSC_IDLEMODE_SMART
+ dev-syscstate = SYSC_AUTOIDLE_MASK;
+ dev-syscstate |= SYSC_ENAWAKEUP_MASK;
+ dev-syscstate |= (SYSC_IDLEMODE_SMART
__ffs(SYSC_SIDLEMODE_MASK));
- v |= (SYSC_CLOCKACTIVITY_FCLK
+ dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
__ffs(SYSC_CLOCKACTIVITY_MASK));
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
+ dev-syscstate);
/*
* Enabling all wakup sources to stop I2C freezing on
* WFI instruction.
--
With Regards,
Jagadeesh Bhaskar P
A.
--
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: [PATCHv2] ARM: OMAP: gptimer based event monitor driver for oprofile
On Thursday 29 January 2009 22:10:06 ext Kevin Hilman wrote:
Siarhei Siamashka siarhei.siamas...@nokia.com writes:
Signed-off-by: Siarhei Siamashka siarhei.siamas...@nokia.com
---
A second revision of gptimer oprofile patch
http://marc.info/?l=linux-omapm=123143937515088w=2
with the fixes suggested by Tony Lindgren
Timers from the CORE domain seem to work best on OMAP3.
Also tested the patch on Nokia 770 (OMAP1710).
Please let me know if anything else needs to be fixed.
Sorry to review this so late, but...
Don't worry about this. Any kind of feedback is very much welcome. Thanks for
your comments.
Why do you need to use a hardware timer for this? If you just need a
periodic event to fire, you should just use an hrtimer.
A bit more control about how the timer behaves is definitely not critical, but
nice to have nevertheless.
This would be a good way to make an oprofile model that is generic
and would not need any HW timer support.
Are there many other platforms which need it? For OMAP3 probably nobody would
even care about any kind generic model if PMU was working reliably.
I will try to check hrtimer and compare it to gptimer based implementation.The
most interesting thing to verify is whether there could be any noticeable
extra overhead related to the use of hrtimer framework.
Another thing to decide is what kind of configurability should be available?
Should the frequency of periodic event specified in Hz, milliseconds, ticks
of the timer, or whatever else?
Kevin
arch/arm/Kconfig |6 ++
arch/arm/oprofile/Makefile|1 +
arch/arm/oprofile/common.c|5 ++
arch/arm/oprofile/op_arm_model.h |2 +
arch/arm/oprofile/op_model_omap_gptimer.c | 93
+ 5 files changed, 107 insertions(+), 0
deletions(-)
create mode 100644 arch/arm/oprofile/op_model_omap_gptimer.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7fb201..8774136 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -160,6 +160,12 @@ config GENERIC_HARDIRQS_NO__DO_IRQ
if OPROFILE
+config OPROFILE_OMAP_GPTIMER
+ def_bool y
+ depends on ARCH_OMAP
+ select CONFIG_OMAP_32K_TIMER
+ select CONFIG_OMAP_DM_TIMER
+
config OPROFILE_ARMV6
def_bool y
depends on CPU_V6 !SMP
diff --git a/arch/arm/oprofile/Makefile b/arch/arm/oprofile/Makefile
index 88e31f5..fc2bc02 100644
--- a/arch/arm/oprofile/Makefile
+++ b/arch/arm/oprofile/Makefile
@@ -8,6 +8,7 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
oprofile-$(CONFIG_CPU_XSCALE) += op_model_xscale.o
+oprofile-$(CONFIG_OPROFILE_OMAP_GPTIMER) += op_model_omap_gptimer.o
oprofile-$(CONFIG_OPROFILE_ARM11_CORE) += op_model_arm11_core.o
oprofile-$(CONFIG_OPROFILE_ARMV6) += op_model_v6.o
oprofile-$(CONFIG_OPROFILE_MPCORE) += op_model_mpcore.o
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 3fcd752..add3cb4 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -133,6 +133,11 @@ int __init oprofile_arch_init(struct
oprofile_operations *ops)
ops-backtrace = arm_backtrace;
+/* comes first, so that it can be overrided by a better implementation
*/ +#ifdef CONFIG_OPROFILE_OMAP_GPTIMER
+ spec = op_omap_gptimer_spec;
+#endif
+
#ifdef CONFIG_CPU_XSCALE
spec = op_xscale_spec;
#endif
diff --git a/arch/arm/oprofile/op_arm_model.h
b/arch/arm/oprofile/op_arm_model.h index 8c4e4f6..db936da 100644
--- a/arch/arm/oprofile/op_arm_model.h
+++ b/arch/arm/oprofile/op_arm_model.h
@@ -24,6 +24,8 @@ struct op_arm_model_spec {
extern struct op_arm_model_spec op_xscale_spec;
#endif
+extern struct op_arm_model_spec op_omap_gptimer_spec;
+
extern struct op_arm_model_spec op_armv6_spec;
extern struct op_arm_model_spec op_mpcore_spec;
extern struct op_arm_model_spec op_armv7_spec;
diff --git a/arch/arm/oprofile/op_model_omap_gptimer.c
b/arch/arm/oprofile/op_model_omap_gptimer.c new file mode 100644
index 000..98f7d2b
--- /dev/null
+++ b/arch/arm/oprofile/op_model_omap_gptimer.c
@@ -0,0 +1,93 @@
+/**
+ * OMAP gptimer based event monitor driver for oprofile
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Siarhei Siamashka siarhei.siamas...@nokia.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.
+ *
+ */
+
+#include linux/types.h
+#include linux/oprofile.h
+#include linux/interrupt.h
+#include linux/irq.h
+
+#include mach/dmtimer.h
+
+#include op_counter.h
+#include op_arm_model.h
+
+static struct omap_dm_timer *gptimer;
+
+static int gptimer_init(void)
+{
Remaining bits for basic support of LDP
Tony, Thye LDP platform network interface still doesn't seem to work. There seems to be several reasons for this: 1. wrong resource size in arch/arm/mach-omap2/board-ldp.c 2. missing OMAPx4xx configuration from drivers/net/smc911x.h 3. missing SMC9211 chip IDs from drivers/net/smc911x.c The patch to fix these issues would seem to be relatively small (12 lines in the smc911x and one line change in board-ldp.c) - is it something we want done for -rc4 or do we scrap the ethernet support on the LDP until the SMSC driver has been merged ? Obviously, having working ethernet would be helpful, and since it was half heartedly merged when the initial OMAP3 stuff went upstream we should do something with it one way or another. -- 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: Remaining bits for basic support of LDP
From: Russell King - ARM Linux li...@arm.linux.org.uk Date: Mon, 2 Feb 2009 21:39:53 + The patch to fix these issues would seem to be relatively small (12 lines in the smc911x and one line change in board-ldp.c) - is it something we want done for -rc4 or do we scrap the ethernet support on the LDP until the SMSC driver has been merged ? Obviously, having working ethernet would be helpful, and since it was half heartedly merged when the initial OMAP3 stuff went upstream we should do something with it one way or another. Well, the SMSC driver is there already in the tree. The only thing not currently being scheduled to hit 2.6.29-rcX are the recent changes to support platform specified interrupt flags and all of that stuff. If you want, we can look into pushing that work into 2.6.29-rcX -- 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: Remaining bits for basic support of LDP
On Mon, Feb 2, 2009 at 1:45 PM, David Miller da...@davemloft.net wrote: From: Russell King - ARM Linux li...@arm.linux.org.uk Date: Mon, 2 Feb 2009 21:39:53 + The patch to fix these issues would seem to be relatively small (12 lines in the smc911x and one line change in board-ldp.c) - is it something we want done for -rc4 or do we scrap the ethernet support on the LDP until the SMSC driver has been merged ? Obviously, having working ethernet would be helpful, and since it was half heartedly merged when the initial OMAP3 stuff went upstream we should do something with it one way or another. Well, the SMSC driver is there already in the tree. The only thing not currently being scheduled to hit 2.6.29-rcX are the recent changes to support platform specified interrupt flags and all of that stuff. If you want, we can look into pushing that work into 2.6.29-rcX That would be great! The patch I recently submitted for Overo's SMSC support really does need the platform specified interrupt flag patch to function properly. So accelerating those patches into 2.6.29-rcX gets my vote :-) Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remaining bits for basic support of LDP
On Mon, Feb 02, 2009 at 01:45:30PM -0800, David Miller wrote: From: Russell King - ARM Linux li...@arm.linux.org.uk Date: Mon, 2 Feb 2009 21:39:53 + The patch to fix these issues would seem to be relatively small (12 lines in the smc911x and one line change in board-ldp.c) - is it something we want done for -rc4 or do we scrap the ethernet support on the LDP until the SMSC driver has been merged ? Obviously, having working ethernet would be helpful, and since it was half heartedly merged when the initial OMAP3 stuff went upstream we should do something with it one way or another. Well, the SMSC driver is there already in the tree. The only thing not currently being scheduled to hit 2.6.29-rcX are the recent changes to support platform specified interrupt flags and all of that stuff. If you want, we can look into pushing that work into 2.6.29-rcX Hmm. Since we should assume that the other smc911x using platforms work as-is, merging Steve's first four and the LDP patch seems to be a sane idea. We can queue the remainder for when bugs are reported or the next merge window, whichever comes earlier. -- 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] I2C: OMAP: Include OMAP_I2C_SYSC_REG in save and restore
Ben, is this necessary for inclusion as a bugfix, or can it wait for a merge window? This patch applies to Linux Omap tree only. It is a bug fix, and preferably taken ASAP. I'd like to incorporate your review comments, if you have any. -Jagadeesh -- 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: BUG: LDP - smc911x region too small
Here should be 0x100. Fixing this won't cause problems with smsc911x patches. Yes it will - if it gets fixed in the -rc series for the smc911x driver your patches will conflict. There's more which needs fixing though - no platform data is being passed so the smc911x driver still fails to initialise. Data sheet shows addressable range as 0x50 from base -- 0xFC. So 0xFF should be good. I tried to send Russell data sheet but his emails is rejecting it. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Add and build TPS6235x based PR785 board support
Change in this patch include
comments fix from David Brownell and Mark
TPS6235x chip based PR785 power modules are from Texas Instruments
for OMAP3 EVM boards. This patch supports the PR785 card
and provides the driver support for the TPS devices.
For compilation, the LCD and MMC drivers are modified and will not
work. Further patches will be provided for support of LCD and MMC
with PR785 boards.
Signed-off-by: Manikandan Pillai mani.pil...@ti.com
---
arch/arm/mach-omap2/Kconfig| 11 +++
arch/arm/mach-omap2/board-omap3evm.c | 139
arch/arm/mach-omap2/mmc-twl4030.c |4 +-
arch/arm/plat-omap/i2c.c |4 +-
drivers/regulator/tps6235x-regulator.c |8 +-
drivers/video/omap/lcd_omap3evm.c |6 ++
6 files changed, 166 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0a86a88..91890be 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -121,6 +121,17 @@ config MACH_OMAP3EVM
bool OMAP 3530 EVM board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+menu PR785 Power board selection for OMAP3 EVM
+config OMAP3EVM_PR785
+ bool Power board for OMAP3 EVM
+ depends on I2C=y ARCH_OMAP34XX
+ help
+ Say yes here if you are using the TPS6235x based PR785 Power Module
+ for the EVM boards. This core driver provides register access and IRQ
+ handling facilities, and registers devices for the various functions
+ so that function-specific drivers can bind to them.
+endmenu
+
config MACH_OMAP3_BEAGLE
bool OMAP3 BEAGLE board
depends on ARCH_OMAP3 ARCH_OMAP34XX
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index e4e60e2..4eac042 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -36,11 +36,20 @@
#include mach/usb-ehci.h
#include mach/common.h
#include mach/mcspi.h
+#include mach/mux.h
#include sdram-micron-mt46h32m32lf-6.h
#include twl4030-generic-scripts.h
#include mmc-twl4030.h
+#include linux/regulator/machine.h
+#if defined(CONFIG_OMAP3EVM_PR785) defined(CONFIG_TWL4030_CORE)
+#error config err : only one of OMAP3EVM_PR785 or TWL4030_CORE can be defined
+#endif
+
+struct platform_device *vdd2_platform_device;
+struct platform_device *vdd1_platform_device;
+extern struct platform_device omap_i2c_devices[];
static struct resource omap3evm_smc911x_resources[] = {
[0] = {
@@ -89,6 +98,7 @@ static struct omap_uart_config omap3_evm_uart_config
__initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
+#if defined(CONFIG_TWL4030_CORE)
static struct twl4030_gpio_platform_data omap3evm_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
@@ -150,11 +160,66 @@ static struct i2c_board_info __initdata
omap3evm_i2c_boardinfo[] = {
.platform_data = omap3evm_twldata,
},
};
+#endif
+
+#if defined(CONFIG_OMAP3EVM_PR785)
+/* CORE voltage regulator */
+struct regulator_consumer_supply tps62352_core_consumers = {
+ .supply = vdd2,
+};
+
+/* MPU voltage regulator */
+struct regulator_consumer_supply tps62352_mpu_consumers = {
+ .supply = vdd1,
+};
+
+struct regulator_init_data vdd2_tps_regulator_data = {
+ .constraints = {
+ .min_uV = 75,
+ .max_uV = 1537000,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps62352_core_consumers,
+};
+
+struct regulator_init_data vdd1_tps_regulator_data = {
+ .constraints = {
+ .min_uV = 75,
+ .max_uV = 1537000,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps62352_mpu_consumers,
+};
+
+static struct i2c_board_info __initdata tps_6235x_i2c_board_info[] = {
+ {
+ I2C_BOARD_INFO(tps62352, 0x4A),
+ .flags = I2C_CLIENT_WAKE,
+ .platform_data = vdd2_tps_regulator_data,
+ },
+ {
+ I2C_BOARD_INFO(tps62353, 0x48),
+ .flags = I2C_CLIENT_WAKE,
+ .platform_data = vdd1_tps_regulator_data,
+ },
+};
+#endif
static int __init omap3_evm_i2c_init(void)
{
+#if defined(CONFIG_OMAP3EVM_PR785)
+ omap_register_i2c_bus(1, 2600, tps_6235x_i2c_board_info,
+ ARRAY_SIZE(tps_6235x_i2c_board_info));
+
+#endif
+#if defined(CONFIG_TWL4030_CORE)
omap_register_i2c_bus(1, 2600, omap3evm_i2c_boardinfo,
[PATCH 1/2] Add support for TPS6235x support
The patch has been fixed for comments given by David Brownell
and Mark Brown for adding TPS6235x support on OMAP3 EVM.
Comments fixed include
moving Makefile changes to this patch
dev_err used
removed the extra configuration option from Kconfig
Signed-off-by: Manikandan Pillai mani.pil...@ti.com
---
drivers/regulator/Kconfig |8 +
drivers/regulator/Makefile |1 +
drivers/regulator/tps6235x-regulator.c | 350
3 files changed, 359 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/tps6235x-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 0765389..c61024f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -80,4 +80,12 @@ config REGULATOR_DA903X
Say y here to support the BUCKs and LDOs regulators found on
Dialog Semiconductor DA9030/DA9034 PMIC.
+config REGULATOR_TPS6235X
+tristate TI TPS6235x Power regulators
+ depends on I2C
+ help
+ This driver supports TPS6235x voltage regulator chips, for values
+ of x from 0 to 6. These are buck converters which support TI's
+ hardware based SmartReflex dynamic voltage scaling.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 0dacb18..fdc5f5b 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_REGULATOR_TWL4030) += twl4030-regulator.o
obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
+obj-$(CONFIG_REGULATOR_TPS6235X)+= tps6235x-regulator.o
ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/tps6235x-regulator.c
b/drivers/regulator/tps6235x-regulator.c
new file mode 100644
index 000..f10fae6
--- /dev/null
+++ b/drivers/regulator/tps6235x-regulator.c
@@ -0,0 +1,350 @@
+/*
+ * tps6235x-regulator.c -- support regulators in tps6235x family chips
+ *
+ * Author : Manikandan Pillaimani.pil...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/i2c.h
+#include linux/delay.h
+
+/*
+ * These chips are often used in OMAP-based systems.
+ *
+ * This driver implements software-based resource control for various
+ * voltage regulators. This is usually augmented with state machine
+ * based control.
+ *
+ * For now, all regulator operations apply to VSEL1 (the ceiling),
+ * instead of VSEL0 (the floor) which is used for low power modes.
+ * Also, this *assumes* only software mode control is used...
+*/
+
+#defineTPS6235X_REG_VSEL0 0
+#defineTPS6235X_REG_VSEL1 1
+#defineTPS6235X_REG_CTRL1 2
+#defineTPS6235X_REG_CTRL2 3
+
+/* VSEL bitfields (EN_DCDC is shared) */
+#defineTPS6235X_EN_DCDCBIT(7)
+#defineTPS6235X_LIGHTPFM BIT(6)
+#defineTPS6235X_VSM_MSK(0x3F)
+
+/* CTRL1 bitfields */
+#define TPS6235X_EN_SYNC BIT(5)
+#define TPS6235X_HW_nSWBIT(4)
+
+/* CTRL2 bitfields */
+#define TPS6235X_PWR_OK_MSKBIT(5)
+#define TPS6235X_OUT_DIS_MSK BIT(6)
+#define TPS6235X_GO_MSKBIT(7)
+
+struct tps_info {
+ unsignedmin_uV;
+ unsignedmax_uV;
+ unsignedmult_uV;
+ boolfixed;
+};
+
+struct tps {
+ struct regulator_desc desc;
+ struct i2c_client *client;
+ struct regulator_dev*rdev;
+ const struct tps_info *info;
+};
+
+static inline int tps_6235x_read_reg(struct tps *tps, u8 reg, u8 *val)
+{
+ int status;
+
+ status = i2c_smbus_read_byte_data(tps-client, reg);
+ *val = status;
+ if (status 0)
+ return status;
+ return 0;
+}
+
+static inline int tps_6235x_write_reg(struct tps *tps, u8 reg, u8 val)
+{
+ return i2c_smbus_write_byte_data(tps-client, reg, val);
+}
+
+static int tps6235x_dcdc_is_enabled(struct regulator_dev *dev)
+{
+ struct tps *tps = rdev_get_drvdata(dev);
+
+ ret = tps_6235x_read_reg(tps, TPS6235X_REG_VSEL1, vsel1);
+ /* REVISIT we need to be able to report errors here ... */
+
+ return !!(vsel1 TPS6235X_EN_DCDC);
+}
+
+static int tps6235x_dcdc_enable(struct regulator_dev *dev)
+{
+ unsigned char vsel1;
+ int ret;
+ struct tps *tps = rdev_get_drvdata(dev);
+
+ ret = tps_6235x_read_reg(tps, TPS6235X_REG_VSEL1, vsel1);
+
+ if (ret == 0) {
+ vsel1 |=
Re: [PATCH] I2C: OMAP: Add missing wakeup events
On Mon, Feb 02, 2009 at 12:47:05PM +0530, Pakaravoor, Jagadeesh wrote: Ben, Did you get a chance to look at this patch? Is it a necesary bugfix, or should it wait for the next merge window? -Original Message- From: linux-i2c-ow...@vger.kernel.org [mailto:linux-i2c-ow...@vger.kernel.org] On Behalf Of Pakaravoor, Jagadeesh Sent: Friday, January 23, 2009 2:19 PM To: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org; Ben Dooks Subject: [PATCH] I2C: OMAP: Add missing wakeup events From: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com Include wake up events for receiver overflow and transmitter underflow in OMAP_I2C_WE_REG configuration. Also fix a small typo. Signed-off-by: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com --- Index: kernel_org/drivers/i2c/busses/i2c-omap.c === --- kernel_org.orig/drivers/i2c/busses/i2c-omap.c 2009-01-23 12:46:58.0 +0530 +++ kernel_org/drivers/i2c/busses/i2c-omap.c 2009-01-23 14:15:52.187150630 +0530 @@ -92,8 +92,10 @@ #define OMAP_I2C_STAT_AL (1 0)/* Arbitration lost int ena */ /* I2C WE wakeup enable register */ -#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakup */ +#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakeup */ #define OMAP_I2C_WE_RDR_WE (1 13) /* RX drain wakeup */ +#define OMAP_I2C_WE_ROVR_WE (1 11) /* RX overflow wakeup */ +#define OMAP_I2C_WE_XUDF_WE (1 10) /* TX underflow wakeup */ #define OMAP_I2C_WE_AAS_WE (1 9)/* Address as slave wakeup*/ #define OMAP_I2C_WE_BF_WE(1 8)/* Bus free wakeup */ #define OMAP_I2C_WE_STC_WE (1 6)/* Start condition wakeup */ @@ -104,6 +106,7 @@ #define OMAP_I2C_WE_AL_WE(1 0)/* Arbitration lost wakeup */ #define OMAP_I2C_WE_ALL (OMAP_I2C_WE_XDR_WE | OMAP_I2C_WE_RDR_WE | \ + OMAP_I2C_WE_ROVR_WE | OMAP_I2C_WE_XUDF_WE | \ OMAP_I2C_WE_AAS_WE | OMAP_I2C_WE_BF_WE | \ OMAP_I2C_WE_STC_WE | OMAP_I2C_WE_GC_WE | \ OMAP_I2C_WE_DRDY_WE | OMAP_I2C_WE_ARDY_WE | \ -- With Regards, Jagadeesh Bhaskar P Some men see things as they are and say why - I dream things that never were and say why not. - George Bernard Shaw -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add and build TPS6235x based PR785 board support
On Mon, Feb 02, 2009 at 03:22:05PM +0530, Manikandan Pillai wrote:
+int omap_i2c_register_child(struct platform_device *pdev_parent,
+ const char *name, struct platform_device **pdev)
+{
+ (*pdev)-dev.parent = pdev_parent-dev;
+ if (!strcmp(name, vdd2_consumer))
+ (*pdev)-dev.platform_data = vdd2_tps_regulator_data;
+ else if (!strcmp(name, vdd1_consumer))
+ (*pdev)-dev.platform_data = vdd1_tps_regulator_data;
With a name like that this function shouldn't have this sort of device
specific stuff in it. I'm really not clear what you're trying to do
here so it's difficult to comment in any detail.
+ /* Initialize the regulator consumer platform devices here */
+ pdev = omap_i2c_devices[0];
+ omap_i2c_register_child(pdev, vdd2_consumer, \
+ vdd2_platform_device);
+ omap_i2c_register_child(pdev, vdd1_consumer, \
+ vdd1_platform_device);
+ tps62352_core_consumers.dev = vdd2_platform_device-dev;
+ tps62352_mpu_consumers.dev = vdd1_platform_device-dev;
The concerns previously raised by myself and David still appear to exist
here: you shouldn't be adding platform devices as children of the I2C
controller like this and the vdd1_consumer and vdd2_consumer names
look very suspicious - I'd be surprised to see someone adding a device
driver with either name.
Given the large number of interations this has been through I feel it
would be better if you were to remove configuration of the consumers
from this patch and then add it in later along with the code for the
consumer devices. I expect that review of the drivers for the consumer
devices is likely to also address the issues here.
#define OMAP_I2C_SIZE0x3f
#define OMAP1_I2C_BASE 0xfffb3800
@@ -69,7 +71,7 @@ static struct resource i2c_resources[][2] = {
}
static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
-static struct platform_device omap_i2c_devices[] = {
+struct platform_device omap_i2c_devices[] = {
I2C_DEV_BUILDER(1, i2c_resources[0], i2c_rate[0]),
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
I2C_DEV_BUILDER(2, i2c_resources[1], i2c_rate[1]),
You should not need to do this.
diff --git a/drivers/regulator/tps6235x-regulator.c
b/drivers/regulator/tps6235x-regulator.c
index f10fae6..36e6fcf 100644
--- a/drivers/regulator/tps6235x-regulator.c
+++ b/drivers/regulator/tps6235x-regulator.c
@@ -82,12 +82,12 @@ static inline int tps_6235x_write_reg(struct tps *tps, u8
reg, u8 val)
As previously mentioned you should merge this in with the regulator
patch if it is required. Either this patch is broken or the regulator
driver is quite clearly broken without this patch.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] Add and build TPS6235x based PR785 board support
Hi Mark,
I can remove all the consumer related portion in the patch.
The consumer patch will be sent as different patch like the
Other consumer drivers.
Regards
Mani
-Original Message-
From: Mark Brown [mailto:broo...@sirena.org.uk]
Sent: Monday, February 02, 2009 5:30 PM
To: Pillai, Manikandan
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] Add and build TPS6235x based PR785 board support
On Mon, Feb 02, 2009 at 03:22:05PM +0530, Manikandan Pillai wrote:
+int omap_i2c_register_child(struct platform_device *pdev_parent,
+ const char *name, struct platform_device **pdev)
+{
+ (*pdev)-dev.parent = pdev_parent-dev;
+ if (!strcmp(name, vdd2_consumer))
+ (*pdev)-dev.platform_data = vdd2_tps_regulator_data;
+ else if (!strcmp(name, vdd1_consumer))
+ (*pdev)-dev.platform_data = vdd1_tps_regulator_data;
With a name like that this function shouldn't have this sort of device
specific stuff in it. I'm really not clear what you're trying to do
here so it's difficult to comment in any detail.
+ /* Initialize the regulator consumer platform devices here */
+ pdev = omap_i2c_devices[0];
+ omap_i2c_register_child(pdev, vdd2_consumer, \
+ vdd2_platform_device);
+ omap_i2c_register_child(pdev, vdd1_consumer, \
+ vdd1_platform_device);
+ tps62352_core_consumers.dev = vdd2_platform_device-dev;
+ tps62352_mpu_consumers.dev = vdd1_platform_device-dev;
The concerns previously raised by myself and David still appear to exist
here: you shouldn't be adding platform devices as children of the I2C
controller like this and the vdd1_consumer and vdd2_consumer names
look very suspicious - I'd be surprised to see someone adding a device
driver with either name.
Given the large number of interations this has been through I feel it
would be better if you were to remove configuration of the consumers
from this patch and then add it in later along with the code for the
consumer devices. I expect that review of the drivers for the consumer
devices is likely to also address the issues here.
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE 0xfffb3800
@@ -69,7 +71,7 @@ static struct resource i2c_resources[][2] = {
}
static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
-static struct platform_device omap_i2c_devices[] = {
+struct platform_device omap_i2c_devices[] = {
I2C_DEV_BUILDER(1, i2c_resources[0], i2c_rate[0]),
#ifdefined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
I2C_DEV_BUILDER(2, i2c_resources[1], i2c_rate[1]),
You should not need to do this.
diff --git a/drivers/regulator/tps6235x-regulator.c
b/drivers/regulator/tps6235x-regulator.c
index f10fae6..36e6fcf 100644
--- a/drivers/regulator/tps6235x-regulator.c
+++ b/drivers/regulator/tps6235x-regulator.c
@@ -82,12 +82,12 @@ static inline int tps_6235x_write_reg(struct tps *tps,
u8 reg, u8 val)
As previously mentioned you should merge this in with the regulator
patch if it is required. Either this patch is broken or the regulator
driver is quite clearly broken without this patch.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Add support for TPS6235x support
The patch has been fixed for comments given by David Brownell
and Mark Brown for adding TPS6235x support on OMAP3 EVM.
Comments fixed include
moving Makefile changes to this patch
dev_err used
removed the extra configuration option from Kconfig
Signed-off-by: Manikandan Pillai mani.pil...@ti.com
---
drivers/regulator/Kconfig |8 +
drivers/regulator/Makefile |1 +
drivers/regulator/tps6235x-regulator.c | 350
3 files changed, 359 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/tps6235x-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 0765389..c61024f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -80,4 +80,12 @@ config REGULATOR_DA903X
Say y here to support the BUCKs and LDOs regulators found on
Dialog Semiconductor DA9030/DA9034 PMIC.
+config REGULATOR_TPS6235X
+tristate TI TPS6235x Power regulators
+ depends on I2C
+ help
+ This driver supports TPS6235x voltage regulator chips, for values
+ of x from 0 to 6. These are buck converters which support TI's
+ hardware based SmartReflex dynamic voltage scaling.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 0dacb18..fdc5f5b 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_REGULATOR_TWL4030) += twl4030-regulator.o
obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
+obj-$(CONFIG_REGULATOR_TPS6235X)+= tps6235x-regulator.o
ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/tps6235x-regulator.c
b/drivers/regulator/tps6235x-regulator.c
new file mode 100644
index 000..f10fae6
--- /dev/null
+++ b/drivers/regulator/tps6235x-regulator.c
@@ -0,0 +1,350 @@
+/*
+ * tps6235x-regulator.c -- support regulators in tps6235x family chips
+ *
+ * Author : Manikandan Pillaimani.pil...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/i2c.h
+#include linux/delay.h
+
+/*
+ * These chips are often used in OMAP-based systems.
+ *
+ * This driver implements software-based resource control for various
+ * voltage regulators. This is usually augmented with state machine
+ * based control.
+ *
+ * For now, all regulator operations apply to VSEL1 (the ceiling),
+ * instead of VSEL0 (the floor) which is used for low power modes.
+ * Also, this *assumes* only software mode control is used...
+*/
+
+#defineTPS6235X_REG_VSEL0 0
+#defineTPS6235X_REG_VSEL1 1
+#defineTPS6235X_REG_CTRL1 2
+#defineTPS6235X_REG_CTRL2 3
+
+/* VSEL bitfields (EN_DCDC is shared) */
+#defineTPS6235X_EN_DCDCBIT(7)
+#defineTPS6235X_LIGHTPFM BIT(6)
+#defineTPS6235X_VSM_MSK(0x3F)
+
+/* CTRL1 bitfields */
+#define TPS6235X_EN_SYNC BIT(5)
+#define TPS6235X_HW_nSWBIT(4)
+
+/* CTRL2 bitfields */
+#define TPS6235X_PWR_OK_MSKBIT(5)
+#define TPS6235X_OUT_DIS_MSK BIT(6)
+#define TPS6235X_GO_MSKBIT(7)
+
+struct tps_info {
+ unsignedmin_uV;
+ unsignedmax_uV;
+ unsignedmult_uV;
+ boolfixed;
+};
+
+struct tps {
+ struct regulator_desc desc;
+ struct i2c_client *client;
+ struct regulator_dev*rdev;
+ const struct tps_info *info;
+};
+
+static inline int tps_6235x_read_reg(struct tps *tps, u8 reg, u8 *val)
+{
+ int status;
+
+ status = i2c_smbus_read_byte_data(tps-client, reg);
+ *val = status;
+ if (status 0)
+ return status;
+ return 0;
+}
+
+static inline int tps_6235x_write_reg(struct tps *tps, u8 reg, u8 val)
+{
+ return i2c_smbus_write_byte_data(tps-client, reg, val);
+}
+
+static int tps6235x_dcdc_is_enabled(struct regulator_dev *dev)
+{
+ struct tps *tps = rdev_get_drvdata(dev);
+
+ ret = tps_6235x_read_reg(tps, TPS6235X_REG_VSEL1, vsel1);
+ /* REVISIT we need to be able to report errors here ... */
+
+ return !!(vsel1 TPS6235X_EN_DCDC);
+}
+
+static int tps6235x_dcdc_enable(struct regulator_dev *dev)
+{
+ unsigned char vsel1;
+ int ret;
+ struct tps *tps = rdev_get_drvdata(dev);
+
+ ret = tps_6235x_read_reg(tps, TPS6235X_REG_VSEL1, vsel1);
+
+ if (ret == 0) {
+ vsel1 |=
[PATCH 2/2] Add and build TPS6235x based PR785 board support
Change in this patch include
comments fix from David Brownell and Mark
Removed all the child registration functions for I2C controller
TPS6235x chip based PR785 power modules are from Texas Instruments
for OMAP3 EVM boards. This patch supports the PR785 card
and provides the driver support for the TPS devices.
For compilation, the LCD and MMC drivers are modified and will not
work. Further patches will be provided for support of LCD and MMC
with PR785 boards.
Signed-off-by: Manikandan Pillai mani.pil...@ti.com
---
arch/arm/mach-omap2/Kconfig| 11
arch/arm/mach-omap2/board-omap3evm.c | 84
arch/arm/mach-omap2/mmc-twl4030.c |4 +-
arch/arm/plat-omap/i2c.c |4 +-
drivers/regulator/tps6235x-regulator.c |8 ++--
drivers/video/omap/lcd_omap3evm.c |6 ++
6 files changed, 111 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0a86a88..91890be 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -121,6 +121,17 @@ config MACH_OMAP3EVM
bool OMAP 3530 EVM board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+menu PR785 Power board selection for OMAP3 EVM
+config OMAP3EVM_PR785
+ bool Power board for OMAP3 EVM
+ depends on I2C=y ARCH_OMAP34XX
+ help
+ Say yes here if you are using the TPS6235x based PR785 Power Module
+ for the EVM boards. This core driver provides register access and IRQ
+ handling facilities, and registers devices for the various functions
+ so that function-specific drivers can bind to them.
+endmenu
+
config MACH_OMAP3_BEAGLE
bool OMAP3 BEAGLE board
depends on ARCH_OMAP3 ARCH_OMAP34XX
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index e4e60e2..4d8e836 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -36,11 +36,16 @@
#include mach/usb-ehci.h
#include mach/common.h
#include mach/mcspi.h
+#include mach/mux.h
#include sdram-micron-mt46h32m32lf-6.h
#include twl4030-generic-scripts.h
#include mmc-twl4030.h
+#include linux/regulator/machine.h
+#if defined(CONFIG_OMAP3EVM_PR785) defined(CONFIG_TWL4030_CORE)
+#error config err : only one of OMAP3EVM_PR785 or TWL4030_CORE can be defined
+#endif
static struct resource omap3evm_smc911x_resources[] = {
[0] = {
@@ -89,6 +94,7 @@ static struct omap_uart_config omap3_evm_uart_config
__initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
+#if defined(CONFIG_TWL4030_CORE)
static struct twl4030_gpio_platform_data omap3evm_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
@@ -150,11 +156,66 @@ static struct i2c_board_info __initdata
omap3evm_i2c_boardinfo[] = {
.platform_data = omap3evm_twldata,
},
};
+#endif
+
+#if defined(CONFIG_OMAP3EVM_PR785)
+/* CORE voltage regulator */
+struct regulator_consumer_supply tps62352_core_consumers = {
+ .supply = vdd2,
+};
+
+/* MPU voltage regulator */
+struct regulator_consumer_supply tps62352_mpu_consumers = {
+ .supply = vdd1,
+};
+
+struct regulator_init_data vdd2_tps_regulator_data = {
+ .constraints = {
+ .min_uV = 75,
+ .max_uV = 1537000,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps62352_core_consumers,
+};
+
+struct regulator_init_data vdd1_tps_regulator_data = {
+ .constraints = {
+ .min_uV = 75,
+ .max_uV = 1537000,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps62352_mpu_consumers,
+};
+
+static struct i2c_board_info __initdata tps_6235x_i2c_board_info[] = {
+ {
+ I2C_BOARD_INFO(tps62352, 0x4A),
+ .flags = I2C_CLIENT_WAKE,
+ .platform_data = vdd2_tps_regulator_data,
+ },
+ {
+ I2C_BOARD_INFO(tps62353, 0x48),
+ .flags = I2C_CLIENT_WAKE,
+ .platform_data = vdd1_tps_regulator_data,
+ },
+};
+#endif
static int __init omap3_evm_i2c_init(void)
{
+#if defined(CONFIG_OMAP3EVM_PR785)
+ omap_register_i2c_bus(1, 2600, tps_6235x_i2c_board_info,
+ ARRAY_SIZE(tps_6235x_i2c_board_info));
+
+#endif
+#if defined(CONFIG_TWL4030_CORE)
omap_register_i2c_bus(1, 2600, omap3evm_i2c_boardinfo,
ARRAY_SIZE(omap3evm_i2c_boardinfo));
+#endif
omap_register_i2c_bus(2, 400, NULL, 0);
Re: Omap3430 does not resume after suspend
On Fri, Jan 30, 2009 at 7:32 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shreyas Mahajan Sent: Friday, January 30, 2009 2:54 PM To: linux-omap@vger.kernel.org Subject: Omap3430 does not resume after suspend Hello, I am a newbie with omap3430. As a part of my project, I suspended my board with 'echo mem /sys/power/state'.The suspend happens correctly, without giving any failure message. But, when I tried it to resume, it is not resuming.I tried to find some reasons for this, and got the patches for unmasking keyboard interrupt while suspending. But, all patches are for omap2 and omap1 board architecture. [sp] Are you following updates in Kevin Hilman's pm branch? With lastest updates you shouldn't see this problem on a minimal config. Would be good to start from here and add drivers selectively. Are there any patches to do this thing in omap3430? [sp] omap2 applies to OMAP3430 as well. Thanks, -- 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 Thanks for reply. I went through the Kevin Hilman's PM branch and found the same problem posted by you (@Sanjeev), 'Hangs on a echo mem /sys/power/state Goes into suspend, but cannot recover' So, can you please tell me if this problem is solved? -- 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
