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

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 rz-pfc driver (it seems so) and if this justify splitting sh-pfc > in two,

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

Hi Laurent, Chris, On 10/01/2017 02:28, Laurent Pinchart wrote: 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.

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

> Oddly enough the error are only printed when I insert the SD card in the > mmc0 slot. I can insert/eject the card multiple times in mmc1 and no > error but the first insertion in mmc0 and boom. Only difference I can > see are the clock speed between mmc0 and mmc1. Can you try this patch?

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

Hi Laurent, On Tue, Jan 10, 2017 at 8:58 PM, Laurent Pinchart wrote: > 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

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

Hi Simon, I started to se errors when I was testing DMAC+IPMMU patches on top of v4.10-rc1 on Koelsch. [2.247490] [drm] Device feb0.display probed [2.254407] sh_mobile_sdhi ee10.sd: Got CD GPIO [2.259535] sh_mobile_sdhi ee10.sd: Got WP GPIO [2.473871] sh_mobile_sdhi

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

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 peripherals groups > > configuration to r7s72100 device tree, and enabling some

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

* Tony Lindgren [170110 07:32]: > * Geert Uytterhoeven [170110 06:09]: > > Hi Tony, > > > > On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren wrote: > > > Having the pin control framework call pin controller functions > > > before it's

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

On 01/10/2017 01:44 AM, Stephen Boyd wrote: > 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

Re: [PATCH] watchdog: softdog: make pretimeout support a compile option

On Fri, Jan 06, 2017 at 09:41:44AM +0100, Wolfram Sang wrote: > It occured to me that the panic pretimeout governor will stall the > softdog, because it is purely software which simply halts on panic. > Testing governors with the softdog on the other hand is really useful. > So, make this feature

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

On 10/01/17 14:00, Nikita Yushchenko wrote: > 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,

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

* Geert Uytterhoeven [170110 06:09]: > Hi Tony, > > On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren wrote: > > Having the pin control framework call pin controller functions > > before it's probe has finished is not nice as the pin controller > > device

Re: NVMe vs DMA addressing limitations

On Tuesday, January 10, 2017 3:48:39 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann 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

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

On Tuesday, January 10, 2017 2:16:57 PM CET Robin Murphy wrote: > On 10/01/17 13:42, Arnd Bergmann wrote: > > On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: > >> On 10/01/17 12:47, Nikita Yushchenko wrote: > The point here is that an IOMMU doesn't solve your issue, and the >

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

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 enabling some of them on > Genmai evaluation board >

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

On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > > 32-bit architectures without swiotlb (arc, arm, some mips32), and > > there are several

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

On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: > On 10/01/17 12:47, Nikita Yushchenko wrote: > >> The point here is that an IOMMU doesn't solve your issue, and the > >> IOMMU-backed DMA ops need the same treatment. In light of that, it really > >> feels to me like the DMA masks

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

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

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

On Tue, Jan 10, 2017 at 02:42:23PM +0100, Arnd Bergmann wrote: > It's a much rarer problem for the IOMMU case though, because it only > impacts devices that are restricted to addressing of less than 32-bits. > > If you have an IOMMU enabled, the dma-mapping interface does not care > if the device

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

On Tue, Jan 10, 2017 at 03:47:25PM +0300, Nikita Yushchenko wrote: > With this direction, semantics of dma mask becomes even more > questionable. I'd say dma_mask is candidate for removal (or to move to > swiotlb's or iommu's local area) We need the dma mask so that the device can advertise what

Re: NVMe vs DMA addressing limitations

On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann 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 > the device.

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

On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > 32-bit architectures without swiotlb (arc, arm, some mips32), and > there are several 64-bit architectures that do not have swiotlb > (alpha, parisc, s390, sparc). I

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

On 10/01/17 13:42, Arnd Bergmann wrote: > On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: >> On 10/01/17 12:47, Nikita Yushchenko wrote: The point here is that an IOMMU doesn't solve your issue, and the IOMMU-backed DMA ops need the same treatment. In light of that, it

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

Hi Tony, On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren wrote: > Having the pin control framework call pin controller functions > before it's probe has finished is not nice as the pin controller > device driver does not yet have struct pinctrl_dev handle. > > Let's fix this

Re: DRM range manger test failures

On Tue, Jan 10, 2017 at 12:45:04PM +, Chris Wilson wrote: > On Tue, Jan 10, 2017 at 01:41:54PM +0100, Geert Uytterhoeven wrote: > > Hi Chris, Laurent, > > > > On R-Car Gen2 (Koelsch) and Gen3 (Salvator-X), the new DRM range > > manager selftests fail with: > > > > drm_mm: Testing DRM

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

>> What issue "IOMMU doesn't solve"? >> >> Issue I'm trying to address is - inconsistency within swiotlb >> dma_map_ops, where (1) any wide mask is silently accepted, but (2) then >> mask is used to decide if bounce buffers are needed or not. This >> inconsistency causes NVMe+R-Car cobmo not

[PATCH] 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

renesas-drivers-2017-01-10-v4.10-rc3

and (b) branches with driver code submitted or planned for submission to maintainers into the development branch of Simon Horman's renesas.git tree. Today's version is based on renesas-devel-20170110-v4.10-rc3. Included branches with driver code: - clk-renesas-for-v4.11 - sh-pfc-for-v4.11

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

On 10/01/17 12:47, Nikita Yushchenko wrote: > Hi > >> The point here is that an IOMMU doesn't solve your issue, and the >> IOMMU-backed DMA ops need the same treatment. In light of that, it really >> feels to me like the DMA masks should be restricted in of_dma_configure >> so that the parent

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

On Tuesday, January 10, 2017 3:47:25 PM CET Nikita Yushchenko wrote: > > > The point here is that an IOMMU doesn't solve your issue, and the > > IOMMU-backed DMA ops need the same treatment. In light of that, it really > > feels to me like the DMA masks should be restricted in of_dma_configure >

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

Hi > The point here is that an IOMMU doesn't solve your issue, and the > IOMMU-backed DMA ops need the same treatment. In light of that, it really > feels to me like the DMA masks should be restricted in of_dma_configure > so that the parent mask is taken into account there, rather than hook >

Re: DRM range manger test failures

On Tue, Jan 10, 2017 at 01:41:54PM +0100, Geert Uytterhoeven wrote: > Hi Chris, Laurent, > > On R-Car Gen2 (Koelsch) and Gen3 (Salvator-X), the new DRM range > manager selftests fail with: > > drm_mm: Testing DRM range manger (struct drm_mm), with > random_seed=0x83a9b910 max_iterations=8192

DRM range manger test failures

Hi Chris, Laurent, On R-Car Gen2 (Koelsch) and Gen3 (Salvator-X), the new DRM range manager selftests fail with: drm_mm: Testing DRM range manger (struct drm_mm), with random_seed=0x83a9b910 max_iterations=8192 max_prime=128 drm_mm: igt_sanitycheck - ok! drm_mm: node has wrong color,

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

On Mon, Jan 09, 2017 at 10:30:02AM +0300, Nikita Yushchenko wrote: > It is possible that device is capable of 64-bit DMA addresses, and > device driver tries to set wide DMA mask, but bridge or bus used to > connect device to the system can't handle wide addresses. > > With swiotlb, memory above

Re: NVMe vs DMA addressing limitations

On Tuesday, January 10, 2017 10:31:47 AM CET Nikita Yushchenko wrote: > 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,

Re: NVMe vs DMA addressing limitations

On Tuesday, January 10, 2017 8:07:20 AM CET Christoph Hellwig wrote: > 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, > > -

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

On Monday, January 9, 2017 9:57:46 PM CET Christoph Hellwig wrote: > > - architecture should stop breaking 64-bit DMA when driver attempts to > > set 64-bit dma mask, > > > > - NVMe should issue proper blk_queue_bounce_limit() call based on what > > is actually set mask, > > Or even better

Re: [PATCH v4 0/4] thermal: add driver for R-Car Gen3

Hi Wolfram, On Thu, Dec 1, 2016 at 11:04 PM, Wolfram Sang wrote: > Here is the next series for adding thermal support to Renesas R-Car Gen3 SoCs. > All changes from last revision went into patch 2/4, so please check the > changelog there. This series has again

Re: [PATCH 0/6] R-Car DU: Fix IOMMU operation when connected to VSP

Hi Laurent, On Fri, Aug 19, 2016 at 10:39 AM, Laurent Pinchart wrote: > This patch series fixes the rcar-du-drm driver to support VSP plane sources > with an IOMMU. It is available for convenience at > > git://linuxtv.org/pinchartl/media.git

Re: [GIT PULL FOR renesas-drivers] VSP Writeback prototype

On Mon, Nov 14, 2016 at 9:17 PM, Kieran Bingham wrote: > The following changes since commit 8bc55e5947b58dee3c8b126d7c303991ae0db130: > > tty: serial_core: Fix serial console crash on port shutdown (2016-10-25 > 13:53:49 +0200) > > are available in the

Re: [GIT PULL FOR renesas-drivers] VSP Partition algorithm improvements

Hi Kieran, On Mon, Nov 14, 2016 at 9:17 PM, Kieran Bingham wrote: > The following changes since commit 8bc55e5947b58dee3c8b126d7c303991ae0db130: > > tty: serial_core: Fix serial console crash on port shutdown (2016-10-25 > 13:53:49 +0200) > > are

Re: [PATCH v2 0/5] r8a7796 I2C integration

Hi Uli, On Thu, Nov 3, 2016 at 5:06 PM, Ulrich Hecht wrote: > On Mon, Oct 31, 2016 at 12:46 PM, Wolfram Sang wrote: >> >>> This revision is based on renesas-devel-20161024-v4.9-rc2. It adds the >>> Reviewed-bys and the entries for SYS-DMAC2

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

Hi Laurent, > > >>> 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 > >

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

On Tue, Jan 10, 2017 at 8:54 AM, Simon Horman wrote: > 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: >> > >> > Chris Paterson

Re: [PATCH v2 0/6] usb: Replace the deprecated extcon API

Hi Felipe, These patches have already acked-by tag from you. Could you please apply them if there is additional comment? On 2016년 12월 30일 13:08, Chanwoo Choi wrote: > This patches just replace the deprecated extcon API without any change > of extcon operation and use the resource-managed

Re: [PATCH v2 0/2] phy: Replace the deprecated extcon API

Hi Kishon, Could you review these patches or pick up them if there is no any comment? On 2016년 12월 30일 13:11, Chanwoo Choi wrote: > This patches just replace the deprecated extcon API without any change > of extcon operation and use the resource-managed function for > extcon_register_notifier().

Re: [RFC 3/3] mmc: tmio: discard obsolete SDIO irqs before enabling irqs

On Thu, Jan 05, 2017 at 12:43:26PM +0100, Wolfram Sang wrote: > Before enabling SDIO irqs, clear the status bit, so we discard old and > stale interrupts. Needed to get two wireless cards working. > > Signed-off-by: Wolfram Sang > --- >

Re: [RFC 2/3] mmc: host: tmio: SDIO_STATUS_QUIRK is rather SDIO_STATUS_SETBITS

On Thu, Jan 05, 2017 at 12:43:25PM +0100, Wolfram Sang wrote: > QUIRK sounds like there is something wrong, but actually there are just > some bits which need to be 1. Rename it to be more clear. > > Signed-off-by: Wolfram Sang > --- >

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

On Tue, Jan 10, 2017 at 07:41:28AM +, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > commit 5bcd74e8a30d9259 ("arm64: dts: r8a7795: add sound MIX support") > commit 5be5ee41d011f26b ("arm64: dts: r8a7795: add sound CTU support") > added MIX/CTU