Re: [PATCH] spi/omap2: Let device core handle pinctrl
On Tue, May 07, 2013 at 03:56:09AM +, Hebbar, Gururaja wrote:
There are cases where driver('s) needs to place pin-mux's to sleep on suspend
default/idle on resume. For such cases Pinctrl needs to be handled inside
the driver. Example [1].
Well, obviously - but at the minute the driver is pure boilerplate.
There's also been some discussion about factoring out the suspend/resume
code since it's going to get equally repetitive.
I will be submitting a patch to enhance the existing pinctrl support for
spi omap2 shortly which does above work.
How soon is shortly?
signature.asc
Description: Digital signature
[PATCH 0/2] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad
'clkout2' comes out on the device pad and is being used by various external on-board peripherals like, Audio codecs, Wilink and stuff. So enable the clkout2 by default during init sequence itself along with right pinmux configuration clkout2 output. Also, add the missing entry of clkout2_ck to the AM33xx clock table. As far as enabling of clkout2 during init is concerned, we can argue that it can be handled using DT property and enable the clock only when specified; but not until OMAP clock-tree migration to DT. Vaibhav Hiremath (2): ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output arch/arm/boot/dts/am335x-bone.dts |8 +++- arch/arm/boot/dts/am335x-evm.dts |8 +++- arch/arm/boot/dts/am335x-evmsk.dts|8 +++- arch/arm/mach-omap2/cclock33xx_data.c |2 ++ 4 files changed, 23 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output
xdma_event_intr1.clkout2 pad can be used to source clock
from either 32K OSC or any of the PLL (except MPU) outputs.
On the existing AM335x based boards (EVM, EVM-SK and Bone),
this pad is used to feed the clock to audio codes.
So, this patch configures the pinmux to get clkout2 on the pad.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |8 +++-
arch/arm/boot/dts/am335x-evm.dts |8 +++-
arch/arm/boot/dts/am335x-evmsk.dts |8 +++-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index bfba6fc..f4630a3 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = ;
+ pinctrl-0 = clkout2_pin;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -50,6 +50,12 @@
0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
;
};
+
+ clkout2_pin: pinumx_clkout2_pin {
+ pinctrl-single,pins =
+ 0x1b4 0x03 /* xdma_event_intr1.clkout2
OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
+ ;
+ };
};
ocp {
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index f598ed2..0673308 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0 clkout2_pin;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins =
@@ -65,6 +65,12 @@
0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
;
};
+
+ clkout2_pin: pinumx_clkout2_pin {
+ pinctrl-single,pins =
+ 0x1b4 0x03 /* xdma_event_intr1.clkout2
OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
+ ;
+ };
};
ocp {
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0eec644..a559389 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = gpio_keys_s0;
+ pinctrl-0 = gpio_keys_s0 clkout2_pin;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -65,6 +65,12 @@
0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
;
};
+
+ clkout2_pin: pinumx_clkout2_pin {
+ pinctrl-single,pins =
+ 0x1b4 0x03 /* xdma_event_intr1.clkout2
OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
+ ;
+ };
};
ocp {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init
clkout2 comes out on the pad and is being used by various
external on-board peripherals like, Audio codecs and stuff.
So enable the clkout2 by default during init sequence itself.
Also, add the missing entry of clkout2_ck to the clock table.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/cclock33xx_data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index 6fd0ed1..a8140b6 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -979,6 +979,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, trace_pmd_clk_mux_ck, trace_pmd_clk_mux_ck),
CLK(NULL, stm_clk_div_ck, stm_clk_div_ck),
CLK(NULL, trace_clk_div_ck, trace_clk_div_ck),
+ CLK(NULL, clkout2_ck, clkout2_ck),
};
@@ -989,6 +990,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ clkout2_ck, /* Required for external peripherals like, Audio codecs
*/
};
int __init am33xx_clk_init(void)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] spi/omap2: Let device core handle pinctrl
On Tue, May 07, 2013 at 14:25:35, Mark Brown wrote:
On Tue, May 07, 2013 at 03:56:09AM +, Hebbar, Gururaja wrote:
There are cases where driver('s) needs to place pin-mux's to sleep on
suspend
default/idle on resume. For such cases Pinctrl needs to be handled inside
the driver. Example [1].
Well, obviously - but at the minute the driver is pure boilerplate.
Correct.
There's also been some discussion about factoring out the suspend/resume
code since it's going to get equally repetitive.
Really. Any link/referenceso that I can follow.
But I think each module will have its own work to do. May be I can confirm once
I look at the factoring-out discussion.
I will be submitting a patch to enhance the existing pinctrl support for
spi omap2 shortly which does above work.
How soon is shortly?
Since I am adding this Pinctrl PM mode support to many other drivers (i2c,
cpsw, da8xx-fb, hsmmc, ti-pwm, usb ...), I would say Shortly = 1 week - 10 days.
Regards,
Gururaja
--
To unsubscribe from this list: send the line unsubscribe 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, (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 ? 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] (__do_softirq+0x60/0x184) from [c003440c] (irq_exit+0x70/0xc4) [c003440c] (irq_exit+0x70/0xc4) from [c000ebcc] (handle_IRQ+0x64/0x84) [c000ebcc] (handle_IRQ+0x64/0x84) from [c0008594] (omap3_intc_handle_irq+0x58/0x6c) [c0008594] (omap3_intc_handle_irq+0x58/0x6c) from [c000df00] (__irq_svc+0x40/0x70) Exception stack(0xc0507f80 to 0xc0507fc8) 7f80:c0547548 c050fb50 0001 c0506000 c050e0d8 c04fb954 c0510844 7fa0:80004059 413fc082 c0507fc8 c0506008 c000ed78 7fc0:2013 [c000df00] (__irq_svc+0x40/0x70) from [c000ed78] (cpu_idle+0x60/0x90) [c000ed78] (cpu_idle+0x60/0x90) from [c04da7a8] (start_kernel+0x234/0x284) Code: e0022006 e0033007 e1920003 0a02 (e7f001f2) ---[ end trace 58d781a6c1166535 ]--- Kernel
Re: [GIT PULL] Urgent omap timer fix for current merge window
On Mon, May 06, 2013 at 04:46:11PM -0700, Tony Lindgren wrote: Vaibhav Hiremath (1): ARM: OMAP2+: Fix mismerge for timer.c between ff931c82 and da4a686a Neither your pull request subject nor the above summary line really sum up what the problem is - the real problem is fix breakage causing OMAP to fail to boot. I've just been chasing this problem and the descriptions given on this just suggest that it's a timer issue not a non-boot issue. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] hwspinlock for 3.10
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git tags/hwspinlock-3.10 for you to fetch changes up to 8ae053d62e88c400330ebaf27558bf02dde5a1fa: hwspinlock/omap: support OMAP5 as well (2013-04-05 09:11:17 +0300) A single patch from Vincent extending OMAP's hwspinlock support to OMAP5. Vincent Stehlé (1): hwspinlock/omap: support OMAP5 as well drivers/hwspinlock/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] rpmsg for 3.10
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git tags/rpmsg-3.10 for you to fetch changes up to 397944df3290ddc46dcc6a08cd71fb560700431b: rpmsg: fix kconfig dependencies for VIRTIO (2013-04-21 16:32:29 +0300) A small pull request consisting of: - Make rpmsg process all pending messages instead of just one, from Robert Tivy - Fix Kconfig dependency on VIRTUALIZATION, from Suman. Note: this was submitted late during the 3.9 rc cycle and it seemed appropriate to wait with it for the merge window. - Belated addition of an rpmsg entry to the MAINTAINERS file. People seem to look for this. Ohad Ben-Cohen (1): MAINTAINERS: add rpmsg entry Robert Tivy (1): rpmsg: process _all_ pending messages in rpmsg_recv_done Suman Anna (1): rpmsg: fix kconfig dependencies for VIRTIO MAINTAINERS | 8 +++ drivers/rpmsg/Kconfig| 1 + drivers/rpmsg/virtio_rpmsg_bus.c | 49 3 files changed, 44 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] remoteproc for 3.10
There's a trivial merge conflict with a Kconfig typo that got fixed during the rc cycle, but otherwise: The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git tags/remoteproc-3.10 for you to fetch changes up to b9777859ec015a78dae1476e317d04f851bfdd0d: remoteproc: fix kconfig dependencies for VIRTIO (2013-04-21 16:30:22 +0300) This pull request contains: - Some refactoring, cleanups and small improvements from Sjur Brændeland. The improvements are mainly about better supporting varios virtio properties (such as virtio's config space, status and features). I now see that I messed up while commiting one of Sjur's patches and erroneously put myself as the author, as well as letting a nasty typo sneak in. I will not fix this in order to avoid rebasing the patches. Sjur - sorry! - A new remoteproc driver for OMAP-L13x (technically a DaVinci platform) from Robert Tivy. - Extend OMAP support to OMAP5 as well, from Vincent Stehlé. - Fix Kconfig VIRTUALIZATION dependency, from Suman Anna (a non-critical fix which arrived late during the rc cycle). Ohad Ben-Cohen (1): remoteproc: perserve resource table data Robert Tivy (2): remoteproc: support default firmware name in rproc_alloc() remoteproc/davinci: add a remoteproc driver for OMAP-L13x DSP Sjur Brændeland (7): remoteproc: refactor rproc_elf_find_rsc_table() remoteproc: add find_loaded_rsc_table firmware ops remoteproc: parse STE-firmware and find resource table address remoteproc: code cleanup of resource parsing remoteproc: calculate max_notifyid by counting vrings remoteproc: support virtio config space. remoteproc: set vring addresses in resource table Suman Anna (1): remoteproc: fix kconfig dependencies for VIRTIO Vincent Stehlé (1): remoteproc/omap: support OMAP5 too drivers/remoteproc/Kconfig | 27 ++- drivers/remoteproc/Makefile| 1 + drivers/remoteproc/da8xx_remoteproc.c | 324 + drivers/remoteproc/remoteproc_core.c | 211 --- drivers/remoteproc/remoteproc_elf_loader.c | 100 ++--- drivers/remoteproc/remoteproc_internal.h | 15 +- drivers/remoteproc/remoteproc_virtio.c | 79 +-- drivers/remoteproc/ste_modem_rproc.c | 45 ++-- include/linux/remoteproc.h | 13 +- 9 files changed, 677 insertions(+), 138 deletions(-) create mode 100644 drivers/remoteproc/da8xx_remoteproc.c -- To unsubscribe from this list: send the line unsubscribe 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
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] (__do_softirq+0x60/0x184) from [c003440c] (irq_exit+0x70/0xc4) [c003440c] (irq_exit+0x70/0xc4) from [c000ebcc] (handle_IRQ+0x64/0x84) [c000ebcc] (handle_IRQ+0x64/0x84) from [c0008594] (omap3_intc_handle_irq+0x58/0x6c) [c0008594] (omap3_intc_handle_irq+0x58/0x6c) from [c000df00] (__irq_svc+0x40/0x70) Exception stack(0xc0507f80 to 0xc0507fc8) 7f80:c0547548 c050fb50 0001 c0506000 c050e0d8 c04fb954 c0510844 7fa0:80004059 413fc082
Re: [GIT PULL] Urgent omap timer fix for current merge window
On Tuesday 07 May 2013, Tony Lindgren wrote: The following changes since commit dc2d3db8137fba0f62d7517e1bea8a47f69fcbc4: Merge tag 'omap-for-v3.10/timer-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers (2013-04-08 19:30:48 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-for-merge-window for you to fetch changes up to 08a48be32ff31d38bcfec7d210c954cb62fd5cd7: ARM: OMAP4: change the device names in usb_bind_phy (2013-05-06 16:39:16 -0700) An urgent fix for a timer mismerge for and a regression fix for musb device naming change. Hi Tony, Russell also ran into this problem, so I'm including these in the late/cleanup branch, which I'll send to Linus later today. Thanks, Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] drivers: bus: omap_l3: Conversion to devm_*
On Thursday 02 May 2013 05:39 PM, Peter Ujfalusi wrote: Hi, Cleanup of platform probe and remove (removing the remove function at the end) with converting the driver to use the devm_* versions kzalloc, ioremap and request_irq. Thanks Peter. All patches looks fine to my eyes. In the last patch wher you are changing the error level is bit debatable but I agree with you. So FWIW, Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Peter Ujfalusi (5): drivers: bus: omap_l3: Convert to use devm_kzalloc drivers: bus: omap_l3: Convert to use devm_request_and_ioremap() drivers: bus: omap_l3: Convert to use devm_request_irq() drivers: bus: omap_l3: Remove the platform driver's remove function drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails drivers/bus/omap_l3_noc.c | 106 +++--- 1 file changed, 24 insertions(+), 82 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
Hello Jason, On 06-05-2013 20:36, Jason Gunthorpe wrote: On Mon, May 06, 2013 at 08:23:13PM -0400, Eduardo Valentin wrote: I get the impression it is desired to minimize driver kconfig dependencies to the minimum required to compile to increase build testing coverage, so maybe it would be appropriate to drop this entirely? Well, it is also desired to compile things to the correct target right? There is some of that too.. But broadly the direction seems that drivers should have minimal dependencies so, eg, the thermal maintainer compiling for x86 should be able to compile test/static analyze your driver.. Well, I do not see much of this attempt actually. Do you have some link / evidene that shows someone who actually cares about compiling drivers for targets that they are not used for? On this specific driver, I actually have had exactly the opposite advice [1]. I am not convinced people actually want to do that. Thats the idea behind this config option. It follows the same design as CONFIG_ARCH_HAS_CPUFREQ, for instance. That is entirely contained inside arch/arm and doesn't involve drivers. It actually goes outside arch/arm. Jason [1] - https://patchwork.kernel.org/patch/1185431/ signature.asc Description: OpenPGP digital signature
Re: [PATCH] ti_tscadc: Update with IIO map interface deal with partial activation
Hi Jonathan, On May 6, 2013, at 7:12 PM, Jonathan Cameron wrote: On 05/06/2013 01:48 PM, Jan Luebbe wrote: Hi Pantelis, while trying out your patch on a custom AM335x board, I noticed that the sysfs entries ware missing. This is fixed in the first patch, you might want to squash that into your original patch. The second one makes sure that the iio framework does not read invalid data. Regards, Jan I don't believe Pantelis ever came back with a response to the various issues raised with the original patches? I am aware. We've been quite busy getting the new beaglebone out. I plan to revisit the full patchset for all the various fixes we had to do in a month or so. If Pantelis has moved on, Jan feel free to pick up the patches, respin them and resend to linux-iio if you like (with appropriate crediting naturally) I wouldn't mind Jan to pick up the IIO patches. Until these are appropriately fixed up and resent, I'm lazy so will ignore these. (your patches look reasonable to me based on a really superficial look) Jonathan Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe 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] ti_tscadc: Update with IIO map interface deal with partial activation
On Tue, 2013-05-07 at 16:08 +0300, Pantelis Antoniou wrote: Hi Jonathan, On May 6, 2013, at 7:12 PM, Jonathan Cameron wrote: On 05/06/2013 01:48 PM, Jan Luebbe wrote: Hi Pantelis, while trying out your patch on a custom AM335x board, I noticed that the sysfs entries ware missing. This is fixed in the first patch, you might want to squash that into your original patch. The second one makes sure that the iio framework does not read invalid data. Regards, Jan I don't believe Pantelis ever came back with a response to the various issues raised with the original patches? I am aware. We've been quite busy getting the new beaglebone out. I plan to revisit the full patchset for all the various fixes we had to do in a month or so. It seems that TI continued working on this in their vendor kernel: http://arago-project.org/git/projects/?p=linux-am33x.git;a=history;f=drivers/staging/iio;hb=v3.2-staging We could possibly reuse/port some of that work. If Pantelis has moved on, Jan feel free to pick up the patches, respin them and resend to linux-iio if you like (with appropriate crediting naturally) I wouldn't mind Jan to pick up the IIO patches. I'm currently also busy with other things, so I'm not optimistic that I'd find some time to do this. :/ Thanks, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Urgent omap timer fix for current merge window
* Russell King - ARM Linux li...@arm.linux.org.uk [130507 05:07]: On Mon, May 06, 2013 at 04:46:11PM -0700, Tony Lindgren wrote: Vaibhav Hiremath (1): ARM: OMAP2+: Fix mismerge for timer.c between ff931c82 and da4a686a Neither your pull request subject nor the above summary line really sum up what the problem is - the real problem is fix breakage causing OMAP to fail to boot. I've just been chasing this problem and the descriptions given on this just suggest that it's a timer issue not a non-boot issue. Oops yes sorry if the description was a bit unclear. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Urgent omap timer fix for current merge window
* Arnd Bergmann a...@arndb.de [130507 05:54]: On Tuesday 07 May 2013, Tony Lindgren wrote: The following changes since commit dc2d3db8137fba0f62d7517e1bea8a47f69fcbc4: Merge tag 'omap-for-v3.10/timer-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers (2013-04-08 19:30:48 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-for-merge-window for you to fetch changes up to 08a48be32ff31d38bcfec7d210c954cb62fd5cd7: ARM: OMAP4: change the device names in usb_bind_phy (2013-05-06 16:39:16 -0700) An urgent fix for a timer mismerge for and a regression fix for musb device naming change. Hi Tony, Russell also ran into this problem, so I'm including these in the late/cleanup branch, which I'll send to Linus later today. Thanks! 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 RESEND] genirq: add function to get IRQ edge/level flags
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
while the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that want to get the IRQ edge/level flags
defined in the Device Tree from a struct resource will not be able
to get it.
Drivers can get the IRQ flags by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
So, is better to add an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
Signed-off-by: Javier Martinez Canillas javier.marti...@dowhile0.org
---
include/linux/irq.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index bc4e066..0e8e3a6 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -579,6 +579,12 @@ static inline struct msi_desc *irq_data_get_msi(struct
irq_data *d)
return d-msi_desc;
}
+static inline u32 irq_get_trigger_type(unsigned int irq)
+{
+ struct irq_data *d = irq_get_irq_data(irq);
+ return d ? irqd_get_trigger_type(d) : 0;
+}
+
int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
struct module *owner);
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Tue, May 07, 2013 at 09:15:00AM -0400, Eduardo Valentin wrote: But broadly the direction seems that drivers should have minimal dependencies so, eg, the thermal maintainer compiling for x86 should be able to compile test/static analyze your driver.. Well, I do not see much of this attempt actually. Do you have some link / evidene that shows someone who actually cares about compiling drivers for targets that they are not used for? On this specific driver, I actually have had exactly the opposite advice [1]. I am not convinced people actually want to do that. There was a discussion a bit ago, but I can't find a link.. The context was subsystem maintainers are being asked to look after more code with the DT transition moving things out of arch/arm and at least one complained they couldn't even compile test on x86... But again, I can't find a link and you are right, there are lots and lots of 'depends ARCH..' style things in kConfig already. Lets just call it something to think about. Thats the idea behind this config option. It follows the same design as CONFIG_ARCH_HAS_CPUFREQ, for instance. That is entirely contained inside arch/arm and doesn't involve drivers. It actually goes outside arch/arm. Hm, must have missed that, seemed like all it did was control including drivers/cpufreq/Kconfig within the ARM kconfigs.. And unicore32 copied the name, but did the same thing. Regards, Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Tue, May 07, 2013 at 12:27:11PM -0600, Jason Gunthorpe wrote: On Tue, May 07, 2013 at 09:15:00AM -0400, Eduardo Valentin wrote: But broadly the direction seems that drivers should have minimal dependencies so, eg, the thermal maintainer compiling for x86 should be able to compile test/static analyze your driver.. Well, I do not see much of this attempt actually. Do you have some link / evidene that shows someone who actually cares about compiling drivers for targets that they are not used for? On this specific driver, I actually have had exactly the opposite advice [1]. I am not convinced people actually want to do that. There was a discussion a bit ago, but I can't find a link.. The context was subsystem maintainers are being asked to look after more code with the DT transition moving things out of arch/arm and at least one complained they couldn't even compile test on x86... But again, I can't find a link and you are right, there are lots and lots of 'depends ARCH..' style things in kConfig already. Lets just call it something to think about. Tomi started a thread related to this recently: http://marc.info/?l=linux-kernelm=136731558332265w=2 I think there's some good reasons listed there, but I guess up to the subsystem maintainers to decide what they prefer. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: omap_device: use late_initcall_sync
If DEBUG_LL and earlyprintk are enabled, and omap-serial.c is compiled as a module, the kernel boot hangs early as the clocks for serial port are cut while earlyprintk still uses the port. The problem is a race between the late_initcall for omap_device (which idles devices that have no drivers) and the late_initcall in kernel/printk.c which turns off the earlyconsole. Any printks that happen between this omap_device late initcall and the earlyconsole late initcall will crash when accessing the UART. The fix is to ensure the omap_device initcall happens after the earlyconsole initcall. Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@linaro.org --- Based on v3.9-rc8 arch/arm/mach-omap2/omap_device.c | 2 +- arch/arm/mach-omap2/soc.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c index 381be7a..2d20d69 100644 --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -879,4 +879,4 @@ static int __init omap_device_late_init(void) bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle); return 0; } -omap_late_initcall(omap_device_late_init); +omap_late_initcall_sync(omap_device_late_init); diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index c62116b..de88611 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -494,6 +494,7 @@ level(__##fn); #define omap_subsys_initcall(fn) omap_initcall(subsys_initcall, fn) #define omap_device_initcall(fn) omap_initcall(device_initcall, fn) #define omap_late_initcall(fn) omap_initcall(late_initcall, fn) +#define omap_late_initcall_sync(fn)omap_initcall(late_initcall_sync, fn) #endif /* __ASSEMBLY__ */ -- 1.8.2 -- To unsubscribe from this list: send the line unsubscribe 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: set device dma_mask without reference to global data
From: Stephen Warren swar...@nvidia.com
Many USB host drivers contain code such as:
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = tegra_ehci_dma_mask;
... where tegra_ehci_dma_mask is a global. I suspect this code originated
in commit 4a53f4e USB: ehci-tegra: add probing through device tree and
was simply copied everywhere else.
This works fine when the code is built-in, but can cause a crash when the
code is in a module. The first module load sets up the dma_mask pointer,
but if the module is removed and re-inserted, the value is now non-NULL,
and hence is not updated to point at the new location, and hence points
at a stale location within the previous module load address, which in
turn causes a crash if the pointer is de-referenced.
The simplest way of solving this seems to be to copy the code from
ehci-platform.c, which uses the coherent_dma_mask as the target for the
dma_mask pointer.
Suggested-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/usb/chipidea/ci13xxx_imx.c | 15 ---
drivers/usb/dwc3/dwc3-exynos.c |6 +++---
drivers/usb/host/ehci-atmel.c |6 +++---
drivers/usb/host/ehci-omap.c |8
drivers/usb/host/ehci-orion.c |6 +++---
drivers/usb/host/ehci-s5p.c|4 +---
drivers/usb/host/ehci-spear.c |6 +++---
drivers/usb/host/ehci-tegra.c |6 +++---
drivers/usb/host/ohci-at91.c |6 +++---
drivers/usb/host/ohci-exynos.c |4 +---
drivers/usb/host/ohci-omap3.c |8
drivers/usb/host/ohci-pxa27x.c |6 +++---
drivers/usb/host/ohci-spear.c |6 +++---
drivers/usb/host/uhci-platform.c |6 +++---
14 files changed, 41 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 8faec9d..73f9d5f 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -173,17 +173,10 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
ci13xxx_imx_platdata.phy = data-phy;
- if (!pdev-dev.dma_mask) {
- pdev-dev.dma_mask = devm_kzalloc(pdev-dev,
- sizeof(*pdev-dev.dma_mask), GFP_KERNEL);
- if (!pdev-dev.dma_mask) {
- ret = -ENOMEM;
- dev_err(pdev-dev, Failed to alloc dma_mask!\n);
- goto err;
- }
- *pdev-dev.dma_mask = DMA_BIT_MASK(32);
- dma_set_coherent_mask(pdev-dev, *pdev-dev.dma_mask);
- }
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
+ if (!pdev-dev.coherent_dma_mask)
+ pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
if (usbmisc_ops usbmisc_ops-init) {
ret = usbmisc_ops-init(pdev-dev);
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index a8afe6e..929e7dd 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -95,8 +95,6 @@ static int dwc3_exynos_remove_child(struct device *dev, void
*unused)
return 0;
}
-static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
-
static int dwc3_exynos_probe(struct platform_device *pdev)
{
struct dwc3_exynos *exynos;
@@ -118,7 +116,9 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
* Once we move to full device tree support this will vanish off.
*/
if (!dev-dma_mask)
- dev-dma_mask = dwc3_exynos_dma_mask;
+ dev-dma_mask = dev-coherent_dma_mask;
+ if (!dev-coherent_dma_mask)
+ dev-coherent_dma_mask = DMA_BIT_MASK(32);
platform_set_drvdata(pdev, exynos);
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 6642009..02f4611 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -63,8 +63,6 @@ static void atmel_stop_ehci(struct platform_device *pdev)
/*-*/
-static u64 at91_ehci_dma_mask = DMA_BIT_MASK(32);
-
static int ehci_atmel_drv_probe(struct platform_device *pdev)
{
struct usb_hcd *hcd;
@@ -93,7 +91,9 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
* Once we have dma capability bindings this can go away.
*/
if (!pdev-dev.dma_mask)
- pdev-dev.dma_mask = at91_ehci_dma_mask;
+ pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
+ if (!pdev-dev.coherent_dma_mask)
+ pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd) {
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 3d1491b..16d7150 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -90,8 +90,6 @@ static const
Re: [PATCH] USB: set device dma_mask without reference to global data
On Tue, May 07, 2013 at 04:53:52PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Many USB host drivers contain code such as: if (!pdev-dev.dma_mask) pdev-dev.dma_mask = tegra_ehci_dma_mask; ... where tegra_ehci_dma_mask is a global. I suspect this code originated in commit 4a53f4e USB: ehci-tegra: add probing through device tree and was simply copied everywhere else. This works fine when the code is built-in, but can cause a crash when the code is in a module. The first module load sets up the dma_mask pointer, but if the module is removed and re-inserted, the value is now non-NULL, and hence is not updated to point at the new location, and hence points at a stale location within the previous module load address, which in turn causes a crash if the pointer is de-referenced. The simplest way of solving this seems to be to copy the code from ehci-platform.c, which uses the coherent_dma_mask as the target for the dma_mask pointer. Suggested-by: Arnd Bergmann a...@arndb.de Signed-off-by: Stephen Warren swar...@nvidia.com So this needs to go in for 3.10, right? Any older kernels as well? If so, which ones? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe 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] USB: set device dma_mask without reference to global data
On Wednesday 08 May 2013, Greg Kroah-Hartman wrote: On Tue, May 07, 2013 at 04:53:52PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Suggested-by: Arnd Bergmann a...@arndb.de Signed-off-by: Stephen Warren swar...@nvidia.com So this needs to go in for 3.10, right? Any older kernels as well? If so, which ones? The fix should definitely go into 3.10, but I'd suggest waiting with the backport for a couple of -rc releases to avoid possible regressions. We know that the current code is broken, but few people fully understand what is going on with coherent_dma_mask, so it might cause new problems in combination with some other unknown bug, and I don't see this as urgent: none of the ARM defconfigs build this driver as a loadable module and there is no bug in the built-in case. For some reason, only the ARM back-end drivers are broken. The first occurence was apparently in 3.3, but only in ehci-tegra.c, while the other drivers subsequently copied the bug. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: set device dma_mask without reference to global data
On Wed, May 8, 2013 at 6:53 AM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com Many USB host drivers contain code such as: if (!pdev-dev.dma_mask) pdev-dev.dma_mask = tegra_ehci_dma_mask; ... where tegra_ehci_dma_mask is a global. I suspect this code originated in commit 4a53f4e USB: ehci-tegra: add probing through device tree and was simply copied everywhere else. One question: why device tree can't do this when create device? -- To unsubscribe from this list: send the line unsubscribe 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] USB: set device dma_mask without reference to global data
On 05/07/2013 07:13 PM, Peter Chen wrote: On Wed, May 8, 2013 at 6:53 AM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com Many USB host drivers contain code such as: if (!pdev-dev.dma_mask) pdev-dev.dma_mask = tegra_ehci_dma_mask; ... where tegra_ehci_dma_mask is a global. I suspect this code originated in commit 4a53f4e USB: ehci-tegra: add probing through device tree and was simply copied everywhere else. One question: why device tree can't do this when create device? This probably could be initialized from some DT property. However, there's no such property defined right now, and considering that DT is supposed to be an ABI, we'd always need the code in this patch as a fallback for DTs that were created before any such property was defined. Equally, since the data is SoC-specific rather than board-specific, and is even fairly unlikely to vary between SoC versions since these values are all 0x anyway, I don't really see much point in putting it into DT, rather than just putting the static data into the driver. -- To unsubscribe from this list: send the line unsubscribe 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] USB: set device dma_mask without reference to global data
This probably could be initialized from some DT property. However, there's no such property defined right now, and considering that DT is supposed to be an ABI, we'd always need the code in this patch as a fallback for DTs that were created before any such property was defined. Equally, since the data is SoC-specific rather than board-specific, and is even fairly unlikely to vary between SoC versions since these values are all 0x anyway, I don't really see much point in putting it into DT, rather than just putting the static data into the driver. I mean there is already dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); at function of_platform_device_create, why can't add dev-dev.dma_mask = dev-dev.coherent_dma_mask after that? If DT core can do above things, can we delete dma_mask assignment at every driver? -- BR, Peter Chen -- To unsubscribe from this list: send the line unsubscribe 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] USB: set device dma_mask without reference to global data
On 08/05/13 10:53, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Many USB host drivers contain code such as: if (!pdev-dev.dma_mask) pdev-dev.dma_mask = tegra_ehci_dma_mask; ... where tegra_ehci_dma_mask is a global. I suspect this code originated in commit 4a53f4e USB: ehci-tegra: add probing through device tree and was simply copied everywhere else. This works fine when the code is built-in, but can cause a crash when the code is in a module. The first module load sets up the dma_mask pointer, but if the module is removed and re-inserted, the value is now non-NULL, and hence is not updated to point at the new location, and hence points at a stale location within the previous module load address, which in turn causes a crash if the pointer is de-referenced. The simplest way of solving this seems to be to copy the code from ehci-platform.c, which uses the coherent_dma_mask as the target for the dma_mask pointer. Suggested-by: Arnd Bergmann a...@arndb.de Signed-off-by: Stephen Warren swar...@nvidia.com --- In the case of uhci-platform you would be absolutely correct. I copied the example from tegra when we first had the problem on arch-vt8500.Because we have no NAND support yet, I have always booted myrootfs from USB so it's always been builtin and the problem wasnever a problem. The same problem would have existed on ehci-vt8500 but Arnd replaced it with ehci-platform due to the multiplatform issues. for uhci-platform.c Acked-by: Tony Prisk li...@prisktech.co.nz Regards Tony P -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
