Re: [PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

On Mon, Jan 15, 2018 at 08:59:38AM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Monday, 15 January 2018 08:55:29 EET Simon Horman wrote: > > On Fri, Jan 12, 2018 at 03:29:48PM +0200, Laurent Pinchart wrote: > > > On Friday, 12 January 2018 12:13:18 EET Geert Uytterhoeven wrote: > > >> On

Re: [PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

On Mon, Jan 15, 2018 at 09:00:59AM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Monday, 15 January 2018 08:57:48 EET Simon Horman wrote: > > On Fri, Jan 12, 2018 at 03:48:25PM +0200, Laurent Pinchart wrote: > > > On Friday, 12 January 2018 11:47:03 EET Geert Uytterhoeven wrote: > > >> On

Re: [PATCH 05/10] ARM: dts: porter: Fix HDMI output routing

On Fri, Jan 12, 2018 at 02:58:53AM +0200, Laurent Pinchart wrote: > The HDMI encoder is connected to the RGB output of the DU, which is > port@0, not port@1. Fix the incorrect DT description. > > Signed-off-by: Laurent Pinchart Should this have the

Re: [PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

Hi Simon, On Monday, 15 January 2018 08:57:48 EET Simon Horman wrote: > On Fri, Jan 12, 2018 at 03:48:25PM +0200, Laurent Pinchart wrote: > > On Friday, 12 January 2018 11:47:03 EET Geert Uytterhoeven wrote: > >> On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote: > >>> This patch series

Re: [PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

Hi Simon, On Monday, 15 January 2018 08:55:29 EET Simon Horman wrote: > On Fri, Jan 12, 2018 at 03:29:48PM +0200, Laurent Pinchart wrote: > > On Friday, 12 January 2018 12:13:18 EET Geert Uytterhoeven wrote: > >> On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote: > >>> The Renesas R-Car

Re: [PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

On Fri, Jan 12, 2018 at 03:48:25PM +0200, Laurent Pinchart wrote: > Hi Geert, > > On Friday, 12 January 2018 11:47:03 EET Geert Uytterhoeven wrote: > > On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote: > > > This patch series addresses a design mistake that dates back from the > > >

Re: [PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

On Fri, Jan 12, 2018 at 02:58:48AM +0200, Laurent Pinchart wrote: > Hello, > > This patch series addresses a design mistake that dates back from the initial > DU support. Support for the LVDS encoders, which are IP cores separate from > the DU, was bundled in the DU driver. Worse, both the DU and

Re: [PATCH v5 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver

Hello Hans, On Fri, Jan 12, 2018 at 04:27:50PM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > On Friday, 12 January 2018 16:04:00 EET Jacopo Mondi wrote: > > Hello, > >(hopefully) last round for CEU driver. > > > > Changelog is quite thin, I have updated CEU driver MODULE_LICENSE to match >

Re: [PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

On Fri, Jan 12, 2018 at 03:29:48PM +0200, Laurent Pinchart wrote: > Hi Geert, > > On Friday, 12 January 2018 12:13:18 EET Geert Uytterhoeven wrote: > > On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote: > > > The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add > > >

Re: [PATCH] ARM: dts: iwg22m: Enable cmt0

On Thu, Jan 11, 2018 at 08:59:39PM +, Fabrizio Castro wrote: > This patch enables cmt0 support from within the iwg22m SoM dtsi. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das Thanks, applied.

Re: [PATCH] ARM: dts: iwg20m: Enable cmt0

On Thu, Jan 11, 2018 at 08:59:38PM +, Fabrizio Castro wrote: > This patch enables cmt0 support from within the iwg20m SoM dtsi. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das Thanks, applied.

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven wrote: > Hi Rafael, > > On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki wrote: >> On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote: >>> On Fri, Jan 12, 2018 at 2:00 PM, Rafael J.

[PATCH 1/3] extcon: int3496: don't use GPIOF_* with gpiod_get_direction

The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("gpio: correct docs about return value of gpiod_get_direction"). Now, fix this user (until a better, system-wide solution is in place). This also means we

[PATCH 0/3] tree-wide: don't use GPIOF_* with gpiod_get_direction

The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("gpio: correct docs about return value of gpiod_get_direction"). Now, fix the users who got it as wrong as I did when developing bus recovery for the R-Car

[PATCH 3/3] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("gpio: correct docs about return value of gpiod_get_direction"). Now, fix this user (until a better, system-wide solution is in place). Signed-off-by:

[PATCH 2/3] serial: mxs-auart: don't use GPIOF_* with gpiod_get_direction

The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("gpio: correct docs about return value of gpiod_get_direction"). Now, fix this user (until a better, system-wide solution is in place). This also means we

[PATCH 0/2] sh_eth: simplify TSU initialization

Hello! Here's a set of 2 patches against DaveM's 'net-next.git' repo. With those, I'm somewhat simplifying the TSU init code in the driver probe() method... [1/2] sh_eth: gather all TSU init code in one place [2/2] sh_eth: get Ether port # only when needed MBR, Sergei

[PATCH 2/2] sh_eth: get Ether port # only when needed

The dual-port Ether configurations always have a shared TSU to e.g. pass the packets between those ports. With the TSU init. code gathered under the single *if*, we now can only get the port # from 'platform_device::id' only when we actually need it (and not recalculate it each time)...

[PATCH 1/2] sh_eth: gather all TSU init code in one place

The sh_eth_cpu_data::chip_reset() method always resets using ARSTR and this register is always located at the start of the TSU register region. Therefore, we can only call this method if we know TSU is there and thus simplify the probing code a bit... Signed-off-by: Sergei Shtylyov

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

Hi Rafael, On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki wrote: > On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote: >> On Fri, Jan 12, 2018 at 2:00 PM, Rafael J. Wysocki >> wrote: >> > This comes from the recent discussion/testing

RE: Kernel 4.14 test results on porter

Hi, Sorry, I got a mistake in my previous mail. MMC can be used normally in kernel 4.14 on porter, so just ignore the issue:1 in my pre-mail. Thanks. The test results report in the pre-mail is correct. Now, I have two questions, 1. Benchmark.netpipe failed, error msg as below: ... Send