1-Wire in Parasite Power configuration (1-Wire using 2 wires) does not work in 4.19.42 #1143
Comments
|
yup updated my pi zero friday to find my 1 wire DS18B20 reporting in some wildly wrong values (should be closer to 9000. reverted to a backup disk image to double check the sensor wasn't broken, then updated to find the broken values returned) Linux raspberrypi 4.19.42+ #1219 Tue May 14 21:16:38 BST 2019 armv6l GNU/Linux |
|
same for me, had to revert to 4.14 kernel to get correct DS18B20 readings again... |
|
I believe I have a fix for this now, but its waiting on the delivery of some new DS18B20s. (Of the two I have, one is on a module with an LED draining the power, and the other appears to be dead.) |
pelwell
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jun 12, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
|
As in previous w1 failures, the downstream support for Device Tree and module parameters had been dropped due to a merge conflict. The conflict is understandable - most of the work for supporting strong pullup is now standard in the upstream kernel, but the w1-gpio driver had a bug: by failing to ensure the data pin was an output, the attempt to drive the line high was failing. This bug should now be fixed in the source repo. N.B. The parasitic power feature is now enabled by default, meaning the N.B.2. Support for module parameters has been removed pending an outcry. |
popcornmix
added a commit
that referenced
this issue
Jun 13, 2019
kernel: w1: w1-gpio: Make GPIO an output for strong pullup See: #1143 kernel: IQAudio: Fixed 48k timing issue See: raspberrypi/linux#3003 kernel: i2c: bcm2835: Model Divider in CCF See: raspberrypi/linux#3011 kernel: staging: bcm2835-codec: Convert V4L2 nsec timestamps to MMAL usec kernel: staging: bcm2835-codec: Add support for setting S_PARM and G_PARM kernel: bcm2835-sdhost: Fix DMA channel leak on error/remove
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this issue
Jun 13, 2019
kernel: w1: w1-gpio: Make GPIO an output for strong pullup See: raspberrypi/firmware#1143 kernel: IQAudio: Fixed 48k timing issue See: raspberrypi/linux#3003 kernel: i2c: bcm2835: Model Divider in CCF See: raspberrypi/linux#3011 kernel: staging: bcm2835-codec: Convert V4L2 nsec timestamps to MMAL usec kernel: staging: bcm2835-codec: Add support for setting S_PARM and G_PARM kernel: bcm2835-sdhost: Fix DMA channel leak on error/remove
TiejunChina
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jun 19, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jun 26, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jun 26, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jun 26, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 1, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 4, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 12, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 16, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 19, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 19, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
TiejunChina
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 23, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 25, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 25, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 31, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jul 31, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Aug 5, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
mike-scott
pushed a commit
to mike-scott/linux
that referenced
this issue
Aug 14, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Aug 15, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Aug 15, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Aug 28, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Aug 28, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Aug 30, 2019
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Sep 16, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 2, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 2, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 7, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 10, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 10, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 14, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 14, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 17, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 21, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 23, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Oct 28, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 1, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 5, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 6, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 8, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 11, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 18, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 18, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 18, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 25, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Nov 25, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Dec 7, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Dec 9, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Dec 10, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Dec 16, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Dec 16, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Dec 20, 2024
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jan 2, 2025
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
pushed a commit
to raspberrypi/linux
that referenced
this issue
Jan 2, 2025
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <phil@raspberrypi.org> drivers: w1-gpio: add flag to force read-polling while delaying On Pi 5, the link to RP1 will bounce in and out of L1 depending on inactivity timers at both the RC and EP end. Unfortunately for bitbashing 1-wire, this means that on an otherwise idle Pi 5 many of the reads/writes to GPIO registers are delayed by up to 8us which causes mis-sampling of read data and trashes write bits. By issuing dummy reads at a rate greater than the link inactivity timeout while spinning on a delay, PCIe stays in L0 which does not incur additional latency. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> drivers: w1-gpio: Fixup uninitialised variable use in w1_gpio_probe Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I had working setup of two 1-Wire devices (DS18B20) in parasite mode.
/boot/config.txt: dtoverlay=w1-gpio,gpiopin=4,pullup=on
It stopped working right after the kernel upgrade to the latest version
Linux raspberrypi 4.19.42+ #1219 Tue May 14 21:16:38 BST 2019 armv6l GNU/Linux
Both sensors are correctly detected by the system, however reporting 85000, which is value after sensor restart. From the symptoms, it looks that the strong pull-up functionality necessary for the parasite mode is not working.
Can anybody confirm that 1-Wire devices in parasite mode are working in the latest kernel?
Note: @iz8mbw had similar problem in #348 some time ago.
The text was updated successfully, but these errors were encountered: