[PATCH 0/7] Enable most media drivers to build on ARM

[PATCH 0/7] Enable most media drivers to build on ARM

[Mauro Carvalho Chehab]

Right now, all media drivers build successfully with COMPILE_TEST on x86,
on both i386 and x86_64. Yet, several drivers there don't build on other
archs.

I don't need myself to build all drivers outside x86, but others could
find it useful. It also relps spreading COMPILE_TEST builds, with sounds
a good idea, as more developers may be seeing issues and submiting 
us patches.

So, this patch series makes most of them to be built elsewhere (tested
only with ARM with allyesconfig). The only two media drivers that don't build 
on such conditions are:

1) media/staging/atomisp: it uses several ACPI bits that no other media
driver requires (including Intel IPU3);

2) radio-miropcm20: This device depnds on ISA_DMA_API, with is available only
for a few non-Intel architectures.

In other words, the following symbols aren't enabled with allyesconfig:

	INTEL_ATOMISP VIDEO_ATOMISP
	VIDEO_ATOMISP_MSRLIST_HELPER VIDEO_ATOMISP_MT9M114
	VIDEO_ATOMISP_GC0310  VIDEO_ATOMISP_GC2235 
	VIDEO_ATOMISP_OV2722 VIDEO_ATOMISP_OV5693
	VIDEO_ATOMISP_OV2680 VIDEO_ATOMISP_LM3554
	RADIO_MIROPCM20

All patches in this series are available at:

	https://git.linuxtv.org/mchehab/experimental.git/log/?h=compile_test_v7

Mauro Carvalho Chehab (7):
  asm-generic, media: allow COMPILE_TEST with virt_to_bus
  media: meye: allow building it with COMPILE_TEST on non-x86
  media: rc: allow build pnp-dependent drivers with COMPILE_TEST
  media: ipu3: allow building it with COMPILE_TEST on non-x86 archs
  omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
  media: omap2: allow building it with COMPILE_TEST && DRM_OMAP
  media: via-camera: allow build on non-x86 archs with COMPILE_TEST

 drivers/media/pci/intel/ipu3/Kconfig |  3 +-
 drivers/media/pci/meye/Kconfig       |  3 +-
 drivers/media/pci/sta2x11/Kconfig    |  4 +--
 drivers/media/pci/zoran/Kconfig      |  3 +-
 drivers/media/platform/Kconfig       |  2 +-
 drivers/media/platform/omap/Kconfig  |  3 +-
 drivers/media/platform/via-camera.c  | 10 ++++++-
 drivers/media/rc/Kconfig             | 10 +++----
 include/asm-generic/io.h             |  2 +-
 include/linux/sony-laptop.h          |  4 +++
 include/linux/via-core.h             | 17 ++++++++++++
 include/linux/via-gpio.h             |  4 +++
 include/linux/via_i2c.h              |  5 ++++
 include/video/omapfb_dss.h           | 54 ++++++++++++++++++++++++++++++++++--
 14 files changed, 107 insertions(+), 17 deletions(-)

-- 
2.14.3

[PATCH 0/7] Enable most media drivers to build on ARM

[Mauro Carvalho Chehab]

Right now, all media drivers build successfully with COMPILE_TEST on x86,
on both i386 and x86_64. Yet, several drivers there don't build on other
archs.

I don't need myself to build all drivers outside x86, but others could
find it useful. It also relps spreading COMPILE_TEST builds, with sounds
a good idea, as more developers may be seeing issues and submiting 
us patches.

So, this patch series makes most of them to be built elsewhere (tested
only with ARM with allyesconfig). The only two media drivers that don't build 
on such conditions are:

1) media/staging/atomisp: it uses several ACPI bits that no other media
driver requires (including Intel IPU3);

2) radio-miropcm20: This device depnds on ISA_DMA_API, with is available only
for a few non-Intel architectures.

In other words, the following symbols aren't enabled with allyesconfig:

	INTEL_ATOMISP VIDEO_ATOMISP
	VIDEO_ATOMISP_MSRLIST_HELPER VIDEO_ATOMISP_MT9M114
	VIDEO_ATOMISP_GC0310  VIDEO_ATOMISP_GC2235 
	VIDEO_ATOMISP_OV2722 VIDEO_ATOMISP_OV5693
	VIDEO_ATOMISP_OV2680 VIDEO_ATOMISP_LM3554
	RADIO_MIROPCM20

All patches in this series are available at:

	https://git.linuxtv.org/mchehab/experimental.git/log/?h=compile_test_v7

Mauro Carvalho Chehab (7):
  asm-generic, media: allow COMPILE_TEST with virt_to_bus
  media: meye: allow building it with COMPILE_TEST on non-x86
  media: rc: allow build pnp-dependent drivers with COMPILE_TEST
  media: ipu3: allow building it with COMPILE_TEST on non-x86 archs
  omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
  media: omap2: allow building it with COMPILE_TEST && DRM_OMAP
  media: via-camera: allow build on non-x86 archs with COMPILE_TEST

 drivers/media/pci/intel/ipu3/Kconfig |  3 +-
 drivers/media/pci/meye/Kconfig       |  3 +-
 drivers/media/pci/sta2x11/Kconfig    |  4 +--
 drivers/media/pci/zoran/Kconfig      |  3 +-
 drivers/media/platform/Kconfig       |  2 +-
 drivers/media/platform/omap/Kconfig  |  3 +-
 drivers/media/platform/via-camera.c  | 10 ++++++-
 drivers/media/rc/Kconfig             | 10 +++----
 include/asm-generic/io.h             |  2 +-
 include/linux/sony-laptop.h          |  4 +++
 include/linux/via-core.h             | 17 ++++++++++++
 include/linux/via-gpio.h             |  4 +++
 include/linux/via_i2c.h              |  5 ++++
 include/video/omapfb_dss.h           | 54 ++++++++++++++++++++++++++++++++++--
 14 files changed, 107 insertions(+), 17 deletions(-)

-- 
2.14.3

[PATCH 0/7] Enable most media drivers to build on ARM

[Mauro Carvalho Chehab]

Right now, all media drivers build successfully with COMPILE_TEST on x86,
on both i386 and x86_64. Yet, several drivers there don't build on other
archs.

I don't need myself to build all drivers outside x86, but others could
find it useful. It also relps spreading COMPILE_TEST builds, with sounds
a good idea, as more developers may be seeing issues and submiting 
us patches.

So, this patch series makes most of them to be built elsewhere (tested
only with ARM with allyesconfig). The only two media drivers that don't build 
on such conditions are:

1) media/staging/atomisp: it uses several ACPI bits that no other media
driver requires (including Intel IPU3);

2) radio-miropcm20: This device depnds on ISA_DMA_API, with is available only
for a few non-Intel architectures.

In other words, the following symbols aren't enabled with allyesconfig:

	INTEL_ATOMISP VIDEO_ATOMISP
	VIDEO_ATOMISP_MSRLIST_HELPER VIDEO_ATOMISP_MT9M114
	VIDEO_ATOMISP_GC0310  VIDEO_ATOMISP_GC2235 
	VIDEO_ATOMISP_OV2722 VIDEO_ATOMISP_OV5693
	VIDEO_ATOMISP_OV2680 VIDEO_ATOMISP_LM3554
	RADIO_MIROPCM20

All patches in this series are available at:

	https://git.linuxtv.org/mchehab/experimental.git/log/?h=compile_test_v7

Mauro Carvalho Chehab (7):
  asm-generic, media: allow COMPILE_TEST with virt_to_bus
  media: meye: allow building it with COMPILE_TEST on non-x86
  media: rc: allow build pnp-dependent drivers with COMPILE_TEST
  media: ipu3: allow building it with COMPILE_TEST on non-x86 archs
  omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
  media: omap2: allow building it with COMPILE_TEST && DRM_OMAP
  media: via-camera: allow build on non-x86 archs with COMPILE_TEST

 drivers/media/pci/intel/ipu3/Kconfig |  3 +-
 drivers/media/pci/meye/Kconfig       |  3 +-
 drivers/media/pci/sta2x11/Kconfig    |  4 +--
 drivers/media/pci/zoran/Kconfig      |  3 +-
 drivers/media/platform/Kconfig       |  2 +-
 drivers/media/platform/omap/Kconfig  |  3 +-
 drivers/media/platform/via-camera.c  | 10 ++++++-
 drivers/media/rc/Kconfig             | 10 +++----
 include/asm-generic/io.h             |  2 +-
 include/linux/sony-laptop.h          |  4 +++
 include/linux/via-core.h             | 17 ++++++++++++
 include/linux/via-gpio.h             |  4 +++
 include/linux/via_i2c.h              |  5 ++++
 include/video/omapfb_dss.h           | 54 ++++++++++++++++++++++++++++++++++--
 14 files changed, 107 insertions(+), 17 deletions(-)

-- 
2.14.3

[PATCH 0/7] Enable most media drivers to build on ARM

[Mauro Carvalho Chehab]

Right now, all media drivers build successfully with COMPILE_TEST on x86,
on both i386 and x86_64. Yet, several drivers there don't build on other
archs.

I don't need myself to build all drivers outside x86, but others could
find it useful. It also relps spreading COMPILE_TEST builds, with sounds
a good idea, as more developers may be seeing issues and submiting 
us patches.

So, this patch series makes most of them to be built elsewhere (tested
only with ARM with allyesconfig). The only two media drivers that don't build 
on such conditions are:

1) media/staging/atomisp: it uses several ACPI bits that no other media
driver requires (including Intel IPU3);

2) radio-miropcm20: This device depnds on ISA_DMA_API, with is available only
for a few non-Intel architectures.

In other words, the following symbols aren't enabled with allyesconfig:

	INTEL_ATOMISP VIDEO_ATOMISP
	VIDEO_ATOMISP_MSRLIST_HELPER VIDEO_ATOMISP_MT9M114
	VIDEO_ATOMISP_GC0310  VIDEO_ATOMISP_GC2235 
	VIDEO_ATOMISP_OV2722 VIDEO_ATOMISP_OV5693
	VIDEO_ATOMISP_OV2680 VIDEO_ATOMISP_LM3554
	RADIO_MIROPCM20

All patches in this series are available at:

	https://git.linuxtv.org/mchehab/experimental.git/log/?h=compile_test_v7

Mauro Carvalho Chehab (7):
  asm-generic, media: allow COMPILE_TEST with virt_to_bus
  media: meye: allow building it with COMPILE_TEST on non-x86
  media: rc: allow build pnp-dependent drivers with COMPILE_TEST
  media: ipu3: allow building it with COMPILE_TEST on non-x86 archs
  omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
  media: omap2: allow building it with COMPILE_TEST && DRM_OMAP
  media: via-camera: allow build on non-x86 archs with COMPILE_TEST

 drivers/media/pci/intel/ipu3/Kconfig |  3 +-
 drivers/media/pci/meye/Kconfig       |  3 +-
 drivers/media/pci/sta2x11/Kconfig    |  4 +--
 drivers/media/pci/zoran/Kconfig      |  3 +-
 drivers/media/platform/Kconfig       |  2 +-
 drivers/media/platform/omap/Kconfig  |  3 +-
 drivers/media/platform/via-camera.c  | 10 ++++++-
 drivers/media/rc/Kconfig             | 10 +++----
 include/asm-generic/io.h             |  2 +-
 include/linux/sony-laptop.h          |  4 +++
 include/linux/via-core.h             | 17 ++++++++++++
 include/linux/via-gpio.h             |  4 +++
 include/linux/via_i2c.h              |  5 ++++
 include/video/omapfb_dss.h           | 54 ++++++++++++++++++++++++++++++++++--
 14 files changed, 107 insertions(+), 17 deletions(-)

-- 
2.14.3


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[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.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
 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(-)

diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig
index 7af3f1cbcea8..fb4b4c8ac430 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -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
diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig
index 39ec35bd21a5..5d2678a9e310 100644
--- a/drivers/media/pci/zoran/Kconfig
+++ b/drivers/media/pci/zoran/Kconfig
@@ -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
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 66d1d45fa2e1..f448129ad15c 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -1068,7 +1068,7 @@ static inline void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
 }
 #endif
 
-#ifdef CONFIG_VIRT_TO_BUS
+#if defined(CONFIG_VIRT_TO_BUS) || defined(CONFIG_COMPILE_TEST)
 #ifndef virt_to_bus
 static inline unsigned long virt_to_bus(void *address)
 {
-- 
2.14.3

[PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[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.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
 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(-)

diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig
index 7af3f1cbcea8..fb4b4c8ac430 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -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
diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig
index 39ec35bd21a5..5d2678a9e310 100644
--- a/drivers/media/pci/zoran/Kconfig
+++ b/drivers/media/pci/zoran/Kconfig
@@ -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
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 66d1d45fa2e1..f448129ad15c 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -1068,7 +1068,7 @@ static inline void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
 }
 #endif
 
-#ifdef CONFIG_VIRT_TO_BUS
+#if defined(CONFIG_VIRT_TO_BUS) || defined(CONFIG_COMPILE_TEST)
 #ifndef virt_to_bus
 static inline unsigned long virt_to_bus(void *address)
 {
-- 
2.14.3

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[Geert Uytterhoeven]

Hi Mauro,

On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
> 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 <mchehab@s-opensource.com>

Thanks for your patch!

I guess this will cause the kernel to crash if I insert an STA2X11 or Zoran PCI
card in a non-VIRT_TO_BUS machine and boot an all{mod,yes}config kernel?

IMHO dummies are fine if they return error codes, not it they can cause
crashes.

> ---
>  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(-)
>
> diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig
> index 7af3f1cbcea8..fb4b4c8ac430 100644
> --- a/drivers/media/pci/sta2x11/Kconfig
> +++ b/drivers/media/pci/sta2x11/Kconfig
> @@ -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
> diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig
> index 39ec35bd21a5..5d2678a9e310 100644
> --- a/drivers/media/pci/zoran/Kconfig
> +++ b/drivers/media/pci/zoran/Kconfig
> @@ -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
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 66d1d45fa2e1..f448129ad15c 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -1068,7 +1068,7 @@ static inline void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
>  }
>  #endif
>
> -#ifdef CONFIG_VIRT_TO_BUS
> +#if defined(CONFIG_VIRT_TO_BUS) || defined(CONFIG_COMPILE_TEST)
>  #ifndef virt_to_bus
>  static inline unsigned long virt_to_bus(void *address)
>  {

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[Geert Uytterhoeven]

Hi Mauro,

On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
> 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 <mchehab@s-opensource.com>

Thanks for your patch!

I guess this will cause the kernel to crash if I insert an STA2X11 or Zoran PCI
card in a non-VIRT_TO_BUS machine and boot an all{mod,yes}config kernel?

IMHO dummies are fine if they return error codes, not it they can cause
crashes.

> ---
>  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(-)
>
> diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig
> index 7af3f1cbcea8..fb4b4c8ac430 100644
> --- a/drivers/media/pci/sta2x11/Kconfig
> +++ b/drivers/media/pci/sta2x11/Kconfig
> @@ -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
> diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig
> index 39ec35bd21a5..5d2678a9e310 100644
> --- a/drivers/media/pci/zoran/Kconfig
> +++ b/drivers/media/pci/zoran/Kconfig
> @@ -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
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 66d1d45fa2e1..f448129ad15c 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -1068,7 +1068,7 @@ static inline void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
>  }
>  #endif
>
> -#ifdef CONFIG_VIRT_TO_BUS
> +#if defined(CONFIG_VIRT_TO_BUS) || defined(CONFIG_COMPILE_TEST)
>  #ifndef virt_to_bus
>  static inline unsigned long virt_to_bus(void *address)
>  {

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[Arnd Bergmann]

On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
> 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 <mchehab@s-opensource.com>

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.

      Arnd

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[Arnd Bergmann]

On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
> 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 <mchehab@s-opensource.com>

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.

      Arnd

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[Mauro Carvalho Chehab]

Em Tue, 24 Apr 2018 09:55:55 +0200
Arnd Bergmann <arnd@arndb.de> escreveu:

> On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab
> <mchehab@s-opensource.com> wrote:
> > 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 <mchehab@s-opensource.com>  
> 
> 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.

I see. I will drop this patch then. 

I might eventually try to fix the Zoran driver some day, with is the
only media driver that uses virt_to_bus(), if I switch some day my 
builds to default to ARM, but such task has very low priority to me.

Thanks,
Mauro

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

[Mauro Carvalho Chehab]

Em Tue, 24 Apr 2018 09:55:55 +0200
Arnd Bergmann <arnd@arndb.de> escreveu:

> On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab
> <mchehab@s-opensource.com> wrote:
> > 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 <mchehab@s-opensource.com>  
> 
> 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.

I see. I will drop this patch then. 

I might eventually try to fix the Zoran driver some day, with is the
only media driver that uses virt_to_bus(), if I switch some day my 
builds to default to ARM, but such task has very low priority to me.

Thanks,
Mauro

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[PATCH 2/7] media: meye: allow building it with COMPILE_TEST on non-x86

[Mauro Carvalho Chehab]

This driver depends on sony-laptop driver, but this is available
only for x86. So, add a stub function, in order to allow building
it on non-x86 too.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
 drivers/media/pci/meye/Kconfig | 3 ++-
 include/linux/sony-laptop.h    | 4 ++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/meye/Kconfig b/drivers/media/pci/meye/Kconfig
index b4bf848be5a0..2e60334ffef5 100644
--- a/drivers/media/pci/meye/Kconfig
+++ b/drivers/media/pci/meye/Kconfig
@@ -1,6 +1,7 @@
 config VIDEO_MEYE
 	tristate "Sony Vaio Picturebook Motion Eye Video For Linux"
-	depends on PCI && SONY_LAPTOP && VIDEO_V4L2
+	depends on PCI && VIDEO_V4L2
+	depends on SONY_LAPTOP || COMPILE_TEST
 	---help---
 	  This is the video4linux driver for the Motion Eye camera found
 	  in the Vaio Picturebook laptops. Please read the material in
diff --git a/include/linux/sony-laptop.h b/include/linux/sony-laptop.h
index 1a4b77317fa1..72a2e74c62b2 100644
--- a/include/linux/sony-laptop.h
+++ b/include/linux/sony-laptop.h
@@ -28,7 +28,11 @@
 #define SONY_PIC_COMMAND_GETCAMERAROMVERSION	18	/* obsolete */
 #define SONY_PIC_COMMAND_GETCAMERAREVISION	19	/* obsolete */
 
+#ifdef CONFIG_SONY_LAPTOP
 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__ */
 
-- 
2.14.3

Re: [PATCH 2/7] media: meye: allow building it with COMPILE_TEST on non-x86

[Andy Shevchenko]

On Fri, Apr 20, 2018 at 8:42 PM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
> This driver depends on sony-laptop driver, but this is available
> only for x86. So, add a stub function, in order to allow building
> it on non-x86 too.

> --- a/include/linux/sony-laptop.h
> +++ b/include/linux/sony-laptop.h
> @@ -28,7 +28,11 @@
>  #define SONY_PIC_COMMAND_GETCAMERAROMVERSION   18      /* obsolete */
>  #define SONY_PIC_COMMAND_GETCAMERAREVISION     19      /* obsolete */
>
> +#ifdef CONFIG_SONY_LAPTOP

IS_ENABLED(), IS_BUILTIN() ?

>  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__ */



-- 
With Best Regards,
Andy Shevchenko

[PATCH 2/7 v2] media: meye: allow building it with COMPILE_TEST on non-x86

[Mauro Carvalho Chehab]

From: Mauro Carvalho Chehab <mchehab@s-opensource.com>

This driver depends on sony-laptop driver, but this is available
only for x86. So, add a stub function, in order to allow building
it on non-x86 too.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
 drivers/media/pci/meye/Kconfig | 3 ++-
 include/linux/sony-laptop.h    | 4 ++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/meye/Kconfig b/drivers/media/pci/meye/Kconfig
index b4bf848be5a0..2e60334ffef5 100644
--- a/drivers/media/pci/meye/Kconfig
+++ b/drivers/media/pci/meye/Kconfig
@@ -1,6 +1,7 @@
 config VIDEO_MEYE
 	tristate "Sony Vaio Picturebook Motion Eye Video For Linux"
-	depends on PCI && SONY_LAPTOP && VIDEO_V4L2
+	depends on PCI && VIDEO_V4L2
+	depends on SONY_LAPTOP || COMPILE_TEST
 	---help---
 	  This is the video4linux driver for the Motion Eye camera found
 	  in the Vaio Picturebook laptops. Please read the material in
diff --git a/include/linux/sony-laptop.h b/include/linux/sony-laptop.h
index 1a4b77317fa1..374d0fdb0743 100644
--- a/include/linux/sony-laptop.h
+++ b/include/linux/sony-laptop.h
@@ -28,7 +28,11 @@
 #define SONY_PIC_COMMAND_GETCAMERAROMVERSION	18	/* obsolete */
 #define SONY_PIC_COMMAND_GETCAMERAREVISION	19	/* obsolete */
 
+#if IS_ENABLED(CONFIG_SONY_LAPTOP)
 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__ */
 
-- 
2.17.0

[PATCH 3/7] media: rc: allow build pnp-dependent drivers with COMPILE_TEST

[Mauro Carvalho Chehab]

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

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
 drivers/media/rc/Kconfig | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index eb2c3b6eca7f..9a3b66c6700c 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -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
-- 
2.14.3

Re: [PATCH 3/7] media: rc: allow build pnp-dependent drivers with COMPILE_TEST

[Sean Young]

On Fri, Apr 20, 2018 at 01:42:49PM -0400, Mauro Carvalho Chehab wrote:
> The pnp header already provide enough stub to build those
> drivers with COMPILE_TEST on non-x86 archs.

That's great, thanks.

Acked-by: Sean Young <sean@mess.org>

> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
>  drivers/media/rc/Kconfig | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index eb2c3b6eca7f..9a3b66c6700c 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -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
> -- 
> 2.14.3

[PATCH 4/7] media: ipu3: allow building it with COMPILE_TEST on non-x86 archs

[Mauro Carvalho Chehab]

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 <mchehab@s-opensource.com>
---
 drivers/media/pci/intel/ipu3/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig
index a82d3fe277d2..45cf99a512e4 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -2,10 +2,9 @@ config VIDEO_IPU3_CIO2
 	tristate "Intel ipu3-cio2 driver"
 	depends on VIDEO_V4L2 && PCI
 	depends on VIDEO_V4L2_SUBDEV_API
-	depends on X86 || COMPILE_TEST
+	depends on (X86 && ACPI) || COMPILE_TEST
 	depends on MEDIA_CONTROLLER
 	depends on HAS_DMA
-	depends on ACPI
 	select V4L2_FWNODE
 	select VIDEOBUF2_DMA_SG
 
-- 
2.14.3

Re: [PATCH 4/7] media: ipu3: allow building it with COMPILE_TEST on non-x86 archs

[Sakari Ailus]

On Fri, Apr 20, 2018 at 01:42:50PM -0400, Mauro Carvalho Chehab wrote:
> 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 <mchehab@s-opensource.com>

Thanks.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>

Feel free to take this through your tree.

-- 
Regards,

Sakari Ailus
sakari.ailus@linux.intel.com

[PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[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 <mchehab@s-opensource.com>
---
 include/video/omapfb_dss.h | 54 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
index 1d38901d599d..e9775144ff3b 100644
--- a/include/video/omapfb_dss.h
+++ b/include/video/omapfb_dss.h
@@ -774,6 +774,12 @@ struct omap_dss_driver {
 		const struct hdmi_avi_infoframe *avi);
 };
 
+#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
+
+typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
+
+#ifdef CONFIG_FB_OMAP2
+
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
@@ -785,7 +791,6 @@ void omapdss_unregister_display(struct omap_dss_device *dssdev);
 
 struct omap_dss_device *omap_dss_get_device(struct omap_dss_device *dssdev);
 void omap_dss_put_device(struct omap_dss_device *dssdev);
-#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
 struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
 struct omap_dss_device *omap_dss_find_device(void *data,
 		int (*match)(struct omap_dss_device *dssdev, void *data));
@@ -826,7 +831,6 @@ int omapdss_default_get_recommended_bpp(struct omap_dss_device *dssdev);
 void omapdss_default_get_timings(struct omap_dss_device *dssdev,
 		struct omap_video_timings *timings);
 
-typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 
@@ -856,5 +860,51 @@ omapdss_of_get_first_endpoint(const struct device_node *parent);
 
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node);
+#else
+
+static inline enum omapdss_version omapdss_get_version(void)
+{ return OMAPDSS_VER_UNKNOWN; };
+
+static inline bool omapdss_is_initialized(void)
+{ return false; };
+
+static inline int omap_dispc_register_isr(omap_dispc_isr_t isr,
+					  void *arg, u32 mask)
+{ return 0; };
+
+static inline int omap_dispc_unregister_isr(omap_dispc_isr_t isr,
+					    void *arg, u32 mask)
+{ return 0; };
+
+static inline struct omap_dss_device
+*omap_dss_get_device(struct omap_dss_device *dssdev)
+{ return NULL; };
+
+static inline struct omap_dss_device
+*omap_dss_get_next_device(struct omap_dss_device *from)
+{return NULL; };
+
+static inline void omap_dss_put_device(struct omap_dss_device *dssdev) {};
+
+static inline int omapdss_compat_init(void)
+{ return 0; };
+
+static inline void omapdss_compat_uninit(void) {};
+
+static inline int omap_dss_get_num_overlay_managers(void)
+{ return 0; };
+
+static inline struct omap_overlay_manager *omap_dss_get_overlay_manager(int num)
+{ return NULL; };
+
+static inline int omap_dss_get_num_overlays(void)
+{ return 0; };
+
+static inline struct omap_overlay *omap_dss_get_overlay(int num)
+{ return NULL; };
+
+
+#endif /* FB_OMAP2 */
+
 
 #endif /* __OMAPFB_DSS_H */
-- 
2.14.3

[PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[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 <mchehab@s-opensource.com>
---
 include/video/omapfb_dss.h | 54 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
index 1d38901d599d..e9775144ff3b 100644
--- a/include/video/omapfb_dss.h
+++ b/include/video/omapfb_dss.h
@@ -774,6 +774,12 @@ struct omap_dss_driver {
 		const struct hdmi_avi_infoframe *avi);
 };
 
+#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
+
+typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
+
+#ifdef CONFIG_FB_OMAP2
+
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
@@ -785,7 +791,6 @@ void omapdss_unregister_display(struct omap_dss_device *dssdev);
 
 struct omap_dss_device *omap_dss_get_device(struct omap_dss_device *dssdev);
 void omap_dss_put_device(struct omap_dss_device *dssdev);
-#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
 struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
 struct omap_dss_device *omap_dss_find_device(void *data,
 		int (*match)(struct omap_dss_device *dssdev, void *data));
@@ -826,7 +831,6 @@ int omapdss_default_get_recommended_bpp(struct omap_dss_device *dssdev);
 void omapdss_default_get_timings(struct omap_dss_device *dssdev,
 		struct omap_video_timings *timings);
 
-typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 
@@ -856,5 +860,51 @@ omapdss_of_get_first_endpoint(const struct device_node *parent);
 
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node);
+#else
+
+static inline enum omapdss_version omapdss_get_version(void)
+{ return OMAPDSS_VER_UNKNOWN; };
+
+static inline bool omapdss_is_initialized(void)
+{ return false; };
+
+static inline int omap_dispc_register_isr(omap_dispc_isr_t isr,
+					  void *arg, u32 mask)
+{ return 0; };
+
+static inline int omap_dispc_unregister_isr(omap_dispc_isr_t isr,
+					    void *arg, u32 mask)
+{ return 0; };
+
+static inline struct omap_dss_device
+*omap_dss_get_device(struct omap_dss_device *dssdev)
+{ return NULL; };
+
+static inline struct omap_dss_device
+*omap_dss_get_next_device(struct omap_dss_device *from)
+{return NULL; };
+
+static inline void omap_dss_put_device(struct omap_dss_device *dssdev) {};
+
+static inline int omapdss_compat_init(void)
+{ return 0; };
+
+static inline void omapdss_compat_uninit(void) {};
+
+static inline int omap_dss_get_num_overlay_managers(void)
+{ return 0; };
+
+static inline struct omap_overlay_manager *omap_dss_get_overlay_manager(int num)
+{ return NULL; };
+
+static inline int omap_dss_get_num_overlays(void)
+{ return 0; };
+
+static inline struct omap_overlay *omap_dss_get_overlay(int num)
+{ return NULL; };
+
+
+#endif /* FB_OMAP2 */
+
 
 #endif /* __OMAPFB_DSS_H */
-- 
2.14.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[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 <mchehab@s-opensource.com>
---
 include/video/omapfb_dss.h | 54 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
index 1d38901d599d..e9775144ff3b 100644
--- a/include/video/omapfb_dss.h
+++ b/include/video/omapfb_dss.h
@@ -774,6 +774,12 @@ struct omap_dss_driver {
 		const struct hdmi_avi_infoframe *avi);
 };
 
+#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
+
+typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
+
+#ifdef CONFIG_FB_OMAP2
+
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
@@ -785,7 +791,6 @@ void omapdss_unregister_display(struct omap_dss_device *dssdev);
 
 struct omap_dss_device *omap_dss_get_device(struct omap_dss_device *dssdev);
 void omap_dss_put_device(struct omap_dss_device *dssdev);
-#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
 struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
 struct omap_dss_device *omap_dss_find_device(void *data,
 		int (*match)(struct omap_dss_device *dssdev, void *data));
@@ -826,7 +831,6 @@ int omapdss_default_get_recommended_bpp(struct omap_dss_device *dssdev);
 void omapdss_default_get_timings(struct omap_dss_device *dssdev,
 		struct omap_video_timings *timings);
 
-typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 
@@ -856,5 +860,51 @@ omapdss_of_get_first_endpoint(const struct device_node *parent);
 
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node);
+#else
+
+static inline enum omapdss_version omapdss_get_version(void)
+{ return OMAPDSS_VER_UNKNOWN; };
+
+static inline bool omapdss_is_initialized(void)
+{ return false; };
+
+static inline int omap_dispc_register_isr(omap_dispc_isr_t isr,
+					  void *arg, u32 mask)
+{ return 0; };
+
+static inline int omap_dispc_unregister_isr(omap_dispc_isr_t isr,
+					    void *arg, u32 mask)
+{ return 0; };
+
+static inline struct omap_dss_device
+*omap_dss_get_device(struct omap_dss_device *dssdev)
+{ return NULL; };
+
+static inline struct omap_dss_device
+*omap_dss_get_next_device(struct omap_dss_device *from)
+{return NULL; };
+
+static inline void omap_dss_put_device(struct omap_dss_device *dssdev) {};
+
+static inline int omapdss_compat_init(void)
+{ return 0; };
+
+static inline void omapdss_compat_uninit(void) {};
+
+static inline int omap_dss_get_num_overlay_managers(void)
+{ return 0; };
+
+static inline struct omap_overlay_manager *omap_dss_get_overlay_manager(int num)
+{ return NULL; };
+
+static inline int omap_dss_get_num_overlays(void)
+{ return 0; };
+
+static inline struct omap_overlay *omap_dss_get_overlay(int num)
+{ return NULL; };
+
+
+#endif /* FB_OMAP2 */
+
 
 #endif /* __OMAPFB_DSS_H */
-- 
2.14.3

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> 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 <mchehab@s-opensource.com>

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")..

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

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> 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 <mchehab@s-opensource.com>

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")..

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

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> 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 <mchehab@s-opensource.com>

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")..

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

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:47:28 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > 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 <mchehab@s-opensource.com>  
> 
> 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")..

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.

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:47:28 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > 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 <mchehab@s-opensource.com>  
> 
> 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")..

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.

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:47:28 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > 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 <mchehab@s-opensource.com>  
> 
> 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")..

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.

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:47:28 +0200
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> 
> > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > 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 <mchehab@s-opensource.com>  
> > 
> > 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")..
> 
> 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.

I agree.

You can merge this patch through your tree with:

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:47:28 +0200
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> 
> > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > 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 <mchehab@s-opensource.com>  
> > 
> > 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")..
> 
> 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.

I agree.

You can merge this patch through your tree with:

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:47:28 +0200
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> 
> > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > 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 <mchehab@s-opensource.com>  
> > 
> > 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")..
> 
> 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.

I agree.

You can merge this patch through your tree with:

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Wed, 25 Apr 2018 12:47:34 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:47:28 +0200
> > Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> >   
> > > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > > > 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 <mchehab@s-opensource.com>    
> > > 
> > > 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")..  
> > 
> > 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.  
> 
> I agree.
> 
> You can merge this patch through your tree with:
> 
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Thanks, I'll merge it. It would still be really cool if Tony
or someone else could find a better way for omap3isp driver to
not depend on it.

Regards,
Maur

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Wed, 25 Apr 2018 12:47:34 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:47:28 +0200
> > Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> >   
> > > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > > > 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 <mchehab@s-opensource.com>    
> > > 
> > > 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")..  
> > 
> > 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.  
> 
> I agree.
> 
> You can merge this patch through your tree with:
> 
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Thanks, I'll merge it. It would still be really cool if Tony
or someone else could find a better way for omap3isp driver to
not depend on it.

Regards,
Maur

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Wed, 25 Apr 2018 12:47:34 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:47:28 +0200
> > Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> >   
> > > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > > > 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 <mchehab@s-opensource.com>    
> > > 
> > > 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")..  
> > 
> > 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.  
> 
> I agree.
> 
> You can merge this patch through your tree with:
> 
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Thanks, I'll merge it. It would still be really cool if Tony
or someone else could find a better way for omap3isp driver to
not depend on it.

Regards,
Maur

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > 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 <mchehab@s-opensource.com>
> 
> 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")..

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > 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 <mchehab@s-opensource.com>
> 
> 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")..

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > 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 <mchehab@s-opensource.com>
> 
> 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")..

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:

> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:

> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:

> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 17:11:14 +0300
Tomi Valkeinen <tomi.valkeinen@ti.com> escreveu:

> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
> 
> > 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.

Yeah, moving away from omapfb sounds the best alternative. As it seems that
there's just one driver currently depending on it, I guess it shouldn't be
that hard to do such change from Kernel's view, but I may be wrong, as I've
no clue what this would mean to userspace.

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 17:11:14 +0300
Tomi Valkeinen <tomi.valkeinen@ti.com> escreveu:

> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
> 
> > 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.

Yeah, moving away from omapfb sounds the best alternative. As it seems that
there's just one driver currently depending on it, I guess it shouldn't be
that hard to do such change from Kernel's view, but I may be wrong, as I've
no clue what this would mean to userspace.

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 17:11:14 +0300
Tomi Valkeinen <tomi.valkeinen@ti.com> escreveu:

> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
> 
> > 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.

Yeah, moving away from omapfb sounds the best alternative. As it seems that
there's just one driver currently depending on it, I guess it shouldn't be
that hard to do such change from Kernel's view, but I may be wrong, as I've
no clue what this would mean to userspace.

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote:
> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
> 
> > 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.

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..

> 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?

> 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?

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote:
> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
> 
> > 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.

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..

> 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?

> 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?

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote:
> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
> 
> > 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.

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..

> 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?

> 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?

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 14:13, Bartlomiej Zolnierkiewicz wrote:
> 
> On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote:
>> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
>>
>>> 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.
> 
> 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.

We have boot time code, which is always built-in, for both drivers which
adjusts device tree data. I imagine those could easily conflict. Maybe
there's something else too.

And it's not only about the main omapfb or omapdrm driver. We have
drivers for the encoders and panels. Those would conflict too. I guess
we could have the case where omapdrm probes, and then a panel driver
from omapfb probes.

Actually, many of the panel and encoder drivers probably have same
symbols too, which would prevent linking.

> 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..

Neither was I, but I have to say it was a game-changer for omapdrm
development. Doing anything new on omapdrm meant trying to get it to
work on omapfb too (in the same commit, so cross-tree), and many changes
were just too complex to even try. After that commit we were free to
really start restructuring the code to fit the DRM world.

>> 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?

That and the omapdss-boot-init.c we have for both omapfb and omapdrm.

>> 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?

Unfortunatey not. omapfb still has support for some legacy devices that
omapdrm doesn't support.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 14:13, Bartlomiej Zolnierkiewicz wrote:
> 
> On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote:
>> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
>>
>>> 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.
> 
> 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.

We have boot time code, which is always built-in, for both drivers which
adjusts device tree data. I imagine those could easily conflict. Maybe
there's something else too.

And it's not only about the main omapfb or omapdrm driver. We have
drivers for the encoders and panels. Those would conflict too. I guess
we could have the case where omapdrm probes, and then a panel driver
from omapfb probes.

Actually, many of the panel and encoder drivers probably have same
symbols too, which would prevent linking.

> 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..

Neither was I, but I have to say it was a game-changer for omapdrm
development. Doing anything new on omapdrm meant trying to get it to
work on omapfb too (in the same commit, so cross-tree), and many changes
were just too complex to even try. After that commit we were free to
really start restructuring the code to fit the DRM world.

>> 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?

That and the omapdss-boot-init.c we have for both omapfb and omapdrm.

>> 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?

Unfortunatey not. omapfb still has support for some legacy devices that
omapdrm doesn't support.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 14:13, Bartlomiej Zolnierkiewicz wrote:
> 
> On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote:
>> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
>>
>>> 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.
> 
> 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.

We have boot time code, which is always built-in, for both drivers which
adjusts device tree data. I imagine those could easily conflict. Maybe
there's something else too.

And it's not only about the main omapfb or omapdrm driver. We have
drivers for the encoders and panels. Those would conflict too. I guess
we could have the case where omapdrm probes, and then a panel driver
from omapfb probes.

Actually, many of the panel and encoder drivers probably have same
symbols too, which would prevent linking.

> 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..

Neither was I, but I have to say it was a game-changer for omapdrm
development. Doing anything new on omapdrm meant trying to get it to
work on omapfb too (in the same commit, so cross-tree), and many changes
were just too complex to even try. After that commit we were free to
really start restructuring the code to fit the DRM world.

>> 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?

That and the omapdss-boot-init.c we have for both omapfb and omapdrm.

>> 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?

Unfortunatey not. omapfb still has support for some legacy devices that
omapdrm doesn't support.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 15:56:53 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > > 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 <mchehab@s-opensource.com>  
> > 
> > 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")..  
> 
> 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
> ...

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.

> I need some more time to think about this..
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 15:56:53 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > > 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 <mchehab@s-opensource.com>  
> > 
> > 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")..  
> 
> 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
> ...

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.

> I need some more time to think about this..
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 15:56:53 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > > 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 <mchehab@s-opensource.com>  
> > 
> > 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")..  
> 
> 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
> ...

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.

> I need some more time to think about this..
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Mauro,

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:
> > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> >>> 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 <mchehab@s-opensource.com>
> >> 
> >> 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")..
> > 
> > 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 ...
> 
> 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.

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.

> > I need some more time to think about this..

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Mauro,

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:
> > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> >>> 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 <mchehab@s-opensource.com>
> >> 
> >> 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")..
> > 
> > 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 ...
> 
> 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.

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.

> > I need some more time to think about this..

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Mauro,

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:
> > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> >>> 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 <mchehab@s-opensource.com>
> >> 
> >> 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")..
> > 
> > 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 ...
> 
> 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.

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.

> > I need some more time to think about this..

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 22:48:06 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> 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:  
> > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:  
> > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > >>> 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 <mchehab@s-opensource.com>  
> > >> 
> > >> 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")..  
> > > 
> > > 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 ...  
> > 
> > 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.  
> 
> 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.

> 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.

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 22:48:06 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> 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:  
> > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:  
> > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > >>> 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 <mchehab@s-opensource.com>  
> > >> 
> > >> 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")..  
> > > 
> > > 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 ...  
> > 
> > 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.  
> 
> 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.

> 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.

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 22:48:06 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> 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:  
> > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:  
> > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > >>> 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 <mchehab@s-opensource.com>  
> > >> 
> > >> 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")..  
> > > 
> > > 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 ...  
> > 
> > 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.  
> 
> 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.

> 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.

Thanks,
Mauro

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

On Monday, 23 April 2018 23:09:55 EEST Mauro Carvalho Chehab wrote:
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > 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:
> > > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> > > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > >>> 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 <mchehab@s-opensource.com>
> > > >> 
> > > >> 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")..
> > > > 
> > > > 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 ...
> > > 
> > > 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.
> > 
> > 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.
> 
> > 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.

It's on its way, but slowly as we need to take userspace into account. Tomi 
should have more insight on a possible schedule for removal of omapfb.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

On Monday, 23 April 2018 23:09:55 EEST Mauro Carvalho Chehab wrote:
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > 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:
> > > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> > > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > >>> 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 <mchehab@s-opensource.com>
> > > >> 
> > > >> 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")..
> > > > 
> > > > 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 ...
> > > 
> > > 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.
> > 
> > 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.
> 
> > 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.

It's on its way, but slowly as we need to take userspace into account. Tomi 
should have more insight on a possible schedule for removal of omapfb.

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

On Monday, 23 April 2018 23:09:55 EEST Mauro Carvalho Chehab wrote:
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > 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:
> > > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> > > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > >>> 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 <mchehab@s-opensource.com>
> > > >> 
> > > >> 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")..
> > > > 
> > > > 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 ...
> > > 
> > > 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.
> > 
> > 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.
> 
> > 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.

It's on its way, but slowly as we need to take userspace into account. Tomi 
should have more insight on a possible schedule for removal of omapfb.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 23/04/18 23:09, Mauro Carvalho Chehab wrote:

>> 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.

>> 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.

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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 23/04/18 23:09, Mauro Carvalho Chehab wrote:

>> 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.

>> 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.

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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 23/04/18 23:09, Mauro Carvalho Chehab wrote:

>> 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.

>> 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.

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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 09:24:14 EEST Tomi Valkeinen wrote:
> On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
> >> 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.
> 
> >> 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.
> 
> 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 ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 09:24:14 EEST Tomi Valkeinen wrote:
> On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
> >> 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.
> 
> >> 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.
> 
> 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 ?

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 09:24:14 EEST Tomi Valkeinen wrote:
> On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
> >> 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.
> 
> >> 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.
> 
> 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 ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 12:03, Laurent Pinchart wrote:

> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 12:03, Laurent Pinchart wrote:

> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 12:03, Laurent Pinchart wrote:

> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> On 25/04/18 12:03, Laurent Pinchart wrote:
> > 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.

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

> And VRFB on OMAP2/3.

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

> Those need omapfb.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> On 25/04/18 12:03, Laurent Pinchart wrote:
> > 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.

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

> And VRFB on OMAP2/3.

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

> Those need omapfb.

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> On 25/04/18 12:03, Laurent Pinchart wrote:
> > 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.

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

> And VRFB on OMAP2/3.

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

> Those need omapfb.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 13:02, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
>> On 25/04/18 12:03, Laurent Pinchart wrote:
>>> 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.
> 
> 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.

>> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 13:02, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
>> On 25/04/18 12:03, Laurent Pinchart wrote:
>>> 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.
> 
> 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.

>> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 25/04/18 13:02, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
>> On 25/04/18 12:03, Laurent Pinchart wrote:
>>> 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.
> 
> 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.

>> 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.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 13:10:43 EEST Tomi Valkeinen wrote:
> On 25/04/18 13:02, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> >> On 25/04/18 12:03, Laurent Pinchart wrote:
> >>> 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.
> > 
> > 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.
> 
> >> 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.

I agree with you, we shouldn't. We'll need a grace period before removing 
omapfb, if we ever do so.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 13:10:43 EEST Tomi Valkeinen wrote:
> On 25/04/18 13:02, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> >> On 25/04/18 12:03, Laurent Pinchart wrote:
> >>> 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.
> > 
> > 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.
> 
> >> 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.

I agree with you, we shouldn't. We'll need a grace period before removing 
omapfb, if we ever do so.

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 25 April 2018 13:10:43 EEST Tomi Valkeinen wrote:
> On 25/04/18 13:02, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> >> On 25/04/18 12:03, Laurent Pinchart wrote:
> >>> 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.
> > 
> > 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.
> 
> >> 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.

I agree with you, we shouldn't. We'll need a grace period before removing 
omapfb, if we ever do so.

-- 
Regards,

Laurent Pinchart

[PATCH 6/7] media: omap2: allow building it with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Now that FB_OMAP has stubs, the omap2 media drivers can be
built on ARM with COMPILE_TEST && DRM_OMAP.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
 drivers/media/platform/omap/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig
index 27343376f557..a414bcbb9b08 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -5,7 +5,8 @@ config VIDEO_OMAP2_VOUT_VRFB
 
 config VIDEO_OMAP2_VOUT
 	tristate "OMAP2/OMAP3 V4L2-Display driver"
-	depends on MMU && FB_OMAP2
+	depends on MMU
+	depends on FB_OMAP2 || COMPILE_TEST
 	depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
 	select VIDEOBUF_GEN
 	select VIDEOBUF_DMA_CONTIG
-- 
2.14.3

[PATCH 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[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.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
 drivers/media/platform/Kconfig      |  2 +-
 drivers/media/platform/via-camera.c | 10 +++++++++-
 include/linux/via-core.h            | 17 +++++++++++++++++
 include/linux/via-gpio.h            |  4 ++++
 include/linux/via_i2c.h             |  5 +++++
 5 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e3229f7baed1..abaaed98a044 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -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
 	select VIDEOBUF_DMA_SG
 	select VIDEO_OV7670
 	help
diff --git a/drivers/media/platform/via-camera.c b/drivers/media/platform/via-camera.c
index e9a02639554b..4ab1695b33af 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -27,7 +27,10 @@
 #include <linux/via-core.h>
 #include <linux/via-gpio.h>
 #include <linux/via_i2c.h>
+
+#ifdef CONFIG_FB_VIA
 #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
+	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;
 
 	/*
diff --git a/include/linux/via-core.h b/include/linux/via-core.h
index 9c21cdf3e3b3..7aaee6a82392 100644
--- a/include/linux/via-core.h
+++ b/include/linux/via-core.h
@@ -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
+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.
diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
index 8281aea3dd6d..b5a96cf7a874 100644
--- a/include/linux/via-gpio.h
+++ b/include/linux/via-gpio.h
@@ -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
diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
index 44532e468c05..61ae0e7e4576 100644
--- a/include/linux/via_i2c.h
+++ b/include/linux/via_i2c.h
@@ -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);
@@ -39,4 +40,8 @@ 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
+struct i2c_adapter *viafb_find_i2c_adapter(enum viafb_i2c_adap which)
+{ return NULL; }
+#endif
 #endif /* __VIA_I2C_H__ */
-- 
2.14.3

[PATCH 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[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.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
 drivers/media/platform/Kconfig      |  2 +-
 drivers/media/platform/via-camera.c | 10 +++++++++-
 include/linux/via-core.h            | 17 +++++++++++++++++
 include/linux/via-gpio.h            |  4 ++++
 include/linux/via_i2c.h             |  5 +++++
 5 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e3229f7baed1..abaaed98a044 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -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
 	select VIDEOBUF_DMA_SG
 	select VIDEO_OV7670
 	help
diff --git a/drivers/media/platform/via-camera.c b/drivers/media/platform/via-camera.c
index e9a02639554b..4ab1695b33af 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -27,7 +27,10 @@
 #include <linux/via-core.h>
 #include <linux/via-gpio.h>
 #include <linux/via_i2c.h>
+
+#ifdef CONFIG_FB_VIA
 #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
+	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;
 
 	/*
diff --git a/include/linux/via-core.h b/include/linux/via-core.h
index 9c21cdf3e3b3..7aaee6a82392 100644
--- a/include/linux/via-core.h
+++ b/include/linux/via-core.h
@@ -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
+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.
diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
index 8281aea3dd6d..b5a96cf7a874 100644
--- a/include/linux/via-gpio.h
+++ b/include/linux/via-gpio.h
@@ -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
diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
index 44532e468c05..61ae0e7e4576 100644
--- a/include/linux/via_i2c.h
+++ b/include/linux/via_i2c.h
@@ -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);
@@ -39,4 +40,8 @@ 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
+struct i2c_adapter *viafb_find_i2c_adapter(enum viafb_i2c_adap which)
+{ return NULL; }
+#endif
 #endif /* __VIA_I2C_H__ */
-- 
2.14.3

[PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[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.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e3229f7baed1..abaaed98a044 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -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
 	select VIDEOBUF_DMA_SG
 	select VIDEO_OV7670
 	help
diff --git a/drivers/media/platform/via-camera.c b/drivers/media/platform/via-camera.c
index e9a02639554b..4ab1695b33af 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -27,7 +27,10 @@
 #include <linux/via-core.h>
 #include <linux/via-gpio.h>
 #include <linux/via_i2c.h>
+
+#ifdef CONFIG_FB_VIA
 #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
+	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;
 
 	/*
diff --git a/include/linux/via-core.h b/include/linux/via-core.h
index 9c21cdf3e3b3..ced4419baef8 100644
--- a/include/linux/via-core.h
+++ b/include/linux/via-core.h
@@ -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.
diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
index 8281aea3dd6d..b5a96cf7a874 100644
--- a/include/linux/via-gpio.h
+++ b/include/linux/via-gpio.h
@@ -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
diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
index 44532e468c05..209bff950e22 100644
--- a/include/linux/via_i2c.h
+++ b/include/linux/via_i2c.h
@@ -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);
@@ -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__ */

[PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[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.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e3229f7baed1..abaaed98a044 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -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
 	select VIDEOBUF_DMA_SG
 	select VIDEO_OV7670
 	help
diff --git a/drivers/media/platform/via-camera.c b/drivers/media/platform/via-camera.c
index e9a02639554b..4ab1695b33af 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -27,7 +27,10 @@
 #include <linux/via-core.h>
 #include <linux/via-gpio.h>
 #include <linux/via_i2c.h>
+
+#ifdef CONFIG_FB_VIA
 #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
+	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;
 
 	/*
diff --git a/include/linux/via-core.h b/include/linux/via-core.h
index 9c21cdf3e3b3..ced4419baef8 100644
--- a/include/linux/via-core.h
+++ b/include/linux/via-core.h
@@ -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.
diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
index 8281aea3dd6d..b5a96cf7a874 100644
--- a/include/linux/via-gpio.h
+++ b/include/linux/via-gpio.h
@@ -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
diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
index 44532e468c05..209bff950e22 100644
--- a/include/linux/via_i2c.h
+++ b/include/linux/via_i2c.h
@@ -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);
@@ -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__ */

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

Hi Mauro,

On Friday, April 20, 2018 04:03:21 PM Mauro Carvalho Chehab wrote:
> 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).

> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index e3229f7baed1..abaaed98a044 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -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.

>  	select VIDEOBUF_DMA_SG
>  	select VIDEO_OV7670
>  	help
> diff --git a/drivers/media/platform/via-camera.c b/drivers/media/platform/via-camera.c
> index e9a02639554b..4ab1695b33af 100644
> --- a/drivers/media/platform/via-camera.c
> +++ b/drivers/media/platform/via-camera.c
> @@ -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.

>  #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

> +	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;
>  
>  	/*
> diff --git a/include/linux/via-core.h b/include/linux/via-core.h
> index 9c21cdf3e3b3..ced4419baef8 100644
> --- a/include/linux/via-core.h
> +++ b/include/linux/via-core.h
> @@ -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.
> diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
> index 8281aea3dd6d..b5a96cf7a874 100644
> --- a/include/linux/via-gpio.h
> +++ b/include/linux/via-gpio.h
> @@ -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
> diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
> index 44532e468c05..209bff950e22 100644
> --- a/include/linux/via_i2c.h
> +++ b/include/linux/via_i2c.h
> @@ -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);
> @@ -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 <b.zolnierkie@samsung.com>
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 <FlorianSchandinat@gmx.de>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -25,7 +25,6 @@
 #include <linux/stat.h>
 #include <linux/via-core.h>
 #include <linux/via_i2c.h>
-#include <asm/olpc.h>
 
 #define _MASTER_FILE
 #include "global.h"

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

Hi Mauro,

On Friday, April 20, 2018 04:03:21 PM Mauro Carvalho Chehab wrote:
> 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).

> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index e3229f7baed1..abaaed98a044 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -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.

>  	select VIDEOBUF_DMA_SG
>  	select VIDEO_OV7670
>  	help
> diff --git a/drivers/media/platform/via-camera.c b/drivers/media/platform/via-camera.c
> index e9a02639554b..4ab1695b33af 100644
> --- a/drivers/media/platform/via-camera.c
> +++ b/drivers/media/platform/via-camera.c
> @@ -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.

>  #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

> +	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;
>  
>  	/*
> diff --git a/include/linux/via-core.h b/include/linux/via-core.h
> index 9c21cdf3e3b3..ced4419baef8 100644
> --- a/include/linux/via-core.h
> +++ b/include/linux/via-core.h
> @@ -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.
> diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
> index 8281aea3dd6d..b5a96cf7a874 100644
> --- a/include/linux/via-gpio.h
> +++ b/include/linux/via-gpio.h
> @@ -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
> diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
> index 44532e468c05..209bff950e22 100644
> --- a/include/linux/via_i2c.h
> +++ b/include/linux/via_i2c.h
> @@ -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);
> @@ -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 <b.zolnierkie@samsung.com>
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 <FlorianSchandinat@gmx.de>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -25,7 +25,6 @@
 #include <linux/stat.h>
 #include <linux/via-core.h>
 #include <linux/via_i2c.h>
-#include <asm/olpc.h>
 
 #define _MASTER_FILE
 #include "global.h"

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:19:31 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> Hi Mauro,
> 
> On Friday, April 20, 2018 04:03:21 PM Mauro Carvalho Chehab wrote:
> > 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).

Ok. Btw, get maintainer script only gets the fbdev ML:

$ ./scripts/get_maintainer.pl -f include/linux/via-core.h
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> (maintainer:VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER)
linux-fbdev@vger.kernel.org (open list:VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER)
linux-kernel@vger.kernel.org (open list)

It probably makes sense to add a:

R: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

At the MAINTAINERS' entry for VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER.


> 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index e3229f7baed1..abaaed98a044 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -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.

OK. I'll add id, addressing the other issues you pointed and send
a version 2 of the patches on this series that weren't merged.

> 
> * 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.
> 
> >  	select VIDEOBUF_DMA_SG
> >  	select VIDEO_OV7670
> >  	help
> > diff --git a/drivers/media/platform/via-camera.c b/drivers/media/platform/via-camera.c
> > index e9a02639554b..4ab1695b33af 100644
> > --- a/drivers/media/platform/via-camera.c
> > +++ b/drivers/media/platform/via-camera.c
> > @@ -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.
> 
> >  #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
> 
> > +	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;
> >  
> >  	/*
> > diff --git a/include/linux/via-core.h b/include/linux/via-core.h
> > index 9c21cdf3e3b3..ced4419baef8 100644
> > --- a/include/linux/via-core.h
> > +++ b/include/linux/via-core.h
> > @@ -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.
> > diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
> > index 8281aea3dd6d..b5a96cf7a874 100644
> > --- a/include/linux/via-gpio.h
> > +++ b/include/linux/via-gpio.h
> > @@ -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
> > diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
> > index 44532e468c05..209bff950e22 100644
> > --- a/include/linux/via_i2c.h
> > +++ b/include/linux/via_i2c.h
> > @@ -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);
> > @@ -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 <b.zolnierkie@samsung.com>
> 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 <FlorianSchandinat@gmx.de>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
>  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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -25,7 +25,6 @@
>  #include <linux/stat.h>
>  #include <linux/via-core.h>
>  #include <linux/via_i2c.h>
> -#include <asm/olpc.h>
>  
>  #define _MASTER_FILE
>  #include "global.h"
> 
> 



Thanks,
Mauro

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:19:31 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:

> Hi Mauro,
> 
> On Friday, April 20, 2018 04:03:21 PM Mauro Carvalho Chehab wrote:
> > 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).

Ok. Btw, get maintainer script only gets the fbdev ML:

$ ./scripts/get_maintainer.pl -f include/linux/via-core.h
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> (maintainer:VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER)
linux-fbdev@vger.kernel.org (open list:VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER)
linux-kernel@vger.kernel.org (open list)

It probably makes sense to add a:

R: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

At the MAINTAINERS' entry for VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER.


> 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index e3229f7baed1..abaaed98a044 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -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.

OK. I'll add id, addressing the other issues you pointed and send
a version 2 of the patches on this series that weren't merged.

> 
> * 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.
> 
> >  	select VIDEOBUF_DMA_SG
> >  	select VIDEO_OV7670
> >  	help
> > diff --git a/drivers/media/platform/via-camera.c b/drivers/media/platform/via-camera.c
> > index e9a02639554b..4ab1695b33af 100644
> > --- a/drivers/media/platform/via-camera.c
> > +++ b/drivers/media/platform/via-camera.c
> > @@ -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.
> 
> >  #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
> 
> > +	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;
> >  
> >  	/*
> > diff --git a/include/linux/via-core.h b/include/linux/via-core.h
> > index 9c21cdf3e3b3..ced4419baef8 100644
> > --- a/include/linux/via-core.h
> > +++ b/include/linux/via-core.h
> > @@ -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.
> > diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
> > index 8281aea3dd6d..b5a96cf7a874 100644
> > --- a/include/linux/via-gpio.h
> > +++ b/include/linux/via-gpio.h
> > @@ -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
> > diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
> > index 44532e468c05..209bff950e22 100644
> > --- a/include/linux/via_i2c.h
> > +++ b/include/linux/via_i2c.h
> > @@ -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);
> > @@ -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 <b.zolnierkie@samsung.com>
> 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 <FlorianSchandinat@gmx.de>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
>  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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -25,7 +25,6 @@
>  #include <linux/stat.h>
>  #include <linux/via-core.h>
>  #include <linux/via_i2c.h>
> -#include <asm/olpc.h>
>  
>  #define _MASTER_FILE
>  #include "global.h"
> 
> 



Thanks,
Mauro

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:19:31 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:


> 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 <mchehab+samsung@kernel.org>

Thanks!
Mauro

> 
> 
> From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> 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 <FlorianSchandinat@gmx.de>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
>  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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -25,7 +25,6 @@
>  #include <linux/stat.h>
>  #include <linux/via-core.h>
>  #include <linux/via_i2c.h>
> -#include <asm/olpc.h>
>  
>  #define _MASTER_FILE
>  #include "global.h"
> 
> 



Thanks,
Mauro

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Mon, 23 Apr 2018 14:19:31 +0200
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:


> 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 <mchehab+samsung@kernel.org>

Thanks!
Mauro

> 
> 
> From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> 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 <FlorianSchandinat@gmx.de>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
>  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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -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
> @@ -25,7 +25,6 @@
>  #include <linux/stat.h>
>  #include <linux/via-core.h>
>  #include <linux/via_i2c.h>
> -#include <asm/olpc.h>
>  
>  #define _MASTER_FILE
>  #include "global.h"
> 
> 



Thanks,
Mauro

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

On Friday, May 04, 2018 11:07:01 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:19:31 +0200
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> 
> 
> > 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 <mchehab+samsung@kernel.org>

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

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

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

On Friday, May 04, 2018 11:07:01 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:19:31 +0200
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> 
> 
> > 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 <mchehab+samsung@kernel.org>

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

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

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

On Friday, May 04, 2018 04:24:15 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, May 04, 2018 11:07:01 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:19:31 +0200
> > Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> > 
> > 
> > > 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 <mchehab+samsung@kernel.org>
> 
> Thanks, I'll apply it to my tree later.

I've queued the patch for v4.18 now.

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

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

[Bartlomiej Zolnierkiewicz]

On Friday, May 04, 2018 04:24:15 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, May 04, 2018 11:07:01 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:19:31 +0200
> > Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> escreveu:
> > 
> > 
> > > 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 <mchehab+samsung@kernel.org>
> 
> Thanks, I'll apply it to my tree later.

I've queued the patch for v4.18 now.

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