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.
Arnd
