Re: [PATCH] ARM: dma-mapping: Don't tear third-party mappings

Hi Laurent/Robin, On 5/16/2017 10:14 PM, Laurent Pinchart wrote: > Hi Robin, > > On Tuesday 16 May 2017 16:47:36 Robin Murphy wrote: >> On 16/05/17 16:14, Laurent Pinchart wrote: >>> arch_setup_dma_ops() is used in device probe code paths to create an >>> IOMMU mapping and attach it to the

Re: [PATCH v5 3/3] phy: Group vendor specific phy drivers

On 05/16/2017 03:40 PM, Kishon Vijay Abraham I wrote: Hi Vivek, On Thursday 11 May 2017 12:17 PM, Vivek Gautam wrote: Adding vendor specific directories in phy to group phy drivers under their respective vendor umbrella. Also updated the MAINTAINERS file to reflect the correct directory

[renesas:topic/sdhi-refactor-v2+sdhi-cmd23 6/7] ERROR: "renesas_sdhi_remove" [drivers/mmc/host/renesas_sdhi_sys_dmac.ko] undefined!

tree: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/sdhi-refactor-v2+sdhi-cmd23 head: 799c8fd6d9386e2ea6880a89c9de3fbb7a7994f7 commit: 2156a07053f52c85fba8b715116b0241d5fca25b [6/7] mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main module file config:

Re: ASoC: rsnd: fix sound route path when using SRC6/SRC9

Hi Geert > > @@ -70,16 +71,19 @@ static int rsnd_cmd_init(struct rsnd_mod *mod, > > } else { > > struct rsnd_mod *src = rsnd_io_to_mod_src(io); > > > > - u32 path[] = { > > - [0] = 0x3, > > - [1] = 0x30001, > >

Re: [PATCH v2] pinctrl: sh-pfc: r8a7796: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

Hi Geert > >> From: Kuninori Morimoto > >> > >> R-Car Gen3 is using SSI_{WS/SCK}349 instead of SSI_{WS/SCK}34. > >> But, current code is based on old datasheet which had typo. > >> This patch fixes this typo. > >> > >> Signed-off-by: Kuninori Morimoto

[PATCH v2 2/5] v4l: rcar-fcp: Add an API to retrieve the FCP device

The new rcar_fcp_get_device() function retrieves the struct device related to the FCP device. This is useful to handle DMA mapping through the right device. Signed-off-by: Laurent Pinchart --- drivers/media/platform/rcar-fcp.c | 6 ++

[PATCH v2 4/5] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP

The display buffers must be mapped for DMA through the device that performs memory access. Expose an API to map and unmap memory through the VSP device to be used by the DU. As all the buffers allocated by the DU driver are coherent, we can skip cache handling when mapping and unmapping them.

[PATCH v2 3/5] v4l: vsp1: Map the DL and video buffers through the proper bus master

From: Magnus Damm On Gen2 hardware the VSP1 is a bus master and accesses the display list and video buffers through DMA directly. On Gen3 hardware, however, memory accesses go through a separate IP core called FCP. The VSP1 driver unconditionally maps DMA buffers through

[PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device

For planes handled by a VSP instance, map the framebuffer memory through the VSP to ensure proper IOMMU handling. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 74 ---

[PATCH v2 1/5] v4l: rcar-fcp: Don't get/put module reference

Direct callers of the FCP API hold a reference to the FCP module due to module linkage, there's no need to take another one manually. Take a reference to the device instead to ensure that it won't disappear behind the caller's back. Signed-off-by: Laurent Pinchart

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

Hello, 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 iommu/devel/du On R-Car Gen3 the DU has no direct memory access but sources planes through VSP instances. When an

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

Hi Kieran, On Tue, May 16, 2017 at 01:56:05PM +0100, Kieran Bingham wrote: ... > +static int adv748x_afe_g_input_status(struct v4l2_subdev *sd, u32 > *status) > +{ > +struct adv748x_state *state = adv748x_afe_to_state(sd); > +int ret; > + > +

[renesas-drivers:master 101/531] drivers/media//platform/vsp1/vsp1_video.c:951:30: warning: missing braces around initializer

tree: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git master head: 1e9588d83e43b54a15094cd0fa125f8a5645d6ea commit: 5debeb08338b520f52577ca6cf9be815a54c07ea [101/531] v4l: vsp1: Provide a writeback video device config: xtensa-allmodconfig (attached as .config)

Re: [PATCH] ARM: dma-mapping: Don't tear third-party mappings

Hi Robin, On Tuesday 16 May 2017 16:47:36 Robin Murphy wrote: > On 16/05/17 16:14, Laurent Pinchart wrote: > > arch_setup_dma_ops() is used in device probe code paths to create an > > IOMMU mapping and attach it to the device. The function assumes that the > > device is attached to a

Re: [PATCH v3 00/09] arm64: dts: r8a7795: IPMMU upstream integration V3

Hi Magnus, On Mon, Mar 20, 2017 at 9:35 AM, Magnus Damm wrote: > arm64: dts: r8a7795: IPMMU upstream integration V3 > > [PATCH v3 01/09] arm64: dts: r8a7795: Add IPMMU device nodes > [PATCH v3 02/09] arm64: dts: r8a7795: Tie Audio/SYS-DMAC to IPMMU-DS0/1 and > MP1 >

renesas-drivers-2017-05-16-v4.12-rc1

I have pushed renesas-drivers-2017-05-16-v4.12-rc1 to https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git This tree is meant to ease development of platform support and drivers for Renesas ARM SoCs. It is created by merging (a) the for-next branches of various subsystem trees

Re: [PATCH] ARM: dma-mapping: Don't tear third-party mappings

On 16/05/17 16:14, Laurent Pinchart wrote: > arch_setup_dma_ops() is used in device probe code paths to create an > IOMMU mapping and attach it to the device. The function assumes that the > device is attached to a device-specific IOMMU instance (or at least a > device-specific TLB in a shared

Re: [PATCH v3 2/2] v4l: vsp1: Provide a writeback video device

Hi Kieran, On Tue, May 9, 2017 at 6:39 PM, Kieran Bingham wrote: > When the VSP1 is used in an active display pipeline, the output of the > WPF can supply the LIF entity directly and simultaneously write to > memory. > > Support this functionality in the

[PATCH] ARM: dma-mapping: Don't tear third-party mappings

arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific TLB in a shared IOMMU instance) and thus creates a separate mapping

Re: ASoC: rsnd: fix sound route path when using SRC6/SRC9

Hi Morimoto-san, On Fri, Mar 31, 2017 at 9:32 PM, Linux Kernel Mailing List wrote: > Web: > https://git.kernel.org/torvalds/c/a1c2ff53726907aff5feb37e4cfd45c1ff626431 > Commit: a1c2ff53726907aff5feb37e4cfd45c1ff626431 > Parent:

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

On 16/05/17 15:10, Laurent Pinchart wrote: > Hi Robin, > > On Tuesday 16 May 2017 15:04:55 Robin Murphy wrote: >> On 16/05/17 08:17, Laurent Pinchart wrote: >>> On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: > > [snip] > arch_teardown_dma_ops() being the inverse of

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Sricharan, On Tuesday 16 May 2017 19:59:01 sricha...@codeaurora.org wrote: > On 2017-05-16 19:40, Laurent Pinchart wrote: > > On Tuesday 16 May 2017 15:04:55 Robin Murphy wrote: > >> On 16/05/17 08:17, Laurent Pinchart wrote: > >> > On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi, On 2017-05-16 19:40, Laurent Pinchart wrote: Hi Robin, On Tuesday 16 May 2017 15:04:55 Robin Murphy wrote: On 16/05/17 08:17, Laurent Pinchart wrote: > On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: [snip] >> arch_teardown_dma_ops() being the inverse of

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Robin, On Tuesday 16 May 2017 15:04:55 Robin Murphy wrote: > On 16/05/17 08:17, Laurent Pinchart wrote: > > On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: [snip] > >> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops() > >> ,dma_ops should be cleared in the

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Sricharan, On Tuesday 16 May 2017 19:10:03 sricha...@codeaurora.org wrote: > On 2017-05-16 12:47, Laurent Pinchart wrote: > > On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: > >> On 2017-05-16 03:04, Laurent Pinchart wrote: > >>> On Monday 15 May 2017 23:37:16 Laurent Pinchart

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Laurent, On 16/05/17 08:17, Laurent Pinchart wrote: > Hi Sricharan, > > On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: >> On 2017-05-16 03:04, Laurent Pinchart wrote: >>> On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote: On Wednesday 03 May 2017 15:54:59 Sricharan R

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Laurent, On 2017-05-16 12:47, Laurent Pinchart wrote: Hi Sricharan, On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: On 2017-05-16 03:04, Laurent Pinchart wrote: > On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote: >> On Wednesday 03 May 2017 15:54:59 Sricharan R wrote:

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

Hi Sakari, (Gianluca, I've pulled you in on CC in respect to discussing changes you implemented for supporting GCC < 4.4.6) On 16/05/17 12:54, Sakari Ailus wrote: > Hi Kieran, > > On Mon, May 15, 2017 at 01:32:41PM +0100, Kieran Bingham wrote: >> Hi Sakari >> >> On 12/05/17 17:46, Sakari Ailus

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

Hi Kieran, On Mon, May 15, 2017 at 01:32:41PM +0100, Kieran Bingham wrote: > Hi Sakari > > On 12/05/17 17:46, Sakari Ailus wrote: > > Hi Kieran, > > > > Thanks for the patches! > > Thankyou for the review! You're welcome! :-) > > > Would you have a media-ctl -p && media-ctl --print-dot (or

Re: [PATCH v3] pinctrl: sh-pfc: r8a7794: add R8A7745 support

Hi Sergei, On Fri, Apr 28, 2017 at 8:52 PM, Sergei Shtylyov wrote: > Renesas RZ/G1E (R8A7745) is pin compatible with R-Car E2 (R8A7794), > however it doesn't have several automotive specific peripherals. > Annotate all the items that only exist on the R-Car

Re: [PATCH v4] pinctrl: sh-pfc: r8a7791: add R8A7743 support

Hi Sergei, On Thu, Apr 20, 2017 at 8:46 PM, Sergei Shtylyov wrote: > Renesas RZ/G1M (R8A7743) is pin compatible with R-Car M2-W/N (R8A7791/3), > however it doesn't have several automotive specific peripherals. Annotate > all the items that only exist on the

Re: [PATCH] ravb: add wake-on-lan support via magic packet

Hi Simon, On Tue, May 16, 2017 at 1:01 PM, Simon Horman wrote: > On Tue, May 16, 2017 at 11:07:34AM +0200, Geert Uytterhoeven wrote: >> On Tue, May 16, 2017 at 11:02 AM, Niklas Söderlund >> wrote: >> >> > Whit all this being said I still like

[RFC] i2c-stub: make it usable with DT when booting

This patch makes the stub driver parse the device tree when booting and create a virtual bus with the desired devices attached. Here is an example DTS snipplet making use of it. It is for simulating a more complex camera device which has dependencies which needs to be sorted out at boot time:

[PATCH 1/2] i2c: stub: move module_init/exit annotations to the proper place

Signed-off-by: Wolfram Sang --- drivers/i2c/i2c-stub.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/i2c-stub.c b/drivers/i2c/i2c-stub.c index 06af583d510150..0aa4d646f8fb26 100644 --- a/drivers/i2c/i2c-stub.c +++

[PATCH 2/2] i2c: stub: use pr_fmt

Instead of hard coding "i2c-stub:", let's use the pr_fmt mechanism to achieve the same more easily. This makes it easier to stay consistent when adding new messages. Also, remove an unneeded OOM message while we are here. Signed-off-by: Wolfram Sang ---

Re: [PATCH] ravb: add wake-on-lan support via magic packet

On Tue, May 16, 2017 at 11:07:34AM +0200, Geert Uytterhoeven wrote: > Hi Niklas, > > On Tue, May 16, 2017 at 11:02 AM, Niklas Söderlund > wrote: > >> > Whit all this being said I still like to withdraw this patch as I found > >> > another fault with it,

Re: [PATCH 2/2] pinctrl: sh-pfc: r8a7794: remove reserved bits

On Fri, Apr 28, 2017 at 7:50 PM, Sergei Shtylyov wrote: > The R8A7794 PFC driver was apparently based on the preliminary revisions > of the user's manual which had some signals and MOD_SEL register fields > described which the recent manual changed to

Re: [PATCH 1/2] pinctrl: sh-pfc: r8a7794: remove AVB_AVTP_* groups

On Fri, Apr 28, 2017 at 7:50 PM, Sergei Shtylyov wrote: > The ATA_AVTP_* signals are documented as reserved in the recent R-Car E2 > user's manual (the only remaining mention is in the table 5.2 and I believe > it's a simple overlook). Remove the AVB_AVTP_*

Re: [PATCH] pinctrl: sh-pfc: r8a7794: rename some I2C signals

On Thu, Apr 27, 2017 at 11:17 PM, Sergei Shtylyov wrote: > The R8A7794 PFC driver was apparently based on the preliminary revisions > of the user's manual which called I2C5 device IIC0 and IIC0 device IIC1. > Luckily, these signals haven't been used for any

Re: [PATCH v5 3/3] phy: Group vendor specific phy drivers

Hi Vivek, On Thursday 11 May 2017 12:17 PM, Vivek Gautam wrote: > Adding vendor specific directories in phy to group > phy drivers under their respective vendor umbrella. > > Also updated the MAINTAINERS file to reflect the correct > directory structure for phy drivers. > > Signed-off-by: Vivek

Re: [PATCH v2] pinctrl: sh-pfc: r8a7796: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

Hi Morimoto-san, On Tue, May 16, 2017 at 10:50 AM, Geert Uytterhoeven wrote: > On Tue, May 16, 2017 at 10:42 AM, Kuninori Morimoto > wrote: >> From: Kuninori Morimoto >> >> R-Car Gen3 is using

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Laurent, On Tue, May 16, 2017 at 10:17:08AM +0300, Laurent Pinchart wrote: > Hi Sricharan, > > On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: > > On 2017-05-16 03:04, Laurent Pinchart wrote: > > > On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote: > > >> On Wednesday 03

Re: [PATCH] ravb: add wake-on-lan support via magic packet

Hi Niklas, On Tue, May 16, 2017 at 11:02 AM, Niklas Söderlund wrote: >> > Whit all this being said I still like to withdraw this patch as I found >> > another fault with it, ravb_wol_restore() will unconditionally be called >> > while ravb_wol_setup() will only be

Re: [PATCH] ravb: add wake-on-lan support via magic packet

Hi Geert, Thanks for your feedback. On 2017-05-16 09:48:51 +0200, Geert Uytterhoeven wrote: > Hi Niklas, > > On Fri, May 12, 2017 at 11:12 PM, Niklas Söderlund > wrote: > > On 2017-05-12 16:43:55 +0200, Geert Uytterhoeven wrote: > >> On Fri, May 12, 2017 at 4:32

Re: [PATCH v2] pinctrl: sh-pfc: r8a7796: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

On Tue, May 16, 2017 at 10:42 AM, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > R-Car Gen3 is using SSI_{WS/SCK}349 instead of SSI_{WS/SCK}34. > But, current code is based on old datasheet which had typo. > This patch

Re: [PATCH v2] pinctrl: sh-pfc: r8a7795-es1: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

On Tue, May 16, 2017 at 10:42 AM, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > R-Car Gen3 is using SSI_{WS/SCK}349 instead of SSI_{WS/SCK}34. > But, current code is based on old datasheet which had typo. > This patch

[PATCH v2] pinctrl: sh-pfc: r8a7796: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

From: Kuninori Morimoto R-Car Gen3 is using SSI_{WS/SCK}349 instead of SSI_{WS/SCK}34. But, current code is based on old datasheet which had typo. This patch fixes this typo. Signed-off-by: Kuninori Morimoto --- v1 -> v2 -

[PATCH v2] pinctrl: sh-pfc: r8a7795: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

From: Kuninori Morimoto R-Car Gen3 is using SSI_{WS/SCK}349 instead of SSI_{WS/SCK}34. But, current code is based on old datasheet which had typo. This patch fixes this typo. Signed-off-by: Kuninori Morimoto --- v1 -> v2 -

[PATCH v2] pinctrl: sh-pfc: r8a7795-es1: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

From: Kuninori Morimoto R-Car Gen3 is using SSI_{WS/SCK}349 instead of SSI_{WS/SCK}34. But, current code is based on old datasheet which had typo. This patch fixes this typo. Signed-off-by: Kuninori Morimoto --- v1 -> v2 -

Re: [PATCH] pinctrl: sh-pfc: r8a7795-es1: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

Hi Geert > You forgot to change the string in ssi_groups[], like below? > > @@ -4509,7 +4509,7 @@ static const char * const ssi_groups[] = { > "ssi2_ctrl_a", > "ssi2_ctrl_b", > "ssi3_data", > - "ssi34_ctrl", > + "ssi349_ctrl", > "ssi4_data", >

Re: [PATCH] pinctrl: sh-pfc: r8a7795: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

On Tue, May 16, 2017 at 10:01 AM, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > R-Car Gen3 is using SSI_{WS/SCK}_349 instead of SSI_{WS/SCK}_34. > But, current code is based on old datasheet which had typo. > This patch

Re: [PATCH] pinctrl: sh-pfc: r8a7795-es1: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

Hi Morimoto-san, On Tue, May 16, 2017 at 10:01 AM, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > R-Car Gen3 is using SSI_{WS/SCK}_349 instead of SSI_{WS/SCK}_34. > But, current code is based on old datasheet which had

[PATCH] pinctrl: sh-pfc: r8a7796: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

From: Kuninori Morimoto R-Car Gen3 is using SSI_{WS/SCK}_349 instead of SSI_{WS/SCK}_34. But, current code is based on old datasheet which had typo. This patch fixes this typo. Signed-off-by: Kuninori Morimoto ---

[PATCH] pinctrl: sh-pfc: r8a7795-es1: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

From: Kuninori Morimoto R-Car Gen3 is using SSI_{WS/SCK}_349 instead of SSI_{WS/SCK}_34. But, current code is based on old datasheet which had typo. This patch fixes this typo. Signed-off-by: Kuninori Morimoto ---

[PATCH] pinctrl: sh-pfc: r8a7795: SSI_{WS/SCK}34 -> SSI_{WS/SCK}349

From: Kuninori Morimoto R-Car Gen3 is using SSI_{WS/SCK}_349 instead of SSI_{WS/SCK}_34. But, current code is based on old datasheet which had typo. This patch fixes this typo. Signed-off-by: Kuninori Morimoto ---

Re: [PATCH] ravb: add wake-on-lan support via magic packet

Hi Niklas, On Fri, May 12, 2017 at 11:12 PM, Niklas Söderlund wrote: > On 2017-05-12 16:43:55 +0200, Geert Uytterhoeven wrote: >> On Fri, May 12, 2017 at 4:32 PM, Niklas Söderlund >> wrote: >> > On 2017-05-12 14:58:53 +0200, Niklas

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Sricharan, On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: > On 2017-05-16 03:04, Laurent Pinchart wrote: > > On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote: > >> On Wednesday 03 May 2017 15:54:59 Sricharan R wrote: > >>> On 5/3/2017 3:24 PM, Robin Murphy wrote: >

Re: [PATCH v2 02/10] pinctrl: sh-pfc: r8a7796: add Audio SSI pin support

Hi Morimoto-san, On Tue, May 16, 2017 at 3:25 AM, Kuninori Morimoto wrote: >> >> Does this affect H3 ES1.0, too? >> >> My main worry there is that the name "ssi34_ctrl" is part of the DT ABI, >> >> so we have to keep that as an alias for "ssi349_ctrl". >> > >> >