Re: [PATCH 1/1] omap3: Provide means for changing CSI2 PHY configuration
Hi, On Wed, May 09, 2012 at 08:00:41AM +0300, Sakari Ailus wrote: The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to the actual CSI-2 receivers outside the ISP itself. Allow changing this configuration from the ISP driver. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi I just realised also this one is missing: URL:http://www.spinics.net/lists/linux-media/msg43913.html I wonder if we could have these in... :-) Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe 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/08/12 19:24, Greg Kroah-Hartman wrote: On Tue, May 08, 2012 at 10:53:44AM +0300, Igor Grinberg wrote: On 05/07/12 17:48, Alan Stern wrote: 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. Ah, I see. Thanks for the explanation. So currently, I need to do something like this: Greg, This patch has been acked by Alan and Felipe, can you please apply it for the merge window (which is close as I understand from Linus': We've never been closer to a 3.4 release). Ok, but it's fallen out of my email archive (I only keep the past month around), so can you please resend it, with Alan and Felipe's acks, so I can apply it? Yep, will shortly do. Thanks -- 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
[PATCH] omap: hwmod: add support to set dmadisable in hwmod framework
The DMADISABLE bit is a semi-automatic bit present in sysconfig register
of some modules. When the DMA must perform read/write accesses, the
DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power
management, software must set the DMADISABLE bit back to 1.
In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the
DMADISABLE bit (but the romcode/bootloader might not set it back to 1).
In order for the kernel to start in a clean state, it is
necessary for the kernel to set DMADISABLE bit back to 1 (irrespective
of whether it's been set to 1 in romcode or bootloader).
During _reset of the (hwmod)device, the DMADISABLE bit is set so that it
does not prevent idling of the system. (NOTE: having DMADISABLE to 0,
prevents the system to idle)
DMADISABLE bit is present in usbotgss module of omap5.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
checkpath warnings of line over 80 characters is ignored to aid easier
grepping of strings while debugging.
arch/arm/mach-omap2/omap_hwmod.c | 50 ++
arch/arm/mach-omap2/omap_hwmod_common_data.c |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |5 +++
3 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7144ae6..009062f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -345,6 +345,49 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
}
/**
+ * _set_dmadisable: set OCP_SYSCONFIG.DMADISABLE bit in @v
+ * @oh: struct omap_hwmod *
+ *
+ * The DMADISABLE bit is a semi-automatic bit present in sysconfig register
+ * of some modules. When the DMA must perform read/write accesses, the
+ * DMADISABLE bit is cleared by the hardware. But when the DMA must stop
+ * for power management, software must set the DMADISABLE bit back to 1.
+ *
+ * Set the DMADISABLE bit in @v for hwmod @oh. Returns -EINVAL upon
+ * error or 0 upon success.
+ */
+static int _set_dmadisable(struct omap_hwmod *oh)
+{
+ u32 v;
+ u32 dmadisable_mask;
+
+ if (!oh-class-sysc ||
+ !(oh-class-sysc-sysc_flags SYSC_HAS_DMADISABLE))
+ return -EINVAL;
+
+ if (!oh-class-sysc-sysc_fields) {
+ WARN(1, omap_hwmod: %s: offset struct for sysconfig not
provided in class\n, oh-name);
+ return -EINVAL;
+ }
+
+ /* clocks must be on for this operation */
+ if (oh-_state != _HWMOD_STATE_ENABLED) {
+ pr_warning(omap_hwmod: %s: dma can be disabled only from
enabled state\n, oh-name);
+ return -EINVAL;
+ }
+
+ pr_debug(omap_hwmod: %s: setting DMADISABLE\n, oh-name);
+
+ v = oh-_sysc_cache;
+ dmadisable_mask =
+ (0x1 oh-class-sysc-sysc_fields-dmadisable_shift);
+ v |= dmadisable_mask;
+ _write_sysconfig(v, oh);
+
+ return 0;
+}
+
+/**
* _set_module_autoidle: set the OCP_SYSCONFIG AUTOIDLE field in @v
* @oh: struct omap_hwmod *
* @autoidle: desired AUTOIDLE bitfield value (0 or 1)
@@ -1469,6 +1512,12 @@ dis_opt_clks:
* access; others (like the IVA) have idiosyncratic reset sequences.
* So for these relatively rare cases, custom reset code can be
* supplied in the struct omap_hwmod_class .reset function pointer.
+ *
+ * The _set_dmadisable is called to set the DMADISABLE bit so that it
+ * does not prevent idling of the system. This is necessary for cases where
+ * ROMCODE/BOOTLOADER uses dma and transfers control to the kernel without
+ * disabling dma.
+ *
* Passes along the return value from either _reset() or the custom
* reset function - these must return -EINVAL if the hwmod cannot be
* reset this way or if the hwmod is in the wrong state, -ETIMEDOUT if
@@ -1481,6 +1530,7 @@ static int _reset(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: resetting\n, oh-name);
ret = (oh-class-reset) ? oh-class-reset(oh) : _ocp_softreset(oh);
+ _set_dmadisable(oh);
if (oh-class-sysc) {
_update_sysc_cache(oh);
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 51e5418..aff6138 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -47,6 +47,7 @@ struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2 = {
.midle_shift= SYSC_TYPE2_MIDLEMODE_SHIFT,
.sidle_shift= SYSC_TYPE2_SIDLEMODE_SHIFT,
.srst_shift = SYSC_TYPE2_SOFTRESET_SHIFT,
+ .dmadisable_shift = SYSC_TYPE2_DMADISABLE_SHIFT,
};
struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr = {
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 3f26db4..63aee22 100644
---
Re: [GIT PULL] omap fixes for v3.4-rc6
Hi, On Mon, May 7, 2012 at 3:36 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: [..] Enrico Butera (1): ARM: OMAP: igep0020: fix smsc911x dummy regulator id Hmm. Picking 40 without any kind of comment in the code isn't doing any favors for future readers. Seems like 1 would be free on this board, from the rest of the board file to judge (one other reg-fixed-regulator platform device)? Please either comment why you picked 40 (i.e. it's a random number), or change it to something a little less random like 1. :) Laurent Pinchart (1): ARM: OMAP: igep0020: Specify the VPLL2 regulator unconditionally Is this a regression? I don't see any recent changes regarding this, so it's hard to tell. If not then I'd rather hold off for the merge window given that we're at -rc6. -Olof -- To unsubscribe from this list: send the line unsubscribe 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: [RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets
Hi Dmitry ,
On Wed, May 9, 2012 at 10:48 AM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
Ho Sourav,
On Thu, Apr 26, 2012 at 11:24:37AM +0530, Sourav Poddar wrote:
-config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+config KEYBOARD_OMAP4+
I think this works purely by accident - '+' sign getting dropped by
parser...
@@ -139,16 +192,33 @@ static int omap4_keypad_open(struct input_dev *input)
disable_irq(keypad_data-irq);
- __raw_writel(OMAP4_VAL_FUNCTIONALCFG,
- keypad_data-base + OMAP4_KBD_CTRL);
- __raw_writel(OMAP4_VAL_DEBOUNCINGTIME,
- keypad_data-base + OMAP4_KBD_DEBOUNCINGTIME);
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN | OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
- __raw_writel(OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA,
- keypad_data-base + OMAP4_KBD_WAKEUPENABLE);
+ keypad_data-revision = kbd_read_revision(keypad_data,
+ OMAP4_KBD_REVISION);
+ switch (keypad_data-revision) {
+ case 1:
+ keypad_data-irqstatus = OMAP4_KBD_IRQSTATUS + 0x0c;
+ keypad_data-irqenable = OMAP4_KBD_IRQENABLE + 0x0c;
+ keypad_data-reg_offset = 0x10;
+ break;
This should be done in probe().
Dont we then require pm_runtime_put_sync in probe, since we are trying
to read the keypad revision register.?
Could you please tell me if the version of the patch below works for
you?
I just quickly tested this patch and saw the following kernel carsh.
[1.571838] Bad mode in data abort handler detected
[1.576934] Internal error: Oops - bad mode: 0 [#1] SMP ARM
[1.582763] Modules linked in:
[1.585937] CPU: 0Not tainted (3.4.0-rc5-dirty #11)
[1.591522] PC is at __key.13633+0x3f39df40/0x8
[1.596252] LR is at omap4_keypad_probe+0x1cc/0x3dc
[1.601348] pc : [0018]lr : [c0466ffc]psr: 4092
[1.601348] sp : df831e68 ip : fc31c000 fp : 0040
[1.613311] r10: c246 r9 : 0080 r8 : 0003
[1.618774] r7 : de36e880 r6 : df966008 r5 : df965480 r4 : c2422bc0
[1.625579] r3 : 6013 r2 : r1 : r0 : 001e
[1.632385] Flags: nZcv IRQs off FIQs on Mode IRQ_32 ISA ARM
Segment kernel
[1.640106] Control: 10c53c7d Table: 8000404a DAC: 0017
[1.646118] Process swapper/0 (pid: 1, stack limit = 0xdf8302f8)
[1.652374] Stack: (0xdf831e68 to 0xdf832000)
[1.656921] 1e60: 001e
6013 c2422bc0 df965480
[1.665466] 1e80: df966008 de36e880 0003 0080 c246
0040 fc31c000 df831e68
[1.674011] 1ea0: c0466ffc 0018 4092
c008b744 df967590 0098
[1.682556] 1ec0: df96603c df966008 c0c49dd8 df96603c c06f2a00
008e c06687f0 c0643fcc
[1.691070] 1ee0: c02b8748 c02b8730 c02b72c4 df966008
c06f2a00 df96603c
[1.699615] 1f00: 008e c02b74d8 c06f2a00 df831f18 c02b7444
c02b5b2c df8402a8 df968e90
[1.708160] 1f20: c06f2a00 c06e5e28 de395bc0
c02b625c c0575768 c024d028
[1.716705] 1f40: df83 c06f2a00 008e
c06687f0 c0643fcc c02b7ac4
[1.725219] 1f60: df83 0007 c06fdc00 008e
c0008630 0001 c1058170
[1.733764] 1f80: c05f8500 c0643fcc 0001 6013 0001
c05716e0 0006 0006
[1.742309] 1fa0: 6013 c064dbb0 0007 c06fdc00 c061e20c
008e c06687f0 c064dbb8
[1.750854] 1fc0: c061e374 0006 0006 c061e20c
c061e28c
[1.759399] 1fe0: c00152b8 0013
c00152b8
[1.767944] [c0466ffc] (omap4_keypad_probe+0x1cc/0x3dc) from
[df831e68] (0xdf831e68)
[1.776397] Code: e59ff410 eabb ea9a eafa (ea78)
[1.782775] [ cut here ]
[1.787628] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
l3_interrupt_handler+0x17c/0x1b4()
[1.796783] L3 custom error: MASTER:MPU TARGET:L4CFG
[1.801971] Modules linked in:
[1.805175] [c001bba4] (unwind_backtrace+0x0/0xf4) from
[c003f9f0] (warn_slowpath_common+0x4c/0x64)
[1.815002] [c003f9f0] (warn_slowpath_common+0x4c/0x64) from
[c003fa9c] (warn_slowpath_fmt+0x30/0x40)
[1.825012] [c003fa9c] (warn_slowpath_fmt+0x30/0x40) from
[c00341ac] (l3_interrupt_handler+0x17c/0x1b4)
[1.835205] [c00341ac] (l3_interrupt_handler+0x17c/0x1b4) from
[c009d88c] (handle_irq_event_percpu+0x64/0x24c)
[1.846008] [c009d88c] (handle_irq_event_percpu+0x64/0x24c) from
[c009dab0] (handle_irq_event+0x3c/0x5c)
[1.856292] [c009dab0] (handle_irq_event+0x3c/0x5c) from
[c00a05f4] (handle_fasteoi_irq+0x98/0x13c)
[1.866088] [c00a05f4] (handle_fasteoi_irq+0x98/0x13c) from
[c009d330] (generic_handle_irq+0x34/0x44)
[
Re: [RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets
On Wed, May 9, 2012 at 12:24 PM, Poddar, Sourav sourav.pod...@ti.com wrote:
Hi Dmitry ,
On Wed, May 9, 2012 at 10:48 AM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
Ho Sourav,
On Thu, Apr 26, 2012 at 11:24:37AM +0530, Sourav Poddar wrote:
-config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+config KEYBOARD_OMAP4+
I think this works purely by accident - '+' sign getting dropped by
parser...
@@ -139,16 +192,33 @@ static int omap4_keypad_open(struct input_dev *input)
disable_irq(keypad_data-irq);
- __raw_writel(OMAP4_VAL_FUNCTIONALCFG,
- keypad_data-base + OMAP4_KBD_CTRL);
- __raw_writel(OMAP4_VAL_DEBOUNCINGTIME,
- keypad_data-base + OMAP4_KBD_DEBOUNCINGTIME);
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN |
OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
- __raw_writel(OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA,
- keypad_data-base + OMAP4_KBD_WAKEUPENABLE);
+ keypad_data-revision = kbd_read_revision(keypad_data,
+ OMAP4_KBD_REVISION);
+ switch (keypad_data-revision) {
+ case 1:
+ keypad_data-irqstatus = OMAP4_KBD_IRQSTATUS + 0x0c;
+ keypad_data-irqenable = OMAP4_KBD_IRQENABLE + 0x0c;
+ keypad_data-reg_offset = 0x10;
+ break;
This should be done in probe().
Dont we then require pm_runtime_put_sync in probe, since we are trying
to read the keypad revision register.?
Sorry for the typo, I meant pm_runtime_get_sync.
Could you please tell me if the version of the patch below works for
you?
I just quickly tested this patch and saw the following kernel carsh.
[ 1.571838] Bad mode in data abort handler detected
[ 1.576934] Internal error: Oops - bad mode: 0 [#1] SMP ARM
[ 1.582763] Modules linked in:
[ 1.585937] CPU: 0 Not tainted (3.4.0-rc5-dirty #11)
[ 1.591522] PC is at __key.13633+0x3f39df40/0x8
[ 1.596252] LR is at omap4_keypad_probe+0x1cc/0x3dc
[ 1.601348] pc : [0018] lr : [c0466ffc] psr: 4092
[ 1.601348] sp : df831e68 ip : fc31c000 fp : 0040
[ 1.613311] r10: c246 r9 : 0080 r8 : 0003
[ 1.618774] r7 : de36e880 r6 : df966008 r5 : df965480 r4 : c2422bc0
[ 1.625579] r3 : 6013 r2 : r1 : r0 : 001e
[ 1.632385] Flags: nZcv IRQs off FIQs on Mode IRQ_32 ISA ARM
Segment kernel
[ 1.640106] Control: 10c53c7d Table: 8000404a DAC: 0017
[ 1.646118] Process swapper/0 (pid: 1, stack limit = 0xdf8302f8)
[ 1.652374] Stack: (0xdf831e68 to 0xdf832000)
[ 1.656921] 1e60: 001e
6013 c2422bc0 df965480
[ 1.665466] 1e80: df966008 de36e880 0003 0080 c246
0040 fc31c000 df831e68
[ 1.674011] 1ea0: c0466ffc 0018 4092
c008b744 df967590 0098
[ 1.682556] 1ec0: df96603c df966008 c0c49dd8 df96603c c06f2a00
008e c06687f0 c0643fcc
[ 1.691070] 1ee0: c02b8748 c02b8730 c02b72c4 df966008
c06f2a00 df96603c
[ 1.699615] 1f00: 008e c02b74d8 c06f2a00 df831f18 c02b7444
c02b5b2c df8402a8 df968e90
[ 1.708160] 1f20: c06f2a00 c06e5e28 de395bc0
c02b625c c0575768 c024d028
[ 1.716705] 1f40: df83 c06f2a00 008e
c06687f0 c0643fcc c02b7ac4
[ 1.725219] 1f60: df83 0007 c06fdc00 008e
c0008630 0001 c1058170
[ 1.733764] 1f80: c05f8500 c0643fcc 0001 6013 0001
c05716e0 0006 0006
[ 1.742309] 1fa0: 6013 c064dbb0 0007 c06fdc00 c061e20c
008e c06687f0 c064dbb8
[ 1.750854] 1fc0: c061e374 0006 0006 c061e20c
c061e28c
[ 1.759399] 1fe0: c00152b8 0013
c00152b8
[ 1.767944] [c0466ffc] (omap4_keypad_probe+0x1cc/0x3dc) from
[df831e68] (0xdf831e68)
[ 1.776397] Code: e59ff410 eabb ea9a eafa (ea78)
[ 1.782775] [ cut here ]
[ 1.787628] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
l3_interrupt_handler+0x17c/0x1b4()
[ 1.796783] L3 custom error: MASTER:MPU TARGET:L4CFG
[ 1.801971] Modules linked in:
[ 1.805175] [c001bba4] (unwind_backtrace+0x0/0xf4) from
[c003f9f0] (warn_slowpath_common+0x4c/0x64)
[ 1.815002] [c003f9f0] (warn_slowpath_common+0x4c/0x64) from
[c003fa9c] (warn_slowpath_fmt+0x30/0x40)
[ 1.825012] [c003fa9c] (warn_slowpath_fmt+0x30/0x40) from
[c00341ac] (l3_interrupt_handler+0x17c/0x1b4)
[ 1.835205] [c00341ac] (l3_interrupt_handler+0x17c/0x1b4) from
[c009d88c] (handle_irq_event_percpu+0x64/0x24c)
[ 1.846008] [c009d88c] (handle_irq_event_percpu+0x64/0x24c) from
[c009dab0] (handle_irq_event+0x3c/0x5c)
[ 1.856292]
Re: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
On Mon, 2012-05-07 at 15:21 -0400, Ashwin Bihari wrote:
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(-)
snip
+static int omap3logic_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(LCD_PANEL_PWR, 1);
+ if (machine_is_omap3530_lv_som())
+ gpio_set_value(OMAP3530_LV_SOM_BACKLIGHT_PWR, 1);
+ else if (machine_is_omap3_torpedo()) {
+ gpio_set_value(OMAP3530_TORPEDO_BACKLIGHT_PWR, 1);
+
+ gpio_set_value(OMAP3530_TORPEDO_MDISP, 1);
+ }
+
+ return 0;
+}
+
+static int omap3logic_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(LCD_PANEL_PWR, 0);
+ if (machine_is_omap3530_lv_som())
+ gpio_set_value(OMAP3530_LV_SOM_BACKLIGHT_PWR, 0);
+ else if (machine_is_omap3_torpedo()) {
+ gpio_set_value(OMAP3530_TORPEDO_BACKLIGHT_PWR, 0);
+
+ gpio_set_value(OMAP3530_TORPEDO_MDISP, 0);
+ }
+
+ return 0;
+}
This doesn't play well with device-tree. We can't do such callbacks when
we move to DT.
I know we have similar code for other boards, and this can't be properly
fixed right now, but I'm still a bit hesitant to add more such code
because I'm the one that has to clean it up later for DT =).
I can handle the LCD_PANEL_PWR gpio, but the backlight is something that
should be removed from the panel enable callbacks. You could look at
drivers/video/backlight/ and see if there's something there that could
be used for your board. Or implement a new BL driver, if nothing fits.
Tomi
signature.asc
Description: This is a digitally signed message part
[PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg grinb...@compulab.co.il Acked-by: Felipe Balbi ba...@ti.com Tested-by: Govindraj.R govindraj.r...@ti.com Acked-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/host/ehci-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata-reset_gpio_port[0])) - gpio_set_value(pdata-reset_gpio_port[0], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1); if (gpio_is_valid(pdata-reset_gpio_port[1])) - gpio_set_value(pdata-reset_gpio_port[1], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1); } return 0; -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] ARM: OMAP4: register V1V8, V2V1 regulators
Hello, Changes since v1: - rebased on 3.4-rc6 Original intro message: This series adds common configuration for the V1V8, V2V1 regulators from twl6030. These regulators are commonly used to feed the twl6040 audio IC on OMAP4 based boards (SDP4430, PandaBoards). The regulator support for the twl6040 MFD driver will be going via MFD tree to avoid cross tree issues. Regards, Peter --- Peter Ujfalusi (3): OMAP4: twl-common: Add twl6030 V1V8, V2V1 SMPS common configuration OMAP: 4430SDP: Use common configuration for V1V8, V2V1 supplies OMAP: omap4panda: Use common configuration for V1V8, V2V1 supplies arch/arm/mach-omap2/board-4430sdp.c|4 ++- arch/arm/mach-omap2/board-omap4panda.c |4 ++- arch/arm/mach-omap2/twl-common.c | 43 arch/arm/mach-omap2/twl-common.h |2 + 4 files changed, 51 insertions(+), 2 deletions(-) -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] OMAP4: twl-common: Add twl6030 V1V8, V2V1 SMPS common configuration
V1V8 supply from twl6030 commonly used as VIO for the machine.
V2V1 is adviced to supply the twl6040, and also to feed the twl6030's
VCXIO_IN, and VDAC_IN inputs.
Create the common regulator configurations for these regulators:
Make the V2V1 as supply_regulator for VCXIO, VDAC.
Add twl6040 (1-004b) as consumer for V1V8, and V2V1.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 43 ++
arch/arm/mach-omap2/twl-common.h |2 +
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 7a7b893..342fb2c 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -201,6 +201,7 @@ static struct regulator_init_data omap4_vdac_idata = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .supply_regulator = V2V1,
};
static struct regulator_init_data omap4_vaux2_idata = {
@@ -291,6 +292,7 @@ static struct regulator_init_data omap4_vcxio_idata = {
},
.num_consumer_supplies = ARRAY_SIZE(omap4_vcxio_supply),
.consumer_supplies = omap4_vcxio_supply,
+ .supply_regulator = V2V1,
};
static struct regulator_init_data omap4_vusb_idata = {
@@ -310,6 +312,41 @@ static struct regulator_init_data omap4_clk32kg_idata = {
},
};
+static struct regulator_consumer_supply omap4_v1v8_supply[] = {
+ REGULATOR_SUPPLY(vio, 1-004b),
+};
+
+static struct regulator_init_data omap4_v1v8_idata = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ .always_on = true,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap4_v1v8_supply),
+ .consumer_supplies = omap4_v1v8_supply,
+};
+
+static struct regulator_consumer_supply omap4_v2v1_supply[] = {
+ REGULATOR_SUPPLY(v2v1, 1-004b),
+};
+
+static struct regulator_init_data omap4_v2v1_idata = {
+ .constraints = {
+ .min_uV = 210,
+ .max_uV = 210,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap4_v2v1_supply),
+ .consumer_supplies = omap4_v2v1_supply,
+};
+
void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags)
{
@@ -350,5 +387,11 @@ void __init omap4_pmic_get_config(struct
twl4030_platform_data *pmic_data,
if (regulators_flags TWL_COMMON_REGULATOR_CLK32KG
!pmic_data-clk32kg)
pmic_data-clk32kg = omap4_clk32kg_idata;
+
+ if (regulators_flags TWL_COMMON_REGULATOR_V1V8 !pmic_data-v1v8)
+ pmic_data-v1v8 = omap4_v1v8_idata;
+
+ if (regulators_flags TWL_COMMON_REGULATOR_V2V1 !pmic_data-v2v1)
+ pmic_data-v2v1 = omap4_v2v1_idata;
}
#endif /* CONFIG_ARCH_OMAP4 */
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 0962748..8fe71cf 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -22,6 +22,8 @@
#define TWL_COMMON_REGULATOR_VCXIO (1 8)
#define TWL_COMMON_REGULATOR_VUSB (1 9)
#define TWL_COMMON_REGULATOR_CLK32KG (1 10)
+#define TWL_COMMON_REGULATOR_V1V8 (1 11)
+#define TWL_COMMON_REGULATOR_V2V1 (1 12)
/* TWL4030 LDO regulators */
#define TWL_COMMON_REGULATOR_VPLL1 (1 4)
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] OMAP: 4430SDP: Use common configuration for V1V8, V2V1 supplies
These supplies going to be needed for the twl6040 driver. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/board-4430sdp.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 130ab00..c8d38bd 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -615,7 +615,9 @@ static int __init omap4_i2c_init(void) TWL_COMMON_REGULATOR_VANA | TWL_COMMON_REGULATOR_VCXIO | TWL_COMMON_REGULATOR_VUSB | - TWL_COMMON_REGULATOR_CLK32KG); + TWL_COMMON_REGULATOR_CLK32KG | + TWL_COMMON_REGULATOR_V1V8 | + TWL_COMMON_REGULATOR_V2V1); omap4_pmic_init(twl6030, sdp4430_twldata, twl6040_data, OMAP44XX_IRQ_SYS_2N); omap_register_i2c_bus(2, 400, NULL, 0); -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe 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/3] OMAP: omap4panda: Use common configuration for V1V8, V2V1 supplies
These supplies going to be needed for the twl6040 driver. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/board-omap4panda.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 1b782ba..c47feed 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -323,7 +323,9 @@ static int __init omap4_panda_i2c_init(void) TWL_COMMON_REGULATOR_VANA | TWL_COMMON_REGULATOR_VCXIO | TWL_COMMON_REGULATOR_VUSB | - TWL_COMMON_REGULATOR_CLK32KG); + TWL_COMMON_REGULATOR_CLK32KG | + TWL_COMMON_REGULATOR_V1V8 | + TWL_COMMON_REGULATOR_V2V1); omap4_pmic_init(twl6030, omap4_panda_twldata, twl6040_data, OMAP44XX_IRQ_SYS_2N); omap_register_i2c_bus(2, 400, NULL, 0); -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe 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: [RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets
Hi Dmitry ,
On Wed, May 9, 2012 at 10:48 AM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
Ho Sourav,
On Thu, Apr 26, 2012 at 11:24:37AM +0530, Sourav Poddar wrote:
-config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+config KEYBOARD_OMAP4+
I think this works purely by accident - '+' sign getting dropped by
parser...
@@ -139,16 +192,33 @@ static int omap4_keypad_open(struct input_dev *input)
disable_irq(keypad_data-irq);
- __raw_writel(OMAP4_VAL_FUNCTIONALCFG,
- keypad_data-base + OMAP4_KBD_CTRL);
- __raw_writel(OMAP4_VAL_DEBOUNCINGTIME,
- keypad_data-base + OMAP4_KBD_DEBOUNCINGTIME);
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN |
OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
- __raw_writel(OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA,
- keypad_data-base + OMAP4_KBD_WAKEUPENABLE);
+ keypad_data-revision = kbd_read_revision(keypad_data,
+ OMAP4_KBD_REVISION);
+ switch (keypad_data-revision) {
+ case 1:
+ keypad_data-irqstatus = OMAP4_KBD_IRQSTATUS + 0x0c;
+ keypad_data-irqenable = OMAP4_KBD_IRQENABLE + 0x0c;
+ keypad_data-reg_offset = 0x10;
+ break;
This should be done in probe().
Dont we then require pm_runtime_put_sync in probe, since we are trying
to read the keypad revision register.?
Ah, indeed, but I think not pm_runtime_get_sync() but
pm_runtime_set_active().
Not sure if this will fix the crash...
--
Dmitry
Input: omap-keypad - dynamically handle register offsets
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Tested on omap4430 sdp with 3.4-rc3.
Tested on omap5430evm with 3.1-custom kernel.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/input/keyboard/Kconfig|4 +
drivers/input/keyboard/omap4-keypad.c | 117 ++---
2 files changed, 94 insertions(+), 27 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 20a3753..84ee155 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -531,9 +531,9 @@ config KEYBOARD_OMAP
module will be called omap-keypad.
config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+ tristate TI OMAP4+ keypad support
help
- Say Y here if you want to use the OMAP4 keypad.
+ Say Y here if you want to use the OMAP4+ keypad.
To compile this driver as a module, choose M here: the
module will be called omap4-keypad.
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e809ac0..c9fd0df 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -68,19 +68,52 @@
#define OMAP4_MASK_IRQSTATUSDISABLE0x
+enum {
+ KBD_REVISION_OMAP4 = 0,
+ KBD_REVISION_OMAP5,
+};
+
struct omap4_keypad {
struct input_dev *input;
void __iomem *base;
- int irq;
+ unsigned int irq;
unsigned int rows;
unsigned int cols;
+ u32 reg_offset;
+ u32 irqreg_offset;
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32 value)
+{
+ __raw_writel(value,
+keypad_data-base + keypad_data-reg_offset + offset);
+}
+
+static int kbd_read_irqreg(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-irqreg_offset + offset);
+}
+
+static void kbd_write_irqreg(struct omap4_keypad *keypad_data,
+u32 offset, u32 value)
+{
+ __raw_writel(value,
+keypad_data-base + keypad_data-irqreg_offset + offset);
+}
+
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +124,11 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
-keypad_data-base + OMAP4_KBD_IRQENABLE);
+
Re: [PATCH] ARM: OMAP1: fix compilation issue in board-sx1.c
On Tue, 2012-05-08 at 17:17 -0700, Tony Lindgren wrote: * Artem Bityutskiy dedeki...@gmail.com [120508 07:02]: From: Artem Bityutskiy artem.bityuts...@linux.intel.com SX1 board requirese i2c, so select it in Kconfig, otherwise I have the following build error: Thanks applying into fixes-non-critical as this seems to build with omap1_defconfig. Right, because omap1_defconfig has i2c enabled. The build fails if I disable it. But this is not critical to me at all. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, May 09, 2012 at 01:29:28AM +0100, Tony Lindgren wrote: * Ivan Djelic ivan.dje...@parrot.com [120426 05:23]: Hello, Here is version 3 of this patch after review from Tony Lindgren. This version adds a separate initialization function mostly to check CPU compatibility. This check cannot be done in gpmc_enable_hwecc_bch() (which is meant to be called from mtd function ecc.hwctl) because ecc.hwctl is not called before the first NAND read access, and it cannot return an error status. Thanks applying into devel-gpmc branch. OK thanks! I still have a question though: there are recent patches from Afzal Mohammed that seem to go into the opposite direction, that is giving back GPMC register access to the omap2 NAND driver. In particular, [PATCH v4 17/39] [1] commit message says: GPMC driver has been modified to fill NAND platform data with GPMC NAND register details. As these registers are accessible in NAND driver itself, configure NAND in GPMC by itself. This also includes ecc configuration. My original mtd driver patch indeed had ecc handling code inside the driver (not in arch/arm/mach-omap2/gpmc.c). So, my question is: which direction are we going to with respect to this OMAP GPMC/NAND code separation ? Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. BR, -- Ivan [1] http://lists.infradead.org/pipermail/linux-mtd/2012-May/041105.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote:
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.
Below is the pull request for board file related changes. Tested on
panda 4430sdp.
How should I manage my tree related to this... Should I rebase my
original DT preparation series on top of this new branch, or can I just
ignore the new branch for now, as long as I merge it at some point
before sending a pull request to mainline?
Tomi
The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-l-o-3.5
for you to fetch changes up to e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07:
OMAPDSS: DSI: implement generic DSI pin config (2012-05-09 10:53:05 +0300)
Tomi Valkeinen (6):
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi - tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: DSI: implement generic DSI pin config
arch/arm/mach-omap2/board-3430sdp.c| 38 +-
arch/arm/mach-omap2/board-4430sdp.c| 37 ++
arch/arm/mach-omap2/board-am3517evm.c | 25 +---
arch/arm/mach-omap2/board-cm-t35.c | 30 +
arch/arm/mach-omap2/board-devkit8000.c | 30 +
arch/arm/mach-omap2/board-igep0020.c | 32 +
arch/arm/mach-omap2/board-omap3beagle.c| 37 +-
arch/arm/mach-omap2/board-omap3evm.c | 29 +
arch/arm/mach-omap2/board-omap3stalker.c | 29 +
arch/arm/mach-omap2/board-omap4panda.c | 39 +-
arch/arm/mach-omap2/board-overo.c | 25 +---
drivers/video/omap2/displays/Kconfig |8 +-
drivers/video/omap2/displays/Makefile |2 +-
drivers/video/omap2/displays/panel-taal.c | 22
.../omap2/displays/{panel-dvi.c = panel-tfp410.c} | 134 +++-
drivers/video/omap2/dss/dsi.c | 133 +--
include/video/omap-panel-nokia-dsi.h |3 +
.../{omap-panel-dvi.h = omap-panel-tfp410.h} | 18 ++-
include/video/omapdss.h| 28 ++--
19 files changed, 251 insertions(+), 448 deletions(-)
rename drivers/video/omap2/displays/{panel-dvi.c = panel-tfp410.c} (63%)
rename include/video/{omap-panel-dvi.h = omap-panel-tfp410.h} (63%)
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, May 09, 2012 at 01:29:28AM +0100, Tony Lindgren wrote: * Ivan Djelic ivan.dje...@parrot.com [120426 05:23]: Hello, Here is version 3 of this patch after review from Tony Lindgren. This version adds a separate initialization function mostly to check CPU compatibility. This check cannot be done in gpmc_enable_hwecc_bch() (which is meant to be called from mtd function ecc.hwctl) because ecc.hwctl is not called before the first NAND read access, and it cannot return an error status. Thanks applying into devel-gpmc branch. OK thanks! I still have a question though: there are recent patches from Afzal Mohammed that seem to go into the opposite direction, that is giving back GPMC register access to the omap2 NAND driver. In particular, [PATCH v4 17/39] [1] commit message says: GPMC driver has been modified to fill NAND platform data with GPMC NAND register details. As these registers are accessible in NAND driver itself, configure NAND in GPMC by itself. This also includes ecc configuration. My original mtd driver patch indeed had ecc handling code inside the driver (not in arch/arm/mach-omap2/gpmc.c). So, my question is: which direction are we going to with respect to this OMAP GPMC/NAND code separation ? Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. BR, -- Ivan [1] http://lists.infradead.org/pipermail/linux-mtd/2012-May/041105.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Op 9 mei 2012, om 02:39 heeft Woodruff, Richard het volgende geschreven: From: Hilman, Kevin Sent: Tuesday, May 08, 2012 5:17 PM A basic OMAP AVS driver has been in mainline for a long time, yet we have not seen support submitted for all of these features. 1.5/3.5 is a feature. ABB is requirement for a production useable driver. ABB/FBB is also needed for 1GHz support on omap3 based SoCs like AM37xx and DM37xx. regards, Koen-- To unsubscribe from this list: send the line unsubscribe 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
On Tue, 2012-05-08 at 18:55 -0500, Ricardo Neri wrote: Hi Tomi, Thanks for taking the time to comment. On 05/07/2012 06:43 AM, Tomi Valkeinen wrote: 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. Yes, it does not protect. 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 Btw, I meant shortcomings in the general DSS locking strategy, not the locking in this particular patch. 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. But if the function can sleep, protecting it with the HDMI panel's mutex should be enough, shouldn't it? Wouldn't it be pointless to also hold the spinlock? If the start/stop functions use the spinlock, but not the mutex, then the sleeping functions should also use the spinlock to prevent touching the same data at the same time. Ideally, I think, only one lock, the HDMI panel's mutex, should be enough to protect the HDMI panel's functions, including the audio functions. Reusing the HDMI panel's mutex for the audio functions would prevent the situation you describe regarding hdmi_panel.c:hdmi_panel_audio_supported()... and the spinlock would not be required. The only functions that cause problems with this approach are audio_start/stop as ALSA calls them while holding a spinlock. The spinlock could be used for these as they dont read or write the panel's variables. Locks always protect a particular piece of data. What is the data in this case, if not panel's variables? DSS registers? However, holding a spinlock only when start/stopping audio would fail, for instance, if someone starts/stops audio while enabling or configuring audio; but that would be an issue in the design of the component using DSS HDMI audio, wouldn't be? To prevent that, an I guess it's up to us to decide what is the supposed use-patter of the functions =). For dss functions in general it's pretty vague and non-defined. But we could start here with audio functions and define that the audio functions may not be called from multiple threads at the same time. That would remove any issues with concurrent calls to audio functions, presuming the audio side actually conforms to this =). But the video and audio paths are probably always separate, and for those we need protection. As you said, using the mutex for the may-sleep audio functions solves the issue for those, leaving start/stop as the only problem case. However, even if we could protect start/stop with locks, we still have a problem (which is general problem related to dss locking): we don't have any protection between the function calls. So basically this could happen: [video thread] setup video enable [audio thread] check that all is ok, and configure audio [video thread] change video config or disable video [audio thread] start_audio - fails, because video config no longer valid for audio But I guess we have to accept that the locking is not perfect, and try to solve it properly later, as it's a bigger, dss-wide change. Tomi signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] omap fixes for v3.4-rc6
On Wed, May 9, 2012 at 8:48 AM, Olof Johansson o...@lixom.net wrote: Hi, On Mon, May 7, 2012 at 3:36 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: [..] Enrico Butera (1): ARM: OMAP: igep0020: fix smsc911x dummy regulator id Hmm. Picking 40 without any kind of comment in the code isn't doing any favors for future readers. Seems like 1 would be free on this board, from the rest of the board file to judge (one other reg-fixed-regulator platform device)? Please either comment why you picked 40 (i.e. it's a random number), or change it to something a little less random like 1. :) Yes i verified that 1 is free, i will send an updated patch. Enrico -- To unsubscribe from this list: send the line unsubscribe 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: decompressor: Fix mmu mapping for non-DRAM address space.
On Wed, May 9, 2012 at 3:25 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, May 08, 2012 at 07:31:57PM +0530, Shilimkar, Santosh wrote: Ok. Assuming you mean it's _not_ cleaner to have two domains where manager overrides XN attributes Note that DRAM can be in the middle of 4GB address space, so we need to take care of bottom and top address space. Update patch end of the email. Is that fine with you ? This is certainly not cleaner because this will break non-ARMv7. The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code. So it should work as long as XN bit supported or that bit position is not used. I checked ARMv6(OMAP2) and that seems to be fine. Can you please help me to understand which ARM version will be broken because of this change and how ? I only have access to ARMv6 and ARMv7 specs. The updated patch looks like below after fixing last comments from Catalin. Regards Santosh From a52613d1adc38651bf0fb824700efeb2fa02f1a2 Mon Sep 17 00:00:00 2001 From: R Sricharan r.sricha...@ti.com Date: Mon, 7 May 2012 15:11:58 +0530 Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space. 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 all regions are marked as a client domain so that XN attribute is effective. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..0faadf8 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,10 +578,11 @@ __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, #0x12 @ Default executable section orr r1, r1, #3 10 add r2, r3, #16384 1: cmp r1, r9 @ if virt start of RAM + bichs r1, r1, #0x10 @ clear XN for DRAM #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH orrhs r1, r1, #0x08 @ set cacheable #else @@ -589,6 +590,7 @@ __setup_mmu:sub r3, r4, #16384 @ Page directory size #endif cmp r1, r10 @ if virt end of RAM bichs r1, r1, #0x0c @ clear cacheable, bufferable + orrhs r1, r1, #0x10 @ Mark XN for non DRAM str r1, [r0], #4@ 1:1 mapping add r1, r1, #1048576 teq r0, r2 @@ -599,7 +601,7 @@ __setup_mmu:sub r3, r4, #16384 @ Page directory size * so there is no map overlap problem for up to 1 MB compressed kernel. * If the execution is in RAM then we would only be duplicating the above. */ - mov r1, #0x1e + mov r1, #0x0e @ Clear XN orr r1, r1, #3 10 mov r2, pc mov r2, r2, lsr #20 @@ -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, #0x03 @ Clear domain0 bits + orr r1, r1, #0x01 @ Set domain0 as client + mcr p15, 0, r1, c3, c0, 0 #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-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
OK so far.
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...
But what happens when a single kernel is built that has support for an
SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
As such Nothing...I looking into this direction while implementing.
In that case, sdrc.c file will be compiled in and execution will jump to
omap2_set_globals_sdrc(). But inside this function, we are already checking
whether the omap2_globals-sdrc and omap2_globals-sms for NULL and then use
it.
And function omap2_sdrc_init() is also depends on machine, so in case of
Am33xx, it won't get into sdrc execution at all. And in case of omap4, it
will.
In that case this new SOC_HAS_OMAP2_SDRC will be set, and
set_globals_sdrc() will be called even for the SoCs without SDRC.
So, rather than add a new Kconfig option for this, I would rather see
you using the existing runtime feature check for the SDRC: omap_has_sdrc()
There is NO difference between runtime feature check Vs this patch, refer to
the function implementation,
void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
{
if (omap2_globals-sdrc)
omap2_sdrc_base = omap2_globals-sdrc;
if (omap2_globals-sms)
omap2_sms_base = omap2_globals-sms;
}
The initialization happens after checking for NULL, so even if you execute it
or not, the variable are set to NULL in case of am33xx.
So I don't find any difference between runtime and this patch.
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 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Tony,
[snip]
-#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?
Ok, There are multiple functions under that #ifdef.
Also i see that __weak cannot be used for inline functions.
So should those functions should be moved to .c file and qualify them
__weak. There is already a strong override for OMAP2 and 3 which
should not be a problem.
[OR]
So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS
it can be changed as
#ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) ||
defined(CONFIG_ARCH_OMAP3))
So this will avoid patching this for the future socs. ?
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-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
On Wed, May 09, 2012 at 04:20:06, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
This patch cleans up dpll_data structure, making structure
fields definition based on feature availability for given SoC,
managed using Kconfig rules.
SOC_HAS_OMAP3_DPLL_IDLE: idle state
SOC_HAS_OMAP3_DPLL_RECAL: recalibration capability
SOC_HAS_OMAP3_DPLL_DCO_SEL: dco selection
SOC_HAS_OMAP3_DPLL_SDDIV: sigma-delta div factor
SOC_HAS_OMAP3_DPLL_FREQSEL: frequency selection
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Paul is the one to make the call here, but personally I'd much prefer to
just see the existing ifdefs go away[1] instead of adding a bunch of new
ones.
Yes, doing so would add a few fields to a struct that may be unused, but
IMO, the improvement in readabilitly and maintainability is improved.
Note that the users of these fields are not changed and are still based
on Kconfig/Makefile values as before (e.g. CONFIG_ARCH_OMAP3), so to me
this creates another layer of obfuscation.
This will bring in difference on omap2 alone build OR omap4, am33xx alone
builds.
But again, how much it makes sense, and how much benefits we bring-in by
adding config options for every bit-fields (like this) needs to be looked at.
And that's the reason, I submitted first version as a RFC.
[1]
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..656b986 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,6 @@ struct dpll_data {
u8 min_divider;
u16 max_divider;
u8 modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
void __iomem*autoidle_reg;
void __iomem*idlest_reg;
u32 autoidle_mask;
@@ -167,7 +166,6 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
-# endif
u8 flags;
};
Honestly, I wanted to propose this first.
I am OK, as long as we all agree on this.
Paul, can you conform on this?
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: OMAP2+: am33xx: Make am33xx as a separate class
On Wed, May 09, 2012 at 01:38:34, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120508 08:32]: --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -123,8 +123,11 @@ config SOC_OMAPTI81XX config SOC_OMAPAM33XX bool AM33XX support - depends on ARCH_OMAP3 + depends on ARCH_OMAP2PLUS This is not needed, it's inside if ARCH_OMAP2PLUS block. Good point, I will remove it. --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -16,6 +16,7 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_SOC_OMAPAM33XX) += irq.o $(hwmod-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -93,6 +94,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \ cm44xx.o prcm_mpu44xx.o \ prminst44xx.o vc44xx_data.o \ vp44xx_data.o prm44xx.o +obj-$(CONFIG_SOC_OMAPAM33XX) += prcm.o # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -102,6 +104,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= $(voltagedomain-common) \ voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \ voltagedomains44xx_data.o +obj-$(CONFIG_SOC_OMAPAM33XX) += $(voltagedomain-common) # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o @@ -116,6 +119,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= $(powerdomain-common) \ obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \ powerdomain44xx.o \ powerdomains44xx_data.o +obj-$(CONFIG_SOC_OMAPAM33XX) += $(powerdomain-common) # PRCM clockdomain control clockdomain-common += clockdomain.o \ @@ -132,6 +136,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= $(clockdomain-common) \ obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common) \ clockdomain44xx.o \ clockdomains44xx_data.o +obj-$(CONFIG_SOC_OMAPAM33XX) += $(clockdomain-common) # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o \ @@ -149,6 +154,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= $(clock-common) clock3xxx.o \ clkt_iclk.o obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o \ dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_OMAPAM33XX) += $(clock-common) dpll3xxx.o # OMAP2 clock rate set data (old OPP data) obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o Can you please rebase this on what's now in the cleanup branch at commit 382ae00105d9989a821f458084e0428bce10b969? That should simplify the Makefile changes a bit. Yes, will do it and submit next version today. Other than that looks good to me. 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: [RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets
Hi Dmitry,
I did some minor fixes to the patch which you suggested above and
the keypad is functional now.
Changes:
- Move pm_runtime_enable before using pm_runtime_get_sync.
Sending the patch inlined..(also attached).
From: G, Manjunath Kondaiah manj...@ti.com
Date: Mon, 10 Oct 2011 20:52:05 +0530
Subject: [PATCH] Input: omap-keypad: dynamically handle register offsets
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Tested on omap4430 sdp with 3.4-rc3.
Tested on omap5430evm with 3.1-custom kernel.
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/input/keyboard/Kconfig|4 +-
drivers/input/keyboard/omap4-keypad.c | 120 +---
2 files changed, 95 insertions(+), 29 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index f354813..33bbdee 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -512,9 +512,9 @@ config KEYBOARD_OMAP
module will be called omap-keypad.
config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+ tristate TI OMAP4+ keypad support
help
- Say Y here if you want to use the OMAP4 keypad.
+ Say Y here if you want to use the OMAP4+ keypad.
To compile this driver as a module, choose M here: the
module will be called omap4-keypad.
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e809ac0..d7102e8 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -68,19 +68,52 @@
#define OMAP4_MASK_IRQSTATUSDISABLE0x
+enum {
+ KBD_REVISION_OMAP4 = 0,
+ KBD_REVISION_OMAP5,
+};
+
struct omap4_keypad {
struct input_dev *input;
void __iomem *base;
- int irq;
+ unsigned int irq;
unsigned int rows;
unsigned int cols;
+ u32 reg_offset;
+ u32 irqreg_offset;
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32 value)
+{
+ __raw_writel(value,
+keypad_data-base + keypad_data-reg_offset + offset);
+}
+
+static int kbd_read_irqreg(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-irqreg_offset + offset);
+}
+
+static void kbd_write_irqreg(struct omap4_keypad *keypad_data,
+u32 offset, u32 value)
+{
+ __raw_writel(value,
+keypad_data-base + keypad_data-irqreg_offset + offset);
+}
+
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +124,11 @@ static irqreturn_t omap4_keypad_interrupt(int
irq, void *dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
-keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
+OMAP4_VAL_IRQDISABLE);
- *new_state = __raw_readl(keypad_data-base + OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data-base
- + OMAP4_KBD_FULLCODE63_32);
+ *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+ *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
for (row = 0; row keypad_data-rows; row++) {
changed = key_state[row] ^ keypad_data-key_state[row];
@@ -121,12 +153,13 @@ static irqreturn_t omap4_keypad_interrupt(int
irq, void *dev_id)
sizeof(keypad_data-key_state));
/* clear pending interrupts */
- __raw_writel(__raw_readl(keypad_data-base + OMAP4_KBD_IRQSTATUS),
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
+kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS));
/* enable interrupts */
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN | OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
+ OMAP4_DEF_IRQENABLE_EVENTEN |
+ OMAP4_DEF_IRQENABLE_LONGKEY);
return IRQ_HANDLED;
}
@@ -139,16 +172,17 @@ static int omap4_keypad_open(struct input_dev
Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tuesday 08 May 2012 06:05 PM, Archit Taneja wrote: On Tuesday 08 May 2012 05:25 PM, Tomi Valkeinen wrote: On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote: On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote: Checking the validity of all the settings is a bit tricky, but currently I think, as a rule of thumb, we should accept any settings when things are disabled. So, until the interface driver sets the timings before enabling the output, all ovl/mgr settings should be allowed. And we We have 2 ways to go about this, one is to have an initial set of 'always valid' values like I have done, the other option is to ignore manager timing related checks if the manager is disabled, i.e all configs are okay. To implement the second option, I think our function dss_check_settings_low() would get more complicated. We would now have to pass mp-enabled outside of apply, and pass it to dss_mgr_check() which would further need to pass this to dss_ovl_check(). Hence I used the first approach. I'm not sure about that. We already do it for overlay. In ovl.c we have dss_ovl_simple_check() and dss_ovl_check(). The simple check sees if the settings pass basic sanity check. The check sees if all the ovl mgr settings are compatible with each other. Simple check is done when setting the config, called from dss_ovl_set_info(). The proper check is done later when the actual config is about to be taken into use. If mp-enabled == false, can't we just skip dss_check_settings_low() totally for that manager? We skip the check for ovls the same way. Okay, this would work better I guess. If someone tries to enable the manager without setting the timings, that check should fail, and in my approach, it would have passed, and would have led to bad stuff later. One change in behaviour with the patch series I see is with the following use case when connected to Pandaboad's DVI interface: - Bootup with 1080p resolution - Try to set 640x480 timings with sysfs. The older behaviour was that the timings were taken, and a skewed image was seen(because the overlay size is larger in deimension) The behaviour after this series is that the mgr_set_timings fails with the error: omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1920 = 640) I guess this is better in a way, a user of DSS is supposed to reallocate the framebuffer with the desired size and then change the timings. But with DVI, the problem is that dpi_set_timings already does a ton of stuff before dss_mgr_set_timings() is called, so we change the dividers to get the new clock, and then realise that the overlay can't fit inside, and we are left nowhere. I guess this is a separate problem and we could tackle it later. Archit shouldn't even write any shadow registers until the moment the output is enabled. That's being done correctly even now I guess, with the checks for mp-enabled in wrtie_regs() and set_go_bits(). Yes, for timings. I was thinking more about the other settings done in dpi.c currently, like dispc_mgr_set_pol_freq(). That writes directly to registers, so we need runtime_get for that. Ok. Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-fbdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets
Hi Dmitry,
On Wed, May 9, 2012 at 3:14 PM, Poddar, Sourav sourav.pod...@ti.com wrote:
Hi Dmitry,
I did some minor fixes to the patch which you suggested above and
the keypad is functional now.
Changes:
- Move pm_runtime_enable before using pm_runtime_get_sync.
Sending the patch inlined..(also attached).
From: G, Manjunath Kondaiah manj...@ti.com
Date: Mon, 10 Oct 2011 20:52:05 +0530
Subject: [PATCH] Input: omap-keypad: dynamically handle register offsets
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Tested on omap4430 sdp with 3.4-rc3.
Tested on omap5430evm with 3.1-custom kernel.
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/input/keyboard/Kconfig | 4 +-
drivers/input/keyboard/omap4-keypad.c | 120 +---
2 files changed, 95 insertions(+), 29 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index f354813..33bbdee 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -512,9 +512,9 @@ config KEYBOARD_OMAP
module will be called omap-keypad.
config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+ tristate TI OMAP4+ keypad support
help
- Say Y here if you want to use the OMAP4 keypad.
+ Say Y here if you want to use the OMAP4+ keypad.
To compile this driver as a module, choose M here: the
module will be called omap4-keypad.
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e809ac0..d7102e8 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -68,19 +68,52 @@
#define OMAP4_MASK_IRQSTATUSDISABLE 0x
+enum {
+ KBD_REVISION_OMAP4 = 0,
+ KBD_REVISION_OMAP5,
+};
+
struct omap4_keypad {
struct input_dev *input;
void __iomem *base;
- int irq;
+ unsigned int irq;
unsigned int rows;
unsigned int cols;
+ u32 reg_offset;
+ u32 irqreg_offset;
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32
value)
+{
+ __raw_writel(value,
+ keypad_data-base + keypad_data-reg_offset + offset);
+}
+
+static int kbd_read_irqreg(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-irqreg_offset + offset);
+}
+
+static void kbd_write_irqreg(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ __raw_writel(value,
+ keypad_data-base + keypad_data-irqreg_offset + offset);
+}
+
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +124,11 @@ static irqreturn_t omap4_keypad_interrupt(int
irq, void *dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
+ OMAP4_VAL_IRQDISABLE);
- *new_state = __raw_readl(keypad_data-base + OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data-base
- + OMAP4_KBD_FULLCODE63_32);
+ *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+ *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
for (row = 0; row keypad_data-rows; row++) {
changed = key_state[row] ^ keypad_data-key_state[row];
@@ -121,12 +153,13 @@ static irqreturn_t omap4_keypad_interrupt(int
irq, void *dev_id)
sizeof(keypad_data-key_state));
/* clear pending interrupts */
- __raw_writel(__raw_readl(keypad_data-base + OMAP4_KBD_IRQSTATUS),
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
+ kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS));
/* enable interrupts */
- __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN |
OMAP4_DEF_IRQENABLE_LONGKEY,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
+
[PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
An overlay manager's timings (the manager size, and blanking parameters if an LCD manager) are DISPC shadow registers, and they should hence follow the correct programming model. This set makes the timings an extra_info parameter in manager's private data . The interface drivers now apply the timings in instead of directly writing to registers. This change also prevents the need to use display resolution for overlay checks, hence making some of the APPLY functions less dependent on the display. Some DISPC functions that needed display width can also use these privately stored timings. Changes since v3: - Remove direct setting of go bit in dpi_set_timings() - Take some of the patches in OMAPDSS: Misc fixes and cleanups and make them a part of this series as they are more related. - Don't have an initial set of manager timings in private data, only check manager and overlay parameters once the manager is enabled. These patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Reference tree containing this series: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2 Tested on OMAP4 SDP and Panda. Archit Taneja (9): OMAPDSS: APPLY: Add manager timings as extra_info in private data OMAPDSS: Apply manager timings instead of direct DISPC writes OMAPDSS: MANAGER: Create a function to check manager timings OMAPDSS: APPLY: Don't check manager settings if it is disabled OMAPDSS: APPLY: Remove display dependency from overlay and manager checks 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() drivers/video/omap2/dss/apply.c | 132 - drivers/video/omap2/dss/dispc.c | 64 -- drivers/video/omap2/dss/dpi.c |7 +- drivers/video/omap2/dss/dsi.c |5 +- drivers/video/omap2/dss/dss.h | 16 +++-- drivers/video/omap2/dss/hdmi.c|4 +- drivers/video/omap2/dss/manager.c | 19 +- drivers/video/omap2/dss/overlay.c | 10 +-- drivers/video/omap2/dss/rfbi.c|4 +- drivers/video/omap2/dss/sdi.c |2 +- drivers/video/omap2/dss/venc.c|2 +- 11 files changed, 175 insertions(+), 90 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 v4 1/9] OMAPDSS: APPLY: Add manager timings as extra_info in private data
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
---
drivers/video/omap2/dss/apply.c | 96 +-
drivers/video/omap2/dss/dss.h |2 +
2 files changed, 85 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index b10b3bc..57686f6 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -99,6 +99,11 @@ struct mgr_priv_data {
/* If true, a display is enabled using this manager */
bool enabled;
+
+ bool extra_info_dirty;
+ bool shadow_extra_info_dirty;
+
+ struct omap_video_timings timings;
};
static struct {
@@ -261,6 +266,20 @@ static bool need_isr(void)
if (mp-shadow_info_dirty)
return true;
+ /*
+* NOTE: we don't check extra_info flags for disabled
+* managers, once the manager is enabled, the extra_info
+* related manager changes will be taken in by HW.
+*/
+
+ /* to write new values to registers */
+ if (mp-extra_info_dirty)
+ return true;
+
+ /* to set GO bit */
+ if (mp-shadow_extra_info_dirty)
+ return true;
+
list_for_each_entry(ovl, mgr-overlays, list) {
struct ovl_priv_data *op;
@@ -305,7 +324,7 @@ static bool need_go(struct omap_overlay_manager *mgr)
mp = get_mgr_priv(mgr);
- if (mp-shadow_info_dirty)
+ if (mp-shadow_info_dirty || mp-shadow_extra_info_dirty)
return true;
list_for_each_entry(ovl, mgr-overlays, list) {
@@ -320,20 +339,16 @@ static bool need_go(struct omap_overlay_manager *mgr)
/* returns true if an extra_info field is currently being updated */
static bool extra_info_update_ongoing(void)
{
- const int num_ovls = omap_dss_get_num_overlays();
- struct ovl_priv_data *op;
- struct omap_overlay *ovl;
- struct mgr_priv_data *mp;
+ const int num_mgrs = dss_feat_get_num_mgrs();
int i;
- for (i = 0; i num_ovls; ++i) {
- ovl = omap_dss_get_overlay(i);
- op = get_ovl_priv(ovl);
-
- if (!ovl-manager)
- continue;
+ for (i = 0; i num_mgrs; ++i) {
+ struct omap_overlay_manager *mgr;
+ struct omap_overlay *ovl;
+ struct mgr_priv_data *mp;
- mp = get_mgr_priv(ovl-manager);
+ mgr = omap_dss_get_overlay_manager(i);
+ mp = get_mgr_priv(mgr);
if (!mp-enabled)
continue;
@@ -341,8 +356,15 @@ static bool extra_info_update_ongoing(void)
if (!mp-updating)
continue;
- if (op-extra_info_dirty || op-shadow_extra_info_dirty)
+ if (mp-extra_info_dirty || mp-shadow_extra_info_dirty)
return true;
+
+ list_for_each_entry(ovl, mgr-overlays, list) {
+ struct ovl_priv_data *op = get_ovl_priv(ovl);
+
+ if (op-extra_info_dirty || op-shadow_extra_info_dirty)
+ return true;
+ }
}
return false;
@@ -601,6 +623,22 @@ static void dss_mgr_write_regs(struct omap_overlay_manager
*mgr)
}
}
+static void dss_mgr_write_regs_extra(struct omap_overlay_manager *mgr)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ DSSDBGF(%d, mgr-id);
+
+ if (!mp-extra_info_dirty)
+ return;
+
+ dispc_mgr_set_timings(mgr-id, mp-timings);
+
+ mp-extra_info_dirty = false;
+ if (mp-updating)
+ mp-shadow_extra_info_dirty = true;
+}
+
static void dss_write_regs_common(void)
{
const int num_mgrs = omap_dss_get_num_overlay_managers();
@@ -654,6 +692,7 @@ static void dss_write_regs(void)
}
[PATCH v4 2/9] OMAPDSS: Apply manager timings instead of direct DISPC writes
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.
Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit
is now set by dss_mgr_set_timings().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dpi.c |3 +--
drivers/video/omap2/dss/dsi.c |5 ++---
drivers/video/omap2/dss/hdmi.c |2 +-
drivers/video/omap2/dss/rfbi.c |4 ++--
drivers/video/omap2/dss/sdi.c |2 +-
drivers/video/omap2/dss/venc.c |2 +-
6 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index cec1166..e65cf1f 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -156,7 +156,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
t-pixel_clock = pck;
}
- dispc_mgr_set_timings(dssdev-manager-id, t);
+ dss_mgr_set_timings(dssdev-manager, t);
return 0;
}
@@ -294,7 +294,6 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
}
dpi_set_mode(dssdev);
- dispc_mgr_go(dssdev-manager-id);
dispc_runtime_put();
dss_runtime_put();
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6c4b034..95bc996 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4215,13 +4215,12 @@ static int dsi_display_init_dispc(struct
omap_dss_device *dssdev)
dispc_mgr_enable_stallmode(dssdev-manager-id, true);
dispc_mgr_enable_fifohandcheck(dssdev-manager-id, 1);
- dispc_mgr_set_timings(dssdev-manager-id, timings);
+ dss_mgr_set_timings(dssdev-manager, timings);
} else {
dispc_mgr_enable_stallmode(dssdev-manager-id, false);
dispc_mgr_enable_fifohandcheck(dssdev-manager-id, 0);
- dispc_mgr_set_timings(dssdev-manager-id,
- dssdev-panel.timings);
+ dss_mgr_set_timings(dssdev-manager, dssdev-panel.timings);
}
dispc_mgr_set_lcd_display_type(dssdev-manager-id,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 56f6e9c..8d4ff8c 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -376,7 +376,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
dispc_enable_gamma_table(0);
/* tv size */
- dispc_mgr_set_timings(dssdev-manager-id, dssdev-panel.timings);
+ dss_mgr_set_timings(dssdev-manager, dssdev-panel.timings);
hdmi.ip_data.ops-video_enable(hdmi.ip_data, 1);
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index a81ffcb..feadfab 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -320,7 +320,7 @@ static void rfbi_transfer_area(struct omap_dss_device
*dssdev, u16 width,
DSSDBG(rfbi_transfer_area %dx%d\n, width, height);
- dispc_mgr_set_timings(dssdev-manager-id, timings);
+ dss_mgr_set_timings(dssdev-manager, timings);
dispc_mgr_enable(dssdev-manager-id, true);
@@ -804,7 +804,7 @@ int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,
if (*w == 0 || *h == 0)
return -EINVAL;
- dispc_mgr_set_timings(dssdev-manager-id, timings);
+ dss_mgr_set_timings(dssdev-manager, timings);
return 0;
}
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 741b834..67fbe7c 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -107,7 +107,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
}
- dispc_mgr_set_timings(dssdev-manager-id, t);
+ dss_mgr_set_timings(dssdev-manager, t);
r = dss_set_clock_div(dss_cinfo);
if (r)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 6947f5b..9475e6e 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -444,7 +444,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
timings = dssdev-panel.timings;
timings.y_res /= 2;
- dispc_mgr_set_timings(dssdev-manager-id, timings);
+ dss_mgr_set_timings(dssdev-manager, timings);
r = regulator_enable(venc.vdda_dac_reg);
if (r)
--
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 v4 3/9] OMAPDSS: MANAGER: Create a function to check manager timings
Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.
dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the omap_dss_device struct. This would be later
replaced by the timings stored in the manager's private data.
Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
omap_video_timings pointer since these functions just check the timings.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |2 +-
drivers/video/omap2/dss/dpi.c |2 +-
drivers/video/omap2/dss/dss.h |4 +++-
drivers/video/omap2/dss/manager.c | 15 +++
4 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 82012d1..6eec084 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2479,7 +2479,7 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int
hbp,
}
bool dispc_mgr_timings_ok(enum omap_channel channel,
- struct omap_video_timings *timings)
+ const struct omap_video_timings *timings)
{
bool timings_ok;
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e65cf1f..e01ab98 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -311,7 +311,7 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
unsigned long pck;
struct dispc_clock_info dispc_cinfo;
- if (!dispc_mgr_timings_ok(dssdev-manager-id, timings))
+ if (dss_mgr_check_timings(dssdev-manager, timings))
return -EINVAL;
if (timings-pixel_clock == 0)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index b17a212..a13b305 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -208,6 +208,8 @@ int dss_init_overlay_managers(struct platform_device *pdev);
void dss_uninit_overlay_managers(struct platform_device *pdev);
int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
const struct omap_overlay_manager_info *info);
+int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
+ const struct omap_video_timings *timings);
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
@@ -413,7 +415,7 @@ void dispc_enable_gamma_table(bool enable);
void dispc_set_loadmode(enum omap_dss_load_mode mode);
bool dispc_mgr_timings_ok(enum omap_channel channel,
- struct omap_video_timings *timings);
+ const struct omap_video_timings *timings);
unsigned long dispc_fclk_rate(void);
void dispc_find_clk_divs(bool is_tft, unsigned long req_pck, unsigned long fck,
struct dispc_clock_info *cinfo);
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index e736460..566fbba 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -654,6 +654,17 @@ static int dss_mgr_check_zorder(struct
omap_overlay_manager *mgr,
return 0;
}
+int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
+ const struct omap_video_timings *timings)
+{
+ if (!dispc_mgr_timings_ok(mgr-id, timings)) {
+ DSSERR(check_manager: invalid timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
@@ -668,6 +679,10 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
return r;
}
+ r = dss_mgr_check_timings(mgr, dssdev-panel.timings);
+ if (r)
+ return r;
+
list_for_each_entry(ovl, mgr-overlays, list) {
struct omap_overlay_info *oi;
int r;
--
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 v4 4/9] OMAPDSS: APPLY: Don't check manager settings if it is disabled
If a manager is disabled, there is no guarantee at any point in time that all it's parameters are configured. There is always a chance that some more parameters are yet to be configured by a user of DSS, or by DSS itself. However, when the manager is enabled, we can be certain that all the parameters have been configured, as we can't enable a manager with an incomplete configuration. Therefore, if a manager is disabled, don't check for the validity of it's parameters or the parameters of the overlays connected to it. Only check once it is enabled. Add a check in dss_check_settings_low() to achieve the same. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/apply.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c index 57686f6..ad349b3 100644 --- a/drivers/video/omap2/dss/apply.c +++ b/drivers/video/omap2/dss/apply.c @@ -192,6 +192,9 @@ static int dss_check_settings_low(struct omap_overlay_manager *mgr, mp = get_mgr_priv(mgr); + if (!mp-enabled) + return 0; + if (applying mp-user_info_dirty) mi = mp-user_info; else -- 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 v4 5/9] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
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.
Pass the manager's timings in private data to dss_mgr_check(). Remove the need
to pass omap_dss_device structs in the functions which check for the validity
of overlay and manager parameters.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c | 24 +++-
drivers/video/omap2/dss/dss.h |7 ---
drivers/video/omap2/dss/manager.c |6 +++---
drivers/video/omap2/dss/overlay.c | 10 --
4 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index ad349b3..0ffe4e1 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -181,7 +181,7 @@ static bool mgr_manual_update(struct omap_overlay_manager
*mgr)
}
static int dss_check_settings_low(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev, bool applying)
+ bool applying)
{
struct omap_overlay_info *oi;
struct omap_overlay_manager_info *mi;
@@ -214,26 +214,24 @@ static int dss_check_settings_low(struct
omap_overlay_manager *mgr,
ois[ovl-id] = oi;
}
- return dss_mgr_check(mgr, dssdev, mi, ois);
+ return dss_mgr_check(mgr, mi, mp-timings, ois);
}
/*
* check manager and overlay settings using overlay_info from data-info
*/
-static int dss_check_settings(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
+static int dss_check_settings(struct omap_overlay_manager *mgr)
{
- return dss_check_settings_low(mgr, dssdev, false);
+ return dss_check_settings_low(mgr, false);
}
/*
* check manager and overlay settings using overlay_info from ovl-info if
* dirty and from data-info otherwise
*/
-static int dss_check_settings_apply(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
+static int dss_check_settings_apply(struct omap_overlay_manager *mgr)
{
- return dss_check_settings_low(mgr, dssdev, true);
+ return dss_check_settings_low(mgr, true);
}
static bool need_isr(void)
@@ -687,7 +685,7 @@ static void dss_write_regs(void)
if (!mp-enabled || mgr_manual_update(mgr) || mp-busy)
continue;
- r = dss_check_settings(mgr, mgr-device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR(cannot write registers for manager %s:
illegal configuration\n, mgr-name);
@@ -754,7 +752,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
WARN_ON(mp-updating);
- r = dss_check_settings(mgr, mgr-device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR(cannot start manual update: illegal configuration\n);
spin_unlock_irqrestore(data_lock, flags);
@@ -901,7 +899,7 @@ int omap_dss_mgr_apply(struct omap_overlay_manager *mgr)
spin_lock_irqsave(data_lock, flags);
- r = dss_check_settings_apply(mgr, mgr-device);
+ r = dss_check_settings_apply(mgr);
if (r) {
spin_unlock_irqrestore(data_lock, flags);
DSSERR(failed to apply settings: illegal configuration.\n);
@@ -1094,7 +1092,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr)
mp-enabled = true;
- r = dss_check_settings(mgr, mgr-device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR(failed to enable manager %d: check_settings failed\n,
mgr-id);
@@ -1466,7 +1464,7 @@ int dss_ovl_enable(struct omap_overlay *ovl)
op-enabling = true;
- r = dss_check_settings(ovl-manager, ovl-manager-device);
+ r = dss_check_settings(ovl-manager);
if (r) {
DSSERR(failed to enable overlay %d: check_settings failed\n,
ovl-id);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index a13b305..f3fa445 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -179,6 +179,7 @@ int dss_mgr_set_device(struct omap_overlay_manager *mgr,
int dss_mgr_unset_device(struct omap_overlay_manager *mgr);
void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
struct omap_video_timings *timings);
+const struct omap_video_timings *dss_mgr_get_timings(struct
omap_overlay_manager *mgr);
bool dss_ovl_is_enabled(struct omap_overlay *ovl);
int dss_ovl_enable(struct omap_overlay *ovl);
@@ -211,8 +212,8 @@ int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
[PATCH v4 6/9] OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
The DPI and HDMI 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 held by 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 e01ab98..d6e8fe7 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -297,6 +297,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 v4 7/9] 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 0ffe4e1..15c070c 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -960,14 +960,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 v4 8/9] 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 6eec084..cd0a397 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 v4 9/9] 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 it.
The manager's timing is stored in it's private data in APPLY. This contains
the latest timings applied to the manager. Pass these timings to
dispc_ovl_setup() and use them in the above functions. 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/apply.c |6 ++--
drivers/video/omap2/dss/dispc.c | 51 +-
drivers/video/omap2/dss/dss.h |3 +-
3 files changed, 28 insertions(+), 32 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 15c070c..dd88b8f 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -548,11 +548,13 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
oi = op-info;
+ mp = get_mgr_priv(ovl-manager);
+
replication = dss_use_replication(ovl-manager-device, oi-color_mode);
ilace = ovl-manager-device-type == OMAP_DISPLAY_TYPE_VENC;
- r = dispc_ovl_setup(ovl-id, oi, ilace, replication);
+ r = dispc_ovl_setup(ovl-id, oi, ilace, replication, mp-timings);
if (r) {
/*
* We can't do much here, as this function can be called from
@@ -566,8 +568,6 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
return;
}
- mp = get_mgr_priv(ovl-manager);
-
op-info_dirty = false;
if (mp-updating)
op-shadow_info_dirty = true;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index cd0a397..727e15b 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) {
@@ -1661,18 +1653,17 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
* This function is used to avoid synclosts in OMAP3, because of some
* undocumented horizontal position and timing related limitations.
*/
-static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
+static int check_horiz_timing_omap3(enum omap_channel channel,
+ const struct omap_video_timings *t, 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;
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;
+ 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 +1675,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;
@@ -1715,7 +1706,8 @@ static int check_horiz_timing_omap3(enum omap_channel
channel, u16 pos_x,
}
static unsigned long calc_core_clk_five_taps(enum omap_channel channel,
- u16 width, u16 height, u16 out_width, u16 out_height,
+ const struct omap_video_timings *mgr_timings, u16 width,
+ u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
{
u32 core_clk = 0;
@@ -1725,8 +1717,7 @@ 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;
+ unsigned int ppl = mgr_timings-x_res;
tmp = pclk * height * out_width;
do_div(tmp, 2 * out_height * ppl);
@@ -1795,8 +1786,9 @@ static unsigned long calc_core_clk(enum omap_channel
channel, u16 width,
}
static int dispc_ovl_calc_scaling(enum omap_plane plane,
-
Re: [GIT PULL] ARM: OMAP3+: PRM/hwmod: fix and improve I/O chain wakeup support
On Fri, 2012-04-20 at 09:55 -0700, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [120420 01:24]: Hi, What happened with this pull request? It doesn't seem to be in 3.4 at least. There was a boot issue on omap3 evm and that branch got dropped. Will merge it again after Paul has figured out the issue. Paul / Tony, do you want me to re-send the set for this with the OMAP3 EVM related fix? This was figured out in a separate email chain. -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 v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Wed, 2012-05-09 at 15:23 +0530, Archit Taneja wrote: On Tuesday 08 May 2012 06:05 PM, Archit Taneja wrote: On Tuesday 08 May 2012 05:25 PM, Tomi Valkeinen wrote: On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote: On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote: Checking the validity of all the settings is a bit tricky, but currently I think, as a rule of thumb, we should accept any settings when things are disabled. So, until the interface driver sets the timings before enabling the output, all ovl/mgr settings should be allowed. And we We have 2 ways to go about this, one is to have an initial set of 'always valid' values like I have done, the other option is to ignore manager timing related checks if the manager is disabled, i.e all configs are okay. To implement the second option, I think our function dss_check_settings_low() would get more complicated. We would now have to pass mp-enabled outside of apply, and pass it to dss_mgr_check() which would further need to pass this to dss_ovl_check(). Hence I used the first approach. I'm not sure about that. We already do it for overlay. In ovl.c we have dss_ovl_simple_check() and dss_ovl_check(). The simple check sees if the settings pass basic sanity check. The check sees if all the ovl mgr settings are compatible with each other. Simple check is done when setting the config, called from dss_ovl_set_info(). The proper check is done later when the actual config is about to be taken into use. If mp-enabled == false, can't we just skip dss_check_settings_low() totally for that manager? We skip the check for ovls the same way. Okay, this would work better I guess. If someone tries to enable the manager without setting the timings, that check should fail, and in my approach, it would have passed, and would have led to bad stuff later. One change in behaviour with the patch series I see is with the following use case when connected to Pandaboad's DVI interface: - Bootup with 1080p resolution - Try to set 640x480 timings with sysfs. The older behaviour was that the timings were taken, and a skewed image was seen(because the overlay size is larger in deimension) The behaviour after this series is that the mgr_set_timings fails with the error: omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1920 = 640) I guess this is better in a way, a user of DSS is supposed to reallocate the framebuffer with the desired size and then change the timings. Yes, I think it's better. I think it's undefined what happens if the overlay is larger than the output. In theory the DSS HW could lock-up, or something. So we have to prevent it. omapdss could change the size of the overlay automatically, but I dislike things like that. Low level drivers adjusting the configuration from the user almost always brings problems. So yes, I also think that the user of DSS is supposed to handle it correctly. But with DVI, the problem is that dpi_set_timings already does a ton of stuff before dss_mgr_set_timings() is called, so we change the dividers to get the new clock, and then realise that the overlay can't fit inside, and we are left nowhere. I guess this is a separate problem and we could tackle it later. Ah, ok. Yes, I guess we need to roll back the settings in that case. Or, I wonder, would a check function work, that would take the new timings and check those but also check if they match the overlays. Hmm, no, that doesn't solve it totally, as the overlay could be changed after the check. Again a problem with dss locking, we can't do the operation atomically... Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH] ARM: OMAP2+: irq: Increase no of supported interrupts to 128
On Wed, May 09, 2012 at 00:09:34, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: With addition to TI81XX, AM33XX family of devices, the number of interrupts supported has increased to 128, compared to 96. The current implementation for irq handling is hardcoded to use 96 interrupts (with 3 register-sets to handle), this patch cleanups the code, to increase maximum number of interrupts support to 128, with dynamic detection of no of registers required for handling all interrupts. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Ideally, we should use dynamic allocation to allocate memory for registers/arrays, Yes. Thanks Kevin, I will put this activity in my TODO list. may be too much cleanup for this patch, There is no such thing as too much cleanup. ;) And the INTC is in need of it, IMO. Indeed it is in need of cleanup... so as of now restricting to minimal changes to fit devices like, am33xx/ti81xx. Then someone else will have to do the cleanup later. It would be greatly appreciated if you could do the necessary cleanup in order to cleanly add support for more SoCs. Yes, we probably should've insisted when support for TI81xx was added, but that one slipped in under the radar. Yeah, I understand. As I said I will put this activity in my TODO list. For starters, the notion of a banks this code is a rather messed up and needs a cleanup. A bank is supposed to be a group of 32 interrupts, and the INTC is made up of 3 (or 4) banks. However, the current code creates a single bank of 96 (or 128) interrupts. It also confuses what registers are part of the bank and what are global to the INTC. This confusion is both in init and in context save/restore. IMO, to clean this up, first the notion of banks needs to be fixed in that code there is a distinction between what acts on banks and what works on the whole INTC. Then, the init/alloc should be done dynamically based on the number of interrupts passed to omap_init_irq() Kevin, Let me finish up with am33xx baseport upstream activity which is currently going on at full swing, then next thing I will pick up is this code cleanup. I still feel, this is still a valid cleanup patch, and can be merged, as it is required/used when we do major cleanup. 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: decompressor: Fix mmu mapping for non-DRAM address space.
On Wed, May 09, 2012 at 09:50:28AM +0100, Shilimkar, Santosh wrote: On Wed, May 9, 2012 at 3:25 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, May 08, 2012 at 07:31:57PM +0530, Shilimkar, Santosh wrote: Ok. Assuming you mean it's _not_ cleaner to have two domains where manager overrides XN attributes Note that DRAM can be in the middle of 4GB address space, so we need to take care of bottom and top address space. Update patch end of the email. Is that fine with you ? This is certainly not cleaner because this will break non-ARMv7. The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code. So it should work as long as XN bit supported or that bit position is not used. I checked ARMv6(OMAP2) and that seems to be fine. Can you please help me to understand which ARM version will be broken because of this change and how ? I only have access to ARMv6 and ARMv7 specs. It's probably ARMv5 and earlier that didn't have an XN bit (introduced with ARMv6). I have an old ARM ARM on my desk and it looks like bit 4 is XN on ARMv6+ and Implementation Defined on ARMv5 and earlier. It looks like we set it all the time in the current decompressor. Looking at the arch/arm/mm/mmu.c file, there is this PMD_BIT4 which is always set on ARMv5 and earlier except Xscale and XSC3 (see the comment in build_mem_type_table). -- Catalin -- To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state
From: Jean Pihet j-pi...@ti.com
One of the main contributors of the low power code latency is
the PER power domain. To optimize the high-performance and
low-latency C1 state, prevent any PER state which is lower
than the CORE state in C1.
Reported and suggested by Kevin Hilman.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 38 +++-
1 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 5358664..353dd8d 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -247,19 +247,18 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
int index)
{
int new_state_idx;
- u32 core_next_state, per_next_state = 0, per_saved_state = 0, cam_state;
+ u32 core_next_state, per_next_state = 0, per_saved_state = 0;
struct omap3_idle_statedata *cx;
int ret;
/*
-* Prevent idle completely if CAM is active.
+* Use only C1 if CAM is active.
* CAM does not have wakeup capability in OMAP3.
*/
- cam_state = pwrdm_read_pwrst(cam_pd);
- if (cam_state == PWRDM_POWER_ON) {
+ if (pwrdm_read_pwrst(cam_pd) == PWRDM_POWER_ON)
new_state_idx = drv-safe_state_index;
- goto select_state;
- }
+ else
+ new_state_idx = next_valid_state(dev, drv, index);
/*
* FIXME: we currently manage device-specific idle states
@@ -269,24 +268,28 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
*its own code.
*/
- /*
-* Prevent PER off if CORE is not in retention or off as this
-* would disable PER wakeups completely.
-*/
- cx = cpuidle_get_statedata(dev-states_usage[index]);
+ /* 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_pwrst(per_pd);
- if ((per_next_state == PWRDM_POWER_OFF)
- (core_next_state PWRDM_POWER_RET))
- per_next_state = PWRDM_POWER_RET;
+ if (new_state_idx == 0) {
+ /* In C1 do not allow PER state lower than CORE state */
+ if (per_next_state core_next_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.
+*/
+ if ((per_next_state == PWRDM_POWER_OFF)
+ (core_next_state PWRDM_POWER_RET))
+ per_next_state = PWRDM_POWER_RET;
+ }
/* Are we changing PER target state? */
if (per_next_state != per_saved_state)
pwrdm_set_next_pwrst(per_pd, per_next_state);
- new_state_idx = next_valid_state(dev, drv, index);
-
-select_state:
ret = omap3_enter_idle(dev, drv, new_state_idx);
/* Restore original PER state if it was modified */
@@ -372,7 +375,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 */
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
From: Jean Pihet j-pi...@ti.com
It is not needed to iterate through all the clock domains of a
power domain in order to allow or deny it to idle.
This patch allows or denies only the first registered clock domain
of a power domain, and so optimizes the latency of the low power
code. The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 353dd8d..d44b68a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -73,20 +73,6 @@ struct omap3_idle_statedata
omap3_idle_data[OMAP3_NUM_STATES];
struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
-static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_allow_idle(clkdm);
- return 0;
-}
-
-static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_deny_idle(clkdm);
- return 0;
-}
-
static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -105,8 +91,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Deny idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_deny_idle(core_pd-pwrdm_clkdms[0]);
}
/*
@@ -128,8 +114,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Re-allow idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ clkdm_allow_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_allow_idle(core_pd-pwrdm_clkdms[0]);
}
return_sleep_time:
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe 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
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
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.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable hwsup
imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}
So if we want to allow that, some code change are needed in order to set the
clkdm mode to
Re: PM related performance degradation on OMAP3
Hi Kevin,
On Mon, May 7, 2012 at 7:31 PM, Kevin Hilman khil...@ti.com wrote:
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.
I just sent 2 patches which optimize the C1 state latency:
. [PATCH 1/2] ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state
. [PATCH 2/2] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle
latency in C1 state
Note: those patches apply on top of your pre/post_transition
optimization patches.
The performance results are close to the !PM case (No IDLE, no
omap_sram_idle, all pwrdms to ON), i.e. 3.1MB/s on Beagleboard.
The wiki page update comes asap.
Regards,
Jean
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
Re: [PATCH 1/1] omap3: Provide means for changing CSI2 PHY configuration
Hi Sakari,
Thanks for the patch.
On Wednesday 09 May 2012 08:00:41 Sakari Ailus wrote:
The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to
the actual CSI-2 receivers outside the ISP itself. Allow changing this
configuration from the ISP driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Hi,
This patch does what was discussed some time ago: provide a bit more high
level interface than the registers for the ISP driver to change the CSI-2
PHY mappings.
omap_writel()/omap_readl() functions are no longer there so this works as a
convenient push to write a patch such as this. ;-)
arch/arm/mach-omap2/control.c | 32 +
arch/arm/mach-omap2/include/mach/control.h | 11 +
2 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/control.h
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 08e674b..78c27b2 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -12,9 +12,12 @@
*/
#undef DEBUG
+#include linux/export.h
#include linux/kernel.h
#include linux/io.h
+#include mach/control.h
+
#include plat/hardware.h
#include plat/sdrc.h
@@ -564,4 +567,33 @@ int omap3_ctrl_save_padconf(void)
return 0;
}
+void omap3_ctrl_csi2_select(u32 csi2cfg)
+{
+ /* FIXME: Do 34xx / 35xx require something here? */
Well, maybe it's time to find out whether it does ?
+ if (cpu_is_omap3630()) {
I would test !cpu_is_omap3630() and return, that would lower the indentation
level.
+ u32 cam_phy_ctrl =
+ omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+
+ /*
+ * SCM.CONTROL_CAMERA_PHY_CTRL
+ * - bit[4]: CSIPHY1 data sent to CSIB
+ * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
+ * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
+ */
+ if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY1_CCP2B)
+ cam_phy_ctrl |= 1 2;
+ else if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY1_CSI2C)
+ cam_phy_ctrl = ~(1 2);
+
+ if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY2_CCP2B)
+ cam_phy_ctrl |= 1;
+ else if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY2_CSI2A)
+ cam_phy_ctrl = ~1;
+
+ omap_ctrl_writel(cam_phy_ctrl,
+ OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+ }
+}
+EXPORT_SYMBOL_GPL(omap3_ctrl_csi2_select);
+
#endif /* CONFIG_ARCH_OMAP3 CONFIG_PM */
diff --git a/arch/arm/mach-omap2/include/mach/control.h
b/arch/arm/mach-omap2/include/mach/control.h new file mode 100644
index 000..4490b7a
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/control.h
@@ -0,0 +1,11 @@
+#ifndef __MACH_CONTROL_H__
+#define __MACH_CONTROL_H__
+
+#define OMAP3_CTRL_CSI2_SELECT_PHY1_CCP2B (1 0)
+#define OMAP3_CTRL_CSI2_SELECT_PHY1_CSI2C (1 1)
+#define OMAP3_CTRL_CSI2_SELECT_PHY2_CCP2B (1 2)
+#define OMAP3_CTRL_CSI2_SELECT_PHY2_CSI2A (1 3)
As you only test for equality, does a bitmask really make sense ?
+void omap3_ctrl_csi2_select(u32 csi2cfg);
+
+#endif /* __MACH_CONTROL_H__ */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v3.4-rc6
Hi Olof, On Tuesday 08 May 2012 23:48:06 Olof Johansson wrote: Hi, On Mon, May 7, 2012 at 3:36 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: [..] Enrico Butera (1): ARM: OMAP: igep0020: fix smsc911x dummy regulator id Hmm. Picking 40 without any kind of comment in the code isn't doing any favors for future readers. Seems like 1 would be free on this board, from the rest of the board file to judge (one other reg-fixed-regulator platform device)? Please either comment why you picked 40 (i.e. it's a random number), or change it to something a little less random like 1. :) Laurent Pinchart (1): ARM: OMAP: igep0020: Specify the VPLL2 regulator unconditionally Is this a regression? I don't see any recent changes regarding this, so it's hard to tell. If not then I'd rather hold off for the merge window given that we're at -rc6. It's not a regression, I'm fine with holding off until the v3.5 merge window. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote: An overlay manager's timings (the manager size, and blanking parameters if an LCD manager) are DISPC shadow registers, and they should hence follow the correct programming model. This set makes the timings an extra_info parameter in manager's private data . The interface drivers now apply the timings in instead of directly writing to registers. This change also prevents the need to use display resolution for overlay checks, hence making some of the APPLY functions less dependent on the display. Some DISPC functions that needed display width can also use these privately stored timings. Changes since v3: - Remove direct setting of go bit in dpi_set_timings() - Take some of the patches in OMAPDSS: Misc fixes and cleanups and make them a part of this series as they are more related. - Don't have an initial set of manager timings in private data, only check manager and overlay parameters once the manager is enabled. These patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Reference tree containing this series: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2 Tested on OMAP4 SDP and Panda. I did some quick tests on omap3 overo, worked fine. I'll merge to dss master branch. Tomi signature.asc Description: This is a digitally signed message part
[PATCH-V2] ARM: OMAP2+: am33xx: Make am33xx as a separate class
Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). So, after long discussion we have came to the conclusion that, we should not consider am33xx device as omap3 family, instead create separate class (SOC_OMAPAM33XX) under OMAP2PLUS. This means, for am33xx device, cpu_is_omap34xx() will return false, and only cpu_is_am33xx() will be true. Please refer to the link below, for mailing-list discussion on this - http://www.spinics.net/lists/linux-omap/msg69439.html Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com --- NOTE: Boot tested it on OMAP3EVM platform. Changes from V1: - This patch has been rebased against linux-omap/cleanup branch. - Rebased on top of KevinH's patch series - [PATCH 0/3] ARM: OMAP2+: Kconfig: minor cleanup for SOC names [PATCH 1/3] ARM: OMAP2+: INTC: fix Kconfig option for TI81XX [PATCH 2/3] ARM: OMAP2+: Kconfig: convert SOC_OMAPTI81XX to SOC_TI81XX [PATCH 3/3] ARM: OMAP2+: Kconfig: convert SOC_OMAPAM33XX to SOC_AM33XX - Removed stale condition (dependes on ARCH_OMAP2PLUS) in Kconfig for SOC_AM33XX. arch/arm/mach-omap2/Kconfig |4 +++- arch/arm/mach-omap2/Makefile |6 ++ arch/arm/mach-omap2/common.c |2 ++ arch/arm/plat-omap/include/plat/cpu.h |9 ++--- arch/arm/plat-omap/sram.c |2 +- 5 files changed, 18 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 61bf3c3..7a77bb6 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -84,8 +84,10 @@ config SOC_TI81XX config SOC_AM33XX bool AM33XX support - depends on ARCH_OMAP3 default y + select CPU_V7 + select ARM_CPU_SUSPEND if PM + select MULTI_IRQ_HANDLER config OMAP_PACKAGE_ZAF bool diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index a5b8db3..25370fd 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -16,6 +16,7 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -90,6 +91,7 @@ obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o +obj-$(CONFIG_SOC_AM33XX) += prcm.o # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -99,6 +101,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common) # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o @@ -113,6 +116,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= powerdomains2xxx_3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) obj-$(CONFIG_ARCH_OMAP4) += powerdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) # PRCM clockdomain control clockdomain-common += clockdomain.o @@ -127,6 +131,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= clockdomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common) obj-$(CONFIG_ARCH_OMAP4) += clockdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o @@ -144,6 +149,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= dpll3xxx.o clock3xxx_data.o obj-$(CONFIG_ARCH_OMAP3) += clkt_iclk.o obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o # OMAP2 clock
Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
On Wednesday 09 May 2012 04:43 PM, Tomi Valkeinen wrote: On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote: An overlay manager's timings (the manager size, and blanking parameters if an LCD manager) are DISPC shadow registers, and they should hence follow the correct programming model. This set makes the timings an extra_info parameter in manager's private data . The interface drivers now apply the timings in instead of directly writing to registers. This change also prevents the need to use display resolution for overlay checks, hence making some of the APPLY functions less dependent on the display. Some DISPC functions that needed display width can also use these privately stored timings. Changes since v3: - Remove direct setting of go bit in dpi_set_timings() - Take some of the patches in OMAPDSS: Misc fixes and cleanups and make them a part of this series as they are more related. - Don't have an initial set of manager timings in private data, only check manager and overlay parameters once the manager is enabled. These patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Reference tree containing this series: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2 Tested on OMAP4 SDP and Panda. I did some quick tests on omap3 overo, worked fine. I'll merge to dss master branch. Russ did some tests on more omap3 boards, the tree which he used has some slight changes comapred to what I have posted, but it's more or less the same. Could you add 'Tested-by: russ.d...@ti.com' if not too difficult, I missed out doing that. Thanks, 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
Re: smsc911x on Gumstix Overo/Tobi doesn't work
Am 03.05.2012 13:09, schrieb Javier Martinez Canillas: On Wed, May 2, 2012 at 1:42 PM, Thomas Klute thomas2.kl...@uni-dortmund.de wrote: Am 01.04.2012 21:20, schrieb Javier Martinez Canillas: On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute thomas2.kl...@uni-dortmund.de wrote: Hi, I finally had some time to do more tests on this problem. Findings below. Great, I guess we are close to find the issue :) Am 20.03.2012 20:47, schrieb Javier Martinez Canillas: On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute thomas2.kl...@uni-dortmund.de wrote: Am 19.03.2012 23:51, schrieb Tony Lindgren: * Thomas Klute thomas2.kl...@uni-dortmund.de [120319 09:26]: Am 16.03.2012 20:33, schrieb Tony Lindgren: Hi, * Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]: Hi, I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows: du14:~# modprobe smsc911x [ 254.843811] smsc911x: Driver version 2008-10-21 [ 254.854553] smsc911x: Driver version 2008-10-21 [ 254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using dummy regulator [ 254.868377] _regulator_get: smsc911x.1 supply vddvario not found, using dummy regulator ip link show does not show any available Ethernet port. The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3. The Tobi board has only one Ethernet port. I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case. The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed. Care to test the following patch by passing a fixed regulator from board-overo.c? After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you! Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted? You're right, during further tests I found that the problem lies elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after # modprobe -r smsc911x [attach cable] # modprobe smsc911x it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem. Hi Thomas, I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode. The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful. I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset. The commit is: commit 6386994e03ebbe60338ded3d586308a41e81c0dc Author: Javier Martinez Canillas jav...@dowhile0.org Date: Tue Jan 3 13:36:19 2012 + net/smsc911x: Check if PHY is in operational mode before software reset When I fix the issue I only guarded against generation 4 chips (i.e: pdata-generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets). Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode. After looking at the code I set USE_DEBUG to 3 to get as much information as possible and tested with and without the SMSC PHY driver. Results: With the Ethernet cable attached, the device is properly initialized with and without the PHY driver (as before). Without the cable, the smsc911x driver can initialize the card only if the smsc PHY driver had not been loaded previously. Unloading the PHY driver is not enough, even a reboot doesn't help. I have to do a cold boot (or attach the cable). This makes sense
Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
On Wed, 2012-05-09 at 16:54 +0530, Archit Taneja wrote: On Wednesday 09 May 2012 04:43 PM, Tomi Valkeinen wrote: On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote: An overlay manager's timings (the manager size, and blanking parameters if an LCD manager) are DISPC shadow registers, and they should hence follow the correct programming model. This set makes the timings an extra_info parameter in manager's private data . The interface drivers now apply the timings in instead of directly writing to registers. This change also prevents the need to use display resolution for overlay checks, hence making some of the APPLY functions less dependent on the display. Some DISPC functions that needed display width can also use these privately stored timings. Changes since v3: - Remove direct setting of go bit in dpi_set_timings() - Take some of the patches in OMAPDSS: Misc fixes and cleanups and make them a part of this series as they are more related. - Don't have an initial set of manager timings in private data, only check manager and overlay parameters once the manager is enabled. These patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Reference tree containing this series: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2 Tested on OMAP4 SDP and Panda. I did some quick tests on omap3 overo, worked fine. I'll merge to dss master branch. Russ did some tests on more omap3 boards, the tree which he used has some slight changes comapred to what I have posted, but it's more or less the same. Could you add 'Tested-by: russ.d...@ti.com' if not too difficult, I missed out doing that. Sorry, I could, but I already merged and pushed the series, so I can't change it anymore. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote: The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code. Yes, XN is an ARMv6+ thing. Before ARMv5, it was implementation defined. Some implementations used the bit to mean allow writes to update the cache. Other implementations labelled this bit as should be zero while others labelled it as should be one. The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react. The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value. I'll sort out a patch later today for this. -- To unsubscribe from this list: send the line unsubscribe 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: [RFC 00/12] OMAP DMA engine conversion
On Mon, Apr 23, 2012 at 9:34 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: For the full text, please see http://lists.arm.linux.org.uk/lurker/message/20120418.100954.7fa7acf8.en.html This version contains updates for some of the comments received from the previous round, and adds the OMAP1/2 MMC and SPI drivers to the conversion. Tested eMMC, SD on omap4 Blaze Tested-by: Balaji T K balaj...@ti.com I've also added a note to feature-removal noting that the existing APIs will be removed around 2013 - I'm planning January for that at the moment. Having drivers around which are unconverted blocks further work on the DMA engine conversion, so it's actually important that we get as many drivers converted as soon as possible. Anything which isn't converted will probably have its DMA code removed, or if that results in the driver not being usable, the driver itself will be removed. This series is still in RFC mode... Documentation/feature-removal-schedule.txt | 11 + arch/arm/mach-omap1/board-h2-mmc.c | 1 - arch/arm/mach-omap1/board-h3-mmc.c | 1 - arch/arm/mach-omap1/board-nokia770.c | 1 - arch/arm/mach-omap2/board-n8x0.c | 1 - arch/arm/mach-omap2/hsmmc.c | 1 - arch/arm/plat-omap/dma.c | 14 + arch/arm/plat-omap/include/plat/mmc.h | 2 - drivers/dma/Kconfig | 10 + drivers/dma/Makefile | 2 + drivers/dma/omap-dma.c | 521 drivers/dma/sa11x0-dma.c | 249 - drivers/dma/virt-dma.c | 99 ++ drivers/dma/virt-dma.h | 138 drivers/mmc/host/omap.c | 369 +--- drivers/mmc/host/omap_hsmmc.c | 206 ++-- drivers/spi/spi-omap2-mcspi.c | 228 +++-- 17 files changed, 1268 insertions(+), 586 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Tuesday 08 May 2012, Jassi Brar wrote: On 8 May 2012 22:05, Stephen Warren swar...@wwwdotorg.org wrote: The data doesn't need to be part of the DMA controller node in order for the DMA controller driver to be the entity interpreting it. I rather say, if the dma controller driver is the entity going to interpret the data, why not provide the data directly through its node at one go? There is important difference between providing data via clients during runtime vs providing info about every client to the dmac driver at one go during its probe. IMHO the important aspect is what that data contains. The dma engine device node should only describe what that device looks like in hardware, but not how it is being used. If you have two machines that have the same dma engine, but different devices attached to it, the only difference in the device tree ought to be in those devices, not in the parts that are common. 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, I don't think there's any need for it to fit into a fixed number of bytes Yeah, I realized that soon after posting. I think I have run out of ways to explain myself better. FWIW, I won't object to whatever mechanism folks decide after knowing my concerns. I think we should try hard to make it possible to describe your hardware correctly, but we don't need to optimize the syntax for that case if that means making the common case more complex. I'd rather make the common case simple and the exception possible using some extension. 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
[PATCH] spi/omap: cleanup probe/remove routines
Cleanup probe and remove routines, use devm_* functions for
managing resources.
Also, in under free_master label, change use of kfree() into
spi_master_put().
CC: grant.lik...@secretlab.ca
CC: t...@atomide.com
Signed-off-by: Hannu Heikkinen hann...@iki.fi
---
drivers/spi/spi-omap2-mcspi.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bb9274c..392efce 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1166,17 +1166,12 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
r-start += regs_offset;
r-end += regs_offset;
mcspi-phys = r-start;
- if (!request_mem_region(r-start, resource_size(r),
- dev_name(pdev-dev))) {
- status = -EBUSY;
- goto free_master;
- }
- mcspi-base = ioremap(r-start, resource_size(r));
+ mcspi-base = devm_request_and_ioremap(pdev-dev, r);
if (!mcspi-base) {
- dev_dbg(pdev-dev, can't ioremap MCSPI\n);
- status = -ENOMEM;
- goto release_region;
+ dev_dbg(pdev-dev, can't request mem and ioremap MCSPI\n);
+ status = -ENOMEM;
+ goto free_master;
}
mcspi-dev = pdev-dev;
@@ -1191,7 +1186,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
GFP_KERNEL);
if (mcspi-dma_channels == NULL)
- goto unmap_io;
+ goto free_master;
for (i = 0; i master-num_chipselect; i++) {
char dma_ch_name[14];
@@ -1241,12 +1236,8 @@ disable_pm:
pm_runtime_disable(pdev-dev);
dma_chnl_free:
kfree(mcspi-dma_channels);
-unmap_io:
- iounmap(mcspi-base);
-release_region:
- release_mem_region(r-start, resource_size(r));
free_master:
- kfree(master);
+ spi_master_put(master);
platform_set_drvdata(pdev, NULL);
return status;
}
@@ -1256,8 +1247,6 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
struct spi_master *master;
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *dma_channels;
- struct resource *r;
- void __iomem *base;
master = dev_get_drvdata(pdev-dev);
mcspi = spi_master_get_devdata(master);
@@ -1265,12 +1254,8 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
omap2_mcspi_disable_clocks(mcspi);
pm_runtime_disable(pdev-dev);
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(r-start, resource_size(r));
- base = mcspi-base;
spi_unregister_master(master);
- iounmap(base);
kfree(dma_channels);
destroy_workqueue(mcspi-wq);
platform_set_drvdata(pdev, NULL);
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe 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: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
On Wed, May 9, 2012 at 1:16 AM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120427 02:33]: On Wed, Apr 25, 2012 at 9:59 AM, Enric Balletbò i Serra eballe...@gmail.com wrote: Tony, as this is a fix ,may be included ? Acked-by: Enric Balletbo i Serra eballe...@gmail.com Tested-by: Enric Balletbo i Serra eballe...@gmail.com Cheers, Enric Hi Tony, Russel: This patch is a requirement for patch: [RESEND PATCH 2/2] OMAP3: igep0020: Add support for Micron NAND Flash storage memory which is really important since newer IGEPv2 boards have changed their flash memory from OneNAND to NAND. This patch-set is necessary to make the board work, otherwise it doesn't even boot. Could we please include these patches? Thanks for the patience, applying now into board branch finally. Regards, Tony -- Hi Tony, Thanks a lot for applying these patches. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe 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/1] omap3: Provide means for changing CSI2 PHY configuration
Hi Laurent,
Thanks for the review!
On Wed, May 09, 2012 at 01:01:34PM +0200, Laurent Pinchart wrote:
Hi Sakari,
Thanks for the patch.
On Wednesday 09 May 2012 08:00:41 Sakari Ailus wrote:
The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to
the actual CSI-2 receivers outside the ISP itself. Allow changing this
configuration from the ISP driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Hi,
This patch does what was discussed some time ago: provide a bit more high
level interface than the registers for the ISP driver to change the CSI-2
PHY mappings.
omap_writel()/omap_readl() functions are no longer there so this works as a
convenient push to write a patch such as this. ;-)
arch/arm/mach-omap2/control.c | 32 +
arch/arm/mach-omap2/include/mach/control.h | 11 +
2 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/control.h
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 08e674b..78c27b2 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -12,9 +12,12 @@
*/
#undef DEBUG
+#include linux/export.h
#include linux/kernel.h
#include linux/io.h
+#include mach/control.h
+
#include plat/hardware.h
#include plat/sdrc.h
@@ -564,4 +567,33 @@ int omap3_ctrl_save_padconf(void)
return 0;
}
+void omap3_ctrl_csi2_select(u32 csi2cfg)
+{
+ /* FIXME: Do 34xx / 35xx require something here? */
Well, maybe it's time to find out whether it does ?
I'm not aware of anyone having a sensor with CSI-2 bus connected to a 3430;
that's why this hasn't been found out. If we add the support we're at least
going to be unable to test it. For that reason I was going to leave this
as-is. What do you think?
+ if (cpu_is_omap3630()) {
I would test !cpu_is_omap3630() and return, that would lower the indentation
level.
Now, yes. I'll do that if you agree with me on the previous question since
otherwise this won't work too well. :)
+ u32 cam_phy_ctrl =
+ omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+
+ /*
+* SCM.CONTROL_CAMERA_PHY_CTRL
+* - bit[4]: CSIPHY1 data sent to CSIB
+* - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
+* - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
+*/
+ if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY1_CCP2B)
+ cam_phy_ctrl |= 1 2;
+ else if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY1_CSI2C)
+ cam_phy_ctrl = ~(1 2);
+
+ if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY2_CCP2B)
+ cam_phy_ctrl |= 1;
+ else if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY2_CSI2A)
+ cam_phy_ctrl = ~1;
+
+ omap_ctrl_writel(cam_phy_ctrl,
+OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+ }
+}
+EXPORT_SYMBOL_GPL(omap3_ctrl_csi2_select);
+
#endif /* CONFIG_ARCH_OMAP3 CONFIG_PM */
diff --git a/arch/arm/mach-omap2/include/mach/control.h
b/arch/arm/mach-omap2/include/mach/control.h new file mode 100644
index 000..4490b7a
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/control.h
@@ -0,0 +1,11 @@
+#ifndef __MACH_CONTROL_H__
+#define __MACH_CONTROL_H__
+
+#define OMAP3_CTRL_CSI2_SELECT_PHY1_CCP2B (1 0)
+#define OMAP3_CTRL_CSI2_SELECT_PHY1_CSI2C (1 1)
+#define OMAP3_CTRL_CSI2_SELECT_PHY2_CCP2B (1 2)
+#define OMAP3_CTRL_CSI2_SELECT_PHY2_CSI2A (1 3)
As you only test for equality, does a bitmask really make sense ?
No. I'll change that.
Cheers,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe 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
On Wednesday 09 May 2012, Dave Chinner wrote: 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. And thereby stalling what might be writes critical to operation. Indeed, how does this affect the system when it starts swapping heavily? If you keep stalling writes, the system won't be able to swap and free memory... The point here is that reads have a consistent latency, e.g. 500 microseconds for a small access, while writes have a latency that can easily become 1000x the read latency (e.g. 500 ms of blocking the device) depending on the state of the device. Most of the time, writes are fast as well, but sometimes (when garbage collection happens in the device), they are extremely slow and block everything else. This is the only time we ever want to interrupt a write: keeping the system running interactively while eventually getting to do the writeback. There is a small penalty for interrupting the garbage collection, but the device should be able to pick up its work at the point where we interrupt it, so we can still make forward progress. 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. The problem is that the attribute you are setting covers every single data read that is done by all users. If that's what you want to have happen, then why do you even need a new flag at this layer? Just treat every non-REQ_META read request as a demand paged IO and you've got exactly the same behaviour without needing to tag at the higher layer My feeling is that we should just treat every (REQ_SYNC | REQ_READ) request the same and let them interrupt long-running writes, independent of whether it's REQ_META or demand paging. 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 v2 14/16] mmc: block: Implement HPI invocation and handling logic.
On Wednesday 09 May 2012, kdorf...@codeaurora.org wrote:
+static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
+ struct request *req, unsigned int thpi)
+{
+
+ /*
+ * If some time has elapsed since the issuing of previous write
+ * command, or if the size of the request was too small, there's
+ * no point in preempting it. Check if it's worthwhile to preempt
+ */
+ int time_elapsed = jiffies_to_msecs(jiffies -
+ mq-mqrq_cur-mmc_active.mrq-cmd-started_time);
+
+ if (time_elapsed = thpi)
+ return true;
Some host controllers (or DMA) has possibility to get the byte count of
current transaction. It may be implemented as host api (similar to abort
ops). Then you have more accurate estimation of worthiness.
I'm rather sure that the byte count is not relevant here: it's not
the actual write that is taking so long, it's the garbage collection
that the device does internally before the write actually gets done.
The data transfer is much faster than the time we are waiting for here.
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 v2 14/16] mmc: block: Implement HPI invocation and handling logic.
On Wed, May 9, 2012 at 2:05 PM, kdorf...@codeaurora.org wrote:
+static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
+ struct request *req, unsigned int thpi)
+{
+
+ /*
+ * If some time has elapsed since the issuing of previous write
+ * command, or if the size of the request was too small, there's
+ * no point in preempting it. Check if it's worthwhile to preempt
+ */
+ int time_elapsed = jiffies_to_msecs(jiffies -
+ mq-mqrq_cur-mmc_active.mrq-cmd-started_time);
+
+ if (time_elapsed = thpi)
+ return true;
Some host controllers (or DMA) has possibility to get the byte count of
current transaction. It may be implemented as host api (similar to abort
ops). Then you have more accurate estimation of worthiness.
Byte count returned by DMA or the HC doesn't mean that the data has
actually been
burnt into the device (due to internal buffering). This is one of the
reasons for
defining the CORRECTLY_PRG_SECTORS_NUM register in the standard which
can be queried to find how much was correctly written.
Unfortunately it can only be queried after the abort has been issued.
+
+ return false;
+}
Thanks, Kostya
--
To unsubscribe from this list: send the line unsubscribe 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/1] omap3: Provide means for changing CSI2 PHY configuration
Hi Sakari,
On Wednesday 09 May 2012 16:43:08 Sakari Ailus wrote:
On Wed, May 09, 2012 at 01:01:34PM +0200, Laurent Pinchart wrote:
On Wednesday 09 May 2012 08:00:41 Sakari Ailus wrote:
The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected
to the actual CSI-2 receivers outside the ISP itself. Allow changing
this configuration from the ISP driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Hi,
This patch does what was discussed some time ago: provide a bit more
high level interface than the registers for the ISP driver to change the
CSI-2 PHY mappings.
omap_writel()/omap_readl() functions are no longer there so this works
as a convenient push to write a patch such as this. ;-)
arch/arm/mach-omap2/control.c | 32 +
arch/arm/mach-omap2/include/mach/control.h | 11 +
2 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/control.h
[snip]
+void omap3_ctrl_csi2_select(u32 csi2cfg)
+{
+ /* FIXME: Do 34xx / 35xx require something here? */
Well, maybe it's time to find out whether it does ?
I'm not aware of anyone having a sensor with CSI-2 bus connected to a 3430;
that's why this hasn't been found out. If we add the support we're at least
going to be unable to test it. For that reason I was going to leave this
as-is. What do you think?
I haven't seen any SCM register in the 3430 TRM related to CSI2 routing (most
probably because the SoC seems to have the CSI1/CCP2 receiver hardwired to the
CSIb block, and the CSI2 receiver hardwired to the CSIa block). If 34xx/35xx
need something here, I don't know what.
What the 3430 would need is a ccp2 configuration function to access the
CONTROL_CSIRXFE register.
+ if (cpu_is_omap3630()) {
I would test !cpu_is_omap3630() and return, that would lower the
indentation level.
Now, yes. I'll do that if you agree with me on the previous question since
otherwise this won't work too well. :)
+ u32 cam_phy_ctrl =
+ omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+
+ /*
+ * SCM.CONTROL_CAMERA_PHY_CTRL
+ * - bit[4]: CSIPHY1 data sent to CSIB
+ * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
+ * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
+ */
+ if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY1_CCP2B)
+ cam_phy_ctrl |= 1 2;
+ else if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY1_CSI2C)
+ cam_phy_ctrl = ~(1 2);
Looking a bit more at the TRM, don't we need to provide a way to select
between data/clock and data/strobe modes, and to select which PHY to connect
to the ISP CSIb receiver ?
+
+ if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY2_CCP2B)
+ cam_phy_ctrl |= 1;
+ else if (csi2cfg == OMAP3_CTRL_CSI2_SELECT_PHY2_CSI2A)
+ cam_phy_ctrl = ~1;
+
+ omap_ctrl_writel(cam_phy_ctrl,
+ OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+ }
+}
+EXPORT_SYMBOL_GPL(omap3_ctrl_csi2_select);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/16] FS: Added demand paging markers to filesystem
On Wed, May 09, 2012 at 01:59:40PM +, Arnd Bergmann wrote: My feeling is that we should just treat every (REQ_SYNC | REQ_READ) request the same and let them interrupt long-running writes, independent of whether it's REQ_META or demand paging. It's funny that the CFQ scheduler used to boost metadata reads that have REQ_META set - in fact it still does for those filesystems using the now split out REQ_PRIO. -- To unsubscribe from this list: send the line unsubscribe 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] omap fixes for v3.4-rc6
* Laurent Pinchart laurent.pinch...@ideasonboard.com [120509 04:09]: Hi Olof, On Tuesday 08 May 2012 23:48:06 Olof Johansson wrote: Hi, On Mon, May 7, 2012 at 3:36 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: [..] Enrico Butera (1): ARM: OMAP: igep0020: fix smsc911x dummy regulator id Hmm. Picking 40 without any kind of comment in the code isn't doing any favors for future readers. Seems like 1 would be free on this board, from the rest of the board file to judge (one other reg-fixed-regulator platform device)? Please either comment why you picked 40 (i.e. it's a random number), or change it to something a little less random like 1. :) I'll use the update patch from Enrico. Laurent Pinchart (1): ARM: OMAP: igep0020: Specify the VPLL2 regulator unconditionally Is this a regression? I don't see any recent changes regarding this, so it's hard to tell. If not then I'd rather hold off for the merge window given that we're at -rc6. It's not a regression, I'm fine with holding off until the v3.5 merge window. And will move this one into fixes-non-critical. Will send a new pull request 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] OMAP: igep0020: fix smsc911x dummy regulator id
* Enrico Butera ebut...@users.sourceforge.net [120509 02:32]:
From: Enrico Butera ebut...@users.berlios.de
id 0 is already used and causes errors at boot:
WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0x9c/0xac()
sysfs: cannot create duplicate filename
'/devices/platform/reg-fixed-voltage.0'
Fix it by using the next available one (id=1).
Thanks adding into fixes with updated comments for the regression,
updated patch below.
Tony
From: Enrico Butera ebut...@users.berlios.de
Date: Wed, 9 May 2012 11:27:59 +0200
Subject: [PATCH] ARM: OMAP: igep0020: fix smsc911x dummy regulator id
id 0 is already used and causes errors at boot:
WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0x9c/0xac()
sysfs: cannot create duplicate filename '/devices/platform/reg-fixed-voltage.0'
Fix it by using the next available one (id=1).
This was caused by 5b3689f4 (ARM: OMAP2+: smsc911x: Add fixed
board regulators) that did not account for some regulators
already being used.
Signed-off-by: Enrico Butera ebut...@users.berlios.de
[t...@atomide.com: updated comments for regression causing commit]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 930c0d3..740cee9 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -641,7 +641,7 @@ static struct regulator_consumer_supply dummy_supplies[] = {
static void __init igep_init(void)
{
- regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
+ regulator_register_fixed(1, dummy_supplies, ARRAY_SIZE(dummy_supplies));
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
/* Get IGEP2 hardware revision */
--
To unsubscribe from this list: send the line unsubscribe 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
On Mon, May 07, 2012 at 10:16:30PM +0530, S, Venkatraman wrote: [..] 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). Does this feature work with CFQ? As CFQ does not submit sync IO (for idling queues) while async IO is pending and vice a versa (cfq_may_dispatch()). Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omapfb-main.c: check result of simple_strtoul
Tomi,
In drivers/video/omap2/omapfb/omapfb-main.c:
static int omapfb_parse_vram_param(const char *param, int max_entries,
unsigned long *sizes, unsigned long *paddrs)
{
int fbnum;
unsigned long size;
unsigned long paddr = 0;
char *p, *start;
start = (char *)param;
while (1) {
p = start;
fbnum = simple_strtoul(p, p, 10);
- if (p == param)
+ if (p == start)
correct?
Hein
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
* Ivan Djelic ivan.dje...@parrot.com [120509 01:15]: On Wed, May 09, 2012 at 01:29:28AM +0100, Tony Lindgren wrote: * Ivan Djelic ivan.dje...@parrot.com [120426 05:23]: Hello, Here is version 3 of this patch after review from Tony Lindgren. This version adds a separate initialization function mostly to check CPU compatibility. This check cannot be done in gpmc_enable_hwecc_bch() (which is meant to be called from mtd function ecc.hwctl) because ecc.hwctl is not called before the first NAND read access, and it cannot return an error status. Thanks applying into devel-gpmc branch. OK thanks! I still have a question though: there are recent patches from Afzal Mohammed that seem to go into the opposite direction, that is giving back GPMC register access to the omap2 NAND driver. In particular, [PATCH v4 17/39] [1] commit message says: GPMC driver has been modified to fill NAND platform data with GPMC NAND register details. As these registers are accessible in NAND driver itself, configure NAND in GPMC by itself. This also includes ecc configuration. My original mtd driver patch indeed had ecc handling code inside the driver (not in arch/arm/mach-omap2/gpmc.c). So, my question is: which direction are we going to with respect to this OMAP GPMC/NAND code separation ? What Afzal is doing is where we're heading. However, I'm afraid that may not be quite ready for v3.5 merge window as it needs proper testing on quite a few platforms to avoid issues with various devices connected to GPMC. Note that I could prepare a new MTD patch with BCH ecc code included, allowing to drop the GPMC BCH ecc api. OK, let's do that then. I'll drop this patch and you can coordinate your patch with Afzal. Regards, Tony [1] http://lists.infradead.org/pipermail/linux-mtd/2012-May/041105.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, May 08, 2012 8:13 PM To: Ashwin Bihari Cc: linux-omap; Tomi Valkeinen Subject: Re: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits * Ashwin Bihari ashwin.bih...@logicpd.com [120507 12:41]: 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. Applying the 1/2 of this into board branch, but this probably needs to be coordinated with changes Tomi is doing. Regards, Tony Tony, I'll work with Tomi and modify the LCD support to align with what he is doing with DSS.. Thanks -- -- -- ~ Ashwin -- To unsubscribe from this list: send the line unsubscribe 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, take2
Hi Olof, Here's this one updated to drop the non-regression patch and to use updated version of Enrico's patch. The other two patches are the same. Regards, Tony 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-take-2 for you to fetch changes up to 1a21932edc10de0dfd843797427719e5da43355b: ARM: OMAP: igep0020: fix smsc911x dummy regulator id (2012-05-09 08:12:05 -0700) Fix two board spefific regressions and one regression caused by bad documentation 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 arch/arm/mach-omap1/ams-delta-fiq.c|2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- .../include/mach/ctrl_module_pad_core_44xx.h |8 3 files changed, 6 insertions(+), 6 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 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
Sent: Wednesday, May 09, 2012 3:16 AM
To: Ashwin Bihari
Cc: linux-omap; Tony Lindgren
Subject: Re: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
snip
+static int omap3logic_panel_enable_lcd(struct omap_dss_device
+*dssdev) {
+ gpio_set_value(LCD_PANEL_PWR, 1);
+ if (machine_is_omap3530_lv_som())
+ gpio_set_value(OMAP3530_LV_SOM_BACKLIGHT_PWR, 1);
+ else if (machine_is_omap3_torpedo()) {
+ gpio_set_value(OMAP3530_TORPEDO_BACKLIGHT_PWR, 1);
+
+ gpio_set_value(OMAP3530_TORPEDO_MDISP, 1);
+ }
+
+ return 0;
+}
+
+static int omap3logic_panel_disable_lcd(struct omap_dss_device
+*dssdev) {
+ gpio_set_value(LCD_PANEL_PWR, 0);
+ if (machine_is_omap3530_lv_som())
+ gpio_set_value(OMAP3530_LV_SOM_BACKLIGHT_PWR, 0);
+ else if (machine_is_omap3_torpedo()) {
+ gpio_set_value(OMAP3530_TORPEDO_BACKLIGHT_PWR, 0);
+
+ gpio_set_value(OMAP3530_TORPEDO_MDISP, 0);
+ }
+
+ return 0;
+}
This doesn't play well with device-tree. We can't do such callbacks when we
move to DT.
I know we have similar code for other boards, and this can't be properly fixed
right now, but I'm still a bit hesitant to add more such code because I'm the
one that has to clean it up later for DT =).
I can handle the LCD_PANEL_PWR gpio, but the backlight is something that
should be removed from the panel enable callbacks. You could look at
drivers/video/backlight/ and see if there's something there that could be
used for your board. Or implement a new BL driver, if nothing fits.
Tomi
Tomi,
Let me take a look at your linux-omap-dss2 tree and learn a bit more about DT
and figure out how to modify the LCD support so it better aligns with your work
and I'll re-submit that patch again..
Thanks
-- -- --
~ Ashwin
Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
* Tomi Valkeinen tomi.valkei...@ti.com [120509 01:12]:
Below is the pull request for board file related changes. Tested on
panda 4430sdp.
Thanks, I've merged that into clenaup-dss branch and will send it
along with other still pending cleanup branches.
How should I manage my tree related to this... Should I rebase my
original DT preparation series on top of this new branch, or can I just
ignore the new branch for now, as long as I merge it at some point
before sending a pull request to mainline?
Yes you need to rebase on this now. And not touch these commits.
Otherwise we'll end up with duplicate commits in the mainline tree,
which is a big no-no. If something shows up that needs fixing in this
series, it must now be separate patches on top of this series.
When doing pull requests we both just have to make note that there's
a dependency to this branch, and it will find it's way to mainline
via arm-soc pull request. Or if no conflicts need sorting out, then
it will just get merged with your pull request.
Regards,
Tony
Tomi
The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-l-o-3.5
for you to fetch changes up to e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07:
OMAPDSS: DSI: implement generic DSI pin config (2012-05-09 10:53:05 +0300)
Tomi Valkeinen (6):
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi - tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: DSI: implement generic DSI pin config
arch/arm/mach-omap2/board-3430sdp.c| 38 +-
arch/arm/mach-omap2/board-4430sdp.c| 37 ++
arch/arm/mach-omap2/board-am3517evm.c | 25 +---
arch/arm/mach-omap2/board-cm-t35.c | 30 +
arch/arm/mach-omap2/board-devkit8000.c | 30 +
arch/arm/mach-omap2/board-igep0020.c | 32 +
arch/arm/mach-omap2/board-omap3beagle.c| 37 +-
arch/arm/mach-omap2/board-omap3evm.c | 29 +
arch/arm/mach-omap2/board-omap3stalker.c | 29 +
arch/arm/mach-omap2/board-omap4panda.c | 39 +-
arch/arm/mach-omap2/board-overo.c | 25 +---
drivers/video/omap2/displays/Kconfig |8 +-
drivers/video/omap2/displays/Makefile |2 +-
drivers/video/omap2/displays/panel-taal.c | 22
.../omap2/displays/{panel-dvi.c = panel-tfp410.c} | 134
+++-
drivers/video/omap2/dss/dsi.c | 133 +--
include/video/omap-panel-nokia-dsi.h |3 +
.../{omap-panel-dvi.h = omap-panel-tfp410.h} | 18 ++-
include/video/omapdss.h| 28 ++--
19 files changed, 251 insertions(+), 448 deletions(-)
rename drivers/video/omap2/displays/{panel-dvi.c = panel-tfp410.c} (63%)
rename include/video/{omap-panel-dvi.h = omap-panel-tfp410.h} (63%)
--
To unsubscribe from this list: send the line unsubscribe 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: decompressor: Fix mmu mapping for non-DRAM address space.
On Wed, May 09, 2012 at 06:00:10PM +0530, Shilimkar, Santosh wrote: On Wed, May 9, 2012 at 5:53 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, May 09, 2012 at 02:20:28PM +0530, Shilimkar, Santosh wrote: The only change done common code is clearing 'XN' bit for DRAM region in page table entries. The other change of setting the DACR register is done in ARMv7 specific code. Yes, XN is an ARMv6+ thing. Before ARMv5, it was implementation defined. Some implementations used the bit to mean allow writes to update the cache. Other implementations labelled this bit as should be zero while others labelled it as should be one. Good to know. The upshot of this is, we know that having this bit as '1' means that all the CPUs we support today work. I would be _very_ concerned to change this bit to zero as we _really_ don't know how the pre-ARMv6 CPUs would react. I agree. The solution to this is pretty simple - if ARMv6+ needs a different base section mapping value, then we need to extract that from the code and pass in the base section mapping value. I'll sort out a patch later today for this. Great. This works for my 4430SDP board. I haven't booted it on anything else yet. Please can you check that this solves the issue for you? Thanks. arch/arm/boot/compressed/head.S | 29 ++--- 1 files changed, 18 insertions(+), 11 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..5ad33a4 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -567,6 +567,12 @@ __armv3_mpu_cache_on: mcr p15, 0, r0, c7, c0, 0 @ invalidate whole cache v3 mov pc, lr +#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH +#define CB_BITS 0x08 +#else +#define CB_BITS 0x0c +#endif + __setup_mmu: sub r3, r4, #16384 @ Page directory size bic r3, r3, #0xff @ Align the pointer bic r3, r3, #0x3f00 @@ -578,17 +584,14 @@ __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 - orr r1, r1, #3 10 + mov r1, #0x12 @ XN|U + section mapping + orr r1, r1, #3 10@ AP=11 add r2, r3, #16384 1: cmp r1, r9 @ if virt start of RAM -#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH - orrhs r1, r1, #0x08 @ set cacheable -#else - orrhs r1, r1, #0x0c @ set cacheable, bufferable -#endif - cmp r1, r10 @ if virt end of RAM - bichs r1, r1, #0x0c @ clear cacheable, bufferable + cmphs r10, r1 @end of RAM virt + bic r1, r1, #0x1c @ clear XN|U + C + B + orrlo r1, r1, #0x10 @ Set XN|U for non-RAM + orrhs r1, r1, r6 @ set RAM section settings str r1, [r0], #4@ 1:1 mapping add r1, r1, #1048576 teq r0, r2 @@ -599,7 +602,7 @@ __setup_mmu:sub r3, r4, #16384 @ Page directory size * so there is no map overlap problem for up to 1 MB compressed kernel. * If the execution is in RAM then we would only be duplicating the above. */ - mov r1, #0x1e + orr r1, r6, #0x04 @ ensure B is set for this orr r1, r1, #3 10 mov r2, pc mov r2, r2, lsr #20 @@ -620,6 +623,7 @@ __arm926ejs_mmu_cache_on: __armv4_mmu_cache_on: mov r12, lr #ifdef CONFIG_MMU + mov r6, #CB_BITS | 0x12 @ U bl __setup_mmu mov r0, #0 mcr p15, 0, r0, c7, c10, 4 @ drain write buffer @@ -641,6 +645,7 @@ __armv7_mmu_cache_on: #ifdef CONFIG_MMU mrc p15, 0, r11, c0, c1, 4 @ read ID_MMFR0 tst r11, #0xf @ VMSA + movne r6, #CB_BITS | 0x02 @ !XN blne__setup_mmu mov r0, #0 mcr p15, 0, r0, c7, c10, 4 @ drain write buffer @@ -655,7 +660,7 @@ __armv7_mmu_cache_on: orr r0, r0, #1 25@ big-endian page tables #endif orrne r0, r0, #1 @ MMU enabled - movne r1, #-1 + movne r1, #0xfffd @ domain 0 = client mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer mcrne p15, 0, r1, c3, c0, 0 @ load domain access control #endif @@
RE: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
On Wed, 2012-05-09 at 10:38 -0500, Ashwin Bihari wrote:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
Sent: Wednesday, May 09, 2012 3:16 AM
To: Ashwin Bihari
Cc: linux-omap; Tony Lindgren
Subject: Re: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
snip
+static int omap3logic_panel_enable_lcd(struct omap_dss_device
+*dssdev) {
+ gpio_set_value(LCD_PANEL_PWR, 1);
+ if (machine_is_omap3530_lv_som())
+ gpio_set_value(OMAP3530_LV_SOM_BACKLIGHT_PWR, 1);
+ else if (machine_is_omap3_torpedo()) {
+ gpio_set_value(OMAP3530_TORPEDO_BACKLIGHT_PWR, 1);
+
+ gpio_set_value(OMAP3530_TORPEDO_MDISP, 1);
+ }
+
+ return 0;
+}
+
+static int omap3logic_panel_disable_lcd(struct omap_dss_device
+*dssdev) {
+ gpio_set_value(LCD_PANEL_PWR, 0);
+ if (machine_is_omap3530_lv_som())
+ gpio_set_value(OMAP3530_LV_SOM_BACKLIGHT_PWR, 0);
+ else if (machine_is_omap3_torpedo()) {
+ gpio_set_value(OMAP3530_TORPEDO_BACKLIGHT_PWR, 0);
+
+ gpio_set_value(OMAP3530_TORPEDO_MDISP, 0);
+ }
+
+ return 0;
+}
This doesn't play well with device-tree. We can't do such callbacks when we
move to DT.
I know we have similar code for other boards, and this can't be properly
fixed
right now, but I'm still a bit hesitant to add more such code because I'm
the
one that has to clean it up later for DT =).
I can handle the LCD_PANEL_PWR gpio, but the backlight is something that
should be removed from the panel enable callbacks. You could look at
drivers/video/backlight/ and see if there's something there that could be
used for your board. Or implement a new BL driver, if nothing fits.
Tomi
Tomi,
Let me take a look at your linux-omap-dss2 tree and learn a bit more about DT
and figure out how to modify the LCD support so it better aligns with your
work and I'll re-submit that patch again..
I haven't published any DT stuff yet. But there's the DT cleanup series
I have posted, which tries to re-structure stuff for some displays to be
more DT compatible.
The basic idea is that with DT there are no board files, and all device
specific configuration values are in the DT data. So GPIO numbers etc.
are defined in the DT data, and the device driver will read them and use
them.
But DT support is not working yet, and we anyway need to support both DT
and the old way for some time, so the board files should be changed to
this direction. What this means for dss is that the panel specific GPIOs
etc. need to be defined in a device specific struct, which is passed to
the panel driver.
For example, see my cleanup series, and
include/video/omap-panel-tfp410.h,
drivers/video/omap2/displays/panel-tfp410.c and the board files using
that.
All this is still a bit alive and changing, so you could also choose to
wait a bit until things stabilize =).
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 3/3] twl4030: enable wakeup on twl4030 IRQ.
Hi Neil, On Wed, Apr 25, 2012 at 01:05:24PM +1000, NeilBrown wrote: Most of the interrupts that come through this line should trigger wakeups: power button RTC alarm power available usb plug/unplug so mark the interrupt as a wakeup interrupt. This is particularly important for when the interrupt arrives during the late suspend phase. Without this setting it will be ignored. Signed-off-by: NeilBrown ne...@suse.de --- drivers/mfd/twl4030-irq.c |1 + 1 file changed, 1 insertion(+) Patch applied, thanks. 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] ARM: OMAP: Cleanup Beagleboard DVI reset gpio
Hi Tomi,
* Russ Dill russ.d...@ti.com [120508 19:52]:
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. Additionally, it uses
gpio_set_value_cansleep since this GPIO is connected through i2c.
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.
Can you check if this needs updates for your clean up patches?
Regards,
Tony
v3
- Change patch title to include 'ARM: OMAP:'
- Actually rename reset_gpio to dvi_reset_gpio
v2
- Rename reset_gpio to dvi_reset_gpio to self document
- Use gpio_set_value_cansleep since TWL gpio can sleep
- Use gpio_is_valid instead of -EINVAL check
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 | 49
---
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 495b810..3956c51 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -81,13 +81,13 @@ static u8 omap3_beagle_version;
static struct {
int mmc1_gpio_wp;
int usb_pwr_level;
- int reset_gpio;
+ int dvi_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,
+ .dvi_reset_gpio = -EINVAL,
.usr_button_gpio = 4,
.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
};
@@ -126,21 +126,21 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO OMAP3 Beagle Rev: Ax/Bx\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_AXBX;
beagle_config.mmc1_gpio_wp = 29;
- beagle_config.reset_gpio = 170;
+ beagle_config.dvi_reset_gpio = 170;
beagle_config.usr_button_gpio = 7;
break;
case 6:
printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_C1_3;
beagle_config.mmc1_gpio_wp = 23;
- beagle_config.reset_gpio = 170;
+ beagle_config.dvi_reset_gpio = 170;
beagle_config.usr_button_gpio = 7;
break;
case 5:
printk(KERN_INFO OMAP3 Beagle Rev: C4\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_C4;
beagle_config.mmc1_gpio_wp = 23;
- beagle_config.reset_gpio = 170;
+ beagle_config.dvi_reset_gpio = 170;
beagle_config.usr_button_gpio = 7;
break;
case 0:
@@ -196,7 +196,7 @@ static struct mtd_partition omap3beagle_nand_partitions[]
= {
static int beagle_enable_dvi(struct omap_dss_device *dssdev)
{
if (gpio_is_valid(dssdev-reset_gpio))
- gpio_set_value(dssdev-reset_gpio, 1);
+ gpio_set_value_cansleep(dssdev-reset_gpio, 1);
return 0;
}
@@ -204,7 +204,7 @@ static int beagle_enable_dvi(struct omap_dss_device
*dssdev)
static void beagle_disable_dvi(struct omap_dss_device *dssdev)
{
if (gpio_is_valid(dssdev-reset_gpio))
- gpio_set_value(dssdev-reset_gpio, 0);
+ gpio_set_value_cansleep(dssdev-reset_gpio, 0);
}
static struct panel_dvi_platform_data dvi_panel = {
@@ -242,12 +242,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 (gpio_is_valid(beagle_config.dvi_reset_gpio)) {
+ int r;
+
+ omap_mux_init_gpio(beagle_config.dvi_reset_gpio,
OMAP_PIN_OUTPUT);
+ r = gpio_request_one(beagle_config.dvi_reset_gpio,
+ GPIOF_OUT_INIT_LOW, DVI reset);
+ if (r 0)
+ printk(KERN_ERR Unable to get DVI reset GPIO\n);
+
Re: [PATCH 4/6] twl4030_charger: Allow charger to control the regulator that feeds it.
Hi Neil, On Wed, Apr 25, 2012 at 05:33:11PM +1000, NeilBrown wrote: The charger needs usb3v1 to be running, so add a new consumer to keep it running. This allows the charger to draw current even when the USB driver has powered down. Signed-off-by: NeilBrown ne...@suse.de --- drivers/mfd/twl-core.c |9 + drivers/power/twl4030_charger.c | 15 +++ 2 files changed, 20 insertions(+), 4 deletions(-) In case Anton has not taken that patchset yet: Acked-by: Samuel Ortiz sa...@linux.intel.com 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 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* R, Sricharan r.sricha...@ti.com [120509 02:09]:
Tony,
[snip]
-#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?
Ok, There are multiple functions under that #ifdef.
Also i see that __weak cannot be used for inline functions.
So should those functions should be moved to .c file and qualify them
__weak. There is already a strong override for OMAP2 and 3 which
should not be a problem.
Yes that's worth experimenting with to set up things in a way where
we don't need to add new ifdefs to add a new SoC.
[OR]
So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS
it can be changed as
#ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) ||
defined(CONFIG_ARCH_OMAP3))
So this will avoid patching this for the future socs. ?
Well it seems that we've come to a conclusion that if we introduce
new config options, they should be based on features instead. So
CONFIG_SOC_HAS_OMAPXYZ_BLAH rather than CONFIG_SOC_OMAP4PLUS.
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: [GIT PULL] omap fixes for v3.4-rc6, take2
On Wed, May 9, 2012 at 8:35 AM, Tony Lindgren t...@atomide.com wrote: Hi Olof, Here's this one updated to drop the non-regression patch and to use updated version of Enrico's patch. The other two patches are the same. Pulled, thanks! -Olof -- To unsubscribe from this list: send the line unsubscribe 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: DSS2 DVI output: red screen
Vaibhav, Thanks for your help on this. I was unaware that the Kernel changed the pin-mux after U-boot did the initial setup. Applying this fix to the linux kernel fixed the problem. Much appreciated, Neil Johnson On Mon, May 7, 2012 at 11:21 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Tue, May 08, 2012 at 04:41:35, Neil Johnson wrote: 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, Make sure that you have configured the pin mux settings accordingly, We have similar interface done on OMAP3EVM, so you can refer to the Omap3evm code, http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm.c;h=fd1b481c762c97576f1c9cb5503e9bd470a4a528;hb=5e136da4f5d9aa5388097afad1f6a0e6fd8572c6#l556 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: Cleanup Beagleboard DVI reset gpio
On Wed, May 9, 2012 at 8:55 AM, Tony Lindgren t...@atomide.com wrote: Hi Tomi, * Russ Dill russ.d...@ti.com [120508 19:52]: 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. Additionally, it uses gpio_set_value_cansleep since this GPIO is connected through i2c. 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. Can you check if this needs updates for your clean up patches? I'm not sure what you mean, can you be more specific? -- To unsubscribe from this list: send the line unsubscribe 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: Cleanup Beagleboard DVI reset gpio
* Russ Dill russ.d...@ti.com [120509 09:29]: On Wed, May 9, 2012 at 8:55 AM, Tony Lindgren t...@atomide.com wrote: Hi Tomi, * Russ Dill russ.d...@ti.com [120508 19:52]: 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. Additionally, it uses gpio_set_value_cansleep since this GPIO is connected through i2c. 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. Can you check if this needs updates for your clean up patches? I'm not sure what you mean, can you be more specific? Tomi has a DSS clean-up series posted that affects the board-*.c files. 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 01/25] OMAPDSS: panel-dvi: add PD gpio handling
On Thu, May 3, 2012 at 6:57 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-dvi.c | 31
++
include/video/omap-panel-dvi.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-dvi.c
b/drivers/video/omap2/displays/panel-dvi.c
index 03eb14a..876b798 100644
--- a/drivers/video/omap2/displays/panel-dvi.c
+++ b/drivers/video/omap2/displays/panel-dvi.c
@@ -21,6 +21,7 @@
#include linux/slab.h
#include video/omapdss.h
#include linux/i2c.h
+#include linux/gpio.h
#include drm/drm_edid.h
#include video/omap-panel-dvi.h
@@ -44,6 +45,8 @@ struct panel_drv_data {
struct omap_dss_device *dssdev;
struct mutex lock;
+
+ int pd_gpio;
};
static inline struct panel_dvi_platform_data
@@ -54,6 +57,7 @@ static inline struct panel_dvi_platform_data
static int panel_dvi_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
int r;
@@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device
*dssdev)
goto err1;
}
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_set_value(ddata-pd_gpio, 1);
+
On Beagleboard xM, this GPIO is connected though an I2C chip so it
sleeps. Can you change these to gpio_set_value_cansleep?
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -79,11 +86,15 @@ err0:
static void panel_dvi_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_set_value(ddata-pd_gpio, 0);
+
Same with this one.
if (pdata-platform_disable)
pdata-platform_disable(dssdev);
@@ -92,7 +103,9 @@ static void panel_dvi_power_off(struct omap_dss_device
*dssdev)
static int panel_dvi_probe(struct omap_dss_device *dssdev)
{
+ struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
struct panel_drv_data *ddata;
+ int r;
ddata = kzalloc(sizeof(*ddata), GFP_KERNEL);
if (!ddata)
@@ -104,6 +117,21 @@ static int panel_dvi_probe(struct omap_dss_device
*dssdev)
ddata-dssdev = dssdev;
mutex_init(ddata-lock);
+ if (pdata)
+ ddata-pd_gpio = pdata-power_down_gpio;
+ else
+ ddata-pd_gpio = -1;
+
+ if (gpio_is_valid(ddata-pd_gpio)) {
+ r = gpio_request_one(ddata-pd_gpio, GPIOF_OUT_INIT_LOW,
+ tfp410 pd);
+ if (r) {
+ dev_err(dssdev-dev, Failed to request PD GPIO
%d\n,
+ ddata-pd_gpio);
+ ddata-pd_gpio = -1;
+ }
+ }
+
dev_set_drvdata(dssdev-dev, ddata);
return 0;
@@ -115,6 +143,9 @@ static void __exit panel_dvi_remove(struct
omap_dss_device *dssdev)
mutex_lock(ddata-lock);
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_free(ddata-pd_gpio);
+
dev_set_drvdata(dssdev-dev, NULL);
mutex_unlock(ddata-lock);
diff --git a/include/video/omap-panel-dvi.h b/include/video/omap-panel-dvi.h
index 87ad567b..4ad41fc 100644
--- a/include/video/omap-panel-dvi.h
+++ b/include/video/omap-panel-dvi.h
@@ -27,11 +27,13 @@ struct omap_dss_device;
* @platform_enable: platform specific panel enable function
* @platform_disable: platform specific panel disable function
* @i2c_bus_num: i2c bus id for the panel
+ * @power_down_gpio: gpio number for PD pin (or -1 if not available)
*/
struct panel_dvi_platform_data {
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
u16 i2c_bus_num;
+ int power_down_gpio;
};
#endif /* __OMAP_PANEL_DVI_H */
--
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
--
To unsubscribe from this list: send the line unsubscribe 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
On Wednesday 09 May 2012, Christoph Hellwig wrote: On Wed, May 09, 2012 at 01:59:40PM +, Arnd Bergmann wrote: My feeling is that we should just treat every (REQ_SYNC | REQ_READ) request the same and let them interrupt long-running writes, independent of whether it's REQ_META or demand paging. It's funny that the CFQ scheduler used to boost metadata reads that have REQ_META set - in fact it still does for those filesystems using the now split out REQ_PRIO. That certainly sounds more sensible than the opposite. Of course, this is somewhat unrelated to the question of prioritizing reads over any writes that are already started. IMHO It would be pointless to only stop the write in order to do a REQ_PRIO read but not any other read. 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] ARM: OMAP: Cleanup Beagleboard DVI reset gpio
On Wed, May 9, 2012 at 9:36 AM, Tony Lindgren t...@atomide.com wrote: * Russ Dill russ.d...@ti.com [120509 09:29]: On Wed, May 9, 2012 at 8:55 AM, Tony Lindgren t...@atomide.com wrote: Hi Tomi, * Russ Dill russ.d...@ti.com [120508 19:52]: 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. Additionally, it uses gpio_set_value_cansleep since this GPIO is connected through i2c. 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. Can you check if this needs updates for your clean up patches? I'm not sure what you mean, can you be more specific? Tomi has a DSS clean-up series posted that affects the board-*.c files. Yes, it conflicts pretty bad but, it's fairly straightforward to fixup. Additionally, the 'OMAPDSS: panel-dvi: add PD gpio handling' needs to be changed to use gpio_set_value_cansleep (replied to patch in separate email). -- To unsubscribe from this list: send the line unsubscribe 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: OMAP2+: some hwmod data additions for 3.5
* Paul Walmsley p...@pwsan.com [120508 17:37]: Hi Tony, this pull request is for some hwmod data additions for v3.5. It is based on top of the commits in the omap-devel-b-for-3.5 tag. Thanks pulling into devel-hwmod-data. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] ARM: OMAP4: register V1V8, V2V1 regulators
* Peter Ujfalusi peter.ujfal...@ti.com [120509 00:37]: Hello, Changes since v1: - rebased on 3.4-rc6 Original intro message: This series adds common configuration for the V1V8, V2V1 regulators from twl6030. These regulators are commonly used to feed the twl6040 audio IC on OMAP4 based boards (SDP4430, PandaBoards). The regulator support for the twl6040 MFD driver will be going via MFD tree to avoid cross tree issues. Thanks applying into board branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: arm/dts: OMAP4: Add Variscite OMAP4 System-On-Modeule support
Hi, * Uri Yosef ur...@variscite.com [120312 03:23]: From: Uri yosef ur...@variscite.com Hi Tony, This patch add device tree support for Variscite OMAP4 System-On-Modeule. Do you have an updated version of this available now that MMC mostly works? 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 01/25] OMAPDSS: panel-dvi: add PD gpio handling
On Wed, 2012-05-09 at 09:50 -0700, Russ Dill wrote:
On Thu, May 3, 2012 at 6:57 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-dvi.c | 31
++
include/video/omap-panel-dvi.h |2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-dvi.c
b/drivers/video/omap2/displays/panel-dvi.c
index 03eb14a..876b798 100644
--- a/drivers/video/omap2/displays/panel-dvi.c
+++ b/drivers/video/omap2/displays/panel-dvi.c
@@ -21,6 +21,7 @@
#include linux/slab.h
#include video/omapdss.h
#include linux/i2c.h
+#include linux/gpio.h
#include drm/drm_edid.h
#include video/omap-panel-dvi.h
@@ -44,6 +45,8 @@ struct panel_drv_data {
struct omap_dss_device *dssdev;
struct mutex lock;
+
+ int pd_gpio;
};
static inline struct panel_dvi_platform_data
@@ -54,6 +57,7 @@ static inline struct panel_dvi_platform_data
static int panel_dvi_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_drv_data *ddata = dev_get_drvdata(dssdev-dev);
struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
int r;
@@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device
*dssdev)
goto err1;
}
+ if (gpio_is_valid(ddata-pd_gpio))
+ gpio_set_value(ddata-pd_gpio, 1);
+
On Beagleboard xM, this GPIO is connected though an I2C chip so it
sleeps. Can you change these to gpio_set_value_cansleep?
This patch has already been applied, so we have to do follow up patches
for this. I can look at this tomorrow, but if you update your ARM:
OMAP: Cleanup Beagleboard DVI reset gpio patch, will you take a look at
this also?
The applied patches can be found from here, so the follow up patches
should be based on this: git://gitorious.org/linux-omap-dss2/linux.git
for-l-o-3.5
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH-V7 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
* Vaibhav Hiremath hvaib...@ti.com [120503 01:02]: 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) I'll apply these into cleanup-timer branch now that we have the related hwmod patches merged into devel-hwmod-data. 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] ARM: OMAP2+: remove incorrect irq_chip ack field
* Grazvydas Ignotas nota...@gmail.com [120505 17:00]: Each irq_chip for the main interrupt controller has offsets set for irq masking registers, which added to respective base results in a pointer to appropriate hardware register. However this is not correct for INTC_CONTROL as there is only one INTC_CONTROL register. This does not cause problems because generic ack code is never called, but remove this assignment to avoid confusion. Thanks applying into fixes-non-critical. Regards, Tony Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- arch/arm/mach-omap2/irq.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c index 65f0d25..c11e8a8 100644 --- a/arch/arm/mach-omap2/irq.c +++ b/arch/arm/mach-omap2/irq.c @@ -149,7 +149,6 @@ omap_alloc_gc(void __iomem *base, unsigned int irq_start, unsigned int num) ct-chip.irq_mask = irq_gc_mask_disable_reg; ct-chip.irq_unmask = irq_gc_unmask_enable_reg; - ct-regs.ack = INTC_CONTROL; ct-regs.enable = INTC_MIR_CLEAR0; ct-regs.disable = INTC_MIR_SET0; irq_setup_generic_chip(gc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE, -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Benoit,
On 05/09/2012 05:58 AM, Cousson, Benoit wrote:
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
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.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of
view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic
mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable
hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}
So if we want to allow that,
RE: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com] Sent: Wednesday, May 09, 2012 11:52 AM To: Ashwin Bihari Cc: linux-omap; Tony Lindgren Subject: RE: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits On Wed, 2012-05-09 at 10:38 -0500, Ashwin Bihari wrote: -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com] Sent: Wednesday, May 09, 2012 3:16 AM To: Ashwin Bihari Cc: linux-omap; Tony Lindgren Subject: Re: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits snip This doesn't play well with device-tree. We can't do such callbacks when we move to DT. I know we have similar code for other boards, and this can't be properly fixed right now, but I'm still a bit hesitant to add more such code because I'm the one that has to clean it up later for DT =). I can handle the LCD_PANEL_PWR gpio, but the backlight is something that should be removed from the panel enable callbacks. You could look at drivers/video/backlight/ and see if there's something there that could be used for your board. Or implement a new BL driver, if nothing fits. Tomi Tomi, Let me take a look at your linux-omap-dss2 tree and learn a bit more about DT and figure out how to modify the LCD support so it better aligns with your work and I'll re-submit that patch again.. I haven't published any DT stuff yet. But there's the DT cleanup series I have posted, which tries to re-structure stuff for some displays to be more DT compatible. The basic idea is that with DT there are no board files, and all device specific configuration values are in the DT data. So GPIO numbers etc. are defined in the DT data, and the device driver will read them and use them. But DT support is not working yet, and we anyway need to support both DT and the old way for some time, so the board files should be changed to this direction. What this means for dss is that the panel specific GPIOs etc. need to be defined in a device specific struct, which is passed to the panel driver. For example, see my cleanup series, and include/video/omap-panel-tfp410.h, drivers/video/omap2/displays/panel-tfp410.c and the board files using that. All this is still a bit alive and changing, so you could also choose to wait a bit until things stabilize =). Tomi Tomi, I will take a look at the files you mentioned so for my own information, but will hold off on submitting anything until things are stable, as you suggested. Thanks -- -- -- ~ Ashwin
Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Woodruff, Richard r-woodru...@ti.com writes: From: Hilman, Kevin Sent: Tuesday, May 08, 2012 5:17 PM A basic OMAP AVS driver has been in mainline for a long time, yet we have not seen support submitted for all of these features. 1.5/3.5 is a feature. And I'm still waiting for it to be submitted upstream. ABB is requirement for a production useable driver. Higher speed rated OMAP4 and all OMAP5 added these to be useable. ditto Yes this is effort. Point of mentioning is to raise awareness of need. I'm well aware of the need. Yet to be added feature has different meaning than functional gap. And both need to be submitted upstream. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2] ARM: OMAP2+: am33xx: Make am33xx as a separate class
* Vaibhav Hiremath hvaib...@ti.com [120509 04:28]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). Thanks applying into devel-soc after updating for soc_is change and fixing typo in the description that stil said OMAPAM. Updated patch below. Tony From: Vaibhav Hiremath hvaib...@ti.com Date: Wed, 9 May 2012 16:54:27 +0530 Subject: [PATCH] ARM: OMAP2+: am33xx: Make am33xx as a separate class Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). So, after long discussion we have came to the conclusion that, we should not consider am33xx device as omap3 family, instead create separate class (SOC_AM33XX) under OMAP2PLUS. This means, for am33xx device, cpu_is_omap34xx() will return false, and only cpu_is_am33xx() will be true. Please refer to the link below, for mailing-list discussion on this - http://www.spinics.net/lists/linux-omap/msg69439.html Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com [t...@atomide.com: fixed typo, updated for soc_is changes] Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 61bf3c3..7a77bb6 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -84,8 +84,10 @@ config SOC_TI81XX config SOC_AM33XX bool AM33XX support - depends on ARCH_OMAP3 default y + select CPU_V7 + select ARM_CPU_SUSPEND if PM + select MULTI_IRQ_HANDLER config OMAP_PACKAGE_ZAF bool diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index a5b8db3..25370fd 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -16,6 +16,7 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -90,6 +91,7 @@ obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o +obj-$(CONFIG_SOC_AM33XX) += prcm.o # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -99,6 +101,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common) # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o @@ -113,6 +116,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= powerdomains2xxx_3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) obj-$(CONFIG_ARCH_OMAP4) += powerdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) # PRCM clockdomain control clockdomain-common += clockdomain.o @@ -127,6 +131,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= clockdomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common) obj-$(CONFIG_ARCH_OMAP4) += clockdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o +obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o @@ -144,6 +149,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= dpll3xxx.o clock3xxx_data.o obj-$(CONFIG_ARCH_OMAP3) += clkt_iclk.o obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o # OMAP2 clock rate set data (old OPP data) obj-$(CONFIG_SOC_OMAP2420)
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 05/08/2012 01:09 PM, Jassi Brar wrote:
On 8 May 2012 22:05, Stephen Warren swar...@wwwdotorg.org wrote:
The data doesn't need to be part of the DMA controller node in order for
the DMA controller driver to be the entity interpreting it.
I rather say, if the dma controller driver is the entity going to interpret
the
data, why not provide the data directly through its node at one go?
There is important difference between providing data via clients
during runtime vs providing info about every client to the dmac driver
at one go during its probe.
I certainly see that there is a difference.
I don't understand why it's an important difference; I think everything
needs to be handled at run-time no matter what:
Just because there is information in the DT that this client DT node
uses this channel/request-ID/... of this DMA controller doesn't mean
that the driver for the client is going to be loaded, or that SW running
on the system is going to cause that driver to actually be opened and do
any DMA. As such, any resource allocation rules etc. must be evaluated
only if/when a driver actually requests/uses a DMA channel, so having
all the information up front doesn't seem like a theoretically
possible thing anyway.
Very similar to this, in order to support your point that a given client
could potentially use a channel from either of 2 different DMA
controller instances, you don't know until run-time which controller
will be used, so can't have up-front information in this scenario
either, even if the DMA does actually take place.
The advantage here is that:
* The specifier is stored in the client, not the IRQ/GPIO/DMA
controller's node, so it's located right at the usage site, which
typically makes working out what resources a client uses easier.
A client doesn't really need some n'th channel of some m'th dma controller.
A client simply needs one channel for transmitting data whichever
platform it be.
So {n,m}_channel isn't really a required resource, dma_tx is, which I still
specify in the client's node.
The fact that this information is simply fwd by the client as such to the
dmac
(via utility code), makes the ritual even more pointless.
Ah, I see your point now.
To solve this, we would need to (optionally?) model the DMA request
signal routing in the DT, so that one could explicitly model the 1:1 or
1:n situation.
And since a given DMA client might be able to use the services of 2
different DMA controllers, those controllers might not even be identical
HW, and hence would potentially not have identical DMA bindings. So,
that doesn't work; we really do need device-agnostic DMA bindings in
order to support this while maintaining all features.
That all said, do we want to:
a) Have the DT specify exactly which controller a given client will use,
i.e. pick a particular one even when multiple are possible in HW.
This is supported by the currently proposed bindings without issue; we
just ignore the fact that the DT author could have connected the client
to a different controller if they wanted.
b) Have the DT represent exactly what exists in HW, i.e. that the
client's DMA request signal is routed to N places, and have the SW pick
which to use at runtime.
You're obviously arguing for (b), and indeed that does seem more like a
simple representation of the HW, rather than SW's use of HW, and so is
indeed more appropriate.
Solving (b) seems to require something very roughly like:
dma-controller@0 {
compatible = foo,dmac-xxx;
dma-requests =
client0 0 // DMAC req 0 is client0's 0th req output
client0 1
client1 0
client1 1
client2 0
...;
};
dma-controller@1 {
compatible = bar,dmac-yyy;
dma-requests =
// Supports some client modules, but not the same ones
client0 0
client1 0
client3 0
...;
};
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
client2: foo {
/* has 1 DMA request signal: 0 */
};
client3: bar {
/* has 1 DMA request signal: 0 */
};
and then having the core DMA code have an API like:
channel = dma_request(clients_dma_req_output_id)
which looks in each DMA controller's dma-requests list for the client's
phandle and matching dma_req_output_id.
This also keeps client-specific information out of the provider node,
allowing it to be fully generic.
A typical Samsung SoC has 2 peripheral DMA controllers and
about 40 possible clients. Of which ~20 clients could be served by either of
the two dmacs. Of course hardly ever a machine has 10 clients. It would be
desirable if the dma driver doesn't populate the unused 54(32+32-10) channels,
presumably also reserving limited resources for each, on the machine.
Consider this example ...
A PL330 instance has 8 physical channels and 32
Re: oprofile and ARM A9 hardware counter
On 05/09/2012 01:04 PM, Jon Hunter wrote:
Hi Benoit,
On 05/09/2012 05:58 AM, Cousson, Benoit wrote:
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
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.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of
view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic
mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable
hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst,
Re: [PATCH] MFD: twl6040: Add regulator support for VIO, V2V1 supplies
Hi Peter, On Wed, May 02, 2012 at 04:54:42PM +0300, Peter Ujfalusi wrote: twl6040 has three power supply source: VBAT needs to be connected to VBAT, VIO, and V2V1. Add regulator support for the VIO, V2V1 supplies. Initially handle the two supply together with bulk commands. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com --- drivers/mfd/twl6040-core.c | 33 + include/linux/mfd/twl6040.h |2 ++ 2 files changed, 31 insertions(+), 4 deletions(-) Hi Samuel, The runtime dependencies for this patch has been sent to linux-omap list: http://marc.info/?l=linux-omapm=133596645010228w=2 http://marc.info/?l=linux-omapm=133596645610232w=2 http://marc.info/?l=linux-omapm=133596644310224w=2 http://marc.info/?l=linux-omapm=133596643310220w=2 Alone this patch does not cause compile time regression but in runtime it needs the arch/arm/mach-omap2 patches. I try to avoid cross tree issues as much as I can and I'm happy if these will come together in linux-next (and finally in 3.5). I applied this one to my nfc-next branch, thanks. 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 05/04/2012 03:57 PM, Tony Lindgren wrote:
* Stephen Warren swar...@wwwdotorg.org [120504 12:27]:
On 05/02/2012 11:24 AM, Tony Lindgren wrote:
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
...
On the other hand, I worry about whether using pinctrl-simple here as
the compatible value is going to cause issues:
Certainly, this is a pretty simple driver, and most likely reasonably
generic an applicable to many SoCs. However, it doesn't cover a bunch of
cases that I'd still consider simple. For example, what if each pin
has a separate mux and pinconf register? There are probably many such
small cases that would add up to something more complex. to cover those
cases, will we be able to extend pinctrl-simple to cover them, and
continue to be backwards compatible, or will we need to create a
binding/driver for pinctrl-simple-1, pinctrl-simple-2, pinctrl-simple-3
each of which covers some different, yet still simple, configuration?
Yes getting the binding right is the critical part here, everything else
can be added as needed. I was thinking about using separate properties
for auxilary registers, but now thinking about it a bit more, it may not
be sufficient.
How about we make some of these properties into arrays? For example:
#pinctrl-cells = 6;
pinctrl-simple,function-mask = 0x 0x 0x;
pinctrl-simple,function-off = 0x7 0x7 0x7;
pinctrl-simple,pinconf-mask = 0x 0x 0x;
I'm not sure what the 3 entries in the array are meant to describe?
Then for handling the set/clear bits case of registers, we could do that
automatically if both masks are 0 for some registers. We actually have
that for some omap1 where there are three registers per mux with bits
to set or clear. And these bits are not the same across all registers..
+ 0x6c 0xf/* CSI21_DX3 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x6e 0xf/* CSI21_DY3 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x70 0xf/* CSI21_DX4 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x72 0xf/* CSI21_DY4 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ ;
+ };
+ };
+
+
+ /* map all uart2 pins as a single function */
+ uart2_pins: pinmux_uart2_pins {
+ uart2_pins {
+ pinctrl-simple,cells =
+ 0xd8 0x118 /* UART2_CTS
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0 */
+ 0xda 0 /* UART2_RTS OMAP_PIN_OUTPUT |
OMAP_MUX_MODE0 */
+ 0xdc 0x118 /* UART2_RX
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0 */
+ 0xde 0 /* UART2_TX OMAP_PIN_OUTPUT |
OMAP_MUX_MODE0 */
+ ;
+ };
+ };
+
+ /* map all uart3 pins as separate functions */
+ uart3_pins: pinmux_uart3_pins {
From a binding perspective, I don't see why you'd want to allow two cases:
1) One node with multiple entries in pinctrl-simple,cells
2) Multiple nodes each with a single entry in pinctrl-simple,cells
Why not only allow (1)?
Because we need to specify GPIO for some pins. There may be additional flags
What do you mean by specify GPIO?
Nothing in this pinctrl-simple binding seems to imply that it's also a
GPIO controller.
If GPIO is one of the functions that can be mux'd onto a pin, then I'd
expect that to be represented in exactly the same way as any other
function that could be mux'd onto the pin.
So, I'm not sure what GPIO-related information you want to represent.
too, we do have external DMA request lines for few pins available.. I'm not
saying pinctrl fwk should know about that, but it's a similar mapping of pins
to GPIO lines.
Aren't DMA request lines also just another function that can be mux'd
onto a pin?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
