Re: [PATCH 2/4] dt-bindings: arm: Document Renesas V3MSK and Wheat board part numbers

On 2/28/2018 9:49 AM, Simon Horman wrote: [...] On Tue, Feb 27, 2018 at 9:17 AM, Simon Horman wrote: On Mon, Feb 26, 2018 at 07:03:43PM +0100, Geert Uytterhoeven wrote: ... - - Wheat + - Wheat (RTP0RC7792ASKB0010JE) compatible = "renesas,wheat",

Re: [PATCH 3/4] dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-X board

On Tue, Feb 27, 2018 at 10:25:42PM +0100, Geert Uytterhoeven wrote: > Hi Simon, > > On Tue, Feb 27, 2018 at 9:22 AM, Simon Horman wrote: > > On Mon, Feb 26, 2018 at 07:03:44PM +0100, Geert Uytterhoeven wrote: > >> The Renesas Salvator-X development board can be equipped with

Re: [PATCH 4/4] dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-XS board

On Tue, Feb 27, 2018 at 08:41:13AM +, Chris Paterson wrote: > Hello Simon, > > > From: devicetree-ow...@vger.kernel.org [mailto:devicetree- > > ow...@vger.kernel.org] On Behalf Of Simon Horman > > Sent: 27 February 2018 08:25 > > > > On Mon, Feb 26, 2018 at 07:03:45PM +0100, Geert

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

On Tuesday 27 February 2018 06:26 PM, Ville Syrjala wrote: From: Ville Syrjälä Currently we have a mix of static and dynamic information stored in the display info structure. That makes it rather difficult to repopulate the dynamic parts when a new EDID

Re: [PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

On 2018/2/27 23:05, Phil Edworthy wrote: Hi Shawn, On 27 February 2018 14:42, Shawn Lin wrote: On 2018/2/27 22:31, Phil Edworthy wrote: Hi Shawn, On 27 February 2018 14:28, Shawn Lin wrote: 在 2018/2/27 21:55, Phil Edworthy 写道: Since the controller does not support the end-of-busy IRQ,

Re: [PATCH 3/4] dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-X board

Hi Simon, On Tue, Feb 27, 2018 at 9:22 AM, Simon Horman wrote: > On Mon, Feb 26, 2018 at 07:03:44PM +0100, Geert Uytterhoeven wrote: >> The Renesas Salvator-X development board can be equipped with an R-Car >> H3, M3-W, or M3-N SiP, which are pin-compatible. >> >> Document

Re: [PATCH 2/4] dt-bindings: arm: Document Renesas V3MSK and Wheat board part numbers

Hi Simon, On Tue, Feb 27, 2018 at 9:17 AM, Simon Horman wrote: > On Mon, Feb 26, 2018 at 07:03:43PM +0100, Geert Uytterhoeven wrote: >> The DT binding documentation for the Renesas V3MSK and Wheat boards >> lacked board part numbers. >> >> Signed-off-by: Geert Uytterhoeven

Re: [PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure

> AFAICS this only applies if the watchdog is already running at boot, > which is not currently supported to start with. Hmm, probably this is a good occasion to add support for it. I'll check. Thanks! signature.asc Description: PGP signature

Re: [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

On 02/27/2018 11:06 PM, Sergei Shtylyov wrote: > Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's > 'renesas-devel-20180227-v4.16-rc3' tag. We're adding the R8A77970 FCPVD/VSPD/ > DU/LVDS device nodes and then describing the HDMI encoder connected to the > L

[PATCH v2 5/5] arm64: dts: renesas: v3msk: add DU/LVDS/HDMI support

Define the V3M Starter Kit board dependent part of the DU and LVDS device nodes. Also add the device nodes for the Analog Devices ADV7511W HDMI transmitter -- it's actually connected to the LVDS output via an LVDS decoder (deliberately omitted here since there's no driver yet anyway). Based on

[PATCH v2 4/5] arm64: dts: renesas: r8a77970: add LVDS support

Define the generic R8A77970 part of the LVDS device node. Signed-off-by: Sergei Shtylyov --- Changes in version 2: - resolved rejects and updated atop of the DU support patch; - changed the LVDS node's label/name; - renamed the input/output endpoints' labels;

[PATCH v2 3/5] arm64: dts: renesas: r8a77970: add DU support

Define the generic R8A77970 part of the DU device node. Based on the original (and large) patch by Daisuke Matsushita . Signed-off-by: Vladimir Barinov Signed-off-by: Sergei Shtylyov

[PATCH v2 2/5] arm64: dts: renesas: r8a77970: add VSPD support

Describe VSPD0 in the R8A77970 device tree; it will be used by DU in the next patch... Based on the original (and large) patch by Daisuke Matsushita . Signed-off-by: Vladimir Barinov Signed-off-by: Sergei Shtylyov

[PATCH v2 1/5] arm64: dts: renesas: r8a77970: add FCPVD support

Describe FCPVD0 in the R8A77970 device tree; it will be used by VSPD0 in the next patch... Based on the original (and large) patch by Daisuke Matsushita . Signed-off-by: Vladimir Barinov Signed-off-by: Sergei Shtylyov

[PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

Hello! Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20180227-v4.16-rc3' tag. We're adding the R8A77970 FCPVD/VSPD/ DU/LVDS device nodes and then describing the HDMI encoder connected to the LVDS output (we're omitting the LVDS decoder for now

Re: [PATCH net-next] sh_eth: uninline TSU register accessors

From: Sergei Shtylyov Date: Tue, 27 Feb 2018 14:58:16 +0300 > We have uninlined the sh_eth_{read|write}() functions introduced in the > commit 4a55530f38e ("net: sh_eth: modify the definitions of register"). > Now remove *inline* from sh_eth_tsu_{read|write}()

Re: [PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure

On Tue, Feb 27, 2018 at 05:22:56PM +0100, Wolfram Sang wrote: > > > the core gets it wrong. Just add a note to the probe function where cks is > > initialized that RWTCSRA_TME must not be set, and that RWTCSRA_TME must be > > cleared before changing the divider. > > But we would still need to

Re: [PATCH net-next] sh_eth: uninline TSU register accessors

On 02/27/2018 02:58 PM, Sergei Shtylyov wrote: > We have uninlined the sh_eth_{read|write}() functions introduced in the > commit 4a55530f38e ("net: sh_eth: modify the definitions of register"). > Now remove *inline* from sh_eth_tsu_{read|write}() as well and move > these functions from the

Re: [PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure

> the core gets it wrong. Just add a note to the probe function where cks is > initialized that RWTCSRA_TME must not be set, and that RWTCSRA_TME must be > cleared before changing the divider. But we would still need to disable TME sperately if the caclulated cks is not the same value as the

RE: [PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

Hi Shawn, On 27 February 2018 14:42, Shawn Lin wrote: > On 2018/2/27 22:31, Phil Edworthy wrote: > > Hi Shawn, > > > > On 27 February 2018 14:28, Shawn Lin wrote: > >> 在 2018/2/27 21:55, Phil Edworthy 写道: > >>> Since the controller does not support the end-of-busy IRQ, don't use it. > >>>

[PATCH v2 2/3] media: i2c: adv748x: Add missing CBUS page

From: Kieran Bingham The ADV748x has 12 pages mapped onto I2C addresses. In the existing implementation only 11 are mapped correctly in the page enumerations, which causes an off-by-one fault on pages above the infoframe definition due to a missing 'CBUS' page.

[PATCH v2 0/3] media: i2c: adv748x: Fix CBUS page issue

The ADV748x has 12 pages mapped on to I2C addresses. The existing implementation only has 11 of these in the map enumeration, and this can cause an off-by-one error when programming the map addresses. This short series simplifies the regmap configuration tables, and adds the missing CBUS page to

[PATCH v2 3/3] media: i2c: adv748x: Add support for i2c_new_secondary_device

From: Kieran Bingham The ADV748x has twelve 256-byte maps that can be accessed via the main I2C ports. Each map has it own I2C address and acts as a standard slave device on the I2C bus. Allow a device tree node to override the default addresses so that address

Re: [PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure

On 02/27/2018 05:00 AM, Wolfram Sang wrote: - rwdt_write(priv, 0, RWTCSRB); - rwdt_write(priv, priv->cks, RWTCSRA); Isn't this done implicitly with the above already ? After all, priv->cks won't have RWTCSRA_TME set. Yes. The request came from a group doing some (safety?) audit

Re: [PATCH] dmaengine: rcar-dmac: fix max_chunk_size for R-Car Gen3

On Wed, Feb 14, 2018 at 06:40:12PM +0900, Yoshihiro Shimoda wrote: > According to R-Car Gen3 Rev.0.80 manual, the DMATCR can be set to > 16,777,215 as maximum. So, this patch fixes the max_chunk_size for > safety on all of SoCs. Otherwise, a system may hang if the DMATCR > is set to 0 on R-Car

Re: [PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

On 2018/2/27 22:31, Phil Edworthy wrote: Hi Shawn, On 27 February 2018 14:28, Shawn Lin wrote: 在 2018/2/27 21:55, Phil Edworthy 写道: Since the controller does not support the end-of-busy IRQ, don't use it. Otherwise, on older SD cards you will get lots of these messages: "mmc0: Got data

Re: [PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

在 2018/2/27 21:55, Phil Edworthy 写道: Since the controller does not support the end-of-busy IRQ, don't use it. Otherwise, on older SD cards you will get lots of these messages: "mmc0: Got data interrupt 0x0002 even though no data operation was in progress" I'm afraid you have to explain

RE: [PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

Hi Adrian, On 27 February 2018 14:08, Adrian Hunter wrote: > On 27/02/18 15:55, Phil Edworthy wrote: > > Since the controller does not support the end-of-busy IRQ, don't use it. > > Otherwise, on older SD cards you will get lots of these messages: > > "mmc0: Got data interrupt 0x0002 even

Re: [PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

On 27/02/18 15:55, Phil Edworthy wrote: > Since the controller does not support the end-of-busy IRQ, don't use it. > Otherwise, on older SD cards you will get lots of these messages: > "mmc0: Got data interrupt 0x0002 even though no data operation was in > progress" SDHCI_QUIRK2_STOP_WITH_TC

[PATCH] mmc: sdhci-of-arasan: Add quirk to avoid erroneous msg

Since the controller does not support the end-of-busy IRQ, don't use it. Otherwise, on older SD cards you will get lots of these messages: "mmc0: Got data interrupt 0x0002 even though no data operation was in progress" This has been reported on Xilinx devices that also use the Arasan IP. See

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

On Tue, 2018-02-27 at 14:56 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the dynamic parts when a new EDID

RE: [PATCH 0/2] arm: Support for Renesas RZ/N1D (R9A06G032)

Hi Simon, On 26 February 2018, Michel Pollet wrote: > > This series adds the plain basic support for booting a bare > kernel on the RZ/N1D-DB Board. It's been trimmed to the strict > minimum as a 'base', further patches that will add the > rest of the support, pinctrl, clock architecture and

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

On Tue, Feb 27, 2018 at 02:56:53PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the dynamic parts when a new

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

> Perhaps someone need to explain in more detail what the HW controller > needs to manage tuning for HS400? I don't like that we may end up > getting it magically to work, then it's we better understand the > details and if the current sequence provided by the mmc core can't > fulfill the need

Re: [PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure

> > - rwdt_write(priv, 0, RWTCSRB); > > - rwdt_write(priv, priv->cks, RWTCSRA); > > Isn't this done implicitly with the above already ? > After all, priv->cks won't have RWTCSRA_TME set. Yes. The request came from a group doing some (safety?) audit who didn't like the implicit handling which

[RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

From: Ville Syrjälä Currently we have a mix of static and dynamic information stored in the display info structure. That makes it rather difficult to repopulate the dynamic parts when a new EDID appears. Let's make life easier by splitting the structure up into

[RFC][PATCH 03/11] drm/shmobile: Don't fill display_info.{width,height}_mm at init time

From: Ville Syrjälä shmobile is already populating display_info.width_mm and display_info.height_mm from the .get_modes() hook which is what we want. No need to populate it from the init path as well. Cc: Keith Packard Cc: Daniel Vetter

[RFC][PATCH 00/11] drm: Try to make display info less nuts

From: Ville Syrjälä Currently the display info is cleared/populated in a very ad-hoc manner. I'd like to make it more robust by making sure it gets cleared by the core forcing drivers to repopulate in .fill_modes(). The bus_formats stuff looks very much ad-hoc all

Re: [PATCH] dt-bindings: i2c: sh_mobile: Document R-Car M3-N support

On Mon, Feb 26, 2018 at 04:26:43PM +0100, Geert Uytterhoeven wrote: > Document support for the IIC Bus Interface for DVFS (IIC for DVFS) in > the Renesas M3-N (r8a77965) SoC. > > No driver update is needed. > > Signed-off-by: Geert Uytterhoeven Applied to for-next,

[PATCH net-next] sh_eth: uninline TSU register accessors

We have uninlined the sh_eth_{read|write}() functions introduced in the commit 4a55530f38e ("net: sh_eth: modify the definitions of register"). Now remove *inline* from sh_eth_tsu_{read|write}() as well and move these functions from the header to the driver itself. This saves 684 more bytes of

Re: [PATCH 2/4] dt-bindings: arm: Document Renesas V3MSK and Wheat board part numbers

Hello! On 02/27/2018 11:17 AM, Simon Horman wrote: >> The DT binding documentation for the Renesas V3MSK and Wheat boards >> lacked board part numbers. >> >> Signed-off-by: Geert Uytterhoeven >> --- >> Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++-- >> 1

[PATCH v2 00/10] R-Car M3-N: Enable EtherAVB device node

Hi Simon, Geert, in this second iteration I have dropped iommu dependencies for EtherAVB and have changed "phy-mode" for all mainlines Gen-3 boards, this time including ULCB, Draak, Eagle and V3MSK. The series add phy-mode as a board property to the following board files: -

[PATCH v2 01/10] arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode

As the PHY interface installed on the Salvator-X[S] board, provides TX channel delay, make the "phy-mode" property a board-specific one, meant to override the one specified in the SoC DTSI. Follow up patches will reset the r8a7795/96/965 SoC DTSI to use "rgmii" mode and let the board files

[PATCH v2 02/10] arm64: dts: renesas: ulcb: Override EtherAVB phy-mode

As the PHY interface installed on the ULCB board provides TX channel delay, make the "phy-mode" property a board-specific one, meant to override the one specified in the SoC DTSI. Follow up patches will reset the r8a7795/96 SoC DTSI to use "rgmii" mode\ and let the board files override that.

[PATCH v2 04/10] arm64: dts: renesas: eagle: Override EtherAVB phy-mode

As the PHY interface installed on the Eagle board provides TX and RX channels delays, make the "phy-mode" property a board-specific one, meant to override the one specified in the SoC DTSI. Follow up patches will reset the r8a77970 SoC DTSI to use "rgmii" mode and let the board file override

[PATCH v2 03/10] arm64: dts: renesas: draak: Override EtherAVB phy-mode

As the PHY interface installed on the Draak board, provides TX channel delay, make the "phy-mode" property a board-specific one, meant to override the one specified in the SoC DTSI. Follow up patches will reset the r8a77995 SoC DTSI to use "rgmii" mode and let the board file override that.

[PATCH v2 05/10] arm64: dts: renesas: v3msk: Override EtherAVB phy-mode

As the PHY interface installed on the V3MSK board provides TX and RX channels delays, make the "phy-mode" property a board-specific one, meant to override the one specified in the SoC DTSI. Follow up patches will reset the r8a77970 SoC DTSI to use "rgmii" mode and let the board file override

Re: [PATCH v4 11/16] ARM: dts: r8a7791: Convert to new LVDS DT bindings

Hi Sergei, On Friday, 23 February 2018 11:51:59 EET Sergei Shtylyov wrote: > On 2/21/2018 2:10 AM, Laurent Pinchart wrote: > > The internal LVDS encoder now has DT bindings separate from the DU. Port > > the device tree over to the new model. > > > > Signed-off-by: Laurent Pinchart > >

[PATCH v2 06/10] arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"

Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven ---

[PATCH v2 09/10] arm64: dts: renesas: r8a77970: Set EtherAVB phy mode to "rgmii"

Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi --- arch/arm64/boot/dts/renesas/r8a77970.dtsi | 2 +- 1 file changed, 1

[PATCH v2 07/10] arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"

Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven ---

[PATCH v2 10/10] arm64: dts: renesas: r8a77965: Add EtherAVB device node

Populate the ethernet@e680 device node to enable Ethernet interface for R-Car M3-N (R8A77965) SoC. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven --- v1 -> v2: - Replace ALWAYS_ON power area identifier with numeric constant

[PATCH v2 08/10] arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"

Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven ---

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

On 27 February 2018 at 10:07, Wolfram Sang wrote: > >> Is this ready to be queued up for next? It looks good to me. > > Ulf, out of your head, do you have an idea why preparing HS400 during > set_ios works but populating host->ops->prepare_hs400_tuning() does not > (according

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

Hi Geert, Thank you for the patch. On Monday, 26 February 2018 20:09:10 EET Geert Uytterhoeven wrote: > VIDEO_RENESAS_VSP1 depends on ARCH_RENESAS && OF. > As ARCH_RENESAS implies OF, the latter can be dropped. > > Signed-off-by: Geert Uytterhoeven Acked-by: Laurent

Re: [PATCH 02/15] v4l: vsp1: Remove outdated comment

Hi Sergei, On Tuesday, 27 February 2018 10:22:25 EET Sergei Shtylyov wrote: > On 2/27/2018 12:45 AM, Laurent Pinchart wrote: > > The entities in the pipeline are all started when the LIF is setup. > > Remove the outdated comment that state otherwise. > > States? You're right, will fix in v2. >

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

> Is this ready to be queued up for next? It looks good to me. Ulf, out of your head, do you have an idea why preparing HS400 during set_ios works but populating host->ops->prepare_hs400_tuning() does not (according to Simon's tests)? signature.asc Description: PGP signature

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

On Mon, Feb 26, 2018 at 07:09:10PM +0100, Geert Uytterhoeven wrote: > VIDEO_RENESAS_VSP1 depends on ARCH_RENESAS && OF. > As ARCH_RENESAS implies OF, the latter can be dropped. > > Signed-off-by: Geert Uytterhoeven My reasoning is that ARCH_RENESAS depends on

RE: [PATCH 4/4] dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-XS board

Hello Simon, > From: devicetree-ow...@vger.kernel.org [mailto:devicetree- > ow...@vger.kernel.org] On Behalf Of Simon Horman > Sent: 27 February 2018 08:25 > > On Mon, Feb 26, 2018 at 07:03:45PM +0100, Geert Uytterhoeven wrote: > > The Renesas Salvator-XS development board can be equipped with

Re: [PATCH 0/8] R-Car M3-N: Enable EtherAVB device node

On Tue, Feb 27, 2018 at 09:28:38AM +0100, jacopo mondi wrote: > Hi Geert, > > On Mon, Feb 26, 2018 at 07:28:47PM +0100, Geert Uytterhoeven wrote: > > Hi Jacopo, > > > > On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi > > wrote: > > > as discussed with you Sergei and

Re: [PATCH 0/8] R-Car M3-N: Enable EtherAVB device node

Hi Geert, On Mon, Feb 26, 2018 at 07:28:47PM +0100, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi > wrote: > > as discussed with you Sergei and Geert, in order to enable EtherAVB for > > R8A77965 we first wanted to make the

Re: [PATCH] DT: net: renesas,ravb: document R8A77980 bindings

On Mon, Feb 26, 2018 at 03:10:51PM -0500, David Miller wrote: > From: Simon Horman > Date: Mon, 26 Feb 2018 11:58:24 +0100 > > > On Sat, Feb 24, 2018 at 09:53:17PM -0500, David Miller wrote: > >> From: Sergei Shtylyov > >> Date: Sat, 24

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

On Tue, Feb 27, 2018 at 08:53:17AM +0100, Ulf Hansson wrote: > On 13 February 2018 at 13:33, Simon Horman wrote: > > Hi, > > > > this patch-set provides SDHI driver support for eMMC HS400. > > > > Based on mmc/next > > > > Dependencies for applying these patches: none

Re: [PATCH 4/4] dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-XS board

On Mon, Feb 26, 2018 at 07:03:45PM +0100, Geert Uytterhoeven wrote: > The Renesas Salvator-XS development board can be equipped with an R-Car > H3, M3-W, or M3-N SiP, which are pin-compatible. > > Document board part number and compatible values for the version with > R-Car M3-N. > >

Re: [PATCH 3/4] dt-bindings: arm: Document Renesas R-Car M3-N-based Salvator-X board

On Mon, Feb 26, 2018 at 07:03:44PM +0100, Geert Uytterhoeven wrote: > The Renesas Salvator-X development board can be equipped with an R-Car > H3, M3-W, or M3-N SiP, which are pin-compatible. > > Document board part number and compatible values for the version with > R-Car M3-N. > > The board

Re: [PATCH 02/15] v4l: vsp1: Remove outdated comment

Hello! On 2/27/2018 12:45 AM, Laurent Pinchart wrote: The entities in the pipeline are all started when the LIF is setup. Remove the outdated comment that state otherwise. States? Signed-off-by: Laurent Pinchart [...] MBR, Sergei

[PATCH 0/2] usb: add USB2.0/3.0 peripheral bindings for r8a77965

This patch set is based on the latest Felipe's usb.git / testing/next branch (commit id = 892b3e4a3df3f8fa18053aba65acd5a3dee05325). Yoshihiro Shimoda (2): usb: renesas_usbhs: add binding for r8a77965 usb: gadget: udc: renesas_usb3: add binging for r8a77965

[PATCH 1/2] usb: renesas_usbhs: add binding for r8a77965

This patch adds binding for r8a77965 (R-Car M3-N). Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt

[PATCH 2/2] usb: gadget: udc: renesas_usb3: add binging for r8a77965

This patch adds binding for r8a77965 (R-Car M3-N). Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/usb/renesas_usb3.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt

[PATCH] usb: host: xhci-rcar: add support for r8a77965

This patch adds support for r8a77965 (R-Car M3-N). Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + drivers/usb/host/xhci-rcar.c | 4 2 files changed, 5 insertions(+) diff --git

Re: [PATCH 2/4] dt-bindings: arm: Document Renesas V3MSK and Wheat board part numbers

On Mon, Feb 26, 2018 at 07:03:43PM +0100, Geert Uytterhoeven wrote: > The DT binding documentation for the Renesas V3MSK and Wheat boards > lacked board part numbers. > > Signed-off-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/arm/shmobile.txt | 4

Re: [PATCH 1/4] dt-bindings: arm: Document SoC compatible value for Armadillo-800 EVA

On Mon, Feb 26, 2018 at 07:03:42PM +0100, Geert Uytterhoeven wrote: > The compatible property of the root node in a DTS for Atmark Techno > Armadillo-800 EVA should include the compatible value for the R-Mobile > A1 SoC, too. > > Fixes: d2c2a0776899ba2d ("ARM: shmobile: Add platform device tree

[PATCH] usb: host: xhci-rcar: add support for r8a77965

This patch adds support for r8a77965 (R-Car M3-N). Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + drivers/usb/host/xhci-rcar.c | 4 2 files changed, 5 insertions(+) diff --git

[PATCH 1/2] pinctrl: sh-pfc: r8a77965: Add USB2.0 host pins, groups and functions

From: Takeshi Kihara This patch adds USB{0,1} (USB2.0 host) pins, groups and functions to the R8A77965 SoC. Signed-off-by: Takeshi Kihara Signed-off-by: Yoshihiro Shimoda ---

[PATCH 0/2] pinctrl: sh-pfc: r8a77965: Add USB[23] host pins, groups and functions

This patch is based on the renesas-drivers.git / sh-pfc-for-v4.17 branch (commit id = fbd452aeb49e552e7278c25c63198caa918deb04) Takeshi Kihara (2): pinctrl: sh-pfc: r8a77965: Add USB2.0 host pins, groups and functions pinctrl: sh-pfc: r8a77965: Add USB3.0 host pins, groups and functions

[PATCH 2/2] pinctrl: sh-pfc: r8a77965: Add USB3.0 host pins, groups and functions

From: Takeshi Kihara This patch adds USB30 (USB3.0 host) pin, group and function to the R8A77965 SoC. Signed-off-by: Takeshi Kihara Signed-off-by: Yoshihiro Shimoda ---

Re: [PATCH 0/2] arm64: dts: r8a77965: salvator-x(s): Enable s2ram and PMIC

On Mon, Feb 26, 2018 at 04:42:21PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch populates the placeholders in the R-Car M3-N DTS file for the > IIC Bus Interface for DVFS (IIC for DVFS) and Interrupt Controller for > External Devices (INTC-EX) device nodes. > > After