[opensuse-arm] kernel-default 3.15-rc5 build failing on armv7l
Hello, And another build failure: [ 7576s] CC [M] drivers/gpu/drm/msm/msm_fbdev.o [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_create': [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of 'msm_gem_get_iova_locked' from incompatible pointer type [-Werror] [ 7578s] msm_gem_get_iova_locked(fbdev->bo, 0, &paddr); [ 7578s] ^ [ 7578s] In file included from /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c:18:0: [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *' [ 7578s] int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id, [ 7578s] ^ [ 7578s] cc1: all warnings being treated as errors [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:334: recipe for target 'drivers/gpu/drm/msm/msm_fbdev.o' failed [ 7578s] make[6]: *** [drivers/gpu/drm/msm/msm_fbdev.o] Error 1 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu/drm/msm' failed [ 7578s] make[5]: *** [drivers/gpu/drm/msm] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu/drm' failed [ 7578s] make[4]: *** [drivers/gpu/drm] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu' failed [ 7578s] make[3]: *** [drivers/gpu] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/Makefile:904: recipe for target 'drivers' failed [ 7578s] make[2]: *** [drivers] Error 2 [ 7578s] Makefile:148: recipe for target 'sub-make' failed [ 7578s] make[1]: *** [sub-make] Error 2 [ 7578s] Makefile:26: recipe for target 'all' failed [ 7578s] make: *** [all] Error 2 I guess disabling the msm DRM module would be the easiest workaround. Won't get around to it right away myself. Guillaume? Also, can anyone drop x86_64 from "ARM" repository in Kernel:HEAD? https://build.opensuse.org/project/repositories/Kernel:HEAD Similarly, why is armv6l selected for "Ports" but not armv7l? Would've expected it the other way around. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 18.05.14 20:49, Andreas Färber wrote:
Hello,
And another build failure:
[ 7576s] CC [M] drivers/gpu/drm/msm/msm_fbdev.o [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_create': [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of 'msm_gem_get_iova_locked' from incompatible pointer type [-Werror] [ 7578s] msm_gem_get_iova_locked(fbdev->bo, 0, &paddr); [ 7578s] ^ [ 7578s] In file included from /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_fbdev.c:18:0: [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *' [ 7578s] int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id, [ 7578s] ^ [ 7578s] cc1: all warnings being treated as errors [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:334: recipe for target 'drivers/gpu/drm/msm/msm_fbdev.o' failed [ 7578s] make[6]: *** [drivers/gpu/drm/msm/msm_fbdev.o] Error 1 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu/drm/msm' failed [ 7578s] make[5]: *** [drivers/gpu/drm/msm] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu/drm' failed [ 7578s] make[4]: *** [drivers/gpu/drm] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/scripts/Makefile.build:495: recipe for target 'drivers/gpu' failed [ 7578s] make[3]: *** [drivers/gpu] Error 2 [ 7578s] /home/abuild/rpmbuild/BUILD/kernel-default-3.15.rc5/linux-3.15-rc5/Makefile:904: recipe for target 'drivers' failed [ 7578s] make[2]: *** [drivers] Error 2 [ 7578s] Makefile:148: recipe for target 'sub-make' failed [ 7578s] make[1]: *** [sub-make] Error 2 [ 7578s] Makefile:26: recipe for target 'all' failed [ 7578s] make: *** [all] Error 2
I guess disabling the msm DRM module would be the easiest workaround. Won't get around to it right away myself. Guillaume?
As with the exynos one, I think it's worth it to let the maintainers and authors know. There's a good chance they'll be embarrassed enough to fix it themselves. For a maintainer it's also helpful to know that the code is broken, so that he can remove it again if it stays unfixed for a longer time.
Also, can anyone drop x86_64 from "ARM" repository in Kernel:HEAD? https://build.opensuse.org/project/repositories/Kernel:HEAD
Similarly, why is armv6l selected for "Ports" but not armv7l? Would've expected it the other way around.
I can't really answer these two questions :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19.05.2014 14:02, Alexander Graf wrote:
note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
I've fixed that one, but can not figure out what is wrong now: https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13.2/ke... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 04.06.14 09:28, Matwey V. Kornilov wrote:
On 19.05.2014 14:02, Alexander Graf wrote:
note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
I've fixed that one, but can not figure out what is wrong now:
https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13.2/ke...
If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06/04/2014 04:59 PM, Alexander Graf wrote:
On 04.06.14 09:28, Matwey V. Kornilov wrote:
On 19.05.2014 14:02, Alexander Graf wrote:
note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
I've fixed that one, but can not figure out what is wrong now:
https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13.2/ke...
If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module.
Could we ask linux-media@vger.kernel.org to look at this? -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
At Wed, 04 Jun 2014 23:59:55 +0200, Alexander Graf wrote:
On 04.06.14 09:28, Matwey V. Kornilov wrote:
On 19.05.2014 14:02, Alexander Graf wrote:
note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
I've fixed that one, but can not figure out what is wrong now:
https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13.2/ke...
If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module.
The problem is CONFIG_VIDEO_OMAP4=y while the whole V4L stuff is built as modules. You have to build V4L into kernel, too. That said, it's a Kconfig dependency issue. Looking at the code, though, omap4-iss driver itself is written to be built also as a module. But its Kconfig is bool, so the problem happens. Maybe a patch like below works? Takashi --- diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 78b0fba7047e..0c3e3c1acd4f 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,5 +1,5 @@ config VIDEO_OMAP4 - bool "OMAP 4 Camera support" + tristate "OMAP 4 Camera support" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help--- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06/05/2014 08:29 AM, Takashi Iwai wrote:
At Wed, 04 Jun 2014 23:59:55 +0200, Alexander Graf wrote:
On 04.06.14 09:28, Matwey V. Kornilov wrote:
On 19.05.2014 14:02, Alexander Graf wrote:
note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
I've fixed that one, but can not figure out what is wrong now:
https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13.2/ke...
If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module.
The problem is CONFIG_VIDEO_OMAP4=y while the whole V4L stuff is built as modules. You have to build V4L into kernel, too. That said, it's a Kconfig dependency issue.
Looking at the code, though, omap4-iss driver itself is written to be built also as a module. But its Kconfig is bool, so the problem happens. Maybe a patch like below works?
Takashi
--- diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 78b0fba7047e..0c3e3c1acd4f 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,5 +1,5 @@ config VIDEO_OMAP4 - bool "OMAP 4 Camera support" + tristate "OMAP 4 Camera support" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help---
+Sakari and Laurent. Full thread: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg00004.html I agree, I see no reason for these to be bool. -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Nishanth, On Thursday 05 June 2014 08:37:27 Nishanth Menon wrote:
On 06/05/2014 08:29 AM, Takashi Iwai wrote:
Alexander Graf wrote:
On 04.06.14 09:28, Matwey V. Kornilov wrote:
On 19.05.2014 14:02, Alexander Graf wrote:
note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
I've fixed that one, but can not figure out what is wrong now:
https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13. 2/kernel-default/standard/armv7l>>
If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module.
The problem is CONFIG_VIDEO_OMAP4=y while the whole V4L stuff is built as modules. You have to build V4L into kernel, too. That said, it's a Kconfig dependency issue.
Looking at the code, though, omap4-iss driver itself is written to be built also as a module. But its Kconfig is bool, so the problem happens. Maybe a patch like below works?
Takashi
--- diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 78b0fba7047e..0c3e3c1acd4f 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,5 +1,5 @@
config VIDEO_OMAP4 - bool "OMAP 4 Camera support" + tristate "OMAP 4 Camera support" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help---
+Sakari and Laurent. Full thread: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg00004.html
I agree, I see no reason for these to be bool.
There's no good reason for the option to be a boolean, but there's a bad reason :-/ The OMAP4 ISS driver calls the omap4_ctrl_pad_readl() and omap4_ctrl_pad_writel() functions, which are not exported. The right way to fix this would be to implement a control module driver for the OMAP4, but that's not a straightforward task, and I don't have time to do so at the moment. -- Regards, Laurent Pinchart -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06/05/2014 10:56 AM, Laurent Pinchart wrote:
Hi Nishanth,
On Thursday 05 June 2014 08:37:27 Nishanth Menon wrote:
On 06/05/2014 08:29 AM, Takashi Iwai wrote:
Alexander Graf wrote:
On 04.06.14 09:28, Matwey V. Kornilov wrote:
On 19.05.2014 14:02, Alexander Graf wrote:
> note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
I've fixed that one, but can not figure out what is wrong now:
https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13. 2/kernel-default/standard/armv7l>>
If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module.
The problem is CONFIG_VIDEO_OMAP4=y while the whole V4L stuff is built as modules. You have to build V4L into kernel, too. That said, it's a Kconfig dependency issue.
Looking at the code, though, omap4-iss driver itself is written to be built also as a module. But its Kconfig is bool, so the problem happens. Maybe a patch like below works?
Takashi
--- diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 78b0fba7047e..0c3e3c1acd4f 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,5 +1,5 @@
config VIDEO_OMAP4 - bool "OMAP 4 Camera support" + tristate "OMAP 4 Camera support" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help---
+Sakari and Laurent. Full thread: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg00004.html
I agree, I see no reason for these to be bool.
There's no good reason for the option to be a boolean, but there's a bad reason :-/ The OMAP4 ISS driver calls the omap4_ctrl_pad_readl() and omap4_ctrl_pad_writel() functions, which are not exported. The right way to fix this would be to implement a control module driver for the OMAP4, but that's not a straightforward task, and I don't have time to do so at the moment.
a) control module: from: drivers/staging/media/omap4iss/iss_csiphy.c /* * SCM.CONTROL_CAMERA_RX * - bit [31] : CSIPHY2 lane 2 enable (4460+ only) * - bit [30:29] : CSIPHY2 per-lane enable (1 to 0) * - bit [28:24] : CSIPHY1 per-lane enable (4 to 0) * - bit [21] : CSIPHY2 CTRLCLK enable * - bit [20:19] : CSIPHY2 config: 00 d-phy, 01/10 ccp2 * - bit [18] : CSIPHY1 CTRLCLK enable * - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2 */ cam_rx_ctrl = omap4_ctrl_pad_readl( OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX); Is'nt that what pinctrl does? And should be rather trivial to do, no? c) if there is something else that these bits do that I cant figure out, example: for specific stuff like control module bit for clock (which the above code kinda sounds similar to), like how we had for display recently - model it with dts clock[1] b) if you cannot use existing frameworks OR use pinctrl, last ditch way to do it in pdata-quirks in mach-omap2 with fops being send over. We did debate putting entire control module as a syscon_driver, the current split (prior to syscon) just makes it impractical to switch over to it at this point in time, maybe once all dt-fication is done, it might be possible to switch over to that. [1] http://marc.info/?l=linux-omap&m=140127434229399&w=2 -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Excuse me, gentlemen, AFAIU, there is no this module in 3.14, so, the temporary workaround for openSUSE is to set CONFIG_VIDEO_OMAP4=n. Am I right? I just want to get working ARM kernel in Factory. 2014-06-05 20:17 GMT+04:00 Nishanth Menon <nm@ti.com>:
On 06/05/2014 10:56 AM, Laurent Pinchart wrote:
Hi Nishanth,
On Thursday 05 June 2014 08:37:27 Nishanth Menon wrote:
On 06/05/2014 08:29 AM, Takashi Iwai wrote:
Alexander Graf wrote:
On 04.06.14 09:28, Matwey V. Kornilov wrote:
On 19.05.2014 14:02, Alexander Graf wrote: >> note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
I've fixed that one, but can not figure out what is wrong now:
https://build.opensuse.org/package/live_build_log/home:matwey:pcm051:13. 2/kernel-default/standard/armv7l>>
If I had to guess I'd say someone forgot to put a few EXPORT_SYMBOLs into the code and never tested whether compiling his v4l / video driver actually works when it's compiled as a module.
The problem is CONFIG_VIDEO_OMAP4=y while the whole V4L stuff is built as modules. You have to build V4L into kernel, too. That said, it's a Kconfig dependency issue.
Looking at the code, though, omap4-iss driver itself is written to be built also as a module. But its Kconfig is bool, so the problem happens. Maybe a patch like below works?
Takashi
--- diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 78b0fba7047e..0c3e3c1acd4f 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,5 +1,5 @@
config VIDEO_OMAP4 - bool "OMAP 4 Camera support" + tristate "OMAP 4 Camera support" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 select VIDEOBUF2_DMA_CONTIG ---help---
+Sakari and Laurent. Full thread: http://lists.opensuse.org/archive/opensuse-arm/2014-06/msg00004.html
I agree, I see no reason for these to be bool.
There's no good reason for the option to be a boolean, but there's a bad reason :-/ The OMAP4 ISS driver calls the omap4_ctrl_pad_readl() and omap4_ctrl_pad_writel() functions, which are not exported. The right way to fix this would be to implement a control module driver for the OMAP4, but that's not a straightforward task, and I don't have time to do so at the moment.
a) control module: from: drivers/staging/media/omap4iss/iss_csiphy.c /* * SCM.CONTROL_CAMERA_RX * - bit [31] : CSIPHY2 lane 2 enable (4460+ only) * - bit [30:29] : CSIPHY2 per-lane enable (1 to 0) * - bit [28:24] : CSIPHY1 per-lane enable (4 to 0) * - bit [21] : CSIPHY2 CTRLCLK enable * - bit [20:19] : CSIPHY2 config: 00 d-phy, 01/10 ccp2 * - bit [18] : CSIPHY1 CTRLCLK enable * - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2 */ cam_rx_ctrl = omap4_ctrl_pad_readl( OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX);
Is'nt that what pinctrl does? And should be rather trivial to do, no?
c) if there is something else that these bits do that I cant figure out, example: for specific stuff like control module bit for clock (which the above code kinda sounds similar to), like how we had for display recently - model it with dts clock[1]
b) if you cannot use existing frameworks OR use pinctrl, last ditch way to do it in pdata-quirks in mach-omap2 with fops being send over.
We did debate putting entire control module as a syscon_driver, the current split (prior to syscon) just makes it impractical to switch over to it at this point in time, maybe once all dt-fication is done, it might be possible to switch over to that.
[1] http://marc.info/?l=linux-omap&m=140127434229399&w=2
-- Regards, Nishanth Menon
-- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06/05/2014 11:38 AM, Matwey V. Kornilov wrote:
Excuse me, gentlemen,
AFAIU, there is no this module in 3.14, so, the temporary workaround for openSUSE is to set CONFIG_VIDEO_OMAP4=n. Am I right? I just want to get working ARM kernel in Factory.
If there is no need for VIDEO_OMAP, this does sound fine to me at least. But lets ensure that this kernel bug report is available in linux-omap and devel@driverdev.osuosl.org (for staging?) at the very least? not sure if folks do file bugzilla.kernel.org bugs for staging. -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (6)
-
Alexander Graf -
Andreas Färber -
Laurent Pinchart -
Matwey V. Kornilov -
Nishanth Menon -
Takashi Iwai