組み込みLinuxでのLCDディスプレイ用のドライバーの作成

この記事では、メーカーNewhavendisplaysの320x240カラーディスプレイ用のLinuxドライバー、つまり組み込みLinux用のNHD-5.7-320240WFB-CTXI-T1を書いた経験を共有したいと思います。 特にロシア語では、framebufer（FB）ドライバーを書くためのリソースがそれほど多くないので、記事を書くという考えはまさに熟しました。 このモジュールは最新のカーネル（2.6.30）向けに作成されたものではないため、それ以降FBインターフェイスで多くのことが変更されたと思われます。 しかし、それでもなお、この記事がLinuxカーネルレベルの開発に興味がある人にとって興味深いものになることを願っています。 実装をよりシンプルかつエレガントにすることができることを除外しません。したがって、コメントや意見を歓迎します。





先史時代

最初は、QT組み込みなどの標準ツールを使用してアクセスできるドライバーを作成し、最終的にユーザーとの対話用のアイコンとテキストを含むシンプルなメニューを作成することでした。 プラットフォームはAT91SAM9G45のスカーフ、より正確にはwww.armdevs.com/IPC-SAM9G45.htmlでした。
ビデオのストリーミングは計画されていませんでした。 AT91SAM9G45には、DMAサポートと非常に高速なバスを備えた完全に機能する組み込みLCDコントローラーが含まれており、ビデオの速度をかなり向上させることができる可能性がありますが、残念ながらSSD1963とハードウェア互換性はありません。 したがって、唯一の代替手段として、この目的のために通常のGPIOインターフェイスを使用することが決定されました。

SSD1963コントローラインターフェイス

コントローラーのインターフェイスは、表示データシートの図の形式で表示するのが最も簡単です。



ドライバー開発者の観点から、DB0-DB7ピンに関心があります。 これは8ビットのデータバスであり、SSD1963にデータを転送するプロセスを制御するために使用されるDC、RD、WR、CS、RESピンです。
送信されたデータのフォーマットに関しては、このディスプレイは888のフォーマットを使用します。それはどういう意味ですか：8バイト-赤、8バイト-緑、8バイト-青。 このタイプのディスプレイでは、オプション555、565などを見つけることができますが、そうではありません。 送信されるデータの形式は図に示されています。



データの最初のバイトをバスに設定する前に、CSピンとWRピンを1から0に切り替える必要があります。また、データバイトを設定した後、CSとWRを0から1に切り替える必要があります。 SSD1963コントローラへのデータ。 信号のより詳細な波形は、コントローラーのデータシートで確認できます。 www.newhavendisplay.com/app_notes/SSD1963.pdf

ソースコードでは、GPIOピンの配列とのインターフェイスについて説明します。

static unsigned int nhd_data_pin_config[] = { AT91_PIN_PE13, AT91_PIN_PE14, AT91_PIN_PE17, AT91_PIN_PE18, AT91_PIN_PE19, AT91_PIN_PE20, AT91_PIN_PE21, AT91_PIN_PE22 }; static unsigned int nhd_gpio_pin_config[] = { AT91_PIN_PE0, // RESET AT91_PIN_PE2, // DC AT91_PIN_PE5, // CLK AT91_PIN_PE6, // RD AT91_PIN_PE1 // WR }; 

このインターフェイスのバイト転送機能は次のとおりです。

 static void nhd_write_data(int command, unsigned short value) { int i; at91_set_gpio_output(AT91_PIN_PE12, 1); //R/D for (i=0; i<ARRAY_SIZE(nhd_data_pin_config); i++) at91_set_gpio_output(nhd_data_pin_config[i], (value>>i)&0x01); if (command) at91_set_gpio_output(AT91_PIN_PE10, 0); //D/C else at91_set_gpio_output(AT91_PIN_PE10, 1); //D/C at91_set_gpio_output(AT91_PIN_PE11, 0); //WR at91_set_gpio_output(AT91_PIN_PE26, 0); //CS at91_set_gpio_output(AT91_PIN_PE26, 1); //CS at91_set_gpio_output(AT91_PIN_PE11, 1); //WR } 

ご覧のとおり、この機能を使用すると、LCDコントローラーにコマンドを送信して（たとえば、ディスプレイを構成する）、ピクセル形式のデータを送信できます。

フレームバッファコアモデル

ご存じのとおり、Linuxカーネルは、charドライバー、blockドライバー、usbドライバーなど、さまざまなタイプのデバイスドライバー用のインターフェイスを提供します。フレームバッファードライバーは、Linuxドライバーモデルの独立したサブシステムでもあります。 FBドライバーを表すために使用される主な構造は、 linux / fb.hの struct fb_info です。 ちなみに、このヘッダーファイルには興味深い定義が含まれているため、Linuxカーネルコードのユーモア愛好家にとっても興味深いものになります。
#define STUPID_ACCELF_TEXT_SHIT 。 名前はそれ自体を物語っていると思います。 しかし、 fb_info構造に戻ります。 fb_var_screeninfoとfb_fix_screeninfoを含む2つの構造に興味があります 。 ディスプレイのパラメーターでそれらを初期化します。

 static struct fb_fix_screeninfo ssd1963_fix __initdata = { .id = "SSD1963", .type = FB_TYPE_PACKED_PIXELS, .visual = FB_VISUAL_TRUECOLOR, .accel = FB_ACCEL_NONE, .line_length = 320 * 4, }; static struct fb_var_screeninfo ssd1963_var __initdata = { .xres = 320, .yres = 240, .xres_virtual = 320, .yres_virtual = 240, .width = 320, .height = 240, .bits_per_pixel = 32, .transp = {24, 8, 0}, .red = {16, 8, 0}, .green = {8, 8, 0}, .blue = {0, 8, 0}, .activate = FB_ACTIVATE_NOW, .vmode = FB_VMODE_NONINTERLACED, }; 

この場合、ピクセルに4バイトが割り当てられます：8-Red、8-Green、8-Blue、8-Transparent
構造フィールドのいくつかについて説明します。

.typeは、メモリ内のピクセルを記述するビットを配置する方法です。 パックされたピクセルとは、そのバイトを意味します（この場合、8888は次々に順番に配置されます）。

.visual-表示色数。 私たちの場合、それはトゥルーカラー-24ビット色深度です

.accel-ハードウェアアクセラレーション

.transp、red、green、blue -8,8,8,8形式を3つのフィールド（ offset、length 、 msb_right）の形式で設定します。

また、カーネルにドライバーを登録するには、デバイスとドライバーの2つのエンティティを記述する必要があります。 ビデオメモリのページ（ struct ss1963_page ）を含むFBデバイス（ struct ssd1963 ）について説明します。

 struct ssd1963_page { unsigned short x; unsigned short y; unsigned long *buffer; unsigned short len; int must_update; }; struct ssd1963 { struct device *dev; struct fb_info *info; unsigned int pages_count; struct ssd1963_page *pages; }; struct platform_driver ssd1963_driver = { .probe = ssd1963_probe, .remove = ssd1963_remove, .driver = { .name = "ssd1963" } }; 

初期化

他のLinuxカーネルモジュールと同様に、いくつかのinit / remove関数について説明します。 initから始めましょう。 通常、フレームバッファードライバーはシステムにplatform_driverとして登録されます 。

 static int __init ssd1963_init(void) { int ret = 0; ret = platform_driver_register(&ssd1963_driver); if (ret) { pr_err("%s: unable to platform_driver_register\n", __func__); } return ret; } module_init(ssd1963_init); 

プラットフォームドライバーは、特定のドライバーのプローブ関数を呼び出し、必要なすべての操作（メモリの割り当て、リソースの予約、構造の初期化など）を実行します。 ssd1963_probe関数の例を次に示します。

 static int __init ssd1963_probe(struct platform_device *dev) { int ret = 0; struct ssd1963 *item; struct fb_info *info; // Allocating memory for ssd1663 device item = kzalloc(sizeof(struct ssd1963), GFP_KERNEL); if (!item) { dev_err(&dev->dev, "%s: unable to kzalloc for ssd1963\n", __func__); ret = -ENOMEM; goto out; } item->dev = &dev->dev; dev_set_drvdata(&dev->dev, item); // Initializing fb_info struct using kernel framebuffer API info = framebuffer_alloc(sizeof(struct ssd1963), &dev->dev); if (!info) { ret = -ENOMEM; dev_err(&dev->dev, "%s: unable to framebuffer_alloc\n", __func__); goto out_item; } item->info = info; //Here info->par pointer is commonly used to store private data // In our case, we can use it to store pointer to ssd1963 device info->par = item; info->dev = &dev->dev; info->fbops = &ssd1963_fbops; info->flags = FBINFO_FLAG_DEFAULT; info->fix = ssd1963_fix; info->var = ssd1963_var; ret = ssd1963_video_alloc(item); if (ret) { dev_err(&dev->dev, "%s: unable to ssd1963_video_alloc\n", __func__); goto out_info; } info->screen_base = (char __iomem *)item->info->fix.smem_start; ret = ssd1963_pages_alloc(item); if (ret < 0) { dev_err(&dev->dev, "%s: unable to ssd1963_pages_init\n", __func__); goto out_video; } info->fbdefio = &ssd1963_defio; fb_deferred_io_init(info); ret = register_framebuffer(info); if (ret < 0) { dev_err(&dev->dev, "%s: unable to register_frambuffer\n", __func__); goto out_pages; } ssd1963_setup(item); ssd1963_update_all(item); return ret; out_pages: ssd1963_pages_free(item); out_video: ssd1963_video_free(item); out_info: framebuffer_release(info); out_item: kfree(item); out: return ret; } 

関数に関するいくつかのコメント。 ここに順番にあります：
-ssd1963デバイスにメモリを割り当てます
-多くのパラメーターを変更する必要がないため、最初にデフォルト値（ framebuffer_alloc ）でメモリを割り当ててfb_info 構造体を初期化し、次にfb_var_screeninfo、fb_fix_screeninfoおよびfb_opsなどのドライバーの特定の値を使用します。
-仮想メモリ内のピクセルの連続バッファにメモリを割り当てます。これは、ユーザー空間プロセスによる記録に使用されます。
-フレームバッファー仮想メモリの各ページに対してssd1963_pageを選択します。 各ssd1963_pageには、共有FBバッファーに関するページバッファーの開始アドレス、xオフセット、yオフセット、およびページバッファー長が含まれます。 この場合、フレームバッファの容量= line_length * height = 320 * 4 * 240 = 307200バイト。 このようなバッファ容量の場合、line_length * height / PAGE_SIZE = 307200/4096 = 75ページが必要です。 FBメモリでどのように配置されるかに注意してください。 このページレイアウトを理解することは、ssd1963_copy関数を少し後で見るときに役立ちます。



-システムにFBを登録し（ register_framebuffer ）、遅延データ更新の手順を初期化します（ fb_deferred_io_init ）。これについては、「フレームバッファーを使用した操作」セクションで説明します。
-ssd1963_setupは、AT91SAM9G45 CPUで必要なGPIOを構成し、LCDコントローラーの初期セットアップを実行します。 神秘的なバイトのセットを16進数で送信する形式の初期構成アルゴリズムは、SSD1963のドキュメントから取得されているため、ここでは機能の一部のみを示します。

  void ssd1963_setup(struct ssd1963 *item) { nhd_init_gpio_regs(); //initializations of pins in nhd_data-gpio_pin_config at91_set_gpio_output(AT91_PIN_PE27, 0); //RESET udelay(5); at91_set_gpio_output(AT91_PIN_PE27, 1); //RESET udelay(100); nhd_write_data(NHD_COMMAND, 0x01); //Software Reset ... nhd_write_to_register(0xe0, 0x03); //LOCK PLL nhd_write_data(NHD_COMMAND, 0xb0); //SET LCD MODE TFT 18Bits nhd_write_data(NHD_DATA, 0x0c); //SET MODE 24 bits & hsync+Vsync+DEN … } 

-ssd1963_update_allは、すべてのページにmust_update = 1フラグを設定し、 schedule_delayed_work（＆item-> info-> deferred_work、fbdefio-> delay）を呼び出して、遅延コンテキストで表示更新メカニズムを開始します。

そのため、initを理解しました。remove関数ははるかに単純で、割り当てられたメモリを解放し、FB構造体をカーネルに返します。

 static int ssd1963_remove(struct platform_device *device) { struct fb_info *info = platform_get_drvdata(device); struct ssd1963 *item = (struct ssd1963 *)info->par; if (info) { unregister_framebuffer(info); ssd1963_pages_free(item); ssd1963_video_free(item); framebuffer_release(info); kfree(item); } return 0; } 

フレームバッファ操作

それでは、 fb_ops構造を検討します 。

 static struct fb_ops ssd1963_fbops = { .owner = THIS_MODULE, .fb_read = fb_sys_read, .fb_write = ssd1963_write, .fb_fillrect = ssd1963_fillrect, .fb_copyarea = ssd1963_copyarea, .fb_imageblit = ssd1963_imageblit, .fb_setcolreg = ssd1963_setcolreg, .fb_blank = ssd1963_blank, }; 

ここですべての構造メソッドを提供するわけではありません。好奇心reader盛な読者は、モジュールのソースコードまたはドライバー/ビデオディレクトリのカーネルコードの他のドライバーでそれらを見つけることができます。 ご想像のとおり、fb_ops構造体は、ドライバーが実行できるアクションを記述しています。 幸いなことに、カーネル開発者は、例えばfb_sys_readのように、 sys_またはfb_sys接尾辞を持つFBを操作するための標準関数を提供することにより、作業を部分的に促進しました 。 fb_ops （ ssd1963_read、ssd1963_writeなど）の関数の実装に機能を追加するだけで、必要に応じて即席ビデオメモリのデータを更新できます。

たとえば、 ssd1963_fillrect関数は次のようになります。

 static void ssd1963_fillrect(struct fb_info *p, const struct fb_fillrect *rect) { sys_fillrect(p, rect); ssd1963_touch(p, rect->dx, rect->dy, rect->width, rect->height); } 

明らかに、 fb_fillrectシステムコールは画面の特定の長方形領域のビデオデータを更新するため、 must_updateフラグでマークし、ビデオメモリ更新プロシージャを手動で呼び出して、更新する必要があるページを指定する必要があります。

 static void ssd1963_touch(struct fb_info *info, int x, int y, int w, int h) { struct fb_deferred_io *fbdefio = info->fbdefio; struct ssd1963 *item = (struct ssd1963 *)info->par; int i, ystart, yend; if (fbdefio) { //Touch the pages, so the deferred io will update them. for (i=0; i<item->pages_count; i++) { ystart=item->pages[i].y; yend=item->pages[i].y+(item->pages[i].len/info->fix.line_length)+1; if (!((y+h)<ystart || y>yend)) { item->pages[i].must_update=1; } } //Schedule the deferred IO to kick in after a delay. schedule_delayed_work(&info->deferred_work, fbdefio->delay); } } 

ビデオメモリ内のデータは、遅延コンテキストとして更新されます。 グラフィックスで動作するユーザースペースアプリケーションは、ビデオメモリの各フレームの記録が完了するのを待ちません。これは非常に論理的です。 fb_infoの遅延処理は、 fb_deferred_io構造として定義されます。

 static struct fb_deferred_io ssd1963_defio = { .delay = HZ / 20, .deferred_io = &ssd1963_update, }; 

プロトタイプを使用したssd1963_update関数
void ssd1963_update（struct fb_info * info、struct list_head * pagelist）;
すべてのページは更新されませんが、ユーザー空間プロセスによる書き換えの結果として、またはfb_fillrectやcompanyなどのシステムコールの結果として変更されたページのみが更新されます。 したがって、関数の形式は次のとおりです。

 static void ssd1963_update(struct fb_info *info, struct list_head *pagelist) { struct ssd1963 *item = (struct ssd1963 *)info->par; struct page *page; int i; list_for_each_entry(page, pagelist, lru) { item->pages[page->index].must_update=1; } //Copy changed pages. for (i=0; i<item->pages_count; i++) { if (item->pages[i].must_update) { item->pages[i].must_update=0; ssd1963_copy(item, i); } } } 

この時点で、おそらくssd1963_copy関数が何をするのか疑問に思うでしょう。 ビデオメモリページから人為的に作成された8ビットGPIOベースのバスにデータを転送するという汚い作業をすべて行います。

ssd1963_copy関数

ここで、メモリ内のページが表示ピクセルとどのように対応するかを示す図を思い出す必要があります。 たとえば、 ページ[0]には、320ピクセルの上位3表示行の情報と、4行目の64ピクセルの情報が格納されています。 このようなページが75ページあり、図の写真があり、気づくのは難しくありません。 ページ[5]は同じように見えます-320行の3行と64行の1行。したがって、ページインデックスをパラメーターとして取る関数にはswitch（index％ 5）そして、特定の各ページのオフセットに応じて、表示メモリでそれに割り当てられた「ウィンドウ」にデータを送信します。 この関数は非常に長いため、その一部のみを提供します。

 static void ssd1963_copy(struct ssd1963 *item, unsigned int index) { unsigned short x,y, startx, endx, starty, endy, offset; unsigned long *buffer; unsigned int len; unsigned int count; x = item->pages[index].x; y = item->pages[index].y; buffer = item->pages[index].buffer; len = item->pages[index].len; switch (index%5) { case 0: offset = 0; startx = x; starty = y; endx = 319; endy = y+2; len = 960; nhd_set_window(startx, endx, starty, endy); nhd_write_data(NHD_COMMAND, 0x2c); for (count = 0; count < len; count++) { nhd_write_data(NHD_DATA,(unsigned char)((buffer[count+offset])>>16)); //red nhd_write_data(NHD_DATA,(unsigned char)((buffer[count+offset])>>8)); //green nhd_write_data(NHD_DATA,(unsigned char)(buffer[count+offset])); //blue } offset = len; startx = x; starty = y+3; endx = x+63; endy = y+3; len = 64; nhd_set_window(startx, endx, starty, endy); nhd_write_data(NHD_COMMAND, 0x2c); for (count = 0; count < len; count++) { nhd_write_data(NHD_DATA,(unsigned char)((buffer[count+offset])>>16)); //red nhd_write_data(NHD_DATA,(unsigned char)((buffer[count+offset])>>8)); //green nhd_write_data(NHD_DATA,(unsigned char)(buffer[count+offset])); //blue } break; case 1: …. 

ここでは、 nhd_set_window関数は nhd_write_data（NHD_COMMAND、...）を使用して構成されています。 データ（ピクセル）が記録される表示領域。
nhd_write_data（NHD_COMMAND、0x2c）; -データストリームが後に続くLCDコントローラへのコマンド。

最後に、ディスプレイ付きのデバイス上のtslibパッケージのts_calibrateプログラムのスクリーンショット。
誰も気にしない-モジュールの完全なコードを送信できます：