Re: [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API

Hi Sebastian, On 2016년 12월 07일 12:05, Sebastian Reichel wrote: > Hi Chanwoo, > > On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote: >> Could you please review and pick the patch3/4 for power-supply driver? > > Patches look fine. As I expect the merge window to open next week I >

Re: [PATCH v4 2/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

Hello Wolfram, On Thu, Dec 01, 2016 at 11:04:40PM +0100, Wolfram Sang wrote: > Add support for R-Car Gen3 thermal sensors. Polling only for now, > interrupts will be added incrementally. Same goes for reading fuses. > This is documented already, but no hardware available for now. > >

Re: [PATCH v4 2/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

On Thu, Dec 01, 2016 at 11:04:40PM +0100, Wolfram Sang wrote: > Add support for R-Car Gen3 thermal sensors. Polling only for now, > interrupts will be added incrementally. Same goes for reading fuses. > This is documented already, but no hardware available for now. > > Signed-off-by: Hien Dang

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

On Fri, Dec 02, 2016 at 09:44:22PM +0100, Wolfram Sang wrote: > 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

Re: [PATCH 15/22] dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings

On Fri, Dec 02, 2016 at 01:43:30AM +0200, Laurent Pinchart wrote: > The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add > corresponding device tree bindings based on the DWC HDMI TX bindings > model. > > Signed-off-by: Laurent Pinchart

Re: [PATCH 14/22] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote: > Make it clear that the core bridge/dw_hdmi.txt document isn't a device > tree binding by itself but is meant to be referenced by platform device > tree bindings, and update the Rockchip and Freescale DWC HDMI TX > bindings to

Re: [PATCH] iio: Add Maxim MAX11100 driver

On Tue, 6 Dec 2016, Jacopo Mondi wrote: > Add IIO driver for Maxim MAX11100 single-channel ADC. > Support raw_read mode only. comments below; very minimal driver, but several easy issues... the read_raw() is supposed to return millivolts (after application of offset and scale); maybe need

RE: [RFC] New Device Tree property - "bonding"

Hi Rob, > >> On Monday 05 Dec 2016 09:57:32 Rob Herring wrote: > >> > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote: > >> > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote: > >> > >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote: > >> > >>> Hello DT maintainers, > >>

[PATCH] iio: Add Maxim MAX11100 driver

Add IIO driver for Maxim MAX11100 single-channel ADC. Support raw_read mode only. Signed-off-by: Jacopo Mondi --- drivers/iio/adc/Kconfig| 9 +++ drivers/iio/adc/Makefile | 1 + drivers/iio/adc/max11100.c | 165 + 3 files

[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

[PATCH pci/next v3 3/3] 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 pci/next v3 2/3] PCI: rcar: Use gen2 fallback compatibility last

Improve readability by listing fallback compatibility strings after the more-specific compatibility strings they provide a fallback for. This does not effect run-time behaviour as it is the order in the DTB that determines which compatibility string is used. Signed-off-by: Simon Horman

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

Improve readability by listing fallback compatibility strings after the more-specific compatibility strings they provide a fallback for. This does not effect run-time behaviour as it is the order in the DTB that determines which compatibility string is used. Signed-off-by: Simon Horman

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

Hi, this short series makes some bindings cleanups to the Renesas PCI drivers. Changes v2->v3: * Reworded changelogs to indicate that re-ordering struct of_device_id entries does not effect run-time behaviour * Corrected compile error due to typo in symbol name Changes v1->v2: * re-order

RE: [RFC] New Device Tree property - "bonding"

Hi Rob, Laurent, Thanks for the response. > On Monday 05 Dec 2016 09:57:32 Rob Herring wrote: > > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote: > > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote: > > >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote: > > >>> Hello

renesas-drivers-2016-12-06-v4.9-rc8

I have pushed renesas-drivers-2016-12-06-v4.9-rc8 to https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git This tree is meant to ease development of platform support and drivers for Renesas ARM SoCs. It is created by merging branches with driver code submitted or planned for

Re: [PATCH] drm: rcar-du: Fix R-Car Gen3 crash when VSP is disabled

Hello, On Wednesday 26 Oct 2016 18:13:23 Magnus Damm wrote: > On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote: > > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote: > >> From: Magnus Damm > >> > >> For the DU to operate on R-Car Gen3 hardware a

Re: [PATCH renesas/devel 2/2] ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

On Tue, Dec 6, 2016 at 2:32 PM, Simon Horman wrote: > Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs. > > Signed-off-by: Simon Horman Acked-by: Geert Uytterhoeven Gr{oetje,eeting}s,

Re: [PATCH renesas/devel 1/2] ARM: shmobile: defconfig: Enable r8a774[35] SoCs

On Tue, Dec 6, 2016 at 2:32 PM, Simon Horman wrote: > Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs. > > Signed-off-by: Simon Horman Acked-by: Geert Uytterhoeven Gr{oetje,eeting}s,

[PATCH renesas/devel 2/2] ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs. Signed-off-by: Simon Horman --- arch/arm/configs/multi_v7_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig

[PATCH renesas/devel 1/2] ARM: shmobile: defconfig: Enable r8a774[35] SoCs

Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs. Signed-off-by: Simon Horman --- arch/arm/configs/shmobile_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig

[PATCH renesas/devel 0/2] ARM: Enable r8a774[35] SoCs in defconfigs

Hi, this short series enables recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs in relevant defconfigs. Based on renesas-devel-20161206-v4.9-rc8 Simon Horman (2): ARM: shmobile: defconfig: Enable r8a774[35] SoCs ARM: multi_v7_defconfig: Enable r8a774[35] SoCs arch/arm/configs

Re: [PATCH v2 0/5] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode

Hi Simon, On Tue, Dec 6, 2016 at 1:39 PM, Simon Horman wrote: > On Mon, Dec 05, 2016 at 11:39:36AM +0100, Geert Uytterhoeven wrote: >> This patch series allows booting secondary CPU cores on R-Car Gen2 when >> hardware debug mode is enabled. In this mode, reset requests

Re: [PATCH v2 0/5] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode

On Mon, Dec 05, 2016 at 11:39:36AM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series allows booting secondary CPU cores on R-Car Gen2 when > hardware debug mode is enabled. In this mode, reset requests derived > from power-shutoff to the AP-system CPU cores must be

[PATCH 2/4] v4l: vsp1: Refactor video pipeline configuration

With multiple inputs through the BRU it is feasible for the streams to race each other at stream-on. In the case of the video pipelines, this can present two serious issues. 1) A null-dereference if the pipe->dl is committed at the same time as the vsp1_video_setup_pipeline() is processing

[PATCH 3/4] v4l: vsp1: Use local display lists and remove global pipe->dl

The usage of pipe->dl is susceptible to races, and it is redundant to keep this pointer in a larger scoped context. Now that the calling order of vsp1_video_setup_pipeline() has been adapted, it is possible to remove the pipe->dl and pass the variable as required. Currently the pipe->dl is set

[PATCH RFC 4/4] media: Catch null pipes on pipeline stop

media_entity_pipeline_stop() can be called through error paths with a NULL entity pipe object. In this instance, stopping is a no-op, so simply return without any action Signed-off-by: Kieran Bingham --- I've marked this patch as RFC, although if deemed

[PATCH 1/4] v4l: vsp1: Move vsp1_video_setup_pipeline()

Move the static vsp1_video_setup_pipeline() function in preparation for the callee updates so that the vsp1_video_pipeline_run() call can configure pipelines following suspend resume actions. This commit is just a code move for clarity performing no functional change. Signed-off-by: Kieran

[PATCH 0/4] v4l: vsp1: Fix suspend/resume and race on M2M pipelines

This small patchset helps rework the VSP1 driver to repair an issue on suspend/resume operations whereby the pipeline does not get reconfigured after it has been re-initialised following a resume operation. Along side this, there was an intrinsic race in the vsp1_video_start_streaming() function