[PATCH v2 13/13] sh: lib: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto --- arch/sh/lib/ashiftrt.S | 29 - arch/sh/lib/ashlsi3.S| 29 - arch/sh/li

[PATCH v2 11/13] sh: cpu: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/cpu/clock.c| 5 + arch/sh/kernel/cpu/init.c | 5 + arch/sh/kernel/cpu/ir

[PATCH v2 12/13] sh: kernel: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/debugtraps.S| 7 ++- arch/sh/kernel/disassemble.c | 5 + arch/sh/kernel/dm

[PATCH v2 10/13] sh: shmobile: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/cpu/shmobile/Makefile | 1 + arch/sh/kernel/cpu/shmobile/cpuidle.c | 5 + arch/sh/kernel/cpu/

[PATCH v2 09/13] sh: sh5: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/cpu/sh5/clock-sh5.c | 5 + arch/sh/kernel/cpu/sh5/entry.S | 7 ++- arch/sh/kernel/cpu/

[PATCH v2 06/13] sh: sh3: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/cpu/sh3/clock-sh3.c | 5 + arch/sh/kernel/cpu/sh3/clock-sh7705.c | 5 + arch/sh/kerne

[PATCH v2 07/13] sh: sh4: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text, excepting ${LINUX}/arch/sh/kernel/cpu/sh4/softfloat.c which is not GPL license Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/cpu/sh4/clock-sh4-2

[PATCH v2 08/13] sh: sh4a: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/cpu/sh4a/clock-sh7343.c | 14 +- arch/sh/kernel/cpu/sh4a/clock-sh7366.c | 14 +--

[PATCH v2 04/13] sh: sh2: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/cpu/sh2/Makefile | 1 + arch/sh/kernel/cpu/sh2/clock-sh7619.c | 5 + arch/sh/kernel/cpu/

[PATCH v2 05/13] sh: sh2a: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/kernel/cpu/sh2a/clock-sh7201.c | 5 + arch/sh/kernel/cpu/sh2a/clock-sh7203.c | 5 + arch/sh/ker

[PATCH v2 02/13] sh: drivers: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. As original license mentioned, it is GPL-2.0 in SPDX. Then, MODULE_LICENSE() should be "GPL v2" instead of "GPL". See ${LINUX}/include/linux/module.h "GPL" [GNU

[PATCH v2 03/13] sh: include: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/include/asm/Kbuild | 1 + arch/sh/include/asm/addrspace.h

[PATCH v2 01/13] sh: boards: convert to SPDX identifiers

From: Kuninori Morimoto This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Reviewed-by: Simon Horman --- arch/sh/boards/board-apsh4a3a.c | 5 + arch/sh/boards/board-apsh4ad0a.c| 5

[PATCH v2 00/13] sh: convert to SPDX

Hi Yoshinori These patches v2 patches of SPDX license for sh. v1 -> v2 - add Simon's Reviewed-by for [01/13] to [12/13] - [13/13] uses "WITH GCC-exception-2.0" Kuninori Morimoto (13): sh: boards: convert to SPDX identifiers sh: drivers: convert to SPDX identifiers sh: include: conv

Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts

On 08/22/2018 10:37 PM, Wolfram Sang wrote: >> I have encountered an interrupt storm during the eMMC chip probing (and >> the chip finally didn't get detected). It turned out that U-Boot left >> the SDHI DMA interrupts enabled while the Linux driver didn't use those. >> Masking those interrupts i

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: fix #define RST_RESERVED_BITS

On 08/22/2018 10:45 PM, Wolfram Sang wrote: The DM_CM_RST register actually has bits 0-31 defaulting to 1s and bits 32-63 defaulting to 0s -- fix off-by-one in #define RST_RESERVED_BITS. Signed-off-by: Sergei Shtylyov >>> >>> Reviewed-by: Wolfram Sang >>> >>> Suggesting stabl

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: fix #define RST_RESERVED_BITS

On Wed, Aug 22, 2018 at 10:41:56PM +0300, Sergei Shtylyov wrote: > On 08/22/2018 10:38 PM, Wolfram Sang wrote: > > >> The DM_CM_RST register actually has bits 0-31 defaulting to 1s and bits > >> 32-63 defaulting to 0s -- fix off-by-one in #define RST_RESERVED_BITS. > >> > >> Signed-off-by: Sergei

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: fix #define RST_RESERVED_BITS

On 08/22/2018 10:38 PM, Wolfram Sang wrote: >> The DM_CM_RST register actually has bits 0-31 defaulting to 1s and bits >> 32-63 defaulting to 0s -- fix off-by-one in #define RST_RESERVED_BITS. >> >> Signed-off-by: Sergei Shtylyov > > Reviewed-by: Wolfram Sang > > Suggesting stable. Stable

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: fix #define RST_RESERVED_BITS

On Wed, Aug 22, 2018 at 09:28:01PM +0300, Sergei Shtylyov wrote: > The DM_CM_RST register actually has bits 0-31 defaulting to 1s and bits > 32-63 defaulting to 0s -- fix off-by-one in #define RST_RESERVED_BITS. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Wolfram Sang Suggesting stable.

Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts

On Wed, Aug 22, 2018 at 09:22:26PM +0300, Sergei Shtylyov wrote: > I have encountered an interrupt storm during the eMMC chip probing (and > the chip finally didn't get detected). It turned out that U-Boot left > the SDHI DMA interrupts enabled while the Linux driver didn't use those. > Masking th

Re: [PATCH v3 2/2] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support

Hello! On 08/13/2018 06:19 PM, Laurent Pinchart wrote: >> Define the Condor/V3HSK board dependent parts of the DU and LVDS device >> nodes. Also add the device nodes for Thine THC63LVD1024 LVDS decoder and >> Analog Devices ADV7511W HDMI transmitter... >> >> Based on the original (and large) pat

[PATCH] mmc: renesas_sdhi_internal_dmac: fix #define RST_RESERVED_BITS

The DM_CM_RST register actually has bits 0-31 defaulting to 1s and bits 32-63 defaulting to 0s -- fix off-by-one in #define RST_RESERVED_BITS. Signed-off-by: Sergei Shtylyov --- The patch is against Ulf Hansson's 'mmc.git' repo's 'fixes' branch. drivers/mmc/host/renesas_sdhi_internal_dmac.c |

[PATCH v2] mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts

I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It turned out that U-Boot left the SDHI DMA interrupts enabled while the Linux driver didn't use those. Masking those interrupts in renesas_sdhi_internal_dmac_request_dma() gets rid of bo

Re: [PATCH 2/2] arm64: dts: renesas: v3msk: add eMMC support

On 08/22/2018 02:31 PM, Simon Horman wrote: >> Add the eMMC chip support for the V3M Started Kit board. >> >> Based on the original (and large) patches by Vladimir Barinov. >> >> Signed-off-by: Vladimir Barinov >> Signed-off-by: Sergei Shtylyov > > Thanks, > > This looks fine to me but I will

Re: [PATCH/RFT] arm64: dts: renesas: r8a77965: Add OPPs table for cpu devices

On Tue, Aug 14, 2018 at 11:12:41PM +0900, Yoshihiro Kaneko wrote: > From: Dien Pham > > This patch adds OPPs table for CA57{0,1} cpu devices > > Signed-off-by: Dien Pham > Signed-off-by: Takeshi Kihara > Signed-off-by: Yoshihiro Kaneko Tested on r8a77965/Salvator-XS I see that CPUFreq is ac

Re: [LTSI-dev] [GIT PULL LTSI-4.14] Renesas SoCs and Drivers to v4.18-rc8

Hi Simon, On Fri, Aug 17, 2018 at 12:53 PM Simon Horman wrote: > please find the details of the corrected tag below: > > The following changes since commit 2ae6c0413b4768f9d8fc6f718a732f9dae014b67: > > Linux 4.14.61 (2018-08-06 16:20:52 +0200) > > are available in the git repository at: > > h

Re: [PATCH] dt-bindings: mmc: tmio_mmc: document Renesas R8A77970 bindings

On Tue, Aug 21, 2018 at 10:14:12PM +0300, Sergei Shtylyov wrote: > Document the R-Car V3M (R8A77970) SoC in the R-Car SDHI bindings -- it's > the usual R-Car gen3 compatible controller with the internal DMA engine. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Simon Horman

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist

On Sat, Aug 18, 2018 at 09:08:26PM +0300, Sergei Shtylyov wrote: > I've successfully tested eMMC on the V3H Starter Kit board. R8A77970 SoC > has a single SDHI core anyway, so can't be a subject to the known RX DMA > errata... > > Signed-off-by: Sergei Shtylyov Reviewed-by: Simon Horman

Re: [PATCH 2/2] arm64: dts: renesas: v3msk: add eMMC support

On Tue, Aug 21, 2018 at 10:50:31PM +0300, Sergei Shtylyov wrote: > Add the eMMC chip support for the V3M Started Kit board. > > Based on the original (and large) patches by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov Thanks, This looks fine to me but

Re: [PATCH /2] arm64: dts: renesas: r8a77970: add MMC support

On Tue, Aug 21, 2018 at 10:49:26PM +0300, Sergei Shtylyov wrote: > Define the generic R8A77970 part of the MMC0 (SDHI2) device node. > > Based on the original (and large) patches by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov Thanks, This looks fine

Re: [PATCH] arm64: dts: renesas: enable SDR104 on R-Car Gen3

On Tue, Aug 21, 2018 at 09:03:56PM +0200, Wolfram Sang wrote: > Successfully tested on H3 ES1.0 and ES2.0, M3-W ES1.0, and M3-N ES1.0. > Even previously stubborn cards work fine. Transfer rates were >60MB/s. > > Signed-off-by: Wolfram Sang > --- > > The problems I reported last week were simply

Re: [PATCH v2 4/7] arm64: dts: renesas: r8a77965: m3nulcb: Initial device tree

On Sun, Aug 12, 2018 at 03:31:46PM +0200, Eugeniu Rosca wrote: > Allow the bare M3-N-based ULCB board to boot. > > Signed-off-by: Eugeniu Rosca > Reviewed-by: Jacopo Mondi Thanks Eugeniu, applied for v4.20.

Re: [PATCH v2 7/7] arm64: dts: renesas: r8a77965: m3nulcb-kf: Initial device tree

On Sun, Aug 12, 2018 at 03:31:49PM +0200, Eugeniu Rosca wrote: > This is based on the existing KF device tree sources: > $ ls -1 arch/arm64/boot/dts/renesas/*-kf.dts > arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts > arch/arm64/boot/dts/ren

Re: [PATCH v2 6/7] arm64: dts: renesas: r8a77965: Add HSCIF0 device node

On Sun, Aug 12, 2018 at 03:31:48PM +0200, Eugeniu Rosca wrote: > Fix below DTC error: > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:36.1-8 Label or path hscif0 > not found > > The DTC error occurs *after* the addition of r8a77965-m3nulcb-kf.dts. > Fix it beforehand. > > Inspired from v4.12-r

Re: [PATCH v2 5/7] arm64: dts: renesas: r8a77965: Add CAN{0,1} placeholder nodes

On Fri, Aug 17, 2018 at 02:53:37PM +0100, Kieran Bingham wrote: > Hi Eugeniu, > > Thank you for the patch, > > On 12/08/18 14:31, Eugeniu Rosca wrote: > > According to R-Car Gen3 HW manual rev1.00, R-Car M3-N has two CAN > > interfaces, similar to H3, M3-W and other SoCs from the same family. > >

Re: [PATCH] arm64: dts: renesas: r8a77965: Attach the SYS-DMAC to the IPMMU

On Mon, Aug 20, 2018 at 11:17:56PM +0900, Magnus Damm wrote: > From: Magnus Damm > > For R-Car M3-N hook up SYS-DMAC0, SYS-DMAC1 and SYS-DMAC2 to > IPMMU-DS0 and IPMMU-DS1 in same way as for R-Car M3-W. > This follows the R-Car Gen3 Rev.1.00 (April 2018) datasheet. > > Signed-off-by: Magnus Damm

Re: [PATCH] arm: dts: Include R-Car Gen1 product name in DTSI files

On Mon, Aug 20, 2018 at 11:04:44PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Browsing the DTS for all the R-Car SoCs with similar part numbers > still makes my head hurt, so to improve the user friendliness of > the 32-bit ARM DTS code base include R-Car Gen1 product names for > each DTSI

Re: [PATCH] arm64: dts: renesas: salvator-common: Add GPIO keys support

Hi Laurent, thanks for your patch. On Sun, Aug 19, 2018 at 10:44:55PM +0300, Laurent Pinchart wrote: > The Salvator-X and XS boards have a 4 lines DIP switch and 3 push > buttons connected to SoC GPIOs, meant to be used as general-purpose test > keys. Add a corresponding node in DT, mapping (semi

Re: [PATCH] arm64: dts: renesas: r8a77980: add CSI2/VIN support

On Fri, Aug 17, 2018 at 02:13:55PM +0300, Sergei Shtylyov wrote: > On 08/17/2018 11:51 AM, Simon Horman wrote: > > Describe the CSI2 and VIN (and their interconnections) in the R8A77980 > device tree. > > Signed-off-by: Sergei Shtylyov > > --- > This patch is ag

Re: [PATCH v3 2/2] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support

On Mon, Aug 13, 2018 at 06:19:20PM +0300, Laurent Pinchart wrote: > Hi Sergei, > > Thank you for the patch. > > On Wednesday, 13 June 2018 23:12:40 EEST Sergei Shtylyov wrote: > > Define the Condor/V3HSK board dependent parts of the DU and LVDS device > > nodes. Also add the device nodes for Thi

Re: [PATCH v2] arm64: dts: renesas: Initial r8a774a1 SoC device tree

On Mon, Aug 13, 2018 at 01:41:48PM +0100, Biju Das wrote: > Basic support for the RZ/G2M SoC. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks Biju, applied for v4.20.

Re: [PATCH] dt-bindings: mmc: tmio_mmc: document Renesas R8A77970 bindings

On 21 August 2018 at 21:14, Sergei Shtylyov wrote: > Document the R-Car V3M (R8A77970) SoC in the R-Car SDHI bindings -- it's > the usual R-Car gen3 compatible controller with the internal DMA engine. > > Signed-off-by: Sergei Shtylyov Thanks, queued for v4.20! Kind regards Uffe > > --- > This

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist

On 20 August 2018 at 21:44, Sergei Shtylyov wrote: > On 08/20/2018 07:42 PM, Wolfram Sang wrote: > >>> I've successfully tested eMMC on the V3H Starter Kit board. R8A77970 SoC >>> has a single SDHI core anyway, so can't be a subject to the known RX DMA >>> errata... >>> >>> Signed-off-by: Sergei

Re: [PATCH 0/2] Fix some typos in Renesas R-Car gen3 SDHI driver

On 17 August 2018 at 22:16, Sergei Shtylyov wrote: > Hello! > > Here's a set of 2 patches against the 'next' branch of Ulf Hannsson's > 'mmc.git' repo. > They fix some typos I noticed... > > [1/2] mmc: renesas_sdhi_internal_dmac: fix typo in DM_CM_DTRAN_MODE.BUS_WIDTH > field name > [2/2] mmc: r

Re: [PATCH 0/2] Add SDHI support to r8a774a1

On 14 August 2018 at 14:34, Fabrizio Castro wrote: > Dear All, > > this series aims at documenting SDHI support for RZ/G2M (a.k.a. R8A774A1). > > Cheers, > Fab > > Fabrizio Castro (2): > mmc: renesas_sdhi_internal_dmac: Whitelist r8a774a1 > mmc: renesas_sdhi: Add r8a774a1 support > > Document

Re: [PATCH v2 0/7] mmc: tmio: refactor TMIO core a bit and add UniPhier SD/eMMC controller support

On 21 August 2018 at 04:57, Masahiro Yamada wrote: > Hi Wolfram, > > > 2018-08-21 4:07 GMT+09:00 Wolfram Sang : >> >> So, today I did test these patches successfully on a Gen3 board (M3-N) >> and reviewed half of the patches. I will continue tomorrow with >> reviewing and testing more boards. >> >

RE: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling

Hi Lorenzo, On 21 August 2018 16:32, Lorenzo Pieralisi wrote: > On Tue, Aug 21, 2018 at 08:58:38AM +, Phil Edworthy wrote: > > On 20 August 2018 15:48 Lorenzo Pieralisi wrote: > > > On Mon, Aug 20, 2018 at 01:44:48PM +, Phil Edworthy wrote: > > > > > > [...] > > > > > > > However, both bef