On Tue, Mar 5, 2019 at 9:05 AM Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
> On Mon, Mar 4, 2019 at 9:30 PM Arnd Bergmann <a...@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
