[PATCH V2] ARM: shmobile: Rework the PMIC IRQ line quirk

Rather than hard-coding the quirk topology, which stopped scaling, parse the information from DT. The code looks for all compatible PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied to the same pin. If so, the code sends a matching sequence to the PMIC to deassert the IRQ.

Re: [PATCH] PCI: rcar: Clean up PHY init on failure

CC Sergei On Fri, May 25, 2018 at 8:33 PM, Marek Vasut wrote: > If the Gen3 PHY fails to power up, the code does not undo the > initialization caused by phy_init(). Add the missing failure > handling to the rcar_pcie_phy_init_gen3() function. > > Signed-off-by: Marek Vasut

Re: [PATCH 2/2] ARM: shmobile: only call secure_cntvoff_init on SMP builds

Hi Arnd, On Fri, May 25, 2018 at 6:10 PM, Arnd Bergmann wrote: > The secure_cntvoff_init() function is not available without CONFIG_SMP, > leading to a link error on shmobile: > > arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init': >

Re: [PATCH v4 6/6] PCI: rcar: Shut the PHY down in failpath

On 05/25/2018 12:09 PM, Geert Uytterhoeven wrote: > On Thu, May 24, 2018 at 4:36 PM, Marek Vasut wrote: >> If anything fails past phy_init_fn() and the system is a Gen3 with >> a PHY, the PHY will be left on and inited. This is caused by the >> phy_init_fn, which is in fact

[PATCH] PCI: rcar: Clean up PHY init on failure

If the Gen3 PHY fails to power up, the code does not undo the initialization caused by phy_init(). Add the missing failure handling to the rcar_pcie_phy_init_gen3() function. Signed-off-by: Marek Vasut Reported-by: Geert Uytterhoeven Cc:

Re: [PATCH v4 0/6] PCI: rcar: Failpath fixes

On 05/25/2018 06:43 PM, Lorenzo Pieralisi wrote: > On Thu, May 24, 2018 at 04:36:18PM +0200, Marek Vasut wrote: >> Multiple minor failpath fixes for the R-Car PCIe driver. >> >> V4: Sync up the version numbers >> Rebase on top of Lorenzo's tree >> Add new patch fixing bug in the PHY code

Re: [PATCH 4/8] drm/rcar-du: fix merge conflict for state->alpha

Hi Arnd, Thank you for the patch. On Friday, 25 May 2018 18:50:11 EEST Arnd Bergmann wrote: > The "alpha" struct member was removed in one commit but another user > added in another, leading to a build failure: > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function >

Re: [PATCH v4 0/6] PCI: rcar: Failpath fixes

On Thu, May 24, 2018 at 04:36:18PM +0200, Marek Vasut wrote: > Multiple minor failpath fixes for the R-Car PCIe driver. > > V4: Sync up the version numbers > Rebase on top of Lorenzo's tree > Add new patch fixing bug in the PHY code > > Marek Vasut (6): > PCI: rcar: Pull bus clock

[PATCH 2/2] ARM: shmobile: only call secure_cntvoff_init on SMP builds

The secure_cntvoff_init() function is not available without CONFIG_SMP, leading to a link error on shmobile: arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init': setup-rcar-gen2.c:(.init.text+0x18): undefined reference to `secure_cntvoff_init' >From the description in

[PATCH 4/8] drm/rcar-du: fix merge conflict for state->alpha

The "alpha" struct member was removed in one commit but another user added in another, leading to a build failure: drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function 'rcar_du_vsp_plane_atomic_duplicate_state': drivers/gpu/drm/rcar-du/rcar_du_vsp.c:325:6: error: 'struct rcar_du_vsp_plane_state'

[PATCH] gpio: dwapb: Fix rework support for 1 interrupt per port A GPIO

Commit da069d5d2b814d9887989dcdb29fb0202eac8b38 ("gpio: dwapb: Rework support for 1 interrupt per port A GPIO"), was an incremental patch that was supposed to provide the delta between v5 and v6 patch set for adding support for 1 interupt per port A GPIO. v5 was applied, then some other feedback

[PATCH 0/2] arm64: dts: renesas: add missing strobe pin to SDHI

The strobe pin (SD2_DS) was forgotten to be configured when switching to 1.8V on H3/M3-W/M3-N boards. Fix it with this series. While this is a bug, I am not sure if it needs to be backported. This pin is only needed for HS400 operation which we don't support yet but soon. So, we surely want to

[PATCH 2/2] arm64: dts: ulcb: Add sdhi2_ds pin group to SDHI2 pinctrl groups

This patch adds definitions for configuration of the power-source, drive-strength, etc... for the SD2_DS pin. Based on a similar patch for Salvator boards by Masaharu Hayakawa and Takeshi Kihara. Signed-off-by: Wolfram Sang ---

[PATCH 1/2] arm64: dts: salvator-common: Add sdhi2_ds pin group to SDHI2 pinctrl groups

From: Masaharu Hayakawa This patch adds definitions for configuration of the power-source, drive-strength, etc... for the SD2_DS pin. Signed-off-by: Masaharu Hayakawa Signed-off-by: Takeshi Kihara

Re: [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.18

On Fri, May 18, 2018 at 01:14:48PM +0200, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM64 based SoC defconfig updates for v4.18. > > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15

Re: [PATCH v4 5/9] media: rcar-vin: Parse parallel input on Gen3

Hi Niklas, I might have another question before sending v5. On Fri, May 25, 2018 at 12:29:44AM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your work. > > I really like what you did with this patch in v4. > > On 2018-05-25 00:02:15 +0200, Jacopo Mondi wrote: > > The rcar-vin

[PATCH 0/2] arm: dts: salvator-x(s): increase I2C ch4 bus speed

Patches taken from the BSP. I did some testing by accessing the chips manually. I also checked the datasheets of the attached I2C clients which confirm this step up. Takeshi Kihara (2): arm64: dts: salvator-x: Update I2C ch4 clock to 400kHz arm64: dts: salvator-xs: Update I2C ch4 clock to

[PATCH 1/2] arm64: dts: salvator-x: update I2C ch4 clock to 400kHz

From: Takeshi Kihara Any of the following devices connected to I2C ch4 of the Salvator-X board will operate at 400 kHz: PCA9654, 9FGV0841, ADV7482WBBCZ, MAX9611, 5P49V5923 This patch updates the clock frequency to 400 KHz. Signed-off-by: Takeshi Kihara

[PATCH 2/2] arm64: dts: salvator-xs: update I2C ch4 clock to 400kHz

From: Takeshi Kihara Any of the following devices connected to I2C ch4 of the Salvator-XS board will operate at 400 kHz: PCA9654E, 9FGV0841, ADV7482WBBCZ, MAX9611, 5P49V6901A This patch updates the clock frequency to 400 KHz. Signed-off-by: Takeshi Kihara

[PATCH 00/15] arm: dts: Fix OPP and cooling device properties

This fixes missing OPP and cooling device properties for CPUs for the ARM 32 bit platforms. This is build tested by the zero day testing infrastructure as well. Individual maintainers can pick the patches to their SoC trees or I will ask ARM SoC maintainers to pick them up later. -- viresh

[PATCH 13/15] arm: dts: r8a7743: Add missing OPP properties for CPUs

The OPP properties, like "operating-points", should either be present for all the CPUs of a cluster or none. If these are present only for a subset of CPUs of a cluster then things will start falling apart as soon as the CPUs are brought online in a different order. For example, this will happen

Re: [PATCH v7 1/5] dt-bindings: Add the r9a06g032-sysctrl.h file

Hi Michel, On Thu, May 24, 2018 at 11:28 AM, Michel Pollet wrote: > This adds the constants necessary to use the renesas,r9a06g032-sysctrl node. > > Signed-off-by: Michel Pollet Thanks for your patch! > --- /dev/null > +++

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

Hi Simon, On Friday, 25 May 2018 13:13:20 EEST Simon Horman wrote: > On Thu, May 24, 2018 at 11:00:52AM +0300, Laurent Pinchart wrote: > > On Wednesday, 21 February 2018 18:39:25 EEST Simon Horman wrote: > >> On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote: [snip] > >>> Laurent

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

On Thu, May 24, 2018 at 11:00:52AM +0300, Laurent Pinchart wrote: > Hi Simon, > > (Reducing the CC list as this became a Renesas-specific issue) > > On Wednesday, 21 February 2018 18:39:25 EEST Simon Horman wrote: > > On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote: > > > Hello,

Re: [PATCH] arm64: defconfig: Enable BD9571MWV regulator

On Wed, May 23, 2018 at 03:35:31PM +0200, Geert Uytterhoeven wrote: > From: Dien Pham > > The BD9571 PMIC is present on the Renesas Salvator-X(S) and R-Car > Starter Kit Premier/Pro development boards. > > Signed-off-by: Dien Pham >

Re: [PATCH v4 6/6] PCI: rcar: Shut the PHY down in failpath

On Thu, May 24, 2018 at 4:36 PM, Marek Vasut wrote: > If anything fails past phy_init_fn() and the system is a Gen3 with > a PHY, the PHY will be left on and inited. This is caused by the > phy_init_fn, which is in fact a pointer to rcar_pcie_phy_init_gen3() > function,

Re: [PATCH] ARM: dts: porter: Add missing PMIC nodes

On Wed, May 23, 2018 at 01:52:32PM +0200, Geert Uytterhoeven wrote: > Hi Marek, > > On Wed, May 23, 2018 at 1:43 PM, Marek Vasut wrote: > > Add PMIC nodes to Porter and connect CPU DVFS supply. There is > > one DA9063L and one DA9210 on Porter, the only difference from > >

Re: [PATCH] PCI: rcar: Remove IRQ mappings in rcar_pcie_enable_msi failpath

On Wed, May 23, 2018 at 12:52:20PM +0200, Marek Vasut wrote: > The rcar_pcie_enable_msi() creates IRQ mappings using irq_create_mapping() > before requesting the IRQs using devm_request_irq(). If devm_request_irq() > fails for some reason, rcar_pcie_enable_msi() does not remove the mapping. > >

Re: [PATCH v4 0/6] PCI: rcar: Failpath fixes

Hi Lorenzo, On Fri, May 25, 2018 at 11:56 AM, Lorenzo Pieralisi wrote: > On Fri, May 25, 2018 at 11:39:08AM +0200, Geert Uytterhoeven wrote: >> On Fri, May 25, 2018 at 11:35 AM, Lorenzo Pieralisi >> wrote: >> > Can I retain your review tags

Re: [PATCH v4 0/6] PCI: rcar: Failpath fixes

On Fri, May 25, 2018 at 11:39:08AM +0200, Geert Uytterhoeven wrote: > Hi Lorenzo, > > On Fri, May 25, 2018 at 11:35 AM, Lorenzo Pieralisi > wrote: > > Can I retain your review tags on this series so that I can queue > > the patches ? I already added them apart from the

Re: [PATCH v3 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver

Hi Michel, On Thu, May 24, 2018 at 12:30 PM, Michel Pollet wrote: > The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it > requires a special enable method to get it started. > > Signed-off-by: Michel Pollet Thanks

Re: [PATCH v4 0/6] PCI: rcar: Failpath fixes

Hi Lorenzo, On Fri, May 25, 2018 at 11:35 AM, Lorenzo Pieralisi wrote: > Can I retain your review tags on this series so that I can queue > the patches ? I already added them apart from the last patch that > is new, please let me know asap. Yes, please. Thanks!

Re: [PATCH v4 0/6] PCI: rcar: Failpath fixes

Geert, Simon, Can I retain your review tags on this series so that I can queue the patches ? I already added them apart from the last patch that is new, please let me know asap. Thanks, Lorenzo On Thu, May 24, 2018 at 04:36:18PM +0200, Marek Vasut wrote: > Multiple minor failpath fixes for the

Re: [PATCH v7 4/5] ARM: dts: Renesas RZN1D-DB Board base file

On Thu, May 24, 2018 at 11:28 AM, Michel Pollet wrote: > This adds a base device tree file for the RZN1-DB board, with only the > basic support allowing the system to boot to a prompt. Only one UART is > used, with only a single CPU running. > > Signed-off-by: Michel

Re: [PATCH v7 3/5] ARM: dts: Renesas R9A06G032 base device tree file

Hi Michel, On Thu, May 24, 2018 at 11:28 AM, Michel Pollet wrote: > This adds the Renesas R9A06G032 bare bone support. > > This currently only handles generic parts (gic, architected timer) > and a UART. > > Signed-off-by: Michel Pollet

Re: [PATCH v7 2/5] dt-bindings: clock: renesas,r9a06g032-sysctrl: documentation

Hi Michel, On Thu, May 24, 2018 at 11:28 AM, Michel Pollet wrote: > The Renesas R9A06G032 SYSCTRL node description. > > Signed-off-by: Michel Pollet Thanks for your patch! > --- /dev/null > +++

Re: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file

Hi Michel, On Wed, May 23, 2018 at 10:17 AM, M P wrote: > On Wed, 23 May 2018 at 08:26, Geert Uytterhoeven > wrote: >> On Wed, May 23, 2018 at 8:44 AM, M P wrote: >> > On Tue, 22 May 2018 at 19:44, Geert Uytterhoeven

Re: [PATCH 0/6] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers

Hi Vladimir, On Thu, May 24, 2018 at 1:11 PM, Vladimir Zapolskiy wrote: > For ages trivial changes to RAVB and SuperH ethernet links by means of > standard 'ethtool' trigger a 'sleeping function called from invalid > context' bug, to visualize it on r8a7795 ULCB: >

Re: [PATCH v4 5/9] media: rcar-vin: Parse parallel input on Gen3

Hi Niklas, On Fri, May 25, 2018 at 12:29:44AM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your work. > > I really like what you did with this patch in v4. Thanks for review and suggestions, what's there comes mostly from your comments and guidance. > > On 2018-05-25 00:02:15

[PATCH v5] usb: gadget: udc: renesas_usb3: Add register of usb role switch

This patch adds role switch support for R-Car SoCs into the USB 3.0 peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0 dual-role device controller which has the USB 3.0 xHCI host and Renesas USB 3.0 peripheral. Unfortunately, the mode change register (DRD_CON) contains the USB 3.0

Re: [PATCH 0/6] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers

Hello Sergei, On 05/24/2018 08:24 PM, Sergei Shtylyov wrote: > On 05/24/2018 07:40 PM, Sergei Shtylyov wrote: > >>> For ages trivial changes to RAVB and SuperH ethernet links by means of >>> standard 'ethtool' trigger a 'sleeping function called from invalid >>> context' bug, to visualize it on

Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops

Hello Sergei, On 05/24/2018 08:01 PM, Sergei Shtylyov wrote: > On 05/24/2018 07:44 PM, Andrew Lunn wrote: > >> The change fixes a sleep in atomic context issue, which can be >> always triggered by running 'ethtool -r' command, because >> phy_start_aneg() protects phydev fields by a