Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20

On Thu, Oct 4, 2018 at 5:39 PM Geert Uytterhoeven wrote: > On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven > wrote: > > On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann wrote: > > > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven > > > wrote: > > >

Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20

On Thu, Oct 4, 2018 at 9:58 AM Geert Uytterhoeven wrote: > On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven > wrote: > > On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann wrote: > > > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven > > > wrote: > > >

Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20

On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven wrote: > > Hi Arnd, > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann wrote: > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman > > wrote: > > > * Add support for RZ/G2E (r8a774c0) and RZ/G2M (r8a774a1) SoCs &

Re: [GIT PULL] Renesas ARM Based SoC Drivers Updates for v4.20

On Fri, Sep 28, 2018 at 12:23 PM Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC drivers updates for v4.20. > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > >

Re: [GIT PULL] Renesas ARM Based SoC Updates for v4.20

On Fri, Sep 28, 2018 at 12:22 PM Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC updates for v4.20. > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are

Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20

On Fri, Sep 28, 2018 at 12:21 PM Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM64 based SoC SoC updates for v4.20. > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are

Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.20

On Fri, Sep 28, 2018 at 12:21 PM Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC defconfig updates for v4.20. > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > >

Re: [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.20

On Fri, Sep 28, 2018 at 12:19 PM Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM64 based SoC defconfig updates for v4.20. > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) >

Re: [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.20

On Fri, Sep 28, 2018 at 12:23 PM Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC DT bindings updates for v4.20. > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) >

Re: [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.20

On Fri, Sep 28, 2018 at 12:22 PM Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM based SoC DT updates for > v4.20. > > This pull request is based on the previous round of > such requests, tagged as renesas-arm-dt-for-v4.20, > which you

Re: [GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.20

On Fri, Sep 28, 2018 at 12:20 PM Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM64 based SoC DT updates for > v4.20. > > This pull request is based on the previous round of > such requests, tagged as renesas-arm64-dt-for-v4.20, > which

[PATCH 2/2] ARM: shmobile: only call secure_cntvoff_init on SMP builds

cad160ed0a94 ("ARM: shmobile: Convert file to use cntvoff") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/arm/mach-shmobile/setup-rcar-gen2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shm

[PATCH 4/8] drm/rcar-du: fix merge conflict for state->alpha

: Convert to the new generic alpha property") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 4a

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

epend on the first 6 patches, and are thus marked > RFC. This all looks fine to me. Acked-by: Arnd Bergmann <a...@arndb.de> Arnd

Re: [GIT PULL] Renesas ARM Based SoC Updates for v4.17

On Fri, Mar 16, 2018 at 3:53 PM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC updates for v4.17. > Pulled into next/soc, thanks! Arnd

Re: [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.17

On Tue, Mar 27, 2018 at 3:13 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Fri, Mar 16, 2018 at 3:50 PM, Simon Horman > <horms+rene...@verge.net.au> wrote: >> Renesas ARM64 Based SoC Defconfig Updates for v4.17 >> >> Enable the following to allow them to be mor

Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.17

On Fri, Mar 16, 2018 at 3:51 PM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC defconfig updates for v4.17. > > > The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: > > Linux 4.16-rc1

Re: [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.17

On Fri, Mar 16, 2018 at 3:50 PM, Simon Horman wrote: > Renesas ARM64 Based SoC Defconfig Updates for v4.17 > > Enable the following to allow them to be more widely exercised: > * Newly added R8A77965 and R8A77980 SoCs > * PWM and USB as used on R-Car Gen3 SoCs >

Re: [GIT PULL v2] Renesas ARM Based SoC DT Updates for v4.17

On Fri, Mar 16, 2018 at 5:38 PM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC DT updates for v4.17. > > Changes since v1 > * Dropped r7s72100 to avoid conflict, I will see about resubmitting > those still relevant

Re: [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.17

On Fri, Mar 16, 2018 at 3:52 PM, Simon Horman wrote: > Renesas ARM Based SoC DT Bindings Updates for v4.17 > > * Document the bindings for: > - R-Car V3H (r8a77980) SoC > - Condor board with V3H (r8a77980) SoC > - Stout (ADAS Starterkit) board with R-Car H2

Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.17

On Fri, Mar 16, 2018 at 3:51 PM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM64 based SoC DT updates for v4.17. > Pulled into next/dt, thanks! Arnd

Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

On Tue, Mar 20, 2018 at 9:15 PM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > Hi Arnd, > > On Friday, 16 March 2018 10:25:25 EET Arnd Bergmann wrote: >> On Fri, Mar 16, 2018 at 2:39 AM, <frank.row...@sony.com> wrote: >> > On Thursday, March 1

Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

On Fri, Mar 16, 2018 at 2:39 AM, <frank.row...@sony.com> wrote: > On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann [mailto:a...@arndb.de] > wrote: >> >> The *.dtb and *.dtb.S files get removed by 'make' during the build >> process, >> and later seem to

[PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

for a better fix? Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder nodes") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/gpu/drm/rcar-du/Makefile | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/Makefile b/driv

[PATCH] media: renesas-ceu: mark PM functions as __maybe_unused

media: platform: Add Renesas CEU driver") Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/media/platform/renesas-ceu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/renesas-ceu.c b/drivers/media/platform/renesas-ceu.c in

Re: [PATCH v2 09/19] ARM64: dts: Add R-Car Salvator-x M3-N support

On Thu, Feb 22, 2018 at 4:38 PM, Simon Horman wrote: > On Thu, Feb 22, 2018 at 02:28:46PM +0100, Geert Uytterhoeven wrote: >> Removing the .dts file removes the ability to boot the newly added board... >> >> The issue here is that we are sharing board .dtsi for boards that

Re: [PATCH v2 09/19] ARM64: dts: Add R-Car Salvator-x M3-N support

On Wed, Feb 21, 2018 at 6:15 PM, Simon Horman wrote: > On Tue, Feb 20, 2018 at 04:46:23PM +0100, Geert Uytterhoeven wrote: >> On Tue, Feb 20, 2018 at 4:12 PM, Jacopo Mondi >> wrote: >> > Add basic support for R-Car Salvator-X M3-N (R8A77965) board.

[PATCH] clk: fix false-positive Wmaybe-uninitialized warning

ore it can be removed, but I'm not sure about how to best do that. Cc: sta...@vger.kernel.org Cc: Andi Kleen <a...@linux.intel.com> Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/clk/renesas/clk-sh73a0.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.15

On Fri, Dec 22, 2017 at 11:30 AM, Simon Horman wrote: > Renesas ARM Based SoC Fixes for v4.15 > > Vladimir Zapolskiy says: > > The present change is a bug fix for AVB link iteratively up/down. > > Steps to reproduce: > - start AVB TX stream (Using aplay via MSE), > -

Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.16

On Thu, Dec 7, 2017 at 10:53 AM, Simon Horman wrote: > > > Renesas ARM64 Based SoC DT Updates for v4.16 > > * Use r8a77970 (V3M) CPG core clock and SYSC power domain macros > > These may be used in

Re: [GIT PULL] Renesas ARM Based SoC Updates for v4.16

On Wed, Dec 6, 2017 at 11:21 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC updates for v4.16. > > > The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: > > Linux 4.15-rc1 (2017-11-26

Re: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.16

On Wed, Dec 6, 2017 at 11:22 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC DT updates for v4.16. > > > The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: > > Linux 4.15-rc1 (2017-11-26

Re: [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.16

On Wed, Dec 6, 2017 at 11:21 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC DT bindings updates for v4.16. > > > The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: > > Linux 4.15-rc1

Re: [PATCH] ARM: dts: r8a779x: Add '#reset-cells' in cpg-mssr

u, Nov 16, 2017 at 02:35:57PM +0100, Geert Uytterhoeven wrote: >> >> From: Arnd Bergmann <a...@arndb.de> >> >> >> >> With the latest dtc, we get many warnings about the missing >> >> '#reset-cells' property in these controllers, e.g.: >> >>

Re: [GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.15

On Fri, Oct 20, 2017 at 12:28 PM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM64 based SoC DT updates for > v4.15. > > This pull request is based on the previous round of > such requests, tagged as

Re: [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.15

On Fri, Oct 20, 2017 at 12:29 PM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM based SoC DT updates for > v4.15. > > This pull request is based on the previous round of > such requests, tagged as

Re: [GIT PULL] Renesas ARM Based SoC Drivers Updates for v4.15

On Mon, Sep 25, 2017 at 9:53 AM, Simon Horman wrote: > Renesas ARM Based SoC Drivers Updates for v4.15 > > Add basic support for R-Car V3M (R8A77970) SoC. > > Sergei Shtylyov says: > > * Add support for R-Car V3M (R8A77970) SoC power areas to the R-Car SYSC > driver

Re: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.15

On Fri, Sep 29, 2017 at 1:53 PM, Simon Horman wrote: > > Renesas ARM Based SoC DT Updates for v4.15 > > * r7s72100 (RZ/A1) Peach board > - Add pin groups for SCIF2 serial debug interface and Ethernet >

Re: [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.15

On Fri, Sep 29, 2017 at 1:52 PM, Simon Horman wrote: > > Renesas ARM Based SoC DT Bindings Updates for v4.15 > > * Consistently do not use ';' in documentation of compat strings > for boards. A misture

Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.15

On Fri, Sep 29, 2017 at 1:52 PM, Simon Horman wrote: > > Renesas ARM64 Based SoC DT Updates for v4.15 > > * r8a7795 (H3) > - Use r8a7795-cpg-mssr and r8a7795-sysc bindings > Hardcoded indicies are

Re: [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.15

On Tue, Oct 10, 2017 at 10:12 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM based SoC updates for v4.15. > > This pull request is based on the previous round of > such requests, tagged as

Re: [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.15

On Fri, Sep 29, 2017 at 1:52 PM, Simon Horman wrote: > > > Renesas ARM64 Based SoC Defconfig Updates for v4.15 > > * Enable the following to allow further test coverage > - r8a77970 (V3M) and r8a77995

Re: [GIT PULL] Renesas ARM Based SoC Updates for v4.15

On Mon, Sep 25, 2017 at 9:54 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC updates for v4.15. > > > The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: > > Linux 4.14-rc1 (2017-09-16

Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.14

On Mon, Sep 25, 2017 at 9:54 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC fixes for v4.14. > > > The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: > > Linux 4.14-rc1 (2017-09-16

Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.15

On Mon, Sep 25, 2017 at 9:53 AM, Simon Horman wrote: > ARM: multi_v7_defconfig: Enable BQ32000 RTC driver (2017-09-18 07:57:41 > +0200) > > > Renesas ARM Based SoC Defconfig Updates for v4.15 > >

Re: [PATCH 0/4] ipmmu-vmsa cleanup

On Fri, Oct 13, 2017 at 8:23 PM, Robin Murphy wrote: > Arnd reports a build warning[1] thanks to me missing ipmmu-vmsa's second > set of ops when converting io-pgtable-arm users to the new iommu_iotlb_* > callbacks. Rather than just treat the symptom with a point fix, this >

Re: [PATCH] ARM: dts: r8a779x: add '#reset-cells' in cpg-mssr

On Tue, Oct 10, 2017 at 10:45 AM, Arnd Bergmann <a...@arndb.de> wrote: > With the latest dtc, we get many warnings about the missing > '#reset-cells' property in these controllers, e.g.: > > arch/arm/boot/dts/r8a7790-lager.dtb: Warning (resets_property): Missing > property '

[PATCH] ARM: dts: r8a779x: add '#reset-cells' in cpg-mssr

-controller@e615 or bad phandle (referred from /interrupt-controller@e61c:resets[0]) This adds it for the three r8a779x chips that were lacking it. The binding mandates this as <1>, so this is the value I use. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/arm/boot/dts/

Re: [PATCH] ARM: shmobile: rcar-gen2: fix non-SMP build

On Thu, Oct 5, 2017 at 2:25 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > On Thu, Oct 5, 2017 at 2:09 PM, Arnd Bergmann <a...@arndb.de> wrote: >> arch/arm/mach-shmobile/headsmp-apmu.S | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git

[PATCH] ARM: shmobile: rcar-gen2: fix non-SMP build

I'm leaving it always enabled in the Makefile, but enclose the SMP code in an #ifdef. 3fd45a136ff6 ("ARM: shmobile: rcar-gen2: Make sure CNTVOFF is initialized on CA7/15") Signed-off-by: Arnd Bergmann <a...@arndb.de> Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/arm

[PATCH] [media] rcar_drif: fix potential uninitialized variable use

for it in the future, it's also a good idea to shut it up now. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203 Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drivers/media/platform/rcar_drif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/rcar_dri

Re: [GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.14

On Fri, Aug 18, 2017 at 10:19 AM, Simon Horman wrote: > Second Round of Renesas ARM64 Based SoC DT Updates for v4.14 > > * Add PFC device node to R-Car D3 (r8a77995) > > This is a step towards enabling devices that use multiplexed pins > - including ethernet - on

Re: [GIT PULL] Second Round of Renesas ARM Based SoC DT Bindings Updates for v4.14

On Fri, Aug 18, 2017 at 10:20 AM, Simon Horman wrote: > Second Round of Renesas ARM Based SoC DT Bindings Updates for v4.14 > > * Add RZ/G1M (r8a7743) binding to apmu driver > > This allows SMP to be supported on the RZ/G1M SoC > > * Add bindings for

Re: [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.14

On Fri, Aug 18, 2017 at 10:19 AM, Simon Horman wrote: > Second Round of Renesas ARM Based SoC DT Updates for v4.14 > > * Use newly added Gen-3 fallback compat string > > This is consistent with ongoing efforts to use per-generation > fallback strings where

Re: [GIT PULL] Second Round of Renesas ARM Based SoC Defconfig Updates for v4.14

On Thu, Aug 17, 2017 at 11:49 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM based SoC defconfig updates > for v4.14. > > This pull request is based on the previous round of > such requests, tagged as

Re: [GIT PULL] Fourth Round of Renesas ARM Based SoC Fixes for v4.13

On Thu, Aug 17, 2017 at 10:56 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these fourth round of Renesas ARM based SoC fixes for v4.13. > > This pull request is based on the second round of > such requests, tagged as

Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.14

On Mon, Jul 31, 2017 at 5:03 PM, Simon Horman wrote: > > Renesas ARM64 Based SoC DT Updates for v4.14 > > * Add usb2.0 for R-Car H3 (r8a7795) ES2.0 SoC > > * Add R-Car D3 (r8a77995) SoC and Draak board

Re: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.14

On Mon, Jul 31, 2017 at 5:19 PM, Simon Horman wrote: > Renesas ARM Based SoC DT Updates for v4.14 > > Changes of note: > > * Add pin controller support to the RZ/G1M (r8a7743) SoC and > RZ/A1 (r7s72100) SoCs now that the driver is available in v4.13-rc1. > > * Add

Re: [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.14

On Mon, Jul 31, 2017 at 5:04 PM, Simon Horman wrote: > Renesas ARM Based SoC DT Bindings Updates for v4.14 > > * Document R-Car D3 (r8a77995) SoC and Draak board > > * Document reserved SRAM for the SMP jump stub on R-Car Gen2 and RZ/G1 SoCs > > Geert Uytterhoeven

Re: [GIT PULL] Renesas ARM Based SoC Updates for v4.14

On Mon, Jul 31, 2017 at 5:05 PM, Simon Horman wrote: > > * Add debug-ll support to RZ/G1M (r8a7743) SoC > > Chris Paterson says, "RZ/G1M uses SCIF0 for the debug console, like most > of the R-Car Gen2 SoCs." > > * Remove ARCH_SHMOBILE_MULTI > > Geert Uytterhoeven

Re: [PATCH v2] ARM: Convert to using %pOF instead of full_name

On Thu, Aug 10, 2017 at 12:06 AM, Rob Herring wrote: > On Fri, Jul 21, 2017 at 2:28 PM, Rob Herring wrote: >> Now that we have a custom printf format specifier, convert users of >> full_name to use %pOF instead. This is preparation to remove storing >> of the

Re: [GIT PULL] Renesas ARM Based SoC Drivers Updates for v4.14

On Mon, Jul 31, 2017 at 5:04 PM, Simon Horman wrote: > > Renesas ARM Based SoC Drivers Updates for v4.14 > > Add R-Car D3 (r8a77995) support to the Renesas-specific SoC drivers > - SoC identification > -

Re: [PATCH] soc: Convert to using %pOF instead of full_name

On Thu, Aug 10, 2017 at 12:09 AM, Rob Herring wrote: > On Tue, Jul 18, 2017 at 4:43 PM, Rob Herring wrote: >> Now that we have a custom printf format specifier, convert users of >> full_name to use %pOF instead. This is preparation to remove storing >> of the

Re: [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.14

On Mon, Jul 31, 2017 at 5:02 PM, Simon Horman wrote: > > Renesas ARM64 Based SoC Defconfig Updates for v4.14 > > * compile ak4613 and renesas sound as modules > > This is intended to reduce the size of

Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.14

On Mon, Jul 31, 2017 at 5:03 PM, Simon Horman wrote: > > Renesas ARM Based SoC Defconfig Updates for v4.14 > > * Enable DMA for Renesas serial ports > > Geert Uytterhoeven says, "DMA for (H)SCIF(A|B)

Re: [GIT PULL] Third Round of Renesas ARM Based SoC Fixes for v4.13

On Mon, Jul 31, 2017 at 1:12 PM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these third round of Renesas ARM based SoC fixes for v4.13. > > This pull request is based on v4.12-rc1 rather than earlier fixes for v4.13 > as it is unrelated to

Re: [GIT PULL] Second Round of Renesas ARM Based SoC Fixes for v4.13

On Fri, Jul 14, 2017 at 10:04 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these second round of Renesas ARM based SoC fixes for v4.13. > > This pull request is based on the previous round of > such requests, tagged as

Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.13

On Fri, Jun 30, 2017 at 11:16 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider this Renesas ARM based SoC fix for v4.13. > > This pull request is based on > "[GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.13", > tagged as

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

On Mon, Jul 17, 2017 at 4:35 PM, Hans Verkuil <hverk...@xs4all.nl> wrote: > On 17/07/17 16:26, Arnd Bergmann wrote: >> Let me try again without ccache for now and see what warnings remain. >> We can find a solution for those first, and then decide how to deal with >&

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil <hverk...@xs4all.nl> wrote: > On 14/07/17 11:36, Arnd Bergmann wrote: >> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, >> void *fh, >>* digitizer/slicer. Note, cx18_av_vbi() wipes th

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

On Fri, Jul 14, 2017 at 3:09 PM, Dan Carpenter wrote: > On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote: >> I don't agree with it as a static analysis dev... > > What I mean is if it's a macro that returns -ENODEV or a function that > returns -ENODEV, they

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

On Fri, Jul 14, 2017 at 2:05 PM, Dan Carpenter wrote: > Changing: > > - if (!frob()) { > + if (frob() == 0) { > > is a totally pointless change. They're both bad, because they're doing > success testing instead of failure testing, but probably the second one > is

[PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

riable is usually ok, and sometimes this can be used to propagate or print an error code, so I do that. For the 'while' loops, I ended up adding an otherwise useless comparison with zero, which unfortunately makes the code a little uglied. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- drive

Re: [PATCH 9/9] ARM: multi_v7_defconfig: Enable DMA for Renesas serial ports

On Tue, Jul 11, 2017 at 8:59 AM, Geert Uytterhoeven wrote: > Hi Magnus, > > On Tue, Jul 11, 2017 at 5:38 AM, Magnus Damm wrote: >> On Mon, Jul 10, 2017 at 10:28 PM, Geert Uytterhoeven >> Since enabling DMA Engine still keeps PIO support around I

Re: [PATCH 9/9] ARM: multi_v7_defconfig: Enable DMA for Renesas serial ports

On Tue, Jul 11, 2017 at 8:59 AM, Geert Uytterhoeven wrote: > Whether we want to hide the option (and default to y if ARCH_RENESAS, i.e. > ARM) is another question. Note that that wouldn't reduce code > maintainability, > as the #ifdefs would be kept, and it would prevent

Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.12

On Tue, May 2, 2017 at 10:35 AM, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC fixes for v4.12. > > * Fix from Geert Uytterhoeven to avoid an undefined reference > to `rcar_rst_read_mode_pins' in the case where the

Re: [PATCH v2 0/6] mmc: renesas-sdhi: refactor DMA support

> > [1] http://www.spinics.net/lists/linux-mmc/msg38004.html > > Unlike that patch-set this patch-set does not add support for > R-Car Gen-3 DMA. Rather it focuses on refactoring the code. (whole series) Acked-by: Arnd Bergmann <a...@arndb.de>

Re: [PATCH/RFC 0/5] mmc: renesas-sdhi: refactor DMA support

On Tue, May 2, 2017 at 1:15 PM, Simon Horman wrote: > Hi Wolfram, Hi Arnd, Hi all, > > the intention of this patch-set is to refactor the DMA support in > the Renesas SDHI driver in order to make it easier to add support > for using the SDHI hardware with different DMA

Re: [PATCH/RFC 1/5] mmc: renesas-sdhi, tmio: make dma more modular

On Tue, May 2, 2017 at 1:15 PM, Simon Horman wrote: > @@ -202,6 +214,15 @@ void tmio_mmc_enable_mmc_irqs(struct tmio_mmc_host > *host, u32 i); > void tmio_mmc_disable_mmc_irqs(struct tmio_mmc_host *host, u32 i); > irqreturn_t tmio_mmc_irq(int irq, void *devid); > >

Re: [PATCH v2 0/2] base: soc: soc_device_match() improvements

On Wed, Mar 29, 2017 at 9:38 PM, Geert Uytterhoeven wrote: > Hi Arnd, Greg, Kevin, Magnus, Olof, Simon, > > This patch series contains two improvements for the SoC bus and > soc_device_match(). The second one is a dependency for handling > different SoC revisions

Re: [PATCH 2/2] [RFC] base: soc: Allow early registration of a single SoC device

On Mon, Mar 13, 2017 at 1:46 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > On Mon, Mar 13, 2017 at 1:41 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Thu, Mar 9, 2017 at 7:18 PM, Geert Uytterhoeven >> >> I'd prefer to not have to do the early registration

Re: [PATCH 2/2] [RFC] base: soc: Allow early registration of a single SoC device

On Thu, Mar 9, 2017 at 7:18 PM, Geert Uytterhoeven wrote: > commit 1da1b3628df34a2a ("base: soc: Early register bus when needed") > added support for early registration of SoC devices from a > core_initcall(). However, some drivers need to check the SoC revision > from

Re: [PATCH 1/2] [RFC] base: soc: Let soc_device_match() return no match when called too early

ytterhoeven <geert+rene...@glider.be> > --- Acked-by: Arnd Bergmann <a...@arndb.de> > Should this use WARN_ONCE()? I wouldn't mind that either, but your current version seems sufficient.

Re: [PATCH v4 0/3] ARM: l2c: add l2c support for RZ/A1

erged > independently... Arnd? I just checked what we have queued up in next/dt for this platform, and I'm fairly sure that there are no conflicts, so you can pick up all three and add Acked-by: Arnd Bergmann <a...@arndb.de> Arnd

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Thursday, December 29, 2016 11:45:03 PM CET Nikita Yushchenko wrote: > > static int __swiotlb_dma_supported(struct device *hwdev, u64 mask) > { > +#ifdef CONFIG_PCI > + if (dev_is_pci(hwdev)) { > + struct pci_dev *pdev = to_pci_dev(hwdev); > + struct

Re: [PATCH 1/2] ARM: add ARM_SINGLE_ARMV7 as config option

On Thursday, February 9, 2017 8:21:43 PM CET Chris Brandt wrote: > On Thursday, February 09, 2017, Florian Fainelli worte: > > > I think the closest I might have come was to purposely break the build > > > if more then 1 was select, but that still didn't stop you from making > > > the selection. >

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

On Thursday, January 12, 2017 9:33:32 AM CET Nikita Yushchenko wrote: > >> Hmm, I think when the dma-ranges are missing, we should either enforce > >> a 32-bit mask, or disallow DMA completely. It's probably too late for > >> the latter, I wish we had done this earlier in order to force everyone >

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote: > On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote: > > >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > > >> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > > >> index 5ac373c..480b644 100644 > > >> ---

Re: NVMe vs DMA addressing limitations

On Thursday, January 12, 2017 12:09:11 PM CET Sagi Grimberg wrote: > >> Another workaround me might need is to limit amount of concurrent DMA > >> in the NVMe driver based on some platform quirk. The way that NVMe works, > >> it can have very large amounts of data that is concurrently mapped into

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

On Wednesday, January 11, 2017 9:31:51 PM CET Nikita Yushchenko wrote: > diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c > index 9afcbf7..0995ab3 100644 > --- a/drivers/iommu/rockchip-iommu.c > +++ b/drivers/iommu/rockchip-iommu.c > @@ -1096,7 +1096,7 @@ static int

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On Wednesday, January 11, 2017 3:37:22 PM CET Nikita Yushchenko wrote: > > I actually have a third variation of this problem involving a PCI root > > complex which *could* drive full-width (40-bit) addresses, but won't, > > due to the way its PCI<->AXI interface is programmed. That would require >

Re: NVMe vs DMA addressing limitations

On Tuesday, January 10, 2017 3:48:39 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote: > > Another workaround me might need is to limit amount of concurrent DMA > > in the NVMe driver based on some platform quirk. The way that NVMe wo

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On Tuesday, January 10, 2017 2:16:57 PM CET Robin Murphy wrote: > On 10/01/17 13:42, Arnd Bergmann wrote: > > On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: > >> On 10/01/17 12:47, Nikita Yushchenko wrote: > >>>> The point here is that

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > > 32-bit architectures without swiotlb (arc, arm, some mips32), and > >

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: > On 10/01/17 12:47, Nikita Yushchenko wrote: > >> The point here is that an IOMMU doesn't solve your issue, and the > >> IOMMU-backed DMA ops need the same treatment. In light of that, it really > >> feels to me like the DMA masks

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On Tuesday, January 10, 2017 3:47:25 PM CET Nikita Yushchenko wrote: > > > The point here is that an IOMMU doesn't solve your issue, and the > > IOMMU-backed DMA ops need the same treatment. In light of that, it really > > feels to me like the DMA masks should be restricted in of_dma_configure >

Re: NVMe vs DMA addressing limitations

On Tuesday, January 10, 2017 10:31:47 AM CET Nikita Yushchenko wrote: > Christoph, thanks for clear input. > > Arnd, I think that given this discussion, best short-term solution is > indeed the patch I've submitted yesterday. That is, your version + > coherent mask support. With that,

Re: NVMe vs DMA addressing limitations

On Tuesday, January 10, 2017 8:07:20 AM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote: > > I'm now working with HW that: > > - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores, > > and is being manufactured and developed, > > -

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Monday, January 9, 2017 9:57:46 PM CET Christoph Hellwig wrote: > > - architecture should stop breaking 64-bit DMA when driver attempts to > > set 64-bit dma mask, > > > > - NVMe should issue proper blk_queue_bounce_limit() call based on what > > is actually set mask, > > Or even better

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Friday, January 6, 2017 4:47:59 PM CET Nikita Yushchenko wrote: > >>> Just a guess, but if the inbound translation windows in the host > >>> bridge are wider than 32-bit, the reason for setting up a single > >>> 32-bit window is probably because that is what the parent bus supports. > > I've

  1   2   >