On 08.04.21 22:29, Arnd Bergmann wrote:
On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@xxxxxxxxxx> wrote:
On 08.04.21 14:49, Linus Walleij wrote:
On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@xxxxxxxxxx> 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
