Re: [PATCH 13/13] sh: lib: convert to SPDX identifiers
On Mon, 20 Aug 2018 10:37:49 +0900, Kuninori Morimoto wrote: > > > Hi Simon, Sato-san > > > > From: Kuninori Morimoto > > > > > > This patch updates license to use SPDX-License-Identifier > > > instead of verbose license text. > > > > > > Signed-off-by: Kuninori Morimoto > > > --- > (snip) > > > -In addition to the permissions in the GNU General Public License, the > > > -Free Software Foundation gives you unlimited permission to link the > > > -compiled version of this file into combinations with other programs, > > > -and to distribute those combinations without any restriction coming > > > -from the use of this file. (The General Public License restrictions > > > -do apply in other respects; for example, they cover modification of > > > -the file, and distribution when not linked into a combine > > > -executable.) > > > > Given the above clause I wonder if the SPDX identifier should be: > > > > SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0 > > Ahh, indeed. > I will post v2 patch. > Sato-san, can I post [13/13 v2] only ? or should post all patches ? > Please sent all patches. Thanks. -- Yosinori Sato
[PATCH] clk: renesas: cpg-mssr: Add R7S9210 support
Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
Standby.
The Module Standby HW in the RZ/A series is very close to R-Car HW, except
for how the registers are laid out.
The MSTP registers are only 8-bits wide, there is no status registers
(MSTPST), and the register offsets are a little different. Since the RZ/A
hardware manuals refer to these registers as the Standby Control Registers,
we'll use that name to distinguish the RZ/A type for the R-Car type.
Signed-off-by: Chris Brandt
---
.../devicetree/bindings/clock/renesas,cpg-mssr.txt | 3 +-
drivers/clk/renesas/Kconfig| 5 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r7s9210-cpg-mssr.c | 189 +
drivers/clk/renesas/renesas-cpg-mssr.c | 66 +--
drivers/clk/renesas/renesas-cpg-mssr.h | 6 +
include/dt-bindings/clock/r7s9210-cpg-mssr.h | 21 +++
7 files changed, 280 insertions(+), 11 deletions(-)
create mode 100644 drivers/clk/renesas/r7s9210-cpg-mssr.c
create mode 100644 include/dt-bindings/clock/r7s9210-cpg-mssr.h
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
index db542abadb75..66ca973edd77 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
@@ -13,6 +13,7 @@ They provide the following functionalities:
Required Properties:
- compatible: Must be one of:
+ - "renesas,r7s9210-cpg-mssr" for the r7s9210 SoC (RZ/A2)
- "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M)
- "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E)
- "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C)
@@ -37,7 +38,7 @@ Required Properties:
- clock-names: List of external parent clock names. Valid names are:
- "extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7792,
r8a7793, r8a7794, r8a7795, r8a7796, r8a77965, r8a77970,
-r8a77980, r8a77990, r8a77995)
+r8a77980, r8a77990, r8a77995, r7s9210)
- "extalr" (r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
- "usb_extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7793,
r8a7794)
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index 9022bbe1297e..d8ccdaba5103 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -3,6 +3,7 @@ config CLK_RENESAS
default y if ARCH_RENESAS
select CLK_EMEV2 if ARCH_EMEV2
select CLK_RZA1 if ARCH_R7S72100
+ select CLK_R7S9210 if ARCH_R7S9210
select CLK_R8A73A4 if ARCH_R8A73A4
select CLK_R8A7740 if ARCH_R8A7740
select CLK_R8A7743 if ARCH_R8A7743
@@ -45,6 +46,10 @@ config CLK_RZA1
bool "RZ/A1H clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
+config CLK_R7S9210
+ bool "RZ/A2 clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSSR
+
config CLK_R8A73A4
bool "R-Mobile APE6 clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index e4aa3d6143d2..d95bfd758a14 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -2,6 +2,7 @@
# SoC
obj-$(CONFIG_CLK_EMEV2)+= clk-emev2.o
obj-$(CONFIG_CLK_RZA1) += clk-rz.o
+obj-$(CONFIG_CLK_R7S9210) += r7s9210-cpg-mssr.o
obj-$(CONFIG_CLK_R8A73A4) += clk-r8a73a4.o
obj-$(CONFIG_CLK_R8A7740) += clk-r8a7740.o
obj-$(CONFIG_CLK_R8A7743) += r8a7743-cpg-mssr.o
diff --git a/drivers/clk/renesas/r7s9210-cpg-mssr.c
b/drivers/clk/renesas/r7s9210-cpg-mssr.c
new file mode 100644
index ..8b4bdd0ec06a
--- /dev/null
+++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * r7s9210 Clock Pulse Generator / Module Standby and Software Reset
+ *
+ * Based on r8a7795-cpg-mssr.c
+ *
+ * Copyright (C) 2018 Chris Brandt
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ *
+ */
+
+#include
+#include
+#include
+#include "renesas-cpg-mssr.h"
+
+#define CPG_FRQCR 0x00
+#define CPG_CKIOSEL0xF0
+#define CPG_SCLKSEL0xF4
+
+#define PORTL_PIDR 0xFCFFE074
+static u8 cpg_mode;
+
+/* Internal Clock ratio table */
+static const unsigned int ratio_tab[5][5] = {
+ /* I, G, B, P1, P0 */
+ { 2, 4, 8, 16, 32 }, /* FRQCR = 0x012 */
+ { 4, 4, 8, 16, 32 }, /* FRQCR = 0x112 */
+ { 8, 4, 8, 16, 32 }, /* FRQCR = 0x212 */
+ { 16, 8, 16, 16, 32 }, /* FRQCR = 0x322 */
+ { 16, 16, 32, 32, 32 }, /* FRQCR = 0x333 */
+ };
+
+enum rz_clk_types {
+
Re: [PATCH v2 0/7] mmc: tmio: refactor TMIO core a bit and add UniPhier SD/eMMC controller support
Hi Wolfram, 2018-08-21 4:07 GMT+09:00 Wolfram Sang : > > So, today I did test these patches successfully on a Gen3 board (M3-N) > and reviewed half of the patches. I will continue tomorrow with > reviewing and testing more boards. > > In a nutshell, things look good so far. > Thanks for the review! But, this version is not applicable to Linus' tree due to commit db924bba47c80. Resolving the conflict is not trivial. I will rebase and send v3, but I do not understand the quirks Renesas is adding to the TMIO core code. -- Best Regards Masahiro Yamada
Re: [PATCH] ASoC: rsnd: Add device tree binding for r8a77990
On Fri, 17 Aug 2018 16:53:55 +0900, Yoshihiro Kaneko wrote: > From: Hiroyuki Yokoyama > > This patch adds the device tree binding of the r8a77990 SoC. > > Signed-off-by: Hiroyuki Yokoyama > Signed-off-by: Yoshihiro Kaneko > --- > > This patch is based on the devel branch of Simon Horman's renesas tree. > > Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist
On 08/20/2018 11:07 PM, Wolfram Sang wrote: I've successfully tested eMMC on the V3H Starter Kit board. R8A77970 SoC has a single SDHI core anyway, so can't be a subject to the known RX DMA errata... Signed-off-by: Sergei Shtylyov >>> >>> Nit: some strange double spaces and '...' in the commit message: >>> >>> Reviewed-by: Wolfram Sang >> >>Should I repost? Or you'd squash the fouble spaces and ellipsis while >> applying? >> >>BTW, will this patch go into the next or fixes branch? (I remember Ulf >> wanted to >> stick the analogous R8A77980 patch into fixes.) > > I'll leave all these questions to Ulf. Sorry, I forgot you don't have a separate repo. MBR, Sergei
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist
On Mon, Aug 20, 2018 at 10:44:18PM +0300, Sergei Shtylyov wrote: > On 08/20/2018 07:42 PM, Wolfram Sang wrote: > > >> I've successfully tested eMMC on the V3H Starter Kit board. R8A77970 SoC > >> has a single SDHI core anyway, so can't be a subject to the known RX DMA > >> errata... > >> > >> Signed-off-by: Sergei Shtylyov > > > > Nit: some strange double spaces and '...' in the commit message: > > > > Reviewed-by: Wolfram Sang > >Should I repost? Or you'd squash the fouble spaces and ellipsis while > applying? > >BTW, will this patch go into the next or fixes branch? (I remember Ulf > wanted to > stick the analogous R8A77980 patch into fixes.) I'll leave all these questions to Ulf. signature.asc Description: PGP signature
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist
On 08/20/2018 07:42 PM, Wolfram Sang wrote: >> I've successfully tested eMMC on the V3H Starter Kit board. R8A77970 SoC >> has a single SDHI core anyway, so can't be a subject to the known RX DMA >> errata... >> >> Signed-off-by: Sergei Shtylyov > > Nit: some strange double spaces and '...' in the commit message: > > Reviewed-by: Wolfram Sang Should I repost? Or you'd squash the fouble spaces and ellipsis while applying? BTW, will this patch go into the next or fixes branch? (I remember Ulf wanted to stick the analogous R8A77980 patch into fixes.) MBR, Sergei
Re: [PATCH v2 5/7] mmc: renesas_sdhi: merge clk_{start,stop} functions to set_clock
On Thu, Aug 16, 2018 at 04:16:37PM +0900, Masahiro Yamada wrote:
> renesas_sdhi_clk_start() and renesas_sdhi_clk_stop() are now only
> called from renesas_sdhi_set_clock(). Merge them.
I can see the benefit of this change...
> static void renesas_sdhi_set_clock(struct tmio_mmc_host *host,
> unsigned int new_clock)
> {
> u32 clk = 0, clock;
>
> - if (new_clock == 0) {
> - renesas_sdhi_clk_stop(host);
> - return;
> - }
> + sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
> + sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
> +
> + if (new_clock == 0)
> + goto out;
... yet there is a slight change in that we disable the clock a tad
earlier now. I need to check the datasheets tomorrow what is exactly
documented and report back.
signature.asc
Description: PGP signature
Re: [PATCH v2 4/7] mmc: uniphier-sd: add UniPhier SD/eMMC controller driver
On Thu, Aug 16, 2018 at 04:16:36PM +0900, Masahiro Yamada wrote:
> Here is another TMIO MMC variant found in Socionext UniPhier SoCs.
>
> As commit b6147490e6aa ("mmc: tmio: split core functionality, DMA and
> MFD glue") said, these MMC controllers use the IP from Panasonic.
>
> However, the MMC controller in the TMIO (Toshiba Mobile IO) MFD chip
> was the first upstreamed user of this IP. The common driver code
> for this IP is now called 'tmio-mmc-core' in Linux although it is a
> historical misnomer.
>
> Anyway, this driver select's MMC_TMIO_CORE to borrow the common code
> from tmio-mmc-core.c
>
> Older UniPhier SoCs (LD4, Pro4, sLD8) support the external DMA engine
> like renesas_sdhi_sys_dmac.c. The difference is UniPhier SoCs use a
> single DMA channel whereas Renesas chips request separate channels for
> RX and TX.
>
> Newer UniPhier SoCs (Pro5 and later) support the internal DMA engine
> like renesas_sdhi_internal_dmac.c The register map is almost the same,
> so I guess Renesas and Socionext use the same internal DMA hardware.
> The main difference is, the register offsets are doubled for Renesas.
>
> Renesas Socionext
> SDHI UniPhier
> DM_CM_DTRAN_MODE 0x8200x410
> DM_CM_DTRAN_CTRL 0x8280x414
> DM_CM_RST 0x8300x418
> DM_CM_INFO1 0x8400x420
> DM_CM_INFO1_MASK 0x8480x424
> DM_CM_INFO2 0x8500x428
> DM_CM_INFO2_MASK 0x8580x42c
> DM_DTRAN_ADDR 0x8800x440
> DM_DTRAN_ADDREX--- 0x444
>
> This comes from the difference of host->bus_shift; 2 for Renesas SoCs,
> and 1 for UniPhier SoCs. Also, the datasheet for UniPhier SoCs defines
> DM_DTRAN_ADDR and DM_DTRAN_ADDREX as two separate registers.
>
> It could be possible to factor out the DMA common code by introducing
> some hooks to cope with platform quirks, but this patch does not touch
> that for now.
>
> Signed-off-by: Masahiro Yamada
Without docs and HW I cannot really review the driver, but it looks good
and it makes sense to me to keep it seperate and not factor out more
SDHI stuff. Thus:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
Re: [PATCH v2 3/7] dt-bindings: mmc: add DT binding for UniPhier SD/eMMC controller
On Thu, Aug 16, 2018 at 04:16:35PM +0900, Masahiro Yamada wrote: > This SD/eMMC controller is used for UniPhier SoC family. > > Signed-off-by: Masahiro Yamada > Reviewed-by: Rob Herring Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH v2 2/7] mmc: tmio: move tmio_mmc_set_clock() to platform hook
On Thu, Aug 16, 2018 at 04:16:34PM +0900, Masahiro Yamada wrote: > tmio_mmc_set_clock() is full of quirks because different SoC vendors > extended this in different ways. > > The original IP defines the divisor range 1/2 ... 1/512. > > bit 7 is set:1/512 > bit 6 is set:1/256 >... > bit 0 is set:1/4 > all bits clear: 1/2 > > It is platform-dependent how to achieve the 1/1 clock. > > I guess the TMIO-MFD variant uses the clock selector outside of this IP, > as far as I see tmio_core_mmc_clk_div() in drivers/mfd/tmio_core.c > > I guess bit[7:0]=0xff is Renesas-specific extension. > > Socionext (and Panasonic) uses bit 10 (CLKSEL) for 1/1. Also, newer > versions of UniPhier SoC variants use bit 16 for 1/1024. > > host->clk_update() is only used by the Renesas variants, whereas > host->set_clk_div() is only used by the TMIO-MFD variants. > > To cope with this mess, promote tmio_mmc_set_clock() to a new > platform hook ->set_clock(), and melt the old two hooks into it. > > Signed-off-by: Masahiro Yamada Reviewed-by: Wolfram Sang I like this refactoring, much clearer this way. Thanks. signature.asc Description: PGP signature
Re: [PATCH v2 1/7] mmc: tmio: replace tmio_mmc_clk_stop() calls with tmio_mmc_set_clock()
On Thu, Aug 16, 2018 at 04:16:33PM +0900, Masahiro Yamada wrote: > tmio_mmc_clk_stop(host) is equivalent to tmio_mmc_set_clock(host, 0). > This replacement is needed for the next commit. > > Signed-off-by: Masahiro Yamada Reviewed-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH v2 0/7] mmc: tmio: refactor TMIO core a bit and add UniPhier SD/eMMC controller support
So, today I did test these patches successfully on a Gen3 board (M3-N) and reviewed half of the patches. I will continue tomorrow with reviewing and testing more boards. In a nutshell, things look good so far. signature.asc Description: PGP signature
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist
> > Nit: some strange double spaces and '...' in the commit message: > >Why are you so hostile to ...? :-) To me, it has a meaning: either something is to be continued or the sentence is intentionaly left open end, so the reader needs to complete it. I see neither fit here and I don't see any extra value over '.' Congrats, you got me bike-shedding. >I ndon';t have the datasheet handy but I don't think it matters -- the > board > only supplies 3.3V on both chip's voltage inputs... Okay. Pity, would have liked another test report for HS400. signature.asc Description: PGP signature
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist
On 08/20/2018 07:42 PM, Wolfram Sang wrote: >> I've successfully tested eMMC on the V3H Starter Kit board. R8A77970 SoC >> has a single SDHI core anyway, so can't be a subject to the known RX DMA >> errata... >> >> Signed-off-by: Sergei Shtylyov > > Nit: some strange double spaces and '...' in the commit message: Why are you so hostile to ...? :-) > Reviewed-by: Wolfram Sang > > And out of interest: was this an HS400 eMMC memory? I ndon';t have the datasheet handy but I don't think it matters -- the board only supplies 3.3V on both chip's voltage inputs... > Thanks! MBR, Sergei
Re: [PATCH] mmc: tmio_mmc_core: don't claim spurious interrupts
> > Should come after Yamada-san's patches, I'd think. > >What are these? A more complex series adding another SDHI user. > > BTW Sergei, did you test with SDIO devices? > >No. But I really think the current code is borked. If you don't have an > interrupt > to handle, you should idicate that. I think the patch is justified, I am not talking about that. I just wondered if you tested it. So, you are not missing something in the SDIO code path which you changed. signature.asc Description: PGP signature
Re: [PATCH] mmc: tmio_mmc_core: don't claim spurious interrupts
On 08/20/2018 07:55 PM, Wolfram Sang wrote: >> I have encountered an interrupt storm during the eMMC chip probing (and >> the chip finally didn't get detected). It turned out that U-Boot left >> the DMAC interrupts enabled while the Linux driver didn't use those. >> The SDHI driver's interrupt handler somehow assumes that, even if a >> SDIO interrupt didn't happen, it should return IRQ_HANDLED. I think that >> if none of the enabled interrupts happened and got handled, we should >> return IRQ_NONE -- that way the kernel IRQ code recoginizes a spurious >> interrupt and masks it off pretty quickly... >> >> Signed-off-by: Sergei Shtylyov > > Can be argued. You get interrupt storm anyway, just not as quickly stopped as with this fix (I hadn't understood *how* it gets finally stopped, I only know there's ~60 interrupts before it gets quiet instead of 10 with IRQ_NONE). > Should come after Yamada-san's patches, I'd think. What are these? > BTW Sergei, did you test with SDIO devices? No. But I really think the current code is borked. If you don't have an interrupt to handle, you should idicate that. MBR, Sergei
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts
> >> /* DM_CM_INFO2 and DM_CM_INFO2_MASK */ > >> #define INFO2_DTRANERR1 BIT(17) > >> #define INFO2_DTRANERR0 BIT(16) > >> +#define INFO2_RESERVED_BITS GENMASK_ULL(32, 0) > > > > Same as above. Maybe we even need one define only? > >No, I think 2 separate regs deserve 2 separate masks. Whatever. I am not into bike-shedding. It works, too. > >> + /* > >> + * We don't use the DMA interrupts, but they might have been enabled > >> + * by a bootloader, so mask them to avoid an interrupt storm... > >> + */ > > > > Two spaces after ',' looks odd to me. Also, no need for "..." > >Both are my preferences. Yes, I probably should have worked in the > typesetting industry... :-) But where is the continuation of "..."? > > I'd even think with a name like CLEAR_MASK, the comment could even go. > >Disagree here. The register #defines don't provide enough info on what's > going on... Masking out all interrupts at the beginning is pretty standard behaviour in my book. Well, at least, please shorten it to sth like "Disable interrupts, we don't use them". signature.asc Description: PGP signature
Re: [PATCH] mmc: tmio_mmc_core: don't claim spurious interrupts
On Fri, Aug 17, 2018 at 02:41:02PM +0300, Sergei Shtylyov wrote: > I have encountered an interrupt storm during the eMMC chip probing (and > the chip finally didn't get detected). It turned out that U-Boot left > the DMAC interrupts enabled while the Linux driver didn't use those. > The SDHI driver's interrupt handler somehow assumes that, even if a > SDIO interrupt didn't happen, it should return IRQ_HANDLED. I think that > if none of the enabled interrupts happened and got handled, we should > return IRQ_NONE -- that way the kernel IRQ code recoginizes a spurious > interrupt and masks it off pretty quickly... > > Signed-off-by: Sergei Shtylyov Can be argued. Should come after Yamada-san's patches, I'd think. BTW Sergei, did you test with SDIO devices? signature.asc Description: PGP signature
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts
Hello! On 08/20/2018 07:38 PM, Wolfram Sang wrote: >> I have encountered an interrupt storm during the eMMC chip probing (and >> the chip finally didn't get detected). It turned out that U-Boot left >> the SDHI DMA interrupts enabled while the Linux driver didn't use those. >> Masking those interrupts in renesas_sdhi_internal_dmac_request_dma() gets >> rid of both issues... >> >> Signed-off-by: Sergei Shtylyov > > Thanks for fixing this issue. > >> >> --- >> The patch is against Ulf Hansson's 'mmc.git' repo's 'fixes' branch. >> >> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 11 +++ >> 1 file changed, 11 insertions(+) >> >> Index: mmc/drivers/mmc/host/renesas_sdhi_internal_dmac.c >> === >> --- mmc.orig/drivers/mmc/host/renesas_sdhi_internal_dmac.c >> +++ mmc/drivers/mmc/host/renesas_sdhi_internal_dmac.c >> @@ -51,10 +51,12 @@ >> #define INFO1_CLEAR 0 >> #define INFO1_DTRANEND1 BIT(17) >> #define INFO1_DTRANEND0 BIT(16) >> +#define INFO1_RESERVED_BITS GENMASK_ULL(32, 0) > > 31? Indeed. Than RST_RESERVED_BITS (from which I copied w/o much thinking) is also wrong! > Also, RESERVED_BITS is not quite proper. Not all of those bits are > reserved. Maybe CLEAR_MASK? Indeed, would seem better... but RST_RESERVED_BITS also needs fixing then... >> /* DM_CM_INFO2 and DM_CM_INFO2_MASK */ >> #define INFO2_DTRANERR1 BIT(17) >> #define INFO2_DTRANERR0 BIT(16) >> +#define INFO2_RESERVED_BITS GENMASK_ULL(32, 0) > > Same as above. Maybe we even need one define only? No, I think 2 separate regs deserve 2 separate masks. >> +/* >> + * We don't use the DMA interrupts, but they might have been enabled >> + * by a bootloader, so mask them to avoid an interrupt storm... >> + */ > > Two spaces after ',' looks odd to me. Also, no need for "..." Both are my preferences. Yes, I probably should have worked in the typesetting industry... :-) > I'd even think with a name like CLEAR_MASK, the comment could even go. Disagree here. The register #defines don't provide enough info on what's going on... >> +renesas_sdhi_internal_dmac_dm_write(host, DM_CM_INFO1_MASK, >> +INFO1_RESERVED_BITS); >> +renesas_sdhi_internal_dmac_dm_write(host, DM_CM_INFO2_MASK, >> +INFO2_RESERVED_BITS); MBR, Sergei
Re: [PATCH 2/2] mmc: renesas_sdhi_internal_dmac: fix comment typo
On Fri, Aug 17, 2018 at 11:20:23PM +0300, Sergei Shtylyov wrote: > Fix the typo in the comment to #define DTRAN_MODE_CH_NUM_CH1. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Wolfram Sang ...but I really think those two patches should be squashed. One patch per typo is too fine grained IMO. signature.asc Description: PGP signature
Re: [PATCH 1/2] mmc: renesas_sdhi_internal_dmac: fix typo in DM_CM_DTRAN_MODE.BUS_WIDTH field name
On Fri, Aug 17, 2018 at 11:19:02PM +0300, Sergei Shtylyov wrote: > Fix a stray underscore in the DM_CM_DTRAN_MODE.BUS_WIDTH register field > name. > > Signed-off-by: Sergei Shtylyov Yes, I noticed this, too recently Reviewed-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist
On Sat, Aug 18, 2018 at 09:08:26PM +0300, Sergei Shtylyov wrote:
> I've successfully tested eMMC on the V3H Starter Kit board. R8A77970 SoC
> has a single SDHI core anyway, so can't be a subject to the known RX DMA
> errata...
>
> Signed-off-by: Sergei Shtylyov
Nit: some strange double spaces and '...' in the commit message:
Reviewed-by: Wolfram Sang
And out of interest: was this an HS400 eMMC memory?
Thanks!
> ---
> This patch is against the 'next' branch of Ulf Hansson's 'mmc.git' repo.
>
> drivers/mmc/host/renesas_sdhi_internal_dmac.c |1 +
> 1 file changed, 1 insertion(+)
>
> Index: mmc/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> ===
> --- mmc.orig/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ mmc/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -293,6 +293,7 @@ static const struct soc_device_attribute
> { .soc_id = "r8a7795" },
> { .soc_id = "r8a7796" },
> { .soc_id = "r8a77965" },
> + { .soc_id = "r8a77970" },
> { .soc_id = "r8a77980" },
> { .soc_id = "r8a77995" },
> { /* sentinel */ }
signature.asc
Description: PGP signature
Re: [PATCH] mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts
On Fri, Aug 17, 2018 at 07:54:09PM +0300, Sergei Shtylyov wrote: > I have encountered an interrupt storm during the eMMC chip probing (and > the chip finally didn't get detected). It turned out that U-Boot left > the SDHI DMA interrupts enabled while the Linux driver didn't use those. > Masking those interrupts in renesas_sdhi_internal_dmac_request_dma() gets > rid of both issues... > > Signed-off-by: Sergei Shtylyov Thanks for fixing this issue. > > --- > The patch is against Ulf Hansson's 'mmc.git' repo's 'fixes' branch. > > drivers/mmc/host/renesas_sdhi_internal_dmac.c | 11 +++ > 1 file changed, 11 insertions(+) > > Index: mmc/drivers/mmc/host/renesas_sdhi_internal_dmac.c > === > --- mmc.orig/drivers/mmc/host/renesas_sdhi_internal_dmac.c > +++ mmc/drivers/mmc/host/renesas_sdhi_internal_dmac.c > @@ -51,10 +51,12 @@ > #define INFO1_CLEAR 0 > #define INFO1_DTRANEND1 BIT(17) > #define INFO1_DTRANEND0 BIT(16) > +#define INFO1_RESERVED_BITS GENMASK_ULL(32, 0) 31? Also, RESERVED_BITS is not quite proper. Not all of those bits are reserved. Maybe CLEAR_MASK? > /* DM_CM_INFO2 and DM_CM_INFO2_MASK */ > #define INFO2_DTRANERR1 BIT(17) > #define INFO2_DTRANERR0 BIT(16) > +#define INFO2_RESERVED_BITS GENMASK_ULL(32, 0) Same as above. Maybe we even need one define only? > + /* > + * We don't use the DMA interrupts, but they might have been enabled > + * by a bootloader, so mask them to avoid an interrupt storm... > + */ Two spaces after ',' looks odd to me. Also, no need for "..." I'd even think with a name like CLEAR_MASK, the comment could even go. > + renesas_sdhi_internal_dmac_dm_write(host, DM_CM_INFO1_MASK, > + INFO1_RESERVED_BITS); > + renesas_sdhi_internal_dmac_dm_write(host, DM_CM_INFO2_MASK, > + INFO2_RESERVED_BITS); signature.asc Description: PGP signature
Re: [PATCH/RFC v2 02/02] ravb: Clean up duplex handling
On 08/20/2018 05:59 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Since only full-duplex operation is supported by the
> hardware, remove duplex handling code and keep the
> register setting of ECMR.DM fixed at 1.
>
> This updates the driver implementation to follow the
> data sheet text "This bit should always be set to 1."
>
> Not-Yet-Signed-off-by: Magnus Damm
> Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Fixes: tag should precede sign-off.
[...]
You missed to add this from the previous review:
Reviewed-by: Sergei Shtylyov
The net.git repo is always open, so you can post these patches to netdev
already...
MBR, Sergei
[PATCH/RFC v2 02/02] ravb: Clean up duplex handling
From: Magnus Damm
Since only full-duplex operation is supported by the
hardware, remove duplex handling code and keep the
register setting of ECMR.DM fixed at 1.
This updates the driver implementation to follow the
data sheet text "This bit should always be set to 1."
Not-Yet-Signed-off-by: Magnus Damm
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
---
Written on top of next-20180820
drivers/net/ethernet/renesas/ravb.h |1 -
drivers/net/ethernet/renesas/ravb_main.c | 19 +--
2 files changed, 1 insertion(+), 19 deletions(-)
--- 0001/drivers/net/ethernet/renesas/ravb.h
+++ work/drivers/net/ethernet/renesas/ravb.h2018-08-20 23:45:02.203442052
+0900
@@ -1027,7 +1027,6 @@ struct ravb_private {
phy_interface_t phy_interface;
int msg_enable;
int speed;
- int duplex;
int emac_irq;
enum ravb_chip_id chip_id;
int rx_irqs[NUM_RX_QUEUE];
--- 0002/drivers/net/ethernet/renesas/ravb_main.c
+++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-08-20
23:48:17.840945347 +0900
@@ -85,13 +85,6 @@ static int ravb_config(struct net_device
return error;
}
-static void ravb_set_duplex(struct net_device *ndev)
-{
- struct ravb_private *priv = netdev_priv(ndev);
-
- ravb_modify(ndev, ECMR, ECMR_DM, priv->duplex ? ECMR_DM : 0);
-}
-
static void ravb_set_rate(struct net_device *ndev)
{
struct ravb_private *priv = netdev_priv(ndev);
@@ -401,13 +394,11 @@ error:
/* E-MAC init function */
static void ravb_emac_init(struct net_device *ndev)
{
- struct ravb_private *priv = netdev_priv(ndev);
-
/* Receive frame limit set register */
ravb_write(ndev, ndev->mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN, RFLR);
/* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
- ravb_write(ndev, ECMR_ZPF | (priv->duplex ? ECMR_DM : 0) |
+ ravb_write(ndev, ECMR_ZPF | ECMR_DM |
(ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
ECMR_TE | ECMR_RE, ECMR);
@@ -989,12 +980,6 @@ static void ravb_adjust_link(struct net_
ravb_rcv_snd_disable(ndev);
if (phydev->link) {
- if (phydev->duplex != priv->duplex) {
- new_state = true;
- priv->duplex = phydev->duplex;
- ravb_set_duplex(ndev);
- }
-
if (phydev->speed != priv->speed) {
new_state = true;
priv->speed = phydev->speed;
@@ -1009,7 +994,6 @@ static void ravb_adjust_link(struct net_
new_state = true;
priv->link = 0;
priv->speed = 0;
- priv->duplex = -1;
}
/* Enable TX and RX right over here, if E-MAC change is ignored */
@@ -1039,7 +1023,6 @@ static int ravb_phy_init(struct net_devi
priv->link = 0;
priv->speed = 0;
- priv->duplex = -1;
/* Try connecting to PHY */
pn = of_parse_phandle(np, "phy-handle", 0);
[PATCH/RFC v2 01/02] ravb: Do not announce HDX as supported
From: Magnus Damm
According to the data sheet the Ethernet-AVB hardware in R-Car Gen3
and R-Car Gen2 SoCs do not support half duplex operation. So update
the driver to mark 100Mbit and 1Gbps HDX as unsupported.
Not-Yet-Signed-off-by: Magnus Damm
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Reviewed-by: Sergei Shtylyov
---
Written on top of next-20180820
drivers/net/ethernet/renesas/ravb_main.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- 0001/drivers/net/ethernet/renesas/ravb_main.c
+++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-08-20
23:42:46.670859449 +0900
@@ -1076,8 +1076,9 @@ static int ravb_phy_init(struct net_devi
netdev_info(ndev, "limited PHY to 100Mbit/s\n");
}
- /* 10BASE is not supported */
- phydev->supported &= ~PHY_10BT_FEATURES;
+ /* Neither 10BASE nor half duplex are supported */
+ phydev->supported &= ~(PHY_10BT_FEATURES | SUPPORTED_100baseT_Half |
+ SUPPORTED_1000baseT_Half);
phy_attached_info(phydev);
[PATCH/RFC v2 00/02] ravb: Duplex handling update V2
ravb: Duplex handling update V2 [PATCH/RFC v2 01/02] ravb: Do not announce HDX as supported [PATCH/RFC v2 02/02] ravb: Clean up duplex handling This series is V2 of prototype-level code to update the Ethernet-AVB driver to improve duplex handling. Based on the latest data sheet for R-Car Gen3 [1] and R-Car Gen2 [2] the following information is part of the EthernetAVB-IF overview page: Transfer speed: Supports transfer at 100 and 1000 Mbps Mode: Full-duplex mode It seems that the driver implementation is not matching the information provided in the friendly data sheet, and on top of this during run-time when changing PHY configuration of the link partner the Ethernet-AVB PHY seems to want to announce unsupported modes. [1] R-Car Series, 3rd Generation Rev.1.00 (Apr 2018) [2] R-Car Series, 2nd Generation Rev.2.00 (Feb 2016) Changes since V1: - Updated patches to reflect input from Sergei and Geert - thanks! Getting closer to be suitable for upstream merge? Not-Yet-Signed-off-by: Magnus Damm --- Written on top of next-20180820 drivers/net/ethernet/renesas/ravb.h |1 - drivers/net/ethernet/renesas/ravb_main.c | 24 2 files changed, 4 insertions(+), 21 deletions(-)
Re: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling
On Mon, Aug 20, 2018 at 01:44:48PM +, Phil Edworthy wrote: [...] > However, both before and after this patch, the RP does not transition L1 > when the endpoints change to L1. > This patch only transitions the RP to L1 during accessing a card's > config registers, if the RP is not in L1 link state and has received > PM_ENTER_L1 DLLP (e.g. resume). After this, the hardware will handle > the transition out of L1. > > The relevant part of the rcar manual says: "After a recovery to L0, if > the device is in the Non-D0 state and PM_Enter_L1 DLLP is transmitted > from the downstream device, software should confirm that hardware is > in the L0 state (PMSR.PMSTATE = L0) and initiate the L1 transition > sequence again (write 1 to PMCTLR.L1IATN). In this case, the sequence > is: L0 → L1 → L0 recovery → L1 again." Can you map these FSM steps to this patch code please ? I would like to understand what Link state maps to which command written and when. > I don’t think the potential issue that Bjorn talked about can happen > because the RP does go into L1. I could be wrong though... I do not understand this paragraph, mind elaborating on it ? > The driver should also have a runtime-PM hook to transition to L1 on > suspend in order to save power. However, that is somewhat separate > to the problem the patch fixes. Yes that's a separate patch. Thanks for chiming in, let's try to get to the bottom of this thread. Lorenzo
[PATCH] arm64: dts: renesas: r8a77965: Attach the SYS-DMAC to the IPMMU
From: Magnus Damm
For R-Car M3-N hook up SYS-DMAC0, SYS-DMAC1 and SYS-DMAC2 to
IPMMU-DS0 and IPMMU-DS1 in same way as for R-Car M3-W.
This follows the R-Car Gen3 Rev.1.00 (April 2018) datasheet.
Signed-off-by: Magnus Damm
---
Developed on top of renesas-devel-20180810-v4.18-rc7
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 24
1 file changed, 24 insertions(+)
--- 0001/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ work/arch/arm64/boot/dts/renesas/r8a77965.dtsi 2018-08-20
23:11:52.655712775 +0900
@@ -634,6 +634,14 @@
resets = < 219>;
#dma-cells = <1>;
dma-channels = <16>;
+ iommus = <_ds0 0>, <_ds0 1>,
+ <_ds0 2>, <_ds0 3>,
+ <_ds0 4>, <_ds0 5>,
+ <_ds0 6>, <_ds0 7>,
+ <_ds0 8>, <_ds0 9>,
+ <_ds0 10>, <_ds0 11>,
+ <_ds0 12>, <_ds0 13>,
+ <_ds0 14>, <_ds0 15>;
};
dmac1: dma-controller@e730 {
@@ -668,6 +676,14 @@
resets = < 218>;
#dma-cells = <1>;
dma-channels = <16>;
+ iommus = <_ds1 0>, <_ds1 1>,
+ <_ds1 2>, <_ds1 3>,
+ <_ds1 4>, <_ds1 5>,
+ <_ds1 6>, <_ds1 7>,
+ <_ds1 8>, <_ds1 9>,
+ <_ds1 10>, <_ds1 11>,
+ <_ds1 12>, <_ds1 13>,
+ <_ds1 14>, <_ds1 15>;
};
dmac2: dma-controller@e731 {
@@ -702,6 +718,14 @@
resets = < 217>;
#dma-cells = <1>;
dma-channels = <16>;
+ iommus = <_ds1 16>, <_ds1 17>,
+ <_ds1 18>, <_ds1 19>,
+ <_ds1 20>, <_ds1 21>,
+ <_ds1 22>, <_ds1 23>,
+ <_ds1 24>, <_ds1 25>,
+ <_ds1 26>, <_ds1 27>,
+ <_ds1 28>, <_ds1 29>,
+ <_ds1 30>, <_ds1 31>;
};
ipmmu_ds0: mmu@e674 {
[PATCH] arm: dts: Include R-Car Gen1 product name in DTSI files
From: Magnus Damm Browsing the DTS for all the R-Car SoCs with similar part numbers still makes my head hurt, so to improve the user friendliness of the 32-bit ARM DTS code base include R-Car Gen1 product names for each DTSI file. Signed-off-by: Magnus Damm --- Based on renesas-devel-20180810-v4.18-rc7 arch/arm/boot/dts/r8a7778.dtsi |2 +- arch/arm/boot/dts/r8a7779.dtsi |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- 0001/arch/arm/boot/dts/r8a7778.dtsi +++ work/arch/arm/boot/dts/r8a7778.dtsi 2018-08-20 22:54:32.819084747 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for Renesas r8a7778 + * Device Tree Source for the R-Car M1A (R8A77781) SoC * * Copyright (C) 2013 Renesas Solutions Corp. * Copyright (C) 2013 Kuninori Morimoto --- 0001/arch/arm/boot/dts/r8a7779.dtsi +++ work/arch/arm/boot/dts/r8a7779.dtsi 2018-08-20 22:54:05.579741880 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for Renesas r8a7779 + * Device Tree Source for the R-Car H1 (R8A77790) SoC * * Copyright (C) 2013 Renesas Solutions Corp. * Copyright (C) 2013 Simon Horman
RE: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling
Hello,
Sorry for the delay.
On 08 August 2018 14:30, Marek Vasut wrote:
> On 07/25/2018 11:08 PM, Marek Vasut wrote:
> > On 06/13/2018 07:25 PM, Bjorn Helgaas wrote:
> >> On Wed, Jun 13, 2018 at 04:52:52PM +0100, Lorenzo Pieralisi wrote:
> >>> On Wed, Jun 13, 2018 at 08:53:08AM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 13, 2018 at 01:54:51AM +0200, Marek Vasut wrote:
> > On 06/11/2018 03:59 PM, Bjorn Helgaas wrote:
> >> On Sun, Jun 10, 2018 at 03:57:10PM +0200, Marek Vasut wrote:
> >>> On 11/17/2017 06:49 PM, Lorenzo Pieralisi wrote:
> On Fri, Nov 10, 2017 at 10:58:42PM +0100, Marek Vasut wrote:
> > From: Phil Edworthy
> >
> > Most PCIe host controllers support L0s and L1 power states via
> ASPM.
> > The R-Car hardware only supports L0s, so when the system
> > suspends and resumes we have to manually handle L1.
> > When the system suspends, cards can put themselves into L1
> and
> > send a
>
> I assumed L1 entry has to be negotiated depending upon the PCIe
> hierarchy capabilities, I would appreciate if you can explain
> to me what's the root cause of the issue please.
> >>>
> >>> You should probably ignore the suspend/resume part altogether.
> >>> The issue here is that the cards can enter L1 state, while the
> >>> controller won't do that automatically, it can only detect that the
> link went into L1 state.
> >>> If that happens,the driver must manually put the controller to L1
> state.
> >>> The controller can transition out of L1 state automatically though.
> >>
> >> From earlier discussion I thought the R-Car root port did not
> >> advertise L1 support.
> >
> > Which discussion ? This one or somewhere else ?
>
>
> https://lkml.kernel.org/r/HK2PR0601MB1393D917D343E6363484CA68F5CB0
> @
> HK2PR0601MB1393.apcprd06.prod.outlook.com
>
> Re-reading that, I think I see my misunderstanding. I was only
> considering L1 in the ASPM context. I didn't realize the L1
> implications of devices being in states other than D0.
>
> Obviously L1 support for ASPM is optional and advertised via Link
> Capabilities. But per PCIe r4.0, sec 5.2, L1 support is required
> for PCI-PM compatible power management, and is entered "whenever
> all Functions ... are programmed to a D-state other than D0."
>
> So I guess this means *every* device is supposed to support L1 when
> it is in a non-D0 power state. I think *this* is the case you're
> solving.
>
> A little more of this detail, e.g., that this issue has nothing to
> do with ASPM, it's probably an R-Car erratum that the RC can't
> transition from L1 to L0, etc., in the changelog would really help
> clear things up for me.
> >>>
> >>> I think that the issue is related to the L0->L1 transition upon
> >>> system suspend (ie the kernel must force the controller into L1 when
> >>> all devices are in a sleep state) and for this specific reason I
> >>> still think that checking for a PM_Enter_L1 DLLP reception and doing
> >>> the L0->L1 transition within a config access is wrong and prone to
> >>> error (what's the rationale behind that ?), this ought to be done
> >>> using PM methods in the host controller driver.
> >>
> >> But doesn't the problem happen whenever the link goes to L1, for any
> >> reason? E.g., runtime power management might put an endpoint in D3
> >> even if we're not doing a whole system suspend. A user could even
> >> force the endpoint to D3 by writing to PCI_PM_CTRL with "setpci". If
> >> that's the case, I don't think the host controller PM methods will be
> >> enough to work around the issue.
> >
> > I think so, it's the link that goes into L1 state and this can happen
> > without any action from the controller side.
> >
> >> The comment in the patch ("If we are not in L1 link state and we have
> >> received PM_ENTER_L1 DLLP, transition to L1 link state") suggests
> >> that the R-Car host doesn't handle step 10 in PCIe r4.0, sec 5.3.2.1
> >> correctly, i.e., it doesn't complete the transition of the link to L1.
> >>
> >> Putting this workaround in the config accessor makes sense to me
> >> because in this situation the endpoint thinks it's in L1 and it won't
> >> receive TLPs for config accesses. Apparently forcing the RP to L1
> >> completes the L1 entry, and the RP correctly handles the "Exit from
> >> L1 State" (sec 5.3.2.2) that's required when the RP needs to send a
> >> TLP to the endpoint.
That my understanding.
> >> I think there's still a potential issue if the endpoint goes to a
> >> non-D0 state, the link is stuck in this transitional state (endpoint
> >> thinks it's L1, RP thinks it's L0), and the *endpoint* wants to exit
> >> L1, e.g., so it can send a PME message for a wakeup. I don't know
> >> what happens then.
> >
> > Is there some hardware which I can use to simulate
Re: [PATCH 2/2] i2c: rcar: implement STOP and REP_START according to docs
On Wed, Aug 08, 2018 at 09:59:28AM +0200, Wolfram Sang wrote: > When doing a REP_START after a read message, the driver used to trigger > a STOP first which would then be overwritten by REP_START. This was the > only stable method found when doing the last refactoring. However, this > was not in accordance with the documentation. > > After research from our BSP team and myself, we now can implement a > version which works and is according to the documentation. The new > approach ensures the ICMCR register is only changed when really needed. > > Tested on a R-Car Gen2 (H2) and Gen3 with DMA (M3N). > > Signed-off-by: Hiromitsu Yamasaki > Signed-off-by: Wolfram Sang Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH 1/2] i2c: rcar: refactor private flags
On Wed, Aug 08, 2018 at 09:59:27AM +0200, Wolfram Sang wrote: > Use BIT macro to avoid shift-31-problem, indent a little more and use > GENMASK to make it easier to add new flags. > > Signed-off-by: Wolfram Sang Applied to for-next, thanks! signature.asc Description: PGP signature
[RFT 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
From: Takeshi Kihara
This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 504 ++
1 file changed, 504 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 5ea63e5..46c0b06 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1982,6 +1982,446 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const unsigned int vin4_data8_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+};
+
+static const unsigned int vin4_data8_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+};
+
+static const unsigned int vin4_data10_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+};
+
+static const unsigned int vin4_data10_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+};
+
+static const unsigned int vin4_data12_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+};
+
+static const unsigned int vin4_data12_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+};
+
+static const unsigned int vin4_data16_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+};
+
+static const unsigned int vin4_data16_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+};
+
+static const unsigned int vin4_data20_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+};
+
+static const unsigned int vin4_data20_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+};
+
+static const unsigned int vin4_data24_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+};
+
+static const unsigned int vin4_data24_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK,
[RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hello renesas list, this series add supports for the HDMI and CVBS input to R-Car E3 R8A77990 Ebisu board. It's an RFT, as I don't have an Ebisu to test with :( The series adds supports for the following items: - PFC: add VIN groups and functions - R-Car VIN and R-Car CSI-2: add support for R8A77990 - R8A77990: Add I2C, VIN and CSI-2 nodes - Ebisu: describe HDMI and CVBS inputs Each patch, when relevant reports difference between the upported BSP patch and the proposed one. I know Laurent should receive an Ebisu sooner or later, maybe we can sync for testing :) Thanks j PS: the list of upported patches will be sent separately. Jacopo Mondi (5): media: dt-bindings: media: rcar-vin: Add R8A77990 support media: rcar-vin: Add support for R-Car R8A77990 dt-bindings: media: rcar-csi2: Add R8A77990 media: rcar-csi2: Add R8A77990 support arm64: dts: renesas: ebisu: Add HDMI and CVBS input Koji Matsuoka (1): arm64: dts: r8a77990: Add VIN and CSI-2 device nodes Takeshi Kihara (2): pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions arm64: dts: r8a77990: Add I2C device nodes .../devicetree/bindings/media/rcar_vin.txt | 1 + .../bindings/media/renesas,rcar-csi2.txt | 1 + arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 202 + drivers/media/platform/rcar-vin/rcar-core.c| 20 + drivers/media/platform/rcar-vin/rcar-csi2.c| 9 + drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 504 + 7 files changed, 823 insertions(+) -- 2.7.4
[RFT 1/8] media: dt-bindings: media: rcar-vin: Add R8A77990 support
Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by rcar-vin driver. Signed-off-by: Jacopo Mondi --- Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index 2f42005..dfd6058 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -23,6 +23,7 @@ on Gen3 platforms to a CSI-2 receiver. - "renesas,vin-r8a7796" for the R8A7796 device - "renesas,vin-r8a77965" for the R8A77965 device - "renesas,vin-r8a77970" for the R8A77970 device + - "renesas,vin-r8a77990" for the R8A77990 device - "renesas,vin-r8a77995" for the R8A77995 device - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible device. -- 2.7.4
Re: [PATCH 2/3] drm: rcar-du: Rename var to a more precise name
Hi Jacopo,
Thank you for the patch.
On Monday, 30 July 2018 20:20:13 EEST Jacopo Mondi wrote:
> Rename the 'value' variable, only used to for writing to DMSR register to a
> more precise 'dmsr' name.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
I think this simple change can be squashed with patch 1/3.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 6d55cec..4d7907c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -208,7 +208,7 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc) const struct drm_display_mode *mode =
> >crtc.state->adjusted_mode; struct rcar_du_device *rcdu =
> rcrtc->group->dev;
> unsigned long mode_clock = mode->clock * 1000;
> - u32 value;
> + u32 dsmr;
> u32 escr;
>
> if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> @@ -299,11 +299,11 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc) rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ?
> OTAR2 : OTAR, 0);
>
> /* Signal polarities */
> - value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
> - | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)
> - | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
> - | DSMR_DIPM_DISP | DSMR_CSPM;
> - rcar_du_crtc_write(rcrtc, DSMR, value);
> + dsmr = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
> +| ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)
> +| ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
> +| DSMR_DIPM_DISP | DSMR_CSPM;
> + rcar_du_crtc_write(rcrtc, DSMR, dsmr);
>
> /* Display timings */
> rcar_du_crtc_write(rcrtc, HDSR, mode->htotal - mode->hsync_start - 19);
--
Regards,
Laurent Pinchart
[RFT 2/8] media: rcar-vin: Add support for R-Car R8A77990
Add R-Car E3 R8A77990 SoC to the rcar-vin supported ones.
Based on the experimental patch from Magnus Damm.
Signed-off-by: Jacopo Mondi
---
drivers/media/platform/rcar-vin/rcar-core.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 8843367..907985d 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1089,6 +1089,22 @@ static const struct rvin_info rcar_info_r8a77970 = {
.routes = rcar_info_r8a77970_routes,
};
+static const struct rvin_group_route rcar_info_r8a77990_routes[] = {
+ { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
+ { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
+ { .csi = RVIN_CSI40, .channel = 1, .vin = 4, .mask = BIT(2) },
+ { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
+ { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a77990 = {
+ .model = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+ .routes = rcar_info_r8a77990_routes,
+};
+
static const struct rvin_group_route rcar_info_r8a77995_routes[] = {
{ /* Sentinel */ }
};
@@ -1147,6 +1163,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.data = _info_r8a77970,
},
{
+ .compatible = "renesas,vin-r8a77990",
+ .data = _info_r8a77990,
+ },
+ {
.compatible = "renesas,vin-r8a77995",
.data = _info_r8a77995,
},
--
2.7.4
Re: [PATCH] dt-bindings: pwm: rcar: Add bindings for R-Car E3 support
On Mon, Jul 30, 2018 at 08:49:51PM +0900, Yoshihiro Shimoda wrote: > This patch adds bindings for R-Car E3. No driver update is needed. > > Signed-off-by: Yoshihiro Shimoda > --- > Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH 2/2] i2c: rcar: implement STOP and REP_START according to docs
> > - if (priv->pos + 1 >= msg->len)
> > - rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_STOP);
> > + /* If next received data is the _LAST_, go to new phase. */
> > + if (priv->pos + 1 == msg->len) {
> > + if (priv->flags & ID_LAST_MSG) {
> > + rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_STOP);
> > + } else {
> > + rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_START);
> > + priv->flags |= ID_P_REP_AFTER_RD;
> > + }
> > + }
>
> So "priv->pos + 1 <= msg->len" is an invariant? (The current code seems to
> imply that it isn't.)
I think it is, we increment pos by 1 right before this 'if'. Do you
agree? IIRC the old '>=' came from a 'well, won't hurt' attitude. It was
not precise, sadly.
> If it is,
> Reviewed-by: Ulrich Hecht
Thanks.
signature.asc
Description: PGP signature
