Isn't gen3 peripheral bus 32-bit?

Hi R-Car GEN3 PCIe modules have 32-bit connect to internal AXI bus. Could please somebody with lowlevel hardware knowledge answer, if this is PCIe module limitation, or internal bus limitation. Depending on that, different modification of renesas/r8a779[56].dtsi files is needed: either - wrap

Re: [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings

Hi Chris, On Thu, Jan 12, 2017 at 5:14 AM, Chris Brandt wrote: > Signed-off-by: Chris Brandt > > --- > v3: > * added list of how many interrupts each SOC has > v2: > * added interrupt description Thanks or the update! Reviewed-by: Geert

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

12.01.2017 08:52, Nikita Yushchenko wrote: >>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> index 5ac373c..480b644 100644 >>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> @@ -540,7

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> index 5ac373c..480b644 100644 >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc

Re: [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports

>> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 >> dma_base, u64 size, >> if (!dev->archdata.dma_ops) >> dev->archdata.dma_ops = _dma_ops; >> >> + /* >> +* Whatever the parent bus can set. A device must not set >> +* a DMA

[PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings

Signed-off-by: Chris Brandt --- v3: * added list of how many interrupts each SOC has v2: * added interrupt description --- Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 8 1 file changed, 8 insertions(+) diff --git

Re: [PATCH v2] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks

On 01/12/2017 02:51 AM, Laurent Pinchart wrote: > The clocks are generated by an I2C-controlled programmable clock > generator. > > Signed-off-by: Laurent Pinchart Reviewed-by: Marek Vasut > --- >

[PATCH v2] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks

The clocks are generated by an I2C-controlled programmable clock generator. Signed-off-by: Laurent Pinchart --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) This patch

Re: [PATCH] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks

Hi Marek, On Thursday 12 Jan 2017 01:57:09 Marek Vasut wrote: > On 01/12/2017 01:53 AM, Laurent Pinchart wrote: > > The clocks are generated by an I2C-controlled programmable clock > > generator. > > > > Signed-off-by: Laurent Pinchart > > > > --- > >

Re: [PATCH V6 2/2] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

Hi Marek, Thank you for the patch. On Thursday 12 Jan 2017 02:03:24 Marek Vasut wrote: > Add driver for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These > chips have two clock inputs, XTAL or CLK, which are muxed into single > PLL/VCO input. In case of 5P49V5923, the XTAL in built into the

Re: [PATCH V2 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933

Hi Marek, Thank you for the patch. On Thursday 12 Jan 2017 02:03:23 Marek Vasut wrote: > Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. > These are I2C clock generators with optional clock source from > either XTal or dedicated clock generator and, depending on the > model, two

Re: [PATCH] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks

On 01/12/2017 01:53 AM, Laurent Pinchart wrote: > The clocks are generated by an I2C-controlled programmable clock > generator. > > Signed-off-by: Laurent Pinchart > --- > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 29 >

[PATCH V6 2/2] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

Add driver for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These chips have two clock inputs, XTAL or CLK, which are muxed into single PLL/VCO input. In case of 5P49V5923, the XTAL in built into the chip while the 5P49V5923 requires external XTAL. The PLL feeds two fractional dividers. Each

[PATCH V2 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933

Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These are I2C clock generators with optional clock source from either XTal or dedicated clock generator and, depending on the model, two or more clock outputs. Signed-off-by: Marek Vasut Cc: Michael Turquette

[PATCH] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks

The clocks are generated by an I2C-controlled programmable clock generator. Signed-off-by: Laurent Pinchart --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 29 -- 1 file changed, 27 insertions(+), 2 deletions(-) Hi Marek,

Re: [PATCH v2 06/13] drm: panels: Add LVDS panel driver

Hi Thierry, Ping ? On Tuesday 22 Nov 2016 15:17:09 Laurent Pinchart wrote: > On Tuesday 22 Nov 2016 12:14:57 Thierry Reding wrote: > > On Sat, Nov 19, 2016 at 05:28:06AM +0200, Laurent Pinchart wrote: > >> This driver supports LVDS panels that don't require device-specific > >> handling of power

Re: [PATCH V4] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

On 01/11/2017 05:42 PM, Laurent Pinchart wrote: > Hi Marek, Hi! > On Wednesday 11 Jan 2017 16:53:53 Marek Vasut wrote: >> On 01/11/2017 04:41 PM, Laurent Pinchart wrote: >>> On Wednesday 11 Jan 2017 15:37:11 Marek Vasut wrote: On 01/10/2017 07:50 PM, Marek Vasut wrote: > Add driver for

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

On Wednesday, January 11, 2017 9:31:51 PM CET Nikita Yushchenko wrote: > diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c > index 9afcbf7..0995ab3 100644 > --- a/drivers/iommu/rockchip-iommu.c > +++ b/drivers/iommu/rockchip-iommu.c > @@ -1096,7 +1096,7 @@ static int

Re: [PATCH 00/19] sh-sci: Platform data simplification

On Wed, Jan 11, 2017 at 01:06:04PM +0200, Laurent Pinchart wrote: > Hi Greg, > > On Wednesday 11 Jan 2017 11:43:30 Greg KH wrote: > > On Wed, Jan 11, 2017 at 11:38:15AM +0100, Geert Uytterhoeven wrote: > > > On Wed, Jan 11, 2017 at 9:04 AM, Greg KH wrote: > > >> On Wed, Jan 04,

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

Hi Jacopo and Laurent, On Wednesday, January 11, 2017, jacopo mondi wrote: > A big difference from what pinctrl-single does and what the table-based > approach does is that it creates groups, pins and functions at run-time, > parsing the dts... See, this makes me think that this will chew up

Re: [PATCH v2 pci/next] PCI: rcar: Add compatible string for r8a7796

On Wed, Dec 21, 2016 at 03:37:06AM +0900, Yoshihiro Kaneko wrote: > From: Harunobu Kurokawa > > This patch adds support for r8a7796. > > Signed-off-by: Harunobu Kurokawa > Signed-off-by: Yoshihiro Kaneko

Re: [PATCH pci/next] PCI: rcar: return ENODEV code when PCIe card does not insert

On Fri, Dec 16, 2016 at 12:50:04PM +0100, Simon Horman wrote: > From: Harunobu Kurokawa > > R-Car PCIe does not support hotplug so it is appropriate to > treat the absence of a PCIe card as an ENODEV error. > > Signed-off-by: Harunobu Kurokawa

[PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

There are cases when device is capable of wide DMA mask (and driver issues corresponding dma_set_mask() call), but bus device sits on can't support wide address. Example: NVMe device behind PCIe controller sitting on 32-bit SoC bus. To support such case, architecture needs information about such

[PATCH 0/2] arm64: fix handling of DMA masks wider than bus supports

> I reckon the easiest way forward would be to pass in some flag to > arch_setup_dma_ops to indicate whether it's an explicitly-configured > range or not - then simply initialising parent_dma_mask to ~0 for the > default case *should* keep things working as before. Tried to do that. --- Nikita

[PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports

There are cases when device supports wide DMA addresses wider than device's connection supports. In this case driver sets DMA mask based on knowledge of device capabilities. That must succeed to allow drivers to initialize. However, swiotlb or iommu still need knowledge about actual device

Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs

* Tony Lindgren [170111 08:29]: > * Linus Walleij [170111 07:34]: > > On Tue, Jan 10, 2017 at 8:19 PM, Tony Lindgren wrote: > > > > > Below is an experimental fix to intorduce pinctrl_start() that I've > > > tested with

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On 11/01/17 12:37, Nikita Yushchenko wrote: >> I actually have a third variation of this problem involving a PCI root >> complex which *could* drive full-width (40-bit) addresses, but won't, >> due to the way its PCI<->AXI interface is programmed. That would require >> even more complicated

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

Hi Laurent, On 11/01/2017 17:31, Laurent Pinchart wrote: Hi Jacopo, [snip] I was wondering if that should not be be turned into something more similar to the pinctrl-single defined ABI. In that case it would look like this (please excuse the pseduo-dts syntax here) scif2_pins:

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

> I also have a koelsch, so no need to take one on a plane ;-) I thought yours was so heavily hooked up that it was a bit cumbersome to bring it somewhere. Happy to be wrong here :) signature.asc Description: PGP signature

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

On 11/01/17 16:03, Nikita Yushchenko wrote: > > > 11.01.2017 17:50, Robin Murphy пишет: >> On 11/01/17 13:41, Nikita Yushchenko wrote: Yes, I think that ought to work, although the __iommu_setup_dma_ops() call will still want a real size reflecting the default mask >>> >>> I see

Re: [PATCH V4] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

Hi Marek, On Wednesday 11 Jan 2017 16:53:53 Marek Vasut wrote: > On 01/11/2017 04:41 PM, Laurent Pinchart wrote: > > On Wednesday 11 Jan 2017 15:37:11 Marek Vasut wrote: > >> On 01/10/2017 07:50 PM, Marek Vasut wrote: > >>> Add driver for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These >

Re: [PATCH 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933

Hi Marek, Thank you for the patch. On Wednesday 11 Jan 2017 17:16:02 Marek Vasut wrote: > Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. > These are I2C clock generators with optional clock source from > either XTal or dedicated clock generator and, depending on the > model,

Re: [PATCH V4] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

On 01/11/2017 04:41 PM, Laurent Pinchart wrote: > Hi Marek, Hi! > Thank you for the patch. > > On Wednesday 11 Jan 2017 15:37:11 Marek Vasut wrote: >> On 01/10/2017 07:50 PM, Marek Vasut wrote: >>> Add driver for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These >>> chips have two clock

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

Hi Jacopo, On Wednesday 11 Jan 2017 16:15:30 jacopo mondi wrote: > On 11/01/2017 12:22, Laurent Pinchart wrote: > > Hi Jacopo, > > [snip] > > Here is my general question: Which of these 2 approaches are better? > > A) In the DT, the user ask "enable Ethernet please" and magic

Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs

* Linus Walleij [170111 07:34]: > On Tue, Jan 10, 2017 at 8:19 PM, Tony Lindgren wrote: > > > Below is an experimental fix to intorduce pinctrl_start() that I've > > tested with pinctrl-single. Then we should probably make all pin controller > >

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On Wednesday, January 11, 2017 3:37:22 PM CET Nikita Yushchenko wrote: > > I actually have a third variation of this problem involving a PCI root > > complex which *could* drive full-width (40-bit) addresses, but won't, > > due to the way its PCI<->AXI interface is programmed. That would require >

[PATCH V5 2/2] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

Add driver for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These chips have two clock inputs, XTAL or CLK, which are muxed into single PLL/VCO input. In case of 5P49V5923, the XTAL in built into the chip while the 5P49V5923 requires external XTAL. The PLL feeds two fractional dividers. Each

[PATCH 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933

Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These are I2C clock generators with optional clock source from either XTal or dedicated clock generator and, depending on the model, two or more clock outputs. Signed-off-by: Marek Vasut Cc: Michael Turquette

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

On Wed, Jan 11, 2017 at 4:57 PM, Niklas Söderlund wrote: > On 2017-01-11 16:05:21 +0100, Wolfram Sang wrote: >> I wanted to do some TDSEL testing on other Gen2 boards in Brussels, >> provided that people could bring some. So, if you could bring that >> Koelsch

Re: [PATCH v2 4/7] arm: dts: r7s72100-genmai: SCIF2 PINCTRL configuration

Hi Jacopo, On Wed, Jan 11, 2017 at 10:57 AM, Jacopo Mondi wrote: > From: Magnus Damm > > Configure the r7s72100 PINCTRL hardware and select pin function > for the SCIF2 serial console. > > Signed-off-by: Magnus Damm > Acked-by:

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

Hi Wolfram, On 2017-01-11 16:05:21 +0100, Wolfram Sang wrote: > Hi Niklas, > > > I'm doing my tests on Koelsch so I'm afraid setting the TDSEL in > > pfc-r8a7795.c won't do much ;-) Nevertheless I tried to mimic the patch > > for Koelsch but found the documentation lacking and where unable to

Re: [PATCH v2 2/7] gpio: gpio-rz: GPIO driver for Renesas RZ series

On Wed, Jan 11, 2017 at 10:57 AM, Jacopo Mondi wrote: > 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

Re: [PATCH V4] iio: adc: Add Renesas GyroADC driver

On 01/11/2017 03:41 PM, Geert Uytterhoeven wrote: > Hi Marek, > > On Wed, Jan 11, 2017 at 3:32 PM, Marek Vasut wrote: >> On 01/11/2017 02:11 PM, Geert Uytterhoeven wrote: >>> On Wed, Jan 11, 2017 at 1:35 PM, Marek Vasut wrote: >> +Required

Re: [PATCH V4] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

Hi Marek, Thank you for the patch. On Wednesday 11 Jan 2017 15:37:11 Marek Vasut wrote: > On 01/10/2017 07:50 PM, Marek Vasut wrote: > > Add driver for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These > > chips have two clock inputs, XTAL or CLK, which are muxed into single > > PLL/VCO

Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs

On Tue, Jan 10, 2017 at 8:19 PM, Tony Lindgren wrote: > Below is an experimental fix to intorduce pinctrl_start() that I've > tested with pinctrl-single. Then we should probably make all pin controller > drivers call pinctrl_start() to properly fix the issue of struct

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

Hi Laurent, On 11/01/2017 12:22, Laurent Pinchart wrote: Hi Jacopo, [snip] Here is my general question: Which of these 2 approaches are better? A) In the DT, the user ask "enable Ethernet please" and magic happens in the pfc driver. B) In the DT, the user looks up the correct

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

Hi Niklas, > I'm doing my tests on Koelsch so I'm afraid setting the TDSEL in > pfc-r8a7795.c won't do much ;-) Nevertheless I tried to mimic the patch > for Koelsch but found the documentation lacking and where unable to do > so. That is I found a TDSEL register but no documentation of its >

[PATCH v2 13/18] serial: sh-sci: Constify platform data

The driver modifies platform data for internal purpose only. Fix that and make the platform data structure const. Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven --- drivers/tty/serial/sh-sci.c | 97

[PATCH v2 02/18] serial: sh-sci: Don't rely on platform data flags when not needed

The UPF_BOOT_AUTOCONF platform data flag is set by all platforms, hardcode it. The UPF_IOREMAP flag is set by a single SH platform and thus needs to be kept. However, for ARM platforms, we can base the decision on whether an OF node is present and bypass the platform data flags completely.

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

On 11/01/17 13:41, Nikita Yushchenko wrote: >> Yes, I think that ought to work, although the __iommu_setup_dma_ops() >> call will still want a real size reflecting the default mask > > I see iommu_dma_ops do not define set_dma_mask. > > So what if setup was done for size reflecting one mask and

Re: [PATCH] dmaengine: rcar-dmac: unmap slave resource when channel is freed

Hi Niklas, Thank you for the patch. On Wednesday 11 Jan 2017 15:39:31 Niklas Söderlund wrote: > The slave mapping should be removed together with other channel > resources when the channel is freed. If it's not unmapped it will hang > around forever after the channel is freed. > > Fixes:

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

On Mon, Jan 9, 2017 at 8:31 PM, Jacopo Mondi wrote: > 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

[PATCH v2 17/18] serial: sh-sci: Remove unused platform data capabilities field

The field isn't set by any platform but is only used internally in the driver to hold data parsed from DT. Move it to the sci_port structure. Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven ---

[PATCH v2 12/18] serial: sh-sci: Replace regmap array with port parameters

Turn the regmap two-dimensional array to an array of port parameters and store a pointer to the port parameters in the sci_port structure. This will allow handling additional port type dependent parameters. Signed-off-by: Laurent Pinchart Reviewed-by:

[PATCH v2 11/18] serial: sh-sci: Remove initialization of zero fields in sci_port_params

The compiler zeros uninitialized fields, don't zero them manually. Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven --- drivers/tty/serial/sh-sci.c | 94 - 1 file

[PATCH v2 18/18] serial: sh-sci: Compute the regshift value for SCI ports

SCI instances found in SH SoCs have different spacing between registers depending on the SoC. The platform data contains a regshift field that tells the driver by how many bits to shift the register offset to compute its address. We can compute the regshift value automatically based on the memory

[PATCH v2 04/18] sh: Don't set sh-sci pdata scscr TIE and RIE bits

The scscr platform data field is used by the driver in three locations. One of them masks out all bits except SCSCR_REIE. The two other are the set_termios handler and the console write handler. The set_termios handler calls sci_start_rx() to enable the receiver, which sets the RIE bit

[PATCH v2 05/18] sh: sh726[49]: Don't set sh-sci pdata scscr TOIE bit

The SCIF ports on sh7264 and sh7269 don't support the TOIE bit according to the datasheets. Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven --- arch/sh/kernel/cpu/sh2a/setup-sh7264.c | 16

[PATCH v2 06/18] sh: Don't set the sh-sci pdata UPF_BOOT_AUTOCONF flags

The flag is set by the driver internally, don't set it in platform data. Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven --- arch/sh/kernel/cpu/sh2/setup-sh7619.c | 3 --- arch/sh/kernel/cpu/sh2a/setup-mxg.c

[PATCH v2 08/18] sh: Don't set the sh-sci platform data scscr CKE0 bit

The bit is only set by platforms that also set the CKE1 but, in which case its value is ignored by the device. Don't set it, this simplifies platform data and only leaves the CKE1 bit to be handled. Signed-off-by: Laurent Pinchart Reviewed-by: Geert

[PATCH v2 16/18] serial: sh-sci: Remove manual break debouncing

The sh-sci driver implements manual break debouncing for a few SH platforms by reading the value of the RX pin port register. This feature is optional and the driver considers all negative or zero values of the platform data port_reg field as invalid. As the four platforms that set the field to a

[PATCH v2 07/18] sh: Don't set sh-sci port_reg

The driver considers all negative or zero values of the port_reg field as invalid. The four platforms that set the field to a register address all use an address higher than 0x7fff, which is thus considered by the driver as invalid. The feature is thus never used, remove it. The feature could

[PATCH v2 03/18] sh: Don't set sh-sci pdata scscr TE and RE bits

The bits are set by the driver internally, don't set them in platform data. Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven --- arch/sh/kernel/cpu/sh2/setup-sh7619.c | 6 +++---

[PATCH v2 14/18] serial: sh-sci: Extend sci_port_params with more port parameters

The fifo size, overrun register and mask, sampling rate mask and error mask all depend on the port type only and don't need to be computed at runtime. Add them to the sci_port_parameters structure. Signed-off-by: Laurent Pinchart Reviewed-by: Geert

[PATCH v2 00/18] sh-sci: Platform data simplification

Hello, This is the second version of the sh-sci platform data simplification patch series, now with all acks collected and ready to be merged. Greg, could you take the whole series through your tree ? The arch/sh/ patches should not cause any conflict as they only touch legacy platforms that have

[PATCH v2 10/18] serial: sh-sci: Fix register offsets for the IRDA serial port

Even though most of its registers are 8-bit wide, the IRDA has two 16-bit registers that make it a 16-bit peripheral and not a 8-bit peripheral with addresses shifted by one. Fix the registers offset in the driver and the platform data regshift value. Signed-off-by: Laurent Pinchart

[PATCH v2 09/18] sh: Don't set the sh-sci platform data REIE bit when not implemented

According to the datasheets, the sh7760 SIM and sh7723 SCIFA instances don't implement the REIE bit. Don't set it in platform data. Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven ---

[PATCH v2 15/18] serial: sh-sci: Remove the platform data dma slave rx/tx channel IDs

Only SH platforms still use platform data for the sh-sci, and none of them declare DMA channels connected to the SCI. Remove the corresponding platform data fields and simplify the driver accordingly. Signed-off-by: Laurent Pinchart Reviewed-by: Geert

[PATCH v2 01/18] serial: sh-sci: Set the SCSCR TE and RE bits in the driver

The Transmit Enable and Receive Enable bits are set in the scscr field of all instances of the sh-sci platform data. Set them in the driver directly to prepare for their removal from platform data. Signed-off-by: Laurent Pinchart Reviewed-by: Geert

Re: [PATCH V4] iio: adc: Add Renesas GyroADC driver

Hi Marek, On Wed, Jan 11, 2017 at 3:32 PM, Marek Vasut wrote: > On 01/11/2017 02:11 PM, Geert Uytterhoeven wrote: >> On Wed, Jan 11, 2017 at 1:35 PM, Marek Vasut wrote: > +Required properties for subnodes: > +- compatible: Should be either

[PATCH] dmaengine: rcar-dmac: unmap slave resource when channel is freed

The slave mapping should be removed together with other channel resources when the channel is freed. If it's not unmapped it will hang around forever after the channel is freed. Fixes: 9f878603dbdb7db3 ("dmaengine: rcar-dmac: add iommu support for slave transfers") Reported-by: Laurent Pinchart

Re: [PATCH V4] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

On 01/10/2017 07:50 PM, Marek Vasut wrote: > Add driver for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These > chips have two clock inputs, XTAL or CLK, which are muxed into single > PLL/VCO input. In case of 5P49V5923, the XTAL in built into the chip > while the 5P49V5923 requires external

Re: [PATCH] arm64: Add support for DMA_ATTR_SKIP_CPU_SYNC attribute to swiotlb

On 11/01/17 10:11, Geert Uytterhoeven wrote: > From: Takeshi Kihara > > This patch adds support for DMA_ATTR_SKIP_CPU_SYNC attribute for > dma_{un}map_{page,sg} functions family to swiotlb. > > DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

> Yes, I think that ought to work, although the __iommu_setup_dma_ops() > call will still want a real size reflecting the default mask I see iommu_dma_ops do not define set_dma_mask. So what if setup was done for size reflecting one mask and then driver changes mask? Will things still operate

Re: [PATCH V4] iio: adc: Add Renesas GyroADC driver

Hi Marek, On Wed, Jan 11, 2017 at 1:35 PM, Marek Vasut wrote: >>> +Required properties for subnodes: >>> +- compatible: Should be either of: >>> + "fujitsu,mb88101a" >>> + - Fujitsu MB88101A compatible mode, >>> +

Re: [PATCH V4] iio: adc: Add Renesas GyroADC driver

On 01/11/2017 09:38 AM, Geert Uytterhoeven wrote: > Hi Marek, Hi, > Please CC linux-renesas-soc for drivers for (parts of) Renesas ARM SoCs. I just registered and will CC from now on. > On Tue, Jan 10, 2017 at 10:33 PM, Marek Vasut wrote: >> Add IIO driver for the

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

> I actually have a third variation of this problem involving a PCI root > complex which *could* drive full-width (40-bit) addresses, but won't, > due to the way its PCI<->AXI interface is programmed. That would require > even more complicated dma-ranges handling to describe the windows of > valid

Re: [PATCH v1.1 19/19] serial: sh-sci: Compute the regshift value for SCI ports

Hi Laurent, On Fri, Jan 6, 2017 at 1:21 PM, Laurent Pinchart wrote: > SCI instances found in SH SoCs have different spacing between registers > depending on the SoC. The platform data contains a regshift field that > tells the driver by how many bits to

Re: [PATCH v1.1 08/19] serial: sh-sci: Fix register offsets for the IRDA serial port

Hi Laurent, On Fri, Jan 6, 2017 at 12:52 PM, Laurent Pinchart wrote: > Even though most of its registers are 8-bit wide, the IRDA has two > 16-bit registers that make it a 16-bit peripheral and not a 8-bit > peripheral with addresses shifted by one. Fix

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

On 11/01/17 07:59, Nikita Yushchenko wrote: >>> + /* >>> +* we don't yet support buses that have a non-zero mapping. >>> +* Let's hope we won't need it >>> +*/ >>> + WARN_ON(dma_base != 0); >> >> I believe we now accomodate the bus remap bits on BCM2837 as a DMA >> offset, so

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

Hi Jacopo, On Tuesday 10 Jan 2017 23:32:27 jacopo mondi wrote: > On 10/01/2017 02:28, Laurent Pinchart wrote: > > 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

Re: [PATCH 00/19] sh-sci: Platform data simplification

Hi Greg, On Wednesday 11 Jan 2017 11:43:30 Greg KH wrote: > On Wed, Jan 11, 2017 at 11:38:15AM +0100, Geert Uytterhoeven wrote: > > On Wed, Jan 11, 2017 at 9:04 AM, Greg KH wrote: > >> On Wed, Jan 04, 2017 at 01:06:20AM +0200, Laurent Pinchart wrote: > >>> Most of the patches in

Re: [PATCH 00/19] sh-sci: Platform data simplification

Hi Greg, On Wednesday 11 Jan 2017 09:04:37 Greg KH wrote: > On Wed, Jan 04, 2017 at 01:06:20AM +0200, Laurent Pinchart wrote: > > Hello, > > > > Most of the patches in this series have been sitting in my development > > tree for three years now. While rebasing all my development branches I > >

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

On Wed, Jan 11, 2017 at 12:55:23PM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Wednesday 11 Jan 2017 11:33:17 Simon Horman wrote: > > On Tue, Jan 10, 2017 at 09:58:19PM +0200, Laurent Pinchart wrote: > > > On Tuesday 10 Jan 2017 16:07:01 Geert Uytterhoeven wrote: > > >> On Mon, Jan 9, 2017

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

Hi Jacopo, Thank you for the patch. On Monday 09 Jan 2017 20:31:58 Jacopo Mondi wrote: > 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 > >

Re: [PATCH 00/19] sh-sci: Platform data simplification

Hi Greg, On Wed, Jan 11, 2017 at 9:04 AM, Greg KH wrote: > On Wed, Jan 04, 2017 at 01:06:20AM +0200, Laurent Pinchart wrote: >> Most of the patches in this series have been sitting in my development tree >> for three years now. While rebasing all my development branches I decided

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

On Wed, Jan 11, 2017 at 12:46:31AM +, Chris Brandt wrote: > Hi Jacopo, > > On Tuesday, January 10, 2017, Jacopo Mondi wrote: > > So, I guess what direction to take depends on whether or not we're going > > to see more hardware with a per-pin configuration that would benefit from > > this new

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

On Tue, Jan 10, 2017 at 09:58:19PM +0200, Laurent Pinchart wrote: > Hi Geert, > > On Tuesday 10 Jan 2017 16:07:01 Geert Uytterhoeven wrote: > > On Mon, Jan 9, 2017 at 8:31 PM, Jacopo Mondi wrote: > > > From: Magnus Damm > > > > > > This is a squash of several commits, adding

[PATCH] arm64: Add support for DMA_ATTR_SKIP_CPU_SYNC attribute to swiotlb

From: Takeshi Kihara This patch adds support for DMA_ATTR_SKIP_CPU_SYNC attribute for dma_{un}map_{page,sg} functions family to swiotlb. DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of the CPU cache for the given buffer assuming that it has

[PATCH v2 1/7] 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

[PATCH v2 2/7] 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 v2 3/7] arm: dts: r7s72100: GPIO and PFC device nodes

From: Magnus Damm Add support for r7s72100 PFC and GPIO device nodes port0 -> port11 and jtagport0. Signed-off-by: Magnus Damm Signed-off-by: Jacopo Mondi --- arch/arm/boot/dts/r7s72100.dtsi | 138

[PATCH v2 5/7] arm: dts: r7s72100-genmai: LED1 and LED2 support

From: Magnus Damm Add support for Genmai board LED1 and LED2 via gpio-leds. Signed-off-by: Magnus Damm Acked-by: Laurent Pinchart --- arch/arm/boot/dts/r7s72100-genmai.dts | 11 +++ 1 file changed, 11

[PATCH v2 6/7] arm: dts: r7s72100-genmai:Add ethernet PFC node

From: Simon Horman Squash Simon's original commit with his fixup of sh_eth pin names Signed-off-by: Simon Horman Signed-off-by: Jacopo Mondi [WIP] genmai sh_eth dts fixup Signed-off-by: Simon Horman

[PATCH v2 7/7] arm: dts: r7s72100-genmai: Add pinctrl for RSPI

From: Geert Uytterhoeven Add pinctrl for the existing rspi4 node on Genmai. Signed-off-by: Geert Uytterhoeven --- v5: - Rebased, kept pinctrl only (RSPI nodes have been split off and integrated before) v4: - No changes v3: - No

[PATCH v2 4/7] arm: dts: r7s72100-genmai: SCIF2 PINCTRL configuration

From: Magnus Damm Configure the r7s72100 PINCTRL hardware and select pin function for the SCIF2 serial console. Signed-off-by: Magnus Damm Acked-by: Laurent Pinchart --- arch/arm/boot/dts/r7s72100-genmai.dts | 10

[PATCH v2 0/7] 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

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

Hi Geert, Thanks for your feedback. On 2017-01-11 09:42:09 +0100, Geert Uytterhoeven wrote: > Hi Niklas, > > On Wed, Jan 11, 2017 at 9:35 AM, Niklas Söderlund > wrote: > > On 2017-01-10 23:30:43 +0100, Wolfram Sang wrote: > >> > Oddly enough the error are only

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

Hi Geert, On 10/01/2017 16:07, Geert Uytterhoeven wrote: Hi Jacopo, On Mon, Jan 9, 2017 at 8:31 PM, Jacopo Mondi wrote: From: Magnus Damm This is a squash of several commits, adding peripherals groups configuration to r7s72100 device tree, and

Re: [PATCH 2/2] serial: sh-sci: Fix hang in sci_reset()

Hi Laurent, On Fri, Jan 6, 2017 at 1:31 PM, Laurent Pinchart wrote: > On Friday 02 Dec 2016 13:35:11 Geert Uytterhoeven wrote: >> When the .set_termios() callback resets the UART, it first waits until >> all characters in the transmit FIFO have been

  1   2   >