Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.11

On Mon, Jan 09, 2017 at 07:15:32PM -0800, Olof Johansson wrote: > On Fri, Jan 06, 2017 at 12:17:56PM +0100, Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > > > Please consider these Renesas ARM64 based SoC DT updates for v4.11. > > > > This is based on v4.10-rc2 as v4.10-rc1 does not

[PATCH] arm64: dts: h3ulcb: follow sound CTU/MIX supports

From: Kuninori Morimoto commit 5bcd74e8a30d9259 ("arm64: dts: r8a7795: add sound MIX support") commit 5be5ee41d011f26b ("arm64: dts: r8a7795: add sound CTU support") added MIX/CTU support, and it updated clocks on SoC level. Thus, h3ulcb should be updated

Re: NVMe vs DMA addressing limitations

Christoph, thanks for clear input. Arnd, I think that given this discussion, best short-term solution is indeed the patch I've submitted yesterday. That is, your version + coherent mask support. With that, set_dma_mask(DMA_BIT_MASK(64)) will succeed and hardware with work with swiotlb. Possible

Re: NVMe vs DMA addressing limitations

On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote: > I'm now working with HW that: > - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores, > and is being manufactured and developed, > - has 75% of it's RAM located beyond first 4G of address space, > - can't

[PATCH] clk: cs2000: add Suspend/Redume feature

From: Khiem Nguyen CS2000 needs re-setup when redume, otherwise, it can't handle correct clock rate. Signed-off-by: Khiem Nguyen [Kuninori: cleanup original patch] Signed-off-by: Kuninori Morimoto

NVMe vs DMA addressing limitations

>> I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC >> but in block layer, in particular it should be controlled by >> blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it >> is something completely different, namely it is for request merging for >> hw

Re: [GIT PULL] Renesas ARM Based SoC Updates for v4.11

On Fri, Jan 06, 2017 at 12:18:48PM +0100, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC updates for v4.11. > > > The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77: > > Linux 4.10-rc1 (2016-12-25 16:13:08 -0800) >

Re: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.11

On Fri, Jan 06, 2017 at 12:18:31PM +0100, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC DT updates for v4.11. > > > The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77: > > Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.11

On Fri, Jan 06, 2017 at 12:17:56PM +0100, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM64 based SoC DT updates for v4.11. > > This is based on v4.10-rc2 as v4.10-rc1 does not compile using > the defconfig. > > > The following changes since commit

Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.11

On Fri, Jan 06, 2017 at 12:18:10PM +0100, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC defconfig updates for v4.11. > > > The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77: > > Linux 4.10-rc1 (2016-12-25 16:13:08

RE: [PATCH 0/3] Renesas RZ PFC and GPIO driver

Hi Laurent, On Monday, January 09, 2017, Laurent Pinchart wrote: > From a user point of view, option A looks better to me. However, it has > two > drawbacks: > > - Through deciding what pin groups we make available we create a DT ABI > that will make it difficult to fix mistakes in case the

Re: [PATCH 0/3] Renesas RZ PFC and GPIO driver

Hi Chris, On Monday 09 Jan 2017 23:53:39 Chris Brandt wrote: > On Monday, January 09, 2017, Laurent Pinchart wrote: > > Both the existing RZ/A model and the pinctrl model are in my opinion > > improvements over the RZ/G and R-Car models. I don't care much about > > whether pinctrl-single can be

Re: [PATCH] clk: vc5: Add support for IDT VersaClock 5P49V5923B

On 01/10, Marek Vasut wrote: > On 01/10/2017 01:23 AM, Stephen Boyd wrote: > > On 01/05, Marek Vasut wrote: > >> On 01/05/2017 03:13 PM, Laurent Pinchart wrote: > >>> Hi Marek, > >> > >> Hi! > >> > >> [...] > >> > >>> +static unsigned long vc5_mux_recalc_rate(struct clk_hw *hw, > >>> +

Re: [PATCH] clk: vc5: Add support for IDT VersaClock 5P49V5923B

On 01/10/2017 01:23 AM, Stephen Boyd wrote: > On 01/05, Marek Vasut wrote: >> On 01/05/2017 03:13 PM, Laurent Pinchart wrote: >>> Hi Marek, >> >> Hi! >> >> [...] >> >>> +static unsigned long vc5_mux_recalc_rate(struct clk_hw *hw, >>> +unsigned long

Re: [PATCH] clk: vc5: Add support for IDT VersaClock 5P49V5923B

On 01/05, Marek Vasut wrote: > On 01/05/2017 03:13 PM, Laurent Pinchart wrote: > > Hi Marek, > > Hi! > > [...] > > > +static unsigned long vc5_mux_recalc_rate(struct clk_hw *hw, > > +unsigned long parent_rate) > > +{ > > + struct

Re: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

Hello Hans, On Monday 09 Jan 2017 14:36:55 Hans Verkuil wrote: > On 01/03/2017 04:20 PM, Ramesh Shanmugasundaram wrote: > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote: > Add binding documentation for Renesas R-Car Digital Radio Interface > (DRIF) controller. >

Re: [PATCH 0/3] Renesas RZ PFC and GPIO driver

Hi Chris, On Monday 09 Jan 2017 21:08:49 Chris Brandt wrote: > On Monday, January 09, 2017, Laurent Pinchart wrote: > > Pin control on the Renesas RZ chips is performed per pin instead of per > > function (but unfortunately with the various bits of configuration split > > across a bunch of

Re: [PATCHv3 0/6] sh_eth: add wake-on-lan support via magic packet

From: Sergei Shtylyov Date: Tue, 10 Jan 2017 00:48:28 +0300 > On 01/09/2017 11:55 PM, David Miller wrote: > >>> This series adds support for Wake-on-Lan using Magic Packet for a few >>> models of the sh_eth driver. Patch 1/6 fix a naming error, patch 2/6 >>>

Re: [PATCHv3 0/6] sh_eth: add wake-on-lan support via magic packet

On 01/09/2017 11:55 PM, David Miller wrote: This series adds support for Wake-on-Lan using Magic Packet for a few models of the sh_eth driver. Patch 1/6 fix a naming error, patch 2/6 adds generic support to control and support WoL while patches 3/6 - 6/6 enable different models. Based ontop of

RE: [PATCH 0/3] Renesas RZ PFC and GPIO driver

On Monday, January 09, 2017, Laurent Pinchart wrote: > Pin control on the Renesas RZ chips is performed per pin instead of per > function (but unfortunately with the various bits of configuration split > across a bunch of registers, otherwise we could have used pinctrl-single). I will say

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Mon, Jan 09, 2017 at 11:34:55PM +0300, Nikita Yushchenko wrote: > I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC > but in block layer, in particular it should be controlled by > blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it > is something

Re: [PATCHv3 0/6] sh_eth: add wake-on-lan support via magic packet

From: Niklas Söderlund Date: Mon, 9 Jan 2017 16:34:03 +0100 > This series adds support for Wake-on-Lan using Magic Packet for a few > models of the sh_eth driver. Patch 1/6 fix a naming error, patch 2/6 > adds generic support to control and support WoL

Re: [PATCH 0/2] sh_eth: "intgelligent checksum" related cleanups

From: Sergei Shtylyov Date: Sat, 07 Jan 2017 00:01:40 +0300 >Here's a set of 2 patches against DaveM's 'net.git' repo, as they are based > on a couple patches merged there recently; however, the patches are destined > for 'net-next.git' (once 'net.git'

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

[CCing NVMe maintainers since we are discussion issues in that driver] >> With my patch applied and thus 32bit dma_mask set for NVMe device, I do >> see high addresses passed to dma_map_*() routines and handled by >> swiotlb. Thus your statement that behavior "succeed 64bit dma_set_mask() >>

Re: [PATCH 0/3] Renesas RZ PFC and GPIO driver

Hi Jacopo, On Monday 09 Jan 2017 20:31:55 Jacopo Mondi wrote: > Hello, >these patches are the result of a squash and forward porting of Magnus' > PFC and GPIO driver from > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git tree > genmai-gpio-and-pfc branch to kernel

[PATCH 2/3] pinctrl: sh-pfc: r7s72100: IO mode selection

In r7s72100 SoC a pin can be configured in 3 different modes: * DIO: direct IO * SWI: software input mode * SWO: software output mode The r7s72100 pincontrol driver defaulted all modes to software input (PIPC = 0, PIBC = 1, PBDC = 1). This was wrong for most pins, which requires their pins

[PATCH 0/3] pinctrl: sh-pfc: r7s72100: Add IO mode selection

Hello, sending this RFC series out as a follow up of "[PATCH 0/3] Renesas RZ PFC and GPIO driver" patch series. This RFC patches extend the RZ series PFC driver to support selection of pins IO mode. [1/3] extends the existing register settings to set all configured peripherals groups in

[PATCH 1/3] pinctrl: sh-pfc: r7s72100: Enable DIO mode

When selecting alternative function for one pin, set the PIPCn.PIPCnm bit to 1 to enable direct IO mode control (the alternative function decides the pin direction) and disable input buffer and bidirection control functionalities (PIBCn.PIBCnm = 0 and PBDCn.PDBCnm = 0) intially enabled when

[PATCH 3/3] pinctrl: sh-pfc: r7s72100: Add LVDS pin group

The LVDS pin group has to be configured in software driven output mode Signed-off-by: Jacopo Mondi --- drivers/pinctrl/sh-pfc/pfc-r7s72100.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/pinctrl/sh-pfc/pfc-r7s72100.c

[PATCH 3/3] arm: dts: r7s72100: Add peripherals nodes

From: Magnus Damm This is a squash of several commits, adding peripherals groups configuration to r7s72100 device tree, and enabling some of them on Genmai evaluation board Signed-off-by: Jacopo Mondi

[PATCH 2/3] gpio: gpio-rz: GPIO driver for Renesas RZ series

From: Magnus Damm This commit combines Magnus' original driver and minor fixes to forward-port it to a more recent kernel version (v4.10) Signed-off-by: Jacopo Mondi --- gpio: Renesas RZ

[PATCH 0/3] Renesas RZ PFC and GPIO driver

Hello, these patches are the result of a squash and forward porting of Magnus' PFC and GPIO driver from git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git tree genmai-gpio-and-pfc branch to kernel v4.10 The PFC and GPIO driver have been forward ported to v4.10-rc1 with

[PATCH 1/3] pinctrl: sh-pfc: Add r7s72100 PFC driver

From: Magnus Damm Squash commits in Geert's renesas-driver/genmai-gpio-and-pfc branch that add support for r7s72100 PFC. This squash combines commits for Magnus' original driver and minor fixes to forward-port it to a more recent kernel (v4.10) Signed-off-by: Jacopo Mondi

RE: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

Hi Hans, Thanks for the review. > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote: > Add binding documentation for Renesas R-Car Digital Radio Interface > (DRIF) controller. > > Signed-off-by: Ramesh Shanmugasundaram >

Possible issue?

Noticed (only once so far) the below issue on renesas-drivers-2016-12-27-v4.10-rc1 with lockdep enabled. Anybody else seen it? [2.520105] [2.521598] == [2.527771] [ INFO: possible circular locking dependency detected ] [

Re: [PATCHv9 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers

Hi Laurent, On 2017-01-02 01:08:04 +0200, Laurent Pinchart wrote: > Hi Niklas, > > On Monday 05 Sep 2016 12:52:44 Laurent Pinchart wrote: > > On Wednesday 10 Aug 2016 13:22:19 Niklas Söderlund wrote: > > > Enable slave transfers to a device behind a IPMMU by mapping the slave > > > addresses

[PATCHv3 2/6] sh_eth: add generic wake-on-lan support via magic packet

Add generic functionality to support Wake-on-LAN using MagicPacket which are supported by at least a few versions of sh_eth. Only add functionality for WoL, no specific sh_eth versions are marked to support WoL yet. WoL is enabled in the suspend callback by setting MagicPacket detection and

[PATCHv3 3/6] sh_eth: enable wake-on-lan for R-Car Gen2 devices

Tested on Gen2 r8a7791/Koelsch. Signed-off-by: Niklas Söderlund Tested-by: Geert Uytterhoeven --- drivers/net/ethernet/renesas/sh_eth.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCHv3 4/6] sh_eth: enable wake-on-lan for r8a7740/armadillo

Geert Uytterhoeven reported WoL worked on his Armadillo board. Signed-off-by: Niklas Söderlund Tested-by: Geert Uytterhoeven --- drivers/net/ethernet/renesas/sh_eth.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCHv3 1/6] sh_eth: use correct name for ECMR_MPDE bit

This bit was wrongly named due to a typo, Sergei checked the SH7734/63 manuals and this bit should be named MPDE. Suggested-by: Sergei Shtylyov Signed-off-by: Niklas Söderlund --- drivers/net/ethernet/renesas/sh_eth.h |

[PATCHv3 6/6] sh_eth: enable wake-on-lan for sh7763

This is based on public datasheet for sh7763 which shows it has the same behavior and registers for WoL as other versions of sh_eth. Signed-off-by: Niklas Söderlund --- drivers/net/ethernet/renesas/sh_eth.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCHv3 0/6] sh_eth: add wake-on-lan support via magic packet

Hi, This series adds support for Wake-on-Lan using Magic Packet for a few models of the sh_eth driver. Patch 1/6 fix a naming error, patch 2/6 adds generic support to control and support WoL while patches 3/6 - 6/6 enable different models. Based ontop of net-next master. Changes since v2. -

[PATCHv3 5/6] sh_eth: enable wake-on-lan for sh7734

This is based on public datasheet for sh7734 which shows it has the same behavior and registers for WoL as other versions of sh_eth. Signed-off-by: Niklas Söderlund --- drivers/net/ethernet/renesas/sh_eth.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Friday, January 6, 2017 4:47:59 PM CET Nikita Yushchenko wrote: > >>> Just a guess, but if the inbound translation windows in the host > >>> bridge are wider than 32-bit, the reason for setting up a single > >>> 32-bit window is probably because that is what the parent bus supports. > > I've

Re: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

On 01/03/2017 04:20 PM, Ramesh Shanmugasundaram wrote: > Hi Laurent, Geert, > > Thanks for the review comments. > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote: Add binding documentation for Renesas R-Car Digital Radio Interface (DRIF) controller.

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

Hi Geert, On Monday 09 Jan 2017 10:53:55 Geert Uytterhoeven wrote: > On Fri, Jan 6, 2017 at 1:30 PM, Laurent Pinchart wrote: > > On Friday 02 Dec 2016 13:35:10 Geert Uytterhoeven wrote: > >> If a UART has dedicated RTS/CTS pins, there are some issues: > >> 1. When changing hardware control flow,

Re: [PATCH 08/16] arm64: dts: r8a7795: add sound MIX support

On Fri, Jan 6, 2017 at 12:17 PM, Simon Horman wrote: > From: Kuninori Morimoto > > This patch adds MIX (= Mixer) support. > > Signed-off-by: Kuninori Morimoto > Signed-off-by: Simon Horman

Re: [PATCH 07/16] arm64: dts: r8a7795: add sound CTU support

On Fri, Jan 6, 2017 at 12:17 PM, Simon Horman wrote: > From: Kuninori Morimoto > > This patch adds CTU (= Channel Transfer Unit) support which is needed > to sound mixing. > > Signed-off-by: Kuninori Morimoto

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

Hi Laurent, On Fri, Jan 6, 2017 at 1:30 PM, Laurent Pinchart wrote: > On Friday 02 Dec 2016 13:35:10 Geert Uytterhoeven wrote: >> If a UART has dedicated RTS/CTS pins, there are some issues: >> 1. When changing hardware control flow, the new AUTORTS state is

Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C

On 2017-01-04 11:25:50 +0100, Wolfram Sang wrote: > Bump... > > > Yes, this is a bug in the rcar-vin driver which is addressed in the Gen3 > > patches. However I'm not sure those patches will make it to v4.10, not > > much review from the V4L2 side yet (Geert and Sergei have had a few > >