On Sun, Apr 24, 2016 at 11:01:33PM +0200, Juan García Pastor wrote: > Hi, > > We are integrating the sc16is752 chip with a Raspberry compute module. Our > final objective is to obtain 2 UARTs from the I2C channel provided by the > compute module. > > We are facing difficulties accessing the UARTs from the Compute Module. I > will explain first the electrical lay-out and then the configuration done in > the Compute Module. > > I try to be very clear explaining all what we have done. Some things may be > evident, but I think they will be a good help for anyone dealing with > similar problems. I hope advanced developers will understand. Specific > questions are at the end of the mail. > > The connections diagram is: > Raspberry compute module to SC16IS752 pin connections: > RaspberryPiComputeModule Pin-9 (SDA) to sc16is752 Pin-14 > RaspberryPiComputeModule Pin-11 (SCL) to sc16is752 Pin-13 > > We use pool-up resistances (1.8K) in both signals. > > Compute Module configuration: > > I2C: > The first step is to enable the i2c bus within the raspberry advanced > options with the command: > raspi-config > Install the i2c-tools with the command: > sudo apt-get install i2c-tools > Once configured and installed the tools, execute command: > i2cdetect -y 1 (the 1 comes from the fact that we phisically use i2c 1) > Output: > 0 1 2 3 > 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- > -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- > -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- > -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- > -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- > -- -- -- -- -- 4d -- -- > 50: -- -- -- -- -- -- -- -- > -- -- -- -- -- -- -- -- > 60: -- -- -- -- -- -- -- -- > -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- > -- > We will use this ?4d?, later in the .dts file > > Module/driver: > We try now to generate upon the sources in Linux kernel (?sc16is7xx.c?), a > file called ?sc16is7xx.ko, which defines the way how the operating system > will communicate with the chip sc16is752. > We have here the doubt if there is any parameter we need to specify in the > file to make it coherent with the specific Compute Module hardware. We are > concerned that we do not define in any place the descriptors of the ports > that we should use to access both UARTS. We have found some references in > google to /dev/ttySC0 and /dev/ttySC1, but no parameter like this is defined > nowhere, so we basically think something is missing. > > The ?sc16is7xx.c? file: > ---- > https://github.com/raspberrypi/linux/blob/rpi-4.1.y/drivers/tty/serial/sc16i > s7xx.c > ---- > > Our ?/boot/config.txt? file is configured like: > ---------------------------------------------------------------------------- > --- > # For more options and > information see > # > http://www.raspberrypi.org/documentation/configuration/config-txt.md > # Some settings may impact > device functionality. See link above for details > > # uncomment if you get no > picture on HDMI for a default "safe" mode > #hdmi_safe=1 > > # uncomment this if your > display has a black border of unused pixels visible > # and your display can output > without overscan > #disable_overscan=1 > > # uncomment the following to > adjust overscan. Use positive numbers if console > # goes off screen, and > negative if there is too much border > #overscan_left=16 > #overscan_right=16 > #overscan_top=16 > #overscan_bottom=16 > > # uncomment to force a > console size. By default it will be display's size minus > # overscan. > #framebuffer_width=1280 > #framebuffer_height=720 > > # uncomment if hdmi display > is not detected and composite is being output > #hdmi_force_hotplug=1 > > # uncomment to force a > specific HDMI mode (this will force VGA) > #hdmi_group=1 > #hdmi_mode=1 > > # uncomment to force a HDMI > mode rather than DVI. This can make audio work in > # DMT (computer monitor) > modes > #hdmi_drive=2 > > # uncomment to increase > signal to HDMI, if you have interference, blanking, or > # no display > #config_hdmi_boost=4 > > # uncomment for composite PAL > #sdtv_mode=2 > > #uncomment to overclock the > arm. 700 MHz is the default. > #arm_freq=800 > > # Uncomment some or all of > these to enable the optional hardware interfaces > #dtparam=i2c_arm=on > #dtparam=i2s=on > #dtparam=spi=on > > # Uncomment this to enable > the lirc-rpi module > #dtoverlay=lirc-rpi > > # Additional overlays and > parameters are documented /boot/overlays/README > > # ----> I have tested here with different values > matching the .dts file > # > dtoverlay=sc16is752-i2c,clkrate=48000000,irqpin=21 > > dtoverlay=sc16is752-i2c,clkrate=100000,irqpin=22 > # ----> I have tested here > with i2c_arm=on and (i2c0=on and i2c1=on), since we found some reference > that this second option was needed for raspberry compute module > #dtparam=i2c_arm=on > dtparam=i2c0=on > dtparam=i2c1=on > > ---------------------------------------------------------------------------- > --- > > We have tested with following dts files: > .dts version 1 > ---------------------------------------------------------------------------- > --- > // Overlay for the SC16IS752 > I2C-connected UART > /dts-v1/; > /plugin/; > > / { > > compatible = "brcm,bcm2708"; > > > fragment@0 { > > target = <&i2c_arm>; > > __overlay__ { > > > #address-cells = <1>; > > #size-cells > = <0>; > > status = > "okay"; > > > sc16is752: sc16is752@4d > { /*4d is the > address identified with i2cdetect command*/ > > compatible = "nxp,sc16is752"; > > reg = <0x4d>; > > clocks = <&sc16is752_clock>; > > interrupt-parent = <&gpio>; > > interrupts = <255 2>; /* high-to-low edge triggered */ > > gpio-controller; > > #gpio-cells = <2>; > > }; > > }; > > }; > > > fragment@1 { > > target = <&clocks>; > > __overlay__ { > > > #address-cells = <1>; > > #size-cells > = <0>; > > status = > "okay"; > > > sc16is752_clock: sc16is752_clock@10 { > > compatible = "fixed-clock"; > > reg = <10>; > > #clock-cells = <0>; > > clock-output-name = "sc16is752"; > > clock-frequency = <100000>; > > }; > > }; > > }; > > > fragment@2 { > > target = <&gpio>; > > __overlay__ { > > sc16is752_pins: sc16is752_pins { > > > brcm,pins = <255>; > > > brcm,function = <0>; /* in */ > > }; > > }; > > }; > > > __overrides__ { > > clkrate = > <&sc16is752_clock>,"clock-frequency:0"; > > irqpin = <&sc16is752>,"interrupts:0", > > <&sc16is752_pins>,"brcm,pins:0"; > > }; > }; > ---------------------------------------------------------------------------- > --- > > > .dts version 2 > ---------------------------------------------------------------------------- > --- > // Definitions for SC16IS752 > UART > /dts-v1/; > /plugin/; > > / { > compatible = > "brcm,bcm2708"; > > fragment@0 { > target = > <&i2c1>; > __overlay__ > { > > #address-cells = <1>; > > #size-cells = <0>; > > status = "okay"; > > > sc16is752: sc16is752@4d > { /*4d is the > address identified with i2cdetect command*/ > > compatible = "nxp,sc16is752"; > > reg = <0x4D>; > > clocks = <&klok>; > > interrupt-parent = <&gpio>; > > interrupts = <23 0x2>; /* falling edge */ > > > klok: klok { > > compatible = "fixed-clock"; > > #clock-cells = <0>; > > clock-frequency = <100000>; > > }; > > }; > }; > }; > }; > ---------------------------------------------------------------------------- > --- > > The commands used to gerarate .dtb from .dts and .dts from .dtb are: > # Generate dtb from dts > dtc -O dtb -o nombre_de_fichero.dtbo -b 0-@ file_name.dts > # Generate dts from dtb > dtc -I dtb -O dts /boot/overlays/file_name.dtb > /path/file_name.dts > > > > And now the questions: > 1. Is it needed to load the model sc16is7xx.ko and/or configure the device > tree (one, other or both, we believe both)?. Maybe both. > 2. Is it needed to configure/adapt the sc16is7xx.c somehow?. Specially > dealing with the access to /dev/ttySC0 and /dev/ttySC1. This is really our > problem: we are not able to find these devices in our system. Does the driver bind to the device, or at least get probed? Your dts file needs to properly describe the hardwaer so that the driver can know to bind to it. And I can't read the above formatted dts files, sorry, your email client mangled them horribly. > 3. Is it needed to consider the sc16is7xx.c code to generate the .dts file > for the device tree?. Do we need to change anything in .dts file? Probably, see above. > 4. Is .dts version1 or version2 correct?. Which one should we use?. Any > changes needed? No idea, I can't read them :) > 5. Is there any file where the devices /dev/ttySC0 y /dev/ttySC1 should be > declared? What do you mean by this? The kernel will generate the device nodes using devtmpfs, if your distro uses that. Does it? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
