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
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
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:
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,
> >
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
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 ++
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.
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
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 ---
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
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
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;
> +
> +
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)
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
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
>
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
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
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
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
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:
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
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
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
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
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
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
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:
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
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
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
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
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
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:
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
+++
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
---
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,
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
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_*
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
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
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
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
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
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
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
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
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
-
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
-
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
-
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",
>
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
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
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
---
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
---
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
---
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
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:
>
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".
>> >
>> >
58 matches
Mail list logo