Re: [PATCH 1/6] ARM: OMAP2+: PM: protect the power domain state change by a mutex
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
This patch is missing a description, which would describe why this lock is
needed and what it protects against. Please add this.
---
arch/arm/mach-omap2/pm.c |8 ++--
arch/arm/mach-omap2/powerdomain.c |1 +
arch/arm/mach-omap2/powerdomain.h |3 ++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d0c1c96..6918a13 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -100,15 +100,17 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
pwrst)
if (!pwrdm || IS_ERR(pwrdm))
return -EINVAL;
+ mutex_lock(pwrdm-lock);
+
while (!(pwrdm-pwrsts (1 pwrst))) {
if (pwrst == PWRDM_POWER_OFF)
- return ret;
+ goto out;
pwrst--;
}
next_pwrst = pwrdm_read_next_pwrst(pwrdm);
if (next_pwrst == pwrst)
- return ret;
+ goto out;
curr_pwrst = pwrdm_read_pwrst(pwrdm);
if (curr_pwrst PWRDM_POWER_ON) {
@@ -141,6 +143,8 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
pwrst)
break;
}
+out:
+ mutex_unlock(pwrdm-lock);
return ret;
}
So this mutex would protect against simultaneous calls to
omap_set_pwrdm_state(), but shouldn't this protection be extended to
anything that would change the powerdomain's state? For example, couldn't
other calls to pwrdm_set_next_pwrst() race against this function?
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..319b277 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -102,6 +102,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
INIT_LIST_HEAD(pwrdm-voltdm_node);
voltdm_add_pwrdm(voltdm, pwrdm);
+ mutex_init(pwrdm-lock);
list_add(pwrdm-node, pwrdm_list);
/* Initialize the powerdomain's state counter */
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..6c6567d 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -19,7 +19,7 @@
#include linux/types.h
#include linux/list.h
-
+#include linux/mutex.h
#include linux/atomic.h
#include plat/cpu.h
@@ -116,6 +116,7 @@ struct powerdomain {
struct clockdomain *pwrdm_clkdms[PWRDM_MAX_CLKDMS];
struct list_head node;
struct list_head voltdm_node;
+ struct mutex lock;
int state;
unsigned state_counter[PWRDM_MAX_PWRSTS];
unsigned ret_logic_off_counter;
Please add a kerneldoc entry in the struct powerdomain documentation for
this field.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/10] v4l: Add support for ov5640 sensor
2012/5/2 Sergio Aguirre saagui...@ti.com:
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
There is already a limited driver in mainline for ov5642.
How does the 5642 differ from 5640 ?
Can a single driver handle both chip ?
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig | 6 +
drivers/media/video/Makefile | 1 +
drivers/media/video/ov5640.c | 948
++
include/media/ov5640.h | 10 +
4 files changed, 965 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5640.c
create mode 100644 include/media/ov5640.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4482ac4..cc76652 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -480,6 +480,12 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_OV5640
+ tristate OmniVision OV5640 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5640 camera driver
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c95cc0d..da40ab3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/video/ov5640.c b/drivers/media/video/ov5640.c
new file mode 100644
index 000..2a64d50
--- /dev/null
+++ b/drivers/media/video/ov5640.c
@@ -0,0 +1,948 @@
+/*
+ * OmniVision OV5640 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
+
+#include media/ov5640.h
+
+/* OV5640 has only one fixed colorspace per pixelcode */
+struct ov5640_datafmt {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+struct ov5640_timing_cfg {
+ u16 x_addr_start;
+ u16 y_addr_start;
+ u16 x_addr_end;
+ u16 y_addr_end;
+ u16 h_output_size;
+ u16 v_output_size;
+ u16 h_total_size;
+ u16 v_total_size;
+ u16 isp_h_offset;
+ u16 isp_v_offset;
+ u8 h_odd_ss_inc;
+ u8 h_even_ss_inc;
+ u8 v_odd_ss_inc;
+ u8 v_even_ss_inc;
+};
+
+enum ov5640_size {
+ OV5640_SIZE_QVGA,
+ OV5640_SIZE_VGA,
+ OV5640_SIZE_720P,
+ OV5640_SIZE_1080P,
+ OV5640_SIZE_5MP,
+ OV5640_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5640_frmsizes[OV5640_SIZE_LAST]
= {
+ { 320, 240 },
+ { 640, 480 },
+ { 1280, 720 },
+ { 1920, 1080 },
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5640_find_framesize(u32 width, u32 height)
+{
+ int i;
+
+ for (i = 0; i OV5640_SIZE_LAST; i++) {
+ if ((ov5640_frmsizes[i].width = width)
+ (ov5640_frmsizes[i].height = height))
+ break;
+ }
+
+ /* If not found, select biggest */
+ if (i = OV5640_SIZE_LAST)
+ i = OV5640_SIZE_LAST - 1;
+
+ return i;
+}
+
+struct ov5640 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov5640_platform_data *pdata;
+
+ struct v4l2_ctrl *pixel_rate;
+};
+
+static inline struct ov5640 *to_ov5640(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov5640, subdev);
+}
+
+/**
+ * struct ov5640_reg - ov5640 register format
+ * @reg: 16-bit
Re: [PATCH 3/3] ARM: OMAP2+ PM: Add support for TPS62361
On Fri, 2012-05-04 at 17:00 -0500, Nishanth Menon wrote:
On 16:57-20120504, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
TPS62361 is a new PMIC used with OMAP4460 on SDP4430 platform
and panda board ES to supply MPU VDD.
Rest of the VDDs continue to be supplied via TWL6030.
As part of this, the following have been moved to common
location in voltage.h
OMAP4_VP_CONFIG_ERROROFFSET, OMAP4_VP_VSTEPMIN_VSTEPMIN,
OMAP4_VP_VSTEPMAX_VSTEPMAX, OMAP4_VP_VLIMITTO_TIMEOUT_US
[n...@ti.com: cleaned up TPS to handle board variations]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
[t-kri...@ti.com: minor cleanup, added panda board support]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/Kconfig|9 ++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-4430sdp.c| 10 ++
arch/arm/mach-omap2/board-omap4panda.c |8 +
arch/arm/mach-omap2/omap_tps6236x.c| 247
arch/arm/mach-omap2/omap_twl.c |5 -
arch/arm/mach-omap2/twl-common.c |1 +
arch/arm/mach-omap2/twl-common.h | 16 ++
arch/arm/mach-omap2/voltage.h |5 +
9 files changed, 297 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_tps6236x.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8141b76..a147f00 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -334,6 +334,7 @@ config MACH_OMAP_4430SDP
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select OMAP_TPS6236X
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
@@ -342,6 +343,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select OMAP_TPS6236X
config OMAP3_EMU
bool OMAP3 debugging peripherals
@@ -384,6 +386,13 @@ config OMAP4_ERRATA_I688
In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained.
IO barrier ensure that there is no synchronisation loss on initiators
operating on both interconnect port simultaneously.
+
+config OMAP_TPS6236X
+ bool OMAP4 support for TPS6236X power IC
+ help
+ TPS62361 is a PMIC used with OMAP4460 to supply MPU VDD voltage.
+ Rest of the VDDs continue to be supplied via TWL6030.
+
endmenu
endif
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..58861a2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -22,6 +22,7 @@ obj-y += mcbsp.o
endif
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
+obj-$(CONFIG_OMAP_TPS6236X) += omap_tps6236x.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a39fc4b..58fbf64 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -63,6 +63,8 @@
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
+#define TPS62361_GPIO 7
+
static const int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_R),
@@ -958,6 +960,14 @@ static void __init omap_4430sdp_init(void)
pr_err(Keypad initialization failed: %d\n, status);
omap_4430sdp_display_init();
+
+ if (cpu_is_omap446x()) {
+ /* Vsel0 = gpio, vsel1 = gnd */
+ status = omap_tps6236x_board_setup(true, TPS62361_GPIO, -1,
+ OMAP_PIN_OFF_OUTPUT_HIGH, -1);
+ if (status)
+ pr_err(TPS62361 initialization failed: %d\n, status);
+ }
}
MACHINE_START(OMAP_4430SDP, OMAP4430 4430SDP board)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d8c0e89..5b5a6bc 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -55,6 +55,7 @@
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define HDMI_GPIO_HPD 63 /* Hotplug detect */
+#define TPS62361_GPIO 7 /* Vsel0 control for TPS62361 */
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
@@ -572,6 +573,13 @@ static void __init omap4_panda_init(void)
omap4_ehci_init();
usb_musb_init(musb_board_data);
omap4_panda_display_init();
+ if (cpu_is_omap446x()) {
+ /* vsel0 = gpio, vsel1 = gnd */
+ ret = omap_tps6236x_board_setup(true, TPS62361_GPIO, -1,
+ OMAP_PIN_OFF_OUTPUT_HIGH, -1);
+ if (ret)
+
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
Hi Igor, On Sun, May 06, 2012 at 09:25:05AM +0300, Igor Grinberg wrote: Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) Sorry about that. and I'd like this to go into 3.5. Then you may need a better changelog explaining how this fixes a regression, runtime crash or build failure. Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? At that point, it definitely makes more sense for Alan to push it. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 08/13] ARM: OMAP5: Add the WakeupGen IP updates.
On Saturday 05 May 2012 04:25 AM, Tony Lindgren wrote:
* R Sricharan r.sricha...@ti.com [120503 00:30]:
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -17,8 +17,10 @@
#include linux/kernel.h
#include linux/errno.h
#include linux/smp.h
+#include linux/io.h
#include asm/cacheflush.h
+#include mach/omap-wakeupgen.h
#include common.h
@@ -35,7 +37,8 @@ int platform_cpu_kill(unsigned int cpu)
*/
void __ref platform_cpu_die(unsigned int cpu)
{
-unsigned int this_cpu;
+unsigned int boot_cpu = 0;
+void __iomem *base = omap_get_wakeupgen_base();
flush_cache_all();
dsb();
@@ -43,16 +46,27 @@ void __ref platform_cpu_die(unsigned int cpu)
/*
* we're ready for shutdown now, so do it
*/
-if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
-pr_err(Secure clear status failed\n);
+if (cpu_is_omap44xx()) {
+if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
+pr_err(Secure clear status failed\n);
+} else {
+__raw_writel(0, base + OMAP_AUX_CORE_BOOT_0);
+}
+
for (;;) {
/*
* Enter into low power state
*/
omap4_hotplug_cpu(cpu, PWRDM_POWER_OFF);
-this_cpu = smp_processor_id();
-if (omap_read_auxcoreboot0() == this_cpu) {
+
+if (cpu_is_omap44xx())
+boot_cpu = omap_read_auxcoreboot0();
+else
+boot_cpu =
+__raw_readl(base + OMAP_AUX_CORE_BOOT_0) 5;
+
+if (boot_cpu == smp_processor_id()) {
/*
* OK, proper wakeup, we're done
*/
These should use variables set up during init instead of cpu_is_omapxxx
checks.
Sounds good. Will fit it.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: OMAP2+: PM: introduce power domains functional states
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Introduce functional (or logical) states for power domains and the
API functions to read the power domains settings and to convert
between the functional (i.e. logical) and the internal (or registers)
values.
OMAP2, OMAP3 and OMAP4 platforms are defining a conversion routine.
In the new API the function omap_set_pwrdm_state takes the functional
states as parameter; while at it the function is moved to the power
domains code.
The memory and logic states are not using the functional states, this
comes as a subsequent patch.
Signed-off-by: Jean Pihet j-pi...@ti.com
This patch results in several checkpatch warnings; please resolve them.
---
arch/arm/mach-omap2/pm.c | 66 ---
arch/arm/mach-omap2/powerdomain-common.c | 61 ++
arch/arm/mach-omap2/powerdomain.c | 175
arch/arm/mach-omap2/powerdomain.h | 21
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |5 +
arch/arm/mach-omap2/powerdomain44xx.c |2 +
6 files changed, 264 insertions(+), 66 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 6918a13..8670c4b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -74,10 +74,6 @@ static void __init omap2_init_processor_devices(void)
}
}
-/* Types of sleep_switch used in omap_set_pwrdm_state */
-#define FORCEWAKEUP_SWITCH 0
-#define LOWPOWERSTATE_SWITCH 1
-
int __init omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused)
{
if (clkdm-flags CLKDM_CAN_ENABLE_AUTO)
@@ -89,68 +85,6 @@ int __init omap_pm_clkdms_setup(struct clockdomain *clkdm,
void *unused)
}
/*
- * This sets pwrdm state (other than mpu core. Currently only ON
- * RET are supported.
- */
-int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst)
-{
- u8 curr_pwrst, next_pwrst;
- int sleep_switch = -1, ret = 0, hwsup = 0;
-
- if (!pwrdm || IS_ERR(pwrdm))
- return -EINVAL;
-
- mutex_lock(pwrdm-lock);
-
- while (!(pwrdm-pwrsts (1 pwrst))) {
- if (pwrst == PWRDM_POWER_OFF)
- goto out;
- pwrst--;
- }
-
- next_pwrst = pwrdm_read_next_pwrst(pwrdm);
- if (next_pwrst == pwrst)
- goto out;
-
- curr_pwrst = pwrdm_read_pwrst(pwrdm);
- if (curr_pwrst PWRDM_POWER_ON) {
- if ((curr_pwrst pwrst)
- (pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE)) {
- sleep_switch = LOWPOWERSTATE_SWITCH;
- } else {
- hwsup = clkdm_in_hwsup(pwrdm-pwrdm_clkdms[0]);
- clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
- sleep_switch = FORCEWAKEUP_SWITCH;
- }
- }
-
- ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
- if (ret)
- pr_err(%s: unable to set power state of powerdomain: %s\n,
-__func__, pwrdm-name);
-
- switch (sleep_switch) {
- case FORCEWAKEUP_SWITCH:
- if (hwsup)
- clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
- else
- clkdm_sleep(pwrdm-pwrdm_clkdms[0]);
- break;
- case LOWPOWERSTATE_SWITCH:
- pwrdm_set_lowpwrstchange(pwrdm);
- pwrdm_wait_transition(pwrdm);
- pwrdm_state_switch(pwrdm);
- break;
- }
-
-out:
- mutex_unlock(pwrdm-lock);
- return ret;
-}
-
-
-
-/*
* This API is to be called during init to set the various voltage
* domains to the voltage as per the opp table. Typically we boot up
* at the nominal voltage. So this function finds out the rate of
diff --git a/arch/arm/mach-omap2/powerdomain-common.c
b/arch/arm/mach-omap2/powerdomain-common.c
index c0aeabf..098dc42 100644
--- a/arch/arm/mach-omap2/powerdomain-common.c
+++ b/arch/arm/mach-omap2/powerdomain-common.c
@@ -108,3 +108,64 @@ u32 omap2_pwrdm_get_mem_bank_stst_mask(u8 bank)
return 0;
}
+/*
+ * Functional (i.e. logical) to internal (i.e. registers)
+ * values for the power domains states
+ */
Please use kerneldoc-style function comments.
+int omap2_pwrdm_func_to_pwrst(struct powerdomain *pwrdm, u8 func_pwrst)
+{
+ int ret;
+
+ switch (func_pwrst) {
+ case PWRDM_FUNC_PWRST_ON:
+ ret = PWRDM_POWER_ON;
+ break;
+ case PWRDM_FUNC_PWRST_INACTIVE:
+ ret = PWRDM_POWER_INACTIVE;
+ break;
+ case PWRDM_FUNC_PWRST_CSWR:
+ case PWRDM_FUNC_PWRST_OSWR:
+ ret = PWRDM_POWER_RET;
+ break;
+ case PWRDM_FUNC_PWRST_OFF:
+ ret = PWRDM_POWER_OFF;
+ break;
+ default:
+ ret = -1;
+ }
+
+ return ret;
+}
At a quick glance, I don't think
Re: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
Tony, On Thursday 03 May 2012 12:56 PM, R Sricharan wrote: The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Series is generated against the 3.4-rc5. This has been rebased on top of the OMAP2+ cleanup series [1] To get the boot working with omap2plus_defconfig, OMAP5 hwmod/clock/prm/cm database needs to be added. The data and the integrated tree are available in the below git repository OMAP5_DATA: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_data OMAP5_INTEGRATED: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_dt_integrated The series is boot tested on OMAP5430 ES1.0. OMAP2/3/4 build and boot is tested as well to avoid any breakage because of the series. Patch TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks is temporary and can be dropped once rebased against [2] Patch TEMP: ARM: OMAP5: Update the base address of the 32k-counter is temporary and can be dropped once rebased against [3] [1] http://www.spinics.net/lists/linux-omap/msg69233.html [2] http://www.spinics.net/lists/linux-omap/msg69013.html [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html Do you have a branch where above dependencies are merged ? How do you suggest to go about updating this series so that above dependencies plus DT support(3.3 based branch in arm-soc tree and needs to be updated against 3.4) is base tree for the patchset. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
Hi Paul, On 5/2/2012 11:09 AM, Paul Walmsley wrote: On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: I will be waiting for your comment and conformation on, which family AM33xx device should fall in? Please refer to the mail-chain - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html This decision turns out to be pretty important; it certainly affects the AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. Here is my suggestion, based on our previous practice. I am not so sure that it is the best way, but it seems pretty reasonable Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as far as I can tell. The main area of similarity between the other CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU subsystem is quite different between, say, the 3430/3630 and the AM33xx. Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM interface, OMAP4-style interconnect, etc. Plus, most of the CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like the PM code. This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, PL310, etc. None of that is true for AM335x. So first we have to decide whether the CONFIG_ARCH_OMAP* options should have a strong dependency on the MPU type, as they currently do; or whether they should focus on the way the SoC is integrated. I think as well that these devices should be considered as part of the OMAP4 family. The CPU type should not be the parameter that decide the OMAP family, it is just an IP, that can change on some variant, whereas the whole PRCM infrastructure / interconnect is mostly the same. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
On Mon, May 7, 2012 at 4:02 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Paul, On 5/2/2012 11:09 AM, Paul Walmsley wrote: On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: I will be waiting for your comment and conformation on, which family AM33xx device should fall in? Please refer to the mail-chain - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html This decision turns out to be pretty important; it certainly affects the AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. Here is my suggestion, based on our previous practice. I am not so sure that it is the best way, but it seems pretty reasonable Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as far as I can tell. The main area of similarity between the other CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU subsystem is quite different between, say, the 3430/3630 and the AM33xx. Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM interface, OMAP4-style interconnect, etc. Plus, most of the CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like the PM code. This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, PL310, etc. None of that is true for AM335x. So first we have to decide whether the CONFIG_ARCH_OMAP* options should have a strong dependency on the MPU type, as they currently do; or whether they should focus on the way the SoC is integrated. I think as well that these devices should be considered as part of the OMAP4 family. The CPU type should not be the parameter that decide the OMAP family, it is just an IP, that can change on some variant, whereas the whole PRCM infrastructure / interconnect is mostly the same. I agree. In fact more and more I think of this problem, looks like we should get rid off ARCH_OMAP* and just is SOC_* going forward. Common ARM code already takes care of different CPU version and as Benoit mentioned it is just one of the IP in the entire SOC. I saw tony commenting in similarly on of the patch set. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Jon, On Fri, May 04, 2012 at 21:50:16, Hunter, Jon wrote: As mentioned in the cover letter, Additional features that currently boards in mainline does not make use of like, waitpin interrupt handling, changes to leverage revision 6 IP differences has not been incorporated. Priority in this series is to convert into a driver, get all boards working on mainline. Once all boards are working with gpmc driver, these features which are not required for currently supported boards can be added later. Yes, but I meant why 2 and not say 5? Anyway, I think that this should be marked with a comment like a TODO so it is clear that this needs to be re-visited. Ok, it will be marked with TODO I think that it make more sense to have the wait-pin information part of the gpmc_cs_data structure for the following reasons ... Waitpin information is indeed a part of cs as far as boards are concerned, it is only that it gets propogated to device Why does the device's driver care? From my point of view, the wait-pin is just part of the interface setup/configuration. The external device may require this and assumes that this has been setup along with the CS and interface timing, but the device's driver should not care. Remember this is just a ready signal used to stall the access. Once configured, software should be unaware of it. By device, it is referred to gpmc device which only gpmc driver is aware, the peripheral device's driver is not at all aware. Also, any reason why waitpin_polarity is an int? I see you define LOW as -1, but I not sure why LOW cannot be 0 as 0 is programmed into the register for an active low wait signal. Only intention is not to alter default waitpin polarity value, i.e. if any board does make use of it w/o knowledge of Kernel, I don't want to break it, there may be an argument saying that the board code is buggy, while if some board does so, it is, but don't want to break working one. Here unless user explicitly set the flag, it does nothing on polarity Ok. Do such scenario's exist today? Please note that board code will be removed in the future and device-tree will replace. So if there are no cases today, I would not be concerned. Unless this could be something that has already been configured by the bootloader. However, in that case would be even call this function? Let me check this, here only intent was to play safe, as I have only two boards to test. +int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *cs) What scenario is this function used in? May be worth adding a comment about the function. Ok, it was required for OneNAND, as it needs to reconfigure Ok, but why is that? Unless this is something generic about one-nand I don't comprehend. I have a high-level understanding of one-nand, but I am not familiar with the specifics that require it to be reconfigured. Not too familiar with OneNAND, from the code it has been understood that to set into sync mode, first it may have to set to async mode, read frequency from OneNAND, then setup sync mode for that frequency. + gpmc_setup_writeprotect(gpmc); Write protect is a pin and there is only one. Like the waitpins and CS signals this needs to be associated with a device. It would make sense that this is associated with the cs data. As far as platform are concerned, it is associated with cs, it is only that while configuring CS, it is propagated such that it is done once. Hmmm ... but here it looks like if write-protect is used you are going to turn it on. A feature like this seems that it does need to be handled by the device's driver. Enabling and disabling write-protect are functions that I would expect are exported to the device's driver and not directly enabled in the gpmc driver during probe. However, maybe is could be valid for the write protect to be enabled by default which could make sense. However, I don't see anywhere else in the driver to control it. Shouldn't we warn on multiple devices trying to use write-protect when parsing their configuration? Even if a single device sets write protect, kernel will log it. Regards Afzal -- 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 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Jon,
On Fri, May 04, 2012 at 21:57:10, Hunter, Jon wrote:
- gpmc_write_reg(GPMC_SYSCONFIG, l);
- gpmc_mem_init();
+ switch (conf GPMC_WAITPIN_MASK) {
+ case GPMC_WAITPIN_0:
+ idx = GPMC_WAITPIN_IDX0;
+ break;
+ case GPMC_WAITPIN_1:
+ idx = GPMC_WAITPIN_IDX1;
+ break;
+ case GPMC_WAITPIN_2:
+ idx = GPMC_WAITPIN_IDX2;
+ break;
+ case GPMC_WAITPIN_3:
+ idx = GPMC_WAITPIN_IDX3;
+ break;
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+ break;
+ }
Why not combined case 0 and default? Both are invalid configurations so
just report invalid selection.
Case 0 is not invalid, a case where waitpin is not used, default refers
to when a user selects multiple waitpins wrongly.
- /* initalize the irq_chained */
- irq = OMAP_GPMC_IRQ_BASE;
- for (cs = 0; cs GPMC_CS_NUM; cs++) {
- irq_set_chip_and_handler(irq, dummy_irq_chip,
- handle_simple_irq);
- set_irq_flags(irq, IRQF_VALID);
- irq++;
+ switch (conf GPMC_WAITPIN_POLARITY_MASK) {
+ case GPMC_WAITPIN_ACTIVE_LOW:
+ polarity = LOW;
+ break;
+ case GPMC_WAITPIN_ACTIVE_HIGH:
+ polarity = HIGH;
+ break;
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, waitpin polarity set to low high\n);
+ return -EINVAL;
+ break;
}
Again, combine case 0 and default as these are invalid.
Similar to above
+ if (gd-have_waitpin) {
+ if (gd-waitpin != idx ||
+ gd-waitpin_polarity != polarity) {
+ dev_err(gpmc-dev, error: conflict: waitpin %u
with polarity %d on device %s.%d\n,
+ gd-waitpin, gd-waitpin_polarity,
+ gd-name, gd-id);
+ return -EBUSY;
+ }
+ } else {
Don't need the else as you are going to return in the above.
Not always, only in case of error
+ gd-have_waitpin = true;
+ gd-waitpin = idx;
+ gd-waitpin_polarity = polarity;
+ }
+
+ l = ~GPMC_CONFIG1_WAIT_PIN_SEL_MASK;
+ l |= GPMC_CONFIG1_WAIT_PIN_SEL(idx);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+ } else if (polarity) {
+ dev_err(gpmc-dev, error: waitpin polarity specified with out
wait pin number on device %s.%d\n,
+ gd-name, gd-id);
+ return -EINVAL;
Drop this else-if. The above switch statements will report the bad
configuration. This seems a bit redundant.
This is required as switch statements will not report error if polarity
is specified, w/o waitpin to be used.
Regards
Afzal
--
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 RESEND] ARM: OMAP: Revert ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
Hi Tony, Paul, Could you please consider this patch for the next -rc cycle, it fixes contention errors seen on the DSI panel on OMAP4 SDP. Thanks, Archit On Thursday 19 April 2012 05:39 PM, Archit Taneja wrote: This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Cc: sta...@vger.kernel.org # v3.2+ Acked-by: Tomi Valkeinentomi.valkei...@ti.com Signed-off-by: Archit Tanejaarc...@ti.com --- Note: Resend with stable kernel list added in cc .../include/mach/ctrl_module_pad_core_44xx.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h index 1e2d332..c88420d 100644 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h @@ -941,10 +941,10 @@ #define OMAP4_DSI2_LANEENABLE_MASK(0x7 29) #define OMAP4_DSI1_LANEENABLE_SHIFT 24 #define OMAP4_DSI1_LANEENABLE_MASK(0x1f 24) -#define OMAP4_DSI2_PIPD_SHIFT 19 -#define OMAP4_DSI2_PIPD_MASK (0x1f 19) -#define OMAP4_DSI1_PIPD_SHIFT 14 -#define OMAP4_DSI1_PIPD_MASK (0x1f 14) +#define OMAP4_DSI1_PIPD_SHIFT 19 +#define OMAP4_DSI1_PIPD_MASK (0x1f 19) +#define OMAP4_DSI2_PIPD_SHIFT 14 +#define OMAP4_DSI2_PIPD_MASK (0x1f 14) /* CONTROL_MCBSPLP */ #define OMAP4_ALBCTRLRX_FSX_SHIFT 31 -- 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 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Jon, On Fri, May 04, 2012 at 22:00:21, Hunter, Jon wrote: + + pdata-clk_prd = gpmc_get_fclk_period(); Does this need to be done here? May be this should be done in the probe function. You could store the handle to the main clk in the pdata. This is done so that migration of gpmc driver to the drivers folder would be smooth, remember that this function will still live here. Sure, but why call this here? Clk_prd is a platform data passed to the driver, so platform code updates it, where else can it be done ? Regards Afzal -- 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-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi Paul,
On Sun, May 06, 2012 at 07:34:07, Paul Walmsley wrote:
Did you notice the warning that this patch generates on boot?
omap_hwmod: gpmc: cannot be enabled for reset (3)
The HWMOD_NO_IDLEST hwmod flag is needed, since there is no GPMC IDLEST
bit.
Yes, putting that flag makes warning go away, Thanks
...
Also, the OMAP2xxx GPMC hwmod data is missing. It can be combined
with this patch.
In v4, it has been sent as two patches - one for 3xxx one for 2xxx,
do you want to combine both ?
+static struct omap_hwmod omap3xxx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap3xxx_gpmc_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap3xxx_gpmc_irqs,
+ .main_clk = gpmc_fck,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+};
Is there some reason why you are setting the HWMOD_INIT_NO_RESET flag
here? Seems to me that the kernel should not rely on the bootloader GPMC
configuration, but should use a configuration from the board file or DT.
Major reason was that there are some boards that rely on bootloader
settings, eg. kernel does not do any setting for smsc911x. I did not
want to break those, at least it causes problem with omap3evm, see below
Another was that this was created based on,
eb42b5d ARM: OMAP4: hwmod data: add GPMC and an internal one for AM335X,
Both had HWMOD_INIT_NO_RESET flag.
Removing it causes multiple problems, one is that CS0 is valid after reset
of module, with base address starting from zero, which causes requesting
resource failure for CS0, with the way it is currently coded (GPMC resource
starts from 1MB). Even upon skipping CS0, kernel oops at seemingly unrelated
location as follows, probably due to gpmc reset, as bootloader configured
values are modified to reset value. Omap3 evm uses smsc911x.
[2.660095] WARNING: at /home/afzal/dev/SA/src/-kernel/kernel/lockdep.c:956
__bfs+0x1f0/0x230()
[2.669708] Modules linked in:
[2.672973] [c001a568] (unwind_backtrace+0x0/0xf0) from [c003cfec]
(warn_slowpath_common+0x4c/0x64)
[2.682891] [c003cfec] (warn_slowpath_common+0x4c/0x64) from [c003d020]
(warn_slowpath_null+0x1c/0x24)
[2.693084] [c003d020] (warn_slowpath_null+0x1c/0x24) from [c00827d0]
(__bfs+0x1f0/0x230)
[2.702087] [c00827d0] (__bfs+0x1f0/0x230) from [c0084a74]
(check_usage_forwards+0x60/0x10c)
[2.711364] [c0084a74] (check_usage_forwards+0x60/0x10c) from [c00857b8]
(mark_lock+0x1bc/0x64c)
[2.720977] [c00857b8] (mark_lock+0x1bc/0x64c) from [c0086634]
(__lock_acquire+0x9ec/0x1c64)
[2.730255] [c0086634] (__lock_acquire+0x9ec/0x1c64) from [c0087e3c]
(lock_acquire+0x98/0x100)
[2.739715] [c0087e3c] (lock_acquire+0x98/0x100) from [c004a5f8]
(run_timer_softirq+0x13c/0x378)
[2.749359] [c004a5f8] (run_timer_softirq+0x13c/0x378) from [c00438b0]
(__do_softirq+0xc8/0x1f4)
[2.759002] [c00438b0] (__do_softirq+0xc8/0x1f4) from [c0043e64]
(irq_exit+0x90/0x98)
[2.767639] [c0043e64] (irq_exit+0x90/0x98) from [c00141dc]
(handle_IRQ+0x50/0xac)
[2.776000] [c00141dc] (handle_IRQ+0x50/0xac) from [c00086fc]
(omap3_intc_handle_irq+0x54/0x68)
[2.785552] [c00086fc] (omap3_intc_handle_irq+0x54/0x68) from [c0425724]
(__irq_svc+0x4
Another issue on OMAP3EVM is the detection of evm revision based on phy id,
by reading hardcoded address, 0x2c00. It had to be skipped to reach till
above mentioned.
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] OMAPDSS: Misc fixes and cleanups
The first patch in this series is a follow up on the previously posted series 'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is required for HDMI and DPI interfaces to work properly, it ensures manager timings are applied in the set_timing() ops for these interfaces. The next 3 patches remove some unnecessary usage of omap_dss_device pointer in DISPC and APPLY. The last 2 patches are miscellaneous fixes and are self explanatory. Reference tree containing this series: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes Tested on OMAP4 SDP. Archit Taneja (6): OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() OMAPDSS: Fix DSI_FCLK clock source selection OMAPDSS: DISPC: Remove Fake VSYNC support drivers/video/omap2/dss/Kconfig |9 -- drivers/video/omap2/dss/apply.c |3 -- drivers/video/omap2/dss/dispc.c | 61 +- drivers/video/omap2/dss/dpi.c |2 + drivers/video/omap2/dss/dsi.c |4 -- drivers/video/omap2/dss/dss.c |5 ++- drivers/video/omap2/dss/dss.h |1 - drivers/video/omap2/dss/hdmi.c |2 + 8 files changed, 28 insertions(+), 59 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] OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
The HDMI and DPI interfaces use their 'set_timing' functions to take in a new
set of timings. If the panel is disabled, they do not disable and re-enable
the interface. Currently, the manager timings are applied in hdmi_power_on()
and dpi_set_mode() respectively, these are not called by set_timings if the
panel is disabled.
When checking overlay and manager data, the DSS driver uses the last applied
manager timings, and not the timings stored in omap_dss_device struct. Hence,
there is a need to apply the new manager timings even if the panel is disabled.
Apply the manager timings if the panel is disabled. Eventually, there should be
one common place where the timings are applied independent of the state of the
panel.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dpi.c |2 ++
drivers/video/omap2/dss/hdmi.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 8127f46..1650050 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -298,6 +298,8 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
dispc_runtime_put();
dss_runtime_put();
+ } else {
+ dss_mgr_set_timings(dssdev-manager, timings);
}
}
EXPORT_SYMBOL(dpi_set_timings);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8d4ff8c..32ad712 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -435,6 +435,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device
*dssdev)
r = hdmi_power_on(dssdev);
if (r)
DSSERR(failed to power on device\n);
+ } else {
+ dss_mgr_set_timings(dssdev-manager, dssdev-panel.timings);
}
}
--
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 2/6] OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
the pointer variable declaration and it's assignment.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 052d9a2..756c31a 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -977,14 +977,11 @@ static void dss_ovl_setup_fifo(struct omap_overlay *ovl,
bool use_fifo_merge)
{
struct ovl_priv_data *op = get_ovl_priv(ovl);
- struct omap_dss_device *dssdev;
u32 fifo_low, fifo_high;
if (!op-enabled !op-enabling)
return;
- dssdev = ovl-manager-device;
-
dispc_ovl_compute_fifo_thresholds(ovl-id, fifo_low, fifo_high,
use_fifo_merge);
--
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] OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate()
The pixel clock rate for the TV manager is calculated by checking the device
type connected to the manager, and then requesting the VENC/HDMI interface for
the pixel clock rate.
Remove the use of omap_dss_device pointer from here by checking which interface
generates the pixel clock by reading the DSS_CTRL.VENC_HDMI_SWITCH bit.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 49015b8..c198cc8 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2643,13 +2643,14 @@ unsigned long dispc_mgr_pclk_rate(enum omap_channel
channel)
return r / pcd;
} else {
- struct omap_dss_device *dssdev =
- dispc_mgr_get_device(channel);
+ enum dss_hdmi_venc_clk_source_select source;
- switch (dssdev-type) {
- case OMAP_DISPLAY_TYPE_VENC:
+ source = dss_get_hdmi_venc_clk_source();
+
+ switch (source) {
+ case DSS_VENC_TV_CLK:
return venc_get_pixel_clock();
- case OMAP_DISPLAY_TYPE_HDMI:
+ case DSS_HDMI_M_PCLK:
return hdmi_get_pixel_clock();
default:
BUG();
--
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] OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
function dispc_mgr_get_device() to get the omap_dss_device pointer to which
the manager is connected, the width of the panel is derived from that.
Replace this by using dss_mgr_get_device() which returns the manager's timing
stored in it's private data in APPLY. This contains the latest timings applied
to the manager. Remove the function dispc_mgr_get_device() as it isn't used
any more.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 29 +++--
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index c198cc8..ef131cd 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -413,14 +413,6 @@ static inline bool dispc_mgr_is_lcd(enum omap_channel
channel)
return false;
}
-static struct omap_dss_device *dispc_mgr_get_device(enum omap_channel channel)
-{
- struct omap_overlay_manager *mgr =
- omap_dss_get_overlay_manager(channel);
-
- return mgr ? mgr-device : NULL;
-}
-
u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
{
switch (channel) {
@@ -1665,14 +1657,17 @@ static int check_horiz_timing_omap3(enum omap_channel
channel, u16 pos_x,
u16 width, u16 height, u16 out_width, u16 out_height)
{
int DS = DIV_ROUND_UP(height, out_height);
- struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
- struct omap_video_timings t = dssdev-panel.timings;
+ struct omap_overlay_manager *mgr;
+ struct omap_video_timings *t;
unsigned long nonactive, lclk, pclk;
static const u8 limits[3] = { 8, 10, 20 };
u64 val, blank;
int i;
- nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+ mgr = omap_dss_get_overlay_manager(channel);
+ t = dss_mgr_get_timings(mgr);
+
+ nonactive = t-x_res + t-hfp + t-hsw + t-hbp - out_width;
pclk = dispc_mgr_pclk_rate(channel);
if (dispc_mgr_is_lcd(channel))
lclk = dispc_mgr_lclk_rate(channel);
@@ -1684,7 +1679,7 @@ static int check_horiz_timing_omap3(enum omap_channel
channel, u16 pos_x,
i++;
if (out_width width)
i++;
- blank = div_u64((u64)(t.hbp + t.hsw + t.hfp) * lclk, pclk);
+ blank = div_u64((u64)(t-hbp + t-hsw + t-hfp) * lclk, pclk);
DSSDBG(blanking period + ppl = %llu (limit = %u)\n, blank, limits[i]);
if (blank = limits[i])
return -EINVAL;
@@ -1725,8 +1720,14 @@ static unsigned long calc_core_clk_five_taps(enum
omap_channel channel,
return (unsigned long) pclk;
if (height out_height) {
- struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
- unsigned int ppl = dssdev-panel.timings.x_res;
+ struct omap_overlay_manager *mgr;
+ struct omap_video_timings *mgr_timings;
+ unsigned int ppl;
+
+ mgr = omap_dss_get_overlay_manager(channel);
+ mgr_timings = dss_mgr_get_timings(mgr);
+
+ ppl = mgr_timings-x_res;
tmp = pclk * height * out_width;
do_div(tmp, 2 * out_height * ppl);
--
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 5/6] OMAPDSS: Fix DSI_FCLK clock source selection
The wrong bit field was being updated in DSS_CTRL when trying to configure the
clock source of DSI2 functional clock. Use the correct bit field based on the
dsi module number.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dss.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index e731aa4..e212acb 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -335,7 +335,7 @@ void dss_select_dsi_clk_source(int dsi_module,
enum omap_dss_clk_source clk_src)
{
struct platform_device *dsidev;
- int b;
+ int b, pos;
switch (clk_src) {
case OMAP_DSS_CLK_SRC_FCK:
@@ -357,7 +357,8 @@ void dss_select_dsi_clk_source(int dsi_module,
BUG();
}
- REG_FLD_MOD(DSS_CONTROL, b, 1, 1); /* DSI_CLK_SWITCH */
+ pos = dsi_module == 0 ? 1 : 10;
+ REG_FLD_MOD(DSS_CONTROL, b, pos, pos); /* DSIx_CLK_SWITCH */
dss.dsi_clk_source[dsi_module] = clk_src;
}
--
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] OMAPDSS: DISPC: Remove Fake VSYNC support
Fake VSYNC support is a hack and has some bugs in it. It isn't used by any user
of DSS. Remove Fake VSYNC support. For DSI command mode and RFBI panels, a user
of DSS should wait for the completion of a frame by using the panel driver's
sync op.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/Kconfig |9 -
drivers/video/omap2/dss/dispc.c | 21 -
drivers/video/omap2/dss/dsi.c |4
drivers/video/omap2/dss/dss.h |1 -
4 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 7be7c06..9aaf324 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -90,15 +90,6 @@ config OMAP2_DSS_DSI
See http://www.mipi.org/ for DSI spesifications.
-config OMAP2_DSS_FAKE_VSYNC
- bool Fake VSYNC irq from manual update displays
- default n
- help
- If this is selected, DSI will generate a fake DISPC VSYNC interrupt
- when DSI has sent a frame. This is only needed with DSI or RFBI
- displays using manual mode, and you want VSYNC to, for example,
- time animation.
-
config OMAP2_DSS_MIN_FCK_PER_PCK
int Minimum FCK/PCK ratio (for scaling)
range 0 32
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ef131cd..89d54c5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3443,27 +3443,6 @@ int omap_dispc_wait_for_irq_interruptible_timeout(u32
irqmask,
return 0;
}
-#ifdef CONFIG_OMAP2_DSS_FAKE_VSYNC
-void dispc_fake_vsync_irq(void)
-{
- u32 irqstatus = DISPC_IRQ_VSYNC;
- int i;
-
- WARN_ON(!in_interrupt());
-
- for (i = 0; i DISPC_MAX_NR_ISRS; i++) {
- struct omap_dispc_isr_data *isr_data;
- isr_data = dispc.registered_isr[i];
-
- if (!isr_data-isr)
- continue;
-
- if (isr_data-mask irqstatus)
- isr_data-isr(isr_data-arg, irqstatus);
- }
-}
-#endif
-
static void _omap_dispc_initialize_irq(void)
{
unsigned long flags;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index db73598..95bc996 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4152,10 +4152,6 @@ static void dsi_framedone_irq_callback(void *data, u32
mask)
__cancel_delayed_work(dsi-framedone_timeout_work);
dsi_handle_framedone(dsidev, 0);
-
-#ifdef CONFIG_OMAP2_DSS_FAKE_VSYNC
- dispc_fake_vsync_irq();
-#endif
}
int omap_dsi_update(struct omap_dss_device *dssdev, int channel,
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f2a51c6..6699197 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -399,7 +399,6 @@ void dispc_dump_clocks(struct seq_file *s);
void dispc_dump_irqs(struct seq_file *s);
void dispc_dump_regs(struct seq_file *s);
void dispc_irq_handler(void);
-void dispc_fake_vsync_irq(void);
int dispc_runtime_get(void);
void dispc_runtime_put(void);
--
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 14/14] OMAPDSS: HDMI: Implement DSS driver interface for audio
Hi, On Thu, 2012-05-03 at 20:44 -0500, Ricardo Neri wrote: Implement the DSS device driver audio support interface in the HDMI panel driver and generic driver. The implementation relies on the IP-specific functions that are defined at DSS probe time. At the moment, a hardirq-safe spinlock is used to protect the audio functions. This is because such functions might be called while holding a lock (this especially true for audio_start/stop). For the rest of the audio functions, a mutex could be used in the future as the enablement of resources might take too much time. The series looks good, except locking. Granted, the locking in omapdss is a bit bad generally also, but here I think it's a bit more broken. For example, hdmi_panel.c:hdmi_panel_audio_supported() takes the audio lock, and then uses variables like dssdev-state, and the hdmi video mode. However, the video functions do not use audio lock, so effectively the lock doesn't protect at all. I'm not sure how to fix it, though. I think this shows the shortcomings of the current locking strategy (or lack of =). What if the audio functions that can sleep would take the hdmi panel's mutex, and also the audio spinlock? That would at least fix some of the cases. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
Hi Samuel, On 05/07/12 11:09, Samuel Ortiz wrote: Hi Igor, On Sun, May 06, 2012 at 09:25:05AM +0300, Igor Grinberg wrote: Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) Sorry about that. and I'd like this to go into 3.5. Then you may need a better changelog explaining how this fixes a regression, runtime crash or build failure. Well, I did not say it is a regression. In fact it is not. I just finally sent a fix to eliminate a runtime warning which was there for a long time and can be seen on specific configurations. That is why, I want it into 3.5 during the merge window (not 3.4 although I won't object it to go in earlier ;-) ). Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? At that point, it definitely makes more sense for Alan to push it. Yep, makes sense to me. Alan? -- 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 2/3] ARM: OMAP3+: PM: introduce a central pmic control
Hi Tero,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Friday, May 04, 2012 7:27 PM
To: linux-omap@vger.kernel.org; khil...@ti.com
Cc: linux-arm-ker...@lists.infradead.org; Nishanth Menon
Subject: [PATCH 2/3] ARM: OMAP3+: PM: introduce a central pmic
control
From: Nishanth Menon n...@ti.com
Since we are starting to use multiple PMICs in various combinations,
use the existing .omap_chip = OMAP_CHIP_INIT() to mark the
structures we are interested in using per OMAP device we
are currently running on. This mapping is based on the default
device recommendations from TI. Boards using custom PMICs now
have an opportunity to register their own custom mapping.
With this we no longer need omap4_twl_init and omap3_twl_int
instead we introduce a registration mechanism which is PMIC
generic and move twl implementation to use the same. This allows
for future OMAP4460 support where there is a mixture of
PMIC combinations used.
In this patch, you seem to be tying PMIC configuration with a OMAP version
which I think is not quite appropriate. Rather it should be a board
dependent parameter. We have many boards based on 4460 chip with different
PMICs. This implementation will not be able to support all such
configurations.
Vishwa
Signed-off-by: Nishanth Menon n...@ti.com
[t-kri...@ti.com: moved code under twl-common, other minor cleanups]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 81 ++-
---
arch/arm/mach-omap2/pm.h |9 +---
arch/arm/mach-omap2/twl-common.c | 55 +-
arch/arm/mach-omap2/twl-common.h | 27 +
4 files changed, 129 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
omap2/omap_twl.c
index 7830eae..c8e418e 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -19,8 +19,8 @@
#include linux/i2c/twl.h
#include voltage.h
-
#include pm.h
+#include twl-common.h
#define OMAP3_SRI2C_SLAVE_ADDR 0x12
#define OMAP3_VDD_MPU_SR_CONTROL_REG 0x00
@@ -170,7 +170,7 @@ static struct omap_voltdm_pmic omap3_core_pmic =
{
.uv_to_vsel = twl4030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_mpu_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore1_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
@@ -187,7 +187,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic =
{
.uv_to_vsel = twl6030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_iva_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore2_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
@@ -204,7 +204,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic =
{
.uv_to_vsel = twl6030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_core_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore3_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.startup_time = 500,
@@ -222,31 +222,9 @@ static struct omap_voltdm_pmic omap4_core_pmic
= {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-int __init omap4_twl_init(void)
+static int __init twl_set_sr(struct voltagedomain *voltdm)
{
- struct voltagedomain *voltdm;
-
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
- voltdm = voltdm_lookup(mpu);
- omap_voltage_register_pmic(voltdm, omap4_mpu_pmic);
-
- voltdm = voltdm_lookup(iva);
- omap_voltage_register_pmic(voltdm, omap4_iva_pmic);
-
- voltdm = voltdm_lookup(core);
- omap_voltage_register_pmic(voltdm, omap4_core_pmic);
-
- return 0;
-}
-
-int __init omap3_twl_init(void)
-{
- struct voltagedomain *voltdm;
-
- if (!cpu_is_omap34xx())
- return -ENODEV;
+ int r = 0;
/*
* The smartreflex bit on twl4030 specifies if the setting of
voltage
@@ -258,15 +236,50 @@ int __init omap3_twl_init(void)
* voltage scaling will not function on TWL over I2C_SR.
*/
if (!twl_sr_enable_autoinit)
- omap3_twl_set_sr_bit(true);
+ r = omap3_twl_set_sr_bit(true);
- voltdm = voltdm_lookup(mpu_iva);
- omap_voltage_register_pmic(voltdm, omap3_mpu_pmic);
+ return r;
+}
- voltdm = voltdm_lookup(core);
- omap_voltage_register_pmic(voltdm, omap3_core_pmic);
+static __initdata struct omap_pmic_map omap_twl_map[] = {
+ {
+ .name = mpu_iva,
+ .cpu = PMIC_CPU_OMAP3,
+ .pmic_data = omap3_mpu_pmic,
+ .special_action = twl_set_sr,
+ },
+ {
+ .name = core,
+
Re: [PATCH] omap-usb-host: include plat/cpu.h
Hi, Le 03/05/2012 09:50, Felipe Balbi a écrit : Hi, On Wed, May 02, 2012 at 10:36:44AM -0400, Jeff Mahoney wrote: omap-usb-host calls cpu_is_omap3430, which is defined in plat/cpu.h. Reported-by: Guillaume GARDETguillaume.gar...@opensuse.org Signed-off-by: Jeff Mahoneyje...@suse.com this looks right to me, though a driver shouldn't be using cpu_is_*** macros. Still, that patch can come later, this is needed now. Acked-by: Felipe Balbiba...@ti.com It seems it have been added in mainline: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=13176a89e1c4a0011bd9f576730b0338ecb619ff Guillaume -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
Hi Igor, On Mon, May 07, 2012 at 02:46:35PM +0300, Igor Grinberg wrote: Hi Samuel, On 05/07/12 11:09, Samuel Ortiz wrote: Hi Igor, On Sun, May 06, 2012 at 09:25:05AM +0300, Igor Grinberg wrote: Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) Sorry about that. and I'd like this to go into 3.5. Then you may need a better changelog explaining how this fixes a regression, runtime crash or build failure. Well, I did not say it is a regression. In fact it is not. I just finally sent a fix to eliminate a runtime warning which was there for a long time and can be seen on specific configurations. That is why, I want it into 3.5 during the merge window Sorry, I misread that part. Getting that one for the next merge window is just fine. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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] omap3_beagle: init uart2 for beagle rev AX/BX only
On Fri, May 4, 2012 at 11:48 PM, Tony Lindgren t...@atomide.com wrote:
Hi,
Looking at this again..
* Govindraj.R govindraj.r...@ti.com [120306 00:34]:
From: Govindraj.R govindraj.r...@ti.com
All beagle boards rev AX/BX have external usb hubs connected to ehci
interface, external hub/peripheral uses a nreset sequence for which
uart2_rx.gpio_147 pin in mux mode4(USB2HS_nRST) is used on all beagle
boards expect rev Ax/BX.
(Reference to all beagle boards rev schematics:
http://beagleboard.org/hardware/design)
Initialising uart2 will lead to serial init taking over uart2_rx pin
so init uart2_rx pin mux only for Beagle AX/BX rev boards.
Dont init uart2 for all other boards allowing usb_ehci functionality.
OK so the above got fixed for the muxing part with commit
bce492c04ba8fc66a4ea0a52b181ba255daaaf54.
To initialise individual uart port by id utilise and modify the existing
available func. omap_serial_board_init.
This makes sense as board specific fixes.
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -126,6 +126,7 @@ static void __init omap3_beagle_init_rev(void)
beagle_config.mmc1_gpio_wp = 29;
beagle_config.reset_gpio = 170;
beagle_config.usr_button_gpio = 7;
+ omap_serial_board_init(NULL, 1);
break;
case 6:
printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
@@ -528,7 +529,10 @@ static void __init omap3_beagle_init(void)
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_display_init(beagle_dss_data);
- omap_serial_init();
+ omap_serial_board_init(NULL, 0);
+ omap_serial_board_init(NULL, 2);
+ omap_serial_board_init(NULL, 3);
+
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
So this still looks valid, except now you also add the muxing for the
uart pins instead of NULL? Note that you could define OMAP3_UART1_DEFAULT_PINS
etc in some header.
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -393,30 +393,32 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
/**
* omap_serial_board_init() - initialize all supported serial ports
* @info: platform specific data pointer
+ * @port_id: uart port number to be initialised
*
- * Initializes all available UARTs as serial ports. Platforms
+ * Initializes individual UARTs as serial ports. Platforms
* can call this function when they want to have default behaviour
- * for serial ports (e.g initialize them all as serial ports).
+ * for serial ports (e.g initialize individual serial ports based on port
id).
*/
-void __init omap_serial_board_init(struct omap_uart_port_info *info)
+void __init omap_serial_board_init(struct omap_uart_port_info *info, u8
port_id)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
- list_for_each_entry(uart, uart_list, node) {
- bdata.id = uart-num;
- bdata.flags = 0;
- bdata.pads = NULL;
- bdata.pads_cnt = 0;
-
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
-
- if (!info)
- omap_serial_init_port(bdata, NULL);
- else
- omap_serial_init_port(bdata, info[uart-num]);
- }
+ list_for_each_entry(uart, uart_list, node)
+ if (uart-num == port_id) {
+ bdata.id = uart-num;
+ bdata.flags = 0;
+ bdata.pads = NULL;
+ bdata.pads_cnt = 0;
+
+ if (!cpu_is_omap24xx())
+ omap_serial_fill_default_pads(bdata);
+
+ if (!info)
+ omap_serial_init_port(bdata, NULL);
+ else
+ omap_serial_init_port(bdata, info);
+ }
}
@@ -428,5 +430,8 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
*/
void __init omap_serial_init(void)
{
- omap_serial_board_init(NULL);
+ struct omap_uart_state *uart;
+
+ list_for_each_entry(uart, uart_list, node)
+ omap_serial_board_init(NULL, uart-num);
}
Is this fix still needed? If so, it should probably be a separate fix
with it's own description.
No this one is not needed anymore
since its fixed part of commit
bce492c04ba8fc66a4ea0a52b181ba255daaaf54
--
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-V6 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On 5/3/2012 8:19 PM, Jon Hunter wrote: Hi Vaibhav, On 05/03/2012 12:07 AM, Hiremath, Vaibhav wrote: On Thu, May 03, 2012 at 01:26:18, Hunter, Jon wrote: Hi Vaibhav, On 05/02/2012 08:56 AM, Vaibhav Hiremath wrote: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation, movind SoC init code to respective files (mach-omap1/timer32k.c and mach-omap2/timer.c) and uses kernel parameter to override the default clocksource of counter_32k, also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer. if(use_gptimer_clksrc == true) gptimer clocksource init; else if (counter_32 init == false) /* Fallback to gptimer */ gptimer clocksource init(; With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. The patches are also available at (based on linux-omap/master) - https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup I was testing on OMAP4 and I found that the gptimer was always being set by default. I noticed that currently the HWMOD for counter_32k on OMAP4 is commented and hence was not being found. Please can you include the following with your series? The 32kcounter hwmod entry is already enabled in linux-omap/master branch. Your baseline looks pretty old to me, are you not using linux-omap/master? Ha! My old baseline is the latest mainline kernel ;-) I guess this is a bit out-dated in terms of omap now. Sorry I missed that fact your patches were on top of the omap kernel in the changelog. Yeah, in fact Paul submitted a big series to clean / re-organize and add missing hwmod for 3.5. So any change on hwmod should be done on top of Paul's branch. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAPDSS: HDMI: Fix register dump of CORE registers
The HDMI CORE registers are dumped incorrectly due to incorrect register offset calculations. They are also dumped in a random order, with some of the registers repeated. This series fixes these issues. The patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Tested on OMAP4 SDP. Archit Taneja (2): OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump OMAPDSS: HDMI: define and dump CORE registers in correct order drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 163 +++-- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 57 +-- 2 files changed, 109 insertions(+), 111 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/2] OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump
The function ti_hdmi_4xxx_core_dump has some bugs, the following mention the bugs and the solutions: - The macros DUMPCORE and DUMPCOREAV in ti_hdmi_4xxx_core_dump() use hdmi_pll_base() for the offsets needed to calculate register addresses, use functions hdmi_core_sys_base() amd hdmi_av_base() to calculate the correct offsets for CORE_SYS and CORE_AV registers. - Many of the CORE_AV registers use the DUMPCORE macro, and hence the register addresses are calculated incorrectly. Rename the current DUMPCOREAV macro as DUMPCOREAV2 as it takes 2 arguments to dump indexed CORE_AV registers, create a new macro called DUMPCOREAV which is now used for dumping non-indexed CORE_AV registers. Thanks to Ancy Tom ancy...@gmail.com for pointing out the issues. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 142 +++-- 1 files changed, 72 insertions(+), 70 deletions(-) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c index bfe6fe6..e266b8e 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c @@ -886,10 +886,12 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) #define CORE_REG(i, name) name(i) #define DUMPCORE(r) seq_printf(s, %-35s %08x\n, #r,\ - hdmi_read_reg(hdmi_pll_base(ip_data), r)) -#define DUMPCOREAV(i, r) seq_printf(s, %s[%d]%*s %08x\n, #r, i, \ + hdmi_read_reg(hdmi_core_sys_base(ip_data), r)) +#define DUMPCOREAV(r) seq_printf(s, %-35s %08x\n, #r,\ + hdmi_read_reg(hdmi_av_base(ip_data), r)) +#define DUMPCOREAV2(i, r) seq_printf(s, %s[%d]%*s %08x\n, #r, i, \ (i 10) ? 32 - strlen(#r) : 31 - strlen(#r), , \ - hdmi_read_reg(hdmi_pll_base(ip_data), CORE_REG(i, r))) + hdmi_read_reg(hdmi_av_base(ip_data), CORE_REG(i, r))) DUMPCORE(HDMI_CORE_SYS_VND_IDL); DUMPCORE(HDMI_CORE_SYS_DEV_IDL); @@ -924,85 +926,85 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) DUMPCORE(HDMI_CORE_DDC_DATA); DUMPCORE(HDMI_CORE_DDC_SEGM); - DUMPCORE(HDMI_CORE_AV_HDMI_CTRL); - DUMPCORE(HDMI_CORE_AV_DPD); - DUMPCORE(HDMI_CORE_AV_PB_CTRL1); - DUMPCORE(HDMI_CORE_AV_PB_CTRL2); - DUMPCORE(HDMI_CORE_AV_AVI_TYPE); - DUMPCORE(HDMI_CORE_AV_AVI_VERS); - DUMPCORE(HDMI_CORE_AV_AVI_LEN); - DUMPCORE(HDMI_CORE_AV_AVI_CHSUM); + DUMPCOREAV(HDMI_CORE_AV_HDMI_CTRL); + DUMPCOREAV(HDMI_CORE_AV_DPD); + DUMPCOREAV(HDMI_CORE_AV_PB_CTRL1); + DUMPCOREAV(HDMI_CORE_AV_PB_CTRL2); + DUMPCOREAV(HDMI_CORE_AV_AVI_TYPE); + DUMPCOREAV(HDMI_CORE_AV_AVI_VERS); + DUMPCOREAV(HDMI_CORE_AV_AVI_LEN); + DUMPCOREAV(HDMI_CORE_AV_AVI_CHSUM); for (i = 0; i HDMI_CORE_AV_AVI_DBYTE_NELEMS; i++) - DUMPCOREAV(i, HDMI_CORE_AV_AVI_DBYTE); + DUMPCOREAV2(i, HDMI_CORE_AV_AVI_DBYTE); for (i = 0; i HDMI_CORE_AV_SPD_DBYTE_NELEMS; i++) - DUMPCOREAV(i, HDMI_CORE_AV_SPD_DBYTE); + DUMPCOREAV2(i, HDMI_CORE_AV_SPD_DBYTE); for (i = 0; i HDMI_CORE_AV_AUD_DBYTE_NELEMS; i++) - DUMPCOREAV(i, HDMI_CORE_AV_AUD_DBYTE); + DUMPCOREAV2(i, HDMI_CORE_AV_AUD_DBYTE); for (i = 0; i HDMI_CORE_AV_MPEG_DBYTE_NELEMS; i++) - DUMPCOREAV(i, HDMI_CORE_AV_MPEG_DBYTE); + DUMPCOREAV2(i, HDMI_CORE_AV_MPEG_DBYTE); for (i = 0; i HDMI_CORE_AV_GEN_DBYTE_NELEMS; i++) - DUMPCOREAV(i, HDMI_CORE_AV_GEN_DBYTE); + DUMPCOREAV2(i, HDMI_CORE_AV_GEN_DBYTE); for (i = 0; i HDMI_CORE_AV_GEN2_DBYTE_NELEMS; i++) - DUMPCOREAV(i, HDMI_CORE_AV_GEN2_DBYTE); - - DUMPCORE(HDMI_CORE_AV_ACR_CTRL); - DUMPCORE(HDMI_CORE_AV_FREQ_SVAL); - DUMPCORE(HDMI_CORE_AV_N_SVAL1); - DUMPCORE(HDMI_CORE_AV_N_SVAL2); - DUMPCORE(HDMI_CORE_AV_N_SVAL3); - DUMPCORE(HDMI_CORE_AV_CTS_SVAL1); - DUMPCORE(HDMI_CORE_AV_CTS_SVAL2); - DUMPCORE(HDMI_CORE_AV_CTS_SVAL3); - DUMPCORE(HDMI_CORE_AV_CTS_HVAL1); - DUMPCORE(HDMI_CORE_AV_CTS_HVAL2); - DUMPCORE(HDMI_CORE_AV_CTS_HVAL3); - DUMPCORE(HDMI_CORE_AV_AUD_MODE); - DUMPCORE(HDMI_CORE_AV_SPDIF_CTRL); - DUMPCORE(HDMI_CORE_AV_HW_SPDIF_FS); - DUMPCORE(HDMI_CORE_AV_SWAP_I2S); - DUMPCORE(HDMI_CORE_AV_SPDIF_ERTH); - DUMPCORE(HDMI_CORE_AV_I2S_IN_MAP); - DUMPCORE(HDMI_CORE_AV_I2S_IN_CTRL); - DUMPCORE(HDMI_CORE_AV_I2S_CHST0); - DUMPCORE(HDMI_CORE_AV_I2S_CHST1); - DUMPCORE(HDMI_CORE_AV_I2S_CHST2); - DUMPCORE(HDMI_CORE_AV_I2S_CHST4); - DUMPCORE(HDMI_CORE_AV_I2S_CHST5); - DUMPCORE(HDMI_CORE_AV_ASRC); - DUMPCORE(HDMI_CORE_AV_I2S_IN_LEN); - DUMPCORE(HDMI_CORE_AV_HDMI_CTRL); - DUMPCORE(HDMI_CORE_AV_AUDO_TXSTAT); -
[PATCH 2/2] OMAPDSS: HDMI: define and dump CORE registers in correct order
The HDMI core register offset macros aren't defined in ascending order of their values, some of the offset macros are also redefined. The same issues occur when these core registers are dumped. Clean up the ordering of HDMI core registers and remove repeated registers in the definition in ti_hdmi_4xxx_ip.h and in ti_hdmi_4xxx_core_dump(). Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 65 +++-- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 57 +++-- 2 files changed, 59 insertions(+), 63 deletions(-) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c index e266b8e..8fc09d4 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c @@ -900,6 +900,13 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) DUMPCORE(HDMI_CORE_SYS_SRST); DUMPCORE(HDMI_CORE_CTRL1); DUMPCORE(HDMI_CORE_SYS_SYS_STAT); + DUMPCORE(HDMI_CORE_SYS_DE_DLY); + DUMPCORE(HDMI_CORE_SYS_DE_CTRL); + DUMPCORE(HDMI_CORE_SYS_DE_TOP); + DUMPCORE(HDMI_CORE_SYS_DE_CNTL); + DUMPCORE(HDMI_CORE_SYS_DE_CNTH); + DUMPCORE(HDMI_CORE_SYS_DE_LINL); + DUMPCORE(HDMI_CORE_SYS_DE_LINH_1); DUMPCORE(HDMI_CORE_SYS_VID_ACEN); DUMPCORE(HDMI_CORE_SYS_VID_MODE); DUMPCORE(HDMI_CORE_SYS_INTR_STATE); @@ -909,49 +916,20 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) DUMPCORE(HDMI_CORE_SYS_INTR4); DUMPCORE(HDMI_CORE_SYS_UMASK1); DUMPCORE(HDMI_CORE_SYS_TMDS_CTRL); - DUMPCORE(HDMI_CORE_SYS_DE_DLY); - DUMPCORE(HDMI_CORE_SYS_DE_CTRL); - DUMPCORE(HDMI_CORE_SYS_DE_TOP); - DUMPCORE(HDMI_CORE_SYS_DE_CNTL); - DUMPCORE(HDMI_CORE_SYS_DE_CNTH); - DUMPCORE(HDMI_CORE_SYS_DE_LINL); - DUMPCORE(HDMI_CORE_SYS_DE_LINH_1); - DUMPCORE(HDMI_CORE_DDC_CMD); - DUMPCORE(HDMI_CORE_DDC_STATUS); DUMPCORE(HDMI_CORE_DDC_ADDR); + DUMPCORE(HDMI_CORE_DDC_SEGM); DUMPCORE(HDMI_CORE_DDC_OFFSET); DUMPCORE(HDMI_CORE_DDC_COUNT1); DUMPCORE(HDMI_CORE_DDC_COUNT2); + DUMPCORE(HDMI_CORE_DDC_STATUS); + DUMPCORE(HDMI_CORE_DDC_CMD); DUMPCORE(HDMI_CORE_DDC_DATA); - DUMPCORE(HDMI_CORE_DDC_SEGM); - DUMPCOREAV(HDMI_CORE_AV_HDMI_CTRL); - DUMPCOREAV(HDMI_CORE_AV_DPD); - DUMPCOREAV(HDMI_CORE_AV_PB_CTRL1); - DUMPCOREAV(HDMI_CORE_AV_PB_CTRL2); - DUMPCOREAV(HDMI_CORE_AV_AVI_TYPE); - DUMPCOREAV(HDMI_CORE_AV_AVI_VERS); - DUMPCOREAV(HDMI_CORE_AV_AVI_LEN); - DUMPCOREAV(HDMI_CORE_AV_AVI_CHSUM); - for (i = 0; i HDMI_CORE_AV_AVI_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_AVI_DBYTE); - for (i = 0; i HDMI_CORE_AV_SPD_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_SPD_DBYTE); - for (i = 0; i HDMI_CORE_AV_AUD_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_AUD_DBYTE); - - for (i = 0; i HDMI_CORE_AV_MPEG_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_MPEG_DBYTE); - for (i = 0; i HDMI_CORE_AV_GEN_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_GEN_DBYTE); - - for (i = 0; i HDMI_CORE_AV_GEN2_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_GEN2_DBYTE); DUMPCOREAV(HDMI_CORE_AV_ACR_CTRL); DUMPCOREAV(HDMI_CORE_AV_FREQ_SVAL); @@ -991,19 +969,42 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) DUMPCOREAV(HDMI_CORE_AV_AVI_VERS); DUMPCOREAV(HDMI_CORE_AV_AVI_LEN); DUMPCOREAV(HDMI_CORE_AV_AVI_CHSUM); + + for (i = 0; i HDMI_CORE_AV_AVI_DBYTE_NELEMS; i++) + DUMPCOREAV2(i, HDMI_CORE_AV_AVI_DBYTE); + DUMPCOREAV(HDMI_CORE_AV_SPD_TYPE); DUMPCOREAV(HDMI_CORE_AV_SPD_VERS); DUMPCOREAV(HDMI_CORE_AV_SPD_LEN); DUMPCOREAV(HDMI_CORE_AV_SPD_CHSUM); + + for (i = 0; i HDMI_CORE_AV_SPD_DBYTE_NELEMS; i++) + DUMPCOREAV2(i, HDMI_CORE_AV_SPD_DBYTE); + DUMPCOREAV(HDMI_CORE_AV_AUDIO_TYPE); DUMPCOREAV(HDMI_CORE_AV_AUDIO_VERS); DUMPCOREAV(HDMI_CORE_AV_AUDIO_LEN); DUMPCOREAV(HDMI_CORE_AV_AUDIO_CHSUM); + + for (i = 0; i HDMI_CORE_AV_AUD_DBYTE_NELEMS; i++) + DUMPCOREAV2(i, HDMI_CORE_AV_AUD_DBYTE); + DUMPCOREAV(HDMI_CORE_AV_MPEG_TYPE); DUMPCOREAV(HDMI_CORE_AV_MPEG_VERS); DUMPCOREAV(HDMI_CORE_AV_MPEG_LEN); DUMPCOREAV(HDMI_CORE_AV_MPEG_CHSUM); + + for (i = 0; i HDMI_CORE_AV_MPEG_DBYTE_NELEMS; i++) + DUMPCOREAV2(i, HDMI_CORE_AV_MPEG_DBYTE); + + for (i = 0; i HDMI_CORE_AV_GEN_DBYTE_NELEMS; i++) + DUMPCOREAV2(i, HDMI_CORE_AV_GEN_DBYTE); + DUMPCOREAV(HDMI_CORE_AV_CP_BYTE1); + + for (i = 0; i HDMI_CORE_AV_GEN2_DBYTE_NELEMS; i++) +
RE: [PATCH 2/3] ARM: OMAP3+: PM: introduce a central pmic control
On Mon, 2012-05-07 at 17:30 +0530, Vishwanath Sripathy wrote: Hi Tero, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tero Kristo Sent: Friday, May 04, 2012 7:27 PM To: linux-omap@vger.kernel.org; khil...@ti.com Cc: linux-arm-ker...@lists.infradead.org; Nishanth Menon Subject: [PATCH 2/3] ARM: OMAP3+: PM: introduce a central pmic control From: Nishanth Menon n...@ti.com Since we are starting to use multiple PMICs in various combinations, use the existing .omap_chip = OMAP_CHIP_INIT() to mark the structures we are interested in using per OMAP device we are currently running on. This mapping is based on the default device recommendations from TI. Boards using custom PMICs now have an opportunity to register their own custom mapping. With this we no longer need omap4_twl_init and omap3_twl_int instead we introduce a registration mechanism which is PMIC generic and move twl implementation to use the same. This allows for future OMAP4460 support where there is a mixture of PMIC combinations used. In this patch, you seem to be tying PMIC configuration with a OMAP version which I think is not quite appropriate. Rather it should be a board dependent parameter. We have many boards based on 4460 chip with different PMICs. This implementation will not be able to support all such configurations. The ICS tree contains tweaks for this purpose, allowing the mapping to be modified during init time by board files. This should only be the default setup, and once support for boards that do not use default setup is added, we should modify this. However, if someone can provide me specs how the multi PMIC support should actually work, I am willing to implement this. -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 10/13] ARM: OMAP5: board-generic: Add device tree support.
Hi Sricharan,
On 5/3/2012 9:26 AM, R Sricharan wrote:
Adding the minimal support for OMAP5 soc with device tree.
You should probably split that patch since you are doing several things
that are not OMAP5 related.
Do a patch that move the omap_init_irq into the INTC and GIC code first.
Then, you can add a patch to add the OMAP5_DT machine entry.
Signed-off-by: R Sricharanr.sricha...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 39 +-
arch/arm/mach-omap2/common.h|2 +
arch/arm/mach-omap2/irq.c | 11 +
arch/arm/mach-omap2/omap4-common.c | 14
4 files changed, 51 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 098d183..0dd9e3f 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -20,6 +20,7 @@
#includemach/hardware.h
#includeasm/hardware/gic.h
#includeasm/mach/arch.h
+#includemach/omap-wakeupgen.h
#includeplat/board.h
#include common.h
@@ -32,17 +33,6 @@
#define gic_of_init NULL
#endif
-static struct of_device_id irq_match[] __initdata = {
- { .compatible = ti,omap2-intc, .data = omap_intc_of_init, },
- { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
- { }
-};
-
-static void __init omap_init_irq(void)
-{
- of_irq_init(irq_match);
-}
-
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = simple-bus, },
{ .compatible = ti,omap-infra, },
@@ -66,7 +56,7 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
- .init_irq = omap_init_irq,
+ .init_irq = omap_of_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer =omap2_timer,
@@ -85,7 +75,7 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
- .init_irq = omap_init_irq,
+ .init_irq = omap_of_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer =omap2_timer,
@@ -120,7 +110,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
- .init_irq = omap_init_irq,
+ .init_irq = omap_of_init_irq,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap3_init,
.timer =omap3_timer,
@@ -155,7 +145,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = omap_init_irq,
+ .init_irq = omap_gic_of_init,
.handle_irq = gic_handle_irq,
.init_machine = omap4_init,
.timer =omap4_timer,
@@ -163,3 +153,22 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device
Tree))
.restart= omap_prcm_restart,
MACHINE_END
#endif
+
+#ifdef CONFIG_ARCH_OMAP5
+static const char *omap5_boards_compat[] __initdata = {
+ ti,omap5,
+ NULL,
+};
+
+DT_MACHINE_START(OMAP5_DT, Generic OMAP5 (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = omap5_init_early,
+ .init_irq = omap_gic_of_init,
+ .handle_irq = gic_handle_irq,
+ .init_machine = omap_generic_init,
+ .timer =omap5_timer,
+ .dt_compat = omap5_boards_compat,
+ .restart= omap_prcm_restart,
+MACHINE_END
+#endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0771d22..e66859d 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -185,6 +185,8 @@ void omap3_intc_prepare_idle(void);
void omap3_intc_resume_idle(void);
void omap2_intc_handle_irq(struct pt_regs *regs);
void omap3_intc_handle_irq(struct pt_regs *regs);
+void omap_of_init_irq(void);
In order to be consistent with the GIC function and even the previous
ones, you should name the exported one:
+void omap_intc_of_init(void);
+void omap_gic_of_init(void);
#ifdef CONFIG_CACHE_L2X0
extern void __iomem *omap4_get_l2cache_base(void);
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 65f0d25..d316c68 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -21,6 +21,7 @@
#includelinux/irqdomain.h
#includelinux/of.h
#includelinux/of_address.h
+#includelinux/of_irq.h
[PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
From: R Sricharan r.sricha...@ti.com ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that non-DRAM region is marked as a client domain so that XN attribute is effective. A better alternative is to not map un-used regions but since the decompressor code is generic, there might be many exceptions for the devices used like debug console etc. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..4dc799b 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,7 +578,7 @@ __setup_mmu:sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000@ a reasonable RAM size - mov r1, #0x12 + mov r1, #0x32 @ set domain1, XN, valid orr r1, r1, #3 10 add r2, r3, #16384 1: cmp r1, r9 @ if virt start of RAM @@ -587,8 +587,10 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size #else orrhs r1, r1, #0x0c @ set cacheable, bufferable #endif + bichs r1, r1, #0x20 @ set domain0 for DRAM cmp r1, r10 @ if virt end of RAM bichs r1, r1, #0x0c @ clear cacheable, bufferable + orrhs r1, r1, #0x20 @ set domain1 str r1, [r0], #4@ 1:1 mapping add r1, r1, #1048576 teq r0, r2 @@ -658,6 +660,9 @@ __armv7_mmu_cache_on: movne r1, #-1 mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer mcrne p15, 0, r1, c3, c0, 0 @ load domain access control + bic r1, r1, #0xc + orr r1, r1, #0x4 + mcr p15, 0, r1, c3, c0, 0 @ set domain1 as client #endif mcr p15, 0, r0, c7, c5, 4 @ ISB mcr p15, 0, r0, c1, c0, 0 @ load control register -- 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-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
On Mon, May 07, 2012 at 16:14:42, Shilimkar, Santosh wrote: On Mon, May 7, 2012 at 4:02 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Paul, On 5/2/2012 11:09 AM, Paul Walmsley wrote: On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: snip So first we have to decide whether the CONFIG_ARCH_OMAP* options should have a strong dependency on the MPU type, as they currently do; or whether they should focus on the way the SoC is integrated. I think as well that these devices should be considered as part of the OMAP4 family. The CPU type should not be the parameter that decide the OMAP family, it is just an IP, that can change on some variant, whereas the whole PRCM infrastructure / interconnect is mostly the same. I agree. In fact more and more I think of this problem, looks like we should get rid off ARCH_OMAP* and just is SOC_* going forward. Common ARM code already takes care of different CPU version and as Benoit mentioned it is just one of the IP in the entire SOC. I saw tony commenting in similarly on of the patch set. I am working on creating patch-sets for am33xx device on the same direction, that means, am33xx will not fallow, neither ARCH_OMAP3 nor ARCH_OMAP4. am33xx will be separate device under ARCH_OMAP2PLUS, with SOC_OMAPAM33XX. This also means, neither cpu_is_omap34xx() not cpu_is_omap44xx() will be true for am33xx. We will have separate cpu_is_am33xx() class for this. Shortly I will submit patch-series for this. Just FYI, I have some cleanup patches, which actually tries to cleanup some of the existing ARCH_OMAPx dependency in code, making addition of devices easier under ARCH_OMAP2PLUS. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On Sun, 6 May 2012, Igor Grinberg wrote: Hi Alan, ... Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) and I'd like this to go into 3.5. Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? No, I can't, sorry. It has to be accepted by Greg KH. Alan Stern -- 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 10/13] ARM: OMAP5: board-generic: Add device tree support.
Hi Benoit, Thanks for the reviews. Adding the minimal support for OMAP5 soc with device tree. You should probably split that patch since you are doing several things that are not OMAP5 related. Do a patch that move the omap_init_irq into the INTC and GIC code first. Then, you can add a patch to add the OMAP5_DT machine entry. ok, will split this then accordingly. [snip] @@ -185,6 +185,8 @@ void omap3_intc_prepare_idle(void); void omap3_intc_resume_idle(void); void omap2_intc_handle_irq(struct pt_regs *regs); void omap3_intc_handle_irq(struct pt_regs *regs); +void omap_of_init_irq(void); In order to be consistent with the GIC function and even the previous ones, you should name the exported one: +void omap_intc_of_init(void); Ok, will take care of this rename. @@ -279,6 +280,16 @@ int __init omap_intc_of_init(struct device_node *node, And thus rename that one that become a private function without the omap_ prefix. ok.. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On 05/07/12 17:04, Alan Stern wrote: On Sun, 6 May 2012, Igor Grinberg wrote: Hi Alan, ... Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) and I'd like this to go into 3.5. Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? No, I can't, sorry. It has to be accepted by Greg KH. Hmm... I don't mind it be that way, but I'd like to understand: # scripts/get_maintainer.pl -f drivers/usb/host/ehci-omap.c Alan Stern st...@rowland.harvard.edu (maintainer:USB EHCI DRIVER) Felipe Balbi ba...@ti.com (maintainer:OMAP USB SUPPORT) Greg Kroah-Hartman gre...@suse.de (supporter:USB SUBSYSTEM) linux-...@vger.kernel.org (open list:USB EHCI DRIVER) linux-omap@vger.kernel.org (open list:OMAP USB SUPPORT) linux-ker...@vger.kernel.org (open list) This makes you the USB EHCI maintainer, right? I just want to understand... Do you need also ack from Greg to take something to your tree for being applied in the next merge window? -- 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 3/3] ARM: OMAP2+ PM: Add support for TPS62361
On Mon, May 7, 2012 at 2:38 AM, Tero Kristo t-kri...@ti.com wrote: One more point to consider is that with this - we *should* disable VCORE3 and VMEM else we can have weird behavior such as those seen by pandaboard-ES early adopters. In what case are we seeing such? If the regulators should be disabled, maybe we should do it already in bootloader. We deal with tons of bootloaders - each platform tends to have their own custom bootloaders. kernel should always assume bootloader guys screw up and it is upto kernel to ensure that it keeps the platform stable at all points of time. TWL6030 does detect short if any LDO/SMPS is not connected but switched on. so it is necessary to ensure on 4460 that VCORE3 and VMEM are completely switched off in kernel no matter what the heck the bootloader decides to do. Regards, Nishanth Menon -- 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 05/10] v4l: Add support for ov5640 sensor
Hi Jean-Philippe,
On Mon, May 7, 2012 at 2:27 AM, jean-philippe francois
jp.franc...@cynove.com wrote:
2012/5/2 Sergio Aguirre saagui...@ti.com:
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
There is already a limited driver in mainline for ov5642.
How does the 5642 differ from 5640 ?
Well, it has several differences, see:
- OV5640 product brief:
http://www.ovt.com/download_document.php?type=sensorsensorid=93
- OV5642 product brief:
http://www.ovt.com/download_document.php?type=sensorsensorid=65
Some of the most notable differences are:
- OV5642 has a MIPI input, for using OV ISP with an external sensor.
- OV5640 has JPEG compression, OV5642 apparently not...
- OV5640 supports anti-shake, OV5640 apparently not...
Can a single driver handle both chip ?
Maybe, yeah..
Now, for the OV5640 differences above, I'm not enabling much nice
features so far,
so it might be worth a try to attempt the ov5642 driver on my OV5640
as-is, to see
if we can expand it to support both.
I'll also see if I can reach people at OmniVision to consult
feasibility of register settings
sharing.
Regards,
Sergio
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig | 6 +
drivers/media/video/Makefile | 1 +
drivers/media/video/ov5640.c | 948
++
include/media/ov5640.h | 10 +
4 files changed, 965 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5640.c
create mode 100644 include/media/ov5640.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4482ac4..cc76652 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -480,6 +480,12 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_OV5640
+ tristate OmniVision OV5640 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5640 camera driver
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c95cc0d..da40ab3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/video/ov5640.c b/drivers/media/video/ov5640.c
new file mode 100644
index 000..2a64d50
--- /dev/null
+++ b/drivers/media/video/ov5640.c
@@ -0,0 +1,948 @@
+/*
+ * OmniVision OV5640 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
+
+#include media/ov5640.h
+
+/* OV5640 has only one fixed colorspace per pixelcode */
+struct ov5640_datafmt {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+struct ov5640_timing_cfg {
+ u16 x_addr_start;
+ u16 y_addr_start;
+ u16 x_addr_end;
+ u16 y_addr_end;
+ u16 h_output_size;
+ u16 v_output_size;
+ u16 h_total_size;
+ u16 v_total_size;
+ u16 isp_h_offset;
+ u16 isp_v_offset;
+ u8 h_odd_ss_inc;
+ u8 h_even_ss_inc;
+ u8 v_odd_ss_inc;
+ u8 v_even_ss_inc;
+};
+
+enum ov5640_size {
+ OV5640_SIZE_QVGA,
+ OV5640_SIZE_VGA,
+ OV5640_SIZE_720P,
+ OV5640_SIZE_1080P,
+ OV5640_SIZE_5MP,
+ OV5640_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5640_frmsizes[OV5640_SIZE_LAST]
= {
+ { 320, 240 },
+ { 640, 480 },
+ { 1280, 720 },
+ { 1920, 1080 },
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5640_find_framesize(u32
RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120503 23:04]:
Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we
need to follow for AM33XX?
I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose
here?
I think you're getting confused now :) I'm against ARCH_XXX but I'm OK with
adding SOC_XXX.
We should only need ARCH_OMAP2PLUS + SOC_XXX, there should not be any need
to add new ARCH_XXX under mach-omap2. Whatever we have left for ARCH_OMAP
in mach-omap2 will be eventually converted to SOC_OMAP.
Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
OR
No
Should we create ARCH_AM, assuming that all AM devices have similar
No
memory map layout, interrupt mapping, etc...
OR
Should I just add SOC_OMAPAM33XX, wherever required?
Yes, but how about just use SOC_AM33XX?
I will submit patches shortly (in the last cleanup now), where for am33xx
- cpu_is_omap34xx() will be false.
- Only cpu_is_am33xx() will be true here.
- Neither be under ARCH_OMAP3 nor ARCH_OMAP4, instead will be an
independent device under SOC_OMAPAM33XX.
This brings-in, some cleanup in existing code, which I will also submit
shortly.
Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option,
which is required for AM33XX, how should we handle this?
For example,
arch/arm/plat-omap/include/plat/clock.h
struct dpll_data {
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
dpll related variables
#endif
};
arch/arm/mach-omap2/clock.c
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
const struct clkops clkops_omap3_noncore_dpll_ops = {
};
const struct clkops clkops_omap3_core_dpll_ops = {
}
I suggest doing some clean-up patches before adding SOC_AM33XX where
you just convert those to be
#if defined(CONFIG_ARCH_OMAP2PLUS) !defined(CONFIG_ARCH_OMAP2)
or something similar depending if they already are inside mach-omap2
directory. This will make them future proof for adding new SoCs
without having to patch all over the place.
Tony,
Cool, I also thought exactly same solution on this, but next thought came to
my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2
option. However, it will be a good temporary solution for our problem, lets
review them first (I will submit shortly).
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] OMAPDSS: APPLY: Add manager timings as extra_info in private data
Hi,
On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.
To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar to what is done for overlays. This is needed
because timings aren't a part of overlay_manager_info struct configured by a
user of DSS, they are configured internally by the interface or panel drivers.
Add dirty and shadow_dirty extra_info flags for managers, update these flags
at the appropriate places. Rewrite the function extra_info_update_ongoing()
slightly as checking for manager's extra_info flags can simplify the code a
bit.
Create function dss_mgr_set_timings() which applies the new manager timings to
extra_info.
Signed-off-by: Archit Taneja arc...@ti.com
snip
+static void dss_apply_mgr_timings(struct omap_overlay_manager *mgr,
+ struct omap_video_timings *timings)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ mp-timings = *timings;
+ mp-extra_info_dirty = true;
+}
+
+void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
+ struct omap_video_timings *timings)
+{
+ unsigned long flags;
+
+ mutex_lock(apply_lock);
+
+ spin_lock_irqsave(data_lock, flags);
+
+ dss_apply_mgr_timings(mgr, timings);
+
+ spin_unlock_irqrestore(data_lock, flags);
+
+ mutex_unlock(apply_lock);
+}
With this, dpi.c others still need to use dispc_mgr_go(), which is
something that should be removed and done only from apply.c.
dss_ovl|mgr_enable|disable functions handle GO, so you could have a
look at them. However, setting the timings is a bit different, so I'm
not sure how it should be done.
I think we have a few different options:
- Separate omapdss internal function (in apply.c) that can be used to
set GO after set_timings
- set GO in dss_mgr_set_timings(), but don't block
- set GO in dss_mgr_set_timings(), and block until the changes are in HW
(this is more or less what the dss_ovl|mgr_enable|disable functions
do).
The first one would be good if the interface drivers would need to set
multiple configurations, and we don't want to block after each set call.
But we don't have anything like that, at least currently.
The second one avoids blocking, but could perhaps cause problems because
the timings are not actually used yet when the function returns.
I don't see any problem with the last option, so I'm slightly leaning
towards it.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On Mon, 7 May 2012, Igor Grinberg wrote: On 05/07/12 17:04, Alan Stern wrote: On Sun, 6 May 2012, Igor Grinberg wrote: Hi Alan, ... Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) and I'd like this to go into 3.5. Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? No, I can't, sorry. It has to be accepted by Greg KH. Hmm... I don't mind it be that way, but I'd like to understand: # scripts/get_maintainer.pl -f drivers/usb/host/ehci-omap.c Alan Stern st...@rowland.harvard.edu (maintainer:USB EHCI DRIVER) Felipe Balbi ba...@ti.com (maintainer:OMAP USB SUPPORT) Greg Kroah-Hartman gre...@suse.de (supporter:USB SUBSYSTEM) linux-...@vger.kernel.org (open list:USB EHCI DRIVER) linux-omap@vger.kernel.org (open list:OMAP USB SUPPORT) linux-ker...@vger.kernel.org (open list) This makes you the USB EHCI maintainer, right? Right. I just want to understand... Do you need also ack from Greg to take something to your tree for being applied in the next merge window? No. I don't takes patches at all, and in fact I don't even have a git directory or a login account at kernel.org. All my work goes through Greg; I submit or acknowledge patches and he merges them. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a need
to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need
to
rely on the display resolution any more.
Create a function dss_mgr_get_timings() which returns the timings in manager's
private data. Remove the need of passing omap_dss_device structs in the
functions which check for overlay and managers.
Have some initial values for manager timings in apply_init(), these would
ensure
that manager checks don't fail if an interface driver or a panel driver hasn't
set the manager timings yet.
Signed-off-by: Archit Taneja arc...@ti.com
+struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager
*mgr)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ return mp-timings;
+}
This one returns a pointer into apply.c's internal data structures. The
safest way would be to return a copy, but as it's an omapdss internal
function, I think it's enough to return a pointer to a const struct.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2 3/3] omap: remoteproc: add support for a boot register
Hi Juan,
On Mon, May 7, 2012 at 5:38 PM, Gutierrez, Juan jgutier...@ti.com wrote:
@@ -40,6 +41,7 @@ struct omap_rproc_pdata {
const struct rproc_ops *ops;
int (*device_enable) (struct platform_device *pdev);
int (*device_shutdown) (struct platform_device *pdev);
+ u32 boot_reg;
We might want to use an IORESOURCE_MEM resource instead, since we're
dealing with a platform device anyway.
The driver can then fetch the address using platform_get_resource.
Ok, Do you mean using resource table to get the boot_reg address, right?
Sorry for the confusion - I meant using a 'struct resource' as the
standard way to pass this kind of information to platform drivers.
For example take a look how omap2_mbox_probe uses
platform_get_resource to retrieve the parameters which it then feeds
to ioremap.
Using this standard approach will probably make life easier when we
migrate to DT, too.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 05/05/2012 11:10 AM, Jassi Brar wrote:
On 5 May 2012 00:53, Arnd Bergmann a...@arndb.de wrote:
On Friday 04 May 2012, Jassi Brar wrote:
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.
If I understand you correctly, you think we can generalize the dma-request
data in a way that we don't need to pass a specific dma engine phandle.
I very much doubt this is possible, given how different the requirements
are for each of the engines we support. You really need to pass a specific
phandle so that we can find the code that can interpret the data in a
meaningful way.
Hmm... there ought to be a way by which a client is handed a random 'token'
via its dt node and similarly the dmac informed which channel (and with what
capabilities) to allocate should it see a request coming with that token.
I think that's the whole point of the patch.
However, the token needs to be some driver-specific struct, since the
required information may be more than just a single channel or request
ID in general.
That way dmac and client drivers using DT could do away with the filter_fn.
Roughly speaking (I am not very well versed with DT syntax)
Client Node:-
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide unique value
dma_rx = 927 //some platform-wide unique value
...
};
I believe we specifically don't want to introduce any global concept of
DMA channel ID, either within the kernel, or at the device tree level.
While we do have global interrupt and GPIO IDs within the kernel, this
has caused problems, I think primarily due to the need to manage this
unified namespace and allocate a single global ID for a bunch of
different ranges of controller-specific IDs.
Within device tree, everything is always represented as an ID
relative-to or within a particular controller, so it's easy to namespace
things separately.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] omap: remoteproc: add support for a boot register
Hi Ohad
Thanks for reviewing.
On Sun, May 6, 2012 at 6:21 AM, Ohad Ben-Cohen o...@wizery.com wrote:
Hi Juan,
Thanks for the patches ! it's exciting to see that support for OMAP's
DSP is (relatively) easily achieved now. I hope your work can be a
good basis for an OMAP3 port, too.
Overall the patches look good, I have only some minor comments inline.
And - sorry for the late response. I've just left for a (somewhat
long) business trip when you posted this.
On Sat, Apr 14, 2012 at 2:39 AM, Juan Gutierrez jgutier...@ti.com wrote:
Some remote processors (like Omap4's DSP) need to explicitly
configure a boot address in a special register or memory
location
Let's just slightly rephrase this to prevent confusion: some remote
processors need to have the boot address configured in a special
register (as opposed to need to configure).
Ok, I will do it.
@@ -30,6 +30,7 @@ struct platform_device;
* @ops: start/stop rproc handlers
* @device_enable: omap-specific handler for enabling a device
* @device_shutdown: omap-specific handler for shutting down a device
+ * @boot_reg: physical address of the control register for storing boot
address
*/
struct omap_rproc_pdata {
const char *name;
@@ -40,6 +41,7 @@ struct omap_rproc_pdata {
const struct rproc_ops *ops;
int (*device_enable) (struct platform_device *pdev);
int (*device_shutdown) (struct platform_device *pdev);
+ u32 boot_reg;
We might want to use an IORESOURCE_MEM resource instead, since we're
dealing with a platform device anyway.
The driver can then fetch the address using platform_get_resource.
Ok, I will investigate about this, and include it in next series
@@ -203,6 +215,9 @@ static int __devinit omap_rproc_probe(struct
platform_device *pdev)
return 0;
free_rproc:
+ if (oproc-boot_reg)
+ iounmap(oproc-boot_reg);
+err_ioremap:
rproc_free(rproc);
return ret;
}
I tend to call those cleanup snippets with names that indicate what they do.
In this case I'd slightly prefer to keep calling the lower snippet
with free_rproc and just name the new snippet with something like
unmap_bootreg. It's then a bit easier to read the code that calls
into those snippets (the reader easily know which cleanup snippet is
invoked by each 'goto').
Agree. I will do the change.
Thanks,
Ohad.
--
Thanks
juan gutierrez
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] OMAP4: iommu: fix irq and clock name for dsp-iommu
Hi Ohad On Sun, May 6, 2012 at 7:33 AM, Ohad Ben-Cohen o...@wizery.com wrote: Hi Juan, On Sat, Apr 14, 2012 at 2:39 AM, Juan Gutierrez jgutier...@ti.com wrote: Irq and clock names were wrong for dsp iommu configuration for omap4. Looks good. Renamed tesla_ick to dsp_fck. If you're resubmitting the series, please indicate here why this change is needed (specifically let's mention commit 0e43327 OMAP4: clock: Fix clock names and align with hwmod names). Ok, I will mention the reason of this change in next series. Thanks, Ohad. -- Thanks juan gutierrez -- 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 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 05/07/2012 06:01 AM, Mohammed, Afzal wrote:
Hi Jon,
On Fri, May 04, 2012 at 21:57:10, Hunter, Jon wrote:
- gpmc_write_reg(GPMC_SYSCONFIG, l);
- gpmc_mem_init();
+ switch (conf GPMC_WAITPIN_MASK) {
+ case GPMC_WAITPIN_0:
+ idx = GPMC_WAITPIN_IDX0;
+ break;
+ case GPMC_WAITPIN_1:
+ idx = GPMC_WAITPIN_IDX1;
+ break;
+ case GPMC_WAITPIN_2:
+ idx = GPMC_WAITPIN_IDX2;
+ break;
+ case GPMC_WAITPIN_3:
+ idx = GPMC_WAITPIN_IDX3;
+ break;
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+ break;
+ }
Why not combined case 0 and default? Both are invalid configurations so
just report invalid selection.
Case 0 is not invalid, a case where waitpin is not used, default refers
to when a user selects multiple waitpins wrongly.
Ok. Then for case 0, just return here. If the polarity is set, you could
print an error here.
- /* initalize the irq_chained */
- irq = OMAP_GPMC_IRQ_BASE;
- for (cs = 0; cs GPMC_CS_NUM; cs++) {
- irq_set_chip_and_handler(irq, dummy_irq_chip,
- handle_simple_irq);
- set_irq_flags(irq, IRQF_VALID);
- irq++;
+ switch (conf GPMC_WAITPIN_POLARITY_MASK) {
+ case GPMC_WAITPIN_ACTIVE_LOW:
+ polarity = LOW;
+ break;
+ case GPMC_WAITPIN_ACTIVE_HIGH:
+ polarity = HIGH;
+ break;
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, waitpin polarity set to low high\n);
+ return -EINVAL;
+ break;
}
Again, combine case 0 and default as these are invalid.
Similar to above
If you return above, then case 0 is not needed.
+ if (gd-have_waitpin) {
+ if (gd-waitpin != idx ||
+ gd-waitpin_polarity != polarity) {
+ dev_err(gpmc-dev, error: conflict: waitpin %u
with polarity %d on device %s.%d\n,
+ gd-waitpin, gd-waitpin_polarity,
+ gd-name, gd-id);
+ return -EBUSY;
+ }
+ } else {
Don't need the else as you are going to return in the above.
Not always, only in case of error
Ok, but seems that it can be simplified a little.
What happens if a device uses more than one wait-pin? In other words a
device with two chip-selects that uses two wait-pins?
+ gd-have_waitpin = true;
+ gd-waitpin = idx;
+ gd-waitpin_polarity = polarity;
+ }
+
+ l = ~GPMC_CONFIG1_WAIT_PIN_SEL_MASK;
+ l |= GPMC_CONFIG1_WAIT_PIN_SEL(idx);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+ } else if (polarity) {
+ dev_err(gpmc-dev, error: waitpin polarity specified with out
wait pin number on device %s.%d\n,
+ gd-name, gd-id);
+ return -EINVAL;
Drop this else-if. The above switch statements will report the bad
configuration. This seems a bit redundant.
This is required as switch statements will not report error if polarity
is specified, w/o waitpin to be used.
Ok, may be you can print that above when you detect that there are no
wait-pins selected.
Jon
--
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 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Afzal, On 05/07/2012 06:02 AM, Mohammed, Afzal wrote: Hi Jon, On Fri, May 04, 2012 at 22:00:21, Hunter, Jon wrote: + + pdata-clk_prd = gpmc_get_fclk_period(); Does this need to be done here? May be this should be done in the probe function. You could store the handle to the main clk in the pdata. This is done so that migration of gpmc driver to the drivers folder would be smooth, remember that this function will still live here. Sure, but why call this here? Clk_prd is a platform data passed to the driver, so platform code updates it, where else can it be done ? The point is that you can pass what ever you like. You do not need to pass the frequency you can pass the clock handle instead. What happens it the clk_get() of the gpmc_l3_clk fails during the init? In fact if you migrate to runtime pm then we should not have the clk_get in the gpmc_init any more. Jon -- 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 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal, On 05/07/2012 05:57 AM, Mohammed, Afzal wrote: Hi Jon, On Fri, May 04, 2012 at 21:50:16, Hunter, Jon wrote: As mentioned in the cover letter, Additional features that currently boards in mainline does not make use of like, waitpin interrupt handling, changes to leverage revision 6 IP differences has not been incorporated. Priority in this series is to convert into a driver, get all boards working on mainline. Once all boards are working with gpmc driver, these features which are not required for currently supported boards can be added later. Yes, but I meant why 2 and not say 5? Anyway, I think that this should be marked with a comment like a TODO so it is clear that this needs to be re-visited. Ok, it will be marked with TODO I think that it make more sense to have the wait-pin information part of the gpmc_cs_data structure for the following reasons ... Waitpin information is indeed a part of cs as far as boards are concerned, it is only that it gets propogated to device Why does the device's driver care? From my point of view, the wait-pin is just part of the interface setup/configuration. The external device may require this and assumes that this has been setup along with the CS and interface timing, but the device's driver should not care. Remember this is just a ready signal used to stall the access. Once configured, software should be unaware of it. By device, it is referred to gpmc device which only gpmc driver is aware, the peripheral device's driver is not at all aware. Also, any reason why waitpin_polarity is an int? I see you define LOW as -1, but I not sure why LOW cannot be 0 as 0 is programmed into the register for an active low wait signal. Only intention is not to alter default waitpin polarity value, i.e. if any board does make use of it w/o knowledge of Kernel, I don't want to break it, there may be an argument saying that the board code is buggy, while if some board does so, it is, but don't want to break working one. Here unless user explicitly set the flag, it does nothing on polarity Ok. Do such scenario's exist today? Please note that board code will be removed in the future and device-tree will replace. So if there are no cases today, I would not be concerned. Unless this could be something that has already been configured by the bootloader. However, in that case would be even call this function? Let me check this, here only intent was to play safe, as I have only two boards to test. +int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *cs) What scenario is this function used in? May be worth adding a comment about the function. Ok, it was required for OneNAND, as it needs to reconfigure Ok, but why is that? Unless this is something generic about one-nand I don't comprehend. I have a high-level understanding of one-nand, but I am not familiar with the specifics that require it to be reconfigured. Not too familiar with OneNAND, from the code it has been understood that to set into sync mode, first it may have to set to async mode, read frequency from OneNAND, then setup sync mode for that frequency. + gpmc_setup_writeprotect(gpmc); Write protect is a pin and there is only one. Like the waitpins and CS signals this needs to be associated with a device. It would make sense that this is associated with the cs data. As far as platform are concerned, it is associated with cs, it is only that while configuring CS, it is propagated such that it is done once. Hmmm ... but here it looks like if write-protect is used you are going to turn it on. A feature like this seems that it does need to be handled by the device's driver. Enabling and disabling write-protect are functions that I would expect are exported to the device's driver and not directly enabled in the gpmc driver during probe. However, maybe is could be valid for the write protect to be enabled by default which could make sense. However, I don't see anywhere else in the driver to control it. Shouldn't we warn on multiple devices trying to use write-protect when parsing their configuration? Even if a single device sets write protect, kernel will log it. That does not seem sufficient. It should be flagged as an error. Write protect is a resource like the CS and waitpins and so I would have thought that it should be reserved in the same way. Jon -- 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 01/16] FS: Added demand paging markers to filesystem
Mon, May 7, 2012 at 5:01 AM, Dave Chinner da...@fromorbit.com wrote: On Thu, May 03, 2012 at 07:53:00PM +0530, Venkatraman S wrote: From: Ilan Smith ilan.sm...@sandisk.com Add attribute to identify demand paging requests. Mark readpages with demand paging attribute. Signed-off-by: Ilan Smith ilan.sm...@sandisk.com Signed-off-by: Alex Lemberg alex.lemb...@sandisk.com Signed-off-by: Venkatraman S svenk...@ti.com --- fs/mpage.c | 2 ++ include/linux/bio.h | 7 +++ include/linux/blk_types.h | 2 ++ 3 files changed, 11 insertions(+) diff --git a/fs/mpage.c b/fs/mpage.c index 0face1c..8b144f5 100644 --- a/fs/mpage.c +++ b/fs/mpage.c @@ -386,6 +386,8 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages, last_block_in_bio, map_bh, first_logical_block, get_block); + if (bio) + bio-bi_rw |= REQ_RW_DMPG; Have you thought about the potential for DOSing a machine with this? That is, user data reads can now preempt writes of any kind, effectively stalling writeback and memory reclaim which will lead to OOM situations. Or, alternatively, journal flushing will get stalled and no new modifications can take place until the read stream stops. This feature doesn't fiddle with the I/O scheduler's ability to balance read vs write requests or handling requests from various process queues (CFQ). Also, for block devices which don't implement the ability to preempt (and even for older versions of MMC devices which don't implement this feature), the behaviour falls back to waiting for write requests to complete before issuing the read. In low end flash devices, some requests might take too long than normal due to background device maintenance (i.e flash erase / reclaim procedure) kicking in in the context of an ongoing write, stalling them by several orders of magnitude. This implementation (See 14/16) does have several checks and timers to see that it's not triggered very often. In my tests, where I usually have a generous preemption time window, the abort happens 0.1% of the time. This really seems like functionality that belongs in an IO scheduler so that write starvation can be avoided, not in high-level data read paths where we have no clue about anything else going on in the IO subsystem Indeed, the feature is built mostly in the low level device driver and minor changes in the elevator. Changes above the block layer are only about setting attributes and transparent to their operation. Cheers, Dave. -- Dave Chinner da...@fromorbit.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: oprofile and ARM A9 hardware counter
Jon Hunter jon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunter jon-hun...@ti.com With this patch, how is the clkdm ever idled? IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) [1] Author: Paul Walmsley p...@pwsan.com 2012-04-04 07:25:25 Committer: Paul Walmsley p...@pwsan.com 2012-04-04 07:25:25 Parent: c16fa4f2ad19908a47c63d8fa436a1178438c7e7 (Linux 3.3) Branches: many (164) Follows: v3.4-rc1 Precedes: omap-fixes-a-for-3.4rc, omap-fixes-a2-for-3.4rc ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data According to the 4430 ES2.0 TRM vX Table 3-744 CM_EMU_CLKSTCTRL, the emu_sys clockdomain data in mainline is incorrect. The emu_sys clockdomain does not support the DISABLE_AUTO state, and instead it supports the FORCE_WAKEUP state. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Benoît Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Ming Lei ming@canonical.com Cc: Will Deacon will.dea...@arm.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 1/2] of: Add generic device tree DMA helpers
On 7 May 2012 21:23, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/05/2012 11:10 AM, Jassi Brar wrote:
Hmm... there ought to be a way by which a client is handed a random 'token'
via its dt node and similarly the dmac informed which channel (and with what
capabilities) to allocate should it see a request coming with that token.
I think that's the whole point of the patch.
However, the token needs to be some driver-specific struct, since the
required information may be more than just a single channel or request
ID in general.
Well, what I call 'token' could just as well be some numerical hash of
what you call 'driver-specific struct'.
And I never thought we could do without h/w specific information,
just that peculiarities lie with the dmac controllers and that's where
the discerning should happen.
Our opinions differ in that, I believe client side shouldn't need to
parse/decode the h/w specific parameters from data gotten via DT
(what I call 'token' and you 'driver-specific struct') - because that is
the key to having common client drivers working with different dma
controllers. And yes, I don't think we could find a future proof generic
and simple enough representation of dma resource specification in a
DT node :)
Instead, I suggest we encode the finer details of each channel-request
in node of the dma controller matched against the 'token' assigned
to the respective clients. That encoding(channel_id) would be dma
controller specific and if we also manage to contain it within fixed number
of bytes we could also have common helpers for fetching it, though
it still would need to be decoded by dmac controller driver - which I think
we can't do without, considering the variety of dma floating around.
That way dmac and client drivers using DT could do away with the filter_fn.
Roughly speaking (I am not very well versed with DT syntax)
Client Node:-
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide unique value
dma_rx = 927 //some platform-wide unique value
...
};
I believe we specifically don't want to introduce any global concept of
DMA channel ID, either within the kernel, or at the device tree level.
I don't think these tokens have to be global.
They just need to be common for .dts that define client and dmac nodes
- which would usually be the same file. They just have to be unique across
all dma clients on a given machine.
--
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: oprofile and ARM A9 hardware counter
On Tue, May 1, 2012 at 6:25 AM, Kevin Hilman khil...@ti.com wrote: Unfortunately, digging in the code isn't going to help much. We've been trying to get our heads around some undocumented reset behavior for the various debug IPs in OMAP. After a little digging and clarification from HW designers, it appears that if we allow the EMU clockdomain to idle, a full reset of the debug IPs is done. That means there are two solutions to this problem: 1) don't ever alow EMU clockdomain to idle. 2) modify CTI driver to re-init for every use. Obviously (1) is the easiet, and hacks for that have already been posted, but that has pretty significant impacts on power savings. (2) is the right solution to merge upstream, but needs writing. For (2), using runtime PM methods in the driver would be the simplest here since the -runtime_resume method will be called every time the device is about to be used. The previous patch has supported runtime pm on omap4 pmu[1], but still didn't fix the problem. Could you comment on the patch and point out the proper way to support pmu runtime for fixing the problem? [1], http://marc.info/?l=linux-arm-kernelm=131946777028358w=2 Thanks, -- Ming Lei -- 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: PM related performance degradation on OMAP3
Jean Pihet jean.pi...@newoldbits.com writes:
On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
I posted the patches for the power domains registers cache, cf.
http://marc.info/?l=linux-omapm=133587781712039w=2.
All the details are at
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
I updated the page with the measurements results with Kevin's patches
and the registers cache patches.
The results are showing that:
- the registers cache optimizes the low power mode transitions, but is
not sufficient to obtain a big gain. A few unused domains are
transitioning, which causes a big penalty in the idle path.
PER is the one that seems to be causing the most latency.
Can you try do your measurements using hack below which makes sure that
PER isn't any deeper than CORE?
Indeed your patch brings significant improvements, cf. wiki page at
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
for detailed information.
Here below is the reworked patch, more suited for inclusion in mainline [1]
I have another optimisation -in proof of concept state- that brings
another significant improvement. It is about allowing/disabling idle
for only 1 clkdm in a pwrdm and not iterate through all the clkdms.
This still needs some rework though. Cf. patch [2]
That should work since disabling idle for any clkdm will have the same
effect. Can you send this as a separate patch with a descriptive
changelog.
Kevin
Patches [1] and [2] on top of the registers cache and the
optimisations in pre/post_transition bring the performance close to
the performance for the non cpuidle case (3.0MB/s compared to 3.1MB/s
on Beagleboard).
What do you think?
Regards,
Jean
---
[1]
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index e406d7b..572b605 100644
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -279,32 +279,36 @@ static int omap3_enter_idle_bm(struct cpuidle_device
*dev,
int ret;
/*
- * Prevent idle completely if CAM is active.
+ * Use only C1 if CAM is active.
* CAM does not have wakeup capability in OMAP3.
*/
- if (pwrdm_read_func_pwrst(cam_pd) == PWRDM_FUNC_PWRST_ON) {
+ if (pwrdm_read_func_pwrst(cam_pd) == PWRDM_FUNC_PWRST_ON)
new_state_idx = drv-safe_state_index;
- goto select_state;
- }
-
- new_state_idx = next_valid_state(dev, drv, index);
+ else
+ new_state_idx = next_valid_state(dev, drv, index);
- /*
- * Prevent PER off if CORE is not in retention or off as this
- * would disable PER wakeups completely.
- */
+ /* Program PER state */
cx = cpuidle_get_statedata(dev-states_usage[new_state_idx]);
core_next_state = cx-core_state;
- per_next_state = per_saved_state = pwrdm_read_next_func_pwrst(per_pd);
- if ((per_next_state == PWRDM_FUNC_PWRST_OFF)
- (core_next_state PWRDM_FUNC_PWRST_CSWR))
- per_next_state = PWRDM_FUNC_PWRST_CSWR;
+ if (new_state_idx == 0) {
+ /* In C1 do not allow PER state lower than CORE state */
+ per_next_state = core_next_state;
+ } else {
+ /*
+ * Prevent PER off if CORE is not in RETention or OFF as this
+ * would disable PER wakeups completely.
+ */
+ per_next_state = per_saved_state =
+ pwrdm_read_next_func_pwrst(per_pd);
+ if ((per_next_state == PWRDM_FUNC_PWRST_OFF)
+ (core_next_state PWRDM_FUNC_PWRST_CSWR))
+ per_next_state = PWRDM_FUNC_PWRST_CSWR;
+ }
/* Are we changing PER target state? */
if (per_next_state != per_saved_state)
omap_set_pwrdm_state(per_pd, per_next_state);
-select_state:
ret = omap3_enter_idle(dev, drv, new_state_idx);
/* Restore original PER state if it was modified */
@@ -390,7 +394,6 @@ int __init omap3_idle_init(void)
/* C1 . MPU WFI + Core active */
_fill_cstate(drv, 0, MPU ON + CORE ON);
- (drv-states[0])-enter = omap3_enter_idle;
drv-safe_state_index = 0;
cx = _fill_cstate_usage(dev, 0);
cx-valid = 1; /* C1 is always valid */
[2]
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index e406d7b..6aa3c75 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -118,8 +118,10 @@ static int __omap3_enter_idle(struct cpuidle_device
Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
* Hiremath, Vaibhav hvaib...@ti.com [120507 07:41]: On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote: I suggest doing some clean-up patches before adding SOC_AM33XX where you just convert those to be #if defined(CONFIG_ARCH_OMAP2PLUS) !defined(CONFIG_ARCH_OMAP2) or something similar depending if they already are inside mach-omap2 directory. This will make them future proof for adding new SoCs without having to patch all over the place. BTW, just noticied that the above won't work the right way in the multi-omap case when all of them are compiled in.. Cool, I also thought exactly same solution on this, but next thought came to my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2 option. However, it will be a good temporary solution for our problem, lets review them first (I will submit shortly). ..so probably the best way to deal with that is with the additional CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted at: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Can you please take a look and see how that works for am33xx? 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 0/2] ARM: OMAP3: cleanup AM35xx SoC detection
Tony, Kevin Hilman khil...@ti.com writes: The detection of AM35xx SoCs is confusing and has redundancies. Clean this up so that SoC detection is only based on SoC family: AM35xx. Since these aren't PM related, can you queue these with other cleanups for v3.5. This is now independent from the similar changes made to the clock fwk which Paul is queuing. Once both series are merged, I'll have one final patch that removes all users of cpu_is_omap35*. Kevin Kevin Hilman (2): ARM: OMAP: AM35xx: remove redunant cpu_is checks for AM3505 ARM: OMAP: AM35xx: convert 3517 detection/flags to AM35xx arch/arm/mach-omap2/hsmmc.c |8 arch/arm/mach-omap2/id.c |7 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|2 +- arch/arm/mach-omap2/powerdomains3xxx_data.c |2 +- arch/arm/mach-omap2/usb-musb.c|2 +- arch/arm/mach-omap2/voltagedomains3xxx_data.c |2 +- arch/arm/plat-omap/include/plat/cpu.h |8 7 files changed, 19 insertions(+), 12 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 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* R, Sricharan r.sricha...@ti.com [120506 00:40]:
Also, please change the whole series to use CONFIG_SOC_OMAP5 instead
of CONFIG_ARCH_OMAP5. CONFIG_ARCH_OMAP stuff will go away except
for CONFIG_ARCH_OMAP2PLUS. Sorry forgot to mention that earlier.
ok. sure. will change this.
Thanks.
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
+#if (defined(CONFIG_ARCH_OMAP5) || defined(CONFIG_ARCH_OMAP4)) \
+ !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
+
static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
WARN(1, prm: omap2xxx/omap3xxx specific function and
Maybe these functions could be just set up as __weak to avoid the
ifdeffery?
sorry to understand,
you mean make this weak and have a strong override for OMAP2 ?
Yeah that should do the trick, right?
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 07/13] ARM: OMAP5: l3: Add l3 error handler support for omap5.
* R, Sricharan r.sricha...@ti.com [120506 00:42]:
Hi Tony,
- if (!(cpu_is_omap44xx()))
+ if ((!(cpu_is_omap44xx())) (!cpu_is_omap54xx()))
return -ENODEV;
for (i = 0; i L3_MODULES; i++) {
Isn't there some unnecessary parens here?
You mean in this above for loop?.
There are multiple statements .
No, both the old (!(cpu_is_omap44xx())) and the added one.
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 10/13] ARM: OMAP5: board-generic: Add device tree support.
* R, Sricharan r.sricha...@ti.com [120507 07:12]: Hi Benoit, Thanks for the reviews. Adding the minimal support for OMAP5 soc with device tree. You should probably split that patch since you are doing several things that are not OMAP5 related. Do a patch that move the omap_init_irq into the INTC and GIC code first. Then, you can add a patch to add the OMAP5_DT machine entry. ok, will split this then accordingly. Thanks, that allows us to remove the dependencies that will easily cause merge errors adding let's say am33xx here. 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 12/13] ARM: OMAP5: Add the build support
* R, Sricharan r.sricha...@ti.com [120506 20:39]: +config MACH_OMAP5_SEVM + bool OMAP5 sevm Board + depends on ARCH_OMAP5 + config OMAP3_EMU bool OMAP3 debugging peripherals depends on ARCH_OMAP3 No need for it here either. Actually, I think this whole chunk can be now left out since it's DT based? he ok, but the concern here was that without this macro the print from compress and subsequently early prints appear broken. machine_is_omap5_sevm becomes zero without this config and machine_is_ is used by the macro _DEBUG_LL_ENTRY uncompress.h. Ah I see. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: UART: Fix incorrect population of default uart pads
Tony Lindgren t...@atomide.com writes: * Raja, Govindraj govindraj.r...@ti.com [120424 01:41]: On Tue, Apr 24, 2012 at 5:15 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com The following commit: (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts) added default pads for all uarts. But not all boards tend to use all uarts and most of unused uart pins are muxed for other purpose. This commit breaks the modules which where trying to use unused uart pins on their boards. So remove the default pads adding. I just noticed that this patch breaks runtime PM wakeups for UART console (at least on 3530/Overo with ttyO2 console.) By removing the pads, the initial device_init_wakeup() is not called on port init. Without this call serial_omap_pm() disables runtime PM because it checks device_may_wakeup(). Since runtime PM was disabled, I manually re-enabled it and then enabled wakeups: echo auto /sys/devices/platform/omap_uart.2/power/control echo enabled /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup Then, after enabling auto-suspend timeouts, it seems wakeups are still not working since the console hangs. Reverting $SUBJECT patch gets things working again. This was decided as part of discussion [1] If we are _reconsidering_ taking this patch [2] to dynamically probe uart pins and enable rx wakeup. I can re-work on the patch[2] as per tony's comments[1] and re-post it. Just to follow up on this.. Let's first get things working reliably, and only then add more PM support. We absolutely can't revert $SUBJECT because it's known to mess up at least smsc911x and ehci on zoom3, hsi on n900 and probably many other things. For the -rc cycle, it seems that [2] is out of question at this point as too intrusive. If the PM wakeups are broken in the default cases, then I suggest we just take few steps back and disable any deeper PM states in the -rc series. Unfortunately, no need to do anything more to disable deeper PM states. Because $SUBJECT disables runtime PM for UART, it keeps both PER and CORE on all the time. :( 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 00/25] OMAPDSS: DT preparation patches v2
Hi, * Tomi Valkeinen tomi.valkei...@ti.com [120503 07:01]: Hi, I started cleaning up and restructuring omapdss for device tree, and here's the first set of patches from that ordeal. There's nothing DT specific in these patches, but they are mostly generic cleanups that make sense even without DT. This is the second version of these patches, the previous version can be found from: http://www.spinics.net/lists/linux-fbdev/msg05667.html The first 21 patches, which were in the previous version, have only gotten minor cleanups (and, of course, more testing). The last 4 patches are new. The most important of those patches is the DSI pin config patch, which makes it possible for the panel driver to configure the DSI pins it needs. This series can also be found from: git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching patches (and the drivers/video dependencies needed) into a separate branch and send me a pull request. That is assuming those patches are now immutable. Then I can pull it into cleanup-dss branch that we both can merge as needed. 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] omap3_beagle: init uart2 for beagle rev AX/BX only
* Raja, Govindraj govindraj.r...@ti.com [120507 05:26]: On Fri, May 4, 2012 at 11:48 PM, Tony Lindgren t...@atomide.com wrote: Is this fix still needed? If so, it should probably be a separate fix with it's own description. No this one is not needed anymore since its fixed part of commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 OK thanks for the update. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: UART: Fix incorrect population of default uart pads
* Kevin Hilman khil...@ti.com [120507 10:42]: Tony Lindgren t...@atomide.com writes: Just to follow up on this.. Let's first get things working reliably, and only then add more PM support. We absolutely can't revert $SUBJECT because it's known to mess up at least smsc911x and ehci on zoom3, hsi on n900 and probably many other things. For the -rc cycle, it seems that [2] is out of question at this point as too intrusive. If the PM wakeups are broken in the default cases, then I suggest we just take few steps back and disable any deeper PM states in the -rc series. Unfortunately, no need to do anything more to disable deeper PM states. Because $SUBJECT disables runtime PM for UART, it keeps both PER and CORE on all the time. :( Oh well, it seems that that runtime PM can now be enabled on per-board basis as it gets tested. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v4] ARM: OMAP2+: omap_hwmod: Add api to enable/disable module level wakeup events
Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using PM_WKEN1_CORE/PM_WKEN_PER regs. Add api to control the module level wakeup mechanism from info provided from hwmod data. Can you rework this slightly on top of the new SoC detection support recently added to hwmod[1]. That series adds support for init-time, SoC specific function pointers for this kind of SoC specific feature. Kevin [1] git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.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-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
On Mon, May 07, 2012 at 23:02:29, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120507 07:41]: On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote: I suggest doing some clean-up patches before adding SOC_AM33XX where you just convert those to be #if defined(CONFIG_ARCH_OMAP2PLUS) !defined(CONFIG_ARCH_OMAP2) or something similar depending if they already are inside mach-omap2 directory. This will make them future proof for adding new SoCs without having to patch all over the place. BTW, just noticied that the above won't work the right way in the multi-omap case when all of them are compiled in.. Cool, I also thought exactly same solution on this, but next thought came to my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2 option. However, it will be a good temporary solution for our problem, lets review them first (I will submit shortly). ..so probably the best way to deal with that is with the additional CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted at: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Can you please take a look and see how that works for am33xx? I still don't understand, how this will help am33xx, and for that matter any new future devices based on cortex-a8 or a9 core, but not omap exactly families? As I said earlier, am33xx doesn't fall under either omap3 or omap4; we have again same question in front of us, which to follow, either omap3 or omap4?? What is the thought process of creating these config options? Isn't it same as just replacing ARCH_OMAP3/4 with SOC_OMAP3PLUS and SOC_OMAP4PLUS? What is the criteria for the device to get into this umbrella? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Monday 07 May 2012, Stephen Warren wrote:
That way dmac and client drivers using DT could do away with the filter_fn.
Roughly speaking (I am not very well versed with DT syntax)
Client Node:-
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide unique value
dma_rx = 927 //some platform-wide unique value
...
};
I believe we specifically don't want to introduce any global concept of
DMA channel ID, either within the kernel, or at the device tree level.
I agree.
While we do have global interrupt and GPIO IDs within the kernel, this
has caused problems, I think primarily due to the need to manage this
unified namespace and allocate a single global ID for a bunch of
different ranges of controller-specific IDs.
Within device tree, everything is always represented as an ID
relative-to or within a particular controller, so it's easy to namespace
things separately.
Right. Note that strictly speaking the requirement is that everything
is local to a particular namespace, which does not have to be the
device controlling the property.
For instance, we can map interrupt numbers to different controllers
using the interrupt-maps property. It is a fairly complex method,
but something similar or a somewhat simpler method could be applied
to define a namespace for dma controllers from which you can pick
a request line.
The example I've given earlier does just that.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] omap randconfig fixes for v3.3
* Tony Lindgren t...@atomide.com [120329 10:31]: Mathieu, * mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:16]: From: Arnd Bergmann a...@arndb.de The following is a set of patches that have been sent out during the 3.1 cycle that were not acked or merged. Sending again for completeness. Tony, please pull if there are no objections: The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7: Can you please drop the already fixed ones and post a new pull request? It seems that these should merge fine to current mainline if based on v3.3. If not, then maybe use the linux-omap fixes branch as the base that I've just pushed at commit 2533c2cf. Ping, any news on updating the pull request for the remaining comments? 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 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. This would be for two main reasons. One is that Kconfig options like CONFIG_SOC_OMAP3PLUS don't have much meaning. It is really unclear to me what SoCs would be included in CONFIG_SOC_OMAP3PLUS, since some of them differ so radically -- different interconnects, different power and system management IP blocks, different CPU subsystems, different RAM controllers, etc. The advantage of using SoC-specific Kconfig options, from this point of view, is that it is easy to know what they mean. Then those SoC-specific Kconfig options can select the appropriate SoC-independent interconnect driver, PRCM drivers, CPU options, etc. The other motivation would be to support device manufacturers who only wish to build a kernel for the single device that they are shipping. In terms of kernels shipped, this is probably the most popular use-case. With something like CONFIG_SOC_OMAPAM33XX, they can avoid building quite a bit of code and data (and potentially bugs) that are not needed for their specific device. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html This would be for two main reasons. One is that Kconfig options like CONFIG_SOC_OMAP3PLUS don't have much meaning. It is really unclear to me what SoCs would be included in CONFIG_SOC_OMAP3PLUS, since some of them differ so radically -- different interconnects, different power and system management IP blocks, different CPU subsystems, different RAM controllers, etc. The advantage of using SoC-specific Kconfig options, from this point of view, is that it is easy to know what they mean. Then those SoC-specific Kconfig options can select the appropriate SoC-independent interconnect driver, PRCM drivers, CPU options, etc. Just to continue exploring just using the SoC specific options, we would currently end up with more of this kind of nastiness: #if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \ defined(CONFIG_ARCH_OMAP3)) The other motivation would be to support device manufacturers who only wish to build a kernel for the single device that they are shipping. In terms of kernels shipped, this is probably the most popular use-case. With something like CONFIG_SOC_OMAPAM33XX, they can avoid building quite a bit of code and data (and potentially bugs) that are not needed for their specific device. Sure, but I think you're missing the point: This would be in addition to the SoC specific options. Do you still see issues with that? 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 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Tony Lindgren t...@atomide.com [120507 12:22]: * Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Of course we could make this finer grained based on features like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some grouping like that in mind. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Add MSUB support for the LogicPD OMAP3530 DevKits
Add support for the OMAP3 MUSB OTG controller to the LogicPD
OMAP3530 SOM-LV[1] and Torpedo[2] DevKits
[1] - www.logicpd.com/products/system-on-modules/omap35x-som-lv/
[2] - www.logicpd.com/products/system-on-modules/omap35x-torpedo-som/
Signed-off-by: Ashwin Bihari ashwin.bih...@logicpd.com
---
arch/arm/mach-omap2/board-omap3logic.c | 26 +-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 9b3c141..c008bf8 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -4,8 +4,9 @@
* Copyright (C) 2010 Li-Pro.Net
* Stephan Linz l...@li-pro.net
*
- * Copyright (C) 2010 Logic Product Development, Inc.
+ * Copyright (C) 2010-2012 Logic Product Development, Inc.
* Peter Barada peter.bar...@logicpd.com
+ * Ashwin BIhari ashwin.bih...@logicpd.com
*
* Modified from Beagle, EVM, and RX51
*
@@ -45,6 +46,7 @@
#include plat/gpmc-smsc911x.h
#include plat/gpmc.h
#include plat/sdrc.h
+#include plat/usb.h
#define OMAP3LOGIC_SMSC911X_CS 1
@@ -85,6 +87,11 @@ static struct twl4030_gpio_platform_data
omap3logic_gpio_data = {
| BIT(13) | BIT(15) | BIT(16) | BIT(17),
};
+static struct twl4030_usb_data omap3logic_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
+
static struct twl4030_platform_data omap3logic_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -92,6 +99,7 @@ static struct twl4030_platform_data omap3logic_twldata = {
/* platform_data for children goes here */
.gpio = omap3logic_gpio_data,
.vmmc1 = omap3logic_vmmc1,
+ .usb= omap3logic_usb_data,
};
static int __init omap3logic_i2c_init(void)
@@ -185,6 +193,20 @@ static inline void __init board_smsc911x_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* mUSB */
+ OMAP3_MUX(HSUSB0_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_STP, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(HSUSB0_DIR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_NXT, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -205,6 +227,8 @@ static void __init omap3logic_init(void)
board_mmc_init();
board_smsc911x_init();
+ usb_musb_init(NULL);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
--
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 0/2] Add MUSB and LCD support to LogicPD OMAP3530 DevKits
The following patch add MUSB (OTG) and LCD (Sharp 4.3 LQ043T1DG01) support to the LogicPD OMAP3530 DevKits. Ashwin Bihari (2): Add MSUB support for the LogicPD OMAP3530 DevKits Add LCD support for the LogicPD OMAP3530 DevKits arch/arm/mach-omap2/board-omap3logic.c | 173 +++- 1 files changed, 172 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
Use the generic DSS panel driver that provides support for
the 4.3 Sharp LQ043T1DG01 that comes standard on the
OMAP3530 SOM-LV and Torpedo DevKits.
Signed-off-by: Ashwin Bihari ashwin.bih...@logicpd.com
---
arch/arm/mach-omap2/board-omap3logic.c | 147
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index c008bf8..f0545c9 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -47,6 +47,8 @@
#include plat/gpmc.h
#include plat/sdrc.h
#include plat/usb.h
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
#define OMAP3LOGIC_SMSC911X_CS 1
@@ -57,6 +59,11 @@
#define OMAP3_TORPEDO_MMC_GPIO_CD 127
#define OMAP3_TORPEDO_SMSC911X_GPIO_IRQ129
+#define LCD_PANEL_PWR 155
+#define OMAP3530_LV_SOM_BACKLIGHT_PWR 8
+#define OMAP3530_TORPEDO_BACKLIGHT_PWR 154
+#define OMAP3530_TORPEDO_MDISP 56
+
static struct regulator_consumer_supply omap3logic_vmmc1_supply[] = {
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
};
@@ -104,6 +111,10 @@ 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);
+
omap3_pmic_init(twl4030, omap3logic_twldata);
return 0;
}
@@ -207,6 +218,36 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* DSS */
+ OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA8, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA9, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA10, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA11, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA12, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA13, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA14, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA15, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA16, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA17, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA20, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA21, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA23, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -216,17 +257,123 @@ static struct regulator_consumer_supply dummy_supplies[]
= {
REGULATOR_SUPPLY(vdd33a, smsc911x.0),
};
+#if defined(CONFIG_PANEL_GENERIC_DPI) || \
+ defined(CONFIG_PANEL_GENERIC_DPI_MODULE)
+static void __init omap3logic_display_init(void)
+{
+ int r;
+
+ omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_OUTPUT);
+ if (machine_is_omap3530_lv_som())
+ omap_mux_init_gpio(OMAP3530_LV_SOM_BACKLIGHT_PWR,
OMAP_PIN_OUTPUT);
+ else if (machine_is_omap3_torpedo()) {
+ omap_mux_init_gpio(OMAP3530_TORPEDO_BACKLIGHT_PWR,
OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(OMAP3530_TORPEDO_MDISP, OMAP_PIN_OUTPUT);
+ }
+
+ r = gpio_request(LCD_PANEL_PWR, lcd enable);
+ if (r) {
+ printk(KERN_ERR Failed to get DSS panel enable GPIO\n);
+ return;
+ }
+ gpio_direction_output(LCD_PANEL_PWR, 0);
+
+ if (machine_is_omap3530_lv_som()) {
+ r = gpio_request(OMAP3530_LV_SOM_BACKLIGHT_PWR, lcd backlight
enable);
+ if (r) {
+ printk(KERN_ERR Failed to get DSS panel backlight
enable GPIO\n);
+ return;
+ }
+
Re: oprofile and ARM A9 hardware counter
Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunter jon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunter jon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Cheers Jon -- 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] [OMAP] Mark Beagleboard-xM MMC bus as 4-bit
On Beagleboard-xM (all revisions) only MMC1_DAT0-MMC1_DAT3 are wired up. Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4. Signed-off-by: Russ Dill russ.d...@ti.com --- arch/arm/mach-omap2/board-omap3beagle.c |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 7be8d65..3b9647a 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -523,6 +523,10 @@ static void __init omap3_beagle_init(void) if (beagle_config.mmc1_gpio_wp != -EINVAL) omap_mux_init_gpio(beagle_config.mmc1_gpio_wp, OMAP_PIN_INPUT); + + /* All xM versions have 4-bit MMC bus */ + if (cpu_is_omap3630()) + mmc[0].caps = ~MMC_CAP_8_BIT_DATA; omap_hsmmc_init(mmc); omap3_beagle_i2c_init(); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [OMAP] Cleanup Beagleboard DVI reset gpio
This removes several boot warnings from board-omap3beagle.c:
- gpio_request: gpio--22 (DVI reset) status -22
- Unable to get DVI reset GPIO
There is a combination of leftover code and revision confusion.
Additionally, xM support is currently a hack.
For original Beagleboard this removes the double initialization of GPIO
170, properly configures it as an output, and wraps the initialization
in an if block so that xM does not attempt to request it.
For Beagleboard xM it removes reference to GPIO 129 which was part
of rev A1 and A2 designs, but never functioned. It then properly assigns
beagle_dvi_device.reset_gpio in beagle_twl_gpio_setup and removes the
hack of initializing it high.
Unfortunately, there is no way to tell the difference between xM A2 and
A3. However, GPIO 129 does not function on rev A1 and A2, and the TWL
GPIO used on A3 and beyond is not used on rev A1 and A2, there are no
problems created by this fix.
Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 35 +--
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 3b9647a..fcb7b56 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -86,7 +86,7 @@ static struct {
} beagle_config = {
.mmc1_gpio_wp = -EINVAL,
.usb_pwr_level = GPIOF_OUT_INIT_LOW,
- .reset_gpio = 129,
+ .reset_gpio = -EINVAL,
.usr_button_gpio = 4,
};
@@ -238,12 +238,17 @@ static struct omap_dss_board_info beagle_dss_data = {
static void __init beagle_display_init(void)
{
- int r;
-
- r = gpio_request_one(beagle_dvi_device.reset_gpio, GPIOF_OUT_INIT_LOW,
-DVI reset);
- if (r 0)
- printk(KERN_ERR Unable to get DVI reset GPIO\n);
+ if (beagle_config.reset_gpio != -EINVAL) {
+ int r;
+
+ omap_mux_init_gpio(beagle_config.reset_gpio, OMAP_PIN_OUTPUT);
+ r = gpio_request_one(beagle_config.reset_gpio,
+GPIOF_OUT_INIT_LOW, DVI reset);
+ if (r 0)
+ printk(KERN_ERR Unable to get DVI reset GPIO\n);
+ else
+ beagle_dvi_device.reset_gpio = beagle_config.reset_gpio;
+ }
}
#include sdram-micron-mt46h32m32lf-6.h
@@ -296,11 +301,14 @@ static int beagle_twl_gpio_setup(struct device *dev,
if (r)
pr_err(%s: unable to configure nDVI_PWR_EN\n,
__func__);
- r = gpio_request_one(gpio + 2, GPIOF_OUT_INIT_HIGH,
-DVI_LDO_EN);
+
+ r = gpio_request_one(gpio + 2, GPIOF_OUT_INIT_LOW,
+DVI_PU);
if (r)
- pr_err(%s: unable to configure DVI_LDO_EN\n,
- __func__);
+ pr_err(%s: unable to get DVI_PU GPIO\n, __func__);
+ else
+ beagle_dvi_device.reset_gpio = gpio + 2;
+
} else {
/*
* REVISIT: need ehci-omap hooks for external VBUS
@@ -309,7 +317,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
if (gpio_request_one(gpio + 1, GPIOF_IN, EHCI_nOC))
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
- beagle_dvi_device.reset_gpio = beagle_config.reset_gpio;
gpio_request_one(gpio + TWL4030_GPIO_MAX, beagle_config.usb_pwr_level,
nEN_USB_PWR);
@@ -540,10 +547,6 @@ static void __init omap3_beagle_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
- omap_mux_init_gpio(170, OMAP_PIN_INPUT);
- /* REVISIT leave DVI powered down until it's needed ... */
- gpio_request_one(170, GPIOF_OUT_INIT_HIGH, DVI_nPD);
-
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP] Mark Beagleboard-xM MMC bus as 4-bit
* Russ Dill russ.d...@ti.com [120507 13:00]: On Beagleboard-xM (all revisions) only MMC1_DAT0-MMC1_DAT3 are wired up. Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4. Signed-off-by: Russ Dill russ.d...@ti.com --- arch/arm/mach-omap2/board-omap3beagle.c |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 7be8d65..3b9647a 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -523,6 +523,10 @@ static void __init omap3_beagle_init(void) if (beagle_config.mmc1_gpio_wp != -EINVAL) omap_mux_init_gpio(beagle_config.mmc1_gpio_wp, OMAP_PIN_INPUT); + + /* All xM versions have 4-bit MMC bus */ + if (cpu_is_omap3630()) + mmc[0].caps = ~MMC_CAP_8_BIT_DATA; omap_hsmmc_init(mmc); omap3_beagle_i2c_init(); This would be better done in omap3_beagle_init_rev as various other things are already initialized there based on the revision. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure
A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
gpio/omap: Use devm_ API and add request_mem_region). This change
prevented the Amstrad Delta NAND driver, which was doing the same in
order to take control over OMAP MPU I/O lines that the NAND device hangs
off, from loading successfully.
The I/O lines and corresponding registers used by the NAND driver are a
subset of those used for the GPIO function. Then, to avoid run time
collisions, all MPUIO GPIO lines should be marked as requested while
initializing the NAND driver, and vice versa, a single MPUIO GPIO line
already requested before the NAND driver initialization is attempted
should prevent the NAND device from being started successfully.
There is another driver, omap-keypad, which also manipulates MPUIO
registers, but has never been calling request_mem_region() on startup,
so it's not affected by the change in the gpio-omap and works correctly.
It uses the depreciated omap_read/write functions for accessing MPUIO
registers. Unlike the NAND driver, these I/O lines and registers are
separate from those used by the GPIO driver. However, both register sets
are non-contiguous and overlapping, so it would be impractical to
request the two sets separately, one from the gpio-omap, the other form
the omap-keypad driver.
In order to solve all these issues correctly, a solution first suggested
by Artem Bityutskiy, then closer specified by Tony Lindgren while they
commented the initial version of this fix, should be implemented. The
gpio-omap driver should export a few functions which would allow the
other two drivers to access MPUIO registers in a safe manner instead of
trying to manage them in parallel to the GPIO driver. However, such a
big change, affecting 3 drivers all together, is not suitable for the rc
cycle, and should be prepared for the merge window. Then, an
alternative solution is proposed as a regression fix.
For the ams-delta NAND driver to initialize correctly in coexistence
with the changed GPIO driver, drop the request_mem_region() call from
the former, especially as this call is going to be removed while the
long-term solution is implemented.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Tony Lindgren t...@atomide.com
---
Artem, Tony,
I hope the changelog message is now good enough to make you satisfied,
and render the Tony's Ack valid.
Changes against initial version:
* a comment replacing the removed function call added,
* more details on the three drivers coexistance and possible interaction
provided,
* a hopefuly decent long-term plan to properly fix all identified issues
proposed.
drivers/mtd/nand/ams-delta.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 7341695..358162a 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -212,18 +212,17 @@ static int __devinit ams_delta_init(struct
platform_device *pdev)
/* Link the private data with the MTD structure */
ams_delta_mtd-priv = this;
- if (!request_mem_region(res-start, resource_size(res),
- dev_name(pdev-dev))) {
- dev_err(pdev-dev, request_mem_region failed\n);
- err = -EBUSY;
- goto out_free;
- }
+ /*
+* Don't try to request the memory region from here,
+* it should have been already requested from the
+* gpio-omap driver and requesting it again would fail.
+*/
io_base = ioremap(res-start, resource_size(res));
if (io_base == NULL) {
dev_err(pdev-dev, ioremap failed\n);
err = -EIO;
- goto out_release_io;
+ goto out_free;
}
this-priv = io_base;
@@ -271,8 +270,6 @@ out_gpio:
platform_set_drvdata(pdev, NULL);
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
-out_release_io:
- release_mem_region(res-start, resource_size(res));
out_free:
kfree(ams_delta_mtd);
out:
@@ -293,7 +290,6 @@ static int __devexit ams_delta_cleanup(struct
platform_device *pdev)
gpio_free_array(_mandatory_gpio, ARRAY_SIZE(_mandatory_gpio));
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
- release_mem_region(res-start, resource_size(res));
/* Free the MTD device structure */
kfree(ams_delta_mtd);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.4-rc4] ARM: OMAP1: Amstrad Delta: Fix wrong IRQ base in FIQ handler
Dnia piątek, 4 maja 2012 09:59:49 Tony Lindgren pisze: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 10:30]: Commit 384ebe1c2849160d040df3e68634ec506f13d9ff, gpio/omap: Add DT support to GPIO driver, introduced dynamic IRQ numbering of OMAP GPIO interrupts, breaking all IH_GPIO_BASE based IRQ number calculations. This issue was corrected in the OMAP GPIO driver and the related header file with commit 25db711df3258d125dc1209800317e5c0ef3c870, gpio/omap: Fix IRQ handling for SPARSE_IRQ. However, the Amstrad Delta FIQ handler, which replaces the gpio-omap driver in serving GPIO interrupts on this board, still uses that outdated method. Fix it. Thanks applying into fixes. Hi Tony, Thanks for taking this patch, but I ca't see it applied into your fixes branch (the last one sitting there is Linux 3.4-rc4 by Linus). Am I missing something? Regards, 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: [GIT PULL] ARM: OMAP: PM: CPUidle cleanup for v3.5
* Kevin Hilman khil...@ti.com [120507 11:07]: Tony, Please pull the following cleanup/consolidation of the OMAP CPUidle code. It's been reviewed and tested by Jean, Santosh and myself on OMAP3/4. Special thanks to Daniel Lezcano for this nice cleanup and consolidation. Thanks pulling into cleanup-cpuidle. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.4-rc4] ARM: OMAP1: Amstrad Delta: Fix wrong IRQ base in FIQ handler
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120507 14:21]: Dnia piątek, 4 maja 2012 09:59:49 Tony Lindgren pisze: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 10:30]: Commit 384ebe1c2849160d040df3e68634ec506f13d9ff, gpio/omap: Add DT support to GPIO driver, introduced dynamic IRQ numbering of OMAP GPIO interrupts, breaking all IH_GPIO_BASE based IRQ number calculations. This issue was corrected in the OMAP GPIO driver and the related header file with commit 25db711df3258d125dc1209800317e5c0ef3c870, gpio/omap: Fix IRQ handling for SPARSE_IRQ. However, the Amstrad Delta FIQ handler, which replaces the gpio-omap driver in serving GPIO interrupts on this board, still uses that outdated method. Fix it. Thanks applying into fixes. Hi Tony, Thanks for taking this patch, but I ca't see it applied into your fixes branch (the last one sitting there is Linux 3.4-rc4 by Linus). Am I missing something? Oops, sorry forgot to push it out. Pushed out now, so it should appear on the mirrors shortly. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] omap: mailbox: enable mailbox irq per instance
Hi Ohad
On Sun, May 6, 2012 at 11:00 AM, Ohad Ben-Cohen o...@wizery.com wrote:
Hi Juan,
On Sat, Apr 14, 2012 at 2:39 AM, Juan Gutierrez jgutier...@ti.com wrote:
The machine-specific omap2_mbox_startup is called only once
to initialize the whole mbox module. Enabling mbox irq at
startup is only enabling the irq of the very first mailbox
instance created.
The enable_irq function should be called every time a
new mbox instance is created,
s/created/opened/
in the generic platform mailbox layer.
This patch removes an omap2-specific code and then adds it to the
generic layer, which also deals with omap1.
Are we sure it's ok ?
OMAP1 doesn't seem to enable its irq at this point: it doesn't even
have a -startup() handler (which actually somewhat implies it's been
anyway broken for a long time now: omap_mbox_startup() seem to
unhappily bail out if it doesn't find a machine-specific -startup()
handler).
In the ISR the mbox queue are used. If they are not ready a crash might happen.
So enabling_irq should be called after mbox queue allocation and after
ISR registration.
So I think for sure startup is not the right place. Besides that, its
reference counter is
preventing other mbox instances to enable irq's.
Startup it is now only used to enable pm runtime of the whole mbox module.
I think, if request_irq is called from the generic layer, it is kind
of logical to enable_irq
next to it.
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index ad32621..ebc1ba5 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -282,6 +282,8 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
mbox-rxq = mq;
mq-mbox = mbox;
+
+ mbox-ops-enable_irq(mbox, IRQ_RX);
Might be nicer to use omap_mbox_enable_irq() here instead of reaching
out for the internal ops.
Ok, yes I will use omap_mbox_enable_irq
It also looks like there's a race here: omap_mbox_get() registers the
notifier_block only after omap_mbox_startup() returns, which probably
means there's a small window where an interrupt can be received
without us invoking the user's notifier callback.
This isn't related to your patch of course, but since you're touching
this area, it might be nice if you can fix it (i.e. simply by
registering the notifier_block before enabling the mbox's irq).
Ok I can include this fix.
}
mutex_unlock(mbox_configured_lock);
return 0;
@@ -305,6 +307,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mutex_lock(mbox_configured_lock);
if (!--mbox-use_count) {
+ mbox-ops-disable_irq(mbox, IRQ_RX);
omap_mbox_disable_irq() ?
Ok
Thanks,
Ohad.
--
Thanks
juan gutierrez
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
* Santosh Shilimkar santosh.shilim...@ti.com [120507 02:53]: Tony, On Thursday 03 May 2012 12:56 PM, R Sricharan wrote: The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Series is generated against the 3.4-rc5. This has been rebased on top of the OMAP2+ cleanup series [1] To get the boot working with omap2plus_defconfig, OMAP5 hwmod/clock/prm/cm database needs to be added. The data and the integrated tree are available in the below git repository OMAP5_DATA: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_data OMAP5_INTEGRATED: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_dt_integrated The series is boot tested on OMAP5430 ES1.0. OMAP2/3/4 build and boot is tested as well to avoid any breakage because of the series. Patch TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks is temporary and can be dropped once rebased against [2] Patch TEMP: ARM: OMAP5: Update the base address of the 32k-counter is temporary and can be dropped once rebased against [3] [1] http://www.spinics.net/lists/linux-omap/msg69233.html [2] http://www.spinics.net/lists/linux-omap/msg69013.html [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html Do you have a branch where above dependencies are merged ? Seems like those should go into the cleanup branch, and then that can be used as a base. How do you suggest to go about updating this series so that above dependencies plus DT support(3.3 based branch in arm-soc tree and needs to be updated against 3.4) is base tree for the patchset. Probably the DT patch should be separate, we can make dt branch depend on the cleanup branch. Then the data files should be first posted for reviews (and potentially updated for what we have queued in hwmod-cleanup). Does this series compile on it's own without the data now? 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
[GIT PULL] omap fixes for v3.4-rc6
The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: Linux 3.4-rc5 (2012-04-29 15:19:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-for-v3.4-rc6 for you to fetch changes up to 4d975027cc327d4486bb74b6908e874f2fee8c47: ARM: OMAP: igep0020: Specify the VPLL2 regulator unconditionally (2012-05-04 12:45:21 -0700) Few more regression fixes that are mostly board specific Archit Taneja (1): ARM: OMAP: Revert ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields Enrico Butera (1): ARM: OMAP: igep0020: fix smsc911x dummy regulator id Janusz Krzysztofik (1): ARM: OMAP1: Amstrad Delta: Fix wrong IRQ base in FIQ handler Laurent Pinchart (1): ARM: OMAP: igep0020: Specify the VPLL2 regulator unconditionally arch/arm/mach-omap1/ams-delta-fiq.c|2 +- arch/arm/mach-omap2/board-igep0020.c | 12 ++-- .../include/mach/ctrl_module_pad_core_44xx.h |8 3 files changed, 11 insertions(+), 11 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
[GIT PULL 1/5] omap sparse cleanup for v3.5 merge window
The following changes since commit e816b57a337ea3b755de72bec38c10c864f23015:
Linux 3.4-rc3 (2012-04-15 18:28:29 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-cleanup-sparse-for-v3.5
for you to fetch changes up to 09f45b83109cb8e23a06d5efb1096a08a9545974:
Merge tag 'omap-cleanup-a2-for-3.5' of
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
cleanup-sparse (2012-04-18 10:09:26 -0700)
Sparse and cppcheck warning fixes
Paul Walmsley (11):
ARM: OMAP2+: declare file-local functions as static
ARM: OMAP: add includes for missing prototypes
ARM: OMAP1: OCPI: move to mach-omap1/
ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus
ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse
ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warnings
ARM: OMAP: OCM RAM: use memset_io() when clearing SRAM
ARM: OMAP: DMA: use constant array maximum, drop some LCD DMA code
ARM: OMAP: USB: remove unnecessary sideways include
ARM: OMAP1: board files: deduplicate and clean some NAND-related code
ARM: OMAP2+: clean up some cppcheck warnings
Tony Lindgren (1):
Merge tag 'omap-cleanup-a2-for-3.5' of
git://git.kernel.org/.../pjw/omap-pending into cleanup-sparse
arch/arm/mach-omap1/Makefile | 13 ++---
arch/arm/mach-omap1/ams-delta-fiq.c |2 +-
arch/arm/mach-omap1/board-fsample.c | 16 +--
arch/arm/mach-omap1/board-h2.c | 17 +---
arch/arm/mach-omap1/board-h3.c | 16 +--
arch/arm/mach-omap1/board-nand.c | 37 ++
arch/arm/mach-omap1/board-palmz71.c |4 +--
arch/arm/mach-omap1/board-perseus2.c | 16 +--
arch/arm/mach-omap1/clock.c |3 +--
arch/arm/mach-omap1/common.h | 11 +++-
arch/arm/mach-omap1/fpga.c |2 +-
arch/arm/mach-omap1/id.c |2 ++
arch/arm/mach-omap1/io.c |3 +--
arch/arm/mach-omap1/irq.c|2 ++
arch/arm/mach-omap1/lcd_dma.c|7 +
arch/arm/{plat-omap = mach-omap1}/ocpi.c|7 +++--
arch/arm/mach-omap1/pm.c |9 +++
arch/arm/mach-omap1/reset.c |2 ++
arch/arm/mach-omap1/timer.c |3 +--
arch/arm/mach-omap1/usb.c|3 +++
arch/arm/mach-omap2/am35xx-emac.c| 37 --
arch/arm/mach-omap2/board-omap3evm.c |8 +++---
arch/arm/mach-omap2/board-omap4panda.c |8 +++---
arch/arm/mach-omap2/board-rx51-peripherals.c |4 +--
arch/arm/mach-omap2/board-zoom-display.c |1 +
arch/arm/mach-omap2/common.h |2 --
arch/arm/mach-omap2/devices.c|7 +++--
arch/arm/mach-omap2/gpio.c |2 +-
arch/arm/mach-omap2/gpmc-onenand.c |3 +--
arch/arm/mach-omap2/gpmc.c |3 +--
arch/arm/mach-omap2/hwspinlock.c |2 +-
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/irq.c|3 ++-
arch/arm/mach-omap2/mux.c|2 +-
arch/arm/mach-omap2/omap-secure.c|1 +
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm24xx.c |3 ---
arch/arm/mach-omap2/pm34xx.c | 10 +++
arch/arm/mach-omap2/prm_common.c |4 ++-
arch/arm/mach-omap2/serial.c |2 +-
arch/arm/mach-omap2/usb-tusb6010.c |2 +-
arch/arm/plat-omap/Makefile |3 ---
arch/arm/plat-omap/common.c |1 +
arch/arm/plat-omap/dma.c | 13 +++--
arch/arm/plat-omap/dmtimer.c |3 ++-
arch/arm/plat-omap/include/plat/board.h |2 ++
arch/arm/plat-omap/include/plat/common.h |2 ++
arch/arm/plat-omap/include/plat/dma.h|1 +
arch/arm/plat-omap/include/plat/dmtimer.h|4 +--
arch/arm/plat-omap/omap_device.c |2 --
arch/arm/plat-omap/sram.c|4 +--
arch/arm/plat-omap/usb.c |4 ---
drivers/usb/host/ohci-omap.c |5 ++--
53 files changed, 161 insertions(+), 165 deletions(-)
create mode 100644 arch/arm/mach-omap1/board-nand.c
rename arch/arm/{plat-omap = mach-omap1}/ocpi.c (93%)
--
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/7] ARM: OMAP2+: Misc cleanup
* Santosh Shilimkar santosh.shilim...@ti.com [120502 02:51]: This series has some miscellianeous clean up patches which help to add future OMAP2+ device support with bit less changes. It is a preparatory series for adding minimal OMAP5 support. Is this ready to be pulled? 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
DSS2 DVI output: red screen
Linux OMAP list: We are proving out the DVI output on a DM3730 board that we've designed, and we're seeing something strange: Our output to the video window is always red. We see the penguin show up in the corner, and text/graphics show up, but the red channel is always on for all pixels on the screen. Studying our schematic and comparing with the Beagleboard-xm schematic, it appears that we're hooking everything up the same way, with just some subtle differences: We desire to output 1280x720 resolution (720p), and that means we need to use the alternate configuration for the DSS output pins, as mentioned in the DM3730 TRM: On Page 1564, it states: The DISPC_DATA_LCD[5:0] data multiplexed with the DSI signals on dss_data[5:0] pads is limited to up to 60 MHz pixel clock frequency. If the parallel 18/24-bit interface in bypass mode with a pixel clock above 60 MHz is required, the DISPC_DATA_LCD[5:0] multiplexed on dss_data[23:18] pads, and DISPC_DATA_LCD[23:18] multiplexed on sys_boot pads must be used. So, we've mapped DISPC_DATA_LCD[5:0] to dss_data[23:18] pads and routed DISPC_DATA_LCD[23:18] to be multiplexed with the sys_boot pads. Our sys_boot pads are all pulled up to 1.8 V through 4.7 K-ohm resistors. I'm suspicious that this is causing the red lines to be pulled high, generating red pixels all the time. Am I off-base here? Is there something I'm missing, like the U-boot mux configuration or something? What can I check from a software level to verify that all is correct? According to the Beagle-board-xm manual, the board auto-detects which way things are hooked up, but maybe I haven't grabbed that code from the beagleboard board file? Thanks, Neil Johnson -- 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: oprofile and ARM A9 hardware counter
Jon Hunter jon-hun...@ti.com writes: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunter jon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunter jon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed 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 V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
J, KEERTHY j-keer...@ti.com writes:
Hi AnilKumar,
Thanks for reviewing.
On Fri, May 4, 2012 at 2:00 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:35, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Change the name field value to better reflect the smartreflex
integration in the system.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8
arch/arm/mach-omap2/smartreflex.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 144d118..15907b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1324,7 +1324,7 @@ static struct omap_hwmod_irq_info
omap3_smartreflex_mpu_irqs[] = {
};
static struct omap_hwmod omap34xx_sr1_hwmod = {
- .name = sr1,
+ .name = smartreflex_mpu_iva,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -1342,7 +1342,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
};
static struct omap_hwmod omap36xx_sr1_hwmod = {
- .name = sr1,
+ .name = smartreflex_mpu_iva,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -1369,7 +1369,7 @@ static struct omap_hwmod_irq_info
omap3_smartreflex_core_irqs[] = {
};
static struct omap_hwmod omap34xx_sr2_hwmod = {
- .name = sr2,
+ .name = smartreflex_core,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
@@ -1387,7 +1387,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
};
static struct omap_hwmod omap36xx_sr2_hwmod = {
- .name = sr2,
+ .name = smartreflex_core,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2edd1e2..d859277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, sr1))) {
+ if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
What if voltage rail is different for mpu and iva? I have seen some devices
supports SmartReflex have different voltage rails for mpu and iva.
I get the point. OMAP3 iva and mpu have a common rail. OMAP4 onwards
even we have different rails for mpu and iva. I will enhance the checks here.
Rather than enhancing the checks, this SoC specific data should probably
just be made part of the SoC specific hwmod dev_attr.
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 V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
AnilKumar, Chimata anilku...@ti.com writes: On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote: Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. The only thing the higher-level layers might potentially need to do to enable/disable AVS around transitions (e.g. when changing OPP, AVS is disabled before changing OPP and only re-enabled when the new nominal voltage has been acheived.) On OMAP, we handle this inside the OMAP-specific voltage layer which is called by the regulator framework, so even the regulators do not need any knowledge of AVS. Kevin, I want to point out some cases of SR implementation where this may not be true. Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR. Under this, SR module issues an interrupt to ARM when there is a need to change the voltage based on temperature changes, ageing etc. Once the interrupt arrives, kernel needs to adjust voltage using regulator API. The voltage change is a micro adjustment as in other SR classes. That can easily be handled writing a plugin specific to class 2B. This driver was designed so plugins for other classes can be supported. Sure, we might need some enhancements for other classes (we already know that we will for class 1 support.) However, the purpose of this series is to do the cleanups necessary for the driver to move to drivers/*. Support for additional classes can be added after the driver is moved if/when folks are motivated to post that support upstream. The SR class 2B implementation on these devices does not exist in mainline. I can point to some public repositories if you are interested in taking a look at the current code. No thanks. We can discuss it when you post support for it to mainline. Kevin Implementation of this SR method is must on at least the DM8168 device and I know some customers who are using it on their production systems. Regards AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Thanks, 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 V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
Kevin Hilman khil...@ti.com writes:
J, KEERTHY j-keer...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2edd1e2..d859277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, sr1))) {
+ if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
What if voltage rail is different for mpu and iva? I have seen some devices
supports SmartReflex have different voltage rails for mpu and iva.
I get the point. OMAP3 iva and mpu have a common rail. OMAP4 onwards
even we have different rails for mpu and iva. I will enhance the checks here.
Rather than enhancing the checks, this SoC specific data should probably
just be made part of the SoC specific hwmod dev_attr.
That being said, this is an additional feature we can add after this
driver is moved.
I would like this series to concentrate on the cleanups necessary to
move to drivers/*, then additional features to support other SoCs can be
added on top.
Keerthy, please prepare a patch to generalize this to other SoCs by
using dev_attr for this SoC specific data. We can add it after this
series is merged upstream.
Thanks,
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: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
Tero Kristo t-kri...@ti.com writes:
From: Axel Haslam axelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
OK, but this also changes the behavior for OMAP3 as well, right? I
don't see in the changelog how this affects OMAP3 and whether it is
still expected to work on OMAP3. When changing common code like this,
the changelog should describe the impacts on to all affected SoCs.
As suggested by Vaibhav Bedia, now might be the right time to add this
function to the SoC specific function pointers (struct pwrdm_ops.)
Doing that, the existing function could be used for OMAP3 (and OMAP4 if
the changelog describes that it can/should be used for both.)
Then, when AM33xx support is added, it will be obvious where they will
need to plugin support for that SoC.
Kevin
If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.
Signed-off-by: Axel Haslam axelhas...@gmail.com
[rna...@ti.com: Updated changelog, updated patch to support mem counters]
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..068f06b 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -124,18 +124,22 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
static void _update_logic_membank_counters(struct powerdomain *pwrdm)
{
int i;
- u8 prev_logic_pwrst, prev_mem_pwrst;
+ int logic_pwrst, mem_pwrst;
+
+ logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
+ if (logic_pwrst == -EINVAL)
+ logic_pwrst = pwrdm_read_logic_retst(pwrdm);
- prev_logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
if ((pwrdm-pwrsts_logic_ret == PWRSTS_OFF_RET)
- (prev_logic_pwrst == PWRDM_POWER_OFF))
+ (logic_pwrst == PWRDM_POWER_OFF))
pwrdm-ret_logic_off_counter++;
for (i = 0; i pwrdm-banks; i++) {
- prev_mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
-
+ mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
+ if (mem_pwrst == -EINVAL)
+ mem_pwrst = pwrdm_read_mem_retst(pwrdm, i);
if ((pwrdm-pwrsts_mem_ret[i] == PWRSTS_OFF_RET)
- (prev_mem_pwrst == PWRDM_POWER_OFF))
+ (mem_pwrst == PWRDM_POWER_OFF))
pwrdm-ret_mem_off_counter[i]++;
}
}
--
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] [OMAP] Mark Beagleboard-xM MMC bus as 4-bit
On Beagleboard-xM (all revisions) only MMC1_DAT0-MMC1_DAT3 are wired up.
Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.
v2 - Moved logic into omap3_beagle_init_rev
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7be8d65..ae7d3a7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -83,11 +83,13 @@ static struct {
int usb_pwr_level;
int reset_gpio;
int usr_button_gpio;
+ int mmc_caps;
} beagle_config = {
.mmc1_gpio_wp = -EINVAL,
.usb_pwr_level = GPIOF_OUT_INIT_LOW,
.reset_gpio = 129,
.usr_button_gpio = 4,
+ .mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
};
static struct gpio omap3_beagle_rev_gpios[] __initdata = {
@@ -145,10 +147,12 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO OMAP3 Beagle Rev: xM Ax/Bx\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ beagle_config.mmc_caps = ~MMC_CAP_8_BIT_DATA;
break;
case 2:
printk(KERN_INFO OMAP3 Beagle Rev: xM C\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
+ beagle_config.mmc_caps = ~MMC_CAP_8_BIT_DATA;
break;
default:
printk(KERN_INFO OMAP3 Beagle Rev: unknown %hd\n, beagle_rev);
@@ -251,7 +255,7 @@ static void __init beagle_display_init(void)
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
- .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ .caps = MMC_CAP_4_BIT_DATA,
.gpio_wp= -EINVAL,
.deferred = true,
},
@@ -523,6 +527,7 @@ static void __init omap3_beagle_init(void)
if (beagle_config.mmc1_gpio_wp != -EINVAL)
omap_mux_init_gpio(beagle_config.mmc1_gpio_wp, OMAP_PIN_INPUT);
+ mmc[0].caps = beagle_config.mmc_caps;
omap_hsmmc_init(mmc);
omap3_beagle_i2c_init();
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
On Tue, May 8, 2012 at 5:25 AM, Kevin Hilman khil...@ti.com wrote:
Kevin Hilman khil...@ti.com writes:
J, KEERTHY j-keer...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2edd1e2..d859277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, sr1))) {
+ if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
What if voltage rail is different for mpu and iva? I have seen some devices
supports SmartReflex have different voltage rails for mpu and iva.
I get the point. OMAP3 iva and mpu have a common rail. OMAP4 onwards
even we have different rails for mpu and iva. I will enhance the checks
here.
Rather than enhancing the checks, this SoC specific data should probably
just be made part of the SoC specific hwmod dev_attr.
That being said, this is an additional feature we can add after this
driver is moved.
I would like this series to concentrate on the cleanups necessary to
move to drivers/*, then additional features to support other SoCs can be
added on top.
Keerthy, please prepare a patch to generalize this to other SoCs by
using dev_attr for this SoC specific data. We can add it after this
series is merged upstream.
Kevin,
Ok. I will do that.
Thanks,
Kevin
--
Regards and Thanks,
Keerthy
--
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 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman khil...@ti.com wrote: AnilKumar, Chimata anilku...@ti.com writes: On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote: Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. The only thing the higher-level layers might potentially need to do to enable/disable AVS around transitions (e.g. when changing OPP, AVS is disabled before changing OPP and only re-enabled when the new nominal voltage has been acheived.) On OMAP, we handle this inside the OMAP-specific voltage layer which is called by the regulator framework, so even the regulators do not need any knowledge of AVS. Kevin, I want to point out some cases of SR implementation where this may not be true. Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR. Under this, SR module issues an interrupt to ARM when there is a need to change the voltage based on temperature changes, ageing etc. Once the interrupt arrives, kernel needs to adjust voltage using regulator API. The voltage change is a micro adjustment as in other SR classes. That can easily be handled writing a plugin specific to class 2B. This driver was designed so plugins for other classes can be supported. Sure, we might need some enhancements for other classes (we already know that we will for class 1 support.) However, the purpose of this series is to do the cleanups necessary for the driver to move to drivers/*. AnilKumar, The intent of the series as explained by Kevin if to do the necessary clean up for the driver to move from mach-omap to drivers/*. We will for sure need more enhancements for other classes support. Support for additional classes can be added after the driver is moved if/when folks are motivated to post that support upstream. The SR class 2B implementation on these devices does not exist in mainline. I can point to some public repositories if you are interested in taking a look at the current code. No thanks. We can discuss it when you post support for it to mainline. Kevin Implementation of this SR method is must on at least the DM8168 device and I know some customers who are using it on their production systems. Regards AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] OMAPDSS: APPLY: Add manager timings as extra_info in private data
Hi,
On Monday 07 May 2012 08:17 PM, Tomi Valkeinen wrote:
Hi,
On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.
To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar to what is done for overlays. This is needed
because timings aren't a part of overlay_manager_info struct configured by a
user of DSS, they are configured internally by the interface or panel drivers.
Add dirty and shadow_dirty extra_info flags for managers, update these flags
at the appropriate places. Rewrite the function extra_info_update_ongoing()
slightly as checking for manager's extra_info flags can simplify the code a bit.
Create function dss_mgr_set_timings() which applies the new manager timings to
extra_info.
Signed-off-by: Archit Tanejaarc...@ti.com
snip
+static void dss_apply_mgr_timings(struct omap_overlay_manager *mgr,
+ struct omap_video_timings *timings)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ mp-timings = *timings;
+ mp-extra_info_dirty = true;
+}
+
+void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
+ struct omap_video_timings *timings)
+{
+ unsigned long flags;
+
+ mutex_lock(apply_lock);
+
+ spin_lock_irqsave(data_lock, flags);
+
+ dss_apply_mgr_timings(mgr, timings);
+
+ spin_unlock_irqrestore(data_lock, flags);
+
+ mutex_unlock(apply_lock);
+}
With this, dpi.c others still need to use dispc_mgr_go(), which is
something that should be removed and done only from apply.c.
Ah ok, so with this set, dss_mgr_set_timings() doesn't ensure that the
configuration is taken in, the configuration may go in the next
overlay/manager enable or the next mgr_apply, but that may happen much
later.
dss_ovl|mgr_enable|disable functions handle GO, so you could have a
look at them. However, setting the timings is a bit different, so I'm
not sure how it should be done.
I think we have a few different options:
- Separate omapdss internal function (in apply.c) that can be used to
set GO after set_timings
- set GO in dss_mgr_set_timings(), but don't block
- set GO in dss_mgr_set_timings(), and block until the changes are in HW
(this is more or less what the dss_ovl|mgr_enable|disable functions
do).
The first one would be good if the interface drivers would need to set
multiple configurations, and we don't want to block after each set call.
But we don't have anything like that, at least currently.
The second one avoids blocking, but could perhaps cause problems because
the timings are not actually used yet when the function returns.
I don't see any problem with the last option, so I'm slightly leaning
towards it.
The 3rd option looks good to me too, but I'm wondering if we would need
to do the same things with all manager parameters which are in shadow
registers. Like in dpi.c, in dpi_set_mode() we set the DISPC_POL_FREQ
and DISPC_DIVISORo registers, writing GO for each parameter would be in
efficient, it's good that it doesn't happen much often. Maybe we could
group the rest of these parameters.
Archit
Tomi
--
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
