Re: [PATCH] OMAP3: beagle: add support for beagleboard xM revision C
* Koen Kooi k...@dominion.thruhere.net [110531 21:09]:
Op 30 mei 2011, om 16:34 heeft Tony Lindgren het volgende geschreven:
Hi,
* Koen Kooi k...@dominion.thruhere.net [110527 06:28]:
@@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
+ case 2:
+ printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
+ break;
default:
printk(KERN_INFO OMAP3 Beagle Rev: unknown %hd\n, beagle_rev);
- omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
}
}
Maybe just set up static struct omap3_beagle that contains the
various things to initialize. Then initialize it in omap3_beagle_init_rev
above.
Otherwise we'll end up adding more and more omap3_beagle_get_rev and
cpu_is_omap tests to this file and it will become hard to maintain.
@@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
{
int r, usb_pwr_level;
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ if (cpu_is_omap3630()) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
(omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
This would become:
mmc[0].gpio_wp = beagle.gpio_wp;
@@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
* high / others active low)
* DVI reset GPIO is different between beagle revisions
*/
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
- usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ if (cpu_is_omap3630()) {
beagle_dvi_device.reset_gpio = 129;
/*
- * gpio + 1 on Xm controls the TFP410's enable line (active low)
+ * gpio + 1 on xM controls the TFP410's enable line (active low)
* gpio + 2 control varies depending on the board rev as below:
* P7/P8 revisions(prototype): Camera EN
* A2+ revisions (production): LDO (DVI, serial, led blocks)
This would be just:
usb_pwr_level = beagle.usb_pwr_level;
And so on.
Tony, thanks for the feedback! The change you want is a bit too much for my C
knowledge, but Joel will but picking it up from here.
Hmm, not much there to it actually :) I'm sure you too can do it
little help from Joel.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap4: Pass core and wakeup mux tables to omap4_mux_init
* Colin Cross ccr...@android.com [110531 21:46]: On Tue, May 31, 2011 at 5:42 AM, Tony Lindgren t...@atomide.com wrote: * Colin Cross ccr...@android.com [110504 14:54]: OMAP4 contains two separate instances of the padconf registers, one in the core system config and one in the wakeup system config. Pass in two tables to apply the correct values to each instance. Hmm good catch thanks. Will queue this as a fix. This patch doesn't work without another fix to allow NULL to be passed to omap4_mux_init. Do you prefer allowing NULL, or adding empty board_wkup_mux arrays to every board file? I have a patch for the first option. OK, saw that patch and adding to fixes. Passing NULL here is fine. 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 1/3] OMAP2+: Fix debug section mistmatch warnings
* Govindraj.R govindraj.r...@ti.com [110531 22:54]: Fix the below debug section mismatch warnings. while compiling kernel with CONFIG_DEBUG_SECTION_MISMATCH=y WARNING: vmlinux.o(.data+0x38638): Section mismatch in reference from the variable serial*_data to the (unknown reference) .init.data:(unknown) The variable serial*_data references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console These should be already fixed by an earlier patch. Can you please check against our devel-fixes branch? 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] OMAP: clockdomain: Remove redundant call to pwrdm_wait_transition()
Hi, On Thursday, May 26, 2011 4:08 PM, Bedia, Vaibhav wrote: The call to pwrdm_wait_transition() in clkdm_clk_enable() is redundant since the function pwrdm_clkdm_state_switch() which is called next also does the same thing. Any comments on this patch? Can it be merged? Regards, Vaibhav-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] OMAP2+: fix compilation warnings.
* Govindraj.R govindraj.r...@ti.com [110531 22:54]: Fix below compilation warnings. arch/arm/mach-omap2/omap_hwmod.c: In function 'omap_hwmod_for_each': arch/arm/mach-omap2/omap_hwmod.c:1631: warning: 'ret' may be used uninitialized in this function arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_gpio': arch/arm/mach-omap2/mux.c:917: warning: 'm' may be used uninitialized in this function Thanks, applying into devel-fixes. Whee, is the only warning now remaining the h4 keypad warning? 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 1/3] OMAP2+: Fix debug section mistmatch warnings
On Wed, Jun 1, 2011 at 12:43 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [110531 22:54]: Fix the below debug section mismatch warnings. while compiling kernel with CONFIG_DEBUG_SECTION_MISMATCH=y WARNING: vmlinux.o(.data+0x38638): Section mismatch in reference from the variable serial*_data to the (unknown reference) .init.data:(unknown) The variable serial*_data references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console These should be already fixed by an earlier patch. Can you please check against our devel-fixes branch? Yes this is already fixed. Sorry for the noise. -- Thanks, Govindraj.R 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP4: MMC: increase delay for pbias
* Balaji T K balaj...@ti.com [110530 07:23]:
4 micro seconds is not enough for PBIAS if MMC regulator is
enabled from MMC regulator OFF.
Increase the delay for PBIAS to stabilize.
Wait for PBIAS and timeout if not.
Resolves MMC/SD failure on OMAP4
Pbias Voltage is not same as LDO
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/hsmmc.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b2f30be..3f8dc16 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -145,6 +145,7 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
int power_on, int vdd)
{
u32 reg;
+ unsigned long timeout;
if (power_on) {
reg = omap4_ctrl_pad_readl(control_pbias_offset);
@@ -157,9 +158,15 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
OMAP4_MMC1_PWRDNZ_MASK |
OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
- /* 4 microsec delay for comparator to generate an error*/
- udelay(4);
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
+
+ timeout = jiffies + msecs_to_jiffies(5);
+ do {
+ reg = omap4_ctrl_pad_readl(control_pbias_offset);
+ if (!(reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK))
+ break;
+ udelay(100);
+ } while (!time_after(jiffies, timeout));
+
if (reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK) {
pr_err(Pbias Voltage is not same as LDO\n);
/* Caution : On VMODE_ERROR Power Down MMC IO */
Actually, can you check if you can use usleep_range here as recommended
by checkpatch.pl?
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
Patches archived, mailbox cleaned, please check and resend as needed
Hi all, I've marked all the patches as archived in patchwork. The archived patches can be found at: http://patchwork.kernel.org/bundle/tmlind/archived-v2.6.39/ You need to select Filters - Archived - Yes to see them. I'm sure we've missed a bunch of patches this merge window because of the ARM Linux code coalescing work. So please check the state of your patches and repost as needed. It is still unclear how much new code we can add currently, so please be prepared to rebase patches until we know. 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 1/2] ARM: OMAP4: MMC: increase delay for pbias
On Wed, Jun 1, 2011 at 1:11 PM, Tony Lindgren t...@atomide.com wrote:
* Balaji T K balaj...@ti.com [110530 07:23]:
4 micro seconds is not enough for PBIAS if MMC regulator is
enabled from MMC regulator OFF.
Increase the delay for PBIAS to stabilize.
Wait for PBIAS and timeout if not.
Resolves MMC/SD failure on OMAP4
Pbias Voltage is not same as LDO
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/hsmmc.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b2f30be..3f8dc16 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -145,6 +145,7 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
int power_on, int vdd)
{
u32 reg;
+ unsigned long timeout;
if (power_on) {
reg = omap4_ctrl_pad_readl(control_pbias_offset);
@@ -157,9 +158,15 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
OMAP4_MMC1_PWRDNZ_MASK |
OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
- /* 4 microsec delay for comparator to generate an error*/
- udelay(4);
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
+
+ timeout = jiffies + msecs_to_jiffies(5);
+ do {
+ reg = omap4_ctrl_pad_readl(control_pbias_offset);
+ if (!(reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK))
+ break;
+ udelay(100);
+ } while (!time_after(jiffies, timeout));
+
if (reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK) {
pr_err(Pbias Voltage is not same as LDO\n);
/* Caution : On VMODE_ERROR Power Down MMC IO */
Actually, can you check if you can use usleep_range here as recommended
by checkpatch.pl?
sure, fixing it in v2
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: (Bug report) the kernel crash when I run cyclictest on AM3715/DM3730
* stanley.miao stanley.m...@windriver.com [110530 19:19]: The test command : # cyclictest -l1 -m -a0 -t1 -n -p99 -i200 -h200 -q I run the following command to increase cpu's burden at the same time. # while true; do hackbench; sleep 1;done cyclictest and hackbench can be get in git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git The linux kernel version : the kernel I used is windriver linux kernel. but this bug can also be reproduced on the branch OMAPPSP_03.00.01.06 in git://arago-project.org/git/projects/linux-omap3.git. The kernel in linux-omap-2.6 git tree hung and didn't give any useful Oops messages when I ran this cyclictest. Started these tests on zoom3 on current devel-fixes branch at commit 1704bf15deb6de20f8f4272c8d8232b36bbc7484. So far no issues here, so maybe try git bisect between the mainline version you have and v3.0-rc1? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: OMAP4: MMC: no regulator off during probe for eMMC
eMMC does not handle power off when not in sleep state,
Skip regulator disable during probe when eMMC is
not in known state - state left by bootloader.
Resolves eMMC failure on OMAP4
mmc0: error -110 whilst initialising MMC card
Signed-off-by: Balaji T K balaj...@ti.com
Tested-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/hsmmc.c |3 +++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h |3 +++
drivers/mmc/host/omap_hsmmc.c |3 +++
5 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73fa90b..b324605 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -322,6 +322,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_wp= -EINVAL,
.nonremovable = true,
.ocr_mask = MMC_VDD_29_30,
+ .no_off_init= true,
},
{
.mmc= 1,
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 24f25c7..66868c5 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -338,6 +338,9 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
if (c-no_off)
mmc-slots[0].no_off = 1;
+ if (c-no_off_init)
+ mmc-slots[0].no_regulator_off_init = c-no_off_init;
+
if (c-vcc_aux_disable_is_sleep)
mmc-slots[0].vcc_aux_disable_is_sleep = 1;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index f119348..f757e78 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -18,6 +18,7 @@ struct omap2_hsmmc_info {
boolnonremovable; /* Nonremovable e.g. eMMC */
boolpower_saving; /* Try to sleep or power off when possible */
boolno_off; /* power_saving and power is not to go off */
+ boolno_off_init;/* no power off when not in MMC sleep state */
boolvcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index f38fef9..c7b8741 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -101,6 +101,9 @@ struct omap_mmc_platform_data {
/* If using power_saving and the MMC power is not to go off */
unsigned no_off:1;
+ /* eMMC does not handle power off when not in sleep state */
+ unsigned no_regulator_off_init:1;
+
/* Regulator off remapped to sleep */
unsigned vcc_aux_disable_is_sleep:1;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 259ece0..5b2e215 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -435,6 +435,9 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
reg = regulator_get(host-dev, vmmc_aux);
host-vcc_aux = IS_ERR(reg) ? NULL : reg;
+ /* For eMMC do not power off when not in sleep state */
+ if (mmc_slot(host).no_regulator_off_init)
+ return 0;
/*
* UGLY HACK: workaround regulator framework bugs.
* When the bootloader leaves a supply active, it's
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] ARM: OMAP4: fix MMC failure due to regulator enable/disable ops
Balaji T K (2): ARM: OMAP4: MMC: increase delay for pbias ARM: OMAP4: MMC: no regulator off during probe for eMMC arch/arm/mach-omap2/board-4430sdp.c |1 + arch/arm/mach-omap2/hsmmc.c | 16 +--- arch/arm/mach-omap2/hsmmc.h |1 + arch/arm/plat-omap/include/plat/mmc.h |3 +++ drivers/mmc/host/omap_hsmmc.c |3 +++ 5 files changed, 21 insertions(+), 3 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 v2 1/2] ARM: OMAP4: MMC: increase delay for pbias
4 micro seconds is not enough for PBIAS if MMC regulator is
enabled from MMC regulator OFF.
Increase the delay for PBIAS to stabilize.
Wait for PBIAS and timeout if not.
Resolves MMC/SD failure on OMAP4
Pbias Voltage is not same as LDO
Signed-off-by: Balaji T K balaj...@ti.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
v2:
replace usleep by usleep_range
arch/arm/mach-omap2/hsmmc.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b2f30be..24f25c7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -145,6 +145,7 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
int power_on, int vdd)
{
u32 reg;
+ unsigned long timeout;
if (power_on) {
reg = omap4_ctrl_pad_readl(control_pbias_offset);
@@ -157,9 +158,15 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
OMAP4_MMC1_PWRDNZ_MASK |
OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
- /* 4 microsec delay for comparator to generate an error*/
- udelay(4);
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
+
+ timeout = jiffies + msecs_to_jiffies(5);
+ do {
+ reg = omap4_ctrl_pad_readl(control_pbias_offset);
+ if (!(reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK))
+ break;
+ usleep_range(100, 200);
+ } while (!time_after(jiffies, timeout));
+
if (reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK) {
pr_err(Pbias Voltage is not same as LDO\n);
/* Caution : On VMODE_ERROR Power Down MMC IO */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] MFD/ASoC: TWL4030/TWL6040 changes
Hello, The series will do three major things, and they are in one series, because they pretty much depending on each other, so it is easier to handle them together. 1. Rename the twl4030-codec MFD driver to twl4030-audio Since the ASoC multicomponent introduction (2.6.37) the twl4030-codec MFD dirver had been using twl4030-audio to register (twl4030-codec is the ASoC codec driver). The documentation refers to this part of twl as audio block, so it is better to rename the driver as well to avoid confusion. 2. Introduction of MFD driver for twl6040. The TWL6040 audio IC has codec and vibra functionality. Convert the existing ASoC codec driver to use the new MFD driver's interface. 3. Vibrator driver for TWL6040 (Input/ForceFeedback driver) The driver itself, and support for the vibrators in SDP4430 board. The series has been tested on top of merged omap-next, asoc-next, and mfd-next. It applies on top of linux-next as well. Regards, Peter --- Misael Lopez Cruz (3): mfd: twl6040: Add initial support ASoC: twl6040: Convert into TWL6040 MFD child input: Add initial support for TWL6040 vibrator Peter Ujfalusi (5): MFD: twl4030-codec: Rename internals from codec to audio MFD: twl4030-codec - twl4030-audio: Rename the driver MFD: twl4030-audio: Rename platform data MFD: twl6040: Change platform data for soc codec driver OMAP4: SDP4430: Add twl6040 vibrator platform support arch/arm/mach-omap2/board-3430sdp.c |8 +- arch/arm/mach-omap2/board-4430sdp.c | 50 +++- arch/arm/mach-omap2/board-devkit8000.c |8 +- arch/arm/mach-omap2/board-igep0020.c |8 +- arch/arm/mach-omap2/board-omap3beagle.c |8 +- arch/arm/mach-omap2/board-omap3evm.c |8 +- arch/arm/mach-omap2/board-omap3pandora.c |8 +- arch/arm/mach-omap2/board-omap3stalker.c |8 +- arch/arm/mach-omap2/board-omap3touchbook.c |8 +- arch/arm/mach-omap2/board-overo.c|8 +- arch/arm/mach-omap2/board-rx51-peripherals.c |6 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 14 +- arch/arm/plat-omap/include/plat/irqs.h | 12 +- drivers/input/misc/Kconfig | 13 +- drivers/input/misc/Makefile |1 + drivers/input/misc/twl4030-vibra.c | 12 +- drivers/input/misc/twl6040-vibra.c | 428 +++ drivers/mfd/Kconfig |8 +- drivers/mfd/Makefile |3 +- drivers/mfd/twl-core.c | 13 +- drivers/mfd/twl4030-audio.c | 278 drivers/mfd/twl4030-codec.c | 277 drivers/mfd/twl6040-core.c | 588 ++ drivers/mfd/twl6040-irq.c| 205 + include/linux/i2c/twl.h | 21 +- include/linux/mfd/twl4030-audio.h| 272 include/linux/mfd/twl4030-codec.h| 272 include/linux/mfd/twl6040.h | 260 sound/soc/codecs/Kconfig |3 +- sound/soc/codecs/twl4030.c | 22 +- sound/soc/codecs/twl6040.c | 426 --- sound/soc/codecs/twl6040.h | 118 - sound/soc/omap/sdp3430.c |2 +- sound/soc/omap/sdp4430.c |2 + sound/soc/omap/zoom2.c |2 +- 35 files changed, 2290 insertions(+), 1090 deletions(-) create mode 100644 drivers/input/misc/twl6040-vibra.c create mode 100644 drivers/mfd/twl4030-audio.c delete mode 100644 drivers/mfd/twl4030-codec.c create mode 100644 drivers/mfd/twl6040-core.c create mode 100644 drivers/mfd/twl6040-irq.c create mode 100644 include/linux/mfd/twl4030-audio.h delete mode 100644 include/linux/mfd/twl4030-codec.h create mode 100644 include/linux/mfd/twl6040.h -- 1.7.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] MFD: twl4030-audio: Rename platform data
Allign the platform data names for twl4030 audio submodule:
twl4030_audio_data: for the core MFD driver
twl4030_codec_data: for ASoC codec driver
twl4030_vibra_data: for the input/ForceFeedback driver
To avoid breakage, change all depending drivers, files
to use the new types.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |8
arch/arm/mach-omap2/board-devkit8000.c |8
arch/arm/mach-omap2/board-igep0020.c |8
arch/arm/mach-omap2/board-omap3beagle.c |8
arch/arm/mach-omap2/board-omap3evm.c |8
arch/arm/mach-omap2/board-omap3pandora.c |8
arch/arm/mach-omap2/board-omap3stalker.c |8
arch/arm/mach-omap2/board-omap3touchbook.c |8
arch/arm/mach-omap2/board-overo.c|8
arch/arm/mach-omap2/board-rx51-peripherals.c |6 +++---
arch/arm/mach-omap2/board-zoom-peripherals.c | 14 +++---
drivers/input/misc/twl4030-vibra.c |2 +-
drivers/mfd/twl-core.c |8
drivers/mfd/twl4030-audio.c |8
include/linux/i2c/twl.h | 12 ++--
sound/soc/codecs/twl4030.c |6 +++---
sound/soc/codecs/twl6040.c |2 +-
17 files changed, 65 insertions(+), 65 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ae2963a..36fb018 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -463,11 +463,11 @@ static struct regulator_init_data sdp3430_vpll2 = {
.consumer_supplies = sdp3430_vpll2_supplies,
};
-static struct twl4030_codec_audio_data sdp3430_audio;
+static struct twl4030_codec_data sdp3430_codec;
-static struct twl4030_codec_data sdp3430_codec = {
+static struct twl4030_audio_data sdp3430_audio = {
.audio_mclk = 2600,
- .audio = sdp3430_audio,
+ .codec = sdp3430_codec,
};
static struct twl4030_platform_data sdp3430_twldata = {
@@ -480,7 +480,7 @@ static struct twl4030_platform_data sdp3430_twldata = {
.madc = sdp3430_madc_data,
.keypad = sdp3430_kp_data,
.usb= sdp3430_usb_data,
- .codec = sdp3430_codec,
+ .audio = sdp3430_audio,
.vaux1 = sdp3430_vaux1,
.vaux2 = sdp3430_vaux2,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index cf520d7..3a83bc4 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -337,11 +337,11 @@ static struct twl4030_usb_data devkit8000_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
-static struct twl4030_codec_audio_data devkit8000_audio_data;
+static struct twl4030_codec_data devkit8000_codec_data;
-static struct twl4030_codec_data devkit8000_codec_data = {
+static struct twl4030_audio_data devkit8000_audio_data = {
.audio_mclk = 2600,
- .audio = devkit8000_audio_data,
+ .codec = devkit8000_codec_data,
};
static struct twl4030_platform_data devkit8000_twldata = {
@@ -351,7 +351,7 @@ static struct twl4030_platform_data devkit8000_twldata = {
/* platform_data for children goes here */
.usb= devkit8000_usb_data,
.gpio = devkit8000_gpio_data,
- .codec = devkit8000_codec_data,
+ .audio = devkit8000_audio_data,
.vmmc1 = devkit8000_vmmc1,
.vdac = devkit8000_vdac,
.vpll1 = devkit8000_vpll1,
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 0c1bfca..89d3999 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -519,11 +519,11 @@ static void __init igep_init_early(void)
m65kam_sdrc_params);
}
-static struct twl4030_codec_audio_data igep2_audio_data;
+static struct twl4030_codec_data igep2_codec_data;
-static struct twl4030_codec_data igep2_codec_data = {
+static struct twl4030_audio_data igep2_audio_data = {
.audio_mclk = 2600,
- .audio = igep2_audio_data,
+ .codec = igep2_codec_data,
};
static int igep2_keymap[] = {
@@ -588,7 +588,7 @@ static void __init igep_i2c_init(void)
if (ret)
pr_warning(IGEP2: Could not register I2C3 bus (%d)\n,
ret);
- igep_twldata.codec = igep2_codec_data;
+ igep_twldata.audio = igep2_audio_data;
igep_twldata.keypad = igep2_keypad_pdata;
igep_twldata.vpll2 = igep2_vpll2;
}
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..d8ff23b 100644
---
[PATCH 8/8] OMAP4: SDP4430: Add twl6040 vibrator platform support
Add twl4030_vibra platform data, and the needed regulators
for twl6040 vibrator.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 50 ++-
1 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b324605..6c4c1a3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -22,6 +22,7 @@
#include linux/i2c/twl.h
#include linux/gpio_keys.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/leds.h
#include linux/leds_pwm.h
@@ -276,11 +277,40 @@ static struct platform_device sdp4430_lcd_device = {
.id = -1,
};
+static struct regulator_consumer_supply sdp4430_vbat_supply[] = {
+ REGULATOR_SUPPLY(vddvibl, twl6040-vibra),
+ REGULATOR_SUPPLY(vddvibr, twl6040-vibra),
+};
+
+static struct regulator_init_data sdp4430_vbat_data = {
+ .constraints = {
+ .always_on = 1,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(sdp4430_vbat_supply),
+ .consumer_supplies = sdp4430_vbat_supply,
+};
+
+static struct fixed_voltage_config sdp4430_vbat_pdata = {
+ .supply_name= VBAT,
+ .microvolts = 375,
+ .init_data = sdp4430_vbat_data,
+ .gpio = -EINVAL,
+};
+
+static struct platform_device sdp4430_vbat = {
+ .name = reg-fixed-voltage,
+ .id = -1,
+ .dev = {
+ .platform_data = sdp4430_vbat_pdata,
+ },
+};
+
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
sdp4430_leds_pwm,
+ sdp4430_vbat,
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
@@ -522,6 +552,23 @@ static struct regulator_init_data sdp4430_clk32kg = {
},
};
+static struct twl4030_vibra_data twl6040_vibra = {
+ .vibldrv_res = 8,
+ .vibrdrv_res = 3,
+ .viblmotor_res = 10,
+ .vibrmotor_res = 10,
+ .vddvibl_uV = 0,/* fixed volt supply - VBAT */
+ .vddvibr_uV = 0,/* fixed volt supply - VBAT */
+};
+
+static struct twl4030_audio_data twl6040_audio = {
+ .codec = NULL,
+ .vibra = twl6040_vibra,
+ .audpwron_gpio = 127,
+ .naudint_irq= OMAP44XX_IRQ_SYS_2N,
+ .irq_base = TWL6040_CODEC_IRQ_BASE,
+};
+
static struct twl4030_platform_data sdp4430_twldata = {
.irq_base = TWL6030_IRQ_BASE,
.irq_end= TWL6030_IRQ_END,
@@ -538,7 +585,8 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux2 = sdp4430_vaux2,
.vaux3 = sdp4430_vaux3,
.clk32kg= sdp4430_clk32kg,
- .usb= omap4_usbphy_data
+ .usb= omap4_usbphy_data,
+ .audio = twl6040_audio,
};
static struct i2c_board_info __initdata sdp4430_i2c_3_boardinfo[] = {
--
1.7.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] input: Add initial support for TWL6040 vibrator
From: Misael Lopez Cruz misael.lo...@ti.com
Add twl6040_vibra as a child of MFD device twl6040_codec. This
implementation covers the PCM-to-PWM mode of TWL6040 vibrator
module.
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/twl6040-vibra.c | 428
include/linux/i2c/twl.h|8 +
4 files changed, 448 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/twl6040-vibra.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 077309a..d1bf872 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -275,6 +275,17 @@ config INPUT_TWL4030_VIBRA
To compile this driver as a module, choose M here. The module will
be called twl4030_vibra.
+config INPUT_TWL6040_VIBRA
+ tristate Support for TWL6040 Vibrator
+ depends on TWL4030_CORE
+ select TWL6040_CORE
+ select INPUT_FF_MEMLESS
+ help
+ This option enables support for TWL6040 Vibrator Driver.
+
+ To compile this driver as a module, choose M here. The module will
+ be called twl6040_vibra.
+
config INPUT_UINPUT
tristate User level driver support
help
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 38efb2c..4da7c3a 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON) += twl4030-pwrbutton.o
obj-$(CONFIG_INPUT_TWL4030_VIBRA) += twl4030-vibra.o
+obj-$(CONFIG_INPUT_TWL6040_VIBRA) += twl6040-vibra.o
obj-$(CONFIG_INPUT_UINPUT) += uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
diff --git a/drivers/input/misc/twl6040-vibra.c
b/drivers/input/misc/twl6040-vibra.c
new file mode 100644
index 000..5a54515
--- /dev/null
+++ b/drivers/input/misc/twl6040-vibra.c
@@ -0,0 +1,428 @@
+/*
+ * twl6040-vibra.c - TWL6040 Vibrator driver
+ *
+ * Author: Jorge Eduardo Candelaria jorge.candela...@ti.com
+ * Author: Misael Lopez Cruz misael.lo...@ti.com
+ *
+ * Copyright: (C) 2011 Texas Instruments, Inc.
+ *
+ * Based on twl4030-vibra.c by Henrik Saari henrik.sa...@nokia.com
+ * Felipe Balbi felipe.ba...@nokia.com
+ * Jari Vanhala ext-javi.vanh...@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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/workqueue.h
+#include linux/i2c/twl.h
+#include linux/mfd/twl6040.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/regulator/consumer.h
+
+#define EFFECT_DIR_180_DEG 0x8000
+
+/* Recommended modulation index 85% */
+#define TWL6040_VIBRA_MOD 85
+
+#define TWL6040_NUM_SUPPLIES 2
+
+struct vibra_info {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct workqueue_struct *workqueue;
+ struct work_struct play_work;
+ struct mutex mutex;
+
+ bool enabled;
+ int weak_speed;
+ int strong_speed;
+ int direction;
+
+ unsigned int vibldrv_res;
+ unsigned int vibrdrv_res;
+ unsigned int viblmotor_res;
+ unsigned int vibrmotor_res;
+
+ struct regulator_bulk_data supplies[TWL6040_NUM_SUPPLIES];
+
+ struct twl6040 *twl6040;
+};
+
+static irqreturn_t twl6040_vib_irq_handler(int irq, void *data)
+{
+ struct vibra_info *info = data;
+ struct twl6040 *twl6040 = info-twl6040;
+ u8 status;
+
+ status = twl6040_reg_read(twl6040, TWL6040_REG_STATUS);
+ if (status TWL6040_VIBLOCDET) {
+ dev_warn(info-dev, Left Vibrator overcurrent detected\n);
+ twl6040_clear_bits(twl6040, TWL6040_REG_VIBCTLL,
+ TWL6040_VIBENAL);
+ }
+ if (status TWL6040_VIBROCDET) {
+ dev_warn(info-dev, Right Vibrator overcurrent detected\n);
+ twl6040_clear_bits(twl6040, TWL6040_REG_VIBCTLR,
+
[PATCH 6/8] MFD: twl6040: Change platform data for soc codec driver
Pass twl4030_codec_data instead of the twl4030_audio_data
for the ASoC codec driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040-core.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
index bb36862..bc0ee41 100644
--- a/drivers/mfd/twl6040-core.c
+++ b/drivers/mfd/twl6040-core.c
@@ -494,9 +494,8 @@ static int __devinit twl6040_probe(struct platform_device
*pdev)
if (pdata-codec) {
cell = twl6040-cells[children];
cell-name = twl6040-codec;
- /* The codec expects the twl4030_audio_data as platform data */
- cell-platform_data = pdata;
- cell-pdata_size = sizeof(*pdata);
+ cell-platform_data = pdata-codec;
+ cell-pdata_size = sizeof(*pdata-codec);
children++;
}
--
1.7.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] ASoC: twl6040: Convert into TWL6040 MFD child
From: Misael Lopez Cruz misael.lo...@ti.com
Convert TWL6040 CODEC driver into a TWL6040 MFD child, it implies
that MFD-level operations like register accesses, clock setting
and power management are done through MFD APIs, not directly by
CODEC driver anymore. To avoid conflicts with the other MFD child,
vibrator registers are skipped in CODEC driver.
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/Kconfig |1 +
sound/soc/codecs/twl6040.c | 426 +---
sound/soc/codecs/twl6040.h | 118
sound/soc/omap/sdp4430.c |2 +
4 files changed, 91 insertions(+), 456 deletions(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0002220..922f59f 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -240,6 +240,7 @@ config SND_SOC_TWL4030
tristate
config SND_SOC_TWL6040
+ select TWL6040_CORE
tristate
config SND_SOC_UDA134X
diff --git a/sound/soc/codecs/twl6040.c b/sound/soc/codecs/twl6040.c
index ade6616..209089c 100644
--- a/sound/soc/codecs/twl6040.c
+++ b/sound/soc/codecs/twl6040.c
@@ -24,11 +24,10 @@
#include linux/init.h
#include linux/delay.h
#include linux/pm.h
-#include linux/i2c.h
-#include linux/gpio.h
#include linux/platform_device.h
#include linux/slab.h
#include linux/i2c/twl.h
+#include linux/mfd/twl6040.h
#include sound/core.h
#include sound/pcm.h
@@ -77,14 +76,12 @@ struct twl6040_jack_data {
/* codec private data */
struct twl6040_data {
- int audpwron;
- int naudint;
int codec_powered;
int pll;
int non_lp;
+ unsigned int clk_in;
unsigned int sysclk;
struct snd_pcm_hw_constraint_list *sysclk_constraints;
- struct completion ready;
struct twl6040_jack_data hs_jack;
struct snd_soc_codec *codec;
struct workqueue_struct *workqueue;
@@ -239,12 +236,13 @@ static inline void twl6040_write_reg_cache(struct
snd_soc_codec *codec,
static int twl6040_read_reg_volatile(struct snd_soc_codec *codec,
unsigned int reg)
{
+ struct twl6040 *twl6040 = codec-control_data;
u8 value;
if (reg = TWL6040_CACHEREGNUM)
return -EIO;
- twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, value, reg);
+ value = twl6040_reg_read(twl6040, reg);
twl6040_write_reg_cache(codec, reg, value);
return value;
@@ -256,11 +254,13 @@ static int twl6040_read_reg_volatile(struct snd_soc_codec
*codec,
static int twl6040_write(struct snd_soc_codec *codec,
unsigned int reg, unsigned int value)
{
+ struct twl6040 *twl6040 = codec-control_data;
+
if (reg = TWL6040_CACHEREGNUM)
return -EIO;
twl6040_write_reg_cache(codec, reg, value);
- return twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE, value, reg);
+ return twl6040_reg_write(twl6040, reg, value);
}
static void twl6040_init_vio_regs(struct snd_soc_codec *codec)
@@ -268,15 +268,21 @@ static void twl6040_init_vio_regs(struct snd_soc_codec
*codec)
u8 *cache = codec-reg_cache;
int reg, i;
- /* allow registers to be accessed by i2c */
- twl6040_write(codec, TWL6040_REG_ACCCTL, cache[TWL6040_REG_ACCCTL]);
-
for (i = 0; i TWL6040_VIOREGNUM; i++) {
reg = twl6040_vio_reg[i];
- /* skip read-only registers (ASICID, ASICREV, STATUS) */
+ /*
+* skip read-only registers (ASICID, ASICREV, STATUS)
+* and registers shared among MFD children
+*/
switch (reg) {
case TWL6040_REG_ASICID:
case TWL6040_REG_ASICREV:
+ case TWL6040_REG_INTID:
+ case TWL6040_REG_INTMR:
+ case TWL6040_REG_NCPCTL:
+ case TWL6040_REG_LDOCTL:
+ case TWL6040_REG_GPOCTL:
+ case TWL6040_REG_ACCCTL:
case TWL6040_REG_STATUS:
continue;
default:
@@ -293,6 +299,20 @@ static void twl6040_init_vdd_regs(struct snd_soc_codec
*codec)
for (i = 0; i TWL6040_VDDREGNUM; i++) {
reg = twl6040_vdd_reg[i];
+ /* skip vibra and PLL registers */
+ switch (reg) {
+ case TWL6040_REG_VIBCTLL:
+ case TWL6040_REG_VIBDATL:
+ case TWL6040_REG_VIBCTLR:
+ case TWL6040_REG_VIBDATR:
+ case TWL6040_REG_HPPLLCTL:
+ case TWL6040_REG_LPPLLCTL:
+ case TWL6040_REG_LPPLLDIV:
+ continue;
+ default:
+ break;
+ }
+
twl6040_write(codec, reg, cache[reg]);
}
}
@@ -596,88 +616,6 @@ static int
[PATCH 1/8] MFD: twl4030-codec: Rename internals from codec to audio
In preparation of renaming the driver from twl4030-codec
to twl4030-audio, first do some clean ups in the driver,
which does not cause any problems outside.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl4030-codec.c | 135 ++-
1 files changed, 68 insertions(+), 67 deletions(-)
diff --git a/drivers/mfd/twl4030-codec.c b/drivers/mfd/twl4030-codec.c
index 2bf4136..e1782b3 100644
--- a/drivers/mfd/twl4030-codec.c
+++ b/drivers/mfd/twl4030-codec.c
@@ -1,5 +1,6 @@
/*
- * MFD driver for twl4030 codec submodule
+ * MFD driver for twl4030 audio submodule, which contains an audio codec, and
+ * the vibra control.
*
* Author: Peter Ujfalusi peter.ujfal...@ti.com
*
@@ -31,53 +32,53 @@
#include linux/mfd/core.h
#include linux/mfd/twl4030-codec.h
-#define TWL4030_CODEC_CELLS2
+#define TWL4030_AUDIO_CELLS2
-static struct platform_device *twl4030_codec_dev;
+static struct platform_device *twl4030_audio_dev;
-struct twl4030_codec_resource {
+struct twl4030_audio_resource {
int request_count;
u8 reg;
u8 mask;
};
-struct twl4030_codec {
+struct twl4030_audio {
unsigned int audio_mclk;
struct mutex mutex;
- struct twl4030_codec_resource resource[TWL4030_CODEC_RES_MAX];
- struct mfd_cell cells[TWL4030_CODEC_CELLS];
+ struct twl4030_audio_resource resource[TWL4030_CODEC_RES_MAX];
+ struct mfd_cell cells[TWL4030_AUDIO_CELLS];
};
/*
* Modify the resource, the function returns the content of the register
* after the modification.
*/
-static int twl4030_codec_set_resource(enum twl4030_codec_res id, int enable)
+static int twl4030_audio_set_resource(enum twl4030_codec_res id, int enable)
{
- struct twl4030_codec *codec = platform_get_drvdata(twl4030_codec_dev);
+ struct twl4030_audio *audio = platform_get_drvdata(twl4030_audio_dev);
u8 val;
twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, val,
- codec-resource[id].reg);
+ audio-resource[id].reg);
if (enable)
- val |= codec-resource[id].mask;
+ val |= audio-resource[id].mask;
else
- val = ~codec-resource[id].mask;
+ val = ~audio-resource[id].mask;
twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
- val, codec-resource[id].reg);
+ val, audio-resource[id].reg);
return val;
}
-static inline int twl4030_codec_get_resource(enum twl4030_codec_res id)
+static inline int twl4030_audio_get_resource(enum twl4030_codec_res id)
{
- struct twl4030_codec *codec = platform_get_drvdata(twl4030_codec_dev);
+ struct twl4030_audio *audio = platform_get_drvdata(twl4030_audio_dev);
u8 val;
twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, val,
- codec-resource[id].reg);
+ audio-resource[id].reg);
return val;
}
@@ -88,24 +89,24 @@ static inline int twl4030_codec_get_resource(enum
twl4030_codec_res id)
*/
int twl4030_codec_enable_resource(enum twl4030_codec_res id)
{
- struct twl4030_codec *codec = platform_get_drvdata(twl4030_codec_dev);
+ struct twl4030_audio *audio = platform_get_drvdata(twl4030_audio_dev);
int val;
if (id = TWL4030_CODEC_RES_MAX) {
- dev_err(twl4030_codec_dev-dev,
+ dev_err(twl4030_audio_dev-dev,
Invalid resource ID (%u)\n, id);
return -EINVAL;
}
- mutex_lock(codec-mutex);
- if (!codec-resource[id].request_count)
+ mutex_lock(audio-mutex);
+ if (!audio-resource[id].request_count)
/* Resource was disabled, enable it */
- val = twl4030_codec_set_resource(id, 1);
+ val = twl4030_audio_set_resource(id, 1);
else
- val = twl4030_codec_get_resource(id);
+ val = twl4030_audio_get_resource(id);
- codec-resource[id].request_count++;
- mutex_unlock(codec-mutex);
+ audio-resource[id].request_count++;
+ mutex_unlock(audio-mutex);
return val;
}
@@ -117,31 +118,31 @@ EXPORT_SYMBOL_GPL(twl4030_codec_enable_resource);
*/
int twl4030_codec_disable_resource(unsigned id)
{
- struct twl4030_codec *codec = platform_get_drvdata(twl4030_codec_dev);
+ struct twl4030_audio *audio = platform_get_drvdata(twl4030_audio_dev);
int val;
if (id = TWL4030_CODEC_RES_MAX) {
- dev_err(twl4030_codec_dev-dev,
+ dev_err(twl4030_audio_dev-dev,
Invalid resource ID (%u)\n, id);
return -EINVAL;
}
- mutex_lock(codec-mutex);
- if (!codec-resource[id].request_count) {
- dev_err(twl4030_codec_dev-dev,
+ mutex_lock(audio-mutex);
+ if
[PATCH 4/8] mfd: twl6040: Add initial support
From: Misael Lopez Cruz misael.lo...@ti.com
TWL6040 IC provides analog high-end audio codec functions for
handset applications. It contains several audio analog inputs
and outputs as well as vibrator support. It's connected to the
host processor via PDM interface for audio data communication.
The audio modules are controlled by internal registers that
can be accessed by I2C and PDM interface.
TWL6040 MFD will be registered as a child of TWL-CORE, and will
have two children of its own: twl6040-codec and twl6040-vibra.
This driver is based on TWL4030 and WM8350 MFD drivers.
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/include/plat/irqs.h | 12 +-
drivers/mfd/Kconfig|6 +
drivers/mfd/Makefile |1 +
drivers/mfd/twl-core.c |5 +-
drivers/mfd/twl6040-core.c | 589
drivers/mfd/twl6040-irq.c | 205 +++
include/linux/i2c/twl.h|1 +
include/linux/mfd/twl6040.h| 260 ++
8 files changed, 1074 insertions(+), 5 deletions(-)
create mode 100644 drivers/mfd/twl6040-core.c
create mode 100644 drivers/mfd/twl6040-irq.c
create mode 100644 include/linux/mfd/twl6040.h
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 5a25098..2cfba51 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -407,11 +407,19 @@
#endif
#define TWL6030_IRQ_END(TWL6030_IRQ_BASE +
TWL6030_BASE_NR_IRQS)
+#define TWL6040_CODEC_IRQ_BASE TWL6030_IRQ_END
+#ifdef CONFIG_TWL6040_CODEC
+#define TWL6040_CODEC_NR_IRQS 6
+#else
+#define TWL6040_CODEC_NR_IRQS 0
+#endif
+#define TWL6040_CODEC_IRQ_END (TWL6040_CODEC_IRQ_BASE + TWL6040_CODEC_NR_IRQS)
+
/* Total number of interrupts depends on the enabled blocks above */
-#if (TWL4030_GPIO_IRQ_END TWL6030_IRQ_END)
+#if (TWL4030_GPIO_IRQ_END TWL6040_CODEC_IRQ_END)
#define TWL_IRQ_ENDTWL4030_GPIO_IRQ_END
#else
-#define TWL_IRQ_ENDTWL6030_IRQ_END
+#define TWL_IRQ_ENDTWL6040_CODEC_IRQ_END
#endif
/* GPMC related */
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3a6f76a..ac6b4ae 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -233,6 +233,12 @@ config TWL6030_PWM
Say yes here if you want support for TWL6030 PWM.
This is used to control charging LED brightness.
+config TWL6040_CORE
+ bool
+ depends on TWL4030_CORE GENERIC_HARDIRQS
+ select MFD_CORE
+ default n
+
config MFD_STMPE
bool Support STMicroelectronics STMPE
depends on I2C=y GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4cf9465..41f3b61 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
obj-$(CONFIG_TWL6030_PWM) += twl6030-pwm.o
+obj-$(CONFIG_TWL6040_CORE) += twl6040-core.o twl6040-irq.o
obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index f9d7880..a2eddc7 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -110,7 +110,7 @@
#endif
#if defined(CONFIG_TWL4030_CODEC) || defined(CONFIG_TWL4030_CODEC_MODULE) ||\
- defined(CONFIG_SND_SOC_TWL6040) ||
defined(CONFIG_SND_SOC_TWL6040_MODULE)
+ defined(CONFIG_TWL6040_CORE) || defined(CONFIG_TWL6040_CORE_MODULE)
#define twl_has_codec()true
#else
#define twl_has_codec()false
@@ -824,10 +824,9 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
return PTR_ERR(child);
}
- /* Phoenix codec driver is probed directly atm */
if (twl_has_codec() pdata-audio twl_class_is_6030()) {
sub_chip_id = twl_map[TWL_MODULE_AUDIO_VOICE].sid;
- child = add_child(sub_chip_id, twl6040-codec,
+ child = add_child(sub_chip_id, twl6040,
pdata-audio, sizeof(*pdata-audio),
false, 0, 0);
if (IS_ERR(child))
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
new file mode 100644
index 000..bb36862
--- /dev/null
+++ b/drivers/mfd/twl6040-core.c
@@ -0,0 +1,589 @@
+/*
+ * MFD driver for TWL6040 audio device
+ *
+ * Authors:Misael Lopez Cruz misael.lo...@ti.com
+ * Jorge Eduardo Candelaria jorge.candela...@ti.com
+ * Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * Copyright: (C) 2011 Texas Instruments, Inc.
+ *
+ * This program is free
[PATCH 2/8] MFD: twl4030-codec - twl4030-audio: Rename the driver
Rename the driver, and header file from twl4030-codec to
twl4030-audio.
To avoid breakage change depending drivers at the same time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Misael Lopez Cruz misael.lo...@ti.com
---
drivers/input/misc/Kconfig |2 +-
drivers/input/misc/twl4030-vibra.c | 10 +-
drivers/mfd/Kconfig|2 +-
drivers/mfd/Makefile |2 +-
drivers/mfd/twl4030-audio.c| 278
drivers/mfd/twl4030-codec.c| 278
include/linux/mfd/twl4030-audio.h | 272 +++
include/linux/mfd/twl4030-codec.h | 272 ---
sound/soc/codecs/Kconfig |2 +-
sound/soc/codecs/twl4030.c | 16 +-
sound/soc/omap/sdp3430.c |2 +-
sound/soc/omap/zoom2.c |2 +-
12 files changed, 569 insertions(+), 569 deletions(-)
create mode 100644 drivers/mfd/twl4030-audio.c
delete mode 100644 drivers/mfd/twl4030-codec.c
create mode 100644 include/linux/mfd/twl4030-audio.h
delete mode 100644 include/linux/mfd/twl4030-codec.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 45dc6aa..077309a 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -267,7 +267,7 @@ config INPUT_TWL4030_PWRBUTTON
config INPUT_TWL4030_VIBRA
tristate Support for TWL4030 Vibrator
depends on TWL4030_CORE
- select TWL4030_CODEC
+ select MFD_TWL4030_AUDIO
select INPUT_FF_MEMLESS
help
This option enables support for TWL4030 Vibrator Driver.
diff --git a/drivers/input/misc/twl4030-vibra.c
b/drivers/input/misc/twl4030-vibra.c
index 014dd4a..7abca85 100644
--- a/drivers/input/misc/twl4030-vibra.c
+++ b/drivers/input/misc/twl4030-vibra.c
@@ -28,7 +28,7 @@
#include linux/platform_device.h
#include linux/workqueue.h
#include linux/i2c/twl.h
-#include linux/mfd/twl4030-codec.h
+#include linux/mfd/twl4030-audio.h
#include linux/input.h
#include linux/slab.h
@@ -67,7 +67,7 @@ static void vibra_enable(struct vibra_info *info)
{
u8 reg;
- twl4030_codec_enable_resource(TWL4030_CODEC_RES_POWER);
+ twl4030_audio_enable_resource(TWL4030_AUDIO_RES_POWER);
/* turn H-Bridge on */
twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE,
@@ -75,7 +75,7 @@ static void vibra_enable(struct vibra_info *info)
twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
(reg | TWL4030_VIBRA_EN), TWL4030_REG_VIBRA_CTL);
- twl4030_codec_enable_resource(TWL4030_CODEC_RES_APLL);
+ twl4030_audio_enable_resource(TWL4030_AUDIO_RES_APLL);
info-enabled = true;
}
@@ -90,8 +90,8 @@ static void vibra_disable(struct vibra_info *info)
twl_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
(reg ~TWL4030_VIBRA_EN), TWL4030_REG_VIBRA_CTL);
- twl4030_codec_disable_resource(TWL4030_CODEC_RES_APLL);
- twl4030_codec_disable_resource(TWL4030_CODEC_RES_POWER);
+ twl4030_audio_disable_resource(TWL4030_AUDIO_RES_APLL);
+ twl4030_audio_disable_resource(TWL4030_AUDIO_RES_POWER);
info-enabled = false;
}
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0f09c05..3a6f76a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -218,7 +218,7 @@ config TWL4030_POWER
and load scripts controlling which resources are switched off/on
or reset when a sleep, wakeup or warm reset event occurs.
-config TWL4030_CODEC
+config MFD_TWL4030_AUDIO
bool
depends on TWL4030_CORE
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index efe3cc3..4cf9465 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -40,7 +40,7 @@ obj-$(CONFIG_MENELAUS)+= menelaus.o
obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
-obj-$(CONFIG_TWL4030_CODEC)+= twl4030-codec.o
+obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
obj-$(CONFIG_TWL6030_PWM) += twl6030-pwm.o
obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
new file mode 100644
index 000..467ddb8
--- /dev/null
+++ b/drivers/mfd/twl4030-audio.c
@@ -0,0 +1,278 @@
+/*
+ * MFD driver for twl4030 audio submodule, which contains an audio codec, and
+ * the vibra control.
+ *
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * Copyright: (C) 2009 Nokia Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied
Re: [PATCH 1/2] OMAP: gpmc-smsc911x: always set irq flags to IORESOURCE_IRQ_LOWLEVEL
On 05/31/11 13:32, Tony Lindgren wrote: * Mike Rapoport m...@compulab.co.il [110416 15:20]: SMSC911x devices attached to OMAP GPMC always use low level irqs. Setting the appropriate flag in the irq resourse strucure allows using .flags field in the omap_smsc911x_platform_data for driver specific flags Looks like this one needs to be refreshed against v3.0-rc1. Both patches are already in v3.0-rc1... Working late? ;) -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: gpmc-smsc911x: always set irq flags to IORESOURCE_IRQ_LOWLEVEL
* Igor Grinberg grinb...@compulab.co.il [110601 04:29]: On 05/31/11 13:32, Tony Lindgren wrote: * Mike Rapoport m...@compulab.co.il [110416 15:20]: SMSC911x devices attached to OMAP GPMC always use low level irqs. Setting the appropriate flag in the irq resourse strucure allows using .flags field in the omap_smsc911x_platform_data for driver specific flags Looks like this one needs to be refreshed against v3.0-rc1. Both patches are already in v3.0-rc1... Working late? ;) That explains, maybe it's time for me to go to the back room and take a nap :) I was using both patchwork and my mailbox as patchwork was missing some patches and did not allow login yesterday.. 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 1/2] ARM: OMAP4: MMC: increase delay for pbias
* Balaji T K balaj...@ti.com [110601 04:13]: 4 micro seconds is not enough for PBIAS if MMC regulator is enabled from MMC regulator OFF. Increase the delay for PBIAS to stabilize. Wait for PBIAS and timeout if not. Resolves MMC/SD failure on OMAP4 Pbias Voltage is not same as LDO Thanks for updating this, applying to devel-fixes. 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 3/8] MFD: twl4030-audio: Rename platform data
* Peter Ujfalusi peter.ujfal...@ti.com [110601 04:14]:
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -463,11 +463,11 @@ static struct regulator_init_data sdp3430_vpll2 = {
.consumer_supplies = sdp3430_vpll2_supplies,
};
-static struct twl4030_codec_audio_data sdp3430_audio;
+static struct twl4030_codec_data sdp3430_codec;
-static struct twl4030_codec_data sdp3430_codec = {
+static struct twl4030_audio_data sdp3430_audio = {
.audio_mclk = 2600,
- .audio = sdp3430_audio,
+ .codec = sdp3430_codec,
};
static struct twl4030_platform_data sdp3430_twldata = {
@@ -480,7 +480,7 @@ static struct twl4030_platform_data sdp3430_twldata = {
.madc = sdp3430_madc_data,
.keypad = sdp3430_kp_data,
.usb= sdp3430_usb_data,
- .codec = sdp3430_codec,
+ .audio = sdp3430_audio,
.vaux1 = sdp3430_vaux1,
.vaux2 = sdp3430_vaux2,
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -337,11 +337,11 @@ static struct twl4030_usb_data devkit8000_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
-static struct twl4030_codec_audio_data devkit8000_audio_data;
+static struct twl4030_codec_data devkit8000_codec_data;
-static struct twl4030_codec_data devkit8000_codec_data = {
+static struct twl4030_audio_data devkit8000_audio_data = {
.audio_mclk = 2600,
- .audio = devkit8000_audio_data,
+ .codec = devkit8000_codec_data,
};
static struct twl4030_platform_data devkit8000_twldata = {
@@ -351,7 +351,7 @@ static struct twl4030_platform_data devkit8000_twldata = {
/* platform_data for children goes here */
.usb= devkit8000_usb_data,
.gpio = devkit8000_gpio_data,
- .codec = devkit8000_codec_data,
+ .audio = devkit8000_audio_data,
.vmmc1 = devkit8000_vmmc1,
.vdac = devkit8000_vdac,
.vpll1 = devkit8000_vpll1,
...
Can you please take a look at creating arch/arm/mach-omap2/i2c-twl.c or
something in common-board-devices.c to get rid of the cut and paste
duplication in every board-*.c file?
Maybe you could have a generic twl_init function that allows overriding
things like keypad with board specific configuration?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] omap3: iovmm: Support non page-aligned buffers in iommu_vmap
The IOMMU virtual memory mapping API requires page-aligned buffers.
There's no hardware reason behind such a restriction. Remove it by
rounding the address of the first page entry down, and adding the offset
back to the IOMMU virtual address.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index b82cef4..fa5ae98 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -60,6 +60,15 @@
static struct kmem_cache *iovm_area_cachep;
+/* return the offset of the first scatterlist entry in a sg table */
+static unsigned int sgtable_offset(const struct sg_table *sgt)
+{
+ if (!sgt || !sgt-nents)
+ return 0;
+
+ return sgt-sgl-offset;
+}
+
/* return total bytes of sg buffers */
static size_t sgtable_len(const struct sg_table *sgt)
{
@@ -72,11 +81,17 @@ static size_t sgtable_len(const struct sg_table *sgt)
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
size_t bytes;
- bytes = sg_dma_len(sg);
+ bytes = sg_dma_len(sg) + sg-offset;
if (!iopgsz_ok(bytes)) {
- pr_err(%s: sg[%d] not iommu pagesize(%x)\n,
- __func__, i, bytes);
+ pr_err(%s: sg[%d] not iommu pagesize(%u %u)\n,
+ __func__, i, bytes, sg-offset);
+ return 0;
+ }
+
+ if (i sg-offset) {
+ pr_err(%s: sg[%d] offset not allowed in internal
+ entries\n, __func__, i);
return 0;
}
@@ -207,8 +222,8 @@ static void *vmap_sg(const struct sg_table *sgt)
u32 pa;
int err;
- pa = sg_phys(sg);
- bytes = sg_dma_len(sg);
+ pa = sg_phys(sg) - sg-offset;
+ bytes = sg_dma_len(sg) + sg-offset;
BUG_ON(bytes != PAGE_SIZE);
@@ -485,8 +500,8 @@ static int map_iovm_area(struct iommu *obj, struct
iovm_struct *new,
size_t bytes;
struct iotlb_entry e;
- pa = sg_phys(sg);
- bytes = sg_dma_len(sg);
+ pa = sg_phys(sg) - sg-offset;
+ bytes = sg_dma_len(sg) + sg-offset;
flags = ~IOVMF_PGSZ_MASK;
pgsz = bytes_to_iopgsz(bytes);
@@ -666,7 +681,7 @@ u32 iommu_vmap(struct iommu *obj, u32 da, const struct
sg_table *sgt,
if (IS_ERR_VALUE(da))
vunmap_sg(va);
- return da;
+ return da + sgtable_offset(sgt);
}
EXPORT_SYMBOL_GPL(iommu_vmap);
@@ -685,6 +700,7 @@ struct sg_table *iommu_vunmap(struct iommu *obj, u32 da)
* 'sgt' is allocated before 'iommu_vmalloc()' is called.
* Just returns 'sgt' to the caller to free
*/
+ da = PAGE_MASK;
sgt = unmap_vm_area(obj, da, vunmap_sg, IOVMF_DISCONT | IOVMF_MMIO);
if (!sgt)
dev_dbg(obj-dev, %s: No sgt\n, __func__);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
sg_alloc_table can only allocate multi-page scatter-gather list tables
if the architecture supports scatter-gather lists chaining. ARM doesn't
fit in that category.
The IOMMU driver abuses the sg table structure only to hold page
addresses without ever passing the table to the device.
Use __sg_alloc_table instead of sg_alloc_table and allocate all entries
in one go. Otherwise trying to use a large userspace to capture video
will hit a BUG_ON in __sg_alloc_table.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 51ef43e..b82cef4 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -121,6 +121,16 @@ static unsigned sgtable_nents(size_t bytes, u32 da, u32 pa)
return nr_entries;
}
+static struct scatterlist *sg_alloc(unsigned int nents, gfp_t gfp_mask)
+{
+ return kmalloc(nents * sizeof(struct scatterlist), gfp_mask);
+}
+
+static void sg_free(struct scatterlist *sg, unsigned int nents)
+{
+ kfree(sg);
+}
+
/* allocate and initialize sg_table header(a kind of 'superblock') */
static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags,
u32 da, u32 pa)
@@ -146,7 +156,7 @@ static struct sg_table *sgtable_alloc(const size_t bytes,
u32 flags,
if (!sgt)
return ERR_PTR(-ENOMEM);
- err = sg_alloc_table(sgt, nr_entries, GFP_KERNEL);
+ err = __sg_alloc_table(sgt, nr_entries, -1, GFP_KERNEL, sg_alloc);
if (err) {
kfree(sgt);
return ERR_PTR(err);
@@ -163,7 +173,7 @@ static void sgtable_free(struct sg_table *sgt)
if (!sgt)
return;
- sg_free_table(sgt);
+ __sg_free_table(sgt, -1, sg_free);
kfree(sgt);
pr_debug(%s: sgt:%p\n, __func__, sgt);
--
1.7.3.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 v2 2/2] omap3: iovmm: Support non page-aligned buffers in iommu_vmap
* Laurent Pinchart laurent.pinch...@ideasonboard.com [110601 05:21]: The IOMMU virtual memory mapping API requires page-aligned buffers. There's no hardware reason behind such a restriction. Remove it by rounding the address of the first page entry down, and adding the offset back to the IOMMU virtual address. Does this one also fix some bug? 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 3/8] MFD: twl4030-audio: Rename platform data
On Wednesday 01 June 2011 15:07:54 Tony Lindgren wrote: Can you please take a look at creating arch/arm/mach-omap2/i2c-twl.c or something in common-board-devices.c to get rid of the cut and paste duplication in every board-*.c file? Yes, it would make sense, since most of the board has similar configuration, and we have lots of duplicated code around. Maybe you could have a generic twl_init function that allows overriding things like keypad with board specific configuration? We might need also support for overriding other configurations (audio/codec/vibra for sure needs that). I'll take a look, but I think it is not going to be part of v2 of this series. -- Péter -- 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 3/8] MFD: twl4030-audio: Rename platform data
* Peter Ujfalusi peter.ujfal...@ti.com [110601 05:50]: On Wednesday 01 June 2011 15:07:54 Tony Lindgren wrote: Can you please take a look at creating arch/arm/mach-omap2/i2c-twl.c or something in common-board-devices.c to get rid of the cut and paste duplication in every board-*.c file? Yes, it would make sense, since most of the board has similar configuration, and we have lots of duplicated code around. Maybe you could have a generic twl_init function that allows overriding things like keypad with board specific configuration? We might need also support for overriding other configurations (audio/codec/vibra for sure needs that). Yeah, most of it might be possible to describe with just a flags like TWL_HAS_VIBRA etc. I'll take a look, but I think it is not going to be part of v2 of this series. We should not do renaming before the clean-up though, it gets classified as unnecesary churn. 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 2/2] omap3: iovmm: Support non page-aligned buffers in iommu_vmap
On Wednesday 01 June 2011 14:50:24 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [110601 05:21]: The IOMMU virtual memory mapping API requires page-aligned buffers. There's no hardware reason behind such a restriction. Remove it by rounding the address of the first page entry down, and adding the offset back to the IOMMU virtual address. Does this one also fix some bug? Yes, but no oops. It fixes an OMAP3 ISP failure when the buffer passed from userspace is not page-aligned. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] omap3: iovmm: Support non page-aligned buffers in iommu_vmap
* Laurent Pinchart laurent.pinch...@ideasonboard.com [110601 06:04]: On Wednesday 01 June 2011 14:50:24 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [110601 05:21]: The IOMMU virtual memory mapping API requires page-aligned buffers. There's no hardware reason behind such a restriction. Remove it by rounding the address of the first page entry down, and adding the offset back to the IOMMU virtual address. Does this one also fix some bug? Yes, but no oops. It fixes an OMAP3 ISP failure when the buffer passed from userspace is not page-aligned. OK, thanks. I'll update the description with that and apply both to devel-fixes. 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 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
* Laurent Pinchart laurent.pinch...@ideasonboard.com [110601 05:21]: sg_alloc_table can only allocate multi-page scatter-gather list tables if the architecture supports scatter-gather lists chaining. ARM doesn't fit in that category. The IOMMU driver abuses the sg table structure only to hold page addresses without ever passing the table to the device. Use __sg_alloc_table instead of sg_alloc_table and allocate all entries in one go. Otherwise trying to use a large userspace to capture video will hit a BUG_ON in __sg_alloc_table. Is the large userspace above missing a word like buffer? 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 3/8] MFD: twl4030-audio: Rename platform data
On Wednesday 01 June 2011 16:00:34 Tony Lindgren wrote: Yeah, most of it might be possible to describe with just a flags like TWL_HAS_VIBRA etc. Or TWL_BOARD_HAS_VIBRA, TWL_BOARD_HAS_CODEC... For the audio part it is a bit complicated than that: different base frequencies, for twl6040 we have parameters for Vibra (twl4030 class only have the coexistence). The soc codec has a list of misc parameters for board specific configurations as well (not all board using them). I was thinking to switch the MFD driver(s) to use flags to specify the needed child, and change the child drivers to deal with the missing platform data themselves. In that way, board files can pass the vibra/codec platform data to the new i2c_twl file for example, and provide flags to enable functionality. I'll take a look, but I think it is not going to be part of v2 of this series. We should not do renaming before the clean-up though, it gets classified as unnecesary churn. The changes in board files are minimal. The biggest part is the code move, and that will remain the same now or later... -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] omap3: iovmm: Support non page-aligned buffers in iommu_vmap
* Tony Lindgren t...@atomide.com [110601 06:07]: * Laurent Pinchart laurent.pinch...@ideasonboard.com [110601 06:04]: On Wednesday 01 June 2011 14:50:24 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [110601 05:21]: The IOMMU virtual memory mapping API requires page-aligned buffers. There's no hardware reason behind such a restriction. Remove it by rounding the address of the first page entry down, and adding the offset back to the IOMMU virtual address. Does this one also fix some bug? Yes, but no oops. It fixes an OMAP3 ISP failure when the buffer passed from userspace is not page-aligned. OK, thanks. I'll update the description with that and apply both to devel-fixes. Oops not quite. Please repost one more time with linux-arm-kernel also Cc'd for review. Otherwise I have to repost them before merging.. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] mfd: global Suspend and resume support of ehci and ohci
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and resume occurs. Before calling these functions, the
bus suspend and resume of ehci and ohci drivers are called
from runtime pm.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/mfd/omap-usb-host.c | 103 +++
1 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 43de12a..32d19e2 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -146,6 +146,10 @@
#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)
+/* USBHS state bits */
+#define OMAP_USBHS_INIT0
+#define OMAP_USBHS_SUSPEND 4
+
struct usbhs_hcd_omap {
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
@@ -165,6 +169,7 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
int count;
+ unsigned long state;
};
/*-*/
@@ -809,6 +814,8 @@ static int usbhs_enable(struct device *dev)
(pdata-ehci_data-reset_gpio_port[1], 1);
}
+ set_bit(OMAP_USBHS_INIT, omap-state);
+
end_count:
omap-count++;
spin_unlock_irqrestore(omap-lock, flags);
@@ -897,6 +904,7 @@ static void usbhs_disable(struct device *dev)
}
pm_runtime_put_sync(dev);
+ clear_bit(OMAP_USBHS_INIT, omap-state);
/* The gpio_free migh sleep; so unlock the spinlock */
spin_unlock_irqrestore(omap-lock, flags);
@@ -926,10 +934,105 @@ void omap_usbhs_disable(struct device *dev)
}
EXPORT_SYMBOL_GPL(omap_usbhs_disable);
+#ifdef CONFIG_PM
+
+static int usbhs_resume(struct device *dev)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ struct usbhs_omap_platform_data *pdata = omap-platdata;
+ unsigned long flags = 0;
+
+ dev_dbg(dev, Resuming TI HSUSB Controller\n);
+
+ if (!pdata) {
+ dev_dbg(dev, missing platform_data\n);
+ return -ENODEV;
+ }
+
+ spin_lock_irqsave(omap-lock, flags);
+
+ if (!test_bit(OMAP_USBHS_INIT, omap-state) ||
+ !test_bit(OMAP_USBHS_SUSPEND, omap-state))
+ goto end_resume;
+
+ pm_runtime_get_sync(dev);
+
+ if (is_omap_usbhs_rev2(omap)) {
+ if (is_ehci_tll_mode(pdata-port_mode[0])) {
+ clk_enable(omap-usbhost_p1_fck);
+ clk_enable(omap-usbtll_p1_fck);
+ }
+ if (is_ehci_tll_mode(pdata-port_mode[1])) {
+ clk_enable(omap-usbhost_p2_fck);
+ clk_enable(omap-usbtll_p2_fck);
+ }
+ clk_enable(omap-utmi_p1_fck);
+ clk_enable(omap-utmi_p2_fck);
+ }
+ clear_bit(OMAP_USBHS_SUSPEND, omap-state);
+
+end_resume:
+ spin_unlock_irqrestore(omap-lock, flags);
+ return 0;
+}
+
+
+static int usbhs_suspend(struct device *dev)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ struct usbhs_omap_platform_data *pdata = omap-platdata;
+ unsigned long flags = 0;
+
+ dev_dbg(dev, Suspending TI HSUSB Controller\n);
+
+ if (!pdata) {
+ dev_dbg(dev, missing platform_data\n);
+ return -ENODEV;
+ }
+
+ spin_lock_irqsave(omap-lock, flags);
+
+ if (!test_bit(OMAP_USBHS_INIT, omap-state) ||
+ test_bit(OMAP_USBHS_SUSPEND, omap-state))
+ goto end_suspend;
+
+ if (is_omap_usbhs_rev2(omap)) {
+ if (is_ehci_tll_mode(pdata-port_mode[0])) {
+ clk_disable(omap-usbhost_p1_fck);
+ clk_disable(omap-usbtll_p1_fck);
+ }
+ if (is_ehci_tll_mode(pdata-port_mode[1])) {
+ clk_disable(omap-usbhost_p2_fck);
+ clk_disable(omap-usbtll_p2_fck);
+ }
+ clk_disable(omap-utmi_p2_fck);
+ clk_disable(omap-utmi_p1_fck);
+ }
+
+ set_bit(OMAP_USBHS_SUSPEND, omap-state);
+ pm_runtime_put_sync(dev);
+
+end_suspend:
+ spin_unlock_irqrestore(omap-lock, flags);
+ return 0;
+}
+
+
+static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
+ .suspend= usbhs_suspend,
+ .resume = usbhs_resume,
+};
+
+#define USBHS_OMAP_DEV_PM_OPS (usbhsomap_dev_pm_ops)
+#else
+#defineUSBHS_OMAP_DEV_PM_OPS NULL
+#endif
+
static struct platform_driver usbhs_omap_driver = {
.driver = {
[PATCH 2/4] arm: omap: usb: register hwmods of usbhs
The hwmod structure of uhh and tll are retrived
and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 99 ++--
1 files changed, 35 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 89ae298..9d762c4 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -28,51 +28,28 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include plat/omap_device.h
#include mux.h
#ifdef CONFIG_MFD_OMAP_USB_HOST
-#define OMAP_USBHS_DEVICE usbhs-omap
-
-static struct resource usbhs_resources[] = {
- {
- .name = uhh,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = tll,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci-irq,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = ohci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ohci-irq,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device usbhs_device = {
- .name = OMAP_USBHS_DEVICE,
- .id = 0,
- .num_resources = ARRAY_SIZE(usbhs_resources),
- .resource = usbhs_resources,
-};
+#define OMAP_USBHS_DEVICE usbhs_omap
+#defineUSBHS_UHH_HWMODNAME usbhs_uhh
+#define USBHS_TLL_HWMODNAMEusbhs_tll
static struct usbhs_omap_platform_data usbhs_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
+static struct omap_device_pm_latency omap_uhhtll_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
/* MUX settings for EHCI pins */
/*
* setup_ehci_io_mux - initialize IO pad mux for USBHOST
@@ -508,7 +485,10 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- int i;
+ struct omap_hwmod *oh[2];
+ struct omap_device *od;
+ int bus_id = -1;
+ int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
@@ -523,44 +503,35 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
- usbhs_resources[0].start = OMAP34XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP34XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start= OMAP34XX_EHCI_BASE;
- usbhs_resources[2].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = INT_34XX_EHCI_IRQ;
- usbhs_resources[4].start= OMAP34XX_OHCI_BASE;
- usbhs_resources[4].end = OMAP34XX_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = INT_34XX_OHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
} else if (cpu_is_omap44xx()) {
- usbhs_resources[0].start = OMAP44XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP44XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP44XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP44XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start = OMAP44XX_HSUSB_EHCI_BASE;
- usbhs_resources[2].end = OMAP44XX_HSUSB_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = OMAP44XX_IRQ_EHCI;
- usbhs_resources[4].start = OMAP44XX_HSUSB_OHCI_BASE;
- usbhs_resources[4].end = OMAP44XX_HSUSB_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = OMAP44XX_IRQ_OHCI;
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
}
- if (platform_device_add_data(usbhs_device,
- usbhs_data, sizeof(usbhs_data)) 0) {
- printk(KERN_ERR USBHS platform_device_add_data failed\n);
- goto init_end;
+ oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!oh[0]) {
+ pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
+ return;
}
- if (platform_device_register(usbhs_device) 0)
-
[PATCH 3/4] arm: omap: usb: device name change for the clk names of usbhs
From: Keshava Munegowda keshava_mgo...@ti.com
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 28 ++--
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
drivers/mfd/omap-usb-host.c |2 +-
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 75b119b..fabe482 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3285,7 +3285,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3321,7 +3321,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3367,20 +3367,20 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cam_ick, cam_ick, CK_34XX | CK_36XX),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_34XX | CK_36XX),
CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, hs_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, hs_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, fs_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, fs_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
[PATCH 0/4] arm: omap: usb: Hwmod and Runtime PM support for EHCI OHCI
From: Keshava Munegowda keshava_mgo...@ti.com These set of patches - defines the hwmod structures of ehci and ohci of omap3 and omap4 socs. - Implements the Run time pm - global suspend/resume of EHCI and OHCI Since, existing omap usbhs core driver of v3.0-rc1 release uses the run time PM APIs, these patches enables the ehci and ohci functionalaties. Keshava Munegowda (4): arm: omap: usb: ehci and ohci hwmod structures for omap3 and omap4 arm: omap: usb: register hwmods of usbhs arm: omap: usb: device name change for the clk names of usbhs mfd: global Suspend and resume support of ehci and ohci arch/arm/mach-omap2/clock3xxx_data.c | 28 ++-- arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 184 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 153 +++ arch/arm/mach-omap2/usb-host.c | 99 ++-- drivers/mfd/omap-usb-host.c| 105 - 6 files changed, 495 insertions(+), 84 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/4] arm: omap: usb: ehci and ohci hwmod structures for omap3 and omap4
Following 2 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and
EHCI , OHCI irq and base addresses.
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 184
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 153 +++
2 files changed, 337 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 909a84d..fe9a176 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3574,6 +3576,185 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 },
+ { .name = ehci-irq, .irq = 77 },
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x48064400,
+ .pa_end = 0x480647FF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x48064800,
+ .pa_end = 0x48064CFF,
+ .flags = ADDR_MAP_ON_INIT
+ }
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_host_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_irqs),
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt=
[PATCH v3 2/2] omap3: iovmm: Support non page-aligned buffers in iommu_vmap
The IOMMU virtual memory mapping API requires page-aligned buffers.
There's no hardware reason behind such a restriction. Remove it by
rounding the address of the first page entry down, and adding the offset
back to the IOMMU virtual address.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index b82cef4..fa5ae98 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -60,6 +60,15 @@
static struct kmem_cache *iovm_area_cachep;
+/* return the offset of the first scatterlist entry in a sg table */
+static unsigned int sgtable_offset(const struct sg_table *sgt)
+{
+ if (!sgt || !sgt-nents)
+ return 0;
+
+ return sgt-sgl-offset;
+}
+
/* return total bytes of sg buffers */
static size_t sgtable_len(const struct sg_table *sgt)
{
@@ -72,11 +81,17 @@ static size_t sgtable_len(const struct sg_table *sgt)
for_each_sg(sgt-sgl, sg, sgt-nents, i) {
size_t bytes;
- bytes = sg_dma_len(sg);
+ bytes = sg_dma_len(sg) + sg-offset;
if (!iopgsz_ok(bytes)) {
- pr_err(%s: sg[%d] not iommu pagesize(%x)\n,
- __func__, i, bytes);
+ pr_err(%s: sg[%d] not iommu pagesize(%u %u)\n,
+ __func__, i, bytes, sg-offset);
+ return 0;
+ }
+
+ if (i sg-offset) {
+ pr_err(%s: sg[%d] offset not allowed in internal
+ entries\n, __func__, i);
return 0;
}
@@ -207,8 +222,8 @@ static void *vmap_sg(const struct sg_table *sgt)
u32 pa;
int err;
- pa = sg_phys(sg);
- bytes = sg_dma_len(sg);
+ pa = sg_phys(sg) - sg-offset;
+ bytes = sg_dma_len(sg) + sg-offset;
BUG_ON(bytes != PAGE_SIZE);
@@ -485,8 +500,8 @@ static int map_iovm_area(struct iommu *obj, struct
iovm_struct *new,
size_t bytes;
struct iotlb_entry e;
- pa = sg_phys(sg);
- bytes = sg_dma_len(sg);
+ pa = sg_phys(sg) - sg-offset;
+ bytes = sg_dma_len(sg) + sg-offset;
flags = ~IOVMF_PGSZ_MASK;
pgsz = bytes_to_iopgsz(bytes);
@@ -666,7 +681,7 @@ u32 iommu_vmap(struct iommu *obj, u32 da, const struct
sg_table *sgt,
if (IS_ERR_VALUE(da))
vunmap_sg(va);
- return da;
+ return da + sgtable_offset(sgt);
}
EXPORT_SYMBOL_GPL(iommu_vmap);
@@ -685,6 +700,7 @@ struct sg_table *iommu_vunmap(struct iommu *obj, u32 da)
* 'sgt' is allocated before 'iommu_vmalloc()' is called.
* Just returns 'sgt' to the caller to free
*/
+ da = PAGE_MASK;
sgt = unmap_vm_area(obj, da, vunmap_sg, IOVMF_DISCONT | IOVMF_MMIO);
if (!sgt)
dev_dbg(obj-dev, %s: No sgt\n, __func__);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
sg_alloc_table can only allocate multi-page scatter-gather list tables
if the architecture supports scatter-gather lists chaining. ARM doesn't
fit in that category.
The IOMMU driver abuses the sg table structure only to hold page
addresses without ever passing the table to the device.
Use __sg_alloc_table instead of sg_alloc_table and allocate all entries
in one go. Otherwise trying to use a large userspace buffers to capture
video will hit a BUG_ON in __sg_alloc_table.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 51ef43e..b82cef4 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -121,6 +121,16 @@ static unsigned sgtable_nents(size_t bytes, u32 da, u32 pa)
return nr_entries;
}
+static struct scatterlist *sg_alloc(unsigned int nents, gfp_t gfp_mask)
+{
+ return kmalloc(nents * sizeof(struct scatterlist), gfp_mask);
+}
+
+static void sg_free(struct scatterlist *sg, unsigned int nents)
+{
+ kfree(sg);
+}
+
/* allocate and initialize sg_table header(a kind of 'superblock') */
static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags,
u32 da, u32 pa)
@@ -146,7 +156,7 @@ static struct sg_table *sgtable_alloc(const size_t bytes,
u32 flags,
if (!sgt)
return ERR_PTR(-ENOMEM);
- err = sg_alloc_table(sgt, nr_entries, GFP_KERNEL);
+ err = __sg_alloc_table(sgt, nr_entries, -1, GFP_KERNEL, sg_alloc);
if (err) {
kfree(sgt);
return ERR_PTR(err);
@@ -163,7 +173,7 @@ static void sgtable_free(struct sg_table *sgt)
if (!sgt)
return;
- sg_free_table(sgt);
+ __sg_free_table(sgt, -1, sg_free);
kfree(sgt);
pr_debug(%s: sgt:%p\n, __func__, sgt);
--
1.7.3.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 4/4] mfd: global Suspend and resume support of ehci and ohci
Hi, On Wed, Jun 01, 2011 at 06:57:27PM +0530, Keshava Munegowda wrote: diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index 43de12a..32d19e2 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -146,6 +146,10 @@ #define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC) +/* USBHS state bits */ +#define OMAP_USBHS_INIT 0 +#define OMAP_USBHS_SUSPEND 4 #define OMAP_USBHS_INIT BIT(0) #define OMAP_USBHS_SUSPEND BIT(1) ??? -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/8] MFD: twl4030-audio: Rename platform data
* Peter Ujfalusi peter.ujfal...@ti.com [110601 06:13]: On Wednesday 01 June 2011 16:00:34 Tony Lindgren wrote: Yeah, most of it might be possible to describe with just a flags like TWL_HAS_VIBRA etc. Or TWL_BOARD_HAS_VIBRA, TWL_BOARD_HAS_CODEC... For the audio part it is a bit complicated than that: different base frequencies, for twl6040 we have parameters for Vibra (twl4030 class only have the coexistence). The soc codec has a list of misc parameters for board specific configurations as well (not all board using them). I was thinking to switch the MFD driver(s) to use flags to specify the needed child, and change the child drivers to deal with the missing platform data themselves. In that way, board files can pass the vibra/codec platform data to the new i2c_twl file for example, and provide flags to enable functionality. OK, sounds doable. I'll take a look, but I think it is not going to be part of v2 of this series. We should not do renaming before the clean-up though, it gets classified as unnecesary churn. The changes in board files are minimal. The biggest part is the code move, and that will remain the same now or later... But you could easily remove all the board specific struct twl4030_codec_data and struct twl4030_codec_audio_data entries by adding a default audio init option to omap_pmic_init for the common configuration. How about something like: void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int pmic_irq, struct twl4030_platform_data *pmic_data, u32 flags); Where flags would be TWL_BOARD_HAS_DEFAULT_CODEC etc, and if the entry in pmic_data is NULL, just use the default configuration. I think you already have the clkrate there? 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 4/4] mfd: global Suspend and resume support of ehci and ohci
On Wed, Jun 1, 2011 at 7:01 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Jun 01, 2011 at 06:57:27PM +0530, Keshava Munegowda wrote: diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index 43de12a..32d19e2 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -146,6 +146,10 @@ #define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC) +/* USBHS state bits */ +#define OMAP_USBHS_INIT 0 +#define OMAP_USBHS_SUSPEND 4 #define OMAP_USBHS_INIT BIT(0) #define OMAP_USBHS_SUSPEND BIT(1) ??? yes, I will do.. please comment on other patches too keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
On Wed, Jun 01, 2011 at 03:30:11PM +0200, Laurent Pinchart wrote: sg_alloc_table can only allocate multi-page scatter-gather list tables if the architecture supports scatter-gather lists chaining. ARM doesn't fit in that category. Let's fix this properly, as I've said countless times and so far no one has bothered to sort this out: 8 From: Russell King rmk+ker...@arm.linux.org.uk Subject: ARM: Allow SoCs to enable scatterlist chaining Allow SoCs to enable the scatterlist chaining support, which allows scatterlist tables to be broken up into smaller allocations. As support for this feature depends on the implementation details of the users of the scatterlists, we can't enable this globally without auditing all the users, which is a very big task. Instead, let SoCs progressively switch over to using this. SoC drivers using scatterlists and SoC DMA implementations need auditing before this option can be enabled for the SoC. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/Kconfig |3 +++ arch/arm/include/asm/scatterlist.h |4 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9adc278..cc0dcbf 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -37,6 +37,9 @@ config ARM Europe. There is an ARM Linux project with a web page at http://www.arm.linux.org.uk/. +config ARM_HAS_SG_CHAIN + bool + config HAVE_PWM bool diff --git a/arch/arm/include/asm/scatterlist.h b/arch/arm/include/asm/scatterlist.h index 2f87870..cefdb8f 100644 --- a/arch/arm/include/asm/scatterlist.h +++ b/arch/arm/include/asm/scatterlist.h @@ -1,6 +1,10 @@ #ifndef _ASMARM_SCATTERLIST_H #define _ASMARM_SCATTERLIST_H +#ifdef CONFIG_ARM_HAS_SG_CHAIN +#define ARCH_HAS_SG_CHAIN +#endif + #include asm/memory.h #include asm/types.h #include asm-generic/scatterlist.h -- 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 4/8] mfd: twl6040: Add initial support
On Wed, Jun 1, 2011 at 4:47 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
From: Misael Lopez Cruz misael.lo...@ti.com
TWL6040 IC provides analog high-end audio codec functions for
handset applications. It contains several audio analog inputs
and outputs as well as vibrator support. It's connected to the
host processor via PDM interface for audio data communication.
The audio modules are controlled by internal registers that
can be accessed by I2C and PDM interface.
TWL6040 MFD will be registered as a child of TWL-CORE, and will
have two children of its own: twl6040-codec and twl6040-vibra.
This driver is based on TWL4030 and WM8350 MFD drivers.
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/include/plat/irqs.h | 12 +-
drivers/mfd/Kconfig | 6 +
drivers/mfd/Makefile | 1 +
drivers/mfd/twl-core.c | 5 +-
drivers/mfd/twl6040-core.c | 589
drivers/mfd/twl6040-irq.c | 205 +++
include/linux/i2c/twl.h | 1 +
include/linux/mfd/twl6040.h | 260 ++
8 files changed, 1074 insertions(+), 5 deletions(-)
create mode 100644 drivers/mfd/twl6040-core.c
create mode 100644 drivers/mfd/twl6040-irq.c
create mode 100644 include/linux/mfd/twl6040.h
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 5a25098..2cfba51 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -407,11 +407,19 @@
#endif
#define TWL6030_IRQ_END (TWL6030_IRQ_BASE +
TWL6030_BASE_NR_IRQS)
+#define TWL6040_CODEC_IRQ_BASE TWL6030_IRQ_END
+#ifdef CONFIG_TWL6040_CODEC
+#define TWL6040_CODEC_NR_IRQS 6
+#else
+#define TWL6040_CODEC_NR_IRQS 0
+#endif
+#define TWL6040_CODEC_IRQ_END (TWL6040_CODEC_IRQ_BASE +
TWL6040_CODEC_NR_IRQS)
+
/* Total number of interrupts depends on the enabled blocks above */
-#if (TWL4030_GPIO_IRQ_END TWL6030_IRQ_END)
+#if (TWL4030_GPIO_IRQ_END TWL6040_CODEC_IRQ_END)
#define TWL_IRQ_END TWL4030_GPIO_IRQ_END
#else
-#define TWL_IRQ_END TWL6030_IRQ_END
+#define TWL_IRQ_END TWL6040_CODEC_IRQ_END
#endif
/* GPMC related */
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3a6f76a..ac6b4ae 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -233,6 +233,12 @@ config TWL6030_PWM
Say yes here if you want support for TWL6030 PWM.
This is used to control charging LED brightness.
+config TWL6040_CORE
+ bool
+ depends on TWL4030_CORE GENERIC_HARDIRQS
+ select MFD_CORE
+ default n
+
config MFD_STMPE
bool Support STMicroelectronics STMPE
depends on I2C=y GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4cf9465..41f3b61 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL4030_POWER) += twl4030-power.o
obj-$(CONFIG_MFD_TWL4030_AUDIO) += twl4030-audio.o
obj-$(CONFIG_TWL6030_PWM) += twl6030-pwm.o
+obj-$(CONFIG_TWL6040_CORE) += twl6040-core.o twl6040-irq.o
obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index f9d7880..a2eddc7 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -110,7 +110,7 @@
#endif
#if defined(CONFIG_TWL4030_CODEC) || defined(CONFIG_TWL4030_CODEC_MODULE) ||\
- defined(CONFIG_SND_SOC_TWL6040) ||
defined(CONFIG_SND_SOC_TWL6040_MODULE)
+ defined(CONFIG_TWL6040_CORE) || defined(CONFIG_TWL6040_CORE_MODULE)
#define twl_has_codec() true
#else
#define twl_has_codec() false
@@ -824,10 +824,9 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
return PTR_ERR(child);
}
- /* Phoenix codec driver is probed directly atm */
if (twl_has_codec() pdata-audio twl_class_is_6030()) {
sub_chip_id = twl_map[TWL_MODULE_AUDIO_VOICE].sid;
- child = add_child(sub_chip_id, twl6040-codec,
+ child = add_child(sub_chip_id, twl6040,
pdata-audio, sizeof(*pdata-audio),
false, 0, 0);
if (IS_ERR(child))
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
new file mode 100644
index 000..bb36862
--- /dev/null
+++ b/drivers/mfd/twl6040-core.c
@@ -0,0 +1,589 @@
+/*
+ * MFD driver for TWL6040 audio device
+ *
+ * Authors: Misael Lopez Cruz misael.lo...@ti.com
+ * Jorge
Re: [PATCH v3 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
Hi Russell, On Wednesday 01 June 2011 15:43:38 Russell King - ARM Linux wrote: On Wed, Jun 01, 2011 at 03:30:11PM +0200, Laurent Pinchart wrote: sg_alloc_table can only allocate multi-page scatter-gather list tables if the architecture supports scatter-gather lists chaining. ARM doesn't fit in that category. Let's fix this properly, as I've said countless times and so far no one has bothered to sort this out: 8 From: Russell King rmk+ker...@arm.linux.org.uk Subject: ARM: Allow SoCs to enable scatterlist chaining Allow SoCs to enable the scatterlist chaining support, which allows scatterlist tables to be broken up into smaller allocations. As support for this feature depends on the implementation details of the users of the scatterlists, we can't enable this globally without auditing all the users, which is a very big task. Instead, let SoCs progressively switch over to using this. SoC drivers using scatterlists and SoC DMA implementations need auditing before this option can be enabled for the SoC. In the specific iovmm case, the driver uses the sglist API to build a list of page-size sg entries, and then process it in software. Is that considered as an abuse of the sglist API, or valid usage ? Anyway, sglist chaining is not needed by iovmm. As iovmm just walks the sglist manually, it's easier to allocate it in one go rather than using sglist chaining. This of course doesn't make your patch unneeded or wrong. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/Kconfig |3 +++ arch/arm/include/asm/scatterlist.h |4 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9adc278..cc0dcbf 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -37,6 +37,9 @@ config ARM Europe. There is an ARM Linux project with a web page at http://www.arm.linux.org.uk/. +config ARM_HAS_SG_CHAIN + bool + config HAVE_PWM bool diff --git a/arch/arm/include/asm/scatterlist.h b/arch/arm/include/asm/scatterlist.h index 2f87870..cefdb8f 100644 --- a/arch/arm/include/asm/scatterlist.h +++ b/arch/arm/include/asm/scatterlist.h @@ -1,6 +1,10 @@ #ifndef _ASMARM_SCATTERLIST_H #define _ASMARM_SCATTERLIST_H +#ifdef CONFIG_ARM_HAS_SG_CHAIN +#define ARCH_HAS_SG_CHAIN +#endif + #include asm/memory.h #include asm/types.h #include asm-generic/scatterlist.h -- Regards, Laurent Pinchart -- 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 4/4] mfd: global Suspend and resume support of ehci and ohci
On Wednesday, June 01, 2011, Keshava Munegowda wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and resume occurs. Before calling these functions, the
bus suspend and resume of ehci and ohci drivers are called
from runtime pm.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/mfd/omap-usb-host.c | 103
+++
1 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 43de12a..32d19e2 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -146,6 +146,10 @@
#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)
+/* USBHS state bits */
+#define OMAP_USBHS_INIT 0
+#define OMAP_USBHS_SUSPEND 4
+
struct usbhs_hcd_omap {
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
@@ -165,6 +169,7 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
int count;
+ unsigned long state;
};
/*-*/
@@ -809,6 +814,8 @@ static int usbhs_enable(struct device *dev)
(pdata-ehci_data-reset_gpio_port[1], 1);
}
+ set_bit(OMAP_USBHS_INIT, omap-state);
+
end_count:
omap-count++;
spin_unlock_irqrestore(omap-lock, flags);
@@ -897,6 +904,7 @@ static void usbhs_disable(struct device *dev)
}
pm_runtime_put_sync(dev);
+ clear_bit(OMAP_USBHS_INIT, omap-state);
/* The gpio_free migh sleep; so unlock the spinlock */
spin_unlock_irqrestore(omap-lock, flags);
@@ -926,10 +934,105 @@ void omap_usbhs_disable(struct device *dev)
}
EXPORT_SYMBOL_GPL(omap_usbhs_disable);
+#ifdef CONFIG_PM
+
+static int usbhs_resume(struct device *dev)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ struct usbhs_omap_platform_data *pdata = omap-platdata;
+ unsigned long flags = 0;
+
+ dev_dbg(dev, Resuming TI HSUSB Controller\n);
+
+ if (!pdata) {
+ dev_dbg(dev, missing platform_data\n);
+ return -ENODEV;
+ }
+
+ spin_lock_irqsave(omap-lock, flags);
+
+ if (!test_bit(OMAP_USBHS_INIT, omap-state) ||
+ !test_bit(OMAP_USBHS_SUSPEND, omap-state))
+ goto end_resume;
+
+ pm_runtime_get_sync(dev);
+
+ if (is_omap_usbhs_rev2(omap)) {
+ if (is_ehci_tll_mode(pdata-port_mode[0])) {
+ clk_enable(omap-usbhost_p1_fck);
+ clk_enable(omap-usbtll_p1_fck);
+ }
+ if (is_ehci_tll_mode(pdata-port_mode[1])) {
+ clk_enable(omap-usbhost_p2_fck);
+ clk_enable(omap-usbtll_p2_fck);
+ }
+ clk_enable(omap-utmi_p1_fck);
+ clk_enable(omap-utmi_p2_fck);
+ }
+ clear_bit(OMAP_USBHS_SUSPEND, omap-state);
+
+end_resume:
+ spin_unlock_irqrestore(omap-lock, flags);
+ return 0;
+}
+
+
+static int usbhs_suspend(struct device *dev)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ struct usbhs_omap_platform_data *pdata = omap-platdata;
+ unsigned long flags = 0;
+
+ dev_dbg(dev, Suspending TI HSUSB Controller\n);
+
+ if (!pdata) {
+ dev_dbg(dev, missing platform_data\n);
+ return -ENODEV;
+ }
+
+ spin_lock_irqsave(omap-lock, flags);
+
+ if (!test_bit(OMAP_USBHS_INIT, omap-state) ||
+ test_bit(OMAP_USBHS_SUSPEND, omap-state))
+ goto end_suspend;
+
+ if (is_omap_usbhs_rev2(omap)) {
+ if (is_ehci_tll_mode(pdata-port_mode[0])) {
+ clk_disable(omap-usbhost_p1_fck);
+ clk_disable(omap-usbtll_p1_fck);
+ }
+ if (is_ehci_tll_mode(pdata-port_mode[1])) {
+ clk_disable(omap-usbhost_p2_fck);
+ clk_disable(omap-usbtll_p2_fck);
+ }
+ clk_disable(omap-utmi_p2_fck);
+ clk_disable(omap-utmi_p1_fck);
+ }
+
+ set_bit(OMAP_USBHS_SUSPEND, omap-state);
+ pm_runtime_put_sync(dev);
+
+end_suspend:
+ spin_unlock_irqrestore(omap-lock, flags);
+ return 0;
+}
+
+
+static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
+ .suspend= usbhs_suspend,
+ .resume = usbhs_resume,
+};
Please add .freeze()/.thaw() and .poweroff()/.restore() callbacks too.
They may point to the same routines, but must be present.
You can actually use the
Re: [PATCH v3 1/2] omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
On Wed, Jun 01, 2011 at 03:50:50PM +0200, Laurent Pinchart wrote: In the specific iovmm case, the driver uses the sglist API to build a list of page-size sg entries, and then process it in software. Is that considered as an abuse of the sglist API, or valid usage ? Anyway, sglist chaining is not needed by iovmm. As iovmm just walks the sglist manually, it's easier to allocate it in one go rather than using sglist chaining. This of course doesn't make your patch unneeded or wrong. Well, there's a two issues here: 1. Should iovmm use sg_phys(sg) with sg_dma_len(sg) ? Probably not, because a scatterlist before DMA API mapping is defined by sg_page(sg), sg-offset, sg-length and has N entries. After DMA API mapping (n = dma_map_sg(dev, sg, N, dir)), it has n entries where n = N, and the DMA address/lengths are sg_dma_address(sg) and sg_dma_len(sg). Both these are undefined for unmapped scatterlists. Getting this wrong means breakage when CONFIG_NEED_SG_DMA_LENGTH is enabled. 2. What would be the effect of enabling SG list chaining on iovmm? The code uses the correct SG list walking helpers (for_each_sg) so it should be able to cope with chained SG lists. So, I think there's no problem here with chained SG lists, but there is an issue with using sg_dma_len(). I'd suggest converting stuff to use sg-length with sg_page(sg) rather than sg_dma_len(sg). As for whether SG chaining is required or not, if you're running up against the maximum SG table size, then you do have a requirement for SG chaining. -- 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/RFC 2/4] OMAP2: PM debug: remove register dumping
Hi Kevin, [...] Sorry but omapconf is run from userspace, it cannot be used to dump PRCM registers right before and after MPU WFI. Right, taking register snapshots is currently beyond the scope of omapconf. However, as I suggested earlier in this thread, if we had a new driver with read/write interface where register snapshots are saved, I imagine adopting omapconf to read from such an interface for dumping register snapshots would be relatively easy, right? Correct, this feature could be pretty easily added to omapconf. Patrick. Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- 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 4/4] mfd: global Suspend and resume support of ehci and ohci
Hi,
On Wed, Jun 01, 2011 at 03:54:38PM +0200, Rafael J. Wysocki wrote:
+static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
+ .suspend= usbhs_suspend,
+ .resume = usbhs_resume,
+};
Please add .freeze()/.thaw() and .poweroff()/.restore() callbacks too.
They may point to the same routines, but must be present.
You can actually use the SIMPLE_DEV_PM_OPS() convenience macro for this
purpose.
good point. BTW, do we need this #ifdef CONFIG_PM stuff which has been
popping on most drivers recently ? To me it looks like driver.pm field
is always available even if PM is disabled, so what's the point ? Saving
a few bytes ?
--
balbi
signature.asc
Description: Digital signature
Re: OMAP gpiolib?
[adding linux-omap list] Hello, Brian Hutchinson b.hutch...@gmail.com writes: Hi Kevin, I caught part of the conversation on the ARM kernel list where it looks like gpiolib for OMAP was going to be targeted to 2.6.41 or something like that (going from memory). Actually, the recent discussions were more about moving the OMAP driver into drivers/gpio. The OMAP GPIO driver already uses gpiolib. We have the C6A816x-evm (DDR2 version) and we have a custom board that should be here any day based on a DDR3 design. I just stepped up to the latest u-boot kernel for the DDR3 EVM (PSP 04.00.00.10). We need to use both the hardware spi (4 channels built into the c6a816x) and gpio spi. I've been helping a colleague here get the gpio spi going but he claims that he can't have gpio spi and hardware spi going at the same time. He claims if he tries to use both at the same time he gets a kernel crash. So I guess my questions are: 1. In the release notes of the TI kernel we have (2.6.37) it says gpio lib is added. Is this the complete OMAP gpiolib support or are there still things missing that we may need to back port from a 2.6.41 version? I'm just trying to understand the roadmap and which tree I should be watching. I've been in Arago land quite a bit lately and focusing on the git trees associated with that. I'm not familiar with the TI PSP kernels, so any specific questions should be addressed to the support channels for that kernel. In mainline, there is nothing (significant) that is different between .37 and .40 in OMAP GPIO support. Both are using gpiolib. 2. Can hardware spi gpio spi be used at the same time? Now that I think of ... in past projects I've used either/or ... never both at the same time. I don't know without digging into the TERM and knowing which exact GPIO pins and which SPI controller you're wanting to use, but GPIO pins are most always mux'd with other pins, so it is common that use of specific GPIO pins would prevent the use of some peripherals. Hope that helps, 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: OMAP gpiolib?
Thanks Kevin! The TI PSP04.00.00.10 release notes say the 2.6.37 kernel has gpio lib support added. The previous version of the same kernel that was part of the previous PSP (4.00.00.09 I think) had the same kernel but apparently gpiolib was there but wasn't quite all there for the c6a816x. Just wanted to make sure using hardware spi master and gpio spi master was a valid setup and didn't require special magic. I know how to setup the pin mux but I didn't know if there was anything else special I should be aware of. I'm not aware of any boards in arch that require a setup similar to ours we could look at as an example. Regards, Brian -- 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] media: omap3isp: fix a pontential NULL deref
Fix a potential NULL pointer dereference by skipping registration of
external entities in case none are provided.
This is useful at least when testing mere memory-to-memory scenarios.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 2a5fbe6..367ced3 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1756,7 +1756,7 @@ static int isp_register_entities(struct isp_device *isp)
goto done;
/* Register external entities */
- for (subdevs = pdata-subdevs; subdevs-subdevs; ++subdevs) {
+ for (subdevs = pdata-subdevs; subdevs subdevs-subdevs; ++subdevs) {
struct v4l2_subdev *sensor;
struct media_entity *input;
unsigned int flags;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/10] arch/arm/mach-omap2/clock.c: add missing clk_put
From: Julia Lawall ju...@diku.dk
Add missing call to clk_put.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@r exists@
expression e1,e2;
statement S;
@@
e1 = clk_get@p1(...);
... when != e1 = e2
when != clk_put(e1)
when any
if (...) { ... when != clk_put(e1)
when != if (...) { ... clk_put(e1) ... }
* return@p3 ...;
} else S
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
arch/arm/mach-omap2/clock.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 180299e..bf9c36c 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -453,6 +453,7 @@ int __init omap2_clk_switch_mpurate_at_boot(const char
*mpurate_ck_name)
if (IS_ERR_VALUE(r)) {
WARN(1, clock: %s: unable to set MPU rate to %d: %d\n,
mpurate_ck-name, mpurate, r);
+ clk_put(mpurate_ck);
return -EINVAL;
}
--
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/4] arm: omap: usb: ehci and ohci hwmod structures for omap3 and omap4
Keshava Munegowda keshava_mgo...@ti.com writes: Following 2 hwmod strcuture are added: UHH hwmod of usbhs with uhh base address and EHCI , OHCI irq and base addresses. TLL hwmod of usbhs with the TLL base address and irq. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com I believe the OMAP4 data came from Benoit, so should be in a patch with his authorship and signoff. OMAP3 can be a separate patch with your authorship. 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/4] arm: omap: usb: register hwmods of usbhs
Hi Kesheva,
Keshava Munegowda keshava_mgo...@ti.com writes:
The hwmod structure of uhh and tll are retrived
and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Minor comment below...
---
arch/arm/mach-omap2/usb-host.c | 99
++--
1 files changed, 35 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 89ae298..9d762c4 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -28,51 +28,28 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include plat/omap_device.h
#include mux.h
#ifdef CONFIG_MFD_OMAP_USB_HOST
-#define OMAP_USBHS_DEVICEusbhs-omap
-
-static struct resource usbhs_resources[] = {
- {
- .name = uhh,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = tll,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci-irq,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = ohci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ohci-irq,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device usbhs_device = {
- .name = OMAP_USBHS_DEVICE,
- .id = 0,
- .num_resources = ARRAY_SIZE(usbhs_resources),
- .resource = usbhs_resources,
-};
+#define OMAP_USBHS_DEVICEusbhs_omap
+#define USBHS_UHH_HWMODNAME usbhs_uhh
+#define USBHS_TLL_HWMODNAME usbhs_tll
static struct usbhs_omap_platform_data usbhs_data;
static struct ehci_hcd_omap_platform_dataehci_data;
static struct ohci_hcd_omap_platform_dataohci_data;
While changing the platform_data registration, these platform_data
structs should be alloc'd and then free'd after omap_device_build, since
a copy of them is made during device registration.
Kevin
+static struct omap_device_pm_latency omap_uhhtll_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
/* MUX settings for EHCI pins */
/*
* setup_ehci_io_mux - initialize IO pad mux for USBHOST
@@ -508,7 +485,10 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- int i;
+ struct omap_hwmod *oh[2];
+ struct omap_device *od;
+ int bus_id = -1;
+ int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
@@ -523,44 +503,35 @@ void __init usbhs_init(const struct
usbhs_omap_board_data *pdata)
usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
- usbhs_resources[0].start = OMAP34XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP34XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start= OMAP34XX_EHCI_BASE;
- usbhs_resources[2].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = INT_34XX_EHCI_IRQ;
- usbhs_resources[4].start= OMAP34XX_OHCI_BASE;
- usbhs_resources[4].end = OMAP34XX_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = INT_34XX_OHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
} else if (cpu_is_omap44xx()) {
- usbhs_resources[0].start = OMAP44XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP44XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP44XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP44XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start = OMAP44XX_HSUSB_EHCI_BASE;
- usbhs_resources[2].end = OMAP44XX_HSUSB_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = OMAP44XX_IRQ_EHCI;
- usbhs_resources[4].start = OMAP44XX_HSUSB_OHCI_BASE;
- usbhs_resources[4].end = OMAP44XX_HSUSB_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = OMAP44XX_IRQ_OHCI;
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
}
- if (platform_device_add_data(usbhs_device,
- usbhs_data, sizeof(usbhs_data)) 0) {
- printk(KERN_ERR USBHS platform_device_add_data failed\n);
- goto
Re: [PATCH 2/4] arm: omap: usb: register hwmods of usbhs
Keshava Munegowda keshava_mgo...@ti.com writes: The hwmod structure of uhh and tll are retrived and registered with omap device And the name strings are changed as well as the device identifier changed from zero to -1. Please comment and justify. 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 3/4] arm: omap: usb: device name change for the clk names of usbhs
Keshava Munegowda keshava_mgo...@ti.com writes: From: Keshava Munegowda keshava_mgo...@ti.com device name usbhs clocks are changed from usbhs-omap.0 to usbhs_omap; this is because in the hwmod registration the device name is set as usbhs_omap ..and because the identifier is changed to -1 in the previous patch without being documented. 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] OMAP2: CONFIG_TOUCHSCREEN_ADS7846 XOR CONFIG_MTD_NAND_OMAP2 breaks build
On 31.05.2011 15:07, Tony Lindgren wrote: Care to check if this is still needed for v3.0-rc1? If so, please add proper patch description and Signed-off-by. Just tried and successfully built stock 3.0-rc1 kernels with both configuration combinations. Patch no longer needed. Cheers, Matthias -- 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
calling runtime PM from system PM methods
Hi Rafael,
Once again, I'm back to some problems with using runtime PM from system
PM methods. On OMAP, many drivers don't need to do anything different
for runtime PM compared to system PM, so the system PM methods can
simply use runtime PM.
The obvious complication arises when runtime PM is disabled from
userspace, preventing system PM.
Taking into consideration that runtime PM can be disabled from
userspace, the system PM methods need to manually call the subsystems
runtime PM callbask. An example of the resulting system PM methods can
be found in the currenty OMAP I2C driver (excerpt below[1])
This was working, but now we have device power domains which complicate
the story. My first take was to change the system PM methods to check
the device power domain callbacks as well[2], and take care of the
precedence. That seems OK, but it's starting to feel like extra work
for each driver that is easy to screw up, and includes some assumptions
about how the PM core works (e.g. power domain precedence.)
It also has the disadvantage of not taking into consideration the
IRQ-safe capabilities of the PM core.
Rather than adding this additional logic to every driver, what would be
best is if we could just take advantage of all the existing logic in the
runtime PM core, rather than duplicating some of it in the drivers.
The ideal case would be for system PM methods to be able to simply call
pm_runtime_get_sync/_put_sync as well, but somehow force the
transitions, even when pm_runtime_forbid() has been called.
I suspect you won't like that idea, but am curious about your opinions.
In the process of experimenting with other solutions, I found an
interesting discovery:
In the driver's -suspend() hook, I did something like this:
priv-forced_suspend = false;
if (!pm_runtime_suspended(dev)) {
pm_runtime_put_sync(dev);
priv-forced_suspend = true;
}
and in the resume hook I did this:
if (priv-forced_suspend)
pm_runtime_get_sync(dev);
Even after disabling runtime PM from userspace via
/sys/devices/.../power/control, the -suspend() hook triggered an actual
transition. This is because pm_runtime_forbid() just uses the usage
counter, so the _put_sync() in the -suspend callback decrements the
counter and triggers an rpm_idle(). Is this expected behavior?
If I can count on this behavior, then the above solution seems better
than my workaround below[2], although I kinda don't like making
assumptions about how pm_runtime_forbid() is implemented.
Kevin
[1] from drivers/i2c/busses/i2c-omap.c
static int omap_i2c_suspend(struct device *dev)
{
if (!pm_runtime_suspended(dev))
if (dev-bus dev-bus-pm dev-bus-pm-runtime_suspend)
dev-bus-pm-runtime_suspend(dev);
return 0;
}
static int omap_i2c_resume(struct device *dev)
{
if (!pm_runtime_suspended(dev))
if (dev-bus dev-bus-pm dev-bus-pm-runtime_resume)
dev-bus-pm-runtime_resume(dev);
return 0;
}
[2]
static int omap_i2c_suspend(struct device *dev)
{
int (*callback)(struct device *) = NULL;
int ret = 0;
if (!pm_runtime_suspended(dev)) {
if (dev-pwr_domain)
callback = dev-pwr_domain-ops.runtime_suspend;
else if (dev-bus dev-bus-pm)
callback = dev-bus-pm-runtime_suspend;
ret = callback(dev);
}
return ret;
}
static int omap_i2c_resume(struct device *dev)
{
int (*callback)(struct device *) = NULL;
int ret = 0;
if (!pm_runtime_suspended(dev)) {
if (dev-pwr_domain)
callback = dev-pwr_domain-ops.runtime_resume;
else if (dev-bus dev-bus-pm)
callback = dev-bus-pm-runtime_resume;
ret = callback(dev);
}
return ret;
}
--
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 4/4] mfd: global Suspend and resume support of ehci and ohci
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and resume occurs. Before calling these functions, the
bus suspend and resume of ehci and ohci drivers are called
from runtime pm.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
First, from what I can see, this is only a partial implementation of
runtime PM. What I mean is that the runtime PM methods are used only
during the suspend path. The rest of the time the USB host IP block is
left enabled, even when nothing is connected.
I tested this on my 3530/Overo board, and verified that indeed the
usbhost powerdomain hits retention on suspend, but while idle, when
nothing is connected, I would expect the driver could be clever enough
to use runtime PM (probably using autosuspend timeouts) to disable the
hardware as well.
---
drivers/mfd/omap-usb-host.c | 103
+++
1 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 43de12a..32d19e2 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -146,6 +146,10 @@
#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)
+/* USBHS state bits */
+#define OMAP_USBHS_INIT 0
+#define OMAP_USBHS_SUSPEND 4
These additional state bits don't seem to be necessary.
For suspend, just check 'pm_runtime_is_suspended()'
The init flag is only used in the suspend/resume hooks, but the need for
it is a side effect of not correctly using the runtime PM callbacks.
Remember that the runtime PM get/put hooks have usage counting. Only
when the usage count transitions to/from zero is the actual
hardware-level enable/disable (via omap_hwmod) being done.
The current code is making the assumption that every call to get/put is
going to result in an enable/disable of the hardware.
Instead, all of the code that needs to be run only upon actual
enable/disable of the hardware should be done in the driver's
runtime_suspend/runtime_resume callbacks. These are only called when
the hardware actually changes state.
Not knowing that much about the EHCI block, upon first glance, it looks
like mmuch of what is done in usbhs_enable() should actually be done in
the -runtime_resume() callback, and similarily, much of what is done in
usbhs_disable() should be done in the -runtime_suspend() callback.
Another thing to be aware of is that runtime PM can be disabled from
userspace. For example, try this:
echo on /sys/devices/platform/omap/usbhs_omap/power/control
This disables runtime PM for the device. After doing this and
suspending, you'll notice that usbhost powerdomain no longer hits
retention on suspend. Setting it back to 'auto' allows it to work
again.
Because of this, you can not simply call pm_runtime_put() from the
static suspend callback. You should check pm_runtime_is_suspended().
If it is, there's nothing to do. If not, the runtime PM callbacks for
the subsystem need to manually be called. See drivers/i2c/i2c-omap.c
for an example (and check the version in my PM branch, which has a fix
required starting with kernel v3.0.)
While I'm preaching on runtime PM here, some other things that should be
cleaned up because they duplicate what other frameworks are doing:
- drivers should not be touching their SYSCONFIG register. This
is managed by omap_hwmod
- current driver is doing usage counting, but runtime PM core is
already handling usage counting.
My apologies for not reviewing the runtime PM work in this driver
earlier. Some of the problems above come from code that's already in
mainline (which I should've reviewed earlier), and some are added with
this series. All of them should be cleaned up before merging this.
Kevin
struct usbhs_hcd_omap {
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
@@ -165,6 +169,7 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
int count;
+ unsigned long state;
};
/*-*/
@@ -809,6 +814,8 @@ static int usbhs_enable(struct device *dev)
(pdata-ehci_data-reset_gpio_port[1], 1);
}
+ set_bit(OMAP_USBHS_INIT, omap-state);
+
end_count:
omap-count++;
spin_unlock_irqrestore(omap-lock, flags);
@@ -897,6 +904,7 @@ static void usbhs_disable(struct device *dev)
}
pm_runtime_put_sync(dev);
+ clear_bit(OMAP_USBHS_INIT, omap-state);
/* The gpio_free migh sleep; so unlock the spinlock */
spin_unlock_irqrestore(omap-lock, flags);
@@ -926,10 +934,105 @@ void
[PATCH v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
Ben, Please pull in this series from Andy Green for the next merge window. v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic sanity testing against with the latest kernel. It's also available here for pulling: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.1/i2c-andy Original cover letter from Andy below: The following series removes cpu_...() usage completely from the omap-i2c driver by having decisions about functional implementation choices in the SoC held in cpu-specific hwmod tables that are already established, or for OMAP1 where there is no hwmod, set at OMAP1-specific i2c bus addition time. Along the way it solves two issues with the existing implementation, that only 16-bit accesses are documented to be allowed to the I2C peripheral unit, and that due to a confusion in the existing driver about whether it is faced with a newer IP version on OMAP3530, currently it writes to a random non-existent I2C register at times on that platform. The patch series is quite extended from the first try thanks to comments from Benoit Cousson. This 3rd try is based on 2.6.38-rc8 as requested. Andy Green (18): I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c I2C: OMAP2+: Name registers in I2C IP V2 only accordingly I2C: OMAP2+: Introduce I2C IP versioning constants I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision I2C: OMAP: add rev to omap i2c platform data I2C: OMAP1: set IP revision in platform data I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added I2C: OMAP2+: use platform_data ip revision to select register map I2C: OMAP2+: Solve array bounds overflow error on i2c idle I2C: OMAP2+: address confused probed version naming I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32 I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data I2C: OMAP2+: Pass flags up to omap i2c platform_data as well I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr I2C: OMAP1: set i2c unit feature implementation flags in platform data I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info arch/arm/mach-omap2/omap_hwmod_2420_data.c |8 ++- arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 - arch/arm/plat-omap/i2c.c | 27 arch/arm/plat-omap/include/plat/i2c.h |3 +- drivers/i2c/busses/i2c-omap.c | 100 +++- include/linux/i2c-omap.h | 29 8 files changed, 153 insertions(+), 51 deletions(-) -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/18] I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c
From: Andy Green a...@warmcat.com
Peter Maydell noticed when running under QEMU he was getting
errors reporting 32-bit access to I2C peripheral unit registers
that are documented to be 8 or 16-bit only[1][2]
The I2C driver is blameless as it wraps its accesses in a
function using __raw_writew and __raw_readw, it turned out it
is the hwmod stuff.
However the hwmod code already has a flag to force a
perhipheral unit to only be accessed using 16-bit operations.
This patch applies the 16-bit only flag to the 2430,
OMAP3xxx and OMAP44xx hwmod structs. 2420 was already
correctly marked up as 16-bit.
The 2430 change will need testing by TI as arranged
in the comments to the previous patch version.
When the 16-bit flag is or-ed with other flags, it is placed
first as requested in comments.
[1] OMAP4430 Technical reference manual section 23.1.6.2
[2] OMAP3530 Techincal reference manual section 18.6
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 9682dd5..0c272be 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1547,6 +1547,7 @@ static struct omap_hwmod_ocp_if *omap2430_i2c1_slaves[] =
{
static struct omap_hwmod omap2430_i2c1_hwmod = {
.name = i2c1,
+ .flags = HWMOD_16BIT_REG,
.mpu_irqs = i2c1_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(i2c1_mpu_irqs),
.sdma_reqs = i2c1_sdma_reqs,
@@ -1593,6 +1594,7 @@ static struct omap_hwmod_ocp_if *omap2430_i2c2_slaves[] =
{
static struct omap_hwmod omap2430_i2c2_hwmod = {
.name = i2c2,
+ .flags = HWMOD_16BIT_REG,
.mpu_irqs = i2c2_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(i2c2_mpu_irqs),
.sdma_reqs = i2c2_sdma_reqs,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 909a84d..78efb59 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1891,6 +1891,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c1_slaves[] =
{
static struct omap_hwmod omap3xxx_i2c1_hwmod = {
.name = i2c1,
+ .flags = HWMOD_16BIT_REG,
.mpu_irqs = i2c1_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(i2c1_mpu_irqs),
.sdma_reqs = i2c1_sdma_reqs,
@@ -1933,6 +1934,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c2_slaves[] =
{
static struct omap_hwmod omap3xxx_i2c2_hwmod = {
.name = i2c2,
+ .flags = HWMOD_16BIT_REG,
.mpu_irqs = i2c2_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(i2c2_mpu_irqs),
.sdma_reqs = i2c2_sdma_reqs,
@@ -1975,6 +1977,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c3_slaves[] =
{
static struct omap_hwmod omap3xxx_i2c3_hwmod = {
.name = i2c3,
+ .flags = HWMOD_16BIT_REG,
.mpu_irqs = i2c3_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(i2c3_mpu_irqs),
.sdma_reqs = i2c3_sdma_reqs,
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index abc548a..5662097 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2164,7 +2164,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c1_slaves[] =
{
static struct omap_hwmod omap44xx_i2c1_hwmod = {
.name = i2c1,
.class = omap44xx_i2c_hwmod_class,
- .flags = HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_16BIT_REG | HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_i2c1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c1_irqs),
.sdma_reqs = omap44xx_i2c1_sdma_reqs,
@@ -2217,7 +2217,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c2_slaves[] =
{
static struct omap_hwmod omap44xx_i2c2_hwmod = {
.name = i2c2,
.class = omap44xx_i2c_hwmod_class,
- .flags = HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_16BIT_REG | HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_i2c2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c2_irqs),
.sdma_reqs = omap44xx_i2c2_sdma_reqs,
@@ -2270,7 +2270,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c3_slaves[] =
{
static struct omap_hwmod omap44xx_i2c3_hwmod = {
.name = i2c3,
.class = omap44xx_i2c_hwmod_class,
-
[PATCH v4 02/18] I2C: OMAP2+: Name registers in I2C IP V2 only accordingly
From: Andy Green a...@warmcat.com
The OMAP I2C driver dynamically chooses between two register sets of
differing sizes depending on the cpu type it finds itself on.
It has been observed that the existing code references non-existing
registers on OMAP3530, because while it correctly chose the smaller
register layout based on cpu type, the code uses the probed register
ID to decide if to execute code referencing an extra register, and
both register layout devices on OMAP3530 and OMAP4430 report the same
probed ID of 0x40.
This patch changes the extended register names only found on IP V2
of the I2C peripheral unit accordingly to help show up errors in usage.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 58a58c7..6a6b222 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -72,11 +72,12 @@ enum {
OMAP_I2C_SCLH_REG,
OMAP_I2C_SYSTEST_REG,
OMAP_I2C_BUFSTAT_REG,
- OMAP_I2C_REVNB_LO,
- OMAP_I2C_REVNB_HI,
- OMAP_I2C_IRQSTATUS_RAW,
- OMAP_I2C_IRQENABLE_SET,
- OMAP_I2C_IRQENABLE_CLR,
+ /* only on OMAP4430 */
+ OMAP_I2C_IP_V2_REVNB_LO,
+ OMAP_I2C_IP_V2_REVNB_HI,
+ OMAP_I2C_IP_V2_IRQSTATUS_RAW,
+ OMAP_I2C_IP_V2_IRQENABLE_SET,
+ OMAP_I2C_IP_V2_IRQENABLE_CLR,
};
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
@@ -244,11 +245,11 @@ const static u8 omap4_reg_map[] = {
[OMAP_I2C_SCLH_REG] = 0xb8,
[OMAP_I2C_SYSTEST_REG] = 0xbC,
[OMAP_I2C_BUFSTAT_REG] = 0xc0,
- [OMAP_I2C_REVNB_LO] = 0x00,
- [OMAP_I2C_REVNB_HI] = 0x04,
- [OMAP_I2C_IRQSTATUS_RAW] = 0x24,
- [OMAP_I2C_IRQENABLE_SET] = 0x2c,
- [OMAP_I2C_IRQENABLE_CLR] = 0x30,
+ [OMAP_I2C_IP_V2_REVNB_LO] = 0x00,
+ [OMAP_I2C_IP_V2_REVNB_HI] = 0x04,
+ [OMAP_I2C_IP_V2_IRQSTATUS_RAW] = 0x24,
+ [OMAP_I2C_IP_V2_IRQENABLE_SET] = 0x2c,
+ [OMAP_I2C_IP_V2_IRQENABLE_CLR] = 0x30,
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -309,7 +310,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
if (dev-rev = OMAP_I2C_REV_ON_4430)
- omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 1);
+ omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
else
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 03/18] I2C: OMAP2+: Introduce I2C IP versioning constants
From: Andy Green a...@warmcat.com
These represent the two kinds of (incompatible) OMAP I2C
peripheral unit in use so far.
The constants are in linux/i2c-omap.h so the omap i2c driver can have
them too.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/i2c.h |1 +
include/linux/i2c-omap.h | 12
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/i2c.h
b/arch/arm/plat-omap/include/plat/i2c.h
index 878d632..a1d3d06 100644
--- a/arch/arm/plat-omap/include/plat/i2c.h
+++ b/arch/arm/plat-omap/include/plat/i2c.h
@@ -22,6 +22,7 @@
#define __ASM__ARCH_OMAP_I2C_H
#include linux/i2c.h
+#include linux/i2c-omap.h
#if defined(CONFIG_I2C_OMAP) || defined(CONFIG_I2C_OMAP_MODULE)
extern int omap_register_i2c_bus(int bus_id, u32 clkrate,
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 7472449..701886d 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -3,6 +3,18 @@
#include linux/platform_device.h
+/*
+ * Version 2 of the I2C peripheral unit has a different register
+ * layout and extra registers. The ID register in the V2 peripheral
+ * unit on the OMAP4430 reports the same ID as the V1 peripheral
+ * unit on the OMAP3530, so we must inform the driver which IP
+ * version we know it is running on from platform / cpu-specific
+ * code using these constants in the hwmod class definition.
+ */
+
+#define OMAP_I2C_IP_VERSION_1 1
+#define OMAP_I2C_IP_VERSION_2 2
+
struct omap_i2c_bus_platform_data {
u32 clkrate;
void(*set_mpu_wkup_lat)(struct device *dev, long set);
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/18] I2C: OMAP: add rev to omap i2c platform data
From: Andy Green a...@warmcat.com
We need to pass the I2C IP revision from the hwmod class up
into the OMAP I2C driver, which does not have direct
access to it.
This adds a member to the platform data the OMAP I2C driver
does use already to hold the I2C IP revision.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
include/linux/i2c-omap.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 701886d..b321211 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -17,6 +17,7 @@
struct omap_i2c_bus_platform_data {
u32 clkrate;
+ u32 rev;
void(*set_mpu_wkup_lat)(struct device *dev, long set);
int (*device_enable) (struct platform_device *pdev);
int (*device_shutdown) (struct platform_device *pdev);
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 04/18] I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision
From: Andy Green a...@warmcat.com
Since we cannot trust (or even reliably find) the OMAP I2C
peripheral unit's own revision register, we must inform the
OMAP i2c driver of which IP version it is running on. We
do this by tagging the omap_hwmod_class for i2c on all the
OMAP2+ platform / cpu specific hwmod init and passing it up
to the driver (next patches).
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
4 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index c4d0ae8..2223c44 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1447,6 +1447,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .rev= OMAP_I2C_IP_VERSION_1,
};
static struct omap_i2c_dev_attr i2c_dev_attr;
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0c272be..dbcc36e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1524,6 +1524,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .rev= OMAP_I2C_IP_VERSION_1,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 78efb59..80839b1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1460,6 +1460,7 @@ static struct omap_hwmod omap3xxx_uart4_hwmod = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .rev = OMAP_I2C_IP_VERSION_1,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 5662097..a09ab66 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2125,6 +2125,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_i2c_sysc = {
static struct omap_hwmod_class omap44xx_i2c_hwmod_class = {
.name = i2c,
.sysc = omap44xx_i2c_sysc,
+ .rev= OMAP_I2C_IP_VERSION_2,
};
/* i2c1 */
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 06/18] I2C: OMAP1: set IP revision in platform data
From: Andy Green a...@warmcat.com All OMAP1 are using IP revision 1 in terms of register layout. We set this information in omap1_i2c_add_bus() so we don't have to use cpu_is_xxx() any more in the omap i2c driver. Cc: patc...@linaro.org Cc: Ben Dooks ben-li...@fluff.org Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Andy Green andy.gr...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/i2c.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index 3341ca4..a938df0 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -108,6 +108,9 @@ static inline int omap1_i2c_add_bus(int bus_id) res[1].start = INT_I2C; pdata = i2c_pdata[bus_id - 1]; + /* all OMAP1 have IP version 1 register set */ + pdata-rev = OMAP_I2C_IP_VERSION_1; + return platform_device_register(pdev); } -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/18] I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added
From: Andy Green a...@warmcat.com Mark each OMAP I2C bus with the hwmod's knowledge of which I2C IP version is in the chip we're running on. Cc: patc...@linaro.org Cc: Ben Dooks ben-li...@fluff.org Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Andy Green andy.gr...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/i2c.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index a938df0..0d3eda7 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -155,6 +155,12 @@ static inline int omap2_i2c_add_bus(int bus_id) pdata = i2c_pdata[bus_id - 1]; /* +* pass the hwmod class's CPU-specific knowledge of I2C IP revision in +* use up to the OMAP I2C driver via platform data +*/ + pdata-rev = oh-class-rev; + + /* * When waiting for completion of a i2c transfer, we need to * set a wake up latency constraint for the MPU. This is to * ensure quick enough wakeup from idle, when transfer -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/18] I2C: OMAP2+: use platform_data ip revision to select register map
From: Andy Green a...@warmcat.com
Change the register map names to reflect the IP revision they
are representing, and use the platform_data IP revision index
to select between them at init time.
Eliminates 1 of 17 cpu_...() calls in the driver.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6a6b222..fbd4ec4 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -205,7 +205,7 @@ struct omap_i2c_dev {
u16 errata;
};
-const static u8 reg_map[] = {
+const static u8 reg_map_ip_v1[] = {
[OMAP_I2C_REV_REG] = 0x00,
[OMAP_I2C_IE_REG] = 0x01,
[OMAP_I2C_STAT_REG] = 0x02,
@@ -226,7 +226,7 @@ const static u8 reg_map[] = {
[OMAP_I2C_BUFSTAT_REG] = 0x10,
};
-const static u8 omap4_reg_map[] = {
+const static u8 reg_map_ip_v2[] = {
[OMAP_I2C_REV_REG] = 0x04,
[OMAP_I2C_IE_REG] = 0x2c,
[OMAP_I2C_STAT_REG] = 0x28,
@@ -1035,10 +1035,10 @@ omap_i2c_probe(struct platform_device *pdev)
else
dev-reg_shift = 2;
- if (cpu_is_omap44xx())
- dev-regs = (u8 *) omap4_reg_map;
+ if (pdata-rev == OMAP_I2C_IP_VERSION_2)
+ dev-regs = (u8 *)reg_map_ip_v2;
else
- dev-regs = (u8 *) reg_map;
+ dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(pdev-dev);
omap_i2c_unidle(dev);
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 09/18] I2C: OMAP2+: Solve array bounds overflow error on i2c idle
From: Andy Green a...@warmcat.com This solves the main problem the patch series is about. Prior to this patch on OMAP3530 the driver wrongly interprets the I2C peripheral unit's own reported revision as meaning it is running on an IP V2 device and must use the extended registers. In fact OMAP3530 is IP V1 with the smaller register set, the reason for the confusion is that the hardware does in fact report having the same IP revision index as is found on an OMAP4430, which really is IP V2 and has the extended registers. This corrects the test for which registers to use so that it decides using hwmod knowledge found in the platform_data. Cc: patc...@linaro.org Cc: Ben Dooks ben-li...@fluff.org Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Andy Green andy.gr...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index fbd4ec4..f7196f3 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -309,7 +309,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev) pdata = pdev-dev.platform_data; dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG); - if (dev-rev = OMAP_I2C_REV_ON_4430) + if (pdata-rev == OMAP_I2C_IP_VERSION_2) omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1); else omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0); -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 11/18] I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32
From: Andy Green a...@warmcat.com
As part of removing cpu_...() from the OMAP I2C driver, we need to
convert the CPU tests into functionality flags that are set by
hwmod class in the same way the IP revision is.
More flags are needed than will fit in the existing u8 flags
member of omap_i2c_dev_attr.
These flags can refer to options inside the IP block but they are
most needed for information about cpu implementation specific
options that are not part of the IP block itself. For example,
how the CPU data bus is wired to the IP block databus differs
between OMAP cpus and affects how you must shift the address in
the IP block, but is not a feature of the IP block itself.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/i2c.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/i2c.h
b/arch/arm/plat-omap/include/plat/i2c.h
index a1d3d06..fd75dad 100644
--- a/arch/arm/plat-omap/include/plat/i2c.h
+++ b/arch/arm/plat-omap/include/plat/i2c.h
@@ -47,7 +47,7 @@ static inline int omap_register_i2c_bus(int bus_id, u32
clkrate,
*/
struct omap_i2c_dev_attr {
u8 fifo_depth;
- u8 flags;
+ u32 flags;
};
void __init omap1_i2c_mux_pins(int bus_id);
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 10/18] I2C: OMAP2+: address confused probed version naming
From: Andy Green a...@warmcat.com
The driver reflects the confusion that probed I2C revision
from the hardware of 0x40 means it is on an OMAP4430.
However, you will probe the same 0x40 ID on an OMAP3530. So
this patch changes the name to reflect that.
It also clarifies that the original name OMAP_I2C_REV_2 is
referring to some ancient OMAP1 revision number, not to be
confused with the IP revisions this patch series introduces.
Similarly the term rev is used in the ancient OMAP1 ISR,
the term is changed to use omap1 instead.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f7196f3..ecb48c7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -42,12 +42,12 @@
#include linux/pm_runtime.h
/* I2C controller revisions */
-#define OMAP_I2C_REV_2 0x20
+#define OMAP_I2C_OMAP1_REV_2 0x20
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_4430 0x40
+#define OMAP_I2C_REV_ON_3530_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -314,7 +314,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
else
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
- if (dev-rev OMAP_I2C_REV_2) {
+ if (dev-rev OMAP_I2C_OMAP1_REV_2) {
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
} else {
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
@@ -336,7 +336,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long internal_clk = 0;
struct clk *fclk;
- if (dev-rev = OMAP_I2C_REV_2) {
+ if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
omap_i2c_read_reg(dev, OMAP_I2C_CON_REG)
@@ -379,7 +379,9 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev-westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ if (dev-rev OMAP_I2C_REV_ON_3530_4430)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
+ dev-westate);
}
}
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
@@ -721,7 +723,7 @@ static inline void i2c_omap_errata_i207(struct omap_i2c_dev
*dev, u16 stat)
#ifdef CONFIG_ARCH_OMAP15XX
static irqreturn_t
-omap_i2c_rev1_isr(int this_irq, void *dev_id)
+omap_i2c_omap1_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
u16 iv, w;
@@ -775,7 +777,7 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
return IRQ_HANDLED;
}
#else
-#define omap_i2c_rev1_isr NULL
+#define omap_i2c_omap1_isr NULL
#endif
/*
@@ -1060,7 +1062,7 @@ omap_i2c_probe(struct platform_device *pdev)
* size. This is to ensure that we can handle the status on int
* call back latencies.
*/
- if (dev-rev = OMAP_I2C_REV_ON_4430) {
+ if (dev-rev = OMAP_I2C_REV_ON_3530_4430) {
dev-fifo_size = 0;
dev-b_hw = 0; /* Disable hardware fixes */
} else {
@@ -1076,7 +1078,8 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
- isr = (dev-rev OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
+ isr = (dev-rev OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
+ omap_i2c_isr;
r = request_irq(dev-irq, isr, 0, pdev-name, dev);
if (r) {
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 12/18] I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data
From: Andy Green a...@warmcat.com
OMAP I2C driver can access the configuration flags through
its platform data.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
include/linux/i2c-omap.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index b321211..776c8e1 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -18,6 +18,7 @@
struct omap_i2c_bus_platform_data {
u32 clkrate;
u32 rev;
+ u32 flags;
void(*set_mpu_wkup_lat)(struct device *dev, long set);
int (*device_enable) (struct platform_device *pdev);
int (*device_shutdown) (struct platform_device *pdev);
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 15/18] I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr
From: Andy Green a...@warmcat.com
This adds the new functionality flags for omap i2c unit to all OMAP2
hwmod definitions
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |7 ++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |9 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |9 +
4 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2223c44..e9a416c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1450,7 +1450,12 @@ static struct omap_hwmod_class i2c_class = {
.rev= OMAP_I2C_IP_VERSION_1,
};
-static struct omap_i2c_dev_attr i2c_dev_attr;
+static struct omap_i2c_dev_attr i2c_dev_attr = {
+ .flags = OMAP_I2C_FLAG_NO_FIFO |
+ OMAP_I2C_FLAG_SIMPLE_CLOCK |
+ OMAP_I2C_FLAG_16BIT_DATA_REG |
+ OMAP_I2C_FLAG_BUS_SHIFT_2,
+};
/* I2C1 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index dbcc36e..beedda6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1529,6 +1529,9 @@ static struct omap_hwmod_class i2c_class = {
static struct omap_i2c_dev_attr i2c_dev_attr = {
.fifo_depth = 8, /* bytes */
+ .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
+ OMAP_I2C_FLAG_BUS_SHIFT_2 |
+ OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
};
/* I2C1 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 80839b1..dec1a38 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1875,6 +1875,9 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
static struct omap_i2c_dev_attr i2c1_dev_attr = {
.fifo_depth = 8, /* bytes */
+ .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
+OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
@@ -1918,6 +1921,9 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {
static struct omap_i2c_dev_attr i2c2_dev_attr = {
.fifo_depth = 8, /* bytes */
+ .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
+OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod_irq_info i2c2_mpu_irqs[] = {
@@ -1961,6 +1967,9 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {
static struct omap_i2c_dev_attr i2c3_dev_attr = {
.fifo_depth = 64, /* bytes */
+ .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
+OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index a09ab66..3fd182d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -27,6 +27,7 @@
#include plat/mcspi.h
#include plat/mcbsp.h
#include plat/mmc.h
+#include plat/i2c.h
#include omap_hwmod_common_data.h
@@ -2128,6 +2129,10 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class
= {
.rev= OMAP_I2C_IP_VERSION_2,
};
+static struct omap_i2c_dev_attr i2c_dev_attr = {
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+};
+
/* i2c1 */
static struct omap_hwmod omap44xx_i2c1_hwmod;
static struct omap_hwmod_irq_info omap44xx_i2c1_irqs[] = {
@@ -2178,6 +2183,7 @@ static struct omap_hwmod omap44xx_i2c1_hwmod = {
},
.slaves = omap44xx_i2c1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_i2c1_slaves),
+ .dev_attr = i2c_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -2231,6 +2237,7 @@ static struct omap_hwmod omap44xx_i2c2_hwmod = {
},
.slaves = omap44xx_i2c2_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_i2c2_slaves),
+ .dev_attr = i2c_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -2284,6 +2291,7 @@ static struct omap_hwmod omap44xx_i2c3_hwmod = {
},
.slaves = omap44xx_i2c3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_i2c3_slaves),
+ .dev_attr = i2c_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -2337,6 +2345,7 @@ static struct omap_hwmod omap44xx_i2c4_hwmod = {
},
[PATCH v4 17/18] I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data
From: Andy Green a...@warmcat.com
This patch eliminates all cpu_...() tests from the OMAP I2C driver.
Instead, it uses the functionality flags in the platform data to make
the decisions about product variations the driver needs to handle.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 40 +++-
1 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ecb48c7..c997c55 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -277,7 +277,7 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
pm_runtime_get_sync(pdev-dev);
- if (cpu_is_omap34xx()) {
+ if (pdata-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
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);
@@ -335,6 +335,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long timeout;
unsigned long internal_clk = 0;
struct clk *fclk;
+ struct platform_device *pdev;
+ struct omap_i2c_bus_platform_data *pdata;
+
+ pdev = to_platform_device(dev-dev);
+ pdata = pdev-dev.platform_data;
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
@@ -386,7 +391,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
}
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- if (cpu_class_is_omap1()) {
+ if (pdata-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
* The I2C functional clock is the armxor_ck, so there's
* no need to get armxor_ck separately. Now, if OMAP2420
@@ -410,7 +415,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
- if (!(cpu_class_is_omap1() || cpu_is_omap2420())) {
+ if (!(pdata-flags OMAP_I2C_FLAG_SIMPLE_CLOCK)) {
/*
* HSI2C controller internal clk rate should be 19.2 Mhz for
@@ -418,7 +423,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* to get longer filter period for better noise suppression.
* The filter is iclk (fclk for HS) period.
*/
- if (dev-speed 400 || cpu_is_omap2430())
+ if (dev-speed 400 ||
+ pdata-flags OMAP_I2C_FLAG_FORCE_19200_INT_CLK)
internal_clk = 19200;
else if (dev-speed 100)
internal_clk = 9600;
@@ -487,7 +493,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-errata = 0;
- if (cpu_is_omap2430() || cpu_is_omap34xx())
+ if (pdata-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207)
dev-errata |= I2C_OMAP_ERRATA_I207;
/* Enable interrupts */
@@ -496,7 +502,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
OMAP_I2C_IE_AL) | ((dev-fifo_size) ?
(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
- if (cpu_is_omap34xx()) {
+ if (pdata-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
dev-pscstate = psc;
dev-scllstate = scll;
dev-sclhstate = sclh;
@@ -816,6 +822,11 @@ omap_i2c_isr(int this_irq, void *dev_id)
u16 bits;
u16 stat, w;
int err, count = 0;
+ struct platform_device *pdev;
+ struct omap_i2c_bus_platform_data *pdata;
+
+ pdev = to_platform_device(dev-dev);
+ pdata = pdev-dev.platform_data;
if (dev-idle)
return IRQ_NONE;
@@ -884,8 +895,8 @@ complete:
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
*/
- if (cpu_class_is_omap1() ||
- cpu_is_omap2420()) {
+ if (pdata-flags
+OMAP_I2C_FLAG_16BIT_DATA_REG) {
if (dev-buf_len) {
*dev-buf++ = w 8;
dev-buf_len--;
@@ -927,8 +938,8 @@ complete:
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
[PATCH v4 18/18] I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info
From: Andy Green a...@warmcat.com The IP version is prepended to the existing printed probed version as an epoch version. Cc: patc...@linaro.org Cc: Ben Dooks ben-li...@fluff.org Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Andy Green andy.gr...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com --- drivers/i2c/busses/i2c-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index c997c55..d53cd61 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1093,8 +1093,8 @@ omap_i2c_probe(struct platform_device *pdev) goto err_unuse_clocks; } - dev_info(dev-dev, bus %d rev%d.%d at %d kHz\n, -pdev-id, dev-rev 4, dev-rev 0xf, dev-speed); + dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id, +pdata-rev, dev-rev 4, dev-rev 0xf, dev-speed); omap_i2c_idle(dev); -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 13/18] I2C: OMAP2+: Pass flags up to omap i2c platform_data as well
From: Andy Green a...@warmcat.com This is how the driver can find the flags for its implementation functionality in its platform_data Cc: patc...@linaro.org Cc: Ben Dooks ben-li...@fluff.org Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Andy Green andy.gr...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/i2c.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index 0d3eda7..9098669 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -141,6 +141,7 @@ static inline int omap2_i2c_add_bus(int bus_id) struct omap_device *od; char oh_name[MAX_OMAP_I2C_HWMOD_NAME_LEN]; struct omap_i2c_bus_platform_data *pdata; + struct omap_i2c_dev_attr *dev_attr; omap2_i2c_mux_pins(bus_id); @@ -156,10 +157,14 @@ static inline int omap2_i2c_add_bus(int bus_id) pdata = i2c_pdata[bus_id - 1]; /* * pass the hwmod class's CPU-specific knowledge of I2C IP revision in -* use up to the OMAP I2C driver via platform data +* use, and functionality implementation flags, up to the OMAP I2C +* driver via platform data */ pdata-rev = oh-class-rev; + dev_attr = (struct omap_i2c_dev_attr *)oh-dev_attr; + pdata-flags = dev_attr-flags; + /* * When waiting for completion of a i2c transfer, we need to * set a wake up latency constraint for the MPU. This is to -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 16/18] I2C: OMAP1: set i2c unit feature implementation flags in platform data
From: Andy Green a...@warmcat.com Most of the OMAP1 implementation flags are set statically, with the exception that omap7xx has its data bus wired up differently. Cc: patc...@linaro.org Cc: Ben Dooks ben-li...@fluff.org Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Andy Green andy.gr...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/i2c.c | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index 9098669..2388b8e 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -111,6 +111,19 @@ static inline int omap1_i2c_add_bus(int bus_id) /* all OMAP1 have IP version 1 register set */ pdata-rev = OMAP_I2C_IP_VERSION_1; + /* all OMAP1 I2C are implemented like this */ + pdata-flags = OMAP_I2C_FLAG_NO_FIFO | + OMAP_I2C_FLAG_SIMPLE_CLOCK | + OMAP_I2C_FLAG_16BIT_DATA_REG | + OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK; + + /* how the cpu bus is wired up differs for 7xx only */ + + if (cpu_is_omap7xx()) + pdata-flags |= OMAP_I2C_FLAG_BUS_SHIFT_1; + else + pdata-flags |= OMAP_I2C_FLAG_BUS_SHIFT_2; + return platform_device_register(pdev); } -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 14/18] I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test
From: Andy Green a...@warmcat.com
These represent the 8 kinds of implementation functionality
that up until now were inferred by the 16 remaining cpu_...()
tests in the omap i2c driver.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
include/linux/i2c-omap.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 776c8e1..98ae49b 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -15,6 +15,21 @@
#define OMAP_I2C_IP_VERSION_1 1
#define OMAP_I2C_IP_VERSION_2 2
+/* struct omap_i2c_bus_platform_data .flags meanings */
+
+#define OMAP_I2C_FLAG_NO_FIFO 1
+#define OMAP_I2C_FLAG_SIMPLE_CLOCK 2
+#define OMAP_I2C_FLAG_16BIT_DATA_REG 4
+#define OMAP_I2C_FLAG_RESET_REGS_POSTIDLE 8
+#define OMAP_I2C_FLAG_APPLY_ERRATA_I207 0x10
+#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK 0x20
+#define OMAP_I2C_FLAG_FORCE_19200_INT_CLK 0x40
+/* how the CPU address bus must be translated for I2C unit access */
+#define OMAP_I2C_FLAG_BUS_SHIFT_NONE 0
+#define OMAP_I2C_FLAG_BUS_SHIFT_1 0x80
+#define OMAP_I2C_FLAG_BUS_SHIFT_2 0x100
+#define OMAP_I2C_FLAG_BUS_SHIFT__SHIFT 7
+
struct omap_i2c_bus_platform_data {
u32 clkrate;
u32 rev;
--
1.7.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
