lkml.org 
[lkml]   [2019]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] media: staging: davinci_vpfe: disallow building with COMPILE_TEST
On Tue, Mar 5, 2019 at 9:05 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Mar 4, 2019 at 9:30 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > The driver should really call dm365_isif_setup_pinmux() through a callback,
> > but it runs platform specific code by itself, which never actually compiled:
> >
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: implicit declaration of function 'davinci_cfg_reg' [-Werror,-Wimplicit-function-declaration]
> > davinci_cfg_reg(DM365_VIN_CAM_WEN);
> > ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:18: error: use of undeclared identifier 'DM365_VIN_CAM_WEN'
> > davinci_cfg_reg(DM365_VIN_CAM_WEN);
> > ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2029:18: error: use of undeclared identifier 'DM365_VIN_CAM_VD'
> > davinci_cfg_reg(DM365_VIN_CAM_VD);
> > ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2030:18: error: use of undeclared identifier 'DM365_VIN_CAM_HD'
> > davinci_cfg_reg(DM365_VIN_CAM_HD);
> > ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:18: error: use of undeclared identifier 'DM365_VIN_YIN4_7_EN'
> > davinci_cfg_reg(DM365_VIN_YIN4_7_EN);
> > ^
> > /git/arm-soc/drivers/staging/media/davinci_vpfe/dm365_isif.c:2032:18: error: use of undeclared identifier 'DM365_VIN_YIN0_3_EN'
> > davinci_cfg_reg(DM365_VIN_YIN0_3_EN);
> > ^
> > 7 errors generated.
>
> Which tree and which config is this?
> This driver compiles fine with m68k/allmodconfig on v5.0?

Ah, thanks for checking, I found the real issue now:

The Makefile contains a nasty hack that makes it work /almost/ everywhere

# Allow building it with COMPILE_TEST on other archs
ifndef CONFIG_ARCH_DAVINCI
ccflags-y += -I $(srctree)/arch/arm/mach-davinci/include/
endif

This is something we probably don't want to do, but it mostly happens to
do the right thing for compile testing. The case I ran into is the rare
exception of arch/arm/mach-omap1, which has a different mach/mux.h
header, so the '#include <mach/mux.h>' in the driver gets the omap
file rather than the davinci file, and then misses the davinci_cfg_reg()
declaration and the macros.

One way to work around this is to pile on to the hack by adding
'depends on !ARCH_OMAP1'. Should we do that, or is there
a better way out? Do we actually still need the staging driver
in addition to the one in drivers/media/platform/davinci ?

Arnd

\
 
 \ /
  Last update: 2019-03-05 09:49    [W:0.044 / U:4.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site