Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header

2018-05-22 Thread Geert Uytterhoeven
Hi Simon,

On Tue, May 22, 2018 at 11:05 AM, Simon Horman <ho...@verge.net.au> wrote:
>> --- a/drivers/media/platform/vsp1/vsp1_regs.h
>> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
>> @@ -1,4 +1,4 @@
>> -/* SPDX-License-Identifier: GPL-2.0 */
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>
> While you are changing this line, I believe the correct format is
> to use a '//' comment.
>
> i.e.:
>
> // SPDX-License-Identifier: GPL-2.0+

Not for C header files, only for C source files.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH v2] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

2018-05-18 Thread Geert Uytterhoeven
The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
only.  Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
than the legacy ARCH_SHMOBILE, hence use the former.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Acked-by: Arnd Bergmann <a...@arndb.de>
Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Reviewed-by: Simon Horman <horms+rene...@verge.net.au>
---
v2:
  - Add Acked-by, Reviewed-by.
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 840475e3a6b87ac1..a0fe7b127412d3e1 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -397,7 +397,7 @@ config VIDEO_SH_VEU
 config VIDEO_RENESAS_FDP1
tristate "Renesas Fine Display Processor"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
-- 
2.7.4



[PATCH v4] media: Remove depends on HAS_DMA in case of platform dependency

2018-05-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various VIDEOBUF*DMA* symbols had to loose their dependencies on
HAS_DMA, as they are selected by several individual drivers.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
From: kbuild test robot <l...@intel.com>

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git  
no-dma-compile-testing-v4-media
branch HEAD: 9fd4215b490cae0bb6dd058a18a19e60dbcd3020  media: Remove depends on 
HAS_DMA in case of platform dependency

elapsed time: 41m

configs tested: 99

---
v4:
  - Rebase to media-next on 2018-05-17,

v3:
  - Rebase to v4.17-rc1,
  - Handle new VIDEO_RENESAS_CEU symbol,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on
HAS_DMA,
  - Split per subsystem.
---
 drivers/media/common/videobuf2/Kconfig   |  2 --
 drivers/media/pci/dt3155/Kconfig |  1 -
 drivers/media/pci/intel/ipu3/Kconfig |  1 -
 drivers/media/pci/solo6x10/Kconfig   |  1 -
 drivers/media/pci/sta2x11/Kconfig|  1 -
 drivers/media/pci/tw5864/Kconfig |  1 -
 drivers/media/pci/tw686x/Kconfig |  1 -
 drivers/media/platform/Kconfig   | 43 +---
 drivers/media/platform/am437x/Kconfig|  2 +-
 drivers/media/platform/atmel/Kconfig |  4 +--
 drivers/media/platform/davinci/Kconfig   |  6 
 drivers/media/platform/marvell-ccic/Kconfig  |  2 --
 drivers/media/platform/rcar-vin/Kconfig  |  2 +-
 drivers/media/platform/soc_camera/Kconfig|  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig |  2 +-
 drivers/media/v4l2-core/Kconfig  |  2 --
 drivers/staging/media/davinci_vpfe/Kconfig   |  1 -
 drivers/staging/media/omap4iss/Kconfig   |  1 -
 18 files changed, 20 insertions(+), 56 deletions(-)

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index 17c32ea58395d78f..4ed11b46676ac4d0 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS
 
 config VIDEOBUF2_DMA_CONTIG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
select DMA_SHARED_BUFFER
@@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC
 
 config VIDEOBUF2_DMA_SG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
 
diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig
index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644
--- a/drivers/media/pci/dt3155/Kconfig
+++ b/drivers/media/pci/dt3155/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_DT3155
tristate "DT3155 frame grabber"
depends on PCI && VIDEO_DEV && VIDEO_V4L2
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
---help---
diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index 45cf99a512e484d5..c8bd98d7564afdfb 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2
depends on VIDEO_V4L2_SUBDEV_API
depends on (X86 && ACPI) || COMPILE_TEST
depends on MEDIA_CONTROLLER
-   depends on HAS_DMA
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
 
diff --git a/drivers/media/pci/solo6x10/Kconfig 
b/drivers/media/pci/solo6x10/Kconfig
index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644
--- a/drivers/media/pci/solo6x10/Kconfig
+++ b/drivers/media/pci/solo6x10/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_SOLO6X10
tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)"
depends on PCI && VIDEO_DEV && SND && I2C
-   depends on HAS_DMA
select BITREVERSE
select FONT_SUPPORT
select FONT_8x16
diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index 7af3f1cbcea824b9..4407b9f881e400d8 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,7 +1,6 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
depends on STA2X11 || COMPILE_TEST
-   depends on HAS_DMA
select V

Re: [PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0

2018-05-16 Thread Geert Uytterhoeven
Hi Jacopo,

On Thu, Apr 26, 2018 at 8:24 PM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote:
> Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
>
> Reported-by: Geert Uytterhoeven <ge...@glider.be>
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>

Minor question below.

> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -67,6 +67,16 @@
> power-domains = <_d4>;
> };
>
> +   ceu0: ceu@fe91 {
> +   reg = <0xfe91 0x3000>;
> +   compatible = "renesas,r8a7740-ceu";
> +   interrupts = ;
> +   clocks = <_clks R8A7740_CLK_CEU20>;
> +   clock-names = "ceu20";

Why the "clock-names" property? It's not mentioned in the DT bindings, and
may cause issues if the bindings are ever amended.

> +   power-domains = <_a4r>;
> +   status = "disabled";
> +   };
> +

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] media: vsp1: cleanup a false positive warning

2018-05-04 Thread Geert Uytterhoeven
Hi Mauro,

On Fri, May 4, 2018 at 2:13 PM, Mauro Carvalho Chehab
<mchehab+sams...@kernel.org> wrote:
> With the new vsp1 code changes introduced by changeset
> f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines 
> dynamically"),
> smatch complains with:
> drivers/media/platform/vsp1/vsp1_drm.c:262 
> vsp1_du_pipeline_setup_bru() error: we previously assumed 'pipe->bru' could 
> be null (see line 180)
>
> This is a false positive, as, if pipe->bru is NULL, the brx
> var will be different, with ends by calling a code that will
> set pipe->bru to another value.
>
> Yet, cleaning this false positive is as easy as adding an explicit
> check if pipe->bru is NULL.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

Thanks for your patch!

s/bru/brx/

> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -185,7 +185,7 @@ static int vsp1_du_pipeline_setup_brx(struct vsp1_device 
> *vsp1,
> brx = >brs->entity;
>
> /* Switch BRx if needed. */
> -   if (brx != pipe->brx) {
> +   if (brx != pipe->brx || !pipe->brx) {
> struct vsp1_entity *released_brx = NULL;
>
> /* Release our BRx if we have one. */

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v14 03/33] rcar-vin: add Gen3 devicetree bindings documentation

2018-05-02 Thread Geert Uytterhoeven
 -Board setup example (vin1 composite video input)
> -
> +Board setup example for Gen2 platforms (vin1 composite video input)
> +---
>
> {
>  status = "okay";
> @@ -95,6 +118,77 @@ Board setup example (vin1 composite video input)
>  };
>  };
>
> +Device node example for Gen3 platforms
> +--
>
> +vin0: video@e6ef {
> +compatible = "renesas,vin-r8a7795";
> +reg = <0 0xe6ef 0 0x1000>;
> +interrupts = ;
> +clocks = < CPG_MOD 811>;
> +power-domains = < R8A7795_PD_ALWAYS_ON>;
> +resets = < 811>;
> +renesas,id = <0>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@1 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +reg = <1>;
> +
> +vin0csi20: endpoint@0 {
> +reg = <0>;
> +remote-endpoint= <>;
> +};
> +vin0csi21: endpoint@1 {
> +reg = <1>;
> +remote-endpoint= <>;
> +};
> +vin0csi40: endpoint@2 {
> +reg = <2>;
> +remote-endpoint= <>;
> +};
> +};
> +};
> +};
> +
> +csi20: csi2@fea8 {
> +compatible = "renesas,r8a7795-csi2";
> +reg = <0 0xfea8 0 0x1>;
> +interrupts = ;
> +clocks = < CPG_MOD 714>;
> +power-domains = < R8A7795_PD_ALWAYS_ON>;
> +resets = < 714>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +csi20_in: endpoint {
> +clock-lanes = <0>;
> +        data-lanes = <1>;
> +remote-endpoint = <_txb>;
> +};
> +};
> +
> +port@1 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +reg = <1>;
> +
> +csi20vin0: endpoint@0 {
> +reg = <0>;
> +remote-endpoint = <>;
> +};
> +};
> +};
> +};
>
>  [1] video-interfaces.txt common video media interface

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] rcar-vin: fix null pointer dereference in rvin_group_get()

2018-04-25 Thread Geert Uytterhoeven
On Wed, Apr 25, 2018 at 1:45 AM, Niklas Söderlund
<niklas.soderlund+rene...@ragnatech.se> wrote:
> Store the group pointer before disassociating the VIN from the group.

s/get/put/ in one-line summary?

> Fixes: 3bb4c3bc85bf77a7 ("media: rcar-vin: add group allocator functions")
> Reported-by: Colin Ian King <colin.k...@canonical.com>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 7bc2774a11232362..d3072e166a1ca24f 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -338,19 +338,21 @@ static int rvin_group_get(struct rvin_dev *vin)
>
>  static void rvin_group_put(struct rvin_dev *vin)
>  {
> -   mutex_lock(>group->lock);
> +   struct rvin_group *group = vin->group;

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol

2018-04-24 Thread Geert Uytterhoeven
(Reducing/enhancing CC list)

On Fri, Apr 20, 2018 at 3:28 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
> platform dependencies.  Hence finish the conversion from ARCH_SHMOBILE
> to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
> 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
> This depends on the previous patches in this series, hence the RFC.
>
> JFTR, after this, the following symbols for drivers supporting only
> Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
>   - CONFIG_KEYBOARD_SH_KEYSC,
>   - CONFIG_VIDEO_SH_VOU,
>   - CONFIG_VIDEO_SH_MOBILE_CEU,
>   - CONFIG_DRM_SHMOBILE[*],
>   - CONFIG_FB_SH_MOBILE_MERAM.
> (changes for a shmobile_defconfig .config)

Apparently CONFIG_VIDEO_SH_MOBILE_CEU was set in the old
armadillo800eva_defconfig, and used by the old board code.

While DT bindings do exist [1], some DT support has been added to the
driver [2], and this even ended up as the example in [3], this was never
enabled in the corresponding board DTS.

Nevertheless, I understand that soc_camera-based driver is obsolete, and
has been replaced by [4], but bindings for r8a7740 are lacking [5].

[1] Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
[2] drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
[3] Documentation/devicetree/bindings/media/video-interfaces.txt
[4] drivers/media/platform/renesas-ceu.c
[5] Documentation/devicetree/bindings/media/renesas,ceu.txt

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

2018-04-24 Thread Geert Uytterhoeven
Hi Mauro,

On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab
<mche...@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 <mche...@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 -- ge...@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 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

2018-04-23 Thread Geert Uytterhoeven
Hi Laurent,

On Sun, Apr 22, 2018 at 10:46 AM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
> On Saturday, 21 April 2018 11:07:11 EEST Laurent Pinchart wrote:
>> On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote:
>> > The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
>> > only.  Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
>> > ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
>> > than the legacy ARCH_SHMOBILE, hence use the former.
>> >
>> > This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
>> > future.
>> >
>> > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
>>
>> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
>>
>> How would you like to get this merged ?
>
> Unless you would like to merge the whole series in one go, I'll take this in
> my tree as I have a conflicting patch I would like to submit for v4.18.

Please take it in your tree, thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 2/3] v4l: rcar_fdp1: Enable compilation on Gen2 platforms

2018-04-23 Thread Geert Uytterhoeven
Hi Laurent,

On Sun, Apr 22, 2018 at 12:28 PM, Laurent Pinchart
<laurent.pinchart+rene...@ideasonboard.com> wrote:
> Commit 1d3897143815 ("[media] v4l: rcar_fdp1: add FCP dependency") fixed
> a compilation breakage when the optional VIDEO_RENESAS_FCP dependency is
> compiled as a module while the rcar_fdp1 driver is built in. As a side
> effect it disabled compilation on Gen2 by disallowing the valid
> combination ARCH_RENESAS && !VIDEO_RENESAS_FCP. Fix it by handling the
> dependency the same way the vsp1 driver did in commit 199946731fa4
> ("[media] vsp1: clarify FCP dependency").
>
> Fixes: 1d3897143815 ("[media] v4l: rcar_fdp1: add FCP dependency")
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> ---
>  drivers/media/platform/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 621d63b2001d..81c3ab95c050 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -397,7 +397,7 @@ config VIDEO_RENESAS_FDP1
> tristate "Renesas Fine Display Processor"
> depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> depends on ARCH_RENESAS || COMPILE_TEST
> -   depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
> +   depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP

s/!ARM64/ARCH_RCAR_GEN2/?

> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS

2018-04-23 Thread Geert Uytterhoeven
Hi Mark,

On Fri, Apr 20, 2018 at 6:48 PM, Mark Brown <broo...@kernel.org> wrote:
> On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
>> The first 6 patches can be applied independently by subsystem
>> maintainers.
>> The last two patches depend on the first 6 patches, and are thus marked
>> RFC.
>
> Would it not make sense to try to apply everything en masse rather than
> delaying?  I'm happy to apply the subsystem stuff but if it gets things
> done quicker or more efficiently I'm also happy to have the lot merged
> as one series.

In theory, yes.

However, this touches multiple subsystems, and it's non-critical, so I don't
want to spent the energy to get this done in a synchronized way.
It's way easier to postpone the last (RFC) patches when everything else
has been applied by subsystem maintainers.

So please apply your part, thanks!

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol

2018-04-20 Thread Geert Uytterhoeven
All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
platform dependencies.  Hence finish the conversion from ARCH_SHMOBILE
to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
This depends on the previous patches in this series, hence the RFC.

JFTR, after this, the following symbols for drivers supporting only
Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
  - CONFIG_KEYBOARD_SH_KEYSC,
  - CONFIG_VIDEO_SH_VOU,
  - CONFIG_VIDEO_SH_MOBILE_CEU,
  - CONFIG_DRM_SHMOBILE[*],
  - CONFIG_FB_SH_MOBILE_MERAM.
(changes for a shmobile_defconfig .config)

[*] CONFIG_DRM_SHMOBILE has a dependency on ARM, but it was never wired
up.  From the use of sh_mobile_meram, I guess it was meant for
SH-Mobile AP4 on Mackerel or AP4EVB, which are long gone.
So the only remaining upstream platforms that could make use of it
are legacy SuperH SH-Mobile SoCs?
---
 arch/arm/mach-shmobile/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 96672da02f5f17b9..d892c5b52b6f5627 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -1,6 +1,3 @@
-config ARCH_SHMOBILE
-   bool
-
 config PM_RMOBILE
bool
select PM
@@ -30,7 +27,6 @@ menuconfig ARCH_RENESAS
bool "Renesas ARM SoCs"
depends on ARCH_MULTI_V7 && MMU
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
-   select ARCH_SHMOBILE
select ARM_GIC
select GPIOLIB
select HAVE_ARM_SCU if SMP
-- 
2.7.4



[PATCH/RFC 8/8] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

2018-04-20 Thread Geert Uytterhoeven
The Kconfig symbol for Renesas 64-bit ARM SoCs has always been
ARCH_RENESAS, with ARCH_SHMOBILE being selected to reuse drivers shared
with Renesas 32-bit ARM and/or Renesas SuperH SH-Mobile SoCs.

Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
32-bit SoCs.  Now all drivers for Renesas ARM SoCs have gained proper
ARCH_RENESAS platform dependencies, there is no longer a need to select
ARCH_SHMOBILE.

With ARCH_SHMOBILE gone, move the ARCH_RENESAS section up, to restore
alphabetical sort order.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
This depends on the driver patches in this series, hence the RFC.

JFTR, after this, the following symbols for drivers supporting only
Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
  - CONFIG_KEYBOARD_SH_KEYSC,
  - CONFIG_VIDEO_SH_VOU,
  - CONFIG_VIDEO_RENESAS_CEU,
  - CONFIG_FB_SH_MOBILE_MERAM.
(changes for a renesas_defconfig .config)
---
 arch/arm64/Kconfig.platforms | 42 +++---
 1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3a776..49d8ed1ab84766dd 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -145,31 +145,8 @@ config ARCH_REALTEK
  This enables support for the ARMv8 based Realtek chipsets,
  like the RTD1295.
 
-config ARCH_ROCKCHIP
-   bool "Rockchip Platforms"
-   select ARCH_HAS_RESET_CONTROLLER
-   select GPIOLIB
-   select PINCTRL
-   select PINCTRL_ROCKCHIP
-   select ROCKCHIP_TIMER
-   help
- This enables support for the ARMv8 based Rockchip chipsets,
- like the RK3368.
-
-config ARCH_SEATTLE
-   bool "AMD Seattle SoC Family"
-   help
- This enables support for AMD Seattle SOC Family
-
-config ARCH_SHMOBILE
-   bool
-
-config ARCH_SYNQUACER
-   bool "Socionext SynQuacer SoC Family"
-
 config ARCH_RENESAS
bool "Renesas SoC Platforms"
-   select ARCH_SHMOBILE
select PINCTRL
select PM
select PM_GENERIC_DOMAINS
@@ -220,6 +197,25 @@ config ARCH_R8A77995
help
  This enables support for the Renesas R-Car D3 SoC.
 
+config ARCH_ROCKCHIP
+   bool "Rockchip Platforms"
+   select ARCH_HAS_RESET_CONTROLLER
+   select GPIOLIB
+   select PINCTRL
+   select PINCTRL_ROCKCHIP
+   select ROCKCHIP_TIMER
+   help
+ This enables support for the ARMv8 based Rockchip chipsets,
+ like the RK3368.
+
+config ARCH_SEATTLE
+   bool "AMD Seattle SoC Family"
+   help
+ This enables support for AMD Seattle SOC Family
+
+config ARCH_SYNQUACER
+   bool "Socionext SynQuacer SoC Family"
+
 config ARCH_STRATIX10
bool "Altera's Stratix 10 SoCFPGA Family"
help
-- 
2.7.4



[PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS

2018-04-20 Thread Geert Uytterhoeven
Hi all,

Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
ARM SoCs.  This patch series completes the conversion, by:
  1. Updating dependencies for drivers that weren't converted yet,
  2. Removing the ARCH_SHMOBILE Kconfig symbols on ARM and ARM64.

The first 6 patches can be applied independently by subsystem
maintainers.
The last two patches depend on the first 6 patches, and are thus marked
RFC.

Thanks for your comments!

Geert Uytterhoeven (8):
  arm: shmobile: Change platform dependency to ARCH_RENESAS
  dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS
  [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
  sh_eth: Change platform check to CONFIG_ARCH_RENESAS
  staging: emxx_udc: Change platform dependency to ARCH_RENESAS
  ASoC: sh: Update menu title and platform dependency
  [RFC] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol
  [RFC] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

 arch/arm/Kconfig  |  2 +-
 arch/arm/Makefile |  2 +-
 arch/arm/mach-shmobile/Kconfig|  4 ---
 arch/arm64/Kconfig.platforms  | 42 +
 drivers/dma/sh/shdmac.c   | 50 +++
 drivers/media/platform/Kconfig|  2 +-
 drivers/net/ethernet/renesas/sh_eth.h |  2 +-
 drivers/staging/emxx_udc/Kconfig  |  2 +-
 sound/soc/sh/Kconfig  |  4 +--
 9 files changed, 47 insertions(+), 63 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH 1/8] arm: shmobile: Change platform dependency to ARCH_RENESAS

2018-04-20 Thread Geert Uytterhoeven
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency than the legacy
ARCH_SHMOBILE, hence use the former.

This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 arch/arm/Kconfig  | 2 +-
 arch/arm/Makefile | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7f8e7f4b88fdd03..2d34c0a44877e85b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1467,7 +1467,7 @@ config ARM_PSCI
 config ARCH_NR_GPIO
int
default 2048 if ARCH_SOCFPGA
-   default 1024 if ARCH_BRCMSTB || ARCH_SHMOBILE || ARCH_TEGRA || \
+   default 1024 if ARCH_BRCMSTB || ARCH_RENESAS || ARCH_TEGRA || \
ARCH_ZYNQ
default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || \
SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e4e537f27339f7a1..a92f5a876d96839d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -212,7 +212,7 @@ machine-$(CONFIG_ARCH_S3C24XX)  += s3c24xx
 machine-$(CONFIG_ARCH_S3C64XX) += s3c64xx
 machine-$(CONFIG_ARCH_S5PV210) += s5pv210
 machine-$(CONFIG_ARCH_SA1100)  += sa1100
-machine-$(CONFIG_ARCH_SHMOBILE)+= shmobile
+machine-$(CONFIG_ARCH_RENESAS) += shmobile
 machine-$(CONFIG_ARCH_SIRF)+= prima2
 machine-$(CONFIG_ARCH_SOCFPGA) += socfpga
 machine-$(CONFIG_ARCH_STI) += sti
-- 
2.7.4



[PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS

2018-04-20 Thread Geert Uytterhoeven
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.

Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 drivers/net/ethernet/renesas/sh_eth.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/renesas/sh_eth.h 
b/drivers/net/ethernet/renesas/sh_eth.h
index a5b792ce2ae7d046..1bf930d4a1e52c18 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -163,7 +163,7 @@ enum {
 };
 
 /* Driver's parameters */
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_RENESAS)
 #define SH_ETH_RX_ALIGN32
 #else
 #define SH_ETH_RX_ALIGN2
-- 
2.7.4



[PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS

2018-04-20 Thread Geert Uytterhoeven
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.

Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check, just like before support for Renesas ARM SoCs was added.

Instead of blindly changing all the #ifdefs, switch the main code block
in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
remaining #ifdefs.

This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 drivers/dma/sh/shdmac.c | 50 +
 1 file changed, 21 insertions(+), 29 deletions(-)

diff --git a/drivers/dma/sh/shdmac.c b/drivers/dma/sh/shdmac.c
index 516f5487cc44cf96..8fcaae482ce0949a 100644
--- a/drivers/dma/sh/shdmac.c
+++ b/drivers/dma/sh/shdmac.c
@@ -440,7 +440,6 @@ static bool sh_dmae_reset(struct sh_dmae_device *shdev)
return ret;
 }
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
 static irqreturn_t sh_dmae_err(int irq, void *data)
 {
struct sh_dmae_device *shdev = data;
@@ -451,7 +450,6 @@ static irqreturn_t sh_dmae_err(int irq, void *data)
sh_dmae_reset(shdev);
return IRQ_HANDLED;
 }
-#endif
 
 static bool sh_dmae_desc_completed(struct shdma_chan *schan,
   struct shdma_desc *sdesc)
@@ -683,11 +681,8 @@ static int sh_dmae_probe(struct platform_device *pdev)
const struct sh_dmae_pdata *pdata;
unsigned long chan_flag[SH_DMAE_MAX_CHANNELS] = {};
int chan_irq[SH_DMAE_MAX_CHANNELS];
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
unsigned long irqflags = 0;
-   int errirq;
-#endif
-   int err, i, irq_cnt = 0, irqres = 0, irq_cap = 0;
+   int err, errirq, i, irq_cnt = 0, irqres = 0, irq_cap = 0;
struct sh_dmae_device *shdev;
struct dma_device *dma_dev;
struct resource *chan, *dmars, *errirq_res, *chanirq_res;
@@ -789,33 +784,32 @@ static int sh_dmae_probe(struct platform_device *pdev)
if (err)
goto rst_err;
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
-   chanirq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
+   if (IS_ENABLED(CONFIG_CPU_SH4) || IS_ENABLED(CONFIG_ARCH_RENESAS)) {
+   chanirq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
 
-   if (!chanirq_res)
-   chanirq_res = errirq_res;
-   else
-   irqres++;
+   if (!chanirq_res)
+   chanirq_res = errirq_res;
+   else
+   irqres++;
 
-   if (chanirq_res == errirq_res ||
-   (errirq_res->flags & IORESOURCE_BITS) == IORESOURCE_IRQ_SHAREABLE)
-   irqflags = IRQF_SHARED;
+   if (chanirq_res == errirq_res ||
+   (errirq_res->flags & IORESOURCE_BITS) == 
IORESOURCE_IRQ_SHAREABLE)
+   irqflags = IRQF_SHARED;
 
-   errirq = errirq_res->start;
+   errirq = errirq_res->start;
 
-   err = devm_request_irq(>dev, errirq, sh_dmae_err, irqflags,
-  "DMAC Address Error", shdev);
-   if (err) {
-   dev_err(>dev,
-   "DMA failed requesting irq #%d, error %d\n",
-   errirq, err);
-   goto eirq_err;
+   err = devm_request_irq(>dev, errirq, sh_dmae_err,
+  irqflags, "DMAC Address Error", shdev);
+   if (err) {
+   dev_err(>dev,
+   "DMA failed requesting irq #%d, error %d\n",
+   errirq, err);
+   goto eirq_err;
+   }
+   } else {
+   chanirq_res = errirq_res;
}
 
-#else
-   chanirq_res = errirq_res;
-#endif /* CONFIG_CPU_SH4 || CONFIG_ARCH_SHMOBILE */
-
if (chanirq_res->start == chanirq_res->end &&
!platform_get_resource(pdev, IORESOURCE_IRQ, 1)) {
/* Special case - all multiplexed */
@@ -881,9 +875,7 @@ static int sh_dmae_probe(struct platform_device *pdev)
 chan_probe_err:
sh_dmae_chan_remove(shdev);
 
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
 eirq_err:
-#endif
 rst_err:
spin_lock_irq(_dmae_lock);
list_del_rcu(>node);
-- 
2.7.4



[PATCH 5/8] staging: emxx_udc: Change platform dependency to ARCH_RENESAS

2018-04-20 Thread Geert Uytterhoeven
Emma Mobile is a Renesas ARM SoC.  Since commit 9b5ba0df4ea4f940 ("ARM:
shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate
platform dependency than the legacy ARCH_SHMOBILE, hence use the
former.

This will allow to drop ARCH_SHMOBILE on ARM in the near future.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 drivers/staging/emxx_udc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/emxx_udc/Kconfig b/drivers/staging/emxx_udc/Kconfig
index d7577096fb25ae7a..e50e722183648c55 100644
--- a/drivers/staging/emxx_udc/Kconfig
+++ b/drivers/staging/emxx_udc/Kconfig
@@ -1,6 +1,6 @@
 config USB_EMXX
tristate "EMXX USB Function Device Controller"
-   depends on USB_GADGET && (ARCH_SHMOBILE || (ARM && COMPILE_TEST))
+   depends on USB_GADGET && (ARCH_RENESAS || (ARM && COMPILE_TEST))
help
   The Emma Mobile series of SoCs from Renesas Electronics and
   former NEC Electronics include USB Function hardware.
-- 
2.7.4



[PATCH 6/8] ASoC: sh: Update menu title and platform dependency

2018-04-20 Thread Geert Uytterhoeven
Change the menu title to refer to "Renesas SoCs" instead of "SuperH", as
both SuperH and ARM SoCs are supported.

Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency for Renesas ARM
SoCs than the legacy ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the SUPERH
dependency.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 sound/soc/sh/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig
index 1aa5cd77ca24a06f..c1b7fb91e3063f2b 100644
--- a/sound/soc/sh/Kconfig
+++ b/sound/soc/sh/Kconfig
@@ -1,5 +1,5 @@
-menu "SoC Audio support for SuperH"
-   depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
+menu "SoC Audio support for Renesas SoCs"
+   depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
 
 config SND_SOC_PCM_SH7760
tristate "SoC Audio support for Renesas SH7760"
-- 
2.7.4



[PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

2018-04-20 Thread Geert Uytterhoeven
The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
only.  Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
than the legacy ARCH_SHMOBILE, hence use the former.

This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f9235e8f8e962d2e..7ad4725f9d1f9627 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -396,7 +396,7 @@ config VIDEO_SH_VEU
 config VIDEO_RENESAS_FDP1
tristate "Renesas Fine Display Processor"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
-- 
2.7.4



[PATCH v3 18/20] spi: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Mark Brown <broo...@kernel.org>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/spi/Kconfig | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2d4146ce2f1be49d..5a8524a3bc13f92d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -71,7 +71,6 @@ config SPI_ARMADA_3700
 
 config SPI_ATMEL
tristate "Atmel SPI Controller"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
help
  This selects a driver for the Atmel SPI Controller, present on
@@ -233,7 +232,6 @@ config SPI_EFM32
 
 config SPI_EP93XX
tristate "Cirrus Logic EP93xx SPI controller"
-   depends on HAS_DMA
depends on ARCH_EP93XX || COMPILE_TEST
help
  This enables using the Cirrus EP93xx SPI controller in master
@@ -355,7 +353,6 @@ config SPI_FSL_SPI
 config SPI_FSL_DSPI
tristate "Freescale DSPI controller"
select REGMAP_MMIO
-   depends on HAS_DMA
depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || M5441x || 
COMPILE_TEST
help
  This enables support for the Freescale DSPI controller in master
@@ -431,7 +428,6 @@ config SPI_OMAP_UWIRE
 
 config SPI_OMAP24XX
tristate "McSPI driver for OMAP"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select SG_SPLIT
help
@@ -440,7 +436,6 @@ config SPI_OMAP24XX
 
 config SPI_TI_QSPI
tristate "DRA7xxx QSPI controller support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
help
  QSPI master controller for DRA7xxx used for flash devices.
@@ -469,7 +464,6 @@ config SPI_PIC32
 config SPI_PIC32_SQI
tristate "Microchip PIC32 Quad SPI driver"
depends on MACH_PIC32 || COMPILE_TEST
-   depends on HAS_DMA
help
  SPI driver for PIC32 Quad SPI controller.
 
@@ -572,7 +566,7 @@ config SPI_SC18IS602
 
 config SPI_SH_MSIOF
tristate "SuperH MSIOF SPI controller"
-   depends on HAVE_CLK && HAS_DMA
+   depends on HAVE_CLK
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  SPI driver for SuperH and SH Mobile MSIOF blocks.
@@ -650,7 +644,7 @@ config SPI_MXS
 config SPI_TEGRA114
tristate "NVIDIA Tegra114 SPI Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for NVIDIA Tegra114 SPI Controller interface. This 
controller
  is different than the older SoCs SPI controller and also register 
interface
@@ -668,7 +662,7 @@ config SPI_TEGRA20_SFLASH
 config SPI_TEGRA20_SLINK
tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
 
-- 
2.7.4



[PATCH v3 13/20] mmc: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Ulf Hansson <ulf.hans...@linaro.org>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mmc/host/Kconfig | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c9046f14b1..3978d0418958bf6b 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller support"
depends on ARCH_MESON || COMPILE_TEST
depends on COMMON_CLK
-   depends on HAS_DMA
depends on OF
help
  This selects support for the SD/MMC Host Controller on
@@ -401,7 +400,6 @@ config MMC_OMAP
 
 config MMC_OMAP_HS
tristate "TI OMAP High Speed Multimedia Card Interface support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
help
  This selects the TI OMAP High Speed Multimedia card Interface.
@@ -511,7 +509,6 @@ config MMC_DAVINCI
 
 config MMC_GOLDFISH
tristate "goldfish qemu Multimedia Card Interface support"
-   depends on HAS_DMA
depends on GOLDFISH || COMPILE_TEST
help
  This selects the Goldfish Multimedia card Interface emulation
@@ -605,7 +602,7 @@ config MMC_SDHI
 
 config MMC_SDHI_SYS_DMAC
tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if (SUPERH || ARM)
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
 config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
depends on ARM64 || COMPILE_TEST
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if ARM64
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -669,7 +666,6 @@ config MMC_CAVIUM_THUNDERX
 
 config MMC_DW
tristate "Synopsys DesignWare Memory Card Interface"
-   depends on HAS_DMA
depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
help
  This selects support for the Synopsys DesignWare Mobile Storage IP
@@ -748,7 +744,6 @@ config MMC_DW_ZX
 
 config MMC_SH_MMCIF
tristate "SuperH Internal MMCIF support"
-   depends on HAS_DMA
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
help
  This selects the MMC Host Interface controller (MMCIF) found in 
various
@@ -868,7 +863,6 @@ config MMC_TOSHIBA_PCI
 config MMC_BCM2835
tristate "Broadcom BCM2835 SDHOST MMC Controller support"
depends on ARCH_BCM2835 || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the BCM2835 SDHOST MMC controller. If you have
  a BCM2835 platform with SD or MMC devices, say Y or M here.
-- 
2.7.4



[PATCH v3 19/20] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/staging/vc04_services/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/Kconfig 
b/drivers/staging/vc04_services/Kconfig
index f5aaf7d629f0fae9..98064ce2c2b47c7f 100644
--- a/drivers/staging/vc04_services/Kconfig
+++ b/drivers/staging/vc04_services/Kconfig
@@ -1,6 +1,5 @@
 menuconfig BCM_VIDEOCORE
tristate "Broadcom VideoCore support"
-   depends on HAS_DMA
depends on OF
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
default y
-- 
2.7.4



[PATCH v3 05/20] firewire: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/firewire/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 145974f9662b63e6..4199849e37585181 100644
--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -1,5 +1,4 @@
 menu "IEEE 1394 (FireWire) support"
-   depends on HAS_DMA
depends on PCI || COMPILE_TEST
# firewire-core does not depend on PCI but is
# not useful without PCI controller driver
-- 
2.7.4



[PATCH v3 12/20] media: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various VIDEOBUF*DMA* symbols had to loose their dependencies on
HAS_DMA, as they are selected by several individual drivers.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
  - Rebase to v4.17-rc1,
  - Handle new VIDEO_RENESAS_CEU symbol,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on
HAS_DMA,
  - Split per subsystem.
---
 drivers/media/common/videobuf2/Kconfig   |  2 --
 drivers/media/pci/dt3155/Kconfig |  1 -
 drivers/media/pci/intel/ipu3/Kconfig |  1 -
 drivers/media/pci/solo6x10/Kconfig   |  1 -
 drivers/media/pci/sta2x11/Kconfig|  1 -
 drivers/media/pci/tw5864/Kconfig |  1 -
 drivers/media/pci/tw686x/Kconfig |  1 -
 drivers/media/platform/Kconfig   | 42 ++--
 drivers/media/platform/am437x/Kconfig|  2 +-
 drivers/media/platform/atmel/Kconfig |  4 +--
 drivers/media/platform/davinci/Kconfig   |  6 
 drivers/media/platform/marvell-ccic/Kconfig  |  3 +-
 drivers/media/platform/rcar-vin/Kconfig  |  2 +-
 drivers/media/platform/soc_camera/Kconfig|  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig |  2 +-
 drivers/media/v4l2-core/Kconfig  |  2 --
 drivers/staging/media/davinci_vpfe/Kconfig   |  1 -
 drivers/staging/media/omap4iss/Kconfig   |  1 -
 18 files changed, 21 insertions(+), 55 deletions(-)

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index 17c32ea58395d78f..4ed11b46676ac4d0 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS
 
 config VIDEOBUF2_DMA_CONTIG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
select DMA_SHARED_BUFFER
@@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC
 
 config VIDEOBUF2_DMA_SG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
 
diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig
index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644
--- a/drivers/media/pci/dt3155/Kconfig
+++ b/drivers/media/pci/dt3155/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_DT3155
tristate "DT3155 frame grabber"
depends on PCI && VIDEO_DEV && VIDEO_V4L2
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
---help---
diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index a82d3fe277d2cdec..2533ec1cb1177715 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2
depends on VIDEO_V4L2_SUBDEV_API
depends on X86 || COMPILE_TEST
depends on MEDIA_CONTROLLER
-   depends on HAS_DMA
depends on ACPI
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/pci/solo6x10/Kconfig 
b/drivers/media/pci/solo6x10/Kconfig
index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644
--- a/drivers/media/pci/solo6x10/Kconfig
+++ b/drivers/media/pci/solo6x10/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_SOLO6X10
tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)"
depends on PCI && VIDEO_DEV && SND && I2C
-   depends on HAS_DMA
select BITREVERSE
select FONT_SUPPORT
select FONT_8x16
diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index e03587b1af714199..7b856395ede9295c 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,7 +1,6 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
depends on STA2X11
-   depends on HAS_DMA
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
diff --git a/drivers/media/pci/tw5864/Kconfig b/drivers/media/pci/tw5864/Kconfig
index 87c8f327e2d49dfa..760fb11dfeaef47b 100644
--- a/drivers/media/pci/tw5864/Kconfig
+++ b/drivers/media/pci/tw5864/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_TW5864
  

[PATCH v3 07/20] i2c: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/i2c/busses/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c4865b08d7fb9e3b..8d21b9825d71764d 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -707,7 +707,6 @@ config I2C_MPC
 config I2C_MT65XX
tristate "MediaTek I2C adapter"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the MediaTek(R) Integrated Inter Circuit bus driver
  for MT65xx and MT81xx.
@@ -885,7 +884,6 @@ config I2C_SH7760
 
 config I2C_SH_MOBILE
tristate "SuperH Mobile I2C Controller"
-   depends on HAS_DMA
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  If you say yes to this option, support will be included for the
@@ -1098,7 +1096,6 @@ config I2C_XLP9XX
 
 config I2C_RCAR
tristate "Renesas R-Car I2C Controller"
-   depends on HAS_DMA
depends on ARCH_RENESAS || COMPILE_TEST
select I2C_SLAVE
help
-- 
2.7.4



[PATCH v3 14/20] mtd: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop new dependency of MTD_NAND_MARVELL on HAS_DMA,
  - Split per subsystem.
---
 drivers/mtd/nand/raw/Kconfig | 8 ++--
 drivers/mtd/spi-nor/Kconfig  | 2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 19a2b283fbbe627e..6871ff0fd300bb81 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -46,7 +46,7 @@ config MTD_NAND_DENALI
 config MTD_NAND_DENALI_PCI
 tristate "Support Denali NAND controller on Intel Moorestown"
select MTD_NAND_DENALI
-   depends on HAS_DMA && PCI
+   depends on PCI
 help
   Enable the driver for NAND flash on Intel Moorestown, using the
   Denali NAND controller core.
@@ -152,7 +152,6 @@ config MTD_NAND_S3C2410_CLKSTOP
 config MTD_NAND_TANGO
tristate "NAND Flash support for Tango chips"
depends on ARCH_TANGO || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables the NAND Flash controller on Tango chips.
 
@@ -285,7 +284,7 @@ config MTD_NAND_MARVELL
tristate "NAND controller support on Marvell boards"
depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU || \
   COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables the NAND flash controller driver for Marvell boards,
  including:
@@ -447,7 +446,6 @@ config MTD_NAND_SH_FLCTL
tristate "Support for NAND on Renesas SuperH FLCTL"
depends on SUPERH || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
help
  Several Renesas SuperH CPU has FLCTL. This option enables support
  for NAND Flash using FLCTL.
@@ -515,7 +513,6 @@ config MTD_NAND_SUNXI
 config MTD_NAND_HISI504
tristate "Support for NAND controller on Hisilicon SoC Hip04"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on Hisilicon SoC Hip04.
 
@@ -529,7 +526,6 @@ config MTD_NAND_QCOM
 config MTD_NAND_MTK
tristate "Support for NAND controller on MTK SoCs"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on MTK SoCs.
  This controller is found on mt27xx, mt81xx, mt65xx SoCs.
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 89da88e591215db1..c493b8230a38c059 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -71,7 +71,7 @@ config SPI_FSL_QUADSPI
 config SPI_HISI_SFC
tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables support for hisilicon SPI-NOR flash controller.
 
-- 
2.7.4



[PATCH v3 06/20] fpga: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Alan Tull <at...@kernel.org>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/fpga/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index f47ef848bcd056d5..fd539132542e30ee 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -53,7 +53,6 @@ config FPGA_MGR_ALTERA_CVP
 config FPGA_MGR_ZYNQ_FPGA
tristate "Xilinx Zynq FPGA"
depends on ARCH_ZYNQ || COMPILE_TEST
-   depends on HAS_DMA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
-- 
2.7.4



[PATCH v3 16/20] remoteproc: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Bjorn Andersson <bjorn.anders...@linaro.org>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/remoteproc/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 027274008b086d6f..cd1c168fd18898dc 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -24,7 +24,6 @@ config IMX_REMOTEPROC
 
 config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
-   depends on HAS_DMA
depends on ARCH_OMAP4 || SOC_OMAP5
depends on OMAP_IOMMU
select MAILBOX
-- 
2.7.4



[PATCH v3 00/20] Allow compile-testing NO_DMA (drivers)

2018-04-17 Thread Geert Uytterhoeven
Hi all,

As of v4.17-rc1, patch series "[PATCH v2 0/5] Allow compile-testing
NO_DMA (core)" (https://lkml.org/lkml/2018/3/16/435) has been included
upstream, and drivers using the DMA API can be compile-tested on
platforms selecting NO_DMA.

This follow-up patch series removes dependencies on HAS_DMA for symbols
that already have platform dependencies implying HAS_DMA, which increases
compile-coverage.

Please apply to your tree if appropriate.

Changes compared to v2:
  - Add Acked-by,
  - Rebased to v4.17-rc1, dropping applied patch for scsi/hisi_sas,
  - Handle new VIDEO_RENESAS_CEU symbol,
  - Drop obsolete note about FSL_FMAN.

Changes compared to v1:
  - Add Reviewed-by, Acked-by,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
MTD_NAND_MARVELL on HAS_DMA,
  - Split in per-subsystem patches,
  - Split-off the core part in a separate series.

This series is against v4.17-rc1. It can also be found at
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v3

It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.

Thanks for applying!

Geert Uytterhoeven (20):
  ASoC: Remove depends on HAS_DMA in case of platform dependency
  ata: Remove depends on HAS_DMA in case of platform dependency
  crypto: Remove depends on HAS_DMA in case of platform dependency
  fbdev: Remove depends on HAS_DMA in case of platform dependency
  firewire: Remove depends on HAS_DMA in case of platform dependency
  fpga: Remove depends on HAS_DMA in case of platform dependency
  i2c: Remove depends on HAS_DMA in case of platform dependency
  iio: adc: Remove depends on HAS_DMA in case of platform dependency
  iommu: Remove depends on HAS_DMA in case of platform dependency
  lightnvm: Remove depends on HAS_DMA in case of platform dependency
  mailbox: Remove depends on HAS_DMA in case of platform dependency
  media: Remove depends on HAS_DMA in case of platform dependency
  mmc: Remove depends on HAS_DMA in case of platform dependency
  mtd: Remove depends on HAS_DMA in case of platform dependency
  net: Remove depends on HAS_DMA in case of platform dependency
  remoteproc: Remove depends on HAS_DMA in case of platform dependency
  serial: Remove depends on HAS_DMA in case of platform dependency
  spi: Remove depends on HAS_DMA in case of platform dependency
  staging: vc04_services: Remove depends on HAS_DMA in case of platform
dependency
  usb: Remove depends on HAS_DMA in case of platform dependency

 drivers/ata/Kconfig |  2 --
 drivers/crypto/Kconfig  | 14 +++--
 drivers/firewire/Kconfig|  1 -
 drivers/fpga/Kconfig|  1 -
 drivers/i2c/busses/Kconfig  |  3 --
 drivers/iio/adc/Kconfig |  2 --
 drivers/iommu/Kconfig   |  5 ++-
 drivers/lightnvm/Kconfig|  2 +-
 drivers/mailbox/Kconfig |  2 --
 drivers/media/common/videobuf2/Kconfig  |  2 --
 drivers/media/pci/dt3155/Kconfig|  1 -
 drivers/media/pci/intel/ipu3/Kconfig|  1 -
 drivers/media/pci/solo6x10/Kconfig  |  1 -
 drivers/media/pci/sta2x11/Kconfig   |  1 -
 drivers/media/pci/tw5864/Kconfig|  1 -
 drivers/media/pci/tw686x/Kconfig|  1 -
 drivers/media/platform/Kconfig  | 42 +
 drivers/media/platform/am437x/Kconfig   |  2 +-
 drivers/media/platform/atmel/Kconfig|  4 +--
 drivers/media/platform/davinci/Kconfig  |  6 
 drivers/media/platform/marvell-ccic/Kconfig |  3 +-
 drivers/media/platform/rcar-vin/Kconfig |  2 +-
 drivers/media/platform/soc_camera/Kconfig   |  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig|  2 +-
 drivers/media/v4l2-core/Kconfig |  2 --
 drivers/mmc/host/Kconfig| 10 ++
 drivers/mtd/nand/raw/Kconfig|  8 ++---
 drivers/mtd/spi-nor/Kconfig |  2 +-
 drivers/net/ethernet/amd/Kconfig|  2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   |  1 -
 drivers/net/ethernet/apm/xgene/Kconfig  |  1 -
 drivers/net/ethernet/arc/Kconfig|  6 ++--
 drivers/net/ethernet/broadcom/Kconfig   |  2 --
 drivers/net/ethernet/calxeda/Kconfig|  2 +-
 drivers/net/ethernet/hisilicon/Kconfig  |  2 +-
 drivers/net/ethernet/marvell/Kconfig|  8 ++---
 drivers/net/ethernet/mellanox/mlxsw/Kconfig |  2 +-
 drivers/net/ethernet/renesas/Kconfig|  2 --
 drivers/net/wireless/broadcom/brcm80211/Kconfig |  1 -
 drivers/net/wireless/quanten

[PATCH v3 02/20] ata: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/ata/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 2b16e7c8fff35764..39b181d6bd0d8cf2 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -398,7 +398,6 @@ config SATA_DWC_VDEBUG
 
 config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
-   depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
  This option enables support for the Calxeda Highbank SoC's
@@ -408,7 +407,6 @@ config SATA_HIGHBANK
 
 config SATA_MV
tristate "Marvell SATA support"
-   depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
   ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
-- 
2.7.4



[PATCH v3 11/20] mailbox: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
  - Rebase to v4.17-rc1,
  - Removed bogus notes,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mailbox/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index a2bb27446dce4e2b..725dce5ba62d5baf 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -162,7 +162,6 @@ config XGENE_SLIMPRO_MBOX
 config BCM_PDC_MBOX
tristate "Broadcom FlexSparx DMA Mailbox"
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
help
  Mailbox implementation for the Broadcom FlexSparx DMA ring manager,
  which provides access to various offload engines on Broadcom
@@ -172,7 +171,6 @@ config BCM_FLEXRM_MBOX
tristate "Broadcom FlexRM Mailbox"
depends on ARM64
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
select GENERIC_MSI_IRQ_DOMAIN
default m if ARCH_BCM_IPROC
help
-- 
2.7.4



[PATCH v3 03/20] crypto: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Herbert Xu <herb...@gondor.apana.org.au>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/crypto/Kconfig | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index d1ea1a07cecbb36c..3dbc47528667b77c 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG
 config CRYPTO_DEV_S5P
tristate "Support for Samsung S5PV210/Exynos crypto accelerator"
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_BLKCIPHER
help
@@ -466,7 +466,6 @@ endif # if CRYPTO_DEV_UX500
 
 config CRYPTO_DEV_ATMEL_AUTHENC
tristate "Support for Atmel IPSEC/SSL hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AUTHENC
select CRYPTO_DEV_ATMEL_AES
@@ -479,7 +478,6 @@ config CRYPTO_DEV_ATMEL_AUTHENC
 
 config CRYPTO_DEV_ATMEL_AES
tristate "Support for Atmel AES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -494,7 +492,6 @@ config CRYPTO_DEV_ATMEL_AES
 
 config CRYPTO_DEV_ATMEL_TDES
tristate "Support for Atmel DES/TDES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_DES
select CRYPTO_BLKCIPHER
@@ -508,7 +505,6 @@ config CRYPTO_DEV_ATMEL_TDES
 
 config CRYPTO_DEV_ATMEL_SHA
tristate "Support for Atmel SHA hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_HASH
help
@@ -574,7 +570,8 @@ config CRYPTO_DEV_CAVIUM_ZIP
 
 config CRYPTO_DEV_QCE
tristate "Qualcomm crypto engine accelerator"
-   depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_DES
select CRYPTO_ECB
@@ -598,7 +595,6 @@ source "drivers/crypto/vmx/Kconfig"
 config CRYPTO_DEV_IMGTEC_HASH
tristate "Imagination Technologies hardware hash accelerator"
depends on MIPS || COMPILE_TEST
-   depends on HAS_DMA
select CRYPTO_MD5
select CRYPTO_SHA1
select CRYPTO_SHA256
@@ -650,7 +646,6 @@ config CRYPTO_DEV_ROCKCHIP
 
 config CRYPTO_DEV_MEDIATEK
tristate "MediaTek's EIP97 Cryptographic Engine driver"
-   depends on HAS_DMA
depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -688,7 +683,7 @@ source "drivers/crypto/stm32/Kconfig"
 
 config CRYPTO_DEV_SAFEXCEL
tristate "Inside Secure's SafeXcel cryptographic engine driver"
-   depends on HAS_DMA && OF
+   depends on OF
depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT)
select CRYPTO_AES
select CRYPTO_BLKCIPHER
@@ -706,7 +701,6 @@ config CRYPTO_DEV_SAFEXCEL
 config CRYPTO_DEV_ARTPEC6
tristate "Support for Axis ARTPEC-6/7 hardware crypto acceleration."
depends on ARM && (ARCH_ARTPEC || COMPILE_TEST)
-   depends on HAS_DMA
depends on OF
select CRYPTO_AEAD
select CRYPTO_AES
-- 
2.7.4



[PATCH v3 09/20] iommu: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Joerg Roedel <jroe...@suse.de>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iommu/Kconfig | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index df171cb8582296b9..c76157e57f6ba4ba 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -23,7 +23,7 @@ config IOMMU_IO_PGTABLE
 config IOMMU_IO_PGTABLE_LPAE
bool "ARMv7/v8 Long Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || (COMPILE_TEST && 
!GENERIC_ATOMIC64))
+   depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
help
  Enable support for the ARM long descriptor pagetable format.
  This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page
@@ -42,7 +42,7 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
 config IOMMU_IO_PGTABLE_ARMV7S
bool "ARMv7/v8 Short Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST)
+   depends on ARM || ARM64 || COMPILE_TEST
help
  Enable support for the ARM Short-descriptor pagetable format.
  This supports 32-bit virtual and physical addresses mapped using
@@ -376,7 +376,6 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on HAS_DMA
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
-- 
2.7.4



[PATCH v3 01/20] ASoC: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various SND_SOC_LPASS_* symbols had to loose their dependencies
on HAS_DMA, as they are selected by SND_SOC_STORM and/or
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Mark Brown <broo...@kernel.org>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Split per subsystem.
---
 sound/soc/bcm/Kconfig  | 3 +--
 sound/soc/kirkwood/Kconfig | 1 -
 sound/soc/pxa/Kconfig  | 1 -
 sound/soc/qcom/Kconfig | 7 ++-
 4 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index edf367100ebd2f17..02f50b7a966ff262 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -11,9 +11,8 @@ config SND_BCM2835_SOC_I2S
 config SND_SOC_CYGNUS
tristate "SoC platform audio for Broadcom Cygnus chips"
depends on ARCH_BCM_CYGNUS || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y if you want to add support for ASoC audio on Broadcom
  Cygnus chips (bcm958300, bcm958305, bcm911360)
 
- If you don't know what to do here, say N.
\ No newline at end of file
+ If you don't know what to do here, say N.
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index bc3c7b5ac752e471..132bb83f8e99aff3 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,7 +1,6 @@
 config SND_KIRKWOOD_SOC
tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
depends on ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y or M if you want to add support for codecs attached to
  the Kirkwood I2S interface. You will also need to select the
diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index 484ab3c2ad672fc8..960744e46edc0549 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -1,7 +1,6 @@
 config SND_PXA2XX_SOC
tristate "SoC Audio for the Intel PXA2xx chip"
depends on ARCH_PXA || COMPILE_TEST
-   depends on HAS_DMA
select SND_PXA2XX_LIB
help
  Say Y or M if you want to add support for codecs attached to
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 8ec9a074b38bd702..3cc252e55468eaab 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -11,24 +11,21 @@ config SND_SOC_LPASS_CPU
 
 config SND_SOC_LPASS_PLATFORM
tristate
-   depends on HAS_DMA
select REGMAP_MMIO
 
 config SND_SOC_LPASS_IPQ806X
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_LPASS_APQ8016
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_IPQ806X
select SND_SOC_MAX98357A
help
@@ -37,7 +34,7 @@ config SND_SOC_STORM
 
 config SND_SOC_APQ8016_SBC
tristate "SoC Audio support for APQ8016 SBC platforms"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_APQ8016
help
   Support for Qualcomm Technologies LPASS audio block in
-- 
2.7.4



[PATCH v3 20/20] usb: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> [drivers/usb/gadget/]
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/usb/gadget/udc/Kconfig | 4 ++--
 drivers/usb/mtu3/Kconfig   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee9395..9c3b4f86965e80c7 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -179,7 +179,7 @@ config USB_R8A66597
 
 config USB_RENESAS_USBHS_UDC
tristate 'Renesas USBHS controller'
-   depends on USB_RENESAS_USBHS && HAS_DMA
+   depends on USB_RENESAS_USBHS
help
   Renesas USBHS is a discrete USB host and peripheral controller chip
   that supports both full and high speed USB 2.0 data transfers.
@@ -192,7 +192,7 @@ config USB_RENESAS_USBHS_UDC
 config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
-   depends on EXTCON && HAS_DMA
+   depends on EXTCON
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd61947beea51e..c0c0eb88e5eafc74 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
 
 config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
-   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on EXTCON && (USB || USB_GADGET)
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
-- 
2.7.4



[PATCH v3 10/20] lightnvm: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Reviewed-by: Matias Bjørling <m...@lightnvm.io>
---
v3:
  - Add Reviewed-by,
  - Rebase to v4.17-rc1,
  - Removed bogus notes,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/lightnvm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
index 10c08982185a572f..9c03f35d9df113c6 100644
--- a/drivers/lightnvm/Kconfig
+++ b/drivers/lightnvm/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig NVM
bool "Open-Channel SSD target support"
-   depends on BLOCK && HAS_DMA && PCI
+   depends on BLOCK && PCI
select BLK_DEV_NVME
help
  Say Y here to get to enable Open-channel SSDs.
-- 
2.7.4



[PATCH v3 04/20] fbdev: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/video/fbdev/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index d94254263ea5caa7..4f9853ec1721950f 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2075,7 +2075,8 @@ config FB_XILINX
 
 config FB_GOLDFISH
tristate "Goldfish Framebuffer"
-   depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST)
+   depends on FB
+   depends on GOLDFISH || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.7.4



[PATCH v3 15/20] net: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
  - Rebase to v4.17-rc1,
  - Drop obsolete note about FSL_FMAN,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/net/ethernet/amd/Kconfig| 2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   | 1 -
 drivers/net/ethernet/apm/xgene/Kconfig  | 1 -
 drivers/net/ethernet/arc/Kconfig| 6 --
 drivers/net/ethernet/broadcom/Kconfig   | 2 --
 drivers/net/ethernet/calxeda/Kconfig| 2 +-
 drivers/net/ethernet/hisilicon/Kconfig  | 2 +-
 drivers/net/ethernet/marvell/Kconfig| 8 +++-
 drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
 drivers/net/ethernet/renesas/Kconfig| 2 --
 drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
 drivers/net/wireless/quantenna/qtnfmac/Kconfig  | 2 +-
 12 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index d5c15e8bb3de706b..f273af136fc7c995 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -173,7 +173,7 @@ config SUNLANCE
 
 config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
-   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && 
HAS_DMA
+   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM
depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
diff --git a/drivers/net/ethernet/apm/xgene-v2/Kconfig 
b/drivers/net/ethernet/apm/xgene-v2/Kconfig
index 1205861b631896a0..eedd3f3dd22e2201 100644
--- a/drivers/net/ethernet/apm/xgene-v2/Kconfig
+++ b/drivers/net/ethernet/apm/xgene-v2/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE_V2
tristate "APM X-Gene SoC Ethernet-v2 Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
help
  This is the Ethernet driver for the on-chip ethernet interface
diff --git a/drivers/net/ethernet/apm/xgene/Kconfig 
b/drivers/net/ethernet/apm/xgene/Kconfig
index afccb033177b3923..e4e33c900b577161 100644
--- a/drivers/net/ethernet/apm/xgene/Kconfig
+++ b/drivers/net/ethernet/apm/xgene/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE
tristate "APM X-Gene SoC Ethernet Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
select PHYLIB
select MDIO_XGENE
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index e743ddf46343302f..5d0ab8e74b680cc6 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -24,7 +24,8 @@ config ARC_EMAC_CORE
 config ARC_EMAC
tristate "ARC EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && HAS_DMA && (ARC || COMPILE_TEST)
+   depends on OF_IRQ && OF_NET
+   depends on ARC || COMPILE_TEST
---help---
  On some legacy ARC (Synopsys) FPGA boards such as ARCAngel4/ML50x
  non-standard on-chip ethernet device ARC EMAC 10/100 is used.
@@ -33,7 +34,8 @@ config ARC_EMAC
 config EMAC_ROCKCHIP
tristate "Rockchip EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA && (ARCH_ROCKCHIP 
|| COMPILE_TEST)
+   depends on OF_IRQ && OF_NET && REGULATOR
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
---help---
  Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers.
  This selects Rockchip SoC glue layer support for the
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index af75156919edfead..4c3bfde6e8de00f2 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -157,7 +157,6 @@ config BGMAC
 config BGMAC_BCMA
tristate "Broadcom iProc GBit BCMA support"
depends on BCMA && BCMA_HOST_SOC
-   depends on HAS_DMA
depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST
select BGMAC
select PHYLIB
@@ -170,7 +169,6 @@ config BGMAC_BCMA
 
 config BGMAC_PLATFORM
tristate "Broadcom iProc GBit platform support"
-   depends on HAS_DMA

[PATCH v3 08/20] iio: adc: Remove depends on HAS_DMA in case of platform dependency

2018-04-17 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Jonathan Cameron <jonathan.came...@huawei.com>
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iio/adc/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 15606f237480dacb..88bbcd0e98632273 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -157,7 +157,6 @@ config AT91_SAMA5D2_ADC
tristate "Atmel AT91 SAMA5D2 ADC"
depends on ARCH_AT91 || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
select IIO_TRIGGERED_BUFFER
help
  Say yes here to build support for Atmel SAMA5D2 ADC which is
@@ -646,7 +645,6 @@ config SD_ADC_MODULATOR
 config STM32_ADC_CORE
tristate "STMicroelectronics STM32 adc core"
depends on ARCH_STM32 || COMPILE_TEST
-   depends on HAS_DMA
depends on OF
depends on REGULATOR
select IIO_BUFFER
-- 
2.7.4



Re: [PATCH v7] media: platform: Renesas IMR driver

2018-04-16 Thread Geert Uytterhoeven
Hi Sergei,

On Fri, Aug 4, 2017 at 8:03 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> The image renderer, or the distortion correction engine, is a drawing
> processor with a simple instruction system capable of referencing video
> capture data or data in an external memory as the 2D texture data and
> performing texture mapping and drawing with respect to any shape that is
> split into triangular objects.
>
> This V4L2 memory-to-memory device driver only supports image renderer light
> extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
> can be added later...
>
> Based on the original patch by Konstantin Kozhevnikov.
>
> Signed-off-by: Konstantin Kozhevnikov 
> <konstantin.kozhevni...@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> Acked-by: Rob Herring <r...@kernel.org>

>  Documentation/devicetree/bindings/media/rcar_imr.txt |   27
>  Documentation/media/v4l-drivers/index.rst|1
>  Documentation/media/v4l-drivers/rcar_imr.rst |  372 +++
>  drivers/media/platform/Kconfig   |   13
>  drivers/media/platform/Makefile  |1
>  drivers/media/platform/rcar_imr.c| 1832 
> +++
>  include/uapi/linux/rcar_imr.h|  182 +
>  7 files changed, 2428 insertions(+)

What's the status of this patch?
The compatible value "renesas,r8a7796-imr-lx4" has been in use since v4.14.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

2018-04-05 Thread Geert Uytterhoeven
On Wed, Apr 4, 2018 at 5:26 PM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
> On Thursday, 29 March 2018 14:30:39 EEST Maxime Ripard wrote:
>> On Tue, Feb 13, 2018 at 12:01:32AM +0100, Niklas Söderlund wrote:
>> > +   switch (priv->lanes) {
>> > +   case 1:
>> > +   phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_0;
>> > +   break;
>> > +   case 2:
>> > +   phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_1 | PHYCNT_ENABLE_0;
>> > +   break;
>> > +   case 4:
>> > +   phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_3 | PHYCNT_ENABLE_2 |
>> > +   PHYCNT_ENABLE_1 | PHYCNT_ENABLE_0;
>> > +   break;
>> > +   default:
>> > +   return -EINVAL;
>> > +   }
>>
>> I guess you could have a simpler construct here using this:
>>
>> phycnt = PHYCNT_ENABLECLK;
>>
>> switch (priv->lanes) {
>> case 4:
>>   phycnt |= PHYCNT_ENABLE_3 | PHYCNT_ENABLE_2;
>> case 2:
>>   phycnt |= PHYCNT_ENABLE_1;
>> case 1:
>>   phycnt |= PHYCNT_ENABLE_0;
>>   break;
>>
>> default:
>>   return -EINVAL;
>> }
>>
>> But that's really up to you.
>
> Wouldn't Niklas' version generate simpler code as it uses direct assignments ?

Alternatively, you could check for a valid number of lanes, and use knowledge
about the internal lane bits:

phycnt = PHYCNT_ENABLECLK;
phycnt |= (1 << priv->lanes) - 1;

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH v2 04/21] fbdev: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/video/fbdev/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 11e699f1062b78ea..abee481f5fb778dd 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2174,7 +2174,8 @@ config FB_XILINX
 
 config FB_GOLDFISH
tristate "Goldfish Framebuffer"
-   depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST)
+   depends on FB
+   depends on GOLDFISH || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.7.4



[PATCH v2 01/21] ASoC: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various SND_SOC_LPASS_* symbols had to loose their dependencies
on HAS_DMA, as they are selected by SND_SOC_STORM and/or
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Split per subsystem.
---
 sound/soc/bcm/Kconfig  | 3 +--
 sound/soc/kirkwood/Kconfig | 1 -
 sound/soc/pxa/Kconfig  | 1 -
 sound/soc/qcom/Kconfig | 7 ++-
 4 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index edf367100ebd2f17..02f50b7a966ff262 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -11,9 +11,8 @@ config SND_BCM2835_SOC_I2S
 config SND_SOC_CYGNUS
tristate "SoC platform audio for Broadcom Cygnus chips"
depends on ARCH_BCM_CYGNUS || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y if you want to add support for ASoC audio on Broadcom
  Cygnus chips (bcm958300, bcm958305, bcm911360)
 
- If you don't know what to do here, say N.
\ No newline at end of file
+ If you don't know what to do here, say N.
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index bc3c7b5ac752e471..132bb83f8e99aff3 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,7 +1,6 @@
 config SND_KIRKWOOD_SOC
tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
depends on ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y or M if you want to add support for codecs attached to
  the Kirkwood I2S interface. You will also need to select the
diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index 484ab3c2ad672fc8..960744e46edc0549 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -1,7 +1,6 @@
 config SND_PXA2XX_SOC
tristate "SoC Audio for the Intel PXA2xx chip"
depends on ARCH_PXA || COMPILE_TEST
-   depends on HAS_DMA
select SND_PXA2XX_LIB
help
  Say Y or M if you want to add support for codecs attached to
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 8ec9a074b38bd702..3cc252e55468eaab 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -11,24 +11,21 @@ config SND_SOC_LPASS_CPU
 
 config SND_SOC_LPASS_PLATFORM
tristate
-   depends on HAS_DMA
select REGMAP_MMIO
 
 config SND_SOC_LPASS_IPQ806X
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_LPASS_APQ8016
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_IPQ806X
select SND_SOC_MAX98357A
help
@@ -37,7 +34,7 @@ config SND_SOC_STORM
 
 config SND_SOC_APQ8016_SBC
tristate "SoC Audio support for APQ8016 SBC platforms"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_APQ8016
help
   Support for Qualcomm Technologies LPASS audio block in
-- 
2.7.4



[PATCH v2 16/21] remoteproc: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/remoteproc/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index b609e1d3654ba65f..b60d8132113de0f7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -23,7 +23,6 @@ config IMX_REMOTEPROC
 
 config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
-   depends on HAS_DMA
depends on ARCH_OMAP4 || SOC_OMAP5
depends on OMAP_IOMMU
select MAILBOX
-- 
2.7.4



[PATCH v2 03/21] crypto: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/crypto/Kconfig | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4b741b83e23ff4de..3d27da7a430c0bc2 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG
 config CRYPTO_DEV_S5P
tristate "Support for Samsung S5PV210/Exynos crypto accelerator"
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_BLKCIPHER
help
@@ -473,7 +473,6 @@ config CRYPTO_DEV_BFIN_CRC
 
 config CRYPTO_DEV_ATMEL_AUTHENC
tristate "Support for Atmel IPSEC/SSL hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AUTHENC
select CRYPTO_DEV_ATMEL_AES
@@ -486,7 +485,6 @@ config CRYPTO_DEV_ATMEL_AUTHENC
 
 config CRYPTO_DEV_ATMEL_AES
tristate "Support for Atmel AES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -501,7 +499,6 @@ config CRYPTO_DEV_ATMEL_AES
 
 config CRYPTO_DEV_ATMEL_TDES
tristate "Support for Atmel DES/TDES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_DES
select CRYPTO_BLKCIPHER
@@ -515,7 +512,6 @@ config CRYPTO_DEV_ATMEL_TDES
 
 config CRYPTO_DEV_ATMEL_SHA
tristate "Support for Atmel SHA hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_HASH
help
@@ -581,7 +577,8 @@ config CRYPTO_DEV_CAVIUM_ZIP
 
 config CRYPTO_DEV_QCE
tristate "Qualcomm crypto engine accelerator"
-   depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_DES
select CRYPTO_ECB
@@ -605,7 +602,6 @@ source "drivers/crypto/vmx/Kconfig"
 config CRYPTO_DEV_IMGTEC_HASH
tristate "Imagination Technologies hardware hash accelerator"
depends on MIPS || COMPILE_TEST
-   depends on HAS_DMA
select CRYPTO_MD5
select CRYPTO_SHA1
select CRYPTO_SHA256
@@ -657,7 +653,6 @@ config CRYPTO_DEV_ROCKCHIP
 
 config CRYPTO_DEV_MEDIATEK
tristate "MediaTek's EIP97 Cryptographic Engine driver"
-   depends on HAS_DMA
depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -695,7 +690,7 @@ source "drivers/crypto/stm32/Kconfig"
 
 config CRYPTO_DEV_SAFEXCEL
tristate "Inside Secure's SafeXcel cryptographic engine driver"
-   depends on HAS_DMA && OF
+   depends on OF
depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT)
select CRYPTO_AES
select CRYPTO_BLKCIPHER
@@ -713,7 +708,6 @@ config CRYPTO_DEV_SAFEXCEL
 config CRYPTO_DEV_ARTPEC6
tristate "Support for Axis ARTPEC-6/7 hardware crypto acceleration."
depends on ARM && (ARCH_ARTPEC || COMPILE_TEST)
-   depends on HAS_DMA
depends on OF
select CRYPTO_AEAD
select CRYPTO_AES
-- 
2.7.4



[PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Notes:
  - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(),
which does not exist if HAS_DMA=n (Do we need a dummy? The use of
set_dma_ops() in this driver is questionable),
  - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
dependency on HAS_DMA, as they are selected from
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/lightnvm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
index 10c08982185a572f..9c03f35d9df113c6 100644
--- a/drivers/lightnvm/Kconfig
+++ b/drivers/lightnvm/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig NVM
bool "Open-Channel SSD target support"
-   depends on BLOCK && HAS_DMA && PCI
+   depends on BLOCK && PCI
select BLK_DEV_NVME
help
  Say Y here to get to enable Open-channel SSDs.
-- 
2.7.4



[PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

2018-03-16 Thread Geert Uytterhoeven
Hi all,

If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
symbol bad_dma_ops, thus causing a link failure if it is ever used.

The intention of this is twofold:
  1. To catch users of the DMA API on systems that do no support the DMA
 mapping API,
  2. To avoid building drivers that cannot work on such systems anyway.

However, the disadvantage is that we have to keep on adding dependencies
on HAS_DMA all over the place.

Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
already covering intention #2.  Having to add an explicit dependency on
HAS_DMA here is cumbersome, and hinders compile-testing.

Hence I think the time is ripe to reconsider the link failure.
Patch series "[PATCH v2 0/5] Allow compile-testing NO_DMA (core)"
(https://lkml.org/lkml/2018/3/16/435) already:
  - Changed get_dma_ops() to return NULL instead,
  - Added a few more dummies to enable compile-testing.

This patch series:
  - Removes dependencies on HAS_DMA for symbols that already have
platform dependencies implying HAS_DMA.

To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
this (drivers) series should be applied after the previous (core)
series (but not many people may notice/care ;-)

Changes compared to v1:
  - Add Reviewed-by, Acked-by,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
MTD_NAND_MARVELL on HAS_DMA,
  - Split in per-subsystem patches,
  - Split-off the core part in a separate series.

This series is against v4.16-rc5. It can also be found at
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2

It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.

Thanks!

Geert Uytterhoeven (21):
  ASoC: Remove depends on HAS_DMA in case of platform dependency
  ata: Remove depends on HAS_DMA in case of platform dependency
  crypto: Remove depends on HAS_DMA in case of platform dependency
  fbdev: Remove depends on HAS_DMA in case of platform dependency
  firewire: Remove depends on HAS_DMA in case of platform dependency
  fpga: Remove depends on HAS_DMA in case of platform dependency
  i2c: Remove depends on HAS_DMA in case of platform dependency
  iio: adc: Remove depends on HAS_DMA in case of platform dependency
  iommu: Remove depends on HAS_DMA in case of platform dependency
  lightnvm: Remove depends on HAS_DMA in case of platform dependency
  mailbox: Remove depends on HAS_DMA in case of platform dependency
  media: Remove depends on HAS_DMA in case of platform dependency
  mmc: Remove depends on HAS_DMA in case of platform dependency
  mtd: Remove depends on HAS_DMA in case of platform dependency
  net: Remove depends on HAS_DMA in case of platform dependency
  remoteproc: Remove depends on HAS_DMA in case of platform dependency
  scsi: hisi_sas: Remove depends on HAS_DMA in case of platform
dependency
  serial: Remove depends on HAS_DMA in case of platform dependency
  spi: Remove depends on HAS_DMA in case of platform dependency
  staging: vc04_services: Remove depends on HAS_DMA in case of platform
dependency
  usb: Remove depends on HAS_DMA in case of platform dependency

 drivers/ata/Kconfig |  2 --
 drivers/crypto/Kconfig  | 14 +++--
 drivers/firewire/Kconfig|  1 -
 drivers/fpga/Kconfig|  1 -
 drivers/i2c/busses/Kconfig  |  3 --
 drivers/iio/adc/Kconfig |  2 --
 drivers/iommu/Kconfig   |  5 ++--
 drivers/lightnvm/Kconfig|  2 +-
 drivers/mailbox/Kconfig |  2 --
 drivers/media/common/videobuf2/Kconfig  |  2 --
 drivers/media/pci/dt3155/Kconfig|  1 -
 drivers/media/pci/intel/ipu3/Kconfig|  1 -
 drivers/media/pci/solo6x10/Kconfig  |  1 -
 drivers/media/pci/sta2x11/Kconfig   |  1 -
 drivers/media/pci/tw5864/Kconfig|  1 -
 drivers/media/pci/tw686x/Kconfig|  1 -
 drivers/media/platform/Kconfig  | 40 -
 drivers/media/platform/am437x/Kconfig   |  2 +-
 drivers/media/platform/atmel/Kconfig|  4 +--
 drivers/media/platform/blackfin/Kconfig |  1 -
 drivers/media/platform/davinci/Kconfig  |  6 
 drivers/media/platform/marvell-ccic/Kconfig |  3 +-
 drivers/media/platform/rcar-vin/Kconfig |  2 +-
 drivers/media/platform/soc_camera/Kconfig   |  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig|  2 +-
 drivers/media/v4l2-core/Kconfig |  2 --
 drivers/mmc/ho

[PATCH v2 08/21] iio: adc: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iio/adc/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 72bc2b71765ae2ff..57f46e88f5c2536e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -158,7 +158,6 @@ config AT91_SAMA5D2_ADC
tristate "Atmel AT91 SAMA5D2 ADC"
depends on ARCH_AT91 || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
select IIO_TRIGGERED_BUFFER
help
  Say yes here to build support for Atmel SAMA5D2 ADC which is
@@ -647,7 +646,6 @@ config SD_ADC_MODULATOR
 config STM32_ADC_CORE
tristate "STMicroelectronics STM32 adc core"
depends on ARCH_STM32 || COMPILE_TEST
-   depends on HAS_DMA
depends on OF
depends on REGULATOR
select IIO_BUFFER
-- 
2.7.4



[PATCH v2 07/21] i2c: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/i2c/busses/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e2954fb86d659f36..2ce9bbd5d56ed06a 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -725,7 +725,6 @@ config I2C_MPC
 config I2C_MT65XX
tristate "MediaTek I2C adapter"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the MediaTek(R) Integrated Inter Circuit bus driver
  for MT65xx and MT81xx.
@@ -903,7 +902,6 @@ config I2C_SH7760
 
 config I2C_SH_MOBILE
tristate "SuperH Mobile I2C Controller"
-   depends on HAS_DMA
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  If you say yes to this option, support will be included for the
@@ -1106,7 +1104,6 @@ config I2C_XLP9XX
 
 config I2C_RCAR
tristate "Renesas R-Car I2C Controller"
-   depends on HAS_DMA
depends on ARCH_RENESAS || COMPILE_TEST
select I2C_SLAVE
help
-- 
2.7.4



[PATCH v2 09/21] iommu: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iommu/Kconfig | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index f3a21343e636a8f2..32e91398c0555272 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -23,7 +23,7 @@ config IOMMU_IO_PGTABLE
 config IOMMU_IO_PGTABLE_LPAE
bool "ARMv7/v8 Long Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || (COMPILE_TEST && 
!GENERIC_ATOMIC64))
+   depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
help
  Enable support for the ARM long descriptor pagetable format.
  This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page
@@ -42,7 +42,7 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
 config IOMMU_IO_PGTABLE_ARMV7S
bool "ARMv7/v8 Short Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST)
+   depends on ARM || ARM64 || COMPILE_TEST
help
  Enable support for the ARM Short-descriptor pagetable format.
  This supports 32-bit virtual and physical addresses mapped using
@@ -374,7 +374,6 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on HAS_DMA
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
-- 
2.7.4



[PATCH v2 05/21] firewire: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/firewire/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 145974f9662b63e6..4199849e37585181 100644
--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -1,5 +1,4 @@
 menu "IEEE 1394 (FireWire) support"
-   depends on HAS_DMA
depends on PCI || COMPILE_TEST
# firewire-core does not depend on PCI but is
# not useful without PCI controller driver
-- 
2.7.4



[PATCH v2 12/21] media: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various VIDEOBUF*DMA* symbols had to loose their dependencies on
HAS_DMA, as they are selected by several individual drivers.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on
HAS_DMA,
  - Split per subsystem.
---
 drivers/media/common/videobuf2/Kconfig   |  2 --
 drivers/media/pci/dt3155/Kconfig |  1 -
 drivers/media/pci/intel/ipu3/Kconfig |  1 -
 drivers/media/pci/solo6x10/Kconfig   |  1 -
 drivers/media/pci/sta2x11/Kconfig|  1 -
 drivers/media/pci/tw5864/Kconfig |  1 -
 drivers/media/pci/tw686x/Kconfig |  1 -
 drivers/media/platform/Kconfig   | 40 +---
 drivers/media/platform/am437x/Kconfig|  2 +-
 drivers/media/platform/atmel/Kconfig |  4 +--
 drivers/media/platform/blackfin/Kconfig  |  1 -
 drivers/media/platform/davinci/Kconfig   |  6 -
 drivers/media/platform/marvell-ccic/Kconfig  |  3 +--
 drivers/media/platform/rcar-vin/Kconfig  |  2 +-
 drivers/media/platform/soc_camera/Kconfig|  3 +--
 drivers/media/platform/sti/c8sectpfe/Kconfig |  2 +-
 drivers/media/v4l2-core/Kconfig  |  2 --
 drivers/staging/media/davinci_vpfe/Kconfig   |  1 -
 drivers/staging/media/omap4iss/Kconfig   |  1 -
 19 files changed, 20 insertions(+), 55 deletions(-)

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index 17c32ea58395d78f..4ed11b46676ac4d0 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS
 
 config VIDEOBUF2_DMA_CONTIG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
select DMA_SHARED_BUFFER
@@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC
 
 config VIDEOBUF2_DMA_SG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
 
diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig
index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644
--- a/drivers/media/pci/dt3155/Kconfig
+++ b/drivers/media/pci/dt3155/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_DT3155
tristate "DT3155 frame grabber"
depends on PCI && VIDEO_DEV && VIDEO_V4L2
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
---help---
diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index a82d3fe277d2cdec..2533ec1cb1177715 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2
depends on VIDEO_V4L2_SUBDEV_API
depends on X86 || COMPILE_TEST
depends on MEDIA_CONTROLLER
-   depends on HAS_DMA
depends on ACPI
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/pci/solo6x10/Kconfig 
b/drivers/media/pci/solo6x10/Kconfig
index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644
--- a/drivers/media/pci/solo6x10/Kconfig
+++ b/drivers/media/pci/solo6x10/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_SOLO6X10
tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)"
depends on PCI && VIDEO_DEV && SND && I2C
-   depends on HAS_DMA
select BITREVERSE
select FONT_SUPPORT
select FONT_8x16
diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index e03587b1af714199..7b856395ede9295c 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,7 +1,6 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
depends on STA2X11
-   depends on HAS_DMA
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
diff --git a/drivers/media/pci/tw5864/Kconfig b/drivers/media/pci/tw5864/Kconfig
index 87c8f327e2d49dfa..760fb11dfeaef47b 100644
--- a/drivers/media/pci/tw5864/Kconfig
+++ b/drivers/media/pci/tw5864/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_TW5864
tristate &

[PATCH v2 19/21] spi: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/spi/Kconfig | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 603783976b8152d4..7bd3a94f58511c41 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -71,7 +71,6 @@ config SPI_ARMADA_3700
 
 config SPI_ATMEL
tristate "Atmel SPI Controller"
-   depends on HAS_DMA
depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
help
  This selects a driver for the Atmel SPI Controller, present on
@@ -252,7 +251,6 @@ config SPI_EFM32
 
 config SPI_EP93XX
tristate "Cirrus Logic EP93xx SPI controller"
-   depends on HAS_DMA
depends on ARCH_EP93XX || COMPILE_TEST
help
  This enables using the Cirrus EP93xx SPI controller in master
@@ -374,7 +372,6 @@ config SPI_FSL_SPI
 config SPI_FSL_DSPI
tristate "Freescale DSPI controller"
select REGMAP_MMIO
-   depends on HAS_DMA
depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || M5441x || 
COMPILE_TEST
help
  This enables support for the Freescale DSPI controller in master
@@ -450,7 +447,6 @@ config SPI_OMAP_UWIRE
 
 config SPI_OMAP24XX
tristate "McSPI driver for OMAP"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select SG_SPLIT
help
@@ -459,7 +455,6 @@ config SPI_OMAP24XX
 
 config SPI_TI_QSPI
tristate "DRA7xxx QSPI controller support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
help
  QSPI master controller for DRA7xxx used for flash devices.
@@ -488,7 +483,6 @@ config SPI_PIC32
 config SPI_PIC32_SQI
tristate "Microchip PIC32 Quad SPI driver"
depends on MACH_PIC32 || COMPILE_TEST
-   depends on HAS_DMA
help
  SPI driver for PIC32 Quad SPI controller.
 
@@ -591,7 +585,7 @@ config SPI_SC18IS602
 
 config SPI_SH_MSIOF
tristate "SuperH MSIOF SPI controller"
-   depends on HAVE_CLK && HAS_DMA
+   depends on HAVE_CLK
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  SPI driver for SuperH and SH Mobile MSIOF blocks.
@@ -669,7 +663,7 @@ config SPI_MXS
 config SPI_TEGRA114
tristate "NVIDIA Tegra114 SPI Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for NVIDIA Tegra114 SPI Controller interface. This 
controller
  is different than the older SoCs SPI controller and also register 
interface
@@ -687,7 +681,7 @@ config SPI_TEGRA20_SFLASH
 config SPI_TEGRA20_SLINK
tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
 
-- 
2.7.4



[PATCH v2 02/21] ata: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/ata/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a7120d6211546949..9eaeed1fb237fa33 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -398,7 +398,6 @@ config SATA_DWC_VDEBUG
 
 config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
-   depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
  This option enables support for the Calxeda Highbank SoC's
@@ -408,7 +407,6 @@ config SATA_HIGHBANK
 
 config SATA_MV
tristate "Marvell SATA support"
-   depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
   ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
-- 
2.7.4



[PATCH v2 13/21] mmc: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mmc/host/Kconfig | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 620c2d90a646f387..f6d43348b4a3e5d4 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller support"
depends on ARCH_MESON || COMPILE_TEST
depends on COMMON_CLK
-   depends on HAS_DMA
depends on OF
help
  This selects support for the SD/MMC Host Controller on
@@ -401,7 +400,6 @@ config MMC_OMAP
 
 config MMC_OMAP_HS
tristate "TI OMAP High Speed Multimedia Card Interface support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
help
  This selects the TI OMAP High Speed Multimedia card Interface.
@@ -511,7 +509,6 @@ config MMC_DAVINCI
 
 config MMC_GOLDFISH
tristate "goldfish qemu Multimedia Card Interface support"
-   depends on HAS_DMA
depends on GOLDFISH || COMPILE_TEST
help
  This selects the Goldfish Multimedia card Interface emulation
@@ -605,7 +602,7 @@ config MMC_SDHI
 
 config MMC_SDHI_SYS_DMAC
tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if (SUPERH || ARM)
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
 config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
depends on ARM64 || COMPILE_TEST
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if ARM64
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -688,7 +685,6 @@ config MMC_CAVIUM_THUNDERX
 
 config MMC_DW
tristate "Synopsys DesignWare Memory Card Interface"
-   depends on HAS_DMA
depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
help
  This selects support for the Synopsys DesignWare Mobile Storage IP
@@ -758,7 +754,6 @@ config MMC_DW_ZX
 
 config MMC_SH_MMCIF
tristate "SuperH Internal MMCIF support"
-   depends on HAS_DMA
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
help
  This selects the MMC Host Interface controller (MMCIF) found in 
various
@@ -878,7 +873,6 @@ config MMC_TOSHIBA_PCI
 config MMC_BCM2835
tristate "Broadcom BCM2835 SDHOST MMC Controller support"
depends on ARCH_BCM2835 || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the BCM2835 SDHOST MMC controller. If you have
  a BCM2835 platform with SD or MMC devices, say Y or M here.
-- 
2.7.4



[PATCH v2 21/21] usb: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> [drivers/usb/gadget/]
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/usb/gadget/udc/Kconfig | 4 ++--
 drivers/usb/mtu3/Kconfig   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee9395..9c3b4f86965e80c7 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -179,7 +179,7 @@ config USB_R8A66597
 
 config USB_RENESAS_USBHS_UDC
tristate 'Renesas USBHS controller'
-   depends on USB_RENESAS_USBHS && HAS_DMA
+   depends on USB_RENESAS_USBHS
help
   Renesas USBHS is a discrete USB host and peripheral controller chip
   that supports both full and high speed USB 2.0 data transfers.
@@ -192,7 +192,7 @@ config USB_RENESAS_USBHS_UDC
 config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
-   depends on EXTCON && HAS_DMA
+   depends on EXTCON
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd61947beea51e..c0c0eb88e5eafc74 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
 
 config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
-   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on EXTCON && (USB || USB_GADGET)
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
-- 
2.7.4



[PATCH v2 20/21] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/staging/vc04_services/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/Kconfig 
b/drivers/staging/vc04_services/Kconfig
index f5aaf7d629f0fae9..98064ce2c2b47c7f 100644
--- a/drivers/staging/vc04_services/Kconfig
+++ b/drivers/staging/vc04_services/Kconfig
@@ -1,6 +1,5 @@
 menuconfig BCM_VIDEOCORE
tristate "Broadcom VideoCore support"
-   depends on HAS_DMA
depends on OF
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
default y
-- 
2.7.4



[PATCH v2 18/21] serial: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/tty/serial/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3682fd3e960cbd64..a0ea146a2ef5af53 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -115,7 +115,6 @@ config SERIAL_SB1250_DUART_CONSOLE
 
 config SERIAL_ATMEL
bool "AT91 on-chip serial port support"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
@@ -586,7 +585,6 @@ config BFIN_UART3_CTSRTS
 
 config SERIAL_IMX
tristate "IMX serial port support"
-   depends on HAS_DMA
depends on ARCH_MXC || COMPILE_TEST
select SERIAL_CORE
select RATIONAL
@@ -1436,7 +1434,6 @@ config SERIAL_PCH_UART_CONSOLE
 
 config SERIAL_MXS_AUART
tristate "MXS AUART support"
-   depends on HAS_DMA
depends on ARCH_MXS || MACH_ASM9260 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
@@ -1656,7 +1653,6 @@ config SERIAL_SPRD_CONSOLE
 config SERIAL_STM32
tristate "STMicroelectronics STM32 serial port support"
select SERIAL_CORE
-   depends on HAS_DMA
depends on ARCH_STM32 || COMPILE_TEST
help
  This driver is for the on-chip Serial Controller on
-- 
2.7.4



[PATCH v2 15/21] net: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops().
set_dma_ops() does not exist if NO_DMA=y, and its use in this driver
is questionable.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/net/ethernet/amd/Kconfig| 2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   | 1 -
 drivers/net/ethernet/apm/xgene/Kconfig  | 1 -
 drivers/net/ethernet/arc/Kconfig| 6 --
 drivers/net/ethernet/broadcom/Kconfig   | 2 --
 drivers/net/ethernet/calxeda/Kconfig| 2 +-
 drivers/net/ethernet/hisilicon/Kconfig  | 2 +-
 drivers/net/ethernet/marvell/Kconfig| 8 +++-
 drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
 drivers/net/ethernet/renesas/Kconfig| 2 --
 drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
 drivers/net/wireless/quantenna/qtnfmac/Kconfig  | 2 +-
 12 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index d5c15e8bb3de706b..f273af136fc7c995 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -173,7 +173,7 @@ config SUNLANCE
 
 config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
-   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && 
HAS_DMA
+   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM
depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
diff --git a/drivers/net/ethernet/apm/xgene-v2/Kconfig 
b/drivers/net/ethernet/apm/xgene-v2/Kconfig
index 1205861b631896a0..eedd3f3dd22e2201 100644
--- a/drivers/net/ethernet/apm/xgene-v2/Kconfig
+++ b/drivers/net/ethernet/apm/xgene-v2/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE_V2
tristate "APM X-Gene SoC Ethernet-v2 Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
help
  This is the Ethernet driver for the on-chip ethernet interface
diff --git a/drivers/net/ethernet/apm/xgene/Kconfig 
b/drivers/net/ethernet/apm/xgene/Kconfig
index afccb033177b3923..e4e33c900b577161 100644
--- a/drivers/net/ethernet/apm/xgene/Kconfig
+++ b/drivers/net/ethernet/apm/xgene/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE
tristate "APM X-Gene SoC Ethernet Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
select PHYLIB
select MDIO_XGENE
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index e743ddf46343302f..5d0ab8e74b680cc6 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -24,7 +24,8 @@ config ARC_EMAC_CORE
 config ARC_EMAC
tristate "ARC EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && HAS_DMA && (ARC || COMPILE_TEST)
+   depends on OF_IRQ && OF_NET
+   depends on ARC || COMPILE_TEST
---help---
  On some legacy ARC (Synopsys) FPGA boards such as ARCAngel4/ML50x
  non-standard on-chip ethernet device ARC EMAC 10/100 is used.
@@ -33,7 +34,8 @@ config ARC_EMAC
 config EMAC_ROCKCHIP
tristate "Rockchip EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA && (ARCH_ROCKCHIP 
|| COMPILE_TEST)
+   depends on OF_IRQ && OF_NET && REGULATOR
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
---help---
  Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers.
  This selects Rockchip SoC glue layer support for the
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index af75156919edfead..4c3bfde6e8de00f2 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -157,7 +157,6 @@ config BGMAC
 config BGMAC_BCMA
tristate "Broadcom iProc GBit BCMA support"
depends on BCMA && BCMA_HOST_SOC
-   depends on HAS_DMA
depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST
select BGMAC
select PHYLIB
@@ -170,7 +169,6 @@ config BGMAC_BCMA
 
 config BGMAC_PL

[PATCH v2 14/21] mtd: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop new dependency of MTD_NAND_MARVELL on HAS_DMA,
  - Split per subsystem.
---
 drivers/mtd/nand/Kconfig| 8 ++--
 drivers/mtd/spi-nor/Kconfig | 2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 736ac887303c88ba..55a2f8a2fa90cd87 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -46,7 +46,7 @@ config MTD_NAND_DENALI
 config MTD_NAND_DENALI_PCI
 tristate "Support Denali NAND controller on Intel Moorestown"
select MTD_NAND_DENALI
-   depends on HAS_DMA && PCI
+   depends on PCI
 help
   Enable the driver for NAND flash on Intel Moorestown, using the
   Denali NAND controller core.
@@ -184,7 +184,6 @@ config MTD_NAND_S3C2410_CLKSTOP
 config MTD_NAND_TANGO
tristate "NAND Flash support for Tango chips"
depends on ARCH_TANGO || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables the NAND Flash controller on Tango chips.
 
@@ -328,7 +327,7 @@ config MTD_NAND_MARVELL
tristate "NAND controller support on Marvell boards"
depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU || \
   COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables the NAND flash controller driver for Marvell boards,
  including:
@@ -490,7 +489,6 @@ config MTD_NAND_SH_FLCTL
tristate "Support for NAND on Renesas SuperH FLCTL"
depends on SUPERH || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
help
  Several Renesas SuperH CPU has FLCTL. This option enables support
  for NAND Flash using FLCTL.
@@ -558,7 +556,6 @@ config MTD_NAND_SUNXI
 config MTD_NAND_HISI504
tristate "Support for NAND controller on Hisilicon SoC Hip04"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on Hisilicon SoC Hip04.
 
@@ -572,7 +569,6 @@ config MTD_NAND_QCOM
 config MTD_NAND_MTK
tristate "Support for NAND controller on MTK SoCs"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on MTK SoCs.
  This controller is found on mt27xx, mt81xx, mt65xx SoCs.
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 89da88e591215db1..c493b8230a38c059 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -71,7 +71,7 @@ config SPI_FSL_QUADSPI
 config SPI_HISI_SFC
tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables support for hisilicon SPI-NOR flash controller.
 
-- 
2.7.4



[PATCH v2 11/21] mailbox: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Notes:
  - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(),
which does not exist if HAS_DMA=n (Do we need a dummy? The use of
set_dma_ops() in this driver is questionable),
  - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
dependency on HAS_DMA, as they are selected from
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mailbox/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ba2f1525f4eef454..f3c68fe15180d035 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -154,7 +154,6 @@ config XGENE_SLIMPRO_MBOX
 config BCM_PDC_MBOX
tristate "Broadcom FlexSparx DMA Mailbox"
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
help
  Mailbox implementation for the Broadcom FlexSparx DMA ring manager,
  which provides access to various offload engines on Broadcom
@@ -164,7 +163,6 @@ config BCM_FLEXRM_MBOX
tristate "Broadcom FlexRM Mailbox"
depends on ARM64
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
select GENERIC_MSI_IRQ_DOMAIN
default m if ARCH_BCM_IPROC
help
-- 
2.7.4



[PATCH v2 17/21] scsi: hisi_sas: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/scsi/hisi_sas/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hisi_sas/Kconfig b/drivers/scsi/hisi_sas/Kconfig
index d42f29a5eb65046d..57183fce70fb6355 100644
--- a/drivers/scsi/hisi_sas/Kconfig
+++ b/drivers/scsi/hisi_sas/Kconfig
@@ -1,6 +1,6 @@
 config SCSI_HISI_SAS
tristate "HiSilicon SAS"
-   depends on HAS_DMA && HAS_IOMEM
+   depends on HAS_IOMEM
depends on ARM64 || COMPILE_TEST
select SCSI_SAS_LIBSAS
select BLK_DEV_INTEGRITY
-- 
2.7.4



[PATCH v2 06/21] fpga: Remove depends on HAS_DMA in case of platform dependency

2018-03-16 Thread Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/fpga/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index f47ef848bcd056d5..fd539132542e30ee 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -53,7 +53,6 @@ config FPGA_MGR_ALTERA_CVP
 config FPGA_MGR_ZYNQ_FPGA
tristate "Xilinx Zynq FPGA"
depends on ARCH_ZYNQ || COMPILE_TEST
-   depends on HAS_DMA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
-- 
2.7.4



Re: [PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures

2018-03-14 Thread Geert Uytterhoeven
On Tue, Mar 13, 2018 at 7:05 PM, Kieran Bingham
<kieran.bingham+rene...@ideasonboard.com> wrote:
> The use of the packed attribute can cause a performance penalty for
> all accesses to the struct members, as the compiler will assume that the
> structure has the potential to have an unaligned base.
>
> These structures are all correctly aligned and contain no holes, thus
> the attribute is redundant and negatively impacts performance, so we
> remove the attributes entirely.
>
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>

Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH] dt-bindings: media: rcar_vin: Use status "okay"

2018-03-09 Thread Geert Uytterhoeven
According to the Devicetree Specification, "ok" is not a valid status.

Fixes: 47c71bd61b772cd7 ("[media] rcar_vin: add devicetree support")
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
For the checkpatch TODO list?
https://www.devicetree.org/

 Documentation/devicetree/bindings/media/rcar_vin.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 68c5c497b7fa5551..a19517e1c669eb35 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -81,7 +81,7 @@ Board setup example for Gen2 platforms (vin1 composite video 
input)
 ---
 
{
-status = "ok";
+status = "okay";
 pinctrl-0 = <_pins>;
 pinctrl-names = "default";
 
@@ -104,7 +104,7 @@ Board setup example for Gen2 platforms (vin1 composite 
video input)
 pinctrl-0 = <_pins>;
 pinctrl-names = "default";
 
-status = "ok";
+status = "okay";
 
 port {
 #address-cells = <1>;
-- 
2.7.4



Re: [PATCH v2] i2c: adv748x: afe: fix sparse warning

2018-03-08 Thread Geert Uytterhoeven
On Thu, Mar 8, 2018 at 12:02 AM, Niklas Söderlund
<niklas.soderl...@ragnatech.se> wrote:
> CC linux-media.
>
> It's linux-media@vger.kernel.org not linux-me...@vger.kernel.or, sorry
> for the noise.
>
> On 2018-03-07 23:58:16 +0100, Niklas Söderlund wrote:
>> This fixes the following sparse warning:
>>
>> drivers/media/i2c/adv748x/adv748x-afe.c:294:34:expected unsigned int 
>> [usertype] *signal
>> drivers/media/i2c/adv748x/adv748x-afe.c:294:34:got int *
>> drivers/media/i2c/adv748x/adv748x-afe.c:294:34: warning: incorrect type in 
>> argument 2 (different signedness)
>>
>> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH] media: platform: Drop OF dependency of VIDEO_RENESAS_VSP1

2018-02-26 Thread Geert Uytterhoeven
VIDEO_RENESAS_VSP1 depends on ARCH_RENESAS && OF.
As ARCH_RENESAS implies OF, the latter can be dropped.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 614fbef08ddcabb0..2b8b1ad0edd9eb31 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -448,7 +448,7 @@ config VIDEO_RENESAS_FCP
 config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
-   depends on (ARCH_RENESAS && OF) || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
-- 
2.7.4



Re: [PATCH] i2c: adv748x: afe: fix sparse warning

2018-02-22 Thread Geert Uytterhoeven
Hi Niklas,

On Thu, Feb 22, 2018 at 12:21 AM, Niklas Söderlund
<niklas.soderlund+rene...@ragnatech.se> wrote:
> This fixes the following sparse warning:
>
> drivers/media/i2c/adv748x/adv748x-afe.c:294:34:expected unsigned int 
> [usertype] *signal
> drivers/media/i2c/adv748x/adv748x-afe.c:294:34:got int *
> drivers/media/i2c/adv748x/adv748x-afe.c:294:34: warning: incorrect type in 
> argument 2 (different signedness)
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  drivers/media/i2c/adv748x/adv748x-afe.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
> b/drivers/media/i2c/adv748x/adv748x-afe.c
> index 5188178588c9067d..39a9996d0db08c31 100644
> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> @@ -275,7 +275,8 @@ static int adv748x_afe_s_stream(struct v4l2_subdev *sd, 
> int enable)
>  {
> struct adv748x_afe *afe = adv748x_sd_to_afe(sd);
> struct adv748x_state *state = adv748x_afe_to_state(afe);
> -   int ret, signal = V4L2_IN_ST_NO_SIGNAL;
> +   unsigned int signal = V4L2_IN_ST_NO_SIGNAL;

u32, as adv748x_afe_status() takes an u32 signal pointer?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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/5] auxdisplay: charlcd: no need to call charlcd_gotoxy() if nothing changes

2018-02-12 Thread Geert Uytterhoeven
On Mon, Feb 12, 2018 at 2:42 PM, Miguel Ojeda
<miguel.ojeda.sando...@gmail.com> wrote:
> On Mon, Jan 15, 2018 at 10:58 AM, Sean Young <s...@mess.org> wrote:
>> If the line extends beyond the width to the screen, nothing changes. The
>> existing code will call charlcd_gotoxy every time for this case.
>>
>> Signed-off-by: Sean Young <s...@mess.org>
>> ---
>>  drivers/auxdisplay/charlcd.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c
>> index 642afd88870b..45ec5ce697c4 100644
>> --- a/drivers/auxdisplay/charlcd.c
>> +++ b/drivers/auxdisplay/charlcd.c
>> @@ -192,10 +192,11 @@ static void charlcd_print(struct charlcd *lcd, char c)
>> c = lcd->char_conv[(unsigned char)c];
>> lcd->ops->write_data(lcd, c);
>> priv->addr.x++;
>> +
>> +   /* prevents the cursor from wrapping onto the next line */
>> +   if (priv->addr.x == lcd->bwidth)
>> +   charlcd_gotoxy(lcd);
>> }
>> -   /* prevents the cursor from wrapping onto the next line */
>> -   if (priv->addr.x == lcd->bwidth)
>> -   charlcd_gotoxy(lcd);
>>  }
>>
>
> Willy, Geert: is this fine with you? Seems fine: charlcd_write_char()
> right now does an unconditional write_cmd() when writing a normal
> character; so unless some HW requires the command for some reason even
> if there is nothing changed, we can skip it.

Reviewed-by: Geert Uytterhoeven <ge...@linux-m68k.org>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

2018-02-06 Thread Geert Uytterhoeven
Hi Wolfram,

On Mon, Feb 5, 2018 at 9:09 PM, Wolfram Sang
<wsa+rene...@sang-engineering.com> wrote:
> In one Renesas driver, I found a typo which turned an intended bit shift 
> ('<<')
> into a comparison ('<'). Because this is a subtle issue, I looked tree wide 
> for
> similar patterns. This small patch series is the outcome.
>
> Buildbot and checkpatch are happy. Only compile-tested. To be applied
> individually per sub-system, I think. I'd think only the net: amd: patch needs
> to be conisdered for stable, but I leave this to people who actually know this
> driver.
>
> CCing Dan. Maybe he has an idea how to add a test to smatch? In my setup, only
> cppcheck reported a 'coding style' issue with a low prio.

I found two more using "git grep 'define.*0x[0-9a-f]* < '":

drivers/net/can/m_can/m_can.c:#define RXFC_FWM_MASK (0x7f < RXFC_FWM_SHIFT)
drivers/usb/gadget/udc/goku_udc.h:#define INT_EPnNAK(n)
(0x00100 < (n))     /* 0 < n < 4 */

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v7 00/11] Renesas Capture Engine Unit (CEU) V4L2 driver

2018-01-26 Thread Geert Uytterhoeven
Hi Jacopo,

On Fri, Jan 26, 2018 at 2:54 PM, jacopo mondi <jac...@jmondi.org> wrote:
> UUUPS
>
> please ignore this submission as it contains patches from a previous
> version (you may have noticed some patches in the series reports
> [xx/09] in the subject).
>
> I will resend.

Good. So there's still time to fix e.g. "RZ/A1-H" to "RZ/A1H" (same
for M and L).

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] sh: clk: Relax clk rate match test

2018-01-25 Thread Geert Uytterhoeven
Hi Jacopo,

On Thu, Jan 25, 2018 at 3:14 PM, jacopo mondi <jac...@jmondi.org> wrote:
> On Thu, Jan 25, 2018 at 02:53:41PM +0100, Geert Uytterhoeven wrote:
>> CC linux-clk (yes I know this is about the legacy SH clock framework, but
>> the public API is/should be the same)
>>
>> On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi
>> <jacopo+rene...@jmondi.org> wrote:
>> > When asking for a clk rate to be set, the sh core clock matches only
>> > exact rate values against the calculated frequency table entries. If the
>> > rate does not match exactly the test fails, and the whole frequency
>> > table is walked, resulting in selection of the last entry, corresponding to
>> > the lowest available clock rate.
>>
>> IIUIC, the code does not select the last entry, but returns an error code,
>> which is propagated all the way up?
>>
>> > Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" 
>> > line),
>> > the calculated clock frequency 10088572 Hz gets ignored, and the clock is
>> > actually set to 5201920 Hz, which is the last available entry of the 
>> > frequencies
>> > table.
>>
>> Perhaps 5201920 is just the default (or old value)?
>>
>> > Relax the clock frequency match test, allowing selection of clock rates
>> > immediately slower than the required one.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
>> >
>> > ---
>> > Hello renesas lists,
>> >
>> > I'm now working on handling frame rate for the ov7720 image sensor to have 
>> > that
>> > driver accepted as part of v4l2. The sensor is installed on on Migo-R 
>> > board.
>> > In order to properly calculate pixel clock and the framerate I noticed the
>> > clock signal fed to the sensor from the SH7722 chip was always the lowest
>> > available one.
>> >
>> > This patch fixes the issues and allows me to properly select which clock
>> > frequency supply to the sensor, which according to datasheet does not 
>> > support
>> > input clock frequencies slower than 10MHz (but works anyhow).
>> >
>> > As all patches for SH architecture I wonder where they should be picked up 
>> > from,
>> > as SH seems not maintained at the moment.
>> >
>> > Thanks
>> >j
>> >
>> > ---
>> >  drivers/sh/clk/core.c | 9 ++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
>> > index 92863e3..d2cb94c 100644
>> > --- a/drivers/sh/clk/core.c
>> > +++ b/drivers/sh/clk/core.c
>> > @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
>> >  {
>> > struct cpufreq_frequency_table *pos;
>> >
>> > -   cpufreq_for_each_valid_entry(pos, freq_table)
>> > -   if (pos->frequency == rate)
>> > -   return pos - freq_table;
>> > +   cpufreq_for_each_valid_entry(pos, freq_table) {
>> > +   if (pos->frequency > rate)
>> > +   continue;
>>
>> This assumes all frequency tables are sorted.
>>
>> Shouldn't you pick the closest frequency?
>>
>> However, that's what clk_rate_table_round() does, which is called from
>> sh_clk_div_round_rate(), and thus already used as .round_rate:
>>
>> static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
>> .recalc = sh_clk_div_recalc,
>> .set_rate   = sh_clk_div_set_rate,
>> .round_rate = sh_clk_div_round_rate,
>> .enable = sh_clk_div_enable,
>> .disable= sh_clk_div_disable,
>> };
>
> Does this implies clock rates should be set using clk_round_rate() and
> not clk_set_rate() if I understand this right?

Not necessarily...

Note that both cpg_div6_clock_round_rate() and cpg_div6_clock_set_rate()
in the CCF implementation for DIV6 clocks use rounding.

>> (clk_rate_table_find() is called from sh_clk_div_set_rate())
>>
>> Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
>> come from?
>
> From board initialization code, in order to provide a valid input
> clock to OV7720 sensor.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] sh: clk: Relax clk rate match test

2018-01-25 Thread Geert Uytterhoeven
Hi Jacopo,

CC linux-clk (yes I know this is about the legacy SH clock framework, but
the public API is/should be the same)

On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi
<jacopo+rene...@jmondi.org> wrote:
> When asking for a clk rate to be set, the sh core clock matches only
> exact rate values against the calculated frequency table entries. If the
> rate does not match exactly the test fails, and the whole frequency
> table is walked, resulting in selection of the last entry, corresponding to
> the lowest available clock rate.

IIUIC, the code does not select the last entry, but returns an error code,
which is propagated all the way up?

> Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" line),
> the calculated clock frequency 10088572 Hz gets ignored, and the clock is
> actually set to 5201920 Hz, which is the last available entry of the 
> frequencies
> table.

Perhaps 5201920 is just the default (or old value)?

> Relax the clock frequency match test, allowing selection of clock rates
> immediately slower than the required one.
>
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
>
> ---
> Hello renesas lists,
>
> I'm now working on handling frame rate for the ov7720 image sensor to have 
> that
> driver accepted as part of v4l2. The sensor is installed on on Migo-R board.
> In order to properly calculate pixel clock and the framerate I noticed the
> clock signal fed to the sensor from the SH7722 chip was always the lowest
> available one.
>
> This patch fixes the issues and allows me to properly select which clock
> frequency supply to the sensor, which according to datasheet does not support
> input clock frequencies slower than 10MHz (but works anyhow).
>
> As all patches for SH architecture I wonder where they should be picked up 
> from,
> as SH seems not maintained at the moment.
>
> Thanks
>j
>
> ---
>  drivers/sh/clk/core.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
> index 92863e3..d2cb94c 100644
> --- a/drivers/sh/clk/core.c
> +++ b/drivers/sh/clk/core.c
> @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
>  {
> struct cpufreq_frequency_table *pos;
>
> -   cpufreq_for_each_valid_entry(pos, freq_table)
> -   if (pos->frequency == rate)
> -   return pos - freq_table;
> +   cpufreq_for_each_valid_entry(pos, freq_table) {
> +   if (pos->frequency > rate)
> +   continue;

This assumes all frequency tables are sorted.

Shouldn't you pick the closest frequency?

However, that's what clk_rate_table_round() does, which is called from
sh_clk_div_round_rate(), and thus already used as .round_rate:

static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
.recalc = sh_clk_div_recalc,
.set_rate   = sh_clk_div_set_rate,
.round_rate = sh_clk_div_round_rate,
.enable = sh_clk_div_enable,
.disable= sh_clk_div_disable,
};

(clk_rate_table_find() is called from sh_clk_div_set_rate())

Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
come from?

> +
> +   return pos - freq_table;
> +   }
>
> return -ENOENT;
>  }

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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] v4l2-dev.h: fix symbol collision in media_entity_to_video_device()

2018-01-25 Thread Geert Uytterhoeven
Hi Niklas,

On Thu, Jan 25, 2018 at 1:34 AM, Niklas Söderlund
<niklas.soderlund+rene...@ragnatech.se> wrote:
> A recent change to the media_entity_to_video_device() macro breaks some
> use-cases for the macro due to a symbol collision. Before the change
> this worked:
>
> vdev = media_entity_to_video_device(link->sink->entity);
>
> While after the change it results in a compiler error "error: 'struct
> video_device' has no member named 'link'; did you mean 'lock'?". While
> the following still works after the change.
>
> struct media_entity *entity = link->sink->entity;
> vdev = media_entity_to_video_device(entity);
>
> Fix the collision by renaming the macro argument to 'media_entity'.

Thanks!
Given there also exists a "struct media_entity", using "_media_entity" seems
safe to me.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 -next] media: rcar_drif: fix error return code in rcar_drif_alloc_dmachannels()

2018-01-17 Thread Geert Uytterhoeven
On Wed, Jan 17, 2018 at 12:24 PM, Wei Yongjun <weiyongj...@huawei.com> wrote:
> Fix to return error code -ENODEV from the dma_request_slave_channel()
> error handling case instead of 0, as done elsewhere in this function.
> rc can be overwrite to 0 by dmaengine_slave_config() in the for loop.
>
> Signed-off-by: Wei Yongjun <weiyongj...@huawei.com>

Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v2] v4l: async: Protect against double notifier registrations

2018-01-17 Thread Geert Uytterhoeven
Hi Kieran,

On Wed, Jan 17, 2018 at 12:47 AM, Kieran Bingham
<kieran.bing...@ideasonboard.com> wrote:
> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
>
> It can be easy to attempt to register the same notifier twice
> in mis-handled error cases such as working with -EPROBE_DEFER.
>
> This results in odd kernel crashes where the notifier_list becomes
> corrupted due to adding the same entry twice.
>
> Protect against this so that a developer has some sense of the pending
> failure, and use a WARN_ON to identify the fault.
>
> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>

Thanks for your patch!

However, I have several comments:
  1. Instead of walking notifier_list (O(n)), can't you just check if
 notifier.list is part of a list or not (O(1))?
  2. Isn't notifier usually (always?) allocated dynamically, so if will be a
 different pointer after a previous -EPROBE_DEFER anyway?
  3. If you enable CONFIG_DEBUG_LIST, it should scream, too.

> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -374,17 +374,26 @@ static int __v4l2_async_notifier_register(struct 
> v4l2_async_notifier *notifier)
> struct device *dev =
> notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL;
> struct v4l2_async_subdev *asd;
> +   struct v4l2_async_notifier *n;
> int ret;
> int i;
>
> if (notifier->num_subdevs > V4L2_MAX_SUBDEVS)
> return -EINVAL;
>
> +   mutex_lock(_lock);
> +
> +   /* Avoid re-registering a notifier. */
> +   list_for_each_entry(n, _list, list) {
> +   if (WARN_ON(n == notifier)) {
> +   ret = -EEXIST;
> +   goto err_unlock;
> +   }
> +   }
> +
> INIT_LIST_HEAD(>waiting);
> INIT_LIST_HEAD(>done);
>
> -   mutex_lock(_lock);
> -
> for (i = 0; i < notifier->num_subdevs; i++) {
> asd = notifier->subdevs[i];

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v4 3/9] v4l: platform: Add Renesas CEU driver

2018-01-12 Thread Geert Uytterhoeven
Hi Laurent,

On Fri, Jan 12, 2018 at 12:12 AM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
> On Tuesday, 9 January 2018 18:25:25 EET Jacopo Mondi wrote:
>> Add driver for Renesas Capture Engine Unit (CEU).
>>
>> The CEU interface supports capturing 'data' (YUV422) and 'images'
>> (NV[12|21|16|61]).
>>
>> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
>>
>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
>> platform GR-Peach.
>>
>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>>
>> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
>> ---
>>  drivers/media/platform/Kconfig   |9 +
>>  drivers/media/platform/Makefile  |1 +
>>  drivers/media/platform/renesas-ceu.c | 1648
>> ++ 3 files changed, 1658 insertions(+)
>>  create mode 100644 drivers/media/platform/renesas-ceu.c
>
> [snip]
>
>> diff --git a/drivers/media/platform/renesas-ceu.c
>> b/drivers/media/platform/renesas-ceu.c new file mode 100644
>> index 000..d261704
>> --- /dev/null
>> +++ b/drivers/media/platform/renesas-ceu.c
>> @@ -0,0 +1,1648 @@
>> +// SPDX-License-Identifier: GPL-2.0
>
> It was recently brought to my attention that SPDX headers should use either
> GPL-2.0-only or GPL-2.0-or-later, no the ambiguous GPL-2.0. Could you please
> update all patches in this series ?

IMHO it's a bit premature to do that.
As long as Documentation/process/license-rules.rst isn't updated, I wouldn't
follow this change.

See also https://www.spinics.net/lists/linux-xfs/msg14536.html

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v3 1/9] dt-bindings: media: Add Renesas CEU bindings

2018-01-05 Thread Geert Uytterhoeven
On Thu, Jan 4, 2018 at 11:28 PM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
> On Thursday, 4 January 2018 18:03:09 EET Jacopo Mondi wrote:
>> Add bindings documentation for Renesas Capture Engine Unit (CEU).

>> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
>> @@ -0,0 +1,85 @@
>> +Renesas Capture Engine Unit (CEU)
>> +--
>> +
>> +The Capture Engine Unit is the image capture interface found in the Renesas
>> +SH Mobile and RZ SoCs.
>> +
>> +The interface supports a single parallel input with data bus width of 8 or
>> 16
>> +bits.
>> +
>> +Required properties:
>> +- compatible: Must be one of the following.
>> + - "renesas,r7s72100-ceu" for CEU units found in R7S72100 (RZ/A1) SoCs.
>> + - "renesas,ceu" as a generic fallback.
>
> As asked in my review of patch 3/9, what's your policy for compatible strings
> ? As far as I understand there's no generic CEU, as the SH4 and RZ versions
> are not compatible. Should the "renesas,ceu" compatible string then be
> replaced by "renesas,rz-ceu" ?

If they're not compatible, it indeed doesn't make much sense to have a
generic "renesas,ceu".

Note that anything with "rz-" is a bad idea, as after RZ/A1, Renesas introduced
RZ/G1, RZ/N1, and RZ/T1, which are completely different (yes I know
we have a few of these in use, unfortunately).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v2 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

2018-01-02 Thread Geert Uytterhoeven
Hi Jacopo,

On Thu, Dec 28, 2017 at 3:01 PM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote:
> Add Capture Engine Unit (CEU) node to device tree.

Thanks for your patch!

> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>

With the issue below fixed:
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>

> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi

> @@ -667,4 +667,13 @@
> power-domains = <_clocks>;
> status = "disabled";
> };
> +
> +   ceu: ceu@e821 {
> +   reg = <0xe821 0x209c>;

Given the last documented register is at offset 0x209C, the region above is too
small (also in the example in the DT bindings).
But due to MMU granularity, it will be accessible anyway.

reg = <0xe821 0x3000>;

I assume the mandatory "remote-endpoint" property will come with the board
(GR-Peach) DTS patch?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v2 1/9] dt-bindings: media: Add Renesas CEU bindings

2018-01-02 Thread Geert Uytterhoeven
Hi Jacopo,

On Thu, Dec 28, 2017 at 3:01 PM, Jacopo Mondi <jacopo+rene...@jmondi.org> wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).

Thanks for your patch!

> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,85 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with data bus width up to
> +8/16 bits.
> +
> +Required properties:
> +- compatible
> +   Must be one of:
> +   - "renesas,ceu"

Isn't "renesas,ceu" the generic fallback?

> +   - "renesas,r7s72100-ceu"

> +- reg
> +   Physical address base and size.
> +- interrupts
> +   The interrupt specifier.
> +- pinctrl-names, pinctrl-0
> +   phandle of pin controller sub-node configuring pins for CEU 
> operations.
> +- remote-endpoint
> +   phandle to an 'endpoint' subnode of a remote device node.

"remote-endpoint" is not a direct property, but must be part of nested "ports"
and "endpoint" subnodes, like in the example?

> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and an
> +OV7670 image sensor sitting on bus i2c1.
> +
> +ceu: ceu@e821 {
> +   reg = <0xe821 0x209c>;
> +   compatible = "renesas,ceu";
> +   interrupts = ;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   status = "okay";
> +
> +   port {
> +   ceu_in: endpoint {
> +   remote-endpoint = <_out>;
> +
> +   hsync-active = <1>;
> +   vsync-active = <0>;
> +   };
> +   };
> +};

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: [GIT PULL for v4.15-rc3] media fixes

2017-12-13 Thread Geert Uytterhoeven
Hi Mauro,

On Wed, Dec 13, 2017 at 12:53 PM, Mauro Carvalho Chehab
<mche...@osg.samsung.com> wrote:
> Em Wed, 13 Dec 2017 10:03:56 +0100
> Geert Uytterhoeven <ge...@linux-m68k.org> escreveu:
>> On Mon, Dec 11, 2017 at 12:12 PM, Mauro Carvalho Chehab
>> <mche...@osg.samsung.com> wrote:
>> > Without this series, I was getting 809 lines of bogus warnings (see below),
>> > with was preventing me to see new warnings on my incremental builds
>> > while applying new patches at the media tree.
>>
>> $ linux-log-diff build.log{.old,}
>>
>> (from https://github.com/geertu/linux-scripts)
>
> That's nice!
>
> Yet, it is producing some noise. I did a clean build with:
>
> $ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 
> CHECK='' M=drivers/staging/media | grep -v -e " CC " -e " LD " -e " AR " -e " 
> CHK " -e " CALL " -e " UPD " -e "scripts/kconfig/conf " -e " CHECK " >old.log
> $ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 
> CHECK='' M=drivers/media| grep -v -e " CC " -e " LD " -e " AR " -e " CHK " -e 
> " CALL " -e " UPD " -e "scripts/kconfig/conf " -e " CHECK "  >>old.log
>
> and added a new uninitialized "foo" var to a random driver, doing an
> incremental build with:
>
> $ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 
> CHECK='' | grep -v -e " CC " -e " LD " -e " AR " -e " CHK " -e " CALL " -e " 
> UPD " -e "scripts/kconfig/conf " -e " CHECK " M=drivers/staging/media >new.log
> $ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 
> CHECK='' | grep -v -e " CC " -e " LD " -e " AR " -e " CHK " -e " CALL " -e " 
> UPD " -e "scripts/kconfig/conf " -e " CHECK " M=drivers/media >new.log
>
> Then, I ran the script:
>
> $ linux-log-diff old.log new.log
>
> *** ERRORS ***
>
>
> *** WARNINGS ***
>
> 1 warning regressions:
>   + drivers/media/dvb-frontends/dibx000_common.c: warning: unused variable 
> 'foo' [-Wunused-variable]:  => 22:5
>
> 3 warning improvements:
>   - ./arch/x86/include/asm/bitops.h: warning: asm output is not an lvalue: 
> 430:22 =>
>   - 
> drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:
>  warning: function 'mmu_reg_load' with external linkage has definition: 35:30 
> =>
>   - 
> drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:
>  warning: function 'mmu_reg_store' with external linkage has definition: 
> 24:26 =>
>
> It detected the "foo" var warning, but it outputs 3 warning improvements
> on files that were not even built the second time.

If the file wasn't built, the warning cannot be in the log ;-)
So yes, it works best for full builds, only flagging warnings that
(dis)appeared (and ignoring changes due to changed line numbers!).

If you do lots of incremental builds, you want to append the last incremental
log to the existing full log before doing a new build, to avoid false positives
from files that weren't built in the previous run:

$ cat new.log >> old.log
$ make ... > new.log
$ linux-log-diff old.log new.log

And only new warnings should be reported.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: [GIT PULL for v4.15-rc3] media fixes

2017-12-13 Thread Geert Uytterhoeven
Hi Mauro,

On Mon, Dec 11, 2017 at 12:12 PM, Mauro Carvalho Chehab
<mche...@osg.samsung.com> wrote:
> Without this series, I was getting 809 lines of bogus warnings (see below),
> with was preventing me to see new warnings on my incremental builds
> while applying new patches at the media tree.

$ linux-log-diff build.log{.old,}

(from https://github.com/geertu/linux-scripts)

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v4 0/9] vsp1: TLB optimisation and DL caching

2017-12-12 Thread Geert Uytterhoeven
Hi Kieran,

On Fri, Nov 17, 2017 at 4:47 PM, Kieran Bingham
<kieran.bingham+rene...@ideasonboard.com> wrote:
> Each display list currently allocates an area of DMA memory to store register
> settings for the VSP1 to process. Each of these allocations adds pressure to
> the IPMMU TLB entries.
>
> We can reduce the pressure by pre-allocating larger areas and dividing the 
> area
> across multiple bodies represented as a pool.
>
> With this reconfiguration of bodies, we can adapt the configuration code to
> separate out constant hardware configuration and cache it for re-use.
>
> --
>
> The patches provided in this series can be found at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git  
> tags/vsp1/tlb-optimise/v4

This started to conflict with commit dd286a531461748f ("v4l: vsp1:
Start and stop DRM pipeline independently of planes"), causing build
failures as it changes the signature of vsp1_entity_route_setup(), and
removed several VSP1_ENTITY_PARAMS_* definitions.

After fixing those, it hangs after:
 [drm] No driver support for vblank timestamp query.

So I dropped the above for today's release.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH] media: i2c: adv748x: Restore full DT paths in kernel messages

2017-11-28 Thread Geert Uytterhoeven
As of_node_full_name() now returns only the basename, the endpoint
information printed became useless:

adv748x 4-0070: Endpoint endpoint on port 7
adv748x 4-0070: Endpoint endpoint on port 8
adv748x 4-0070: Endpoint endpoint on port 10
adv748x 4-0070: Endpoint endpoint on port 11

Restore the old behavior by using "%pOF" instead:

adv748x 4-0070: Endpoint 
/soc/i2c@e66d8000/video-receiver@70/port@7/endpoint on port 7
adv748x 4-0070: Endpoint 
/soc/i2c@e66d8000/video-receiver@70/port@8/endpoint on port 8
adv748x 4-0070: Endpoint 
/soc/i2c@e66d8000/video-receiver@70/port@10/endpoint on port 10
adv748x 4-0070: Endpoint 
/soc/i2c@e66d8000/video-receiver@70/port@11/endpoint on port 11

Fixes: a7e4cfb0a7ca4773 ("of/fdt: only store the device node basename in 
full_name")
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 drivers/media/i2c/adv748x/adv748x-core.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
b/drivers/media/i2c/adv748x/adv748x-core.c
index 5ee14f2c27478e3a..c1001db6a172e256 100644
--- a/drivers/media/i2c/adv748x/adv748x-core.c
+++ b/drivers/media/i2c/adv748x/adv748x-core.c
@@ -646,14 +646,12 @@ static int adv748x_parse_dt(struct adv748x_state *state)
 
for_each_endpoint_of_node(state->dev->of_node, ep_np) {
of_graph_parse_endpoint(ep_np, );
-   adv_info(state, "Endpoint %s on port %d",
-   of_node_full_name(ep.local_node),
-   ep.port);
+   adv_info(state, "Endpoint %pOF on port %d", ep.local_node,
+ep.port);
 
if (ep.port >= ADV748X_PORT_MAX) {
-   adv_err(state, "Invalid endpoint %s on port %d",
-   of_node_full_name(ep.local_node),
-   ep.port);
+   adv_err(state, "Invalid endpoint %pOF on port %d",
+   ep.local_node, ep.port);
 
continue;
}
-- 
2.7.4



Re: [PATCH v1 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

2017-11-23 Thread Geert Uytterhoeven
Hi Jacopo,

On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
<jacopo+rene...@jmondi.org> wrote:
> Add Capture Engine Unit (CEU) node to device tree.
>
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>

Thanks for your patch!

> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -136,8 +136,8 @@
> compatible = "renesas,r7s72100-mstp-clocks", 
> "renesas,cpg-mstp-clocks";
> reg = <0xfcfe042c 4>;
> clocks = <_clk>;

You forgot to add an entry to clocks.
The parent clock of the CEU module clock is b_clk.

> -   clock-indices = ;
> -   clock-output-names = "rtc";
> +   clock-indices = ;
> +   clock-output-names = "rtc", "ceu";

Usually we follow the order from ,
so CEU should come before RTC.

> @@ -666,4 +666,12 @@
> power-domains = <_clocks>;
> status = "disabled";
> };
> +
> +   ceu: ceu@e821 {
> +   reg = <0xe821 0x209c>;
> +   compatible = "renesas,renesas-ceu";
> +   interrupts = ;
> +   power-domains = <_clocks>;

if you describe the device to be part of the CPG clock domain, you should
provide a clocks property:

clocks = <_clks R7S72100_CLK_CEU>;

> +   status = "disabled";
> +   };
>  };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list

2017-11-23 Thread Geert Uytterhoeven
On Thu, Nov 16, 2017 at 7:22 PM, Fabrizio Castro
<fabrizio.cas...@bp.renesas.com> wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
>
> Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
> Reviewed-by: Biju Das <biju@bp.renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2017-11-22 Thread Geert Uytterhoeven
On Thu, Nov 16, 2017 at 7:22 PM, Fabrizio Castro
<fabrizio.cas...@bp.renesas.com> wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
>
> Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
> Reviewed-by: Biju Das <biju....@bp.renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH] [media] c8sectpfe: DVB_C8SECTPFE should depend on HAS_DMA

2017-11-19 Thread Geert Uytterhoeven
If NO_DMA=y:

ERROR: "bad_dma_ops" [drivers/media/platform/sti/c8sectpfe/c8sectpfe.ko] 
undefined!

Add a dependency on HAS_DMA to fix this.

Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
---
 drivers/media/platform/sti/c8sectpfe/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/c8sectpfe/Kconfig 
b/drivers/media/platform/sti/c8sectpfe/Kconfig
index 7420a50572d347ef..740190f8a3b606d3 100644
--- a/drivers/media/platform/sti/c8sectpfe/Kconfig
+++ b/drivers/media/platform/sti/c8sectpfe/Kconfig
@@ -1,6 +1,6 @@
 config DVB_C8SECTPFE
tristate "STMicroelectronics C8SECTPFE DVB support"
-   depends on PINCTRL && DVB_CORE && I2C
+   depends on PINCTRL && DVB_CORE && I2C && HAS_DMA
depends on ARCH_STI || ARCH_MULTIPLATFORM || COMPILE_TEST
select FW_LOADER
select DEBUG_FS
-- 
2.7.4



Re: [PATCH 1/2] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2017-11-16 Thread Geert Uytterhoeven
Hi Fabrizio,

On Thu, Nov 16, 2017 at 2:45 PM, Fabrizio Castro
<fabrizio.cas...@bp.renesas.com> wrote:
>> Subject: Re: [PATCH 1/2] dt-bindings: media: rcar_vin: add device tree 
>> support for r8a774[35]
>>
>> On Thu, Nov 16, 2017 at 1:11 PM, Fabrizio Castro
>> <fabrizio.cas...@bp.renesas.com> wrote:
>> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > @@ -14,7 +14,10 @@ channel which can be either RGB, YUYV or BT656.
>> > - "renesas,vin-r8a7790" for the R8A7790 device
>> > - "renesas,vin-r8a7779" for the R8A7779 device
>> > - "renesas,vin-r8a7778" for the R8A7778 device
>> > -   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
>> > +   - "renesas,vin-r8a7745" for the R8A7745 device
>> > +   - "renesas,vin-r8a7743" for the R8A7743 device
>>
>> Please keep the list sorted by SoC part number.
>
> It is sorted, just in descending order. Do you want me to re-order the full 
> list in ascending order?

That may be a good idea, given the current order is non-standard and
counter-intuitive.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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/2] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2017-11-16 Thread Geert Uytterhoeven
On Thu, Nov 16, 2017 at 1:11 PM, Fabrizio Castro
<fabrizio.cas...@bp.renesas.com> wrote:
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -14,7 +14,10 @@ channel which can be either RGB, YUYV or BT656.
> - "renesas,vin-r8a7790" for the R8A7790 device
> - "renesas,vin-r8a7779" for the R8A7779 device
> - "renesas,vin-r8a7778" for the R8A7778 device
> -   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> +   - "renesas,vin-r8a7745" for the R8A7745 device
> +   - "renesas,vin-r8a7743" for the R8A7743 device

Please keep the list sorted by SoC part number.

> +   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> + device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
>
> When compatible with the generic version nodes must list the

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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/2] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2017-11-16 Thread Geert Uytterhoeven
On Thu, Nov 16, 2017 at 1:11 PM, Fabrizio Castro
<fabrizio.cas...@bp.renesas.com> wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> change is needed as "renesas,rcar-gen2-vin" will activate the right

double "change"

> code. However, it is good practice to document compatible strings
> for the specific SoC as this allows SoC specific changes to the
> driver if needed, in addition to document SoC support and therefore
> allow checkpatch.pl to validate compatible string values.
>
> Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
> Reviewed-by: Biju Das <biju@bp.renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


[PATCH] media: dvb_frontend: Fix uninitialized error in dvb_frontend_handle_ioctl()

2017-11-16 Thread Geert Uytterhoeven
With gcc-4.1.2:

drivers/media/dvb-core/dvb_frontend.c: In function 
‘dvb_frontend_handle_ioctl’:
drivers/media/dvb-core/dvb_frontend.c:2110: warning: ‘err’ may be used 
uninitialized in this function

Indeed, there are 13 cases where err is used initialized if one of the
dvb_frontend_ops is not implemented.

Preinitialize err to -EOPNOTSUPP like before to fix this.

Fixes: d73dcf0cdb95a47f ("media: dvb_frontend: cleanup ioctl handling logic")
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
---
 drivers/media/dvb-core/dvb_frontend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 3ad83359098bde79..9eff8ce60d535379 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2107,7 +2107,7 @@ static int dvb_frontend_handle_ioctl(struct file *file,
struct dvb_frontend *fe = dvbdev->priv;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
struct dtv_frontend_properties *c = >dtv_property_cache;
-   int i, err;
+   int i, err = -ENOTSUPP;
 
dev_dbg(fe->dvb->device, "%s:\n", __func__);
 
-- 
2.7.4



Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

2017-11-15 Thread Geert Uytterhoeven
Hi Jacopo,

On Wed, Nov 15, 2017 at 7:15 PM, jacopo mondi <jac...@jmondi.org> wrote:
> On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
>> <jacopo+rene...@jmondi.org> wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
>> > @@ -0,0 +1,87 @@
>> > +Renesas Capture Engine Unit (CEU)
>> > +--
>> > +
>> > +The Capture Engine Unit is the image capture interface found on Renesas
>> > +RZ chip series and on SH Mobile ones.
>> > +
>> > +The interface supports a single parallel input with up 8/16bits data bus 
>> > width.
>>
>> ... with data bus widths up to 8/16 bits?
>>
>> > +
>> > +Required properties:
>> > +- compatible
>> > +   Must be "renesas,renesas-ceu".
>>
>> The double "renesas" part looks odd to me. What about "renesas,ceu"?
>
> I'm totally open for better "compatible" strings here, so yeah, let's
> got for the shorter one you proposed...
>
>> Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu",
>> too?
>
> Well, I actually have no SoC-specific data in the driver, so I don't
> need SoC specific "compatible" values. But if it's a good practice
> to have them anyway, I will add those in next spin..

You don't necessarily need them in the driver, but in the bindings and DTS,
just in case a difference is discovered later.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v1 06/10] sh: sh7722: Rename CEU clock

2017-11-15 Thread Geert Uytterhoeven
Hi Jacopo,

On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
<jacopo+rene...@jmondi.org> wrote:
> Rename CEU clock to match the new platform driver name used in Migo-R.
>
> There are no other sh7722 based devices Migo-R apart, so we can safely
> rename this.
>
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> ---
>  arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c 
> b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> index 8f07a1a..d85091e 100644
> --- a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> +++ b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> @@ -223,7 +223,7 @@ static struct clk_lookup lookups[] = {
> CLKDEV_DEV_ID("sh-vou.0", _clks[HWBLK_VOU]),
> CLKDEV_CON_ID("jpu0", _clks[HWBLK_JPU]),
> CLKDEV_CON_ID("beu0", _clks[HWBLK_BEU]),
> -   CLKDEV_DEV_ID("sh_mobile_ceu.0", _clks[HWBLK_CEU]),
> +   CLKDEV_DEV_ID("renesas-ceu.0", _clks[HWBLK_CEU]),
> CLKDEV_CON_ID("veu0", _clks[HWBLK_VEU]),
> CLKDEV_CON_ID("vpu0", _clks[HWBLK_VPU]),
> CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", _clks[HWBLK_LCDC]),

Shouldn't this be merged with "[PATCH v1 05/10] arch: sh: migor: Use new
renesas-ceu camera driver", to avoid breaking bisection?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v1 01/10] dt-bindings: media: Add Renesas CEU bindings

2017-11-15 Thread Geert Uytterhoeven
Hi Jacopo,

CC devicetree folks

On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
<jacopo+rene...@jmondi.org> wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
>
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..a88e9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,87 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with up 8/16bits data bus 
> width.

... with data bus widths up to 8/16 bits?

> +
> +Required properties:
> +- compatible
> +   Must be "renesas,renesas-ceu".

The double "renesas" part looks odd to me. What about "renesas,ceu"?
Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu",
too?

> +- reg
> +   Physical address base and size.
> +- interrupts
> +   The interrupt line number.

interrupt specifier

> +- pinctrl-names, pinctrl-0
> +   phandle of pin controller sub-node configuring pins for CEU 
> operations.
> +
> +CEU supports a single parallel input and should contain a single 'port' 
> subnode
> +with a single 'endpoint'. Optional endpoint properties applicable to parallel
> +input bus are described in "video-interfaces.txt".
> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and a

... an

> +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> +
> +ceu: ceu@e821 {
> +   reg = <0xe821 0x209c>;
> +   compatible = "renesas,renesas-ceu";
> +   interrupts = ;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   status = "okay";
> +
> +   port {
> +   ceu_in: endpoint {
> +   remote-endpoint = <_out>;
> +
> +   bus-width = <8>;
> +   hsync-active = <1>;
> +   vsync-active = <1>;
> +   pclk-sample = <1>;
> +   data-active = <1>;
> +   };
> +   };
> +};
> +
> +i2c1: i2c@fcfee400 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   status = "okay";
> +   clock-frequency = <10>;
> +
> +   ov7670: camera@21 {
> +   compatible = "ovti,ov7670";
> +   reg = <0x21>;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> +   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> +   clocks = <>;
> +   clock-names = "xclk";
> +
> +   xclk: fixed_clk {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <2400>;
> +   };
> +
> +   port {
> +   ov7670_out: endpoint {
> +   remote-endpoint = <_in>;
> +
> +   bus-width = <8>;
> +   hsync-active = <1>;
> +   vsync-active = <1>;
> +   pclk-sample = <1>;
> +   data-active = <1>;
> +   };
> +   };
> +   };
> --
> 2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v7 25/25] rcar-vin: enable support for r8a7796

2017-11-13 Thread Geert Uytterhoeven
CC DT

On Sat, Nov 11, 2017 at 1:38 AM, Niklas Söderlund
 wrote:
> Add the SoC specific information for Renesas r8a7796.
>
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/rcar_vin.txt |  1 +
>  drivers/media/platform/rcar-vin/rcar-core.c| 64 
> ++
>  2 files changed, 65 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index df1abd0fb20386f8..ddf249c2276600d2 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -10,6 +10,7 @@ Depending on the instance the VIN input is connected to 
> external SoC pins, or
>  on Gen3 to a CSI-2 receiver.
>
>   - compatible: Must be one or more of the following
> +   - "renesas,vin-r8a7796" for the R8A7796 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7793" for the R8A7793 device
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index b22f6596700d2479..e329de4ce0172e8d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1084,6 +1084,66 @@ static const struct rvin_info rcar_info_r8a7795es1 = {
> },
>  };
>
> +static const struct rvin_info rcar_info_r8a7796 = {
> +   .chip = RCAR_GEN3,
> +   .use_mc = true,
> +   .max_width = 4096,
> +   .max_height = 4096,
> +
> +   .num_chsels = 5,
> +   .chsels = {
> +   {
> +   { .csi = RVIN_CSI40, .chan = 0 },
> +   { .csi = RVIN_CSI20, .chan = 0 },
> +   { .csi = RVIN_NC, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 0 },
> +   { .csi = RVIN_CSI20, .chan = 0 },
> +   }, {
> +   { .csi = RVIN_CSI20, .chan = 0 },
> +   { .csi = RVIN_NC, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 1 },
> +   { .csi = RVIN_CSI20, .chan = 1 },
> +   }, {
> +   { .csi = RVIN_NC, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 0 },
> +   { .csi = RVIN_CSI20, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 2 },
> +   { .csi = RVIN_CSI20, .chan = 2 },
> +   }, {
> +   { .csi = RVIN_CSI40, .chan = 1 },
> +   { .csi = RVIN_CSI20, .chan = 1 },
> +   { .csi = RVIN_NC, .chan = 1 },
> +   { .csi = RVIN_CSI40, .chan = 3 },
> +   { .csi = RVIN_CSI20, .chan = 3 },
> +   }, {
> +   { .csi = RVIN_CSI40, .chan = 0 },
> +   { .csi = RVIN_CSI20, .chan = 0 },
> +   { .csi = RVIN_NC, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 0 },
> +   { .csi = RVIN_CSI20, .chan = 0 },
> +   }, {
> +   { .csi = RVIN_CSI20, .chan = 0 },
> +   { .csi = RVIN_NC, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 1 },
> +   { .csi = RVIN_CSI20, .chan = 1 },
> +   }, {
> +   { .csi = RVIN_NC, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 0 },
> +   { .csi = RVIN_CSI20, .chan = 0 },
> +   { .csi = RVIN_CSI40, .chan = 2 },
> +   { .csi = RVIN_CSI20, .chan = 2 },
> +   }, {
> +   { .csi = RVIN_CSI40, .chan = 1 },
> +   { .csi = RVIN_CSI20, .chan = 1 },
> +   { .csi = RVIN_NC, .chan = 1 },
> +   { .csi = RVIN_CSI40, .chan = 3 },
> +   { .csi = RVIN_CSI20, .chan = 3 },
> +   },
> +   },
> +};
> +
>  static const struct of_device_id rvin_of_id_table[] = {
> {
> .compatible = "renesas,vin-r8a7778",
> @@ -1117,6 +1177,10 @@ static const struct of_device_id rvin_of_id_table[] = {
> .compatible = "renesas,vin-r8a7795",
> .data = _info_r8a7795,
> },
> +   {
> +   .compatible = "renesas,vin-r8a7796",
> +   .data = _info_r8a7796,
> +   },
> { },
>  };
>  MODULE_DEVICE_TABLE(of, rvin_of_id_table);
> --
> 2.15.0


Re: [PATCH v9 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

2017-11-10 Thread Geert Uytterhoeven
Hi Niklas,

On Fri, Nov 10, 2017 at 12:43 AM, Niklas Söderlund
<niklas.soderlund+rene...@ragnatech.se> wrote:
> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> hardware blocks are connected between the video sources and the video
> grabbers (VIN).
>
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Thanks for your patch!

> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -0,0 +1,933 @@

> +/* Control Timing Select */
> +#define TREF_REG   0x00
> +#define TREF_TREF  (1 << 0)

BIT(0)? (many more)

> +struct phypll_hsfreqrange {
> +   unsigned intmbps;
> +   unsigned char   reg;

The "unsigned char" doesn't buy you much, due to alignment rules.
What about making both u16 instead?

> +static const struct rcar_csi2_format *rcar_csi2_code_to_fmt(unsigned int 
> code)
> +{
> +   int i;

unsigned int

> +
> +   for (i = 0; i < ARRAY_SIZE(rcar_csi2_formats); i++)
> +   if (rcar_csi2_formats[i].code == code)
> +   return rcar_csi2_formats + i;
> +   return NULL;
> +}

> +struct rcar_csi2_info {
> +   const struct phypll_hsfreqrange *hsfreqrange;
> +   bool clear_ulps;
> +   bool have_phtw;
> +   unsigned int csi0clkfreqrange;

I'd sort by decreasing size/alignment, i.e. the bools last.

> +};
> +
> +struct rcar_csi2 {
> +   struct device *dev;
> +   void __iomem *base;
> +   const struct rcar_csi2_info *info;
> +
> +   unsigned short lanes;
> +   unsigned char lane_swap[4];
> +
> +   struct v4l2_subdev subdev;
> +   struct media_pad pads[NR_OF_RCAR_CSI2_PAD];
> +
> +   struct v4l2_mbus_framefmt mf;
> +
> +   struct mutex lock;
> +   int stream_count;
> +
> +   struct v4l2_async_notifier notifier;
> +   struct v4l2_async_subdev remote;

Likewise.

> +static int rcar_csi2_start(struct rcar_csi2 *priv)
> +{

> +   dev_dbg(priv->dev, "Input size (%dx%d%c)\n", mf->width,

%u for __u32

> +   mf->height, mf->field == V4L2_FIELD_NONE ? 'p' : 'i');

> +static int rcar_csi2_probe_resources(struct rcar_csi2 *priv,
> +struct platform_device *pdev)
> +{
> +   struct resource *mem;
> +   int irq;
> +
> +   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +   if (!mem)

No need to check mem, platform_get_resource() and devm_ioremap_resource()
are designed to be pipelined.

> +   return -ENODEV;
> +
> +   priv->base = devm_ioremap_resource(>dev, mem);


> +static const struct soc_device_attribute r8a7795es1[] = {
> +   { .soc_id = "r8a7795", .revision = "ES1.*" },
> +   { /* sentinel */ }
> +};
> +
> +static int rcar_csi2_probe(struct platform_device *pdev)
> +{
> +   struct rcar_csi2 *priv;
> +   unsigned int i;
> +   int ret;
> +
> +   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> +   if (!priv)
> +   return -ENOMEM;
> +
> +   priv->info = of_device_get_match_data(>dev);
> +
> +   /* r8a7795 ES1.x behaves different then ES2.0+ but no own compat */
> +   if (priv->info == _csi2_info_r8a7795 &&
> +   soc_device_match(r8a7795es1))
> +   priv->info = _csi2_info_r8a7795es1;

Please store _csi2_info_r8a7795es1 in r8a7795es1[0].data instead.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v9 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

2017-11-10 Thread Geert Uytterhoeven
Hi Niklas,

On Fri, Nov 10, 2017 at 12:43 AM, Niklas Söderlund
<niklas.soderlund+rene...@ragnatech.se> wrote:
> Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> are located between the video sources (CSI-2 transmitters) and the video
> grabbers (VIN) on Gen3 of Renesas R-Car SoC.
>
> Each CSI-2 device is connected to more then one VIN device which
> simultaneously can receive video from the same CSI-2 device. Each VIN
> device can also be connected to more then one CSI-2 device. The routing
> of which link are used are controlled by the VIN devices. There are only
> a few possible routes which are set by hardware limitations, which are
> different for each SoC in the Gen3 family.
>
> To work with the limitations of routing possibilities it is necessary
> for the DT bindings to describe which VIN device is connected to which
> CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> VIN device that be connected to it. To setup and to know which links are
> valid for each SoC is the responsibility of the VIN driver since the
> register to configure it belongs to the VIN hardware.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
>  .../devicetree/bindings/media/rcar-csi2.txt| 103 
> +
>  MAINTAINERS|   1 +
>  2 files changed, 104 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
>
> diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt 
> b/Documentation/devicetree/bindings/media/rcar-csi2.txt
> new file mode 100644
> index ..39d41d82b71b60eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt

> +Example:
> +
> +   csi20: csi2@fea8 {
> +   compatible = "renesas,r8a7796-csi2", "renesas,rcar-gen3-csi2";
> +   reg = <0 0xfea8 0 0x1>;
> +   interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> +   clocks = < CPG_MOD 714>;
> +   power-domains = < R8A7796_PD_ALWAYS_ON>;

resets?

I know this is just an example, but your prototype patches to add the
csi nodes to r8a7795.dtsi also don't have reset properties.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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


  1   2   3   4   >