Enable most media drivers to build on ARM

The virt_to_bus/bus_to_virt macros are arch-specific. Some archs don't support it. Yet, as it is interesting to allow doing compilation tests on non-ia32/ia64 archs, provide a fallback for such archs.

While here, enable COMPILE_TEST for two media drivers that depends on it.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

---
 drivers/media/pci/sta2x11/Kconfig | 4 ++--
 drivers/media/pci/zoran/Kconfig   | 3 ++-
 include/asm-generic/io.h          | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

drivers/media/pci/sta2x11/Kconfig +2 -2

index 7af3f1cbcea8..fb4b4c8ac430 100644
@@ -1,10 +1,10 @@
 config STA2X11_VIP
        tristate "STA2X11 VIP Video For Linux"
-       depends on STA2X11 || COMPILE_TEST
+       depends on (STA2X11 && VIRT_TO_BUS) || COMPILE_TEST
        depends on HAS_DMA
        select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
        select VIDEOBUF2_DMA_CONTIG
-       depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
+       depends on PCI && VIDEO_V4L2
        depends on VIDEO_V4L2_SUBDEV_API
        depends on I2C
        help

drivers/media/pci/zoran/Kconfig +2 -1

index 39ec35bd21a5..5d2678a9e310 100644
@@ -1,6 +1,7 @@
 config VIDEO_ZORAN
        tristate "Zoran ZR36057/36067 Video For Linux"
-       depends on PCI && I2C_ALGOBIT && VIDEO_V4L2 && VIRT_TO_BUS
+       depends on PCI && I2C_ALGOBIT && VIDEO_V4L2
+       depends on VIRT_TO_BUS || COMPILE_TEST
        depends on !ALPHA
        help
          Say Y for support for MJPEG capture cards based on the Zoran

include/asm-generic/io.h +0 -0

index 66d1d45fa2e1..f448129ad15c 100644

The virt_to_bus/bus_to_virt macros are arch-specific. Some archs don't support it. Yet, as it is interesting to allow doing compilation tests on non-ia32/ia64 archs, provide a fallback for such archs.

While here, enable COMPILE_TEST for two media drivers that depends on it.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Quoted 8 lines · Mauro Carvalho Chehab

The virt_to_bus/bus_to_virt macros are arch-specific. Some archs don't support it. Yet, as it is interesting to allow doing compilation tests on non-ia32/ia64 archs, provide a fallback for such archs.

While here, enable COMPILE_TEST for two media drivers that depends on it.

Quoted 1 line

Signed-off-by Mauro Carvalho Chehab <[email protected]>

I'd prefer not to do this: virt_to_bus() is deprecated for good reasons, and I'd rather see the drivers fixed to use dma-mapping.h correctly.

One problem with your patch is that not all architectures include asm-generic/io.h, so it likely breaks allmodconfig builds on architectures that don't use that file and don't provide virt_to_bus() either.

include/linux/sony-laptop.h +3 -0

 int sony_pic_camera_command(int command, u8 value);
+#else
+static inline int sony_pic_camera_command(int command, u8 value) { return 0; };
+#endif
 
 #endif /* __KERNEL__ */

The pnp header already provide enough stub to build those drivers with COMPILE_TEST on non-x86 archs.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

---
 drivers/media/rc/Kconfig | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/media/rc/Kconfig +5 -5

index eb2c3b6eca7f..9a3b66c6700c 100644
@@ -149,7 +149,7 @@ config RC_ATI_REMOTE
 
 config IR_ENE
 	tristate "ENE eHome Receiver/Transceiver (pnp id: ENE0100/ENE02xxx)"
-	depends on PNP
+	depends on PNP || COMPILE_TEST
 	depends on RC_CORE
 	---help---
 	   Say Y here to enable support for integrated infrared receiver

@@ -210,7 +210,7 @@ config IR_MCEUSB
 
 config IR_ITE_CIR
 	tristate "ITE Tech Inc. IT8712/IT8512 Consumer Infrared Transceiver"
-	depends on PNP
+	depends on PNP || COMPILE_TEST
 	depends on RC_CORE
 	---help---
 	   Say Y here to enable support for integrated infrared receivers

@@ -223,7 +223,7 @@ config IR_ITE_CIR
 
 config IR_FINTEK
 	tristate "Fintek Consumer Infrared Transceiver"
-	depends on PNP
+	depends on PNP || COMPILE_TEST
 	depends on RC_CORE
 	---help---
 	   Say Y here to enable support for integrated infrared receiver

@@ -257,7 +257,7 @@ config IR_MTK
 
 config IR_NUVOTON
 	tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
-	depends on PNP
+	depends on PNP || COMPILE_TEST
 	depends on RC_CORE
 	---help---
 	   Say Y here to enable support for integrated infrared receiver

@@ -305,7 +305,7 @@ config IR_STREAMZAP
 
 config IR_WINBOND_CIR
 	tristate "Winbond IR remote control"
-	depends on X86 && PNP
+	depends on (X86 && PNP) || COMPILE_TEST
 	depends on RC_CORE
 	select NEW_LEDS
 	select LEDS_CLASS

Signature · 1 line

2.14.3

Despite depending on ACPI, this driver builds fine on non-x86 archtecture with COMPILE_TEST, as it doesn't depend on ACPI-specific functions/structs.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

---
 include/video/omapfb_dss.h | 54 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 52 insertions(+), 2 deletions(-)

Quoted 7 lines

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

This patch should be dropped (together with patch #6/7) as it was superseded by a better solution suggested by Laurent:

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

Em Mon, 23 Apr 2018 14:47:28 +0200
Bartlomiej Zolnierkiewicz <[email protected]> escreveu:

Quoted 12 lines · Mauro Carvalho Chehab

Quoted 7 lines

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

This patch should be dropped (together with patch #6/7) as it was superseded by a better solution suggested by Laurent:

Quoted 8 lines

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

I "ressurected" this patch due to patch 6/7.

The problem with the solution already acked/merged is that it works *only* if you don't try to build for ARM.

At the moment you want to build a FB_OMAP2-dependent driver on ARM with allyesc onfig, DRM_OMAP will be true, and FB_OMAP2 will be disabled:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support" depends on FB
depends on DRM_OMAP = n

One solution might be to change the depends on to:

        	depends on (DRM_OMAP = n || COMPILE_TEST)

But someone pointed me that the above check was added to avoid building duplicated symbols. So, the above would cause build failures.

So, in order to build for ARM with DRM_OMAP selected (allyesconfig, allmodconfig), we have the following alternatives:

1) apply patch 5/7;
2) make sure that FB_OMAP2 and DRM_OMAP won't declare the same non-static symbols;
3) redesign FB_OMAP2 to work with DRM_OMAP built.

I suspect that (1) is easier.

Quoted 52 lines

Em Mon, 23 Apr 2018 14:47:28 +0200
Bartlomiej Zolnierkiewicz <[email protected]> escreveu:

Quoted 12 lines · Mauro Carvalho Chehab

Quoted 7 lines

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

This patch should be dropped (together with patch #6/7) as it was superseded by a better solution suggested by Laurent:

Quoted 8 lines

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

I "ressurected" this patch due to patch 6/7.

The problem with the solution already acked/merged is that it works *only* if you don't try to build for ARM.

At the moment you want to build a FB_OMAP2-dependent driver on ARM with allyesc onfig, DRM_OMAP will be true, and FB_OMAP2 will be disabled:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support" depends on FB
depends on DRM_OMAP = n

One solution might be to change the depends on to:

        	depends on (DRM_OMAP = n || COMPILE_TEST)

But someone pointed me that the above check was added to avoid building duplicated symbols. So, the above would cause build failures.

So, in order to build for ARM with DRM_OMAP selected (allyesconfig, allmodconfig), we have the following alternatives:

1) apply patch 5/7;
2) make sure that FB_OMAP2 and DRM_OMAP won't declare the same non-static symbols;
3) redesign FB_OMAP2 to work with DRM_OMAP built.

Quoted 1 line

I suspect that (1) is easier.

I agree.

You can merge this patch through your tree with:

Acked-by Bartlomiej Zolnierkiewicz <[email protected]>

Quoted 7 lines · Mauro Carvalho Chehab

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

This patch should be dropped (together with patch #6/7) as it was superseded by a better solution suggested by Laurent:

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

Ideally we should be able to build both drivers in the same kernel (especially as modules).

I was hoping that it could be fixed easily but then I discovered the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display':
display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here

Quoted 10 lines

Ideally we should be able to build both drivers in the same kernel (especially as modules).

I was hoping that it could be fixed easily but then I discovered the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display':
display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here

The main problem is that omapdrm and omapfb are two different drivers for the same HW. You need to pick one, even if we would change those functions and fix the link issue.

At some point in time we could compile both as modules (but not built-in), but the only use for that was development/testing and in the end made our life more difficult. So, now you must fully disable one of them to enable the other. And, actually, we even have boot-time code, not included in the module itself, which gets enabled when omapdrm is enabled.

While it's of course good to support COMPILE_TEST, if using COMPILE_TEST with omapfb is problematic, I'm not sure if it's worth to spend time on that. We should be moving away from omapfb to omapdrm.

Quoted 6 lines · Bartlomiej Zolnierkiewicz

Ideally we should be able to build both drivers in the same kernel (especially as modules).

I was hoping that it could be fixed easily but then I discovered the root source of the problem:

Quoted 3 lines

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display':
display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here

The main problem is that omapdrm and omapfb are two different drivers for the same HW. You need to pick one, even if we would change those functions and fix the link issue.

At some point in time we could compile both as modules (but not built-in), but the only use for that was development/testing and in the end made our life more difficult. So, now you must fully disable one of them to enable the other. And, actually, we even have boot-time code, not included in the module itself, which gets enabled when omapdrm is enabled.

While it's of course good to support COMPILE_TEST, if using COMPILE_TEST with omapfb is problematic, I'm not sure if it's worth to spend time on that. We should be moving away from omapfb to omapdrm.

Quoted 12 lines · Tomi Valkeinen

Quoted 9 lines · Bartlomiej Zolnierkiewicz

Ideally we should be able to build both drivers in the same kernel (especially as modules).

I was hoping that it could be fixed easily but then I discovered the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display':
display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here

Quoted 3 lines

The main problem is that omapdrm and omapfb are two different drivers for the same HW. You need to pick one, even if we would change those functions and fix the link issue.

With proper resource allocation in both drivers this shouldn't be a problem - the one which allocates resources first will be used (+ we can initialize omapdrm first in case it is built-in). This is how similar situations are handled in other kernel subsystems.

It seems that the real root problem is commit f76ee892a99e ("omapfb:
copy omapdss & displays for omapfb") from Dec 2015 which resulted in duplication of ~30 KLOC of code. The code in question seems to be both fbdev & drm independent:

"
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the display subsystem IPs used on OMAP (and related) SoCs. It offers only a kernel internal API, and does not implement anything for fbdev or drm.

* omapdss panels and encoders, located in drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder drivers, which use APIs offered by omapdss driver. These also don't implement anything for fbdev or drm.
"

While I understand some motives behind this change I'm not overall happy with it..

Quoted 6 lines

At some point in time we could compile both as modules (but not built-in), but the only use for that was development/testing and in the end made our life more difficult. So, now you must fully disable one of them to enable the other. And, actually, we even have boot-time code, not included in the module itself, which gets enabled when omapdrm is enabled.

Do you mean some code in arch/arm/mach-omap2/ or something else?

Quoted 3 lines

While it's of course good to support COMPILE_TEST, if using COMPILE_TEST with omapfb is problematic, I'm not sure if it's worth to spend time on that. We should be moving away from omapfb to omapdrm.

Is there some approximate schedule for omapfb removal available?

Quoted 12 lines · Mauro Carvalho Chehab

Quoted 7 lines

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

This patch should be dropped (together with patch #6/7) as it was superseded by a better solution suggested by Laurent:

Quoted 8 lines

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

Hmm, I see now while this patch is still included:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB
depends on DRM_OMAP = n

Ideally we should be able to build both drivers in the same kernel (especially as modules).

I was hoping that it could be fixed easily but then I discovered the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display':
display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here
...

I need some more time to think about this..

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:

Quoted 32 lines · Bartlomiej Zolnierkiewicz

Quoted 12 lines · Mauro Carvalho Chehab

Quoted 7 lines

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

This patch should be dropped (together with patch #6/7) as it was superseded by a better solution suggested by Laurent:

Quoted 8 lines

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

Hmm, I see now while this patch is still included:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB
depends on DRM_OMAP = n

Ideally we should be able to build both drivers in the same kernel (especially as modules).

Quoted 8 lines

I was hoping that it could be fixed easily but then I discovered the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function omapdss_unregister_display': display.c:(.text+0x2c): multiple definition of omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198):
first defined here ...

Yes, and declared on two different places:

drivers/gpu/drm/omapdrm/dss/omapdss.h:void omapdss_unregister_display(struct omap_dss_device *dssdev); include/video/omapfb_dss.h:void omapdss_unregister_display(struct omap_dss_device *dssdev);

one alternative would be to give different names to it, and a common header for both.

At such header, it could be doing something like:

static inline void omapdss_unregister_display(struct omap_dss_device *dssdev) {

#if enabled(CONFIG_DRM_OMAP)
	omapdss_unregister_display_drm(struct omap_dss_device *dssdev);
#else
	omapdss_unregister_display_fb(struct omap_dss_device *dssdev);

##endif
}

Yet, after a very quick check, it seems that nowadays only the media omap driver uses the symbols at FB_OMAP:

$ git grep omapfb_dss.h
drivers/media/platform/omap/omap_vout.c:#include <video/omapfb_dss.h>
drivers/media/platform/omap/omap_voutdef.h:#include <video/omapfb_dss.h>
drivers/media/platform/omap/omap_voutlib.c:#include <video/omapfb_dss.h>

So, perhaps just renaming the common symbols and changing FB_OMAP2 to:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support" depends on FB
depends on (DRM_OMAP = n) || COMPILE_TEST

would be enough to allow to build both on ARM.

Quoted 1 line

I need some more time to think about this..

Hi Mauro,

Quoted 77 lines · On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote:

Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:

Quoted 32 lines · Bartlomiej Zolnierkiewicz

Quoted 12 lines · Mauro Carvalho Chehab

Quoted 7 lines

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

This patch should be dropped (together with patch #6/7) as it was superseded by a better solution suggested by Laurent:

Quoted 8 lines

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

Hmm, I see now while this patch is still included:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB
depends on DRM_OMAP = n

Ideally we should be able to build both drivers in the same kernel (especially as modules).

Quoted 8 lines

I was hoping that it could be fixed easily but then I discovered the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function omapdss_unregister_display': display.c:(.text+0x2c): multiple definition of omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198):
first defined here ...

Yes, and declared on two different places:

drivers/gpu/drm/omapdrm/dss/omapdss.h:void omapdss_unregister_display(struct omap_dss_device *dssdev); include/video/omapfb_dss.h:void omapdss_unregister_display(struct omap_dss_device *dssdev);

one alternative would be to give different names to it, and a common header for both.

At such header, it could be doing something like:

static inline void omapdss_unregister_display(struct omap_dss_device *dssdev) {

#if enabled(CONFIG_DRM_OMAP)
	omapdss_unregister_display_drm(struct omap_dss_device *dssdev);
#else
	omapdss_unregister_display_fb(struct omap_dss_device *dssdev);

##endif
}

Yet, after a very quick check, it seems that nowadays only the media omap driver uses the symbols at FB_OMAP:

$ git grep omapfb_dss.h
drivers/media/platform/omap/omap_vout.c:#include <video/omapfb_dss.h>
drivers/media/platform/omap/omap_voutdef.h:#include <video/omapfb_dss.h>
drivers/media/platform/omap/omap_voutlib.c:#include <video/omapfb_dss.h>

So, perhaps just renaming the common symbols and changing FB_OMAP2 to:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support" depends on FB
depends on (DRM_OMAP = n) || COMPILE_TEST

Quoted 1 line

would be enough to allow to build both on ARM.

I don't think it's worth it renaming the common symbols. They will change over time as omapdrm is under heavy rework, and it's painful enough without having to handle cross-tree changes.

Let's just live with the fact that both drivers
can't be compiled at the same time, given that omapfb is deprecated.

Laurent Pinchart <[email protected]> escreveu:

Quoted 86 lines · On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote:

Quoted 85 lines

Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:

Quoted 36 lines · Bartlomiej Zolnierkiewicz

Quoted 12 lines · Mauro Carvalho Chehab

Quoted 7 lines

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined, with can happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

This patch should be dropped (together with patch #6/7) as it was superseded by a better solution suggested by Laurent:

Quoted 8 lines

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

Hmm, I see now while this patch is still included:

menuconfig FB_OMAP2

tristate "OMAP2+ frame buffer support"
depends on FB
depends on DRM_OMAP = n

Ideally we should be able to build both drivers in the same kernel (especially as modules).

I was hoping that it could be fixed easily but then I discovered the root source of the problem:

Quoted 7 lines

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display': display.c:(.text+0x2c): multiple definition
of `omapdss_unregister_display' drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198) :
first defined here ...

Yes, and declared on two different places:

drivers/gpu/drm/omapdrm/dss/omapdss.h:void omapdss_unregister_display(struct omap_dss_device *dssdev); include/video/omapfb_dss.h:void omapdss_unregister_display(struct omap_dss_device *dssdev);

one alternative would be to give different names to it, and a common header for both.

At such header, it could be doing something like:

static inline void omapdss_unregister_display(struct omap_dss_device *dssdev) {
#if enabled(CONFIG_DRM_OMAP)

	omapdss_unregister_display_drm(struct omap_dss_device *dssdev);

#else

	omapdss_unregister_display_fb(struct omap_dss_device *dssdev);

##endif
}

Yet, after a very quick check, it seems that nowadays only the media omap driver uses the symbols at FB_OMAP:

$ git grep omapfb_dss.h
drivers/media/platform/omap/omap_vout.c:#include <video/omapfb_dss.h>
drivers/media/platform/omap/omap_voutdef.h:#include <video/omapfb_dss.h>
drivers/media/platform/omap/omap_voutlib.c:#include <video/omapfb_dss.h>

So, perhaps just renaming the common symbols and changing FB_OMAP2 to:
menuconfig FB_OMAP2

tristate "OMAP2+ frame buffer support" depends on FB
depends on (DRM_OMAP = n) || COMPILE_TEST

Quoted 5 lines

Quoted 1 line

would be enough to allow to build both on ARM.

I don't think it's worth it renaming the common symbols. They will change over time as omapdrm is under heavy rework, and it's painful enough without having to handle cross-tree changes.

It could just rename the namespace-conflicting FB_OMAP2 functions, keeping the DRM ones as-is.

Quoted 2 lines

Let's just live with the fact that both drivers
can't be compiled at the same time, given that omapfb is deprecated.

IMO, a driver that it is deprecated, being in a state where it conflicts with a non-deprecated driver that is under heavy rework is a very good candidate to go to drivers/staging or even to /dev/null.

Quoted 3 lines

I don't think it's worth it renaming the common symbols. They will change over time as omapdrm is under heavy rework, and it's painful enough without having to handle cross-tree changes.

It could just rename the namespace-conflicting FB_OMAP2 functions, keeping the DRM ones as-is.

Quoted 2 lines

Let's just live with the fact that both drivers
can't be compiled at the same time, given that omapfb is deprecated.

IMO, a driver that it is deprecated, being in a state where it conflicts with a non-deprecated driver that is under heavy rework is a very good candidate to go to drivers/staging or even to /dev/null.

Quoted 6 lines · Mauro Carvalho Chehab

Quoted 3 lines

I don't think it's worth it renaming the common symbols. They will change over time as omapdrm is under heavy rework, and it's painful enough without having to handle cross-tree changes.

It could just rename the namespace-conflicting FB_OMAP2 functions, keeping the DRM ones as-is.

Yes, I'm fine with renaming omapfb functions if that helps. But still, if omapdrm is enabled in the kernel as module or built-in, omapfb will not work. So even if we get them to compile and link, it'll break at runtime one way or another.

Quoted 3 lines

Quoted 2 lines

Let's just live with the fact that both drivers
can't be compiled at the same time, given that omapfb is deprecated.

Quoted 3 lines

IMO, a driver that it is deprecated, being in a state where it conflicts with a non-deprecated driver that is under heavy rework is a very good candidate to go to drivers/staging or even to /dev/null.

The problem is that it supports old devices which are not supported by omapdrm. But both omapfb and omapdrm support many of the same devices.

Could we trim down omapfb to remove support for the devices supported by omapdrm ?

Quoted 2 lines · Laurent Pinchart

Could we trim down omapfb to remove support for the devices supported by omapdrm ?

I was thinking about just that. But, of course, it's not quite straightforward either.

We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which covers a lot of devices.

And VRFB on OMAP2/3.

Those need omapfb.

Hi Tomi,

Quoted 4 lines · On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:

Quoted 2 lines · Laurent Pinchart

Could we trim down omapfb to remove support for the devices supported by omapdrm ?

Quoted 5 lines

I was thinking about just that. But, of course, it's not quite straightforward either.

We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which covers a lot of devices.

Sebastian is working on getting that feature in omapdrm, isn't he ?

Quoted 1 line

And VRFB on OMAP2/3.

And that's something I'd really like to have in omapdrm too.

Quoted 5 lines · Laurent Pinchart

Quoted 4 lines · On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:

Quoted 2 lines · Laurent Pinchart

Could we trim down omapfb to remove support for the devices supported by omapdrm ?

Quoted 7 lines

Quoted 5 lines

I was thinking about just that. But, of course, it's not quite straightforward either.

We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which covers a lot of devices.

Sebastian is working on getting that feature in omapdrm, isn't he ?

Yes, and I keep pushing it forward because of the restructuring you're doing =) (feel free to comment on that thread). But agreed, it's getting better. When we have manual update support, I think the biggest missing feature is then in omapdrm.

Quoted 3 lines

Quoted 1 line

And VRFB on OMAP2/3.

And that's something I'd really like to have in omapdrm too.

Considering how much headache TILER has given, I'm not exactly looking forward to it ;).

If we get manual update and VRFB, I think we are more or less covered on the supported HW features. It'll still break userspace apps which use omapfb, though. Unless we also port the omapfb specific IOCTLs and the sysfs files, which I believe we should not.

This driver depends on FB_VIA for lots of things. Provide stubs for the functions it needs, in order to allow building it with COMPILE_TEST outside x86 architecture.

drivers/media/platform/via-camera.c +5 -1

+	if (!machine_is_olpc())
+		return false;
+#endif
+
 	if (!pbus)
 		return false;
 	pci_bus_read_config_byte(pbus, VIACAM_SERIAL_DEVFN,

@@ -1343,7 +1351,7 @@ static int viacam_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	if (machine_is_olpc() && viacam_serial_is_enabled())
+	if (viacam_serial_is_enabled())
 		return -EBUSY;
 
 	/*

include/linux/via-core.h +17 -0

index 9c21cdf3e3b3..ced4419baef8 100644
@@ -70,8 +70,12 @@ struct viafb_pm_hooks {
 	void *private;
 };
 
+#ifdef CONFIG_FB_VIA
 void viafb_pm_register(struct viafb_pm_hooks *hooks);
 void viafb_pm_unregister(struct viafb_pm_hooks *hooks);
+#else
+static inline void viafb_pm_register(struct viafb_pm_hooks *hooks) {}
+#endif /* CONFIG_FB_VIA */
 #endif /* CONFIG_PM */
 
 /*

@@ -113,8 +117,13 @@ struct viafb_dev {
  * Interrupt management.
  */
 
+#ifdef CONFIG_FB_VIA
 void viafb_irq_enable(u32 mask);
 void viafb_irq_disable(u32 mask);
+#else
+static inline void viafb_irq_enable(u32 mask) {}
+static inline void viafb_irq_disable(u32 mask) {}
+#endif
 
 /*
  * The global interrupt control register and its bits.

@@ -157,10 +166,18 @@ void viafb_irq_disable(u32 mask);
 /*
  * DMA management.
  */
+#ifdef CONFIG_FB_VIA
 int viafb_request_dma(void);
 void viafb_release_dma(void);
 /* void viafb_dma_copy_out(unsigned int offset, dma_addr_t paddr, int len); */
 int viafb_dma_copy_out_sg(unsigned int offset, struct scatterlist *sg, int nsg);
+#else
+static inline int viafb_request_dma(void) { return 0; }
+static inline void viafb_release_dma(void) {}
+static inline int viafb_dma_copy_out_sg(unsigned int offset,
+					struct scatterlist *sg, int nsg)
+{ return 0; }
+#endif
 
 /*
  * DMA Controller registers.

include/linux/via-gpio.h +4 -0

index 8281aea3dd6d..b5a96cf7a874 100644
@@ -8,7 +8,11 @@
 #ifndef __VIA_GPIO_H__
 #define __VIA_GPIO_H__
 
+#ifdef CONFIG_FB_VIA
 extern int viafb_gpio_lookup(const char *name);
 extern int viafb_gpio_init(void);
 extern void viafb_gpio_exit(void);
+#else
+static inline int viafb_gpio_lookup(const char *name) { return 0; }
+#endif
 #endif

include/linux/via_i2c.h +1 -0

index 44532e468c05..209bff950e22 100644
@@ -32,6 +32,7 @@ struct via_i2c_stuff {
 };
 
 
+#ifdef CONFIG_FB_VIA
 int viafb_i2c_readbyte(u8 adap, u8 slave_addr, u8 index, u8 *pdata);
 int viafb_i2c_writebyte(u8 adap, u8 slave_addr, u8 index, u8 data);
 int viafb_i2c_readbytes(u8 adap, u8 slave_addr, u8 index, u8 *buff, int buff_len);

Hi Mauro,

Quoted 3 lines · Mauro Carvalho Chehab

This driver depends on FB_VIA for lots of things. Provide stubs for the functions it needs, in order to allow building it with COMPILE_TEST outside x86 architecture.

Please cc: me on fbdev related patches (patch adding new FB_VIA ifdefs _is_ definitely fbdev related).

drivers/media/platform/Kconfig source "drivers/media/platform/marvell-ccic/Kconfig" · line 18

Quoted 13 lines

Signed-off-by Mauro Carvalho Chehab <[email protected]>

drivers/media/platform/Kconfig +1 -1

index e3229f7baed1..abaaed98a044 100644
@@ -15,7 +15,7 @@ source "drivers/media/platform/marvell-ccic/Kconfig"
 
 config VIDEO_VIA_CAMERA
 	tristate "VIAFB camera controller support"
-	depends on FB_VIA
+	depends on FB_VIA || COMPILE_TEST  

This is incorrect (too simple), please take a look at FB_VIA entry:

config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support" depends on FB && PCI && X86 && GPIOLIB && I2C select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select I2C_ALGOBIT
help

Therefore you also need to check PCI, GPIOLIB && I2C dependencies.

* For PCI=n:

drivers/media/platform/via-camera.c: In function ‘viacam_serial_is_enabled’:
drivers/media/platform/via-camera.c:1286:9: error: implicit declaration of function ‘pci_find_bus’ [-Werror=implicit-function-declaration] drivers/media/platform/via-camera.c:1286:25: warning: initialization makes pointer from integer without a cast [enabled by default] drivers/media/platform/via-camera.c:1296:2: error: implicit declaration of function ‘pci_bus_read_config_byte’ [-Werror=implicit-function-declaration] drivers/media/platform/via-camera.c:1308:2: error: implicit declaration of function ‘pci_bus_write_config_byte’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/media/platform/via-camera.o] Error 1

* For I2C=n:

WARNING: unmet direct dependencies detected for VIDEO_OV7670
Depends on [n]: MEDIA_SUPPORT [=y] && I2C [=n] && VIDEO_V4L2 [=y] && MEDIA_CAMERA_SUPPORT [=y] Selected by [y]:
- VIDEO_VIA_CAMERA [=y] && MEDIA_SUPPORT [=y] && V4L_PLATFORM_DRIVERS [=y] && (FB_VIA [=n] || COMPILE_TEST [=y])

drivers/media/i2c/ov7670.c: In function ‘ov7670_read_smbus’:
drivers/media/i2c/ov7670.c:483:2: error: implicit declaration of function ‘i2c_smbus_read_byte_data’ [-Werror=implicit-function-declaration]
ret = i2c_smbus_read_byte_data(client, reg);
^
drivers/media/i2c/ov7670.c: In function ‘ov7670_write_smbus’:
drivers/media/i2c/ov7670.c:496:2: error: implicit declaration of function ‘i2c_smbus_write_byte_data’ [-Werror=implicit-function-declaration]
int ret = i2c_smbus_write_byte_data(client, reg, value);
^
drivers/media/i2c/ov7670.c: In function ‘ov7670_read_i2c’:
drivers/media/i2c/ov7670.c:521:2: error: implicit declaration of function ‘i2c_transfer’ [-Werror=implicit-function-declaration]
ret = i2c_transfer(client->adapter, &msg, 1);
^
drivers/media/i2c/ov7670.c: In function ‘ov7670_probe’:
drivers/media/i2c/ov7670.c:1835:3: error: implicit declaration of function ‘i2c_adapter_id’ [-Werror=implicit-function-declaration]
v4l_dbg(1, debug, client,
^
drivers/media/i2c/ov7670.c: At top level:
drivers/media/i2c/ov7670.c:1962:1: warning: data definition has no type or storage class [enabled by default]
module_i2c_driver(ov7670_driver);
^
drivers/media/i2c/ov7670.c:1962:1: error: type defaults to ‘int’ in declaration of ‘module_i2c_driver’ [-Werror=implicit-int] drivers/media/i2c/ov7670.c:1962:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/media/i2c/ov7670.c:1952:26: warning: ‘ov7670_driver’ defined but not used [-Wunused-variable]

 static struct i2c_driver ov7670_driver = {
                          ^

cc1: some warnings being treated as errors
make[3]: *** [drivers/media/i2c/ov7670.o] Error 1

* For GPIOLIB=n it builds fine.

drivers/media/platform/via-camera.c line 31

Quoted 13 lines

drivers/media/platform/Kconfig +0 -0

 	select VIDEOBUF_DMA_SG
 	select VIDEO_OV7670
 	help

drivers/media/platform/via-camera.c +2 -0

index e9a02639554b..4ab1695b33af 100644
@@ -27,7 +27,10 @@
 #include <linux/via-core.h>
 #include <linux/via-gpio.h>
 #include <linux/via_i2c.h>
+
+#ifdef CONFIG_FB_VIA  

This should be CONFIG_X86.

drivers/media/platform/via-camera.c static bool viacam_serial_is_enabled(void) · line 1289

Quoted 10 lines

drivers/media/platform/via-camera.c +2 -0

 #include <asm/olpc.h>
+#endif
 
 #include "via-camera.h"
 

@@ -1283,6 +1286,11 @@ static bool viacam_serial_is_enabled(void)
 	struct pci_bus *pbus = pci_find_bus(0, 0);
 	u8 cbyte;
 
+#ifdef CONFIG_FB_VIA  

ditto

Quoted 95 lines

drivers/media/platform/via-camera.c +5 -1

+	if (!machine_is_olpc())
+		return false;
+#endif
+
 	if (!pbus)
 		return false;
 	pci_bus_read_config_byte(pbus, VIACAM_SERIAL_DEVFN,

@@ -1343,7 +1351,7 @@ static int viacam_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	if (machine_is_olpc() && viacam_serial_is_enabled())
+	if (viacam_serial_is_enabled())
 		return -EBUSY;
 
 	/*

include/linux/via-core.h +17 -0

index 9c21cdf3e3b3..ced4419baef8 100644
@@ -70,8 +70,12 @@ struct viafb_pm_hooks {
 	void *private;
 };
 
+#ifdef CONFIG_FB_VIA
 void viafb_pm_register(struct viafb_pm_hooks *hooks);
 void viafb_pm_unregister(struct viafb_pm_hooks *hooks);
+#else
+static inline void viafb_pm_register(struct viafb_pm_hooks *hooks) {}
+#endif /* CONFIG_FB_VIA */
 #endif /* CONFIG_PM */
 
 /*

@@ -113,8 +117,13 @@ struct viafb_dev {
  * Interrupt management.
  */
 
+#ifdef CONFIG_FB_VIA
 void viafb_irq_enable(u32 mask);
 void viafb_irq_disable(u32 mask);
+#else
+static inline void viafb_irq_enable(u32 mask) {}
+static inline void viafb_irq_disable(u32 mask) {}
+#endif
 
 /*
  * The global interrupt control register and its bits.

@@ -157,10 +166,18 @@ void viafb_irq_disable(u32 mask);
 /*
  * DMA management.
  */
+#ifdef CONFIG_FB_VIA
 int viafb_request_dma(void);
 void viafb_release_dma(void);
 /* void viafb_dma_copy_out(unsigned int offset, dma_addr_t paddr, int len); */
 int viafb_dma_copy_out_sg(unsigned int offset, struct scatterlist *sg, int nsg);
+#else
+static inline int viafb_request_dma(void) { return 0; }
+static inline void viafb_release_dma(void) {}
+static inline int viafb_dma_copy_out_sg(unsigned int offset,
+					struct scatterlist *sg, int nsg)
+{ return 0; }
+#endif
 
 /*
  * DMA Controller registers.

include/linux/via-gpio.h +4 -0

index 8281aea3dd6d..b5a96cf7a874 100644
@@ -8,7 +8,11 @@
 #ifndef __VIA_GPIO_H__
 #define __VIA_GPIO_H__
 
+#ifdef CONFIG_FB_VIA
 extern int viafb_gpio_lookup(const char *name);
 extern int viafb_gpio_init(void);
 extern void viafb_gpio_exit(void);
+#else
+static inline int viafb_gpio_lookup(const char *name) { return 0; }
+#endif
 #endif

include/linux/via_i2c.h +1 -0

index 44532e468c05..209bff950e22 100644
@@ -32,6 +32,7 @@ struct via_i2c_stuff {
 };
 
 
+#ifdef CONFIG_FB_VIA
 int viafb_i2c_readbyte(u8 adap, u8 slave_addr, u8 index, u8 *pdata);
 int viafb_i2c_writebyte(u8 adap, u8 slave_addr, u8 index, u8 data);
 int viafb_i2c_readbytes(u8 adap, u8 slave_addr, u8 index, u8 *buff, int buff_len);

include/linux/via_i2c.h struct i2c_adapter *viafb_find_i2c_adapter(enum viafb_i2c_adap which); · line 48

Quoted 9 lines

include/linux/via_i2c.h +5 -0

@@ -39,4 +40,9 @@ struct i2c_adapter *viafb_find_i2c_adapter(enum viafb_i2c_adap which);
 
 extern int viafb_i2c_init(void);
 extern void viafb_i2c_exit(void);
+#else
+static inline
+struct i2c_adapter *viafb_find_i2c_adapter(enum viafb_i2c_adap which)
+{ return NULL; }
+#endif
 #endif /* __VIA_I2C_H__ */  

How's about just allowing COMPILE_TEST for FB_VIA instead of adding all these stubs?

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] video: fbdev: via: allow COMPILE_TEST build

This patch allows viafb driver to be build on !X86 archs using COMPILE_TEST config option.

Since via-camera driver (VIDEO_VIA_CAMERA) depends on viafb it also needs a little fixup.

Cc Florian Tobias Schandinat <[email protected]>

Cc Mauro Carvalho Chehab <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

---
 drivers/media/platform/via-camera.c |    5 +++++
 drivers/video/fbdev/Kconfig         |    2 +-
 drivers/video/fbdev/via/global.h    |    6 ++++++
 drivers/video/fbdev/via/hw.c        |    1 -
 drivers/video/fbdev/via/via-core.c  |    1 -
 drivers/video/fbdev/via/via_clock.c |    2 +-
 drivers/video/fbdev/via/viafbdev.c  |    1 -
 7 files changed, 13 insertions(+), 5 deletions(-)

Index: b/drivers/media/platform/via-camera.c
===================================================================

drivers/media/platform/via-camera.c +5 -0

@@ -27,7 +27,12 @@
 #include <linux/via-core.h>
 #include <linux/via-gpio.h>
 #include <linux/via_i2c.h>
+
+#ifdef CONFIG_X86
 #include <asm/olpc.h>
+#else
+#define machine_is_olpc(x) 0
+#endif
 
 #include "via-camera.h"
 

Index: b/drivers/video/fbdev/Kconfig
===================================================================

drivers/video/fbdev/Kconfig +1 -1

@@ -1437,7 +1437,7 @@ config FB_SIS_315
 
 config FB_VIA
        tristate "VIA UniChrome (Pro) and Chrome9 display support"
-       depends on FB && PCI && X86 && GPIOLIB && I2C
+       depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
        select FB_CFB_FILLRECT
        select FB_CFB_COPYAREA
        select FB_CFB_IMAGEBLIT

Index: b/drivers/video/fbdev/via/global.h
===================================================================

drivers/video/fbdev/via/global.h +6 -0

@@ -33,6 +33,12 @@
 #include <linux/console.h>
 #include <linux/timer.h>
 
+#ifdef CONFIG_X86
+#include <asm/olpc.h>
+#else
+#define machine_is_olpc(x) 0
+#endif
+
 #include "debug.h"
 
 #include "viafbdev.h"

Index: b/drivers/video/fbdev/via/hw.c
===================================================================

drivers/video/fbdev/via/hw.c +0 -1

@@ -20,7 +20,6 @@
  */
 
 #include <linux/via-core.h>
-#include <asm/olpc.h>
 #include "global.h"
 #include "via_clock.h"
 

Index: b/drivers/video/fbdev/via/via-core.c
===================================================================

drivers/video/fbdev/via/via-core.c +0 -1

@@ -17,7 +17,6 @@
 #include <linux/platform_device.h>
 #include <linux/list.h>
 #include <linux/pm.h>
-#include <asm/olpc.h>
 
 /*
  * The default port config.

Index: b/drivers/video/fbdev/via/via_clock.c
===================================================================

drivers/video/fbdev/via/via_clock.c +1 -1

@@ -25,7 +25,7 @@
 
 #include <linux/kernel.h>
 #include <linux/via-core.h>
-#include <asm/olpc.h>
+
 #include "via_clock.h"
 #include "global.h"
 #include "debug.h"

Index: b/drivers/video/fbdev/via/viafbdev.c
===================================================================

How's about just allowing COMPILE_TEST for FB_VIA instead of adding all these stubs?

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] video: fbdev: via: allow COMPILE_TEST build

This patch allows viafb driver to be build on !X86 archs using COMPILE_TEST config option.

Since via-camera driver (VIDEO_VIA_CAMERA) depends on viafb it also needs a little fixup.

Cc Florian Tobias Schandinat <[email protected]>

Cc Mauro Carvalho Chehab <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

---
 drivers/media/platform/via-camera.c |    5 +++++
 drivers/video/fbdev/Kconfig         |    2 +-
 drivers/video/fbdev/via/global.h    |    6 ++++++
 drivers/video/fbdev/via/hw.c        |    1 -
 drivers/video/fbdev/via/via-core.c  |    1 -
 drivers/video/fbdev/via/via_clock.c |    2 +-
 drivers/video/fbdev/via/viafbdev.c  |    1 -
 7 files changed, 13 insertions(+), 5 deletions(-)

Index: b/drivers/media/platform/via-camera.c
=================================> --- a/drivers/media/platform/via-camera.c 2018-04-23 13:46:37.000000000 +0200
+++ b/drivers/media/platform/via-camera.c 2018-04-23 14:01:07.873322815 +0200

drivers/media/platform/via-camera.c +5 -0

@@ -27,7 +27,12 @@
 #include <linux/via-core.h>
 #include <linux/via-gpio.h>
 #include <linux/via_i2c.h>
+
+#ifdef CONFIG_X86
 #include <asm/olpc.h>
+#else
+#define machine_is_olpc(x) 0
+#endif
 
 #include "via-camera.h"
 

Index: b/drivers/video/fbdev/Kconfig
=================================> --- a/drivers/video/fbdev/Kconfig 2018-04-10 12:34:26.618867549 +0200
+++ b/drivers/video/fbdev/Kconfig 2018-04-23 13:55:41.389314593 +0200

drivers/video/fbdev/Kconfig +1 -1

@@ -1437,7 +1437,7 @@ config FB_SIS_315
 
 config FB_VIA
        tristate "VIA UniChrome (Pro) and Chrome9 display support"
-       depends on FB && PCI && X86 && GPIOLIB && I2C
+       depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
        select FB_CFB_FILLRECT
        select FB_CFB_COPYAREA
        select FB_CFB_IMAGEBLIT

Index: b/drivers/video/fbdev/via/global.h
=================================> --- a/drivers/video/fbdev/via/global.h 2017-10-18 14:35:22.079448310 +0200
+++ b/drivers/video/fbdev/via/global.h 2018-04-23 13:52:57.121310456 +0200

drivers/video/fbdev/via/global.h +6 -0

@@ -33,6 +33,12 @@
 #include <linux/console.h>
 #include <linux/timer.h>
 
+#ifdef CONFIG_X86
+#include <asm/olpc.h>
+#else
+#define machine_is_olpc(x) 0
+#endif
+
 #include "debug.h"
 
 #include "viafbdev.h"

Index: b/drivers/video/fbdev/via/hw.c
=================================> --- a/drivers/video/fbdev/via/hw.c 2017-10-18 14:35:22.079448310 +0200
+++ b/drivers/video/fbdev/via/hw.c 2018-04-23 13:54:24.881312666 +0200

drivers/video/fbdev/via/hw.c +0 -1

@@ -20,7 +20,6 @@
  */
 
 #include <linux/via-core.h>
-#include <asm/olpc.h>
 #include "global.h"
 #include "via_clock.h"
 

Index: b/drivers/video/fbdev/via/via-core.c
=================================> --- a/drivers/video/fbdev/via/via-core.c 2017-11-22 14:11:59.852728679 +0100
+++ b/drivers/video/fbdev/via/via-core.c 2018-04-23 13:53:24.893311156 +0200

drivers/video/fbdev/via/via-core.c +0 -1

@@ -17,7 +17,6 @@
 #include <linux/platform_device.h>
 #include <linux/list.h>
 #include <linux/pm.h>
-#include <asm/olpc.h>
 
 /*
  * The default port config.

Index: b/drivers/video/fbdev/via/via_clock.c
=================================> --- a/drivers/video/fbdev/via/via_clock.c 2017-10-18 14:35:22.083448309 +0200
+++ b/drivers/video/fbdev/via/via_clock.c 2018-04-23 13:53:45.389311672 +0200

drivers/video/fbdev/via/via_clock.c +1 -1

@@ -25,7 +25,7 @@
 
 #include <linux/kernel.h>
 #include <linux/via-core.h>
-#include <asm/olpc.h>
+
 #include "via_clock.h"
 #include "global.h"
 #include "debug.h"

Index: b/drivers/video/fbdev/via/viafbdev.c
=================================> --- a/drivers/video/fbdev/via/viafbdev.c 2017-11-22 14:11:59.852728679 +0100
+++ b/drivers/video/fbdev/via/viafbdev.c 2018-04-23 13:53:55.325311922 +0200

Em Mon, 23 Apr 2018 14:19:31 +0200
Bartlomiej Zolnierkiewicz <[email protected]> escreveu:

Quoted 2 lines

How's about just allowing COMPILE_TEST for FB_VIA instead of adding all these stubs?

Works for me.

Do you want to apply it via your tree or via the media one?

If you prefer to apply on yours:

Reviewed-by Mauro Carvalho Chehab <[email protected]>

Quoted 9 lines · Mauro Carvalho Chehab

Em Mon, 23 Apr 2018 14:19:31 +0200
Bartlomiej Zolnierkiewicz <[email protected]> escreveu:

Quoted 2 lines

How's about just allowing COMPILE_TEST for FB_VIA instead of adding all these stubs?

Works for me.

Quoted 5 lines

Do you want to apply it via your tree or via the media one?

If you prefer to apply on yours:

Reviewed-by Mauro Carvalho Chehab <[email protected]>

Thanks, I'll apply it to my tree later.