Outside the Walled Garden

Last time I described the raw interface between the host and the K1900. Today I want to describe how this interface is used when talking to the K1900.

The i80 interface supports two modes of operation — command mode and a mode for display data.

The command mode is used as the name implies to send commands to the controller. These contain for example init, refresh and reset commands. The display mode is used to send frame data from the framebuffer to the controller.

Missing an i80 bus driver

The i80 bus seems to be some sort of cross of I2C and SPI. The addressing of the target device is done via chip-selects like in SPI but the communication seems to be more similar to I2C.

Messages to send over i80 could be described like the following struct:

{
  { WC, 6001 }, //write-control
  { WD, 576 }, //write-data
  { WD, 12 }, //write-data
  { RD, buf } // read-data
}

This should access register 6001, write 576, write 12 and get a return value put into buf.

As the headline implies the Linux kernel is currently missing support for i80. Therefore it seems an i80 bus-driver made it onto my todo-list too.

Concurrency issues

The two modes of access also create concurrency problems, show in the following diagram: A semaphor or similar structure is needed to prevent one driver from getting to the i80 bus while it is occupied by the other driver.

Real-life example

To illustrate how this all comes together I will describe what happens when a part of the display should be refreshed from the framebuffer.

The following command starts the display update and describes to the display which region should be updated:

{
  { WC,  PRE_DISP_START }, //write-control
  { WD, x }, //write-data
  { WD, y }, //write-data
  { WD, width }, //write-data
  { WD, height }, //write-data
}

The followin part is specific to the S3C SoC and may look different on other SoCs. The region to send has to be marked. On the S3C2416 the specific region is copied to a memory region and the VIDWW00ADD* registers are used to declare its position and size to the i80 part of the framebuffer.

Now the ENVID/ENVID_F bits of VIDCON0 are set to binary-11. This enables the lcd logic and the frame-data is sent via the i80 bus to the K1900. After this single frame the lcd logic is deactivated again. And another command is sent to the K1900 which marks the end of the data transmission.

{
  { WC,  PRE_DISP_STOP }, //write-control
}

After this the K1900 updates the named region with the sent data.

Path of the display data

The grayscale part is strange thing happening in the original framebuffer. It presents a normal color framebuffer to the user-space and converts it internally to gray levels. I'm not sure if this is necessary, or if the framebuffer can also be completly grayscale.

SPI interface

The K1900 also has a SPI interface alongside the i80 one, but it seems to only be used to access the flash storage attached to it. At least it's not documented and also not used in the upstream code we have.