dmar, dma_pool, etc

Johannes Lundberg johalun at FreeBSD.org
Sat Apr 27 18:46:18 UTC 2019


Hi

Tycho, I'd like to understand what is the goal with the changes to
linuxkpi and what you plan to use it for. LinuxKPI base is tightly
connected to LinuxkPI GPLv2 and the DRM drivers in ports. We need to
make sure that any change to base LinuxKPI is compatible with what we
have in ports, or patch the ports to handle the changes in base.

For example, there is a CONFIG_INTEL_IOMMU options in Linux code that
enables DMAR. It turns out, ttm has it's own dma_pool implementation.
This is possible since in Linux dma_pool is private to dmapool.c.
Enabling this option for us cause a compile error since dma_pool is
public in base linuxkpi. I don't know if this is really a problem if
CONFIG_INTEL_IOMMU (or CONFIG_SWIOTBL) are options that we'll never use...

Also, we do have a problem with Firefox causing GPU hangs so I'd
appreciate it if Tycho could look through linuxkpi_gplv2, drm and
i915kms (i915kms does not use ttm so no need to look there for problems
with Intel GPU) to see if there are any places needing patching. I know
there's one vtophys() call in fb_mmap() but IIRC, that is never used.
I'll look into that next. There are also uses of PHYS_TO_DMAP() and
VM_PAGE_TO_PHYS(). Would any of these need patching?

Use the default branch at https://github.com/FreeBSDDesktop/kms-drm 

/Johannes




More information about the freebsd-x11 mailing list