Help wanted to test a new OpenVFD alternative

[Jean-Francois Lessard]

Hi

 

I've made a new kernel Auxiliary Display Driver for TM16XX and compatible LED controllers. This driver supports various LED controller chips, including TM16XX family, FD6XX family, PT6964, and HBS658. It provides support for both I2C and SPI interfaces.

 

I wanted it to manage the hardware on the kernel space while having an easy sysfs user space interface. It also aims to reduce the code to maintain by relaying on existing kernel features instead of recoding them. Plus, you can switch to hardware i2c/spi (instead of software gpio) depending on the pins used.

 

You can use "vfdconf-convert" to convert your existing vfd.conf to its device-tree version.  Or you can use the already converted vfd.conf of https://github.com/arthur-liberman/vfd-configurations that are listed in the device table.

 

You don't need to manually edit your device tree, the "make" command will apply the device tree source overlay to your dtb.

 

It comes with a service written as a simple bash script. So it's easily customizable without having to write custom C code.

 

Instructions and source code at https://github.com/jefflessard/tm16xx-display/

 

Could you please give it a try and report your feedback? 

[ning]

I'm happy to and will test your driver on JianPian Rk3566 TV box.

[Jean-Francois Lessard]

@ning thank you! Do you have an existing vfd.conf for this device? Couldn't find one online. Let me know if you need help for it's configuration.

[ning]

I don't have vfd.conf. I can try the drivers one by one, then try to write a conf.

[Jean-Francois Lessard]

I have added rk3566-h96-max-v56 to the repo. You could try with this one.

 

I think the JianPian is very similar to H96 Max V56 so I made this config file from this post.

 

This is a blind attempt... I have no much info on the JianPian and I have no way to test the config. Let me know if it works for you.

 

[ning]

OK, I will try this suggestion.

[ning]

the correct part is VFD device is fdhisi,fd6551, I see the chip on board.

 

but the i2c gpios are icorrect..

[ning]

it's on i2c4. I don't see I2c error during probe. please let me know what to do next!

 

&i2c4 {
        status = "okay";

        vfd@24 {
                compatible = "fdhisi,fd6551";
                reg = <0x24>;

                tm16xx,digits = [04 03 02 01];
                tm16xx,segment-mapping = [03 01 02 06 04 05 00];

                #address-cells = <2>;
                #size-cells = <0>;

                led@0,0 {
                        reg = <0 0>;
                        function = LED_FUNCTION_ALARM;
                };

                led@0,1 {
                        reg = <0 1>;
                        function = LED_FUNCTION_USB;
                };

                led@0,3 {
                        reg = <0 3>;
                        function = "play";
                };

                led@0,2 {
                        reg = <0 2>;
                        function = "pause";
                };

                led@0,4 {
                        reg = <0 4>;
                        function = "colon";
                };

                led@0,5 {
                        reg = <0 5>;
                        function = LED_FUNCTION_LAN;
                };

                led@0,6 {
                        reg = <0 6>;
                        function = LED_FUNCTION_WLAN;
                };
        };
};

 

[ning]

use sysfs leds interface to control it

 

but it doesn't show any thing...

[Jean-Francois Lessard]

All LEDs should be on when you probe the driver, before writing to sysfs LEDs. You can also enable debug to see what bytes are being written to the controller.

 

```

 

systemctl stop display

 

make debug module-install

rmmod tm16xx

# clear previous kernel logs

dmesg -c > /dev/null

 

modprobe tm16xx

# you should see all LEDs ON

 

# check probe logs 

dmesg -c

 

echo 1 > /sys/class/leds/display\:\:lan/brightness

# you should see only LAN led on

 

# check new logs

dmesg -c

 

```

 

You can paste the probe logs here so I can see what is happening on the wire

 

[ning]

I checked your code, the i2c address is correct, brightness register is correct. dig registers are correct.

 

it should work, but no.

 

I don't know why, let me check fd6551's VDD.

 

if there no power, will it answer I2C command, I2C write should return -1, but no error in dmesg.

[Jean-Francois Lessard]

i2c slaves usually responds with ACK. But maybe rockchip hardware i2c doesn't check this. Of course, if there is no VDD to the controller, this would have to be investigated first.

 

Otherwise, just throwing some ideas here:

 

1. It might be a problem with hardware i2c. You could use software i2c to validate this assomption. By keeping i2c4 disabled and configuring i2c-gpio instead (example template here). Using i2c-gpio, you should see if controller doesn't not ACK in dmesg.

 

2. May be an issue with the led controller identification. For example, some magicsee-n5 boards have the fd6551 chip but use brightness commands of the fd655 chip. You could try setting compatible to "fdhisi,fd655".

 

In anyway, it would be easier to start from a known working configuration. Since you don't have an OpenVFD vfd.conf, would you mind sharing the Android dtb from the original firmware?

[ning]

after read spec, 7 SEG pins for 7 LEDs (LAN, WIFI...etc) and 4 DIG pins control 4 digital.

 

5 DIG pins are controlled by 66h~6eh, while 4 digitals

 

how to control seg pins? use 1 DIG pin? I guess Yes. each digital has 7 LEDs, and there also 7 Seg LED.

 

write number to DIG register, at least 1 LED will on.

 

OK. 1 DIG pin controls 1 digtal, and each digital has 7 seg, 1 seg connects to 1 SEG pin.  there are 5 digitals (one virtual), and they share SEG pins.

 

So let me check VDD.

[ning]

it's easy to try fd655 and i2c-gpio. and I read Android dts many times, not findings.

jianpian.dts

[Jean-Francois Lessard]

After reviewing your original dtb I found that i2c4 is disabled (i2c@fe5d0000 uses pinctrl with phandle <0xdd>).

 

But 2 pins are defined on the top level fddis_dev:

```

fddis_dev {

  fddis_gpio_dat = <0x35 0x0c 0x00>;

  fddis_gpio_clk = <0x35 0x0b 0x00>;

  compatible = "fddis_dev"; status = "okay";

};

```

 

This means that original firmware uses software i2c. So start with i2c-gpio first. Once everything works then you could later try moving to hardware i2c if you like.

 

Please try the conf I've created for you. It already has this pin definition: rk3566-h96-max-v56. 

[Jean-Francois Lessard]

I've looked at rk3368.dtsi and there is no hardware i2c on pins RK_PB3 and RK_PB4. So you really need to stick to  software "i2c-gpio".

Edited August 14 by Jean-Francois Lessard

[ning]

	i2c1 {
		/omit-if-no-ref/
		i2c1_xfer: i2c1-xfer {
			rockchip,pins =
				/* i2c1_scl */
				<0 RK_PB3 1 &pcfg_pull_none_smt>,
				/* i2c1_sda */
				<0 RK_PB4 1 &pcfg_pull_none_smt>;
		};
	};

phandle 0x35  is gpio0

[ning]

[   23.946809] tm16xx 4-0034: Display initialized successfully

 

i2c4 is bad, any address can have good write result.

[ning]

use i2c1, error timeout, use gpio-i2c error no such device.

 

let me check power VDD.

[Jean-Francois Lessard]

3 hours ago, ning said:

use gpio-i2c error no such device

 

3 hours ago, ning said:

phandle 0x35  is gpio0

 

gpio-i2c is not the same as i2c-gpio. Have you tried rk3566-h96-max-v56 ? Pins already refer to &gpio0

[ning]

VDD has 3.3V..

 

I have no idea now.

[ning]

in fd6551 data sheet, page 7, it says: clk better lower than 100K.

 

I don't know how to set i2c-rockchip or i2c-gpio to 100k or lower? i2c-gpio,delay-us = <10>; ?

 

http://www.fdhisi.com/down/upload/20191023/1571794231.pdf