RE: [PATCH 1/2] clk: renesas: Add r8a77990 CPG Core Clock Definitions

Hi Geert-san, Thank you for the review! > From: Geert Uytterhoeven, Sent: Thursday, April 12, 2018 9:23 PM > > Hi Shimoda-san, > > On Wed, Apr 11, 2018 at 11:37 AM, Yoshihiro Shimoda > wrote: > > --- /dev/null > > +++

Re: [PATCH] extcon: int3496: use proper GPIO include

On 2018년 04월 13일 10:09, Chanwoo Choi wrote: > Hi, > > On 2018년 04월 10일 21:43, Wolfram Sang wrote: >> Since commit eca0f13c836a ("extcon: int3496: Ignore incorrect >> IoRestriction for ID pin"), the driver doesn't use GPIOF_* flags >> anymore. We can thus now drop the deprecated include file for

Re: [PATCH] extcon: int3496: use proper GPIO include

Hi, On 2018년 04월 10일 21:43, Wolfram Sang wrote: > Since commit eca0f13c836a ("extcon: int3496: Ignore incorrect > IoRestriction for ID pin"), the driver doesn't use GPIOF_* flags > anymore. We can thus now drop the deprecated include file for GPIO and > use the new one. Looks good to me. But,

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Vincent, Thanks for helping trying to figure this out. On 2018-04-12 15:30:31 +0200, Vincent Guittot wrote: [snip] > > I'd like to narrow the problem a bit more with the 2 patchies aboves. Can you > try > them separatly on top of c18bb396d3d261eb ("Merge >

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Vincent, On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote: [snip[ > > Can you send me your config ? > > I'm going to prepare a debug patch to spy what's happening when entering idle I'm sorry i missed this request when first reading your reply, I'm using

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Am 12.04.2018 um 15:30 schrieb Vincent Guittot: > Heiner, Niklas, > > Le Thursday 12 Apr 2018 à 13:15:19 (+0200), Niklas Söderlund a écrit : >> Hi Vincent, >> >> Thanks for your feedback. >> >> On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote: >>> Hi Niklas, >>> >>> On 12 April 2018 at 11:18,

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

Hi Philipp, On Thu, Apr 12, 2018 at 4:10 PM, Philipp Zabel wrote: > On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote: >> On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya wrote: >> > On 4/12/2018 7:49 AM, Auger Eric wrote: >> > > On 12/04/18

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote: > Hi Sinan, > > On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya wrote: > > On 4/12/2018 7:49 AM, Auger Eric wrote: > > > On 12/04/18 13:32, Geert Uytterhoeven wrote: > > > > On Thu, Apr 12, 2018 at 12:31 PM, Auger

[PATCH qemu v3] device_tree: Increase FDT_MAX_SIZE to 1 MiB

It is not uncommon for a contemporary FDT to be larger than 64 KiB, leading to failures loading the device tree from sysfs: qemu-system-aarch64: qemu_fdt_setprop: Couldn't set ...: FDT_ERR_NOSPACE Hence increase the limit to 1 MiB, like on PPC. For reference, the largest arm64 DTB created

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

Hi Sinan, On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya wrote: > On 4/12/2018 7:49 AM, Auger Eric wrote: >> On 12/04/18 13:32, Geert Uytterhoeven wrote: >>> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric wrote: On 11/04/18 11:15, Geert Uytterhoeven

Re: [PATCH/RFC 3/5] hw/arm/virt: Allow dynamic sysbus devices again

Hi Eric, On Wed, Feb 14, 2018 at 11:37 AM, Auger Eric wrote: > On 09/02/18 16:17, Geert Uytterhoeven wrote: >> Allow the instantation of generic dynamic sysbus devices again, without >> the need to create a new device-specific vfio type. >> >> This is a partial revert of

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

On 4/12/2018 7:49 AM, Auger Eric wrote: > Hi Geert, > On 12/04/18 13:32, Geert Uytterhoeven wrote: >> Hi Eric, >> >> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric wrote: >>> On 11/04/18 11:15, Geert Uytterhoeven wrote: Vfio-platform requires reset support, provided

Re: [PATCH 1/2] clk: renesas: Add r8a77990 CPG Core Clock Definitions

Hi Shimoda-san, On Wed, Apr 11, 2018 at 11:37 AM, Yoshihiro Shimoda wrote: > From: Takeshi Kihara > > This patch adds all R-Car E3 Clock Pulse Generator Core Clock Outputs. > > Note that internal CPG clocks (S0, S1, S2, S3, SDSRC)

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

Hi Geert, On 12/04/18 13:32, Geert Uytterhoeven wrote: > Hi Eric, > > On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric wrote: >> On 11/04/18 11:15, Geert Uytterhoeven wrote: >>> Vfio-platform requires reset support, provided either by ACPI, or, on DT >>> platforms, by a

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

On Thu, Apr 12, 2018 at 01:34:41PM +0200, Geert Uytterhoeven wrote: > Hi Wolfram, > > On Thu, Apr 12, 2018 at 1:31 PM, Wolfram Sang wrote: > >> That should have been caught by the !soc check above, and have already > >> returned with -ENODEV. > > > > Now I get it: You mean

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

Hi Eric, On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric wrote: > On 11/04/18 11:15, Geert Uytterhoeven wrote: >> Vfio-platform requires reset support, provided either by ACPI, or, on DT >> platforms, by a device-specific reset driver matching against the >> device's

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

> That should have been caught by the !soc check above, and have already > returned with -ENODEV. Now I get it: You mean non-0 check, not non-NULL check... signature.asc Description: PGP signature

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

Hi Wolfram, On Thu, Apr 12, 2018 at 1:11 PM, Wolfram Sang wrote: >> > + if (soc->data) >> >> This non-NULL check is not really needed. > > And if we match using the Gen3 generic compatible with a non-whitelisted > SoC? That should have been caught by the !soc check

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

> > +static unsigned long global_flags; > > Is the restriction on concurrent DMA RX streams global or per-device? ? Each device has only one DMA RX channel. Hey Simon, you upstreamed this driver :) Or did I get the question wrong? > > + if (dir == DMA_FROM_DEVICE) > > +

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Vincent, Thanks for your feedback. On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote: > Hi Niklas, > > On 12 April 2018 at 11:18, Niklas Söderlund > wrote: > > Hi Vincent, > > > > I have observed issues running on linus/master from a few days back [1]. > >

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

> > + if (soc->data) > > This non-NULL check is not really needed. And if we match using the Gen3 generic compatible with a non-whitelisted SoC? signature.asc Description: PGP signature

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Niklas, On 12 April 2018 at 11:18, Niklas Söderlund wrote: > Hi Vincent, > > I have observed issues running on linus/master from a few days back [1]. > I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue > by X forwarding the v4l2 test

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

Hi Geert, Philipp, On 11/04/18 11:15, Geert Uytterhoeven wrote: > Vfio-platform requires reset support, provided either by ACPI, or, on DT > platforms, by a device-specific reset driver matching against the > device's compatible value. > > On many SoCs, devices are connected to an SoC-internal

Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Hi Vincent, I have observed issues running on linus/master from a few days back [1]. I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue by X forwarding the v4l2 test application qv4l2 over ssh and moving the courser around in the GUI (best test case description award...).

RE: [PATCH 3/4] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

Hi Geert-san, Simon-san, > From: Simon Horman , Sent: Thursday, April 12, 2018 4:55 > PM > > On Wed, Apr 11, 2018 at 05:10:02PM +0200, Geert Uytterhoeven wrote: > > Hi Shimoda-san, > > > > On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda > >

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

From: Sergei Shtylyov 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

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

From: Sergei Shtylyov 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

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

From: Sergei Shtylyov Define the generic R8A77970 part of the LVDS device node. Signed-off-by: Sergei Shtylyov --- arch/arm64/boot/dts/renesas/r8a77970.dtsi | 28 1 file changed, 28

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

From: Sergei Shtylyov 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

[PATCH v3 5/5] arm64: dts: renesas: eagle: Enable HDMI output

Enable HDMI output on Renesas R-Car V3M Eagle board. The HDMI ouput is enabled connecting the DU LVDS output to the transparent LVDS converter THC63LVD1024, and successively routing its RGB output to the ADV7511W HDMI encoder. Signed-off-by: Niklas Söderlund

[PATCH v3 0/5] V3M-Eagle HDMI output enablement

Hello, I have rebased the Eagle display enablement on top of (part of) Sergei's series: [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support Simon: you can skip "[1/5] arm64: dts: renesas: r8a77970: add FCPVD support" as you already collected that Sergei: I re-sent your series because there

[PATCH v3 0/5] V3M-Eagle HDMI output enablement

Hello, I have rebased the Eagle display enablement on top of (part of) Sergei's series: [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support Simon: you can skip "[1/5] arm64: dts: renesas: r8a77970: add FCPVD support" as you already collected that Sergei: I re-sent your series because there

Re: [PATCH v3 0/5] V3M-Eagle HDMI output enablement

Hi Simon, On Thu, Apr 12, 2018 at 10:08:27AM +0200, Simon Horman wrote: > On Wed, Apr 11, 2018 at 02:43:05PM +0200, Jacopo Mondi wrote: > > Hello, > >I have rebased the Eagle display enablement on top of (part of) Sergei's > > series: > > [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support >

RE: [PATCH 4/4] soc: renesas: rcar-rst: Add support for R-Car E3

Hi Simon-san, > From: Simon Horman, Sent: Thursday, April 12, 2018 4:55 PM > > On Wed, Apr 11, 2018 at 05:18:28PM +0200, Geert Uytterhoeven wrote: > > Hi Shimoda-san, > > > > Thanks for your patch! > > > > On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda > >

Re: [PATCH v3 0/5] V3M-Eagle HDMI output enablement

On Wed, Apr 11, 2018 at 02:43:05PM +0200, Jacopo Mondi wrote: > Hello, >I have rebased the Eagle display enablement on top of (part of) Sergei's > series: > [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support Hi Jacopo, the emails with the patches of this series do not seem to have hit my

Re: [PATCH v4 1/8] arm: shmobile: Add the RZ/N1 arch to the shmobile Kconfig

On Tue, Apr 10, 2018 at 09:30:01AM +0100, Michel Pollet wrote: > Add the RZ/N1 Family (Part #R9A06G0xx) ARCH config to the rest of > the Renesas SoC collection. > > Signed-off-by: Michel Pollet > Reviewed-by: Geert Uytterhoeven This change

Re: [PATCH 3/4] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

On Wed, Apr 11, 2018 at 05:10:02PM +0200, Geert Uytterhoeven wrote: > Hi Shimoda-san, > > On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda > wrote: > > From: Takeshi Kihara > > > > This patch adds Cortex-A53 CPU{0,1},

Re: [PATCH 4/4] soc: renesas: rcar-rst: Add support for R-Car E3

On Wed, Apr 11, 2018 at 05:18:28PM +0200, Geert Uytterhoeven wrote: > Hi Shimoda-san, > > Thanks for your patch! > > On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda > wrote: > > From: Takeshi Kihara > > > > This patch adds

Re: [PATCH 2/4] soc: renesas: Add r8a77990 SYSC PM Domain Binding Definitions

On Wed, Apr 11, 2018 at 04:55:46PM +0200, Geert Uytterhoeven wrote: > On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda > wrote: > > From: Takeshi Kihara > > > > This patch adds power domain indices for R-Car E3. > > > >

Re: [PATCH 1/4] soc: renesas: identify R-Car E3

On Wed, Apr 11, 2018 at 03:26:49PM +0200, Geert Uytterhoeven wrote: > On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda > wrote: > > From: Takeshi Kihara > > > > This patch adds support for identifying the R-Car E3 (R8A77990)

Re: [PATCH 3/3] arm64: renesas: Add Renesas R8A77990 Kconfig support

On Wed, Apr 11, 2018 at 03:25:06PM +0200, Geert Uytterhoeven wrote: > On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda > wrote: > > Add configuration option for the R-Car E3 (R8A77990) SoC. > > > > Signed-off-by: Yoshihiro Shimoda

Re: [PATCH 2/3] dt-bindings: arm: Document Renesas Ebisu board DT bindings

On Wed, Apr 11, 2018 at 03:24:39PM +0200, Geert Uytterhoeven wrote: > On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda > wrote: > > This patch adds device tree bindings documentation for Renesas > > Ebisu board (RTP0RC77990SEB0010S). > > > > Signed-off-by:

Re: [PATCH 1/3] dt-bindings: arm: Document R-Car E3 SoC DT bindings

On Wed, Apr 11, 2018 at 01:42:08PM +0200, Geert Uytterhoeven wrote: > On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda > wrote: > > This patch adds device tree bindings documentation for Renesas R-Car > > E3 (r8a77990). > > > > Signed-off-by: Yoshihiro Shimoda

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

On Wed, Apr 11, 2018 at 11:24:08AM +0200, Geert Uytterhoeven wrote: > If a device is part of a PM Domain (e.g. power and/or clock domain), its > power state is managed using Runtime PM. Without Runtime PM, the device > may not be powered up, causing subtle failures, crashes, or system > lock-ups

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

On Wed, Apr 11, 2018 at 11:15:49AM +0200, Geert Uytterhoeven wrote: > Vfio-platform requires reset support, provided either by ACPI, or, on DT > platforms, by a device-specific reset driver matching against the > device's compatible value. > > On many SoCs, devices are connected to an

Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

Hi Geert, On Wed, Apr 11, 2018 at 10:39:19AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Wed, Apr 11, 2018 at 10:22 AM, Simon Horman wrote: > > On Tue, Apr 10, 2018 at 05:53:47PM +0200, Geert Uytterhoeven wrote: ... > >> @@ -217,6 +236,9 @@ static int