linux-toradex.git/drivers/w1, branch tegra Linux kernel for Apalis and Colibri modules drivers: w1: tegra_w1: Improve IRQ detection 2015-05-04T14:11:53+00:00 Sanchayan Maity maitysanchayan@gmail.com 2015-04-29T13:37:36+00:00 ff73aabd871910b44bea051e41c5024584b1061b On Tegra30, on a high CPU load or operating at maximum frequency results in continous interrupt generation, with the following log spewout: (tegra_w1_irq: line 236) spurious interrupt, status = 0x800 (tegra_w1_irq: line 236) spurious interrupt, status = 0x800 (tegra_w1_irq: line 236) spurious interrupt, status = 0x800 (tegra_w1_irq: line 236) spurious interrupt, status = 0x800 which shows the TX_FIFO_DATA_REQ to be somehow continously being set. To circumvent this specifically detect the bit transfer and presence done IRQ's only, for generating a "completion" signal on which the core logic waits. We anyhow only wait for these interrupts in particular. While at it, also change the error message to be printed only if it is conditionally enabled instead of all the time, which floods the serial console and allows a wrong interpretation of the one wire device not working at all. Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com> 
On Tegra30, on a high CPU load or operating at maximum frequency results
in continous interrupt generation, with the following log spewout:

(tegra_w1_irq: line 236) spurious interrupt, status = 0x800
(tegra_w1_irq: line 236) spurious interrupt, status = 0x800
(tegra_w1_irq: line 236) spurious interrupt, status = 0x800
(tegra_w1_irq: line 236) spurious interrupt, status = 0x800

which shows the TX_FIFO_DATA_REQ to be somehow continously being set. To
circumvent this specifically detect the bit transfer and presence done
IRQ's only, for generating a "completion" signal on which the core logic
waits. We anyhow only wait for these interrupts in particular. While at
it, also change the error message to be printed only if it is
conditionally enabled instead of all the time, which floods the serial
console and allows a wrong interpretation of the one wire device not
working at all.

Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
drivers: w1: tegra_w1: Fix race condition on high CPU load 2015-05-04T14:11:51+00:00 Sanchayan Maity maitysanchayan@gmail.com 2015-04-29T13:37:35+00:00 feb85c154f0a457e17c8b74e9eb2938207a76090 On Tegra3 at high CPU load, for example while running stress, reading data from one wire results in the following stack trace: [ 58.436052] [<c05e93d4>] (__raw_spin_lock_irqsave+0x3c/0xac) from [<c05e945c>] (_raw_spin_lock_irqsave+0x18/0x1c) [ 58.446322] [<c05e945c>] (_raw_spin_lock_irqsave+0x18/0x1c) from [<c0048eb4>] (complete+0x28/0x64) [ 58.455276] [<c0048eb4>] (complete+0x28/0x64) from [<c03e276c>] (tegra_w1_irq+0x74/0xb4) [ 58.463376] [<c03e276c>] (tegra_w1_irq+0x74/0xb4) from [<c009a1fc>] (handle_irq_event_percpu+0x9c/0x278) [ 58.472847] [<c009a1fc>] (handle_irq_event_percpu+0x9c/0x278) from [<c009a424>] (handle_irq_event+0x4c/0x6c) [ 58.482666] [<c009a424>] (handle_irq_event+0x4c/0x6c) from [<c009cc40>] (handle_fasteoi_irq+0xe0/0x118) [ 58.492048] [<c009cc40>] (handle_fasteoi_irq+0xe0/0x118) from [<c0099bd8>] (generic_handle_irq+0x30/0x40) [ 58.501616] [<c0099bd8>] (generic_handle_irq+0x30/0x40) from [<c000ecfc>] (handle_IRQ+0x88/0xc8) [ 58.510393] [<c000ecfc>] (handle_IRQ+0x88/0xc8) from [<c0008430>] (asm_do_IRQ+0x18/0x1c) [ 58.518475] [<c0008430>] (asm_do_IRQ+0x18/0x1c) from [<c000e098>] (__irq_usr+0x38/0xc0) [ 58.526464] Exception stack(0xe51a3fb0 to 0xe51a3ff8) [ 58.531506] 3fa0: 00000000 bea29b04 4030b1b0 4030b4c8 [ 58.539673] 3fc0: 4030b22c 4fd2f305 0000d770 0000d6b0 00000000 00000001 0000000d 00000145 [ 58.547839] 3fe0: 193c62ce bea29af4 4030b22c 4020beb4 600b0010 ffffffff [ 58.554445] Code: e5843004 e10f0000 f10c0080 e3a02001 (e1953f9f) [ 58.560539] ---[ end trace fb2fc83ceb8e95c1 ]--- [ 58.565154] Kernel panic - not syncing: Fatal exception in interrupt [ 58.571520] [<c0014ef4>] (unwind_backtrace+0x0/0xec) from [<c05e10c8>] (dump_stack+0x20/0x24) [ 58.580039] [<c05e10c8>] (dump_stack+0x20/0x24) from [<c05e16a0>] (panic+0x7c/0x1ac) [ 58.587783] [<c05e16a0>] (panic+0x7c/0x1ac) from [<c0012038>] (die+0x280/0x2e8) [ 58.595087] [<c0012038>] (die+0x280/0x2e8) from [<c05e1130>] (__do_kernel_fault.part.3+0x64/0x84) [ 58.603952] [<c05e1130>] (__do_kernel_fault.part.3+0x64/0x84) from [<c0015c84>] (do_page_fault+0x204/0x21c) [ 58.613681] [<c0015c84>] (do_page_fault+0x204/0x21c) from [<c000830c>] (do_DataAbort+0x44/0xa8) [ 58.622369] [<c000830c>] (do_DataAbort+0x44/0xa8) from [<c000de18>] (__dabt_svc+0x38/0x60) This seems to be generated due a possible race condition between the on stack kernel completion being set to NULL in tegra_w1_touch_bit, while a possible spurious IRQ calling this completion in the IRQ handler. This is a temporary bandaid and the ideal solution would be to find why this affects the Tegra3 and not Tegra2. Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Stefan Agner <stefan.agner@toradex.com> 
On Tegra3 at high CPU load, for example while running stress, reading
data from one wire results in the following stack trace:

[   58.436052] [<c05e93d4>] (__raw_spin_lock_irqsave+0x3c/0xac) from
[<c05e945c>] (_raw_spin_lock_irqsave+0x18/0x1c)
[   58.446322] [<c05e945c>] (_raw_spin_lock_irqsave+0x18/0x1c) from
[<c0048eb4>] (complete+0x28/0x64)
[   58.455276] [<c0048eb4>] (complete+0x28/0x64) from [<c03e276c>]
(tegra_w1_irq+0x74/0xb4)
[   58.463376] [<c03e276c>] (tegra_w1_irq+0x74/0xb4) from [<c009a1fc>]
(handle_irq_event_percpu+0x9c/0x278)
[   58.472847] [<c009a1fc>] (handle_irq_event_percpu+0x9c/0x278) from
[<c009a424>] (handle_irq_event+0x4c/0x6c)
[   58.482666] [<c009a424>] (handle_irq_event+0x4c/0x6c) from
[<c009cc40>] (handle_fasteoi_irq+0xe0/0x118)
[   58.492048] [<c009cc40>] (handle_fasteoi_irq+0xe0/0x118) from
[<c0099bd8>] (generic_handle_irq+0x30/0x40)
[   58.501616] [<c0099bd8>] (generic_handle_irq+0x30/0x40) from
[<c000ecfc>] (handle_IRQ+0x88/0xc8)
[   58.510393] [<c000ecfc>] (handle_IRQ+0x88/0xc8) from [<c0008430>]
(asm_do_IRQ+0x18/0x1c)
[   58.518475] [<c0008430>] (asm_do_IRQ+0x18/0x1c) from [<c000e098>]
(__irq_usr+0x38/0xc0)
[   58.526464] Exception stack(0xe51a3fb0 to 0xe51a3ff8)
[   58.531506] 3fa0:                                     00000000
bea29b04 4030b1b0 4030b4c8
[   58.539673] 3fc0: 4030b22c 4fd2f305 0000d770 0000d6b0 00000000
00000001 0000000d 00000145
[   58.547839] 3fe0: 193c62ce bea29af4 4030b22c 4020beb4 600b0010
ffffffff
[   58.554445] Code: e5843004 e10f0000 f10c0080 e3a02001 (e1953f9f)
[   58.560539] ---[ end trace fb2fc83ceb8e95c1 ]---
[   58.565154] Kernel panic - not syncing: Fatal exception in interrupt
[   58.571520] [<c0014ef4>] (unwind_backtrace+0x0/0xec) from
[<c05e10c8>] (dump_stack+0x20/0x24)
[   58.580039] [<c05e10c8>] (dump_stack+0x20/0x24) from [<c05e16a0>]
(panic+0x7c/0x1ac)
[   58.587783] [<c05e16a0>] (panic+0x7c/0x1ac) from [<c0012038>]
(die+0x280/0x2e8)
[   58.595087] [<c0012038>] (die+0x280/0x2e8) from [<c05e1130>]
(__do_kernel_fault.part.3+0x64/0x84)
[   58.603952] [<c05e1130>] (__do_kernel_fault.part.3+0x64/0x84) from
[<c0015c84>] (do_page_fault+0x204/0x21c)
[   58.613681] [<c0015c84>] (do_page_fault+0x204/0x21c) from
[<c000830c>] (do_DataAbort+0x44/0xa8)
[   58.622369] [<c000830c>] (do_DataAbort+0x44/0xa8) from [<c000de18>]
(__dabt_svc+0x38/0x60)

This seems to be generated due a possible race condition between the on
stack kernel completion being set to NULL in tegra_w1_touch_bit, while a
possible spurious IRQ calling this completion in the IRQ handler. This
is a temporary bandaid and the ideal solution would be to find why this
affects the Tegra3 and not Tegra2.

Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
w1: master: tegra: treat compile warning as error 2012-08-02T16:36:36+00:00 schowdary schowdary@nvidia.com 2012-07-24T15:51:27+00:00 95b5dfcb4b7e25725b534d55b0b451622851c484 - Add compilation flag to treat warning as error bug 949219 Change-Id: Ifc6b454e3debf44c14720d2aa908147902d57b79 Signed-off-by: schowdary <schowdary@nvidia.com> Reviewed-on: http://git-master/r/118087 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Sanjay Singh Rawat <srawat@nvidia.com> Reviewed-by: Sachin Nikam <snikam@nvidia.com> 
- Add compilation flag to treat warning as error

bug 949219

Change-Id: Ifc6b454e3debf44c14720d2aa908147902d57b79
Signed-off-by: schowdary <schowdary@nvidia.com>
Reviewed-on: http://git-master/r/118087
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Sanjay Singh Rawat <srawat@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
gcov-kernel: Add GCOV_KERNEL := y to Makefiles 2011-12-01T05:49:58+00:00 Juha Tukkinen jtukkinen@nvidia.com 2011-11-08T13:48:34+00:00 9fac242eb449b68905fd1c4b74fd94dd8ddcbc79 These changes have no effect if CONFIG_GCOV_KERNEL is not set in defconfig. It is easier to trigger GCOV for kernel if this patch is in by only setting the before mentioned flag. Change-Id: I8aade309da2da62c4b3889bd84e4123ba8f182da Signed-off-by: Juha Tukkinen <jtukkinen@nvidia.com> Reviewed-on: http://git-master/r/62999 Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com> Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com> Rebase-Id: R4c238f707f1db600f188ae83426336753992b7be 
These changes have no effect if CONFIG_GCOV_KERNEL is not set in
defconfig. It is easier to trigger GCOV for kernel if this patch
is in by only setting the before mentioned flag.

Change-Id: I8aade309da2da62c4b3889bd84e4123ba8f182da
Signed-off-by: Juha Tukkinen <jtukkinen@nvidia.com>
Reviewed-on: http://git-master/r/62999
Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>

Rebase-Id: R4c238f707f1db600f188ae83426336753992b7be
w1: master: tegra_w1: Add initial Tegra W1 master driver 2011-12-01T05:34:40+00:00 Andrei Warkentin andreiw@motorola.com 2010-06-28T22:56:06+00:00 34948d61be4f46818c50aa707c7971b69f3506a1 Initial implementation of W1 master driver for Tegra SoCs. Tested with DS2781 slave driver. Change-Id: I6cda1ea152d25a789ae6cdca96b710da72884033 Signed-off-by: Andrei Warkentin <andreiw@motorola.com> 
Initial implementation of W1 master driver for Tegra SoCs.
Tested with DS2781 slave driver.

Change-Id: I6cda1ea152d25a789ae6cdca96b710da72884033
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
drivers/power/ds2780_battery.c: add a nolock function to w1 interface 2011-11-11T17:43:49+00:00 Clifton Barnes cabarnes@indesign-llc.com 2011-11-02T20:39:52+00:00 1b4e7370d4b6591f64e12f8f35bc219996c509f6 commit 9fe678fa2feb4aaac0b4220de63e1b7f8ccebae6 upstream. Adds a nolock function to the w1 interface to avoid locking the mutex if needed. Signed-off-by: Clifton Barnes <cabarnes@indesign-llc.com> Cc: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 9fe678fa2feb4aaac0b4220de63e1b7f8ccebae6 upstream.

Adds a nolock function to the w1 interface to avoid locking the
mutex if needed.

Signed-off-by: Clifton Barnes <cabarnes@indesign-llc.com>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
MAINTAINERS: Evgeniy has moved 2011-08-25T23:25:33+00:00 Evgeniy Polyakov zbr@ioremap.net 2011-08-25T22:59:06+00:00 a801876638c5ce650223476c4eb8f37cea32dc1c Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
w1: fix for loop in w1_f29_remove_slave() 2011-08-25T23:25:33+00:00 Dan Carpenter error27@gmail.com 2011-08-25T22:59:04+00:00 58299449257566613f58dcfb757f0ba4a377987a The for loop was looking for i <= 0 instead of i >= 0 so this function never did anything. Also we started with i = NB_SYSFS_BIN_FILES instead of "NB_SYSFS_BIN_FILES - 1" which is an off by one bug. Reported-by: Bojan Prtvar <prtvar.b@gmail.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Acked-by: Jean-Franois Dagenais <dagenaisj@sonatest.com> Cc: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
The for loop was looking for i <= 0 instead of i >= 0 so this function
never did anything.  Also we started with i = NB_SYSFS_BIN_FILES instead
of "NB_SYSFS_BIN_FILES - 1" which is an off by one bug.

Reported-by: Bojan Prtvar <prtvar.b@gmail.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Jean-Franois Dagenais <dagenaisj@sonatest.com>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
atomic: use <linux/atomic.h> 2011-07-26T23:49:47+00:00 Arun Sharma asharma@fb.com 2011-07-26T23:09:06+00:00 60063497a95e716c9a689af3be2687d261f115b4 This allows us to move duplicated code in <asm/atomic.h> (atomic_inc_not_zero() for now) to <linux/atomic.h> Signed-off-by: Arun Sharma <asharma@fb.com> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
This allows us to move duplicated code in <asm/atomic.h>
(atomic_inc_not_zero() for now) to <linux/atomic.h>

Signed-off-by: Arun Sharma <asharma@fb.com>
Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/w1/slaves/w1_therm.c: add support for DS28EA00 2011-07-26T23:49:45+00:00 Christian Glindkamp christian.glindkamp@taskit.de 2011-07-26T23:08:55+00:00 f7b1371eb6b3ff72e38de220663b22f7cc9df296 Signed-off-by: Christian Glindkamp <christian.glindkamp@taskit.de> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Signed-off-by: Christian Glindkamp <christian.glindkamp@taskit.de>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>