increase of the residue. Fix this by introducing a 'safe read' logic.
Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for
residue")
Signed-off-by: Achim Dahlhoff
Signed-off-by: Dirk Behme
Cc: # v4.16+
---
Note: Patch done against mainline v5.0
Changes in v
tatus")
Signed-off-by: Dirk Behme
Signed-off-by: Achim Dahlhoff
Signed-off-by: Hiroyuki Yokoyama
Signed-off-by: Yao Lihua
Cc: # v4.8+
---
Note: Patch done against mainline v5.0
Changes in v2: None
Changes in v3: Move reading rchan into the spin lock protection.
drivers/dma/sh/rcar-
Hi Renesas SoC team,
On 05.03.2019 06:56, Dirk Behme wrote:
From: Achim Dahlhoff
The tx_status poll in the rcar_dmac driver reads the status register
which indicates which chunk is busy (DMACHCRB). Afterwards the point
inside the chunk is read from DMATCRB. It is possible that the chunk
has
tterhoeven
Acked-by: Dirk Behme
---
drivers/tty/serial/sh-sci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 060fcd42b6d56010..2bdaeba5d527a6ce 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/seria
Hi Geert,
On 29.03.2019 14:00, Geert Uytterhoeven wrote:
Hi Dirk,
On Fri, Mar 29, 2019 at 1:13 PM Dirk Behme wrote:
On 29.03.2019 10:46, Geert Uytterhoeven wrote:
On Fri, Mar 29, 2019 at 8:05 AM Dirk Behme wrote:
On 28.03.2019 12:30, Dirk Behme wrote:
On 28.03.2019 11:16, Dirk Behme
On 29.03.2019 10:46, Geert Uytterhoeven wrote:
Hi Dirk,
On Fri, Mar 29, 2019 at 8:05 AM Dirk Behme wrote:
On 28.03.2019 12:30, Dirk Behme wrote:
On 28.03.2019 11:16, Dirk Behme wrote:
On 28.03.2019 10:24, Geert Uytterhoeven wrote:
On Wed, Mar 27, 2019 at 7:36 PM Eugeniu Rosca
wrote
On 29.03.2019 10:46, Ulrich Hecht wrote:
On March 29, 2019 at 8:05 AM Dirk Behme wrote:
Hi Geert,
On 28.03.2019 12:30, Dirk Behme wrote:
On 28.03.2019 11:16, Dirk Behme wrote:
* Testing the patch [5]
- int shift = min(-8, max(7, deviation / 2));
+ int shift = clamp(deviation / 2, -8, 7
Hi Geert,
On 28.03.2019 12:30, Dirk Behme wrote:
On 28.03.2019 11:16, Dirk Behme wrote:
Hi Geert,
On 28.03.2019 10:24, Geert Uytterhoeven wrote:
Hi Eugeniu,
On Wed, Mar 27, 2019 at 7:36 PM Eugeniu Rosca
wrote:
We've recently switched from rcar-3.7.x to rcar-3.9.x [1] kernel and
On 28.03.2019 11:16, Dirk Behme wrote:
Hi Geert,
On 28.03.2019 10:24, Geert Uytterhoeven wrote:
Hi Eugeniu,
On Wed, Mar 27, 2019 at 7:36 PM Eugeniu Rosca
wrote:
We've recently switched from rcar-3.7.x to rcar-3.9.x [1] kernel and the
latter contains this patch [2] by virtue of rcar-
Hi Geert,
On 28.03.2019 10:24, Geert Uytterhoeven wrote:
Hi Eugeniu,
On Wed, Mar 27, 2019 at 7:36 PM Eugeniu Rosca wrote:
We've recently switched from rcar-3.7.x to rcar-3.9.x [1] kernel and the
latter contains this patch [2] by virtue of rcar-3.9.0 commit [3], which
mirrors v4.18-rc1 commit
tatus")
Signed-off-by: Dirk Behme
Signed-off-by: Achim Dahlhoff
Signed-off-by: Hiroyuki Yokoyama
Cc: # v4.8+
---
Note: Patch done against mainline v5.0
Changes in v2: None
drivers/dma/sh/rcar-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/sh/rca
increase of the residue. Fix this by introducing a 'safe read' logic.
Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for
residue")
Signed-off-by: Achim Dahlhoff
Signed-off-by: Dirk Behme
Cc: # v4.16+
---
Note: Patch done against mainline v5.0
Changes in v
tatus")
Signed-off-by: Dirk Behme
Signed-off-by: Achim Dahlhoff
Signed-off-by: Hiroyuki Yokoyama
Cc: # v4.8+
---
Note: Patch done against mainline v5.0
drivers/dma/sh/rcar-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/d
increase of the residue. Fix this by introducing a 'safe read' logic.
Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for
residue")
Signed-off-by: Achim Dahlhoff
Signed-off-by: Dirk Behme
Cc: # v4.16+
---
Note: Patch done against mainline v5.0
drivers/dma
On 30.06.2016 17:15, Niklas Söderlund wrote:
From: Muhammad Hamza Farooq
The hardware might have complete the transfer but the interrupt handler
might not have had a chance to run. If rcar_dmac_chan_get_residue()
which reads HW registers finds that there is no residue return
DMA_COMPLETE.
Sign
On 03.01.2018 18:25, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Sep 7, 2017 at 11:12 AM, Geert Uytterhoeven
wrote:
On Thu, Sep 7, 2017 at 11:05 AM, Dirk Behme wrote:
On 07.09.2017 10:59, Geert Uytterhoeven wrote:
On Thu, Sep 7, 2017 at 10:42 AM, Dirk Behme
wrote:
On 07.09.2017 10:39
On 03.01.2018 18:44, Mark Brown wrote:
The patch
spi: sh-msiof: Fix timeout failures for TX-only DMA transfers
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
Would it make sense to forward this to -stable, too?
Best regards
Dir
tterhoeven
Acked-by: Dirk Behme
---
v2
* Added Geert's Ack
Sorry for letting this slip through the cracks, it appears
to have been on my todo list for 1 year less 5 days.
Thanks for picking it :)
Best regards
Dirk
P.S.: The remaining msiof (DMA) patches are not forgotten, we are s
Hi Geert,
today, I want to learn some history ;)
On 12.11.2015 16:54, Geert Uytterhoeven wrote:
Add a new R-Car H3 Clock Pulse Generator / Module Standby and Software
Reset driver, using the new CPG/MSSR driver core.
Signed-off-by: Geert Uytterhoeven
---
...
diff --git a/drivers/clk/shmobil
Limiting the thread to Renesas only, again, to discuss the other issue:
On 17.10.2017 06:51, Yoshihiro Shimoda wrote:
Hi Linus-san,
From: Linus Walleij, Sent: Monday, October 16, 2017 9:22 PM
On Mon, Oct 16, 2017 at 2:07 PM, Geert Uytterhoeven
wrote:
On Mon, Oct 16, 2017 at 1:41 PM, Linus
On 12.10.2017 10:20, Dirk Behme wrote:
On 11.10.2017 15:20, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Oct 11, 2017 at 2:57 PM, Dirk Behme
wrote:
On 11.10.2017 14:42, Geert Uytterhoeven wrote:
On Wed, Oct 11, 2017 at 2:23 PM, Dirk Behme
wrote:
trying to boot recent mainline v4.14-rc4 on a
Hi Geert,
On 11.10.2017 14:42, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Oct 11, 2017 at 2:23 PM, Dirk Behme wrote:
trying to boot recent mainline v4.14-rc4 on a custom H3 ES2.0 board with
rootfs on SD card I'm getting [1].
Last time I think I used v4.13 in the same environment and I
Hi,
trying to boot recent mainline v4.14-rc4 on a custom H3 ES2.0 board with
rootfs on SD card I'm getting [1].
Last time I think I used v4.13 in the same environment and I think it
worked fine, most probably because renesas_sdhi_internal_dmac wasn't
there, yet ;)
I checked renesas-drivers
On 07.09.2017 10:59, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Sep 7, 2017 at 10:42 AM, Dirk Behme wrote:
On 07.09.2017 10:39, Geert Uytterhoeven wrote:
On Thu, Sep 7, 2017 at 10:33 AM, Dirk Behme
wrote:
On 07.09.2017 10:31, Geert Uytterhoeven wrote:
On Wed, Sep 6, 2017 at 9:05 AM, Dirk
On 07.09.2017 10:39, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Sep 7, 2017 at 10:33 AM, Dirk Behme wrote:
On 07.09.2017 10:31, Geert Uytterhoeven wrote:
On Wed, Sep 6, 2017 at 9:05 AM, Dirk Behme
wrote:
From: Hiromitsu Yamasaki
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2
On 07.09.2017 10:33, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Sep 6, 2017 at 9:05 AM, Dirk Behme wrote:
From: Ryo Kataoka
When reception DMA completes before transmission DMA, next transmission
DMA may not be able to start. This patch adds wait_for_completion_timeout()
to both of
On 07.09.2017 10:31, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Sep 6, 2017 at 9:05 AM, Dirk Behme wrote:
From: Hiromitsu Yamasaki
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Dirk Behme
---
drivers/spi
On 07.09.2017 10:11, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Sep 6, 2017 at 9:05 AM, Dirk Behme wrote:
From: Hiromitsu Yamasaki
This patch is for debug of transfer between master and slave.
Since the slave needs to complete a preparation in data transfer
before the master working, the
On 07.09.2017 09:04, Vladimir Zapolskiy wrote:
Hi Dirk,
On 09/06/2017 10:05 AM, Dirk Behme wrote:
From: Hiromitsu Yamasaki
This patch is for debug of transfer between master and slave.
Since the slave needs to complete a preparation in data transfer
before the master working, the sleep wait
On 06.09.2017 12:42, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Sep 6, 2017 at 12:09 PM, Dirk Behme wrote:
On 06.09.2017 11:22, Geert Uytterhoeven wrote:
On Wed, Sep 6, 2017 at 9:05 AM, Dirk Behme
wrote:
From: Ryo Kataoka
MSIOF Base Address H'E6xx can be accessed by CPU and DMAC.
On 06.09.2017 11:22, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Sep 6, 2017 at 9:05 AM, Dirk Behme wrote:
From: Ryo Kataoka
MSIOF Base Address H'E6xx can be accessed by CPU and DMAC.
MSIOF Base Address H'E7xx for DMAC was removed from H/W manual.
Signed-off-by: Ryo Kataoka
Sig
From: Hiromitsu Yamasaki
This patch is for debug of transfer between master and slave.
Since the slave needs to complete a preparation in data transfer
before the master working, the sleep wait is put before
the data transfer of the master.
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Dirk
From: Hiromitsu Yamasaki
When Tx DMA is only used, Tx FIFO is still not empty after DMA callback.
This patch waits for sweeping data out of the Tx FIFO.
Signed-off-by: Hiromitsu Yamasaki
[adjust context]
Signed-off-by: Dirk Behme
---
drivers/spi/spi-sh-msiof.c | 13 -
1 file
From: Ryo Kataoka
MSIOF Base Address H'E6xx can be accessed by CPU and DMAC.
MSIOF Base Address H'E7xx for DMAC was removed from H/W manual.
Signed-off-by: Ryo Kataoka
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Dirk Behme
---
drivers/spi/spi-sh-msiof.c | 5 +
1 file
From: Hiromitsu Yamasaki
Reset register before starting transfer.
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Dirk Behme
---
drivers/spi/spi-sh-msiof.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
From: Hiromitsu Yamasaki
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Dirk Behme
---
drivers/spi/spi-sh-msiof.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-sh-msiof.c b
From: Hiromitsu Yamasaki
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Dirk Behme
---
drivers/spi/spi-sh-msiof.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index a960e8da123d..2c53fc3f73af 100644
--- a
of DMA Engine may be still processing.
Signed-off-by: Ryo Kataoka
[reword commit message]
Signed-off-by: Hiromitsu Yamasaki
[adjust context]
Signed-off-by: Dirk Behme
---
drivers/spi/spi-sh-msiof.c | 53 +++---
1 file changed, 36 insertions(+), 17
Pick some patches and fixes from Renesas v4.9/rcar-3.5.8 BSP to make spi
on RCar3 more reliably.
Patches are done against renesas-drivers-2017-09-05-v4.13.
Should we consider
spi: sh-msiof: Fix DMA transfer size check
spi: sh-msiof: Fix MSIOF address for DMAC
for -stable?
Both have been introd
0 {
...
reg = <0>;
...
};
spidev@1 {
...
reg = <1>;
...
};
};
Signed-off-by: Hiromitsu Yamasaki
Signed-off-by: Dirk Behme
---
drivers/spi/spi-sh-msiof.c | 9 +++--
1 file
rt for R-Car H3 ES2.0"). As the DRIF doesn't differ, re-add
it here.
Signed-off-by: Dirk Behme
---
Patch based on sh-pfc-for-v4.14-tag1
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 291 +++
1 file changed, 291 insertions(+)
diff --git a/drivers/pinctr
On 30.08.2017 08:48, Simon Horman wrote:
On Tue, Aug 29, 2017 at 12:36:50PM +0200, Dirk Behme wrote:
On 29.08.2017 11:44, Geert Uytterhoeven wrote:
Hi Dirk,
On Tue, Aug 29, 2017 at 11:15 AM, Dirk Behme wrote:
But ZG and with this module clock #112 is still missing, no?
https
On 29.08.2017 11:44, Geert Uytterhoeven wrote:
Hi Dirk,
On Tue, Aug 29, 2017 at 11:15 AM, Dirk Behme wrote:
But ZG and with this module clock #112 is still missing, no?
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=aa7b99b06d280e4
On 29.08.2017 10:01, Geert Uytterhoeven wrote:
Hi Dirk,
On Tue, Aug 29, 2017 at 9:51 AM, Dirk Behme wrote:
as mentioned previously since ages I'm back looking at the RCar3 status in
recent mainline (4.13-rc7). While doing so, it looks to me that some Z*
clock patches from recent BSP
Hi,
as mentioned previously since ages I'm back looking at the RCar3 status
in recent mainline (4.13-rc7). While doing so, it looks to me that some
msiof fixes from recent BSP
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/log/?h=v4.9/rcar-3.5.8
are not in mainline, ye
Hi,
as mentioned previously since ages I'm back looking at the RCar3 status
in recent mainline (4.13-rc7). While doing so, it looks to me that some
Z* clock patches from recent BSP
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/log/?h=v4.9/rcar-3.5.8
are not in mainlin
On 22.08.2017 08:56, Wolfram Sang wrote:
I'm not an expert on this, does SDR104 need 1.8V?
To my understanding, sd-uhs-sdr50 is the max speed for 3.3V?
Nope, everything with SDR* needs 1.8V. So, classic "highspeed" is the
maximum for your slot.
I ask because on my custom board the hardware
Add SDHIx support for ES2.0. Taken from the Renesas BSP
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
Signed-off-by: Dirk Behme
---
Note: Patch is generated against renesas-drivers-2017-08-16-v4.13-rc5
Changes in v2: Fix a typo
On 21.08.2017 15:47, Wolfram Sang wrote:
It works, now :)
Great!
tmio_mmc_init_ocr()
fails (silently!). And with this the whole RCar3 SDHI, without any error
message.
I'll check next week about an error message there.
Many thanks for your help!
You're welcome. If you want, you can ev
Add SDHIx support for ES2.0. Taken from the Renesas BSP
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
Signed-off-by: Dirk Behme
---
Note: Patch is generated against renesas-drivers-2017-08-16-v4.13-rc5
drivers/pinctrl/sh-pfc
On 21.08.2017 10:24, Dirk Behme wrote:
On 21.08.2017 10:18, Wolfram Sang wrote:
Hi Dirk,
Ah, ES2.0. That's the missing information. Yup, is on the todo-list. I
will try to test your patch on my Salvator-XS board today.
Ok, thanks :)
Your patch on top of v4.13-rc5 makes SDHI work
On 21.08.2017 10:18, Wolfram Sang wrote:
Hi Dirk,
Ah, ES2.0. That's the missing information. Yup, is on the todo-list. I
will try to test your patch on my Salvator-XS board today.
Ok, thanks :)
Your patch on top of v4.13-rc5 makes SDHI work on my Salvator-XS with a
Please feel free to fo
On 18.08.2017 11:00, Wolfram Sang wrote:
What's the status of SDHI support in mainline and/or renesas-drivers
(renesas-drivers-2017-08-16-v4.13-rc5)?
I use it daily here, even with SDR104 enabled.
On ES2.0? I wonder how if not even the pinmux is there ;)
Ah, ES2.0. That's the missing info
On 17.08.2017 09:29, Wolfram Sang wrote:
What's the status of SDHI support in mainline and/or renesas-drivers
(renesas-drivers-2017-08-16-v4.13-rc5)?
I use it daily here, even with SDR104 enabled.
On ES2.0? I wonder how if not even the pinmux is there ;)
sdhci-pltfm: SDHCI platform and
On 17.08.2017 09:48, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Aug 17, 2017 at 9:44 AM, Dirk Behme wrote:
On 17.08.2017 09:33, Geert Uytterhoeven wrote:
On Thu, Aug 17, 2017 at 9:23 AM, Dirk Behme
wrote:
since ages I tried recent mainline (v4.13-rc5) on a custom r8a7795 board.
R-Car H3
On 17.08.2017 09:33, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Aug 17, 2017 at 9:23 AM, Dirk Behme wrote:
since ages I tried recent mainline (v4.13-rc5) on a custom r8a7795 board.
R-Car H3 ES1.x or ES2.0?
ES2.0
I tried with the attachment and picked some patches from
renesas-drivers
F driver helper
hidraw: raw HID events driver (C) Jiri Kosina
NET: Registered protocol family 17
...
From ae0ba44723548f835824ad8f2f96dd971cfedb0f Mon Sep 17 00:00:00 2001
From: Dirk Behme
Date: Thu, 17 Aug 2017 08:02:14 +0200
Subject: [PATCH] pinctrl: sh-pfc: r8a7795: Add SDHIx support
Taken from
On 01.07.2017 20:14, Uwe Kleine-König wrote:
Hello,
On Sat, Jul 01, 2017 at 07:02:48AM +0200, Dirk Behme wrote:
On 30.06.2017 22:24, Uwe Kleine-König wrote:
Hello,
On Fri, Jun 30, 2017 at 10:58:26AM -0500, Rob Herring wrote:
TL;DR: Clocks may be in use by another CPU not running Linux
to start a Linux kernel on a Cortex-M companion to a Cortex-A.
On Mon, Jun 26, 2017 at 1:30 PM, Dirk Behme wrote:
With commit 72f5df2c2bbb6 ("clk: renesas: cpg-mssr: Migrate to
CLK_IS_CRITICAL") we are able to handle critical module clocks.
Introduce the same logic for critical c
On 29.06.2017 13:18, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Jun 29, 2017 at 12:28 PM, Dirk Behme wrote:
On 29.06.2017 11:27, Geert Uytterhoeven wrote:
CC clock, ARM, DT, PM people
TL;DR: Clocks may be in use by another CPU not running Linux, while Linux
disables them as being unused
On 29.06.2017 14:45, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Jun 29, 2017 at 2:07 PM, Dirk Behme wrote:
On 29.06.2017 13:56, Geert Uytterhoeven wrote:
On Thu, Jun 29, 2017 at 11:27 AM, Geert Uytterhoeven
wrote:
CC clock, ARM, DT, PM people
TL;DR: Clocks may be in use by another CPU not
On 29.06.2017 13:56, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Jun 29, 2017 at 11:27 AM, Geert Uytterhoeven
wrote:
CC clock, ARM, DT, PM people
TL;DR: Clocks may be in use by another CPU not running Linux, while Linux
disables them as being unused.
Of course this is not limited to clocks,
On 29.06.2017 11:27, Geert Uytterhoeven wrote:
Hi Dirk,
CC clock, ARM, DT, PM people
TL;DR: Clocks may be in use by another CPU not running Linux, while Linux
disables them as being unused.
On Mon, Jun 26, 2017 at 1:30 PM, Dirk Behme wrote:
With commit 72f5df2c2bbb6 ("clk: renesas: cpg
With commit 72f5df2c2bbb6 ("clk: renesas: cpg-mssr: Migrate to
CLK_IS_CRITICAL") we are able to handle critical module clocks.
Introduce the same logic for critical core clocks.
Signed-off-by: Dirk Behme
---
Commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.
On 29.04.2017 11:55, Wolfram Sang wrote:
Hi Dirk,
Checking the recent kernel [1] it seems to me that this changes never made
it into mainline.
Does anybody remember why and/or the history?
As for Ulf, it was RFC, so no urge to pick it up. As for me, I was
waiting for more feedback and then i
Hi,
On 26.01.2016 12:46, Wolfram Sang wrote:
Honestly, I still think this is a micro-optimization: Assuming SCLKDIVEN is
basically CBSY plus 8 SD clock cycles, then we'd save in the best case (SD
clock is slowest, 24 MHz) around 333ns while we are polling with 1 us
granularity...
However, in ca
Hi Geert,
I've been offline some weeks, so sorry if I'm not completely up to date,
yet, or miss anything.
Overall, having a quick look, the proposal in this patch series and your
second series "arm64: renesas: r8a7795: R-Car H3 ES2.0 Prototype" looks
nice to me. At least much better than enc
Hi Simon,
On 21.07.2016 01:51, Simon Horman wrote:
On Wed, Jun 29, 2016 at 10:15:27AM +0200, Dirk Behme wrote:
Hi Simon,
...
Hmm, could you kindly help me to remember what's the recent status of your
discussion above regarding a hierarchical structure of the RCar3 device
trees?
Hi
0 0
Note that I still have a Salvator-X with a 16.67 MHz i.s.o. 33.33 Mhz crystal.
Wolfram, Dirk: any comments?
I think this has changed (corrected?) in the manual since
90c073e53909da85 ("clk: shmobile: r8a7795: Add SD divider support")
Acked-by: Dirk Behme
Best regards
Dirk
-
Hi Wolfram,
On 06.06.2016 18:08, Wolfram Sang wrote:
From: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Wolfram Sang
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/b
Hi Simon,
On 27.05.2016 09:32, Dirk Behme wrote:
Hi Simon,
On 27.05.2016 02:42, Simon Horman wrote:
On Thu, May 26, 2016 at 09:14:16AM +0200, Dirk Behme wrote:
Hi Simon,
On 26.05.2016 04:28, Simon Horman wrote:
Hi Dirk,
On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote:
Hi Simon
Hi Geert,
On 10.06.2016 08:34, Dirk Behme wrote:
Hi Geert,
On 09.06.2016 10:54, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Jun 9, 2016 at 10:31 AM, Dirk Behme
wrote:
On 07.06.2016 10:17, Geert Uytterhoeven wrote:
On Tue, Jun 7, 2016 at 9:53 AM, Dirk Behme
wrote:
I think I just want to
Hi Magnus,
On 01.06.2016 07:19, Magnus Damm wrote:
Hi Dirk,
On Fri, May 27, 2016 at 4:56 PM, Dirk Behme wrote:
On 27.05.2016 05:13, Magnus Damm wrote:
I don't think anyone disagrees that it makes sense to be able to
determine ES version during runtime. The questions in my mind are how
On 10.06.2016 09:58, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Jun 2, 2016 at 7:42 AM, Dirk Behme wrote:
+int __init rcar_rst_read_mode_pins(u32 *mode)
Just a style issue: Is the string 'pins' in the function name still
relevant? I.e. what's about just 'rcar_rst_re
Hi Geert,
On 09.06.2016 10:54, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Jun 9, 2016 at 10:31 AM, Dirk Behme wrote:
On 07.06.2016 10:17, Geert Uytterhoeven wrote:
On Tue, Jun 7, 2016 at 9:53 AM, Dirk Behme
wrote:
I think I just want to discuss if we have a clever idea to further
improve
Hi Geert,
On 09.06.2016 11:20, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Jun 9, 2016 at 10:58 AM, Dirk Behme wrote:
On 09.06.2016 10:22, Geert Uytterhoeven wrote:
On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme
wrote:
with the R-Car3, the pinmux/drvctrl is done at 3 places:
1. ARM trusted
Hi Geert,
On 09.06.2016 10:22, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme wrote:
with the R-Car3, the pinmux/drvctrl is done at 3 places:
1. ARM trusted firmware / IPL:
https://github.com/renesas-rcar/meta-renesas/blob/jethro/meta-rcar-gen3/recipes-bsp
Hi Geert,
On 07.06.2016 10:17, Geert Uytterhoeven wrote:
Hi Dirk,
On Tue, Jun 7, 2016 at 9:53 AM, Dirk Behme wrote:
I think I just want to discuss if we have a clever idea to further improve
one detail. That is, if we have a clever idea to avoid the copy & paste
between the family mem
Hi,
with the R-Car3, the pinmux/drvctrl is done at 3 places:
1. ARM trusted firmware / IPL:
https://github.com/renesas-rcar/meta-renesas/blob/jethro/meta-rcar-gen3/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware/0001-add-bl2-bl31-R-Car-support.patch#L8428
2. U-Boot:
https://github.com/
Hi Geert,
On 06.06.2016 14:59, Geert Uytterhoeven wrote:
Hi Dirk,
On Mon, Jun 6, 2016 at 2:03 PM, Dirk Behme wrote:
On 30.05.2016 18:36, Dirk Behme wrote:
On 30.05.2016 18:28, Geert Uytterhoeven wrote:
Add all R-Car M3-W Clock Pulse Generator Core Clock Outputs, as listed
in Table 8.2b
Hi Geert,
On 30.05.2016 18:36, Dirk Behme wrote:
Hi Geert,
On 30.05.2016 18:28, Geert Uytterhoeven wrote:
Add all R-Car M3-W Clock Pulse Generator Core Clock Outputs, as listed
in Table 8.2b ("List of Clocks [R-Car M3-W]") of the R-Car Gen3
datasheet (rev. 0.51 + Errata for Rev051 M
car-rst.c
create mode 100644 include/linux/soc/renesas/rcar-rst.h
Whole series:
Acked-by: Dirk Behme
Thanks!
Dirk
On 01.06.2016 21:21, Geert Uytterhoeven wrote:
The R-Car M1A board code no longer calls r8a7778_clocks_init().
Signed-off-by: Geert Uytterhoeven
---
v3:
- New.
---
drivers/clk/renesas/clk-r8a7778.c | 13 -
include/linux/clk/renesas.h | 1 -
2 files changed, 14 deletions(-)
On 01.06.2016 21:21, Geert Uytterhoeven wrote:
Add a driver for the Renesas R-Car Gen1 RESET/WDT and R-Car Gen2/Gen3
RST module.
For now this driver just provides an API to obtain the state of the mode
pins, as latched at reset time. As this is typically called from the
probe function of a cloc
On 01.06.2016 21:20, Geert Uytterhoeven wrote:
Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
RESET/WDT and R-Car Gen2/Gen3 RST).
As the features provided by the hardware module differ a lot across the
various SoC families and members, only SoC-specific compatible values
are
Hi Geert,
On 01.06.2016 10:26, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Jun 1, 2016 at 9:38 AM, Dirk Behme wrote:
Sorry, if that was unclear. I took the example and transferred it to R-Car3
where we have ES1 - ES3.
So, taking this example, on R-Car3 we might end up with
On 01.06.2016 10:40, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Jun 1, 2016 at 10:36 AM, Dirk Behme wrote:
On 01.06.2016 10:26, Geert Uytterhoeven wrote:
On Wed, Jun 1, 2016 at 9:38 AM, Dirk Behme
wrote:
Sorry, if that was unclear. I took the example and transferred it to
R-Car3
where we
Hi Geert,
On 01.06.2016 09:27, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, Jun 1, 2016 at 9:19 AM, Dirk Behme wrote:
On 01.06.2016 07:19, Magnus Damm wrote:
On Fri, May 27, 2016 at 4:56 PM, Dirk Behme
wrote:
On 27.05.2016 05:13, Magnus Damm wrote:
I don't think anyone disagrees th
Hi Magnus,
On 01.06.2016 07:19, Magnus Damm wrote:
Hi Dirk,
On Fri, May 27, 2016 at 4:56 PM, Dirk Behme wrote:
On 27.05.2016 05:13, Magnus Damm wrote:
I don't think anyone disagrees that it makes sense to be able to
determine ES version during runtime. The questions in my mind are how
Hi Geert,
On 30.05.2016 18:28, Geert Uytterhoeven wrote:
Add all R-Car M3-W Clock Pulse Generator Core Clock Outputs, as listed
in Table 8.2b ("List of Clocks [R-Car M3-W]") of the R-Car Gen3
datasheet (rev. 0.51 + Errata for Rev051 Mar 31 2016).
Note that internal CPG clocks (S0, S1, S2, S3, S
On 30.05.2016 18:00, Ulrich Hecht wrote:
From: Koji Matsuoka
Signed-off-by: Koji Matsuoka
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 97 -
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 8 +++
drivers/gpu/drm/rcar-du/rcar_du
Hi Magnus,
On 27.05.2016 11:56, Magnus Damm wrote:
Hi Dirk,
On Fri, May 27, 2016 at 5:16 PM, Dirk Behme wrote:
Hi Magnus,
On 27.05.2016 05:40, Magnus Damm wrote:
Hi Dirk,
On Wed, May 25, 2016 at 5:58 PM, Dirk Behme
wrote:
Instead of hard coding the product register in the rcar-du
On 27.05.2016 10:39, Geert Uytterhoeven wrote:
On Fri, May 27, 2016 at 9:56 AM, Dirk Behme wrote:
Given the use of PRR you saw is in a patch that's definitely not ready for
upstream, I think adding a full-fledged PRR driver is a bit premature.
I don't think anyone disagrees tha
Hi Magnus,
On 27.05.2016 05:40, Magnus Damm wrote:
Hi Dirk,
On Wed, May 25, 2016 at 5:58 PM, Dirk Behme wrote:
Instead of hard coding the product register in the rcar-du, use
the framework for it to get the SoC version and the revision needed
for the enabling the workaround.
Signed-off-by
Hi Magnus,
On 27.05.2016 05:13, Magnus Damm wrote:
Hi Dirk,
On Thu, May 26, 2016 at 4:48 PM, Dirk Behme wrote:
Hi Geert,
On 26.05.2016 09:14, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, May 25, 2016 at 10:58 AM, Dirk Behme
wrote:
Instead of hard coding the product register in
Hi Simon,
On 27.05.2016 02:42, Simon Horman wrote:
On Thu, May 26, 2016 at 09:14:16AM +0200, Dirk Behme wrote:
Hi Simon,
On 26.05.2016 04:28, Simon Horman wrote:
Hi Dirk,
On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote:
Hi Simon,
On 25.05.2016 02:48, Simon Horman wrote:
Hi
Hi Geert,
On 26.05.2016 10:05, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, May 26, 2016 at 9:32 AM, Dirk Behme wrote:
On 26.05.2016 09:03, Geert Uytterhoeven wrote:
On Wed, May 25, 2016 at 9:32 AM, Dirk Behme
wrote:
P.S.: This also results in the question why we need similar
r8a7795-cpg
Hi Geert,
On 26.05.2016 09:14, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, May 25, 2016 at 10:58 AM, Dirk Behme wrote:
Instead of hard coding the product register in rcar_du_crtc.c,
read it based on the device tree.
This patch series is based on
https://git.kernel.org/cgit/linux/kernel/git
On 26.05.2016 09:03, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, May 25, 2016 at 9:32 AM, Dirk Behme wrote:
P.S.: This also results in the question why we need similar
r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for
the same clocks. Can't we use the
Hi Simon,
On 26.05.2016 04:28, Simon Horman wrote:
Hi Dirk,
On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote:
Hi Simon,
On 25.05.2016 02:48, Simon Horman wrote:
Hi Dirk,
On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
Hi Simon,
[...]
With Renesas R-Car3 we will
1 - 100 of 195 matches
Mail list logo
