-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SC16IS752 device tree overlay, bug? #3156
Comments
Okay I am fairly certain there is 2 bugs in this overlay. #1) Prior to making a hard coded change to the clock_frequency value in the DTS I was only getting gibberish, but on the expected cadence I am expecting. I have now hardcoded the actual frequency of my crystal, recompiled and rebooted. Now when I monitor the input, the signal is coming through perfectly as desired. #2) When I use a native GPIO (24) everything works as expected with the change to bug 1, but leaving the fix in place and reverting back to my desired gpio on the expander, the driver fails to load the chipset and the ttySC0/1 are not created. |
I can see one bug: the
However, as far as the DT goes, the |
@pelwell correct me if I'm wrong, but the 503 is the old sysfs style GPIO numbering for the line, whereas the kernel internally uses controller, and index on that controller. If you want to change to using a GPIO expander on the I2C bus then |
I can switch to a native gpio on my hat board, I was just trying to leave
as many native gpio open as possible for flexibility in adding other hats.
My expectation was that since the expander is being loaded up in the device
tree it would be usable just like the native gpio. I can understand the
distinction between a native pin and something that needs to be software
driver based though.
I appreciate the confirmation on the clock bug, I will work around until a
fix hits mainline updates. I am on Stretch for the moment, but will move
to buster before long.
…On Sat, Aug 17, 2019, 3:44 AM 6by9 ***@***.***> wrote:
@pelwell <https://github.com/pelwell> correct me if I'm wrong, but the
int_pin parameter is changing the GPIO line within the GPIO controller
specified by interrupt-parent. That's set as &gpio and you're not
changing it, therefore it is a native GPIO.
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/sc16is752-i2c-overlay.dts#L19
503 is the old sysfs style GPIO numbering for the line, whereas the kernel
internally uses controller, and index on that controller.
If you want to change to using a GPIO expander on the I2C bus then
(a) that needs to be wired up for interrupts
(b) you need to change interrupt-parent to point at that GPIO exapnder,
and
(c) int_pin needs to match the line on that controller that you wish to
use.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3156?email_source=notifications&email_token=ACPI3DN7RKPT5L3XJP466Z3QE7JBBA5CNFSM4IMAVVVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QIWQA#issuecomment-522226496>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACPI3DISVFBLWEWYOVWPW4TQE7JBBANCNFSM4IMAVVVA>
.
|
It would have helped if I'd read all the words in your post, and not conflated it with a similar sounding interrupt issue on the Forums that is all native GPIO. As @6by9 said, it is possible to use non-native GPIOs from an expander, but you would need a custom overlay to do so for a number of reasons:
The combination of those factors means that a custom overlay is probably the best way to go. Note that there is a utility, ovmerge, that can combine overlays to make a new one, renumbering fragments and allowing you to refer to labels between the constituent overlays. Because ovmerge manipulates the source code rather than compiling and decompiling, the end result is quite readable. It is currently used to maintain the upstream overlay. |
I will have a look at the ovmerge tool to streamline other overlays I am working on. I frequently have to merge overlays to get multiple devices of the same type working together, example mcp23017. I am okay with using the native gpio pin for now, I only have a few native gpio consumed and I expose several more through the expanders. I was not 100% clear on which line to make the applicable change to the xtal = .... above. Will you be updating the source with the correction? If so I will issue a "sed" command to reflect the code change in my scripts to fix the code until it hits mainline. Right now I have it decompiling, fixing the hardcode and recompiling the dtbo which works, but obviously is not the best way to do it. |
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The patch is in the rpi-4.19.y now. |
kernel: configs: Add TINYDRM modules See: raspberrypi/linux#3173 kernel: overlays: sc16ic752-i2c: Fix xtal parameter See: raspberrypi/linux#3156
kernel: configs: Add TINYDRM modules See: raspberrypi/linux#3173 kernel: overlays: sc16ic752-i2c: Fix xtal parameter See: raspberrypi/linux#3156
I think something may still be broken. I copied the entire file from the updated dts and recompiled it using dtc
and use the following to instantiate the device (note I updated the clock frequency from before to one more suitable to UART @ 115200, this should yield a perfect divisor and prescalar result in the registers of the chip)
when rebooting I get the following (which appears to be ignoring the address update since it says its looking at 0x48
any ideas? |
just to be sure, I also moved my crystal input pin back to the 12.288MHz and it still responds the same way. its possible its a soldering issue as I had to lift the pin, but I see the crystal making it into the pin at least and no obvious soldering defects when looking under magnification. I will try a second board when I get a chance just to confirm I haven't damaged the chip somehow. |
Your kernel log says
0x48 there, but you're dtoverlay line supposedly changed the address to 0x4D. I think there's something still wrong in your overlay. |
Sure thing, I will start fresh and see how it goes.
…On Sat, Aug 31, 2019, 7:06 AM 6by9 ***@***.***> wrote:
Your kernel log says
[ 4.261837] i2c i2c-1: Failed to register i2c client sc16is752 at 0x48 (-16)
0x48 there, but you're dtoverlay line supposedly changed the address to
0x4D. I think there's something still wrong in your overlay.
The change is merged into the kernel image, therefore please use
rpi-update to update a non-critical Pi to use this updated image, and
report back. Sorry, but it's nearly impossible to predict what has gone
wrong with your rebuilt dt files.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3156?email_source=notifications&email_token=ACPI3DNCNVUSH5DPGLTVYXTQHJ3EVA5CNFSM4IMAVVVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5TNM6I#issuecomment-526833273>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACPI3DOPQF3F3XKJ4PHZ2CLQHJ3EVANCNFSM4IMAVVVA>
.
|
Everything is working when I got an image up to buster and used the precompiled DTBO files |
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: raspberrypi/linux#3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Michael Scott <mike@foundries.io>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
BugLink: https://bugs.launchpad.net/bugs/1849623 The xtal parameter is targetting the wrong node - fix it. See: raspberrypi/linux#3156 Signed-off-by: Phil Elwell <phil@raspberrypi.org> (cherry picked from commit f5830465c45ca00f901f7a55fecba1e7b1fb981e https://github.com/raspberrypi/linux.git rpi-5.3.y) Signed-off-by: Hui Wang <hui.wang@canonical.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Source: kernel.org MR: 103889 Type: Enhancement Disposition: Merged from https://github.com/raspberrypi/linux.git rpi-5.4.y ChangeID: c518f0eb310430163af958d575f6ce25df586217 Description: The xtal parameter is targetting the wrong node - fix it. See: raspberrypi/linux#3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xtal parameter is targetting the wrong node - fix it. See: #3156 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
I am also documenting my ongoing debugging effort on the forums in hopes of getting some insights from the larger RPi audience, but so far the thread has been radio silence. This particular bit looks like a bug hence the report for further investigation by more knowledgeable device tree users.
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=248736
Describe the bug
In the device tree overlay for this device (I2C version only has been checked), There are 2 fields for the clocking frequency "clock-frequency=...", however it appears that only 1 gets updated as a result of the override. I haven't fully confirmed this is truly a bug, but I can't get the device to work on my crystal frequency of 12.288MHz hence the investigation into the possible causes.
To reproduce
Instantiate the device in the device tree using the clock-frequency override, in my example
dtoverlay=sc16is752-i2c,int_pin=503,xtal=12288000 (note the gpio 503 is an MCP23017 expander also on the i2c bus). I have not fully confirmed the gpio503 is correct as I see absolutely no activity on the interrupt signal from the chip so I haven't inspected the gpio in software to confirm the mapping has succeeded as predicted.
Inspect the device tree using the command
dtc -I fs /proc/device-tree
and locate the SC16IS752 device, which in my case yields the followingHere is the full dt if needed
Reviewing the clock-frequency variable, it can be observed these are not the same frequency which I believe may be causing the device to malfunction.
Expected behaviour
Unless I am misinterpriting the usage of this child block of code, the clock-frequency fields should agree.
Actual behaviour
The clocks do not match
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:
The raspinfo command fails, so filling out the details manually.
Which model of Raspberry Pi?
Pi3b
Which OS and version (
cat /etc/rpi-issue
)?Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, e910bf55ac92e27c6e77043e8995bcb5e0a2d742, stage2
Which firmware version (
vcgencmd version
)?Mar 27 2019 15:45:53
Copyright (c) 2012 Broadcom
version 2e98b31d18547962e564bdf88e57b3df7085c29b (clean) (release) (start)
Which kernel version (
uname -a
)?Linux openrepeater 4.14.98-v7+ Add FBUNSUPPORTED ioctl for bcm2708_fb #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
Logs
If applicable, add the relevant output from
dmesg
or similar.dmesg
note - I can't find where this error code is described so unable to debug it further
[ 5.466004] sc16is7xx: probe of 1-004d failed with error -22
vcdbg log msg
002345.680: brfs: File read: /mfs/sd/overlays/sc16is752-i2c.dtbo
002359.741: Loaded overlay 'sc16is752-i2c'
002359.796: dtparam: int_pin=497
002360.238: dtparam: addr=0x4D
002360.746: dtparam: xtal=12288000
Additional context
Add any other relevant context for the problem.
The text was updated successfully, but these errors were encountered: