[OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build

[Julien Grall]

Hi,

On 10/04/2019 16:27, Thierry Reding wrote:
> On Wed, Apr 10, 2019 at 03:23:27PM +0100, Ian Jackson wrote:
>> From: Wei Liu <wei.liu2 at citrix.com>
>>
>> Empirically, on stretch armhf:
>>
>>    drivers/gpu/host1x/cdma.c: In function `host1x_pushbuffer_init':
>>    drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of `dma_alloc_wc' from incompatible pointer type [-Werror=incompatible-pointer-types]
>>       pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
>> 						  ^
>> etc.
> 
> This was fixed in v4.18 by this commit:
> 
> 	commit 2f8a6da866eff746a9f8c7745790f3765baeb589
> 	Author: Emil Goode <emil.fsw at goode.io>
> 	Date:   Wed May 16 12:22:04 2018 +0200
> 
> 	    gpu: host1x: Fix compiler errors by converting to dma_addr_t
> 
> 	    The compiler is complaining with the following errors:
> 
> 	    drivers/gpu/host1x/cdma.c:94:48: error:
> 	            passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
> 	            [-Werror=incompatible-pointer-types]
> 
> 	    drivers/gpu/host1x/cdma.c:113:48: error:
> 	            passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
> 	            [-Werror=incompatible-pointer-types]
> 
> 	    The expected pointer type of the third argument to dma_alloc_wc() is
> 	    dma_addr_t but phys_addr_t is passed.
> 
> 	    Change the phys member of struct push_buffer to be dma_addr_t so that we
> 	    pass the correct type to dma_alloc_wc().
> 	    Also check pb->mapped for non-NULL in the destroy function as that is the
> 	    right way of checking if dma_alloc_wc() was successful.
> 
> 	    Signed-off-by: Emil Goode <emil.fsw at goode.io>
> 	    Signed-off-by: Thierry Reding <treding at nvidia.com>
> 
> It should be fairly easy to backport this to older releases, though I'm
> not sure exactly what made this trigger. This wasn't causing any build
> errors for a very long time, since this type mismatch has existed ever
> since the driver was merged all the way back in v3.10.

Likely no-one ever tried to build this module with CONFIG_XEN=y. Xen requires 
dma_addr_t to be 64-bit regardless the page-tables format selected (e.g short vs 
LPAE).

AFAIK, this is the only case on Arm32 where phys_addr_t and dma_addr_t would 
mismatched.

Ian are we using a different config between Jessie and Stretch?

Cheers,

-- 
Julien Grall