Kernel 4.19.50+ dtoverlay=i2c-gpio, bus 3 and 4 may be mislabeled #3062
Comments
|
from config.txt: from dmesg: |
pelwell
pushed a commit
that referenced
this issue
Jul 9, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
|
It looks like the bus numbering functionality has been broken for a long time - it's caused by the refusal of the firmware to create a "reg" property as the result of an overlay parameter if one doesn't already exist. Fortunately there is a sensible default value that can be used by the overlay that causes the auto-generated number to be used unless overridden by the "bus" parameter. A fixed overlay will be in the next firmware release, but until then you can download the updated version from here: https://drive.google.com/file/d/1dTwQ3sz_q7oQyu2ytNrEF61m27beu_pz/view?usp=sharing |
|
Thanks. That was quick! (And thanks for the edit of my first comment.) |
|
Let me know when you've had chance to try it so we can close the issue. |
|
The test worked. The issue is fixed. Thank you. |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this issue
Jul 15, 2019
kernel: i2c: bcm2835: Set clock-stretch timeout to 35ms See: raspberrypi/linux#3064 kernel: xhci: add quirk for host controllers that don't update endpoint DCS See: raspberrypi/linux#3060 kernel: tty: amba-pl011: Make TX optimisation conditional See: #1017 kernel: overlays: Add real parameters to the rpi-poe overlay kernel: overlays: Correct gpio-fan gpio flags for 4.19 See: raspberrypi/linux#2715 kernel: overlays: i2c-gpio: Fix the bus parameter See: raspberrypi/linux#3062 kernel: overlays: Rename pi3- overlays to be less model-specific See: raspberrypi/linux#3052 firmware: dispmanx: Fix handling of disable_overscan to not disable it totally See: raspberrypi/linux#3059 firmware: power: Enable/disable H264 and ISP clocks with domain firmware: arm_loader: arm_64bit=0 should disable loading of kernel8.img firmware: dt-blob: CM has no activity LED
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this issue
Jul 15, 2019
kernel: i2c: bcm2835: Set clock-stretch timeout to 35ms See: raspberrypi/linux#3064 kernel: xhci: add quirk for host controllers that don't update endpoint DCS See: raspberrypi/linux#3060 kernel: tty: amba-pl011: Make TX optimisation conditional See: raspberrypi/firmware#1017 kernel: overlays: Add real parameters to the rpi-poe overlay kernel: overlays: Correct gpio-fan gpio flags for 4.19 See: raspberrypi/linux#2715 kernel: overlays: i2c-gpio: Fix the bus parameter See: raspberrypi/linux#3062 kernel: overlays: Rename pi3- overlays to be less model-specific See: raspberrypi/linux#3052 firmware: dispmanx: Fix handling of disable_overscan to not disable it totally See: raspberrypi/linux#3059 firmware: power: Enable/disable H264 and ISP clocks with domain firmware: arm_loader: arm_64bit=0 should disable loading of kernel8.img firmware: dt-blob: CM has no activity LED
pelwell
pushed a commit
that referenced
this issue
Jul 19, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
that referenced
this issue
Jul 19, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
that referenced
this issue
Jul 19, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
that referenced
this issue
Jul 19, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
TiejunChina
pushed a commit
that referenced
this issue
Jul 23, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jul 25, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jul 25, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jul 31, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jul 31, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Aug 5, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Aug 15, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Aug 28, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Aug 30, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
jason77-wang
pushed a commit
to jason77-wang/eoan-rpi4
that referenced
this issue
Sep 1, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: raspberrypi/linux#3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Sep 6, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Sep 17, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
mike-scott
pushed a commit
to mike-scott/linux
that referenced
this issue
Sep 17, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: raspberrypi/linux#3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Michael Scott <mike@foundries.io>
popcornmix
pushed a commit
that referenced
this issue
Oct 4, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 11, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
that referenced
this issue
Oct 29, 2019
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: #3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is this the right place for my bug report?
This relates to entries in config.txt. It could be either kernel or firmware. I don't know where the dividing line is.
Describe the bug
When I add two dtoverlay=i2c-gpio lines to config.txt for bus=3 and bus=4, the resulting /dev names are not consistent. If the bus=3 line precedes the bus=4 line in config.txt, then the /dev names are reversed: the one I entered as bus=3 has the name i2c-4, and vice versa. However, if the bus=4 line is first in config.txt, then they are named the same as the bus number.
To reproduce
Enter two dtoverlay=i2c-gpio lines in config.txt, one with bus=3, the other with bus=4, and the respective data and clock pins. Then reboot. Read/write the attached devices. If you entered 3 before 4, the devices will be swapped. If you entered 4 before 3, then the device name will be the same as the bus number.
Expected behaviour
My expectation is that the device I enter as bus=3 will be /dev/i2c-3, and device I enter as bus=4 will be /dev/i2c-4. It should not matter which is entered first in config.txt.
Actual behaviour
It appears that the bus=x part of the dtoverlay=i2c-gpio entry has no meaning. No matter what you enter in bus=x, the last dtoverlay line will be /dev/i2c-3, the one before that will be /dev/i2c-4. I presume, if you also entered a 3rd dtoverlay=i2c-gpio line, the first one in config.txt would be /dev/i2c-5, but I did not test this.
System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
Pi1B+
Which OS and version (
cat /etc/rpi-issue)?Raspberry Pi reference 2019-06-20
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 150e25c4f8123a4c9c63e8dca1b4737fa6c1135c, stage4
Which firmware version (
vcgencmd version)?Jun 20 2019 16:12:41
Copyright (c) 2012 Broadcom
version a59fb7a74180be0111dbc5c18a37ec6df86f14a3 (clean) (release) (start)
Which kernel version (
uname -a)?Linux rasppi4 4.19.50+ dts: overlay: add generic support for ads7846 #896 Thu Jun 20 16:09:52 BST 2019 armv6l GNU/Linux
Logs
n/a
Additional context
n/a
The text was updated successfully, but these errors were encountered: