Re: [PATCH v2] ARM: OMAP3LOGIC: Adding DSS support
On Tue, 2011-12-13 at 09:52 +0200, Alex wrote:
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD
and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
Overall looks fine. A few questions below about the GPIOs, though.
snip
+static void __init omap3logic_display_init(void)
+{
+ int r;
+
+ r = gpio_request_array(omap3logic_dss_gpios,
+ARRAY_SIZE(omap3logic_dss_gpios));
+ if (r) {
+ printk(KERN_ERR failed to get lcd_panel_* gpios\n);
+ return;
+ }
+
+ gpio_export(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_export(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_export(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
Why do you want to export these GPIOs? They are handled here in the
board file, and I don't think there's any reason the userspace would
need to touch them.
+ gpio_set_value(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
These are already set to 0 in gpio_request_array, as you've defined the
flag GPIOF_OUT_INIT_LOW.
+
+ msleep(50);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 1);
What does this do, and why do you need msleep(50)? I understand
LCD_ENABLE gpio enables the LCD panel, but what exactly do LCD_BACKLIGHT
and LCD_PWM gpios do? Why don't you set/unset LCD_PWM in the panel
enable/disable functions like the other gpios?
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
On Wed, Dec 14, 2011 at 12:56 AM, Kevin Hilman khil...@ti.com wrote: Govindraj govindraj...@gmail.com writes: [...] I have re-based this patch series against LO master commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a Same is available here [1] I have tested this patch series along with: 1.) Tero's V11 irq chaining series http://www.spinics.net/lists/linux-omap/msg61445.html (This patch series is used for uart wakeup handling using prcm_irq chaining) 2.) Rajendra's hwmod change http://www.spinics.net/lists/arm-kernel/msg148632.html (This patch handles init_no_idle flag setting without this patch there will be boot warning however all pm features will work after boot up.) 3.) Vishwa's io daisy chain changes. http://permalink.gmane.org/gmane.linux.ports.arm.omap/65500 (tested with and without this patch series pm features works). Same combination of patches based on above commit id used for testing is available here [2]. Please have a closer look at your branch. The second commit[1] commits the .rej file from a failed patch apply, so obviously doesn't do what was intended. Sorry my bad I have refreshed the uart runtime branch [1] test branch [2]. stat for uart patches for the both the branches as here [3] -- Thanks, Govindraj.R [1]: git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime [2]: git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/tmp_rc4_uart_pm_intg [3]: uart runtime branch ubnuser@ula0131859:~/clones/runtime_3-0$ git diff --stat deee6d5 arch/arm/mach-omap2/board-3430sdp.c | 100 +--- arch/arm/mach-omap2/board-4430sdp.c | 68 +-- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap4panda.c| 68 +-- arch/arm/mach-omap2/cpuidle34xx.c |6 - arch/arm/mach-omap2/pm24xx.c | 20 - arch/arm/mach-omap2/pm34xx.c | 43 -- arch/arm/mach-omap2/serial.c | 907 +++-- arch/arm/plat-omap/include/plat/omap-serial.h | 37 +- arch/arm/plat-omap/include/plat/serial.h | 10 +- drivers/tty/serial/omap-serial.c | 343 -- 11 files changed, 584 insertions(+), 1024 deletions(-) tmp_intg_test branch ubnuser@ula0131859:~/clones/runtime_3-0$ git diff --stat deee6d5..aad8423 arch/arm/mach-omap2/board-3430sdp.c | 100 +--- arch/arm/mach-omap2/board-4430sdp.c | 68 +-- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap4panda.c| 68 +-- arch/arm/mach-omap2/cpuidle34xx.c |6 - arch/arm/mach-omap2/pm24xx.c | 20 - arch/arm/mach-omap2/pm34xx.c | 43 -- arch/arm/mach-omap2/serial.c | 907 +++-- arch/arm/plat-omap/include/plat/omap-serial.h | 37 +- arch/arm/plat-omap/include/plat/serial.h | 10 +- drivers/tty/serial/omap-serial.c | 343 -- 11 files changed, 584 insertions(+), 1024 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] HACK: arm: reprogram twd based on clk notifier
Hi Mike,
I just sent new patches for the TWD CPUfreq stuff, including the bug fix you
provide below for clk_prepare(). They're in Russell's patch tracker:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7210/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7211/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7212/1
On Wed, Dec 14, 2011 at 5:31 AM, Mike Turquette mturque...@ti.com wrote:
The primary purpose behind this change is to test the new clk notifier
code. If you find it useful beyond that, please let me know!
This is way more elegant that the cpufreq way of doing things.
For several years I was confused by TI:s way of re-reading any
peripheral clock speed in CPUfreq notifiers when there was strictly
no theoretical requirement for the CPU to actually change it's frequency
when the clock frequency for that particular device changed.
See for example drivers/mmc/host/davinci_mmc.c:
#ifdef CONFIG_CPU_FREQ
static int mmc_davinci_cpufreq_transition(struct notifier_block *nb,
unsigned long val, void *data)
{
struct mmc_davinci_host *host;
unsigned int mmc_pclk;
struct mmc_host *mmc;
unsigned long flags;
host = container_of(nb, struct mmc_davinci_host, freq_transition);
mmc = host-mmc;
mmc_pclk = clk_get_rate(host-clk);
if (val == CPUFREQ_POSTCHANGE) {
spin_lock_irqsave(mmc-lock, flags);
host-mmc_input_clk = mmc_pclk;
calculate_clk_divider(mmc, mmc-ios);
spin_unlock_irqrestore(mmc-lock, flags);
}
return 0;
}
...what does the CPU has to do with the MMC host-clk again?
Absolutely nothing. There is no point in the MMC framework
knowing that the CPU is changing operating point.
(There is a similar hack in the s3c MMC driver.)
The clk notifiers are the sane way of doing this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
On Wed, Dec 14, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote: Govindraj govindraj...@gmail.com writes: [...] I have re-based this patch series against LO master commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a Same is available here [1] I have tested this patch series along with: 1.) Tero's V11 irq chaining series http://www.spinics.net/lists/linux-omap/msg61445.html (This patch series is used for uart wakeup handling using prcm_irq chaining) 2.) Rajendra's hwmod change http://www.spinics.net/lists/arm-kernel/msg148632.html (This patch handles init_no_idle flag setting without this patch there will be boot warning however all pm features will work after boot up.) Actually, without Rajendra's patch all features do not work. I don't get UART console wakeups from idle (with runtime PM autosuspend enabled) on 3430/n900 or 3530/Overo without Rajendra's patch. okay, I forgot last time when I tested without rajendra's patch was with a custom activate func. and now we have removed it. Yes you are correct Rajendra's patch + Tero's v11 series is a needed for proper uart_runtime_pm functioning. -- Thanks, Govindraj.R -- 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] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi Martin,
On 12/14/11 03:25, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3evm-camera.c | 155
+++
arch/arm/mach-omap2/board-omap3evm.c|4 +
3 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V3
* Added missing copyright and attribution.
* switched to gpio_request_array for gpio init.
* removed device_initcall and added call to omap3_evm_camera_init into
omap3_evm_init
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b009f17..6045789 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -196,7 +196,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_ENCORE)+= board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
-obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
+board-omap3evm-camera.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..bffd5b8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Authors:
+ *Vaibhav Hiremath hvaib...@ti.com
+ *Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C
Bus 2
+ *
+ * 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/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
Laurent,
In one of the previous reviews, you stated:
I'll probably split it and move the part required by board files to
include/media/omap3isp.h.
Is there any progress on that?
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL 157
+
+#define MT9M032_I2C_BUS_NUM 2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
I don't really care about that, but I don't see any mux
being set in the above function so the name and comments
are misleading.
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 1350,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+
[PATCH 00/10] OMAP4: ASoC: Support for PandaBoard family
Hello,
the following series will add ASoC support for PandaBoards.
PandaBoards have different audio routings compared to SDP4430/Blaze boards, but
the differences not that big to justify a new ASoC machine driver.
Main changes:
- Rename the sdp4430 ASoC machine driver to use generic name: omap-abe-twl6040
- Convert the ASoC machine driver to platform driver
- The type of the board, and the desired sound card name is passed via platform
data to the ASoC machine driver
- Based on the board type the driver selects different audio routings
- Registration of the needed platform devices in board files (sdp4403, panda)
After this series the sound card names will be different for easier UCM
integration:
OMAP4-SDP4430 for SDP4430/Blaze boards
OMAP4-Panda for PandaBoard 4430
OMAP4-PandaES for PandaBoard ES (4460)
The series has been tested on Blaze, and PandaBoard ES.
Regards,
Peter
---
Peter Ujfalusi (10):
ASoC: sdp4430: Correct author e-mail address
ASoC: OMAP4: Rename the sdp4430 machine driver
ASoC: omap-abe-twl6040: Correct internal prefix, Kconfig entry
include: platform_data: Platform data header for OMAP4 ASoC audio
OMAP4: 4430sdp: Register platform device for OMAP4 audio
ASoC: omap-abe-twl6040: Convert to platform deriver
ASoC: omap-abe-twl6040: Add support for PandaBoard
OMAP4: omap4panda: Enable audio support
ASoC: omap-abe-twl6040: Add missing audio route information
ASoC: omap-abe-twl6040: Fix DAPM widget type for FM input
arch/arm/mach-omap2/board-4430sdp.c | 15 ++
arch/arm/mach-omap2/board-omap4panda.c | 48 +-
include/linux/platform_data/omap-abe-twl6040.h | 33
sound/soc/omap/Kconfig | 14 +-
sound/soc/omap/Makefile |4 +-
sound/soc/omap/{sdp4430.c = omap-abe-twl6040.c} | 198 --
6 files changed, 251 insertions(+), 61 deletions(-)
create mode 100644 include/linux/platform_data/omap-abe-twl6040.h
rename sound/soc/omap/{sdp4430.c = omap-abe-twl6040.c} (52%)
--
1.7.8
--
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 01/10] ASoC: sdp4430: Correct author e-mail address
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- sound/soc/omap/sdp4430.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/omap/sdp4430.c b/sound/soc/omap/sdp4430.c index 2735fa0..3186e0a 100644 --- a/sound/soc/omap/sdp4430.c +++ b/sound/soc/omap/sdp4430.c @@ -1,7 +1,7 @@ /* * sdp4430.c -- SoC audio for TI OMAP4430 SDP * - * Author: Misael Lopez Cruz x0052...@ti.com + * Author: Misael Lopez Cruz misael.lo...@ti.com * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -272,7 +272,7 @@ static void __exit sdp4430_soc_exit(void) } module_exit(sdp4430_soc_exit); -MODULE_AUTHOR(Misael Lopez Cruz x0052...@ti.com); +MODULE_AUTHOR(Misael Lopez Cruz misael.lo...@ti.com); MODULE_DESCRIPTION(ALSA SoC SDP4430); MODULE_LICENSE(GPL); -- 1.7.8 -- 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 02/10] ASoC: OMAP4: Rename the sdp4430 machine driver
The same machine driver will support other boards
with similar audio configuration (OMAP4, ABE, twl6040).
Rename the driver to have more generic name.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/Kconfig |2 +-
sound/soc/omap/Makefile |4 ++--
sound/soc/omap/{sdp4430.c = omap-abe-twl6040.c} |1 -
3 files changed, 3 insertions(+), 4 deletions(-)
rename sound/soc/omap/{sdp4430.c = omap-abe-twl6040.c} (99%)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index fb1bf25..4eae929 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -97,7 +97,7 @@ config SND_OMAP_SOC_SDP3430
Say Y if you want to add support for SoC audio on Texas Instruments
SDP3430.
-config SND_OMAP_SOC_SDP4430
+config SND_OMAP_SOC_OMAP_ABE_TWL6040
tristate SoC Audio support for Texas Instruments SDP4430
depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP_4430SDP
select SND_OMAP_SOC_DMIC
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index 1fd723f..123ac18 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -20,7 +20,7 @@ snd-soc-overo-objs := overo.o
snd-soc-omap3evm-objs := omap3evm.o
snd-soc-am3517evm-objs := am3517evm.o
snd-soc-sdp3430-objs := sdp3430.o
-snd-soc-sdp4430-objs := sdp4430.o
+snd-soc-omap-abe-twl6040-objs := omap-abe-twl6040.o
snd-soc-omap3pandora-objs := omap3pandora.o
snd-soc-omap3beagle-objs := omap3beagle.o
snd-soc-zoom2-objs := zoom2.o
@@ -36,7 +36,7 @@ obj-$(CONFIG_SND_OMAP_SOC_OMAP2EVM) += snd-soc-omap2evm.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3EVM) += snd-soc-omap3evm.o
obj-$(CONFIG_SND_OMAP_SOC_AM3517EVM) += snd-soc-am3517evm.o
obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o
-obj-$(CONFIG_SND_OMAP_SOC_SDP4430) += snd-soc-sdp4430.o
+obj-$(CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040) += snd-soc-omap-abe-twl6040.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o
obj-$(CONFIG_SND_OMAP_SOC_ZOOM2) += snd-soc-zoom2.o
diff --git a/sound/soc/omap/sdp4430.c b/sound/soc/omap/omap-abe-twl6040.c
similarity index 99%
rename from sound/soc/omap/sdp4430.c
rename to sound/soc/omap/omap-abe-twl6040.c
index 3186e0a..67c1709 100644
--- a/sound/soc/omap/sdp4430.c
+++ b/sound/soc/omap/omap-abe-twl6040.c
@@ -275,4 +275,3 @@ module_exit(sdp4430_soc_exit);
MODULE_AUTHOR(Misael Lopez Cruz misael.lo...@ti.com);
MODULE_DESCRIPTION(ALSA SoC SDP4430);
MODULE_LICENSE(GPL);
-
--
1.7.8
--
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 03/10] ASoC: omap-abe-twl6040: Correct internal prefix, Kconfig entry
Change the internal prefixes within the driver from sdp4430.
At he same time correct the Kconfig text as well.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/Kconfig|7 ++--
sound/soc/omap/omap-abe-twl6040.c | 65 +++--
2 files changed, 37 insertions(+), 35 deletions(-)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 4eae929..98410b8 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -98,15 +98,16 @@ config SND_OMAP_SOC_SDP3430
SDP3430.
config SND_OMAP_SOC_OMAP_ABE_TWL6040
- tristate SoC Audio support for Texas Instruments SDP4430
+ tristate SoC Audio support for OMAP boards using ABE and twl6040 codec
depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP_4430SDP
select SND_OMAP_SOC_DMIC
select SND_OMAP_SOC_MCPDM
select SND_SOC_TWL6040
select SND_SOC_DMIC
help
- Say Y if you want to add support for SoC audio on Texas Instruments
- SDP4430.
+ Say Y if you want to add support for SoC audio on OMAP boards using
+ ABE and twl6040 codec. This driver currently supports:
+ - SDP4430/Blaze boards
config SND_OMAP_SOC_OMAP4_HDMI
tristate SoC Audio support for Texas Instruments OMAP4 HDMI
diff --git a/sound/soc/omap/omap-abe-twl6040.c
b/sound/soc/omap/omap-abe-twl6040.c
index 67c1709..9c6d97a 100644
--- a/sound/soc/omap/omap-abe-twl6040.c
+++ b/sound/soc/omap/omap-abe-twl6040.c
@@ -1,5 +1,6 @@
/*
- * sdp4430.c -- SoC audio for TI OMAP4430 SDP
+ * omap-abe-twl6040.c -- SoC audio for TI OMAP based boards with ABE and
+ *twl6040 codec
*
* Author: Misael Lopez Cruz misael.lo...@ti.com
*
@@ -38,7 +39,7 @@
#include omap-pcm.h
#include ../codecs/twl6040.h
-static int sdp4430_hw_params(struct snd_pcm_substream *substream,
+static int omapabe_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
@@ -64,11 +65,11 @@ static int sdp4430_hw_params(struct snd_pcm_substream
*substream,
return ret;
}
-static struct snd_soc_ops sdp4430_ops = {
- .hw_params = sdp4430_hw_params,
+static struct snd_soc_ops omapabe_ops = {
+ .hw_params = omapabe_hw_params,
};
-static int sdp4430_dmic_hw_params(struct snd_pcm_substream *substream,
+static int omapabe_dmic_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
@@ -90,8 +91,8 @@ static int sdp4430_dmic_hw_params(struct snd_pcm_substream
*substream,
return 0;
}
-static struct snd_soc_ops sdp4430_dmic_ops = {
- .hw_params = sdp4430_dmic_hw_params,
+static struct snd_soc_ops omapabe_dmic_ops = {
+ .hw_params = omapabe_dmic_hw_params,
};
/* Headset jack */
@@ -110,7 +111,7 @@ static struct snd_soc_jack_pin hs_jack_pins[] = {
};
/* SDP4430 machine DAPM */
-static const struct snd_soc_dapm_widget sdp4430_twl6040_dapm_widgets[] = {
+static const struct snd_soc_dapm_widget twl6040_dapm_widgets[] = {
SND_SOC_DAPM_MIC(Ext Mic, NULL),
SND_SOC_DAPM_SPK(Ext Spk, NULL),
SND_SOC_DAPM_MIC(Headset Mic, NULL),
@@ -145,7 +146,7 @@ static const struct snd_soc_dapm_route audio_map[] = {
{AFMR, NULL, FM Stereo In},
};
-static int sdp4430_twl6040_init(struct snd_soc_pcm_runtime *rtd)
+static int omapabe_twl6040_init(struct snd_soc_pcm_runtime *rtd)
{
struct snd_soc_codec *codec = rtd-codec;
int ret, hs_trim;
@@ -175,7 +176,7 @@ static int sdp4430_twl6040_init(struct snd_soc_pcm_runtime
*rtd)
return ret;
}
-static const struct snd_soc_dapm_widget sdp4430_dmic_dapm_widgets[] = {
+static const struct snd_soc_dapm_widget dmic_dapm_widgets[] = {
SND_SOC_DAPM_MIC(Digital Mic, NULL),
};
@@ -184,14 +185,14 @@ static const struct snd_soc_dapm_route dmic_audio_map[] =
{
{Digital Mic1 Bias, NULL, Digital Mic},
};
-static int sdp4430_dmic_init(struct snd_soc_pcm_runtime *rtd)
+static int omapabe_dmic_init(struct snd_soc_pcm_runtime *rtd)
{
struct snd_soc_codec *codec = rtd-codec;
struct snd_soc_dapm_context *dapm = codec-dapm;
int ret;
- ret = snd_soc_dapm_new_controls(dapm, sdp4430_dmic_dapm_widgets,
- ARRAY_SIZE(sdp4430_dmic_dapm_widgets));
+ ret = snd_soc_dapm_new_controls(dapm, dmic_dapm_widgets,
+ ARRAY_SIZE(dmic_dapm_widgets));
if (ret)
return ret;
@@ -208,8 +209,8 @@ static struct snd_soc_dai_link sdp4430_dai[] = {
.codec_dai_name = twl6040-legacy,
.platform_name = omap-pcm-audio,
.codec_name = twl6040-codec,
- .init = sdp4430_twl6040_init,
- .ops = sdp4430_ops,
+ .init = omapabe_twl6040_init,
[PATCH 04/10] include: platform_data: Platform data header for OMAP4 ASoC audio
Include file to be used with the upcoming ASoC machine driver
for OMAP platform using ABE with twl6040 codec.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/platform_data/omap-abe-twl6040.h | 33
1 files changed, 33 insertions(+), 0 deletions(-)
create mode 100644 include/linux/platform_data/omap-abe-twl6040.h
diff --git a/include/linux/platform_data/omap-abe-twl6040.h
b/include/linux/platform_data/omap-abe-twl6040.h
new file mode 100644
index 000..afbdff4
--- /dev/null
+++ b/include/linux/platform_data/omap-abe-twl6040.h
@@ -0,0 +1,33 @@
+/**
+ * omap-abe-twl6040.h - ASoC machine driver OMAP4+ devices, header.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * All rights reserved.
+ *
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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
+ */
+
+enum board_type {
+ OMAP_ABE_TWL6040_SDP4430,
+ OMAP_ABE_TWL6040_PANDA,
+ OMAP_ABE_TWL6040_PANDA_ES,
+};
+
+struct omap_abe_twl6040_data {
+ char *card_name;
+ enum board_type board;
+};
--
1.7.8
--
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 05/10] OMAP4: 4430sdp: Register platform device for OMAP4 audio
To avoid breakage in audio support with the coming change
in ASoC machine driver (conversion to platfrom device).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 271e50b..69708a4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -25,6 +25,7 @@
#include linux/regulator/fixed.h
#include linux/leds.h
#include linux/leds_pwm.h
+#include linux/platform_data/omap-abe-twl6040.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -377,12 +378,26 @@ static struct platform_device sdp4430_dmic_codec = {
.id = -1,
};
+static struct omap_abe_twl6040_data sdp4430_abe_audio_data = {
+ .card_name = OMAP4-SDP4430,
+ .board = OMAP_ABE_TWL6040_SDP4430,
+};
+
+static struct platform_device sdp4430_abe_audio = {
+ .name = omap-abe-twl6040,
+ .id = -1,
+ .dev = {
+ .platform_data = sdp4430_abe_audio_data,
+ },
+};
+
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
sdp4430_leds_pwm,
sdp4430_vbat,
sdp4430_dmic_codec,
+ sdp4430_abe_audio,
};
static struct omap_musb_board_data musb_board_data = {
--
1.7.8
--
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 06/10] ASoC: omap-abe-twl6040: Convert to platform deriver
Convert the OMAP4 ABE/TWL6040 machine driver to platform
driver.
For the card name use the string provided via platform data.
The card's name for OMAP4 SDP4430 has been changed:
SDP4430 - OMAP4-SDP4430
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-abe-twl6040.c | 59 ++--
1 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/sound/soc/omap/omap-abe-twl6040.c
b/sound/soc/omap/omap-abe-twl6040.c
index 9c6d97a..4974ea1 100644
--- a/sound/soc/omap/omap-abe-twl6040.c
+++ b/sound/soc/omap/omap-abe-twl6040.c
@@ -23,6 +23,7 @@
#include linux/clk.h
#include linux/platform_device.h
#include linux/mfd/twl6040.h
+#include linux/platform_data/omap-abe-twl6040.h
#include linux/module.h
#include sound/core.h
@@ -226,7 +227,6 @@ static struct snd_soc_dai_link sdp4430_dai[] = {
/* Audio machine driver */
static struct snd_soc_card omapabe_card = {
- .name = SDP4430,
.dai_link = sdp4430_dai,
.num_links = ARRAY_SIZE(sdp4430_dai),
@@ -236,43 +236,56 @@ static struct snd_soc_card omapabe_card = {
.num_dapm_routes = ARRAY_SIZE(audio_map),
};
-static struct platform_device *omapabe_snd_device;
-
-static int __init omapabe_soc_init(void)
+static __devinit int omapabe_probe(struct platform_device *pdev)
{
+ struct omap_abe_twl6040_data *pdata = dev_get_platdata(pdev-dev);
+ struct snd_soc_card *card = omapabe_card;
int ret;
- if (!machine_is_omap_4430sdp())
- return -ENODEV;
- printk(KERN_INFO SDP4430 SoC init\n);
+ card-dev = pdev-dev;
- omapabe_snd_device = platform_device_alloc(soc-audio, -1);
- if (!omapabe_snd_device) {
- printk(KERN_ERR Platform device allocation failed\n);
- return -ENOMEM;
+ if (!pdata) {
+ dev_err(pdev-dev, Missing pdata\n);
+ return -ENODEV;
}
- platform_set_drvdata(omapabe_snd_device, omapabe_card);
+ if (pdata-card_name) {
+ card-name = pdata-card_name;
+ } else {
+ dev_err(pdev-dev, Card name is not provided\n);
+ return -ENODEV;
+ }
- ret = platform_device_add(omapabe_snd_device);
+ ret = snd_soc_register_card(card);
if (ret)
- goto err;
-
- return 0;
+ dev_err(pdev-dev, snd_soc_register_card() failed: %d\n,
+ ret);
-err:
- printk(KERN_ERR Unable to add platform device\n);
- platform_device_put(omapabe_snd_device);
return ret;
}
-module_init(omapabe_soc_init);
-static void __exit omapabe_soc_exit(void)
+static int __devexit omapabe_remove(struct platform_device *pdev)
{
- platform_device_unregister(omapabe_snd_device);
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+ snd_soc_unregister_card(card);
+
+ return 0;
}
-module_exit(omapabe_soc_exit);
+
+static struct platform_driver omapabe_driver = {
+ .driver = {
+ .name = omap-abe-twl6040,
+ .owner = THIS_MODULE,
+ .pm = snd_soc_pm_ops,
+ },
+ .probe = omapabe_probe,
+ .remove = __devexit_p(omapabe_remove),
+};
+
+module_platform_driver(omapabe_driver);
MODULE_AUTHOR(Misael Lopez Cruz misael.lo...@ti.com);
MODULE_DESCRIPTION(ALSA SoC for OMAP boards with ABE and twl6040 codec);
MODULE_LICENSE(GPL);
+MODULE_ALIAS(platform:omap-abe-twl6040);
--
1.7.8
--
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 07/10] ASoC: omap-abe-twl6040: Add support for PandaBoard
PandaBoard has a bit different set of audio features compared
to SDP4430:
- No DMIC
- Earphone pins are not connected
- Vibra is not connected
On PandaBoard 4430:
- FM receiver is connected to AFML/R input
- FM transmitter is connected to AUXL/R output
- Input jack is connected as to HSMIC
On PandaBoard ES:
- FM receiver/transmitter is not connected
- Input jack is connected to AFML/R
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/Kconfig|5 ++-
sound/soc/omap/omap-abe-twl6040.c | 82 ++---
2 files changed, 80 insertions(+), 7 deletions(-)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 98410b8..3463ee2 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -99,7 +99,8 @@ config SND_OMAP_SOC_SDP3430
config SND_OMAP_SOC_OMAP_ABE_TWL6040
tristate SoC Audio support for OMAP boards using ABE and twl6040 codec
- depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP_4430SDP
+ depends on TWL4030_CORE SND_OMAP_SOC
+ depends on MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
select SND_OMAP_SOC_DMIC
select SND_OMAP_SOC_MCPDM
select SND_SOC_TWL6040
@@ -108,6 +109,8 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040
Say Y if you want to add support for SoC audio on OMAP boards using
ABE and twl6040 codec. This driver currently supports:
- SDP4430/Blaze boards
+ - PandaBoard 4430
+ - PandaBoard ES (4460)
config SND_OMAP_SOC_OMAP4_HDMI
tristate SoC Audio support for Texas Instruments OMAP4 HDMI
diff --git a/sound/soc/omap/omap-abe-twl6040.c
b/sound/soc/omap/omap-abe-twl6040.c
index 4974ea1..25a75f3 100644
--- a/sound/soc/omap/omap-abe-twl6040.c
+++ b/sound/soc/omap/omap-abe-twl6040.c
@@ -119,9 +119,11 @@ static const struct snd_soc_dapm_widget
twl6040_dapm_widgets[] = {
SND_SOC_DAPM_HP(Headset Stereophone, NULL),
SND_SOC_DAPM_SPK(Earphone Spk, NULL),
SND_SOC_DAPM_INPUT(FM Stereo In),
+ SND_SOC_DAPM_LINE(FM Stereo Out, NULL),
+ SND_SOC_DAPM_LINE(Line In, NULL),
};
-static const struct snd_soc_dapm_route audio_map[] = {
+static const struct snd_soc_dapm_route sdp4430_audio_map[] = {
/* External Mics: MAINMIC, SUBMIC with bias*/
{MAINMIC, NULL, Main Mic Bias},
{SUBMIC, NULL, Main Mic Bias},
@@ -147,6 +149,42 @@ static const struct snd_soc_dapm_route audio_map[] = {
{AFMR, NULL, FM Stereo In},
};
+static const struct snd_soc_dapm_route panda_audio_map[] = {
+ /* External Speakers: HFL, HFR - through expansion connector */
+ {Ext Spk, NULL, HFL},
+ {Ext Spk, NULL, HFR},
+
+ /* Headset Mic: HSMIC with bias */
+ {HSMIC, NULL, Headset Mic Bias},
+ {Headset Mic Bias, NULL, Headset Mic},
+
+ /* Headset Stereophone (Headphone): HSOL, HSOR */
+ {Headset Stereophone, NULL, HSOL},
+ {Headset Stereophone, NULL, HSOR},
+
+ /* Aux/FM Stereo In: AFML, AFMR */
+ {AFML, NULL, FM Stereo In},
+ {AFMR, NULL, FM Stereo In},
+
+ /* AUXL/R output to FM transmitter */
+ {FM Stereo Out, NULL, AUXL},
+ {FM Stereo Out, NULL, AUXR},
+};
+
+static const struct snd_soc_dapm_route pandaes_audio_map[] = {
+ /* External Speakers: HFL, HFR - through expansion connector */
+ {Ext Spk, NULL, HFL},
+ {Ext Spk, NULL, HFR},
+
+ /* Headset Stereophone (Headphone): HSOL, HSOR */
+ {Headset Stereophone, NULL, HSOL},
+ {Headset Stereophone, NULL, HSOR},
+
+ /* Line in jack: AFML, AFMR */
+ {AFML, NULL, Line In},
+ {AFMR, NULL, Line In},
+};
+
static int omapabe_twl6040_init(struct snd_soc_pcm_runtime *rtd)
{
struct snd_soc_codec *codec = rtd-codec;
@@ -225,15 +263,23 @@ static struct snd_soc_dai_link sdp4430_dai[] = {
},
};
+static struct snd_soc_dai_link panda_dai[] = {
+ {
+ .name = TWL6040,
+ .stream_name = TWL6040,
+ .cpu_dai_name = omap-mcpdm,
+ .codec_dai_name = twl6040-legacy,
+ .platform_name = omap-pcm-audio,
+ .codec_name = twl6040-codec,
+ .init = omapabe_twl6040_init,
+ .ops = omapabe_ops,
+ },
+};
+
/* Audio machine driver */
static struct snd_soc_card omapabe_card = {
- .dai_link = sdp4430_dai,
- .num_links = ARRAY_SIZE(sdp4430_dai),
-
.dapm_widgets = twl6040_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(twl6040_dapm_widgets),
- .dapm_routes = audio_map,
- .num_dapm_routes = ARRAY_SIZE(audio_map),
};
static __devinit int omapabe_probe(struct platform_device *pdev)
@@ -256,6 +302,30 @@ static __devinit int omapabe_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ switch (pdata-board) {
+ case OMAP_ABE_TWL6040_SDP4430:
+ card-dai_link = sdp4430_dai;
+ card-num_links =
[PATCH 08/10] OMAP4: omap4panda: Enable audio support
PandaBoard has twl6040 codec for audio.
Register the omap4-abe-twl6040 platform device.
Add platform data to enable the twl6040 codec.
Since there is a difference in audio between PandaBoard 4430
and PandaBoard ES (4460):
Use different name for the sound card:
OMAP4-Panda for PandaBoard 4430
OMAP4-PandaES for PandaBoard ES
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
board: audio for panda
---
arch/arm/mach-omap2/board-omap4panda.c | 48 +++-
1 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a8c2c42..6331626 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -28,6 +28,7 @@
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
#include linux/wl12xx.h
+#include linux/platform_data/omap-abe-twl6040.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -90,9 +91,23 @@ static struct platform_device leds_gpio = {
},
};
+static struct omap_abe_twl6040_data panda_abe_audio_data = {
+ .card_name = OMAP4-Panda,
+ .board = OMAP_ABE_TWL6040_PANDA,
+};
+
+static struct platform_device panda_abe_audio = {
+ .name = omap-abe-twl6040,
+ .id = -1,
+ .dev = {
+ .platform_data = panda_abe_audio_data,
+ },
+};
+
static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
wl1271_device,
+ panda_abe_audio,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
@@ -251,8 +266,25 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
return 0;
}
+static struct twl4030_codec_data twl6040_codec = {
+ /* single-step ramp for headset and handsfree */
+ .hs_left_step = 0x0f,
+ .hs_right_step = 0x0f,
+ .hf_left_step = 0x1d,
+ .hf_right_step = 0x1d,
+};
+
+static struct twl4030_audio_data twl6040_audio = {
+ .codec = twl6040_codec,
+ .audpwron_gpio = 127,
+ .naudint_irq= OMAP44XX_IRQ_SYS_2N,
+ .irq_base = TWL6040_CODEC_IRQ_BASE,
+};
+
/* Panda board uses the common PMIC configuration */
-static struct twl4030_platform_data omap4_panda_twldata;
+static struct twl4030_platform_data omap4_panda_twldata = {
+ .audio = twl6040_audio,
+};
/*
* Display monitor features are burnt in their EEPROM as EDID data. The EEPROM
@@ -548,6 +580,19 @@ void omap4_panda_display_init(void)
omap_display_init(omap4_panda_dss_data);
}
+static void omap4_panda_audio_init(void)
+{
+ if (cpu_is_omap4430()) {
+ /* PandaBoard 4430 */
+ panda_abe_audio_data.card_name = OMAP4-Panda;
+ panda_abe_audio_data.board = OMAP_ABE_TWL6040_PANDA;
+ } else {
+ /* PandaBoard ES */
+ panda_abe_audio_data.card_name = OMAP4-PandaES;
+ panda_abe_audio_data.board = OMAP_ABE_TWL6040_PANDA_ES;
+ }
+}
+
static void __init omap4_panda_init(void)
{
int package = OMAP_PACKAGE_CBS;
@@ -560,6 +605,7 @@ static void __init omap4_panda_init(void)
pr_err(error setting wl12xx data\n);
omap4_panda_i2c_init();
+ omap4_panda_audio_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
platform_device_register(omap_vwlan_device);
board_serial_init();
--
1.7.8
--
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 09/10] ASoC: omap-abe-twl6040: Add missing audio route information
AUXL/R: connected to FM transmitter on SDP4430
Vibra: connected to vibrator drivers (only SDP4430)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-abe-twl6040.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-abe-twl6040.c
b/sound/soc/omap/omap-abe-twl6040.c
index 25a75f3..05c6474 100644
--- a/sound/soc/omap/omap-abe-twl6040.c
+++ b/sound/soc/omap/omap-abe-twl6040.c
@@ -121,6 +121,7 @@ static const struct snd_soc_dapm_widget
twl6040_dapm_widgets[] = {
SND_SOC_DAPM_INPUT(FM Stereo In),
SND_SOC_DAPM_LINE(FM Stereo Out, NULL),
SND_SOC_DAPM_LINE(Line In, NULL),
+ SND_SOC_DAPM_SPK(Vibrators, NULL),
};
static const struct snd_soc_dapm_route sdp4430_audio_map[] = {
@@ -147,6 +148,14 @@ static const struct snd_soc_dapm_route sdp4430_audio_map[]
= {
/* Aux/FM Stereo In: AFML, AFMR */
{AFML, NULL, FM Stereo In},
{AFMR, NULL, FM Stereo In},
+
+ /* AUXL/R output to FM transmitter */
+ {FM Stereo Out, NULL, AUXL},
+ {FM Stereo Out, NULL, AUXR},
+
+ /* Vibra outputs */
+ {Vibrators, NULL, VIBRAL},
+ {Vibrators, NULL, VIBRAR},
};
static const struct snd_soc_dapm_route panda_audio_map[] = {
--
1.7.8
--
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 04/10] include: platform_data: Platform data header for OMAP4 ASoC audio
On Wed, Dec 14, 2011 at 11:46:57AM +0200, Peter Ujfalusi wrote:
+enum board_type {
+ OMAP_ABE_TWL6040_SDP4430,
+ OMAP_ABE_TWL6040_PANDA,
+ OMAP_ABE_TWL6040_PANDA_ES,
+};
It seems like it might better in the long run to make this feature based
rather than enumerating the individual boards - that means that if
boards mix and match the features or add features on the side of
additional designs (eg, external amplifiers that need power control)
it's easier to scale the options.
--
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 06/10] ASoC: omap-abe-twl6040: Convert to platform deriver
On Wed, Dec 14, 2011 at 11:46:59AM +0200, Peter Ujfalusi wrote: The card's name for OMAP4 SDP4430 has been changed: SDP4430 - OMAP4-SDP4430 Why? The board appaers to be generally known as SDP4430... -- 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: [PATCHv11 1/8] ARM: OMAP2+: hwmod: Add API to enable IO ring wakeup.
On Tue, 2011-12-13 at 19:34 -0700, Paul Walmsley wrote:
Hi
so I've updated this patch to change the SCM PADCTRL registers if the
hwmod is currently idle, and _set_idle_ioring_wakeup() is called.
Otherwise calling _set_idle_ioring_wakeup() would be useless under those
conditions, since the new I/O ring wakeup values wouldn't be written back
to the hardware until the hwmod had gone through an idle-enabled and
enabled-idle transition.
Please try to consider the function's appropriate behavior under which
these functions can be called...
Updated patch below. Will update internally once I get Tero's
Signed-off-by:.
Hi Paul,
Patch looks okay to me, I also quickly tested it out and it works.
Signed-off-by: Tero Kristo t-kri...@ti.com
- Paul
From: Govindraj R govindraj.r...@ti.com
Date: Tue, 13 Dec 2011 13:50:23 -0700
Subject: [PATCH] ARM: OMAP2+: hwmod: Add API to enable IO ring wakeup
Add API to enable IO pad wakeup capability based on mux pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability for the given
pads. Wakeup capability will be enabled/disabled during hwmod idle
transition based on whether wakeup_flag is set or cleared. If the
hwmod is currently idled, and any mux values were changed by
_set_idle_ioring_wakeup(), the SCM PADCTRL registers will be updated.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
XXX Tero's sign-off?
[p...@pwsan.com: rearranged code to limit indentation; cleaned up
function documentation; removed unused non-static functions; modified
to search all hwmod pads, not just dynamic remuxing ones; modified to
update SCM regs if hwmod is currently idle and any pads have changed]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 47
++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 207a2ff..21ffd8a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -381,6 +381,51 @@ static int _set_module_autoidle(struct omap_hwmod *oh,
u8 autoidle,
}
/**
+ * _set_idle_ioring_wakeup - enable/disable IO pad wakeup on hwmod idle for
mux
+ * @oh: struct omap_hwmod *
+ * @set_wake: bool value indicating to set (true) or clear (false) wakeup
enable
+ *
+ * Set or clear the I/O pad wakeup flag in the mux entries for the
+ * hwmod @oh. This function changes the @oh-mux-pads_dynamic array
+ * in memory. If the hwmod is currently idled, and the new idle
+ * values don't match the previous ones, this function will also
+ * update the SCM PADCTRL registers. Otherwise, if the hwmod is not
+ * currently idled, this function won't touch the hardware: the new
+ * mux settings are written to the SCM PADCTRL registers when the
+ * hwmod is idled. No return value.
+ */
+static void _set_idle_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ struct omap_device_pad *pad;
+ bool change = false;
+ u16 prev_idle;
+ int j;
+
+ if (!oh-mux || !oh-mux-enabled)
+ return;
+
+ for (j = 0; j oh-mux-nr_pads_dynamic; j++) {
+ pad = oh-mux-pads_dynamic[j];
+
+ if (!(pad-flags OMAP_DEVICE_PAD_WAKEUP))
+ continue;
+
+ prev_idle = pad-idle;
+
+ if (set_wake)
+ pad-idle |= OMAP_WAKEUP_EN;
+ else
+ pad-idle = ~OMAP_WAKEUP_EN;
+
+ if (prev_idle != pad-idle)
+ change = true;
+ }
+
+ if (change oh-_state == _HWMOD_STATE_IDLE)
+ omap_hwmod_mux(oh-mux, _HWMOD_STATE_IDLE);
+}
+
+/**
* _enable_wakeup: set OCP_SYSCONFIG.ENAWAKEUP bit in the hardware
* @oh: struct omap_hwmod *
*
@@ -2416,6 +2461,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_enable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ _set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
@@ -2446,6 +2492,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_disable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ _set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] ASoC: sdp4430: Correct author e-mail address
On Wed, Dec 14, 2011 at 11:46:54AM +0200, Peter Ujfalusi wrote: Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv11 2/8] ARM: OMAP2+: hwmod: Add API to check IO PAD wakeup status
On Tue, 2011-12-13 at 20:04 -0700, Paul Walmsley wrote:
Hi Tero
looking at this patch:
On Mon, 12 Dec 2011, Tero Kristo wrote:
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
It seems that your last patch drops the following code that this patch
adds:
Hmm yea true, it seems like the code in patch 2 does not exist anymore
after patch 8, and well, the code in patch 2 was never used for anything
anyway. Sorry for not spotting this myself, I added patch 8 in hurry to
this set.
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 8d37d83..d7f4623 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2721,3 +2721,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+ if (oh oh-mux)
+ return omap_hwmod_mux_get_wake_status(oh-mux);
+ return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8b372ed..1b81dfb 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -604,6 +604,7 @@ int omap_hwmod_get_context_loss_count(struct omap_hwmod
*oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
* to use initcalls once the initial boot ordering is straightened out
It's best in these circumstances to modify this patch not to add the code
in the first place. Otherwise this creates needless churn which plenty of
people are quite sensitized to. So, dropping these from patch 2.
Yeah, good call.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 09/10] ASoC: omap-abe-twl6040: Add missing audio route information
On Wed, Dec 14, 2011 at 11:47:02AM +0200, Peter Ujfalusi wrote: AUXL/R: connected to FM transmitter on SDP4430 Vibra: connected to vibrator drivers (only SDP4430) This is an example of the sort of thing I was talking about with the platform data - if someone does a variant of SDP4430 with the FM transmitter removed they'd have to add a completely new board definition. -- 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: Re: [PATCH 06/10] ASoC: omap-abe-twl6040: Convert to platform deriver
On Wednesday 14 December 2011 18:01:00 Mark Brown wrote: On Wed, Dec 14, 2011 at 11:46:59AM +0200, Peter Ujfalusi wrote: The card's name for OMAP4 SDP4430 has been changed: SDP4430 - OMAP4-SDP4430 Why? The board appaers to be generally known as SDP4430... At the moment we do not have users using the audio on top of the upstream kernel. All distributions are using patched kernel with ABE support. In there the audio card is know as SDP4430, and we have the UCM profile for the ABE version of the OMAP4 boards there which will not work on the upstream kernel since we do not have yet the ABE in mainline kernel. My plan is to add the UCM files for the upstream version of the driver which will be updated as soon we got new features (like the ABE support). It is easier for distros also to move, when time comes to the new kernel. -- 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: [PATCHv11 2/8] ARM: OMAP2+: hwmod: Add API to check IO PAD wakeup status
On Tue, 2011-12-13 at 14:48 -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [111213 14:06]:
On Tue, 13 Dec 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [111213 13:44]:
On Mon, 12 Dec 2011, Tero Kristo wrote:
So the patch description says:
From: R, Govindraj govindraj.r...@ti.com
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
But the code does:
+ for (i = 0; i hmux-nr_pads; i++) {
+ struct omap_device_pad *pad = hmux-pads[i];
which is going to check all of the pads, not just the dynamic ones.
So it seems to me that we need to decide whether this code should be
testing all the pads, or just the dynamically remuxed ones. The same
thing should be decided for the code in patch 1.
Naïvely it seems to me that we want to test all of the pads in both
patches 1 and 2, not just the dynamically remuxable ones. Comments?
You're right, it should be only the dynamic ones.
Hmm, looks to me like it should check all of them? Can't a pad be marked
with OMAP_DEVICE_PAD_WAKEUP, but not be marked with OMAP_DEVICE_PAD_REMUX?
In that case it would not end up on the dynamic list, right?
Hmm yes that's even more true :) Maybe the right approach would be to
copy the OMAP_DEVICE_PAD_WAKEUP pins also to the dynamic list to
avoid going through all of them.
Yea, all pads that have WAKEUP capability should be checked. Not sure if
this comment is valid anymore seeing patch 2 is kind of irrelevant with
patch 8, but the code that scans wakeups should check them all.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] ASoC: OMAP4: Rename the sdp4430 machine driver
On Wed, Dec 14, 2011 at 11:46:55AM +0200, Peter Ujfalusi wrote: The same machine driver will support other boards with similar audio configuration (OMAP4, ABE, twl6040). Rename the driver to have more generic name. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Though given that ABE is part of the OMAP4 silicon it seems silly to include it in the name, it's like calling it omap4-abe-mcpdm- and so on. -- 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 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Sunday 11 of December 2011 at 21:11:59, Janusz Krzysztofik wrote:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Please ignore this patch, I'm going to submit a replacement, based on an
alternative approach suggested by Tony.
Thanks,
Janusz
Created against linux-3.2-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/gpio/gpio-generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 4e24436..a6eaf38 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -528,7 +528,7 @@ static int __init bgpio_platform_init(void)
{
return platform_driver_register(bgpio_driver);
}
-module_init(bgpio_platform_init);
+postcore_initcall(bgpio_platform_init);
static void __exit bgpio_platform_exit(void)
{
--
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: Re: [PATCH 06/10] ASoC: omap-abe-twl6040: Convert to platform deriver
On Wed, Dec 14, 2011 at 12:15:58PM +0200, Péter Ujfalusi wrote: On Wednesday 14 December 2011 18:01:00 Mark Brown wrote: Why? The board appaers to be generally known as SDP4430... At the moment we do not have users using the audio on top of the upstream kernel. All distributions are using patched kernel with ABE support. In there the audio card is know as SDP4430, and we have the UCM profile for the ABE version of the OMAP4 boards there which will not work on the upstream kernel since we do not have yet the ABE in mainline kernel. My plan is to add the UCM files for the upstream version of the driver which will be updated as soon we got new features (like the ABE support). It is easier for distros also to move, when time comes to the new kernel. This seems like we need a better system for doing this, we can't go changing the machine name every time there's a kernel space change that affects a UCM file, that's going to get crazy. Not quite sure what the best approach is here - version specific directories perhaps, or some method of keying off the presence of certain controls. -- 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 REPOST 0/5] Refactor common Kconfigs for easier maintenance
Common Kconfig options which depend on a long list of board- and SoC- specific Kconfigs can be cumbersome to maintain, leading to annoying merge conflicts (although rather trivial ones). This series factors out the dependencies of CACHE_L2X0 and SMP so that the knowledge about when these can be enabled is moved to the relevant board/SoC Kconfig files instead. New MIGHT_HAVE_CACHE_L2X0 and HAVE_SMP options are defined to mediate the dependencies. This series has been substantially reworked compared with the previous post, and is now in two parts: * The first two patches simply refactor the way the Kconfig options for CACHE_L2X0 and SMP are implemented, without making any other changes. * The final three patches apply functional changes suggested by the contributors to this series, to make the config dependencies more correct for some specific boards. Thanks to Rob Herring, Shawn Guo and Russell King for their contributions to this series. Thanks also to David Brown for pointing out the lack of a comprehensive CC list. I have briefly build-tested on some of the affected boards, but any further reviews or Tested-Bys would be much appreciated. Dave Martin (5): ARM: l2x0/pl310: Refactor Kconfig to be more maintainable ARM: SMP: Refactor Kconfig to be more maintainable omap4: Unconditionally require l2x0 L2 cache controller support highbank: Unconditionally require l2x0 L2 cache controller support imx6q: Remove unconditional dependency on l2x0 L2 cache support arch/arm/Kconfig | 23 +++ arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-imx/Kconfig |3 ++- arch/arm/mach-msm/Kconfig |1 + arch/arm/mach-omap2/Kconfig|2 ++ arch/arm/mach-realview/Kconfig |9 + arch/arm/mach-vexpress/Kconfig |2 ++ arch/arm/mm/Kconfig| 15 --- arch/arm/plat-mxc/Kconfig |1 + 9 files changed, 46 insertions(+), 12 deletions(-) -- 1.7.4.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 v4 REPOST 1/5] ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other. Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select CACHE_L2X0 directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/Kconfig |8 arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-realview/Kconfig |5 + arch/arm/mach-vexpress/Kconfig |1 + arch/arm/mm/Kconfig| 15 --- arch/arm/plat-mxc/Kconfig |1 + 7 files changed, 25 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 44789ef..16a4b9e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -344,6 +344,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards. @@ -361,6 +362,7 @@ config ARCH_CNS3XXX select CPU_V6K select GENERIC_CLOCKEVENTS select ARM_GIC + select MIGHT_HAVE_CACHE_L2X0 select MIGHT_HAVE_PCI select PCI_DOMAINS if PCI help @@ -381,6 +383,7 @@ config ARCH_PRIMA2 select GENERIC_CLOCKEVENTS select CLKDEV_LOOKUP select GENERIC_IRQ_CHIP + select MIGHT_HAVE_CACHE_L2X0 select USE_OF select ZONE_DMA help @@ -633,6 +636,7 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SCHED_CLOCK + select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ help This enables support for NVIDIA Tegra based systems (Tegra APX, @@ -703,6 +707,7 @@ config ARCH_SHMOBILE select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV select GENERIC_CLOCKEVENTS + select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT select SPARSE_IRQ select MULTI_IRQ_HANDLER @@ -904,6 +909,7 @@ config ARCH_U8500 select CLKDEV_LOOKUP select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture @@ -914,6 +920,7 @@ config ARCH_NOMADIK select CPU_ARM926T select CLKDEV_LOOKUP select GENERIC_CLOCKEVENTS + select MIGHT_HAVE_CACHE_L2X0 select ARCH_REQUIRE_GPIOLIB help Support for the Nomadik platform by ST-Ericsson @@ -973,6 +980,7 @@ config ARCH_ZYNQ select ARM_GIC select ARM_AMBA select ICST + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for Xilinx Zynq ARM Cortex A9 Platform diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 724ec0f..7f2347b 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -17,6 +17,7 @@ choice config ARCH_EXYNOS4 bool SAMSUNG EXYNOS4 + select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 5034147..c841578 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -44,6 +44,7 @@ config ARCH_OMAP4 select CPU_V7 select ARM_GIC select LOCAL_TIMERS if SMP + select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig index dba6d0c..3dd620f 100644 --- a/arch/arm/mach-realview/Kconfig +++ b/arch/arm/mach-realview/Kconfig @@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP bool Support Multicore Cortex-A9 Tile depends on MACH_REALVIEW_EB select CPU_V7 + select MIGHT_HAVE_CACHE_L2X0 help Enable support for the Cortex-A9MPCore tile fitted to the Realview(R) Emulation Baseboard platform. @@ -21,6 +22,7 @@ config REALVIEW_EB_ARM11MP depends on MACH_REALVIEW_EB select CPU_V6K select ARCH_HAS_BARRIERS if SMP + select MIGHT_HAVE_CACHE_L2X0 help Enable support for the ARM11MPCore tile fitted to the Realview(R) Emulation Baseboard platform. @@ -39,6 +41,7 @@ config MACH_REALVIEW_PB11MP select CPU_V6K select ARM_GIC select HAVE_PATA_PLATFORM + select MIGHT_HAVE_CACHE_L2X0 select
[PATCH v4 REPOST 2/5] ARM: SMP: Refactor Kconfig to be more maintainable
Making SMP depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new HAVE_SMP config option is introduced to allow machines to indicate that they can run in a SMP configuration. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/Kconfig | 15 +++ arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-imx/Kconfig |1 + arch/arm/mach-msm/Kconfig |1 + arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-realview/Kconfig |4 arch/arm/mach-vexpress/Kconfig |1 + 7 files changed, 20 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 16a4b9e..d33eb39 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -344,6 +344,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select USE_OF help @@ -636,6 +637,7 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SCHED_CLOCK + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ help @@ -706,6 +708,7 @@ config ARCH_SHMOBILE select HAVE_CLK select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV + select HAVE_SMP select GENERIC_CLOCKEVENTS select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT @@ -909,6 +912,7 @@ config ARCH_U8500 select CLKDEV_LOOKUP select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture @@ -1430,14 +1434,17 @@ menu Kernel Features source kernel/time/Kconfig +config HAVE_SMP + bool + help + This option should be selected by machines which have an SMP- + capable CPU. + config SMP bool Symmetric Multi-Processing depends on CPU_V6K || CPU_V7 depends on GENERIC_CLOCKEVENTS - depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \ -MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \ -ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \ -ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || ARCH_HIGHBANK || SOC_IMX6Q + depends on HAVE_SMP depends on MMU select USE_GENERIC_SMP_HELPERS select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 7f2347b..e1efbca 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -17,6 +17,7 @@ choice config ARCH_EXYNOS4 bool SAMSUNG EXYNOS4 + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 5f7f9c2..29a3d61 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -615,6 +615,7 @@ config SOC_IMX6Q select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC + select HAVE_SMP select USE_OF help diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index ebde97f..e6beaff 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -67,6 +67,7 @@ config MSM_SOC_REV_A bool config ARCH_MSM_SCORPIONMP bool + select HAVE_SMP config ARCH_MSM_ARM11 bool diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index c841578..bb1b670 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -43,6 +43,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC + select HAVE_SMP select LOCAL_TIMERS if SMP select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig index 3dd620f..c593be4 100644 --- a/arch/arm/mach-realview/Kconfig +++ b/arch/arm/mach-realview/Kconfig @@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP bool Support Multicore Cortex-A9 Tile depends on MACH_REALVIEW_EB select CPU_V7 + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Enable support for the Cortex-A9MPCore tile fitted to the @@ -22,6 +23,7 @@ config REALVIEW_EB_ARM11MP depends on MACH_REALVIEW_EB select CPU_V6K select ARCH_HAS_BARRIERS if SMP + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Enable support for the ARM11MPCore tile fitted to the Realview(R) @@ -41,6 +43,7 @@ config MACH_REALVIEW_PB11MP select CPU_V6K select ARM_GIC select HAVE_PATA_PLATFORM +
[PATCH v4 REPOST 4/5] highbank: Unconditionally require l2x0 L2 cache controller support
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the Highbank SoC. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d33eb39..744296d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -340,12 +340,12 @@ config ARCH_HIGHBANK select ARM_AMBA select ARM_GIC select ARM_TIMER_SP804 + select CACHE_L2X0 select CLKDEV_LOOKUP select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU select HAVE_SMP - select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards. -- 1.7.4.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 v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.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 v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help -- 1.7.4.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 v3 2/4] omap-serial: Use default clock speed (48Mhz) if not specified
Use a default clock speed of 48Mhz, instead of ending up with 0,
if platforms fail to specify a valid clock speed.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/tty/serial/omap-serial.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index a02cc9f..f14b9c5 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,6 +43,8 @@
#include plat/dmtimer.h
#include plat/omap-serial.h
+#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -1386,6 +1388,11 @@ static int serial_omap_probe(struct platform_device
*pdev)
up-port.flags = omap_up_info-flags;
up-port.uartclk = omap_up_info-uartclk;
+ if (!up-port.uartclk) {
+ up-port.uartclk = DEFAULT_CLK_SPEED;
+ dev_warn(pdev-dev, No clock speed specified: using default:
+ %d\n, DEFAULT_CLK_SPEED);
+ }
up-uart_dma.uart_base = mem-start;
up-errata = omap_up_info-errata;
--
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 v3 0/4] OMAP serial device tree support
v3 is rebased on top of the latest serial runtime patches[1] and boot tested with/without DT on OMAP4 SDP and OMAP4 Panda boards. Patches can be found here.. git://gitorious.org/omap-pm/linux.git for-dt/serial I also had to pull in a fix[2] for DT testing (already in linux-omap master) which was missing as the serial runtime branch[1] was based on an older master commit. Changes in v3: -1- Rebased on latest serial runtime patches -2- Minor typr fixes Changes in v2: -1- Got rid of binding to define which uart is console -2- Added checks to default clock speed to 48Mhz -3- Added compatible for each OMAP family -4- Used of_alias_get_id to populate port.line [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime [2] http://www.spinics.net/lists/arm-kernel/msg150751.html Rajendra Nayak (4): omap-serial: Get rid of all pdev-id usage omap-serial: Use default clock speed (48Mhz) if not specified omap-serial: Add minimal device tree support ARM: omap: pass minimal SoC/board data for UART from dt .../devicetree/bindings/serial/omap_serial.txt | 10 +++ arch/arm/boot/dts/omap3.dtsi | 31 arch/arm/boot/dts/omap4.dtsi | 28 +++ arch/arm/mach-omap2/board-generic.c|1 - drivers/tty/serial/omap-serial.c | 80 +++ 5 files changed, 132 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt -- 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 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/boot/dts/omap3.dtsi| 31 +++
arch/arm/boot/dts/omap4.dtsi| 28
arch/arm/mach-omap2/board-generic.c |1 -
3 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..216c331 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
/ {
compatible = ti,omap3430, ti,omap3;
+ aliases {
+ serial0 = uart1;
+ serial1 = uart2;
+ serial2 = uart3;
+ serial3 = uart4;
+ };
+
cpus {
cpu@0 {
compatible = arm,cortex-a8;
@@ -59,5 +66,29 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ uart1: serial@0x4806a000 {
+ compatible = ti,omap3-uart;
+ ti,hwmods = uart1;
+ clock-frequency = 4800;
+ };
+
+ uart2: serial@0x4806c000 {
+ compatible = ti,omap3-uart;
+ ti,hwmods = uart2;
+ clock-frequency = 4800;
+ };
+
+ uart3: serial@0x4902 {
+ compatible = ti,omap3-uart;
+ ti,hwmods = uart3;
+ clock-frequency = 4800;
+ };
+
+ uart4: serial@0x49042000 {
+ compatible = ti,omap3-uart;
+ ti,hwmods = uart4;
+ clock-frequency = 4800;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..e8fe75f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = gic;
aliases {
+ serial0 = uart1;
+ serial1 = uart2;
+ serial2 = uart3;
+ serial3 = uart4;
};
cpus {
@@ -99,5 +103,29 @@
reg = 0x48241000 0x1000,
0x48240100 0x0100;
};
+
+ uart1: serial@0x4806a000 {
+ compatible = ti,omap4-uart;
+ ti,hwmods = uart1;
+ clock-frequency = 4800;
+ };
+
+ uart2: serial@0x4806c000 {
+ compatible = ti,omap4-uart;
+ ti,hwmods = uart2;
+ clock-frequency = 4800;
+ };
+
+ uart3: serial@0x4802 {
+ compatible = ti,omap4-uart;
+ ti,hwmods = uart3;
+ clock-frequency = 4800;
+ };
+
+ uart4: serial@0x4806e000 {
+ compatible = ti,omap4-uart;
+ ti,hwmods = uart4;
+ clock-frequency = 4800;
+ };
};
};
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 63b5416..a508ed5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
- omap_serial_init();
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
--
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 v3 1/4] omap-serial: Get rid of all pdev-id usage
With Device tree, pdev-id would no longer be Valid.
Hence get rid of all instances of its usage in the
driver. Device tree support for the driver is added
in subsequent patches.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/tty/serial/omap-serial.c | 30 +++---
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f3ff0ca..a02cc9f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -115,7 +115,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
- dev_dbg(up-port.dev, serial_omap_enable_ms+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_enable_ms+%d\n, up-port.line);
pm_runtime_get_sync(up-pdev-dev);
up-ier |= UART_IER_MSI;
@@ -418,7 +418,7 @@ static unsigned int serial_omap_tx_empty(struct uart_port
*port)
unsigned int ret = 0;
pm_runtime_get_sync(up-pdev-dev);
- dev_dbg(up-port.dev, serial_omap_tx_empty+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_tx_empty+%d\n, up-port.line);
spin_lock_irqsave(up-port.lock, flags);
ret = serial_in(up, UART_LSR) UART_LSR_TEMT ? TIOCSER_TEMT : 0;
spin_unlock_irqrestore(up-port.lock, flags);
@@ -436,7 +436,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port
*port)
status = check_modem_status(up);
pm_runtime_put(up-pdev-dev);
- dev_dbg(up-port.dev, serial_omap_get_mctrl+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_get_mctrl+%d\n, up-port.line);
if (status UART_MSR_DCD)
ret |= TIOCM_CAR;
@@ -454,7 +454,7 @@ static void serial_omap_set_mctrl(struct uart_port *port,
unsigned int mctrl)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char mcr = 0;
- dev_dbg(up-port.dev, serial_omap_set_mctrl+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_set_mctrl+%d\n, up-port.line);
if (mctrl TIOCM_RTS)
mcr |= UART_MCR_RTS;
if (mctrl TIOCM_DTR)
@@ -478,7 +478,7 @@ static void serial_omap_break_ctl(struct uart_port *port,
int break_state)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
- dev_dbg(up-port.dev, serial_omap_break_ctl+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_break_ctl+%d\n, up-port.line);
pm_runtime_get_sync(up-pdev-dev);
spin_lock_irqsave(up-port.lock, flags);
if (break_state == -1)
@@ -504,7 +504,7 @@ static int serial_omap_startup(struct uart_port *port)
if (retval)
return retval;
- dev_dbg(up-port.dev, serial_omap_startup+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_startup+%d\n, up-port.line);
pm_runtime_get_sync(up-pdev-dev);
/*
@@ -545,7 +545,7 @@ static int serial_omap_startup(struct uart_port *port)
0);
init_timer((up-uart_dma.rx_timer));
up-uart_dma.rx_timer.function = serial_omap_rxdma_poll;
- up-uart_dma.rx_timer.data = up-pdev-id;
+ up-uart_dma.rx_timer.data = up-port.line;
/* Currently the buffer size is 4KB. Can increase it */
up-uart_dma.rx_buf = dma_alloc_coherent(NULL,
up-uart_dma.rx_buf_size,
@@ -573,7 +573,7 @@ static void serial_omap_shutdown(struct uart_port *port)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
- dev_dbg(up-port.dev, serial_omap_shutdown+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_shutdown+%d\n, up-port.line);
pm_runtime_get_sync(up-pdev-dev);
/*
@@ -883,7 +883,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
spin_unlock_irqrestore(up-port.lock, flags);
pm_runtime_put(up-pdev-dev);
- dev_dbg(up-port.dev, serial_omap_set_termios+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_set_termios+%d\n, up-port.line);
}
static void
@@ -893,7 +893,7 @@ serial_omap_pm(struct uart_port *port, unsigned int state,
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char efr;
- dev_dbg(up-port.dev, serial_omap_pm+%d\n, up-pdev-id);
+ dev_dbg(up-port.dev, serial_omap_pm+%d\n, up-port.line);
pm_runtime_get_sync(up-pdev-dev);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
@@ -932,7 +932,7 @@ static void serial_omap_config_port(struct uart_port *port,
int flags)
struct uart_omap_port *up = (struct uart_omap_port *)port;
dev_dbg(up-port.dev, serial_omap_config_port+%d\n,
- up-pdev-id);
+ up-port.line);
[PATCH v3 3/4] omap-serial: Add minimal device tree support
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smartidle bits and handling
remote wakeup and dynamic muxing.
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/serial/omap_serial.txt | 10
drivers/tty/serial/omap-serial.c | 45 ++-
2 files changed, 52 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..342eedd
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,10 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be ti,omap2-uart for OMAP2 controllers
+- compatible : should be ti,omap3-uart for OMAP3 controllers
+- compatible : should be ti,omap4-uart for OMAP4 controllers
+- ti,hwmods : Must be uartn, n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f14b9c5..5aa524e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
#include linux/serial_core.h
#include linux/irq.h
#include linux/pm_runtime.h
+#include linux/of.h
#include plat/dma.h
#include plat/dmtimer.h
@@ -1324,6 +1325,19 @@ static void uart_tx_dma_callback(int lch, u16 ch_status,
void *data)
return;
}
+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+ struct omap_uart_port_info *omap_up_info;
+
+ omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+ if (!omap_up_info)
+ return NULL; /* out of memory */
+
+ of_property_read_u32(dev-of_node, clock-frequency,
+omap_up_info-uartclk);
+ return omap_up_info;
+}
+
static int serial_omap_probe(struct platform_device *pdev)
{
struct uart_omap_port *up;
@@ -1331,6 +1345,9 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = pdev-dev.platform_data;
int ret = -ENOSPC;
+ if (pdev-dev.of_node)
+ omap_up_info = of_get_uart_port_info(pdev-dev);
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(pdev-dev, no mem resource?\n);
@@ -1375,9 +1392,20 @@ static int serial_omap_probe(struct platform_device
*pdev)
up-port.regshift = 2;
up-port.fifosize = 64;
up-port.ops = serial_omap_pops;
- up-port.line = pdev-id;
- sprintf(up-name, OMAP UART%d, up-port.line);
+ if (pdev-dev.of_node)
+ up-port.line = of_alias_get_id(pdev-dev.of_node, serial);
+ else
+ up-port.line = pdev-id;
+
+ if (up-port.line 0) {
+ dev_err(pdev-dev, failed to get alias/pdev id, errno %d\n,
+ up-port.line);
+ ret = -ENODEV;
+ goto err;
+ }
+
+ sprintf(up-name, OMAP UART%d, up-port.line);
up-port.mapbase = mem-start;
up-port.membase = ioremap(mem-start, resource_size(mem));
if (!up-port.membase) {
@@ -1530,7 +1558,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;
- if (!pdata-enable_wakeup)
+ if (!pdata || !pdata-enable_wakeup)
return 0;
if (pdata-get_context_loss_count)
@@ -1591,12 +1619,23 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops =
{
serial_omap_runtime_resume, NULL)
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+ { .compatible = ti,omap2-uart },
+ { .compatible = ti,omap3-uart },
+ { .compatible = ti,omap4-uart },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#endif
+
static struct platform_driver serial_omap_driver = {
.probe = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name = DRIVER_NAME,
.pm = serial_omap_dev_pm_ops,
+ .of_match_table = of_match_ptr(omap_serial_of_match),
},
};
--
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
Re: [PATCH v4 REPOST 1/5] ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
On Wed, Dec 14, 2011 at 11:39:37AM +, Dave Martin wrote: Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other. Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select CACHE_L2X0 directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example. Signed-off-by: Dave Martin dave.mar...@linaro.org For CNS3xxx bits: Acked-by: Anton Vorontsov cbouatmai...@gmail.com Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] ARM: OMAP3LOGIC: Adding DSS support
Hi Tomi,
On Tue, 2011-12-13 at 09:52 +0200, Alex wrote:
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD
and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
Overall looks fine. A few questions below about the GPIOs, though.
snip
+static void __init omap3logic_display_init(void)
+{
+ int r;
+
+ r = gpio_request_array(omap3logic_dss_gpios,
+ARRAY_SIZE(omap3logic_dss_gpios));
+ if (r) {
+ printk(KERN_ERR failed to get lcd_panel_* gpios\n);
+ return;
+ }
+
+ gpio_export(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_export(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_export(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
Why do you want to export these GPIOs? They are handled here in the
board file, and I don't think there's any reason the userspace would
need to touch them.
Ok I can remove it from the kernel, if someone wants to use them,
It can be done from userspace.
+ gpio_set_value(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
These are already set to 0 in gpio_request_array, as you've defined the
flag GPIOF_OUT_INIT_LOW.
Thanks, I will correct it.
+
+ msleep(50);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 1);
What does this do, and why do you need msleep(50)? I understand
LCD_ENABLE gpio enables the LCD panel, but what exactly do LCD_BACKLIGHT
and LCD_PWM gpios do? Why don't you set/unset LCD_PWM in the panel
enable/disable functions like the other gpios?
LCD_BACKLIGHT supply's power to LED Driver and LCD_PWM used to
Control the backlight level.
I'll check your suggestion and if it suits, I'll update the patch accordingly.
Thanks,
Alex
--
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] ARM: OMAP3LOGIC: Adding DSS support
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
arch/arm/mach-omap2/board-omap3logic.c | 96
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 7c0f193..b44c485 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -7,6 +7,9 @@
* Copyright (C) 2010 Logic Product Development, Inc.
* Peter Barada peter.bar...@logicpd.com
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin al...@meprolight.com
+ *
* Modified from Beagle, EVM, and RX51
*
* This program is free software; you can redistribute it and/or modify
@@ -45,6 +48,9 @@
#include plat/gpmc.h
#include plat/sdrc.h
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
+
#define OMAP3LOGIC_SMSC911X_CS 1
#define OMAP3530_LV_SOM_MMC_GPIO_CD110
@@ -95,6 +101,13 @@ static struct twl4030_platform_data omap3logic_twldata = {
static int __init omap3logic_i2c_init(void)
{
+ omap3_pmic_get_config(omap3logic_twldata, TWL_COMMON_PDATA_USB,
+ TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
+
+ omap3logic_twldata.vdac-constraints.apply_uV = true;
+ omap3logic_twldata.vpll2-constraints.apply_uV = true;
+ omap3logic_twldata.vpll2-constraints.name = VDSI;
+
omap3_pmic_init(twl4030, omap3logic_twldata);
return 0;
}
@@ -182,6 +195,88 @@ static inline void __init board_smsc911x_init(void)
gpmc_smsc911x_init(board_smsc911x_data);
}
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+#define OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO 154
+#define OMAP3_TORPEDO_LCD_ENABLE_GPIO 155
+#define OMAP3_TORPEDO_LCD_PWM_GPIO 56
+
+static struct gpio omap3logic_dss_gpios[] __initdata = {
+ {OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, lcd_bl_pwr},
+ {OMAP3_TORPEDO_LCD_PWM_GPIO, GPIOF_OUT_INIT_LOW, lcd bl enable},
+ {OMAP3_TORPEDO_LCD_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, lcd enable},
+};
+
+static int omap3logic_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 1);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 1);
+
+ return 0;
+}
+
+static void omap3logic_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
+}
+
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = sharp_lq,
+ .platform_enable= omap3logic_enable_lcd,
+ .platform_disable = omap3logic_disable_lcd,
+};
+
+static struct omap_dss_device omap3logic_lcd_device = {
+ .name = lcd,
+ .driver_name= generic_dpi_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .data = lcd_panel,
+ .phy.dpi.data_lines = 16,
+};
+
+static struct omap_dss_device omap3logic_tv_device = {
+ .name = tv,
+ .driver_name= venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static struct omap_dss_device *omap3logic_dss_devices[] = {
+ omap3logic_lcd_device,
+ omap3logic_tv_device,
+};
+
+static struct omap_dss_board_info omap3logic_dss_data = {
+ .num_devices= ARRAY_SIZE(omap3logic_dss_devices),
+ .devices= omap3logic_dss_devices,
+ .default_device = omap3logic_lcd_device,
+};
+
+static void __init omap3logic_display_init(void)
+{
+ int r;
+
+ r = gpio_request_array(omap3logic_dss_gpios,
+ ARRAY_SIZE(omap3logic_dss_gpios));
+ if (r) {
+ printk(KERN_ERR failed to get lcd_panel_* gpios\n);
+ return;
+ }
+
+ r = omap_display_init(omap3logic_dss_data);
+ if (r) {
+ pr_err(OMAP3LOGIC: failed to register DSS device\n);
+ gpio_free_array(omap3logic_dss_gpios,
+ ARRAY_SIZE(omap3logic_dss_gpios));
+ }
+}
+#else
+static void __init omap3logic_display_init(void) { }
+#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
+
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -197,6 +292,7 @@ static void __init omap3logic_init(void)
omap_sdrc_init(NULL, NULL);
board_mmc_init();
board_smsc911x_init();
+ omap3logic_display_init();
/* Ensure
[PATCH] Linux OMAP: Add omap_reserve functionality
This patch adds omap_reserve functionality to board-omap3logic.c Signed-off-by: Alex Gershgorin al...@meprolight.com --- arch/arm/mach-omap2/board-omap3logic.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c index b44c485..6230a96 100644 --- a/arch/arm/mach-omap2/board-omap3logic.c +++ b/arch/arm/mach-omap2/board-omap3logic.c @@ -301,6 +301,7 @@ static void __init omap3logic_init(void) MACHINE_START(OMAP3_TORPEDO, Logic OMAP3 Torpedo board) .atag_offset= 0x100, + .reserve= omap_reserve, .map_io = omap3_map_io, .init_early = omap35xx_init_early, .init_irq = omap3_init_irq, @@ -310,6 +311,7 @@ MACHINE_END MACHINE_START(OMAP3530_LV_SOM, OMAP Logic 3530 LV SOM board) .atag_offset= 0x100, + .reserve= omap_reserve, .map_io = omap3_map_io, .init_early = omap35xx_init_early, .init_irq = omap3_init_irq, -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: RX-51: complete tsc2005 controller support
This change adds initialization of TSC2005 touchscreen controller found on Nokia
RX-51 board.
The change is taken from MeeGo kernel adaptation for Nokia N900, it repeats the
work of Aaro Koskinen and Mika Laitio, the original discussion is at
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26749.html
Signed-off-by: Vladimir Zapolskiy vladimir.zapols...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 45 -
1 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ba1aa07..f30484e 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -15,6 +15,7 @@
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
#include linux/wl12xx.h
+#include linux/spi/tsc2005.h
#include linux/i2c.h
#include linux/i2c/twl.h
#include linux/clk.h
@@ -56,6 +57,9 @@
#define RX51_FMTX_IRQ 53
#define RX51_LP5523_CHIP_EN_GPIO 41
+#define RX51_TSC2005_RESET_GPIO104
+#define RX51_TSC2005_IRQ_GPIO 100
+
#define RX51_USB_TRANSCEIVER_RST_GPIO 67
/* list all spi devices here */
@@ -146,6 +150,17 @@ static struct omap2_mcspi_device_config
tsc2005_mcspi_config = {
.single_channel = 1,
};
+static struct tsc2005_platform_data tsc2005_pdata = {
+ .ts_pressure_max= 2048,
+ .ts_pressure_fudge = 2,
+ .ts_x_max = 4096,
+ .ts_x_fudge = 4,
+ .ts_y_max = 4096,
+ .ts_y_fudge = 4,
+ .ts_x_plate_ohm = 320,
+ .esd_timeout_ms = 8000,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -167,10 +182,10 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.modalias = tsc2005,
.bus_num= 1,
.chip_select= 0,
- /* .irq = OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),*/
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
.max_speed_hz = 600,
.controller_data= tsc2005_mcspi_config,
- /* .platform_data = tsc2005_config,*/
+ .platform_data = tsc2005_pdata,
},
};
@@ -1086,6 +1101,31 @@ error:
*/
}
+static void rx51_tsc2005_set_reset(bool enable)
+{
+ gpio_set_value(RX51_TSC2005_RESET_GPIO, enable);
+}
+
+static void __init rx51_init_tsc2005(void)
+{
+ int r;
+
+ r = gpio_request(RX51_TSC2005_IRQ_GPIO, tsc2005 IRQ);
+ if (r = 0)
+ gpio_direction_input(RX51_TSC2005_IRQ_GPIO);
+else
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 IRQ);
+
+ r = gpio_request(RX51_TSC2005_RESET_GPIO, tsc2005 reset);
+ if (r = 0) {
+ gpio_direction_output(RX51_TSC2005_RESET_GPIO, 1);
+ tsc2005_pdata.set_reset = rx51_tsc2005_set_reset;
+ } else {
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 reset);
+ tsc2005_pdata.esd_timeout_ms = 0;
+ }
+}
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1094,6 +1134,7 @@ void __init rx51_peripherals_init(void)
board_smc91x_init();
rx51_add_gpio_keys();
rx51_init_wl1251();
+ rx51_init_tsc2005();
rx51_init_si4713();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
1.7.2.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 v2] OMAP3: RX-51: complete tsc2005 controller support
This change adds initialization of TSC2005 touchscreen controller found on Nokia
RX-51 board.
The change is taken from MeeGo kernel adaptation for Nokia N900, it repeats the
work of Aaro Koskinen and Mika Laitio, the original discussion is at
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26749.html
Signed-off-by: Vladimir Zapolskiy vladimir.zapols...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
---
Changes from v1 to v2:
* whitespace fix
arch/arm/mach-omap2/board-rx51-peripherals.c | 45 -
1 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ba1aa07..f30484e 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -15,6 +15,7 @@
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
#include linux/wl12xx.h
+#include linux/spi/tsc2005.h
#include linux/i2c.h
#include linux/i2c/twl.h
#include linux/clk.h
@@ -56,6 +57,9 @@
#define RX51_FMTX_IRQ 53
#define RX51_LP5523_CHIP_EN_GPIO 41
+#define RX51_TSC2005_RESET_GPIO104
+#define RX51_TSC2005_IRQ_GPIO 100
+
#define RX51_USB_TRANSCEIVER_RST_GPIO 67
/* list all spi devices here */
@@ -146,6 +150,17 @@ static struct omap2_mcspi_device_config
tsc2005_mcspi_config = {
.single_channel = 1,
};
+static struct tsc2005_platform_data tsc2005_pdata = {
+ .ts_pressure_max= 2048,
+ .ts_pressure_fudge = 2,
+ .ts_x_max = 4096,
+ .ts_x_fudge = 4,
+ .ts_y_max = 4096,
+ .ts_y_fudge = 4,
+ .ts_x_plate_ohm = 320,
+ .esd_timeout_ms = 8000,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -167,10 +182,10 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.modalias = tsc2005,
.bus_num= 1,
.chip_select= 0,
- /* .irq = OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),*/
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
.max_speed_hz = 600,
.controller_data= tsc2005_mcspi_config,
- /* .platform_data = tsc2005_config,*/
+ .platform_data = tsc2005_pdata,
},
};
@@ -1086,6 +1101,31 @@ error:
*/
}
+static void rx51_tsc2005_set_reset(bool enable)
+{
+ gpio_set_value(RX51_TSC2005_RESET_GPIO, enable);
+}
+
+static void __init rx51_init_tsc2005(void)
+{
+ int r;
+
+ r = gpio_request(RX51_TSC2005_IRQ_GPIO, tsc2005 IRQ);
+ if (r = 0)
+ gpio_direction_input(RX51_TSC2005_IRQ_GPIO);
+ else
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 IRQ);
+
+ r = gpio_request(RX51_TSC2005_RESET_GPIO, tsc2005 reset);
+ if (r = 0) {
+ gpio_direction_output(RX51_TSC2005_RESET_GPIO, 1);
+ tsc2005_pdata.set_reset = rx51_tsc2005_set_reset;
+ } else {
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 reset);
+ tsc2005_pdata.esd_timeout_ms = 0;
+ }
+}
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1094,6 +1134,7 @@ void __init rx51_peripherals_init(void)
board_smc91x_init();
rx51_add_gpio_keys();
rx51_init_wl1251();
+ rx51_init_tsc2005();
rx51_init_si4713();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
1.7.2.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
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. Hi, I'm almost done with moving registration of all latch dependent devices down to a late_initcall hook, however while working on this, I've found still another arrangement, yet better in my opinion: 1) generic-gpio driver registration moved from device_initcall up to subsys_initcall, 2) latch dependent device registration left at arch_initcall, as it is now, 3) a temporary hack, removed with the last patch in the series, that requests GPIO pins on behalf of device drivers before those are updated, placed between subsys_initcall and device_initcall, i.e., at fs_initcall or rootfs_initcall; both look ugly, but this is only for a while, in order to keep things working while in the transition, 4) the modem init hook, once updated with extra GPIO setup that must be done on behalf of the 8250 driver, which is not prepared for accepting any extra init hooks passed with the device platform data, moved down to late_initcall, as suggested, 5) once all drivers are updated, the hack is removed, and an initialization of unused pins added to that late_initcall modem hook, perhaps renamed in order to not suggest it is still modem only related. What do you think? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Regards, Shawn select USE_OF help -- 1.7.4.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi Igor, On Wednesday 14 December 2011 10:31:35 Igor Grinberg wrote: On 12/14/11 03:25, Martin Hostettler wrote: Adds board support for an MT9M032 based camera to omap3evm. Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org [snip] diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644 index 000..bffd5b8 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c @@ -0,0 +1,155 @@ [snip] +#include linux/i2c.h +#include linux/init.h +#include linux/platform_device.h + +#include linux/gpio.h +#include plat/mux.h +#include mux.h + +#include ../../../drivers/media/video/omap3isp/isp.h Laurent, In one of the previous reviews, you stated: I'll probably split it and move the part required by board files to include/media/omap3isp.h. Is there any progress on that? Yes, it has been half-fixed in mainline. Half only because all the structures and macros that should be used by board code are now in media/omap3isp.h, but some boards need to access OMAP3 ISP internals from board code, which still requires drivers/media/video/omap3isp/isp.h. This will eventually be fixed, when the generic struct clk object will be available. After a quick look at this patch it seems that media/omap3isp.h should be enough here. +#include media/mt9m032.h And this should be media/mt9m032.h +#include devices.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 v4 3/6] clk: introduce the common clock framework
On Tue, 13 Dec 2011, Mike Turquette wrote:
+void __clk_unprepare(struct clk *clk)
+{
+ if (!clk)
+ return;
+
+ if (WARN_ON(clk-prepare_count == 0))
+ return;
+
+ if (--clk-prepare_count 0)
+ return;
+
+ WARN_ON(clk-enable_count 0);
So this leaves the clock enable count set. I'm a bit wary about
that. Shouldn't it either return (including bumping the prepare_count
again) or call clk_disable() ?
+/**
+ * clk_get_parent - return the parent of a clk
+ * @clk: the clk whose parent gets returned
+ *
+ * Simply returns clk-parent. It is up to the caller to hold the
+ * prepare_lock, if desired. Returns NULL if clk is NULL.
Holding the prepare lock in the caller will deadlock. So it's not a
real good idea to document it as an option :)
+ */
+struct clk *clk_get_parent(struct clk *clk)
+{
+ struct clk *parent;
+
+ if (!clk)
+ return NULL;
+
+ mutex_lock(prepare_lock);
+/**
+ * clk_init - initialize the data structures in a struct clk
+ * @dev: device initializing this clk, placeholder for now
+ * @clk: clk being initialized
+ *
+ * Initializes the lists in struct clk, queries the hardware for the
+ * parent and rate and sets them both. Adds the clk to the sysfs tree
+ * topology.
+ *
+ * Caller must populate clk-name and clk-flags before calling
I'm not too happy about this construct. That leaves struct clk and its
members exposed to the world instead of making it a real opaque
cookie. I know from my own painful experience, that this will lead to
random fiddling in that data structure in drivers and arch code just
because the core code has a shortcoming.
Why can't we make struct clk a real cookie and confine the data
structure to the core code ?
That would change the init call to something like:
struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
struct clk *parent)
And have:
struct clk_hw {
struct clk_hw_ops *ops;
const char*name;
unsigned long flags;
};
Implementers can do:
struct my_clk_hw {
struct clk_hwhw;
mydata;
};
And then change the clk ops callbacks to take struct clk_hw * as an
argument.
So the core code can allocate the clk data structure and you return a
real opaque cookie. You do the same thing for the basic gated clock in
one of the next patches, so doing it for struct clk itself is just
consequent.
+ * clk_init. A key assumption in the call to .get_parent is that clks
+ * are being initialized in-order.
We should not require that, see below.
+ */
+void clk_init(struct device *dev, struct clk *clk)
+{
+ if (!clk)
+ return;
+
+ INIT_HLIST_HEAD(clk-children);
+ INIT_HLIST_NODE(clk-child_node);
+
+ mutex_lock(prepare_lock);
+
+ /*
+ * .get_parent is mandatory for populating .parent for clks with
+ * multiple possible parents. For clks with a fixed parent
+ * .get_parent is not mandatory and .parent can be statically
+ * initialized
+ */
+ if (clk-ops-get_parent)
+ clk-parent = clk-ops-get_parent(clk);
+
+ /* clks without a parent are considered root clks */
I'd rather prefer that root clocks are explicitely marked with a flag
instead of relying on clk-parent being NULL.
+ if (clk-parent)
+ hlist_add_head(clk-child_node,
+ clk-parent-children);
+ else
+ hlist_add_head(clk-child_node, clk_root_list);
You could put clocks which have no parent and are not marked as root
clock onto a separate list clk_orphaned or such. You might need this
for handling clocks which are disconnected from any parent runtime as
well.
And to avoid the whole in-order initialization issue, you could change
clk_init to:
struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
unsigned long flags, const char *parent_name)
Then you can lookup the requested parent by name. If that fails, you
put the clock into the orphaned list. When a new clock is initialized,
then you walk the orphaned list and check whether something is waiting
for that clock.
To handle multi-parent clocks you need to go one step further and add:
struct clk_hw {
struct clk_hw_ops *ops;
const char*name;
const char**possible_parents;
};
You also require a get_parent_idx() function in clk_hw_ops. So when
clk_init() is called with parent_name = NULL and get_parent_idx() is
implemented, then you call it and the clock returns you the index of
the possible_parents array. If that parent clock is not yet
registered, you store the requested name and do the lookup when new
clocks are registered.
That has also the advantage, that you can validate parent settings
upfront and for setting the parent during runtime, you don't have to
acquire a pointer to the parent clock. It's enough to call
clk_set_named_parent().
[PATCH] ARM: OMAP: hsmmc: add max_freq field
External circuitry like level shifters may limit the maximum operation
speed of the hsmmc controller. Add a field to struct omap2_hsmmc_info
so boards can adjust the setting on demand.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/hsmmc.c |1 +
arch/arm/mach-omap2/hsmmc.h |2 ++
drivers/mmc/host/omap_hsmmc.c |8 ++--
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index f4a1020..4c7bc36 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -298,6 +298,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-slots[0].caps = c-caps;
mmc-slots[0].internal_clock = !c-ext_clock;
mmc-dma_mask = 0x;
+ mmc-max_freq = c-max_freq;
if (cpu_is_omap44xx())
mmc-reg_offset = OMAP4_MMC_REG_OFFSET;
else
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index f757e78..65a8c12 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -25,6 +25,8 @@ struct omap2_hsmmc_info {
char*name; /* or NULL for default */
struct device *dev; /* returned: pointer to mmc adapter */
int ocr_mask; /* temporary HACK */
+ int max_freq; /* maximum clock, if constrained by external
+* circuitry, or 0 for default */
/* Remux (pad configuration) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
/* init some special card */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 101cd31..8215ef9 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
if (mmc_slot(host).vcc_aux_disable_is_sleep)
mmc_slot(host).no_off = 1;
- mmc-f_min = OMAP_MMC_MIN_CLOCK;
- mmc-f_max = OMAP_MMC_MAX_CLOCK;
+ mmc-f_min = OMAP_MMC_MIN_CLOCK;
+
+ if (pdata-max_freq 0)
+ mmc-f_max = pdata-max_freq;
+ else
+ mmc-f_max = OMAP_MMC_MAX_CLOCK;
spin_lock_init(host-irq_lock);
--
1.7.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
Re: [PATCH v4 REPOST 4/5] highbank: Unconditionally require l2x0 L2 cache controller support
On 12/14/2011 05:39 AM, Dave Martin wrote: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the Highbank SoC. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html Doesn't this need to be above the SOB? Otherwise: Acked-by: Rob Herring rob.herr...@calxeda.com --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d33eb39..744296d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -340,12 +340,12 @@ config ARCH_HIGHBANK select ARM_AMBA select ARM_GIC select ARM_TIMER_SP804 + select CACHE_L2X0 select CLKDEV_LOOKUP select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU select HAVE_SMP - select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] OMAP serial device tree support
On 12/14/2011 05:55 AM, Rajendra Nayak wrote: v3 is rebased on top of the latest serial runtime patches[1] and boot tested with/without DT on OMAP4 SDP and OMAP4 Panda boards. Patches can be found here.. git://gitorious.org/omap-pm/linux.git for-dt/serial I also had to pull in a fix[2] for DT testing (already in linux-omap master) which was missing as the serial runtime branch[1] was based on an older master commit. Changes in v3: -1- Rebased on latest serial runtime patches -2- Minor typr fixes Changes in v2: -1- Got rid of binding to define which uart is console -2- Added checks to default clock speed to 48Mhz -3- Added compatible for each OMAP family -4- Used of_alias_get_id to populate port.line [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime [2] http://www.spinics.net/lists/arm-kernel/msg150751.html Rajendra Nayak (4): omap-serial: Get rid of all pdev-id usage omap-serial: Use default clock speed (48Mhz) if not specified omap-serial: Add minimal device tree support ARM: omap: pass minimal SoC/board data for UART from dt .../devicetree/bindings/serial/omap_serial.txt | 10 +++ arch/arm/boot/dts/omap3.dtsi | 31 arch/arm/boot/dts/omap4.dtsi | 28 +++ arch/arm/mach-omap2/board-generic.c|1 - drivers/tty/serial/omap-serial.c | 80 +++ 5 files changed, 132 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt Looks good. For the series: Reviewed-by: Rob Herring rob.herr...@calxeda.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 4/5] highbank: Unconditionally require l2x0 L2 cache controller support
On Wed, Dec 14, 2011 at 07:37:32AM -0600, Rob Herring wrote: On 12/14/2011 05:39 AM, Dave Martin wrote: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the Highbank SoC. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html Doesn't this need to be above the SOB? Otherwise: You may be right ... certainly I see no reason _not_ to change it. So I'll change it. Acked-by: Rob Herring rob.herr...@calxeda.com Thanks ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 0/7] media: introduce object detection(OD) driver
Hi, These v2 patches(against -next tree) introduce v4l2 based object detection(OD) device driver, and enable face detection hardware[1] on omap4 SoC.. The idea of implementing it on v4l2 is from from Alan Cox, Sylwester and Greg-Kh. For verification purpose, I write one user space utility[2] to test the module and driver, follows its basic functions: - detect faces in input grayscal picture(PGM raw, 320 by 240) - detect faces in input y8 format video stream - plot a rectangle to mark the detected faces, and save it as another same format picture or video stream Looks the performance of the module is not bad, see some detection results on the link[3][4]. Face detection can be used to implement some interesting applications (camera, face unlock, baby monitor, ...). v2-v1: - extend face detection API to object detection API - extend face detection generic module to object detection module - introduce subdevice and media entity to object detection module - some minor fixes TODO: - implement OD setting interfaces with v4l2 controls or ext controls arch/arm/mach-omap2/devices.c | 33 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 81 +++ drivers/media/video/Kconfig|6 + drivers/media/video/Makefile |2 + drivers/media/video/odif/Kconfig | 13 + drivers/media/video/odif/Makefile |2 + drivers/media/video/odif/fdif_omap4.c | 685 + drivers/media/video/odif/odif.c| 890 drivers/media/video/odif/odif.h| 157 + drivers/media/video/v4l2-ioctl.c | 72 +++- drivers/media/video/videobuf2-dma-contig.c |1 + drivers/media/video/videobuf2-memops.c |1 - drivers/media/video/videobuf2-page.c | 117 include/linux/videodev2.h | 124 include/media/v4l2-ioctl.h |6 + include/media/videobuf2-page.h | 20 + 16 files changed, 2207 insertions(+), 3 deletions(-) thanks, -- Ming Lei [1], Ch9 of OMAP4 Technical Reference Manual [2], http://kernel.ubuntu.com/git?p=ming/fdif.git;a=shortlog;h=refs/heads/v4l2-fdif [3], http://kernel.ubuntu.com/~ming/dev/fdif/output [4], All pictures are taken from http://www.google.com/imghp and converted to pnm from jpeg format, only for test purpose. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 6/8] media: v4l2: introduce two IOCTLs for object detection
This patch introduces two new IOCTLs and related data
structure which will be used by the coming video device
with object detect capability.
The two IOCTLs and related data structure will be used by
user space application to retrieve the results of object
detection.
The utility fdif[1] is useing the two IOCTLs to find
objects(faces) deteced in raw images or video streams.
[1],http://kernel.ubuntu.com/git?p=ming/fdif.git;a=shortlog;h=refs/heads/v4l2-fdif
Signed-off-by: Ming Lei ming@canonical.com
---
v2:
- extend face detection API to object detection API
- introduce capability of V4L2_CAP_OBJ_DETECTION for object detection
- 32/64 safe array parameter
---
drivers/media/video/v4l2-ioctl.c | 41 -
include/linux/videodev2.h| 124 ++
include/media/v4l2-ioctl.h |6 ++
3 files changed, 170 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index ded8b72..575d445 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2140,6 +2140,30 @@ static long __video_do_ioctl(struct file *file,
dbgarg(cmd, index=%d, b-index);
break;
}
+ case VIDIOC_G_OD_RESULT:
+ {
+ struct v4l2_od_result *or = arg;
+
+ if (!ops-vidioc_g_od_result)
+ break;
+
+ ret = ops-vidioc_g_od_result(file, fh, or);
+
+ dbgarg(cmd, index=%d, or-frm_seq);
+ break;
+ }
+ case VIDIOC_G_OD_COUNT:
+ {
+ struct v4l2_od_count *oc = arg;
+
+ if (!ops-vidioc_g_od_count)
+ break;
+
+ ret = ops-vidioc_g_od_count(file, fh, oc);
+
+ dbgarg(cmd, index=%d, oc-frm_seq);
+ break;
+ }
default:
if (!ops-vidioc_default)
break;
@@ -2241,7 +2265,22 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
static int is_64_32_array_args(unsigned int cmd, void *parg, int *extra_len)
{
- return 0;
+ int ret = 0;
+
+ switch (cmd) {
+ case VIDIOC_G_OD_RESULT: {
+ struct v4l2_od_result *or = parg;
+
+ *extra_len = or-obj_cnt *
+ sizeof(struct v4l2_od_object);
+ ret = 1;
+ break;
+ }
+ default:
+ break;
+ }
+
+ return ret;
}
long
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..c08ceaf 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -270,6 +270,9 @@ struct v4l2_capability {
#define V4L2_CAP_RADIO 0x0004 /* is a radio device */
#define V4L2_CAP_MODULATOR 0x0008 /* has a modulator */
+/* The device has capability of object detection */
+#define V4L2_CAP_OBJ_DETECTION 0x0010
+
#define V4L2_CAP_READWRITE 0x0100 /* read/write systemcalls
*/
#define V4L2_CAP_ASYNCIO0x0200 /* async I/O */
#define V4L2_CAP_STREAMING 0x0400 /* streaming I/O ioctls */
@@ -2160,6 +2163,125 @@ struct v4l2_create_buffers {
__u32 reserved[8];
};
+/**
+ * struct v4l2_od_obj_desc
+ * @centerx: return, position in x direction of detected object
+ * @centery: return, position in y direction of detected object
+ * @sizex: return, size in x direction of detected object
+ * @sizey: return, size in y direction of detected object
+ * @angle: return, angle of detected object
+ * 0 deg ~ 359 deg, vertical is 0 deg, clockwise
+ * @reserved: future extensions
+ */
+struct v4l2_od_obj_desc {
+ __u16 centerx;
+ __u16 centery;
+ __u16 sizex;
+ __u16 sizey;
+ __u16 angle;
+ __u16 reserved[5];
+};
+
+/**
+ * struct v4l2_od_face_desc
+ * @id:return, used to be associated with detected eyes, mouth,
+ * and other objects inside this face, and each face in one
+ * frame has a unique id, start from 1
+ * @smile_level:return, smile level of the face
+ * @f: return, face description
+ */
+struct v4l2_od_face_desc {
+ __u16 id;
+ __u8smile_level;
+ __u8reserved[15];
+
+ struct v4l2_od_obj_desc f;
+};
+
+/**
+ * struct v4l2_od_eye_desc
+ * @face_id: return, used to associate with which face, 0 means
+ * no face associated with the eye
+ * @blink_level:return, blink level of the eye
+ * @e: return, eye description
+ */
+struct v4l2_od_eye_desc {
+ __u16 face_id;
+ __u8blink_level;
+ __u8reserved[15];
+
+ struct v4l2_od_obj_desc e;
+};
+
+/**
+ * struct v4l2_od_mouth_desc
+ * @face_id: return, used to associate with
[RFC PATCH v2 1/8] omap4: introduce fdif(face detect module) hwmod
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 81
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6cf21ee..30db754 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -53,6 +53,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod;
static struct omap_hwmod omap44xx_dsp_hwmod;
static struct omap_hwmod omap44xx_dss_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
+static struct omap_hwmod omap44xx_fdif_hwmod;
static struct omap_hwmod omap44xx_hsi_hwmod;
static struct omap_hwmod omap44xx_ipu_hwmod;
static struct omap_hwmod omap44xx_iss_hwmod;
@@ -354,6 +355,14 @@ static struct omap_hwmod_ocp_if
omap44xx_dma_system__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* fdif - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_fdif__l3_main_2 = {
+ .master = omap44xx_fdif_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* hsi - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_hsi__l3_main_2 = {
.master = omap44xx_hsi_hwmod,
@@ -5444,6 +5453,75 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+/* 'fdif' class */
+static struct omap_hwmod_class_sysconfig omap44xx_fdif_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_fdif_hwmod_class = {
+ .name = fdif,
+ .sysc = omap44xx_fdif_sysc,
+};
+
+/*fdif*/
+static struct omap_hwmod_addr_space omap44xx_fdif_addrs[] = {
+ {
+ .pa_start = 0x4a10a000,
+ .pa_end = 0x4a10afff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - fdif */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__fdif = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_fdif_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_fdif_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* fdif slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_fdif_slaves[] = {
+ omap44xx_l4_cfg__fdif,
+};
+static struct omap_hwmod_irq_info omap44xx_fdif_irqs[] = {
+ { .irq = 69 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+/* fdif master ports */
+static struct omap_hwmod_ocp_if *omap44xx_fdif_masters[] = {
+ omap44xx_fdif__l3_main_2,
+};
+
+static struct omap_hwmod omap44xx_fdif_hwmod = {
+ .name = fdif,
+ .class = omap44xx_fdif_hwmod_class,
+ .clkdm_name = iss_clkdm,
+ .mpu_irqs = omap44xx_fdif_irqs,
+ .main_clk = fdif_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_CAM_FDIF_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_CAM_FDIF_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_fdif_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_fdif_slaves),
+ .masters= omap44xx_fdif_masters,
+ .masters_cnt= ARRAY_SIZE(omap44xx_fdif_masters),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5593,6 +5671,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_wd_timer2_hwmod,
omap44xx_wd_timer3_hwmod,
+ /* fdif class */
+ omap44xx_fdif_hwmod,
+
NULL,
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 2/8] omap4: build fdif omap device from hwmod
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/devices.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1166bdc..bd7f9b3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -728,6 +728,38 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
#endif
+static __init struct platform_device *omap4_init_fdif(void)
+{
+ struct platform_device *pd;
+ struct omap_hwmod *oh;
+ const char *dev_name = omap-fdif;
+
+ oh = omap_hwmod_lookup(fdif);
+ if (!oh) {
+ pr_err(Could not look up fdif hwmod\n);
+ return NULL;
+ }
+
+ pd = omap_device_build(dev_name, -1, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(pd), Can't build omap_device for %s.\n,
+ dev_name);
+ return pd;
+}
+
+static void __init omap_init_fdif(void)
+{
+ struct platform_device *pd;
+
+ if (!cpu_is_omap44xx())
+ return;
+
+ pd = omap4_init_fdif();
+ if (!pd)
+ return;
+
+ pm_runtime_enable(pd-dev);
+}
+
/*-*/
#if defined(CONFIG_HDQ_MASTER_OMAP) || defined(CONFIG_HDQ_MASTER_OMAP_MODULE)
@@ -808,6 +840,7 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_vout();
+ omap_init_fdif();
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 3/8] media: videobuf2: move out of setting pgprot_noncached from vb2_mmap_pfn_range
So that we can reuse vb2_mmap_pfn_range for the coming videobuf2_page
memops.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/media/video/videobuf2-dma-contig.c |1 +
drivers/media/video/videobuf2-memops.c |1 -
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index f17ad98..0ea8866 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -106,6 +106,7 @@ static int vb2_dma_contig_mmap(void *buf_priv, struct
vm_area_struct *vma)
return -EINVAL;
}
+ vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
vb2_common_vm_ops, buf-handler);
}
diff --git a/drivers/media/video/videobuf2-memops.c
b/drivers/media/video/videobuf2-memops.c
index 71a7a78..77e0def 100644
--- a/drivers/media/video/videobuf2-memops.c
+++ b/drivers/media/video/videobuf2-memops.c
@@ -162,7 +162,6 @@ int vb2_mmap_pfn_range(struct vm_area_struct *vma, unsigned
long paddr,
size = min_t(unsigned long, vma-vm_end - vma-vm_start, size);
- vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
ret = remap_pfn_range(vma, vma-vm_start, paddr PAGE_SHIFT,
size, vma-vm_page_prot);
if (ret) {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 4/8] media: videobuf2: introduce VIDEOBUF2_PAGE memops
DMA contig memory resource is very limited and precious, also
accessing to it from CPU is very slow on some platform.
For some cases(such as the comming face detection driver), DMA Streaming
buffer is enough, so introduce VIDEOBUF2_PAGE to allocate continuous
physical memory but letting video device driver to handle DMA buffer mapping
and unmapping things.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/media/video/Kconfig |4 +
drivers/media/video/Makefile |1 +
drivers/media/video/videobuf2-page.c | 117 ++
include/media/videobuf2-page.h | 20 ++
4 files changed, 142 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/videobuf2-page.c
create mode 100644 include/media/videobuf2-page.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4e8a0c4..5684a00 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -60,6 +60,10 @@ config VIDEOBUF2_VMALLOC
select VIDEOBUF2_MEMOPS
tristate
+config VIDEOBUF2_PAGE
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
config VIDEOBUF2_DMA_SG
#depends on HAS_DMA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ddeaa6c..bc797f2 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -125,6 +125,7 @@ obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC)+= videobuf2-vmalloc.o
+obj-$(CONFIG_VIDEOBUF2_PAGE) += videobuf2-page.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
diff --git a/drivers/media/video/videobuf2-page.c
b/drivers/media/video/videobuf2-page.c
new file mode 100644
index 000..6a24a34
--- /dev/null
+++ b/drivers/media/video/videobuf2-page.c
@@ -0,0 +1,117 @@
+/*
+ * videobuf2-page.c - page memory allocator for videobuf2
+ *
+ * Copyright (C) 2011 Canonical Ltd.
+ *
+ * Author: Ming Lei ming@canonical.com
+ *
+ * This file is based on videobuf2-vmalloc.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/mm.h
+#include linux/slab.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+struct vb2_page_buf {
+ void*vaddr;
+ unsigned long size;
+ atomic_trefcount;
+ struct vb2_vmarea_handler handler;
+};
+
+static void vb2_page_put(void *buf_priv);
+
+static void *vb2_page_alloc(void *alloc_ctx, unsigned long size)
+{
+ struct vb2_page_buf *buf;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return NULL;
+
+ buf-size = size;
+ buf-vaddr = (void *)__get_free_pages(GFP_KERNEL,
+ get_order(buf-size));
+ buf-handler.refcount = buf-refcount;
+ buf-handler.put = vb2_page_put;
+ buf-handler.arg = buf;
+
+ if (!buf-vaddr) {
+ printk(KERN_ERR page of size %ld failed\n, buf-size);
+ kfree(buf);
+ return NULL;
+ }
+
+ atomic_inc(buf-refcount);
+ printk(KERN_DEBUG Allocated page buffer of size %ld at vaddr=%p\n,
+ buf-size, buf-vaddr);
+
+ return buf;
+}
+
+static void vb2_page_put(void *buf_priv)
+{
+ struct vb2_page_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(buf-refcount)) {
+ printk(KERN_DEBUG %s: Freeing page mem at vaddr=%p\n,
+ __func__, buf-vaddr);
+ free_pages((unsigned long)buf-vaddr, get_order(buf-size));
+ kfree(buf);
+ }
+}
+
+static void *vb2_page_vaddr(void *buf_priv)
+{
+ struct vb2_page_buf *buf = buf_priv;
+
+ BUG_ON(!buf);
+
+ if (!buf-vaddr) {
+ printk(KERN_ERR Address of an unallocated plane requested\n);
+ return NULL;
+ }
+
+ return buf-vaddr;
+}
+
+static unsigned int vb2_page_num_users(void *buf_priv)
+{
+ struct vb2_page_buf *buf = buf_priv;
+ return atomic_read(buf-refcount);
+}
+
+static int vb2_page_mmap(void *buf_priv, struct vm_area_struct *vma)
+{
+ struct vb2_page_buf *buf = buf_priv;
+
+ if (!buf) {
+ printk(KERN_ERR No memory to map\n);
+ return -EINVAL;
+ }
+
+ vma-vm_page_prot = vm_get_page_prot(vma-vm_flags);
+ return vb2_mmap_pfn_range(vma, virt_to_phys(buf-vaddr),
+ buf-size, vb2_common_vm_ops,
+ buf-handler);
+}
+
+const struct vb2_mem_ops vb2_page_memops = {
+ .alloc =
[RFC PATCH v2 5/8] media: v4l2-ioctl: support 64/32 compatible array parameter
This patch supports to handle 64/32 compatible array parameter,
such as below:
struct v4l2_fd_result {
__u32 buf_index;
__u32 face_cnt;
__u32 reserved[6];
struct v4l2_fd_detection fd[];
};
With this patch, the pointer to user space array needn't be passed
to kernel any more.
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/media/video/v4l2-ioctl.c | 33 +++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..ded8b72 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2239,6 +2239,11 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
return ret;
}
+static int is_64_32_array_args(unsigned int cmd, void *parg, int *extra_len)
+{
+ return 0;
+}
+
long
video_usercopy(struct file *file, unsigned int cmd, unsigned long arg,
v4l2_kioctl func)
@@ -2251,6 +2256,7 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg,
size_t array_size = 0;
void __user *user_ptr = NULL;
void**kernel_ptr = NULL;
+ int extra = 0;
/* Copy arguments into temp kernel buffer */
if (_IOC_DIR(cmd) != _IOC_NONE) {
@@ -2280,9 +2286,32 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg,
}
}
- err = check_array_args(cmd, parg, array_size, user_ptr, kernel_ptr);
+ if (is_64_32_array_args(cmd, parg, extra)) {
+ int size;
+ void *old_mbuf;
+
+ err = 0;
+ if (!extra)
+ goto handle_array_args;
+ old_mbuf = mbuf;
+ size = extra + _IOC_SIZE(cmd);
+ mbuf = kmalloc(size, GFP_KERNEL);
+ if (NULL == mbuf) {
+ mbuf = old_mbuf;
+ err = -ENOMEM;
+ goto out;
+ }
+ memcpy(mbuf, parg, _IOC_SIZE(cmd));
+ parg = mbuf;
+ kfree(old_mbuf);
+ } else {
+ err = check_array_args(cmd, parg, array_size,
+ user_ptr, kernel_ptr);
+ }
+
if (err 0)
goto out;
+handle_array_args:
has_array_args = err;
if (has_array_args) {
@@ -2321,7 +2350,7 @@ out_array_args:
switch (_IOC_DIR(cmd)) {
case _IOC_READ:
case (_IOC_WRITE | _IOC_READ):
- if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd)))
+ if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd) +
extra))
err = -EFAULT;
break;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 7/8] media: video: introduce object detection driver module
This patch introduces object detection generic driver.
The driver is responsible for all v4l2 stuff, buffer management
and other general things, and doesn't touch object detection hardware
directly. Several interfaces are exported to low level drivers
(such as the coming omap4 FD driver) which will communicate with
object detection hw module.
So the driver will make driving object detection hw modules more
easy.
TODO:
- implement object detection setting interfaces with v4l2
controls or ext controls
Signed-off-by: Ming Lei ming@canonical.com
---
v2:
- extend face detection driver to object detection driver
- introduce subdevice and media entity
- provide support to detect object from media HW
---
drivers/media/video/Kconfig |2 +
drivers/media/video/Makefile |1 +
drivers/media/video/odif/Kconfig |7 +
drivers/media/video/odif/Makefile |1 +
drivers/media/video/odif/odif.c | 890 +
drivers/media/video/odif/odif.h | 157 +++
6 files changed, 1058 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/odif/Kconfig
create mode 100644 drivers/media/video/odif/Makefile
create mode 100644 drivers/media/video/odif/odif.c
create mode 100644 drivers/media/video/odif/odif.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 5684a00..8740ee9 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1166,3 +1166,5 @@ config VIDEO_SAMSUNG_S5P_MFC
MFC 5.1 driver for V4L2.
endif # V4L_MEM2MEM_DRIVERS
+
+source drivers/media/video/odif/Kconfig
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index bc797f2..259c8d8 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -197,6 +197,7 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-y += davinci/
obj-$(CONFIG_ARCH_OMAP)+= omap/
+obj-$(CONFIG_ODIF) += odif/
ccflags-y += -Idrivers/media/dvb/dvb-core
ccflags-y += -Idrivers/media/dvb/frontends
diff --git a/drivers/media/video/odif/Kconfig b/drivers/media/video/odif/Kconfig
new file mode 100644
index 000..5090bd6
--- /dev/null
+++ b/drivers/media/video/odif/Kconfig
@@ -0,0 +1,7 @@
+config ODIF
+ depends on VIDEO_DEV VIDEO_V4L2
+ select VIDEOBUF2_PAGE
+ tristate Object Detection module
+ help
+ The ODIF is a object detection module, which can be integrated into
+ some SoCs to detect objects in images or video.
diff --git a/drivers/media/video/odif/Makefile
b/drivers/media/video/odif/Makefile
new file mode 100644
index 000..a55ff66
--- /dev/null
+++ b/drivers/media/video/odif/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ODIF) += odif.o
diff --git a/drivers/media/video/odif/odif.c b/drivers/media/video/odif/odif.c
new file mode 100644
index 000..381ab9d
--- /dev/null
+++ b/drivers/media/video/odif/odif.c
@@ -0,0 +1,890 @@
+/*
+ * odif.c -- object detection module driver
+ *
+ * Copyright (C) 2011 Ming Lei (ming@canonical.com)
+ *
+ * This file is based on drivers/media/video/vivi.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+/*/
+
+#include linux/module.h
+#include linux/fs.h
+#include linux/mm.h
+#include linux/signal.h
+#include linux/wait.h
+#include linux/poll.h
+#include linux/mman.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include asm/uaccess.h
+#include asm/byteorder.h
+#include asm/io.h
+#include odif.h
+
+#defineinput_from_user(dev) \
+ (dev-input == OD_INPUT_FROM_USER_SPACE)
+
+#defineDEFAULT_PENDING_RESULT_CNT 8
+
+static unsigned debug = 0;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, activates debug info);
+
+static unsigned result_cnt_threshold = DEFAULT_PENDING_RESULT_CNT;
+module_param(result_cnt_threshold, uint, 0644);
+MODULE_PARM_DESC(result_cnt, max pending result count);
+
+static LIST_HEAD(odif_devlist);
+static unsigned video_nr = -1;
+
+int odif_open(struct file *file)
+{
+ struct odif_dev *dev = video_drvdata(file);
+
+
[RFC PATCH v2 8/8] media: video: introduce omap4 face detection module driver
The patch introduces one face detection device driver for
driving face detection hardware on omap4[1].
Most things of the driver are dealing with omap4 face detection
hardware.
This driver is platform independent, so in theory it can
be used to drive same IP module on other platforms.
[1], Ch9 of OMAP4 Technical Reference Manual
Signed-off-by: Ming Lei ming@canonical.com
---
v2:
- based on odif module
- use new object detection API
---
drivers/media/video/odif/Kconfig |6 +
drivers/media/video/odif/Makefile |1 +
drivers/media/video/odif/fdif_omap4.c | 685 +
3 files changed, 692 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/odif/fdif_omap4.c
diff --git a/drivers/media/video/odif/Kconfig b/drivers/media/video/odif/Kconfig
index 5090bd6..2a8c545 100644
--- a/drivers/media/video/odif/Kconfig
+++ b/drivers/media/video/odif/Kconfig
@@ -5,3 +5,9 @@ config ODIF
help
The ODIF is a object detection module, which can be integrated into
some SoCs to detect objects in images or video.
+
+config ODIF_OMAP4
+ depends on ODIF
+ tristate OMAP4 Face Detection module
+ help
+ OMAP4 face detection support
diff --git a/drivers/media/video/odif/Makefile
b/drivers/media/video/odif/Makefile
index a55ff66..0eb844f 100644
--- a/drivers/media/video/odif/Makefile
+++ b/drivers/media/video/odif/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_ODIF) += odif.o
+obj-$(CONFIG_ODIF_OMAP4) += fdif_omap4.o
diff --git a/drivers/media/video/odif/fdif_omap4.c
b/drivers/media/video/odif/fdif_omap4.c
new file mode 100644
index 000..d7953d8
--- /dev/null
+++ b/drivers/media/video/odif/fdif_omap4.c
@@ -0,0 +1,685 @@
+/*
+ * fdif_omap4.c -- face detection module driver
+ *
+ * Copyright (C) 2011 Ming Lei (ming@canonical.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+/*/
+#include linux/init.h
+#include linux/fs.h
+#include linux/mm.h
+#include linux/slab.h
+#include linux/signal.h
+#include linux/wait.h
+#include linux/poll.h
+#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+#include linux/user_namespace.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/dma-mapping.h
+#include odif.h
+#include asm/uaccess.h
+#include asm/byteorder.h
+#include asm/io.h
+
+#undef DEBUG
+
+#define PICT_SIZE_X 320
+#define PICT_SIZE_Y 240
+
+#defineWORK_MEM_SIZE (52*1024)
+
+/* 9.5 FDIF Register Manua of TI OMAP4 TRM */
+#define FDIF_REVISION 0x0
+#define FDIF_HWINFO0x4
+#define FDIF_SYSCONFIG 0x10
+#define SOFTRESET (1 0)
+
+#define FDIF_IRQSTATUS_RAW_j (0x24 + 2*0x10)
+#define FDIF_IRQSTATUS_j (0x28 + 2*0x10)
+#define FDIF_IRQENABLE_SET_j (0x2c + 2*0x10)
+#define FDIF_IRQENABLE_CLR_j (0x30 + 2*0x10)
+#define FINISH_IRQ (1 8)
+#define ERR_IRQ(1 0)
+
+#define FDIF_PICADDR 0x60
+#define FDIF_CTRL 0x64
+#define CTRL_MAX_TAGS 0x0A
+
+#define FDIF_WKADDR0x68
+#define FD_CTRL0x80
+#define CTRL_FINISH(1 2)
+#define CTRL_RUN (1 1)
+#define CTRL_SRST (1 0)
+
+
+#define FD_DNUM0x84
+#define FD_DCOND 0x88
+#define FD_STARTX 0x8c
+#define FD_STARTY 0x90
+#define FD_SIZEX 0x94
+#define FD_SIZEY 0x98
+#define FD_LHIT0x9c
+#define FD_CENTERX_i 0x160
+#define FD_CENTERY_i 0x164
+#define FD_CONFSIZE_i 0x168
+#define FD_ANGLE_i 0x16c
+
+static inline void fd_writel(void __iomem *base, u32 reg, u32 val)
+{
+ __raw_writel(val, base + reg);
+}
+
+static inline u32 fd_readl(void __iomem *base, u32 reg)
+{
+ return __raw_readl(base + reg);
+}
+
+struct fdif_qvga {
+ struct odif_dev *dev;
+
+ /*should be removed*/
+ struct platform_device *pdev;
+ int irq;
+ void __iomem*base;
+
+ void
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote: Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0. Thanks Richard Regards, Shawn select USE_OF help -- 1.7.4.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3LOGIC: Adding DSS support
Hi Alex,
On 12/14/11 14:25, Alex wrote:
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD
and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
arch/arm/mach-omap2/board-omap3logic.c | 96
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 7c0f193..b44c485 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -7,6 +7,9 @@
* Copyright (C) 2010 Logic Product Development, Inc.
* Peter Barada peter.bar...@logicpd.com
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin al...@meprolight.com
+ *
* Modified from Beagle, EVM, and RX51
*
* This program is free software; you can redistribute it and/or modify
@@ -45,6 +48,9 @@
#include plat/gpmc.h
#include plat/sdrc.h
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
+
#define OMAP3LOGIC_SMSC911X_CS 1
#define OMAP3530_LV_SOM_MMC_GPIO_CD 110
@@ -95,6 +101,13 @@ static struct twl4030_platform_data omap3logic_twldata = {
static int __init omap3logic_i2c_init(void)
{
+ omap3_pmic_get_config(omap3logic_twldata, TWL_COMMON_PDATA_USB,
+ TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
+
+ omap3logic_twldata.vdac-constraints.apply_uV = true;
+ omap3logic_twldata.vpll2-constraints.apply_uV = true;
+ omap3logic_twldata.vpll2-constraints.name = VDSI;
+
omap3_pmic_init(twl4030, omap3logic_twldata);
return 0;
}
@@ -182,6 +195,88 @@ static inline void __init board_smsc911x_init(void)
gpmc_smsc911x_init(board_smsc911x_data);
}
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+#define OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO 154
+#define OMAP3_TORPEDO_LCD_ENABLE_GPIO155
+#define OMAP3_TORPEDO_LCD_PWM_GPIO 56
+
+static struct gpio omap3logic_dss_gpios[] __initdata = {
+ {OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, lcd_bl_pwr},
+ {OMAP3_TORPEDO_LCD_PWM_GPIO, GPIOF_OUT_INIT_LOW, lcd bl enable},
+ {OMAP3_TORPEDO_LCD_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, lcd enable},
+};
+
+static int omap3logic_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 1);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 1);
+
+ return 0;
+}
+
+static void omap3logic_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
+}
+
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = sharp_lq,
+ .platform_enable= omap3logic_enable_lcd,
+ .platform_disable = omap3logic_disable_lcd,
+};
+
+static struct omap_dss_device omap3logic_lcd_device = {
+ .name = lcd,
+ .driver_name= generic_dpi_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .data = lcd_panel,
+ .phy.dpi.data_lines = 16,
+};
+
+static struct omap_dss_device omap3logic_tv_device = {
+ .name = tv,
+ .driver_name= venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static struct omap_dss_device *omap3logic_dss_devices[] = {
+ omap3logic_lcd_device,
+ omap3logic_tv_device,
+};
+
+static struct omap_dss_board_info omap3logic_dss_data = {
+ .num_devices= ARRAY_SIZE(omap3logic_dss_devices),
+ .devices= omap3logic_dss_devices,
+ .default_device = omap3logic_lcd_device,
+};
+
+static void __init omap3logic_display_init(void)
+{
+ int r;
+
+ r = gpio_request_array(omap3logic_dss_gpios,
+ARRAY_SIZE(omap3logic_dss_gpios));
+ if (r) {
+ printk(KERN_ERR failed to get lcd_panel_* gpios\n);
You use pr_err() below, why not here?
+ return;
+ }
+
+ r = omap_display_init(omap3logic_dss_data);
+ if (r) {
+ pr_err(OMAP3LOGIC: failed to register DSS device\n);
+ gpio_free_array(omap3logic_dss_gpios,
+ ARRAY_SIZE(omap3logic_dss_gpios));
+ }
+}
+#else
+static void __init omap3logic_display_init(void) { }
+#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
+
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -197,6 +292,7 @@ static void __init omap3logic_init(void)
Re: [PATCH v2] OMAP3: RX-51: complete tsc2005 controller support
Hi Vladimir,
On 12/14/11 15:02, Vladimir Zapolskiy wrote:
This change adds initialization of TSC2005 touchscreen controller found on
Nokia
RX-51 board.
The change is taken from MeeGo kernel adaptation for Nokia N900, it repeats
the
work of Aaro Koskinen and Mika Laitio, the original discussion is at
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26749.html
Signed-off-by: Vladimir Zapolskiy vladimir.zapols...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
---
Changes from v1 to v2:
* whitespace fix
arch/arm/mach-omap2/board-rx51-peripherals.c | 45 -
1 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ba1aa07..f30484e 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -15,6 +15,7 @@
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
#include linux/wl12xx.h
+#include linux/spi/tsc2005.h
#include linux/i2c.h
#include linux/i2c/twl.h
#include linux/clk.h
@@ -56,6 +57,9 @@
#define RX51_FMTX_IRQ53
#define RX51_LP5523_CHIP_EN_GPIO 41
+#define RX51_TSC2005_RESET_GPIO 104
+#define RX51_TSC2005_IRQ_GPIO100
+
#define RX51_USB_TRANSCEIVER_RST_GPIO67
/* list all spi devices here */
@@ -146,6 +150,17 @@ static struct omap2_mcspi_device_config
tsc2005_mcspi_config = {
.single_channel = 1,
};
+static struct tsc2005_platform_data tsc2005_pdata = {
+ .ts_pressure_max= 2048,
+ .ts_pressure_fudge = 2,
+ .ts_x_max = 4096,
+ .ts_x_fudge = 4,
+ .ts_y_max = 4096,
+ .ts_y_fudge = 4,
+ .ts_x_plate_ohm = 320,
+ .esd_timeout_ms = 8000,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -167,10 +182,10 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.modalias = tsc2005,
.bus_num= 1,
.chip_select= 0,
- /* .irq = OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),*/
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
.max_speed_hz = 600,
.controller_data= tsc2005_mcspi_config,
- /* .platform_data = tsc2005_config,*/
+ .platform_data = tsc2005_pdata,
},
};
@@ -1086,6 +1101,31 @@ error:
*/
}
+static void rx51_tsc2005_set_reset(bool enable)
+{
+ gpio_set_value(RX51_TSC2005_RESET_GPIO, enable);
+}
+
+static void __init rx51_init_tsc2005(void)
+{
+ int r;
+
+ r = gpio_request(RX51_TSC2005_IRQ_GPIO, tsc2005 IRQ);
+ if (r = 0)
+ gpio_direction_input(RX51_TSC2005_IRQ_GPIO);
+ else
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 IRQ);
+
+ r = gpio_request(RX51_TSC2005_RESET_GPIO, tsc2005 reset);
+ if (r = 0) {
+ gpio_direction_output(RX51_TSC2005_RESET_GPIO, 1);
+ tsc2005_pdata.set_reset = rx51_tsc2005_set_reset;
+ } else {
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 reset);
+ tsc2005_pdata.esd_timeout_ms = 0;
+ }
I would suggest using gpio_request_array() here,
or if those pins are independent from each other, for some reason,
then gpio_request_one() would do.
Also, don't you need to setup the mux for these GPIOs?
Or is it done in some other place (like bootloader)?
+}
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1094,6 +1134,7 @@ void __init rx51_peripherals_init(void)
board_smc91x_init();
rx51_add_gpio_keys();
rx51_init_wl1251();
+ rx51_init_tsc2005();
rx51_init_si4713();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
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 v3 0/4] OMAP serial device tree support
Hi Rajendra, On Wed, Dec 14, 2011 at 5:25 PM, Rajendra Nayak rna...@ti.com wrote: v3 is rebased on top of the latest serial runtime patches[1] and boot tested with/without DT on OMAP4 SDP and OMAP4 Panda boards. Patches can be found here.. git://gitorious.org/omap-pm/linux.git for-dt/serial I also had to pull in a fix[2] for DT testing (already in linux-omap master) which was missing as the serial runtime branch[1] was based on an older master commit. Changes in v3: -1- Rebased on latest serial runtime patches -2- Minor typr fixes Changes in v2: -1- Got rid of binding to define which uart is console -2- Added checks to default clock speed to 48Mhz -3- Added compatible for each OMAP family -4- Used of_alias_get_id to populate port.line [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime [2] http://www.spinics.net/lists/arm-kernel/msg150751.html I merged this patch series to a tmp_intg branch [1] having uart runtime changes and sanity tested on 3430sdp/zoom3/panda seems fine. -- Thanks, Govindraj.R [1]: git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/tmp_rc4_uart_pm_intg -- 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 v6 0/6] PM QoS: implement the OMAP low level constraints management code
From: Jean Pihet j-pi...@ti.com . Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer . Implement the low level code which controls the power domains next power states, through the hwmod and pwrdm layers . Add cpuidle and power domains wake-up latency figures for OMAP3, cf. comments in the code and [1] for the details on where the numbers are magically coming from . Implement the relation between the cpuidle and per-device PM QoS frameworks in the OMAP3 specific idle callbacks. The chosen C-state shall satisfy the following conditions: . the 'valid' field is enabled, . it satisfies the enable_off_mode flag, . the next state for MPU and CORE power domains is not lower than the state programmed by the per-device PM QoS. ToDo: 1. support OMAP4 chipset when the low power modes will be supported 2. validate the constraints framework on OMAP4 HW (done on OMAP3) 3. Re-visit the OMAP power domains states initialization procedure. Currently the power states that have been changed from the constraints API which were applied before the initialization of the power domains are lost 4. Further clean-up the OMAP PM layer, use the generic frameworks instead (OPP, PM QoS...) Based on the pm-qos branch of the linux-omap git tree (3.2.0-rc4), cf. [2]. Tested on OMAP3 Beagleboard (ES2.x) with constraints on MPU, CORE, PER in RETention and OFF modes. [1] http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement [2] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git v6: . minor change in the commits description after Kevin's review . added Kevin's Reviewed-by v5: . rebased on latest linux-omap [2] . rework after Kevin's comments on the MLs v4: . split up the patches which remove the omap_pm_ code from the patch set. Those patches are to be submitted later, on top of this patch set. . latency numbers: provide the measurements setup and conditions in the code comments, added the link to the details on wiki [1]. . improved kerneldoc . split big functions into smaller ones, in order to improve the readability v3: reworked the error return path and improved the kerneldoc v2: reworked the OMAP specific cpuidle code to demote the initial C-state to a valid C-state which fulfills the per-device constraints v1: initial version Jean Pihet (6): OMAP2+: powerdomain: control power domains next state OMAP2+: omap_hwmod: manage the wake-up latency constraints OMAP: PM: register to the per-device PM QoS framework OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints OMAP3: update cpuidle latency and threshold figures OMAP3: powerdomain data: add wake-up latency figures arch/arm/mach-omap2/cpuidle34xx.c| 107 +++- arch/arm/mach-omap2/omap_hwmod.c | 27 +++- arch/arm/mach-omap2/pm.c | 71 - arch/arm/mach-omap2/pm.h | 17 ++- arch/arm/mach-omap2/powerdomain.c| 245 ++ arch/arm/mach-omap2/powerdomain.h| 36 - arch/arm/mach-omap2/powerdomains3xxx_data.c | 83 + arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + 8 files changed, 539 insertions(+), 49 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] OMAP2+: powerdomain: control power domains next state
From: Jean Pihet j-pi...@ti.com
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power domain.
The power domains get the next power state programmed directly in the
registers via pwrdm_wakeuplat_update_pwrst.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using
wake-up latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 245 +
arch/arm/mach-omap2/powerdomain.h | 36 +-
2 files changed, 279 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 8a18d1b..677a182 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -17,8 +17,10 @@
#include linux/kernel.h
#include linux/types.h
#include linux/list.h
+#include linux/slab.h
#include linux/errno.h
#include linux/string.h
+#include linux/pm_qos.h
#include trace/events/power.h
#include cm2xxx_3xxx.h
@@ -112,6 +114,12 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
+ /* Initialize the per-device wake-up constraints framework data */
+ spin_lock_init(pwrdm-wkup_lat_plist_lock);
+ plist_head_init(pwrdm-wkup_lat_plist_head);
+ pwrdm-wkup_lat_next_state = PWRDM_POWER_OFF;
+
+ /* Initialize the pwrdm state */
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
@@ -199,6 +207,158 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
return 0;
}
+/**
+ * _pwrdm_wakeuplat_update_list - Set/update/remove a powerdomain wakeup
+ * latency constraint from the pwrdm's constraint list
+ * @pwrdm: struct powerdomain * which the constraint applies to
+ * @cookie: constraint identifier, used for tracking.
+ * @min_latency: minimum wakeup latency constraint (in microseconds) for
+ * the given pwrdm. The value of PM_QOS_DEV_LAT_DEFAULT_VALUE removes
+ * the constraint.
+ * @user: pointer to the current list entry
+ * @new_user: allocated list entry, used for insertion of new constraints
+ * in the list
+ * @free_new_user: set to non-zero if the newly allocated list entry
+ * is unused and needs to be freed
+ * @free_node: set to non-zero if the current list entry is not in use
+ * anymore and needs to be freed
+ *
+ * Tracks the constraints by @cookie.
+ * Constraint set/update: Adds a new entry to powerdomain's wake-up latency
+ * constraint list.
+ * If the constraint identifier already exists in the list, the old value is
+ * overwritten.
+ * Constraint removal: Removes the identifier's entry from powerdomain's
+ * wakeup latency constraint list.
+ *
+ * Called with the pwrdm wakeup latency spinlock held.
+ *
+ * Returns 0 upon success, -EINVAL if the constraint is not existing.
+ */
+static inline int _pwrdm_update_wakeuplat_list(
+ struct powerdomain *pwrdm,
+ void *cookie,
+ long min_latency,
+ struct pwrdm_wkup_constraints_entry *user,
+ struct pwrdm_wkup_constraints_entry *new_user,
+ int *free_new_user,
+ int *free_node)
+{
+ struct pwrdm_wkup_constraints_entry *tmp_user;
+
+ /* Check if there already is a constraint for cookie */
+ plist_for_each_entry(tmp_user, pwrdm-wkup_lat_plist_head, node) {
+ if (tmp_user-cookie == cookie) {
+ user = tmp_user;
+ break;
+ }
+ }
+
+ if (min_latency != PM_QOS_DEV_LAT_DEFAULT_VALUE) {
+ /* If nothing to update, job done */
+ if (user (user-node.prio == min_latency))
+ return 0;
+
+ if (!user) {
+ /* Add new entry to the list */
+ user = new_user;
+ user-cookie = cookie;
+ *free_new_user = 0;
+ } else {
+ /* Update existing entry */
+ plist_del(user-node, pwrdm-wkup_lat_plist_head);
+ }
+
+ plist_node_init(user-node, min_latency);
+ plist_add(user-node, pwrdm-wkup_lat_plist_head);
+ } else {
+ if (user) {
+ /* Remove the constraint from the list */
+ plist_del(user-node, pwrdm-wkup_lat_plist_head);
+ *free_node = 1;
+ } else {
+ /* Constraint not existing or list empty, do nothing */
+
[PATCH 2/6] OMAP2+: omap_hwmod: manage the wake-up latency constraints
From: Jean Pihet j-pi...@ti.com
The OMAP PM code implements a handler for the per-device PM QoS framework.
The handler queries the omap_hwmod layer in order to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 529142a..c3a4cc4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -143,6 +143,7 @@
#include powerdomain.h
#include plat/clock.h
#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include plat/prcm.h
#include cm2xxx_3xxx.h
@@ -2616,10 +2617,34 @@ ohsps_unlock:
}
/**
+ * omap_hwmod_set_wkup_constraint- set/release a wake-up latency constraint
+ *
+ * @oh: struct omap_hwmod* to which the target device belongs to.
+ * @cookie: identifier of the constraints list for @oh.
+ * @min_latency: the minimum allowed wake-up latency for @oh.
+ *
+ * Returns 0 upon success, -EINVAL in case of invalid parameters, or
+ * the return value from pwrdm_set_wkup_lat_constraint.
+ */
+int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh,
+ void *cookie, long min_latency)
+{
+ struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh);
+
+ if (!pwrdm) {
+ pr_err(%s: Error: could not find powerdomain
+ for %s\n, __func__, oh-name);
+ return -EINVAL;
+ }
+
+ return pwrdm_set_wkup_lat_constraint(pwrdm, cookie, min_latency);
+}
+
+/**
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
* count for this device.
*
* Returns the context loss count of the powerdomain assocated with @oh
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8b372ed..222f792 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -600,6 +600,8 @@ int omap_hwmod_for_each_by_class(const char *classname,
void *user);
int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state);
+int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh, void *cookie,
+ long min_latency);
int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] OMAP: PM: register to the per-device PM QoS framework
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c | 71 +-
1 files changed, 70 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..a40d4f3 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -11,15 +11,18 @@
#include linux/kernel.h
#include linux/init.h
+#include linux/notifier.h
#include linux/io.h
#include linux/err.h
#include linux/opp.h
+#include linux/pm_qos.h
#include linux/export.h
#include plat/omap-pm.h
#include plat/omap_device.h
-#include common.h
+#include plat/omap_hwmod.h
+#include common.h
#include voltage.h
#include powerdomain.h
#include clockdomain.h
@@ -215,12 +218,78 @@ static void __init omap4_init_voltages(void)
omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva);
}
+/* Interface to the per-device PM QoS framework */
+static int omap2_dev_pm_qos_handler(struct notifier_block *nb,
+ unsigned long new_value,
+ void *req)
+{
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ struct dev_pm_qos_request *dev_pm_qos_req = req;
+
+ pr_debug(OMAP PM constraints: req@0x%p, new_value=%lu\n,
+req, new_value);
+
+ /* Look for the platform device for the constraint target device */
+ pdev = to_platform_device(dev_pm_qos_req-dev);
+
+ /* Try to catch non platform devices */
+ if (pdev-name == NULL) {
+ pr_err(%s: Error: platform device for device %s not valid\n,
+ __func__, dev_name(dev_pm_qos_req-dev));
+ return -EINVAL;
+ }
+
+ /* Find the associated omap_device for dev */
+ od = to_omap_device(pdev);
+ if (od == NULL) {
+ pr_err(%s: Error: no omap_device for device %s\n,
+ __func__, dev_name(dev_pm_qos_req-dev));
+ return -EINVAL;
+ }
+
+ /* Check that the omap_device has an unique hwmod entry */
+ if (od-hwmods_cnt != 1) {
+ pr_err(%s: Error: No unique hwmod for device %s\n,
+ __func__, dev_name(dev_pm_qos_req-dev));
+ return -EINVAL;
+ }
+
+ /* Find the primary omap_hwmod for dev */
+ oh = od-hwmods[0];
+
+ pr_debug(OMAP PM constraints: req@0x%p, dev=0x%p, new_value=%lu\n,
+req, dev_pm_qos_req-dev, new_value);
+
+ /* Apply the constraint */
+ return omap_hwmod_set_wkup_lat_constraint(oh, dev_pm_qos_req,
+ new_value);
+}
+
+static struct notifier_block omap2_dev_pm_qos_notifier = {
+ .notifier_call = omap2_dev_pm_qos_handler,
+};
+
+static int __init omap2_dev_pm_qos_init(void)
+{
+ int ret;
+
+ ret = dev_pm_qos_add_global_notifier(omap2_dev_pm_qos_notifier);
+ WARN(ret, KERN_ERR Cannot add global notifier for dev PM QoS\n);
+
+ return ret;
+}
+
static int __init omap2_common_pm_init(void)
{
if (!of_have_populated_dt())
omap2_init_processor_devices();
omap_pm_if_init();
+ /* Register to the per-device PM QoS framework */
+ omap2_dev_pm_qos_init();
+
return 0;
}
postcore_initcall(omap2_common_pm_init);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints
From: Jean Pihet j-pi...@ti.com
The MPU latency figures for cpuidle include the MPU itself and also
the peripherals needed for the MPU to execute instructions (e.g.
main memory, caches, IRQ controller, MMU etc). On OMAP3 those
peripherals belong to the MPU and CORE power domains and so the
cpuidle C-states are a combination of MPU and CORE states.
This patch implements the relation between the cpuidle and per-
device PM QoS frameworks in the OMAP3 specific idle callbacks.
The chosen C-state shall satisfy the following conditions:
. the 'valid' field is enabled,
. it satisfies the enable_off_mode flag,
. the next state for MPU and CORE power domains is not lower than the
next state calculated by the per-device PM QoS.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 57
arch/arm/mach-omap2/pm.h | 17 ++-
2 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1f71ebb..c67835f 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -40,7 +40,7 @@
#ifdef CONFIG_CPU_IDLE
/*
- * The latencies/thresholds for various C states have
+ * The MPU latencies/thresholds for various C states have
* to be configured from the respective board files.
* These are some default values (which might not provide
* the best power savings) used on boards which do not
@@ -75,14 +75,14 @@ struct omap3_idle_statedata
omap3_idle_data[OMAP3_NUM_STATES];
struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
+ struct clockdomain *clkdm)
{
clkdm_allow_idle(clkdm);
return 0;
}
static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
+ struct clockdomain *clkdm)
{
clkdm_deny_idle(clkdm);
return 0;
@@ -96,10 +96,13 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
*
* Called from the CPUidle framework to program the device to the
* specified target state selected by the governor.
+ *
+ * Note: this function does not check for any pending activity or dependency
+ * between power domains states, so the caller shall check the parameters
+ * correctness.
*/
static int omap3_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+ struct cpuidle_driver *drv, int index)
{
struct omap3_idle_statedata *cx =
cpuidle_get_statedata(dev-states_usage[index]);
@@ -174,18 +177,23 @@ return_sleep_time:
* to the caller. Else, this function searches for a lower c-state which is
* still valid (as defined in omap3_power_states[]) and returns its index.
*
- * A state is valid if the 'valid' field is enabled and
- * if it satisfies the enable_off_mode condition.
+ * A state is valid if:
+ * . the 'valid' field is enabled,
+ * . it satisfies the enable_off_mode flag,
+ * . the next state for MPU and CORE power domains is not lower than the
+ * state programmed by the per-device PM QoS.
*/
static int next_valid_state(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+ struct cpuidle_driver *drv, int index)
{
struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
struct cpuidle_state *curr = drv-states[index];
struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
+ u32 mpu_pm_qos_next_state = mpu_pd-wkup_lat_next_state;
+ u32 core_pm_qos_next_state = core_pd-wkup_lat_next_state;
+
int next_index = -1;
if (enable_off_mode) {
@@ -202,7 +210,9 @@ static int next_valid_state(struct cpuidle_device *dev,
/* Check if current state is valid */
if ((cx-valid)
(cx-mpu_state = mpu_deepest_state)
- (cx-core_state = core_deepest_state)) {
+ (cx-core_state = core_deepest_state)
+ (cx-mpu_state = mpu_pm_qos_next_state)
+ (cx-core_state = core_pm_qos_next_state)) {
return index;
} else {
int idx = OMAP3_NUM_STATES - 1;
@@ -227,7 +237,9 @@ static int next_valid_state(struct cpuidle_device *dev,
cx = cpuidle_get_statedata(dev-states_usage[idx]);
if ((cx-valid)
(cx-mpu_state = mpu_deepest_state)
-
[PATCH 5/6] OMAP3: update cpuidle latency and threshold figures
From: Jean Pihet j-pi...@ti.com
Update the data from the measurements performed at HW and SW levels.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers coming from.
ToDo:
- Measure the wake-up latencies for all power domains for OMAP3
- Correct some numbers when sys_clkreq and sys_offmode are supported
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 52 +++-
1 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index c67835f..3caa932 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -40,27 +40,41 @@
#ifdef CONFIG_CPU_IDLE
/*
- * The MPU latencies/thresholds for various C states have
- * to be configured from the respective board files.
- * These are some default values (which might not provide
- * the best power savings) used on boards which do not
- * pass these details from the board file.
+ * The MPU latency and threshold values for the C-states are the worst case
+ * values from the HW and SW, as described in details at
+ *
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#cpuidle_results
+ *
+ * Measurements conditions and remarks:
+ * . the measurements have been performed at OPP50
+ * . the sys_offmode signal is not supported and so not used for the
+ *measurements. Instead the latency and threshold values for C9 are
+ *corrected with the value for Triton 2, which is 11.5ms
+ * . the sys_clkreq signal is not used and so a correction is needed - TBD
+ * . the sys_clkoff signal is supported, this value need to be corrected with
+ *the correct value of SYSCLK on/off timings (1ms for sysclk on, 2.5ms
+ *for sysclk off)
+ * . in order to force the cpuidle algorithm to chose the power efficient
+ *C-states (C1, C3, C5, C7) in preference, the other C-states have a
+ *threshold value equal to the next power efficient C-state
+ *
+ * The latency and threshold values can be overriden by data from the board
+ * files, using omap3_pm_init_cpuidle.
*/
static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 */
- {2 + 2, 5, 1},
- /* C2 */
- {10 + 10, 30, 1},
- /* C3 */
- {50 + 50, 300, 1},
- /* C4 */
- {1500 + 1800, 4000, 1},
- /* C5 */
- {2500 + 7500, 12000, 1},
- /* C6 */
- {3000 + 8500, 15000, 1},
- /* C7 */
- {1 + 3, 30, 1},
+ /* C1 . MPU WFI + Core active */
+ {73 + 78, 152, 1},
+ /* C2 . MPU WFI + Core inactive */
+ {165 + 88, 345, 1},
+ /* C3 . MPU CSWR + Core inactive */
+ {163 + 182, 345, 1},
+ /* C4 . MPU OFF + Core inactive */
+ {2852 + 605, 15, 1},
+ /* C5 . MPU RET + Core RET */
+ {800 + 366, 2120, 1},
+ /* C6 . MPU OFF + Core RET */
+ {4080 + 801, 215000, 1},
+ /* C7 . MPU OFF + Core OFF */
+ {4300 + 13000, 215000, 1},
};
#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] OMAP3: powerdomain data: add wake-up latency figures
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are preliminary and
shall be added.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers coming from.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 83 +++
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index 8ef26da..63a3afd 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -31,6 +31,19 @@
/*
* Powerdomains
+ *
+ * The wakeup_lat values are derived from HW and SW measurements on
+ * the actual target. For more details cf.
+ *
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#Results_for_individual_power_domains
+ *
+ * Note: the latency figures for MPU, PER, CORE, NEON have been obtained
+ * from actual measurements.
+ * The latency figures for the other power domains are preliminary and
+ * shall be added.
+ *
+ * Note: only the SW restore timing values are taken into account.
+ * The HW impact of the sys_clkreq and sys_offmode signals is not taken
+ * into account - TDB
*/
static struct powerdomain iva2_pwrdm = {
@@ -51,6 +64,13 @@ static struct powerdomain iva2_pwrdm = {
[2] = PWRSTS_OFF_ON,
[3] = PWRSTS_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1100,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 350,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = mpu_iva },
};
@@ -67,6 +87,13 @@ static struct powerdomain mpu_3xxx_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_OFF_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1830,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 121,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = mpu_iva },
};
@@ -94,6 +121,13 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
[0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
[1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 3082,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 153,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = core },
};
@@ -116,6 +150,13 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
[0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
[1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 3082,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 153,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = core },
};
@@ -131,6 +172,13 @@ static struct powerdomain dss_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 70,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 20,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = core },
};
@@ -152,6 +200,13 @@ static struct powerdomain sgx_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
.voltdm = { .name = core },
};
@@ -167,6 +222,13 @@ static struct powerdomain cam_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 850,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+
Re: [PATCH v5 0/6] PM QoS: implement the OMAP low level constraints management code
Hi Kevin, On Wed, Dec 14, 2011 at 12:53 AM, Kevin Hilman khil...@ti.com wrote: Hi Jean, jean.pi...@newoldbits.com writes: From: Jean Pihet j-pi...@ti.com . Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer . Implement the low level code which controls the power domains next power states, through the hwmod and pwrdm layers . Add cpuidle and power domains wake-up latency figures for OMAP3, cf. comments in the code and [1] for the details on where the numbers are magically coming from . Implement the relation between the cpuidle and per-device PM QoS frameworks in the OMAP3 specific idle callbacks. The chosen C-state shall satisfy the following conditions: . the 'valid' field is enabled, . it satisfies the enable_off_mode flag, . the next state for MPU and CORE power domains is not lower than the state programmed by the per-device PM QoS. I had a couple minor comments on this version, but after that, feel free to add: Reviewed-by: Kevin Hilman khil...@ti.com Thanks for reviewing! I fixed (most of) the minor remarks and re-submitted. after that, this series will go upstream through Paul. Kevin Regards, Jean -- 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 0/2] OMAP: PM: switch from omap_pm_ functions to PM QoS
Hi Paul, Kevin, This patch series is depending on the latest constraints stuff for OMAP [1], which has been reviewed by Kevin. [1] http://marc.info/?l=linux-omapm=132387443205028w=2 Regards, Jean On Mon, Dec 12, 2011 at 5:27 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Kevin, Paul, ping on this series Thanks, Jean On Wed, Oct 19, 2011 at 4:28 PM, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com . Convert the OMAP I2C driver to the PM QoS API for MPU latency constraints . Remove the latency related functions from OMAP PM in favor of the generic per-device PM QoS API Apply on top of the OMAP PM QoS patch set [1]. Based on the pm-qos branch of the linux-pm git tree (3.1.0-rc3), cf. [2]. Tested on OMAP3 Beagleboard (ES2.x) with constraints on MPU, CORE, PER in RETention and OFF modes. [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/65971 [2] git://github.com/rjwysocki/linux-pm.git Jean Pihet (2): OMAP: convert I2C driver to PM QoS for latency constraints OMAP: PM: remove the latency related functions from the API Documentation/arm/OMAP/omap_pm | 55 +++- arch/arm/plat-omap/i2c.c | 20 -- arch/arm/plat-omap/include/plat/omap-pm.h | 99 - arch/arm/plat-omap/omap-pm-noop.c | 88 - drivers/i2c/busses/i2c-omap.c | 30 +- include/linux/i2c-omap.h | 1 - 6 files changed, 24 insertions(+), 269 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote: On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote: Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0. Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select it only from SOC_IMX6Q? Cheers ---Dave -- 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] ARM: OMAP3LOGIC: Adding DSS support
Hi,
On 12/14/11 14:25, Alex wrote:
This patch adds DSS2 support to the LogicPD OMAP 35x Torpedo boardfile. LCD
and
TV-out are supported.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
arch/arm/mach-omap2/board-omap3logic.c | 96
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 7c0f193..b44c485 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -7,6 +7,9 @@
* Copyright (C) 2010 Logic Product Development, Inc.
* Peter Barada peter.bar...@logicpd.com
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin al...@meprolight.com
+ *
* Modified from Beagle, EVM, and RX51
*
* This program is free software; you can redistribute it and/or modify
@@ -45,6 +48,9 @@
#include plat/gpmc.h
#include plat/sdrc.h
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
+
#define OMAP3LOGIC_SMSC911X_CS 1
#define OMAP3530_LV_SOM_MMC_GPIO_CD 110
@@ -95,6 +101,13 @@ static struct twl4030_platform_data omap3logic_twldata = {
static int __init omap3logic_i2c_init(void)
{
+ omap3_pmic_get_config(omap3logic_twldata, TWL_COMMON_PDATA_USB,
+ TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
+
+ omap3logic_twldata.vdac-constraints.apply_uV = true;
+ omap3logic_twldata.vpll2-constraints.apply_uV = true;
+ omap3logic_twldata.vpll2-constraints.name = VDSI;
+
omap3_pmic_init(twl4030, omap3logic_twldata);
return 0;
}
@@ -182,6 +195,88 @@ static inline void __init board_smsc911x_init(void)
gpmc_smsc911x_init(board_smsc911x_data);
}
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+#define OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO 154
+#define OMAP3_TORPEDO_LCD_ENABLE_GPIO155
+#define OMAP3_TORPEDO_LCD_PWM_GPIO 56
+
+static struct gpio omap3logic_dss_gpios[] __initdata = {
+ {OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, lcd_bl_pwr},
+ {OMAP3_TORPEDO_LCD_PWM_GPIO, GPIOF_OUT_INIT_LOW, lcd bl enable},
+ {OMAP3_TORPEDO_LCD_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, lcd enable},
+};
+
+static int omap3logic_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 1);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 1);
+
+ return 0;
+}
+
+static void omap3logic_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_ENABLE_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3_TORPEDO_LCD_BACKLIGHT_GPIO, 0);
+ gpio_set_value(OMAP3_TORPEDO_LCD_PWM_GPIO, 0);
+}
+
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = sharp_lq,
+ .platform_enable= omap3logic_enable_lcd,
+ .platform_disable = omap3logic_disable_lcd,
+};
+
+static struct omap_dss_device omap3logic_lcd_device = {
+ .name = lcd,
+ .driver_name= generic_dpi_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .data = lcd_panel,
+ .phy.dpi.data_lines = 16,
+};
+
+static struct omap_dss_device omap3logic_tv_device = {
+ .name = tv,
+ .driver_name= venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static struct omap_dss_device *omap3logic_dss_devices[] = {
+ omap3logic_lcd_device,
+ omap3logic_tv_device,
+};
+
+static struct omap_dss_board_info omap3logic_dss_data = {
+ .num_devices= ARRAY_SIZE(omap3logic_dss_devices),
+ .devices= omap3logic_dss_devices,
+ .default_device = omap3logic_lcd_device,
+};
+
+static void __init omap3logic_display_init(void)
+{
+ int r;
+
+ r = gpio_request_array(omap3logic_dss_gpios,
+ARRAY_SIZE(omap3logic_dss_gpios));
+ if (r) {
+ printk(KERN_ERR failed to get lcd_panel_* gpios\n);
You use pr_err() below, why not here?
You're absolutely right, thanks.
+ return;
+ }
+
+ r = omap_display_init(omap3logic_dss_data);
+ if (r) {
+ pr_err(OMAP3LOGIC: failed to register DSS device\n);
+ gpio_free_array(omap3logic_dss_gpios,
+ ARRAY_SIZE(omap3logic_dss_gpios));
+ }
+}
+#else
+static void __init omap3logic_display_init(void) { }
+#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
+
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -197,6 +292,7 @@ static void __init
[PATCH 1/1] omap3: add definition for CONTROL_CAMERA_PHY_CTRL
The register is used to configure the behaviour of the CSI-2 and CCP-2 receivers. This register is available only in OMAP3630. The original patch was submitted by Vimarsh Zutshi. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- arch/arm/mach-omap2/control.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index d4ef75d..6a26a0d 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -183,6 +183,7 @@ #define OMAP3630_CONTROL_FUSE_OPP120_VDD1 (OMAP2_CONTROL_GENERAL + 0x0120) #define OMAP3630_CONTROL_FUSE_OPP50_VDD2(OMAP2_CONTROL_GENERAL + 0x0128) #define OMAP3630_CONTROL_FUSE_OPP100_VDD2 (OMAP2_CONTROL_GENERAL + 0x012C) +#define OMAP3630_CONTROL_CAMERA_PHY_CTRL (OMAP2_CONTROL_GENERAL + 0x02f0) /* OMAP44xx control efuse offsets */ #define OMAP44XX_CONTROL_FUSE_IVA_OPP500x22C -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] OMAP serial device tree support
Greg, Alan, Rajendra Nayak rna...@ti.com writes: v3 is rebased on top of the latest serial runtime patches[1] and boot tested with/without DT on OMAP4 SDP and OMAP4 Panda boards. With your ack on the drivers/tty/* stuff, I can queue this via the OMAP tree on top of the runtime PM conversion that it depends on. Thanks, Kevin Patches can be found here.. git://gitorious.org/omap-pm/linux.git for-dt/serial I also had to pull in a fix[2] for DT testing (already in linux-omap master) which was missing as the serial runtime branch[1] was based on an older master commit. Changes in v3: -1- Rebased on latest serial runtime patches -2- Minor typr fixes Changes in v2: -1- Got rid of binding to define which uart is console -2- Added checks to default clock speed to 48Mhz -3- Added compatible for each OMAP family -4- Used of_alias_get_id to populate port.line [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime [2] http://www.spinics.net/lists/arm-kernel/msg150751.html Rajendra Nayak (4): omap-serial: Get rid of all pdev-id usage omap-serial: Use default clock speed (48Mhz) if not specified omap-serial: Add minimal device tree support ARM: omap: pass minimal SoC/board data for UART from dt .../devicetree/bindings/serial/omap_serial.txt | 10 +++ arch/arm/boot/dts/omap3.dtsi | 31 arch/arm/boot/dts/omap4.dtsi | 28 +++ arch/arm/mach-omap2/board-generic.c|1 - drivers/tty/serial/omap-serial.c | 80 +++ 5 files changed, 132 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt -- 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 v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
Govindraj govindraj...@gmail.com writes: On Wed, Dec 14, 2011 at 12:56 AM, Kevin Hilman khil...@ti.com wrote: Govindraj govindraj...@gmail.com writes: [...] I have re-based this patch series against LO master commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a Same is available here [1] I have tested this patch series along with: 1.) Tero's V11 irq chaining series http://www.spinics.net/lists/linux-omap/msg61445.html (This patch series is used for uart wakeup handling using prcm_irq chaining) 2.) Rajendra's hwmod change http://www.spinics.net/lists/arm-kernel/msg148632.html (This patch handles init_no_idle flag setting without this patch there will be boot warning however all pm features will work after boot up.) 3.) Vishwa's io daisy chain changes. http://permalink.gmane.org/gmane.linux.ports.arm.omap/65500 (tested with and without this patch series pm features works). Same combination of patches based on above commit id used for testing is available here [2]. Please have a closer look at your branch. The second commit[1] commits the .rej file from a failed patch apply, so obviously doesn't do what was intended. Sorry my bad I have refreshed the uart runtime branch [1] test branch [2]. Can you add another patch which fixes these compiler warnings: /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq': /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized] /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:176:16: note: 'ch' was declared here /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized] /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:176:16: note: 'ch' was declared here 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 v2] OMAP3: RX-51: complete tsc2005 controller support
Hi Igor,
thanks for review.
On 12/14/2011 04:32 PM, ext Igor Grinberg wrote:
Hi Vladimir,
On 12/14/11 15:02, Vladimir Zapolskiy wrote:
This change adds initialization of TSC2005 touchscreen controller found on Nokia
RX-51 board.
The change is taken from MeeGo kernel adaptation for Nokia N900, it repeats the
work of Aaro Koskinen and Mika Laitio, the original discussion is at
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26749.html
Signed-off-by: Vladimir Zapolskiyvladimir.zapols...@nokia.com
Cc: Tony Lindgrent...@atomide.com
Cc: Aaro Koskinenaaro.koski...@nokia.com
Cc: Dmitry Torokhovdmitry.torok...@gmail.com
---
Changes from v1 to v2:
* whitespace fix
arch/arm/mach-omap2/board-rx51-peripherals.c | 45 -
1 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ba1aa07..f30484e 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -15,6 +15,7 @@
#includelinux/input/matrix_keypad.h
#includelinux/spi/spi.h
#includelinux/wl12xx.h
+#includelinux/spi/tsc2005.h
#includelinux/i2c.h
#includelinux/i2c/twl.h
#includelinux/clk.h
@@ -56,6 +57,9 @@
#define RX51_FMTX_IRQ 53
#define RX51_LP5523_CHIP_EN_GPIO 41
+#define RX51_TSC2005_RESET_GPIO104
+#define RX51_TSC2005_IRQ_GPIO 100
+
#define RX51_USB_TRANSCEIVER_RST_GPIO 67
/* list all spi devices here */
@@ -146,6 +150,17 @@ static struct omap2_mcspi_device_config
tsc2005_mcspi_config = {
.single_channel = 1,
};
+static struct tsc2005_platform_data tsc2005_pdata = {
+ .ts_pressure_max= 2048,
+ .ts_pressure_fudge = 2,
+ .ts_x_max = 4096,
+ .ts_x_fudge = 4,
+ .ts_y_max = 4096,
+ .ts_y_fudge = 4,
+ .ts_x_plate_ohm = 320,
+ .esd_timeout_ms = 8000,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -167,10 +182,10 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.modalias = tsc2005,
.bus_num= 1,
.chip_select= 0,
- /* .irq = OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),*/
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
.max_speed_hz = 600,
.controller_data=tsc2005_mcspi_config,
- /* .platform_data =tsc2005_config,*/
+ .platform_data =tsc2005_pdata,
},
};
@@ -1086,6 +1101,31 @@ error:
*/
}
+static void rx51_tsc2005_set_reset(bool enable)
+{
+ gpio_set_value(RX51_TSC2005_RESET_GPIO, enable);
+}
+
+static void __init rx51_init_tsc2005(void)
+{
+ int r;
+
+ r = gpio_request(RX51_TSC2005_IRQ_GPIO, tsc2005 IRQ);
+ if (r= 0)
+ gpio_direction_input(RX51_TSC2005_IRQ_GPIO);
+ else
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 IRQ);
+
+ r = gpio_request(RX51_TSC2005_RESET_GPIO, tsc2005 reset);
+ if (r= 0) {
+ gpio_direction_output(RX51_TSC2005_RESET_GPIO, 1);
+ tsc2005_pdata.set_reset = rx51_tsc2005_set_reset;
+ } else {
+ printk(KERN_ERR unable to get %s GPIO\n, tsc2005 reset);
+ tsc2005_pdata.esd_timeout_ms = 0;
+ }
I would suggest using gpio_request_array() here,
or if those pins are independent from each other, for some reason,
then gpio_request_one() would do.
These pins are actually independent, but I agree that it would be
simpler and therefore better to use gpio_request_array() here.
Also, don't you need to setup the mux for these GPIOs?
Or is it done in some other place (like bootloader)?
I presume it's done in the original bootloader, however it won't harm to
add explicit pin mux definitions.
+}
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1094,6 +1134,7 @@ void __init rx51_peripherals_init(void)
board_smc91x_init();
rx51_add_gpio_keys();
rx51_init_wl1251();
+ rx51_init_tsc2005();
rx51_init_si4713();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
With best wishes,
Vladimir
--
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] OMAP3: RX-51: complete tsc2005 controller support
This change adds initialization of TSC2005 touchscreen controller found on Nokia
RX-51 board.
The change is taken from MeeGo kernel adaptation for Nokia N900, it repeats the
work of Aaro Koskinen and Mika Laitio, the original discussion is at
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26749.html
Signed-off-by: Vladimir Zapolskiy vladimir.zapols...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
---
Changes from v2 to v3:
* added explicit gpio pin mux definitions
* use gpio_array_request() for requesting multiple GPIOs
Changes from v1 to v2:
* whitespace fix
arch/arm/mach-omap2/board-rx51-peripherals.c | 48 -
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ba1aa07..dc15ae8 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -15,6 +15,7 @@
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
#include linux/wl12xx.h
+#include linux/spi/tsc2005.h
#include linux/i2c.h
#include linux/i2c/twl.h
#include linux/clk.h
@@ -56,6 +57,9 @@
#define RX51_FMTX_IRQ 53
#define RX51_LP5523_CHIP_EN_GPIO 41
+#define RX51_TSC2005_RESET_GPIO104
+#define RX51_TSC2005_IRQ_GPIO 100
+
#define RX51_USB_TRANSCEIVER_RST_GPIO 67
/* list all spi devices here */
@@ -146,6 +150,17 @@ static struct omap2_mcspi_device_config
tsc2005_mcspi_config = {
.single_channel = 1,
};
+static struct tsc2005_platform_data tsc2005_pdata = {
+ .ts_pressure_max= 2048,
+ .ts_pressure_fudge = 2,
+ .ts_x_max = 4096,
+ .ts_x_fudge = 4,
+ .ts_y_max = 4096,
+ .ts_y_fudge = 4,
+ .ts_x_plate_ohm = 320,
+ .esd_timeout_ms = 8000,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -167,10 +182,10 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.modalias = tsc2005,
.bus_num= 1,
.chip_select= 0,
- /* .irq = OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),*/
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
.max_speed_hz = 600,
.controller_data= tsc2005_mcspi_config,
- /* .platform_data = tsc2005_config,*/
+ .platform_data = tsc2005_pdata,
},
};
@@ -1086,6 +1101,34 @@ error:
*/
}
+static struct gpio rx51_tsc2005_gpios[] __initdata = {
+ { RX51_TSC2005_IRQ_GPIO, GPIOF_IN,tsc2005 IRQ },
+ { RX51_TSC2005_RESET_GPIO, GPIOF_OUT_INIT_HIGH, tsc2005 reset },
+};
+
+static void rx51_tsc2005_set_reset(bool enable)
+{
+ gpio_set_value(RX51_TSC2005_RESET_GPIO, enable);
+}
+
+static void __init rx51_init_tsc2005(void)
+{
+ int r;
+
+ omap_mux_init_gpio(RX51_TSC2005_RESET_GPIO, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(RX51_TSC2005_IRQ_GPIO, OMAP_PIN_INPUT_PULLUP);
+
+ r = gpio_request_array(rx51_tsc2005_gpios,
+ ARRAY_SIZE(rx51_tsc2005_gpios));
+ if (r 0) {
+ printk(KERN_ERR tsc2005 board initialization failed\n);
+ tsc2005_pdata.esd_timeout_ms = 0;
+ return;
+ }
+
+ tsc2005_pdata.set_reset = rx51_tsc2005_set_reset;
+}
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1094,6 +1137,7 @@ void __init rx51_peripherals_init(void)
board_smc91x_init();
rx51_add_gpio_keys();
rx51_init_wl1251();
+ rx51_init_tsc2005();
rx51_init_si4713();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
1.7.2.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
Re: [PATCH] OMAP3: RX-51: complete tsc2005 controller support
Hi, On Wed, 14 Dec 2011, Vladimir Zapolskiy wrote: This change adds initialization of TSC2005 touchscreen controller found on Nokia RX-51 board. The change is taken from MeeGo kernel adaptation for Nokia N900, it repeats the work of Aaro Koskinen and Mika Laitio, the original discussion is at http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26749.html I think Tony applied this already: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=3dad5356aa47097cf67027cf0a07298b4f5baef6 And that patch was from Maemo, not MeeGo kernel... A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: RX-51: complete tsc2005 controller support
Hi, On 12/14/2011 05:45 PM, Aaro Koskinen wrote: Hi, On Wed, 14 Dec 2011, Vladimir Zapolskiy wrote: This change adds initialization of TSC2005 touchscreen controller found on Nokia RX-51 board. The change is taken from MeeGo kernel adaptation for Nokia N900, it repeats the work of Aaro Koskinen and Mika Laitio, the original discussion is at http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26749.html I think Tony applied this already: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=3dad5356aa47097cf67027cf0a07298b4f5baef6 great, I haven't noticed that initially. In that case please ignore the duplicate. And that patch was from Maemo, not MeeGo kernel... A. -- With best wishes, Vladimir -- 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
[PATCHV2 REPOST 6/7] ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the
function.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 17 -
arch/arm/mach-omap2/prm2xxx_3xxx.c |8
arch/arm/mach-omap2/prm2xxx_3xxx.h |7 ---
3 files changed, 0 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 258d871..175102c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -302,13 +302,6 @@ void omap_sram_idle(void)
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (omap3_has_io_wakeup()
- (per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON)) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- if (omap3_has_io_chain_ctrl())
- omap3_trigger_wuclk_ctrl();
- }
/* Block console output in case it is on one of the OMAP UARTs */
if (!is_suspending())
@@ -406,16 +399,6 @@ void omap_sram_idle(void)
console_unlock();
console_still_active:
- /* Disable IO-PAD and IO-CHAIN wakeup */
- if (omap3_has_io_wakeup()
- (per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON)) {
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
-PM_WKEN);
- if (omap3_has_io_chain_ctrl())
- omap3_disable_io_chain();
- }
-
clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 6db5935..688e74c 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -252,14 +252,6 @@ void omap3_trigger_wuclk_ctrl(void)
PM_WKEN);
}
-/* OMAP3 Daisychain disable sequence */
-void omap3_disable_io_chain(void)
-{
- if (omap_rev() = OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
- PM_WKEN);
-}
-
static int __init omap3xxx_prcm_init(void)
{
if (cpu_is_omap34xx())
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index e6f8206..6287dc4 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -295,12 +295,6 @@ static inline void omap3_trigger_wuclk_ctrl(void)
not suppose to be used on omap4\n);
return 0;
}
-static inline void omap3_disable_io_chain(void)
-{
- WARN(1, prm: omap2xxx/omap3xxx specific function and
- not suppose to be used on omap4\n);
- return 0;
-}
#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
@@ -315,7 +309,6 @@ extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8
shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8
st_shift);
extern void omap3_trigger_wuclk_ctrl(void);
-extern void omap3_disable_io_chain(void);
/* OMAP3-specific VP functions */
u32 omap3_prm_vp_check_txdone(u8 vp_id);
--
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
[PATCHV2 REPOST 5/7] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a window
where device
is idled and corresponding powerdomain can be ON/INACTIVE state. In such
situations,
since both module wake up is enabled at padlevel as well as io daisychain
sequence is
triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup
and IO Pad
interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit
in the
first interrupt, module specific interrupt handler will not triggered for the
second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |9 +++--
arch/arm/mach-omap2/pm.c | 11 +++
arch/arm/mach-omap2/pm.h |1 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f7f22da..1a72463 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -151,6 +151,7 @@
#include prm44xx.h
#include prminst44xx.h
#include mux.h
+#include pm.h
/* Maximum microseconds to wait for OMAP module to softreset */
#define MAX_MODULE_SOFTRESET_WAIT 1
@@ -1462,8 +1463,10 @@ static int _enable(struct omap_hwmod *oh)
/* Mux pins for device runtime if populated */
if (oh-mux (!oh-mux-enabled ||
((oh-_state == _HWMOD_STATE_IDLE)
-oh-mux-pads_dynamic)))
+oh-mux-pads_dynamic))) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_ENABLED);
+ omap_trigger_wuclk_ctrl();
+ }
_add_initiator_dep(oh, mpu_oh);
@@ -1553,8 +1556,10 @@ static int _idle(struct omap_hwmod *oh)
clkdm_hwmod_disable(oh-clkdm, oh);
/* Mux pins for device idle if populated */
- if (oh-mux oh-mux-pads_dynamic)
+ if (oh-mux oh-mux-pads_dynamic) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_IDLE);
+ omap_trigger_wuclk_ctrl();
+ }
oh-_state = _HWMOD_STATE_IDLE;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..4d8ca28 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -25,6 +25,8 @@
#include clockdomain.h
#include pm.h
#include twl-common.h
+#include prm2xxx_3xxx.h
+#include prm44xx.h
static struct omap_device_pm_latency *pm_lats;
@@ -64,6 +66,15 @@ static void omap2_init_processor_devices(void)
}
}
+void omap_trigger_wuclk_ctrl(void)
+{
+ if (cpu_is_omap34xx())
+ omap3_trigger_wuclk_ctrl();
+
+ if (cpu_is_omap44xx())
+ omap4_trigger_wuclk_ctrl();
+}
+
/* Types of sleep_switch used in omap_set_pwrdm_state */
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH 1
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..05c2da2 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+void omap_trigger_wuclk_ctrl(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
--
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
[PATCHV2 REPOST 1/7] ARM: OMAP3 PM: correct enable/disable of daisy io chain
From: Mohan V moh...@ti.com
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain according to the Sec 3.5.7.2.2
I/O Wake-Up Mechanism in OMAP3630 Public TRM[1].
Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.
Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.
Step [e] [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.
[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip
Signed-off-by: Mohan V moh...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3b9edc8..074688b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -105,16 +105,17 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN)
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout 1000) {
pr_err(Wake up daisy chain activation failed.\n);
return;
}
- omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
}
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+
}
static void omap3_disable_io_chain(void)
--
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
[PATCHV2 REPOST 7/7] ARM: OMAP3 PM: Enable IO Daisychain for supported chips
IO Daisychain has to be enabled only if the corresponding omap has
io chain wake up capability.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 26 ++
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 688e74c..712ce02 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -238,18 +238,20 @@ void omap3_trigger_wuclk_ctrl(void)
{
int i = 0;
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
-PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- omap_test_timeout(
- (((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
-OMAP3430_ST_IO_CHAIN_MASK) == 1)),
- MAX_IOPAD_LATCH_TIME, i);
-
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
-PM_WKEN);
+ if (omap3_has_io_chain_ctrl()) {
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(
+ (((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+OMAP3430_ST_IO_CHAIN_MASK) == 1)),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
+PM_WKEN);
+ }
}
static int __init omap3xxx_prcm_init(void)
--
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
[PATCHV2 REPOST 0/7] ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
The following patch series provides IO Daisychain feature via omap hwmod mux framework. The patch series has been generated against Tero's V11 irq chaining series [1]. Testing Performed: OMAP3: Tested for Retention and OFF mode in suspend/cpuidle path on OMAP3430 SDP and ZOOM3. Also tested against latest UART Runtime + Chain Handler patches[2] for Ret/OFF in cpuidle/suspend path. OMAP4: Boot tested on OMAP4430 SDP. Also tested for Suspend/resume with CSWR using custom OMAP4 kernel as Core PM is not yet supported in mainline. Thanks to Govind for testing the series with UART Runtime patches on various OMAP3 platforms. Patch series is available here[3]. [1]: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git chain-prcm-v11 [2]: git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/tmp_rc4_uart_pm_intg [3]: git://gitorious.org/omap-pm/linux.git for_3.3/io_daisy_chain_rebased Mohan V (1): ARM: OMAP3 PM: correct enable/disable of daisy io chain Rajendra Nayak (1): ARM: OMAP4 PM: Add IO Daisychain support Vishwanath BS (5): ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file ARM: OMAP3 PM: Enable IO Wake up ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle ARM: OMAP3 PM: Enable IO Daisychain for supported chips arch/arm/mach-omap2/omap_hwmod.c |9 +- arch/arm/mach-omap2/pm.c | 11 arch/arm/mach-omap2/pm.h |1 + arch/arm/mach-omap2/pm34xx.c | 47 ++- arch/arm/mach-omap2/prm2xxx_3xxx.c | 27 arch/arm/mach-omap2/prm2xxx_3xxx.h |7 + arch/arm/mach-omap2/prm44xx.c | 30 +++ arch/arm/mach-omap2/prm44xx.h |1 + 8 files changed, 87 insertions(+), 46 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
[PATCHV2 REPOST 4/7] ARM: OMAP3 PM: Enable IO Wake up
Enable IO Wake up for OMAP3 as part of PM Init.
Currently this has been managed in cpuidle path which is not the right place.
Subsequent patch will remove IO Daisy chain handling in cpuidle path once daisy
chain is handled as part of hwmod mux.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 448e620..258d871 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -836,6 +836,9 @@ static int __init omap3_pm_init(void)
goto err1;
}
+ if (omap3_has_io_wakeup())
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\n);
--
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
[PATCHV2 REPOST 3/7] ARM: OMAP4 PM: Add IO Daisychain support
From: Rajendra Nayak rna...@ti.com
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 30 ++
arch/arm/mach-omap2/prm44xx.h |1 +
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 67d8d74..4dc58f7 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -142,3 +142,33 @@ static int __init omap4xxx_prcm_init(void)
return omap_prcm_register_chain_handler(omap4_prcm_irq_setup);
return 0;
}
+
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP4 IO Daisychain trigger sequence */
+void omap4_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET)
+OMAP4430_GLOBAL_WUEN_MASK))
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK,
OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ ((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET)
+OMAP4430_WUCLK_STATUS_SHIFT) == 1), MAX_IOPAD_LATCH_TIME, i);
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+}
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 3d66ccd..a8678db 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -750,6 +750,7 @@
extern u32 omap4_prm_read_inst_reg(s16 inst, u16 idx);
extern void omap4_prm_write_inst_reg(u32 val, s16 inst, u16 idx);
extern u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
+extern void omap4_trigger_wuclk_ctrl(void);
/* OMAP4-specific VP functions */
u32 omap4_prm_vp_check_txdone(u8 vp_id);
--
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
[PATCHV2 REPOST 2/7] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
Since IO Daisychain modifies only PRM registers, it makes sense to move it to
PRM File.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 30 +-
arch/arm/mach-omap2/prm2xxx_3xxx.c | 33 +
arch/arm/mach-omap2/prm2xxx_3xxx.h | 14 ++
3 files changed, 48 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 074688b..448e620 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -96,34 +96,6 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
-{
- int timeout = 0;
-
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
-OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout 1000) {
- pr_err(Wake up daisy chain activation failed.\n);
- return;
- }
- }
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
-
-}
-
-static void omap3_disable_io_chain(void)
-{
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
-PM_WKEN);
-}
-
static void omap3_core_save_context(void)
{
omap3_ctrl_save_padconf();
@@ -335,7 +307,7 @@ void omap_sram_idle(void)
core_next_state PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
if (omap3_has_io_chain_ctrl())
- omap3_enable_io_chain();
+ omap3_trigger_wuclk_ctrl();
}
/* Block console output in case it is on one of the OMAP UARTs */
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 2a4a678..6db5935 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -227,6 +227,39 @@ u32 omap3_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset)
return omap2_prm_rmw_mod_reg_bits(mask, bits, OMAP3430_GR_MOD, offset);
}
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP3 Daisychain trigger sequence */
+void omap3_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(
+ (((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+OMAP3430_ST_IO_CHAIN_MASK) == 1)),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
+}
+
+/* OMAP3 Daisychain disable sequence */
+void omap3_disable_io_chain(void)
+{
+ if (omap_rev() = OMAP3430_REV_ES3_1)
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
+ PM_WKEN);
+}
+
static int __init omap3xxx_prcm_init(void)
{
if (cpu_is_omap34xx())
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index cef533d..e6f8206 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -289,6 +289,18 @@ static inline int omap2_prm_deassert_hardreset(s16
prm_mod, u8 rst_shift,
not suppose to be used on omap4\n);
return 0;
}
+static inline void omap3_trigger_wuclk_ctrl(void)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+static inline void omap3_disable_io_chain(void)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
@@ -302,6 +314,8 @@ extern u32 omap2_prm_read_mod_bits_shift(s16 domain, s16
idx, u32 mask);
extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8
st_shift);
+extern void omap3_trigger_wuclk_ctrl(void);
+extern void omap3_disable_io_chain(void);
/* OMAP3-specific VP functions */
u32 omap3_prm_vp_check_txdone(u8 vp_id);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
On Wed, Dec 14, 2011 at 8:59 PM, Kevin Hilman khil...@ti.com wrote:
Govindraj govindraj...@gmail.com writes:
On Wed, Dec 14, 2011 at 12:56 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj govindraj...@gmail.com writes:
[...]
I have re-based this patch series against LO master
commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a
Same is available here [1]
I have tested this patch series along with:
1.) Tero's V11 irq chaining series
http://www.spinics.net/lists/linux-omap/msg61445.html
(This patch series is used for uart wakeup handling using
prcm_irq chaining)
2.) Rajendra's hwmod change
http://www.spinics.net/lists/arm-kernel/msg148632.html
(This patch handles init_no_idle flag setting
without this patch there will be boot warning however
all pm features will work after boot up.)
3.) Vishwa's io daisy chain changes.
http://permalink.gmane.org/gmane.linux.ports.arm.omap/65500
(tested with and without this patch series pm features works).
Same combination of patches based on above commit id
used for testing is available here [2].
Please have a closer look at your branch.
The second commit[1] commits the .rej file from a failed patch apply,
so obviously doesn't do what was intended.
Sorry my bad I have refreshed the uart runtime branch [1]
test branch [2].
Can you add another patch which fixes these compiler warnings:
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c: In function
'serial_omap_irq':
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:228:29: warning: 'ch'
may be used uninitialized in this function [-Wuninitialized]
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:176:16: note: 'ch' was
declared here
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:228:29: warning: 'ch'
may be used uninitialized in this function [-Wuninitialized]
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:176:16: note: 'ch' was
declared here
Here is the patch [1] and pushed to
git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
--
Thanks,
Govindraj.R
[1]:
From 3a40f4e1a4c6db40d06cc6c5536ec06e9e5daf3d Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Wed, 14 Dec 2011 21:24:11 +0530
Subject: [PATCH] OMAP2+: UART: Fix compilation/sparse warnings
Fixes below compilation warning.
drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq':
drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used
uninitialized in this function [-Wuninitialized]
Fix below sparse warning.
drivers/tty/serial/omap-serial.c:392:52: warning: incorrect type in
argument 2 (different signedness)
drivers/tty/serial/omap-serial.c:392:52:expected int *status
drivers/tty/serial/omap-serial.c:392:52:got unsigned int *noident
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
drivers/tty/serial/omap-serial.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f3ff0ca..7b0303d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -166,11 +166,12 @@ static void serial_omap_stop_rx(struct uart_port *port)
pm_runtime_put_autosuspend(up-pdev-dev);
}
-static inline void receive_chars(struct uart_omap_port *up, int *status)
+static inline void receive_chars(struct uart_omap_port *up,
+ unsigned int *status)
{
struct tty_struct *tty = up-port.state-port.tty;
- unsigned int flag;
- unsigned char ch, lsr = *status;
+ unsigned int flag, lsr = *status;
+ unsigned char ch = 0;
int max_count = 256;
do {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
Hi Kevin,
On 12/14/2011 6:06 AM, Kevin Hilman wrote:
Hi Benoit,
Benoit Coussonb-cous...@ti.com writes:
Update pandaboard dts file with required clock frequencies
for the i2c client devices existing on pandaboard.
Add the twl6030 node in i2c1 controller.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add a generic i2c EEPROM entry.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Grant Likelygrant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap4-panda.dts | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 9755ad5..b66bcd6 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -18,3 +18,48 @@
reg =0x8000 0x4000; /* 1 GB */
};
};
+
+i2c1 {
+ clock-frequency =40;
+
+ /*
+* Integrated Power Management Chip
+* http://www.ti.com/lit/ds/symlink/twl6030.pdf
+*/
+ twl@48 {
+ compatible = ti,twl6030;
+ reg =0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts =0 7 4; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells =1;
+ interrupt-parent =gic;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ rtc {
+ compatible = ti,twl4030-rtc;
+ interrupts =11;
+ };
After seeing the mostly cut paste in Rajendra's regulator series, I'm
wondering if it wouldn't be better to just have a twl4030.dtsi here
which has the RTC and all the regulators with the default voltage ranges
from the TWL data sheet.
Yes, indeed, it is still small here but will become much bigger with the
regulators.
In fact twl6030 is a SoC like OMAP, so all the TWL specific internal
details can be located in a single file.
The board will just have to provide the i2c address and the IRQ information.
Not knowing much about how includes work in DT, would it then be
possible for board files to override things like default voltage ranges
for regulators?
To be honest, I was wondering as well how to do that with the /include/
functionality :-)
But I've just done a couple of DTC test, and this seems to be pretty
straightforward.
The boards will contain that:
i2c1 {
clock-frequency = 40;
twl: twl@48 {
reg = 0x48;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
interrupt-controller;
interrupt-parent = gic;
};
};
/include/ twl6030.dtsi
...
And the twl6030.dtsi will contain that for the moment:
/*
* Integrated Power Management Chip
* http://www.ti.com/lit/ds/symlink/twl6030.pdf
*/
twl {
compatible = ti,twl6030;
#interrupt-cells = 1;
/* twl is a MFD, so it will contain a bunch of sub-ips */
rtc {
compatible = ti,twl4030-rtc;
interrupts = 11;
};
};
And then all the regulators from Rajendra's series will be there as well.
This will avoid the duplication between sdp and panda. Beagle will need
a twl4030.dtsi which is different than the twl6030.
I'll update and repost the series soon.
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/10] i2c: OMAP: Add DT support for i2c controller
Benoit,
On 12/09/2011 08:02 AM, Benoit Cousson wrote:
Add initial DT support to retrieve the frequency using a
DT attribute instead of the pdata pointer if of_node exist.
Add documentation for omap i2c controller binding.
Based on original patches from Manju and Grant.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
---
Documentation/devicetree/bindings/i2c/omap-i2c.txt | 42
drivers/i2c/busses/i2c-omap.c | 100
+---
2 files changed, 107 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
diff --git a/Documentation/devicetree/bindings/i2c/omap-i2c.txt
b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
new file mode 100644
index 000..d259a17
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
@@ -0,0 +1,42 @@
+I2C for OMAP platforms
+
+Required properties :
+- compatible : Must be ti,omap3-i2c or ti,omap4-i2c
+- ti,hwmods : Must be i2cn, n being the instance number (1-based)
+- #address-cells = 1;
+- #size-cells = 0;
+
+Recommended properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
+ the default 100 kHz frequency will be used.
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+- ti,flags : u32: settings or errata relative to the i2c
+0x1: OMAP_I2C_FLAG_NO_FIFO
+0x2: OMAP_I2C_FLAG_SIMPLE_CLOCK
+0x4: OMAP_I2C_FLAG_16BIT_DATA_REG
+0x8: OMAP_I2C_FLAG_RESET_REGS_POSTIDLE
+0x10: OMAP_I2C_FLAG_APPLY_ERRATA_I207
+0x20: OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK
+0x40: OMAP_I2C_FLAG_FORCE_19200_INT_CLK
+ Valid for ti,omap3-i2c only:
+0x80: OMAP_I2C_FLAG_BUS_SHIFT_1: 8 bits registers
+0x100: OMAP_I2C_FLAG_BUS_SHIFT_2: 16 bits registers
It's generally preferred to split these out to separate properties since
there is not yet define capability in dts. Can some of these be removed
by having more specific compatible strings? That is the whole point in
having compatible strings not be generic. omap4-i2c and omap3-i2c is
still kind of generic.
+Note: Current implementation will fetch base address, irq and dma
+from omap hwmod data base during device registration.
+Future plan is to migrate hwmod data base contents into device tree
+blob so that, all the required data will be used from device tree dts
+file.
+
+Examples :
+
+i2c1: i2c@0 {
+compatible = ti,omap3-i2c;
+#address-cells = 1;
+#size-cells = 0;
+ti,hwmods = i2c1;
+clock-frequency = 40;
+ti,flags = 0x118;
+};
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a43d002..b4a8eee 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -37,6 +37,8 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/io.h
+#include linux/of_i2c.h
+#include linux/of_device.h
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
@@ -182,7 +184,9 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
- u32 speed; /* Speed of bus in Khz */
+ u32 speed; /* Speed of bus in kHz */
+ u32 dtrev; /* extra revision from DT */
+ u32 flags;
u16 cmd_err;
u8 *buf;
u8 *regs;
@@ -266,11 +270,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
- struct omap_i2c_bus_platform_data *pdata;
-
- pdata = dev-dev-platform_data;
-
- if (pdata-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ if (dev-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);
@@ -291,13 +291,10 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
- struct omap_i2c_bus_platform_data *pdata;
u16 iv;
- pdata = dev-dev-platform_data;
-
dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (pdata-rev == OMAP_I2C_IP_VERSION_2)
+ if (dev-dtrev == 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);
@@ -320,9 +317,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long timeout;
unsigned long internal_clk = 0;
struct clk *fclk;
- struct
Re: [PATCH v3 0/4] OMAP serial device tree support
On Wed, 14 Dec 2011 07:20:13 -0800 Kevin Hilman khil...@ti.com wrote: Greg, Alan, Rajendra Nayak rna...@ti.com writes: v3 is rebased on top of the latest serial runtime patches[1] and boot tested with/without DT on OMAP4 SDP and OMAP4 Panda boards. With your ack on the drivers/tty/* stuff, I can queue this via the OMAP tree on top of the runtime PM conversion that it depends on. Go for it -- 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] OMAP3: RX-51: complete tsc2005 controller support
Hi, * Vladimir Zapolskiy vladimir.zapols...@nokia.com [111214 07:09]: This change adds initialization of TSC2005 touchscreen controller found on Nokia RX-51 board. The change is taken from MeeGo kernel adaptation for Nokia N900, it repeats the work of Aaro Koskinen and Mika Laitio, the original discussion is at http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26749.html We already have commit 3dad5356aa47097cf67027cf0a07298b4f5baef6 queued up in linux-omap board branch. Can you please make this and incremental patch to that one? Looks like you got some additional changes like the muxing of the pins. 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 05/10] OMAP4: 4430sdp: Register platform device for OMAP4 audio
Hi, * Peter Ujfalusi peter.ujfal...@ti.com [111214 01:17]: To avoid breakage in audio support with the coming change in ASoC machine driver (conversion to platfrom device). Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com This series looks OK to me to queue via the ASoC tree: Acked-by: Tony Lindgren t...@atomide.com To avoid merge conflicts, you should base the branch on commit deee6d5359969a0ce4e2760cfd7b9f379bd5698a (ARM: 7194/1: OMAP: Fix build after a merge between v3.2-rc4 and ARM restart changes) in Russell's devel-stable branch because of the common.h changes. This is because at least.. --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -25,6 +25,7 @@ #include linux/regulator/fixed.h #include linux/leds.h #include linux/leds_pwm.h +#include linux/platform_data/omap-abe-twl6040.h #include mach/hardware.h #include mach/omap4-common.h ..omap4-common.h no longer exists. Just guessing, might be worth trying a test merge to see what happens. 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 08/10] OMAP4: omap4panda: Enable audio support
* Peter Ujfalusi peter.ujfal...@ti.com [111214 01:17]: PandaBoard has twl6040 codec for audio. Register the omap4-abe-twl6040 platform device. Add platform data to enable the twl6040 codec. Since there is a difference in audio between PandaBoard 4430 and PandaBoard ES (4460): Use different name for the sound card: OMAP4-Panda for PandaBoard 4430 OMAP4-PandaES for PandaBoard ES Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com This too might have some minor merge conflicts, but looks OK to queue via ASoC tree: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
On Wed, Dec 14, 2011 at 11:31:35AM +0200, Igor Grinberg wrote:
Hi Martin,
On 12/14/11 03:25, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3evm-camera.c | 155
+++
arch/arm/mach-omap2/board-omap3evm.c|4 +
3 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V3
* Added missing copyright and attribution.
* switched to gpio_request_array for gpio init.
* removed device_initcall and added call to omap3_evm_camera_init into
omap3_evm_init
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b009f17..6045789 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -196,7 +196,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
-obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
+ board-omap3evm-camera.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..bffd5b8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Authors:
+ *Vaibhav Hiremath hvaib...@ti.com
+ *Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C
Bus 2
+ *
+ * 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/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
Laurent,
In one of the previous reviews, you stated:
I'll probably split it and move the part required by board files to
include/media/omap3isp.h.
Is there any progress on that?
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL157
+
+#define MT9M032_I2C_BUS_NUM2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
I don't really care about that, but I don't see any mux
being set in the above function so the name and comments
are misleading.
There's are video
Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
* Dave Martin dave.mar...@linaro.org [111214 03:08]: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented. BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux. The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :( Sounds like devicetree is the only safe way to deal with the L2 control options. Regards, Tony This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 1/5] ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
* Anton Vorontsov cbouatmai...@gmail.com [111214 03:31]: On Wed, Dec 14, 2011 at 11:39:37AM +, Dave Martin wrote: Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other. Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select CACHE_L2X0 directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example. Signed-off-by: Dave Martin dave.mar...@linaro.org For CNS3xxx bits: Acked-by: Anton Vorontsov cbouatmai...@gmail.com For omap: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
