linux-kernel - Re: i80 (Intel 8080-like) command interface to LCDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <201105171825.43506.heiko@sntech.de>
Date:	Tue, 17 May 2011 18:25:42 +0200
From:	Heiko Stübner <heiko@...ech.de>
To:	linux-kernel@...r.kernel.org
Cc:	linux-fbdev@...r.kernel.org, linux-i2c@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net
Subject: Re: i80 (Intel 8080-like) command interface to LCDs - how to implement

Am Dienstag 17 Mai 2011, 13:59:40 schrieb Heiko Stübner:
> I'm trying to find the best way on implementing an i80 interface
> (especially the command mode) between a s3c2416 and an AUO-K1900 (epaper
> controller).
> 
> On the host side it is usable at least in all Samsung SoCs following the
> S3C2443 and on the device side I've found, apart from the K1900, for
> example the ili9320 and STM32F10xxx displays controllers using this
> interface.
> 
> It looks a bit like a cross between SPI and I2C but fits neither category -
> at least for my understanding.
after some more thoughts while cycling home, would it be sane to implement it 
as spi devices like:

lcd-ctrl <->i80_device (spi_device) <->spi-layer <-> i80_spi_master

i80_device would implement the message logic as described below
i80_spi_master would control the registers 

the write-enable/read-enable bit settings can be determined by the direction 
of the transfer, but how do I determine the value to set for RS?

The idea I had was to set bits_per_word to n+1, i.e. the register has 18 data 
bits and I would use the 19th bit do transmit the required RS setting.

Does this look at least halfway plausible?

Thanks
Heiko

[rest of this mail included as I have just added spi-devel to the recipients]
> pins/pins consist of:
> CS ... chip-select
> RS ... control or data register select
> WE ... write enable
> RE ... read enable
> D0-Dn ... data 0-n for variing values of n
> (I've seen up to 18 data bits)
> 
> 
> commands can look like:
> (* set command mode)
> * set chip-select
> 
> * set RS to control (mostly low)
> * set WE to high
> * write command to D
> * unset WE
> * set RS to data
> 
> * set WE
> * write data to D
> * unset WE
> * set WE
> * write data to D
> * unset WE
> ...
> * set RE
> * read data from D
> * unset RE
> ...
> * unset chip-select
> (* unset command mode)
> 
> the fourth possible state (read-control) is also used by the ili9320.
> 
> looks a lot like an i2c-transfer, i.e. something like
> {
>   { WC, 6001 }, //for write-control
>   { WD, 576 }, //for write-data
>   { WD, 12 }, //for write-data
>   { RD, *buf } //for read-data
> }
> could represent the above command-sequence.
> 
> 
> So, is this a new bus type or does it fit somehow into spi or i2c or some
> other bus-type I don't know yet? Or, does code for i80 exist somewhere I
> haven't looked yet?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/