Re: [PATCH 00/22] R-Car Gen3 HDMI output support

Hi Laurent, On 01-12-2016 23:43, Laurent Pinchart wrote: > Hello, > > This patch series implements support for the HDMI output on Renesas R-Car Gen3 > SoCs, and more specifically on the R-Car H3. > > R-Car Gen3 SoCs include one or multiple Synopsys DWC HDMI TX controllers. The > series thus

Re: [PATCH v2 3/3 pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar

On Fri, Dec 2, 2016 at 11:37 AM, Simon Horman wrote: > Add fallback compatibility string for the R-Car Gen 3 family. This is in > keeping with the both the existing fallback compatibility string for the > R-Car Gen 2 family and the fallback scheme being adopted

Re: [PATCH v2 1/3 pci/next] PCI: rcar-gen2: Use gen2 fallback compatibility last

On Fri, Dec 2, 2016 at 11:36 AM, Simon Horman wrote: > Fallback compatibility strings should be used only if more specific ones > are matched and the order of compatibility strings in the corresponding > struct of_device_id should implement this. > > This does not have

Re: [PATCH 06/12] usb: dwc3: omap: Replace the extcon API

Hi Felipe, 2016-12-02 18:03 GMT+09:00 Felipe Balbi : > > Hi, > > Chanwoo Choi writes: >> Hi Felipe, >> >> On 2016년 11월 30일 19:36, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Chanwoo Choi writes: This patch uses the

Re: [PATCH v2] sh_eth: remove unchecked interrupts

Hi Chris, On Thu, Dec 1, 2016 at 7:53 PM, Chris Brandt wrote: > On 12/1/2016, Sergei Shtylyov wrote: >> >> On 12/01/2016 05:42 PM, Geert Uytterhoeven wrote: >> >> >> --- a/drivers/net/ethernet/renesas/sh_eth.c >> >> +++ b/drivers/net/ethernet/renesas/sh_eth.c >> >> @@

Re: [PATCH 12/22] drm: bridge: dw-hdmi: Abstract the platform PHY configuration

Hi Jose, On Friday 02 Dec 2016 11:15:19 Jose Abreu wrote: > On 01-12-2016 23:43, Laurent Pinchart wrote: > > From: Kieran Bingham > > > > Platforms implement the dw-hdmi with a separate PHY entity. It is > > configured over it's own I2C bus. To allow for

Re: [PATCH 12/22] drm: bridge: dw-hdmi: Abstract the platform PHY configuration

Hi Laurent, On 01-12-2016 23:43, Laurent Pinchart wrote: > From: Kieran Bingham > > Platforms implement the dw-hdmi with a separate PHY entity. It is > configured over it's own I2C bus. To allow for different PHY's to be > configured from the dw-hdmi

Re: R-Car gen3 PLL0/2/4 frequencies incorrect?

Hi Sergei, On Sun, Oct 30, 2016 at 7:36 PM, Sergei Shtylyov wrote: > drivers/clk/renesas/rcar-gen3-cpg.c seems to forget that the PLL0/2/4 all > have a fixed divisor (2) while it multiplies PLLxCR.STC with 2 for the > 'mult' variable (see the manual). All the

Re: [PATCH 0/4] ARM, arm64: dts: Use usb-phy fallback bindings

On Thu, Dec 01, 2016 at 03:47:57PM +0100, Geert Uytterhoeven wrote: > On Thu, Dec 1, 2016 at 3:25 PM, Simon Horman > wrote: > > this short series makes use of fallback bindings for Renesas R-Car PHY > > drivers in the DT of SoCs which already use those drivers. > > >

Re: [PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote: > From: Kieran Bingham > > The current code hard codes the call of hdmi_phy_configure() to be 8bpp > and provides extraneous error checking to verify that this hardcoded > value is correct.

[PATCH v3 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings

In the case of Renesas R-Car hardware we know that there are generations of SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant

Re: [PATCH 06/12] usb: dwc3: omap: Replace the extcon API

Hi, Chanwoo Choi writes: > Hi Felipe, > > On 2016년 11월 30일 19:36, Felipe Balbi wrote: >> >> Hi, >> >> Chanwoo Choi writes: >>> This patch uses the resource-managed extcon API for >>> extcon_register_notifier() >>> and replaces the deprecated

Re: [patch] net: renesas: ravb: unintialized return value

On Thu, Dec 01, 2016 at 11:57:44PM +0300, Dan Carpenter wrote: > We want to set the other "err" variable here so that we can return it > later. My version of GCC misses this issue but I caught it with a > static checker. > Fixes: 9f70eb339f52 ("net: ethernet: renesas: ravb: fix fixed-link phydev

[PATCH v2 3/3 pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar

Add fallback compatibility string for the R-Car Gen 3 family. This is in keeping with the both the existing fallback compatibility string for the R-Car Gen 2 family and the fallback scheme being adopted wherever appropriate for drivers for Renesas SoCs. Signed-off-by: Simon Horman

[PATCH v2 0/3 pci/next] PCI: rcar, rcar-gen2: Bindings cleanups

Hi, this short series makes some bindings cleanups to the Renesas PCI drivers. Simon Horman (3): PCI: rcar-gen2: Use gen2 fallback compatibility last PCI: rcar: Use gen2 fallback compatibility last PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar

[PATCH v2 2/3 pci/next] PCI: rcar: Use gen2 fallback compatibility last

Fallback compatibility strings should be used only if more specific ones are matched and the order of compatibility strings in the corresponding struct of_device_id should implement this. This does not have a run-time effect as current all relevant compatibility strings result in the same

[PATCH v2 1/3 pci/next] PCI: rcar-gen2: Use gen2 fallback compatibility last

Fallback compatibility strings should be used only if more specific ones are matched and the order of compatibility strings in the corresponding struct of_device_id should implement this. This does not have a run-time effect as current all relevant compatibility strings result in the same

Re: [PATCH pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar

Hi Simon, On Thu, Dec 1, 2016 at 5:28 PM, Simon Horman wrote: > Add fallback compatibility string for the R-Car Gen 3 family. This is in > keeping with the both the existing fallback compatibility string for the > R-Car Gen 2 family and the fallback scheme being

Re: [PATCH v3 01/13] drm: Don't include in

vmwgfx part: Reviewed-by: Sinclair Yeh On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote: > used to define most of the in-kernel KMS API. It has > now been split into separate files for each object type, but still > includes most other KMS headers to avoid

Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hi Russell, On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: > On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote: > > From: Kieran Bingham > > > > The dw-hdmi driver declares a dev_type to distinguish platform specific > >

[RFC 1/3] gpio-rz: Port to v3.18

Fix invalid return value in gpio remove function Signed-off-by: Jacopo Mondi --- drivers/gpio/gpio-rz.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-rz.c b/drivers/gpio/gpio-rz.c index a933dab..cb8f785 100644 ---

Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hi Russell, On Friday 02 Dec 2016 16:08:17 Russell King - ARM Linux wrote: > On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote: > > DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that. > > > > Do you know why this function needs to write to the HDMI_FC_INVIDCONF > >

Re: [PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

On Fri, Dec 02, 2016 at 05:51:18PM +0200, Laurent Pinchart wrote: > Hi Russell, > > On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote: > > On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote: > > > From: Kieran Bingham > > > > >

RE: [RFC 1/3] gpio-rz: Port to v3.18

On 12/2/2016, Jacopo Mondi wrote: > Fix invalid return value in gpio remove function > > Signed-off-by: Jacopo Mondi > --- > drivers/gpio/gpio-rz.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpio-rz.c b/drivers/gpio/gpio-rz.c

[RFC 2/3] dts: arm: genmai: Add MAXDESREF4x spidev

Add device node for the MAX11100 evaluation board connected to Genmai's CN2. The evaluation kit is connected to 4 GPIO lines configured ad bitbanged SPI master interface Signed-off-by: Jacopo Mondi --- arch/arm/boot/dts/r7s72100-genmai.dts | 22 ++ 1 file

[RFC 3/3] spidev: Add back "linux,spidev" as compatible

spidev is not meant to be configured directly from DTS anymore. Since we're prototyping, add the "linux,spidev" compatibility string back Signed-off-by: Jacopo Mondi --- drivers/spi/spidev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spidev.c

Re: [PATCH v2 2/3 pci/next] PCI: rcar: Use gen2 fallback compatibility last

On Fri, Dec 2, 2016 at 11:36 AM, Simon Horman wrote: > Fallback compatibility strings should be used only if more specific ones > are matched and the order of compatibility strings in the corresponding > struct of_device_id should implement this. > > This does not have

Re: [PATCH v4 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings

On Fri, Dec 2, 2016 at 3:25 PM, Simon Horman wrote: > In the case of Renesas R-Car hardware we know that there are generations of > SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the > relationship between IP blocks might be. For example, I believe

Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote: > From: Kieran Bingham > > The dw-hdmi driver declares a dev_type to distinguish platform specific > changes. Replace this with a quirk field, so that the platform can > specify the

[PATCH v4 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings

In the case of Renesas R-Car hardware we know that there are generations of SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant

Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote: > DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that. > > Do you know why this function needs to write to the HDMI_FC_INVIDCONF > register four times in the normal case, and once only for IMX6DL ? (I don't have much

Re: [RFC 1/3] gpio-rz: Port to v3.18

Hi Chris, On 02/12/2016 17:23, Chris Brandt wrote: On 12/2/2016, Jacopo Mondi wrote: Fix invalid return value in gpio remove function Signed-off-by: Jacopo Mondi --- drivers/gpio/gpio-rz.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

RE: [RFC 1/3] gpio-rz: Port to v3.18

Hi Jacopo, On 12/2/2016, Jacopo Mondi wrote: > > What tree/branch is this based off? > > > > Quoting the cover letter: > The series is based on branch "genmai-gpio-and-pfc" of Geert's tree at > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git > and target Linux v3.18 > >

[RFC 0/3] Enable and test MAXREFDES4# on Genmai board

Hello Magnus and Geert, list, this patch series enable the creation of a spidev device though which interface to a MAXREFDES4# MAX11100-ADC evaluation kit connected to Genmai CON2 expansion header. The series is not intended for inclusion but will probably serve as base for future integration

[PATCH v4 5/4] thermal: rcar_gen3_thermal: restrict to 64BIT

COMPILE_TEST triggers problems on 32 bit machines, so limit this driver to 64BIT for now. This is no loss because the hardware is only available on 64 bit SoCs anyhow. After we obtained more data from the hardware engineers, we will refactor the code to be usable with COMPILE_TEST. Signed-off-by:

Re: [PATCH pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar

Hi Simon, [auto build test ERROR on pci/next] url: https://github.com/0day-ci/linux/commits/Simon-Horman/PCI-rcar-Add-gen3-fallback-compatibility-string-for-pcie-rcar/20161203-030440 base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next config: arm64-allmodconfig

Re: [PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

Hi Russell, On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote: > On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote: > > From: Kieran Bingham > > > > The current code hard codes the call of hdmi_phy_configure() to be 8bpp > >

Re: [PATCH v3] sh_eth: remove unchecked interrupts for RZ/A1

From: Chris Brandt Date: Thu, 1 Dec 2016 13:32:14 -0500 > When streaming a lot of data and the RZ/A1 can't keep up, some status bits > will get set that are not being checked or cleared which cause the > following messages and the Ethernet driver to stop working. This

Re: [patch] net: renesas: ravb: unintialized return value

From: Dan Carpenter Date: Thu, 1 Dec 2016 23:57:44 +0300 > We want to set the other "err" variable here so that we can return it > later. My version of GCC misses this issue but I caught it with a > static checker. > > Fixes: 9f70eb339f52 ("net: ethernet: renesas:

Re: [RFC 2/3] dts: arm: genmai: Add MAXDESREF4x spidev

Hi Jacopo, On Fri, Dec 2, 2016 at 4:43 PM, Jacopo Mondi wrote: > Add device node for the MAX11100 evaluation board connected to Genmai's > CN2. > The evaluation kit is connected to 4 GPIO lines configured ad bitbanged 3 GPIO lines? configured as > SPI master interface > >

[PATCH 0/2] serial: sh-sci: Assorted flow control fixes

Hi Greg, Jiri, This patch series fixes two issues related to hardware flow control on Renesas SCIF UARTs. Thanks! Geert Uytterhoeven (2): serial: sh-sci: Fix early deassertion of dedicated RTS serial: sh-sci: Fix hang in sci_reset() drivers/tty/serial/sh-sci.c | 12 +--- 1

[PATCH 1/2] serial: sh-sci: Fix early deassertion of dedicated RTS

If a UART has dedicated RTS/CTS pins, there are some issues: 1. When changing hardware control flow, the new AUTORTS state is not immediately reflected in the hardware, but only when RTS is raised. However, the serial core doesn't call .set_mctrl() after .set_termios(), hence AUTORTS may

Re: [PATCH v2 3/3 pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar

On Fri, Dec 02, 2016 at 11:37:00AM +0100, Simon Horman wrote: > Add fallback compatibility string for the R-Car Gen 3 family. This is in > keeping with the both the existing fallback compatibility string for the > R-Car Gen 2 family and the fallback scheme being adopted wherever > appropriate