Skip to content

SC16is752 ttySCx device not longer availible #3765

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

Closed
Thomas-GeDaD opened this issue Jul 29, 2020 · 24 comments
Closed

SC16is752 ttySCx device not longer availible #3765

Thomas-GeDaD opened this issue Jul 29, 2020 · 24 comments

Comments

@Thomas-GeDaD
Copy link

Describe the bug
I used several SC16IS752 on a Pi 4.
After the Last Update, the ttySCx devices are not longer available. After downgrading, the devices are available again. (4.19)
Seems the devices are recognized correct, but the device in /dev/ are not created.
Any Idears?

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
    PI4
  • Which OS and version (cat /etc/rpi-issue)?
    Raspberry Pi reference 2019-07-10
    Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 175dfb027ffabd4b8d5080097af0e51ed9a4a56c, stage5
  • Which firmware version (vcgencmd version)?
    Jul 17 2020 10:59:17
    Copyright (c) 2012 Broadcom
    version 21a15cb094f41c7506ad65d2cb9b29c550693057 (clean) (release) (start)
  • Which kernel version (uname -a)?
    Linux marine-control-server 5.4.51-v8+ 4.19.97 Booting RPi 4 with rootfs on SSD on USB 3 hub fails firmware#1329 SMP PREEMPT Wed Jul 29 10:33:36 BST 2020 aarch64 GNU/Linux

Logs
-dmesg:
[ 5.551930] serial serial0: tty port ttySC0 registered
[ 5.583411] serial serial1: tty port ttySC1 registered
[ 5.620841] serial serial2: tty port ttySC2 registered
[ 5.626098] serial serial3: tty port ttySC3 registered
[ 5.641702] serial serial4: tty port ttySC4 registered
[ 5.646916] serial serial5: tty port ttySC5 registered

-sudo vcdbg log msg
005693.525: brfs: File read: /mfs/sd/overlays/sc16is752-i2c.dtbo
005744.434: Loaded overlay 'sc16is752-i2c'
005744.463: dtparam: int_pin=13
005744.950: dtparam: addr=0x4c
005745.863: dtparam: xtal=14745600
005893.915: brfs: File read: 1356 bytes
005895.258: brfs: File read: /mfs/sd/overlays/sc16is752-i2c.dtbo
005946.342: Loaded overlay 'sc16is752-i2c'
005946.366: dtparam: int_pin=12
005946.834: dtparam: addr=0x49
005947.744: dtparam: xtal=14745600
006097.264: brfs: File read: 1356 bytes
006098.597: brfs: File read: /mfs/sd/overlays/sc16is752-i2c.dtbo
006149.818: Loaded overlay 'sc16is752-i2c'
006149.841: dtparam: int_pin=6
006150.311: dtparam: addr=0x48
006151.224: dtparam: xtal=14745600

-cat /proc/tty/drivers
unknown /dev/ttySC 235 0-7 serial

Additional context
Add any other relevant context for the problem.

@Thomas-GeDaD
Copy link
Author

2020-07-29_13h27_41

@pelwell
Copy link
Contributor

pelwell commented Jul 29, 2020

To be clear, you are saying that the kernel driver is outputing:

[ 5.551930] serial serial0: tty port ttySC0 registered
[ 5.583411] serial serial1: tty port ttySC1 registered
[ 5.620841] serial serial2: tty port ttySC2 registered
[ 5.626098] serial serial3: tty port ttySC3 registered
[ 5.641702] serial serial4: tty port ttySC4 registered
[ 5.646916] serial serial5: tty port ttySC5 registered

and the output from cat /proc/tty/drivers include:

unknown /dev/ttySC 235 0-7 serial

but that there is no /dev/ttySC*?

@Thomas-GeDaD
Copy link
Author

yes, exactly

@pelwell
Copy link
Contributor

pelwell commented Jul 29, 2020

Try this:

  1. Comment out the dtoverlay=sc16is752-i2c entries in config.txt and reboot.
  2. Run sudo udevadm monitor -p in one terminal.
  3. Run sudo dtoverlay sc16is752-i2c int_pin=13 addr=0x4c xtal=14745600.
  4. See if /dev/ttySC* exists.
  5. Post the output from udevadm.

@Thomas-GeDaD
Copy link
Author

KERNEL[96.856680] add /devices/platform/soc/fe804000.i2c/i2c-1/1-004c (i2c)
ACTION=add
DEVPATH=/devices/platform/soc/fe804000.i2c/i2c-1/1-004c
SUBSYSTEM=i2c
OF_NAME=sc16is752
OF_FULLNAME=/soc/i2c@7e804000/sc16is752@4c
OF_COMPATIBLE_0=nxp,sc16is752
OF_COMPATIBLE_N=1
MODALIAS=of:Nsc16is752T(null)Cnxp,sc16is752
SEQNUM=1789

KERNEL[96.884522] add /module/regmap_i2c (module)
ACTION=add
DEVPATH=/module/regmap_i2c
SUBSYSTEM=module
SEQNUM=1790

KERNEL[96.887343] add /module/regmap_spi (module)
ACTION=add
DEVPATH=/module/regmap_spi
SUBSYSTEM=module
SEQNUM=1791

UDEV [96.892598] add /module/regmap_i2c (module)
ACTION=add
DEVPATH=/module/regmap_i2c
SUBSYSTEM=module
SEQNUM=1790
USEC_INITIALIZED=96889007

UDEV [96.892770] add /module/regmap_spi (module)
ACTION=add
DEVPATH=/module/regmap_spi
SUBSYSTEM=module
SEQNUM=1791
USEC_INITIALIZED=96891677

KERNEL[96.893584] add /module/sc16is7xx (module)
ACTION=add
DEVPATH=/module/sc16is7xx
SUBSYSTEM=module
SEQNUM=1792

KERNEL[96.894100] add /bus/i2c/drivers/sc16is7xx (drivers)
ACTION=add
DEVPATH=/bus/i2c/drivers/sc16is7xx
SUBSYSTEM=drivers
SEQNUM=1793

KERNEL[96.894241] add /bus/spi/drivers/sc16is7xx (drivers)
ACTION=add
DEVPATH=/bus/spi/drivers/sc16is7xx
SUBSYSTEM=drivers
SEQNUM=1794

UDEV [96.897778] add /devices/platform/soc/fe804000.i2c/i2c-1/1-004c (i2c)
ACTION=add
DEVPATH=/devices/platform/soc/fe804000.i2c/i2c-1/1-004c
SUBSYSTEM=i2c
OF_NAME=sc16is752
OF_FULLNAME=/soc/i2c@7e804000/sc16is752@4c
OF_COMPATIBLE_0=nxp,sc16is752
OF_COMPATIBLE_N=1
MODALIAS=of:Nsc16is752T(null)Cnxp,sc16is752
SEQNUM=1789
USEC_INITIALIZED=96859644

UDEV [96.898261] add /bus/spi/drivers/sc16is7xx (drivers)
ACTION=add
DEVPATH=/bus/spi/drivers/sc16is7xx
SUBSYSTEM=drivers
SEQNUM=1794
USEC_INITIALIZED=96898036

UDEV [96.898925] add /bus/i2c/drivers/sc16is7xx (drivers)
ACTION=add
DEVPATH=/bus/i2c/drivers/sc16is7xx
SUBSYSTEM=drivers
SEQNUM=1793
USEC_INITIALIZED=96898701

UDEV [96.899796] add /module/sc16is7xx (module)
ACTION=add
DEVPATH=/module/sc16is7xx
SUBSYSTEM=module
SEQNUM=1792
USEC_INITIALIZED=96899559

=> No ttySCx available

@pelwell
Copy link
Contributor

pelwell commented Jul 29, 2020

A kernel configuration change in our 5.4 tree (CONFIG_SERIAL_DEV_BUS=y) has had the unintended consequence of preventing the char device from being created. More time is needed to understand why the other serial devices are unaffected and whether this is fixable.

@pelwell
Copy link
Contributor

pelwell commented Jul 29, 2020

See #3682 for some context.

@pelwell pelwell transferred this issue from raspberrypi/firmware Jul 29, 2020
@pelwell
Copy link
Contributor

pelwell commented Jul 29, 2020

[ Issue moved to the linux repo ]

@gentoo-root
Copy link
Contributor

A kernel configuration change in our 5.4 tree (CONFIG_SERIAL_DEV_BUS=y) has had the unintended consequence of preventing the char device from being created. More time is needed to understand why the other serial devices are unaffected and whether this is fixable.

Without this config option, of_serdev_register_devices doesn't run. What is function does is, when some subnodes are defined in DT of the serial device, and it probes their drivers. Later on, tty_port_register_device_attr_serdev looks at the return code of serdev_tty_port_register and skips creating the TTY device if any child devices were registered by of_serdev_register_devices. The purpose is to prevent exposing the TTY device to the userspace if some kernel driver uses the same netdev simultaneously, which makes sense.

In our case, I see that sc16is752-i2c-overlay.dts defines a sc16is752 serial device with one child: sc16is752_clk. So, the driver for this sc16is752_clk device is probed and it uses the serdev, that's why it's not exposed as a TTY device to the userspace.

Unfortunately, I have no knowledge of what this device is, so I don't know if this clk device is needed or not. It looks like it's some auxiliary device needed by the serial port that doesn't actually interfere with it. We need to understand if it's needed, because I think the clk device wasn't probed before CONFIG_SERIAL_DEV_BUS=y (or was it probed in a different way? Please advise). Workarounds could be to blacklist the clk driver, disable this subnode (with a dtparam?), remove it, but if it's actually needed, we need to find some other way, and we need to understand how it was probed before. Reverting CONFIG_SERIAL_DEV_BUS to m in defconfig is not a good option, we need to find the real root cause, because probing of the device in topic shouldn't break if we enable additional kernel options.

@HiassofT
Copy link
Contributor

The sc16is75x overlays are a bit odd, the fixed-clock node should probably be moved to / (or /clocks?), as it's probably an external oscillator, not a clock output provided by the device.

@Thomas-GeDaD
Copy link
Author

Yes the clock can define by an external oscillator. Typicly xtal=14745600

@connection-reset
Copy link

connection-reset commented Jul 30, 2020

As far as I understand the clock frequency is required or else the chip will not function [1, page 16f., 7.8 Programmable baud rate generator].
The device tree bindings support setting the clock frequency directly via the clock-frequency property instead of referencing a clock [2], the ttySC* devices get created in /dev and work just like before.

@pelwell
Copy link
Contributor

pelwell commented Jul 30, 2020

The reason the fixed clock (an expensive way to wrap an integer) is embedded within the sc16is75x node is to guarantee that it is unique. The firmware doesn't automatically uniquify node names that clash, resulting in phandles getting overwritten and the ensuing mayhem, but there are other options that I'm exploring.

pelwell added a commit that referenced this issue Jul 30, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
@pelwell
Copy link
Contributor

pelwell commented Jul 30, 2020

Bleeugh (or however you spell that):

  1. Clocks have to have names (which seems unnecessary when the clock is created and located by Device Tree, but ho hum.
  2. Clock names have to be unique, otherwise Linux objects. And what would be the point.
  3. Clocks created by device tree get their name from the clock-output-name property, or from the node name.
  4. Node names don't include the address, therefore it isn't sufficient to uniquify the clock's node name by appending an address.

The overlay parameter mechanism allows a node's address to be changed by writing to the reg property, but that doesn't help the problem of unique clock names. The ugly workaround is to change the entire node name by writing to the magic name property. This unfortunately change the name to something like 0x48, but at least it should be unique. I think the firmware also needs to know how to generate unique names by some other means.

Anyway, there's a new patch in rpi-5.4.y that moves the clock nodes to the root to stop them looking like serdev nodes. reviewing them has revealed a number of errors, so it was a worthwhile exercise.

@pelwell
Copy link
Contributor

pelwell commented Jul 30, 2020

Running with:

dtoverlay=sc16is750-i2c,int_pin=12,addr=0x4c,xtal=14745600
dtoverlay=sc16is750-i2c,int_pin=13,addr=0x4d,xtal=14745600
dtoverlay=sc16is752-i2c,int_pin=16,addr=0x4e,xtal=14745600
dtoverlay=sc16is752-i2c,int_pin=17,addr=0x4f,xtal=14745600

results in:

pi@raspberrypi:~ $ ls -l /dev/ttySC*
crw-rw---- 1 root dialout 234, 0 Jul 30 15:10 /dev/ttySC0
crw-rw---- 1 root dialout 234, 1 Jul 30 15:10 /dev/ttySC1
crw-rw---- 1 root dialout 234, 2 Jul 30 15:10 /dev/ttySC2
crw-rw---- 1 root dialout 234, 3 Jul 30 15:10 /dev/ttySC3
crw-rw---- 1 root dialout 234, 4 Jul 30 15:10 /dev/ttySC4
crw-rw---- 1 root dialout 234, 5 Jul 30 15:10 /dev/ttySC5

so we're back in business.

popcornmix added a commit to raspberrypi/firmware that referenced this issue Jul 31, 2020
See: raspberrypi/linux#3765

kernel: overlays: Delete spi0-hw-cs
See: raspberrypi/linux#3355

kernel: backlight: gpio: Explicitly set the direction of the GPIO
See: raspberrypi/linux#3767

kernel: overlays: Add maxtherm overlay for MAX6675/31855
See: raspberrypi/linux#3763

firmware: arm_loader: Knock 1.7 seconds off boot time
See: #1375

firmware: Imx477 external sync signals
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Jul 31, 2020
See: raspberrypi/linux#3765

kernel: overlays: Delete spi0-hw-cs
See: raspberrypi/linux#3355

kernel: backlight: gpio: Explicitly set the direction of the GPIO
See: raspberrypi/linux#3767

kernel: overlays: Add maxtherm overlay for MAX6675/31855
See: raspberrypi/linux#3763

firmware: arm_loader: Knock 1.7 seconds off boot time
See: raspberrypi/firmware#1375

firmware: Imx477 external sync signals
@popcornmix
Copy link
Collaborator

This should be resolved in latest rpi-update kernel.

@Thomas-GeDaD
Copy link
Author

Have tested with this raspberrypi/firmware@bd816db firmware commit and seems to work fine. Tested with 3x sc16is752
Many thanks and real good work!! When is the release with the next stable fw?

pelwell added a commit that referenced this issue Aug 12, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Aug 12, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
pelwell added a commit that referenced this issue Aug 18, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Aug 19, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Aug 19, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Sep 1, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Sep 1, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Sep 11, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Sep 15, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Sep 28, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Oct 2, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Oct 7, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Oct 16, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Oct 19, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Nov 4, 2020
Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: #3765

Signed-off-by: Phil Elwell <[email protected]>
@Aalococo
Copy link

Aalococo commented Dec 1, 2020

Hi there,
im not really into dt overlays but i have a similar Problem . I recently updated my pi 3 and now cant find ttySC0 and SC1 anymore as described above. I can find the following lines in dmesg after booting:

[ 7.778335] serial serial0: tty port ttySC0 registered
[ 7.778926] serial serial1: tty port ttySC1 registered

As i understand for some of you the Problem got solved but i cant figure out how ?

@pelwell
Copy link
Contributor

pelwell commented Dec 1, 2020

You say you aren't into overlays, but are you using one?

If you read through the above comments carefully you find that there were two significant changes:

  1. The "fixed-clock" declaration was moved out of the declaration of the main sc16is752 node, because its presence was making the kernel think it was going to be used as a bus for other kernel-controlled devices, rather than being user-accessible.
  2. To allow multiple instances of the sc1is752 to be used simultaneously, the overlay was modified to give the clock a unique-ish name to stop it clashing.

These changes have been present in all kernels released since the end of August.

@Aalococo
Copy link

Aalococo commented Dec 1, 2020

thanks pelwell for the quick answer. Yes im using one but i made it copying together stuff that i dont quite understand enough to debug it myself. I added aditional aditional spi channels and the sc16 to my dt:

I understand i have to change something about my fixed-clock but i dont know what to do about it ? Here is my overlay:

`/dts-v1/;
/plugin/;

/ {
compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2837", "brcm,bcm2708", "brcm,bcm2709";

fragment@0 {
	target = <&spi0>;
	frag0: __overlay__ {
		#address-cells = <1>;
		#size-cells = <0>;
		pinctrl-0 = <&spi0_pins &spi0_cs_pins>;
		status = "okay";
		cs-gpios = <&gpio 8 1>, <&gpio 7 1>, <&gpio 23 1>, <&gpio 24 1>, <&gpio 25 1>, <&gpio 5 1>, <&gpio 6 1>, <&gpio 26 1>, <&gpio 4 1>;

		spidev@0{
                compatible = "spidev";
                reg = <0>;      /* CE0 */
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
                };

		spidev@1{
                compatible = "spidev";
                reg = <1>;      /* CE1 */
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
                };



		spidev@2{
			    compatible = "spidev";
		        reg = <2>;	/* CE2 */
		        #address-cells = <1>;
		        #size-cells = <0>;
			    spi-max-frequency = <4000000>;
            	};

		spidev@3{
		        compatible = "spidev";
		        reg = <3>;	/* CE3 */
			    #address-cells = <1>;
		        #size-cells = <0>;
		        spi-max-frequency = <4000000>;
	            };

		spidev@4{
                compatible = "spidev";
                reg = <4>;      /* CE4 */
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
                };

		spidev@5{
                compatible = "spidev";
                reg = <5>;      /* CE5 */
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
                };

		spidev@6{
                compatible = "spidev";
                reg = <6>;      /* CE6 */
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
                };

		spidev@7{
                compatible = "spidev";
                reg = <7>;      /* CE7 */
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
                };
		
        sc16is752: sc16is752@8 {
            compatible = "nxp,sc16is752";
            reg = <8>; /* CE8  */
            clocks = <&sc16is752_clk>;
            interrupt-parent = <&gpio>;
            interrupts = <17 2>; /* IRQ_TYPE_EDGE_FALLING */
            gpio-controller;
            #gpio-cells = <2>;
            spi-max-frequency = <4000000>;
                status = "okay";

            sc16is752_clk: sc16is752_0_clk {
                compatible = "fixed-clock";
                #clock-cells = <0>;
                clock-frequency = <14745600>;
                };
        };
	};
};

fragment@1 {
	target = <&gpio>;
	__overlay__ {
		spi0_cs_pins: spi0_cs_pins {
			brcm,pins = <8 7 23 24 25 5 6 26 4>;
			brcm,function = <1>; /* out */
		};
	};
};

/*
__overrides__ {
	
    int_pin = <&sc16is752>,"interrupts:0";
                  

};
*/

};
`

@pelwell
Copy link
Contributor

pelwell commented Dec 1, 2020

Move it to the top level - this is one of the official overlays: https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/overlays/sc16is752-spi0-overlay.dts

You can just copy fragment 2:

	fragment@2 {
		target-path = "/";
		__overlay__ {
			sc16is752_clk: sc16is752_spi0_0_clk {
				compatible = "fixed-clock";
				#clock-cells = <0>;
				clock-frequency = <14745600>;
			};
		};
	};

@Aalococo
Copy link

Aalococo commented Dec 1, 2020

Thanks a million times :)

@vohum
Copy link

vohum commented Feb 22, 2021

Hi I have problem with my custom board, I tried write dts for my board
CS-gpios: 8 7 25 16 23
CS0 - SC16IS752 (IRQ 24)
CS1 - MCP2515
CS2 - RFID RC522 module
CS3 - RFID RC522 module
CS4 - SC16IS752 (IRQ 27)

/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709";

	fragment@0 {
		target = <&spi0>;
		frag0: __overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			pinctrl-0 = <&spi0_pins &spi0_cs_pins>;
			status = "okay";
			cs-gpios = <&gpio 8 1>, <&gpio 7 1> , <&gpio 25 1>, <&gpio 16 1>, <&gpio 23 1>;

			sc16is752_1: sc16is752@0 {
				compatible = "nxp,sc16is752";
				reg = <0>; /* CE0 */ 
				clocks = <&sc16is752_clk>;
				interrupt-parent = <&gpio>;
				interrupts = <24 2>; /* IRQ_TYPE_EDGE_FALLING */
				#gpio-controller;
				#gpio-cells = <2>;
				spi-max-frequency = <4000000>;
			};
			
			spidev@1{
                compatible = "spidev";
                reg = <1>; /* CE1 */ /*CAN*/
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
             };
			
			spidev@2{
                compatible = "spidev";
                reg = <2>; /* CE2 */ /*RFID_1*/
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
             };
			 
			spidev@3{
                compatible = "spidev";
                reg = <3>; /* CE3 */ /*RFID_2*/
                #address-cells = <1>;
                #size-cells = <0>;
                spi-max-frequency = <4000000>;
            };

			sc16is752_2: sc16is752@4 {
				compatible = "nxp,sc16is752";
				reg = <4>; /* CE4 */
				clocks = <&sc16is752_clk>;
				interrupt-parent = <&gpio>;
				interrupts = <27 2>; /* IRQ_TYPE_EDGE_FALLING */
				#gpio-controller;
				#gpio-cells = <2>;
				spi-max-frequency = <4000000>;
			};
		};
	};

	fragment@1 {
		target = <&gpio>;
		__overlay__ {
			spi0_cs_pins: spi0_cs_pins {
				brcm,pins = <8 7 25 16 23>;
				brcm,function = <1>; /* out */
			};
		};
	};	

	fragment@2 {
		target-path = "/";
		__overlay__ {
			sc16is752_clk: sc16is752_spi0_0_clk {
				compatible = "fixed-clock";
				#clock-cells = <0>;
				clock-frequency = <14745600>;
			};
		};
	};
};

I think device init correcty

ls /dev/spidev*
/dev/spidev0.1  /dev/spidev0.2  /dev/spidev0.3
ls /dev/ttySC*
/dev/ttySC0  /dev/ttySC1  /dev/ttySC2  /dev/ttySC3

But any SPI device don't work, and cs is set to low level

raspi-gpio get
BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=1 fsel=4 alt=0 func=SDA1
GPIO 3: level=1 fsel=4 alt=0 func=SCL1
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=0 fsel=0 func=INPUT
GPIO 6: level=0 fsel=0 func=INPUT
GPIO 7: level=1 fsel=4 alt=0 func=SPI0_CE1_N
GPIO 8: level=1 fsel=1 func=OUTPUT
GPIO 9: level=1 fsel=4 alt=0 func=SPI0_MISO
GPIO 10: level=0 fsel=4 alt=0 func=SPI0_MOSI
GPIO 11: level=0 fsel=4 alt=0 func=SPI0_SCLK
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=1 fsel=0 func=INPUT
GPIO 16: level=1 fsel=1 func=OUTPUT
GPIO 17: level=1 fsel=0 func=INPUT
GPIO 18: level=0 fsel=1 func=OUTPUT
GPIO 19: level=1 fsel=0 func=INPUT
GPIO 20: level=0 fsel=0 func=INPUT
GPIO 21: level=1 fsel=0 func=INPUT
GPIO 22: level=0 fsel=0 func=INPUT
GPIO 23: level=0 fsel=1 func=OUTPUT
GPIO 24: level=0 fsel=1 func=OUTPUT
GPIO 25: level=0 fsel=1 func=OUTPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=1 fsel=0 func=INPUT

@mondocata
Copy link

mondocata commented Oct 18, 2023

Same issue here, after the new verion of Raspbian from May or October.
Until now i can't find the right solution to work my Waveshare 2-CH RS 485 HAT.

In the past i used this in config :
dtoverlay=sc16is752-spi1,int_pin=24,addr=0x48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants