Linux 3.0

Geschrieben von MMind am Dienstag, 31. Mai 2011 in Oyo

Nachdem es der Treiber für den USB-Device-Controller in diesem Merge-Window in den Hauptkernel geschafft hat, habe ich heute mal das update des Oyo-Kernels in Angriff genommen. Der Kernel basiert jetzt also auf Linux 3.0rc1

Abgesehen von der gewöhnungsbedürftigen neuen Nummerierung ging das Update eigentlich relativ problemlos vonstatten. Hier zahlte sich auch der Einsatz von topgit aus. Nacheinem einfachen tg update war der Unterbau meiner Topic-Branches und damit auch gleich die späteren Upstream-Patches aktualisiert.

Ein paar kleine Fehler haben sich anscheinend bei einem groß angelegten Update des Power-Managements eingeschlichen. Diese muss ich jetzt also noch bereinigen und wieder in Richtung der Kernel-Entwickler schieben.

Auch der zweite HSMMC-Kanal hat scheinbar einen Schnupfen entwickelt und wirft Unmengen irgendwelcher IRQ-Meldungen. Ich hab ihn jetzt einfach erstmal deaktiviert, da beim Oyo die SD-Karte eh am ersten Kanal hängt. Bis ich so einen Asus DR-900 besitze, sollte ich das Problem aber schon noch finden, da dort die MMC-Kanäle vertauscht sind.

0 Kommentare Mehr...

Communicating with the AUO-K1900

Geschrieben von MMind am Dienstag, 17. Mai 2011 in Oyo

Sorry, wieder in Englisch — aber die Zielgruppe des Artikels ist im deutschsprachigen Raum eher klein :-)

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: EPD access scheme 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.

0 Kommentare Mehr...

Documenting the K1900 interface

Geschrieben von MMind am Sonntag, 15. Mai 2011 in Oyo

This time in english to keep as reference for whoever may need it.

As written last time, the K1900 uses the I80 interface of the S3C2416. This interface is also present on the following SoCs [S3C64xx, S5Psomething] in an improved version where the S3C2416 only has the so called "manual command mode".

The connection between the I80-pins of the S3C and the K1900 are as follows:

PINS3C (SIFCCON0)K1900
Command mode enableSCOMEN----
Chip-SelectnCS0CSEL
Register/State switch (where to write to)SYS_RSDC
Write enablenWEHWE
Read enablenOEHRD
DataSIFCCON1/2 [17:0]DBUS[15:0]

Settings are made in the SYSIFCON / I80IFCON register. The data exchange is then handled via the SIFCCON[0,1,2] registers. SIFCCON0 controls the connection, SIFCCON1 contains the data to send to the K1900 and SIFCCON2 contains the data received from the K1900. Data is transmitted through setting the SIFCCON0 bits in the right sequence and combination:

RSnOEnWEFunction
001Write command to register
010(read register - not used)
101Write data (params)
110Read data (return values)

Sending a command to the K1900 therefore follows along this path:

  • command mode enable
  • nCS0 enable
  • send command
    • RS low
    • nWE enable
    • write command to SIFCCON1
    • nWE disable
    • RS high
  • optionally send parameters
    • nWE enabled
    • write value to SIFCCON1
    • nWE disabled
    repeat for each param
  • optionally read returned values
    • nRD enabled
    • read value from SIFCCON2
    • nRD disabled
    repeat for each value
  • nCS0 disable
  • command mode disable
0 Kommentare Mehr...

kleine Tintenkleckse

Geschrieben von MMind am Sonntag, 15. Mai 2011 in Oyo

In den letzten Tagen habe ich begonnen, mich etwas mit dem Display-Controller der Reader zu beschäftigen.

Der AUO-K1900 ist ein sogenannter FPGA (Field-programmable-Gate-Array), der von SiliconBlue hergestellt wird. FPGAs sind im Prinzip eine Sammlung von Schaltungselementen, deren Funktion erst später durch eine Konfiguration festgelegt wird und auch später noch änderbar ist.

Ist-Zustand

Wie alle anderen Teile des Original-Kernelcodes, sieht auch der Displaycode wüst aus. Im Prinzip wurde nichts anderes getan, als den Framebuffer-Treiber für den S3C2416 zu kopieren und das Display-Interface hinein zu hacken. Herausgekommen sind dabei stolze 242KB Quelltext.

Der erste Schritt war also, den ganzen Mist, der eh nie wieder benötigt wird, raus zu werfen. Danach habe ich versucht die ganzen ähnlichen Codeblöcke zusammenzufassen — also so in Funktionen auszulagern, dass das Funktionsprinzip besser erkennbar wird.

So ist die schiere Masse an Code schon mal auf 120KB zusammengeschrumpft und es lässt sich überblicken, was dort eigentlich passiert.

Das Interface

Das Interface zwischen Host-Framebuffer und dem K1900 wird meist »Intel 8080-like I80 interface« genannt. Allgemeinere Dokumentation dafür zu finden ist scheinbar fast unmöglich und es scheint im Umfeld des Linux-Kernels bis jetzt auch noch nicht verwendet worden zu sein. Es ist vom Aufbau aber auch nicht so dramatisch, denn es werden einfach nacheinander ein Kommando und gegebenenfalls ein paar Parameter übertragen.

Interessanter wird schon werden, dem aktuellen s3c-fb beizubringen bei Änderungen des Framebuffers, diese automatisch an den K1900 zu übermitteln. Im Originalcode wurde dieses Update ja von der Anwendungssoftware ausgelöst.

Und an die notwendige Konvertierung der RBG-Farben in Graystufen möchte ich noch gar nicht denken :-)

0 Kommentare Mehr...

Seite 1 von 1, insgesamt 4 Einträge

Suche

Nach Einträgen suchen in Outside the Walled Garden:

Das Gesuchte nicht gefunden? Gib einen Kommentar in einem Eintrag ab oder nimm per E-Mail Kontakt auf!