Wowbagger

Best source of documentation IMHO is from the armbian source. These references should provide the needed description to make a usable device tree. They are mirrored here: SPI Controller Generic Binding This binding is for display panels using an Ilitek ILI9341 controller in SPImode. Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046SPI driven touch screen controllers. The other tidbit of info is the structure of a gpio cell property. AFAIK the numeric values for <&pio 0 2 1> refers to pin group 0 = A, pin offset 2 (A2), and pull-up flag. Also, it is required to configure and activate the device trees. Configuration, like param_spidev_spi_bus=0, is still a mystery to me. armbian-config doesn't automatically add these items to /boot/armbianEnv.txt so this can be a major source of frustration. My example /boot/armbianEnv.txt: verbosity=7 dtdebug=7 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun50i-h5 overlays=spi-spidev param_spidev_spi_bus=0 user_overlays=sun50i-h5-ili9341 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u rootdev=UUID=8d9edae5-2ab9-4c42-933e-ee4235da815f rootfstype=ext4 I created sun50i-h5-ili9341 using the referenced documentation as a guide.

Attempting to connect ILI9341 LCD with XPT2046 Touch to NanoPi NEO Core2 and then migrate to NanoPi Duo2. The ILI9341 / XPT2046 peripheral board has shared SPI with a separate slave chip select for the screen and touch controllers. Starting with hardware datasheet for the H3 I see there is lots of support for different chip select implementations. This makes me think I am on good footing from a hardware perspective. What is not clear to me is how the register support for four slave chip selects translates into pin assignments. Reading through spi-sun6i.c., for example, static int sun6i_spi_transfer_one( ... ) uses SUN6I_TFR_CTL_CS_MANUAL which implies software control but I don't understand where the software control is actually done. I'm sure devtree helps configure the drivers but I'm a bit lost wrt hardware support of four slave devices. I suspect that SPI1 Slave 0 is the default mapping assigned to pin 23. Can the hardware default be changed with hardware support or is this always controlled through driver software? Any pointers would help. WoW

Driver looks for property called "backlight" NOTE: gpio_backlight uses brightness as power state during probe ./drivers/video/backlight/backlight.c _of_find_backlight(dev) ... of_parse_phandle( dev->of_node, "backlight", 0)

I don't understand "The screen still doesn’t light up after the device is turned off. " My screen is on order and I hope to have it work with Duo2 and am looking at the spi drivers and the ili9341 code. Hopefully you get it to work so I can follow your example. See /build/cache/sources/linux-mainline/orange-pi-5.9/drivers/gpu/drm/tiny/ili9341.c to see if any DT items you may have missed or not configured correctly. If you download the source take a look at ili9341_probe( struct spi_device *spi) ... devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ... devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW); ... devm_of_find_backlight(dev); ... device_property_read_u32(dev, "rotation", &rotation); ... mipi_dbi_dev_init(spi, dbi, dc); This is what the probe does. Your DT seems to have the right elements. Maybe try stripping your wiring down to the absolute minimum needed?

Managed to find the following statements from a blog called "Stupid Projects". LOL. I am mostly interested in Allwinner SoCs so I guess this tells me what I need to know. TL;DR Hardware assisted image signal processing involves Codec support, SoC Support, and finally Application Support. Hobby projects that involve transcoding are likely to sink a lot of time. Reports on the advancement of the development of Sunxi-Cedrus. Allwinner VPU support in mainline Linux November status update. More OpenGL binaries for the Mali support on Allwinner platforms with mainline Linux. Adding armbian supported boards to meta-sunxi Yocto (updated).

Working on an embedded SBC home automation application with a very small form factor. Size and reliability is at a premium. Just want to have a smart device at the door that will help notify and find me when someone presses the doorbell button, or detects motion at the entrance or curbside mailbox. Two way audio and outbound alerts are progressing nicely but complexity increases significantly when integrating video into the solution. For example, two widely used video trans-coding applications, ffmpeg and gstreamer, may or may not have hardware assisted image signal processing on the SBC. Is any form of image signal processing within scope when a board is supported by Armbian? How is hardware assisted image signal processing qualified within Armbian? I'm trying to set my expectations. BTW. I had the opportunity to follow the Armbian cross-compile recipe and build environment last weekend. I was blown away with how seamless and truly useful the Armbian suite made the entire effort. Thank you to the entire team.