[PATCH] dmaengine: rcar-dmac: clear pertinence number of channels

From: Kuninori Morimoto DMACHCLR clears each channels, but its channel number is based on its SoC or IP. Current driver is using fixed 0x7fff (= for 14ch), it is not good match for Gen3 or Gen2 Audio DMAC. This patch fixes it Signed-off-by: Kuninori Morimoto

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

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

RE: [PATCH] usb: renesas_usbhs: gadget: fix giveback status code in usbhsg_pipe_disable()

Hi Felipe, Oops, I completely forgot this patch. Would you review this patch? Or should I resend it? I confirmed that this patch could be applied on your latest testing/fixes branch. Best regards, Yoshihiro Shimoda > -Original Message- > From: Yoshihiro Shimoda > Sent: Friday, December

[PATCH v2] Input: sh_keysc - Remove dependency on SUPERH

A dependency on ARCH_SHMOBILE seems to be the best option for sh_keysc: * For Super H based SoCs: sh_keysc is used on SH_MIGOR, SH_ECOVEC, SH_KFR2R09, SH_7722_SOLUTION_ENGINE, and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722 or CPU_SUBTYPE_SH7724, and both select

[PATCH v2 1/2] phy: rcar-gen2: add fallback binding

In the case of Renesas R-Car hardware we know that there are generations of SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant

[PATCH v2 2/2] phy: rcar-gen3-usb2: add fallback binding

In the case of Renesas R-Car hardware we know that there are generations of SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant

[PATCH v2 0/2] phy: rcar-gen2, rcar-gen3-usb2: add fallback binding

Add fallback compatibility strings for rcar phy drivers. In the case of Renesas R-Car hardware we know that there are generations of SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than

Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS

On Wed, Mar 02, 2016 at 12:32:39PM +0100, Hans Verkuil wrote: > Hi Simon, > > Note that the patch subject still mentions sh_vou. > > Otherwise: > > Acked-by: Hans Verkuil [snip] On Wed, Mar 02, 2016 at 04:17:10PM +0300, Sergei Shtylyov wrote: [snip] > >v2 > >* Do

[PATCH v3] media: platform: rcar_jpu, vsp1: Use ARCH_RENESAS

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. Acked-by: Geert

Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks

Hi Laurent > > > The parent clock isn't documented in the datasheet, use S2D1 as a best > > > guess for now. > > > > Would you be able to find out what the parent clock is for the FCP and LVDS > > (patch 2/9) clocks ? It seems FCP clock is based on each SoC In H3 ES1 case, it is using - s2d2

Re: [PATCH 2/2] net: ethernet: renesas: sh_eth: don't open code of_device_get_match_data()

On Wed, Mar 02, 2016 at 07:46:24AM +0100, Wolfram Sang wrote: > On Wed, Mar 02, 2016 at 10:21:34AM +0900, Simon Horman wrote: > > On Tue, Mar 01, 2016 at 05:37:59PM +0100, Wolfram Sang wrote: > > > From: Wolfram Sang > > > > > > This change will also make

Re: [PATCH 4/6] pwm: pwm-lpc18xx-sct: test clock rate to avoid division by 0

On Wed, Mar 02, 2016 at 11:44:02PM +0100, Joachim Eastwood wrote: > Hi Wolfram, > > On 2 March 2016 at 23:33, Wolfram Sang wrote: > > From: Wolfram Sang > > > > The clk API may return 0 on clk_get_rate, so we should check the result > >

[PATCH 3/6] pwm: pwm-img: test clock rate to avoid division by 0

From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree. drivers/pwm/pwm-img.c | 5

[PATCH 0/6] treewide: test clock rate to avoid division by 0

Here is the outcome of researching if the result of clk_get_rate() was directly used as a divisor without checking if it is 0. Inspired by a Coverity report. Wolfram Sang (6): ide: palm_bk3710: test clock rate to avoid division by 0 net: ethernet: renesas: ravb_main: test clock rate to avoid

[PATCH 5/6] watchdog: atlas7_wdt: test clock rate to avoid division by 0

From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree.

[PATCH 6/6] watchdog: tangox_wdt: test clock rate to avoid division by 0

From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree.

[PATCH 2/6] net: ethernet: renesas: ravb_main: test clock rate to avoid division by 0

From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree.

[PATCH 1/6] ide: palm_bk3710: test clock rate to avoid division by 0

From: Wolfram Sang The clk API may return 0 on clk_get_rate, so we should check the result before using it as a divisor. Signed-off-by: Wolfram Sang --- Should go individually via subsystem tree. drivers/ide/palm_bk3710.c |

Re: [PATCH/RFC 0/4] media: soc_camera: rcar_vin: Add UDS and NV16 scaling support

Hi Kaneko-san, On 2016-03-03 02:26:41 +0900, Yoshihiro Kaneko wrote: > Hi Hans, > > 2016-02-29 22:27 GMT+09:00 Hans Verkuil : > > Huh, you must have missed Niklas's work the rcar-vin driver: > > > > http://www.spinics.net/lists/linux-media/msg97816.html > > > > I expect that

Re: [PATCH v2 8/9] ARM: shmobile: lager dts: Add entries for VIN HDMI input support

The new way of writing the subject prefix is "ARM: dts: lager: ..."

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

On 03/02/2016 09:16 PM, Yoshihiro Kaneko wrote: From: Kazuya Mizuguchi This patch supports the following interrupts. - One interrupt for multiple (timestamp, error, gPTP) - One interrupt for emac - Four interrupts for dma queue (best effort rx/tx, network

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

2016-03-01 5:55 GMT+09:00 Sergei Shtylyov : > On 02/28/2016 05:13 PM, Yoshihiro Kaneko wrote: > From: Kazuya Mizuguchi This patch supports the following interrupts. - One interrupt for multiple (error,

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

2016-03-01 5:30 GMT+09:00 Sergei Shtylyov : > Hello. > > > On 02/28/2016 06:41 PM, Yoshihiro Kaneko wrote: > >> From: Kazuya Mizuguchi >> >> This patch supports the following interrupts. >> >> - One interrupt for multiple

Re: [PATCH 2/6] ASoC: rsrc-card: add convert channels support

On Thu, Feb 25, 2016 at 05:51:44AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > Renesas sound device has CTU (= Channel Transfer Unit), and > sound card needs its support. > > Signed-off-by: Kuninori Morimoto

Re: [PATCH/RFC 0/4] media: soc_camera: rcar_vin: Add UDS and NV16 scaling support

Hi Hans, 2016-02-29 22:27 GMT+09:00 Hans Verkuil : > Huh, you must have missed Niklas's work the rcar-vin driver: > > http://www.spinics.net/lists/linux-media/msg97816.html > > I expect that the old soc-camera driver will be retired soon in favor of > the new driver, so I

[PATCH v2 1/9] v4l: subdev: Add pad config allocator and init

From: Laurent Pinchart Add a new subdev operation to initialize a subdev pad config array, and a helper function to allocate and initialize the array. This can be used by bridge drivers to implement try format based on subdev pad operations. Signed-off-by: Laurent

[PATCH v2 4/9] media: rcar_vin: Use correct pad number in try_fmt

Fix rcar_vin_try_fmt's use of an inappropriate pad number when calling the subdev set_fmt function - for the ADV7612, IDs should be non-zero. Signed-off-by: William Towle Reviewed-by: Rob Taylor Acked-by: Hans Verkuil

[PATCH v2 5/9] media: rcar-vin: pad-aware driver initialisation

Add detection of source pad number for drivers aware of the media controller API, so that rcar-vin can create device nodes to support modern drivers such as adv7604.c (for HDMI on Lager) and the converted adv7180.c (for composite) underneath. Building rcar_vin gains a dependency on

[PATCH v2 7/9] media: rcar-vin: initialize EDID data

Initializes the decoder subdevice with a fixed EDID blob. Signed-off-by: Ulrich Hecht --- drivers/media/platform/rcar-vin/rcar-dma.c | 46 ++ 1 file changed, 46 insertions(+) diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c

[PATCH v2 6/9] media: rcar-vin: add DV timings support

Adds ioctls DV_TIMINGS_CAP, ENUM_DV_TIMINGS, G_DV_TIMINGS, S_DV_TIMINGS, and QUERY_DV_TIMINGS. Signed-off-by: Ulrich Hecht --- drivers/media/platform/rcar-vin/rcar-dma.c | 69 ++ 1 file changed, 69 insertions(+) diff --git

[PATCH v2 3/9] adv7604: fix SPA register location for ADV7612

SPA location LSB register is at 0x70. Signed-off-by: Ulrich Hecht --- drivers/media/i2c/adv7604.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 2097c48..1680c0e 100644 ---

[PATCH v2 2/9] media: adv7604: automatic "default-input" selection

From: William Towle Add logic such that the "default-input" property becomes unnecessary for chips that only have one suitable input (ADV7611 by design, and ADV7612 due to commit 7111cddd "[media] media: adv7604: reduce support to first (digital) input").

[PATCH v2 0/9] Lager board HDMI input support

Hi! This series implements Lager HDMI input support on top of version 2 of Niklas's herculean rewrite of the rcar-vin driver ("[PATCHv2] [media] rcar-vin: add Renesas R-Car VIN driver"). A couple of the included patches are pushed or have been picked up elsewhere already and are included here

Re: [PATCH] net: sh_eth: avoid NULL pointer dereference in ring setup

> >Reported-by: coverity (CID 1056464) > >Signed-off-by: Wolfram Sang > >Will you respin or should I? Please go ahead. You have more knowledge about this driver, so you will be faster. Reported-by: Wolfram Sang

Re: [PATCH] net: sh_eth: avoid NULL pointer dereference in ring setup

Hello. On 03/02/2016 06:26 PM, Wolfram Sang wrote: From: Wolfram Sang When allocating an skb fails, rxdesc is still NULL (or the previous ring index on further iterations of the loop). However, this pointer is dereferenced after the loop. This is

[PATCH] net: sh_eth: avoid NULL pointer dereference in ring setup

From: Wolfram Sang When allocating an skb fails, rxdesc is still NULL (or the previous ring index on further iterations of the loop). However, this pointer is dereferenced after the loop. So, make sure rxdesc is updated immediately at the beginning of the loop.

Re: [PATCH] Remove ARCH_SHMOBILE

I think you forgot a proper prefix in the subject...

Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS

Hello. On 3/2/2016 4:14 AM, Simon Horman wrote: 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

Re: [PATCH] arm64: dts: r8a7795: Add CAN FD support

Hello. On 3/2/2016 10:29 AM, Ramesh Shanmugasundaram wrote: Adds CAN FD controller node for r8a7795. Note: CAN FD controller register base address specified in R-Car Gen3 Hardware User Manual v0.5E is incorrect. The correct address is: CAN FD - 0xe66c Signed-off-by: Ramesh

Re: [PATCH v2] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS

Hi Simon, Note that the patch subject still mentions sh_vou. Otherwise: Acked-by: Hans Verkuil Regards, Hans On 03/02/16 12:00, Laurent Pinchart wrote: > Hi Simon, > > Thank you for the patch. > > On Wednesday 02 March 2016 10:14:51 Simon Horman wrote: >>

Re: [PATCH 4/8] drivers/pinctrl: make sh-pfc/core.c explicitly non-modular

On Mon, Feb 29, 2016 at 9:48 PM, Paul Gortmaker wrote: > The Kconfig / Makefile currently controlling compilation of this code is: > > drivers/pinctrl/sh-pfc/Makefile:obj-$(CONFIG_PINCTRL_SH_PFC)+= sh-pfc.o > drivers/pinctrl/sh-pfc/Makefile:sh-pfc-objs

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

On 03/02/2016 11:08 AM, Ramesh Shanmugasundaram wrote: I see no locking for the tx-path. >>> >>> I am not sure why locking is needed in tx-path? >> >> If the tx-path is shared between both channels you need locking as the >> networking subsystem may send one frame to each controller at the

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

Hi Marc, > On 03/02/2016 09:41 AM, Ramesh Shanmugasundaram wrote: > >> Is the channel loopback mode configurable per channel? If so, please > >> remove the module parameter and make use of CAN_CTRLMODE_LOOPBACK to > >> configure it. > > > > The loopback setting is not truly a per channel

Re: [PATCH 2/2] phy: rcar-gen3-usb2: add fallback binding

On Wed, Mar 2, 2016 at 3:37 AM, Simon Horman wrote: > In the case of Renesas R-Car hardware we know that there are generations of > SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the > relationship between IP blocks might be. For example, I believe that

Re: [PATCH 1/2] phy: rcar-gen2: add fallback binding

On Wed, Mar 2, 2016 at 3:37 AM, Simon Horman wrote: > In the case of Renesas R-Car hardware we know that there are generations of > SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the > relationship between IP blocks might be. For example, I believe that

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

On Wed, Mar 2, 2016 at 3:25 AM, Simon Horman wrote: > 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

Re: [PATCH] usb: gadget: renesas_usb3: Use ARCH_RENESAS

On Wed, Mar 2, 2016 at 3:17 AM, Simon Horman wrote: > 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

Re: [PATCH] thermal: rcar: Use ARCH_RENESAS

On Wed, Mar 2, 2016 at 3:04 AM, Simon Horman wrote: > 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

Re: [PATCH] Remove ARCH_SHMOBILE

Hi Simon, On Wed, Mar 2, 2016 at 2:55 AM, Simon Horman wrote: > [PATCH] Remove ARCH_SHMOBILE Please use a more appropriate one-line summary. > Since the removal of legacy (non-multiplatform) support this driver has not > been used by any Renesas ARM based SoCs. > >

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

On 03/02/2016 09:41 AM, Ramesh Shanmugasundaram wrote: >> Is the channel loopback mode configurable per channel? If so, please >> remove the module parameter and make use of CAN_CTRLMODE_LOOPBACK to >> configure it. > > The loopback setting is not truly a per channel attribute. It > requires

Re: [PATCH net-next] sh_eth, ravb: Use ARCH_RENESAS

On Wed, Mar 2, 2016 at 2:28 AM, Simon Horman wrote: > 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

Re: [PATCH] pinctrl: sh-pfc: core: don't open code of_device_get_match_data()

On Tue, Mar 1, 2016 at 5:38 PM, Wolfram Sang wrote: > From: Wolfram Sang > > This change will also make Coverity happy by avoiding a theoretical NULL > pointer dereference; yet another reason is to use the above helper function > to tighten

Re: [PATCH 1/2] ASoC: sh: rcar: core: don't open code of_device_get_match_data()

On Tue, Mar 1, 2016 at 5:39 PM, Wolfram Sang wrote: > From: Wolfram Sang > > This change will also make Coverity happy by avoiding a theoretical NULL > pointer dereference; yet another reason is to use the above helper function > to tighten

Re: [PATCH] gpu: drm: rcar-du: rcar_du_drv: don't open code of_device_get_match_data()

On Tue, Mar 1, 2016 at 5:37 PM, Wolfram Sang wrote: > From: Wolfram Sang > > This change will also make Coverity happy by avoiding a theoretical NULL > pointer dereference; yet another reason is to use the above helper function > to tighten

Re: [PATCH] i2c: rcar: don't open code of_device_get_match_data()

On Tue, Mar 1, 2016 at 5:36 PM, Wolfram Sang wrote: > From: Wolfram Sang > > This change will also make Coverity happy by avoiding a theoretical NULL > pointer dereference; yet another reason is to use the above helper function > to tighten

Re: [PATCH] dmaengine: sh: shdmac: don't open code of_device_get_match_data()

On Tue, Mar 1, 2016 at 5:37 PM, Wolfram Sang wrote: > From: Wolfram Sang > > This change will also make Coverity happy by avoiding a theoretical NULL > pointer dereference; yet another reason is to use the above helper function > to tighten

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

Hi Oliver, Thanks for the review. > On 03/01/2016 10:34 AM, 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. Two > > test modes are available and can be enabled by the > >

Re: [PATCH] drivers: sh: Use ARCH_RENESAS

Hi Simon, On Wed, Mar 2, 2016 at 2:43 AM, Simon Horman wrote: > 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 >

Re: [PATCH] tty: sh-sci: Use ARCH_RENESAS

On Wed, Mar 2, 2016 at 2:35 AM, Simon Horman wrote: > 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

Re: [PATCH] iommu/ipmmu-vmsa: Add r8a7795 DT binding

Hi Magnus, On Mon, Feb 29, 2016 at 3:33 PM, Magnus Damm wrote: > From: Magnus Damm > > Update the IPMMU DT binding documentation to include the r8a7795 compat > string as well as the "renesas,ipmmu-main" property that on r8a7795 will > be used

Re: [PATCH] arm64: dts: r8a7795: Add CAN FD support

On Wed, Mar 02, 2016 at 07:29:04AM +, Ramesh Shanmugasundaram wrote: > Hi Sergei, > > > On 3/1/2016 1:04 PM, Ramesh Shanmugasundaram wrote: > > > > > Adds CAN FD controller node for r8a7795. > > > > > > Note: CAN FD controller register base address specified in R-Car Gen3 > > > Hardware User