[PATCH v3] iio: adc: Add Maxim MAX11100 driver

From: Jacopo Mondi Add IIO driver for Maxim MAX11100 single-channel ADC. Add DT bindings documentation. Signed-off-by: Jacopo Mondi Tested-by: Marek Vasut --- Sending v3 incorporating last comments from review and from testing.

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

On Wed, Jan 04, 2017 at 06:39:52PM +0100, Wolfram Sang wrote: > Simon, > > as Ulf picked up the driver patches for HS200 support, it is now safe to pick > up the DTS patches, I'd say? I rebased them to the dt-for-4.11 branch. > > All the best, > >Wolfram > > > Wolfram Sang (2): > arm64:

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

Hi Geert, On Thursday, January 12, 2017, Geert Uytterhoeven wrote: > This is strange. There are two SDHI channels, but the STBCR12 > documentation (all versions up to rev. 3.00) says the register has MSTP > bits for four SD host interfaces? > > Can you please enlighten me? Thanks! Ya, I saw

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

Hi Chris, On Thu, Jan 12, 2017 at 7:11 PM, Chris Brandt wrote: > Now that all the clocks in the boot loader are disabled before booting > the kernel, and the mstp driver has been fixed for RZ/A1, here is a typo > that was missed during original testing. > > Fixes:

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

Hi Jacopo, On Thursday, January 12, 2017, jacopo mondi wrote: > Oh! That's weird I don't have that statement in my manual (public version > R01UH0403EJ0060 Rev.0.60) If you go to www.renesas.com and search for "RZ/A1H User Manual", you will see that a new version 3.0 manual was recently posted.

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

Hi Chris, On 12/01/2017 15:39, Chris Brandt wrote: Hi Jacopo, On Thursday, January 12, 2017, jacopo mondi wrote: To read the pin direction I would need to add one more register to the "reg" property range provided in the DTS. This is of course doable, but I would have two questions here: -

[PATCH 0/2] clocksource: Add renesas-ostm timer driver

This patch set adds a new clocksource driver that uses the OS Timer (OSTM) that exists in the R7S72100 (RZ/A1) SoC. The operation of the driver was tested with a simple user application that does multiple calls to nanosleep() and gettimeofday(). The purpose of adding this driver is to get better

[PATCH 1/2] dt-bindings: document renesas-ostm timer

Signed-off-by: Chris Brandt --- .../devicetree/bindings/timer/renesas,ostm.txt | 36 ++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt diff --git

[PATCH 2/2] clocksource: Add renesas-ostm timer driver

This patch adds a OSTM driver for the Renesas architecture. Signed-off-by: Chris Brandt --- arch/arm/mach-shmobile/Kconfig | 1 + drivers/clocksource/Kconfig| 12 ++ drivers/clocksource/Makefile | 1 + drivers/clocksource/renesas-ostm.c | 389

[PATCH 0/3] ARM: dts: add ostm support for r7s72100

This patch set enables the use of the newly created driver renesas-ostm.c for the r7s72100 SoC. This patch set depends on the acceptance of: [PATCH 1/2] dt-bindings: document renesas-ostm timer [PATCH 2/2] clocksource: Add renesas-ostm timer driver Chris Brandt (3): ARM: dts: r7s72100:

[PATCH 3/3] ARM: dts: rskrza1: add ostm DT support

Signed-off-by: Chris Brandt --- arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 arch/arm/boot/dts/r7s72100.dtsi| 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts

[PATCH 2/3] ARM: dts: r7s72100: add ostm to device tree

Signed-off-by: Chris Brandt --- arch/arm/boot/dts/r7s72100.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi index d5946df..247bbe0 100644 --- a/arch/arm/boot/dts/r7s72100.dtsi +++

[PATCH 1/3] ARM: dts: r7s72100: add ostm clock to device tree

Signed-off-by: Chris Brandt --- arch/arm/boot/dts/r7s72100.dtsi| 9 + include/dt-bindings/clock/r7s72100-clock.h | 4 2 files changed, 13 insertions(+) diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi index

[PATCH] ARM: dts: r7s72100: fix sdhi clock define

Now that all the clocks in the boot loader are disabled before booting the kernel, and the mstp driver has been fixed for RZ/A1, here is a typo that was missed during original testing. Fixes: 7c8522b7047c ("ARM: dts: r7s72100: add sdhi clock to device tree") Signed-off-by: Chris Brandt

Re: [EXT] Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

On 01/12/2017 07:55 PM, Lino Sanfilippo wrote: + +for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) { BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater? {cur|dirty}_tx never wrap. Both values are 32 bit and AFAICS they are only

Re: [EXT] Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

Hi, On 12.01.2017 17:37, Sergei Shtylyov wrote: External Email -- On 01/12/2017 04:23 PM, Lino Sanfilippo wrote: + +for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) { BTW: How can this work

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

On 01/12/2017 04:23 PM, Lino Sanfilippo wrote: + +for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) { BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater? {cur|dirty}_tx never wrap. Regards, Lino MBR, Sergei

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

On 01/12/2017 04:18 PM, Simon Horman wrote: ... Here, it stop once an untransmitted buffer is encountered... Yes, I see that now. I wonder if we should: a) paramatise ravb_tx_free() so it may either clear all transmitted buffers (current behaviour) or all buffers (new behaviour). b)

Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request

On 01/12/2017 07:04 PM, David Miller wrote: What I now see is that a few lines further up there is: if (skb_put_padto(skb, ETH_ZLEN)) goto drop; where ETH_ZLEN is 60. So I don't think we need to worry about skb->len being less than 60 and this patch can be

Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request

From: Simon Horman Date: Thu, 12 Jan 2017 16:46:47 +0100 > What I now see is that a few lines further up there is: > >if (skb_put_padto(skb, ETH_ZLEN)) > goto drop; > > where ETH_ZLEN is 60. > > So I don't think we need to worry about skb->len

Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request

On 01/12/2017 04:53 PM, Simon Horman wrote: From: Masaru Nagai Due to alignment requirements of the hardware transmissions are split into two DMA requests, Rather DMA descriptors. a small padding request of 0 - 4 bytes in length 0..3 currently.

Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request

On Thu, Jan 12, 2017 at 10:21:02AM -0500, David Miller wrote: > From: Simon Horman > Date: Thu, 12 Jan 2017 14:53:37 +0100 > > > diff --git a/drivers/net/ethernet/renesas/ravb_main.c > > b/drivers/net/ethernet/renesas/ravb_main.c > > index 92d7692c840d..3b4d2504285e

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

On Wed, Jan 11, 2017 at 11:11:17AM +0100, 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

Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request

From: Simon Horman Date: Thu, 12 Jan 2017 14:53:37 +0100 > diff --git a/drivers/net/ethernet/renesas/ravb_main.c > b/drivers/net/ethernet/renesas/ravb_main.c > index 92d7692c840d..3b4d2504285e 100644 > --- a/drivers/net/ethernet/renesas/ravb_main.c > +++

Re: [PATCH 04/04] arm64: dts: r8a7795: Connect Ethernet AVB to IPMMU

Hi Magnus, On Fri, Oct 28, 2016 at 2:40 PM, Geert Uytterhoeven wrote: > On Thu, Oct 27, 2016 at 12:29 PM, Magnus Damm wrote: >> From: Magnus Damm >> >> Add IPMMU-DS0 to the Ethernet-AVB device node. >> >> Signed-off-by:

Re: [PATCH net] ravb: Remove Rx overflow log messages

From: Simon Horman Date: Thu, 12 Jan 2017 13:21:06 +0100 > From: Kazuya Mizuguchi > > Remove Rx overflow log messages as in an environment where logging results > in network traffic logging may cause further overflows. > > Fixes:

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

Hi Jacopo, On Thursday, January 12, 2017, jacopo mondi wrote: > To read the pin direction I would need to add one more register to the > "reg" property range provided in the DTS. > This is of course doable, but I would have two questions here: > - why did you chose to use PMSR register instead of

[PATCH/RFC net] ravb: do not use zero-length alighment DMA request

From: Masaru Nagai Due to alignment requirements of the hardware transmissions are split into two DMA requests, a small padding request of 0 - 4 bytes in length followed by the a request for rest of the packet. In the case of IP packets the first request will never

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

Hmm, I think when the dma-ranges are missing, we should either enforce a 32-bit mask, or disallow DMA completely. It's probably too late for the latter, I wish we had done this earlier in order to force everyone on ARM64 to have a valid dma-ranges property for any DMA master.

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

On 01/12/2017 09:25 AM, Geert Uytterhoeven wrote: > Hi Marek, Hi! > On Thu, Jan 12, 2017 at 2:03 AM, 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

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

On 12/01/17 13:25, Arnd Bergmann wrote: > On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote: >> On Thu, Jan 12, 2017 at 08:52:51AM +0300, 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

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

Hi, On 12.01.2017 10:11, Simon Horman wrote: + + for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) { BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater? Regards, Lino

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

On Thursday, January 12, 2017 9:33:32 AM CET Nikita Yushchenko wrote: > >> Hmm, I think when the dma-ranges are missing, we should either enforce > >> a 32-bit mask, or disallow DMA completely. It's probably too late for > >> the latter, I wish we had done this earlier in order to force everyone >

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

On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote: > On Thu, Jan 12, 2017 at 08:52:51AM +0300, 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 > > >> ---

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

On Thu, Jan 12, 2017 at 03:03:05PM +0300, Sergei Shtylyov wrote: > On 01/12/2017 12:11 PM, Simon Horman wrote: ... > >> Here, it stop once an untransmitted buffer is encountered... > > > >Yes, I see that now. > > > >I wonder if we should: > > > >a) paramatise ravb_tx_free() so it may either

Re: NVMe vs DMA addressing limitations

On Thu, Jan 12, 2017 at 12:56:07PM +0100, Arnd Bergmann wrote: > That is an interesting question: We actually have the > "DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements > it in the coherent interface, so that might be a good fit. Yes. my WIP HMB patch uses

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

> I'll bring my Koelsch. Great. I *think* one Koelsch will do, but if it is not too much of a problem, double-checking with a second board won't hurt. So, since Geert will probably bring all necessary cables and supplies, maybe you can pack the board nonetheless? But having one Koelsch already

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

Hello! On 01/09/2017 06:34 PM, Niklas Söderlund wrote: 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

[PATCH net] ravb: Remove Rx overflow log messages

From: Kazuya Mizuguchi Remove Rx overflow log messages as in an environment where logging results in network traffic logging may cause further overflows. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Kazuya Mizuguchi

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

On 01/12/2017 12:11 PM, Simon Horman wrote: From: Kazuya Mizuguchi "swiotlb buffer is full" errors occur after repeated initialisation of a device - f.e. suspend/resume or ip link set up/down. This is because memory mapped using dma_map_single() in

Re: [PATCH] mmc: host: tmio: drop superfluous exit path

On 6 January 2017 at 09:38, Wolfram Sang wrote: > The probe exit path on error does nothing since commit 94b110aff8679b > ("mmc: tmio: add tmio_mmc_host_alloc/free()"), so we can bail out > immediately. > > Signed-off-by: Wolfram Sang

Re: NVMe vs DMA addressing limitations

On Thursday, January 12, 2017 12:09:11 PM CET Sagi Grimberg wrote: > >> Another workaround me might need is to limit amount of concurrent DMA > >> in the NVMe driver based on some platform quirk. The way that NVMe works, > >> it can have very large amounts of data that is concurrently mapped into

Re: [PATCH/RFC net] ravb: Remove Rx overflow log messages

On 01/12/2017 11:41 AM, Simon Horman wrote: From: Kazuya Mizuguchi Remove Rx overflow log messages as in an environment where logging results in network traffic logging may cause further overflows. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")

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

On Thu, Jan 12, 2017 at 12:17 PM, Niklas Söderlund wrote: > On 2017-01-11 18:34:32 +0100, Wolfram Sang wrote: >> > 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

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

On 2017-01-11 18:34:32 +0100, Wolfram Sang wrote: > > > 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 :) > To be super clear, Geert you can bring your

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

Hi Linus, thanks for review On 11/01/2017 15:55, Linus Walleij wrote: On Mon, Jan 9, 2017 at 8:31 PM, Jacopo Mondi wrote: +static void rz_gpio_free(struct gpio_chip *chip, unsigned offset) +{ + pinctrl_free_gpio(chip->base + offset); + + /* Set

Re: NVMe vs DMA addressing limitations

Another workaround me might need is to limit amount of concurrent DMA in the NVMe driver based on some platform quirk. The way that NVMe works, it can have very large amounts of data that is concurrently mapped into the device. That's not really just NVMe - other storage and network

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

On Thu, Jan 12, 2017 at 11:23:57AM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Thursday 12 Jan 2017 10:04:34 Simon Horman wrote: > > On Thu, Jan 12, 2017 at 03:51:21AM +0200, Laurent Pinchart wrote: > > > The clocks are generated by an I2C-controlled programmable clock > > > generator. > >

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

Hi Simon, On Thursday 12 Jan 2017 10:04:34 Simon Horman wrote: > On Thu, Jan 12, 2017 at 03:51:21AM +0200, Laurent Pinchart wrote: > > The clocks are generated by an I2C-controlled programmable clock > > generator. > > > > Signed-off-by: Laurent Pinchart > >

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

On Fri, Jan 06, 2017 at 10:02:36PM +0300, Sergei Shtylyov wrote: > Hello! > > On 01/05/2017 01:43 PM, Simon Horman wrote: > > >From: Kazuya Mizuguchi > > > >"swiotlb buffer is full" errors occur after repeated initialisation of a > >device - f.e. suspend/resume

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

On Thu, Jan 12, 2017 at 08:36:10AM +0100, Geert Uytterhoeven wrote: > 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

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

On Thu, Jan 12, 2017 at 03:51:21AM +0200, 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 | 26 >

Re: [PATCH] pinctrl: core: Fix regression caused by delayed work for hogs

Hi Tony, On Wed, Jan 11, 2017 at 11:13 PM, Tony Lindgren wrote: > Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a > regression at least with sh-pfc that is also a GPIO controller as > noted by Geert Uytterhoeven . > > As the

[PATCH/RFC net] ravb: Remove Rx overflow log messages

From: Kazuya Mizuguchi Remove Rx overflow log messages as in an environment where logging results in network traffic logging may cause further overflows. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Kazuya Mizuguchi

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

On Thu, Jan 12, 2017 at 2:51 AM, Laurent Pinchart wrote: > The clocks are generated by an I2C-controlled programmable clock > generator. > > Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven

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

Hi Marek, On Thu, Jan 12, 2017 at 2:03 AM, 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