Bagikan melalui

Objek-objek ruang nama pengelolaan perangkat

Spesifikasi ACPI 5.0 mendefinisikan beberapa jenis objek namespace yang dapat digunakan untuk mengelola perangkat. Misalnya, objek identifikasi perangkat berisi informasi identifikasi untuk perangkat yang terhubung ke bus, seperti I2C, yang tidak mendukung enumerasi perangkat keras perangkat anak. Jenis objek namespace lainnya dapat menentukan sumber daya sistem, menjelaskan dependensi perangkat, dan menunjukkan perangkat mana yang dapat dinonaktifkan.

Identifikasi perangkat di Windows

Windows Plug and Play menemukan dan memuat driver perangkat berdasarkan pengidentifikasi perangkat yang disediakan oleh enumerator perangkat. Enumerator adalah driver bus yang tahu cara mengekstrak informasi identifikasi dari perangkat. Beberapa bus (seperti PCI, SD, dan USB) memiliki mekanisme yang ditentukan perangkat keras untuk melakukan ekstraksi ini. ACPI menentukan objek-objek pengidentifikasi di dalam namespace untuk bus yang tidak (seperti bus prosesor atau bus periferal sederhana).

Driver Windows ACPI, Acpi.sys, menyusun nilai yang ditemukan dalam objek ini ke dalam berbagai string pengidentifikasi perangkat yang dapat mengidentifikasi perangkat secara khusus, atau secara umum, tergantung pada kebutuhan driver. Beberapa pola string yang dibuat untuk mengidentifikasi perangkat yang di-enumerasi oleh ACPI adalah:

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

Anda dapat melihat pengidentifikasi perangkat yang dibuat Windows untuk perangkat Anda dengan membuka Manajer Perangkat dan memeriksa properti ID Perangkat Keras dan ID yang Kompatibel dari perangkat enumerasi. Masing-masing string ini tersedia untuk ditentukan dalam file INF untuk mengidentifikasi driver yang akan dimuat untuk perangkat. Urutan pencocokan INF adalah dari pengidentifikasi perangkat keras yang paling spesifik (driver yang paling disukai) ke pengidentifikasi yang paling tidak spesifik (driver paling tidak disukai), sehingga driver yang tahu lebih banyak tentang fitur spesifik perangkat dapat menggantikan yang kurang spesifik (dan karenanya hanya mendukung subset fitur perangkat).

Pengidentifikasi perangkat harus digunakan hanya untuk pencocokan INF, dan tidak boleh diurai atau diproses oleh driver perangkat. Jika driver perangkat memiliki kebutuhan untuk mengidentifikasi perangkat keras tertentu yang dimuat, metode yang direkomendasikan adalah mengatur kunci registri yang sesuai pada waktu penginstalan. Driver kemudian dapat mengakses kunci ini selama inisialisasi untuk mendapatkan informasi yang diperlukan.

Identifikasi perangkat di ACPI

ID Perangkat Keras (_HID)

Persyaratan minimum untuk mengidentifikasi perangkat di ACPI adalah objek ID Perangkat Keras (_HID). _HID mengembalikan string dengan format "ABC[D]xxxx", di mana "ABC[D]" adalah string 3 karakter atau 4 karakter yang mengidentifikasi produsen perangkat ("ID Vendor"), dan xxxx adalah angka heksadesimal yang mengidentifikasi perangkat tertentu yang diproduksi oleh vendor tersebut ("ID Perangkat"). ID vendor harus unik di seluruh industri. Microsoft mengalokasikan string ini untuk memastikan bahwa string tersebut unik. ID Penjual dapat diperoleh dari ID Plug and Play - permintaan ID PNPID.

ACPI 5.0 juga mendukung penggunaan ID vendor yang ditetapkan PCI di _HID dan objek identifikasi lainnya, sehingga Anda mungkin tidak perlu mendapatkan ID vendor dari Microsoft. Untuk informasi selengkapnya tentang persyaratan identifikasi perangkat keras, lihat bagian 6.1.5, "_HID (ID Perangkat Keras)", dari spesifikasi ACPI 5.0.

ID yang kompatibel (_CID)

Microsoft telah mencadangkan ID vendor "PNP" untuk perangkat yang kompatibel dengan driver kotak masuk yang dikirim dengan Windows. Windows mendefinisikan sejumlah ID perangkat untuk digunakan dengan ID vendor ini yang dapat digunakan untuk memuat pengandar yang disediakan Windows untuk suatu perangkat. Objek terpisah, objek ID yang Kompatibel (_CID), digunakan untuk mengembalikan pengidentifikasi ini. Windows selalu lebih suka ID Perangkat Keras (dikembalikan oleh _HID) daripada ID yang Kompatibel (dikembalikan oleh _CID) dalam pencocokan INF dan pemilihan driver. Preferensi ini memungkinkan driver yang disediakan Windows diperlakukan sebagai driver default jika driver khusus perangkat yang disediakan vendor tidak tersedia. ID yang Kompatibel dalam tabel berikut ini baru dibuat untuk digunakan dengan platform SoC.

ID yang Kompatibel Deskripsi
PNP0C40 Array tombol yang kompatibel dengan Windows
PNP0C50 Perangkat yang mematuhi HID-over-I2C
PNP0C60 Perangkat sensor tampilan laptop yang dapat dikonversi
PNP0C70 Perangkat sensor stasiun dok
PNP0D10 Pengontrol USB yang sesuai dengan XHCI dengan pemecahan masalah standar
PNP0D15 Pengontrol USB yang mematuhi XHCI tanpa debug standar
PNP0D20 Pengontrol USB yang mematuhi EHCI tanpa debug standar
PNP0D25 Pengontrol USB yang mematuhi EHCI dengan debug standar
PNP0D40 Pengontrol host SD yang mematuhi standar SDA
PNP0D80 Pengontrol manajemen daya sistem yang kompatibel dengan Windows

ID Subsistem (_SUB), Revisi Perangkat Keras (_HRV), dan Kelas (_CLS)

ACPI 5.0 mendefinisikan objek _SUB, _HRV, dan _CLS yang dapat digunakan bersama dengan _HID untuk membuat pengidentifikasi yang lebih unik mengidentifikasi versi, integrasi, atau revisi perangkat keras tertentu dari perangkat, atau untuk menunjukkan keanggotaan di kelas perangkat yang ditentukan PCI. Objek-objek ini umumnya opsional, tetapi mungkin diperlukan oleh kelas perangkat tertentu di Windows. Untuk informasi selengkapnya tentang objek ini, lihat bagian 6.1, "Objek Identifikasi Perangkat", dari spesifikasi ACPI 5.0.

Untuk kemudahan layanan, ada persyaratan Windows Hardware Certification Kit (HCK) bahwa ID perangkat pada sistem OEM harus berupa ID "empat bagian". Empat bagian tersebut adalah ID vendor, ID perangkat, ID vendor subsistem (OEM), dan ID perangkat subsistem (OEM). Oleh karena itu, objek ID Subsistem (_SUB) diperlukan untuk platform OEM.

Metode Device-Specific (_DSM)

Metode _DSM didefinisikan dalam bagian 9.14.1, "_DSM (Metode Khusus Perangkat)", dari spesifikasi ACPI 5.0. Metode ini menyediakan fungsi kontrol dan data khusus perangkat individual yang dapat dipanggil oleh driver perangkat tanpa bertentangan dengan metode khusus perangkat lainnya. _DSM untuk perangkat atau kelas perangkat tertentu mendefinisikan UUID (GUID) yang dijamin tidak berbenturan dengan UUID lain. Untuk setiap UUID, ada serangkaian fungsi yang ditentukan yang dapat diterapkan metode _DSM untuk menyediakan data atau melakukan fungsi kontrol untuk driver. Data khusus kelas dan format datanya disediakan dalam spesifikasi khusus untuk setiap kelas perangkat, dan bahasan terdapat pada Metode Device-Specific ACPI.

Alamat (_ADR) dan ID Unik (_UID)

Ada tiga persyaratan tambahan untuk identifikasi perangkat:

  • Untuk perangkat yang terhubung ke bus induk yang dapat diidentifikasi oleh perangkat keras (misalnya, SDIO, USB HSIC), tetapi memiliki fitur atau kontrol khusus platform (misalnya, daya sideband atau interupsi bangun), _HID tidak digunakan. Sebagai gantinya, pengidentifikasi perangkat dibuat oleh driver bus induk (seperti yang dibahas sebelumnya). Namun, dalam hal ini, Objek Alamat (_ADR) harus berada di namespace ACPI untuk perangkat. Objek ini memungkinkan sistem operasi untuk mengaitkan perangkat yang dienumerasi oleh bus dengan fitur atau kontrol yang dijelaskan oleh ACPI.
  • Pada platform tempat beberapa instans blok IP tertentu digunakan, sehingga setiap blok memiliki objek identifikasi perangkat yang sama, objek Pengidentifikasi Unik (_UID) diperlukan untuk memungkinkan sistem operasi membedakan antar blok.
  • Tidak ada dua perangkat dalam cakupan namespace tertentu yang dapat memiliki nama yang sama.

Objek konfigurasi perangkat

Untuk setiap perangkat yang diidentifikasi di namespace layanan, sumber daya sistem (alamat memori, gangguan, dan sebagainya) yang digunakan oleh perangkat juga harus dilaporkan oleh objek Pengaturan Sumber Daya Saat Ini (_CRS). Pelaporan beberapa kemungkinan konfigurasi sumber daya (_PRS) dan kontrol untuk mengubah konfigurasi sumber daya perangkat (_SRS) didukung tetapi opsional.

Baru untuk platform SoC adalah sumber daya GPIO dan bus periferal sederhana (SPB) yang dapat dikonsumsi perangkat. Untuk informasi selengkapnya, lihat General Purpose I/O (GPIO) dan Simple Peripheral Bus (SPB).

Yang baru untuk platform SoC adalah deskriptor DMA tetap serbaguna. Deskriptor FixedDMA mendukung berbagi perangkat keras pengontrol DMA oleh sejumlah perangkat sistem. Sumber daya DMA (baris permintaan dan register saluran) yang dialokasikan secara statis ke perangkat sistem tertentu tercantum dalam deskriptor FixedDMA. Untuk informasi selengkapnya, lihat bagian 19.5.49, "FixedDMA (DMA Resource Descriptor Macro)", dari spesifikasi ACPI 5.0.

Perubahan status perangkat

Perangkat yang terdaftar di ACPI dapat dinonaktifkan atau dihapus karena berbagai alasan. Objek Status (_STA) disediakan untuk memungkinkan perubahan status tersebut dikomunikasikan ke sistem operasi. Untuk deskripsi _STA, lihat bagian 6.3.7 dari spesifikasi ACPI 5.0. Windows menggunakan _STA untuk menentukan apakah perangkat harus dijumlahkan, ditampilkan sebagai dinonaktifkan, atau tidak terlihat oleh pengguna. Kontrol dalam firmware ini berguna untuk banyak aplikasi, termasuk docking dan pengalihan host-ke-fungsi USB OTG.

Selain itu, ACPI menyediakan mekanisme pemberitahuan yang dapat digunakan ASL untuk memberi tahu driver tentang peristiwa pada platform, seperti perangkat yang dihapus sebagai bagian dari proses docking. Secara umum, ketika status perangkat ACPI berubah, firmware harus melakukan pemberitahuan "pemeriksaan perangkat" atau "pemeriksaan bus" untuk menyebabkan Windows menghitung ulang perangkat dan mengevaluasi kembali _STA. Untuk informasi tentang pemberitahuan ACPI, lihat bagian 5.6.6, "Pemberitahuan Objek Perangkat", dari spesifikasi ACPI 5.0.

Aktifkan/nonaktifkan

Sebagai bagian dari Windows Plug and Play, driver harus mampu diaktifkan secara dinamis dan dinonaktifkan oleh pengguna atau oleh sistem (misalnya, untuk memperbarui driver).

Perangkat On-SoC diintegrasikan ke dalam chip SoC dan tidak dapat dihapus. Driver untuk sebagian besar perangkat di SoC dapat dikecualikan dari persyaratan untuk mengaktifkan dan menonaktifkan. Untuk driver yang tidak dikecualikan, ada antarmuka driver untuk menunjukkan bahwa driver mendukung penghapusan tertib. Untuk informasi selengkapnya, lihat dokumen berjudul "Mengurangi Persyaratan PNP untuk Driver SoC" di situs web Microsoft Connect.

Jika driver mendukung penghapusan tertib, dan perangkat keras perangkat dapat dinonaktifkan (yaitu, perangkat dapat dikonfigurasi untuk berhenti mengakses sumber daya yang ditetapkan), maka simpul namespace ACPI untuk perangkat dapat menyertakan objek Nonaktifkan (_DIS). Metode ini akan dievaluasi oleh sistem operasi setiap kali driver dihapus. Penggunaan _DIS memiliki persyaratan tambahan berikut:

  • _STA harus menghapus bit "diaktifkan dan mendekode sumber dayanya" setiap kali perangkat dinonaktifkan.
  • Perangkat harus menyediakan objek Atur Pengaturan Sumber Daya (_SRS) untuk mengaktifkan kembali perangkat keras perangkat dan mengatur bit di atas dalam _STA.

Untuk informasi selengkapnya, lihat bagian 6.2.3 (_DIS), 6.2.15 (_SRS), dan 6.3.7 (_STA) dari spesifikasi ACPI 5.0.

Dependensi perangkat

Biasanya, ada dependensi perangkat keras antara perangkat pada platform tertentu. Windows mengharuskan semua dependensi tersebut dijelaskan sehingga dapat memastikan bahwa semua perangkat berfungsi dengan benar saat hal-hal berubah secara dinamis dalam sistem (daya perangkat dihapus, driver dihentikan dan dimulai, dan sebagainya). Di ACPI, dependensi antar perangkat dijelaskan dengan cara berikut:

  1. Hierarki namespace. Perangkat apa pun yang merupakan perangkat anak (terdaftar sebagai perangkat dalam namespace perangkat lain) bergantung pada perangkat induk. Misalnya, perangkat USB HSIC bergantung pada port (induk) dan pengontrol (kakek-nenek) yang terhubung dengannya. Demikian pula, perangkat GPU yang tercantum dalam namespace perangkat unit manajemen memori sistem (MMU) bergantung pada perangkat MMU.

  2. Koneksi sumber daya. Perangkat yang terhubung ke pengontrol GPIO atau SPB bergantung pada pengontrol tersebut. Jenis dependensi ini dijelaskan oleh penyertaan Sumber Daya Koneksi dalam _CRS perangkat.

  3. Dependensi OpRegion. Untuk metode kontrol ASL yang menggunakan OpRegions untuk melakukan I/O, dependensi tidak secara implisit diketahui oleh sistem operasi karena hanya ditentukan selama evaluasi metode kontrol. Masalah ini berlaku untuk GeneralPurposeIO dan GenericSerialBus OpRegions di mana driver Plug and Play menyediakan akses ke wilayah tersebut. Untuk mengurangi masalah ini, ACPI mendefinisikan objek Dependensi OpRegion (_DEP). _DEP harus digunakan di namespace perangkat mana pun di mana OpRegion (sumber daya HW) direferensikan oleh metode kontrol, dan tidak ada poin 1 atau 2 di atas yang telah berlaku untuk sumber daya koneksi OpRegion yang direferensikan. Untuk informasi selengkapnya, lihat bagian 6.5.8, "_DEP (Dependensi Wilayah Operasi)", dari spesifikasi ACPI 5.0.

Mungkin juga ada dependensi perangkat lunak antara driver perangkat. Dependensi ini juga harus dijelaskan.

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

  • Last updated on