Messages in this thread | | | Subject | Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv | From | David Hildenbrand <> | Date | Fri, 9 Apr 2021 10:09:51 +0200 |
| |
On 08.04.21 22:29, Arnd Bergmann wrote: > 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 >>>>> >>>>> Arnd >>>>> >>>> >>>> That'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.
Right, and even at runtime there is no guarantee that DMA_CMA will do anything -- especially if we don't reserve a CMA region (e.g., "cma=X").
So this really sounds like a
"desires DMA_CMA"
and achieving that via an additional symbol or via "default y if ..." for DMA_CMA sounds reasonable.
Thanks!
-- Thanks,
David / dhildenb
| |