Objek namespace manajemen perangkat

  • Artikel

Spesifikasi ACPI 5.0 menentukan beberapa jenis objek namespace layanan 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 pengemudi 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. Untuk bus yang tidak (seperti bus prosesor atau bus periferal sederhana), ACPI menentukan objek identifikasi di namespace layanan.

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 dijumlahkan 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 yang dijumlahkan. 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 yang paling tidak disukai), sehingga driver yang tahu lebih banyak tentang fitur spesifik perangkat dapat menggantikan fitur 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 disarankan 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 Vendor dapat diperoleh dari ID Plug and Play - Permintaan 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 perangkat. Objek terpisah, objek ID yang Kompatibel (_CID), digunakan untuk mengembalikan pengidentifikasi ini. Windows selalu lebih suka ID Piranti 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 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 dock
PNP0D10 Pengontrol USB yang mematuhi XHCI dengan debug 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 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 servis, ada persyaratan Windows Hardware Certification Kit (HCK) bahwa ID perangkat pada sistem OEM menjadi 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 sekumpulan fungsi yang ditentukan yang dapat diterapkan metode _DSM untuk menyediakan data atau melakukan fungsi kontrol untuk driver. Data khusus kelas dan format data disediakan dalam spesifikasi khusus kelas perangkat terpisah, dan juga dibahas dalam 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 dijumlahkan perangkat keras (misalnya, SDIO, USB HSIC), tetapi yang memiliki fitur atau kontrol khusus platform (misalnya, daya sideband atau gangguan 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 dijumlahkan bus dengan fitur atau kontrol yang dijelaskan ACPI.
  • Pada platform di mana 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).

Juga baru untuk platform SoC adalah deskriptor DMA tetap tujuan umum. Deskriptor FixedDMA mendukung berbagi perangkat keras pengontrol DMA oleh sejumlah perangkat sistem. Sumber daya DMA (baris permintaan dan register saluran) 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 dijumlahkan 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 peristiwa di platform, seperti perangkat yang dihapus sebagai bagian dari dock. 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, "Device Object Notifications", dari spesifikasi ACPI 5.0.

Aktifkan/Nonaktifkan

Sebagai bagian dari Plug and Play Windows, driver harus mampu diaktifkan dan dinonaktifkan secara dinamis 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 yang teratur. 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 karena 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 layanan 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 apa pun di mana opRegion (sumber daya HW) direferensikan oleh metode kontrol, dan tidak 1 atau 2 di atas sudah 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 berikut ini: