Re: [patch 2.6.29-rc3-git] input: twl4030_keypad driver
On Friday 06 February 2009, David Brownell wrote:
> From: David Brownell
>
> Add a driver for the keypad controller on TWL4030 family chips.
PING? I was told this was in the input queue, but it's not in
http://git.kernel.org/?p=linux/kernel/git/dtor/input.git
Here's a current version of the patch.
- Dave
CUT HERE
From: David Brownell
Add a driver for the keypad controller on TWL4030 family chips.
These support up to an 8x8 key matrix. The TWL4030 multifunction
chips are mostly used on OMAP3 (or OMAP 2430) based boards.
Reviewed-by: Trilok Soni
Signed-off-by: David Brownell
---
Sometime later we may get a more generic/reusable solution
than the KEY() macros used here, which basically came from
the OMAP keypad support.
drivers/input/keyboard/Kconfig | 11
drivers/input/keyboard/Makefile |1
drivers/input/keyboard/twl4030_keypad.c | 493 ++
include/linux/i2c/twl4030.h | 17 -
4 files changed, 517 insertions(+), 5 deletions(-)
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -259,6 +259,17 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
+config KEYBOARD_TWL4030
+ tristate "TI TWL4030/TWL5030/TPS659x0 keypad support"
+ depends on TWL4030_CORE
+ help
+ Say Y here if your board use the keypad controller on
+ TWL4030 family chips. It's safe to say enable this
+ even on boards that don't use the keypad controller.
+
+ To compile this driver as a module, choose M here: the
+ module will be called twl4030_keypad.
+
config KEYBOARD_PXA27x
tristate "PXA27x/PXA3xx keypad support"
depends on PXA27x || PXA3xx
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_KEYBOARD_TOSA) += tosakbd.
obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
obj-$(CONFIG_KEYBOARD_OMAP)+= omap-keypad.o
+obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keypad.o
obj-$(CONFIG_KEYBOARD_PXA930_ROTARY) += pxa930_rotary.o
obj-$(CONFIG_KEYBOARD_AAED2000)+= aaed2000_kbd.o
--- /dev/null
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -0,0 +1,493 @@
+/*
+ * twl4030_keypad.c - driver for 8x8 keypad controller in twl4030 chips
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Code re-written for 2430SDP by:
+ * Syed Mohammed Khasim
+ *
+ * Initial Code:
+ * Manjunatha G K
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/*
+ * The TWL4030 family chips include a keypad controller that supports
+ * up to an 8x8 switch matrix. The controller can issue system wakeup
+ * events, since it uses only the always-on 32KiHz oscillator, and has
+ * an internal state machine that decodes pressed keys, including
+ * multi-key combinations.
+ *
+ * This driver lets boards define what keycodes they wish to report for
+ * which scancodes, as part of the "struct twl4030_keypad_data" used in
+ * the probe() routine.
+ *
+ * See the TPS65950 documentation; that's the general availability
+ * version of the TWL5030 second generation part.
+ */
+#define MAX_ROWS 8 /* TWL4030 hard limit */
+
+struct twl4030_keypad {
+ unsigned*keymap;
+ unsigned intkeymapsize;
+ u16 kp_state[MAX_ROWS];
+ unsignedn_rows;
+ unsignedn_cols;
+ unsignedirq;
+
+ struct device *dbg_dev;
+ struct input_dev *input;
+};
+
+#define ROWCOL_MASKKEY(0xf, 0xf, 0)
+#define KEYNUM_MASK~PERSISTENT_KEY(0xf, 0xf)
+
+/*--*/
+
+/* arbitrary prescaler value 0..7 */
+#define PTV_PRESCALER 4
+
+/* Register Offsets */
+#define KEYP_CTRL 0x00
+#define KEYP_DEB 0x01
+#define KEYP_LONG_KEY 0x02
+#define KEYP_LK_PTV0x03
+#define KEYP_TIMEOUT
Re: git pull request for omap fixes, v2 (Re: [PATCH 00/11] Omap fixes for 2.6.30-rc1)
* Tony Lindgren [090416 18:23]:
> * Tony Lindgren [090414 14:48]:
> > Hi all,
> >
> > Here are some omap fixes for review.
>
> Also merged in Paul's clock fixes posted here earlier.
>
> Russell, here's the pull request for you.
I merged in Paul's updated patch "OMAP2/3 GPTIMER: allow system tick
GPTIMER to be changed in board-*.c files".
The diff to earlier series and the updated pull request are attached.
Cheers,
Tony
Index: linux-omap-2.6/arch/arm/mach-omap2/clock24xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock24xx.h 2009-04-20 10:42:21.0 -0700
+++ linux-omap-2.6/arch/arm/mach-omap2/clock24xx.h 2009-04-20 10:46:09.0 -0700
@@ -625,8 +625,8 @@ static struct clk func_32k_ck = {
.clkdm_name = "wkup_clkdm",
};
-static struct clk secure_32k_fck = {
- .name = "secure_32k_fck",
+static struct clk secure_32k_ck = {
+ .name = "secure_32k_ck",
.ops = &clkops_null,
.rate = 32768,
.flags = RATE_FIXED,
The following changes since commit 0882e8dd3aad33eca41696d463bb896e6c8817eb:
Linus Torvalds (1):
Linux 2.6.30-rc2
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-fixes
Arun KS (1):
OMAP1: clock: Typo fix for clock in omap1
Huang Weiyi (1):
ARM: OMAP3: remove duplicated #include
Jarkko Nikula (1):
ARM: OMAP2: Remove defines and resource init for OMAP24XX EAC
Kevin Hilman (2):
ARM: OMAP2/3: GPIO: do not attempt to wake-enable
OMAP: dmtimer: enable all timers to be wakeup events
Ladislav Michl (3):
ARM: OMAP: MMC: Remove unused power_pin
ARM: OMAP1: Simplify board-h2 MMC setup
ARM: OMAP1: Fix mmc_set_power GPIO usage
Paul Walmsley (4):
OMAP2xxx clock: init osc_ck, sys_ck internal lists early
OMAP2xxx clock: fix broken cpu_mask code
OMAP3 GPTIMER: fix GPTIMER12 IRQ
OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c
files
Roel Kluin (1):
ARM: OMAP2: possible division by 0
Roger Quadros (2):
ARM: OMAP3: Fixed spurious IRQ issue for GPIO interrupts
ARM: OMAP3: Clean up spurious interrupt check logic
Santosh Shilimkar (1):
ARM: OMAP: Fix for possible race condition in omap_free_dma()
Sergio Aguirre (1):
OMAP3: clock: Camera module doesn't have IDLEST bit
Tony Lindgren (2):
ARM: OMAP: Remove old dead gpio expander code
Merge branch 'omap-clock-fixes' into omap-fixes
arch/arm/mach-omap1/board-h2-mmc.c | 14 +---
arch/arm/mach-omap1/board-h3-mmc.c |6 +-
arch/arm/mach-omap1/board-h3.c | 101
arch/arm/mach-omap1/board-nokia770.c |6 +-
arch/arm/mach-omap1/mcbsp.c|4 +-
arch/arm/mach-omap2/board-h4.c | 95 --
arch/arm/mach-omap2/board-omap3beagle.c|4 +
arch/arm/mach-omap2/board-rx51.c |1 -
arch/arm/mach-omap2/clock24xx.c| 15 ++--
arch/arm/mach-omap2/clock24xx.h| 10 ++-
arch/arm/mach-omap2/clock34xx.h|7 +-
arch/arm/mach-omap2/devices.c | 33
arch/arm/mach-omap2/irq.c |4 +-
arch/arm/mach-omap2/timer-gp.c | 48 +++-
arch/arm/mach-omap2/usb-tusb6010.c |2 +-
arch/arm/plat-omap/dma.c | 13 ++--
arch/arm/plat-omap/dmtimer.c | 28 ---
arch/arm/plat-omap/gpio.c | 20 ++---
arch/arm/plat-omap/include/mach/dmtimer.h |2 +-
arch/arm/plat-omap/include/mach/eac.h | 100 ---
arch/arm/plat-omap/include/mach/gpioexpander.h | 35
arch/arm/plat-omap/include/mach/irda.h |4 -
arch/arm/plat-omap/include/mach/mmc.h |1 -
arch/arm/plat-omap/include/mach/timer-gp.h | 17
drivers/mmc/host/omap.c|2 -
25 files changed, 128 insertions(+), 444 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/mach/eac.h
delete mode 100644 arch/arm/plat-omap/include/mach/gpioexpander.h
create mode 100644 arch/arm/plat-omap/include/mach/timer-gp.h
RE: 2.6.29 and SDP3430
Thanks Richard for root casing the issue. Yes I also did observed this. Second time when framework calls "omap2_gp_timer_set_mode" set the periodic mode, R0 contains 0 (CLOCK_EVT_MODE_UNUSED) instead of 2(CLOCK_EVT_MODE_PERIODIC). The assembly generated looks shocking because it prepares the second function arguments in register R1 as expected and then 'pop' destroys it. A "push" before a function call is reasonable but this not quite understandable. Can this be taken up with Codesorcery team to check what is triggering compiler to generate such an assembly ? > -Original Message- > From: Woodruff, Richard > Sent: Tuesday, April 21, 2009 6:34 AM > To: Aguirre Rodriguez, Sergio Alberto; Mark Brown; Menon, > Nishanth; Tony Lindgren > Cc: Jarkko Nikula; linux-omap; Shilimkar, Santosh; Pandita, Vikram > Subject: RE: 2.6.29 and SDP3430 compiler error> > > So using defconfig and float I debugged around a bit and for > q3-2007 I see what looks to be compiler error. > > The parameter in R1 which sets PERIODIC mode for call to > clockevnet_set_mode()is destroyed. See PNG. I did make sure > at start_kernel the correct opcode was in place (no overwrite > later, no cache flush issue). > > If I apply hacks to reduce optimization scope the code does > go past hang. See attached hack. > > It seems kind of odd this would bite now after a lot of new > use. Perhaps the new mix of functions and layout triggered it. > > Regards, > Richard W. > > -- To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Replacing custom implementation for Mapping
From: Omar Ramirez Luna
Date: Mon, 20 Apr 2009 21:45:46 -0500
Subject: [PATCH] DSPBRIDGE: Replacing custom implementation for Mapping
DSPBRIDGE: Replacing custom implementation for Mapping
Currently, we walk through the entire page table
translating the addresses from virtual to physical
whenever we map a buffer. This custom implementation
is meant to be optimized for performance, but it bypasses
the standard memory management subsystem.
This patch removes the custom implementation and uses
the kernel APIs to get the virtual to physical maps.
Map times for DMM
Buffer | Kernel APIs | Custom Implement. |
Size | time (usec) |time (usec)|
4 KB | 427 |396|
64 KB |1038 |824|
1 MB |9827 | 7110|
4 MB | 37811 | 26916|
6 MB | 56366 | 39978|
Signed-off-by: Hari Kanigeri
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/wmd/tiomap3430.c | 484 +++
1 files changed, 149 insertions(+), 335 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 208f752..c32ee78 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -1,4 +1,3 @@
-
/*
* tiomap.c
*
@@ -133,9 +132,7 @@ static DSP_STATUS WMD_DEV_Create(OUT struct WMD_DEV_CONTEXT
**ppDevContext,
static DSP_STATUS WMD_DEV_Ctrl(struct WMD_DEV_CONTEXT *pDevContext, u32 dwCmd,
IN OUT void *pArgs);
static DSP_STATUS WMD_DEV_Destroy(struct WMD_DEV_CONTEXT *pDevContext);
-static DSP_STATUS TIOMAP_VirtToPhysical(struct mm_struct *mm, u32 ulMpuAddr,
- u32 ulNumBytes, u32 *numOfTableEntries,
- u32 *physicalAddrTable);
+static u32 user_va2pa(struct mm_struct *mm, u32 address);
static DSP_STATUS PteUpdate(struct WMD_DEV_CONTEXT *hDevContext, u32 pa,
u32 va, u32 size,
struct HW_MMUMapAttrs_t *mapAttrs);
@@ -270,6 +267,21 @@ static inline void flush_all(struct WMD_DEV_CONTEXT
*pDevContext)
tlb_flush_all(pDevContext->dwDSPMmuBase);
}
+void badpagedump(u32 pa, struct page *pg)
+{
+ printk(KERN_EMERG "DSPBRIDGE:MAP function: COUNT 0 FOR PA 0x%x\n", pa);
+ printk(KERN_EMERG "Bad page state in process '%s'\n"
+ "page:%p flags:0x%0*lx mapping:%p mapcount:%d count:%d\n"
+ "Trying to fix it up, but a reboot is needed\n"
+ "Backtrace:\n",
+ current->comm, pg, (int)(2*sizeof(unsigned long)),
+ (unsigned long)pg->flags, pg->mapping,
+ page_mapcount(pg), page_count(pg));
+ dump_stack();
+ BUG_ON(1);
+
+}
+
/*
* WMD_DRV_Entry
* purpose:
@@ -1352,11 +1364,16 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
DSP_STATUS status = DSP_SOK;
struct WMD_DEV_CONTEXT *pDevContext = hDevContext;
struct HW_MMUMapAttrs_t hwAttrs;
- u32 numOfActualTabEntries = 0;
- u32 *pPhysAddrPageTbl = NULL;
struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
- u32 temp = 0;
+ u32 write = 0;
+ u32 numUsrPgs = 0;
+ struct page *mappedPage, *pg;
+ s32 pgNum;
+ u32 va = ulVirtAddr;
+ struct task_struct *curr_task = current;
+ u32 pgI = 0;
+ u32 mpuAddr, pa;
DBG_Trace(DBG_ENTER, "> WMD_BRD_MemMap hDevContext %x, pa %x, va %x, "
"size %x, ulMapAttr %x\n", hDevContext, ulMpuAddr, ulVirtAddr,
@@ -1424,7 +1441,6 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
* virtual memory address space in order to be of use to us here! */
down_read(&mm->mmap_sem);
vma = find_vma(mm, ulMpuAddr);
- up_read(&mm->mmap_sem);
if (vma)
DBG_Trace(DBG_LEVEL6, "VMAfor UserBuf: ulMpuAddr=%x, "
"ulNumBytes=%x, vm_start=%x vm_end=%x vm_flags=%x \n",
@@ -1436,9 +1452,7 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
* user buffer is covered */
while ((vma != NULL) && (ulMpuAddr + ulNumBytes > vma->vm_end)) {
/* jump to the next VMA region */
- down_read(&mm->mmap_sem);
vma = find_vma(mm, vma->vm_end + 1);
- up_read(&mm->mmap_sem);
DBG_Trace(DBG_LEVEL6, "VMAfor UserBuf ulMpuAddr=%x, "
"ulNumBytes=%x, vm_start=%x vm_end=%x vm_flags=%x\n",
ulMpuAddr, ulNumBytes, vma->vm_start,
@@ -1449,44 +1463,100 @@ static DSP_STATUS WMD_BRD_MemMap(struct
WMD_DEV_CONTEXT *hDevContext,
"MPU Buffer !!! \n");
status = DSP_EINVALIDARG;
}
- if (DSP_FAILED(status))
- goto func_cont;
- pPhysAddrPageTbl = DMM_GetPhysi
RE: LDP broken in 2.6.30-rc 2
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
>Christensen, Mikkel
>Sent: Monday, April 20, 2009 3:28 PM
>To: linux-omap@vger.kernel.org
>Subject: LDP broken in 2.6.30-rc 2
>
>Hi,
>
>
>I cloned master a few days ago and when I boot up the OMAP3 LDP, the board
>seem to hang in the "i2c
>/dev entries driver" dialog and after a minute the kernel dumps. Have anybody
>else seen this problem?
>
>Log is below.
>
>Best regards,
> Mikkel
Here is the crash log after enabling all kernel debugging options on LDP with
master of L-O tree.
Code base: linux-omap master
Platform: LDP
Defconfig: enabled debugging options
[ 97.854797] i2c /dev entries driver
<1>Unable to handle kernel NULL pointer dereference at virtual address 009b
[ 113.881439] Unable to handle kernel NULL pointer dereference at virtual addre
ss 009b
<1>pgd = c0004000
[ 113.891387] pgd = c0004000
<1>[009b] *pgd=[ 113.896545] [009b] *pgd=
Internal error: Oops: 5 [#1]
[ 113.903076] Internal error: Oops: 5 [#1]
Modules linked in:[ 113.908630] Modules linked in:
CPU: 0Not tainted (2.6.30-rc2-omap1-05650-gdc1ac9c-dirty #5)
[ 113.917877] CPU: 0Not tainted (2.6.30-rc2-omap1-05650-gdc1ac9c-dirty #5)
PC is at device_add+0x2d8/0x630
[ 113.928039] PC is at device_add+0x2d8/0x630
LR is at __mutex_unlock_slowpath+0x70/0x10c
[ 113.936279] LR is at __mutex_unlock_slowpath+0x70/0x10c
pc : []lr : []psr: 2013
sp : c7817e80 ip : c78b8674 fp :
[ 113.950653] pc : []lr : []psr: 2013
[ 113.950653] sp : c7817e80 ip : c78b8674 fp :
r10: r9 : c7840928 r8 : c7841a60
[ 113.966217] r10: r9 : c7840928 r8 : c7841a60
r7 : c03b8d04 r6 : c7802be0 r5 : c7840920 r4 :
[ 113.976837] r7 : c03b8d04 r6 : c7802be0 r5 : c7840920 r4 :
r3 : 0007 r2 : c7840aa8 r1 : 0007 r0 : c7840aa8
[ 113.988739] r3 : 0007 r2 : c7840aa8 r1 : 0007 r0 : c7840aa8
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 114.001464] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kern
el
Control: 10c5387d Table: 80004019 DAC: 0017
[ 114.013366] Control: 10c5387d Table: 80004019 DAC: 0017
Process swapper (pid: 1, stack limit = 0xc78162e0)
[ 114.023803] Process swapper (pid: 1, stack limit = 0xc78162e0)
Stack: (0xc7817e80 to 0xc7818000)
[ 114.032806] Stack: (0xc7817e80 to 0xc7818000)
7e80: [ 114.037719] 7e80: c785e090 c785e090 3a393800 3a393800
c7840033 c7840033 0021 0021 c784092
0 c7840920
7ea0: [ 114.053222] 7ea0: c7841a60 c7841a60 0593 0593 c785e090 c785e090
c01be36
4 c01be364
7ec0: [ 114.068756] 7ec0: c03570f4 c03570f4 c78513c0 c78513c0 c03c86dc c03c86dc
c785e038 c785e038 c03e1dc0 c03e1dc0 c01be394 c01be394 c03570f4 c03570f4 c7817ef
4 c7817ef4
7ee0: [ 114.084259] 7ee0: c03c86f8 c03c86f8 c7817ef4 c7817ef4 c01ca380 c01ca380
c01c9918 c01c9918 c03570f4 c03570f4 0003 0003 c03c86f8 c03c86f8 c785e03
8 c785e038
7f00: [ 114.099792] 7f00: c03c86f8 c03c86f8 c01c9330 c01c9330 c01ca380 c01ca380
c01c9358 c01c9358 c7817f2c c7817f2c c03c86f8 c03c86f8 c01c0af
4 c01c0af4
7f20: [ 114.115295] 7f20: c03c8584 c03c8584 c03c85c0 c03c85c0 c03c8584 c03c8584
c784b6b0 c784b6b0 c785e114 c785e114 c03c86f
8 c03c86f8
7f40: [ 114.130828] 7f40: c03c8584 c03c8584
c01c8b0c c01c8b0c c03e1dc0 c03e1dc0 c03d0760 c03d0760 c01ca41
0 c01ca410
7f60: [ 114.146331] 7f60: c002391c c002391c c00239ec c00239ec c03d0760 c03d0760
c002e2dc c002e2dc c00e9338 c00e9338 c03d880c c03d880c c033ee2
4 c033ee24
7f80: [ 114.161865] 7f80: 0100 0100 024e 024e c78370a0 c78370a0
c03d880c c03d880c c03b6908 c03b6908 015f 015f c00e958
8 c00e9588
7fa0: [ 114.177368] 7fa0: c007e594 c007e594 c7838680 c7838680 c7817fb6 c7817fb6
c007e5b8 c007e5b8 c7810f60 c7810f60 353339ec 353339ec 0031 0031 000
0
7fc0: [ 114.192901] 7fc0: c002391c c002391c c00239ec c00239ec
c002366c c002366c 000
0
7fe0: [ 114.208404] 7fe0: c0008554 c0008554
c005795c c005795c 107fff11 107fff11 00fbff2
0 00fbff20
[] [ 114.224578] [] (device_add+0x2d8/0x630) (device_add+0x
2d8/0x630) from [] from [] (device_create_vargs+0x9c/0xac)
(device_create_vargs+0x9c/0xac)
[] [ 114.241668] [] (device_create_vargs+0x9c/0xac) (device
_create_vargs+0x9c/0xac) from [] from [] (device_create+0x20
/0x28)
(device_create+0x20/0x28)
[] [ 114.258941] [] (device_create+0x20/0x28) (device_creat
e+0x20/0x28) from [] from [] (i2cdev_
Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3
Kim Kyuwon writes:
> Sometimes, it is necessary to find out "what does wake up my board
> from suspend?". Notifying wake-up source feature may be used to blame
> unexpected wake-up events which increase power consumption. And user
> mode applications can act smartly according to the wake-up event from
> Suspend-to-RAM state to minimize power consumption. Note that this
> driver can't inform wake-up events from idle state. This driver uses
> sysfs interface to give information to user mode applications like:
>
> cat /sys/power/omap_resume_irq
> cat /sys/power/omap_resume_event
>
> This driver also privides the unified GPIO wake-up source
> configuration. specific GPIO settings in the board files are:
>
> /* Wakeup source configuration */
> static struct gpio_wake boardname_gpio_wake[] = {
> { 23, IRQF_TRIGGER_RISING,"BT_WAKEUP",1},
> { 24, IRQF_TRIGGER_RISING,"USB_DETECT", 1},
> };
>
> static struct omap_wake_platform_data boardname_wake_data = {
> .gpio_wakes = boardname_gpio_wake,
> .gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
> };
>
> static struct platform_device boardname_wakeup = {
> .name = "omap-wake",
> .id = -1,
> .dev= {
> .platform_data = &boardname_wake_data,
> },
> };
>
> The patch adds Kconfig options "OMAP34xx wakeup source support" under
> "System type"->"TI OMAP implementations" menu.
>
> Signed-off-by: Kim Kyuwon
Hi Kyuwon,
While I still like the concept of this driver, I'm still not quite
happy about how it is implemented for various reasons. Most of which
have to do with the fact that this driver does many things that really
should be the job of other layers. In particular, the list of
omap3_wake_events is a bit troubling. It really should be handled by
the omapdev layer. You'll see that you are duplicating the data that
is handled there. Rather, we should just extend the omapdev data to
handle the wakeup events for that device.
Also, I still think the WKST register reading should be done in the
PRCM interrupt handler. In your previous attempt, you were seeing a
bunch of non-device wakeup related interrupts. Can you try again
with the attached patch (thanks to Paul Walmseley) which should help
us debug why you were seeing spurious PRCM interrupts.
Also, I know we discussed this before, but I think the GPIO wakeup
source stuff really belongs in a separate patch, and if you think it
is still useful, and cannot be done by just enabling a GPIO IRQ from
the board file, I suggest you propose a patch to the generic GPIO
layer to add this interface.
> ---
> arch/arm/mach-omap2/Makefile |1 +
> arch/arm/mach-omap2/irq.c | 21 +-
> arch/arm/mach-omap2/prcm-common.h |4 +
> arch/arm/mach-omap2/prm-regbits-34xx.h |5 +
> arch/arm/mach-omap2/wake34xx.c | 681
>
> arch/arm/plat-omap/Kconfig |9 +
> arch/arm/plat-omap/include/mach/irqs.h |4 +
> arch/arm/plat-omap/include/mach/wake.h | 30 ++
> 8 files changed, 752 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/mach-omap2/wake34xx.c
> create mode 100644 arch/arm/plat-omap/include/mach/wake.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index e693efd..4d7dbca 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= pm24xx.o
> obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o
> obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
> +obj-$(CONFIG_OMAP_WAKE) += wake34xx.o
> endif
>
> # SmartReflex driver
> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
> index 700fc3d..18ac725 100644
> --- a/arch/arm/mach-omap2/irq.c
> +++ b/arch/arm/mach-omap2/irq.c
> @@ -33,9 +33,6 @@
> #define INTC_MIR_SET00x008c
> #define INTC_PENDING_IRQ00x0098
>
> -/* Number of IRQ state bits in each MIR register */
> -#define IRQ_BITS_PER_REG 32
> -
> /*
> * OMAP2 has a number of different interrupt controllers, each interrupt
> * controller is identified as its own "bank". Register definitions are
> @@ -193,6 +190,24 @@ int omap_irq_pending(void)
> return 0;
> }
>
> +void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
> +{
> + int i, j = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(irq_banks); i++) {
> + struct omap_irq_bank *bank = irq_banks + i;
> + int irq;
> +
> + for (irq = 0; irq < bank->nr_irqs && j < len;
> + irq += IRQ_BITS_PER_REG) {
> + int offset = irq & (~(IRQ_BITS_PER_REG - 1));
> +
> + pending_irqs[j++] = intc_bank_read_reg(bank,
> +
RE: 2.6.29 and SDP3430
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Mark Brown > Sent: Thursday, April 09, 2009 4:34 PM > To: Menon, Nishanth > Cc: Woodruff, Richard; Jarkko Nikula; linux-omap > Subject: Re: 2.6.29 and SDP3430 > > On Thu, Apr 09, 2009 at 01:32:27PM -0500, Menon, Nishanth wrote: > > > implementor 41 architecture 3 part 30 variant c rev 1 > > regulator_init_complete: incomplete constraints, leaving VAUX3 on > > That last message shouldn't be a problem - it means that if the machine > init code had requested it the regulator core would've powered off the > VAUX3 regulator since it has no users. Well, I just disabled TWL4030 regulator support (CONFIG_REGULATOR_TWL4030) and now it boots without problem... I'm using a SDP3430 VG9.0.0 with an ES3.1 chip. > -- > To unsubscribe from this list: send the line "unsubscribe 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: [PM PATCH] OMAP3: PM: Save and restore I2C wakeup sources
Aaro Koskinen writes:
> Save and restore I2C wakeup sources.
>
> Signed-off-by: Aaro Koskinen
Sorry for the delay, this one slipped through the cracks.
Pushing to PM branch.
Kevin
> ---
> drivers/i2c/busses/i2c-omap.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 50f3285..5ce055c 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -183,6 +183,7 @@ struct omap_i2c_dev {
> u16 sclhstate;
> u16 bufstate;
> u16 syscstate;
> + u16 westate;
> };
>
> static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
> @@ -242,6 +243,7 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
> omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
> omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev->bufstate);
> omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev->syscstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
> }
> dev->idle = 0;
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> @@ -316,8 +318,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>* WFI instruction.
>* REVISIT: Some wkup sources might not be needed.
>*/
> - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
> - OMAP_I2C_WE_ALL);
> + dev->westate = OMAP_I2C_WE_ALL;
> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
>
> }
> }
> --
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe 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 take 2] PM: OMAP: Fix build with CONFIG_OMAP_PM_NONE set
Roger Quadros writes: > From: Roger Quadros > Date: Wed, 8 Apr 2009 17:12:43 +0300 > Subject: [PATCH] PM: OMAP: Fix build with CONFIG_OMAP_PM_NONE set > > Removes undefined symbol link errors when CONFIG_OMAP_PM is set. > The required symbols are defined in common.c and omap-pm.h > Dummy variables mpu_oops, dsp_oops and l3_oops have to be defined > because they are used in a number of places > > It fixes the following link errors > > arch/arm/mach-omap2/built-in.o: In function `omap3_round_to_table_rate': > arch/arm/mach-omap2/clock34xx.c:956: undefined reference to `mpu_opps' > arch/arm/mach-omap2/clock34xx.c:956: undefined reference to `dsp_opps' > arch/arm/mach-omap2/clock34xx.c:956: undefined reference to `l3_opps' > arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_hw': > arch/arm/mach-omap2/io.c:241: undefined reference to > `omap_pm_if_early_init' > arch/arm/mach-omap2/io.c:246: undefined reference to `omap_pm_if_init' > make: *** [.tmp_vmlinux1] Error 1 > > Signed-off-by: Roger Quadros Thanks, pushing to PM branch today. Kevin > --- > arch/arm/plat-omap/common.c |6 ++ > arch/arm/plat-omap/include/mach/omap-pm.h |8 > 2 files changed, 14 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c > index 2866612..634ca39 100644 > --- a/arch/arm/plat-omap/common.c > +++ b/arch/arm/plat-omap/common.c > @@ -46,6 +46,12 @@ int omap_bootloader_tag_len; > struct omap_board_config_kernel *omap_board_config; > int omap_board_config_size; > > +#ifdef CONFIG_OMAP_PM_NONE > +struct omap_opp *mpu_opps; > +struct omap_opp *dsp_opps; > +struct omap_opp *l3_opps; > +#endif > + > #ifdef CONFIG_OMAP_BOOT_TAG > > static int __init parse_tag_omap(const struct tag *tag) > diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h > b/arch/arm/plat-omap/include/mach/omap-pm.h > index f0bbd36..5526e89 100644 > --- a/arch/arm/plat-omap/include/mach/omap-pm.h > +++ b/arch/arm/plat-omap/include/mach/omap-pm.h > @@ -58,9 +58,13 @@ extern struct omap_opp *l3_opps; > * framework starts. The "_if_" is to avoid name collisions with the > * PM idle-loop code. > */ > +#ifdef CONFIG_OMAP_PM_NONE > +#define omap_pm_if_early_init(a, b, c) 0 > +#else > int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table, >struct omap_opp *dsp_opp_table, >struct omap_opp *l3_opp_table); > +#endif > > /** > * omap_pm_if_init - OMAP PM init code called after clock fw init > @@ -68,7 +72,11 @@ int __init omap_pm_if_early_init(struct omap_opp > *mpu_opp_table, > * The main initialization code. OPP tables are passed in here. The > * "_if_" is to avoid name collisions with the PM idle-loop code. > */ > +#ifdef CONFIG_OMAP_PM_NONE > +#define omap_pm_if_init() 0 > +#else > int __init omap_pm_if_init(void); > +#endif > > /** > * omap_pm_if_exit - OMAP PM exit code > -- > 1.5.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] twl4030: Add some error checking to twl4030 init
Whitespace-fixed version and passed through checkpatch.pl
Check for return values of i2c read/write operations and size of scripts being
uploaded to TWL4030
Signed-off-by: Amit Kucheria
---
drivers/mfd/twl4030-core.c |2 +-
drivers/mfd/twl4030-power.c | 49 ++
2 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 769b34b..067b02e 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -358,7 +358,7 @@ EXPORT_SYMBOL(twl4030_i2c_read);
int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
{
- /* 2 bytes offset 1 contains the data offset 0 is used by i2c_write */
+ /* 2 bytes: offset 1 contains the data, offset 0 is used by i2c_write */
u8 temp_buffer[2] = { 0 };
/* offset 1 contains the data */
temp_buffer[1] = value;
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9dc493b..b4b636d 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -257,36 +257,38 @@ static int __init config_warmreset_sequence(u8 address)
return err;
}
-void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
{
int rconfig_addr;
+ int err;
u8 type;
if (rconfig->resource > NUM_OF_RESOURCES) {
printk(KERN_ERR
"TWL4030 Resource %d does not exist\n",
rconfig->resource);
- return;
+ return -EINVAL;
}
rconfig_addr = res_config_addrs[rconfig->resource];
/* Set resource group */
-
if (rconfig->devgroup >= 0)
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
rconfig->devgroup << 5,
rconfig_addr + DEVGROUP_OFFSET);
+ if (err < 0) {
+ printk(KERN_ERR "TWL4030 failed to program devgroup");
+ return err;
+ }
/* Set resource types */
-
- if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
- &type,
- rconfig_addr + TYPE_OFFSET) < 0) {
- printk(KERN_ERR
- "TWL4030 Resource %d type could not read\n",
+ err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &type,
+ rconfig_addr + TYPE_OFFSET);
+ if (err < 0) {
+ printk(KERN_ERR "TWL4030 Resource %d type could not be read\n",
rconfig->resource);
- return;
+ return err;
}
if (rconfig->type >= 0) {
@@ -299,8 +301,14 @@ void twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
type |= rconfig->type2 << 3;
}
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
type, rconfig_addr + TYPE_OFFSET);
+ if (err < 0) {
+ printk(KERN_ERR "TWL4030 failed to program resource type");
+ return err;
+ }
+
+ return 0;
}
@@ -309,6 +317,12 @@ static int __init load_triton_script(struct twl4030_script
*tscript)
u8 address = triton_next_free_address;
int err;
+ /* Make sure the script isn't going beyond last valid address */
+ if ((address + tscript->size) > (END_OF_SCRIPT-1)) {
+ printk(KERN_ERR "TWL4030 script too big error\n");
+ return -EINVAL;
+ }
+
err = twl4030_write_script(address, tscript->script, tscript->size);
if (err)
return err;
@@ -346,15 +360,22 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
for (i = 0; i < triton2_scripts->size; i++) {
err = load_triton_script(triton2_scripts->scripts[i]);
- if (err)
+ if (err < 0) {
+ printk(KERN_ERR "TWL4030 failed to load scripts");
break;
+ }
}
resconfig = triton2_scripts->resource_config;
if (resconfig) {
while (resconfig->resource) {
- twl4030_configure_resource(resconfig);
+ err = twl4030_configure_resource(resconfig);
resconfig++;
+ if (err < 0) {
+ printk(KERN_ERR
+ "TWL4030 failed to configure resource");
+ break;
+ }
}
}
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to
RE: [PATCH] twl4030: Add some error checking to twl4030 init
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Amit Kucheria
> Sent: Monday, April 20, 2009 6:20 PM
> To: linux-omap@vger.kernel.org
> Subject: [PATCH] twl4030: Add some error checking to twl4030 init
>
> Check for return values of i2c read/write operations and size
> of scripts being
> uploaded to TWL4030
>
> Signed-off-by: Amit Kucheria
[sp] You may want to fix the leading whitespaces in some places.
see few instanes below.
Otherwise, looks pretty straight.
> ---
> drivers/mfd/twl4030-core.c |2 +-
> drivers/mfd/twl4030-power.c | 52
> +++---
> 2 files changed, 39 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
> index 769b34b..067b02e 100644
> --- a/drivers/mfd/twl4030-core.c
> +++ b/drivers/mfd/twl4030-core.c
> @@ -358,7 +358,7 @@ EXPORT_SYMBOL(twl4030_i2c_read);
> int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
> {
>
> - /* 2 bytes offset 1 contains the data offset 0 is used
> by i2c_write */
> + /* 2 bytes: offset 1 contains the data, offset 0 is
> used by i2c_write */
> u8 temp_buffer[2] = { 0 };
> /* offset 1 contains the data */
> temp_buffer[1] = value;
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 9dc493b..8f5d149 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -257,36 +257,40 @@ static int __init
> config_warmreset_sequence(u8 address)
> return err;
> }
>
> -void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
> +static int __init twl4030_configure_resource(struct
> twl4030_resconfig *rconfig)
> {
> int rconfig_addr;
> + int err;
> u8 type;
>
> if (rconfig->resource > NUM_OF_RESOURCES) {
> printk(KERN_ERR
> "TWL4030 Resource %d does not exist\n",
> rconfig->resource);
> - return;
> + return -EINVAL;
> }
>
> rconfig_addr = res_config_addrs[rconfig->resource];
>
> /* Set resource group */
> -
> if (rconfig->devgroup >= 0)
> - twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> + err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> rconfig->devgroup << 5,
> rconfig_addr + DEVGROUP_OFFSET);
> + if (err < 0) {
> + printk(KERN_ERR
> +"TWL4030 failed to program devgroup");
[sp] ...here...
> + return err;
> + }
>
> /* Set resource types */
> -
> - if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
> - &type,
> - rconfig_addr +
> TYPE_OFFSET) < 0) {
> + err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &type,
> + rconfig_addr + TYPE_OFFSET);
> + if (err < 0) {
> printk(KERN_ERR
> - "TWL4030 Resource %d type could not read\n",
> - rconfig->resource);
> - return;
> +"TWL4030 Resource %d type could not be read\n",
> +rconfig->resource);
[sp] ...here...
> + return err;
> }
>
> if (rconfig->type >= 0) {
> @@ -299,8 +303,15 @@ void twl4030_configure_resource(struct
> twl4030_resconfig *rconfig)
> type |= rconfig->type2 << 3;
> }
>
> - twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> + err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> type, rconfig_addr + TYPE_OFFSET);
> + if (err < 0) {
> + printk(KERN_ERR
> +"TWL4030 failed to program resource type");
[sp] ...here...
> + return err;
> + }
> +
> + return 0;
>
> }
>
> @@ -309,6 +320,12 @@ static int __init
> load_triton_script(struct twl4030_script *tscript)
> u8 address = triton_next_free_address;
> int err;
>
> + /* Make sure the script isn't going beyond last valid address */
> + if ((address + tscript->size) > (END_OF_SCRIPT-1)) {
> + printk(KERN_ERR "TWL4030 script too big error\n");
> + return -EINVAL;
> + }
> +
> err = twl4030_write_script(address, tscript->script,
> tscript->size);
> if (err)
> return err;
> @@ -346,15 +363,22 @@ void __init twl4030_power_init(struct
> twl4030_power_data *triton2_scripts)
>
> for (i = 0; i < triton2_scripts->size; i++) {
> err = load_triton_script(triton2_scripts->scripts[i]);
> - if (err)
> + if (err < 0) {
> + printk(KERN_ERR "TWL4030 failed to load
> scripts");
> break;
> + }
> }
>
> resconfig = triton2_scripts->resource_config;
LDP broken in 2.6.30-rc 2
Hi, I cloned master a few days ago and when I boot up the OMAP3 LDP, the board seem to hang in the "i2c /dev entries driver" dialog and after a minute the kernel dumps. Have anybody else seen this problem? Log is below. Best regards, Mikkel Bytes transferred = 1851164 (1c3f1c hex) ## Booting image at 8000 ... Image Name: Linux-2.6.30-rc2-omap1-05648-g8e Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1851100 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... <5>Linux version 2.6.30-rc2-omap1-05648-g8e58316-dirty (a0389...@a0389005-desktop) (gcc version 4.2.3 (Sourcery G++ Lite 20089 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP LDP board Memory policy: ECC disabled, Data cache writeback <7>On node 0 totalpages: 28672 <7>free_area_init_node: node 0, pgdat c0391ac8, node_mem_map c03ad000 <7> Normal zone: 224 pages used for memmap <7> Normal zone: 0 pages reserved <7> Normal zone: 28448 pages, LIFO batch:7 <6>OMAP3430 ES2.1 <6>SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 28448 <5>Kernel command line: console=ttyS2,115200n8 noinitrd mem=112M root=/dev/nfs rw nfsroot=128.247.85.60:/home/a0389051/omap34p <6>NR_IRQS:402 <6>Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz <6>GPMC revision 5.0 <6>IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts <6>Total of 96 interrupts on 1 active controller <6>OMAP34xx GPIO hardware version 2.5 PID hash table entries: 512 (order: 9, 2048 bytes) <6>OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 <6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) <6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) <6>Memory: 112MB = 112MB total <5>Memory: 109780KB available (3176K code, 292K data, 144K init, 0K highmem) <6>Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696) Mount-cache hash table entries: 512 <6>CPU: Testing write buffer coherency: ok <6>net_namespace: 520 bytes <6>regulator: core version 0.5 <6>NET: Registered protocol family 16 <3>mmci-omap-hs.0: use which platform_data? <6>OMAP DMA hardware revision 4.0 bio: create slab at 0 <6>i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz <6>twl4030: PIH (irq 7) chaining IRQs 368..375 <6>twl4030: power (irq 373) chaining IRQs 376..383 <3>twl4030_bci: use which platform_data? <3>twl4030_gpio: use which platform_data? <6>twl4030: gpio (irq 368) chaining IRQs 384..401 <3>twl4030_keypad: use which platform_data? <3>twl4030_madc: use which platform_data? <3>twl4030_usb: use which platform_data? <3>twl4030_reg.17: use which platform_data? <3>set_machine_constraints: invalid 'VUSB1V5' voltage constraints <3>twl4030_reg twl4030_reg.17: can't register VUSB1V5, -22 <4>twl4030_reg: probe of twl4030_reg.17 failed with error -22 <3>twl4030_reg.18: use which platform_data? <3>set_machine_constraints: invalid 'VUSB1V8' voltage constraints <3>twl4030_reg twl4030_reg.18: can't register VUSB1V8, -22 <4>twl4030_reg: probe of twl4030_reg.18 failed with error -22 <3>twl4030_reg.19: use which platform_data? <3>set_machine_constraints: invalid 'VUSB3V1' voltage constraints <3>twl4030_reg twl4030_reg.19: can't register VUSB3V1, -22 <4>twl4030_reg: probe of twl4030_reg.19 failed with error -22 <6>i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz <6>i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz <5>SCSI subsystem initialized <3>twl4030_usb twl4030_usb: ldo init failed <6>usbcore: registered new interface driver usbfs <6>usbcore: registered new interface driver hub <6>usbcore: registered new device driver usb <6>musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 <7>Switched to high resolution mode on CPU 0 <7>musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X)) <7>musb_hdrc: MHDRC RTL version 1.400 <7>musb_hdrc: setup fifo_mode 4 <7>musb_hdrc: 29/31 max ep, 15424/16384 memory <7>musb_hdrc: hw_ep 0shared, max 64 <7>musb_hdrc: hw_ep 1tx, max 512 <7>musb_hdrc: hw_ep 1rx, max 512 <7>musb_hdrc: hw_ep 2tx, max 512 <7>musb_hdrc: hw_ep 2rx, max 512 <7>musb_hdrc: hw_ep 3tx, max 512 <7>musb_hdrc: hw_ep 3rx, max 512 <7>musb_hdrc: hw_ep 4tx, max 512 <7>musb_hdrc: hw_ep 4rx, max 512 <7>musb_hdrc: hw_ep 5tx, max 512 <7>musb_hdrc: hw_ep 5rx, max 512 <7>musb_hdrc: hw_ep 6tx, max 512 <7>musb_hdrc: hw_ep 6rx, max 512 <7>musb_hdrc: hw_ep 7tx, max 512 <7>musb_hdrc: hw_ep 7rx, max 512 <7>musb_hdrc: hw_ep 8tx, max 512 <7>musb_hdrc: hw_ep 8rx, max 512 <7>musb_hdrc: hw_ep 9tx, max 512 <7>musb_hdrc: hw_ep 9rx, max 512 <7>musb_hdrc: hw_ep 10tx, max 5
[no subject]
subscribe -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Compilation Issue with OMAP_SMARTREFLEX, CONFIG_USB_ARCH_HAS_EHCI
Hi, The following set of .config settings: #CONFIG_PM set to OFF CONFIG_USB_ARCH_HAS_EHCI=y triggers the following compile error: ... CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `omap3_sr_init': usb-ehci.c:(.init.text+0xc0c): undefined reference to `power_kobj' make: *** [.tmp_vmlinux1] Error 1 When EHCI is turned off, the error becomes: arch/arm/mach-omap2/built-in.o: In function `omap3_sr_init': board-omap3evm-flash.c:(.init.text+0xc0c): undefined reference to `power_kobj' make: *** [.tmp_vmlinux1] Error 1 Error disappears when Smart reflex is turned off: #OMAP_SMARTREFLEX set to OFF Than the kernel compiles OK. -dmt -- To unsubscribe from this list: send the line "unsubscribe 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] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Monday 20 April 2009 12:31:53 Hiremath, Vaibhav wrote: > Thanks, > Vaibhav Hiremath > > > -Original Message- > > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > > Sent: Saturday, April 18, 2009 9:24 PM > > To: Hiremath, Vaibhav > > Cc: linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; > > DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux- > > o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; > > R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam > > Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support > > under V4L2 framework > > > > On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: > > > Thanks, > > > Vaibhav Hiremath > > > > > > > > APPROACH 3 - > > > > > -- > > > > > > > > > > . > > > > > > It makes sense, since such memory-to-memory devices will mostly > > > > being > > > > > used from codecs context. And this would be more clear from user > > > application. > > > > To be honest, I don't see the need for this. I think > > TYPE_VIDEO_CAPTURE and > > TYPE_VIDEO_OUTPUT are perfectly fine. > > [Hiremath, Vaibhav] Agreed, and you will also find implementation of > driver aligned to this which I have shared with you. > > > > And as acknowledged by you, we can use VIDIOC_S_FMT for setting > > > parameters. > > > > > > One thing I am not able to convince myself is that, using "priv" > > > > field > > > > > for custom configuration. > > > > I agree. Especially since you cannot use it as a pointer to addition > > information. > > > > > I would prefer and recommend capability based > > > interface, where application will query the capability of the > > > > device for > > > > > luma enhancement, filter coefficients (number of coeff and depth), > > > interpolation type, etc... > > > > > > This way we can make sure that, any such future devices can be > > > > adapted by > > > > > this framework. > > > > The big question is how many of these capabilities are 'generic' and > > how > > many are very much hardware specific. I am leaning towards using the > > extended control API for this. It's a bit awkward to implement in > > drivers > > at the moment, but that should improve in the future when a lot of > > the > > control handling code will move into the new core framework. > > > > I really need to know more about the sort of features that > > omap/davinci > > offer (and preferably also for similar devices by other > > manufacturers). > > [Hiremath, Vaibhav] Hans, Can we have IRC session for this? We will > discuss this in detail and try to get closure on it. > > Again I would request you to join me and mauro on IRC chat, I will be > staying online tomorrow. No problem (assuming we don't have another major network outage as we had today at work). It would be helpful if you could mail a summary of the capabilities that are needed but are not yet in the API. Also note that I have to leave at 16:15 (UTC+2). Magnus, does the SuperH also have resizing/previewer capabilities? And if so, is there a datasheet available with detailed information? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] n800 build error in clock24xx.c: 'secure_32k_ck' undeclared
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): dc1ac9cea15e3317badd0fdece931926413f6759 PatchWorks http://patchwork.kernel.org/patch/19037/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=dc1ac9cea15e3317badd0fdece931926413f6759 -- To unsubscribe from this list: send the line "unsubscribe 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: n800 build error in clock24xx.c: 'secure_32k_ck' undeclared
On Mon, 20 Apr 2009, Paul Walmsley wrote:
> On Fri, 17 Apr 2009, Kalle Valo wrote:
>
> > In file included from arch/arm/mach-omap2/clock24xx.c:46:
> > arch/arm/mach-omap2/clock24xx.h:1801: error: 'secure_32k_ck' undeclared
> > here (not in a function)
> >
> > Any hints?
>
> This is a bug in the version of fa9ef57a1efdd4e7c41a42db71d99b9b69e9b356 I
> pushed. The new clock definition in clock24xx.h for "secure_32k_fck"
> should be for "secure_32k_ck". Just talked with Tony about this; he's
> going to re-pull a fixed version of that patch today.
Here's the patch BTW:
- Paul
Index: linux-omap-2.6/arch/arm/mach-omap2/clock24xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock24xx.h 2009-04-20
10:42:21.0 -0700
+++ linux-omap-2.6/arch/arm/mach-omap2/clock24xx.h 2009-04-20
10:46:09.0 -0700
@@ -625,8 +625,8 @@ static struct clk func_32k_ck = {
.clkdm_name = "wkup_clkdm",
};
-static struct clk secure_32k_fck = {
- .name = "secure_32k_fck",
+static struct clk secure_32k_ck = {
+ .name = "secure_32k_ck",
.ops= &clkops_null,
.rate = 32768,
.flags = RATE_FIXED,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC for supporting multiple PMICs
All,
Based on our understanding/experiences till so far, we suggest the
following:
a) Remove all the PMIC-board related stuff from the EVM specific file (
like board-omap3evm.c) and keep it in a separate file (board-omap3evm-
pmic.c). All platform related Inits should be done here.
b) PMIC initialization and other PMIC specific routines (enable/disable,
get/set voltage/current) should be done in the PMIC specific file like
drivers/regulator/pmic.c
c) Probing for PMIC during runtime could be done in either of the ways
specified in the attached sample template.
d) Generic wrappers should be provided to have a consistent interface
for accessing PMIC registers and to use its supported features.
Please find attached the sample implementation of the things mentioned
above and provide your feedback.
Thanks and Regards,
Anuj Aggarwal
Platform Support Products
Texas Instruments Incorporated
/*
* linux/arch/arm/mach-omap2/board-omap3evm-pmic.c
*
* Copyright (C) 2009 Texas Instruments Incorporated
*
* copyright
*/
#include
#include
#include
#include
#include
/* --- other generic headers --- */
/*
*
* If we are okay with controlled ifdef in this file then we can follow
* the scheme below...
*
*/
#ifdef CONFIG_TWL4030_CORE
/*
* Definitions specific to TWL4030
*/
#endif /* CONFIG_TWL4030_CORE */
#ifdef CONFIG_PMIC_TPS62350
/*
* Definitions specific to TPS62350
*/
#endif /* CONFIG_PMIC_TPS62350 */
#ifdef CONFIG_PMIC_TPS65023
/*
* Definitions specific to TPS65023
*/
#endif /* CONFIG_PMIC_TPS65023 */
int omap3_evm_pmic_init()
{
#ifdef CONFIG_TWL4030_CORE
/* do stuff specific to TWL4030 */
#elif CONFIG_PMIC_TPS62350
/* do stuff specific to TPS62350 */
#elif CONFIG_PMIC_TPS65023
/* do stuff specific to TPS65023 */
#endif
}
/* =
*
* If we would like to run same image on multiple OMAP3EVMs and don't really
* care about the image size, then we can follow the scheme below...
*
* Though there is still an open question of how to detect PMIC at runtime?
* =
*/
/*
* Definitions specific to TWL4030
*/
/*
* Definitions specific to TPS62350
*/
/*
* Definitions specific to TPS65023
*/
static int flag_pmic_twl4030 = 0;
static int flag_pmic_tps6235x = 0;
static int flag_pmic_tps65023 = 0;
/*
* Detect the current PMIC
* Set one of the flags
*/
static inline int detect_pmic()
{
/* How? Any suggestions?? */
}
static inline int use_pmic_twl4030()
{
return flag_pmic_twl4030;
}
static inline int use_pmic_tps6235x()
{
return flag_pmic_tps6235x;
}
static inline int use_pmic_tps65023()
{
return flag_pmic_tps65023;
}
int omap3_evm_pmic_init()
{
if (use_pmic_twl4030())
{
/* do stuff specific to TWL4030 */
}
else if (use_pmic_tps6235x())
{
/* do stuff specific to TPS62350 */
}
else if (use_pmic_tps65023())
{
/* do stuff specific to TPS65023 */
}
}
/*
*
* Generic wrappers to access PMIC registers and use its supported features...
*
*/
int omap3_pmic_i2c_read()
{
/* Approach 1 */
#ifdef CONFIG_TWL4030_CORE
/* do stuff specific to TWL4030 */
#elif CONFIG_PMIC_TPS62350
/* do stuff specific to TPS62350 */
#elif CONFIG_PMIC_TPS65023
/* do stuff specific to TPS65023 */
#endif
/* Approach 2 */
if (use_pmic_twl4030())
{
/* do stuff specific to TWL4030 */
}
else if (use_pmic_tps6235x())
{
/* do stuff specific to TPS62350 */
}
else if (use_pmic_tps65023())
{
/* do stuff specific to TPS65023 */
}
}
int omap3_pmic_i2c_write()
{
/* just for illustration */
}
int omap3_evm_enable_lcd()
{
/* just for illustration */
}
int omap3_evm_disable_lcd()
{
/* just for illustration */
}
int omap3_evm_enable_dvi()
{
/* just for illustration */
}
int omap3_evm_disable_dvi()
{
/* just for illustration */
}
int omap3_evm_enable_tv()
{
/* just for illustration */
}
int omap3_evm_disable_tv()
{
/* just for illustration */
}
Re: n800 build error in clock24xx.c: 'secure_32k_ck' undeclared
Hi Kalle, On Fri, 17 Apr 2009, Kalle Valo wrote: > In file included from arch/arm/mach-omap2/clock24xx.c:46: > arch/arm/mach-omap2/clock24xx.h:1801: error: 'secure_32k_ck' undeclared here > (not in a function) > > Any hints? This is a bug in the version of fa9ef57a1efdd4e7c41a42db71d99b9b69e9b356 I pushed. The new clock definition in clock24xx.h for "secure_32k_fck" should be for "secure_32k_ck". Just talked with Tony about this; he's going to re-pull a fixed version of that patch today. Thanks for the find, - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: n800 build error in clock24xx.c: 'secure_32k_ck' undeclared
* green [090419 18:43]: > Kalle Valo wrote at 2009-04-19 09:58 -0600: > > green writes: > > > > > Kalle Valo wrote at 2009-04-17 14:44 -0600: > > > > > >> arch/arm/kernel/sys_oabi-compat.c: In function 'sys_oabi_epoll_wait': > > >> arch/arm/kernel/sys_oabi-compat.c:289: error: implicit declaration of > > >> function 'kmalloc' > > >> arch/arm/kernel/sys_oabi-compat.c:289: warning: assignment makes pointer > > >> from integer without a cast > > >> arch/arm/kernel/sys_oabi-compat.c:302: error: implicit declaration of > > >> function 'kfree' > > >> arch/arm/kernel/sys_oabi-compat.c: In function 'sys_oabi_semtimedop': > > >> arch/arm/kernel/sys_oabi-compat.c:325: warning: assignment makes pointer > > >> from integer without a cast > > > > > > I see nearly the same: > > > > > > arch/arm/kernel/sys_oabi-compat.c: In function ‘sys_oabi_epoll_wait’: > > > arch/arm/kernel/sys_oabi-compat.c:288: error: implicit declaration of > > > function ‘kmalloc’ > > > arch/arm/kernel/sys_oabi-compat.c:288: error: ‘GFP_KERNEL’ undeclared > > > (first use in this function) > > > > I think that's the same error. Most probably my tree was dirty and > > that's the line numbers are different. > > I was noticing the 'GFP_KERNEL' undeclared error rather than the line numbers. Looks like the above is fixed by cbb55092a674bcfd9774637a06d0f1511763aa2c, I'll git cherry-pick that one. The secure_32k_ck is still undefined though. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] musb_hdrc: Fix compile omap3 boards if CONFIG_PM is not set
Hi,
Here's a minimal build fix, please queue.
Regards,
Tony
>From 4b1d3e9c32fb21056a1a8a20374be82e1d97d2c0 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Mon, 20 Apr 2009 10:06:35 -0700
Subject: [PATCH] musb_hdrc: Fix compile omap3 boards if CONFIG_PM is not set
Otherwise we'll get:
drivers/usb/musb/musb_core.c:2206: error: 'musb_resume_early' undeclared
here (not in a function)
CONFIG_PM is not merged yet to mainline three for omap3.
Signed-off-by: Tony Lindgren
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0112353..6c1cc8e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2192,6 +2192,7 @@ static int musb_resume_early(struct platform_device *pdev)
#else
#define musb_suspend NULL
#define musb_resume NULL
+#define musb_resume_early NULL
#endif
static struct platform_driver musb_driver = {
Re: [PATCH 00/02] OMAP3 clock: Remove virtual clock nodes
"Nayak, Rajendra" writes: > Resending this patch-set with some issues of tabs-to-spaces reported by Kevin > Hilman > fixed and also some warning removals from Jean Pihet. > > Patches apply on latest linux-omap pm branch + > [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver sent on 04/15/09 > http://marc.info/?l=linux-omap&m=123980012121460&w=2 > Thanks, pushing this whitespace-fixed version of series to PM branch today. Kevin > > This patch set removes the virtual clock node implementation for > VDD1/2 on omap3 which was causing issues with recursive locking of spinlocks. > All references to virtual clock nodes from resource framework and cpufreq > driver are removed. Resource framework now uses individual dpll clock > nodes to do frequency scaling. > Most of the functionality implemented as part of the virtual clock nodes > is now implemented internally in the resource framework. > > Thanks to Tero Kristo who has implemented > most of these changes. > > regards, > Rajendra > -- > To unsubscribe from this list: send the line "unsubscribe 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: ehci problem on OMAP35xx
On Wed, Apr 15, 2009 at 9:34 PM, twebb wrote: > I'm having issues getting USB up and going on HSUSB2/EHCI on > OMAP35xx-based hardware (very similar to beagle board). We're using > an SMSC3317 connected to HSUSB2, and in turn, the 3317 is connected to > an onboard hub - a SMSC USB2513. When the hub is removed from reset, > it appears that handshaking/chirping starts to happen between xcvr and > hub, but ends with the code announcing that it is "unable to enumerate > USB device on port 2". I'm guessing it's failing because we never see > PED set in the PORTSC_1 reg (and we are seeing PO=1 which doesn't make > any sense). Is the driver chirping properly? Is it identifying the speed properly? I had a similar problem. Please check the D+ and D- line for loading. I used SMSC3320 which also had similar problems because of ESD protection thermistors placed in the board. > I'm running a l-o git-based 2.6.28-omap1 kernel with > omap3_beagle_defconfig. Beagle board works fine (with patch to > ehci-omap.c and with CONFIG_USB_EHCI_HCD turned on), but my hardware > (with virtually same xcvr and and onboard hub) does not. > > Kind of new to this low level USB functionality, so a few questions... > 1. Any ideas why we'd see PORTSC_1[PO] = 1? > 2. Any suggestions on debugging basic connectivity between 35xx EHCI > controller and transceiver + hub? > > Thanks, > twebb > -- > To unsubscribe from this list: send the line "unsubscribe 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] [DSPBRIDGE] Various compile warning fixes
Miku,
> The field in question is declared in
> arch/arm/plat-omap/include/dspbridge/_chnl_sm.h in line 120 as
> u32, so checking for negative value makes no sense unless you
> modify struct SHM too.
-- You are right. I missed checking the declaration in _chnl_sm.h
Thank you,
Best regards,
Hari
> -Original Message-
> From: mika.kukko...@nokia.com [mailto:mika.kukko...@nokia.com]
> Sent: Monday, April 20, 2009 12:23 AM
> To: Kanigeri, Hari; Gupta, Ramesh; ameya.pala...@nokia.com
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] [DSPBRIDGE] Various compile warning fixes
>
> >-Original Message-
> >From: linux-omap-ow...@vger.kernel.org
> >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
> >Kanigeri, Hari
> >Sent: 17 April, 2009 17:21
> >To: Gupta, Ramesh; Palande Ameya (Nokia-D/Helsinki);
> >linux-omap@vger.kernel.org
> >Subject: RE: [PATCH] [DSPBRIDGE] Various compile warning fixes
> >
> >Ameya,
> >
> >-if (!(chnlId >= 0) || !(chnlId < CHNL_MAXCHANNELS)) {
> >+if (chnlId >= CHNL_MAXCHANNELS) {
> >
> >-- How about declaring chnlId as s32 so that the checks can be
> >extended to negative values too ?
>
> The field in question is declared in
> arch/arm/plat-omap/include/dspbridge/_chnl_sm.h in line 120 as
> u32, so checking for negative value makes no sense unless you
> modify struct SHM too.
>
> --MiKu
--
To unsubscribe from this list: send the line "unsubscribe 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] twl4030: Add some error checking to twl4030 init
Check for return values of i2c read/write operations and size of scripts being
uploaded to TWL4030
Signed-off-by: Amit Kucheria
---
drivers/mfd/twl4030-core.c |2 +-
drivers/mfd/twl4030-power.c | 52 +++---
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 769b34b..067b02e 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -358,7 +358,7 @@ EXPORT_SYMBOL(twl4030_i2c_read);
int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
{
- /* 2 bytes offset 1 contains the data offset 0 is used by i2c_write */
+ /* 2 bytes: offset 1 contains the data, offset 0 is used by i2c_write */
u8 temp_buffer[2] = { 0 };
/* offset 1 contains the data */
temp_buffer[1] = value;
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9dc493b..8f5d149 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -257,36 +257,40 @@ static int __init config_warmreset_sequence(u8 address)
return err;
}
-void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
{
int rconfig_addr;
+ int err;
u8 type;
if (rconfig->resource > NUM_OF_RESOURCES) {
printk(KERN_ERR
"TWL4030 Resource %d does not exist\n",
rconfig->resource);
- return;
+ return -EINVAL;
}
rconfig_addr = res_config_addrs[rconfig->resource];
/* Set resource group */
-
if (rconfig->devgroup >= 0)
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
rconfig->devgroup << 5,
rconfig_addr + DEVGROUP_OFFSET);
+ if (err < 0) {
+ printk(KERN_ERR
+ "TWL4030 failed to program devgroup");
+ return err;
+ }
/* Set resource types */
-
- if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
- &type,
- rconfig_addr + TYPE_OFFSET) < 0) {
+ err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &type,
+ rconfig_addr + TYPE_OFFSET);
+ if (err < 0) {
printk(KERN_ERR
- "TWL4030 Resource %d type could not read\n",
- rconfig->resource);
- return;
+ "TWL4030 Resource %d type could not be read\n",
+ rconfig->resource);
+ return err;
}
if (rconfig->type >= 0) {
@@ -299,8 +303,15 @@ void twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
type |= rconfig->type2 << 3;
}
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
type, rconfig_addr + TYPE_OFFSET);
+ if (err < 0) {
+ printk(KERN_ERR
+ "TWL4030 failed to program resource type");
+ return err;
+ }
+
+ return 0;
}
@@ -309,6 +320,12 @@ static int __init load_triton_script(struct twl4030_script
*tscript)
u8 address = triton_next_free_address;
int err;
+ /* Make sure the script isn't going beyond last valid address */
+ if ((address + tscript->size) > (END_OF_SCRIPT-1)) {
+ printk(KERN_ERR "TWL4030 script too big error\n");
+ return -EINVAL;
+ }
+
err = twl4030_write_script(address, tscript->script, tscript->size);
if (err)
return err;
@@ -346,15 +363,22 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
for (i = 0; i < triton2_scripts->size; i++) {
err = load_triton_script(triton2_scripts->scripts[i]);
- if (err)
+ if (err < 0) {
+ printk(KERN_ERR "TWL4030 failed to load scripts");
break;
+ }
}
resconfig = triton2_scripts->resource_config;
if (resconfig) {
while (resconfig->resource) {
- twl4030_configure_resource(resconfig);
+ err = twl4030_configure_resource(resconfig);
resconfig++;
+ if (err < 0) {
+ printk(KERN_ERR
+ "TWL4030 failed to configure resource");
+ break;
+ }
}
}
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath > -Original Message- > From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] > Sent: Monday, April 20, 2009 4:15 PM > To: Hiremath, Vaibhav > Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez, > Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- > o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; > R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam > Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support > under V4L2 framework > > Hello Vaibhav, > > This is user manual of S3C6400 (not much different from S3C6410) > http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 > 00X_UserManual_rev1-0_2008-02_661558um.pdf > > That SoC is from my company but not from the same division of mine. > Actually I'm doing this driver job without any request from chip > delivering division. I'm doing this because this is so challenging > and > want better generic driver :-) > > Take a look at the user manual and please let me know your opinion. > In my understanding scaler and some camera interface feature in > S3C64XX are very similar to the features in Omap3. > [Hiremath, Vaibhav] Thanks for the link, I will go though it and get back to you. > Cheers, > > Nate > > On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav > wrote: > > > > > > Thanks, > > Vaibhav Hiremath > > > >> -Original Message- > >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >> ow...@vger.kernel.org] On Behalf Of Dongsoo Kim > >> Sent: Sunday, April 19, 2009 12:06 PM > >> To: Hans Verkuil > >> Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; Aguirre > >> Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); > linux- > >> o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh > R; > >> R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam > >> Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support > >> under V4L2 framework > >> > >> Hello Hans and Hiremath, > >> > >> One of my recent job is making S3C64XX camera interface driver > (even > >> though other jobs of mine are not finished yet...;-() > >> And, what a incident! S3C64XX has also similar H/W block in > camera > >> interface. > >> Resizer in S3C camera interface can be used in system wide like > the > >> one in Omap3. > >> > > [Hiremath, Vaibhav] Can you share the spec for the same; I wanted > to verify the configuration part of it? What all configuration is > exported to the user? > > > >> But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE > >> and > >> TYPE_VIDEO_OUTPUT. > >> I thought that is was enough. Actually I took omap video out > (vout?) > >> for reference :-) > > > > [Hiremath, Vaibhav] I have also implemented the driver is the same > way and also working with Hans to get it reviewed. But there are > some configuration like coeff., luma enhancement, etc... need to > export to the user, where we need to add mechanism in V4L2 > framework. > > > > Since we have one more device where we are demanding for M-to-M > operation, I think it is important to go through it. Can you share > some documents of your IP for better understanding. > > > > > >> Cheers, > >> > >> Nate > >> > >> > >> 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: > >> > >> > On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: > >> >> Thanks, > >> >> Vaibhav Hiremath > >> >> > >> APPROACH 3 - > >> -- > >> > >> . > >> > >> (Any other approach which I could not think of would be > >> >>> > >> >>> appreciated) > >> >>> > >> I would prefer second approach, since this will provide > >> standard > >> interface to applications independent on underneath > hardware. > >> > >> There may be many number of such configuration parameters > >> required > >> >>> > >> >>> for > >> >>> > >> different such devices, we need to work on this and come up > >> with > >> >>> > >> >>> some > >> >>> > >> standard capability fields covering most of available > devices. > >> > >> Does anybody have some other opinions on this? > >> Any suggestions will be helpful here, > >> >>> > >> >>> FYI: I have very little time to look at this for the next 2-3 > >> weeks. > >> >>> As you > >> >>> know I'm working on the last pieces of the v4l2_subdev > >> conversion > >> >>> for 2.6.30 > >> >>> that should be finished this week. After that I'm attending > the > >> >>> Embedded > >> >>> Linux Conference in San Francisco. > >> >>> > >> >>> But I always thought that something like this would be just a > >> >>> regular video > >> >>> device that can do both 'output' and 'capture'. For a resizer > I > >> >>> would > >> >>> expect that you set the 'output' size (the size of your > source > >> >>> image) and > >> >>> the 'capture' size (the size of the resized image), then just > >> send > >> >>> the > >> >>> frames to the device (== resizer) and get them back on the > >> capture > >> >>> side
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C6400X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav wrote: > > > Thanks, > Vaibhav Hiremath > >> -Original Message- >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> ow...@vger.kernel.org] On Behalf Of Dongsoo Kim >> Sent: Sunday, April 19, 2009 12:06 PM >> To: Hans Verkuil >> Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; Aguirre >> Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; >> R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam >> Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support >> under V4L2 framework >> >> Hello Hans and Hiremath, >> >> One of my recent job is making S3C64XX camera interface driver (even >> though other jobs of mine are not finished yet...;-() >> And, what a incident! S3C64XX has also similar H/W block in camera >> interface. >> Resizer in S3C camera interface can be used in system wide like the >> one in Omap3. >> > [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify > the configuration part of it? What all configuration is exported to the user? > >> But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE >> and >> TYPE_VIDEO_OUTPUT. >> I thought that is was enough. Actually I took omap video out (vout?) >> for reference :-) > > [Hiremath, Vaibhav] I have also implemented the driver is the same way and > also working with Hans to get it reviewed. But there are some configuration > like coeff., luma enhancement, etc... need to export to the user, where we > need to add mechanism in V4L2 framework. > > Since we have one more device where we are demanding for M-to-M operation, I > think it is important to go through it. Can you share some documents of your > IP for better understanding. > > >> Cheers, >> >> Nate >> >> >> 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: >> >> > On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: >> >> Thanks, >> >> Vaibhav Hiremath >> >> >> APPROACH 3 - >> -- >> >> . >> >> (Any other approach which I could not think of would be >> >>> >> >>> appreciated) >> >>> >> I would prefer second approach, since this will provide >> standard >> interface to applications independent on underneath hardware. >> >> There may be many number of such configuration parameters >> required >> >>> >> >>> for >> >>> >> different such devices, we need to work on this and come up >> with >> >>> >> >>> some >> >>> >> standard capability fields covering most of available devices. >> >> Does anybody have some other opinions on this? >> Any suggestions will be helpful here, >> >>> >> >>> FYI: I have very little time to look at this for the next 2-3 >> weeks. >> >>> As you >> >>> know I'm working on the last pieces of the v4l2_subdev >> conversion >> >>> for 2.6.30 >> >>> that should be finished this week. After that I'm attending the >> >>> Embedded >> >>> Linux Conference in San Francisco. >> >>> >> >>> But I always thought that something like this would be just a >> >>> regular video >> >>> device that can do both 'output' and 'capture'. For a resizer I >> >>> would >> >>> expect that you set the 'output' size (the size of your source >> >>> image) and >> >>> the 'capture' size (the size of the resized image), then just >> send >> >>> the >> >>> frames to the device (== resizer) and get them back on the >> capture >> >>> side. >> >> >> >> [Hiremath, Vaibhav] Yes, it is possible to do that. >> >> >> >> Hans, >> >> >> >> I went through the link referred by Sergio and I think we should >> >> inherit >> >> some implementation for CODECs here for such devices. >> >> >> >> V4L2_BUF_TYPE_CODECIN - To access the input format. >> >> V4L2_BUF_TYPE_CODECOUT - To access the output format. >> >> >> >> It makes sense, since such memory-to-memory devices will mostly >> being >> >> used from codecs context. And this would be more clear from user >> >> application. >> > >> > To be honest, I don't see the need for this. I think >> > TYPE_VIDEO_CAPTURE and >> > TYPE_VIDEO_OUTPUT are perfectly fine. >> > >> >> And as acknowledged by you, we can use VIDIOC_S_FMT for setting >> >> parameters. >> >> >> >> One thing I am not able to convince myself is that, using "priv" >> >> field >> >> for custom configuration. >>
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath > -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Saturday, April 18, 2009 9:24 PM > To: Hiremath, Vaibhav > Cc: linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; > DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux- > o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; > R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam > Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support > under V4L2 framework > > On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: > > Thanks, > > Vaibhav Hiremath > > > > > > APPROACH 3 - > > > > -- > > > > > > > > . > > It makes sense, since such memory-to-memory devices will mostly > being > > used from codecs context. And this would be more clear from user > > application. > > To be honest, I don't see the need for this. I think > TYPE_VIDEO_CAPTURE and > TYPE_VIDEO_OUTPUT are perfectly fine. > [Hiremath, Vaibhav] Agreed, and you will also find implementation of driver aligned to this which I have shared with you. > > And as acknowledged by you, we can use VIDIOC_S_FMT for setting > > parameters. > > > > One thing I am not able to convince myself is that, using "priv" > field > > for custom configuration. > > I agree. Especially since you cannot use it as a pointer to addition > information. > > > I would prefer and recommend capability based > > interface, where application will query the capability of the > device for > > luma enhancement, filter coefficients (number of coeff and depth), > > interpolation type, etc... > > > > This way we can make sure that, any such future devices can be > adapted by > > this framework. > > The big question is how many of these capabilities are 'generic' and > how > many are very much hardware specific. I am leaning towards using the > extended control API for this. It's a bit awkward to implement in > drivers > at the moment, but that should improve in the future when a lot of > the > control handling code will move into the new core framework. > > I really need to know more about the sort of features that > omap/davinci > offer (and preferably also for similar devices by other > manufacturers). > [Hiremath, Vaibhav] Hans, Can we have IRC session for this? We will discuss this in detail and try to get closure on it. Again I would request you to join me and mauro on IRC chat, I will be staying online tomorrow. > > > > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe 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] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Dongsoo Kim > Sent: Sunday, April 19, 2009 12:06 PM > To: Hans Verkuil > Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; Aguirre > Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- > o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; > R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam > Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support > under V4L2 framework > > Hello Hans and Hiremath, > > One of my recent job is making S3C64XX camera interface driver (even > though other jobs of mine are not finished yet...;-() > And, what a incident! S3C64XX has also similar H/W block in camera > interface. > Resizer in S3C camera interface can be used in system wide like the > one in Omap3. > [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the configuration part of it? What all configuration is exported to the user? > But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE > and > TYPE_VIDEO_OUTPUT. > I thought that is was enough. Actually I took omap video out (vout?) > for reference :-) [Hiremath, Vaibhav] I have also implemented the driver is the same way and also working with Hans to get it reviewed. But there are some configuration like coeff., luma enhancement, etc... need to export to the user, where we need to add mechanism in V4L2 framework. Since we have one more device where we are demanding for M-to-M operation, I think it is important to go through it. Can you share some documents of your IP for better understanding. > Cheers, > > Nate > > > 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: > > > On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: > >> Thanks, > >> Vaibhav Hiremath > >> > APPROACH 3 - > -- > > . > > (Any other approach which I could not think of would be > >>> > >>> appreciated) > >>> > I would prefer second approach, since this will provide > standard > interface to applications independent on underneath hardware. > > There may be many number of such configuration parameters > required > >>> > >>> for > >>> > different such devices, we need to work on this and come up > with > >>> > >>> some > >>> > standard capability fields covering most of available devices. > > Does anybody have some other opinions on this? > Any suggestions will be helpful here, > >>> > >>> FYI: I have very little time to look at this for the next 2-3 > weeks. > >>> As you > >>> know I'm working on the last pieces of the v4l2_subdev > conversion > >>> for 2.6.30 > >>> that should be finished this week. After that I'm attending the > >>> Embedded > >>> Linux Conference in San Francisco. > >>> > >>> But I always thought that something like this would be just a > >>> regular video > >>> device that can do both 'output' and 'capture'. For a resizer I > >>> would > >>> expect that you set the 'output' size (the size of your source > >>> image) and > >>> the 'capture' size (the size of the resized image), then just > send > >>> the > >>> frames to the device (== resizer) and get them back on the > capture > >>> side. > >> > >> [Hiremath, Vaibhav] Yes, it is possible to do that. > >> > >> Hans, > >> > >> I went through the link referred by Sergio and I think we should > >> inherit > >> some implementation for CODECs here for such devices. > >> > >> V4L2_BUF_TYPE_CODECIN - To access the input format. > >> V4L2_BUF_TYPE_CODECOUT - To access the output format. > >> > >> It makes sense, since such memory-to-memory devices will mostly > being > >> used from codecs context. And this would be more clear from user > >> application. > > > > To be honest, I don't see the need for this. I think > > TYPE_VIDEO_CAPTURE and > > TYPE_VIDEO_OUTPUT are perfectly fine. > > > >> And as acknowledged by you, we can use VIDIOC_S_FMT for setting > >> parameters. > >> > >> One thing I am not able to convince myself is that, using "priv" > >> field > >> for custom configuration. > > > > I agree. Especially since you cannot use it as a pointer to > addition > > information. > > > >> I would prefer and recommend capability based > >> interface, where application will query the capability of the > >> device for > >> luma enhancement, filter coefficients (number of coeff and > depth), > >> interpolation type, etc... > >> > >> This way we can make sure that, any such future devices can be > >> adapted by > >> this framework. > > > > The big question is how many of these capabilities are 'generic' > and > > how > > many are very much hardware specific. I am leaning towards using > the > > extended control API for this. It's a bit awkward to implement in > > drivers > > at the moment, but that should improve in the future when a lot of > the > > control handling code will move into the new core fr
