UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity

video/aperture: Fix typos in comments 

EFI FB, VESA FB or VGA FB etc belong to firmware based framebuffer driver.

Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230404040101.2165600-1-suijingfeng@loongson.cn
This commit is contained in:
Sui Jingfeng 2023-04-04 12:01:01 +08:00 committed by Javier Martinez Canillas
parent 3e66f493e1
commit 92ba67347a
No known key found for this signature in database
GPG Key ID: C751E590D63F3D69
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
drivers/video/aperture.c
View File

@ -20,7 +20,7 @@
* driver can be active at any given time. Many systems load a generic * driver can be active at any given time. Many systems load a generic
* graphics drivers, such as EFI-GOP or VESA, early during the boot process. * graphics drivers, such as EFI-GOP or VESA, early during the boot process.
* During later boot stages, they replace the generic driver with a dedicated, * During later boot stages, they replace the generic driver with a dedicated,
* hardware-specific driver. To take over the device the dedicated driver * hardware-specific driver. To take over the device, the dedicated driver
* first has to remove the generic driver. Aperture functions manage * first has to remove the generic driver. Aperture functions manage
* ownership of framebuffer memory and hand-over between drivers. * ownership of framebuffer memory and hand-over between drivers.
* *
@ -76,7 +76,7 @@
* generic EFI or VESA drivers, have to register themselves as owners of their * generic EFI or VESA drivers, have to register themselves as owners of their
* framebuffer apertures. Ownership of the framebuffer memory is achieved * framebuffer apertures. Ownership of the framebuffer memory is achieved
* by calling devm_aperture_acquire_for_platform_device(). If successful, the * by calling devm_aperture_acquire_for_platform_device(). If successful, the
* driveris the owner of the framebuffer range. The function fails if the * driver is the owner of the framebuffer range. The function fails if the
* framebuffer is already owned by another driver. See below for an example. * framebuffer is already owned by another driver. See below for an example.
* *
* .. code-block:: c * .. code-block:: c
@ -126,7 +126,7 @@
* et al for the registered framebuffer range, the aperture helpers call * et al for the registered framebuffer range, the aperture helpers call
* platform_device_unregister() and the generic driver unloads itself. The * platform_device_unregister() and the generic driver unloads itself. The
* generic driver also has to provide a remove function to make this work. * generic driver also has to provide a remove function to make this work.
* Once hot unplugged fro mhardware, it may not access the device's * Once hot unplugged from hardware, it may not access the device's
* registers, framebuffer memory, ROM, etc afterwards. * registers, framebuffer memory, ROM, etc afterwards.
*/ */
@ -203,7 +203,7 @@ static void aperture_detach_platform_device(struct device *dev)
/* /*
* Remove the device from the device hierarchy. This is the right thing * Remove the device from the device hierarchy. This is the right thing
* to do for firmware-based DRM drivers, such as EFI, VESA or VGA. After * to do for firmware-based fb drivers, such as EFI, VESA or VGA. After
* the new driver takes over the hardware, the firmware device's state * the new driver takes over the hardware, the firmware device's state
* will be lost. * will be lost.
* *