Jean-Francois Lessard

@L Jumadi there is something weird about this open vfd configuration `openvfd_chars = [02 01 02 03 04];` and the resulting conversion in device tree for my driver. Grid index 02 is used twice. LEDs should not use the same grid index as the digits. There might be some special handling of this case in the OpenVFD driver (to be confirmed by reviewing OpenVFD code). The controller typically use an array of 5 grids (indexed from 0 to 4) where each grid has 7 segments. There are 4 grids used for the digits, where the segments are turned on or off to represent a specific number. For example, the number 8 has all segments on and the number 1 has only the 2 segments on (the ones on the right). The display assembly then uses the remaining grid to control the various icons (the LEDs) by mapping one segment to each of these icons. In your device tree `tm16xx,digits = [01 02 03 04];` maps the digits to grid indexes 1, 2, 3, 4 and LEDs also uses the grid index 2 for the LEDs: ``` led@2,[SEGMENT] { reg = <2 [SEGMENT]>; /* ... */ }; ``` I would start by commenting out the LEDs configuration in the device tree and then confirming which grid indexes are used for the digits by following Test alternative digits ordering. For example, you could try grid indexes "0 1 2 3" and check if it still starts from the 2nd digit. Once the correct grid indexes for the digits are found, you can update the `tm16xx,digits` accordingly, uncomment the LEDs configuration and change the LED grid index to the one that is not used in the digits. For example, if using digit indexes "0 1 2 3", the led grid index should be 4. Or if digits indexes are "1 2 3 4", led grid index should be 0. Edit: Looking at fd650 controller datasheet, it supports only 4 grids, so they will be indexed from 0 to 3. There is no need to test digit indexes over 3. It would also mean that your display has no LED icons as all grids are used for the digits. You can then completely remove the LEDs definition in the device tree. If your display has icons, its likely that you need to configure a different controller by changing the compatible string in the device tree. Both "fdhisi,fd655" and "fdhisi,fd6551" are pretty similar to fd650 but supports a 5th grid (so grid indexes goes from 0 to 4). The main difference between fd655 and fd6551 is the number of brightness levels supported (3 for fd655 and 8 for fd6551).

@L Jumadi can you share your DTS config for the display controller and LEDs?

@L Jumadi that is great news! It means driver has initialized the display device properly. Displaying 8888 is expected when device gets probed. It's the display service that will then set the time and LEDs on the display from user space. But before you start the service, you can check that segment and digit mappings are well configured by running `display-utils -c`. Please read Check your display configuration of README.md to know how to check and adjust these mappings. Once mappings are good, you can start the service by using `systemctl start display`.

@L Jumadi It looks like you should reverse the pin configuration of the data and clock pins Your openvfd config: ``` openvfd_gpio_clk = <&pio 8 11 0>; // this is the clock ping openvfd_gpio_dat = <&pio 8 12 0>; // this is the data pin ``` Should become: ``` sda-gpios = <&pio 8 12 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; // this is the data pin scl-gpios = <&pio 8 11 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; // this is the clock pin ``` You can also try setting gpio flags to 0 such as in your openvfd config. It would become: ``` sda-gpios = <&pio 8 12 0>; // this is the data pin scl-gpios = <&pio 8 11 0>; // this is the clock pin ``` Edit: I have added a check in tm16xx.c to report "Failed to initialize display" instead of "Display initialized successfully" when it fails to set brightness or to write display data. This won't fix your issue per se but at least it will add clarity when looking at dmesg.

@L Jumadi there are 2 components: the module in kernel space and the service in user space. You don't need to use make module / module-install / service-install because the command `make install` documented in README.md will do these 3 commands for you. Now, if it's trying to install the module in `/lib/module/6.7.12/build` instead of `/lib/module/6.7.12-edge-sunxi64/build`, that's probably because you ran some make command in the `/lib/module/6.7.12-edge-sunxi64/build` directory which caused the kernel configuration to be updated. Unless you are familiar with building kernel, you should stay away from the `/lib/module/6.7.12-edge-sunxi64/` directory. You just build the module from another directory (such as /home/user/tm16xx). To revert to your kernel configuration (so installing out of tree modules won't use `/lib/module/6.7.12`, you can remove your Linux header package and reinstall it. Whatsoever, we can focus on the next steps since you have been able to build and probe the module. Before checking the service, you need to get sure the the drivers initialize the device properly. You can have a look at kernel messages after loading the module, like this: ``` rmmod tm16xx # clear previous kernel logs dmesg -c > /dev/null modprobe tm16xx # you should see all LEDs ON # check probe logs dmesg ```

@jock Thank you! It's always nice to know that your work is appreciated. Thanks also for the pull request. Since I can't test all configuration combinations myself, the idea was to contribute this driver to mainline Linux once there are sufficient reports of it working properly. Your pull request makes this one step closer @L Jumadi I am less familiar with Allwinner SoCs and it gpio driver. After looking at sun50i-h6-tanix.dtsi (line 34) and sun50i-h6.dtsi (line 352) it looks like its using a multi cell pin controller. This is not about supporting the same chip_name config as OpenVFD but rather configuring the device tree properly. I've updated https://github.com/jefflessard/tm16xx-display/blob/main/devices/tanix-tx6-allwinner-h6.dtso to use the same pin configuration as in sun50i-h6-tanix.dtsi so you can test it. I think it should works now, if not, then someone with more knowledge of Allwinner than I have would need to figure out the appropriate device tree configuration. I'll then be glad to update the device tree configuration on my GitHub to make it easier for next users.

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

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".

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.

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?

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

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 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.

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?

Hi @haven and everyone I've made a new kernel driver for fd628 and fs6551-like LED controllers. 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. It comes with a service written as a simple bash script. So it's easily customizable without having to write custom C code. Could you please give it a try and report your feedback? If my understanding is correct, the X88 pro 10 uses a fd628 controller. Then DTB should be configured to use spi-gpio as well as the led-controller compatible = "titan,tm1628". https://github.com/jefflessard/tm16xx-display/tree/main Thank you

removed

Thanks @haven for your work on porting openvfd on kernel 6. Your instructions works well on amlogic gxl s905x magicsee n5 tvbox.