Support HD44780 attached to a TS7800 SBC's LCD header

[czo]

Hi Everyone,

I had to recomissione one of my ancient SBC's, which is a TS-7800 (https://www.embeddedts.com/products/TS-7800). Because it has an LCD header for a HD44780 compatible display (and i also had a display for it), i had to wrote a small driver which is basad on thier's sample tolcd.c (https://files.embeddedts.com/ftp/ts-arm-sbc/ts-7800-linux/samples/).

This driver is working fine on my TS7800, which is currently running Debian 11.3.

[haraldg]

Hi, thanks for your interest in LCDproc.

If I understand your code correctly, it seems the LCD header of your device is actually a GPIO port behind some bus? Couldn't you use one of the gpio HD44780 drivers? It is generally frowned upon to directly access hardware from LCDd. If your device has no GPIO support in linux yet, adding this might be a more worthwhile project then a custom LCDd driver.

Also your code would need proper documentation (man page, default config, user guide).

Also you should mention the tolcd.c in your copyright notice. However it seems tolcd.c doesn't have a license, so not sure if we can include it at all.

[czo]

Yes, its a kind of GPIO, but GPIO's on this SBC's are memory mapped by a CPLD (btw this board has almost hunderd GPIO of it). So, pins of the LCD header (like any other headers there), can be controlled by manipulationg memory at specific address (for the LCD header, this address is 0xE8000000). This driver works with the newer, TS7800-V2 too, which is a completley different SBC, but the vendor try to keep up software and hardware compatible as they can. And, i think, it will work with other type of Technologic Systems boards too, where the memory address is the same, but i don't have more to test it. Maybe, i need to find a better name, becuse of the number of the compatible Technologic Systems boards.

Btw, this LCD header on thier SBC's are designed for thier "LCD-LED" module (which is made by the same company). I don't know if any other LCD module will working or not on this header.

I have only the TS7800, which is an ancient, ARMv5 based board, creating a GPIO driver for a Linux kernel, is a complete time waste, because the age of the architecture, and noone knows when it will be dropped. Thier newer boards (like the TS7800-V2) has generic in-kernel GPIO support which is coexists with this memory mapped thing too, so this code still work with it.

If this driver is a complete dead end, i will accept it, but if it's will be OK, i can write some documentation and configuration example too.

About the licensing of tolcd.c, i had to sent a mail to get some statement about it, i am waiting for the answer.

[haraldg]

I believe many GPIO controllers are memory mapped. This is pretty standard. Also if your code works with TS7800-V2 too then I'd expect that the linux GPIO driver for the new system works on the old system too or at least would be easy to make compatible. And in my experience linux is much more capable of supporting ancient hardware without breaking other things. While in contrast we have a build system that nobody still around really understands and whenever we add something special (like code, that shouldn't be compiled on all platforms) we get issues like it doesn't work on cross compiling this or c compiler that.

Also I'm not sure what "generic in-kernel GPIO support which is coexists with this memory mapped thing" would mean. Usually having kernel and user space controlling the same memory region is exactly what people are avoiding. There even are kernel configuration options, that mark such memory regions as read-only. So AFAICS it would depend on the linux distribution / kernel config whether your driver would work at all. (I think for example on OpenWRT with their default kernel your code would not work.)

So I'm really torn on your code. On one hand, policy so far was to include anything that,

• somebody is willing to maintain
• somebody is willing to use
• can be used on HW that can be bought new and would otherwise be unsupported
• is legally distribute-able and otherwise inoffensive.

On the other hand, this really is a GPIO driver rather then a display driver and adds to a growing mess. There has been some discussion a few years ago about separating pin drivers and display drivers by some HAL. Your code might fit in nicely with such a system, but never anything came from the discussion.

I can see several ways forward for your code:

1. We do our best to keep a stable API and even ABI for drivers to support out of tree drivers. You might just publish your code on your own without any fuss about legal compatibility and whatever from our side.
2. You could convince somebody (not necessarily me) that enough people are going to use this, that it is worth the trouble.
3. You could compare your code with the existing linux GPIO code and create a GPIO driver for your board. That shouldn't be more work than sorting out documentation, build system etc for lcdproc and would have a much higher benefit.
4. You could look into the HAL thing, but it would be a lot of work and I don't recommend it.

Obviously I believe, that (3) would be the best use of your time.