Jean-Francois Lessard

That should make it. You can always try to see if it works and search online if not.

Your commands looks ok, but you need to use hk1-x3, not hk1-box Your runtime device-tree do contains the display-controller under /proc/device-tree/i2c-display. So your correctly copying your dtb, but device-tree/i2c-display/sda-gpios and device-tree/i2c-display/scl-gpios shows pin of hk1-box, not hk1-x3. You also need to remove any references to OpenVFD from your device tree. This will create conflicts if you have multiple nodes using the same pins. Your dmesg also has some messages about the i2c bus on which is connected your display controller: [ 3.787786] gpio-576 (sda): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 3.792897] gpio-577 (scl): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 3.802509] i2c-gpio i2c-display: using lines 576 (SDA) and 577 (SCL) If course, you need to first configure the right pins by using hk1-x3 (and removing openvfd). Then you can investigate remaining i2c issues, if any.

You have checked that neither

@KrzyPacu your Android DTS confirms the pinout of hk1-x3 fd628_dev { compatible = "amlogic,fd628_dev"; fd628_gpio_clk = <0x12 0x41 0x00>; fd628_gpio_dat = <0x12 0x40 0x00>; status = "okay"; }; 0x40 is data pin 64 0x41 is clock pin 65 So there must be something wrong with how you are copying the dtb to boot. Maybe to the wrong location. Ensure you have the proper dtb loaded at runtime by inspecting /proc/device-tree

@KrzyPacu try with hk1-box.dtso instead: make hk1-box.dtb cp release/hk1-box.dtb /boot/dtb/{YOUR_DTB_PATH}.dtb reboot hk1-box.dtso has the same configuration as hk1-x3.dtso but with pins 63/64 instead 64/65. Original OpenVFD specify "Vontar X3" in hk1-box, not hk1-x3. If that still doesn't work, you need to start from a known working configuration, either OpenVFD or original Android firmware dtb. Then you can work backwards to understand your configuration and create the proper dtso.

@KrzyPacu Can you look at your full dmesg output (no filter on tm16xx)? I guess there are some other error messages prior to there filtered output. I don't think that you have a different controller. Maybe rather the pinout: which pins of the SoC of your TV box are wired to the controller and how they are declared in the device tree. Was your display working properly with the OpenVFD driver and the hk1-x3.conf VFD configuration file you posted? If so, the controller is good and it's probably the pin numbers described in the device tree that needs to be adjusted. My hk1-x3.dtso was converted from the OpenVFD configuration file, but the device hasn't been tested yet to my knowledge. So it might need some corrections.

No need to disassemble anything. Given your device has the same configuration as hk1-x3, you should rather use the corresponding device tree definition: make hk1-x3.dtb cp release/hk1-x3.dtb /boot/dtb/{YOUR_DTB_PATH}.dtb reboot

What is your Android TV device model? What is the led controller model? Then what is your DTS configuration for the display client?

There should have been an exception on first load that now prevent removing the module. You can force removal of the module but that can create unstable kernel side effects. You are better to reboot the device (you may need to unplug power if kernel refuses to reboot). Then after boot, check dmesg kernel messages (do not clear them first!) something like dmesg | grep tm16xx

Have you looked for dmesg output about tm16xx after probing the driver? dmesg -c # clear kernel messages modprobe -r tm16xx # unload driver modprobe tm16xx # load driver dmesg # check for new kernel messages

Looking back at your previous output, I've just noticed something wrong. I've should have seen it first instead of pointing you to kernel headers issue. Here M should be pointing to your path to the tm16xx-display folder. I think the PWD environment variable is affected by sudo. You can specify the PWD variable explicitly when calling make: sudo make PWD=$(pwd) module-install That should make it.

@KrzyPacu it seems there is an issue with your kernel source code (or minimal headers). Ensure to install kernel headers for your distribution/version first If it still doesn't point to your headers/source path, you can pass it as a variable when executing make. Something like: sudo make module-install KDIR=/path/to/your/headers/build

@KrzyPacu Start by copying your original dtb into tm16xx-display folder: cd tm16xx-display cp meson-sm1-x96-air-gbit.dtb original.dtb # or alternatively run: make extract-dtb Then, assuming the corresponding device tree source overlay in the "devices" subfolder is "x96-max-1gbit.dtso", build the updated dtb: make x96-max-1gbit.dtb # <-- same name as the dtso file in devices subfolder but with dtb extension Finally, replace the original dtb of your boot path with the updated one (first keep a copy of your original dtb somewhere else, just in case) and reboot: cp release/x96-max-1gbit.dtb /boot/dtb/{YOUR_DTB_PATH}.dtb reboot

Hi @KrzyPacu I can only provide basic instructions without any support regarding loading overlays. It's not supported on every device (and I personally don't own a device which supports this). You can always search for other posts on device tree overlay for your device if you absolutely want to use overlays. Though, you can easily embed the device tree overlay into your dtb instead. This is what I do personally. You can check instructions of Option 2: Create an updated dtb at : https://github.com/jefflessard/tm16xx-display/blob/main/README.md#configure-the-device-tree

Hi @Mark Waples, first thanks for your detailed question completeness. It helps so much to understand your context! You need to define the other led entries in your device tree, so the tm16xx driver will know about them and it will create a corresponding sysfs led interface (i.e /sys/class/leds/display::lan/ path and alikes). Once the sysfs interface will be created, the LEDs will be controllable from user space, such as display-service does. Since the AIP650E0 controller is most likely tm1650 or fd650 compatible, it can drive a maximum of 4 grids and my guess is that it uses the 8th segment (index 7) of each grid for the LEDs (segments 0 to 6 being used for clock digits - which you reported to work). There should be no additional grid index involved since probing the module turns on all these LEDs. Try something like: ``` led@0,7 { reg = <0 7>; function = "lan"; } led@1,7 { reg = <1 7>; function = "wlan"; } led@2,7 { reg = <2 7>; function = "colon"; } led@3,7 { reg = < 3 7>; function = "usb"; } ``` First try this led device tree nodes to check if you can control these LEDs from sysfs. Then, you may need to change the grid indexes of these led entries to match your actual icons order. If required, "display-utils -c" may be used at that point to check that led name matches the icon (ex: LAN icon is ON while "LAN" text is shown on the digits). Then you should be good to go! Please report success or failure. Thank you.

@SpellKilleR you should see "Operating in transposed mode" in dmesg, if not it's either that the flag is not correctly set or you are running an older version of the code For the flag, it should be in the display controller node such as in this example: https://github.com/jefflessard/tm16xx-display/blob/ecacbdcf7963c7480bf69d1afe0c5c57bff57d46/devices/x96-max.dtso#L26 To get the latest code version either clone or pull https://github.com/jefflessard/tm16xx-display.git

@SpellKilleR it looks like you may need the transposed flag: https://github.com/jefflessard/tm16xx-display/issues/4

I should have specified that it's how to configure kernel command line parameters with the amlogic devices I own. The boot process is slightly different for these devices. I'm glad you found a way to make it work with your device anyway. With amlogic, there is also a '/boot/armbianEnv.txt' file that can be edited but it doesn't pickup command line arguments from there (as opposed to other Armbian versions). Don't you have such a file with your Armbian version? It may be an acceptable solution to edit the file after installation.

@paradigman it looks like an issue with your kernel build system, not the display driver. The kernel build system is either packaged with the kernel source code or the kernel headers of your very specific kernel version. Since the compiled module is once again specific to your kernel version, sharing compiled objects won't be of any help. Try to fix your kernel build system first.

@dfahren you can pull latest version from https://github.com/jefflessard/tm16xx-display (this is commit 47df76a). It now has the "default_value" parameter. You can test directly by setting the parameter value at modprobe. To have it automatically configured at boot time there are 2 options: 1. Using Linux kernel boot arguments by adding the parameter to /boot/extlinux/extlinux.conf. Something like adding "tm16xx.default_value=boot" to your "append" directive. 2. By configuring modprobe.d options of /etc/modprobe.d/tm16xx.conf with the following line: options tm16xx default_value="boot" Please test and reports your results.

Turning on all the LEDs (all 8s) should not be considered as user space content but rather a diagnostic mechanism to ensure the device is working properly (which do respect separation of concerns). Now, I do understand that you want to display some content as soon as possible and that relaying on user space mechanism would happen to late in the process, especially if you are targeting "in tree" kernel module. The appropriate approach would then be to have a kernel module parameter that would accept the default value to display. This default value could be configured using either kernel boot command line arguments or modprobe configuration file to "boot" or whatever the user prefers. Then, when the kernel module probes the device, it would initialize it it's value to default value instead of turning on all LEDs. I'll implement this when I will have some free time.

@jock perfectly explained my point! Thank you. I would add that the idea of open source is to allow collaboration among developers. So it's perfectly fine if you @dfahren want to change the code. Let's say you add a kernel module parameter that can be configured in the Linux kernel boot parameters to display some specific content, I would then be inclined to merge your pull request. Now, if you would prefer to have the content embedded in the code, I would rather suggest you to keep your code in a fork as it doesn't follow the separation of concerns.

@dfahren you can configure modprobe like the above to display "boot" without modifying the source code. You could even replace "echo boot" with "display-utils -t whatever" to scroll any text you would like. I really think this is a much better way to do so. It prevents having the driver module to manage content instead of the device. The idea of turning on all led at module probe is to ease diagnostic of module configuration, much like a car console that will turn on all subsystems LEDs when turning the ignition key. Personally, I don't understand why so many people want to display "boot" but it's up to you to customize the display the way you want.

@dfahren thanks for your feedback. I'll try to answer your questions but they are rather broad and not strictly related to the driver itself. Plus, it's difficult to have a clear understanding without knowing your DTS configuration. 1. The display device is usable as soon as the tm16xx device driver is loaded by the kernel during boot (which will turn on all display LEDs at this stage, showing 88:88). There is no way to load the driver before that. Some other LEDs might be hardware controlled or configured by u-boot preloader, before the kernel is loaded, so you can't compare against these. Currently display.service loads the driver using ExecStartPre at basic.target, which is somewhat the earliest it can using systemd. There might be other ways to load the driver a couple of milliseconds before but I don't think it worths investigating. Anyway, the display-service won't show the correct local time before network and ntp will have loaded properly (local time is only available from user space, not within kernel space). 2. Display brightness is set by using controller specific values, there is no amps to control. You can try setting different `/sys/class/leds/display/brightness` values to see if there's a bug (0 is off and `cat /sys/class/leds/display/max_brightness` being the max value for your configured controller). If brightness is not behaving as expected, it is likely that you have not configured the right controller in your `compatible` string of the display-controller node in your DTS. You can check the controller model by looking at the controller chip on your device main board. 3. The display would not work with incorrect I2C SDA and SDL pins configuration. I guess that your i2c-6 is another unrelated device in your DTS. You can check which i2c device is used by your display controller using `ls -l /sys/class/leds/display/device` 4. "link" sysfs is not to control a led status but rather to configure some specific led trigger. You need to check specific led trigger module documentation to understand how to use these sysfs attributes. If you want to turn on or off a led without using a led trigger, you can do so: ``` # turn on a specific led/symbol echo 1 > /sys/class/leds/display\:\:lan/brightness # turn off a specific led/symbol echo 0 > /sys/class/leds/display\:\:lan/brightness ``` Please refer to https://github.com/jefflessard/tm16xx-display/blob/main/README.md for tm16xx specific documentation. 5. Use `display-utils -a` as documented in tm16xx documentation at https://github.com/jefflessard/tm16xx-display/blob/main/README.md then you can update your DTS. 6. If using software i2c (i2c-gpio) you should not require pinctrl. If using hardware i2c, it depends on the specific hardware configuration of your device.

@L Jumadi following your finding on softdep, I've removed the /etc/modprobe.d/tm16xx.conf creation from the service-install and rather modprobe the dependent modules in the display.service as pre exec commands. I think this may be a cleaner solution since there is no real dependencies between the tm16xx module and the ledtrig modules, it's really about the display service which relies on them. Now, your idea of customizing the tm16xx module install to display boot is interesting! It ensure it's executed as soon as the module is loaded instead of waiting for the service to be loaded. On my side, I ended up with: cat /etc/modprobe.d/tm16xx.conf install tm16xx /sbin/modprobe --ignore-install tm16xx && \ /bin/echo boot > /sys/class/leds/display/value I won't include this in the code base, since I prefer that full led on to be default for diagnosis purposes. But it's a nice customization worth to be noted.