mainline build failure due to 322458c2bb1a ("drm/ttm: Reduce the number of used allocation orders for TTM pages")
Linus Torvalds
torvalds at linux-foundation.org
Wed Apr 26 18:30:59 UTC 2023
On Wed, Apr 26, 2023 at 10:44 AM Sudip Mukherjee (Codethink)
<sudipm.mukherjee at gmail.com> wrote:
>
> drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified 'global_write_combined' at file scope
> 73 | static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> | ^~~~~~~~~~~~~~~~~~~~~
Ugh.
This is because we have
#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ?
__TTM_DIM_ORDER : MAX_ORDER)
which looks perfectly fine as a constant ("pick the smaller of
MAX_ORDER and __TTM_DIM_ORDER").
But:
#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
which still _looks_ fine, but on 64-bit powerpc, we then have
#define PTE_INDEX_SIZE __pte_index_size
so that __TTM_DIM_ORDER constant isn't actually a constant at all.
I would suggest that the DRM code just make those fixed-size arrays
use "MAX_ORDER", because even though it might be a bit bigger than
necessary, that's still not a very big constant (ie typically it's
"11", but it could be up to 64).
It's a bit sad how that macro that _looks_ like a constant (and is one
pretty much everywhere else) isn't actually constant on powerpc, but
looking around it looks fairly unavoidable.
Maybe the DRM code could try to avoid using things like PMD_SHIFT entirely?
Linus
More information about the dri-devel
mailing list