Re: [PATCH] dt-bindings: i2c: eeprom: Add Renesas R1EX24128

[Wolfram Sang]

On Thu, Nov 16, 2017 at 02:46:34PM +0100, Geert Uytterhoeven wrote:
> Document the compatible value for the Renesas R1EX24128ASAS0A two-wire
> serial interface EEPROM, so it can be used in DTS files without causing
> checkpatch warnings.
> 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature

[PATCH/RFC 04/04] iommu/ipmmu-vmsa: VA64 mode with 30-bit IOVA

[Magnus Damm]

From: Magnus Damm 

Hack up the IPMMU driver to enable VM64 mode with 30-bit IOVA.

For this configuration the IPMMU hardware is configured with IMTTBCR.SL=0
and TSZ0 bits set to 0x22. This will enable a 30-bit IOVA space and use
"Initial lookup level 2" (in Table D4-13 of armv8_arm.pdf) also known as
"Start at second level" in IPMMU documentation.

Not for upstream merge. Tested on ULCB with r8a7796 ES1.0.

Not-Yet-Signed-off-by: Magnus Damm 
---

 drivers/iommu/ipmmu-vmsa.c |   40 +++-
 1 files changed, 27 insertions(+), 13 deletions(-)

--- 0009/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-11-17 13:46:17.670607110 +0900
@@ -42,6 +42,7 @@ struct ipmmu_features {
unsigned int number_of_contexts;
bool setup_imbuscr;
bool twobit_imttbcr_sl0;
+   bool imctr_va64;
 };
 
 struct ipmmu_vmsa_device {
@@ -97,6 +98,7 @@ static struct ipmmu_vmsa_iommu_priv *to_
 #define IM_CTX_SIZE0x40
 
 #define IMCTR  0x
+#define IMCTR_VA64 (1 << 29)
 #define IMCTR_TRE  (1 << 17)
 #define IMCTR_AFE  (1 << 16)
 #define IMCTR_RTSEL_MASK   (3 << 4)
@@ -422,10 +424,10 @@ static int ipmmu_domain_init_context(str
 */
domain->cfg.quirks = IO_PGTABLE_QUIRK_ARM_NS;
domain->cfg.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K;
-   domain->cfg.ias = 32;
+   domain->cfg.ias = 30;
domain->cfg.oas = 40;
domain->cfg.tlb = _gather_ops;
-   domain->io_domain.geometry.aperture_end = DMA_BIT_MASK(32);
+   domain->io_domain.geometry.aperture_end = DMA_BIT_MASK(30);
domain->io_domain.geometry.force_aperture = true;
/*
 * TODO: Add support for coherent walk through CCI with DVM and remove
@@ -442,8 +444,9 @@ static int ipmmu_domain_init_context(str
 
domain->context_id = ret;
 
-   domain->iop = alloc_io_pgtable_ops(ARM_32_LPAE_S1, >cfg,
-  domain);
+   domain->iop = alloc_io_pgtable_ops(domain->mmu->features->imctr_va64 ?
+  ARM_64_LPAE_S1 : ARM_32_LPAE_S1,
+  >cfg, domain);
if (!domain->iop) {
ipmmu_domain_free_context(domain->mmu->root,
  domain->context_id);
@@ -456,14 +459,22 @@ static int ipmmu_domain_init_context(str
ipmmu_ctx_write_root(domain, IMTTUBR0, ttbr >> 32);
 
/*
-* TTBCR
-* We use long descriptors with inner-shareable WBWA tables and allocate
-* the whole 32-bit VA space to TTBR0.
-*/
-   if (domain->mmu->features->twobit_imttbcr_sl0)
-   tmp = IMTTBCR_SL0_TWOBIT_LVL_1;
-   else
-   tmp = IMTTBCR_SL0_LVL_1;
+* For IMCTR_VA64 and ARM_64_LPAE_S1 we need lowest bits of TTBCR
+*/
+   if (domain->mmu->features->imctr_va64) {
+   tmp = (0 << 6) | 0x22;
+   } else {
+   /*
+* TTBCR
+* We use long descriptors with inner-shareable WBWA tables
+* and allocate the whole 32-bit VA space to TTBR0.
+*/
+
+   if (domain->mmu->features->twobit_imttbcr_sl0)
+   tmp = IMTTBCR_SL0_TWOBIT_LVL_1;
+   else
+   tmp = IMTTBCR_SL0_LVL_1;
+   }
 
ipmmu_ctx_write_root(domain, IMTTBCR, IMTTBCR_EAE |
 IMTTBCR_SH0_INNER_SHAREABLE | IMTTBCR_ORGN0_WB_WA |
@@ -493,7 +504,8 @@ static int ipmmu_domain_init_context(str
 * required when modifying the context registers.
 */
ipmmu_ctx_write_all(domain, IMCTR,
-   IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
+(domain->mmu->features->imctr_va64 ? IMCTR_VA64 : 0)
+| IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
 
return 0;
 }
@@ -1018,6 +1030,7 @@ static const struct ipmmu_features ipmmu
.number_of_contexts = 1, /* software only tested with one context */
.setup_imbuscr = true,
.twobit_imttbcr_sl0 = false,
+   .imctr_va64 = false,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -1026,6 +1039,7 @@ static const struct ipmmu_features ipmmu
.number_of_contexts = 8,
.setup_imbuscr = false,
.twobit_imttbcr_sl0 = true,
+   .imctr_va64 = true,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {

[PATCH/RFC 00/04] iommu/ipmmu-vmsa: IPMMU IOVA prototyping on r8a7796 ES1.0

[Magnus Damm]

iommu/ipmmu-vmsa: IPMMU IOVA prototyping on r8a7796 ES1.0

[PATCH/RFC 01/04] iommu: Hack to dump page table configuration on boot
[PATCH/RFC 02/04] iommu/ipmmu-vmsa: VA64 mode with 32-bit IOVA
[PATCH/RFC 03/04] iommu/ipmmu-vmsa: VA64 mode with 31-bit IOVA
[PATCH/RFC 04/04] iommu/ipmmu-vmsa: VA64 mode with 30-bit IOVA

This series contains a collection of prototype patches to play with
various IOVA space sizes on the r8a7796 IPMMU. Use one of patches
2-4 to test the desired mode and use patch 1 to dump the page table
configuration on boot to see the size of the pgd and other things.

The actual goal with this activity is to play with the page table
concatenation feature that is needed for 40-bit IOVA support. The
Renesas IPMMU hardware according to the friendly documentation
supports stage 1 translation with concatenation as opposed to other
implementations that only use concatenation for stage 2 translation.

My early investigation of the IPMMMU on r8a7996 ES1.0 only allowed me
to successfully scale down the IOVA from 32 to lower values. The patches
in this series has allowed me to test "Initial lookup level" settings
but without concatenation.

In the not so distant future my plan is to continue this activity on
more recent hardware such as the r8a77965 SoC (R-Car M3-N).

Not-Yet-Signed-off-by: Magnus Damm 
---
 drivers/iommu/io-pgtable-arm.c |   12 
 drivers/iommu/io-pgtable.c |4 +
 drivers/iommu/ipmmu-vmsa.c |  116 +++-
 3 files changed, 95 insertions(+), 37 deletions(-)

[PATCH/RFC 03/04] iommu/ipmmu-vmsa: VA64 mode with 31-bit IOVA

[Magnus Damm]

From: Magnus Damm 

Hack up the IPMMU driver to enable VM64 mode with 31-bit IOVA.

For this configuration the IPMMU hardware is configured with IMTTBCR.SL=1
and TSZ0 bits set to 0x21. This will enable a 31-bit IOVA space and use
"Initial lookup level 1" (in Table D4-13 of armv8_arm.pdf) also known as
"Start at first level" in IPMMU documentation.

Not for upstream merge. Tested on ULCB with r8a7796 ES1.0.

Not-Yet-Signed-off-by: Magnus Damm 
---

 drivers/iommu/ipmmu-vmsa.c |   40 +++-
 1 files changed, 27 insertions(+), 13 deletions(-)

--- 0009/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-11-17 13:11:35.760607110 +0900
@@ -42,6 +42,7 @@ struct ipmmu_features {
unsigned int number_of_contexts;
bool setup_imbuscr;
bool twobit_imttbcr_sl0;
+   bool imctr_va64;
 };
 
 struct ipmmu_vmsa_device {
@@ -97,6 +98,7 @@ static struct ipmmu_vmsa_iommu_priv *to_
 #define IM_CTX_SIZE0x40
 
 #define IMCTR  0x
+#define IMCTR_VA64 (1 << 29)
 #define IMCTR_TRE  (1 << 17)
 #define IMCTR_AFE  (1 << 16)
 #define IMCTR_RTSEL_MASK   (3 << 4)
@@ -422,10 +424,10 @@ static int ipmmu_domain_init_context(str
 */
domain->cfg.quirks = IO_PGTABLE_QUIRK_ARM_NS;
domain->cfg.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K;
-   domain->cfg.ias = 32;
+   domain->cfg.ias = 31;
domain->cfg.oas = 40;
domain->cfg.tlb = _gather_ops;
-   domain->io_domain.geometry.aperture_end = DMA_BIT_MASK(32);
+   domain->io_domain.geometry.aperture_end = DMA_BIT_MASK(31);
domain->io_domain.geometry.force_aperture = true;
/*
 * TODO: Add support for coherent walk through CCI with DVM and remove
@@ -442,8 +444,9 @@ static int ipmmu_domain_init_context(str
 
domain->context_id = ret;
 
-   domain->iop = alloc_io_pgtable_ops(ARM_32_LPAE_S1, >cfg,
-  domain);
+   domain->iop = alloc_io_pgtable_ops(domain->mmu->features->imctr_va64 ?
+  ARM_64_LPAE_S1 : ARM_32_LPAE_S1,
+  >cfg, domain);
if (!domain->iop) {
ipmmu_domain_free_context(domain->mmu->root,
  domain->context_id);
@@ -456,14 +459,22 @@ static int ipmmu_domain_init_context(str
ipmmu_ctx_write_root(domain, IMTTUBR0, ttbr >> 32);
 
/*
-* TTBCR
-* We use long descriptors with inner-shareable WBWA tables and allocate
-* the whole 32-bit VA space to TTBR0.
-*/
-   if (domain->mmu->features->twobit_imttbcr_sl0)
-   tmp = IMTTBCR_SL0_TWOBIT_LVL_1;
-   else
-   tmp = IMTTBCR_SL0_LVL_1;
+* For IMCTR_VA64 and ARM_64_LPAE_S1 we need lowest bits of TTBCR
+*/
+   if (domain->mmu->features->imctr_va64) {
+   tmp = (1 << 6) | 0x21;
+   } else {
+   /*
+* TTBCR
+* We use long descriptors with inner-shareable WBWA tables
+* and allocate the whole 32-bit VA space to TTBR0.
+*/
+
+   if (domain->mmu->features->twobit_imttbcr_sl0)
+   tmp = IMTTBCR_SL0_TWOBIT_LVL_1;
+   else
+   tmp = IMTTBCR_SL0_LVL_1;
+   }
 
ipmmu_ctx_write_root(domain, IMTTBCR, IMTTBCR_EAE |
 IMTTBCR_SH0_INNER_SHAREABLE | IMTTBCR_ORGN0_WB_WA |
@@ -493,7 +504,8 @@ static int ipmmu_domain_init_context(str
 * required when modifying the context registers.
 */
ipmmu_ctx_write_all(domain, IMCTR,
-   IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
+(domain->mmu->features->imctr_va64 ? IMCTR_VA64 : 0)
+| IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
 
return 0;
 }
@@ -1018,6 +1030,7 @@ static const struct ipmmu_features ipmmu
.number_of_contexts = 1, /* software only tested with one context */
.setup_imbuscr = true,
.twobit_imttbcr_sl0 = false,
+   .imctr_va64 = false,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -1026,6 +1039,7 @@ static const struct ipmmu_features ipmmu
.number_of_contexts = 8,
.setup_imbuscr = false,
.twobit_imttbcr_sl0 = true,
+   .imctr_va64 = true,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {

[PATCH/RFC 01/04] iommu: Hack to dump page table configuration on boot

[Magnus Damm]

From: Magnus Damm 

Adjust code to output page table configuration on boot. Not for upstream merge.

Not-Yet-Signed-off-by: Magnus Damm 
---

 drivers/iommu/io-pgtable-arm.c |   12 
 drivers/iommu/io-pgtable.c |4 
 2 files changed, 16 insertions(+)

--- 0001/drivers/iommu/io-pgtable-arm.c
+++ work/drivers/iommu/io-pgtable-arm.c 2017-11-17 12:44:09.100607110 +0900
@@ -970,6 +970,18 @@ struct io_pgtable_init_fns io_pgtable_ar
.free   = arm_lpae_free_pgtable,
 };
 
+void arm_lpae_dump(struct io_pgtable_ops *ops)
+{
+   struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+   struct io_pgtable_cfg *cfg = >iop.cfg;
+
+   pr_err("cfg: pgsize_bitmap 0x%lx, ias %u-bit\n",
+   cfg->pgsize_bitmap, cfg->ias);
+   pr_err("data: %d levels, 0x%zx pgd_size, %lu pg_shift, %lu 
bits_per_level, pgd @ %p\n",
+   data->levels, data->pgd_size, data->pg_shift,
+   data->bits_per_level, data->pgd);
+}
+
 #ifdef CONFIG_IOMMU_IO_PGTABLE_LPAE_SELFTEST
 
 static struct io_pgtable_cfg *cfg_cookie;
--- 0001/drivers/iommu/io-pgtable.c
+++ work/drivers/iommu/io-pgtable.c 2017-11-17 12:44:31.290607110 +0900
@@ -37,6 +37,8 @@ io_pgtable_init_table[IO_PGTABLE_NUM_FMT
 #endif
 };
 
+void arm_lpae_dump(struct io_pgtable_ops *ops);
+
 struct io_pgtable_ops *alloc_io_pgtable_ops(enum io_pgtable_fmt fmt,
struct io_pgtable_cfg *cfg,
void *cookie)
@@ -59,6 +61,8 @@ struct io_pgtable_ops *alloc_io_pgtable_
iop->cookie = cookie;
iop->cfg= *cfg;
 
+   arm_lpae_dump(>ops);
+
return >ops;
 }
 

[PATCH/RFC 02/04] iommu/ipmmu-vmsa: VA64 mode with 32-bit IOVA

[Magnus Damm]

From: Magnus Damm 

Hack up the IPMMU driver to enable VM64 mode with 32-bit IOVA.

For this configuration the IPMMU hardware is configured with IMTTBCR.SL=1
and TSZ0 bits set to 0x20. This will enable a 32-bit IOVA space and use
"Initial lookup level 1" (in Table D4-13 of armv8_arm.pdf) also known as
"Start at first level" in IPMMU documentation.

Not for upstream merge. Tested on ULCB with r8a7796 ES1.0.

Earlier version posted as:
[PATCH/RFC] iommu/ipmmu-vmsa: Initial R-Car Gen3 VA64 mode support

The SL bit position has since then been updated to match more recent
IPMMU hardware documentation.

Not-Yet-Signed-off-by: Magnus Damm 
---

 drivers/iommu/ipmmu-vmsa.c |   36 +---
 1 files changed, 25 insertions(+), 11 deletions(-)

--- 0009/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-11-17 13:17:33.510607110 +0900
@@ -42,6 +42,7 @@ struct ipmmu_features {
unsigned int number_of_contexts;
bool setup_imbuscr;
bool twobit_imttbcr_sl0;
+   bool imctr_va64;
 };
 
 struct ipmmu_vmsa_device {
@@ -97,6 +98,7 @@ static struct ipmmu_vmsa_iommu_priv *to_
 #define IM_CTX_SIZE0x40
 
 #define IMCTR  0x
+#define IMCTR_VA64 (1 << 29)
 #define IMCTR_TRE  (1 << 17)
 #define IMCTR_AFE  (1 << 16)
 #define IMCTR_RTSEL_MASK   (3 << 4)
@@ -442,8 +444,9 @@ static int ipmmu_domain_init_context(str
 
domain->context_id = ret;
 
-   domain->iop = alloc_io_pgtable_ops(ARM_32_LPAE_S1, >cfg,
-  domain);
+   domain->iop = alloc_io_pgtable_ops(domain->mmu->features->imctr_va64 ?
+  ARM_64_LPAE_S1 : ARM_32_LPAE_S1,
+  >cfg, domain);
if (!domain->iop) {
ipmmu_domain_free_context(domain->mmu->root,
  domain->context_id);
@@ -456,14 +459,22 @@ static int ipmmu_domain_init_context(str
ipmmu_ctx_write_root(domain, IMTTUBR0, ttbr >> 32);
 
/*
-* TTBCR
-* We use long descriptors with inner-shareable WBWA tables and allocate
-* the whole 32-bit VA space to TTBR0.
-*/
-   if (domain->mmu->features->twobit_imttbcr_sl0)
-   tmp = IMTTBCR_SL0_TWOBIT_LVL_1;
-   else
-   tmp = IMTTBCR_SL0_LVL_1;
+* For IMCTR_VA64 and ARM_64_LPAE_S1 we need lowest bits of TTBCR
+*/
+   if (domain->mmu->features->imctr_va64) {
+   tmp = (1 << 6) | 0x20;
+   } else {
+   /*
+* TTBCR
+* We use long descriptors with inner-shareable WBWA tables
+* and allocate the whole 32-bit VA space to TTBR0.
+*/
+
+   if (domain->mmu->features->twobit_imttbcr_sl0)
+   tmp = IMTTBCR_SL0_TWOBIT_LVL_1;
+   else
+   tmp = IMTTBCR_SL0_LVL_1;
+   }
 
ipmmu_ctx_write_root(domain, IMTTBCR, IMTTBCR_EAE |
 IMTTBCR_SH0_INNER_SHAREABLE | IMTTBCR_ORGN0_WB_WA |
@@ -493,7 +504,8 @@ static int ipmmu_domain_init_context(str
 * required when modifying the context registers.
 */
ipmmu_ctx_write_all(domain, IMCTR,
-   IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
+(domain->mmu->features->imctr_va64 ? IMCTR_VA64 : 0)
+| IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
 
return 0;
 }
@@ -1018,6 +1030,7 @@ static const struct ipmmu_features ipmmu
.number_of_contexts = 1, /* software only tested with one context */
.setup_imbuscr = true,
.twobit_imttbcr_sl0 = false,
+   .imctr_va64 = false,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -1026,6 +1039,7 @@ static const struct ipmmu_features ipmmu
.number_of_contexts = 8,
.setup_imbuscr = false,
.twobit_imttbcr_sl0 = true,
+   .imctr_va64 = true,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {

[PATCH/RFC] arm64: r8a77965 Salvator-X SoC/board support prototype

[Magnus Damm]

From: Magnus Damm 

Here's a simple prototype hack to get the R-Car M3-N SoC working with
the r8a77965 Salvator-X that is available in my remote access rack.

This code will allow me to test and development IPMMU features on
latest mainline together with new hardware such as r8a77965.

As base the most recent renesas-drivers release is used, and since the
regular tag is optimized for stability and lacking various -next trees
this code is based on "renesas-drivers-next-2017-11-14-v4.14".

The following patches are picked from renesas-bsp @ kernel.org and
in particular the recent "rcar-3.5.9.rc2" release:

dca5c4d1adc6 arm64: renesas: Add Renesas R8A77965 Kconfig support
6f3c0086b8b2 soc: renesas: identify R-Car M3N
711dec8fc1df soc: renesas: rcar-rst: Add R8A77965 support (*)
c8418d81dd26 clk: renesas: Add r8a77965 CPG Core Clock Definitions
d642ad7d1a40 clk: renesas: cpg-mssr: Add support for R-Car M3N (*)
4cec6dcde2f5 arm64: dts: r8a77965: Add Renesas R8A77965 SoC support (*)
92be4952a4d5 arm64: dts: r8a77965-salvator-x: Add Salvator-X board on R8A77965 
SoC support (*)
1c69363cc1eb arm64: dts: r8a77965-salvator-x: Add reserved memory regions

Commits above original author is Kihara-san:
Signed-off-by: Takeshi Kihara 

Commits marked with (*) above have been updated to fit on upstream

Since this is prototype code and not suitable for mainline merge as-is:
Not-Yet-Signed-off-by: Magnus Damm 
---

 Documentation/devicetree/bindings/arm/shmobile.txt   |4 
 Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt |5 
 arch/arm64/Kconfig.platforms |6 
 arch/arm64/boot/dts/renesas/Makefile |1 
 arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts  |   79 
 arch/arm64/boot/dts/renesas/r8a77965.dtsi|  141 +++
 drivers/clk/renesas/Kconfig  |5 
 drivers/clk/renesas/Makefile |1 
 drivers/clk/renesas/r8a77965-cpg-mssr.c  |  195 ++
 drivers/clk/renesas/renesas-cpg-mssr.c   |6 
 drivers/clk/renesas/renesas-cpg-mssr.h   |1 
 drivers/soc/renesas/Kconfig  |4 
 drivers/soc/renesas/rcar-rst.c   |1 
 drivers/soc/renesas/renesas-soc.c|8 
 include/dt-bindings/clock/r8a77965-cpg-mssr.h|   66 +++
 15 files changed, 519 insertions(+), 4 deletions(-)

--- 0001/Documentation/devicetree/bindings/arm/shmobile.txt
+++ work/Documentation/devicetree/bindings/arm/shmobile.txt 2017-11-18 
12:31:14.510607110 +0900
@@ -39,6 +39,8 @@ SoCs:
 compatible = "renesas,r8a7795"
   - R-Car M3-W (R8A77960)
 compatible = "renesas,r8a7796"
+  - R-Car M3-N (R8A77965)
+compatible = "renesas,r8a77965"
   - R-Car V3M (R8A77970)
 compatible = "renesas,r8a77970"
   - R-Car D3 (R8A77995)
@@ -102,6 +104,8 @@ Boards:
 compatible = "renesas,salvator-x", "renesas,r8a7795"
   - Salvator-X (RTP0RC7796SIPB0011S)
 compatible = "renesas,salvator-x", "renesas,r8a7796"
+  - Salvator-X (RTP0RC7796SIPB0011S (M3-N))
+compatible = "renesas,salvator-x", "renesas,r8a77965"
   - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
 compatible = "renesas,salvator-xs", "renesas,r8a7795"
   - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
--- 0001/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ work/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt   
2017-11-18 12:31:14.510607110 +0900
@@ -22,6 +22,7 @@ Required Properties:
   - "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2)
   - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
   - "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
+  - "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N)
   - "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M)
   - "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3)
 
@@ -32,8 +33,8 @@ Required Properties:
 clock-names
   - clock-names: List of external parent clock names. Valid names are:
   - "extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794,
-r8a7795, r8a7796, r8a77970, r8a77995)
-  - "extalr" (r8a7795, r8a7796, r8a77970)
+r8a7795, r8a7796, r8a77965, r8a77970, r8a77995)
+  - "extalr" (r8a7795, r8a7796, r8a77965, r8a77970)
   - "usb_extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7793, r8a7794)
 
   - #clock-cells: Must be 2
--- 0001/arch/arm64/Kconfig.platforms
+++ work/arch/arm64/Kconfig.platforms   2017-11-18 12:31:14.510607110 +0900
@@ -198,6 +198,12 @@ config ARCH_R8A77995
help
  This enables support for the Renesas R-Car D3 SoC.
 
+config ARCH_R8A77965
+   bool "Renesas R-Car 

Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list

[Rob Herring]

On Thu, Nov 16, 2017 at 06:22:48PM +, Fabrizio Castro wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
> v1->v2:
> * new patch triggered by Geert's comment, see the below link for details:
>   https://www.mail-archive.com/linux-media@vger.kernel.org/msg121992.html
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

[Rob Herring]

On Thu, Nov 16, 2017 at 06:22:49PM +, Fabrizio Castro wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
> v1->v2:
> * Fixed double "change" in changelog
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH] dt-bindings: i2c: eeprom: Add Renesas R1EX24128

[Rob Herring]

On Thu, Nov 16, 2017 at 02:46:34PM +0100, Geert Uytterhoeven wrote:
> Document the compatible value for the Renesas R1EX24128ASAS0A two-wire
> serial interface EEPROM, so it can be used in DTS files without causing
> checkpatch warnings.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH 3/4] arm64: dts: r8a77995: draak: enable SDHI2

[Marek Vasut]

On 11/17/2017 03:35 PM, Simon Horman wrote:
> On Thu, Nov 16, 2017 at 10:43:35AM +0100, Geert Uytterhoeven wrote:
>> Hi Uli,
>>
>> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>>  wrote:
>>> The single SDHI controller is connected to eMMC.
>>>
>>> Signed-off-by: Ulrich Hecht 
>>
>> Thanks for your patch!
>>
>>> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
>>> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
>>> @@ -32,6 +32,24 @@
>>> /* first 128MB is reserved for secure area. */
>>> reg = <0x0 0x4800 0x0 0x1800>;
>>> };
>>> +
>>> +   reg_1p8v: regulator0 {
>>> +   compatible = "regulator-fixed";
>>> +   regulator-name = "fixed-1.8V";
>>> +   regulator-min-microvolt = <180>;
>>> +   regulator-max-microvolt = <180>;
>>> +   regulator-boot-on;
>>> +   regulator-always-on;
>>> +   };
>>> +
>>> +   reg_3p3v: regulator1 {
>>> +   compatible = "regulator-fixed";
>>> +   regulator-name = "fixed-3.3V";
>>> +   regulator-min-microvolt = <330>;
>>> +   regulator-max-microvolt = <330>;
>>> +   regulator-boot-on;
>>> +   regulator-always-on;
>>> +   };
>>
>> As the eMMC is 1.8V only, I'll defer the review to the people looking
>> into the need
>> to specify the 3.3V pinctrl on other R-Car Gen3 boards.
> 
> I don't see any harm in describing the hardware present in DT.
> 
The hardware present has 1V8 only bus interface. The 3V3 rail connected
to the eMMC is used for the flash array only, not for the bus interface.
The bus interface has a separate power rail, 1V8 one.

-- 
Best regards,
Marek Vasut

Re: [PATCH] dt-bindings: qspi: Add r8a7743/5 to the compatible list

[Mark Brown]

On Fri, Nov 17, 2017 at 06:00:46PM +, Fabrizio Castro wrote:

> this patch has been around for some time now, it was reviewed-by Geert 
> Uytterhoeven and acked-by Rob Herring, any news?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, though there are some other maintainers who like them - if in
doubt look at how patches for the subsystem are normally handled.

Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.  Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.


signature.asc
Description: PGP signature

RE: [PATCH] dt-bindings: qspi: Add r8a7743/5 to the compatible list

[Fabrizio Castro]

Dear All,

this patch has been around for some time now, it was reviewed-by Geert 
Uytterhoeven and acked-by Rob Herring, any news?

Thanks,
Fab

> Subject: [PATCH] dt-bindings: qspi: Add r8a7743/5 to the compatible list
>
> Signed-off-by: Fabrizio Castro 
> ---
>  Documentation/devicetree/bindings/spi/spi-rspi.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt 
> b/Documentation/devicetree/bindings/spi/spi-rspi.txt
> index 8f4169f..3b02b3a 100644
> --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt
> @@ -5,11 +5,14 @@ Required properties:
>   "renesas,rspi-", "renesas,rspi" as fallback.
>   For Renesas Serial Peripheral Interface on RZ/A1H:
>   "renesas,rspi-", "renesas,rspi-rz" as fallback.
> - For Quad Serial Peripheral Interface on R-Car Gen2:
> + For Quad Serial Peripheral Interface on R-Car Gen2 and
> + RZ/G1 devices:
>   "renesas,qspi-", "renesas,qspi" as fallback.
>   Examples with soctypes are:
>  - "renesas,rspi-sh7757" (SH)
>  - "renesas,rspi-r7s72100" (RZ/A1H)
> +- "renesas,qspi-r8a7743" (RZ/G1M)
> +- "renesas,qspi-r8a7745" (RZ/G1E)
>  - "renesas,qspi-r8a7790" (R-Car H2)
>  - "renesas,qspi-r8a7791" (R-Car M2-W)
>  - "renesas,qspi-r8a7792" (R-Car V2H)
> --
> 2.7.4




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling

[Lorenzo Pieralisi]

Hi Marek,

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.

> PM_ENTER_L1 DLLP to the host controller. At this point, we can no longer
> access the card's config registers.
> 
> The R-Car host controller will handle taking cards out of L1 as long as
> the host controller has also been transitioned to L1 link state.

I wonder why this can't be done in a PM restore hook but that's not
really where my question is.

> Ideally, we would detect the PM_ENTER_L1 DLLP using an interrupt and
> transition the host to L1 immediately. However, this patch just ensures
> that we can talk to cards after they have gone into L1.

> When attempting a config access, it checks to see if the card has gone
> into L1, and if so, does the same for the host controller.
> 
> This is based on a patch by Hien Dang 
> 
> Signed-off-by: Phil Edworthy 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: - Drop extra parenthesis
> - Use GENMASK()
> - Fix comment "The HW will handle coming of of L1.", s/of of/out of/
> ---
>  drivers/pci/host/pcie-rcar.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index ab61829db389..068bf9067ec1 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -92,6 +92,13 @@
>  #define MACCTLR  0x011058
>  #define  SPEED_CHANGEBIT(24)
>  #define  SCRAMBLE_DISABLEBIT(27)
> +#define PMSR 0x01105c
> +#define  L1FAEG  BIT(31)
> +#define  PM_ENTER_L1RX   BIT(23)
> +#define  PMSTATE GENMASK(18, 16)
> +#define  PMSTATE_L1  GENMASK(17, 16)
> +#define PMCTLR   0x011060
> +#define  L1_INIT BIT(31)
>  #define MACS2R   0x011078
>  #define MACCGSPSETR  0x011084
>  #define  SPCNGRSNBIT(31)
> @@ -191,6 +198,7 @@ static int rcar_pcie_config_access(struct rcar_pcie *pcie,
>   unsigned int devfn, int where, u32 *data)
>  {
>   int dev, func, reg, index;
> + u32 val;
>  
>   dev = PCI_SLOT(devfn);
>   func = PCI_FUNC(devfn);
> @@ -232,6 +240,22 @@ static int rcar_pcie_config_access(struct rcar_pcie 
> *pcie,
>   if (pcie->root_bus_nr < 0)
>   return PCIBIOS_DEVICE_NOT_FOUND;
>  
> + /*
> +  * If we are not in L1 link state and we have received PM_ENTER_L1 DLLP,
> +  * transition to L1 link state. The HW will handle coming out of L1.
> +  */
> + val = rcar_pci_read_reg(pcie, PMSR);
> + if (val & PM_ENTER_L1RX && (val & PMSTATE) != PMSTATE_L1) {
> + rcar_pci_write_reg(pcie, L1_INIT, PMCTLR);
> +
> + /* Wait until we are in L1 */
> + while (!(val & L1FAEG))
> + val = rcar_pci_read_reg(pcie, PMSR);
> +
> + /* Clear flags indicating link has transitioned to L1 */
> + rcar_pci_write_reg(pcie, L1FAEG | PM_ENTER_L1RX, PMSR);
> + }

I do not get why you need to add the DLLP check for _every_ given config
access and how/why it is just related to suspend/resume and not eg cold
boot (I supposed it is because devices can enter L1 upon suspend(?)), I
would ask you please to provide a thorough explanation so that I can
actually review this patch (the commit log must be rewritten nonetheless,
I do not think it is clear, at least it is not for me).

Thanks,
Lorenzo

> +
>   /* Clear errors */
>   rcar_pci_write_reg(pcie, rcar_pci_read_reg(pcie, PCIEERRFR), PCIEERRFR);
>  
> -- 
> 2.11.0
> 

Re: [PATCH 5/6] arm64: renesas: draak: enable I2C controller 1

[Simon Horman]

On Fri, Nov 17, 2017 at 06:32:19AM -0800, Simon Horman wrote:
> On Thu, Nov 16, 2017 at 10:31:31AM +0100, Geert Uytterhoeven wrote:
> > Hi Uli,
> > 
> > On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
> >  wrote:
> > > No devices to add, I2C1 has an external connector only.
> > >
> > > Signed-off-by: Ulrich Hecht 
> > 
> > Thanks for your patch!
> > 
> > Reviewed-by: Geert Uytterhoeven 
> > but please see below.
> 
> Thanks, applied.

Sorry, I was a bit hasty there as this patch
depends on a patch earlier in the series which I have not applied.

I've dropped this patch for now and will wait a bit longer for the review
to unfold.

> > > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > 
> > > @@ -84,6 +89,12 @@
> > > };
> > >  };
> > >
> > > + {
> > > +   pinctrl-0 = <_pins>;
> > > +   pinctrl-names = "default";
> > > +   status = "okay";
> > 
> > If no devices are connected, perhaps it's wise to defer the status update
> > to e.g. an overlay that describes what's connected to CN23?
> > 
> > Or do you want it enabled to allow adding devices manually using
> > /sys/bus/i2c/devices/i2c-1/new_device?
> 
> Ulrich, please consider following up on this.
> 

Re: [PATCH 4/6] arm64: renesas: draak: enable I2C controller 0 and EEPROM

[Simon Horman]

On Fri, Nov 17, 2017 at 06:31:21AM -0800, Simon Horman wrote:
> On Thu, Nov 16, 2017 at 10:27:56AM +0100, Geert Uytterhoeven wrote:
> > Hi Ulrich,
> > 
> > On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
> >  wrote:
> > > Enables EEPROM on I2C0 on the Draak board.
> > >
> > > Signed-off-by: Ulrich Hecht 
> > 
> > Thanks for your patch!
> > 
> > > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > 
> > > @@ -67,6 +72,18 @@
> > > };
> > >  };
> > >
> > > + {
> > > +   pinctrl-0 = <_pins>;
> > > +   pinctrl-names = "default";
> > > +   status = "okay";
> > > +
> > > +   eeprom@50 {
> > > +   compatible = "atmel,24c01";
> > 
> > This is actually a ROHM Semiconductor BR24T01FVM-W, so it should be
> > 
> > compatible = "rohm,br24t01", "atmel,24c01";
> 
> Applied with the above change.

Sorry, I was a bit hasty there as this patch
depends on a patch earlier in the series which I have not applied.

I've dropped this patch for now and will wait a bit longer for the review
to unfold.

> 
> > Please also submit a patch to add that compatible value to
> > Documentation/devicetree/bindings/eeprom/eeprom.txt.
> 
> Ulrich, please follow-up on this, thanks!
> 
> > With the above fixed:
> > Reviewed-by: Geert Uytterhoeven 
> > 
> > Gr{oetje,eeting}s,
> > 
> > Geert
> > 
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> > ge...@linux-m68k.org
> > 
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like 
> > that.
> > -- Linus Torvalds
> > 
> 

Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: add GPIO support

[Simon Horman]

On Fri, Nov 17, 2017 at 07:11:18PM +0300, Sergei Shtylyov wrote:
> On 11/17/2017 05:19 PM, Simon Horman wrote:
> 
> > > > Describe all 6 GPIO controllers in the R8A77970 device tree.
> > > > 
> > > > Signed-off-by: Sergei Shtylyov 
> > > 
> > > Reviewed-by: Geert Uytterhoeven 
> > 
> > Thanks, applied.
> 
>It doesn't build w/o PFC support (and I thought I mde it clearin the
> cover letter), so please either merge R8A77970 PFC patch or pull this one
> out!

Sorry, my bad. I have dropped this series for now.
Please resubmit or otherwise ping me once the dependency hits
an RC release.

[GIT PULL FOR renesas-drivers] vsp1: TLB optimisation and DL caching

[Kieran Bingham]

From: Kieran Bingham 

Hi Geert,

Please consider this updated tag for the next renesas drivers release.

Regards

Kieran


The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4:

  Linux 4.14 (2017-11-12 10:46:13 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git 
tags/vsp1/tlb-optimise/v4

for you to fetch changes up to 84592170dbe4ffdb4cc8d33aa20c23218e029ee7:

  v4l: vsp1: Reduce display list body size (2017-11-17 15:38:43 +)


Kieran Bingham (9):
  v4l: vsp1: Reword uses of 'fragment' as 'body'
  v4l: vsp1: Protect bodies against overflow
  v4l: vsp1: Provide a body pool
  v4l: vsp1: Convert display lists to use new body pool
  v4l: vsp1: Use reference counting for bodies
  v4l: vsp1: Refactor display list configure operations
  v4l: vsp1: Adapt entities to configure into a body
  v4l: vsp1: Move video configuration to a cached dlb
  v4l: vsp1: Reduce display list body size

 drivers/media/platform/vsp1/vsp1_bru.c|  32 ++-
 drivers/media/platform/vsp1/vsp1_clu.c|  94 ---
 drivers/media/platform/vsp1/vsp1_clu.h|   1 +
 drivers/media/platform/vsp1/vsp1_dl.c | 393 +-
 drivers/media/platform/vsp1/vsp1_dl.h |  21 +-
 drivers/media/platform/vsp1/vsp1_drm.c|  21 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  23 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  31 ++-
 drivers/media/platform/vsp1/vsp1_hgo.c|  26 +-
 drivers/media/platform/vsp1/vsp1_hgt.c|  28 +--
 drivers/media/platform/vsp1/vsp1_hsit.c   |  20 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  23 +-
 drivers/media/platform/vsp1/vsp1_lut.c|  71 --
 drivers/media/platform/vsp1/vsp1_lut.h|   1 +
 drivers/media/platform/vsp1/vsp1_pipe.c   |  11 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |   7 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 179 +++---
 drivers/media/platform/vsp1/vsp1_sru.c|  24 +-
 drivers/media/platform/vsp1/vsp1_uds.c|  73 +++---
 drivers/media/platform/vsp1/vsp1_uds.h|   2 +-
 drivers/media/platform/vsp1/vsp1_video.c  |  82 ---
 drivers/media/platform/vsp1/vsp1_video.h  |   2 +
 drivers/media/platform/vsp1/vsp1_wpf.c| 325 
 23 files changed, 820 insertions(+), 670 deletions(-)

Re: [PATCH 0/7] R-Car D3 (r8a77995) CAN support

[Wolfram Sang]

> Here's CAN and CAN FD support for the R-Car D3. This is a by-the-datasheet
> implementation, with the datasheet missing some bits, namely the pin map.
> I filled in the gaps with frog DNA^W^W^Wby deducing the information from
> pin numbers already in the PFC driver, so careful scrutiny is advised.

Did you have a chance to test one of the configurations?



signature.asc
Description: PGP signature

Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: add GPIO support

[Sergei Shtylyov]

On 11/17/2017 05:19 PM, Simon Horman wrote:


Describe all 6 GPIO controllers in the R8A77970 device tree.

Signed-off-by: Sergei Shtylyov 


Reviewed-by: Geert Uytterhoeven 


Thanks, applied.


   It doesn't build w/o PFC support (and I thought I mde it clearin the cover 
letter), so please either merge R8A77970 PFC patch or pull this one out!


MBR, Segei

[PATCH v4 6/9] v4l: vsp1: Refactor display list configure operations

[Kieran Bingham]

The entities provide a single .configure operation which configures the
object into the target display list, based on the vsp1_entity_params
selection.

This restricts us to a single function prototype for both static
configuration (the pre-stream INIT stage) and the dynamic runtime stages
for both each frame - and each partition therein.

Split the configure function into two parts, '.prepare()' and
'.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
.configure(). The configuration for individual partitions is handled by
passing the partition number to the configure call, and processing any
runtime stage actions on the first partition only.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_clu.c|  42 +--
 drivers/media/platform/vsp1/vsp1_drm.c|  11 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
 drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
 drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
 drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
 drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
 drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
 15 files changed, 358 insertions(+), 371 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index e8fd2ae3b3eb..b9ff96f76b3e 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -285,19 +285,15 @@ static const struct v4l2_subdev_ops bru_ops = {
  * VSP1 Entity Operations
  */
 
-static void bru_configure(struct vsp1_entity *entity,
- struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+static void bru_prepare(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
unsigned int flags;
unsigned int i;
 
-   if (params != VSP1_ENTITY_PARAMS_INIT)
-   return;
-
format = vsp1_entity_get_pad_format(>entity, bru->entity.config,
bru->entity.source_pad);
 
@@ -404,7 +400,7 @@ static void bru_configure(struct vsp1_entity *entity,
 }
 
 static const struct vsp1_entity_operations bru_entity_ops = {
-   .configure = bru_configure,
+   .prepare = bru_prepare,
 };
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index b2a39a6ef7e4..be4d7e493746 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -213,37 +213,36 @@ static const struct v4l2_subdev_ops clu_ops = {
 /* 
-
  * VSP1 Entity Operations
  */
+static void clu_prepare(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   /*
+* The yuv_mode can't be changed during streaming. Cache it internally
+* for future runtime configuration calls.
+*/
+   struct v4l2_mbus_framefmt *format;
+
+   format = vsp1_entity_get_pad_format(>entity,
+   clu->entity.config,
+   CLU_PAD_SINK);
+   clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
+}
 
 static void clu_configure(struct vsp1_entity *entity,
  struct vsp1_pipeline *pipe,
  struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+ unsigned int partition)
 {
struct vsp1_clu *clu = to_clu(>subdev);
struct vsp1_dl_body *dlb;
unsigned long flags;
u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN;
 
-   switch (params) {
-   case VSP1_ENTITY_PARAMS_INIT: {
-   /*
-* The format can't be changed during streaming, only verify it
-* at setup time and store the information internally for future
-* runtime configuration calls.
-*/
-   struct v4l2_mbus_framefmt *format;
-
-   format = vsp1_entity_get_pad_format(>entity,
-

[PATCH v4 3/9] v4l: vsp1: Provide a body pool

[Kieran Bingham]

Each display list allocates a body to store register values in a dma
accessible buffer from a dma_alloc_wc() allocation. Each of these
results in an entry in the TLB, and a large number of display list
allocations adds pressure to this resource.

Reduce TLB pressure on the IPMMUs by allocating multiple display list
bodies in a single allocation, and providing these to the display list
through a 'body pool'. A pool can be allocated by the display list
manager or entities which require their own body allocations.

Signed-off-by: Kieran Bingham 

---
v4:
 - Provide comment explaining extra allocation on body pool
   highlighting area for optimisation later.

v3:
 - s/fragment/body/, s/fragments/bodies/
 - qty -> num_bodies
 - indentation fix
 - s/vsp1_dl_body_pool_{alloc,free}/vsp1_dl_body_pool_{create,destroy}/'
 - Add kerneldoc to non-static functions

v2:
 - assign dlb->dma correctly
---
 drivers/media/platform/vsp1/vsp1_dl.c | 163 +++-
 drivers/media/platform/vsp1/vsp1_dl.h |   8 +-
 2 files changed, 171 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index a45d35aa676e..0047030483e1 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -45,6 +45,8 @@ struct vsp1_dl_entry {
 /**
  * struct vsp1_dl_body - Display list body
  * @list: entry in the display list list of bodies
+ * @free: entry in the pool free body list
+ * @pool: pool to which this body belongs
  * @vsp1: the VSP1 device
  * @entries: array of entries
  * @dma: DMA address of the entries
@@ -54,6 +56,9 @@ struct vsp1_dl_entry {
  */
 struct vsp1_dl_body {
struct list_head list;
+   struct list_head free;
+
+   struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
 
struct vsp1_dl_entry *entries;
@@ -65,6 +70,30 @@ struct vsp1_dl_body {
 };
 
 /**
+ * struct vsp1_dl_body_pool - display list body pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the pool and free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_body_pool {
+   /* DMA allocation */
+   dma_addr_t dma;
+   size_t size;
+   void *mem;
+
+   /* Body management */
+   struct vsp1_dl_body *bodies;
+   struct list_head free;
+   spinlock_t lock;
+
+   struct vsp1_device *vsp1;
+};
+
+/**
  * struct vsp1_dl_list - Display list
  * @list: entry in the display list manager lists
  * @dlm: the display list manager
@@ -104,6 +133,7 @@ enum vsp1_dl_mode {
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
+ * @pool: body pool for the display list bodies
  * @gc_work: bodies garbage collector work struct
  * @gc_bodies: array of display list bodies waiting to be freed
  */
@@ -119,6 +149,8 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *queued;
struct vsp1_dl_list *pending;
 
+   struct vsp1_dl_body_pool *pool;
+
struct work_struct gc_work;
struct list_head gc_bodies;
 };
@@ -127,6 +159,137 @@ struct vsp1_dl_manager {
  * Display List Body Management
  */
 
+/**
+ * vsp1_dl_body_pool_create - Create a pool of bodies from a single allocation
+ * @vsp1: The VSP1 device
+ * @num_bodies: The quantity of bodies to allocate
+ * @num_entries: The maximum number of entries that the body can contain
+ * @extra_size: Extra allocation provided for the bodies
+ *
+ * Allocate a pool of display list bodies each with enough memory to contain 
the
+ * requested number of entries.
+ *
+ * Return a pointer to a pool on success or NULL if memory can't be allocated.
+ */
+struct vsp1_dl_body_pool *
+vsp1_dl_body_pool_create(struct vsp1_device *vsp1, unsigned int num_bodies,
+unsigned int num_entries, size_t extra_size)
+{
+   struct vsp1_dl_body_pool *pool;
+   size_t dlb_size;
+   unsigned int i;
+
+   pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+   if (!pool)
+   return NULL;
+
+   pool->vsp1 = vsp1;
+
+   /*
+* Todo: 'extra_size' is only used by vsp1_dlm_create(), to allocate
+* extra memory for the display list header. We need only one header per
+* display list, not per display list body, thus this allocation is
+* extraneous and should be reworked in the future.
+*/
+   dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size;
+   pool->size = dlb_size * num_bodies;
+
+   pool->bodies = kcalloc(num_bodies, sizeof(*pool->bodies), GFP_KERNEL);
+   if (!pool->bodies) {
+   kfree(pool);
+   return NULL;
+   }
+
+   pool->mem = 

[PATCH v4 9/9] v4l: vsp1: Reduce display list body size

[Kieran Bingham]

The display list originally allocated a body of 256 entries to store all
of the register lists required for each frame.

This has now been separated into fragments for constant stream setup, and
runtime updates.

Empirical testing shows that the body0 now uses a maximum of 41
registers for each frame, for both DRM and Video API pipelines thus a
rounded 64 entries provides a suitable allocation.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 49d88b03d359..278451e8bc4e 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -21,7 +21,7 @@
 #include "vsp1.h"
 #include "vsp1_dl.h"
 
-#define VSP1_DL_NUM_ENTRIES256
+#define VSP1_DL_NUM_ENTRIES64
 
 #define VSP1_DLH_INT_ENABLE(1 << 1)
 #define VSP1_DLH_AUTO_START(1 << 0)
-- 
git-series 0.9.1

[PATCH v4 4/9] v4l: vsp1: Convert display lists to use new body pool

[Kieran Bingham]

Adapt the dl->body0 object to use an object from the body pool. This
greatly reduces the pressure on the TLB for IPMMU use cases, as all of
the lists use a single allocation for the main body.

The CLU and LUT objects pre-allocate a pool containing three bodies,
allowing a userspace update before the hardware has committed a previous
set of tables.

Bodies are no longer 'freed' in interrupt context, but instead released
back to their respective pools. This allows us to remove the garbage
collector in the DLM.

Signed-off-by: Kieran Bingham 

---
v3:
 - 's/fragment/body', 's/fragments/bodies/'
 - CLU/LUT now allocate 3 bodies
 - vsp1_dl_list_fragments_free -> vsp1_dl_list_bodies_put

v2:
 - Use dl->body0->max_entries to determine header offset, instead of the
   global constant VSP1_DL_NUM_ENTRIES which is incorrect.
 - squash updates for LUT, CLU, and fragment cleanup into single patch.
   (Not fully bisectable when separated)
---
 drivers/media/platform/vsp1/vsp1_clu.c |  27 ++-
 drivers/media/platform/vsp1/vsp1_clu.h |   1 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 223 ++
 drivers/media/platform/vsp1/vsp1_dl.h  |   3 +-
 drivers/media/platform/vsp1/vsp1_lut.c |  27 ++-
 drivers/media/platform/vsp1/vsp1_lut.h |   1 +-
 6 files changed, 101 insertions(+), 181 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 9621afa3658c..2018144470c5 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -23,6 +23,8 @@
 #define CLU_MIN_SIZE   4U
 #define CLU_MAX_SIZE   8190U
 
+#define CLU_SIZE   (17 * 17 * 17)
+
 /* 
-
  * Device Access
  */
@@ -47,19 +49,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_body_get(clu->pool);
if (!dlb)
return -ENOMEM;
 
vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
-   for (i = 0; i < 17 * 17 * 17; ++i)
+   for (i = 0; i < CLU_SIZE; ++i)
vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_body_free(dlb);
+   vsp1_dl_body_put(dlb);
return 0;
 }
 
@@ -261,8 +263,16 @@ static void clu_configure(struct vsp1_entity *entity,
}
 }
 
+static void clu_destroy(struct vsp1_entity *entity)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   vsp1_dl_body_pool_destroy(clu->pool);
+}
+
 static const struct vsp1_entity_operations clu_entity_ops = {
.configure = clu_configure,
+   .destroy = clu_destroy,
 };
 
 /* 
-
@@ -288,6 +298,17 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device *vsp1)
if (ret < 0)
return ERR_PTR(ret);
 
+   /*
+* Pre-allocate a body pool, with 3 bodies allowing a userspace update
+* before the hardware has committed a previous set of tables, handling
+* both the queued and pending dl entries. One extra entry is added to
+* the CLU_SIZE to allow for the VI6_CLU_ADDR header.
+*/
+   clu->pool = vsp1_dl_body_pool_create(clu->entity.vsp1, 3, CLU_SIZE + 1,
+0);
+   if (!clu->pool)
+   return ERR_PTR(-ENOMEM);
+
/* Initialize the control handler. */
v4l2_ctrl_handler_init(>ctrls, 2);
v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);
diff --git a/drivers/media/platform/vsp1/vsp1_clu.h 
b/drivers/media/platform/vsp1/vsp1_clu.h
index 036e0a2f1a42..fa3fe856725b 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.h
+++ b/drivers/media/platform/vsp1/vsp1_clu.h
@@ -36,6 +36,7 @@ struct vsp1_clu {
spinlock_t lock;
unsigned int mode;
struct vsp1_dl_body *clu;
+   struct vsp1_dl_body_pool *pool;
 };
 
 static inline struct vsp1_clu *to_clu(struct v4l2_subdev *subdev)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 0047030483e1..a64a80f8085f 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -110,7 +110,7 @@ struct vsp1_dl_list {
struct vsp1_dl_header *header;
dma_addr_t dma;
 
-   struct vsp1_dl_body body0;
+   struct vsp1_dl_body *body0;
struct list_head bodies;
 
bool has_chain;
@@ -134,8 +134,6 @@ enum vsp1_dl_mode {
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
  * @pool: body pool for the display list bodies
- * 

[PATCH v4 5/9] v4l: vsp1: Use reference counting for bodies

[Kieran Bingham]

Extend the display list body with a reference count, allowing bodies to
be kept as long as a reference is maintained. This provides the ability
to keep a cached copy of bodies which will not change, so that they can
be re-applied to multiple display lists.

Signed-off-by: Kieran Bingham 

---
This could be squashed into the body update code, but it's not a
straightforward squash as the refcounts will affect both:
  v4l: vsp1: Provide a body pool
and
  v4l: vsp1: Convert display lists to use new body pool
therefore, I have kept this separate to prevent breaking bisectability
of the vsp-tests.

v3:
 - 's/fragment/body/'

v4:
 - Fix up reference handling comments.
---
 drivers/media/platform/vsp1/vsp1_clu.c |  7 ++-
 drivers/media/platform/vsp1/vsp1_dl.c  | 15 ++-
 drivers/media/platform/vsp1/vsp1_lut.c |  7 ++-
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 2018144470c5..b2a39a6ef7e4 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -257,8 +257,13 @@ static void clu_configure(struct vsp1_entity *entity,
clu->clu = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+   /* release our local reference */
+   vsp1_dl_body_put(dlb);
+   }
+
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index a64a80f8085f..fb54cbe4c682 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -58,6 +59,8 @@ struct vsp1_dl_body {
struct list_head list;
struct list_head free;
 
+   refcount_t refcnt;
+
struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
 
@@ -258,6 +261,7 @@ struct vsp1_dl_body *vsp1_dl_body_get(struct 
vsp1_dl_body_pool *pool)
if (!list_empty(>free)) {
dlb = list_first_entry(>free, struct vsp1_dl_body, free);
list_del(>free);
+   refcount_set(>refcnt, 1);
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -278,6 +282,9 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
if (!dlb)
return;
 
+   if (!refcount_dec_and_test(>refcnt))
+   return;
+
dlb->num_entries = 0;
 
spin_lock_irqsave(>pool->lock, flags);
@@ -464,7 +471,11 @@ void vsp1_dl_list_write(struct vsp1_dl_list *dl, u32 reg, 
u32 data)
  * in the order in which bodies are added.
  *
  * Adding a body to a display list passes ownership of the body to the list. 
The
- * caller must not touch the body after this call.
+ * caller retains its reference to the fragment when adding it to the display
+ * list, but is not allowed to add new entries to the body.
+ *
+ * The reference must be explicitly released by a call to vsp1_dl_body_put()
+ * when the body isn't needed anymore.
  *
  * Additional bodies are only usable for display lists in header mode.
  * Attempting to add a body to a header-less display list will return an error.
@@ -476,6 +487,8 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl,
if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
return -EINVAL;
 
+   refcount_inc(>refcnt);
+
list_add_tail(>list, >bodies);
return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index 262cb72139d6..77cf7137a0f2 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -213,8 +213,13 @@ static void lut_configure(struct vsp1_entity *entity,
lut->lut = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+   /* release our local reference */
+   vsp1_dl_body_put(dlb);
+   }
+
break;
}
 }
-- 
git-series 0.9.1

[PATCH v4 8/9] v4l: vsp1: Move video configuration to a cached dlb

[Kieran Bingham]

We are now able to configure a pipeline directly into a local display
list body. Take advantage of this fact, and create a cacheable body to
store the configuration of the pipeline in the video object.

vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
Convert this function to use the cached video->config body and obtain a
local display list reference.

Attach the video->config body to the display list when needed before
committing to hardware.

The pipe object is marked as un-configured when resuming from a suspend.
This ensures that when the hardware is reset - our cached configuration
will be re-attached to the next committed DL.

Signed-off-by: Kieran Bingham 
---

v3:
 - 's/fragment/body/', 's/fragments/bodies/'
 - video dlb cache allocation increased from 2 to 3 dlbs

Our video DL usage now looks like the below output:

dl->body0 contains our disposable runtime configuration. Max 41.
dl_child->body0 is our partition specific configuration. Max 12.
dl->bodies shows our constant configuration and LUTs.

  These two are LUT/CLU:
 * dl->bodies[x]->num_entries 256 / max 256
 * dl->bodies[x]->num_entries 4914 / max 4914

Which shows that our 'constant' configuration cache is currently
utilised to a maximum of 64 entries.

trace-cmd report | \
grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;

  dl->body0->num_entries 13 / max 128
  dl->body0->num_entries 14 / max 128
  dl->body0->num_entries 16 / max 128
  dl->body0->num_entries 20 / max 128
  dl->body0->num_entries 27 / max 128
  dl->body0->num_entries 34 / max 128
  dl->body0->num_entries 41 / max 128
  dl_child->body0->num_entries 10 / max 128
  dl_child->body0->num_entries 12 / max 128
  dl->bodies[x]->num_entries 15 / max 128
  dl->bodies[x]->num_entries 16 / max 128
  dl->bodies[x]->num_entries 17 / max 128
  dl->bodies[x]->num_entries 18 / max 128
  dl->bodies[x]->num_entries 20 / max 128
  dl->bodies[x]->num_entries 21 / max 128
  dl->bodies[x]->num_entries 256 / max 256
  dl->bodies[x]->num_entries 31 / max 128
  dl->bodies[x]->num_entries 32 / max 128
  dl->bodies[x]->num_entries 39 / max 128
  dl->bodies[x]->num_entries 40 / max 128
  dl->bodies[x]->num_entries 47 / max 128
  dl->bodies[x]->num_entries 48 / max 128
  dl->bodies[x]->num_entries 4914 / max 4914
  dl->bodies[x]->num_entries 55 / max 128
  dl->bodies[x]->num_entries 56 / max 128
  dl->bodies[x]->num_entries 63 / max 128
  dl->bodies[x]->num_entries 64 / max 128

v4:
 - Adjust pipe configured flag to be reset on resume rather than suspend
 - rename dl_child, dl_next
---
 drivers/media/platform/vsp1/vsp1_pipe.c  |  7 +++-
 drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
 drivers/media/platform/vsp1/vsp1_video.c | 67 -
 drivers/media/platform/vsp1/vsp1_video.h |  2 +-
 4 files changed, 54 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 5012643583b6..fa445b1a2e38 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
   VI6_CMD_STRCMD);
pipe->state = VSP1_PIPELINE_RUNNING;
+   pipe->configured = true;
}
 
pipe->buffers_ready = 0;
@@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device *vsp1)
continue;
 
spin_lock_irqsave(>irqlock, flags);
+   /*
+* The hardware may have been reset during a suspend and will
+* need a full reconfiguration
+*/
+   pipe->configured = false;
+
if (vsp1_pipeline_ready(pipe))
vsp1_pipeline_run(pipe);
spin_unlock_irqrestore(>irqlock, flags);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 90d29492b9b9..e7ad6211b4d0 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -90,6 +90,7 @@ struct vsp1_partition {
  * @irqlock: protects the pipeline state
  * @state: current state
  * @wq: wait queue to wait for state change completion
+ * @configured: flag determining if the hardware has run since reset
  * @frame_end: frame end interrupt handler
  * @lock: protects the pipeline use count and stream count
  * @kref: pipeline reference count
@@ -117,6 +118,7 @@ struct vsp1_pipeline {
spinlock_t irqlock;
enum vsp1_pipeline_state state;
wait_queue_head_t wq;
+   bool configured;
 
void (*frame_end)(struct vsp1_pipeline *pipe, bool completed);
 
@@ -143,8 +145,6 @@ struct vsp1_pipeline {
 */
struct list_head entities;
 
-   struct vsp1_dl_list *dl;
-
unsigned int partitions;
struct 

[PATCH v4 7/9] v4l: vsp1: Adapt entities to configure into a body

[Kieran Bingham]

Currently the entities store their configurations into a display list.
Adapt this such that the code can be configured into a body directly,
allowing greater flexibility and control of the content.

All users of vsp1_dl_list_write() are removed in this process, thus it
too is removed.

A helper, vsp1_dl_list_get_body0() is provided to access the internal body0
from the display list.

Signed-off-by: Kieran Bingham 

---

v4:
 - Rename vsp1_dl_list_get_body() to vsp1_dl_list_get_body0()
   The similarities between vsp1_dl_list_get_body and
   vsp1_dl_list_body_get() were too close

 - body0 could be removed later when the default body is no longer
   needed.
---
 drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
 drivers/media/platform/vsp1/vsp1_dl.h |  4 +-
 drivers/media/platform/vsp1/vsp1_drm.c| 14 +---
 drivers/media/platform/vsp1/vsp1_entity.c | 16 -
 drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
 drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
 drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
 drivers/media/platform/vsp1/vsp1_lif.c| 13 +++
 drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
 drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
 drivers/media/platform/vsp1/vsp1_sru.c| 14 
 drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
 drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
 drivers/media/platform/vsp1/vsp1_video.c  | 11 --
 drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
 20 files changed, 169 insertions(+), 154 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index b9ff96f76b3e..60d449d7b135 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -30,10 +30,10 @@
  * Device Access
  */
 
-static inline void vsp1_bru_write(struct vsp1_bru *bru, struct vsp1_dl_list 
*dl,
- u32 reg, u32 data)
+static inline void vsp1_bru_write(struct vsp1_bru *bru,
+ struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
-   vsp1_dl_list_write(dl, bru->base + reg, data);
+   vsp1_dl_body_write(dlb, bru->base + reg, data);
 }
 
 /* 
-
@@ -287,7 +287,7 @@ static const struct v4l2_subdev_ops bru_ops = {
 
 static void bru_prepare(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
-   struct vsp1_dl_list *dl)
+   struct vsp1_dl_body *dlb)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
@@ -309,7 +309,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 * format at the pipeline output is premultiplied.
 */
flags = pipe->output ? pipe->output->format.flags : 0;
-   vsp1_bru_write(bru, dl, VI6_BRU_INCTRL,
+   vsp1_bru_write(bru, dlb, VI6_BRU_INCTRL,
   flags & V4L2_PIX_FMT_FLAG_PREMUL_ALPHA ?
   0 : VI6_BRU_INCTRL_NRM);
 
@@ -317,12 +317,12 @@ static void bru_prepare(struct vsp1_entity *entity,
 * Set the background position to cover the whole output image and
 * configure its color.
 */
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_SIZE,
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_SIZE,
   (format->width << VI6_BRU_VIRRPF_SIZE_HSIZE_SHIFT) |
   (format->height << VI6_BRU_VIRRPF_SIZE_VSIZE_SHIFT));
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_LOC, 0);
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_LOC, 0);
 
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_COL, bru->bgcolor |
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_COL, bru->bgcolor |
   (0xff << VI6_BRU_VIRRPF_COL_A_SHIFT));
 
/*
@@ -332,7 +332,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 * unit.
 */
if (entity->type == VSP1_ENTITY_BRU)
-   vsp1_bru_write(bru, dl, VI6_BRU_ROP,
+   vsp1_bru_write(bru, dlb, VI6_BRU_ROP,
   VI6_BRU_ROP_DSTSEL_BRUIN(1) |
   VI6_BRU_ROP_CROP(VI6_ROP_NOP) |
   VI6_BRU_ROP_AROP(VI6_ROP_NOP));
@@ -374,7 +374,7 @@ static void bru_prepare(struct vsp1_entity *entity,
if (!(entity->type == VSP1_ENTITY_BRU && i == 1))
ctrl |= VI6_BRU_CTRL_SRCSEL_BRUIN(i);
 
-   vsp1_bru_write(bru, dl, VI6_BRU_CTRL(i), ctrl);
+   vsp1_bru_write(bru, dlb, VI6_BRU_CTRL(i), 

[PATCH v4 1/9] v4l: vsp1: Reword uses of 'fragment' as 'body'

[Kieran Bingham]

Throughout the codebase, the term 'fragment' is used to represent a
display list body. This term duplicates the 'body' which is already in
use.

The datasheet references these objects as a body, therefore replace all
mentions of a fragment with a body, along with the corresponding
pluralised terms.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_clu.c |  10 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 107 --
 drivers/media/platform/vsp1/vsp1_dl.h  |  14 +--
 drivers/media/platform/vsp1/vsp1_lut.c |   8 +-
 4 files changed, 69 insertions(+), 70 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index f2fb26e5ab4e..9621afa3658c 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -47,19 +47,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_fragment_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
if (!dlb)
return -ENOMEM;
 
-   vsp1_dl_fragment_write(dlb, VI6_CLU_ADDR, 0);
+   vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
for (i = 0; i < 17 * 17 * 17; ++i)
-   vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
+   vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_fragment_free(dlb);
+   vsp1_dl_body_free(dlb);
return 0;
 }
 
@@ -256,7 +256,7 @@ static void clu_configure(struct vsp1_entity *entity,
spin_unlock_irqrestore(>lock, flags);
 
if (dlb)
-   vsp1_dl_list_add_fragment(dl, dlb);
+   vsp1_dl_list_add_body(dl, dlb);
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8b5cbb6b7a70..643f7ea3af24 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -69,7 +69,7 @@ struct vsp1_dl_body {
  * @header: display list header, NULL for headerless lists
  * @dma: DMA address for the header
  * @body0: first display list body
- * @fragments: list of extra display list bodies
+ * @bodies: list of extra display list bodies
  * @chain: entry in the display list partition chain
  */
 struct vsp1_dl_list {
@@ -80,7 +80,7 @@ struct vsp1_dl_list {
dma_addr_t dma;
 
struct vsp1_dl_body body0;
-   struct list_head fragments;
+   struct list_head bodies;
 
bool has_chain;
struct list_head chain;
@@ -97,13 +97,13 @@ enum vsp1_dl_mode {
  * @mode: display list operation mode (header or headerless)
  * @singleshot: execute the display list in single-shot mode
  * @vsp1: the VSP1 device
- * @lock: protects the free, active, queued, pending and gc_fragments lists
+ * @lock: protects the free, active, queued, pending and gc_bodies lists
  * @free: array of all free display lists
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
- * @gc_work: fragments garbage collector work struct
- * @gc_fragments: array of display list fragments waiting to be freed
+ * @gc_work: bodies garbage collector work struct
+ * @gc_bodies: array of display list bodies waiting to be freed
  */
 struct vsp1_dl_manager {
unsigned int index;
@@ -118,7 +118,7 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
 
struct work_struct gc_work;
-   struct list_head gc_fragments;
+   struct list_head gc_bodies;
 };
 
 /* 
-
@@ -156,17 +156,16 @@ static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
 }
 
 /**
- * vsp1_dl_fragment_alloc - Allocate a display list fragment
+ * vsp1_dl_body_alloc - Allocate a display list body
  * @vsp1: The VSP1 device
- * @num_entries: The maximum number of entries that the fragment can contain
+ * @num_entries: The maximum number of entries that the body can contain
  *
- * Allocate a display list fragment with enough memory to contain the requested
+ * Allocate a display list body with enough memory to contain the requested
  * number of entries.
  *
- * Return a pointer to a fragment on success or NULL if memory can't be
- * allocated.
+ * Return a pointer to a body on success or NULL if memory can't be allocated.
  */
-struct vsp1_dl_body *vsp1_dl_fragment_alloc(struct vsp1_device *vsp1,
+struct vsp1_dl_body *vsp1_dl_body_alloc(struct vsp1_device *vsp1,
unsigned int num_entries)
 {
struct vsp1_dl_body *dlb;
@@ -186,20 +185,20 @@ 

[PATCH v4 2/9] v4l: vsp1: Protect bodies against overflow

[Kieran Bingham]

The body write function relies on the code never asking it to write more
than the entries available in the list.

Currently with each list body containing 256 entries, this is fine, but
we can reduce this number greatly saving memory. In preparation of this
add a level of protection to catch any buffer overflows.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 

---

v3:
 - adapt for new 'body' terminology
 - simplify WARN_ON macro usage
---
 drivers/media/platform/vsp1/vsp1_dl.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 643f7ea3af24..a45d35aa676e 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -50,6 +50,7 @@ struct vsp1_dl_entry {
  * @dma: DMA address of the entries
  * @size: size of the DMA memory in bytes
  * @num_entries: number of stored entries
+ * @max_entries: number of entries available
  */
 struct vsp1_dl_body {
struct list_head list;
@@ -60,6 +61,7 @@ struct vsp1_dl_body {
size_t size;
 
unsigned int num_entries;
+   unsigned int max_entries;
 };
 
 /**
@@ -138,6 +140,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
 
dlb->vsp1 = vsp1;
dlb->size = size;
+   dlb->max_entries = num_entries;
 
dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, >dma,
GFP_KERNEL);
@@ -219,6 +222,10 @@ void vsp1_dl_body_free(struct vsp1_dl_body *dlb)
  */
 void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
+   if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
+ "DLB size exceeded (max %u)", dlb->max_entries))
+   return;
+
dlb->entries[dlb->num_entries].addr = reg;
dlb->entries[dlb->num_entries].data = data;
dlb->num_entries++;
-- 
git-series 0.9.1

[PATCH v4 0/9] vsp1: TLB optimisation and DL caching

[Kieran Bingham]

Each display list currently allocates an area of DMA memory to store register
settings for the VSP1 to process. Each of these allocations adds pressure to
the IPMMU TLB entries.

We can reduce the pressure by pre-allocating larger areas and dividing the area
across multiple bodies represented as a pool.

With this reconfiguration of bodies, we can adapt the configuration code to
separate out constant hardware configuration and cache it for re-use.

--

The patches provided in this series can be found at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git  
tags/vsp1/tlb-optimise/v4

This series is currently based on the v4.14 release tag.

Outstanding points remaining:

 v4l: vsp1: Provide a fragment pool:
  - extra_size is over allocated, but a Todo: has been added

 v4l: vsp1: Refactor display list configure operations
  - Determination of naming for prepare()/configure()

 v4l: vsp1: Adapt entities to configure into a body
  - Whether or not to rework to contain 'cached' body in a DL.

Changelog:
--

v4:
 - Rebased to v4.14
 * v4l: vsp1: Use reference counting for bodies
   - Fix up reference handling comments

 * v4l: vsp1: Provide a body pool
   - Provide comment explaining extra allocation on body pool
 highlighting area for optimisation later.

 * v4l: vsp1: Refactor display list configure operations
   - Fix up comment to describe yuv_mode caching rather than format

 * vsp1: Adapt entities to configure into a body
   - Rename vsp1_dl_list_get_body() to vsp1_dl_list_get_body0()

 * v4l: vsp1: Move video configuration to a cached dlb
   - Adjust pipe configured flag to be reset on resume rather than suspend
   - rename dl_child, dl_next

Testing:

The VSP unit tests have been run on this patch set with the following results:

- vsp-unit-test-0001.sh
Testing WPF packing in RGB332: pass
Testing WPF packing in ARGB555: pass
Testing WPF packing in XRGB555: pass
Testing WPF packing in RGB565: pass
Testing WPF packing in BGR24: pass
Testing WPF packing in RGB24: pass
Testing WPF packing in ABGR32: pass
Testing WPF packing in ARGB32: pass
Testing WPF packing in XBGR32: pass
Testing WPF packing in XRGB32: pass
- vsp-unit-test-0002.sh
Testing WPF packing in NV12M: pass
Testing WPF packing in NV16M: pass
Testing WPF packing in NV21M: pass
Testing WPF packing in NV61M: pass
Testing WPF packing in UYVY: pass
Testing WPF packing in VYUY: skip
Testing WPF packing in YUV420M: pass
Testing WPF packing in YUV422M: pass
Testing WPF packing in YUV444M: pass
Testing WPF packing in YVU420M: pass
Testing WPF packing in YVU422M: pass
Testing WPF packing in YVU444M: pass
Testing WPF packing in YUYV: pass
Testing WPF packing in YVYU: pass
- vsp-unit-test-0003.sh
Testing scaling from 640x640 to 640x480 in RGB24: pass
Testing scaling from 1024x768 to 640x480 in RGB24: pass
Testing scaling from 640x480 to 1024x768 in RGB24: pass
Testing scaling from 640x640 to 640x480 in YUV444M: pass
Testing scaling from 1024x768 to 640x480 in YUV444M: pass
Testing scaling from 640x480 to 1024x768 in YUV444M: pass
- vsp-unit-test-0004.sh
Testing histogram in RGB24: pass
Testing histogram in YUV444M: pass
- vsp-unit-test-0005.sh
Testing RPF.0: pass
Testing RPF.1: pass
Testing RPF.2: pass
Testing RPF.3: pass
Testing RPF.4: pass
- vsp-unit-test-0006.sh
Testing invalid pipeline with no RPF: pass
Testing invalid pipeline with no WPF: pass
- vsp-unit-test-0007.sh
Testing BRU in RGB24 with 1 inputs: pass
Testing BRU in RGB24 with 2 inputs: pass
Testing BRU in RGB24 with 3 inputs: pass
Testing BRU in RGB24 with 4 inputs: pass
Testing BRU in RGB24 with 5 inputs: pass
Testing BRU in YUV444M with 1 inputs: pass
Testing BRU in YUV444M with 2 inputs: pass
Testing BRU in YUV444M with 3 inputs: pass
Testing BRU in YUV444M with 4 inputs: pass
Testing BRU in YUV444M with 5 inputs: pass
- vsp-unit-test-0008.sh
Test requires unavailable feature set `bru rpf.0 uds wpf.0': skipped
- vsp-unit-test-0009.sh
Test requires unavailable feature set `rpf.0 wpf.0 wpf.1': skipped
- vsp-unit-test-0010.sh
Testing CLU in RGB24 with zero configuration: pass
Testing CLU in RGB24 with identity configuration: pass
Testing CLU in RGB24 with wave configuration: pass
Testing CLU in YUV444M with zero configuration: pass
Testing CLU in YUV444M with identity configuration: pass
Testing CLU in YUV444M with wave configuration: pass
Testing LUT in RGB24 with zero configuration: pass
Testing LUT in RGB24 with identity configuration: pass
Testing LUT in RGB24 with gamma configuration: pass
Testing LUT in YUV444M with zero configuration: pass
Testing LUT in YUV444M with identity configuration: pass
Testing LUT in YUV444M with gamma configuration: pass
- vsp-unit-test-0011.sh
Testing  hflip=0 vflip=0 rotate=0: pass
Testing  hflip=1 vflip=0 rotate=0: pass
Testing  hflip=0 vflip=1 rotate=0: pass
Testing  hflip=1 vflip=1 rotate=0: pass
Testing  hflip=0 vflip=0 rotate=90: pass
Testing  hflip=1 vflip=0 rotate=90: pass
Testing  hflip=0 vflip=1 rotate=90: pass

Re: [PATCH 6/7] can: rcar_can: document r8a77995 (R-Car D3) compatibility strings

[Simon Horman]

On Fri, Nov 17, 2017 at 11:41:28AM +0100, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 
> ---
>  Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt 
> b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 06bb7cc..f7d0358 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -11,6 +11,7 @@ Required properties:
> "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
> "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
> "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
> +   "renesas,can-r8a77995" if CAN controller is a part of R8A77995 
> SoC.
> "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible 
> device.
> "renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible 
> device.
> "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible 
> device.
> @@ -25,12 +26,12 @@ Required properties:
>  - pinctrl-0: pin control group to be used for this controller.
>  - pinctrl-names: must be "default".
>  
> -Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
> -compatible:
> -In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
> -and can be used by both CAN and CAN FD controller at the same time. It needs 
> to
> -be scaled to maximum frequency if any of these controllers use it. This is 
> done
> -using the below properties:
> +Required properties for "renesas,can-r8a7795", "renesas,can-r8a7796" and
> +"renesas,can-r8a77995" compatible:

Not strictly related to this patch, but aren't these requirements also
applicable to "renesas,rcar-gen3-can"?

> +In R8A7795, R8A7796 and R8A77995 SoCs, "clkp2" can be CANFD clock. This is a
> +div6 clock and can be used by both CAN and CAN FD controller at the same
> +time. It needs to be scaled to maximum frequency if any of these
> +controllers use it. This is done using the below properties:
>  
>  - assigned-clocks: phandle of clkp2(CANFD) clock.
>  - assigned-clock-rates: maximum frequency of this clock.
> -- 
> 2.7.4
> 

Re: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

[Simon Horman]

On Thu, Nov 16, 2017 at 06:22:49PM +, Fabrizio Castro wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Reviewed-by: Simon Horman 

Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list

[Simon Horman]

On Thu, Nov 16, 2017 at 06:22:48PM +, Fabrizio Castro wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Reviewed-by: Simon Horman 

Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

[Kieran Bingham]

Hi Laurent,

Just a query on your bikeshedding here.

Choose your colours wisely :)

--
Kieran

On 12/09/17 20:19, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Tuesday, 12 September 2017 00:16:50 EEST Kieran Bingham wrote:
>> On 17/08/17 19:13, Laurent Pinchart wrote:
>>> On Monday 14 Aug 2017 16:13:28 Kieran Bingham wrote:
 The entities provide a single .configure operation which configures the
 object into the target display list, based on the vsp1_entity_params
 selection.

 This restricts us to a single function prototype for both static
 configuration (the pre-stream INIT stage) and the dynamic runtime stages
 for both each frame - and each partition therein.

 Split the configure function into two parts, '.prepare()' and
 '.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
 VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
 .configure(). The configuration for individual partitions is handled by
 passing the partition number to the configure call, and processing any
 runtime stage actions on the first partition only.

 Signed-off-by: Kieran Bingham 
 ---

  drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
  drivers/media/platform/vsp1/vsp1_clu.c|  43 +--
  drivers/media/platform/vsp1/vsp1_drm.c|  11 +-
  drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
  drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
  drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
  drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
  drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
  drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
  drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
  drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
  drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
  drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
  drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
  drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
  15 files changed, 359 insertions(+), 371 deletions(-)
>>>
>>> [snip]
>>>
 diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
 b/drivers/media/platform/vsp1/vsp1_clu.c index 175717018e11..5f65ce3ad97f
 100644
 --- a/drivers/media/platform/vsp1/vsp1_clu.c
 +++ b/drivers/media/platform/vsp1/vsp1_clu.c
 @@ -213,37 +213,37 @@ static const struct v4l2_subdev_ops clu_ops = {

  /*
  ---
  -
  
   * VSP1 Entity Operations
   */

 +static void clu_prepare(struct vsp1_entity *entity,
 +  struct vsp1_pipeline *pipe,
 +  struct vsp1_dl_list *dl)
 +{
 +  struct vsp1_clu *clu = to_clu(>subdev);
 +
 +  /*
 +   * The format can't be changed during streaming, only verify it
 +   * at setup time and store the information internally for future
 +   * runtime configuration calls.
 +   */
>>>
>>> I know you're just moving the comment around, but let's fix it at the same
>>> time. There's no verification here (and no "setup time" either). I'd write
>>> it as
>>>
>>> /*
>>> 
>>>  * The format can't be changed during streaming. Cache it internally
>>>  * for future runtime configuration calls.
>>>  */
>>
>> I think I'm ok with that and I've updated the patch - but I'm not sure we
>> are really caching the 'format' here, as much as the yuv_mode ...
> 
> Yes, it's the YUV mode we're caching, feel free to update the comment.

Done.

> 
>> I'll ponder ...
>>
 +  struct v4l2_mbus_framefmt *format;
 +
 +  format = vsp1_entity_get_pad_format(>entity,
 +  clu->entity.config,
 +  CLU_PAD_SINK);
 +  clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
 +}
>>>
>>> [snip]
>>>
 diff --git a/drivers/media/platform/vsp1/vsp1_entity.h
 b/drivers/media/platform/vsp1/vsp1_entity.h index
 408602ebeb97..2f33e343ccc6 100644
 --- a/drivers/media/platform/vsp1/vsp1_entity.h
 +++ b/drivers/media/platform/vsp1/vsp1_entity.h
>>>
>>> [snip]
>>>
 @@ -80,8 +68,10 @@ struct vsp1_route {

  /**
  
   * struct vsp1_entity_operations - Entity operations
   * @destroy:  Destroy the entity.

 - * @configure:Setup the hardware based on the entity state
 (pipeline, formats,
 - *selection rectangles, ...)
 + * @prepare:  Setup the initial hardware parameters for the stream
 (pipeline,
 + *formats)
 + * @configure:Configure the runtime parameters for each partition
 (rectangles,
 + *buffer addresses, ...)
>>>
>>> Now moving to the bikeshedding territory, I'm not sure if prepare and
>>> configure are the best names for those 

Re: [PATCH 3/4] arm64: dts: r8a77995: draak: enable SDHI2

[Simon Horman]

On Thu, Nov 16, 2017 at 10:43:35AM +0100, Geert Uytterhoeven wrote:
> Hi Uli,
> 
> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>  wrote:
> > The single SDHI controller is connected to eMMC.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Thanks for your patch!
> 
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > @@ -32,6 +32,24 @@
> > /* first 128MB is reserved for secure area. */
> > reg = <0x0 0x4800 0x0 0x1800>;
> > };
> > +
> > +   reg_1p8v: regulator0 {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "fixed-1.8V";
> > +   regulator-min-microvolt = <180>;
> > +   regulator-max-microvolt = <180>;
> > +   regulator-boot-on;
> > +   regulator-always-on;
> > +   };
> > +
> > +   reg_3p3v: regulator1 {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "fixed-3.3V";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   regulator-boot-on;
> > +   regulator-always-on;
> > +   };
> 
> As the eMMC is 1.8V only, I'll defer the review to the people looking
> into the need
> to specify the 3.3V pinctrl on other R-Car Gen3 boards.

I don't see any harm in describing the hardware present in DT.

Re: [PATCH 4/4] dt-bindings: mmc: renesas_sdhi: Add r8a77995 support

[Simon Horman]

On Thu, Nov 16, 2017 at 10:33:43AM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>  wrote:
> > Adds bindings for the R-Car D3 SoC's SDHI IP.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Reviewed-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

Re: [PATCH 2/4] arm64: dts: r8a77995: Add SDHI (MMC) support

[Simon Horman]

On Thu, Nov 16, 2017 at 10:40:41AM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>  wrote:
> > R-Car D3 has only one SDHI controller.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 5/6] arm64: renesas: draak: enable I2C controller 1

[Simon Horman]

On Thu, Nov 16, 2017 at 10:31:31AM +0100, Geert Uytterhoeven wrote:
> Hi Uli,
> 
> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>  wrote:
> > No devices to add, I2C1 has an external connector only.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Thanks for your patch!
> 
> Reviewed-by: Geert Uytterhoeven 
> but please see below.

Thanks, applied.

> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> 
> > @@ -84,6 +89,12 @@
> > };
> >  };
> >
> > + {
> > +   pinctrl-0 = <_pins>;
> > +   pinctrl-names = "default";
> > +   status = "okay";
> 
> If no devices are connected, perhaps it's wise to defer the status update
> to e.g. an overlay that describes what's connected to CN23?
> 
> Or do you want it enabled to allow adding devices manually using
> /sys/bus/i2c/devices/i2c-1/new_device?

Ulrich, please consider following up on this.

Re: [PATCH 4/6] arm64: renesas: draak: enable I2C controller 0 and EEPROM

[Simon Horman]

On Thu, Nov 16, 2017 at 10:27:56AM +0100, Geert Uytterhoeven wrote:
> Hi Ulrich,
> 
> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>  wrote:
> > Enables EEPROM on I2C0 on the Draak board.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Thanks for your patch!
> 
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> 
> > @@ -67,6 +72,18 @@
> > };
> >  };
> >
> > + {
> > +   pinctrl-0 = <_pins>;
> > +   pinctrl-names = "default";
> > +   status = "okay";
> > +
> > +   eeprom@50 {
> > +   compatible = "atmel,24c01";
> 
> This is actually a ROHM Semiconductor BR24T01FVM-W, so it should be
> 
> compatible = "rohm,br24t01", "atmel,24c01";

Applied with the above change.

> Please also submit a patch to add that compatible value to
> Documentation/devicetree/bindings/eeprom/eeprom.txt.

Ulrich, please follow-up on this, thanks!

> With the above fixed:
> Reviewed-by: Geert Uytterhoeven 
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

Re: [PATCH 3/6] arm64: renesas: r8a77995: add I2C support

[Simon Horman]

On Thu, Nov 16, 2017 at 10:10:27AM +0100, Geert Uytterhoeven wrote:
> Hi Ulrich,
> 
> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>  wrote:
> > Defines R-Car D3 I2C controllers 0-3.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Thanks for your patch!
> 
> > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > @@ -400,6 +400,70 @@
> > status = "disabled";
> > };
> >
> > +   i2c0: i2c@e650 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   compatible = "renesas,i2c-r8a77995",
> > +"renesas,rcar-gen3-i2c";
> > +   reg = <0 0xe650 0 0x40>;
> > +   interrupts = ;
> > +   clocks = < CPG_MOD 931>;
> > +   power-domains = < R8A77995_PD_ALWAYS_ON>;
> > +   resets = < 931>;
> > +   dmas = < 0x91>, < 0x90>;
> > +   dma-names = "tx", "rx";
> 
> Missing set for dmac2? (for all four interfaces)
> 
> > +   i2c-scl-internal-delay-ns = <110>;
> 
> According to Table 57.1, all i2c interfaces on R-Car D3 have LVTTL
> output buffers,
> so this should be <6> for all four interfaces.
> 
> With the above fixed:
> Reviewed-by: Geert Uytterhoeven 

Hi Ulrich,

I would like Geert's review addressed before I consider applying this patch.

Re: [PATCH 2/3] arm64: dts: r8a7795: add DMA for SCIF2

[Simon Horman]

On Wed, Nov 15, 2017 at 04:25:09PM +0100, Ulrich Hecht wrote:
> Tested on Draak.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
>  1 file changed, 2 insertions(+)

Hi Ulrich,

there seem to be some review comments for this patch.
I would like you to address them before I apply this patch.

Re: [PATCH 1/3] arm64: dts: r8a77995: add SYS-DMAC nodes

[Simon Horman]

On Thu, Nov 16, 2017 at 09:41:23AM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>  wrote:
> > Differs from other Gen3 SoCs in that each controller only supports eight
> > channels.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 3/3] dmaengine: rcar-dmac: Document R-Car D3 bindings

[Simon Horman]

On Thu, Nov 16, 2017 at 09:40:33AM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 15, 2017 at 4:25 PM, Ulrich Hecht
>  wrote:
> > R8A77995's SYS-DMAC is R-Car Gen3-compatible.
> >
> > Signed-off-by: Ulrich Hecht 
> 
> Reviewed-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

Re: [PATCH v1 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Simon Horman]

On Wed, Nov 15, 2017 at 11:55:57AM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.

Other patches in this series (which are not for my tree) appear
to warrant updating. Accordingly I am marking this patch as
"Changes Requested" and am expecting it to be reposted at some point.

Re: [PATCH 2/2] arm64: dts: renesas: eagle: specify EtherAVB PHY IRQ

[Simon Horman]

On Wed, Nov 15, 2017 at 05:15:58PM +0100, Geert Uytterhoeven wrote:
> On Mon, Nov 13, 2017 at 10:23 PM, Sergei Shtylyov
>  wrote:
> > Specify  EtherAVB PHY IRQ  in the Eagle board's device tree, now that we
> > have the GPIO support (previously phylib had to resort to polling).
> >
> > Signed-off-by: Sergei Shtylyov 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: add GPIO support

[Simon Horman]

On Wed, Nov 15, 2017 at 05:12:30PM +0100, Geert Uytterhoeven wrote:
> On Mon, Nov 13, 2017 at 10:23 PM, Sergei Shtylyov
>  wrote:
> > Describe all 6 GPIO controllers in the R8A77970 device tree.
> >
> > Signed-off-by: Sergei Shtylyov 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH] arm64: dts: ulcb-kf: add dr_mode property for USB2.0 channel 0

[Simon Horman]

On Wed, Nov 15, 2017 at 05:52:29PM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 8, 2017 at 2:09 PM, Vladimir Barinov
>  wrote:
> > ULCB-KF has a USB2.0 dual-role channel (CN13).
> > This adds dr_mode property for USB2.0 channel 0 (EHCI/OHCI and HS-USB)
> > as "otg".
> >
> > Signed-off-by: Vladimir Barinov 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH v2] arm64: dts: ulcb-kf: enable USB2 PHY of channel 0

[Simon Horman]

On Wed, Nov 15, 2017 at 05:36:21PM +0100, Geert Uytterhoeven wrote:
> Hi Vladimir,
> 
> On Wed, Nov 8, 2017 at 1:21 PM, Vladimir Barinov
>  wrote:
> > This supports USB2 PHY channel #0 on ULCB Kingfisher board
> >
> > The dedicated USB0_PWEN pin is used to control CN13 VBUS source from U43
> > power supply.
> > MAX3355 can also provide VBUS, hence it should be disabled via OTG_OFFVBUSn
> > node coming from gpio expander TCA9539.
> > Set MAX3355 enabled using OTG_EXTLPn node to be able to read OTG ID of CN13.

I took the liberty of line-wrapping the line above to keep it from going
over 75 characters wide to keep checkpatch happy.

> >
> > Signed-off-by: Vladimir Barinov 
> > ---
> > Changes in version 2:
> > - added gpio hogs for MAX3355 VBUS and SHDN
> 
> Thanks for the update!
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[Rob Herring]

On Wed, Nov 15, 2017 at 4:58 PM, Niklas Söderlund
 wrote:
> Hi Rob,
>
> Thanks for your feedback, much appreciated!
>
> On 2017-11-15 14:02:26 -0600, Rob Herring wrote:
>> On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
>> > Document the devicetree bindings for the CSI-2 inputs available on Gen3.
>> >
>> > There is a need to add a custom property 'renesas,id' and to define
>> > which CSI-2 input is described in which endpoint under the port@1 node.
>> > This information is needed since there are a set of predefined routes
>> > between each VIN and CSI-2 block. This routing table will be kept
>> > inside the driver but in order for it to act on it it must know which
>> > VIN and CSI-2 is which.
>> >
>> > Signed-off-by: Niklas Söderlund 
>> > ---
>> >  .../devicetree/bindings/media/rcar_vin.txt | 116 
>> > ++---
>> >  1 file changed, 104 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
>> > b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
>> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>> >  ---
>> >
>> >  The rcar_vin device provides video input capabilities for the Renesas 
>> > R-Car
>> > -family of devices. The current blocks are always slaves and suppot one 
>> > input
>> > -channel which can be either RGB, YUYV or BT656.
>> > +family of devices.
>> > +
>> > +Each VIN instance has a single parallel input that supports RGB and YUV 
>> > video,
>> > +with both external synchronization and BT.656 synchronization for the 
>> > latter.
>> > +Depending on the instance the VIN input is connected to external SoC 
>> > pins, or
>> > +on Gen3 to a CSI-2 receiver.
>> >
>> >   - compatible: Must be one or more of the following
>> > - "renesas,vin-r8a7795" for the R8A7795 device
>> > @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
>> >  Additionally, an alias named vinX will need to be created to specify
>> >  which video input device this is.
>> >
>> > -The per-board settings:
>> > +The per-board settings Gen2:
>> >   - port sub-node describing a single endpoint connected to the vin
>> > as described in video-interfaces.txt[1]. Only the first one will
>> > be considered as each vin interface has one input port.
>> >
>> > -   These settings are used to work out video input format and widths
>> > -   into the system.
>> > +The per-board settings Gen3:
>> > +
>> > +Gen3 can support both a single connected parallel input source from
>> > +external SoC pins (port0) and/or multiple parallel input sources from
>> > +local SoC CSI-2 receivers (port1) depending on SoC.
>> >
>> > +- renesas,id - ID number of the VIN, VINx in the documentation.
>>
>> Why is this needed? We try to avoid indexes unless that's the only way a
>> device is addressed (and then we use reg).
>
> This is unfortunately needed (or something similar) as there is a
> register in one VIN instance which controls the routing of the incoming
> CSI-2 video streams, not only to itself, but also to other VIN instances
> inside the same SoC.
>
> To be more specific I will try to clarify this using the R-Car H3 as an
> example. On the H3 there are 8 instances of the capture hardware (VIN0 -
> VIN7) and 3 instances off CSI-2 receivers (CSI20, CSI40 and CSI41) which
> receives CSI-2 streams, split the possible multiple virtual channels
> (VC) encoded in CSI-2 streams and forwards it to the VIN's.
>
> The problem is that VIN0 and VIN4 are different from the other VIN's,
> they have one register (CHSEL) which controls the limited number of
> possible routes of video streams between a CSI-2 + VC to a specific VIN.
> The CHSEL register in VIN0 controls the routing for VIN0-3 and the one
> in VIN4 controls VIN4-7 (the two subgroups are similar so lets only
> consider VIN0-3).
>
> There are only a handful of routes possible and the kicker is that
> changing the CHSEL value in VIN0, directly reflects all routes for
> VIN0-VIN3 per this table:
>
> CHSEL reg in VIN0:  0 1 2 3 4
> Video sent to VIN0: CSI40/VC0 CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI20/VC0
> Video sent to VIN1: CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI40/VC1 CSI20/VC1
> Video sent to VIN2: CSI20/VC1 CSI40/VC0 CSI20/VC0 CSI40/VC2 CSI20/VC2
> Video sent to VIN3: CSI40/VC1 CSI20/VC1 CSI20/VC1 CSI40/VC3 CSI20/VC3
>
> So if CHSEL in VIN0 is set to 2 the following routes are active: VIN0:
> CSI40/VC1, VIN1: CSI40/VC0, VIN2: CSI20/VC0, CSI20/VC1. These routing
> tables are different for most SoCs in the R-Car Gen3 family, and are
> kept inside the driver code.
>
> So the renesas,id properly is used so that the rcar-vin driver knows
> which of the driver 

Re: [PATCH v2 6/8] v4l: vsp1: Adapt entities to configure into a body

[Kieran Bingham]

Hi Laurent,

On 12/09/17 20:18, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Tuesday, 12 September 2017 00:42:09 EEST Kieran Bingham wrote:
>> On 17/08/17 18:58, Laurent Pinchart wrote:
>>> On Monday 14 Aug 2017 16:13:29 Kieran Bingham wrote:
 Currently the entities store their configurations into a display list.
 Adapt this such that the code can be configured into a body fragment
 directly, allowing greater flexibility and control of the content.

 All users of vsp1_dl_list_write() are removed in this process, thus it
 too is removed.

 A helper, vsp1_dl_list_body() is provided to access the internal body0
 from the display list.

 Signed-off-by: Kieran Bingham 
 ---

  drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
  drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
  drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
  drivers/media/platform/vsp1/vsp1_dl.h |  2 +-
  drivers/media/platform/vsp1/vsp1_drm.c| 14 +---
  drivers/media/platform/vsp1/vsp1_entity.c | 16 -
  drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
  drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
  drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
  drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
  drivers/media/platform/vsp1/vsp1_lif.c| 13 +++
  drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
  drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
  drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
  drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
  drivers/media/platform/vsp1/vsp1_sru.c| 14 
  drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
  drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
  drivers/media/platform/vsp1/vsp1_video.c  | 11 --
  drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
  20 files changed, 168 insertions(+), 153 deletions(-)
>>>
>>> This is quite intrusive, and it bothers me slightly that we need to pass
>>> both the DL and the DLB to the configure function in order to add
>>> fragments to the DL in the CLU and LUT modules. Wouldn't it be simpler to
>>> add a pointer to the current body in the DL structure, and modify
>>> vsp1_dl_list_write() to write to the current fragment ?
>>
>> No doubt about it, 168+, 153- is certainly intrusive.
>>
>> Yes, now I'm looking back at this, I think this does look like this part is
>> not quite the right approach.
>>
>> Which otherwise stalls the series until I have time to reconsider. I will
>> likely repost the work I have done on the earlier patches, including the
>> 's/fragment/body/g' changes and ready myself for a v4 which will contain the
>> heavier reworks.
> 
> Fine with me. Could you make sure to mention the open issues in the cover 
> letter ? I want to avoid commenting on them if you know already that you will 
> rework them later.

I've been trying to tackle this today, but I think I've come up a bit stuck on a
key part.

The reason for this patch, is to allow the functions to configure directly into
a display list body, even when that body *is not part* of a display list.

So - converting vsp1_dl_list_write() to configure into the 'current' body (was
fragment) of a display list would not work for writing to the cached objects -
which do not have a display list. They are simply body objects.

It seems a bit extraneous to create holding display lists to contain a single
body, when the display list itself will never be used, but I can't think of an
alternative.

Would you prefer this 'container display list' approach? or do you have another
idea?

--
Regards

Kieran

Re: [PATCH v2 0/7] arm64: dts: renesas: r8a7796: IPMMU upstream integration

[Simon Horman]

On Fri, Nov 10, 2017 at 02:26:05PM +0100, Simon Horman wrote:
> This series adds DT nodes for IPMMU instances on r8a7796 together with
> connections to various r8a7796 on-chip devices such as Audio-DMAC, SYS-DMAC,
> Ethernet-AVB and a bunch of multimedia devices that make use of FCP.
> 
> With these patches applied a white list enabled IPMMU driver may be used
> to check silicon revision and then enable IPMMU in the known working cases.
> 
> The recommended test stack for this patchset is a merge of
> * The iommu/next branch of the vfio tree
> * renesas-devel-20171110-v4.14-rc8 tag of the renesas tree
> 
> With the following applied:
>  [PATCH v4 0/3] iommu/ipmmu-vmsa: r8a7796 support V4
> 
> The final patch in the series enable IPMMU support for all IPMMU
> instances on r8a7796 that are used by IPMMU devices listed above.
> 
> The DT binding for r8a7796 have been acked (as part of the r8a7796 series
> noted above) but have not yet been merged.
> 
> Changes since V1:
> * Drop mostly redundant comments from nodes
> * Add power domains
> 
> Based on work by Magnus Damm.
> 
> Based on renesas-devel-20171110-v4.14-rc8

I have applied this series.

Re: [PATCH v5 00/15] arm64: dts: renesas: r8a7795: IPMMU upstream integration

[Simon Horman]

On Fri, Nov 10, 2017 at 02:25:17PM +0100, Simon Horman wrote:
> This series adds DT nodes for IPMMU instances on r8a7795 together with
> connections to various r8a7795 on-chip devices such as Audio-DMAC, SYS-DMAC,
> Ethernet-AVB, SATA and a bunch of multimedia devices that make use of FCP.
> 
> With these patches applied a white list enabled IPMMU driver may be used
> to check silicon revision and then enable IPMMU in the known working cases.
> 
> The recommended test stack for this patchset is a merge of
> * The iommu/next branch of the vfio tree
> * renesas-devel-20171110-v4.14-rc8 tag of the renesas tree
> 
> The final two patches in the series enable IPMMU support for all IPMMU
> instances on r8a7795 that are used by IPMMU devices listed above with one
> exception.  The exception is the SATA device connected to IPMMU-HC which
> still is disabled pending IPMMU USB integration support. I expect IPMMU USB
> integration to be handled as a second step once this series is agreed on.
> 
> The DT binding for r8a7795 has since long been included in mainline and
> this series implements support following such format:
> 
> d4e42e7 iommu/ipmmu-vmsa: Add r8a7795 DT binding

I have applied this series.

Re: [PATCH v5 01/15] arm64: dts: renesas: r8a7795: Add IPMMU device nodes

[Simon Horman]

On Wed, Nov 15, 2017 at 03:29:55PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Fri, Nov 10, 2017 at 2:25 PM, Simon Horman
>  wrote:
> > From: Magnus Damm 
> >
> > Add r8a7795 IPMMU nodes and keep all disabled by default.
> >
> > This includes all IPMMU devices for r8a7795 ES2.0. Those
> > not present in r8a7795 ES1.x are removed from the DT for those
> > SoCs using delete-node. A follow-up patch will add IPMMU devices
> > to ES1.x which are not also present in ES2.0.
> >
> > Signed-off-by: Magnus Damm 
> > Reviewed-by: Laurent Pinchart 
> > Signed-off-by: Simon Horman 
> > ---
> > v5 [Simon Horman]
> > * Correct ES1.x override for ipmmu_vc0
> > * Add ES1.x override for ipmmu_vc1
> > * Drop mostly redundant comments from nodes
> > * Add power domains
> > * Consistently mark all nodes as disabled
> 
> Thanks for the update!
> 
> Looks like "power-domains" do work for IOMMU nodes.
> However, adding them seems to postpone initialization of the IOMMUs.
> 
> With the two typos below fixed:
> Reviewed-by: Geert Uytterhoeven 

Thanks, I have applied this patch with those fixes and your tag.

> 
> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> 
> > +   ipmmu_vc0: mmu@fe6b {
> > +   compatible = "renesas,ipmmu-r8a7795";
> > +   reg = <0 0xfe6b 0 0x1000>;
> > +   renesas,ipmmu-main = <_mm 12>;
> > +   power-domains = < R8A7795_PD_A3VP>;
> 
> R8A7795_PD_A3VC
> 
> > +   #iommu-cells = <1>;
> > +   status = "disabled";
> > +   };
> > +
> > +   ipmmu_vc1: mmu@fe6f {
> > +   compatible = "renesas,ipmmu-r8a7795";
> > +   reg = <0 0xfe6f 0 0x1000>;
> > +   renesas,ipmmu-main = <_mm 13>;
> > +   power-domains = < R8A7795_PD_A3VP>;
> 
> R8A7795_PD_A3VC
> 
> > +   #iommu-cells = <1>;
> > +   status = "disabled";
> > +   };
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

Re: [PATCH v2 1/7] arm64: dts: renesas: r8a7796: Add IPMMU device nodes

[Simon Horman]

On Wed, Nov 15, 2017 at 03:41:14PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Fri, Nov 10, 2017 at 2:26 PM, Simon Horman
>  wrote:
> > From: Magnus Damm 
> >
> > Add r8a7796 IPMMU nodes and keep all disabled by default.
> >
> > Signed-off-by: Magnus Damm 
> > Signed-off-by: Simon Horman 
> > ---
> > v2 [Simon Horman]
> > * Drop mostly redundant comments from nodes
> > * Add power domains
> 
> Thanks for the update!
> 
> With the below fixed:
> Reviewed-by: Geert Uytterhoeven 

Thanks, I have applied this patch with those fixes and your tag.

> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> 
> [...]
> 
> > +   ipmmu_vc0: mmu@fe6b {
> > +   compatible = "renesas,ipmmu-r8a7796";
> > +   reg = <0 0xfe6b 0 0x1000>;
> > +   renesas,ipmmu-main = <_mm 8>;
> > +   power-domains = < R8A7796_PD_ALWAYS_ON>;
> 
> R8A7796_PD_A3VC
> 
> > +   #iommu-cells = <1>;
> > +   status = "disabled";
> > +   };
> 
> [...]
> 
> > +   ipmmu_ds0: mmu@e674 {
> > +   compatible = "renesas,ipmmu-r8a7796";
> > +   reg = <0 0xe674 0 0x1000>;
> > +   renesas,ipmmu-main = <_mm 0>;
> 
> power-domains = < R8A7796_PD_ALWAYS_ON>;
> 
> > +   #iommu-cells = <1>;
> > +   status = "disabled";
> > +   };
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

Re: [PATCH 2/7] pinctrl: sh-pfc: r8a77995: Add CAN FD support

[Geert Uytterhoeven]

On Fri, Nov 17, 2017 at 11:41 AM, Ulrich Hecht
 wrote:
> This patch adds CAN FD[0-1] pinmux support to the r8a77995 SoC.
>
> Signed-off-by: Ulrich Hecht 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.16.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 1/7] pinctrl: sh-pfc: r8a77995: Add CAN support

[Geert Uytterhoeven]

On Fri, Nov 17, 2017 at 11:41 AM, Ulrich Hecht
 wrote:
> This patch adds CAN[0-1] pinmux support to the r8a77995 SoC.
>
> Signed-off-by: Ulrich Hecht 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.16.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v11 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Hans Verkuil]

On 11/11/17 01:25, Niklas Söderlund wrote:
> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> hardware blocks are connected between the video sources and the video
> grabbers (VIN).
> 
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> 
> Signed-off-by: Niklas Söderlund 

I found one small typo (see below). After fixing that you can add my:

Reviewed-by: Hans Verkuil 

I would like to see another Ack before merging this (Sakari?).

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/Kconfig |  12 +
>  drivers/media/platform/rcar-vin/Makefile|   1 +
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 896 
> 
>  3 files changed, 909 insertions(+)
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> 
> diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> b/drivers/media/platform/rcar-vin/Kconfig
> index af4c98b44d2e22cb..6875f30c1ae42631 100644
> --- a/drivers/media/platform/rcar-vin/Kconfig
> +++ b/drivers/media/platform/rcar-vin/Kconfig
> @@ -1,3 +1,15 @@
> +config VIDEO_RCAR_CSI2
> + tristate "R-Car MIPI CSI-2 Receiver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> + depends on ARCH_RENESAS || COMPILE_TEST
> + select V4L2_FWNODE
> + ---help---
> +   Support for Renesas R-Car MIPI CSI-2 receiver.
> +   Supports R-Car Gen3 SoCs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called rcar-csi2.
> +
>  config VIDEO_RCAR_VIN
>   tristate "R-Car Video Input (VIN) Driver"
>   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> MEDIA_CONTROLLER
> diff --git a/drivers/media/platform/rcar-vin/Makefile 
> b/drivers/media/platform/rcar-vin/Makefile
> index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> --- a/drivers/media/platform/rcar-vin/Makefile
> +++ b/drivers/media/platform/rcar-vin/Makefile
> @@ -1,3 +1,4 @@
>  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
>  
> +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
>  obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> new file mode 100644
> index ..4202c60b4d0aa7f7
> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -0,0 +1,896 @@
> +/*
> + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> + *
> + * Copyright (C) 2017 Renesas Electronics Corp.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets and bits */
> +
> +/* Control Timing Select */
> +#define TREF_REG 0x00
> +#define TREF_TREFBIT(0)
> +
> +/* Software Reset */
> +#define SRST_REG 0x04
> +#define SRST_SRSTBIT(0)
> +
> +/* PHY Operation Control */
> +#define PHYCNT_REG   0x08
> +#define PHYCNT_SHUTDOWNZ BIT(17)
> +#define PHYCNT_RSTZ  BIT(16)
> +#define PHYCNT_ENABLECLK BIT(4)
> +#define PHYCNT_ENABLE_3  BIT(3)
> +#define PHYCNT_ENABLE_2  BIT(2)
> +#define PHYCNT_ENABLE_1  BIT(1)
> +#define PHYCNT_ENABLE_0  BIT(0)
> +
> +/* Checksum Control */
> +#define CHKSUM_REG   0x0c
> +#define CHKSUM_ECC_ENBIT(1)
> +#define CHKSUM_CRC_ENBIT(0)
> +
> +/*
> + * Channel Data Type Select
> + * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
> + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
> + */
> +#define VCDT_REG 0x10
> +#define VCDT2_REG0x14
> +#define VCDT_VCDTN_ENBIT(15)
> +#define VCDT_SEL_VC(n)   (((n) & 0x3) << 8)
> +#define VCDT_SEL_DTN_ON  BIT(6)
> +#define VCDT_SEL_DT(n)   (((n) & 0x3f) << 0)
> +
> +/* Frame Data Type Select */
> +#define FRDT_REG 0x18
> +
> +/* Field Detection Control */
> +#define FLD_REG  0x1c
> +#define FLD_FLD_NUM(n)   (((n) & 0xff) << 16)
> +#define FLD_FLD_EN4  BIT(3)
> +#define FLD_FLD_EN3  BIT(2)
> +#define FLD_FLD_EN2  BIT(1)
> +#define FLD_FLD_EN   BIT(0)
> +
> +/* Automatic Standby Control */
> +#define ASTBY_REG

Re: [PATCH v7 02/25] rcar-vin: register the video device at probe time

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> The driver registers the video device from the async complete callback
> and unregistered in the async unbind callback. This creates problems if
> if the subdevice is bound, unbound and later rebound. The second time

"unbound and later rebound": that's a manual operation via /sys bind/unbind?

I remain unhappy about this patch. It's a workaround for a more basic problem
IMHO.

Can you move this patch to the end of the series? That way I can decide later
whether to merge it or not without blocking the rest of the series.

Other than this patch the only blocking patch is the bindings patch which hasn't
got an Ack yet.

Regards,

Hans

> video_register_device() is called it fails:
> 
>kobject (eb3be918): tried to init an initialized object, something is 
> seriously wrong.
> 
> To prevent this register the video device at probe time and don't allow
> user-space to open the video device if the subdevice is not bound yet.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 124 
> +++-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  47 ++-
>  drivers/media/platform/rcar-vin/rcar-vin.h  |   5 +-
>  3 files changed, 95 insertions(+), 81 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 108d776f32651b27..856df3e407c05d97 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -46,54 +46,18 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
> direction)
>   return -EINVAL;
>  }
>  
> -static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
> -{
> - struct v4l2_subdev *sd = entity->subdev;
> - struct v4l2_subdev_mbus_code_enum code = {
> - .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> - };
> -
> - code.index = 0;
> - code.pad = entity->source_pad;
> - while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
> - code.index++;
> - switch (code.code) {
> - case MEDIA_BUS_FMT_YUYV8_1X16:
> - case MEDIA_BUS_FMT_UYVY8_2X8:
> - case MEDIA_BUS_FMT_UYVY10_2X10:
> - case MEDIA_BUS_FMT_RGB888_1X24:
> - entity->code = code.code;
> - return true;
> - default:
> - break;
> - }
> - }
> -
> - return false;
> -}
> -
>  static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
>  {
>   struct rvin_dev *vin = notifier_to_vin(notifier);
>   int ret;
>  
> - /* Verify subdevices mbus format */
> - if (!rvin_mbus_supported(vin->digital)) {
> - vin_err(vin, "Unsupported media bus format for %s\n",
> - vin->digital->subdev->name);
> - return -EINVAL;
> - }
> -
> - vin_dbg(vin, "Found media bus format for %s: %d\n",
> - vin->digital->subdev->name, vin->digital->code);
> -
>   ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
>   if (ret < 0) {
>   vin_err(vin, "Failed to register subdev nodes\n");
>   return ret;
>   }
>  
> - return rvin_v4l2_probe(vin);
> + return 0;
>  }
>  
>  static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
> @@ -103,8 +67,15 @@ static void rvin_digital_notify_unbind(struct 
> v4l2_async_notifier *notifier,
>   struct rvin_dev *vin = notifier_to_vin(notifier);
>  
>   vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
> - rvin_v4l2_remove(vin);
> +
> + mutex_lock(>lock);
> +
> + vin->vdev.ctrl_handler = NULL;
> + v4l2_ctrl_handler_free(>ctrl_handler);
> +
>   vin->digital->subdev = NULL;
> +
> + mutex_unlock(>lock);
>  }
>  
>  static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
> @@ -112,12 +83,14 @@ static int rvin_digital_notify_bound(struct 
> v4l2_async_notifier *notifier,
>struct v4l2_async_subdev *asd)
>  {
>   struct rvin_dev *vin = notifier_to_vin(notifier);
> + struct v4l2_subdev_mbus_code_enum code = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
>   int ret;
>  
>   v4l2_set_subdev_hostdata(subdev, vin);
>  
>   /* Find source and sink pad of remote subdevice */
> -
>   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
>   if (ret < 0)
>   return ret;
> @@ -126,21 +99,82 @@ static int rvin_digital_notify_bound(struct 
> v4l2_async_notifier *notifier,
>   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
>   vin->digital->sink_pad = ret < 0 ? 0 : ret;
>  
> + /* Find compatible subdevices mbus format */
> + vin->digital->code = 0;
> + code.index = 0;
> + code.pad = vin->digital->source_pad;
> + while (!vin->digital->code &&
> +

Re: [PATCH v7 23/25] rcar-vin: extend {start,stop}_streaming to work with media controller

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> The procedure to start or stop streaming using the non-MC single
> subdevice and the MC graph and multiple subdevices are quite different.
> Create a new function to abstract which method is used based on which
> mode the driver is running in and add logic to start the MC graph.
> 
> Signed-off-by: Niklas Söderlund 

One tiny typo in a comment, see below. After fixing that you can add my:

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 113 
> +++--
>  1 file changed, 106 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index fe1319eb4c5df02d..b16b892a4de876bb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1087,15 +1087,116 @@ static void rvin_buffer_queue(struct vb2_buffer *vb)
>   spin_unlock_irqrestore(>qlock, flags);
>  }
>  
> +static int rvin_set_stream(struct rvin_dev *vin, int on)
> +{
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + struct media_pipeline *pipe;
> + struct  v4l2_subdev *sd;
> + struct media_pad *pad;
> + int ret;
> +
> + /* No media controller used, simply pass operation to subdevice */
> + if (!vin->info->use_mc) {
> + ret = v4l2_subdev_call(vin->digital->subdev, video, s_stream,
> +on);
> +
> + return ret == -ENOIOCTLCMD ? 0 : ret;
> + }
> +
> + pad = media_entity_remote_pad(>pad);
> + if (!pad)
> + return -EPIPE;
> +
> + sd = media_entity_to_v4l2_subdev(pad->entity);
> + if (!sd)
> + return -EPIPE;
> +
> + if (!on) {
> + media_pipeline_stop(>vdev.entity);
> + ret = v4l2_subdev_call(sd, video, s_stream, 0);
> + return 0;
> + }
> +
> + fmt.pad = pad->index;
> + if (v4l2_subdev_call(sd, pad, get_fmt, NULL, ))
> + return -EPIPE;
> +
> + switch (fmt.format.code) {
> + case MEDIA_BUS_FMT_YUYV8_1X16:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_UYVY10_2X10:
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + vin->code = fmt.format.code;
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + switch (fmt.format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Supported nativly */

nativly -> natively

> + break;
> + case V4L2_FIELD_ALTERNATE:
> + switch (vin->format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + break;
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Use VIN hardware to combine the two fields */
> + fmt.format.height *= 2;
> + break;
> + default:
> + return -EPIPE;
> + }
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + if (fmt.format.width != vin->format.width ||
> + fmt.format.height != vin->format.height)
> + return -EPIPE;
> +
> + pipe = sd->entity.pipe ? sd->entity.pipe : >vdev.pipe;
> + if (media_pipeline_start(>vdev.entity, pipe))
> + return -EPIPE;
> +
> + ret = v4l2_subdev_call(sd, video, s_stream, 1);
> + if (ret == -ENOIOCTLCMD)
> + ret = 0;
> + if (ret)
> + media_pipeline_stop(>vdev.entity);
> +
> + return ret;
> +}
> +
>  static int rvin_start_streaming(struct vb2_queue *vq, unsigned int count)
>  {
>   struct rvin_dev *vin = vb2_get_drv_priv(vq);
> - struct v4l2_subdev *sd;
>   unsigned long flags;
>   int ret;
>  
> - sd = vin_to_source(vin);
> - v4l2_subdev_call(sd, video, s_stream, 1);
> + ret = rvin_set_stream(vin, 1);
> + if (ret) {
> + spin_lock_irqsave(>qlock, flags);
> + return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
> + spin_unlock_irqrestore(>qlock, flags);
> + return ret;
> + }
>  
>   spin_lock_irqsave(>qlock, flags);
>  
> @@ -1104,7 +1205,7 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
> unsigned int count)
>   ret = rvin_capture_start(vin);
>   if (ret) {
>   return_all_buffers(vin, 

Re: [PATCH v7 14/25] rcar-vin: add function to manipulate Gen3 CHSEL value

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> feature of this register is that it's only present in the VIN0 and VIN4
> instances. The register in VIN0 controls the routing for VIN0-3 and the
> register in VIN4 controls routing for VIN4-7.
> 
> To be able to control routing from a media device this function is need
> to control runtime PM for the subgroup master (VIN0 and VIN4). The
> subgroup master must be switched on before the register is manipulated,
> once the operation is complete it's safe to switch the master off and
> the new routing will still be in effect.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 25 +
>  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index c4f8e81e88c99e28..463c656b9878be52 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -16,6 +16,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -1228,3 +1229,27 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
>  
>   return ret;
>  }
> +
> +/* 
> -
> + * Gen3 CHSEL manipulation
> + */
> +
> +void rvin_set_chsel(struct rvin_dev *vin, u8 chsel)
> +{
> + u32 ifmd, vnmc;
> +
> + pm_runtime_get_sync(vin->dev);
> +
> + /* Make register writes take effect immediately */
> + vnmc = rvin_read(vin, VNMC_REG) & ~VNMC_VUP;
> + rvin_write(vin, vnmc, VNMC_REG);
> +
> + ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> + VNCSI_IFMD_CSI_CHSEL(chsel);
> +
> + rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> +
> + vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> +
> + pm_runtime_put(vin->dev);
> +}
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 1f761518a6cc60b8..8a7c51724a90786c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -164,4 +164,6 @@ int rvin_reset_format(struct rvin_dev *vin);
>  
>  const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
>  
> +void rvin_set_chsel(struct rvin_dev *vin, u8 chsel);
> +
>  #endif
> 

Re: [PATCH v7 20/25] rcar-vin: add chsel information to rvin_info

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> Each Gen3 SoC has a limited set of predefined routing possibilities for
> which CSI-2 device and virtual channel can be routed to which VIN
> instance. Prepare to store this information in the struct rvin_info.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/rcar-vin.h | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index a9bd570d6635fd47..41c81b8d9fb8e851 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -35,6 +35,9 @@
>  /* Max number on VIN instances that can be in a system */
>  #define RCAR_VIN_NUM 8
>  
> +/* Max number of CHSEL values for any Gen3 SoC */
> +#define RCAR_CHSEL_MAX 6
> +
>  enum chip_id {
>   RCAR_H1,
>   RCAR_M1,
> @@ -91,6 +94,22 @@ struct rvin_graph_entity {
>  
>  struct rvin_group;
>  
> +/** struct rvin_group_chsel - Map a CSI-2 receiver and channel to a CHSEL 
> value
> + * @csi: VIN internal number for CSI-2 device
> + * @chan:Output channel of the CSI-2 receiver. Each R-Car CSI-2
> + *   receiver has four output channels facing the VIN
> + *   devices, each channel can carry one CSI-2 Virtual
> + *   Channel (VC) and there are no correlation between
> + *   output channel number and CSI-2 VC. It's up to the
> + *   CSI-2 receiver driver to configure which VC is
> + *   outputted on which channel, the VIN devices only
> + *   cares about output channels.
> + */
> +struct rvin_group_chsel {
> + enum rvin_csi_id csi;
> + unsigned int chan;
> +};
> +
>  /**
>   * struct rvin_info - Information about the particular VIN implementation
>   * @chip:type of VIN chip
> @@ -98,6 +117,9 @@ struct rvin_group;
>   *
>   * max_width:max input width the VIN supports
>   * max_height:   max input height the VIN supports
> + *
> + * num_chsels:   number of possible chsel values for this VIN
> + * chsels:   routing table VIN <-> CSI-2 for the chsel values
>   */
>  struct rvin_info {
>   enum chip_id chip;
> @@ -105,6 +127,9 @@ struct rvin_info {
>  
>   unsigned int max_width;
>   unsigned int max_height;
> +
> + unsigned int num_chsels;
> + struct rvin_group_chsel chsels[RCAR_VIN_NUM][RCAR_CHSEL_MAX];
>  };
>  
>  /**
> 

Re: [PATCH v7 22/25] rcar-vin: add link notify for Gen3

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> Add the ability to process media device link change request. Link
> enabling is a bit complicated on Gen3, whether or not it's possible to
> enable a link depends on what other links already are enabled. On Gen3
> the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
> routing perspective these two groups are independent of each other.
> Each subgroup's routing is controlled by the subgroup VIN master
> instance (VIN0 and VIN4).
> 
> There are a limited number of possible route setups available for each
> subgroup and the configuration of each setup is dictated by the
> hardware. On H3 for example there are 6 possible route setups for each
> subgroup to choose from.
> 
> This leads to the media device link notification code being rather large
> since it will find the best routing configuration to try and accommodate
> as many links as possible. When it's not possible to enable a new link
> due to hardware constrains the link_notifier callback will return
> -EMLINK.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 205 
> 
>  1 file changed, 205 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 78a9766eb7114959..79b0334d8c563328 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -27,6 +27,209 @@
>  
>  #include "rcar-vin.h"
>  
> +/* 
> -
> + * Media Controller link notification
> + */
> +
> +static unsigned int rvin_group_csi_pad_to_chan(unsigned int pad)
> +{
> + /*
> +  * The companion CSI-2 receiver driver (rcar-csi2) is known
> +  * and we know it have one source pad (pad 0) and four sink
> +  * pads (pad 1-4). So to translate a pad on the remote
> +  * CSI-2 receiver to the VIN internal channel number simply
> +  * subtract one from the pad number.
> +  */
> + return pad - 1;
> +}
> +
> +/* group lock should be held when calling this function */
> +static int rvin_group_entity_to_vin_num(struct rvin_group *group,
> + struct media_entity *entity)
> +{
> + struct video_device *vdev;
> + int i;
> +
> + if (!is_media_entity_v4l2_video_device(entity))
> + return -ENODEV;
> +
> + vdev = media_entity_to_video_device(entity);
> +
> + for (i = 0; i < RCAR_VIN_NUM; i++) {
> + if (!group->vin[i])
> + continue;
> +
> + if (>vin[i]->vdev == vdev)
> + return i;
> + }
> +
> + return -ENODEV;
> +}
> +
> +/* group lock should be held when calling this function */
> +static int rvin_group_entity_to_csi_num(struct rvin_group *group,
> + struct media_entity *entity)
> +{
> + struct v4l2_subdev *sd;
> + int i;
> +
> + if (!is_media_entity_v4l2_subdev(entity))
> + return -ENODEV;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + for (i = 0; i < RVIN_CSI_MAX; i++)
> + if (group->csi[i].subdev == sd)
> + return i;
> +
> + return -ENODEV;
> +}
> +
> +/* group lock should be held when calling this function */
> +static void __rvin_group_build_link_list(struct rvin_group *group,
> +  struct rvin_group_chsel *map,
> +  int start, int len)
> +{
> + struct media_pad *vin_pad, *remote_pad;
> + unsigned int n;
> +
> + for (n = 0; n < len; n++) {
> + map[n].csi = -1;
> + map[n].chan = -1;
> +
> + if (!group->vin[start + n])
> + continue;
> +
> + vin_pad = >vin[start + n]->vdev.entity.pads[0];
> +
> + remote_pad = media_entity_remote_pad(vin_pad);
> + if (!remote_pad)
> + continue;
> +
> + map[n].csi =
> + rvin_group_entity_to_csi_num(group, remote_pad->entity);
> + map[n].chan = rvin_group_csi_pad_to_chan(remote_pad->index);
> + }
> +}
> +
> +/* group lock should be held when calling this function */
> +static int __rvin_group_try_get_chsel(struct rvin_group *group,
> +   struct rvin_group_chsel *map,
> +   int start, int len)
> +{
> + const struct rvin_group_chsel *sel;
> + unsigned int i, n;
> + int chsel;
> +
> + for (i = 0; i < group->vin[start]->info->num_chsels; i++) {
> + chsel = i;
> + for (n = 0; n < len; n++) {
> +
> + /* If the link is not active it's OK */
> + if (map[n].csi == -1)
> + 

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Hans Verkuil]

Hi Laurent,

On 16/11/17 01:33, Laurent Pinchart wrote:
> Device unplug being asynchronous, it naturally races with operations
> performed by userspace through ioctls or other file operations on video
> device nodes.
> 
> This leads to potential access to freed memory or to other resources
> during device access if unplug occurs during device access. To solve
> this, we need to wait until all device access completes when unplugging
> the device, and block all further access when the device is being
> unplugged.
> 
> Three new functions are introduced. The video_device_enter() and
> video_device_exit() functions must be used to mark entry and exit from
> all code sections where the device can be accessed. The
> video_device_unplug() function is then used in the unplug handler to
> mark the device as being unplugged and wait for all access to complete.
> 
> As an example mark the ioctl handler as a device access section. Other
> file operations need to be protected too, and blocking ioctls (such as
> VIDIOC_DQBUF) need to be handled as well.

As long as the queue field in struct video_device is filled in properly
this shouldn't be a problem.

This looks pretty good, simple and straightforward.

Do we need something similar for media_device? Other devices?

Regards,

Hans

> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/media/v4l2-core/v4l2-dev.c | 57 
> ++
>  include/media/v4l2-dev.h   | 47 +++
>  2 files changed, 104 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> b/drivers/media/v4l2-core/v4l2-dev.c
> index c647ba648805..c73c6d49e7cf 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device 
> *vdev)
>  }
>  EXPORT_SYMBOL(video_device_release_empty);
>  
> +int video_device_enter(struct video_device *vdev)
> +{
> + bool unplugged;
> +
> + spin_lock(>unplug_lock);
> + unplugged = vdev->unplugged;
> + if (!unplugged)
> + vdev->access_refcount++;
> + spin_unlock(>unplug_lock);
> +
> + return unplugged ? -ENODEV : 0;
> +}
> +EXPORT_SYMBOL_GPL(video_device_enter);
> +
> +void video_device_exit(struct video_device *vdev)
> +{
> + bool wake_up;
> +
> + spin_lock(>unplug_lock);
> + WARN_ON(--vdev->access_refcount < 0);
> + wake_up = vdev->access_refcount == 0;
> + spin_unlock(>unplug_lock);
> +
> + if (wake_up)
> + wake_up(>unplug_wait);
> +}
> +EXPORT_SYMBOL_GPL(video_device_exit);
> +
> +void video_device_unplug(struct video_device *vdev)
> +{
> + bool unplug_blocked;
> +
> + spin_lock(>unplug_lock);
> + unplug_blocked = vdev->access_refcount > 0;
> + vdev->unplugged = true;
> + spin_unlock(>unplug_lock);
> +
> + if (!unplug_blocked)
> + return;
> +
> + if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
> + msecs_to_jiffies(15)))
> + WARN(1, "Timeout waiting for device access to complete\n");
> +}
> +EXPORT_SYMBOL_GPL(video_device_unplug);
> +
>  static inline void video_get(struct video_device *vdev)
>  {
>   get_device(>dev);
> @@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
>   struct video_device *vdev = video_devdata(filp);
>   int ret = -ENODEV;
>  
> + ret = video_device_enter(vdev);
> + if (ret < 0)
> + return ret;
> +
>   if (vdev->fops->unlocked_ioctl) {
>   struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
>  
> @@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
>   return -ERESTARTSYS;
>   if (video_is_registered(vdev))
>   ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
> + else
> + ret = -ENODEV;
>   if (lock)
>   mutex_unlock(lock);
>   } else
>   ret = -ENOTTY;
>  
> + video_device_exit(vdev);
>   return ret;
>  }
>  
> @@ -841,6 +894,10 @@ int __video_register_device(struct video_device *vdev, 
> int type, int nr,
>   if (WARN_ON(!vdev->v4l2_dev))
>   return -EINVAL;
>  
> + /* unplug support */
> + spin_lock_init(>unplug_lock);
> + init_waitqueue_head(>unplug_wait);
> +
>   /* v4l2_fh support */
>   spin_lock_init(>fh_lock);
>   INIT_LIST_HEAD(>fh_list);
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index e657614521e3..365a94f91dc9 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -178,6 +179,12 @@ struct v4l2_file_operations {
>   * @pipe:  media_pipeline
>   * @fops: pointer to  

Re: [PATCH] gpio: pca953x: fix vendor prefix for PCA9654

[Sergei Shtylyov]

On 11/17/2017 12:06 PM, Geert Uytterhoeven wrote:


Despite commit 55020c8056a8 ("of: Add vendor prefix for ON Semiconductor
Corp.") was made long ago, the latter commit 9f49f6dd0473 ("gpio: pca953x:
add onsemi,pca9654 id") made use of another, undocumented vendor prefix.


Ouch...


Since such prefix doesn't seem to be used in any device trees, I think we
can just fix the "compatible" string in the driver and the bindings and be
done with that...

Fixes: 9f49f6dd0473 ("gpio: pca953x: add onsemi,pca9654 id")
Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'fixes' branch of LinusW's 'linux-gpio.git' repo.

  Documentation/devicetree/bindings/gpio/gpio-pca953x.txt |2 +-
  drivers/gpio/gpio-pca953x.c |2 +-


There's another (different) one in
Documentation/devicetree/bindings/misc/idt_89hpesx.txt


   Saw that. Do you think it also should be fixed (in this patch)?


Gr{oetje,eeting}s,

 Geert


MBR, Sergei

[PATCH 4/7] arm64: dts: r8a77995: Add CAN support

[Ulrich Hecht]

Adds CAN controller nodes for r8a77995.

Based on a patch for r8a7796 by Chris Paterson.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 32 +++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index a8df296..a611324 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -274,6 +274,38 @@
resets = < 906>;
};
 
+   can0: can@e6c3 {
+   compatible = "renesas,can-r8a77995",
+"renesas,rcar-gen3-can";
+   reg = <0 0xe6c3 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 916>,
+  < CPG_CORE R8A77995_CLK_CANFD>,
+  <_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   assigned-clocks = < CPG_CORE R8A77995_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 916>;
+   status = "disabled";
+   };
+
+   can1: can@e6c38000 {
+   compatible = "renesas,can-r8a77995",
+"renesas,rcar-gen3-can";
+   reg = <0 0xe6c38000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 915>,
+  < CPG_CORE R8A77995_CLK_CANFD>,
+  <_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   assigned-clocks = < CPG_CORE R8A77995_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 915>;
+   status = "disabled";
+   };
+
avb: ethernet@e680 {
compatible = "renesas,etheravb-r8a77995",
 "renesas,etheravb-rcar-gen3";
-- 
2.7.4

[PATCH 1/7] pinctrl: sh-pfc: r8a77995: Add CAN support

[Ulrich Hecht]

This patch adds CAN[0-1] pinmux support to the r8a77995 SoC.

Signed-off-by: Ulrich Hecht 
---
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
index 89b7541..616854d 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
@@ -1057,6 +1057,45 @@ static const unsigned int avb0_avtp_capture_b_mux[] = {
AVB0_AVTP_CAPTURE_B_MARK,
 };
 
+/* - CAN -- */
+static const unsigned int can0_data_a_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(4, 28), RCAR_GP_PIN(4, 31),
+};
+static const unsigned int can0_data_a_mux[] = {
+   CAN0_TX_A_MARK, CAN0_RX_A_MARK,
+};
+static const unsigned int can0_data_b_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(4, 22), RCAR_GP_PIN(4, 5),
+};
+static const unsigned int can0_data_b_mux[] = {
+   CAN0_TX_B_MARK, CAN0_RX_B_MARK,
+};
+static const unsigned int can1_data_a_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(4, 30), RCAR_GP_PIN(4, 29),
+};
+static const unsigned int can1_data_a_mux[] = {
+   CAN1_TX_A_MARK, CAN1_RX_A_MARK,
+};
+static const unsigned int can1_data_b_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(4, 7), RCAR_GP_PIN(4, 6),
+};
+static const unsigned int can1_data_b_mux[] = {
+   CAN1_TX_B_MARK, CAN1_RX_B_MARK,
+};
+
+/* - CAN Clock -- 
*/
+static const unsigned int can_clk_pins[] = {
+   /* CLK */
+   RCAR_GP_PIN(5, 2),
+};
+static const unsigned int can_clk_mux[] = {
+   CAN_CLK_MARK,
+};
+
 /* - I2C  
*/
 static const unsigned int i2c0_pins[] = {
/* SCL, SDA */
@@ -1504,6 +1543,11 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb0_avtp_pps_b),
SH_PFC_PIN_GROUP(avb0_avtp_match_b),
SH_PFC_PIN_GROUP(avb0_avtp_capture_b),
+   SH_PFC_PIN_GROUP(can0_data_a),
+   SH_PFC_PIN_GROUP(can0_data_b),
+   SH_PFC_PIN_GROUP(can1_data_a),
+   SH_PFC_PIN_GROUP(can1_data_b),
+   SH_PFC_PIN_GROUP(can_clk),
SH_PFC_PIN_GROUP(i2c0),
SH_PFC_PIN_GROUP(i2c1),
SH_PFC_PIN_GROUP(i2c2_a),
@@ -1581,6 +1625,18 @@ static const char * const avb0_groups[] = {
"avb0_avtp_capture_b",
 };
 
+static const char * const can0_groups[] = {
+   "can0_data_a",
+   "can0_data_b",
+};
+static const char * const can1_groups[] = {
+   "can1_data_a",
+   "can1_data_b",
+};
+static const char * const can_clk_groups[] = {
+   "can_clk",
+};
+
 static const char * const i2c0_groups[] = {
"i2c0",
 };
@@ -1691,6 +1747,9 @@ static const char * const usb0_groups[] = {
 static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(audio_clk),
SH_PFC_FUNCTION(avb0),
+   SH_PFC_FUNCTION(can0),
+   SH_PFC_FUNCTION(can1),
+   SH_PFC_FUNCTION(can_clk),
SH_PFC_FUNCTION(i2c0),
SH_PFC_FUNCTION(i2c1),
SH_PFC_FUNCTION(i2c2),
-- 
2.7.4

[PATCH 3/7] arm64: dts: r8a77995: Add CAN external clock support

[Ulrich Hecht]

Adds external CAN clock node for r8a77995. This clock can be used as
fCAN clock of CAN and CAN FD controller.

Based on a patch for r8a7796 by Chris Paterson.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 788e3af..a8df296 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -51,6 +51,13 @@
clock-frequency = <0>;
};
 
+   /* External CAN clock - to be overridden by boards that provide it */
+   can_clk: can {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
scif_clk: scif {
compatible = "fixed-clock";
#clock-cells = <0>;
-- 
2.7.4

[PATCH 2/7] pinctrl: sh-pfc: r8a77995: Add CAN FD support

[Ulrich Hecht]

This patch adds CAN FD[0-1] pinmux support to the r8a77995 SoC.

Signed-off-by: Ulrich Hecht 
---
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
index 616854d..e7849a4 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
@@ -1096,6 +1096,22 @@ static const unsigned int can_clk_mux[] = {
CAN_CLK_MARK,
 };
 
+/* - CAN FD - 
*/
+static const unsigned int canfd0_data_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(4, 28), RCAR_GP_PIN(4, 31),
+};
+static const unsigned int canfd0_data_mux[] = {
+   CANFD0_TX_MARK, CANFD0_RX_MARK,
+};
+static const unsigned int canfd1_data_pins[] = {
+   /* TX, RX */
+   RCAR_GP_PIN(4, 30), RCAR_GP_PIN(4, 29),
+};
+static const unsigned int canfd1_data_mux[] = {
+   CANFD1_TX_MARK, CANFD1_RX_MARK,
+};
+
 /* - I2C  
*/
 static const unsigned int i2c0_pins[] = {
/* SCL, SDA */
@@ -1548,6 +1564,8 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(can1_data_a),
SH_PFC_PIN_GROUP(can1_data_b),
SH_PFC_PIN_GROUP(can_clk),
+   SH_PFC_PIN_GROUP(canfd0_data),
+   SH_PFC_PIN_GROUP(canfd1_data),
SH_PFC_PIN_GROUP(i2c0),
SH_PFC_PIN_GROUP(i2c1),
SH_PFC_PIN_GROUP(i2c2_a),
@@ -1637,6 +1655,13 @@ static const char * const can_clk_groups[] = {
"can_clk",
 };
 
+static const char * const canfd0_groups[] = {
+   "canfd0_data",
+};
+static const char * const canfd1_groups[] = {
+   "canfd1_data",
+};
+
 static const char * const i2c0_groups[] = {
"i2c0",
 };
@@ -1750,6 +1775,8 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(can0),
SH_PFC_FUNCTION(can1),
SH_PFC_FUNCTION(can_clk),
+   SH_PFC_FUNCTION(canfd0),
+   SH_PFC_FUNCTION(canfd1),
SH_PFC_FUNCTION(i2c0),
SH_PFC_FUNCTION(i2c1),
SH_PFC_FUNCTION(i2c2),
-- 
2.7.4

[PATCH 7/7] can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt 
b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 93c3a6a..5617892 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -6,6 +6,7 @@ Required properties:
   - "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
   - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
   - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
+  - "renesas,r8a77995-canfd" for R8A77995 (R-Car D3) compatible controller.
 
   When compatible with the generic version, nodes must list the
   SoC-specific version corresponding to the platform first, followed by the
@@ -24,12 +25,12 @@ The name of the child nodes are "channel0" and "channel1" 
respectively. Each
 child node supports the "status" property only, which is used to
 enable/disable the respective channel.
 
-Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd"
-compatible:
-In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by 
both
-CAN and CAN FD controller at the same time. It needs to be scaled to maximum
-frequency if any of these controllers use it. This is done using the below
-properties:
+Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and
+"renesas,r8a77995" compatible:
+In R8A7795, R8A7796 and R8A77995 SoCs, canfd clock is a div6 clock and can
+be used by both CAN and CAN FD controller at the same time. It needs to be
+scaled to maximum frequency if any of these controllers use it. This is
+done using the below properties:
 
 - assigned-clocks: phandle of canfd clock.
 - assigned-clock-rates: maximum frequency of this clock.
-- 
2.7.4

[PATCH 0/7] R-Car D3 (r8a77995) CAN support

[Ulrich Hecht]

Hi!

Here's CAN and CAN FD support for the R-Car D3. This is a by-the-datasheet
implementation, with the datasheet missing some bits, namely the pin map.
I filled in the gaps with frog DNA^W^W^Wby deducing the information from
pin numbers already in the PFC driver, so careful scrutiny is advised.

CU
Uli


Ulrich Hecht (7):
  pinctrl: sh-pfc: r8a77995: Add CAN support
  pinctrl: sh-pfc: r8a77995: Add CAN FD support
  arm64: dts: r8a77995: Add CAN external clock support
  arm64: dts: r8a77995: Add CAN support
  arm64: dts: r8a77995: Add CAN FD support
  can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
  can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings

 .../devicetree/bindings/net/can/rcar_can.txt   | 13 ++--
 .../devicetree/bindings/net/can/rcar_canfd.txt | 13 ++--
 arch/arm64/boot/dts/renesas/r8a77995.dtsi  | 64 
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c  | 86 ++
 4 files changed, 164 insertions(+), 12 deletions(-)

-- 
2.7.4

[PATCH 6/7] can: rcar_can: document r8a77995 (R-Car D3) compatibility strings

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt 
b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 06bb7cc..f7d0358 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -11,6 +11,7 @@ Required properties:
  "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
  "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
  "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
+ "renesas,can-r8a77995" if CAN controller is a part of R8A77995 
SoC.
  "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible 
device.
  "renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible 
device.
  "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible 
device.
@@ -25,12 +26,12 @@ Required properties:
 - pinctrl-0: pin control group to be used for this controller.
 - pinctrl-names: must be "default".
 
-Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
-compatible:
-In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
-and can be used by both CAN and CAN FD controller at the same time. It needs to
-be scaled to maximum frequency if any of these controllers use it. This is done
-using the below properties:
+Required properties for "renesas,can-r8a7795", "renesas,can-r8a7796" and
+"renesas,can-r8a77995" compatible:
+In R8A7795, R8A7796 and R8A77995 SoCs, "clkp2" can be CANFD clock. This is a
+div6 clock and can be used by both CAN and CAN FD controller at the same
+time. It needs to be scaled to maximum frequency if any of these
+controllers use it. This is done using the below properties:
 
 - assigned-clocks: phandle of clkp2(CANFD) clock.
 - assigned-clock-rates: maximum frequency of this clock.
-- 
2.7.4

[PATCH 5/7] arm64: dts: r8a77995: Add CAN FD support

[Ulrich Hecht]

Adds CAN FD controller node for r8a77995.

Based on a patch for r8a7796 by Chris Paterson.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index a611324..6648c9b 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -306,6 +306,31 @@
status = "disabled";
};
 
+   canfd: can@e66c {
+   compatible = "renesas,r8a77995-canfd",
+"renesas,rcar-gen3-canfd";
+   reg = <0 0xe66c 0 0x8000>;
+   interrupts = ,
+  ;
+   clocks = < CPG_MOD 914>,
+  < CPG_CORE R8A77995_CLK_CANFD>,
+  <_clk>;
+   clock-names = "fck", "canfd", "can_clk";
+   assigned-clocks = < CPG_CORE R8A77995_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 914>;
+   status = "disabled";
+
+   channel0 {
+   status = "disabled";
+   };
+
+   channel1 {
+   status = "disabled";
+   };
+   };
+
avb: ethernet@e680 {
compatible = "renesas,etheravb-r8a77995",
 "renesas,etheravb-rcar-gen3";
-- 
2.7.4

Re: [PATCH RFT] i2c: sh_mobile: make sure to not accidently trigger STOP

[jacopo mondi]

Hi Wolfram,

On Wed, Nov 15, 2017 at 03:32:21PM +0100, Wolfram Sang wrote:
> The datasheet was a bit vague, but after consultation with HW designers,
> we came to the conclusion that we should set the SCP bit always when
> dealing only with the ICE bit. A set SCP bit is ignored, and thus fine,
> a cleared one may trigger STOP on the bus.
>
> Signed-off-by: Wolfram Sang 
> ---
>
> Jacopo: another to test, please. On top of all the other patches. Thank you!

and for this one as well, on Migo-R no visible regressions. I2c sensor
probes properly, and I can capture images.

Tested-by: Jacopo Mondi 

Thanks
  j

>
>  drivers/i2c/busses/i2c-sh_mobile.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-sh_mobile.c 
> b/drivers/i2c/busses/i2c-sh_mobile.c
> index 9012d5f8fb38b8..c2841a4f5807c0 100644
> --- a/drivers/i2c/busses/i2c-sh_mobile.c
> +++ b/drivers/i2c/busses/i2c-sh_mobile.c
> @@ -604,10 +604,10 @@ static int start_ch(struct sh_mobile_i2c_data *pd, 
> struct i2c_msg *usr_msg,
>
>   if (do_init) {
>   /* Initialize channel registers */
> - iic_wr(pd, ICCR, 0);
> + iic_wr(pd, ICCR, ICCR_SCP);
>
>   /* Enable channel and configure rx ack */
> - iic_wr(pd, ICCR, ICCR_ICE);
> + iic_wr(pd, ICCR, ICCR_ICE | ICCR_SCP);
>
>   /* Set the clock */
>   iic_wr(pd, ICCL, pd->iccl & 0xff);
> @@ -723,7 +723,7 @@ static int sh_mobile_i2c_xfer(struct i2c_adapter *adapter,
>   }
>
>   /* Disable channel */
> - iic_wr(pd, ICCR, 0);
> + iic_wr(pd, ICCR, ICCR_SCP);
>
>   /* Disable clock and mark device as idle */
>   pm_runtime_put_sync(pd->dev);
> --
> 2.11.0
>

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[jacopo mondi]

Hi Sakari!

On Fri, Nov 17, 2017 at 02:36:51AM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Wed, Nov 15, 2017 at 03:25:11PM +0100, jacopo mondi wrote:
> > Hi Sakari,
> >thanks for review!
>
> You're welcome!
>
> > On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote:
> > > Hi Jacopo,
> > >
> > > Could you remove the original driver and send the patch using git
> > > send-email -C ? That way a single patch would address converting it to a
> > > proper V4L2 driver as well as move it to the correct location. The changes
> > > would be easier to review that way since then, well, it'd be easier to see
> > > the changes. :-)
> >
> > Actually I prefer not to remove the existing driver at the moment. See
> > the cover letter for reasons why not to do so right now...
>
> So it's about testing mostly? Does someone (possibly you) have those boards
> to test? I'd like to see this patchset to remove that last remaining SoC
> camera bridge driver. :-)

Well, we agreed that for most of those platforms, compile testing it
would be enough (let's believe in "if it compiles, it works"). I
personally don't have access to those boards, and frankly I'm not even
sure there are many of them around these days (I guess most of them
are not even produced anymore).

>
> >
> > Also, there's not that much code from the old driver in here, surely
> > less than the default 50% -C and -M options of 'git format-patch' use
> > as a threshold for detecting copies iirc..
>
> Oh, if that's so, then makes sense to review it as a new driver.

thanks :)

>
> >
> > > The same goes for the two V4L2 SoC camera sensor / video decoder drivers 
> > > at
> > > the end of the set.
> > >
> >
> > Also in this case I prefer not to remove existing code, as long as
> > there are platforms using it..
>
> Couldn't they use this driver instead?

Oh, they will eventually, I hope :)

I would like to make sure we're all on the same page with this. My
preference would be:

1) Have renesas-ceu.c driver merged with Migo-R ported to use this new
driver as an 'example'.
2) Do not remove any of the existing soc_camera code at this point
3) Port all other 4 SH users of sh_mobile_ceu_camera to use the now
merged renesas-ceu driver
4) Remove sh_mobile_ceu_camera and soc_camera sensor drivers whose
only users were those 4 SH boards
5) Remove soc_camera completely. For my understanding there are some
PXA platforms still using soc_camera provided utilities somewhere.
Hans knows better, but we can discuss this once we'll get there.

Let me know if this is ok for everyone.

Thanks
   j

Re: [PATCH v1 06/10] sh: sh7722: Rename CEU clock

[jacopo mondi]

Hi Geert,

On Wed, Nov 15, 2017 at 02:13:43PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
>  wrote:
> > Rename CEU clock to match the new platform driver name used in Migo-R.
> >
> > There are no other sh7722 based devices Migo-R apart, so we can safely
> > rename this.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c 
> > b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> > index 8f07a1a..d85091e 100644
> > --- a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> > +++ b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> > @@ -223,7 +223,7 @@ static struct clk_lookup lookups[] = {
> > CLKDEV_DEV_ID("sh-vou.0", _clks[HWBLK_VOU]),
> > CLKDEV_CON_ID("jpu0", _clks[HWBLK_JPU]),
> > CLKDEV_CON_ID("beu0", _clks[HWBLK_BEU]),
> > -   CLKDEV_DEV_ID("sh_mobile_ceu.0", _clks[HWBLK_CEU]),
> > +   CLKDEV_DEV_ID("renesas-ceu.0", _clks[HWBLK_CEU]),
> > CLKDEV_CON_ID("veu0", _clks[HWBLK_VEU]),
> > CLKDEV_CON_ID("vpu0", _clks[HWBLK_VPU]),
> > CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", _clks[HWBLK_LCDC]),
>
> Shouldn't this be merged with "[PATCH v1 05/10] arch: sh: migor: Use new
> renesas-ceu camera driver", to avoid breaking bisection?

That's a good idea. I will merge these two commits in v2.

Thanks
   j

>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH v1 08/10] media: i2c: ov772x: Remove soc_camera dependencies

[jacopo mondi]

Hi Sakari!

On Fri, Nov 17, 2017 at 02:43:15AM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Wed, Nov 15, 2017 at 11:56:01AM +0100, Jacopo Mondi wrote:
> >

[snip]

> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -25,8 +26,8 @@
> >  #include 
> >
> >  #include 
> > -#include 
> > -#include 
> > +
> > +#include 
>
> Alphabetical order would be nice.

ups!

>
> >  #include 
> >  #include 
> >  #include 
> > @@ -393,7 +394,7 @@ struct ov772x_win_size {
> >  struct ov772x_priv {
> > struct v4l2_subdevsubdev;
> > struct v4l2_ctrl_handler  hdl;
> > -   struct v4l2_clk  *clk;
> > +   struct clk   *clk;
> > struct ov772x_camera_info*info;
> > const struct ov772x_color_format *cfmt;
> > const struct ov772x_win_size *win;
> > @@ -550,7 +551,7 @@ static int ov772x_reset(struct i2c_client *client)
> >  }
> >
> >  /*
> > - * soc_camera_ops function
> > + * subdev ops
> >   */
> >
> >  static int ov772x_s_stream(struct v4l2_subdev *sd, int enable)
> > @@ -650,13 +651,36 @@ static int ov772x_s_register(struct v4l2_subdev *sd,
> >  }
> >  #endif
> >
> > +static int ov772x_power_on(struct ov772x_priv *priv)
> > +{
> > +   int ret;
> > +
> > +   if (priv->info->platform_enable) {
> > +   ret = priv->info->platform_enable();
> > +   if (ret)
> > +   return ret;
>
> What does this do, enable the regulator?

Well, it depends on what function the platform code stores in
'platform_enable' pointer, doesn't it?

As you can see in [05/10] of this series, for Migo-R it's not about
a regulator, but switching between the two available video inputs
(OV7725 and TW9910) toggling their 'enable' pins.

Thanks
   j

Re: [PATCH] gpio: pca953x: fix vendor prefix for PCA9654

[Geert Uytterhoeven]

Hi Sergei,

On Thu, Nov 16, 2017 at 9:18 PM, Sergei Shtylyov
 wrote:
> Despite commit 55020c8056a8 ("of: Add vendor prefix for ON Semiconductor
> Corp.") was made long ago, the latter commit 9f49f6dd0473 ("gpio: pca953x:
> add onsemi,pca9654 id") made use of another, undocumented vendor prefix.

Ouch...

> Since such prefix doesn't seem to be used in any device trees, I think we
> can just fix the "compatible" string in the driver and the bindings and be
> done with that...
>
> Fixes: 9f49f6dd0473 ("gpio: pca953x: add onsemi,pca9654 id")
> Signed-off-by: Sergei Shtylyov 
>
> ---
> The patch is against the 'fixes' branch of LinusW's 'linux-gpio.git' repo.
>
>  Documentation/devicetree/bindings/gpio/gpio-pca953x.txt |2 +-
>  drivers/gpio/gpio-pca953x.c |2 +-

There's another (different) one in
Documentation/devicetree/bindings/misc/idt_89hpesx.txt

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds