Re: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

2016-03-07 Thread Oliver Hartkopp
On 03/07/2016 09:32 AM, Ramesh Shanmugasundaram wrote: > + /* Ensure channel starts in FD mode */ > + if (!(priv->can.ctrlmode & CAN_CTRLMODE_FD)) { > + netdev_err(ndev, "enable can fd mode for channel %d\n", ch); > + goto fail_mode; > + } What's

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

2016-03-07 Thread Christoph Hellwig
Please add some documentation on where/how this should be used. It's not a very obvious interface.

[PATCH 2/2] usb: renesas_usbhs: disable tx irq before starting TX DMAC transfer

2016-03-07 Thread Yoshihiro Shimoda
This patch adds a code to surely disable tx irq of the pipe before starting TX DMAC transfer. Otherwise, a lot of unnecessary tx irqs may heppen in rare cases when DMAC is used. Signed-off-by: Yoshihiro Shimoda --- drivers/usb/renesas_usbhs/fifo.c | 1 + 1 file

[PATCH 0/2] usb: renesas_usbhs: fix to avoid unexpected condition

2016-03-07 Thread Yoshihiro Shimoda
This patch set is based on the latest Felipe's usb.git / testing/next branch. (commit id = ac5706631325ae3695bfa1527101ab2b2f64859f) Yoshihiro Shimoda (2): usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() usb: renesas_usbhs: disable tx irq before starting TX DMAC

[PATCH v5 8/9] ARM: dts: r8a7790: add iommus to dmac0 and dmac1

2016-03-07 Thread Niklas Söderlund
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the DMAC together with the IPMMU. The DMAC driver will disable the channels reducing the effective number of channels to 14 per DMAC. Signed-off-by: Niklas Söderlund Acked-by: Laurent

[PATCH v5 1/9] iommu: Add MMIO mapping type

2016-03-07 Thread Niklas Söderlund
From: Robin Murphy On some platforms, MMIO regions might need slightly different treatment compared to mapping regular memory; add the notion of MMIO mappings to the IOMMU API's memory type flags, so that callers can let the IOMMU drivers know to do the right thing.

[PATCH v5 5/9] dmaengine: rcar-dmac: slave address are physical

2016-03-07 Thread Niklas Söderlund
Slave addresses coming from a client is physical not dma. Store the address using the correct data type. This is in preparation for hooking up the dma-mapping API to the slave addresses. Signed-off-by: Niklas Söderlund --- drivers/dma/sh/rcar-dmac.c | 4

[PATCH v5 7/9] dmaengine: rcar-dmac: add iommu support for slave transfers

2016-03-07 Thread Niklas Söderlund
Enable slave transfers to a device behind a IPMMU by mapping the slave addresses using the dma-mapping API. Signed-off-by: Niklas Söderlund --- drivers/dma/sh/rcar-dmac.c | 82 +- 1 file changed, 74

[PATCH v5 6/9] dmaengine: rcar-dmac: group slave configuration

2016-03-07 Thread Niklas Söderlund
Group slave address and transfer size in own structs for source and destination. This is in preparation for hooking up the dma-mapping API to the slave addresses. Signed-off-by: Niklas Söderlund --- drivers/dma/sh/rcar-dmac.c | 38

[PATCH v5 0/9] dmaengine: rcar-dmac: add iommu support for slave transfers

2016-03-07 Thread Niklas Söderlund
Hi, This series add iommu support to rcar-dmac. It's tested on Koelsch with CONFIG_IPMMU_VMSA and by enabling the ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with /dev/mmcblk1 and the serial console which both are devices behind the iommu. The series depends patch '[PATCH]

[PATCH v5 2/9] dma-mapping: add {map,unmap}_resource to dma_map_ops

2016-03-07 Thread Niklas Söderlund
Add methods to handle mapping of device resources from a physical address. This is needed for example to be able to map MMIO FIFO registers to a IOMMU. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart ---

Re: [PATCH] ata: sata_rcar: add gen[123] fallback compatibility strings

2016-03-07 Thread Simon Horman
[CC devicet...@vger.kernel.org] On Tue, Mar 08, 2016 at 10:30:42AM +0900, Simon Horman wrote: > Add fallback compatibility string for R-Car Gen 1, 2 and 3. > > In the case of Renesas R-Car hardware we know that there are generations of > SoCs, e.g. Gen 1 and 2. But beyond that its not clear what

Re: [PATCH] SATA: rcar: add device tree support for r8a7792

2016-03-07 Thread Simon Horman
On Thu, Feb 25, 2016 at 10:16:25AM +0900, Simon Horman wrote: > Simply document new compatibility string. > As a previous patch adds a generic R-Car Gen2 compatibility string > there appears to be no need for a driver updates. > > By documenting this compat sting it may be used in DTSs shipped,

[PATCH v2] media: rcar_vin: Use ARCH_RENESAS

2016-03-07 Thread Simon Horman
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. This is part of an ongoing process to migrate from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that RENESAS seems to be a more appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs. Signed-off-by: Simon

[PATCH v2] media: sh_mobile_ceu_camera: Remove dependency on SUPERH

2016-03-07 Thread Simon Horman
A dependency on ARCH_SHMOBILE seems to be the best option for sh_mobile_ceu_camera: * For Super H based SoCs: sh_mobile_ceu is used on SH_AP325RXA, SH_ECOVEC, SH_KFR2R09, SH_MIGOR, and SH_7724_SOLUTION_ENGINE which depend on CPU_SUBTYPE_SH7722, CPU_SUBTYPE_SH7723, or CPU_SUBTYPE_SH7724 which

[PATCH] clk: renesas: div6: use RENESAS for #define

2016-03-07 Thread Simon Horman
Name the #define guarding compilation of this header __RENESAS_CLK_DIV6_H__ rather than __SHMOBILE_CLK_DIV6_H__. This is a follow-up to renaming the directory in which this file lives from shmobile to renesas which is in turn part of an ongoing process to migrate from ARCH_SHMOBILE to

Re: [PATCH] bus: simple-pm-bus: Use ARCH_RENESAS

2016-03-07 Thread Simon Horman
On Mon, Mar 07, 2016 at 02:22:57PM +0100, Geert Uytterhoeven wrote: > On Fri, Mar 4, 2016 at 6:20 AM, Simon Horman wrote: > > On Thu, Mar 03, 2016 at 09:31:49AM +0100, Geert Uytterhoeven wrote: > >> On Thu, Mar 3, 2016 at 2:39 AM, Simon Horman >

Re: [PATCH] media: sh_mobile_ceu_camera, rcar_vin: Use ARCH_RENESAS

2016-03-07 Thread Simon Horman
On Mon, Mar 07, 2016 at 08:53:56AM +0100, Geert Uytterhoeven wrote: > Hi Simon, > > Oops, seems I dropped all CCs in my earlier reply. Fixing up... > > On Mon, Mar 7, 2016 at 2:28 AM, Simon Horman wrote: > > On Thu, Mar 03, 2016 at 09:40:07AM +0100, Geert Uytterhoeven wrote:

[PATCH 1/2] sh_eth: fix NULL pointer dereference in sh_eth_ring_format()

2016-03-07 Thread Sergei Shtylyov
In a low memory situation, if netdev_alloc_skb() fails on a first RX ring loop iteration in sh_eth_ring_format(), 'rxdesc' is still NULL. Avoid kernel oops by adding the 'rxdesc' check after the loop. Reported-by: Wolfram Sang Signed-off-by: Sergei Shtylyov

[PATCH 2/2] sh_eth: advance 'rxdesc' later in sh_eth_ring_format()

2016-03-07 Thread Sergei Shtylyov
Iff dma_map_single() fails, 'rxdesc' should point to the last filled RX descriptor, so that it can be marked as the last one, however the driver would have already advanced it by that time. In order to fix that, only fill an RX descriptor once all the data for it is ready. Signed-off-by:

[PATCH 0/2] sh_eth: fix couple of bugs in sh_eth_ring_format()

2016-03-07 Thread Sergei Shtylyov
Hello. Here's a set of 2 patches against DaveM's 'net.git' repo fixing two bugs in sh_eth_.ring_format()... [1/2] sh_eth: fix NULL pointer dereference in sh_eth_ring_format() [2/2] sh_eth: advance 'rxdesc' later in sh_eth_ring_format() MBR, Sergei

Re: [RFC] pinctrl: sh-pfc: only use dummy states for non-DT platforms

2016-03-07 Thread Wolfram Sang
> Perhaps the of_have_populated_dt() check should be moved inside > pinctrl_provide_dummies()? Hmm, the kernel-doc for pinctrl_provide_dummies() says "Usually this function is called by platforms without pinctrl driver support...". Is "without pintctrl" == "no DT"? Linus? signature.asc

Re: [RFC] pinctrl: sh-pfc: only use dummy states for non-DT platforms

2016-03-07 Thread Sergei Shtylyov
On 03/08/2016 12:00 AM, Geert Uytterhoeven wrote: --- a/drivers/pinctrl/sh-pfc/core.c +++ b/drivers/pinctrl/sh-pfc/core.c @@ -545,7 +545,9 @@ static int sh_pfc_probe(struct platform_device *pdev) return ret; } - pinctrl_provide_dummies(); + /*

Re: [RFC] pinctrl: sh-pfc: only use dummy states for non-DT platforms

2016-03-07 Thread Sergei Shtylyov
On 03/07/2016 11:29 PM, Geert Uytterhoeven wrote: --- a/drivers/pinctrl/sh-pfc/core.c +++ b/drivers/pinctrl/sh-pfc/core.c @@ -545,7 +545,9 @@ static int sh_pfc_probe(struct platform_device *pdev) return ret; } - pinctrl_provide_dummies(); + /*

Re: [RFC] pinctrl: sh-pfc: only use dummy states for non-DT platforms

2016-03-07 Thread Geert Uytterhoeven
On Mon, Mar 7, 2016 at 9:02 PM, Sergei Shtylyov wrote: >>> --- a/drivers/pinctrl/sh-pfc/core.c >>> +++ b/drivers/pinctrl/sh-pfc/core.c >>> @@ -545,7 +545,9 @@ static int sh_pfc_probe(struct platform_device *pdev) >>> return ret; >>>

Re: [RFC] pinctrl: sh-pfc: only use dummy states for non-DT platforms

2016-03-07 Thread Sergei Shtylyov
Hello. On 03/07/2016 10:56 PM, Geert Uytterhoeven wrote: From: Wolfram Sang If pinctrl_provide_dummies() is used unconditionally, then the dummy state will be used even on DT platforms when the "init" state was intentionally left out. Instead of "default",

Re: [RFC] pinctrl: sh-pfc: only use dummy states for non-DT platforms

2016-03-07 Thread Geert Uytterhoeven
Hi Wolfram, On Mon, Mar 7, 2016 at 7:40 PM, Wolfram Sang wrote: > From: Wolfram Sang > > If pinctrl_provide_dummies() is used unconditionally, then the dummy > state will be used even on DT platforms when the "init" state was > intentionally

[RFC] pinctrl: sh-pfc: only use dummy states for non-DT platforms

2016-03-07 Thread Wolfram Sang
From: Wolfram Sang If pinctrl_provide_dummies() is used unconditionally, then the dummy state will be used even on DT platforms when the "init" state was intentionally left out. Instead of "default", the dummy "init" state will then be used during probe. Thus,

Re: [PATCH/RFC v6 net-next] ravb: Add dma queue interrupt support

2016-03-07 Thread Yoshihiro Kaneko
2016-03-03 3:50 GMT+09:00 Sergei Shtylyov : > On 03/02/2016 09:16 PM, Yoshihiro Kaneko wrote: > From: Kazuya Mizuguchi This patch supports the following interrupts. - One interrupt for multiple

Re: [PATCH/RFC] v4l: subdev: subdev_fh->pad depends on CONFIG_VIDEO_V4L2_SUBDEV_API

2016-03-07 Thread Laurent Pinchart
Hi Geert, Thank you for the patch. On Monday 07 March 2016 15:31:22 Geert Uytterhoeven wrote: > If CONFIG_VIDEO_V4L2_SUBDEV_API=n: > > drivers/media/v4l2-core/v4l2-subdev.c: In function 'subdev_open': > drivers/media/v4l2-core/v4l2-subdev.c:86:106: error: 'struct > v4l2_subdev_fh' has

renesas-drivers-2016-03-07-v4.5-rc7

2016-03-07 Thread Geert Uytterhoeven
of various subsystem trees 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-20160307-v4.5-rc7. I made the release one day earlier than expected to push out

[PATCH/RFC] v4l: subdev: subdev_fh->pad depends on CONFIG_VIDEO_V4L2_SUBDEV_API

2016-03-07 Thread Geert Uytterhoeven
If CONFIG_VIDEO_V4L2_SUBDEV_API=n: drivers/media/v4l2-core/v4l2-subdev.c: In function 'subdev_open': drivers/media/v4l2-core/v4l2-subdev.c:86:106: error: 'struct v4l2_subdev_fh' has no member named 'pad' v4l2_subdev_fh.pad exists only if CONFIG_VIDEO_V4L2_SUBDEV_API is enabled. Protect

Re: [PATCH 05/16] drm/gma: removed optional dummy crtc mode_fixup function.

2016-03-07 Thread Patrik Jakobsson
On Tue, Feb 16, 2016 at 3:17 PM, Carlos Palminha wrote: > This patch set nukes all the dummy crtc mode_fixup implementations. > (made on top of Daniel topic/drm-misc branch) > > Signed-off-by: Carlos Palminha You should try to avoid mixing

Re: [PATCH] bus: simple-pm-bus: Use ARCH_RENESAS

2016-03-07 Thread Geert Uytterhoeven
On Fri, Mar 4, 2016 at 6:20 AM, Simon Horman wrote: > On Thu, Mar 03, 2016 at 09:31:49AM +0100, Geert Uytterhoeven wrote: >> On Thu, Mar 3, 2016 at 2:39 AM, Simon Horman >> wrote: >> > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. >> > >> >

Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended

2016-03-07 Thread Ulf Hansson
[...] >> I agree, that's a better idea. Drivers shouldn't call >> pm_runtime_force_resume() if they haven't called pm_runtime_force_suspend(), >> so checking the PM use count should be fine. I'll modify the patch, test it >> and resubmit. > > I gave it an unfortunately unsuccessful try. The

RE: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

2016-03-07 Thread Ramesh Shanmugasundaram
Hi Rob, Thanks for the review comments. > On Thu, Mar 03, 2016 at 03:38:35PM +, Ramesh Shanmugasundaram wrote: > > This patch adds support for the CAN FD controller found in Renesas > > R-Car SoCs. The controller operates in CAN FD mode by default. > > > > CAN FD mode supports both Classical

RE: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

2016-03-07 Thread Ramesh Shanmugasundaram
Hi Marc, > On 03/07/2016 09:02 AM, Ramesh Shanmugasundaram wrote: > > Hi Oliver, > > > > Thanks for the review comments. > > > >> On 03/03/2016 04:38 PM, Ramesh Shanmugasundaram wrote: > >> > >>> Changes since v1: > >>> * Removed testmodes & debugfs code (suggested by Oliver H) > >>> * Fixed

RE: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

2016-03-07 Thread Ramesh Shanmugasundaram
Hi Oliver, Thanks for the review comments. > On 03/03/2016 04:38 PM, Ramesh Shanmugasundaram wrote: > > > Changes since v1: > > * Removed testmodes & debugfs code (suggested by Oliver H) > > * Fixed tx path race issue by introducing lock (suggested by Marc K) > > * Removed

Re: [PATCH v2] phy: rcar-gen3-usb2, rcar-gen2: Use ARCH_RENESAS

2016-03-07 Thread Geert Uytterhoeven
On Mon, Mar 7, 2016 at 2:14 AM, Simon Horman wrote: > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > A now redundant dependency on OF is also dropped. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which