這一段是在摩托的問題,後來自行解決了,貼過來
在 2.6.28 下,把 CONFIG_SERIAL_8250 = m (可以卸載) ,kernel 重編安裝後開機
開機後有看到 ttyS0 硬體存在:
00:0c: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
然後把 8250_pnp, 8250, serial_core 卸載,
看到卸載訊息:
serial 00:0c: disabled
現在載入自己的測試 driver ,起始部份長這樣:
static int __init modem_init(void)
{
int ret;
printk("modem_init()\n");
if (!request_region(MODEM_IO_BASE , 8, "serial"))
ret = -EBUSY;
printk("MSR = %x\n", inb(MSR));
printk("IER =0x%X \n", inb(IER));
...
}
載入後 request_region() 成功,但是之後讀到的 register 值都是 0xFF
找過 8250.c 很多地方,都沒頭緒,為何 kernel 的 8250 driver 可以動,自己的測試 driver 就讀不到 port data ?
================================================================
解決了,在此把原因整理一下,以後有人遇到這種問題不用卡在這裡~~ 以下是參考kernel version 2.6.28 所得的結果。
若只把 kernel 的 8250.ko 模組載入,該模組一樣無法讀到 serial port,
必須一起載入 8250_pnp.ko 才可以,所以關鍵就在 8250_pnp.c 裡面--->
從 serial8250_pnp_init() 開始追...有一天會呼叫到 pnp_start_dev(),這裡面呼叫了pnp_acpi_set_resources() 然後進入一大包的 ACPI 的動作(至此無力再繼續,希望後續動作有高手指點...),
ok,拉回來 pnp_start_dev() 這邊,繼續會印出
"serial 00:06 activated" ,其中數字是 bus 編號,每台機器不盡相同。
經過了這步驟(pnp_acpi_set_resources()),ACPI 幫你打開 port 了,就可以用了(~~竟然跟 ACPI 有關耶,所以在 embedded 環境下,若是 ACPI 不管這裡的話,就不會有開版所提的問題產生了)
實驗:把之前的 test driver 模仿 8250_pnp.c 的作法,宣告一個 pnp_device_id table & pnp_driver :
static const struct pnp_device_id pnp_dev_table[] = {
{ "ANYDEVS", 0 },
{ "", 0 }
};
static struct pnp_driver test_pnp_driver = {
.name = "serial",
.probe = test_pnp_probe,
.remove = __devexit_p(test_pnp_remove),
.id_table = pnp_dev_table,
};
這裡用 "ANYDEVS" 是要讓 device probe 的過程中 match_device() 能夠成功,match 成功後,pnp 系統才會呼叫我們的 test_pnp_probe() ,此時的 serial port 已經被 ACPI enable 了。
所以在這裡面開始使用 serial port 就沒問題了。
到這裡可告一個段落,只是後續的疑問是:ACPI 到底用甚麼方式來 enable serial port 呢?有待各位大大的指點了...
在 2.6.28 下,把 CONFIG_SERIAL_8250 = m (可以卸載) ,kernel 重編安裝後開機
開機後有看到 ttyS0 硬體存在:
00:0c: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
然後把 8250_pnp, 8250, serial_core 卸載,
看到卸載訊息:
serial 00:0c: disabled
現在載入自己的測試 driver ,起始部份長這樣:
static int __init modem_init(void)
{
int ret;
printk("modem_init()\n");
if (!request_region(MODEM_IO_BASE , 8, "serial"))
ret = -EBUSY;
printk("MSR = %x\n", inb(MSR));
printk("IER =0x%X \n", inb(IER));
...
}
載入後 request_region() 成功,但是之後讀到的 register 值都是 0xFF
找過 8250.c 很多地方,都沒頭緒,為何 kernel 的 8250 driver 可以動,自己的測試 driver 就讀不到 port data ?
================================================================
解決了,在此把原因整理一下,以後有人遇到這種問題不用卡在這裡~~ 以下是參考kernel version 2.6.28 所得的結果。
若只把 kernel 的 8250.ko 模組載入,該模組一樣無法讀到 serial port,
必須一起載入 8250_pnp.ko 才可以,所以關鍵就在 8250_pnp.c 裡面--->
從 serial8250_pnp_init() 開始追...有一天會呼叫到 pnp_start_dev(),這裡面呼叫了pnp_acpi_set_resources() 然後進入一大包的 ACPI 的動作(至此無力再繼續,希望後續動作有高手指點...),
ok,拉回來 pnp_start_dev() 這邊,繼續會印出
"serial 00:06 activated" ,其中數字是 bus 編號,每台機器不盡相同。
經過了這步驟(pnp_acpi_set_resources()),ACPI 幫你打開 port 了,就可以用了(~~竟然跟 ACPI 有關耶,所以在 embedded 環境下,若是 ACPI 不管這裡的話,就不會有開版所提的問題產生了)
實驗:把之前的 test driver 模仿 8250_pnp.c 的作法,宣告一個 pnp_device_id table & pnp_driver :
static const struct pnp_device_id pnp_dev_table[] = {
{ "ANYDEVS", 0 },
{ "", 0 }
};
static struct pnp_driver test_pnp_driver = {
.name = "serial",
.probe = test_pnp_probe,
.remove = __devexit_p(test_pnp_remove),
.id_table = pnp_dev_table,
};
這裡用 "ANYDEVS" 是要讓 device probe 的過程中 match_device() 能夠成功,match 成功後,pnp 系統才會呼叫我們的 test_pnp_probe() ,此時的 serial port 已經被 ACPI enable 了。
所以在這裡面開始使用 serial port 就沒問題了。
到這裡可告一個段落,只是後續的疑問是:ACPI 到底用甚麼方式來 enable serial port 呢?有待各位大大的指點了...
沒有留言:
張貼留言