Re: omap3-isp : panic using previewer from V4L input
Hi Laurent, I have a beagle xm board, but no sensor board. Is it possible to have the omap3-isp initialised ? I would like to try my program on a beagle board to eliminate any hardware related problem. From the board file in mainline kernel, it seems omap3_init_camera is not called, do you know any kernel tree where isp is initialized for beagle board ? Thank you, Jean-Philippe François 2013/5/7 jean-philippe francois jp.franc...@cynove.com: 2013/5/7 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Jean-Philippe, (CC'ed linux-omap) On Monday 06 May 2013 10:59:07 jean-philippe francois wrote: Hi, I am trying to use the previewer to debayer pictures coming from the filesystem instead of the capture hardware. The media-ctl links are as follows : preview V4L input - preview pad 0 (sink), preview pad 1(src) -preview V4L output. Input output format is set via media-ctl for the preview element, and via the V4L2 api for the V4L2 file descriptors. I am using USERPTR buffer allocated via memalign, and the application goes like this : REQBUFS 1 buf on on input REQBUFS 1 buf on output alloc buffers QBUF on input QBUF on output STREAMON on output STREAMON on input DQBUF on output. The board either panics or hangs (though HUNG_TASK_DETECTION and SOFT_LOCKUP_DETECTION is set) Does it happen every time you run the application, including on the first run after a cold boot ? Yes, every time. Previewer usage in device to memory mode works fine. Tested on 3.6.11 and 3.9 with the same results. The only difference observed so far between runs is that sometimes the board hangs without anything printed on the console. Please find attached the panic log, and the application code. (log inlined) omap3isp omap3isp: can't find source, failing now omap3isp omap3isp: can't find source, failing now Those are harmless warnings. I have a fix for them, I'll repost it. [ cut here ] Kernel BUG at c019bb1c [verbose debug info unavailable] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: omap3_isp ov10630(O) CPU: 0Tainted: G O (3.9.0 #3) PC is at omap3_l3_app_irq+0x3c/0xbc L3 APP interconnect timeout errors are not supposed to happen. This is the first time I see one. Maybe someone on the linux-omap list will have some clues regarding how to debug this. LR is at handle_irq_event_percpu+0x28/0x10c pc : [c019bb1c]lr : [c006b354]psr: 2193 sp : c0507e58 ip : 0006 fp : r10: cf804dc0 r9 : 9e65 r8 : 0020 r7 : r6 : 1000 r5 : r4 : cf87f3c0 r3 : r2 : 1000 r1 : cf8ffc80 r0 : 1000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8fa80019 DAC: 0015 Process swapper (pid: 0, stack limit = 0xc0506230) Stack: (0xc0507e58 to 0xc0508000) 7e40: 0002 cf87f3c0 7e60:001a c006b354 cf804dc0 cf87f3c0 cf804dc0 c0506000 7e80:cf87f3c0 c0507f0c 0020 9e65 c054d640 c006b490 cf804dc0 c0507f80 7ea0: c006da68 001a c006ac44 001a c000ebc8 000a c0507ed8 7ec0:001a c0008594 c054d600 c003400c 6113 c000df00 0001 c054d600 7ee0:0101 c0506000 0002 c0507fb4 0020 9e65 7f00:c054d640 c0526f28 c0507f20 c054d600 c003400c 6113 7f20:cf805c40 c0506000 c0511c98 c0507fb4 80004059 0035 7f40:c0507fb4 80004059 413fc082 c003440c 0035 c000ebcc 7f60:0025 c0507f80 0035 c0008594 c0506008 c000ed78 2013 c000df00 7f80:c0547548 c050fb50 0001 c0506000 c050e0d8 c04fb954 c0510844 7fa0:80004059 413fc082 c0507fc8 c0506008 c000ed78 7fc0:2013 c036c958 c04da7a8 c04da344 7fe0:c04fb958 271ae41c 10c53c7d c050e028 80008070 [c019bb1c] (omap3_l3_app_irq+0x3c/0xbc) from [c006b354] (handle_irq_event_percpu+0x28/0x10c) [c006b354] (handle_irq_event_percpu+0x28/0x10c) from [c006b490] (handle_irq_event+0x58/0x74) [c006b490] (handle_irq_event+0x58/0x74) from [c006da68] (handle_level_irq+0xd8/0x110) [c006da68] (handle_level_irq+0xd8/0x110) from [c006ac44] (generic_handle_irq+0x20/0x30) [c006ac44] (generic_handle_irq+0x20/0x30) from [c000ebc8] (handle_IRQ+0x60/0x84) [c000ebc8] (handle_IRQ+0x60/0x84) from [c0008594] (omap3_intc_handle_irq+0x58/0x6c) [c0008594] (omap3_intc_handle_irq+0x58/0x6c) from [c000df00] (__irq_svc+0x40/0x70) Exception stack(0xc0507ed8 to 0xc0507f20) 7ec0: 0001 c054d600 7ee0:0101 c0506000 0002 c0507fb4 0020 9e65 7f00:c054d640 c0526f28 c0507f20 c054d600 c003400c 6113 [c000df00] (__irq_svc+0x40/0x70) from [c003400c] (__do_softirq+0x60/0x184) [c003400c]
am3517: failed to boot 3.10-rc1
Trying to boot 3.10-rc1 on an am3515 based board. With the same .config as 3.7 the system comes to RTC stops there. I've also tried make omap2plus_defconfig with no visible difference. I'm booting from MMC card and it will be detected by the system. Kernel is from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git, latest commit f722406faae2d073cc1d01063d1123c35425939e. Are there any pending patches needed to boot on am3517? Here bootlog: Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-3.10.0-rc1-dirty Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3750728 Bytes = 3.6 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.10.0-rc1-dirty (YegorYefremov@development1) (gcc version 4.5.3 (Buildroot 2012.05-rc2-00022-g339098e) ) #27 SMP Tue May 14 11:10:08 CEST 2013 [0.00] CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3517/AM3517 EVM [0.00] Ignoring tag cmdline (using the default kernel command line) [0.00] cma: CMA: reserved 16 MiB at 8e80 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM3517 ES1.1 (l2cache sgx neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0ecd000 s13632 r8192 d15040 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 nohlt [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 229308k/229308k available, 32836k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0689084 (6661 kB) [0.00] .init : 0xc068a000 - 0xc06e2540 ( 354 kB) [0.00] .data : 0xc06e4000 - 0xc0764f68 ( 516 kB) [0.00].bss : 0xc0764f68 - 0xc0cc6b58 (5511 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [0.00] OMAP clockevent source: timer1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] OMAP clocksource: 32k_counter at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001464] Calibrating delay loop... 329.31 BogoMIPS (lpj=1646592) [0.119567] pid_max: default: 32768 minimum: 301 [0.120330] Security Framework initialized [0.120544] Mount-cache hash table entries: 512 [0.125946] CPU: Testing write buffer coherency: ok [0.128051] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.128204] Setting up static identity map for 0xc04a99c8 - 0xc04a9a20 [0.133209] Brought up 1 CPUs [0.133270] SMP: Total of 1 processors activated (329.31 BogoMIPS). [0.133270] CPU: All CPU(s) started in SVC mode. [0.137817] devtmpfs: initialized [0.205139] pinctrl core: initialized pinctrl subsystem [0.212188] regulator-dummy: no parameters [0.217559] NET: Registered protocol family 16 [0.230255] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.233306] omap-gpmc omap-gpmc: GPMC revision 5.0 [0.249542] OMAP GPIO hardware version 2.5 [0.276336] omap_mux_init: Add partition:
Re: [PATCH] spi: spi-omap2-mcspi.c: Add dts for slave device configuration.
@@ -745,6 +781,11 @@ static int omap2_mcspi_setup_transfer(struct
spi_device *spi,
mcspi = spi_master_get_devdata(spi-master);
spi_cntrl = mcspi-master;
+ if (!cd spi-dev.of_node) {
+ cd = omap2_mcspi_get_slave_ctrldata(spi);
+ spi-controller_data = cd;
Here you call omap2_mcspi_get_slave_ctrldata function that allocate
memory for cd structure, but this memory never freed.
Also, why do you read DT data in omap2_mcspi_setup_transfer function?
Under certain conditions the omap2_mcspi_setup_transfer function may be
calling for each transfer and each call it will check (!cd
spi-dev.of_node) condition.
Consider to move DT data read code from omap2_mcspi_setup_transfer to
omap2_mcspi_setup function and free spi-controller_data pointer in
omap2_mcspi_cleanup function.
--
To unsubscribe from this list: send the line unsubscribe 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] usb: dwc3: Fix compilation break when building with USB_DWC3_DUAL_ROLE=y
The commit: 388e5c5 usb: dwc3: remove dwc3 dependency on host AND gadget breaks compilation when USB=y, USB_GADGET=m, USB_DWC3=y and USB_DWC3_DUAL_ROLE=y. drivers/built-in.o: In function `dwc3_gadget_giveback': drivers/usb/dwc3/gadget.c:271: undefined reference to `usb_gadget_unmap_request' drivers/built-in.o: In function `__dwc3_gadget_kick_transfer': drivers/usb/dwc3/gadget.c:1005: undefined reference to `usb_gadget_unmap_request' drivers/built-in.o: In function `__dwc3_gadget_ep_queue': drivers/usb/dwc3/gadget.c:1073: undefined reference to `usb_gadget_map_request' drivers/built-in.o: In function `dwc3_gadget_reset_interrupt': drivers/usb/dwc3/gadget.c:2165: undefined reference to `usb_gadget_set_state' drivers/built-in.o: In function `dwc3_gadget_init': drivers/usb/dwc3/gadget.c:2647: undefined reference to `usb_add_gadget_udc' drivers/built-in.o: In function `dwc3_gadget_exit': drivers/usb/dwc3/gadget.c:2681: undefined reference to `usb_del_gadget_udc' drivers/built-in.o: In function `__dwc3_ep0_do_control_data': drivers/usb/dwc3/ep0.c:929: undefined reference to `usb_gadget_map_request' drivers/usb/dwc3/ep0.c:906: undefined reference to `usb_gadget_map_request' drivers/built-in.o: In function `dwc3_ep0_set_config': drivers/usb/dwc3/ep0.c:575: undefined reference to `usb_gadget_set_state' drivers/built-in.o: In function `dwc3_ep0_set_address': drivers/usb/dwc3/ep0.c:520: undefined reference to `usb_gadget_set_state' drivers/usb/dwc3/ep0.c:522: undefined reference to `usb_gadget_set_state' drivers/built-in.o: In function `dwc3_ep0_set_config': drivers/usb/dwc3/ep0.c:556: undefined reference to `usb_gadget_set_state' Making changes similar to patch: 71a5e61 usb: chipidea: fix and improve dependencies if usb host or gadget support is built as module Let us limit the DWC3 mode to depend on corresponding usb-subsystem and USB_DWC3. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Felipe Balbi ba...@ti.com Cc: Fengguang Wu fengguang...@intel.com --- drivers/usb/dwc3/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index ea5ee9c..757aa18 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -19,21 +19,21 @@ choice config USB_DWC3_HOST bool Host only mode - depends on USB + depends on USB=y || USB=USB_DWC3 help Select this when you want to use DWC3 in host mode only, thereby the gadget feature will be regressed. config USB_DWC3_GADGET bool Gadget only mode - depends on USB_GADGET + depends on USB_GADGET=y || USB_GADGET=USB_DWC3 help Select this when you want to use DWC3 in gadget mode only, thereby the host feature will be regressed. config USB_DWC3_DUAL_ROLE bool Dual Role mode - depends on (USB USB_GADGET) + depends on ((USB=y || USB=USB_DWC3) (USB_GADGET=y || USB_GADGET=USB_DWC3)) help This is the default mode of working of DWC3 controller where both host and gadget features are enabled. -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am3517: failed to boot 3.10-rc1
On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote: Trying to boot 3.10-rc1 on an am3515 based board. With the same .config as 3.7 the system comes to RTC stops there. I've also tried make omap2plus_defconfig with no visible difference. I'm booting from MMC card and it will be detected by the system. Kernel is from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git, latest commit f722406faae2d073cc1d01063d1123c35425939e. Are there any pending patches needed to boot on am3517? does v3.9 work ? Can you bisect ? -- balbi signature.asc Description: Digital signature
Re: am3517: failed to boot 3.10-rc1
On 14.05.2013 14:52, Felipe Balbi wrote: On Tue, May 14, 2013 at 11:24:44AM +0200, Yegor Yefremov wrote: Trying to boot 3.10-rc1 on an am3515 based board. With the same .config as 3.7 the system comes to RTC stops there. I've also tried make omap2plus_defconfig with no visible difference. I'm booting from MMC card and it will be detected by the system. Kernel is from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git, latest commit f722406faae2d073cc1d01063d1123c35425939e. Are there any pending patches needed to boot on am3517? does v3.9 work ? Can you bisect ? 'git checkout v3.9' version is working, will try to bisect. Yegor -- To unsubscribe from this list: send the line unsubscribe 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: configs: omap2plus_defconfig: enable USB bits which work
Felipe Balbi ba...@ti.com writes: those USB bits work fine, so we can enable them safely. Plus, without USB_PHY EHCI wouldn't work and it would take quite a few bogus error reports until all users got the new changes. Signed-off-by: Felipe Balbi ba...@ti.com --- comiple tested only. Would be great to have someone testing on actual HW. Right now I don't have access to my HW. cheers arch/arm/configs/omap2plus_defconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c1ef64b..a1fc0ca 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -74,6 +74,7 @@ CONFIG_CMA=y CONFIG_CONNECTOR=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y +CONFIG_OMAP_OCP2SCP=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y @@ -206,10 +207,18 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=y NAK (on this particular change) This cannot be enable by default yet as EHCI *still* breaks core retention[1] (which has been broken since at least v3.5, almost a year now.) CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y CONFIG_USB_LIBUSUAL=y +CONFIG_USB_DWC3=m +CONFIG_USB_DWC3_DEBUG=y +CONFIG_USB_DWC3_VERBOSE=y CONFIG_USB_TEST=y +CONFIG_USB_PHY=y +CONFIG_NOP_USB_XCEIV=y These two are needed though since before v3.10, they used to be selected, and without them USB host doesn't work on Panda anymore. +CONFIG_OMAP_USB2=y +CONFIG_OMAP_USB3=y I guess these are for OMAP5? The changelog should probably describe which bits are for which platforms for those of us not intimate with USB. CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_DEBUG_FILES=y Kevin [1] commit 06b4ba529528fbf9c24ce37b7618f4b0264750e2 Author: Kevin Hilman khil...@ti.com Date: Fri Jul 6 11:20:28 2012 -0700 ARM: OMAP2+: omap2plus_defconfig: EHCI driver is not stable, disable it The EHCI driver is not stable enough to be enabled by default. In v3.5, it has at least the following problems: - warning dump during bootup - hang during suspend - prevents CORE powerdomain from entering retention during idle (even when no USB devices connected.) This demonstrates that this driver has not been thoroughly tested and therfore should not be enabled in the default defconfig. In addition, the problems above cause new PM regressions which need be addressed before this driver should be enabled in the default defconfig. Signed-off-by: Kevin Hilman khil...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
Joel A Fernandes joelag...@ti.com writes: Calling runtime PM API for every block causes serious perf hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The runtime PM API is also called those many times. We call runtime_pm_get_sync only at beginning on the session (cra_init) and runtime_pm_put at the end. This result in upto a 50% speedup as below. This doesn't make the driver to keep the system awake as runtime get/put is only called during a crypto session which completes usually quickly. Before: root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s After: root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s While at it, also drop enter and exit pr_debugs, in related code. tracers can be used for that. Tested on a Beaglebone (AM335x SoC) board. Signed-off-by: Joel A Fernandes joelag...@ti.com Acked-by: Kevin Hilman khil...@linaro.org Thanks for the updated changelog. 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
[PATCH v3] ARM:dts:omap4-panda:Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 40 +
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..2b516af 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,7 +16,7 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
heartbeat {
label = pandaboard::status1;
@@ -137,6 +137,20 @@
};
};
+omap4_pmx_wkup {
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..8d1ba03 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,43 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = pandaboard::status1;
+ gpios = gpio4 14 0;
+ linux,default-trigger = heartbeat;
+ };
+ mmc {
+ label = pandaboard::status2;
+ gpios = gpio1 8 0;
+ linux,default-trigger = gpio;
+ };
+};
+
+omap4_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_gpio_pins
+ ;
+
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+omap4_pmx_wkup {
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM : omap : remove __init for _enable_preprogram
_enable_preprogram is marked as __init, but is called from _enable which is not.
This results in oops once init is freed.
Fix this by removing the __init marker.
Signed-off-by: Jean-Philippe François jp.franc...@cynove.com
Index: b/arch/arm/mach-omap2/omap_hwmod.c
===
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2066,7 +2066,7 @@
* do so is present in the hwmod data, then call it and pass along the
* return value; otherwise, return 0.
*/
-static int __init _enable_preprogram(struct omap_hwmod *oh)
+static int _enable_preprogram(struct omap_hwmod *oh)
{
if (!oh-class-enable_preprogram)
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP5: select SCU
From: Vincent Stehlé v-ste...@ti.com OMAP5 needs SCU in SMP. This fixes the following link errors: arch/arm/mach-omap2/built-in.o: In function `scu_gp_set': arch/arm/mach-omap2/sleep44xx.S:132: undefined reference to `scu_power_mode' arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear': arch/arm/mach-omap2/sleep44xx.S:229: undefined reference to `scu_power_mode' arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus': arch/arm/mach-omap2/omap-smp.c:211: undefined reference to `scu_enable' arch/arm/mach-omap2/built-in.o: In function `omap4_smp_init_cpus': arch/arm/mach-omap2/omap-smp.c:185: undefined reference to `scu_get_core_count' Signed-off-by: Vincent Stehlé v-ste...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..81690a2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -109,6 +109,7 @@ config SOC_OMAP5 select ARM_CPU_SUSPEND if PM select ARM_GIC select CPU_V7 + select HAVE_ARM_SCU if SMP select HAVE_SMP select COMMON_CLK select HAVE_ARM_ARCH_TIMER -- 1.7.10.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] ARM: omap2: gpmc: fix compilation warning
From: Vincent Stehlé v-ste...@ti.com
Fix the following compilation warning:
arch/arm/mach-omap2/gpmc.c: In function 'gpmc_probe_generic_child':
arch/arm/mach-omap2/gpmc.c:1477:4: warning: format '%x' expects argument of
type 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat]
Signed-off-by: Vincent Stehlé v-ste...@ti.com
Cc: triv...@kernel.org
---
Tony wrote:
You should just change the format for dev_err instead of the casting.
Hi,
Sorry for the late answer; it seems this is a bit more complicated after all,
as res.start can be 32b or 64b in LPAE. The common solution seems to be: cast
to long long in all cases and print accordingly. Would you like this better?
Best regards,
V.
arch/arm/mach-omap2/gpmc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 6c4da12..e74501e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1473,8 +1473,8 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
*/
ret = gpmc_cs_remap(cs, res.start);
if (ret 0) {
- dev_err(pdev-dev, cannot remap GPMC CS %d to 0x%x\n,
- cs, res.start);
+ dev_err(pdev-dev, cannot remap GPMC CS %d to 0x%llx\n,
+ cs, (long long)res.start);
goto err;
}
--
1.7.10.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] ARM : omap : remove __init for _enable_preprogram
jp.franc...@cynove.com writes:
_enable_preprogram is marked as __init, but is called from _enable which is
not.
This results in oops once init is freed.
Fix this by removing the __init marker.
Signed-off-by: Jean-Philippe François jp.franc...@cynove.com
Acked-by: Kevin Hilman khil...@linaro.org
Tony, this should probably be queued for v3.10-rc, and tagged for stable.
Kevin
Index: b/arch/arm/mach-omap2/omap_hwmod.c
===
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2066,7 +2066,7 @@
* do so is present in the hwmod data, then call it and pass along the
* return value; otherwise, return 0.
*/
-static int __init _enable_preprogram(struct omap_hwmod *oh)
+static int _enable_preprogram(struct omap_hwmod *oh)
{
if (!oh-class-enable_preprogram)
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM : omap : remove __init for _enable_preprogram
On Tue, May 14, 2013 at 06:07:01PM +0200, jp.franc...@cynove.com wrote: _enable_preprogram is marked as __init, but is called from _enable which is not. This results in oops once init is freed. Fix this by removing the __init marker. Signed-off-by: Jean-Philippe François jp.franc...@cynove.com formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] gpio/omap: replace open coded read-modify-write with _gpio_rmw function.
By also making it return the modified value, we save the readl
needed to update the context.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
---
drivers/gpio/gpio-omap.c | 162 ++
1 file changed, 50 insertions(+), 112 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 159f5c5..082919e 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -87,6 +87,19 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+static inline u32 _gpio_rmw(void __iomem *base, u32 reg, u32 mask, bool set)
+{
+ u32 l = __raw_readl(base + reg);
+
+ if (set)
+ l |= mask;
+ else
+ l = ~mask;
+
+ __raw_writel(l, base + reg);
+ return l;
+}
+
static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
return gpio_irq - bank-irq_base + bank-chip.base;
@@ -94,20 +107,10 @@ static int irq_to_gpio(struct gpio_bank *bank, unsigned
int gpio_irq)
static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input)
{
- void __iomem *reg = bank-base;
- u32 l;
-
- reg += bank-regs-direction;
- l = __raw_readl(reg);
- if (is_input)
- l |= 1 gpio;
- else
- l = ~(1 gpio);
- __raw_writel(l, reg);
- bank-context.oe = l;
+ bank-context.oe = _gpio_rmw(bank-base, bank-regs-direction, 1
+gpio, is_input);
}
-
/* set data out value using dedicate set/clear register */
static void _set_gpio_dataout_reg(struct gpio_bank *bank, int gpio, int enable)
{
@@ -128,17 +131,8 @@ static void _set_gpio_dataout_reg(struct gpio_bank *bank,
int gpio, int enable)
/* set data out value using mask register */
static void _set_gpio_dataout_mask(struct gpio_bank *bank, int gpio, int
enable)
{
- void __iomem *reg = bank-base + bank-regs-dataout;
- u32 gpio_bit = GPIO_BIT(bank, gpio);
- u32 l;
-
- l = __raw_readl(reg);
- if (enable)
- l |= gpio_bit;
- else
- l = ~gpio_bit;
- __raw_writel(l, reg);
- bank-context.dataout = l;
+ bank-context.dataout = _gpio_rmw(bank-base, bank-regs-dataout,
+ GPIO_BIT(bank, gpio), enable);
}
static int _get_gpio_datain(struct gpio_bank *bank, int offset)
@@ -155,18 +149,6 @@ static int _get_gpio_dataout(struct gpio_bank *bank, int
offset)
return (__raw_readl(reg) (1 offset)) != 0;
}
-static inline void _gpio_rmw(void __iomem *base, u32 reg, u32 mask, bool set)
-{
- int l = __raw_readl(base + reg);
-
- if (set)
- l |= mask;
- else
- l = ~mask;
-
- __raw_writel(l, base + reg);
-}
-
static inline void _gpio_dbck_enable(struct gpio_bank *bank)
{
if (bank-dbck_enable_mask !bank-dbck_enabled) {
@@ -291,28 +273,24 @@ static inline void set_gpio_trigger(struct gpio_bank
*bank, int gpio,
void __iomem *base = bank-base;
u32 gpio_bit = 1 gpio;
- _gpio_rmw(base, bank-regs-leveldetect0, gpio_bit,
- trigger IRQ_TYPE_LEVEL_LOW);
- _gpio_rmw(base, bank-regs-leveldetect1, gpio_bit,
- trigger IRQ_TYPE_LEVEL_HIGH);
- _gpio_rmw(base, bank-regs-risingdetect, gpio_bit,
- trigger IRQ_TYPE_EDGE_RISING);
- _gpio_rmw(base, bank-regs-fallingdetect, gpio_bit,
- trigger IRQ_TYPE_EDGE_FALLING);
bank-context.leveldetect0 =
- __raw_readl(bank-base + bank-regs-leveldetect0);
+ _gpio_rmw(base, bank-regs-leveldetect0,
+ gpio_bit, trigger IRQ_TYPE_LEVEL_LOW);
bank-context.leveldetect1 =
- __raw_readl(bank-base + bank-regs-leveldetect1);
+ _gpio_rmw(base, bank-regs-leveldetect1,
+ gpio_bit, trigger IRQ_TYPE_LEVEL_HIGH);
bank-context.risingdetect =
- __raw_readl(bank-base + bank-regs-risingdetect);
+ _gpio_rmw(base, bank-regs-risingdetect,
+ gpio_bit, trigger IRQ_TYPE_EDGE_RISING);
bank-context.fallingdetect =
- __raw_readl(bank-base + bank-regs-fallingdetect);
+ _gpio_rmw(base, bank-regs-fallingdetect,
+ gpio_bit, trigger IRQ_TYPE_EDGE_FALLING);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
- _gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
bank-context.wake_en =
- __raw_readl(bank-base + bank-regs-wkup_en);
+ _gpio_rmw(base, bank-regs-wkup_en, gpio_bit,
+ trigger != 0);
}
/* This part needs to be executed always for OMAP{34xx, 44xx} */
@@ -406,9
[PATCH v3 2/3] gpio/omap: modify wake-up register with interrupt enable.
OMAP4430 TRM chap. 25.4.5.2
To reduce dynamic consumption, an efficient idle scheme is based on the
following:
• An efficient local autoclock gating for each module
• The implementation of control sideband signals between the PRCM module
and each module
This enhanced idle control allows clocks to be activated and deactivated
safely without requiring complex software management. The idle mode
request, idle acknowledge, and wake-up request are sideband signals
between the PRCM module and the general-purpose interface
OMAP4430 TRM chap. 25.4.6.2
There must be a correlation between the wake-up enable and interrupt
enable register. If a GPIO pin has a wake-up configured on it, it must
also have the corresponding interrupt enabled. Otherwise, it is possible
there is a wake-up event, but after exiting the IDLE state, no interrupt
is generated; the corresponding bit from the interrupt status register is
not cleared, and the module does not acknowledge a future idle request.
Up to now _set_gpio_triggering() is also handling the wake-up enable
register. According the TRM this should be in sync with the interrupt
enable. Wakeup is still enabled by default, since the module would not
wake from idle otherwise.
The enabled_wakeup_gpios was introduced to remember an explicit
_set_gpio_wakeup beyond a mask/unmask cycle. Calling the flag flag
disabled_wakeup_gpios would spare the problem of initializing it, but
feels very unnatural to read.
Wakeup functionality is completely untested, since the AM335x
lacks a IRQWAKEN register.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
---
drivers/gpio/gpio-omap.c | 68 ++
1 file changed, 45 insertions(+), 23 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 082919e..44a93be 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,6 +57,7 @@ struct gpio_bank {
struct irq_domain *domain;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
+ u32 enabled_wakeup_gpios;
struct gpio_regs context;
u32 saved_datain;
u32 level_mask;
@@ -287,12 +288,6 @@ static inline void set_gpio_trigger(struct gpio_bank
*bank, int gpio,
_gpio_rmw(base, bank-regs-fallingdetect,
gpio_bit, trigger IRQ_TYPE_EDGE_FALLING);
- if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
- bank-context.wake_en =
- _gpio_rmw(base, bank-regs-wkup_en, gpio_bit,
- trigger != 0);
- }
-
/* This part needs to be executed always for OMAP{34xx, 44xx} */
if (!bank-regs-irqctrl) {
/* On omap24xx proceed only when valid GPIO bit is set */
@@ -350,12 +345,13 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
unsigned trigger)
{
void __iomem *reg = bank-base;
- void __iomem *base = bank-base;
u32 l = 0;
- if (bank-regs-leveldetect0 bank-regs-wkup_en) {
+ if (bank-regs-leveldetect0) {
+ /* edge both flanks simultaneously / plus level */
set_gpio_trigger(bank, gpio, trigger);
} else if (bank-regs-irqctrl) {
+ /* edge single flank */
reg += bank-regs-irqctrl;
l = __raw_readl(reg);
@@ -370,6 +366,7 @@ static int _set_gpio_triggering(struct gpio_bank *bank, int
gpio,
__raw_writel(l, reg);
} else if (bank-regs-edgectrl1) {
+ /* edge both flanks simultaneously */
if (gpio 0x08)
reg += bank-regs-edgectrl2;
else
@@ -382,11 +379,6 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
l |= 2 (gpio 1);
if (trigger IRQ_TYPE_EDGE_FALLING)
l |= 1 (gpio 1);
-
- /* Enable wake-up during idle for dynamic tick */
- bank-context.wake_en =
- _gpio_rmw(base, bank-regs-wkup_en, 1 gpio,
- trigger);
__raw_writel(l, reg);
}
return 0;
@@ -485,10 +477,19 @@ static void _disable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
static inline void _set_gpio_irqenable(struct gpio_bank *bank, int gpio, int
enable)
{
+ u32 gpio_bit = GPIO_BIT(bank, gpio);
+ void __iomem *base = bank-base;
+
if (enable)
- _enable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ _enable_gpio_irqbank(bank, gpio_bit);
else
- _disable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ _disable_gpio_irqbank(bank, gpio_bit);
+
+ if (bank-enabled_wakeup_gpios gpio_bit) {
+ /* Enable wake-up during idle for dynamic tick */
+ bank-context.wake_en =
+
[PATCH v3 3/3] gpio/omap: split irq_mask callback fucntion into irq_disable/irq_mask.
Disabling an IRQ is turning off interrupt generating mechanisms in the
hardware. Masking means, the interrupt doesn't get delivered to the OS,
but the interrupt status register is still getting updated. The
difference is apparent when unmasking or re-enabling the interrupt. In
case of masking you might get an interrupt straight away, but never if
the interrupt was disabled.
This is the definition Jon Hunter formulated as a question in a earlier
thread of this patchset, the exact formulation is from ppwaskie on
#kernelnewbies. It sounds reasonable to me so I will stick to it from now
on. Neither Documentation/, source code, LDD or Google search gave a me
better definition.
The omap has separate trigger and interrupt enable registers, so it can
express the the subtle difference between masking and disabling an
interrupt. But the current implementation does not make use of it.
The public disable_irq function, uses the genirq 'lazy disable'
functionality as fallback when irq_disable is not implemented. In short
lazy disable marks the interrupt as disabled, but leaves the hardware
unmasked. If an interrupt happens, the interrupt flow handler masks the
line at the hardware level and marks the interrupt as pending.
void irq_disable(struct irq_desc *desc)
{
irq_state_set_disabled(desc);
if (desc-irq_data.chip-irq_disable) {
desc-irq_data.chip-irq_disable(desc-irq_data);
irq_state_set_masked(desc);
}
}
This is a contradiction with above definition of disable, since in
disabled state the interrupt should not be marked pending. So the
behavior -- at least on ARM, see HARDIRQS_SW_RESEND -- is more
similar to masking than disable.
The advantage of lazy interrupt is, that it allows to latch a pending
interrupt on a hardware that has no separate registers for signalling and
triggering. Depending on the use case, it might also be an optimization,
since it avoids a hardware access, for the common case where no interrupt
happens between marking it disabled and reenabling it again.
Getting to the point, this patch implements a feature, supported
by the HW and foreseen by the struct irq_chip. But unfortunately
no real benefit seems to emerge from that.
The basic advantage of this patch is a) while being masked, a pending
interrupt could now be latched in HW and not SW. b) with the current
implementation, there is no latching of pending interrupts while masked,
because currently triggering is disabled when masked.
Unfortunately no no code path makes use of this;
1) while there is global disable_irq, there is not global mask_irq.
2) being a chained irq, the irq of the gpio bank is masked while the
chain handler is running, hence masking individual edge type interrupts
is unnecessary, because the aggregated bank irq is already masked
3) level type interrupts are cleared after the handler has run,
since there is no earlier time it can be cleared/re-enabled.
Major drawback of the patch:
- no more pending when enable_irq, which is in contradiction with
above definition anyway, but maybe some drivers have relied on
that behavior
- wake-up path might be affected which depends on the interplay of
several register, so we might introduce a nasty regression here
The only other irq chip driver having distinctive functions for
enable/disable and mask/unmask is drivers/gpio/gpio-ml-ioh.c
Implementation itself is straightfoward: mask/unmaks modifies
only the interrupt enable register, so it keeps latching new
interrupts into the status register. Enable/disable goes one step
further, also disabling latching of new interrupts.
Testing was done on AM335x, by using gpio-keys. While IRQ was
masked/disabled key was pressed. So upon unmask there had to be
an IRQ, while for enable no IRQ must be generated.
Masking/enabling the first gpio was controlled using a second
gpio-key. Selecting masking or disable the IRQ used was hardcoded
at compile time.
Wakeup functionality is completely untested, since the AM335x
lacks a IRQWAKEN register.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
---
drivers/gpio/gpio-omap.c | 71 --
1 file changed, 62 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 44a93be..83e77a1 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -732,6 +732,13 @@ static void gpio_ack_irq(struct irq_data *d)
_clear_gpio_irqstatus(bank, gpio);
}
+/**
+ * gpio_mask_irq - mask IRQ signaling
+ * @d : the gpio data we're acting upon
+ *
+ * Only signaling is masked. IRQs are still latched to status
+ * register.
+ */
static void gpio_mask_irq(struct irq_data *d)
{
struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
@@ -740,33 +747,77 @@ static void gpio_mask_irq(struct irq_data *d)
spin_lock_irqsave(bank-lock, flags);
_set_gpio_irqenable(bank, gpio, 0);
- _set_gpio_triggering(bank,
Re: OMAP baseline test results for v3.9
Hi, * Paul Walmsley p...@pwsan.com [130508 12:45]: PM off, dynamic idle: FAIL ( 2/ 5): 4430es2panda, 4460pandaes Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm Looking at your pm logs, 3730beaglexm won't hit off-idle. I've pasted the relevant lines from your logs below. Is this a known issue? Regards, Tony 3530es3beagle hits OFF: core_pwrdm (ON),OFF:24,RET:41,INA:0,ON:66,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 3730beaglexm won't hit OFF: core_pwrdm (ON),OFF:0,RET:88,INA:0,ON:89,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 37xxevm hits OFF: core_pwrdm (ON),OFF:8,RET:10,INA:0,ON:19,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.9
On Tue, 14 May 2013, Tony Lindgren wrote: Hi, * Paul Walmsley p...@pwsan.com [130508 12:45]: PM off, dynamic idle: FAIL ( 2/ 5): 4430es2panda, 4460pandaes Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm Looking at your pm logs, 3730beaglexm won't hit off-idle. I've pasted the relevant lines from your logs below. Is this a known issue? Yes, the Beagle XM in my testbed is a 3630ES1.0. From the PM logs: [ 63.154418] omap3_pm_off_mode_enable: Core OFF disabled due to errata i583 I should probably clarify how this is reported in the test results. - 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: OMAP baseline test results for v3.9
* Paul Walmsley p...@pwsan.com [130514 14:24]: On Tue, 14 May 2013, Tony Lindgren wrote: Hi, * Paul Walmsley p...@pwsan.com [130508 12:45]: PM off, dynamic idle: FAIL ( 2/ 5): 4430es2panda, 4460pandaes Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm Looking at your pm logs, 3730beaglexm won't hit off-idle. I've pasted the relevant lines from your logs below. Is this a known issue? Yes, the Beagle XM in my testbed is a 3630ES1.0. From the PM logs: [ 63.154418] omap3_pm_off_mode_enable: Core OFF disabled due to errata i583 I should probably clarify how this is reported in the test results. Thanks that explains. BTW, the PM off naming might make some people think that CONFIG_PM is not set :) 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: omap3-isp : panic using previewer from V4L input
Hi Jean-Philippe,
On Tuesday 14 May 2013 11:29:39 jean-philippe francois wrote:
Hi Laurent,
I have a beagle xm board, but no sensor board. Is it possible to have
the omap3-isp initialised ?
Yes it is. You will just need to call omap3_init_camera() in your board code
with a pointer to platform data that contain an empty list of subdevs.
Something like
static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
{ },
};
static struct isp_platform_data beagle_isp_platform_data = {
.subdevs = beagle_camera_subdevs,
};
static int __init beagle_camera_init(void)
{
if (!machine_is_omap3_beagle())
return 0;
omap3_init_camera(beagle_isp_platform_data);
return 0;
}
late_initcall(beagle_camera_init);
should do (you will also need to include the appropriate headers).
I would like to try my program on a beagle board to eliminate any
hardware related problem.
From the board file in mainline kernel, it seems omap3_init_camera is
not called, do you know any kernel tree where isp is initialized for beagle
board ?
--
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] ARM: OMAP2+: Allow NAND transfer mode to be specified in DT
Acked-by: Pekon Gupta pe...@ti.com
OMAP devices support various NAND transfer modes.
Currently all device-tree definitions will use the default prefetch
polled mode, so this patch enables the transfer mode to be specified
in the device-tree.
---
.../devicetree/bindings/mtd/gpmc-nand.txt |8
arch/arm/mach-omap2/gpmc.c | 14 ++
2 files changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index e7f8d7e..cd4a19b 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -29,6 +29,13 @@ Optional properties:
bch4 4-bit BCH ecc code
bch8 8-bit BCH ecc code
+ - ti,nand-xfer-type:A string setting the data transfer type.
One of:
+
+ prefetch-polled Prefetch polled mode (default)
+ polledPolled mode, without prefetch
+ prefetch-dma Prefetch enabled sDMA
mode
+ prefetch-irq Prefetch enabled irq mode
+
- elm_id: Specifies elm device node. This is required to support
BCH
error correction using ELM module.
@@ -55,6 +62,7 @@ Example for an AM33xx board:
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 16;
ti,nand-ecc-opt = bch8;
+ ti,nand-xfer-type = polled;
gpmc,sync-clk = 0;
gpmc,cs-on = 0;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-
omap2/gpmc.c
index 410e1ba..2f47f76 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1212,6 +1212,13 @@ static const char * const nand_ecc_opts[] = {
[OMAP_ECC_BCH8_CODE_HW] = bch8,
};
+static const char * const nand_xfer_types[] = {
+ [NAND_OMAP_PREFETCH_POLLED] = prefetch-
polled,
+ [NAND_OMAP_POLLED] = polled,
+ [NAND_OMAP_PREFETCH_DMA]= prefetch-
dma,
+ [NAND_OMAP_PREFETCH_IRQ]= prefetch-irq,
+};
+
static int gpmc_probe_nand_child(struct platform_device *pdev,
struct device_node *child)
{
@@ -1241,6 +1248,13 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
break;
}
+ if (!of_property_read_string(child, ti,nand-xfer-type, s))
+ for (val = 0; val ARRAY_SIZE(nand_xfer_types); val++)
+ if (!strcasecmp(s, nand_xfer_types[val])) {
+ gpmc_nand_data-xfer_type = val;
+ break;
+ }
+
val = of_get_nand_bus_width(child);
if (val == 16)
gpmc_nand_data-devsize = NAND_BUSWIDTH_16;
--
1.7.9.5
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM:dts:omap4-panda:Update the LED support for the panda DTS
$subject - add a space?
s/ARM:dts:omap4-panda:Update/ARM: dts: omap4-panda: Update/ ?
On 09:17-20130514, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
Thanks for fixing this - this is a key fix else, GPIO_7 which controls
VSEL for VDD_MPU on PandaBoard-ES will create all kind of ruckus (change
voltage on heartbeat)!
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
[...]
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..8d1ba03 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,43 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = pandaboard::status1;
+ gpios = gpio4 14 0;
+ linux,default-trigger = heartbeat;
+ };
+ mmc {
+ label = pandaboard::status2;
+ gpios = gpio1 8 0;
+ linux,default-trigger = gpio;
mmc0?
+ };
+};
+
Other that that,
Tested-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
