ユーザースペースから直接LEDの動作を制御するmmapシステムコールを使用してGPIOを制御することができました。ここで、カーネル空間にドライバーを実装したいと思います。
LinuxでARMコントローラーRPi用の16*2ラインのLCD用の最初のカーネルスペースデバイスドライバーを作成しようとしています。今、私はこの目的のためにGPIOにアクセスする必要があります。
AVRでは、私はこのようにポートにアクセスするために使用します。
#define PORTA *(volatile unsigned char*)0x30
私は、inb（）およびoutb（）関数を使用してi/oポートにアクセスするように指示するLLDを読んでいました。
http://www.makelinux.net/ldd3/chp-9-sect-2
1>ポートの#defineアドレスを使用してGPIOにアクセスすることはできませんか？
2> GPIOを制御するためにinb（）およびoutb（）関数を使用する利点は何ですか？
提案してください。
AVRでは、私はこのようにポートにアクセスするために使用します。
#define PORTA *(volatile unsigned char*)0x30
これは、シンボルをオーバーロードする不適切な定義ですPORTA。
ポートアドレスを0x30として定義することに加えて、その場所の間接参照も行います。
したがって、これは実際には読み取り操作ですが、名前にそのことを示すものはありません。つまり、実際に。のマクロを定義しているということですREAD_PORTA。
1>ポートの#defineアドレスを使用してGPIOにアクセスすることはできませんか？
もちろん、できます（そしてすべきです）。
#define PORTA (unsigned char *)0x30
Linuxソースツリーのデバイスレジスタのヘッダーファイルにも同様のステートメントがあります。#defines新しいデバイスドライバーを開発するとき、デバイスのすべてのレジスターとコマンドコードのヘッダーファイルを探し、ファイルがまだない場合は1つを書き始めます。
2> GPIOを制御するためにinb（）およびoutb（）関数を使用する利点は何ですか？
このコードは、アーキテクチャがI/OポートまたはメモリマップドI/Oのどちらを使用しているかに関係なく、I/Oが実行されていることを明確に示しています。
以下を読んでいる人は誰でも、何が起こっているのかを推測できるはずです。
x = inb(PORTA);
マクロを使用するときの混乱との比較：
x = PORTA;
オーバーロードされたマクロを使用する上記のステートメントは、有能なコーダーによって実施されたコードレビューに合格しません。
また、 Linuxカーネルのコーディングスタイルに精通して使用する必要があります。
1）定義を使用すると、タスクが簡単になることがよくあります。もちろん、ポートにdefineを使用して、ポートにアクセスする必要があるすべての場所でこの構造を文字通り使用することはできません。ただし、LEDをポートBに接続する場合など、デバイスのデザインを変更する場合は、どこでも0x30を別のアドレスに置き換える必要があります。また、コードが読みにくくなります。または、ポートにアクセスする関数を宣言することもできます。このような単純な関数が宣言されているinline場合（コンパイラがインラインをサポートしている場合）、パフォーマンスに違いはありません。
2）を使用する利点はinb()、outb()プログラムの移植性です。これが問題ではない場合は、ポートに直接アクセスすることで問題ありません。