RE: [PATCH] musb: cleanup the nop registration for OMAP3EVM
On Friday 03 July 2009, Ajay Kumar Gupta wrote:
OMAP3EVM uses ISP1504 phy which doesn't require any
programming and thus has to use NOP otg transceiver.
Cleanups being done:
- Remove unwanted code in usb-musb.c file
- Register nop in OMAP3EVM board file using
usb_nop_xceiv_register().
- Select NOP_USB_XCEIV for OMAP3EVM boards.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
... another for-2.6.31 bugfix.
Greg,
Here is the refreshed version of this patch.
Thanks,
Ajay
cut here =
OMAP3EVM uses ISP1504 phy which doesn't require any programming and
thus has to use NOP otg transceiver.
Cleanups being done:
- Remove unwanted code in usb-musb.c file
- Register NOP in OMAP3EVM board file using
usb_nop_xceiv_register().
- Select NOP_USB_XCEIV for OMAP3EVM boards.
- Don't enable TWL4030_USB in omap3_evm_defconfig
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Eino-Ville Talvala talv...@stanford.edu
---
Resubmitting with below changes.
- Refreshed against linus tree
- Combining recent patch from Eino-Ville Talvala on
Removing TWL4030_USB from omap3_evm_defconfig
- Register nop under #ifdef to avoid compilation warning when
USB itself it not selected in OMAP3EVM build.
arch/arm/configs/omap3_evm_defconfig |2 +-
arch/arm/mach-omap2/board-omap3evm.c |5 +
arch/arm/mach-omap2/usb-musb.c | 21 -
drivers/usb/musb/Kconfig |1 +
4 files changed, 7 insertions(+), 22 deletions(-)
diff --git a/arch/arm/configs/omap3_evm_defconfig
b/arch/arm/configs/omap3_evm_defconfig
index 28be17f..d5ff477 100644
--- a/arch/arm/configs/omap3_evm_defconfig
+++ b/arch/arm/configs/omap3_evm_defconfig
@@ -1107,7 +1107,7 @@ CONFIG_USB_ZERO=m
CONFIG_USB_OTG_UTILS=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_ISP1301_OMAP is not set
-CONFIG_TWL4030_USB=y
+# CONFIG_TWL4030_USB is not set
# CONFIG_NOP_USB_XCEIV is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index d3cc145..cf3dd77 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -25,6 +25,7 @@
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl4030.h
+#include linux/usb/otg.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -307,6 +308,10 @@ static void __init omap3_evm_init(void)
ARRAY_SIZE(omap3evm_spi_board_info));
omap_serial_init();
+#ifdef CONFIG_NOP_USB_XCEIV
+ /* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
+ usb_nop_xceiv_register();
+#endif
usb_musb_init();
ads7846_dev_init();
}
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index d85296d..739e59e 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -155,20 +155,6 @@ static struct platform_device musb_device = {
.resource = musb_resources,
};
-#ifdef CONFIG_NOP_USB_XCEIV
-static u64 nop_xceiv_dmamask = DMA_BIT_MASK(32);
-
-static struct platform_device nop_xceiv_device = {
- .name = nop_usb_xceiv,
- .id = -1,
- .dev = {
- .dma_mask = nop_xceiv_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = NULL,
- },
-};
-#endif
-
void __init usb_musb_init(void)
{
if (cpu_is_omap243x())
@@ -183,13 +169,6 @@ void __init usb_musb_init(void)
*/
musb_plat.clock = ick;
-#ifdef CONFIG_NOP_USB_XCEIV
- if (platform_device_register(nop_xceiv_device) 0) {
- printk(KERN_ERR Unable to register NOP-XCEIV device\n);
- return;
- }
-#endif
-
if (platform_device_register(musb_device) 0) {
printk(KERN_ERR Unable to register HS-USB (MUSB) device\n);
return;
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 70073b1..803adcb 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -12,6 +12,7 @@ config USB_MUSB_HDRC
depends on !SUPERH
select NOP_USB_XCEIV if ARCH_DAVINCI
select TWL4030_USB if MACH_OMAP_3430SDP
+ select NOP_USB_XCEIV if MACH_OMAP3EVM
select USB_OTG_UTILS
tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
help
--
1.6.2.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 2/2] DSPBRIDGE: introduce VMA checking for cache operation
From: Doyu Hiroshi (Nokia-D/Helsinki) hiroshi.d...@nokia.com
Subject: [PATCH 2/2] DSPBRIDGE: introduce VMA checking for cache operation
Date: Wed, 22 Jul 2009 10:22:50 +0200
Check if the given area blongs to process virtul memory address space.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
drivers/dsp/bridge/rmgr/proc.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 3a2879f..fe9dabf 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -735,6 +735,30 @@ DSP_STATUS PROC_EnumNodes(DSP_HPROCESSOR hProcessor, OUT
DSP_HNODE *aNodeTab,
return status;
}
+/* Check if the given area blongs to process virtul memory address space */
+static int memory_check_vma(unsigned long start, u32 len)
+{
+ int err = 0;
+ unsigned long end;
+ struct vm_area_struct *vma;
+
+ len = PAGE_ALIGN(len);
+ end = start + len;
+ if (end = start)
+ return -EINVAL;
+
+ down_read(current-mm-mmap_sem);
+
+ vma = find_vma(current-mm, start);
+ if (!vma || start vma-vm_start) {
end should be checkd if it's lower than vm_end as below.
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index fe9dabf..f567329 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -742,6 +742,7 @@ static int memory_check_vma(unsigned long start, u32 len)
unsigned long end;
struct vm_area_struct *vma;
+ start = PAGE_MASK;
len = PAGE_ALIGN(len);
end = start + len;
if (end = start)
@@ -750,8 +751,9 @@ static int memory_check_vma(unsigned long start, u32 len)
down_read(current-mm-mmap_sem);
vma = find_vma(current-mm, start);
- if (!vma || start vma-vm_start) {
- pr_err(%s: no vma for %08lx %08lx\n, __func__, start, end);
+ if (!vma || start vma-vm_start || end vma-vm_end) {
+ pr_err(%s: no vma for %08lx-%08lx (%08lx-%08lx)\n, __func__,
+ start, end, vma-vm_start, vma-vm_end);
err = -EINVAL;
}
The update one is attached.
0001-DSPBRIDGE-introduce-VMA-checking-for-cache-operatio.patch
Description: Binary data
Re: [PATCH V2 0/32] mmc and omap_hsmmc patches
On Tue, Jul 28, 2009 at 01:38:34PM +0300, Adrian Hunter wrote: Hi Here is version 2 of our 32 patches for mmc and omap_hsmmc. They include Matt Fleming's change for card caps, and 2 other fixes: - use a spin lock rather than enable / diable irq - make disable delay specified in milliseconds not jiffies because the value is an int, and jiffies are unsigned long (also millisecs are better anyway) Thanks for doing this Adrian. I appreciate it. My Reviewed-by tag still applies. -- 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
N810: external mmc died?
I was working on moving Debian's root from internal mmc (because it still doesn't work with linux-omap) to external mmc, running standard Maemo and connected by USB to the MMC cards (with the cards mounted), when suddenly the N810 reset. I have no idea why, but now external MMC does not work. I have been using this card for a while and have not had any problems with it; it surely can also be considered still nearly 'new'. I reflashed Maemo with the latest RX-44_DIABLO_5.2008.43-7_PR_COMBINED_MR0_ARM (and checked md5sum) and now I get the following from dmesg with either an open or close of the external MMC slot. [ 2292.843750] menelaus 1-0072: Setting voltage 'VMMC' to 3100 mV (reg 0x0a, val 0xf8) [ 2292.953125] menelaus 1-0072: Setting voltage 'VMMC' to 3000 mV (reg 0x0a, val 0xb8) [ 2295.320312] menelaus 1-0072: Shutting off 'VMMC' No device ever shows up in /dev, only mmcblk0 (the internal MMC). When I connect by USB to the MMC cards, I see in the logs on my Debian system: kernel: scsi 43:0:0:0: Direct-Access NokiaN810 031 PQ: 0 ANSI: 2 kernel: scsi 43:0:0:1: Direct-Access NokiaN810 031 PQ: 0 ANSI: 2 kernel: sd 43:0:0:0: [sdb] 3932160 512-byte hardware sectors: (2.01 GB/1.87 GiB) kernel: sd 43:0:0:0: [sdb] Write Protect is off kernel: sd 43:0:0:0: [sdb] Mode Sense: 0f 00 00 00 kernel: sd 43:0:0:0: [sdb] Assuming drive cache: write through kernel: sd 43:0:0:0: [sdb] 3932160 512-byte hardware sectors: (2.01 GB/1.87 GiB) kernel: sd 43:0:0:0: [sdb] Write Protect is off kernel: sd 43:0:0:0: [sdb] Mode Sense: 0f 00 00 00 kernel: sd 43:0:0:0: [sdb] Assuming drive cache: write through kernel: sdb: sdb1 kernel: sd 43:0:0:0: [sdb] Attached SCSI removable disk kernel: sd 43:0:0:0: Attached scsi generic sg1 type 0 kernel: sd 43:0:0:1: [sdc] Attached SCSI removable disk kernel: sd 43:0:0:1: Attached scsi generic sg2 type 0 No information about the external MMC. Thanks for any hints. signature.asc Description: Digital signature
Re: N810: external mmc died?
I'll try again, the message was botched up somehow with ^M everywhere... I was working on moving Debian's root from internal mmc (because it still doesn't work with linux-omap) to external mmc, running standard Maemo and connected by USB to the MMC cards (with the cards mounted), when suddenly the N810 reset. I have no idea why, but now external MMC does not work. I have been using this card for a while and have not had any problems with it; it surely can also be considered still nearly 'new'. I reflashed Maemo with the latest RX-44_DIABLO_5.2008.43-7_PR_COMBINED_MR0_ARM (and checked md5sum) and now I get the following from dmesg with either an open or close of the external MMC slot. [ 2292.843750] menelaus 1-0072: Setting voltage 'VMMC' to 3100 mV (reg 0x0a, val 0xf8) [ 2292.953125] menelaus 1-0072: Setting voltage 'VMMC' to 3000 mV (reg 0x0a, val 0xb8) [ 2295.320312] menelaus 1-0072: Shutting off 'VMMC' No device ever shows up in /dev, only mmcblk0 (the internal MMC). When I connect by USB to the MMC cards, I see in the logs on my Debian system: kernel: scsi 43:0:0:0: Direct-Access NokiaN810 031 PQ: 0 ANSI: 2 kernel: scsi 43:0:0:1: Direct-Access NokiaN810 031 PQ: 0 ANSI: 2 kernel: sd 43:0:0:0: [sdb] 3932160 512-byte hardware sectors: (2.01 GB/1.87 GiB) kernel: sd 43:0:0:0: [sdb] Write Protect is off kernel: sd 43:0:0:0: [sdb] Mode Sense: 0f 00 00 00 kernel: sd 43:0:0:0: [sdb] Assuming drive cache: write through kernel: sd 43:0:0:0: [sdb] 3932160 512-byte hardware sectors: (2.01 GB/1.87 GiB) kernel: sd 43:0:0:0: [sdb] Write Protect is off kernel: sd 43:0:0:0: [sdb] Mode Sense: 0f 00 00 00 kernel: sd 43:0:0:0: [sdb] Assuming drive cache: write through kernel: sdb: sdb1 kernel: sd 43:0:0:0: [sdb] Attached SCSI removable disk kernel: sd 43:0:0:0: Attached scsi generic sg1 type 0 kernel: sd 43:0:0:1: [sdc] Attached SCSI removable disk kernel: sd 43:0:0:1: Attached scsi generic sg2 type 0 No information about the external MMC. Thanks for any hints. signature.asc Description: Digital signature
Recommended buildroot config for OMAP3 boards?
Hi, I was wondering if anyone of you have a recommended config for building a buildroot filesystem for running it on any omap3 based board (3430SDP, or zoom2 preferred) I'm interested in getting always the latest version of the tools. (I've working so far with an old busybox filesystem that someone else generated for me, but now I'm interested in learning myself) Regards, Sergio -- 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: Recommended buildroot config for OMAP3 boards?
Hi,
Why don't you shift to OpenEmbedded. It has all the required recipes
for 3430, EVM, Beagleboard, etc.
Here is a technote to help you get started in case you are interested.
Best regards,
Elvis
Technote Overo-024: How to setup a development environment for the
Overo platform using a Fedora-10 VMware image
Overview
This document describes how to setup a development environment for the
Overo platform using a Fedora-10 VMware image.
Procedure
Step 01.00: Install Fedora 10 into a VMware image.
Ensure that you install the following packages
- development-libraries
- development-tools
Create a new user group called ‘developers’.
Change the primary group for all developers to the ‘developers’ group,
e.g. for user ‘elvis’, change the primary group to ‘developers’.
Step 02.00: Enable root login.
Step 02.01: Login as a regular user
$ su
# vi /etc/pam.d/gdm
Click ‘A’ and remove user!=root from the following line
auth required pam_succeed_if.so user!=root quiet
Click Esc and then type the following command :wq
Step 02.03: Modify /etc/sysctl.conf to make vm.mmap_min_addr = 0.
# vi /etc/sysctl.conf
Add the following line to the sysctl.conf file
vm.mmap_min_addr = 0
Step 02.03: Relogin as root
Step 03.00: Install the vmware tools
$ su
# cd Downloads/vmware-tools-distrib
# ./vmware-install.pl
Step 04.00: Install Sun JDK 1.6
$ su
# cd Downloads/jdk-6u12-linux-i586
# ./jdk-6u12-linux-i586-rpm.bin
Step 05.00: Install Psyco JIT compiler
Step 05.01: Download Psyco JIT compiler sources from svn
$ svn co http://codespeak.net/svn/psyco/dist/ psyco-dist
Step 05.02: Run the python installation script as a super user
$ su python setup.py install
Step 06.00: Download, build and install kermit
$ cd /tool
$ mkdir kermit
$ cd kermit
$ wget ftp://kermit.columbia.edu/kermit/archives/cku211.tar.gz
$ tar zxvf cku211.tar.gz
$ make linux
$ su
# make install
Set the permissions for /dev/ttyUSB0, so that a developer can access
the Overo USB console.
$ su
# chgrp developers /dev/ttyUSB0
Step 07.00: Setup the Overo build environment
Step 07.01: Check out the OpenEmbedded build system.
$ cd /tool
$ mkdir overo-oe
$ cd overo-oe
$ git clone git://gitorious.org/gumstix-oe/mainline.git
org.openembedded.dev
$ cd org.openembedded.dev
$ git checkout --track -b overo origin/overo
Step 07.02: Install BitBake.
$ cd /tool/overo-oe
$ svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake
Step 07.03: Creating the OE configuration files and profile.
We now will create a profile script and the configuration files
required to tailor OE to our needs.
To make this a somewhat easier task, there is a template for the
required files in the openembedded installation we just did.
Copy these files to your overo-oe directory:
$ cp -r org.openembedded.dev/contrib/gumstix/build .
If you have followed the example installation and placed the build
system in overo-oe in your home directory, you are now ready to
proceed to the next step. If you have installed the build system in a
different location you will need to edit overo-oe/build/profile and
change the definition of OVEROTOP as appropriate.
Step 07.04: Setup source code caching.
As part of the build process OpenEmbedded downloads source code
tarballs for the linux kernel, compiler, and other software packages.
By default this source code cache will be placed in overo-oe/sources.
If you would like this cache to be located elsewhere, now is the time
to edit build/conf/site.conf and set DL_DIR as appropriate.
For example, if you would like to cache the sources in /usr/share/
sources, perform the following steps:
Add new group for cache management and add operating user to this group.
$ sudo groupadd oe
$ sudo usermod -a -G oe {your_username}
Next make source code storing directory and set owner and permission
appropriately.
$ sudo mkdir /usr/share/sources
$ sudo chgrp oe /usr/share/sources
$ sudo chmod 0775 /usr/share/sources
$ sudo chmod ug+s /usr/share/sources
Edit the buid/conf/site.conf and set DL_DIR to /usr/share/sources as
follows:
DL_DIR = /usr/share/sources
Step 07.05: Modify your .bashrc file.
# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# User specific aliases and functions
#
# Environment setup for java
#
export JAVA_HOME=/usr/java/jdk1.6.0_12
export PATH=${JAVA_HOME}/bin:$PATH
#
# end java setup
#
#
# Environment setup for oe
#
export BB_ENV_EXTRAWHITE=MACHINE DISTRO ANGSTROM_MODE OVEROTOP
OEBRANCH USERBRANCH
export OVEROTOP=/tool/overo-oe
export OEBRANCH=${OVEROTOP}/org.openembedded.dev
export USERBRANCH=${OVEROTOP}/user.collection
export CROSSCOMPILER=armv7a
export PATH=${OVEROTOP}/bitbake/bin:${OVEROTOP}/tmp/cross/$
{CROSSCOMPILER}/bin:$PATH
export BBPATH=${OVEROTOP}/build:${USERBRANCH}:${OEBRANCH}
umask 0002
#
# end oe setup
#
#
# Environment setup for android
#
export REPOTOP=/tool/repo
export
Re: N810: external mmc died?
green wrote at 2009-07-29 13:12 -0600: I was working on moving Debian's root from internal mmc (because it still doesn't work with linux-omap) to external mmc, running standard Maemo and connected by USB to the MMC cards (with the cards mounted), when suddenly the N810 reset. I have no idea why, but now external MMC does not work. I went back to commit 401b285465488f515290e0f9111872b94e1cf922 where both internal and external MMC worked, and now I get this error message while booting: mmc0: error -110 whilst initialising SD card I have never seen that message before. It seems that some hardware has broken. Has this thing decided to start eating MMC cards now? Can a MMC card not handle a reset while mounted (it probably was not being written to)? If it helps, the card is labeled with Patriot Memory MiniSDHC Class 6 8GB. Thanks. signature.asc Description: Digital signature
[PATCH] ARM: Overo: Fix smsc911x platform device resource value
From 7a35b843689937256399ece6ef807d43b6e9296a Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 29 Jul 2009 16:30:46 -0500
Subject: [PATCH] ARM: Overo: Fix smsc911x platform device resource value
Fixes a wrong setting of resource parameter list in
SMSC911x platform driver data structure for Overo case.
This fixes folowing warning when compiling for Overo board:
warning: initialization from incompatible pointer type
Introduced since commit id:
commit 172ef275444efa12d834fb9d1b1acdac92db47f7
Author: Steve Sakoman sako...@gmail.com
Date: Mon Feb 2 06:27:49 2009 +
ARM: Add SMSC911X support to Overo platform (V2)
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-overo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 501d020..7e54713 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -146,7 +146,7 @@ static struct platform_device overo_smsc911x_device = {
.name = smsc911x,
.id = -1,
.num_resources = ARRAY_SIZE(overo_smsc911x_resources),
- .resource = overo_smsc911x_resources,
+ .resource = overo_smsc911x_resources,
.dev= {
.platform_data = overo_smsc911x_config,
},
--
1.6.3.2
From 7a35b843689937256399ece6ef807d43b6e9296a Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 29 Jul 2009 16:30:46 -0500
Subject: [PATCH] ARM: Overo: Fix smsc911x platform device resource value
Fixes a wrong setting of resource parameter list in
SMSC911x platform driver data structure for Overo case.
This fixes folowing warning when compiling for Overo board:
warning: initialization from incompatible pointer type
Introduced since commit id:
commit 172ef275444efa12d834fb9d1b1acdac92db47f7
Author: Steve Sakoman sako...@gmail.com
Date: Mon Feb 2 06:27:49 2009 +
ARM: Add SMSC911X support to Overo platform (V2)
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-overo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 501d020..7e54713 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -146,7 +146,7 @@ static struct platform_device overo_smsc911x_device = {
.name = smsc911x,
.id = -1,
.num_resources = ARRAY_SIZE(overo_smsc911x_resources),
- .resource = overo_smsc911x_resources,
+ .resource = overo_smsc911x_resources,
.dev = {
.platform_data = overo_smsc911x_config,
},
--
1.6.3.2
Re: [PATCH] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
On Tue, Jul 21, 2009 at 04:09:03PM -0700, Kevin Hilman wrote:
From: Rajendra Nayak rna...@ti.com
Because of OMAP off-mode, powerdomain can go off when I2C is idle.
Save enough state, and do a re-init for each transfer.
Additional save/restore state added by Jagadeesh Bhaskar Pakaravoor
(SYSC_REG) and Aaro Koskinen (wakeup sources.)
Also, The OMAP3430 TRM states:
During active mode (I2Ci.I2C_CON[15] I2C_EN bit is set to 1), make no
changes to the I2Ci.I2C_SCLL and I2Ci.I2C_SCLH registers. Changes may
result in unpredictable behavior.
Hence, the I2C_EN bit should be clearer when modifying these
registers. Please note that clearing the entire I2C_CON register to
disable the I2C module is safe, because the I2C_CON register is
re-configured for each transfer.
should this be applied as a bugfix, or kept for next merge window?
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Hu Tao ta...@motorola.com
Cc: Xiaolong Chen a21...@motorola.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
This patch has been tested extensively as part of the OMAP 'PM branch'
drivers/i2c/busses/i2c-omap.c | 64 ++--
1 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ad8d201..bb8ae50 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -178,6 +178,12 @@ struct omap_i2c_dev {
unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
+ u16 pscstate;
+ u16 scllstate;
+ u16 sclhstate;
+ u16 bufstate;
+ u16 syscstate;
+ u16 westate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -230,9 +236,18 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
clk_enable(dev-iclk);
clk_enable(dev-fclk);
+ if (cpu_is_omap34xx()) {
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ 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);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
dev-idle = 0;
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
@@ -258,7 +273,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -287,24 +302,22 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
SYSC_AUTOIDLE_MASK);
} else if (dev-rev = OMAP_I2C_REV_ON_3430) {
- u32 v;
-
- 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.
* REVISIT: Some wkup sources might not be needed.
*/
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- OMAP_I2C_WE_ALL);
-
+ dev-westate = OMAP_I2C_WE_ALL;
+
Re: [PATCH 0/3] [OMAP:I2C] Small bug fixes and errata 1.153
On Tue, Jul 21, 2009 at 10:13:20AM -0500, Sonasath, Moiz wrote: This patch includes the following: - Bug in reading the RXSTAT/TXSTAT values from I2C_BUFFSTAT - In case of a NACK|ARDY|AL interrupts return from the ISR - OMAP3430 silicon errata 1.153 hi, in future it would be better to prefix the patch subjects with i2c-omap (IE, the driver name). Signed-off-by: Moiz Sonasathm-sonas...@ti.com ^ space to go in here. Signed-off-by: Vikram panditavikram.pand...@ti.com Moiz Sonasath (3): [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values from the I2C_BUFFSTAT register [OMAP:I2C]In case of a NACK|ARDY|AL return from the ISR [OMAP:I2C]OMAP3430 Silicon Errata 1.153 drivers/i2c/busses/i2c-omap.c | 42 +--- 1 files changed, 34 insertions(+), 8 deletions(-) -- 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: [RESUBMIT][PATCH-v2][RFC] OMAP4: I2C Support for OMAP4430
On Fri, Jul 24, 2009 at 04:40:02PM +0530, Syed Rafiuddin wrote: Hi Ben, This patch adds OMAP4 support to the I2C driver. All I2C register addresses are different between OMAP1/2/3 and OMAP4. In order to not have #ifdef's at various places in code, as well as to support multi-OMAP build, Array's are created to hold the register addresses. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com --- No comment received on this patch, Is there anything that I need to resolve? Else can this patch get merged. sorry, been busy, will look at this in the next few days. Regards, Syed Rafiuddin -- 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 1/3] [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values from the I2C_BUFFSTAT register
On Tue, Jul 21, 2009 at 10:14:06AM -0500, Sonasath, Moiz wrote:
Fix bug in reading the I2C_BUFFSTAT register for getting byte count on RX/TX
interrupt.
On Interrupt: I2C_STAT[RDR],
read 'RXSTAT' from I2C_BUFFSTAT[8-13]
On Interrupt: I2C_STAT[XDR]
read 'TXSTAT' from I2C_BUFFSTAT[0-5]
Signed-off-by: Jagadeesh Pakaravoorj-pakarav...@ti.com
Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Vikram panditavikram.pand...@ti.com
IIRC, email addresses should have a space between the real name
and the address part. I've fixed this when applying as well as
changing all subjects to start i2c-omap:
---
drivers/i2c/busses/i2c-omap.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ad8d201..d280acf 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -692,9 +692,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (dev-fifo_size) {
if (stat OMAP_I2C_STAT_RRDY)
num_bytes = dev-fifo_size;
- else
- num_bytes = omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG);
+ else/* read RXSTAT on RDR interrupt */
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG)
+ 8) 0x3F;
}
while (num_bytes) {
num_bytes--;
@@ -731,9 +732,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (dev-fifo_size) {
if (stat OMAP_I2C_STAT_XRDY)
num_bytes = dev-fifo_size;
- else
- num_bytes = omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG);
+ else/* read TXSTAT on XDR interrupt */
+ num_bytes = omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG)
+ 0x3F;
}
while (num_bytes) {
num_bytes--;
--
1.5.6.3
--
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 V2 4/32] mmc: add ability to save power by powering off cards
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Adrian Hunter
Sent: Tuesday, July 28, 2009 5:39 AM
To: Andrew Morton
Cc: Jarkko Lavinen; Adrian Hunter; linux-omap Mailing List; Pierre Ossman;
Denis Karpov; Matt Fleming; lkml
Subject: [PATCH V2 4/32] mmc: add ability to save power by powering off
cards
From e6355578d082d94707c8fda1e1342c478019b5c8 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Mon, 11 May 2009 12:20:57 +0300
Subject: [PATCH] mmc: add ability to save power by powering off cards
Power can be saved by powering off cards that are not
in use. This is similar to suspend / resume except
it is under the control of the driver, and does not
require any power management support. It can only
be used when the driver can monitor whether the card
is removed, otherwise it is unsafe. This is possible
because, unlike suspend, the driver still receives
card detect and / or cover switch interrupts.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
drivers/mmc/core/core.c | 34 ++
drivers/mmc/core/core.h |2 ++
drivers/mmc/core/mmc.c | 11 +++
drivers/mmc/core/sd.c| 11 +++
include/linux/mmc/host.h |3 +++
5 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index bab5015..39f7bd1 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1145,6 +1145,40 @@ void mmc_stop_host(struct mmc_host *host)
mmc_power_off(host);
}
+void mmc_power_save_host(struct mmc_host *host)
+{
+ mmc_bus_get(host);
+
+ if (!host-bus_ops || host-bus_dead || !host-bus_ops-
power_restore) {
+ mmc_bus_put(host);
+ return;
+ }
+
+ if (host-bus_ops-power_save)
+ host-bus_ops-power_save(host);
+
+ mmc_bus_put(host);
+
+ mmc_power_off(host);
+}
+EXPORT_SYMBOL(mmc_power_save_host);
+
+void mmc_power_restore_host(struct mmc_host *host)
+{
+ mmc_bus_get(host);
+
+ if (!host-bus_ops || host-bus_dead || !host-bus_ops-
power_restore) {
+ mmc_bus_put(host);
+ return;
+ }
+
+ mmc_power_up(host);
+ host-bus_ops-power_restore(host);
+
+ mmc_bus_put(host);
+}
+EXPORT_SYMBOL(mmc_power_restore_host);
+
Who calls these exported functions mmc_power_save_host and
mmc_power_restore_host?
#ifdef CONFIG_PM
/**
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index c819eff..f7eb4c4 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -20,6 +20,8 @@ struct mmc_bus_ops {
void (*detect)(struct mmc_host *);
void (*suspend)(struct mmc_host *);
void (*resume)(struct mmc_host *);
+ void (*power_save)(struct mmc_host *);
+ void (*power_restore)(struct mmc_host *);
};
void mmc_attach_bus(struct mmc_host *host, const struct mmc_bus_ops
*ops);
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 3e35075..01f7226 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -549,6 +549,14 @@ static void mmc_resume(struct mmc_host *host)
}
+static void mmc_power_restore(struct mmc_host *host)
+{
+ host-card-state = ~MMC_STATE_HIGHSPEED;
+ mmc_claim_host(host);
+ mmc_init_card(host, host-ocr, host-card);
+ mmc_release_host(host);
+}
+
#ifdef CONFIG_MMC_UNSAFE_RESUME
static const struct mmc_bus_ops mmc_ops = {
@@ -556,6 +564,7 @@ static const struct mmc_bus_ops mmc_ops = {
.detect = mmc_detect,
.suspend = mmc_suspend,
.resume = mmc_resume,
+ .power_restore = mmc_power_restore,
};
static void mmc_attach_bus_ops(struct mmc_host *host)
@@ -570,6 +579,7 @@ static const struct mmc_bus_ops mmc_ops = {
.detect = mmc_detect,
.suspend = NULL,
.resume = NULL,
+ .power_restore = mmc_power_restore,
};
static const struct mmc_bus_ops mmc_ops_unsafe = {
@@ -577,6 +587,7 @@ static const struct mmc_bus_ops mmc_ops_unsafe = {
.detect = mmc_detect,
.suspend = mmc_suspend,
.resume = mmc_resume,
+ .power_restore = mmc_power_restore,
};
static void mmc_attach_bus_ops(struct mmc_host *host)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 80cccd2..debe26e 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -603,6 +603,14 @@ static void mmc_sd_resume(struct mmc_host *host)
}
+static void mmc_sd_power_restore(struct mmc_host *host)
+{
+ host-card-state = ~MMC_STATE_HIGHSPEED;
+ mmc_claim_host(host);
+ mmc_sd_init_card(host, host-ocr, host-card);
+ mmc_release_host(host);
+}
+
#ifdef CONFIG_MMC_UNSAFE_RESUME
static const struct mmc_bus_ops mmc_sd_ops = {
@@ -610,6 +618,7 @@ static const struct mmc_bus_ops mmc_sd_ops = {
.detect =
RE: [PATCH V2 13/32] omap_hsmmc: context save/restore support
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Adrian Hunter
Sent: Tuesday, July 28, 2009 5:40 AM
To: Andrew Morton
Cc: Jarkko Lavinen; Adrian Hunter; linux-omap Mailing List; Pierre Ossman;
Denis Karpov; Matt Fleming; lkml
Subject: [PATCH V2 13/32] omap_hsmmc: context save/restore support
From 43e9fa346d7e386328876a8535dc8619bd1f47ae Mon Sep 17 00:00:00 2001
From: Denis Karpov ext-denis.2.kar...@nokia.com
Date: Wed, 22 Apr 2009 16:04:25 +0200
Subject: [PATCH] omap_hsmmc: context save/restore support
Keep the context over PM dynamic OFF states.
Signed-off-by: Denis Karpov ext-denis.2.kar...@nokia.com
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c | 194
++--
1 files changed, 184 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c28d055..ac1a3bf 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -37,6 +37,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSCONFIG 0x0010
+#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -94,6 +95,8 @@
#define DUAL_VOLT_OCR_BIT7
#define SRC (1 25)
#define SRD (1 26)
+#define SOFTRESET(1 1)
+#define RESETDONE(1 0)
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -152,6 +155,8 @@ struct mmc_omap_host {
int slot_id;
int dbclk_enabled;
int response_busy;
+ int context_loss;
+
struct omap_mmc_platform_data *pdata;
};
@@ -166,6 +171,166 @@ static void omap_mmc_stop_clock(struct mmc_omap_host
*host)
dev_dbg(mmc_dev(host-mmc), MMC Clock is not stoped\n);
}
+#ifdef CONFIG_PM
+
+/*
+ * Restore the MMC host context, if it was lost as result of a
+ * power state change.
+ */
+static int omap_mmc_restore_ctx(struct mmc_omap_host *host)
+{
+ struct mmc_ios *ios = host-mmc-ios;
+ struct omap_mmc_platform_data *pdata = host-pdata;
+ int context_loss = 0;
+ u32 hctl, capa, con;
+ u16 dsor = 0;
+ unsigned long timeout;
+
+ if (pdata-get_context_loss_count) {
+ context_loss = pdata-get_context_loss_count(host-dev);
+ if (context_loss 0)
+ return 1;
+ }
This seems to restore the context always. The context should be restored
only if the card was powered OFF, Right?
The context could also be lost if the CORE transitions to OFF. I assume that
case gets handled here without anything extra required if power_saving is
set to true. Am I right?
How about the case of eMMC? Since it is not a removable device the card is
not powered OFF. But the CORE OFF would result in context loss. Do we hit
the restore_ctx path in that case?
+
+ dev_dbg(mmc_dev(host-mmc), context was %slost\n,
+ context_loss == host-context_loss ? not : );
+ if (host-context_loss == context_loss)
+ return 1;
+
+ /* Wait for hardware reset */
+ timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
+ while ((OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE) !=
RESETDONE
+ time_before(jiffies, timeout))
+ ;
+
+ /* Do software reset */
+ OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET);
+ timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
+ while ((OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE) !=
RESETDONE
+ time_before(jiffies, timeout))
+ ;
+
+ OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
+ OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+
+ if (host-id == OMAP_MMC1_DEVID) {
+ if (host-power_mode != MMC_POWER_OFF
+ (1 ios-vdd) = MMC_VDD_23_24)
+ hctl = SDVS18;
+ else
+ hctl = SDVS30;
+ capa = VS30 | VS18;
+ } else {
+ hctl = SDVS18;
+ capa = VS18;
+ }
+
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+ OMAP_HSMMC_READ(host-base, HCTL) | hctl);
+
+ OMAP_HSMMC_WRITE(host-base, CAPA,
+ OMAP_HSMMC_READ(host-base, CAPA) | capa);
+
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+ OMAP_HSMMC_READ(host-base, HCTL) | SDBP);
+
+ timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
+ while ((OMAP_HSMMC_READ(host-base, HCTL) SDBP) != SDBP
+ time_before(jiffies, timeout))
+ ;
+
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host-base, ISE,
