Last nights automated ARM build found the following errors with randconfig.
All information as usual at http://www.arm.linux.org.uk/developer/build/
Versatile randconfig:
ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
OMAP4430 randconfig:
drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/tty/serial/8250/8250.c:57:32: error: 'CONFIG_SERIAL_8250_RUNTIME_UARTS' undeclared here (not in a function)
drivers/tty/serial/8250/8250.c:2712:47: error: 'CONFIG_SERIAL_8250_NR_UARTS' undeclared here (not in a function)
drivers/tty/serial/8250/8250.c:2971:95: error: negative width in bit-field '<anonymous>'
The last three are caused by incorrect use of 'select':
warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS)
warning: (USB_MUSB_HDRC) selects TWL6030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
This 'select' madness of driver symbols *HAS* *TO* *STOP*.
Hi Rob & Felipe,
* Russell King - ARM Linux <[email protected]> [130304 01:56]:
> Last nights automated ARM build found the following errors with randconfig.
>
> All information as usual at http://www.arm.linux.org.uk/developer/build/
>
>
> Versatile randconfig:
>
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
>
> OMAP4430 randconfig:
>
> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
Rob, I assume you'll do a patch for this one?
> drivers/tty/serial/8250/8250.c:57:32: error: 'CONFIG_SERIAL_8250_RUNTIME_UARTS' undeclared here (not in a function)
> drivers/tty/serial/8250/8250.c:2712:47: error: 'CONFIG_SERIAL_8250_NR_UARTS' undeclared here (not in a function)
> drivers/tty/serial/8250/8250.c:2971:95: error: negative width in bit-field '<anonymous>'
The patch below fixes the 8250 related issue by removing the
selects from Kconfig and adding them to omap2plus_defconfig.
> The last three are caused by incorrect use of 'select':
>
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS)
> warning: (USB_MUSB_HDRC) selects TWL6030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
>
> This 'select' madness of driver symbols *HAS* *TO* *STOP*.
Felipe, can you take a look at removing the MUSB selects from Kconfig?
You might be able to just have MUSB depends on TWL if omap.
Regards,
Tony
From: Tony Lindgren <[email protected]>
Date: Mon, 4 Mar 2013 10:28:21 -0800
Subject: [PATCH] ARM: OMAP2+: Fix unmet direct dependencies for zoom for 8250 serial
We should not select drivers from kconfig as they should by default
be optional. Otherwise we'll be chasing broken dependencies forever:
warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250
which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
Fix the issue by removing the selects for zoom and add them to
omap2plus_defconfig.
Reported-by: Russell King <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -126,6 +126,8 @@ CONFIG_INPUT_MISC=y
CONFIG_INPUT_TWL4030_PWRBUTTON=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -311,9 +311,6 @@ config MACH_OMAP_ZOOM2
default y
select OMAP_PACKAGE_CBB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
- select SERIAL_8250
- select SERIAL_8250_CONSOLE
- select SERIAL_CORE_CONSOLE
config MACH_OMAP_ZOOM3
bool "OMAP3630 Zoom3 board"
@@ -321,9 +318,6 @@ config MACH_OMAP_ZOOM3
default y
select OMAP_PACKAGE_CBP
select REGULATOR_FIXED_VOLTAGE if REGULATOR
- select SERIAL_8250
- select SERIAL_8250_CONSOLE
- select SERIAL_CORE_CONSOLE
config MACH_CM_T35
bool "CompuLab CM-T35/CM-T3730 modules"
Hi,
On Mon, Mar 04, 2013 at 10:46:50AM -0800, Tony Lindgren wrote:
> > The last three are caused by incorrect use of 'select':
> >
> > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS)
> > warning: (USB_MUSB_HDRC) selects TWL6030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
> > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
> >
> > This 'select' madness of driver symbols *HAS* *TO* *STOP*.
>
> Felipe, can you take a look at removing the MUSB selects from Kconfig?
> You might be able to just have MUSB depends on TWL if omap.
I don't think we even need depend or select at all for MUSB. I'll look
at it tomorrow.
--
balbi
* Felipe Balbi <[email protected]> [130304 10:56]:
> Hi,
>
> On Mon, Mar 04, 2013 at 10:46:50AM -0800, Tony Lindgren wrote:
> > > The last three are caused by incorrect use of 'select':
> > >
> > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > > warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS)
> > > warning: (USB_MUSB_HDRC) selects TWL6030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > > warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
> > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > > warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > > warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
> > >
> > > This 'select' madness of driver symbols *HAS* *TO* *STOP*.
> >
> > Felipe, can you take a look at removing the MUSB selects from Kconfig?
> > You might be able to just have MUSB depends on TWL if omap.
>
> I don't think we even need depend or select at all for MUSB. I'll look
> at it tomorrow.
OK thanks!
Tony
On Monday 04 March 2013, Russell King - ARM Linux wrote:
> Versatile randconfig:
>
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
>
I'm pretty sure I submitted a patch for this one before. I'll go looking
for it. IIRC the solution was to export that symbol.
Arnd
On Mon, Mar 04, 2013 at 10:54:24AM -0800, Tony Lindgren wrote:
> * Felipe Balbi <[email protected]> [130304 10:56]:
> > Hi,
> >
> > On Mon, Mar 04, 2013 at 10:46:50AM -0800, Tony Lindgren wrote:
> > > > The last three are caused by incorrect use of 'select':
> > > >
> > > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > > > warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS)
> > > > warning: (USB_MUSB_HDRC) selects TWL6030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> > > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> > > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > > > warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
> > > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > > > warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> > > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> > > > warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> > > > warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
> > > >
> > > > This 'select' madness of driver symbols *HAS* *TO* *STOP*.
> > >
> > > Felipe, can you take a look at removing the MUSB selects from Kconfig?
> > > You might be able to just have MUSB depends on TWL if omap.
> >
> > I don't think we even need depend or select at all for MUSB. I'll look
> > at it tomorrow.
>
> OK thanks!
http://marc.info/?l=linux-usb&m=136248269928419&w=2
--
balbi
On 3/4/2013 3:21 PM, Russell King - ARM Linux wrote:
> Last nights automated ARM build found the following errors with randconfig.
>
> All information as usual at http://www.arm.linux.org.uk/developer/build/
>
>
> Versatile randconfig:
>
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
>
> OMAP4430 randconfig:
> The last three are caused by incorrect use of 'select':
>
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS)
> warning: (USB_MUSB_HDRC) selects TWL6030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MWAVE) selects SERIAL_8250 which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> warning: (USB_MUSB_HDRC) selects TWL4030_USB which has unmet direct dependencies (USB_SUPPORT && (USB || USB_GADGET) && TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_8250_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && SERIAL_8250=y)
> warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3) selects SERIAL_CORE_CONSOLE which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS)
> warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
I submitted a patch to the media guys for the DaVinci media driver
related issues.
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2013-March/026559.html
Thanks,
Sekhar
On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren <[email protected]> wrote:
>
>> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>
> Rob, I assume you'll do a patch for this one?
oh, I apologize for the late reply, I didn't see this email...
There is a patch that we can merge to make tilcdc bool instead of
tristate[1], which I suppose is ok for a temporary fix. Although I'm
all-ears if someone has a better idea about how to fix this. The
problem is that we have multiple sub-devices for different possible
panel drivers, so that depending on DT tables, the correct ones get
loaded for the hw. But they are all built into a single module.
Splitting them into multiple modules will be problematic, as panel
drivers which are present really need to get probed before the
toplevel drm device.. I suppose in theory it is possible to make drm
cope better with dynamically loaded outputs, but I'm not sure that
there is any way to do this without breaking userspace which expects
that all of the connectors/encoders are present once the drm device is
loaded.
BR,
-R
[1] https://patchwork.kernel.org/patch/2376061/
On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote:
> On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren <[email protected]> wrote:
> >
> >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >
> > Rob, I assume you'll do a patch for this one?
>
>
> oh, I apologize for the late reply, I didn't see this email...
>
> There is a patch that we can merge to make tilcdc bool instead of
> tristate[1], which I suppose is ok for a temporary fix. Although I'm
> all-ears if someone has a better idea about how to fix this. The
> problem is that we have multiple sub-devices for different possible
> panel drivers, so that depending on DT tables, the correct ones get
> loaded for the hw. But they are all built into a single module.
> Splitting them into multiple modules will be problematic, as panel
> drivers which are present really need to get probed before the
> toplevel drm device..
You could look at the Tegra driver. I had to solve a similar problem
there. What I did is basically parse the DT in the host1x driver and add
all device nodes which are required by DRM to a list. Later when the
individual devices are probed they are removed from that list, so that
when the list becomes empty we are sure that all required devices are
there and only then call the drm_platform_init() function.
This fits very well with how Tegra hardware is designed because host1x
is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is
probed before any of its children and it can easily parse the DT upfront
and initialize the list of required devices.
> I suppose in theory it is possible to make drm
> cope better with dynamically loaded outputs, but I'm not sure that
> there is any way to do this without breaking userspace which expects
> that all of the connectors/encoders are present once the drm device is
> loaded.
I had been thinking about this on and off for a while, but I haven't
come up with anything concrete. Ideally we could just have some kind of
event that userspace would listen for, so that new outputs can be
dynamically added and userspace informed about them. Last time I checked
most of the helpers assumed that the complete output configuration is
known when the DRM device is registered, so some major rework will be
required to efficiently make use of such dynamicity.
Thierry
On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding
<[email protected]> wrote:
> On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote:
>> On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren <[email protected]> wrote:
>> >
>> >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
>> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>> >
>> > Rob, I assume you'll do a patch for this one?
>>
>>
>> oh, I apologize for the late reply, I didn't see this email...
>>
>> There is a patch that we can merge to make tilcdc bool instead of
>> tristate[1], which I suppose is ok for a temporary fix. Although I'm
>> all-ears if someone has a better idea about how to fix this. The
>> problem is that we have multiple sub-devices for different possible
>> panel drivers, so that depending on DT tables, the correct ones get
>> loaded for the hw. But they are all built into a single module.
>> Splitting them into multiple modules will be problematic, as panel
>> drivers which are present really need to get probed before the
>> toplevel drm device..
>
> You could look at the Tegra driver. I had to solve a similar problem
> there. What I did is basically parse the DT in the host1x driver and add
> all device nodes which are required by DRM to a list. Later when the
> individual devices are probed they are removed from that list, so that
> when the list becomes empty we are sure that all required devices are
> there and only then call the drm_platform_init() function.
thx, ok, I'll have a look at this
> This fits very well with how Tegra hardware is designed because host1x
> is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is
> probed before any of its children and it can easily parse the DT upfront
> and initialize the list of required devices.
>
>> I suppose in theory it is possible to make drm
>> cope better with dynamically loaded outputs, but I'm not sure that
>> there is any way to do this without breaking userspace which expects
>> that all of the connectors/encoders are present once the drm device is
>> loaded.
>
> I had been thinking about this on and off for a while, but I haven't
> come up with anything concrete. Ideally we could just have some kind of
> event that userspace would listen for, so that new outputs can be
> dynamically added and userspace informed about them. Last time I checked
> most of the helpers assumed that the complete output configuration is
> known when the DRM device is registered, so some major rework will be
> required to efficiently make use of such dynamicity.
I'm less worried about the kernel re-work.. more worried about the
fact that we have no way to know whether userspace knows to listen for
this new event. So anything down this path could, I think, be
considered as breaking userspace.
I think in the end, we need some way to have sort of "dummy"
connectors for output drivers which might or might not be probed, so
that from userspace perspective, non-present panels appear as displays
that are not plugged in.
BR,
-R
> Thierry
On Sun, Apr 14, 2013 at 12:29:46AM -0400, Rob Clark wrote:
> On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding
[...]
> > I had been thinking about this on and off for a while, but I haven't
> > come up with anything concrete. Ideally we could just have some kind of
> > event that userspace would listen for, so that new outputs can be
> > dynamically added and userspace informed about them. Last time I checked
> > most of the helpers assumed that the complete output configuration is
> > known when the DRM device is registered, so some major rework will be
> > required to efficiently make use of such dynamicity.
>
> I'm less worried about the kernel re-work.. more worried about the
> fact that we have no way to know whether userspace knows to listen for
> this new event. So anything down this path could, I think, be
> considered as breaking userspace.
Yes, that's probably true. Although the typical use-case would be that
the application would run on any of the detected outputs and if there is
none to begin with it will just fail. If there already is one, it will
try to use that instead and only fail to use a second one if it becomes
available.
> I think in the end, we need some way to have sort of "dummy"
> connectors for output drivers which might or might not be probed, so
> that from userspace perspective, non-present panels appear as displays
> that are not plugged in.
I can imagine that quite a few userspace programs will be broken by this
as well. For instance if you have an LVDS panel, I'm pretty sure people
will just assume that it can't be in a disconnected state and therefore
won't deal with that case.
From a driver's point of view this isn't all that different from the
case you're trying to solve now. You still need to find out which
outputs can eventually become available. But instead of waiting until
they do before registering the DRM device you'd have to create dummy
outputs and keep checking whether the device is actually there each time
somebody interacts with the output.
But maybe this case is different. For Tegra the problem is that some
outputs (such as HDMI) require other drivers to be loaded first because
they provide resources (regulators, GPIOs, ...) that the output drivers
require. All of the drivers use deferred probing to resolve this
dependency and we can be reasonably sure that eventually probing of the
output will succeed (and therefore the output will become available).
Postponing the DRM registration until that point doesn't hurt. From what
I understand your use-case is similar. You need to load drivers for
different panels based on a runtime decision. So the only thing you need
is to be able to postpone the DRM registration until the panel driver
has been loaded, right?
Thierry
On Saturday 13 April 2013, Rob Clark wrote:
> On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren <[email protected]> wrote:
> >
> >> drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >> drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >> drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
> >> drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
> >
> > Rob, I assume you'll do a patch for this one?
>
>
> oh, I apologize for the late reply, I didn't see this email...
>
> There is a patch that we can merge to make tilcdc bool instead of
> tristate[1], which I suppose is ok for a temporary fix. Although I'm
> all-ears if someone has a better idea about how to fix this. The
> problem is that we have multiple sub-devices for different possible
> panel drivers, so that depending on DT tables, the correct ones get
> loaded for the hw. But they are all built into a single module.
If the master device is always present, that's enough for autoloading
the module anyway, you can just drop the other two MODULE_DEVICE_TABLE
lines.
Arnd