LinuxKPI: import framebuffer support code from drm-kmod

[wulf]

Summary

Historically generic framebuffer support code was tightly integrated
with drm subsystem and was built as part of it. Recent work decoupled
FB support from drm code thus it can be compiled separately.

This change imports following slightly refactored files from drm-kmod:

• linux/fb.h
• linux_fb.c
• vt_drmfb.c

Most meaningfull improvements as compared to current code are:

• All remaining references to drm headers were deleted.
• fictitious page registration was moved back to generic framebuffer support code. The drm driver now has to fill aperture_base and aperture_size fields of struct drm_device rather than call vm_phys_fictitious_reg_range() directly.
• Framebuffer attachment interface has been switched from direct calls to vt_allocate/vt_deallocate to fbd/vt_fb compatible newbus device_attach/device_detach. That allows to choose FreeBSD framebuffer driver at runtime. Traditional fbd/vt_fb can be enabled with setting of loader tunable kern.vt.disable_drmfb to 1
• vd_init, vd_fini, vd_postswitch, vd_suspend, and vd_resume methods implementation was dropped. vt_fb one is used instead as it is almost identical. The only visible difference is extra vd_postswitch call during vd_init in vt_fb code that should not do any harm.

Commit by commit log can be found here:

https://github.com/wulf7/drm-kmod/commits/linux-fb/

drm-kmod MR: https://github.com/freebsd/drm-kmod/pull/342

Currently existing branches with integrated framebuffer support do not
require any patching as all exportable symbols has changed their names.

[bz]

Forgive my lack of knowledge:

(a) what is using this interface in FreeBSD?
(b) has the decoupling also happened upstream?
(c) what's the motivation for migrating it out of drm-kmod? (likely (a) and (b) will answer that I assume)
(d) how is this going to be maintained in the future? I am asking given drivers/video/fbdev/ is a "driver" and we usually tend to import them to sys/contrib/dev/ and not into sys/comapt.linuxkpi?

[wulf]

In D57488#1317060, @bz wrote:

Forgive my lack of knowledge:

(a) what is using this interface in FreeBSD?

udl(4) and inbase legacy drm. Formerly it served for i915kms and amdgpu but now for nvidia tegra only

(b) has the decoupling also happened upstream?

Which upstream? Linux? On Linux FB support consist of at least of 3 layers:

1. drm-agnostic generic frame buffer support in drivers/video/fbdev/core/*.
2. generic drm helpers in drivers/gpu/drm/drm_fb*.
3. Device specific routines in respective drivers.

Code in this review belongs to layer 1 so it is decoupled from day 0.

If you meant drm-kmod as upstream see https://github.com/freebsd/drm-kmod/pull/342

(c) what's the motivation for migrating it out of drm-kmod? (likely (a) and (b) will answer that I assume)

It is not migrated out of drm-kmod. It is moved from drm.ko to linuxkpi_video.ko. But the copy of the latter is a part of base system now.

The motivation is:

1. Move code that do not belong to drm layer out of drm.ko
2. As linux_fb.c has native implementation of couple linuxkpi_video functions, it should be moved to linuxkpi_video.so

(d) how is this going to be maintained in the future? I am asking given drivers/video/fbdev/ is a "driver" and we usually tend to import them to sys/contrib/dev/ and not into sys/comapt.linuxkpi?

It is still part of drm-kmod, To use drm-kmod's version of this code one should do the next:

$ make -DDEVELOPER && mdo make install -DDEVELOPER

and add /boot/modules/linuxkpi_video.ko to kld_list variable in rc.conf before i915kms or amdgpu