On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand david@redhat.com wrote:
On 08.04.21 14:49, Linus Walleij wrote:
On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand david@redhat.com wrote:
This is something you could do using a hidden helper symbol like
config DRMA_ASPEED_GFX bool "Aspeed display driver" select DRM_WANT_CMA
config DRM_WANT_CMA bool help Select this from any driver that benefits from CMA being enabled
config DMA_CMA bool "Use CMA helpers for DRM" default DRM_WANT_CMA
ArndThat's precisely what I had first, with an additional "WANT_CMA" -- but looking at the number of such existing options (I was able to spot 1 !)
If you do this it probably makes sense to fix a few other drivers Kconfig in the process. It's not just a problem with your driver. "my" drivers:
:) I actually wanted to convert them to "depends on DMA_CMA" but ran into recursive dependencies ...
drivers/gpu/drm/mcde/Kconfig drivers/gpu/drm/pl111/Kconfig drivers/gpu/drm/tve200/Kconfig
Right, this is the main problem caused by using 'select' to force-enable symbols that other drivers depend on.
Usually, the answer is to be consistent about the use of 'select' and 'depends on', using the former only to enable symbols that are hidden, while using 'depends on' for anything that is an actual build time dependency.
I was assuming these are "real" dependencies. Will it also work without DMA_CMA?
I think in this case, it is fairly likely to work without DMA_CMA when the probe function gets called during a fresh boot, but fairly likely to fail if it gets called after the system has run for long enough to fragment the free memory.
The point of DMA_CMA is to make it work reliably.
Arnd