[PATCH 1/2] sh_eth: get rid of 'sh_eth_cpu_data::shift_rd0'

[Sergei Shtylyov]

After checking all  the available manuals,  I have enough information to
conclude  that the 'shift_rd0' flag is only relevant  for the Ether cores
supporting so called "intelligent checksum" (and hence having CSMR) which
is indicated  by the 'hw_crc' flag.  Since  all the relevant SoCs now have
both these flags set, we can  at last  get  rid of the former flag...

Signed-off-by: Sergei Shtylyov 

---
 drivers/net/ethernet/renesas/sh_eth.c |5 +
 drivers/net/ethernet/renesas/sh_eth.h |1 -
 2 files changed, 1 insertion(+), 5 deletions(-)

Index: net/drivers/net/ethernet/renesas/sh_eth.c
===
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -537,7 +537,6 @@ static struct sh_eth_cpu_data r7s72100_d
.no_ade = 1,
.hw_crc = 1,
.tsu= 1,
-   .shift_rd0  = 1,
 };
 
 static void sh_eth_chip_reset_r8a7740(struct net_device *ndev)
@@ -577,7 +576,6 @@ static struct sh_eth_cpu_data r8a7740_da
.hw_crc = 1,
.tsu= 1,
.select_mii = 1,
-   .shift_rd0  = 1,
 };
 
 /* There is CPU dependent code */
@@ -820,7 +818,6 @@ static struct sh_eth_cpu_data sh7734_dat
.tsu= 1,
.hw_crc = 1,
.select_mii = 1,
-   .shift_rd0  = 1,
 };
 
 /* SH7763 */
@@ -1421,7 +1418,7 @@ static int sh_eth_rx(struct net_device *
 * the RFS bits are from bit 25 to bit 16. So, the
 * driver needs right shifting by 16.
 */
-   if (mdp->cd->shift_rd0)
+   if (mdp->cd->hw_crc)
desc_status >>= 16;
 
skb = mdp->rx_skbuff[entry];
Index: net/drivers/net/ethernet/renesas/sh_eth.h
===
--- net.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net/drivers/net/ethernet/renesas/sh_eth.h
@@ -490,7 +490,6 @@ struct sh_eth_cpu_data {
unsigned no_ade:1;  /* E-DMAC DO NOT have ADE bit in EESR */
unsigned hw_crc:1;  /* E-DMAC have CSMR */
unsigned select_mii:1;  /* EtherC have RMII_MII (MII select register) */
-   unsigned shift_rd0:1;   /* shift Rx descriptor word 0 right by 16 */
unsigned rmiimode:1;/* EtherC has RMIIMODE register */
unsigned rtrate:1;  /* EtherC has RTRATE register */
 };

[PATCH 2/2] sh_eth: rename 'sh_eth_cpu_data::hw_crc'

[Sergei Shtylyov]

The 'struct sh_eth_cpu_data' field indicating the "intelligent checksum"
support was misnamed 'hw_crc' -- rename it to 'hw_checksum'.

Signed-off-by: Sergei Shtylyov 

---
 drivers/net/ethernet/renesas/sh_eth.c |   12 ++--
 drivers/net/ethernet/renesas/sh_eth.h |2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

Index: net/drivers/net/ethernet/renesas/sh_eth.c
===
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -535,7 +535,7 @@ static struct sh_eth_cpu_data r7s72100_d
.rpadir_value   = 2 << 16,
.no_trimd   = 1,
.no_ade = 1,
-   .hw_crc = 1,
+   .hw_checksum= 1,
.tsu= 1,
 };
 
@@ -573,7 +573,7 @@ static struct sh_eth_cpu_data r8a7740_da
.rpadir_value   = 2 << 16,
.no_trimd   = 1,
.no_ade = 1,
-   .hw_crc = 1,
+   .hw_checksum= 1,
.tsu= 1,
.select_mii = 1,
 };
@@ -816,7 +816,7 @@ static struct sh_eth_cpu_data sh7734_dat
.no_trimd   = 1,
.no_ade = 1,
.tsu= 1,
-   .hw_crc = 1,
+   .hw_checksum= 1,
.select_mii = 1,
 };
 
@@ -933,7 +933,7 @@ static int sh_eth_reset(struct net_devic
sh_eth_write(ndev, 0x0, RDFFR);
 
/* Reset HW CRC register */
-   if (mdp->cd->hw_crc)
+   if (mdp->cd->hw_checksum)
sh_eth_write(ndev, 0x0, CSMR);
 
/* Select MII mode */
@@ -1418,7 +1418,7 @@ static int sh_eth_rx(struct net_device *
 * the RFS bits are from bit 25 to bit 16. So, the
 * driver needs right shifting by 16.
 */
-   if (mdp->cd->hw_crc)
+   if (mdp->cd->hw_checksum)
desc_status >>= 16;
 
skb = mdp->rx_skbuff[entry];
@@ -1986,7 +1986,7 @@ static size_t __sh_eth_get_regs(struct n
add_reg(MAFCR);
if (cd->rtrate)
add_reg(RTRATE);
-   if (cd->hw_crc)
+   if (cd->hw_checksum)
add_reg(CSMR);
if (cd->select_mii)
add_reg(RMII_MII);
Index: net/drivers/net/ethernet/renesas/sh_eth.h
===
--- net.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net/drivers/net/ethernet/renesas/sh_eth.h
@@ -488,7 +488,7 @@ struct sh_eth_cpu_data {
unsigned rpadir:1;  /* E-DMAC have RPADIR */
unsigned no_trimd:1;/* E-DMAC DO NOT have TRIMD */
unsigned no_ade:1;  /* E-DMAC DO NOT have ADE bit in EESR */
-   unsigned hw_crc:1;  /* E-DMAC have CSMR */
+   unsigned hw_checksum:1; /* E-DMAC has CSMR */
unsigned select_mii:1;  /* EtherC have RMII_MII (MII select register) */
unsigned rmiimode:1;/* EtherC has RMIIMODE register */
unsigned rtrate:1;  /* EtherC has RTRATE register */

[PATCH 0/2] sh_eth: "intgelligent checksum" related cleanups

[Sergei Shtylyov]

Hello.

   Here's a set of 2 patches against DaveM's 'net.git' repo, as they are based
on a couple patches merged there recently; however, the patches are destined
for 'net-next.git' (once 'net.git' gets merged there next time). I'm cleaning
up the "intelligent checksum" related code (however, the driver only disables
this feature for now, theres's no proper offload supprt yet).

[1/2] sh_eth: get rid of 'sh_eth_cpu_data::shift_rd0'
[2/2] sh_eth: rename 'sh_eth_cpu_data::hw_crc'

MBR, Sergei

Re: [PATCH] sh_eth: R8A7740 supports packet shecksumming

[David Miller]

From: Sergei Shtylyov 
Date: Thu, 5 Jan 2017 12:33:21 +0300

>Oops, typo in the subject, "shecksumming". David, should I resend?

I accidently pushed this out without fixing the typo, sorry about
that but that's going to be how it is I'm afraid :-)

Re: [PATCH] sh_eth: R8A7740 supports packet shecksumming

[David Miller]

From: Sergei Shtylyov 
Date: Thu, 05 Jan 2017 00:29:32 +0300

> The R8A7740 GEther controller supports the packet checksum offloading
> but the 'hw_crc' (bad name, I'll fix it) flag isn't set in the R8A7740
> data,  thus CSMR isn't cleared...
> 
> Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740")
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH] sh_eth: fix EESIPR values for SH77{34|63}

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 04 Jan 2017 22:18:24 +0300

> As the SH77{34|63} manuals are freely available,  I've checked the EESIPR
> values written against the manuals, and they appeared to set the reserved
> bits 11-15 (which should be 0 on write). Fix those EESIPR values.
> 
> Fixes: 380af9e390ec ("net: sh_eth: CPU dependency code collect to "struct 
> sh_eth_cpu_data"")
> Fixes: f5d12767c8fd ("sh_eth: get SH77{34|63} support out of #ifdef")
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

[Sergei Shtylyov]

Hello!

On 01/05/2017 01:43 PM, Simon Horman wrote:


From: Kazuya Mizuguchi 

"swiotlb buffer is full" errors occur after repeated initialisation of a
device - f.e. suspend/resume or ip link set up/down. This is because memory
mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
is not released.  Resolve this problem by unmapping descriptors when
freeing rings.

Note, ravb_tx_free() is moved but not otherwise modified by this patch.

Signed-off-by: Kazuya Mizuguchi 
[simon: reworked]
Signed-off-by: Simon Horman 
--
v1 [Kazuya Mizuguchi]

v2 [Simon Horman]
* As suggested by Sergei Shtylyov
  - Use dma_mapping_error() and rx_desc->ds_cc when unmapping RX descriptors;
this is consistent with the way that they are mapped
  - Use ravb_tx_free() to clear TX descriptors


   Not sure that was good idea (sorry)... ravb_tx_ring() only unmaps the 
transmitted buffers, while we need to unmap everything...



* Reduce scope of new local variable
---
 drivers/net/ethernet/renesas/ravb_main.c | 89 ++--
 1 file changed, 51 insertions(+), 38 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 92d7692c840d..1797c48e3176 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -179,6 +179,44 @@ static struct mdiobb_ops bb_ops = {
.get_mdio_data = ravb_get_mdio_data,
 };

+/* Free TX skb function for AVB-IP */
+static int ravb_tx_free(struct net_device *ndev, int q)
+{
+   struct ravb_private *priv = netdev_priv(ndev);
+   struct net_device_stats *stats = >stats[q];
+   struct ravb_tx_desc *desc;
+   int free_num = 0;
+   int entry;
+   u32 size;
+
+   for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
+   entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+NUM_TX_DESC);
+   desc = >tx_ring[q][entry];
+   if (desc->die_dt != DT_FEMPTY)


   Here, it stop once an untransmitted buffer is encountered...


+   break;
+   /* Descriptor type must be checked before all other reads */
+   dma_rmb();
+   size = le16_to_cpu(desc->ds_tagl) & TX_DS;
+   /* Free the original skb. */
+   if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+   dma_unmap_single(ndev->dev.parent, 
le32_to_cpu(desc->dptr),
+size, DMA_TO_DEVICE);
+   /* Last packet descriptor? */
+   if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
+   entry /= NUM_TX_DESC;
+   dev_kfree_skb_any(priv->tx_skb[q][entry]);
+   priv->tx_skb[q][entry] = NULL;
+   stats->tx_packets++;
+   }
+   free_num++;
+   }
+   stats->tx_bytes += size;
+   desc->die_dt = DT_EEMPTY;
+   }
+   return free_num;
+}
+
 /* Free skb's and DMA buffers for Ethernet AVB */
 static void ravb_ring_free(struct net_device *ndev, int q)
 {
@@ -207,6 +245,18 @@ static void ravb_ring_free(struct net_device *ndev, int q)
priv->tx_align[q] = NULL;

if (priv->rx_ring[q]) {
+   for (i = 0; i < priv->num_rx_ring[q]; i++) {
+   struct ravb_ex_rx_desc *rx_desc = >rx_ring[q][i];
+
+   if (!dma_mapping_error(ndev->dev.parent,
+  rx_desc->dptr)) {


  You forgot le32_to_cpu() here, we can't use the raw descriptor fields.


+   dma_unmap_single(ndev->dev.parent,
+le32_to_cpu(rx_desc->dptr),
+PKT_BUF_SZ,
+DMA_FROM_DEVICE);
+   rx_desc->ds_cc = cpu_to_le16(0);


   You don't check it anyway, not sure what that buys...

[...]

MBR, Sergei

[PATCH] arm64: do not set dma masks that device connection can't handle

[Nikita Yushchenko]

It is possible that device is capable of 64-bit DMA addresses, and
device driver tries to set wide DMA mask, but bridge or bus used to
connect device to the system can't handle wide addresses.

With swiotlb, memory above 4G still can be used by drivers for streaming
DMA, but *dev->mask and dev->dma_coherent_mask must still keep values
that hardware handles physically.

This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.

Signed-off-by: Nikita Yushchenko 
CC: Arnd Bergmann 
---

... now with initially missed change in arch_setup_dma_ops() ...

 arch/arm64/Kconfig  |  3 +++
 arch/arm64/include/asm/device.h |  1 +
 arch/arm64/mm/dma-mapping.c | 52 +
 3 files changed, 56 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1117421..afb2c08 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -216,6 +216,9 @@ config NEED_DMA_MAP_STATE
 config NEED_SG_DMA_LENGTH
def_bool y
 
+config ARCH_HAS_DMA_SET_COHERENT_MASK
+   def_bool y
+
 config SMP
def_bool y
 
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 243ef25..a57e7bb 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
void *iommu;/* private IOMMU data */
 #endif
bool dma_coherent;
+   u64 parent_dma_mask;
 };
 
 struct pdev_archdata {
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..09c7900 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,31 @@ static int __swiotlb_dma_supported(struct device *hwdev, 
u64 mask)
return 1;
 }
 
+static int __swiotlb_set_dma_mask(struct device *dev, u64 mask)
+{
+   /* device is not DMA capable */
+   if (!dev->dma_mask)
+   return -EIO;
+
+   /* mask is below swiotlb bounce buffer, so fail */
+   if (!swiotlb_dma_supported(dev, mask))
+   return -EIO;
+
+   /*
+* because of the swiotlb, we can return success for
+* larger masks, but need to ensure that bounce buffers
+* are used above parent_dma_mask, so set that as
+* the effective mask.
+*/
+   if (mask > dev->archdata.parent_dma_mask)
+   mask = dev->archdata.parent_dma_mask;
+
+
+   *dev->dma_mask = mask;
+
+   return 0;
+}
+
 static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,
@@ -367,8 +392,23 @@ static struct dma_map_ops swiotlb_dma_ops = {
.sync_sg_for_device = __swiotlb_sync_sg_for_device,
.dma_supported = __swiotlb_dma_supported,
.mapping_error = swiotlb_dma_mapping_error,
+   .set_dma_mask = __swiotlb_set_dma_mask,
 };
 
+int dma_set_coherent_mask(struct device *dev, u64 mask)
+{
+   if (!dma_supported(dev, mask))
+   return -EIO;
+
+   if (get_dma_ops(dev) == _dma_ops &&
+   mask > dev->archdata.parent_dma_mask)
+   mask = dev->archdata.parent_dma_mask;
+
+   dev->coherent_dma_mask = mask;
+   return 0;
+}
+EXPORT_SYMBOL(dma_set_coherent_mask);
+
 static int __init atomic_pool_init(void)
 {
pgprot_t prot = __pgprot(PROT_NORMAL_NC);
@@ -957,6 +997,18 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = _dma_ops;
 
+   /*
+* we don't yet support buses that have a non-zero mapping.
+*  Let's hope we won't need it
+*/
+   WARN_ON(dma_base != 0);
+
+   /*
+* Whatever the parent bus can set. A device must not set
+* a DMA mask larger than this.
+*/
+   dev->archdata.parent_dma_mask = size;
+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
 }
-- 
2.1.4

Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

[Laurent Pinchart]

Hi Jose,

On Friday 06 Jan 2017 10:07:03 Jose Abreu wrote:
> Hi Laurent,
> 
> Sorry for the delayed answer but I am quite busy at the moment.

No worries, your help is really appreciated.

> On 06-01-2017 01:48, Laurent Pinchart wrote:
> 
> [snip]
> 
>  The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
>  output signal, but there seems to be no HDMI TX register from which its
>  state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
>  through I2C ? How long is the PHY expected to take to set TX_READY to 0
>  ?
> >>> 
> >>> TX_READY can be read from register 0x1A of phy, BIT(2) (through
> >>> I2C).
> >> 
> >> That's what I thought, I'll poll that then. Do you have any idea how long
> >> it's supposed to take, to set an appropriate timeout ?
> 
> For 3d tx phy and for 25 MHz input reference clock the power-up
> time is ~1ms, there is no data in the docs to power-down time but
> it should be similar. Reference clock value is board dependent
> and the minimum value for HDMI shall be 13.5MHz.
> 
> > On i.MX6 (3D TX PHY) register 0x1a reads as 0x0007 before powering down
> > the PHY (by deasserting TXPWRON) and as 0x immediately after. On
> > RK3288 (MHL PHY) the register reads as 0x0207 and as 0x immediately
> > after deasserting TXPWRON. It seems that one I2C read is a sufficient
> > delay for TX_READY to go low.
> > 
> >>> Not sure if same offset for all phys though.
> >> 
> >> Most probably not, it would be too easy :-) I'll investigate (which will
> >> likely include lots of guesswork). If you can find any information about
> >> that (and especially about the MHL and HDMI 2.0 PHYs) that would be very
> >> appreciated, as I don't have access to any documentation that mentions a
> >> TX_READY bit for those.
> > 
> > I haven't tested the HDMI 2.0 PHY yet, but I'd be surprised if the
> > TX_READY bit was in the same register at the same position.
> 
> The info I got the register offset is from an HDMI 2.0 phy :)

That's good news :-)

> Notice that there are a lot of phy versions and some of them
> (used in dw-hdmi) maybe customized, I don't think I have access
> to that custom phys documentation.

I think we will eventually have to implement PHY-specific power up and power 
down sequences, but for now a common sequence should work.

> Please test the HDMI 2.0 phy and check if the register is the same, it
> should be.

I did, and it is \o/ I'll send patches.

> In the meantime it would really be helpful if some of the developers
> that used dw-hdmi supplied this info about the registers as they
> should know exactly what phy was used.

I will ask internally for the R-Car H3 SoC.

-- 
Regards,

Laurent Pinchart

Re: About VSPD

[Laurent Pinchart]

Hello Jithin,

On Friday 06 Jan 2017 07:15:27 Jithin T Raj wrote:
> hello Laurent and all,
> 
> Can anybody give me an insight to VSPD .Recently I am going through
> the term VSPD..Is it associated with Display Unit ? ..It will be a help if
> someone share some links about VSPD..I am a beginner in both kernel and
> RCar families..

The VSP is a memory-to-memory image processor than can perform operations such 
as format conversion, scaling, blending, ... There are multiple VSP instances 
on R-Car Gen2 and Gen3 SoCs, whose number and features depend on the 
particular SoC. The VSPD is a VSP type designed for display operation that can 
feed its output directly to the display in addition to writing it to memory 
like all other VSPs. On R-Car Gen3 SoCs usage of the VSPD for display is 
mandatory, so the VSPD is handled automatically by the DU driver and isn't 
visible to userspace. On R-Car Gen2 SocS usage of the VSPD for display os 
optional, so the VSPD is exposed to userspace through the V4L2 API. Connecting 
the VSPD output directly to the display on R-Car Gen2 currently requires out-
of-tree patches (see 
http://comments.gmane.org/gmane.comp.video.dri.devel/127526).

-- 
Regards,

Laurent Pinchart

[PATCH] arm64: do not set dma masks that device connection can't handle

[Nikita Yushchenko]

It is possible that device is capable of 64-bit DMA addresses, and
device driver tries to set wide DMA mask, but bridge or bus used to
connect device to the system can't handle wide addresses.

With swiotlb, memory above 4G still can be used by drivers for streaming
DMA, but *dev->mask and dev->dma_coherent_mask must still keep values
that hardware handles physically.

This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.

Signed-off-by: Nikita Yushchenko 
CC: Arnd Bergmann 
---
 arch/arm64/Kconfig  |  3 +++
 arch/arm64/include/asm/device.h |  1 +
 arch/arm64/mm/dma-mapping.c | 40 
 3 files changed, 44 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1117421..afb2c08 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -216,6 +216,9 @@ config NEED_DMA_MAP_STATE
 config NEED_SG_DMA_LENGTH
def_bool y
 
+config ARCH_HAS_DMA_SET_COHERENT_MASK
+   def_bool y
+
 config SMP
def_bool y
 
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 243ef25..a57e7bb 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
void *iommu;/* private IOMMU data */
 #endif
bool dma_coherent;
+   u64 parent_dma_mask;
 };
 
 struct pdev_archdata {
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..be3632e 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,31 @@ static int __swiotlb_dma_supported(struct device *hwdev, 
u64 mask)
return 1;
 }
 
+static int __swiotlb_set_dma_mask(struct device *dev, u64 mask)
+{
+   /* device is not DMA capable */
+   if (!dev->dma_mask)
+   return -EIO;
+
+   /* mask is below swiotlb bounce buffer, so fail */
+   if (!swiotlb_dma_supported(dev, mask))
+   return -EIO;
+
+   /*
+* because of the swiotlb, we can return success for
+* larger masks, but need to ensure that bounce buffers
+* are used above parent_dma_mask, so set that as
+* the effective mask.
+*/
+   if (mask > dev->archdata.parent_dma_mask)
+   mask = dev->archdata.parent_dma_mask;
+
+
+   *dev->dma_mask = mask;
+
+   return 0;
+}
+
 static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,
@@ -367,8 +392,23 @@ static struct dma_map_ops swiotlb_dma_ops = {
.sync_sg_for_device = __swiotlb_sync_sg_for_device,
.dma_supported = __swiotlb_dma_supported,
.mapping_error = swiotlb_dma_mapping_error,
+   .set_dma_mask = __swiotlb_set_dma_mask,
 };
 
+int dma_set_coherent_mask(struct device *dev, u64 mask)
+{
+   if (!dma_supported(dev, mask))
+   return -EIO;
+
+   if (get_dma_ops(dev) == _dma_ops &&
+   mask > dev->archdata.parent_dma_mask)
+   mask = dev->archdata.parent_dma_mask;
+
+   dev->coherent_dma_mask = mask;
+   return 0;
+}
+EXPORT_SYMBOL(dma_set_coherent_mask);
+
 static int __init atomic_pool_init(void)
 {
pgprot_t prot = __pgprot(PROT_NORMAL_NC);
-- 
2.1.4

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

[Nikita Yushchenko]

>>> Just a guess, but if the inbound translation windows in the host
>>> bridge are wider than 32-bit, the reason for setting up a single
>>> 32-bit window is probably because that is what the parent bus supports.

I've re-checked rcar-pcie hardware documentation.

It indeed mentions that AXI bus it sits on is 32-bit.


>> Well anyway applying patch similar to your's will fix pcie-rcar + nvme
>> case - thus I don't object :)   But it can break other cases ...
>>
>> But why do you hook at set_dma_mask() and overwrite mask inside, instead
>> of hooking at dma_supported() and rejecting unsupported mask?
>>
>> I think later is better, because it lets drivers to handle unsupported
>> high-dma case, like documented in DMA-API_HOWTO.
> 
> I think the behavior I put in there is required for swiotlb to make
> sense, otherwise you would rely on the driver to handle dma_set_mask()
> failure gracefully with its own bounce buffers (as network and
> scsi drivers do but others don't).
> 
> Having swiotlb or iommu enabled should result in dma_set_mask() always
> succeeding unless the mask is too small to cover the swiotlb
> bounce buffer area or the iommu virtual address space. This behavior
> is particularly important in case the bus address space is narrower
> than 32-bit, as we have to guarantee that the fallback to 32-bit
> DMA always succeeds. There are also a lot of drivers that try to
> set a 64-bit mask but don't implement bounce buffers for streaming
> mappings if that fails, and swiotlb is what we use to make those
> drivers work.
> 
> And yes, the API is a horrible mess.

With my patch applied and thus 32bit dma_mask set for NVMe device, I do
see high addresses passed to dma_map_*() routines and handled by
swiotlb. Thus your statement that behavior "succeed 64bit dma_set_mask()
operation but silently replace mask behind the scene" is required for
swiotlb to be used, does not match reality.

It can be interpreted as a breakage elsewhere, but it's hard to point
particular "root cause". The entire infrastructure to allocate and use
DMA memory is messy.

Still current code does not work, thus fix is needed.

Perhaps need to introduce some generic API to "allocate memory best
suited for DMA to particular device", and fix allocation points (in
drivers, filesystems, etc) to use it. Such an API could try to allocate
area that can be DMAed by hardware, and fallback to other memory that
can be used via swiotlb or other bounce buffer implementation.

But for now, have to stay with dma masks. Will follow-up with a patch
based on your but with coherent mask handling added.

Nikita

Re: [PATCH 1/2] serial: sh-sci: Fix early deassertion of dedicated RTS

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Friday 02 Dec 2016 13:35:10 Geert Uytterhoeven wrote:
> If a UART has dedicated RTS/CTS pins, there are some issues:
> 
> 1. When changing hardware control flow, the new AUTORTS state is not
>immediately reflected in the hardware, but only when RTS is raised.
>However, the serial core doesn't call .set_mctrl() after
>.set_termios(), hence AUTORTS may only become effective when the port
>is closed, and reopened later.
>Note that this problem does not happen when manually using stty to
>change CRTSCTS, as AUTORTS will work fine on next open.
> 
> 2. When hardware control flow is disabled (or AUTORTS is not yet
>effective), changing any serial port configuration deasserts RTS, as
>.set_termios() calls sci_init_pins().

Isn't this still a problem with this patch applied ? Calling sci_set_mctrl() 
should reconfigure the pins properly, but won't there be a short window during 
which the configuration will be wrong ?

> To fix both issues, call .set_mctrl() from .set_termios() when dedicated
> RTS/CTS pins are present, to refresh the AUTORTS or RTS state.
> This is similar to what other drivers supporting AUTORTS do (e.g.
> omap-serial).
> 
> Reported-by: Baumann, Christoph (C.)  (issue 1)
> Fixes: 33f50ffc253854cf ("serial: sh-sci: Fix support for hardware-assisted
> RTS/CTS")
> Signed-off-by: Geert Uytterhoeven 
> ---
> Tested on r8a7791/koelsch with HSCIF1 (GPIO hardware flow control),
> and HSCIF2 and SCIFB0 (dedicated hardware flow control).
> 
> A simple test program (basically "cat" with CRTSCTS configuration
> capability) can be found at https://github.com/geertu/sercat
> 
> Without this patch the following will fail:
> 
>   1. sercat -f /dev/hscif2 &
>  seq 100 120 | sercat -f -w /dev/hscif1 # hangs
> 
>   2. seq 200 220 | sercat -f -w /dev/hscif2 &
>  sercat -f /dev/hscif1 # no data received
> ---
>  drivers/tty/serial/sh-sci.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 91e7dddbf72cd3de..c503db1900f003ed 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2340,6 +2340,10 @@ static void sci_set_termios(struct uart_port *port,
> struct ktermios *termios,
> 
>   serial_port_out(port, SCFCR, ctrl);
>   }
> + if (port->flags & UPF_HARD_FLOW) {
> + /* Refresh (Auto) RTS */
> + sci_set_mctrl(port, port->mctrl);
> + }
> 
>   scr_val |= s->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0);
>   dev_dbg(port->dev, "SCSCR 0x%x\n", scr_val);

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] serial: sh-sci: Fix hang in sci_reset()

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Friday 02 Dec 2016 13:35:11 Geert Uytterhoeven wrote:
> When the .set_termios() callback resets the UART, it first waits until
> all characters in the transmit FIFO have been transmitted, to prevent a
> port configuration change from impacting these characters.
> 
> However, if the previous user of the UART had dedicated RTS/CTS hardware
> flow control enabled, these characters may have been stuck in the FIFO
> due to CTS not being asserted. When the new user opens the port,
> .set_termios() is called while transmission is still disabled, leading
> to an infinite loop:
> 
> NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> 
> This has been observed with SCIFA (on r8a7740/armadillo) and SCIFB (on
> r8a7791/koelsch).
> 
> The issue does not seem to happen when using:
>   - GPIO RTS/CTS hardware flow control,
>   - No hardware flow control,
>   - HSCIF (on r8a7791/koelsch).
> 
> To fix this, wait for the draining of the transmit FIFO only if
> transmission is already enabled.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> To reproduce:
> 
> stty -echo < /dev/scifb0
> stty crtscts < /dev/scifb0
> echo hello > /dev/scifb0  # returns early (wrote to FIFO)
> echo hello > /dev/scifb0  # hangs
> 
>  drivers/tty/serial/sh-sci.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index c503db1900f003ed..db5de80c5399a7bd 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2137,9 +2137,11 @@ static void sci_reset(struct uart_port *port)
>   const struct plat_sci_reg *reg;
>   unsigned int status;
> 
> - do {
> - status = serial_port_in(port, SCxSR);
> - } while (!(status & SCxSR_TEND(port)));
> + if (serial_port_in(port, SCSCR) & SCSCR_TE) {
> + do {
> + status = serial_port_in(port, SCxSR);
> + } while (!(status & SCxSR_TEND(port)));

Won't we still loop forever if the remote side never asserts CTS ?

> + }
> 
>   serial_port_out(port, SCSCR, 0x00); /* TE=0, RE=0, CKE1=0 */

-- 
Regards,

Laurent Pinchart

[PATCH v1.1 19/19] serial: sh-sci: Compute the regshift value for SCI ports

[Laurent Pinchart]

SCI instances found in SH SoCs have different spacing between registers
depending on the SoC. The platform data contains a regshift field that
tells the driver by how many bits to shift the register offset to
compute its address. We can compute the regshift value automatically
based on the memory resource size, there's no need to pass the value
through platform data.

Fix the sh7750 SCI and sh7760 SIM port memory resources length to ensure
proper computation of the regshift value.

Signed-off-by: Laurent Pinchart 
---
 arch/sh/kernel/cpu/sh3/setup-sh770x.c |  1 -
 arch/sh/kernel/cpu/sh4/setup-sh7750.c |  3 +--
 arch/sh/kernel/cpu/sh4/setup-sh7760.c | 10 --
 drivers/tty/serial/sh-sci.c   |  8 +++-
 include/linux/serial_sci.h|  1 -
 5 files changed, 16 insertions(+), 7 deletions(-)

This combines the previous 09/19 and 19/19 patches, with the IRDA hunk split
off.

diff --git a/arch/sh/kernel/cpu/sh3/setup-sh770x.c 
b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
index 592cd9ab30c4..59a88611df55 100644
--- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
+++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
@@ -111,7 +111,6 @@ static struct platform_device rtc_device = {
 static struct plat_sci_port scif0_platform_data = {
.type   = PORT_SCI,
.ops= _sci_port_ops,
-   .regshift   = 1,
 };
 
 static struct resource scif0_resources[] = {
diff --git a/arch/sh/kernel/cpu/sh4/setup-sh7750.c 
b/arch/sh/kernel/cpu/sh4/setup-sh7750.c
index d98a55416306..57d30689204d 100644
--- a/arch/sh/kernel/cpu/sh4/setup-sh7750.c
+++ b/arch/sh/kernel/cpu/sh4/setup-sh7750.c
@@ -39,11 +39,10 @@ static struct platform_device rtc_device = {
 
 static struct plat_sci_port sci_platform_data = {
.type   = PORT_SCI,
-   .regshift   = 2,
 };
 
 static struct resource sci_resources[] = {
-   DEFINE_RES_MEM(0xffe0, 0x100),
+   DEFINE_RES_MEM(0xffe0, 0x20),
DEFINE_RES_IRQ(evt2irq(0x4e0)),
 };
 
diff --git a/arch/sh/kernel/cpu/sh4/setup-sh7760.c 
b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
index 0c0cdfc69dcc..e51fe1734e13 100644
--- a/arch/sh/kernel/cpu/sh4/setup-sh7760.c
+++ b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
@@ -200,12 +200,18 @@ static struct platform_device scif2_device = {
 };
 
 static struct plat_sci_port scif3_platform_data = {
+   /*
+* This is actually a SIM card module serial port, based on an SCI with
+* additional registers. The sh-sci driver doesn't support the SIM port
+* type, declare it as a SCI. Don't declare the additional registers in
+* the memory resource or the driver will compute an incorrect regshift
+* value.
+*/
.type   = PORT_SCI,
-   .regshift   = 2,
 };
 
 static struct resource scif3_resources[] = {
-   DEFINE_RES_MEM(0xfe48, 0x100),
+   DEFINE_RES_MEM(0xfe48, 0x10),
DEFINE_RES_IRQ(evt2irq(0xc00)),
DEFINE_RES_IRQ(evt2irq(0xc20)),
DEFINE_RES_IRQ(evt2irq(0xc40)),
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index a27449fa..50fffa1f5a33 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2572,9 +2572,15 @@ static int sci_init_single(struct platform_device *dev,
 
port->type  = p->type;
port->flags = UPF_FIXED_PORT | UPF_BOOT_AUTOCONF | p->flags;
-   port->regshift  = p->regshift;
port->fifosize  = sci_port->params->fifosize;
 
+   if (port->type == PORT_SCI) {
+   if (sci_port->reg_size >= 0x20)
+   port->regshift = 2;
+   else
+   port->regshift = 1;
+   }
+
/*
 * The UART port needs an IRQ value, so we peg this to the RX IRQ
 * for the multi-IRQ ports, which is where we are primarily
diff --git a/include/linux/serial_sci.h b/include/linux/serial_sci.h
index f9a4526f4ec5..e598eaef3962 100644
--- a/include/linux/serial_sci.h
+++ b/include/linux/serial_sci.h
@@ -56,7 +56,6 @@ struct plat_sci_port {
/*
 * Platform overrides if necessary, defaults otherwise.
 */
-   unsigned char   regshift;
unsigned char   regtype;
 
struct plat_sci_port_ops*ops;
-- 
Regards,

Laurent Pinchart

[PATCH v4 3/4] v4l: vsp1: Repair suspend resume operations for video pipelines

[Kieran Bingham]

When a suspend/resume action is taken, the pipeline is reset and never
reconfigured.

To correct this, we establish a new flag pipe->configured and utilise
this to establish when we write a full configuration set to the current
display list.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drv.c   |  4 ++-
 drivers/media/platform/vsp1/vsp1_pipe.c  |  1 +-
 drivers/media/platform/vsp1/vsp1_pipe.h  |  2 +-
 drivers/media/platform/vsp1/vsp1_video.c | 56 ++---
 4 files changed, 31 insertions(+), 32 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index aa237b48ad55..d596cdead1c1 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -413,6 +413,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
 
 int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned int index)
 {
+   struct vsp1_rwpf *wpf = vsp1->wpf[index];
unsigned int timeout;
u32 status;
 
@@ -429,6 +430,9 @@ int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned int 
index)
usleep_range(1000, 2000);
}
 
+   if (wpf->pipe)
+   wpf->pipe->configured = false;
+
if (!timeout) {
dev_err(vsp1->dev, "failed to reset wpf.%u\n", index);
return -ETIMEDOUT;
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 280ba0804699..c568db193fba 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -216,6 +216,7 @@ void vsp1_pipeline_init(struct vsp1_pipeline *pipe)
 
INIT_LIST_HEAD(>entities);
pipe->state = VSP1_PIPELINE_STOPPED;
+   pipe->configured = false;
 }
 
 /* Must be called with the pipe irqlock held. */
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index ac4ad261..fff122b4874d 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -61,6 +61,7 @@ enum vsp1_pipeline_state {
  * @pipe: the media pipeline
  * @irqlock: protects the pipeline state
  * @state: current state
+ * @configured: true if the pipeline has been set up for video streaming
  * @wq: wait queue to wait for state change completion
  * @frame_end: frame end interrupt handler
  * @lock: protects the pipeline use count and stream count
@@ -86,6 +87,7 @@ struct vsp1_pipeline {
 
spinlock_t irqlock;
enum vsp1_pipeline_state state;
+   bool configured;
wait_queue_head_t wq;
 
void (*frame_end)(struct vsp1_pipeline *pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 938ecc2766ed..414303442e7c 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -355,18 +355,14 @@ static void vsp1_video_frame_end(struct vsp1_pipeline 
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
 }
 
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl)
 {
struct vsp1_entity *entity;
 
/* Determine this pipelines sizes for image partitioning support. */
vsp1_video_pipeline_setup_partitions(pipe);
 
-   /* Prepare the display list. */
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
-   if (!pipe->dl)
-   return -ENOMEM;
-
if (pipe->uds) {
struct vsp1_uds *uds = to_uds(>uds->subdev);
 
@@ -386,13 +382,15 @@ static int vsp1_video_setup_pipeline(struct vsp1_pipeline 
*pipe)
}
 
list_for_each_entry(entity, >entities, list_pipe) {
-   vsp1_entity_route_setup(entity, pipe->dl);
+   vsp1_entity_route_setup(entity, dl);
 
if (entity->ops->configure)
-   entity->ops->configure(entity, pipe, pipe->dl,
+   entity->ops->configure(entity, pipe, dl,
   VSP1_ENTITY_PARAMS_INIT);
}
 
+   pipe->configured = true;
+
return 0;
 }
 
@@ -415,9 +413,16 @@ static void vsp1_video_pipeline_run(struct vsp1_pipeline 
*pipe)
 {
struct vsp1_device *vsp1 = pipe->output->entity.vsp1;
struct vsp1_entity *entity;
+   struct vsp1_dl_list *dl;
 
-   if (!pipe->dl)
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
+   dl = vsp1_dl_list_get(pipe->output->dlm);
+   if (!dl) {
+   dev_err(vsp1->dev, "Failed to obtain a dl list\n");
+   return;
+   }
+
+   if (!pipe->configured)
+   vsp1_video_setup_pipeline(pipe, dl);
 
/*
 * Start with the runtime parameters as the configure operation can
@@ -426,45 +431,43 @@ static void 

[PATCH v4 1/4] v4l: vsp1: Prevent multiple streamon race commencing pipeline early

[Kieran Bingham]

With multiple inputs through the BRU it is feasible for the streams to
race each other at stream-on.

Multiple VIDIOC_STREAMON calls racing each other could have process
N-1 skipping over the pipeline setup section and then start the pipeline
early, if videobuf2 has already enqueued buffers to the driver for
process N but not called the .start_streaming() operation yet

In the case of the video pipelines, this
can present two serious issues.

 1) A null-dereference if the pipe->dl is committed at the same time as
the vsp1_video_setup_pipeline() is processing

 2) A hardware hang, where a display list is committed without having
called vsp1_video_setup_pipeline() first

Repair this issue, by ensuring that only the stream which configures the
pipeline is able to start it.

Signed-off-by: Kieran Bingham 

---

v4:
 - Revert and rework back to v1 implementation style
 - Provide detailed comments on the race

v3:
 - Move 'flag reset' to be inside the vsp1_reset_wpf() function call
 - Tidy up the wpf->pipe reference for the configured flag

To test this race, I have used the vsp-unit-test-0007.sh from Laurent's
VSP-Tests [0] in iteration. Without this patch, failures can be seen be
seen anywhere up to the 150 iterations mark.

With this patch in place, tests have successfully iterated over 1500
loops.

The function affected by this change appears to have been around since
v4.6-rc2-105-g351bbf99f245 and thus could be included in stable trees
from that point forward. The issue may have been prevalent before that
but the solution would need reworking for earlier version.

[0] http://git.ideasonboard.com/renesas/vsp-tests.git
---
 drivers/media/platform/vsp1/vsp1_video.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index e6592b576ca3..f7dc249eb398 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -797,6 +797,7 @@ static int vsp1_video_start_streaming(struct vb2_queue *vq, 
unsigned int count)
 {
struct vsp1_video *video = vb2_get_drv_priv(vq);
struct vsp1_pipeline *pipe = video->rwpf->pipe;
+   bool start_pipeline = false;
unsigned long flags;
int ret;
 
@@ -807,11 +808,23 @@ static int vsp1_video_start_streaming(struct vb2_queue 
*vq, unsigned int count)
mutex_unlock(>lock);
return ret;
}
+
+   start_pipeline = true;
}
 
pipe->stream_count++;
mutex_unlock(>lock);
 
+   /*
+* vsp1_pipeline_ready() is not sufficient to establish that all streams
+* are prepared and the pipeline is configured, as multiple streams
+* can race through streamon with buffers already queued; Therefore we
+* don't even attempt to start the pipeline until the last stream has
+* called through here.
+*/
+   if (!start_pipeline)
+   return 0;
+
spin_lock_irqsave(>irqlock, flags);
if (vsp1_pipeline_ready(pipe))
vsp1_video_pipeline_run(pipe);
-- 
git-series 0.9.1

[PATCH v4 2/4] v4l: vsp1: Move vsp1_video_setup_pipeline()

[Kieran Bingham]

Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.

This commit is just a code move for clarity performing no functional
change.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_video.c | 82 -
 1 file changed, 41 insertions(+), 41 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index f7dc249eb398..938ecc2766ed 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -355,6 +355,47 @@ static void vsp1_video_frame_end(struct vsp1_pipeline 
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
 }
 
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_entity *entity;
+
+   /* Determine this pipelines sizes for image partitioning support. */
+   vsp1_video_pipeline_setup_partitions(pipe);
+
+   /* Prepare the display list. */
+   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
+   if (!pipe->dl)
+   return -ENOMEM;
+
+   if (pipe->uds) {
+   struct vsp1_uds *uds = to_uds(>uds->subdev);
+
+   /* If a BRU is present in the pipeline before the UDS, the alpha
+* component doesn't need to be scaled as the BRU output alpha
+* value is fixed to 255. Otherwise we need to scale the alpha
+* component only when available at the input RPF.
+*/
+   if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
+   uds->scale_alpha = false;
+   } else {
+   struct vsp1_rwpf *rpf =
+   to_rwpf(>uds_input->subdev);
+
+   uds->scale_alpha = rpf->fmtinfo->alpha;
+   }
+   }
+
+   list_for_each_entry(entity, >entities, list_pipe) {
+   vsp1_entity_route_setup(entity, pipe->dl);
+
+   if (entity->ops->configure)
+   entity->ops->configure(entity, pipe, pipe->dl,
+  VSP1_ENTITY_PARAMS_INIT);
+   }
+
+   return 0;
+}
+
 static void vsp1_video_pipeline_run_partition(struct vsp1_pipeline *pipe,
  struct vsp1_dl_list *dl)
 {
@@ -752,47 +793,6 @@ static void vsp1_video_buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(>irqlock, flags);
 }
 
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
-{
-   struct vsp1_entity *entity;
-
-   /* Determine this pipelines sizes for image partitioning support. */
-   vsp1_video_pipeline_setup_partitions(pipe);
-
-   /* Prepare the display list. */
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
-   if (!pipe->dl)
-   return -ENOMEM;
-
-   if (pipe->uds) {
-   struct vsp1_uds *uds = to_uds(>uds->subdev);
-
-   /* If a BRU is present in the pipeline before the UDS, the alpha
-* component doesn't need to be scaled as the BRU output alpha
-* value is fixed to 255. Otherwise we need to scale the alpha
-* component only when available at the input RPF.
-*/
-   if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
-   uds->scale_alpha = false;
-   } else {
-   struct vsp1_rwpf *rpf =
-   to_rwpf(>uds_input->subdev);
-
-   uds->scale_alpha = rpf->fmtinfo->alpha;
-   }
-   }
-
-   list_for_each_entry(entity, >entities, list_pipe) {
-   vsp1_entity_route_setup(entity, pipe->dl);
-
-   if (entity->ops->configure)
-   entity->ops->configure(entity, pipe, pipe->dl,
-  VSP1_ENTITY_PARAMS_INIT);
-   }
-
-   return 0;
-}
-
 static int vsp1_video_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct vsp1_video *video = vb2_get_drv_priv(vq);
-- 
git-series 0.9.1

[PATCH v4 4/4] v4l: vsp1: Remove redundant pipe->dl usage from drm

[Kieran Bingham]

The pipe->dl is used only inside vsp1_du_atomic_flush(), and can be
obtained and stored locally to simplify the code.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c  | 20 ++--
 drivers/media/platform/vsp1/vsp1_pipe.h |  2 --
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index b4b583f7137a..d7ec980300dd 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -220,9 +220,6 @@ void vsp1_du_atomic_begin(struct device *dev)
struct vsp1_pipeline *pipe = >drm->pipe;
 
vsp1->drm->num_inputs = pipe->num_inputs;
-
-   /* Prepare the display list. */
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_begin);
 
@@ -426,10 +423,14 @@ void vsp1_du_atomic_flush(struct device *dev)
struct vsp1_pipeline *pipe = >drm->pipe;
struct vsp1_rwpf *inputs[VSP1_MAX_RPF] = { NULL, };
struct vsp1_entity *entity;
+   struct vsp1_dl_list *dl;
unsigned long flags;
unsigned int i;
int ret;
 
+   /* Prepare the display list. */
+   dl = vsp1_dl_list_get(pipe->output->dlm);
+
/* Count the number of enabled inputs and sort them by Z-order. */
pipe->num_inputs = 0;
 
@@ -484,26 +485,25 @@ void vsp1_du_atomic_flush(struct device *dev)
struct vsp1_rwpf *rpf = to_rwpf(>subdev);
 
if (!pipe->inputs[rpf->entity.index]) {
-   vsp1_dl_list_write(pipe->dl, entity->route->reg,
+   vsp1_dl_list_write(dl, entity->route->reg,
   VI6_DPR_NODE_UNUSED);
continue;
}
}
 
-   vsp1_entity_route_setup(entity, pipe->dl);
+   vsp1_entity_route_setup(entity, dl);
 
if (entity->ops->configure) {
-   entity->ops->configure(entity, pipe, pipe->dl,
+   entity->ops->configure(entity, pipe, dl,
   VSP1_ENTITY_PARAMS_INIT);
-   entity->ops->configure(entity, pipe, pipe->dl,
+   entity->ops->configure(entity, pipe, dl,
   VSP1_ENTITY_PARAMS_RUNTIME);
-   entity->ops->configure(entity, pipe, pipe->dl,
+   entity->ops->configure(entity, pipe, dl,
   VSP1_ENTITY_PARAMS_PARTITION);
}
}
 
-   vsp1_dl_list_commit(pipe->dl);
-   pipe->dl = NULL;
+   vsp1_dl_list_commit(dl);
 
/* Start or stop the pipeline if needed. */
if (!vsp1->drm->num_inputs && pipe->num_inputs) {
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index fff122b4874d..e59bef2653f6 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -108,8 +108,6 @@ struct vsp1_pipeline {
 
struct list_head entities;
 
-   struct vsp1_dl_list *dl;
-
unsigned int div_size;
unsigned int partitions;
struct v4l2_rect partition;
-- 
git-series 0.9.1

[PATCH v4 0/4] v4l: vsp1: Fix suspend/resume and race on M2M pipelines

[Kieran Bingham]

This small patchset helps rework the VSP1 driver to repair an issue on
suspend/resume operations whereby the pipeline does not get reconfigured after
it has been re-initialised following a resume operation.

Along side this, there was an intrinsic race in the vsp1_video_start_streaming()
function whereby multiple streams operating through a BRU, could find themselves
commencing an operation before the pipeline has been configured, or worse -
commencing, just as the pipeline is being configured resulting in a null pointer
dereference on pipe->dl.

Patch [1/4] fixes the multiple stream BRU race
Patch [2/4] is a code move only, with no functional change.
Patch [3/4] fixes the suspend/resume operations for video pipelines by marking
the new pipe configured flag as false, and configuring the pipe
during the vsp1_video_pipeline_run() call.
Patch [4/4] removes the context scoped 'pipe->dl' from vsp1_drm.c which is only
used in a single function

v4:
 - Rework and separate out the BRU race back to v1 style implementation
 - Split BRU race and Suspend Resume fixes into separate commits.

v3:
 - Move configured=false from vsp1_device_init to vsp1_reset_wpf()
 - Clean up flag dereferencing with a local struct *

v2:
 - Refactor video pipeline configuration implementation to solve both suspend
   resume and the VSP BRU race in a single change

v1:
 - Original pipeline configuration rework

Kieran Bingham (4):
  v4l: vsp1: Prevent multiple streamon race commencing pipeline early
  v4l: vsp1: Move vsp1_video_setup_pipeline()
  v4l: vsp1: Repair suspend resume operations for video pipelines
  v4l: vsp1: Remove redundant pipe->dl usage from drm

 drivers/media/platform/vsp1/vsp1_drm.c   |  20 ++--
 drivers/media/platform/vsp1/vsp1_drv.c   |   4 +-
 drivers/media/platform/vsp1/vsp1_pipe.c  |   1 +-
 drivers/media/platform/vsp1/vsp1_pipe.h  |   4 +-
 drivers/media/platform/vsp1/vsp1_video.c | 133 
 5 files changed, 86 insertions(+), 76 deletions(-)

base-commit: 16b6839d4e6f0c3fe6d5db2b4c90fb39dabc8640
-- 
git-series 0.9.1

[PATCH v1.1 08/19] serial: sh-sci: Fix register offsets for the IRDA serial port

[Laurent Pinchart]

Even though most of its registers are 8-bit wide, the IRDA has two
16-bit registers that make it a 16-bit peripheral and not a 8-bit
peripheral with addresses shifted by one. Fix the registers offset in
the driver and the platform data regshift value.

Signed-off-by: Laurent Pinchart 
---
 arch/sh/kernel/cpu/sh3/setup-sh770x.c |  1 -
 drivers/tty/serial/sh-sci.c   | 17 -
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/sh/kernel/cpu/sh3/setup-sh770x.c 
b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
index e1e54258b822..592cd9ab30c4 100644
--- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
+++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
@@ -157,7 +157,6 @@ static struct platform_device scif1_device = {
 static struct plat_sci_port scif2_platform_data = {
.type   = PORT_IRDA,
.ops= _sci_port_ops,
-   .regshift   = 1,
 };
 
 static struct resource scif2_resources[] = {
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 8c58c43fc85d..1eb91ba43b2e 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -193,18 +193,17 @@ static const struct plat_sci_reg 
sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
},
 
/*
-* Common definitions for legacy IrDA ports, dependent on
-* regshift value.
+* Common definitions for legacy IrDA ports.
 */
[SCIx_IRDA_REGTYPE] = {
[SCSMR] = { 0x00,  8 },
-   [SCBRR] = { 0x01,  8 },
-   [SCSCR] = { 0x02,  8 },
-   [SCxTDR]= { 0x03,  8 },
-   [SCxSR] = { 0x04,  8 },
-   [SCxRDR]= { 0x05,  8 },
-   [SCFCR] = { 0x06,  8 },
-   [SCFDR] = { 0x07, 16 },
+   [SCBRR] = { 0x02,  8 },
+   [SCSCR] = { 0x04,  8 },
+   [SCxTDR]= { 0x06,  8 },
+   [SCxSR] = { 0x08,  8 },
+   [SCxRDR]= { 0x0a,  8 },
+   [SCFCR] = { 0x0c,  8 },
+   [SCFDR] = { 0x0e, 16 },
[SCTFDR]= sci_reg_invalid,
[SCRFDR]= sci_reg_invalid,
[SCSPTR]= sci_reg_invalid,
-- 
Regards,

Laurent Pinchart

[PATCH 1/4] ARM: shmobile: defconfig: Enable CONFIG_VIDEO_ADV7604

[Simon Horman]

From: Niklas Söderlund 

The adv7612 is used on Gen2 boards (Lager, Koelsch and Gose) for HDMI
input. Enable support for this chip in shmobile_defconfig.

Signed-off-by: Niklas Söderlund 
Signed-off-by: Simon Horman 
---
 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 1b0f8ae36fb3..98e9ce66740d 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -145,6 +145,7 @@ CONFIG_VIDEO_RENESAS_JPU=y
 CONFIG_VIDEO_RENESAS_VSP1=y
 # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
 CONFIG_VIDEO_ADV7180=y
+CONFIG_VIDEO_ADV7604=y
 CONFIG_VIDEO_ML86V7667=y
 CONFIG_DRM=y
 CONFIG_DRM_I2C_ADV7511=y
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 14/16] arm64: dts: r8a7796: salvator-x: Enable EthernetAVB

[Simon Horman]

From: Laurent Pinchart 

Signed-off-by: Laurent Pinchart 
[geert: Add pinctrl]
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 32 ++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 38bde9de3250..c7f40f8f3169 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -18,6 +18,7 @@
 
aliases {
serial0 = 
+   ethernet0 = 
};
 
chosen {
@@ -107,6 +108,11 @@
pinctrl-0 = <_clk_pins>;
pinctrl-names = "default";
 
+   avb_pins: avb {
+   groups = "avb_mdc";
+   function = "avb";
+   };
+
scif2_pins: scif2 {
groups = "scif2_data_a";
function = "scif2";
@@ -158,6 +164,32 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   renesas,no-ether-link;
+   phy-handle = <>;
+   status = "okay";
+
+   phy0: ethernet-phy@0 {
+   rxc-skew-ps = <900>;
+   rxdv-skew-ps = <0>;
+   rxd0-skew-ps = <0>;
+   rxd1-skew-ps = <0>;
+   rxd2-skew-ps = <0>;
+   rxd3-skew-ps = <0>;
+   txc-skew-ps = <900>;
+   txen-skew-ps = <0>;
+   txd0-skew-ps = <0>;
+   txd1-skew-ps = <0>;
+   txd2-skew-ps = <0>;
+   txd3-skew-ps = <0>;
+   reg = <0>;
+   interrupt-parent = <>;
+   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
 _clk {
clock-frequency = <1666>;
 };
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 3/4] ARM: shmobile: defconfig: Enable r8a774[35] SoCs

[Simon Horman]

Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.

Signed-off-by: Simon Horman 
Acked-by: Geert Uytterhoeven 
---
 arch/arm/configs/shmobile_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index b66e17aec058..760688aa5c79 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -14,6 +14,8 @@ CONFIG_ARCH_EMEV2=y
 CONFIG_ARCH_R7S72100=y
 CONFIG_ARCH_R8A73A4=y
 CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7743=y
+CONFIG_ARCH_R8A7745=y
 CONFIG_ARCH_R8A7778=y
 CONFIG_ARCH_R8A7779=y
 CONFIG_ARCH_R8A7790=y
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 16/16] arm64: dts: r8a7795: Add PWM support

[Simon Horman]

From: Laurent Pinchart 

Add the 7 PWM channels to the r8a7795 device tree, in the disabled
state.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 63 
 1 file changed, 63 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 3fe7e0af5989..972e379c0596 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -894,6 +894,69 @@
status = "disabled";
};
 
+   pwm0: pwm@e6e3 {
+   compatible = "renesas,pwm-r8a7795", "renesas,pwm-rcar";
+   reg = <0 0xe6e3 0 0x8>;
+   clocks = < CPG_MOD 523>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #pwm-cells = <2>;
+   status = "disabled";
+   };
+
+   pwm1: pwm@e6e31000 {
+   compatible = "renesas,pwm-r8a7795", "renesas,pwm-rcar";
+   reg = <0 0xe6e31000 0 0x8>;
+   clocks = < CPG_MOD 523>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #pwm-cells = <2>;
+   status = "disabled";
+   };
+
+   pwm2: pwm@e6e32000 {
+   compatible = "renesas,pwm-r8a7795", "renesas,pwm-rcar";
+   reg = <0 0xe6e32000 0 0x8>;
+   clocks = < CPG_MOD 523>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #pwm-cells = <2>;
+   status = "disabled";
+   };
+
+   pwm3: pwm@e6e33000 {
+   compatible = "renesas,pwm-r8a7795", "renesas,pwm-rcar";
+   reg = <0 0xe6e33000 0 0x8>;
+   clocks = < CPG_MOD 523>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #pwm-cells = <2>;
+   status = "disabled";
+   };
+
+   pwm4: pwm@e6e34000 {
+   compatible = "renesas,pwm-r8a7795", "renesas,pwm-rcar";
+   reg = <0 0xe6e34000 0 0x8>;
+   clocks = < CPG_MOD 523>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #pwm-cells = <2>;
+   status = "disabled";
+   };
+
+   pwm5: pwm@e6e35000 {
+   compatible = "renesas,pwm-r8a7795", "renesas,pwm-rcar";
+   reg = <0 0xe6e35000 0 0x8>;
+   clocks = < CPG_MOD 523>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #pwm-cells = <2>;
+   status = "disabled";
+   };
+
+   pwm6: pwm@e6e36000 {
+   compatible = "renesas,pwm-r8a7795", "renesas,pwm-rcar";
+   reg = <0 0xe6e36000 0 0x8>;
+   clocks = < CPG_MOD 523>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   #pwm-cells = <2>;
+   status = "disabled";
+   };
+
rcar_sound: sound@ec50 {
/*
 * #sound-dai-cells is required
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 15/16] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes

[Simon Horman]

Use recently added R-Car Gen 3 fallback binding for msiof nodes in
DT for r8a7796 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7796 and the
fallback binding for R-Car Gen 3.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index d4beb15b076a..eb446d966621 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -485,7 +485,8 @@
};
 
msiof0: spi@e6e9 {
-   compatible = "renesas,msiof-r8a7796";
+   compatible = "renesas,msiof-r8a7796",
+"renesas,rcar-gen3-msiof";
reg = <0 0xe6e9 0 0x0064>;
interrupts = ;
clocks = < CPG_MOD 211>;
@@ -499,7 +500,8 @@
};
 
msiof1: spi@e6ea {
-   compatible = "renesas,msiof-r8a7796";
+   compatible = "renesas,msiof-r8a7796",
+"renesas,rcar-gen3-msiof";
reg = <0 0xe6ea 0 0x0064>;
interrupts = ;
clocks = < CPG_MOD 210>;
@@ -513,7 +515,8 @@
};
 
msiof2: spi@e6c0 {
-   compatible = "renesas,msiof-r8a7796";
+   compatible = "renesas,msiof-r8a7796",
+"renesas,rcar-gen3-msiof";
reg = <0 0xe6c0 0 0x0064>;
interrupts = ;
clocks = < CPG_MOD 209>;
@@ -526,7 +529,8 @@
};
 
msiof3: spi@e6c1 {
-   compatible = "renesas,msiof-r8a7796";
+   compatible = "renesas,msiof-r8a7796",
+"renesas,rcar-gen3-msiof";
reg = <0 0xe6c1 0 0x0064>;
interrupts = ;
clocks = < CPG_MOD 208>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 03/16] arm64: dts: r8a7796: Add CAN support

[Simon Horman]

From: Chris Paterson 

Adds CAN controller nodes for r8a7796.

Based on a patch for r8a7795 by Ramesh Shanmugasundaram.

Signed-off-by: Chris Paterson 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Marc Kleine-Budde 
Acked-by: Rob Herring 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index c0f9ced8df7e..a97ef2e7202c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -367,6 +367,36 @@
status = "disabled";
};
 
+   can0: can@e6c3 {
+   compatible = "renesas,can-r8a7796",
+"renesas,rcar-gen3-can";
+   reg = <0 0xe6c3 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 916>,
+  < CPG_CORE R8A7796_CLK_CANFD>,
+  <_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   assigned-clocks = < CPG_CORE R8A7796_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   can1: can@e6c38000 {
+   compatible = "renesas,can-r8a7796",
+"renesas,rcar-gen3-can";
+   reg = <0 0xe6c38000 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 915>,
+  < CPG_CORE R8A7796_CLK_CANFD>,
+  <_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   assigned-clocks = < CPG_CORE R8A7796_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a7796",
 "renesas,rcar-gen3-scif", "renesas,scif";
-- 
2.7.0.rc3.207.g0ac5344

[GIT PULL] Renesas ARM Based SoC DT Updates for v4.11

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC DT updates for v4.11.


The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-dt-for-v4.11

for you to fetch changes up to 654450baf2afba86cf328e1849ccac61ec4630af:

  ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes 
(2017-01-03 10:47:05 +0100)


Renesas ARM Based SoC DT Updates for v4.11

* Add da9063 PMIC device node for system restart to gose board
* Add device node for PRR to SoCs where it was missing
* Move RST node before SYSC node where it was incorrectly placed
* Use Gen 2 fallback bindings for I2C, IIC, MSIOf and USB2 phy
* Use SoC-specific compat string for MMCIF where it was missing


Geert Uytterhoeven (5):
  ARM: dts: r8a7743: Move RST node before SYSC node
  ARM: dts: r8a7745: Move RST node before SYSC node
  ARM: dts: r8a7743: Add device node for PRR
  ARM: dts: r8a7745: Add device node for PRR
  ARM: dts: gose: Add da9063 PMIC device node for system restart

Simon Horman (20):
  ARM: dts: r8a73a4: Use SoC-specific compat string for mmcif
  ARM: dts: r8a7778: Use SoC-specific compat string for mmcif
  ARM: dts: sh73a0: Use SoC-specific compat string for mmcif
  ARM: dts: r8a7790: Use renesas,rcar-gen2-usb-phy fallback binding
  ARM: dts: r8a7791: Use renesas,rcar-gen2-usb-phy fallback binding
  ARM: dts: r8a7794: Use renesas,rcar-gen2-usb-phy fallback binding
  ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
  ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes
  ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
  ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
  ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes
  ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes
  ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
  ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for iic nodes
  ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for iic nodes
  ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for iic nodes
  ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for iic nodes
  ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for msiof nodes
  ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for msiof nodes
  ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes

 arch/arm/boot/dts/r8a73a4.dtsi |  4 ++--
 arch/arm/boot/dts/r8a7743.dtsi | 13 +
 arch/arm/boot/dts/r8a7745.dtsi | 13 +
 arch/arm/boot/dts/r8a7778.dtsi | 10 +-
 arch/arm/boot/dts/r8a7779.dtsi |  8 
 arch/arm/boot/dts/r8a7790.dtsi | 35 ++-
 arch/arm/boot/dts/r8a7791.dtsi | 33 -
 arch/arm/boot/dts/r8a7792.dtsi | 24 
 arch/arm/boot/dts/r8a7793-gose.dts | 21 +
 arch/arm/boot/dts/r8a7793.dtsi | 21 -
 arch/arm/boot/dts/r8a7794.dtsi | 21 -
 arch/arm/boot/dts/sh73a0.dtsi  |  2 +-
 12 files changed, 133 insertions(+), 72 deletions(-)

[PATCH 04/16] arm64: dts: r8a7796: Add CAN FD support

[Simon Horman]

From: Chris Paterson 

Adds CAN FD controller node for r8a7796.

Based on a patch for r8a7795 by Ramesh Shanmugasundaram.

Signed-off-by: Chris Paterson 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Marc Kleine-Budde 
Acked-by: Rob Herring 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index a97ef2e7202c..a37bb5eb062c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -397,6 +397,30 @@
status = "disabled";
};
 
+   canfd: can@e66c {
+   compatible = "renesas,r8a7796-canfd",
+"renesas,rcar-gen3-canfd";
+   reg = <0 0xe66c 0 0x8000>;
+   interrupts = ,
+  ;
+   clocks = < CPG_MOD 914>,
+  < CPG_CORE R8A7796_CLK_CANFD>,
+  <_clk>;
+   clock-names = "fck", "canfd", "can_clk";
+   assigned-clocks = < CPG_CORE R8A7796_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   status = "disabled";
+
+   channel0 {
+   status = "disabled";
+   };
+
+   channel1 {
+   status = "disabled";
+   };
+   };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a7796",
 "renesas,rcar-gen3-scif", "renesas,scif";
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 11/16] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 3 fallback binding for i2c nodes in
DT for r8a7796 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7796 and the
fallback binding for R-Car Gen 3.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index a37bb5eb062c..26a0506e3013 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -269,7 +269,8 @@
i2c0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7796";
+   compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe650 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 931>;
@@ -284,7 +285,8 @@
i2c1: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7796";
+   compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 930>;
@@ -299,7 +301,8 @@
i2c2: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7796";
+   compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe651 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 929>;
@@ -314,7 +317,8 @@
i2c3: i2c@e66d {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7796";
+   compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66d 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 928>;
@@ -328,7 +332,8 @@
i2c4: i2c@e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7796";
+   compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66d8000 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 927>;
@@ -342,7 +347,8 @@
i2c5: i2c@e66e {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7796";
+   compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66e 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 919>;
@@ -356,7 +362,8 @@
i2c6: i2c@e66e8000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7796";
+   compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66e8000 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 918>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 09/16] arm64: dts: r8a7795: Use Gen 3 fallback compat string for PCIE

[Simon Horman]

Use recently added en 3 fallback compat string for PCIE
in r8a7795 DT.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 7e21491c6510..91a797b18c11 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1279,7 +1279,8 @@
};
 
pciec0: pcie@fe00 {
-   compatible = "renesas,pcie-r8a7795";
+   compatible = "renesas,pcie-r8a7795",
+"renesas,pcie-rcar-gen3";
reg = <0 0xfe00 0 0x8>;
#address-cells = <3>;
#size-cells = <2>;
@@ -1304,7 +1305,8 @@
};
 
pciec1: pcie@ee80 {
-   compatible = "renesas,pcie-r8a7795";
+   compatible = "renesas,pcie-r8a7795",
+"renesas,pcie-rcar-gen3";
reg = <0 0xee80 0 0x8>;
#address-cells = <3>;
#size-cells = <2>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 13/16] arm64: dts: renesas: r8a7796: Add EthernetAVB instance

[Simon Horman]

From: Laurent Pinchart 

Signed-off-by: Laurent Pinchart 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 43 
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 26a0506e3013..d4beb15b076a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -428,6 +428,49 @@
};
};
 
+   avb: ethernet@e680 {
+   compatible = "renesas,etheravb-r8a7796",
+"renesas,etheravb-rcar-gen3";
+   reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   interrupt-names = "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14", "ch15",
+ "ch16", "ch17", "ch18", "ch19",
+ "ch20", "ch21", "ch22", "ch23",
+ "ch24";
+   clocks = < CPG_MOD 812>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   phy-mode = "rgmii-id";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a7796",
 "renesas,rcar-gen3-scif", "renesas,scif";
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 05/16] arm64: renesas: r8a7796/salvator-x: Add board part number to DT bindings

[Simon Horman]

From: Geert Uytterhoeven 

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 253bf9b86690..c9502634316d 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -75,7 +75,7 @@ Boards:
 compatible = "renesas,rskrza1", "renesas,r7s72100"
   - Salvator-X (RTP0RC7795SIPB0010S)
 compatible = "renesas,salvator-x", "renesas,r8a7795";
-  - Salvator-X
+  - Salvator-X (RTP0RC7796SIPB0011S)
 compatible = "renesas,salvator-x", "renesas,r8a7796";
   - SILK (RTP0RC7794LCB00011S)
 compatible = "renesas,silk", "renesas,r8a7794"
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 06/16] arm64: dts: r8a7795: Use renesas,rcar-gen3-usb2-phy fallback binding

[Simon Horman]

A fallback binding for the Renesas R-Car Gen3 for USB2.0 PHY driver was
added by commit cde7bc367f09 ("phy: rcar-gen3-usb2: add fallback binding").
This patch makes use of this binding in the DT for the r8a7795 SoC.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index bbf594bce930..2c076c21d7fa 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1146,7 +1146,8 @@
};
 
usb2_phy0: usb-phy@ee080200 {
-   compatible = "renesas,usb2-phy-r8a7795";
+   compatible = "renesas,usb2-phy-r8a7795",
+"renesas,rcar-gen3-usb2-phy";
reg = <0 0xee080200 0 0x700>;
interrupts = ;
clocks = < CPG_MOD 703>;
@@ -1156,7 +1157,8 @@
};
 
usb2_phy1: usb-phy@ee0a0200 {
-   compatible = "renesas,usb2-phy-r8a7795";
+   compatible = "renesas,usb2-phy-r8a7795",
+"renesas,rcar-gen3-usb2-phy";
reg = <0 0xee0a0200 0 0x700>;
clocks = < CPG_MOD 702>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -1165,7 +1167,8 @@
};
 
usb2_phy2: usb-phy@ee0c0200 {
-   compatible = "renesas,usb2-phy-r8a7795";
+   compatible = "renesas,usb2-phy-r8a7795",
+"renesas,rcar-gen3-usb2-phy";
reg = <0 0xee0c0200 0 0x700>;
clocks = < CPG_MOD 701>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 2/4] ARM: shmobile: defconfig: Enable CMA for DMA

[Simon Horman]

From: Niklas Söderlund 

To be able to use VIN with larger frame sizes CMA memory are needed for
DMA. If this is not enabled trying to capture large frames can result in
errors such as:

rcar-vin e6ef.video: dma_alloc_coherent of size 8388608 failed

A CMA area of 64MB are needed for v4l2-compliance to pass on all formats
on the largest possible frame size of 2048x2048.

Signed-off-by: Niklas Söderlund 
Signed-off-by: Simon Horman 
---
 arch/arm/configs/shmobile_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 98e9ce66740d..b66e17aec058 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -33,6 +33,7 @@ CONFIG_HAVE_ARM_ARCH_TIMER=y
 CONFIG_NR_CPUS=8
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
+CONFIG_CMA=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
@@ -58,6 +59,8 @@ CONFIG_CAN_RCAR=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_DMA_CMA=y
+CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_SIMPLE_PM_BUS=y
 CONFIG_MTD=y
 CONFIG_MTD_BLOCK=y
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 4/4] ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

[Simon Horman]

Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.

Signed-off-by: Simon Horman 
Acked-by: Geert Uytterhoeven 
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index b01a43851294..f084a0a928b8 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -87,6 +87,8 @@ CONFIG_ARCH_EMEV2=y
 CONFIG_ARCH_R7S72100=y
 CONFIG_ARCH_R8A73A4=y
 CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7743=y
+CONFIG_ARCH_R8A7745=y
 CONFIG_ARCH_R8A7778=y
 CONFIG_ARCH_R8A7779=y
 CONFIG_ARCH_R8A7790=y
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 07/16] arm64: dts: r8a7795: add sound CTU support

[Simon Horman]

From: Kuninori Morimoto 

This patch adds CTU (= Channel Transfer Unit) support which is needed
to sound mixing.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  1 +
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 13 +
 2 files changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index bcaf4008d32d..82a269a4f10d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -412,6 +412,7 @@
 < CPG_MOD 1026>, < CPG_MOD 1027>,
 < CPG_MOD 1028>, < CPG_MOD 1029>,
 < CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
 < CPG_MOD 1019>, < CPG_MOD 1018>,
 <_clk_a>, <>,
 <_clk_c>,
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 2c076c21d7fa..e09f5b7b874a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -919,6 +919,7 @@
 < CPG_MOD 1026>, < CPG_MOD 1027>,
 < CPG_MOD 1028>, < CPG_MOD 1029>,
 < CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
 < CPG_MOD 1019>, < CPG_MOD 1018>,
 <_clk_a>, <_clk_b>,
 <_clk_c>,
@@ -930,6 +931,7 @@
  "src.9", "src.8", "src.7", "src.6",
  "src.5", "src.4", "src.3", "src.2",
  "src.1", "src.0",
+ "ctu.1", "ctu.0",
  "dvc.0", "dvc.1",
  "clk_a", "clk_b", "clk_c", "clk_i";
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -946,6 +948,17 @@
};
};
 
+   rcar_sound,ctu {
+   ctu00: ctu-0 { };
+   ctu01: ctu-1 { };
+   ctu02: ctu-2 { };
+   ctu03: ctu-3 { };
+   ctu10: ctu-4 { };
+   ctu11: ctu-5 { };
+   ctu12: ctu-6 { };
+   ctu13: ctu-7 { };
+   };
+
rcar_sound,src {
src0: src-0 {
interrupts = ;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 08/16] arm64: dts: r8a7795: add sound MIX support

[Simon Horman]

From: Kuninori Morimoto 

This patch adds MIX (= Mixer) support.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 +
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 82a269a4f10d..7a8986edcdc0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -413,6 +413,7 @@
 < CPG_MOD 1028>, < CPG_MOD 1029>,
 < CPG_MOD 1030>, < CPG_MOD 1031>,
 < CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
 < CPG_MOD 1019>, < CPG_MOD 1018>,
 <_clk_a>, <>,
 <_clk_c>,
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e09f5b7b874a..7e21491c6510 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -920,6 +920,7 @@
 < CPG_MOD 1028>, < CPG_MOD 1029>,
 < CPG_MOD 1030>, < CPG_MOD 1031>,
 < CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
 < CPG_MOD 1019>, < CPG_MOD 1018>,
 <_clk_a>, <_clk_b>,
 <_clk_c>,
@@ -931,6 +932,7 @@
  "src.9", "src.8", "src.7", "src.6",
  "src.5", "src.4", "src.3", "src.2",
  "src.1", "src.0",
+ "mix.1", "mix.0",
  "ctu.1", "ctu.0",
  "dvc.0", "dvc.1",
  "clk_a", "clk_b", "clk_c", "clk_i";
@@ -948,6 +950,11 @@
};
};
 
+   rcar_sound,mix {
+   mix0: mix-0 { };
+   mix1: mix-1 { };
+   };
+
rcar_sound,ctu {
ctu00: ctu-0 { };
ctu01: ctu-1 { };
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 10/16] arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 3 fallback binding for i2c nodes in
DT for r8a7795 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7795 and the
fallback binding for R-Car Gen 3.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 91a797b18c11..3fe7e0af5989 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -792,7 +792,8 @@
i2c0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7795";
+   compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe650 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 931>;
@@ -806,7 +807,8 @@
i2c1: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7795";
+   compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 930>;
@@ -820,7 +822,8 @@
i2c2: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7795";
+   compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe651 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 929>;
@@ -834,7 +837,8 @@
i2c3: i2c@e66d {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7795";
+   compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66d 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 928>;
@@ -848,7 +852,8 @@
i2c4: i2c@e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7795";
+   compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66d8000 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 927>;
@@ -862,7 +867,8 @@
i2c5: i2c@e66e {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7795";
+   compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66e 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 919>;
@@ -876,7 +882,8 @@
i2c6: i2c@e66e8000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7795";
+   compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66e8000 0 0x40>;
interrupts = ;
clocks = < CPG_MOD 918>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 01/16] arm64: dts: r8a7796: Add all MSIOF nodes

[Simon Horman]

From: Geert Uytterhoeven 

Add the device nodes for all MSIOF SPI controllers.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 54 
 1 file changed, 54 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 28ba59a00cd8..4bf8e14956fe 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -373,6 +373,60 @@
status = "disabled";
};
 
+   msiof0: spi@e6e9 {
+   compatible = "renesas,msiof-r8a7796";
+   reg = <0 0xe6e9 0 0x0064>;
+   interrupts = ;
+   clocks = < CPG_MOD 211>;
+   dmas = < 0x41>, < 0x40>,
+  < 0x41>, < 0x40>;
+   dma-names = "tx", "rx";
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   msiof1: spi@e6ea {
+   compatible = "renesas,msiof-r8a7796";
+   reg = <0 0xe6ea 0 0x0064>;
+   interrupts = ;
+   clocks = < CPG_MOD 210>;
+   dmas = < 0x43>, < 0x42>,
+  < 0x43>, < 0x42>;
+   dma-names = "tx", "rx";
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   msiof2: spi@e6c0 {
+   compatible = "renesas,msiof-r8a7796";
+   reg = <0 0xe6c0 0 0x0064>;
+   interrupts = ;
+   clocks = < CPG_MOD 209>;
+   dmas = < 0x45>, < 0x44>;
+   dma-names = "tx", "rx";
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   msiof3: spi@e6c1 {
+   compatible = "renesas,msiof-r8a7796";
+   reg = <0 0xe6c1 0 0x0064>;
+   interrupts = ;
+   clocks = < CPG_MOD 208>;
+   dmas = < 0x47>, < 0x46>;
+   dma-names = "tx", "rx";
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a7796",
 "renesas,rcar-dmac";
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCHv3 2/4] v4l: vsp1: Refactor video pipeline configuration

[Kieran Bingham]

Hi Laurent,

I've been reworking this series to split things out and adapt for the
comments you've provided, but I have the following queries outstanding:

On 15/12/16 11:50, Kieran Bingham wrote:
> Hi Laurent,
> 
> On 14/12/16 16:30, Laurent Pinchart wrote:
>> Hi Kieran,
>>
>> Thank you for the patch.
>>
>> On Tuesday 13 Dec 2016 17:59:42 Kieran Bingham wrote:
>>> With multiple inputs through the BRU it is feasible for the streams to
>>> race each other at stream-on.
>>
>> Could you please explain the race condition in the commit message ? The 
>> issue 
>> is that multiple VIDIOC_STREAMON calls racing each other could have process 
>> N-1 skipping over the pipeline setup section and then start the pipeline, if 
>> videobuf2 has already enqueued buffers to the driver for process N but not 
>> called the .start_streaming() operation yet.
>>
>>> In the case of the video pipelines, this
>>> can present two serious issues.
>>>
>>>  1) A null-dereference if the pipe->dl is committed at the same time as
>>> the vsp1_video_setup_pipeline() is processing
>>>
>>>  2) A hardware hang, where a display list is committed without having
>>> called vsp1_video_setup_pipeline() first
>>>
>>> Along side these race conditions, the work done by
>>> vsp1_video_setup_pipeline() is undone by the re-initialisation during a
>>> suspend resume cycle, and an active pipeline does not attempt to
>>> reconfigure the correct routing and init parameters for the entities.
>>>
>>> To repair all of these issues, we can move the call to a conditional
>>> inside vsp1_video_pipeline_run() and ensure that this can only be called
>>> on the last stream which calls into vsp1_video_start_streaming()
>>>
>>> As a convenient side effect of this, by specifying that the
>>> configuration has been lost during suspend/resume actions - the
>>> vsp1_video_pipeline_run() call can re-initialise pipelines when
>>> necessary thus repairing resume actions for active m2m pipelines.
>>>
>>> Signed-off-by: Kieran Bingham 
>>>
>>> ---
>>> v3:
>>>  - Move 'flag reset' to be inside the vsp1_reset_wpf() function call
>>>  - Tidy up the wpf->pipe reference for the configured flag
>>>
>>>  drivers/media/platform/vsp1/vsp1_drv.c   |  4 
>>>  drivers/media/platform/vsp1/vsp1_pipe.c  |  1 +
>>>  drivers/media/platform/vsp1/vsp1_pipe.h  |  2 ++
>>>  drivers/media/platform/vsp1/vsp1_video.c | 20 +---
>>>  4 files changed, 16 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
>>> b/drivers/media/platform/vsp1/vsp1_drv.c index 57c713a4e1df..1dc3726c4e83
>>> 100644
>>> --- a/drivers/media/platform/vsp1/vsp1_drv.c
>>> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
>>> @@ -413,6 +413,7 @@ static int vsp1_create_entities(struct vsp1_device
>>> *vsp1)
>>>
>>>  int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned int index)
>>>  {
>>> +   struct vsp1_rwpf *wpf = vsp1->wpf[index];
>>> unsigned int timeout;
>>> u32 status;
>>>
>>> @@ -429,6 +430,9 @@ int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned
>>> int index) usleep_range(1000, 2000);
>>> }
>>>
>>> +   if (wpf->pipe)
>>> +   wpf->pipe->configured = false;
>>> +
>>> if (!timeout) {
>>> dev_err(vsp1->dev, "failed to reset wpf.%u\n", index);
>>> return -ETIMEDOUT;
>>> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
>>> b/drivers/media/platform/vsp1/vsp1_pipe.c index 756ca4ea7668..7ddf862ee403
>>> 100644
>>> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
>>> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
>>> @@ -208,6 +208,7 @@ void vsp1_pipeline_init(struct vsp1_pipeline *pipe)
>>>
>>> INIT_LIST_HEAD(>entities);
>>> pipe->state = VSP1_PIPELINE_STOPPED;
>>> +   pipe->configured = false;
>>>  }
>>>
>>>  /* Must be called with the pipe irqlock held. */
>>> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
>>> b/drivers/media/platform/vsp1/vsp1_pipe.h index ac4ad261..0743b9fcb655
>>> 100644
>>> --- a/drivers/media/platform/vsp1/vsp1_pipe.h
>>> +++ b/drivers/media/platform/vsp1/vsp1_pipe.h
>>> @@ -61,6 +61,7 @@ enum vsp1_pipeline_state {
>>>   * @pipe: the media pipeline
>>>   * @irqlock: protects the pipeline state
>>>   * @state: current state
>>> + * @configured: determines routing configuration active on cell.
>>
>> I'm not sure to understand that. How about "true if the pipeline has been 
>> set 
>> up" ? Or maybe "true if the pipeline has been set up for video streaming" as 
>> it only applies to pipelines handled through the V4L2 API ?
> 
> 
> Yes, Reading it now - I have no idea what context I was writing that in.
> I hope it was late and I was tired ... otherwise I have no excuse :D
> 
> 
> 
>>>   * @wq: wait queue to wait for state change completion
>>>   * @frame_end: frame end interrupt handler
>>>   * @lock: protects the pipeline use count and stream count
>>> @@ -86,6 +87,7 @@ struct vsp1_pipeline {
>>>
>>> spinlock_t irqlock;
>>> enum 

[GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.11

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM64 based SoC DT updates for v4.11.

This is based on v4.10-rc2 as v4.10-rc1 does not compile using
the defconfig.


The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:

  Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-arm64-dt-for-v4.11

for you to fetch changes up to b2b9443beee5017ebdb3f2be9ef472c73d260481:

  arm64: dts: r8a7795: Add PWM support (2017-01-04 10:00:44 +0100)


Renesas ARM64 Based SoC DT Updates for v4.11

* Add PWM, and sound MIX and CTU support to r8a7795 SoC
* Add CAN, CAN FD and all MSIOF nodes to r8a7796 SoC
* Use Gen 3 fallback binding for i2c, msiof, PCIE and USB2 phy
* Enable Ethernet and 4 GiB memory on r8a7796/salvator-x board
* Add r8a7796/salvator-x board part number to bindings


Chris Paterson (3):
  arm64: dts: r8a7796: Add CAN external clock support
  arm64: dts: r8a7796: Add CAN support
  arm64: dts: r8a7796: Add CAN FD support

Geert Uytterhoeven (2):
  arm64: dts: r8a7796: Add all MSIOF nodes
  arm64: renesas: r8a7796/salvator-x: Add board part number to DT bindings

Kuninori Morimoto (2):
  arm64: dts: r8a7795: add sound CTU support
  arm64: dts: r8a7795: add sound MIX support

Laurent Pinchart (3):
  arm64: dts: renesas: r8a7796: Add EthernetAVB instance
  arm64: dts: r8a7796: salvator-x: Enable EthernetAVB
  arm64: dts: r8a7795: Add PWM support

Simon Horman (5):
  arm64: dts: r8a7795: Use renesas,rcar-gen3-usb2-phy fallback binding
  arm64: dts: r8a7795: Use Gen 3 fallback compat string for PCIE
  arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes
  arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes
  arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes

Takeshi Kihara (1):
  arm64: dts: r8a7796: salvator-x: Update memory node to 4 GiB map

 Documentation/devicetree/bindings/arm/shmobile.txt |   2 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |   2 +
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 119 --
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |  37 +
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   | 183 -
 5 files changed, 323 insertions(+), 20 deletions(-)

[PATCH 12/16] arm64: dts: r8a7796: salvator-x: Update memory node to 4 GiB map

[Simon Horman]

From: Takeshi Kihara 

This patch updates memory region:

  - After changes, the new map of the Salvator-X board on R8A7796 SoC
Bank0: 2GiB RAM : 0x4800 -> 0x000bfff
Bank1: 2GiB RAM : 0x0006 -> 0x0067fff

  - Before changes, the old map looked like this:
Bank0: 2GiB RAM : 0x4800 -> 0x000bfff

Signed-off-by: Takeshi Kihara 
[geert: Correct size of old map]
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index f35e96ca7d60..38bde9de3250 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -31,6 +31,11 @@
reg = <0x0 0x4800 0x0 0x7800>;
};
 
+   memory@6 {
+   device_type = "memory";
+   reg = <0x6 0x 0x0 0x8000>;
+   };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
-- 
2.7.0.rc3.207.g0ac5344

[GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.11

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC defconfig updates for v4.11.


The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-defconfig-for-v4.11

for you to fetch changes up to e37278d83e348eb53029452e65892780359b6bea:

  ARM: multi_v7_defconfig: Enable r8a774[35] SoCs (2017-01-03 10:44:04 +0100)


Renesas ARM Based SoC Defconfig Updates for v4.11

Enable:
* Recently added Enable r8a774[35] SoCs
* CMA for DMA to allow use of VIN with large frame sizes
* CONFIG_VIDEO_ADV7604 to allow use of HDMI input


Niklas Söderlund (2):
  ARM: shmobile: defconfig: Enable CONFIG_VIDEO_ADV7604
  ARM: shmobile: defconfig: Enable CMA for DMA

Simon Horman (2):
  ARM: shmobile: defconfig: Enable r8a774[35] SoCs
  ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

 arch/arm/configs/multi_v7_defconfig | 2 ++
 arch/arm/configs/shmobile_defconfig | 6 ++
 2 files changed, 8 insertions(+)

[PATCH 02/16] arm64: dts: r8a7796: Add CAN external clock support

[Simon Horman]

From: Chris Paterson 

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

Based on a patch for r8a7795 by Ramesh Shanmugasundaram.

Signed-off-by: Chris Paterson 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Marc Kleine-Budde 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 4bf8e14956fe..c0f9ced8df7e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -69,6 +69,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>;
+   };
+
/* External SCIF clock - to be overridden by boards that provide it */
scif_clk: scif {
compatible = "fixed-clock";
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 04/25] ARM: dts: r8a7745: Add device node for PRR

[Simon Horman]

From: Geert Uytterhoeven 

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7745.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0a5d7872ce28..2f60c3cb9117 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -102,6 +102,11 @@
#power-domain-cells = <0>;
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
+
rst: reset-controller@e616 {
compatible = "renesas,r8a7745-rst";
reg = <0 0xe616 0 0x100>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 13/25] ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7778 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7778 and the
fallback binding for R-Car Gen 1.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7778.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index b0c9674fad17..1e93c94a9eac 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -150,7 +150,7 @@
i2c0: i2c@ffc7 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7778";
+   compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc7 0x1000>;
interrupts = ;
clocks = <_clks R8A7778_CLK_I2C0>;
@@ -161,7 +161,7 @@
i2c1: i2c@ffc71000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7778";
+   compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc71000 0x1000>;
interrupts = ;
clocks = <_clks R8A7778_CLK_I2C1>;
@@ -172,7 +172,7 @@
i2c2: i2c@ffc72000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7778";
+   compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc72000 0x1000>;
interrupts = ;
clocks = <_clks R8A7778_CLK_I2C2>;
@@ -183,7 +183,7 @@
i2c3: i2c@ffc73000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7778";
+   compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc73000 0x1000>;
interrupts = ;
clocks = <_clks R8A7778_CLK_I2C3>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 05/25] ARM: dts: r8a73a4: Use SoC-specific compat string for mmcif

[Simon Horman]

Use the SoC-specific compat string for mmcif in DT for the r8a73a4 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.

Signed-off-by: Simon Horman 
Acked-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a73a4.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 53183ffe04c1..b138584b8800 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -440,7 +440,7 @@
};
 
mmcif0: mmc@ee20 {
-   compatible = "renesas,sh-mmcif";
+   compatible = "renesas,mmcif-r8a73a4", "renesas,sh-mmcif";
reg = <0 0xee20 0 0x80>;
interrupts = ;
clocks = <_clks R8A73A4_CLK_MMCIF0>;
@@ -450,7 +450,7 @@
};
 
mmcif1: mmc@ee22 {
-   compatible = "renesas,sh-mmcif";
+   compatible = "renesas,mmcif-r8a73a4", "renesas,sh-mmcif";
reg = <0 0xee22 0 0x80>;
interrupts = ;
clocks = <_clks R8A73A4_CLK_MMCIF1>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 02/25] ARM: dts: r8a7745: Move RST node before SYSC node

[Simon Horman]

From: Geert Uytterhoeven 

To preserve both alphabetical (label) and numerical ordering (unit
address).

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7745.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0b2e2f37150f..0a5d7872ce28 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -102,17 +102,17 @@
#power-domain-cells = <0>;
};
 
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a7745-rst";
+   reg = <0 0xe616 0 0x100>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7745-sysc";
reg = <0 0xe618 0 0x200>;
#power-domain-cells = <1>;
};
 
-   rst: reset-controller@e616 {
-   compatible = "renesas,r8a7745-rst";
-   reg = <0 0xe616 0 0x100>;
-   };
-
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a7745",
 "renesas,rcar-dmac";
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 06/25] ARM: dts: r8a7778: Use SoC-specific compat string for mmcif

[Simon Horman]

Use the SoC-specific compat string for mmcif in DT for the r8a7778 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.

Signed-off-by: Simon Horman 
Acked-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7778.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index d0db998effc8..b0c9674fad17 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -369,7 +369,7 @@
};
 
mmcif: mmc@ffe4e000 {
-   compatible = "renesas,sh-mmcif";
+   compatible = "renesas,mmcif-r8a7778", "renesas,sh-mmcif";
reg = <0xffe4e000 0x100>;
interrupts = ;
clocks = <_clks R8A7778_CLK_MMC>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 09/25] ARM: dts: r8a7790: Use renesas,rcar-gen2-usb-phy fallback binding

[Simon Horman]

A fallback binding for the Renesas R-Car Gen2 PHY driver was
added by commit cb8ba08d ("phy: rcar-gen2: add fallback binding").
This patch makes use of this binding in the DT for the r8a7790 SoC.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7790.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 0c8900d4b824..b7ed7466308b 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -883,7 +883,8 @@
};
 
usbphy: usb-phy@e6590100 {
-   compatible = "renesas,usb-phy-r8a7790";
+   compatible = "renesas,usb-phy-r8a7790",
+"renesas,rcar-gen2-usb-phy";
reg = <0 0xe6590100 0 0x100>;
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 03/25] ARM: dts: r8a7743: Add device node for PRR

[Simon Horman]

From: Geert Uytterhoeven 

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7743.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index ca0cda28a3eb..0956125597fd 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -102,6 +102,11 @@
#power-domain-cells = <0>;
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
+
rst: reset-controller@e616 {
compatible = "renesas,r8a7743-rst";
reg = <0 0xe616 0 0x100>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 07/25] ARM: dts: sh73a0: Use SoC-specific compat string for mmcif

[Simon Horman]

Use the SoC-specific compat string for mmcif in DT for the sh73a0 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.

Signed-off-by: Simon Horman 
Acked-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/sh73a0.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index e1267590b575..6b01ab354e88 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -263,7 +263,7 @@
};
 
mmcif: mmc@e6bd {
-   compatible = "renesas,sh-mmcif";
+   compatible = "renesas,mmcif-sh73a0", "renesas,sh-mmcif";
reg = <0xe6bd 0x100>;
interrupts = ;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 10/25] ARM: dts: r8a7791: Use renesas,rcar-gen2-usb-phy fallback binding

[Simon Horman]

A fallback binding for the Renesas R-Car Gen2 PHY driver was
added by commit cb8ba08d ("phy: rcar-gen2: add fallback binding").
This patch makes use of this binding in the DT for the r8a7791 SoC.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7791.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 87214668d70f..a5c596a15120 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -934,7 +934,8 @@
};
 
usbphy: usb-phy@e6590100 {
-   compatible = "renesas,usb-phy-r8a7791";
+   compatible = "renesas,usb-phy-r8a7791",
+"renesas,rcar-gen2-usb-phy";
reg = <0 0xe6590100 0 0x100>;
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 01/25] ARM: dts: r8a7743: Move RST node before SYSC node

[Simon Horman]

From: Geert Uytterhoeven 

To preserve both alphabetical (label) and numerical ordering (unit
address).

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7743.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 216cb1f37f87..ca0cda28a3eb 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -102,17 +102,17 @@
#power-domain-cells = <0>;
};
 
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a7743-rst";
+   reg = <0 0xe616 0 0x100>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7743-sysc";
reg = <0 0xe618 0 0x200>;
#power-domain-cells = <1>;
};
 
-   rst: reset-controller@e616 {
-   compatible = "renesas,r8a7743-rst";
-   reg = <0 0xe616 0 0x100>;
-   };
-
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a7743",
 "renesas,rcar-dmac";
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 22/25] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for iic nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7794 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7794 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7794.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 89f8f98cb115..86042e64972a 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -683,7 +683,8 @@
};
 
i2c6: i2c@e650 {
-   compatible = "renesas,iic-r8a7794", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7794", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe650 0 0x425>;
interrupts = ;
clocks = <_clks R8A7794_CLK_IIC0>;
@@ -697,7 +698,8 @@
};
 
i2c7: i2c@e651 {
-   compatible = "renesas,iic-r8a7794", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7794", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe651 0 0x425>;
interrupts = ;
clocks = <_clks R8A7794_CLK_IIC1>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 12/25] ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7779 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7779 and the
fallback binding for R-Car Gen 1.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7779.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 55a7c1e37c57..f47a0edc26d4 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -173,7 +173,7 @@
i2c0: i2c@ffc7 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7779";
+   compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc7 0x1000>;
interrupts = ;
clocks = <_clks R8A7779_CLK_I2C0>;
@@ -184,7 +184,7 @@
i2c1: i2c@ffc71000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7779";
+   compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc71000 0x1000>;
interrupts = ;
clocks = <_clks R8A7779_CLK_I2C1>;
@@ -195,7 +195,7 @@
i2c2: i2c@ffc72000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7779";
+   compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc72000 0x1000>;
interrupts = ;
clocks = <_clks R8A7779_CLK_I2C2>;
@@ -206,7 +206,7 @@
i2c3: i2c@ffc73000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7779";
+   compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc73000 0x1000>;
interrupts = ;
clocks = <_clks R8A7779_CLK_I2C3>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 11/25] ARM: dts: r8a7794: Use renesas,rcar-gen2-usb-phy fallback binding

[Simon Horman]

A fallback binding for the Renesas R-Car Gen2 PHY driver was
added by commit cb8ba08d ("phy: rcar-gen2: add fallback binding").
This patch makes use of this binding in the DT for the r8a7794 SoC.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7794.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index fb576dba748c..9692bfd82b1d 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -878,7 +878,8 @@
};
 
usbphy: usb-phy@e6590100 {
-   compatible = "renesas,usb-phy-r8a7794";
+   compatible = "renesas,usb-phy-r8a7794",
+"renesas,rcar-gen2-usb-phy";
reg = <0 0xe6590100 0 0x100>;
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 1/5] ARM: shmobile: apmu: Add more register documentation

[Simon Horman]

From: Geert Uytterhoeven 

Signed-off-by: Geert Uytterhoeven 
Tested-by: Hiep Cao Minh 
Signed-off-by: Simon Horman 
---
 arch/arm/mach-shmobile/platsmp-apmu.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c 
b/arch/arm/mach-shmobile/platsmp-apmu.c
index 0c6bb458b7a4..933f9b902405 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -31,9 +31,15 @@ static struct {
int bit;
 } apmu_cpus[NR_CPUS];
 
-#define WUPCR_OFFS 0x10
-#define PSTR_OFFS 0x40
-#define CPUNCR_OFFS(n) (0x100 + (0x10 * (n)))
+#define WUPCR_OFFS  0x10   /* Wake Up Control Register */
+#define PSTR_OFFS   0x40   /* Power Status Register */
+#define CPUNCR_OFFS(n) (0x100 + (0x10 * (n)))
+   /* CPUn Power Status Control Register */
+
+/* Power Status Register */
+#define CPUNST(r, n)   (((r) >> (n * 4)) & 3)  /* CPUn Status Bit */
+#define CPUST_RUN  0   /* Run Mode */
+#define CPUST_STANDBY  3   /* CoreStandby Mode */
 
 static int __maybe_unused apmu_power_on(void __iomem *p, int bit)
 {
@@ -59,7 +65,7 @@ static int __maybe_unused apmu_power_off_poll(void __iomem 
*p, int bit)
int k;
 
for (k = 0; k < 1000; k++) {
-   if (((readl_relaxed(p + PSTR_OFFS) >> (bit * 4)) & 0x03) == 3)
+   if (CPUNST(readl_relaxed(p + PSTR_OFFS), bit) == CPUST_STANDBY)
return 1;
 
mdelay(1);
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 24/25] ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for msiof nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7792 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7792 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7792.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 59d31d433244..135e06920e2d 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -591,7 +591,8 @@
};
 
msiof0: spi@e6e2 {
-   compatible = "renesas,msiof-r8a7792";
+   compatible = "renesas,msiof-r8a7792",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6e2 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7792_CLK_MSIOF0>;
@@ -605,7 +606,8 @@
};
 
msiof1: spi@e6e1 {
-   compatible = "renesas,msiof-r8a7792";
+   compatible = "renesas,msiof-r8a7792",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6e1 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7792_CLK_MSIOF1>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 17/25] ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7793 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7793 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7793.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 2fb527ca0b15..4d271ad8bf52 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -411,7 +411,7 @@
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7793";
+   compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7793_CLK_I2C0>;
@@ -423,7 +423,7 @@
i2c1: i2c@e6518000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7793";
+   compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7793_CLK_I2C1>;
@@ -435,7 +435,7 @@
i2c2: i2c@e653 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7793";
+   compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <_clks R8A7793_CLK_I2C2>;
@@ -447,7 +447,7 @@
i2c3: i2c@e654 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7793";
+   compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <_clks R8A7793_CLK_I2C3>;
@@ -459,7 +459,7 @@
i2c4: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7793";
+   compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe652 0 0x40>;
interrupts = ;
clocks = <_clks R8A7793_CLK_I2C4>;
@@ -472,7 +472,7 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7793";
+   compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe6528000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7793_CLK_I2C5>;
-- 
2.7.0.rc3.207.g0ac5344

[GIT PULL] Renesas ARM Based SoC Updates for v4.11

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC updates for v4.11.


The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-soc-for-v4.11

for you to fetch changes up to 70def3e53694a65c5583fb5f411491a5074bab18:

  ARM: shmobile: rcar-gen2: Remove unused rcar_gen2_read_mode_pins() 
(2017-01-03 10:50:45 +0100)


Renesas ARM Based SoC Updates for v4.11

* Allow booting secondary CPU cores in debug mode


Geert Uytterhoeven (5):
  ARM: shmobile: apmu: Add more register documentation
  ARM: shmobile: apmu: Add debug resource reset for secondary CPU boot
  ARM: shmobile: apmu: Allow booting secondary CPU cores in debug mode
  ARM: shmobile: r8a7791: Allow booting secondary CPU cores in debug mode
  ARM: shmobile: rcar-gen2: Remove unused rcar_gen2_read_mode_pins()

 arch/arm/mach-shmobile/platsmp-apmu.c| 41 +++-
 arch/arm/mach-shmobile/rcar-gen2.h   |  2 --
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 18 --
 arch/arm/mach-shmobile/smp-r8a7791.c | 14 +--
 4 files changed, 25 insertions(+), 50 deletions(-)

[PATCH 08/25] ARM: dts: gose: Add da9063 PMIC device node for system restart

[Simon Horman]

From: Geert Uytterhoeven 

Enable i2c6, and add a device node for the da9063 PMIC, with subnodes
for rtc and wdt.  Regulator support is not yet included.

This allows the system to be restarted when the watchdog timer times
out, or when a system restart is requested.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7793-gose.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index dc311eba..92fff07c5e2b 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -538,6 +538,27 @@
};
 };
 
+ {
+   status = "okay";
+   clock-frequency = <10>;
+
+   pmic@58 {
+   compatible = "dlg,da9063";
+   reg = <0x58>;
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+
+   rtc {
+   compatible = "dlg,da9063-rtc";
+   };
+
+   wdt {
+   compatible = "dlg,da9063-watchdog";
+   };
+   };
+};
+
 _sound {
pinctrl-0 = <_pins _clk_pins>;
pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 15/25] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7791 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7791.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index a5c596a15120..b61700aa862e 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -444,7 +444,7 @@
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7791";
+   compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7791_CLK_I2C0>;
@@ -456,7 +456,7 @@
i2c1: i2c@e6518000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7791";
+   compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7791_CLK_I2C1>;
@@ -468,7 +468,7 @@
i2c2: i2c@e653 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7791";
+   compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <_clks R8A7791_CLK_I2C2>;
@@ -480,7 +480,7 @@
i2c3: i2c@e654 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7791";
+   compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <_clks R8A7791_CLK_I2C3>;
@@ -492,7 +492,7 @@
i2c4: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7791";
+   compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe652 0 0x40>;
interrupts = ;
clocks = <_clks R8A7791_CLK_I2C4>;
@@ -505,7 +505,7 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7791";
+   compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6528000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7791_CLK_I2C5>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 16/25] ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7792 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7792 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7792.dtsi | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 6ced3c1ec377..59d31d433244 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -498,7 +498,8 @@
 
/* I2C doesn't need pinmux */
i2c0: i2c@e6508000 {
-   compatible = "renesas,i2c-r8a7792";
+   compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7792_CLK_I2C0>;
@@ -510,7 +511,8 @@
};
 
i2c1: i2c@e6518000 {
-   compatible = "renesas,i2c-r8a7792";
+   compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7792_CLK_I2C1>;
@@ -522,7 +524,8 @@
};
 
i2c2: i2c@e653 {
-   compatible = "renesas,i2c-r8a7792";
+   compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <_clks R8A7792_CLK_I2C2>;
@@ -534,7 +537,8 @@
};
 
i2c3: i2c@e654 {
-   compatible = "renesas,i2c-r8a7792";
+   compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <_clks R8A7792_CLK_I2C3>;
@@ -546,7 +550,8 @@
};
 
i2c4: i2c@e652 {
-   compatible = "renesas,i2c-r8a7792";
+   compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe652 0 0x40>;
interrupts = ;
clocks = <_clks R8A7792_CLK_I2C4>;
@@ -558,7 +563,8 @@
};
 
i2c5: i2c@e6528000 {
-   compatible = "renesas,i2c-r8a7792";
+   compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe6528000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7792_CLK_I2C5>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 20/25] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for iic nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7791 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7791.dtsi | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index b61700aa862e..55872fc8fa4c 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -518,7 +518,8 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe60b 0 0x425>;
interrupts = ;
clocks = <_clks R8A7791_CLK_IICDVFS>;
@@ -532,7 +533,8 @@
i2c7: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe650 0 0x425>;
interrupts = ;
clocks = <_clks R8A7791_CLK_IIC0>;
@@ -546,7 +548,8 @@
i2c8: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe651 0 0x425>;
interrupts = ;
clocks = <_clks R8A7791_CLK_IIC1>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 23/25] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for msiof nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7791 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7791.dtsi | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 55872fc8fa4c..06486664d754 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1521,7 +1521,8 @@
};
 
msiof0: spi@e6e2 {
-   compatible = "renesas,msiof-r8a7791";
+   compatible = "renesas,msiof-r8a7791",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6e2 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7791_CLK_MSIOF0>;
@@ -1535,7 +1536,8 @@
};
 
msiof1: spi@e6e1 {
-   compatible = "renesas,msiof-r8a7791";
+   compatible = "renesas,msiof-r8a7791",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6e1 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7791_CLK_MSIOF1>;
@@ -1549,7 +1551,8 @@
};
 
msiof2: spi@e6e0 {
-   compatible = "renesas,msiof-r8a7791";
+   compatible = "renesas,msiof-r8a7791",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6e0 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7791_CLK_MSIOF2>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 25/25] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7790 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7790.dtsi | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ddf6a8cbe6c1..44ea77febe17 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1508,7 +1508,8 @@
};
 
msiof0: spi@e6e2 {
-   compatible = "renesas,msiof-r8a7790";
+   compatible = "renesas,msiof-r8a7790",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6e2 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7790_CLK_MSIOF0>;
@@ -1522,7 +1523,8 @@
};
 
msiof1: spi@e6e1 {
-   compatible = "renesas,msiof-r8a7790";
+   compatible = "renesas,msiof-r8a7790",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6e1 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7790_CLK_MSIOF1>;
@@ -1536,7 +1538,8 @@
};
 
msiof2: spi@e6e0 {
-   compatible = "renesas,msiof-r8a7790";
+   compatible = "renesas,msiof-r8a7790",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6e0 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7790_CLK_MSIOF2>;
@@ -1550,7 +1553,8 @@
};
 
msiof3: spi@e6c9 {
-   compatible = "renesas,msiof-r8a7790";
+   compatible = "renesas,msiof-r8a7790",
+"renesas,rcar-gen2-msiof";
reg = <0 0xe6c9 0 0x0064>;
interrupts = ;
clocks = <_clks R8A7790_CLK_MSIOF3>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 14/25] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7790 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7790.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b7ed7466308b..823ab536175d 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -480,7 +480,7 @@
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7790";
+   compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7790_CLK_I2C0>;
@@ -492,7 +492,7 @@
i2c1: i2c@e6518000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7790";
+   compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7790_CLK_I2C1>;
@@ -504,7 +504,7 @@
i2c2: i2c@e653 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7790";
+   compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <_clks R8A7790_CLK_I2C2>;
@@ -516,7 +516,7 @@
i2c3: i2c@e654 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7790";
+   compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <_clks R8A7790_CLK_I2C3>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 21/25] ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for iic nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7793 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7793 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7793.dtsi | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 4d271ad8bf52..bf64e2420fb5 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -485,7 +485,8 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe60b 0 0x425>;
interrupts = ;
clocks = <_clks R8A7793_CLK_IICDVFS>;
@@ -499,7 +500,8 @@
i2c7: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe650 0 0x425>;
interrupts = ;
clocks = <_clks R8A7793_CLK_IIC0>;
@@ -513,7 +515,8 @@
i2c8: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe651 0 0x425>;
interrupts = ;
clocks = <_clks R8A7793_CLK_IIC1>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 18/25] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7794 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7794 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7794.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 9692bfd82b1d..89f8f98cb115 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -611,7 +611,7 @@
 
/* The memory map in the User's Manual maps the cores to bus numbers */
i2c0: i2c@e6508000 {
-   compatible = "renesas,i2c-r8a7794";
+   compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7794_CLK_I2C0>;
@@ -623,7 +623,7 @@
};
 
i2c1: i2c@e6518000 {
-   compatible = "renesas,i2c-r8a7794";
+   compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7794_CLK_I2C1>;
@@ -635,7 +635,7 @@
};
 
i2c2: i2c@e653 {
-   compatible = "renesas,i2c-r8a7794";
+   compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <_clks R8A7794_CLK_I2C2>;
@@ -647,7 +647,7 @@
};
 
i2c3: i2c@e654 {
-   compatible = "renesas,i2c-r8a7794";
+   compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <_clks R8A7794_CLK_I2C3>;
@@ -659,7 +659,7 @@
};
 
i2c4: i2c@e652 {
-   compatible = "renesas,i2c-r8a7794";
+   compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe652 0 0x40>;
interrupts = ;
clocks = <_clks R8A7794_CLK_I2C4>;
@@ -671,7 +671,7 @@
};
 
i2c5: i2c@e6528000 {
-   compatible = "renesas,i2c-r8a7794";
+   compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe6528000 0 0x40>;
interrupts = ;
clocks = <_clks R8A7794_CLK_I2C5>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 19/25] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for iic nodes

[Simon Horman]

Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7790 SoC.

This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7790.dtsi | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 823ab536175d..ddf6a8cbe6c1 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -528,7 +528,8 @@
iic0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe650 0 0x425>;
interrupts = ;
clocks = <_clks R8A7790_CLK_IIC0>;
@@ -542,7 +543,8 @@
iic1: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe651 0 0x425>;
interrupts = ;
clocks = <_clks R8A7790_CLK_IIC1>;
@@ -556,7 +558,8 @@
iic2: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe652 0 0x425>;
interrupts = ;
clocks = <_clks R8A7790_CLK_IIC2>;
@@ -570,7 +573,8 @@
iic3: i2c@e60b {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+   compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe60b 0 0x425>;
interrupts = ;
clocks = <_clks R8A7790_CLK_IICDVFS>;
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 3/5] ARM: shmobile: apmu: Allow booting secondary CPU cores in debug mode

[Simon Horman]

From: Geert Uytterhoeven 

Now debug resource reset is handled properly, allow booting secondary
CPU cores when hardware debug mode is enabled (MD21=1) on SoCs using the
"renesas,apmu" enable method.

Signed-off-by: Geert Uytterhoeven 
Tested-by: Hiep Cao Minh 
Signed-off-by: Simon Horman 
---
 arch/arm/mach-shmobile/platsmp-apmu.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c 
b/arch/arm/mach-shmobile/platsmp-apmu.c
index 7e4ca6788be5..e19266844e16 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -216,21 +216,9 @@ static void __init 
shmobile_smp_apmu_prepare_cpus_dt(unsigned int max_cpus)
rcar_gen2_pm_init();
 }
 
-static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
-struct task_struct *idle)
-{
-   /* Error out when hardware debug mode is enabled */
-   if (rcar_gen2_read_mode_pins() & BIT(21)) {
-   pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
-   return -ENOTSUPP;
-   }
-
-   return shmobile_smp_apmu_boot_secondary(cpu, idle);
-}
-
 static struct smp_operations apmu_smp_ops __initdata = {
.smp_prepare_cpus   = shmobile_smp_apmu_prepare_cpus_dt,
-   .smp_boot_secondary = shmobile_smp_apmu_boot_secondary_md21,
+   .smp_boot_secondary = shmobile_smp_apmu_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
.cpu_can_disable= shmobile_smp_cpu_can_disable,
.cpu_die= shmobile_smp_apmu_cpu_die,
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 2/5] ARM: shmobile: apmu: Add debug resource reset for secondary CPU boot

[Simon Horman]

From: Geert Uytterhoeven 

In debug mode (MD21=1), reset requests derived from power-shutoff to the
AP-system CPU cores must be enabled before the AP-system CPU cores
resume from power-shutoff for the first time. Else resume may fail,
causing the system to hang during boot.

As setting these bits is a no-op in normal mode, there's no need to
check the actual state of MD21 first.

Inspired by CPU-specific patches in the BSP by Hisashi Nakamura
.

Signed-off-by: Geert Uytterhoeven 
Tested-by: Hiep Cao Minh 
Signed-off-by: Simon Horman 
---
 arch/arm/mach-shmobile/platsmp-apmu.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c 
b/arch/arm/mach-shmobile/platsmp-apmu.c
index 933f9b902405..7e4ca6788be5 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -35,12 +35,18 @@ static struct {
 #define PSTR_OFFS   0x40   /* Power Status Register */
 #define CPUNCR_OFFS(n) (0x100 + (0x10 * (n)))
/* CPUn Power Status Control Register */
+#define DBGRCR_OFFS0x180   /* Debug Resource Reset Control Reg. */
 
 /* Power Status Register */
 #define CPUNST(r, n)   (((r) >> (n * 4)) & 3)  /* CPUn Status Bit */
 #define CPUST_RUN  0   /* Run Mode */
 #define CPUST_STANDBY  3   /* CoreStandby Mode */
 
+/* Debug Resource Reset Control Register */
+#define DBGCPUREN  BIT(24) /* CPU Other Reset Request Enable */
+#define DBGCPUNREN(n)  BIT((n) + 20)   /* CPUn Reset Request Enable */
+#define DBGCPUPREN BIT(19) /* CPU Peripheral Reset Req. Enable */
+
 static int __maybe_unused apmu_power_on(void __iomem *p, int bit)
 {
/* request power on */
@@ -84,6 +90,8 @@ static int __maybe_unused apmu_wrap(int cpu, int (*fn)(void 
__iomem *p, int cpu)
 #ifdef CONFIG_SMP
 static void apmu_init_cpu(struct resource *res, int cpu, int bit)
 {
+   u32 x;
+
if ((cpu >= ARRAY_SIZE(apmu_cpus)) || apmu_cpus[cpu].iomem)
return;
 
@@ -91,6 +99,11 @@ static void apmu_init_cpu(struct resource *res, int cpu, int 
bit)
apmu_cpus[cpu].bit = bit;
 
pr_debug("apmu ioremap %d %d %pr\n", cpu, bit, res);
+
+   /* Setup for debug mode */
+   x = readl(apmu_cpus[cpu].iomem + DBGRCR_OFFS);
+   x |= DBGCPUREN | DBGCPUNREN(bit) | DBGCPUPREN;
+   writel(x, apmu_cpus[cpu].iomem + DBGRCR_OFFS);
 }
 
 static void apmu_parse_cfg(void (*fn)(struct resource *res, int cpu, int bit),
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 4/5] ARM: shmobile: r8a7791: Allow booting secondary CPU cores in debug mode

[Simon Horman]

From: Geert Uytterhoeven 

Now debug resource reset is handled properly, allow booting secondary
CPU cores when hardware debug mode is enabled (MD21=1, SW8-4=OFF on
koelsch) on legacy r8a7791.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/mach-shmobile/smp-r8a7791.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7791.c 
b/arch/arm/mach-shmobile/smp-r8a7791.c
index 2d6417af73b5..2948c22cfc53 100644
--- a/arch/arm/mach-shmobile/smp-r8a7791.c
+++ b/arch/arm/mach-shmobile/smp-r8a7791.c
@@ -42,21 +42,9 @@ static void __init r8a7791_smp_prepare_cpus(unsigned int 
max_cpus)
rcar_gen2_pm_init();
 }
 
-static int r8a7791_smp_boot_secondary(unsigned int cpu,
- struct task_struct *idle)
-{
-   /* Error out when hardware debug mode is enabled */
-   if (rcar_gen2_read_mode_pins() & BIT(21)) {
-   pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
-   return -ENOTSUPP;
-   }
-
-   return shmobile_smp_apmu_boot_secondary(cpu, idle);
-}
-
 const struct smp_operations r8a7791_smp_ops __initconst = {
.smp_prepare_cpus   = r8a7791_smp_prepare_cpus,
-   .smp_boot_secondary = r8a7791_smp_boot_secondary,
+   .smp_boot_secondary = shmobile_smp_apmu_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
.cpu_can_disable= shmobile_smp_cpu_can_disable,
.cpu_die= shmobile_smp_apmu_cpu_die,
-- 
2.7.0.rc3.207.g0ac5344

[PATCH 5/5] ARM: shmobile: rcar-gen2: Remove unused rcar_gen2_read_mode_pins()

[Simon Horman]

From: Geert Uytterhoeven 

After
  1. commit 9f5ce39ddb8f68b3 ("ARM: shmobile: rcar-gen2: Obtain extal
 frequency from DT"),
  2. commit 80951f04c3f92533 ("ARM: shmobile: rcar-gen2: Stop passing
 mode pins state to clock driver"),
  3. and handling of debug resource reset,
there are no more users of rcar_gen2_read_mode_pins() left.
Remove the function and its support definitions.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/mach-shmobile/rcar-gen2.h   |  2 --
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 18 --
 2 files changed, 20 deletions(-)

diff --git a/arch/arm/mach-shmobile/rcar-gen2.h 
b/arch/arm/mach-shmobile/rcar-gen2.h
index 8a66b4aae035..6792e249cf56 100644
--- a/arch/arm/mach-shmobile/rcar-gen2.h
+++ b/arch/arm/mach-shmobile/rcar-gen2.h
@@ -2,8 +2,6 @@
 #define __ASM_RCAR_GEN2_H__
 
 void rcar_gen2_timer_init(void);
-#define MD(nr) BIT(nr)
-u32 rcar_gen2_read_mode_pins(void);
 void rcar_gen2_reserve(void);
 void rcar_gen2_pm_init(void);
 
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c 
b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index ac63fa407b64..52d466b75973 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -29,24 +29,6 @@
 #include "common.h"
 #include "rcar-gen2.h"
 
-#define MODEMR 0xe6160060
-
-u32 rcar_gen2_read_mode_pins(void)
-{
-   static u32 mode;
-   static bool mode_valid;
-
-   if (!mode_valid) {
-   void __iomem *modemr = ioremap_nocache(MODEMR, 4);
-   BUG_ON(!modemr);
-   mode = ioread32(modemr);
-   iounmap(modemr);
-   mode_valid = true;
-   }
-
-   return mode;
-}
-
 static unsigned int __init get_extal_freq(void)
 {
struct device_node *cpg, *extal;
-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

[Arnd Bergmann]

On Wednesday, January 4, 2017 6:29:39 PM CET Nikita Yushchenko wrote:

> > Just a guess, but if the inbound translation windows in the host
> > bridge are wider than 32-bit, the reason for setting up a single
> > 32-bit window is probably because that is what the parent bus supports.
> 
> Well anyway applying patch similar to your's will fix pcie-rcar + nvme
> case - thus I don't object :)   But it can break other cases ...
> 
> But why do you hook at set_dma_mask() and overwrite mask inside, instead
> of hooking at dma_supported() and rejecting unsupported mask?
> 
> I think later is better, because it lets drivers to handle unsupported
> high-dma case, like documented in DMA-API_HOWTO.

I think the behavior I put in there is required for swiotlb to make
sense, otherwise you would rely on the driver to handle dma_set_mask()
failure gracefully with its own bounce buffers (as network and
scsi drivers do but others don't).

Having swiotlb or iommu enabled should result in dma_set_mask() always
succeeding unless the mask is too small to cover the swiotlb
bounce buffer area or the iommu virtual address space. This behavior
is particularly important in case the bus address space is narrower
than 32-bit, as we have to guarantee that the fallback to 32-bit
DMA always succeeds. There are also a lot of drivers that try to
set a 64-bit mask but don't implement bounce buffers for streaming
mappings if that fails, and swiotlb is what we use to make those
drivers work.

And yes, the API is a horrible mess.

Arnd

Re: [PATCH 18/19] serial: sh-sci: Remove unused platform data capabilities field

[Laurent Pinchart]

Hi Geert,

On Friday 06 Jan 2017 11:59:58 Geert Uytterhoeven wrote:
> On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart wrote:
> > The field isn't set by any platform but is only used internally in the
> > driver to hold data parsed from DT. Move it to the sci_port structure.
> 
> This does mean legacy platform data can no longer set it
> (no platform data did).

Correct. Platforms that want to set it should migrate to DT :-)

> > Signed-off-by: Laurent Pinchart
> > 
> 
> Reviewed-by: Geert Uytterhoeven 

-- 
Regards,

Laurent Pinchart

Re: [PATCH 18/19] serial: sh-sci: Remove unused platform data capabilities field

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The field isn't set by any platform but is only used internally in the
> driver to hold data parsed from DT. Move it to the sci_port structure.

This does mean legacy platform data can no longer set it
(no platform data did).

> Signed-off-by: Laurent Pinchart 

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 19/19] serial: sh-sci: Compute the regshift value for SCI ports

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> SCI instances found in SH SoCs have different spacing between registers
> depending on the SoC. The platform data contains a regshift field that
> tells the driver by how many bits to shift the register offset to
> compute its address. We can compute the regshift value automatically
> based on the memory resource size, there's no need to pass the value
> through platform data.
>
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/tty/serial/sh-sci.c | 25 +++--
>  include/linux/serial_sci.h  |  1 -
>  2 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 5fc2606fc525..fbffe89b493f 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -187,19 +187,18 @@ static const struct sci_port_params 
> sci_port_params[SCIx_NR_REGTYPES] = {
> },
>
> /*
> -* Common definitions for legacy IrDA ports, dependent on
> -* regshift value.
> +* Common definitions for legacy IrDA ports.
>  */
> [SCIx_IRDA_REGTYPE] = {
> .regs = {
> [SCSMR] = { 0x00,  8 },
> -   [SCBRR] = { 0x01,  8 },
> -   [SCSCR] = { 0x02,  8 },
> -   [SCxTDR]= { 0x03,  8 },
> -   [SCxSR] = { 0x04,  8 },
> -   [SCxRDR]= { 0x05,  8 },
> -   [SCFCR] = { 0x06,  8 },
> -   [SCFDR] = { 0x07, 16 },
> +   [SCBRR] = { 0x02,  8 },
> +   [SCSCR] = { 0x04,  8 },
> +   [SCxTDR]= { 0x06,  8 },
> +   [SCxSR] = { 0x08, 16 },
> +   [SCxRDR]= { 0x0a,  8 },
> +   [SCFCR] = { 0x0c,  8 },
> +   [SCFDR] = { 0x0e, 16 },

This hunk is not documented, and belongs in "[PATCH 08/19] sh: sh3: sh770x:
Fix platform data for the IRDA serial port" to avoid breaking bisection.

The rest looks OK.

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 00/19] sh-sci: Platform data simplification

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> Most of the patches in this series have been sitting in my development tree
> for three years now. While rebasing all my development branches I decided it
> was time to send them out in case they're considered useful. I've then thrown
> a few additional patches in to move the driver further in the right direction
> (or at least the direction I consider right).
>
> The idea behind this series is to move towards removal of the sh-sci platform
> data. This won't be possible until SH platforms move to DT (and I won't hold
> my breath), but we can get rid of most of the platform data fields already and
> cleanup the sh-sci driver at the same time.

Thanks for your series!

Most of it looks sane to me (cfr. my Reviewed-by tags).

Who's got a SuperH farm to regression test this? ;-)

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 17/19] serial: sh-sci: Remove manual break debouncing

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The sh-sci driver implements manual break debouncing for a few SH
> platforms by reading the value of the RX pin port register. This feature
> is optional and the driver considers all negative or zero values of the
> platform data port_reg field as invalid. As the four platforms that set
> the field to a register address all use an address higher than
> 0x7fff, the driver will always consider the value as invalid and
> never perform debouncing. The feature is unused, remove it.
>
> Debouncing could be implemented properly in the future using the pinctrl
> and GPIO APIs if desired.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

> --- a/include/linux/serial_sci.h
> +++ b/include/linux/serial_sci.h

> @@ -41,8 +39,6 @@ enum {
> SCIx_NR_REGTYPES,
>  };
>
> -struct device;
> -


Unrelated change (missed in commit 937bb6e4c676 ("serial: sh-sci: don't
filter on DMA device, use only channel ID")


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 16/19] serial: sh-sci: Remove the platform data dma slave rx/tx channel IDs

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> Only SH platforms still use platform data for the sh-sci, and none of
> them declare DMA channels connected to the SCI. Remove the corresponding
> platform data fields and simplify the driver accordingly.
>
> Signed-off-by: Laurent Pinchart 

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 15/19] serial: sh-sci: Extend sci_port_params with more port parameters

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The fifo size, overrun register and mask, sampling rate mask and error
> mask all depend on the port type only and don't need to be computed at
> runtime. Add them to the sci_port_parameters structure.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -107,6 +107,12 @@ struct plat_sci_reg {
>
>  struct sci_port_params {
> const struct plat_sci_reg regs[SCIx_NR_REGS];
> +   unsigned int fifosize;
> +   unsigned int overrun_reg;
> +   unsigned int overrun_mask;
> +   unsigned int sampling_rate_mask;
> +   unsigned int error_mask;
> +   unsigned int error_clear;
>  };
>
>  struct sci_port {


> @@ -2649,29 +2687,10 @@ static int sci_init_single(struct platform_device 
> *dev,
> sci_port->break_timer.function = sci_break_timer;
> init_timer(_port->break_timer);
>
> -   /*
> -* Establish some sensible defaults for the error detection.
> -*/
> -   if (p->type == PORT_SCI) {
> -   sci_port->error_mask = SCI_DEFAULT_ERROR_MASK;
> -   sci_port->error_clear = SCI_ERROR_CLEAR;
> -   } else {
> -   sci_port->error_mask = SCIF_DEFAULT_ERROR_MASK;
> -   sci_port->error_clear = SCIF_ERROR_CLEAR;
> -   }
> -
> -   /*
> -* Make the error mask inclusive of overrun detection, if
> -* supported.
> -*/
> -   if (sci_port->overrun_reg == SCxSR) {
> -   sci_port->error_mask |= sci_port->overrun_mask;
> -   sci_port->error_clear &= ~sci_port->overrun_mask;
> -   }
> -
> port->type  = p->type;
> port->flags = UPF_FIXED_PORT | UPF_BOOT_AUTOCONF | 
> p->flags;
> port->regshift  = p->regshift;
> +   port->fifosize  = sci_port->params->fifosize;

You still need this assignment because you didn't convert a handfull
remaining users of port->fifosize to params->fifosize?

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 13/19] serial: sh-sci: Replace regmap array with port parameters

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> Turn the regmap two-dimensional array to an array of port parameters and
> store a pointer to the port parameters in the sci_port structure. This
> will allow handling additional port type dependent parameters.
>
> Signed-off-by: Laurent Pinchart 

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 14/19] serial: sh-sci: Constify platform data

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The driver modifies platform data for internal purpose only. Fix that
> and make the platform data structure const.
>
> Signed-off-by: Laurent Pinchart 

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 10/19] sh: Don't set the sh-sci platform data scscr CKE0 bit

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The bit is only set by platforms that also set the CKE1 but, in which
> case its value is ignored by the device. Don't set it, this simplifies
> platform data and only leaves the CKE1 bit to be handled.
>
> Signed-off-by: Laurent Pinchart 

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 12/19] serial: sh-sci: Remove initialization of zero fields in sci_port_params

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The compiler zeros uninitialized fields, don't zero them manually.
>
> Signed-off-by: Laurent Pinchart 

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 11/19] sh: Don't set the sh-sci platform data REIE bit when not implemented

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> According to the datasheets, the sh7760 SIM and sh7723 SCIFA instances
> don't implement the REIE bit. Don't set it in platform data.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

> ---
>  arch/sh/kernel/cpu/sh4/setup-sh7760.c  | 1 -
>  arch/sh/kernel/cpu/sh4a/setup-sh7723.c | 3 ---
>  2 files changed, 4 deletions(-)
>
> diff --git a/arch/sh/kernel/cpu/sh4/setup-sh7760.c 
> b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
> index 6dbcbf1621aa..e51fe1734e13 100644
> --- a/arch/sh/kernel/cpu/sh4/setup-sh7760.c
> +++ b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
> @@ -200,7 +200,6 @@ static struct platform_device scif2_device = {
>  };
>
>  static struct plat_sci_port scif3_platform_data = {
> -   .scscr  = SCSCR_REIE,

Note that this bit does have a function (WAIT_IE --- Enables wait error
interrupt (SIMERI) requests), so this may impact behavior.

> /*
>  * This is actually a SIM card module serial port, based on an SCI 
> with
>  * additional registers. The sh-sci driver doesn't support the SIM 
> port

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 08/19] sh: sh3: sh770x: Fix platform data for the IRDA serial port

[Laurent Pinchart]

Hi Geert,

On Friday 06 Jan 2017 11:18:32 Geert Uytterhoeven wrote:
> On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart wrote:
> > Even though most of its registers are 8-bit wide, the IRDA has two
> > 16-bit registers that make it a 16-bit peripheral and not a 8-bit
> > peripheral with addresses shifted by one. Fix the memory resource size
> > and the platform data regshift value.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  arch/sh/kernel/cpu/sh3/setup-sh770x.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> > b/arch/sh/kernel/cpu/sh3/setup-sh770x.c index e1e54258b822..084a91e6027e
> > 100644
> > --- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> > +++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> > @@ -157,11 +157,10 @@ static struct platform_device scif1_device = {
> >  static struct plat_sci_port scif2_platform_data = {
> > .type   = PORT_IRDA,
> > .ops= _sci_port_ops,
> > -   .regshift   = 1,
> 
> According to my sh7707 and sh7709 datasheets. regshift = 1 is correct.
> 
> SCIx_IRDA_REGTYPE uses:
> 
> [SCSMR] = { 0x00,  8 },
> [SCBRR] = { 0x01,  8 },
> [SCSCR] = { 0x02,  8 },
> [SCxTDR]= { 0x03,  8 },
> [SCxSR] = { 0x04,  8 },
> [SCxRDR]= { 0x05,  8 },
> [SCFCR] = { 0x06,  8 },
> [SCFDR] = { 0x07, 16 },
> 
> While the datasheet says:
> 
> SCSMR1  H'A4000140  8 bits
> SCBRR1  H'A4000142  8 bits
> SCSCR1  H'A4000144  8 bits
> SCFTDR1 H'A4000146  8 bits
> SCSSR1  H'A4000148  16 bits
> SCFRDR1 H'A400014A  8 bits
> SCFCR1  H'A400014C  8 bits
> SCFDR1  H'A400014E  16 bits
> 
> So you do need regshift = 1 to handle the gaps.
> 
> Note that SCSSR1 is a 16-bit registers, while SCIx_IRDA_REGTYPE
> declares it as 8-bit, so it may not work at all...
> 
> Ah, you're fixing all this in "[PATCH 19/19] serial: sh-sci: Compute the
> regshift value for SCI ports".
> I think that part should be moved to this patch, to not break bisection.

Yes, I realized that after sending the series. If you think we need to care 
about bisection here (given that it seems that sh-sci hasn't been tested on SH 
since at least v3.1...) we can fix that.

> >  static struct resource scif2_resources[] = {
> > -   DEFINE_RES_MEM(0xa4000140, 0x10),
> > +   DEFINE_RES_MEM(0xa4000140, 0x20),
> > DEFINE_RES_IRQ(evt2irq(0x880)),
> >  };
> 
> According to the register list above, resource size 0x10 is correct.

I'll fix this.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 08/19] sh: sh3: sh770x: Fix platform data for the IRDA serial port

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> Even though most of its registers are 8-bit wide, the IRDA has two
> 16-bit registers that make it a 16-bit peripheral and not a 8-bit
> peripheral with addresses shifted by one. Fix the memory resource size
> and the platform data regshift value.
>
> Signed-off-by: Laurent Pinchart 
> ---
>  arch/sh/kernel/cpu/sh3/setup-sh770x.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/sh/kernel/cpu/sh3/setup-sh770x.c 
> b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> index e1e54258b822..084a91e6027e 100644
> --- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> +++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> @@ -157,11 +157,10 @@ static struct platform_device scif1_device = {
>  static struct plat_sci_port scif2_platform_data = {
> .type   = PORT_IRDA,
> .ops= _sci_port_ops,
> -   .regshift   = 1,

According to my sh7707 and sh7709 datasheets. regshift = 1 is correct.

SCIx_IRDA_REGTYPE uses:

[SCSMR] = { 0x00,  8 },
[SCBRR] = { 0x01,  8 },
[SCSCR] = { 0x02,  8 },
[SCxTDR]= { 0x03,  8 },
[SCxSR] = { 0x04,  8 },
[SCxRDR]= { 0x05,  8 },
[SCFCR] = { 0x06,  8 },
[SCFDR] = { 0x07, 16 },

While the datasheet says:

SCSMR1  H'A4000140  8 bits
SCBRR1  H'A4000142  8 bits
SCSCR1  H'A4000144  8 bits
SCFTDR1 H'A4000146  8 bits
SCSSR1  H'A4000148  16 bits
SCFRDR1 H'A400014A  8 bits
SCFCR1  H'A400014C  8 bits
SCFDR1  H'A400014E  16 bits

So you do need regshift = 1 to handle the gaps.

Note that SCSSR1 is a 16-bit registers, while SCIx_IRDA_REGTYPE
declares it as 8-bit, so it may not work at all...

Ah, you're fixing all this in "[PATCH 19/19] serial: sh-sci: Compute the
regshift value for SCI ports".
I think that part should be moved to this patch, to not break bisection.

>  static struct resource scif2_resources[] = {
> -   DEFINE_RES_MEM(0xa4000140, 0x10),
> +   DEFINE_RES_MEM(0xa4000140, 0x20),
> DEFINE_RES_IRQ(evt2irq(0x880)),
>  };

According to the register list above, resource size 0x10 is correct.

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 09/19] sh: Don't set the sh-sci platform data regshift field

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The regshift value is computed automatically by the driver, there's no
> need to set it in platform data. Specify the associated memory resource
> lengths to ensure proper computation of the value.
>
> Signed-off-by: Laurent Pinchart 

Doing this separate from "[PATCH 19/19] serial: sh-sci: Compute the regshift
value for SCI ports") breaks bisection.

> --- a/arch/sh/kernel/cpu/sh4/setup-sh7760.c
> +++ b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
> @@ -201,12 +201,18 @@ static struct platform_device scif2_device = {
>
>  static struct plat_sci_port scif3_platform_data = {
> .scscr  = SCSCR_REIE,
> +   /*
> +* This is actually a SIM card module serial port, based on an SCI 
> with
> +* additional registers. The sh-sci driver doesn't support the SIM 
> port
> +* type, declare it as a SCI. Don't declare the additional registers 
> in
> +* the memory resource or the driver will compute an incorrect 
> regshift
> +* value.
> +*/
> .type   = PORT_SCI,
> -   .regshift   = 2,

Yeah, that regshift value doesn't match the datasheet at all
(should have been 1 before).

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 07/19] sh: Don't set sh-sci port_reg

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The driver considers all negative or zero values of the port_reg field
> as invalid. The four platforms that set the field to a register address
> all use an address higher than 0x7fff, which is thus considered by
> the driver as invalid. The feature is thus never used, remove it.

Yeah, it's been broken since v3.1
(commit 514820eb982eb856 ("serial: sh-sci: Consolidate RXD pin handling")).

> The feature could be implemented properly in the future using the
> pinctrl and GPIO APIs if desired.
>
> While at it, don't set the field to SCIx_NOT_SUPPORTED (-1) either,
> leaving it unset leads to the same result. This will allow removing the
> SCIx_NOT_SUPPORTED macro.
>
> Signed-off-by: Laurent Pinchart 

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 06/19] sh: Don't set the sh-sci pdata UPF_BOOT_AUTOCONF flags

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The flag is set by the driver internally, don't set it in platform data.
>
> Signed-off-by: Laurent Pinchart 

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 05/19] sh: sh726[49]: Don't set sh-sci pdata scscr TOIE bit

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The SCIF ports on sh7264 and sh7269 don't support the TOIE bit according
> to the datasheets.
>
> Signed-off-by: Laurent Pinchart 

Looks OK for sh7269
I don't have a sh7264 datasheet, so let's trust you on that ;-)

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 01/19] serial: sh-sci: Set the SCSCR TE and RE bits in the driver

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The Transmit Enable and Receive Enable bits are set in the scscr field
> of all instances of the sh-sci platform data. Set them in the driver
> directly to prepare for their removal from platform data.
>
> Signed-off-by: Laurent Pinchart 

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 02/19] serial: sh-sci: Don't rely on platform data flags when not needed

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The UPF_BOOT_AUTOCONF platform data flag is set by all platforms,
> hardcode it.
>
> The UPF_IOREMAP flag is set by a single SH platform and thus needs to be
> kept. However, for ARM platforms, we can base the decision on whether an
> OF node is present and bypass the platform data flags completely.
>
> Signed-off-by: Laurent Pinchart 

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 04/19] sh: Don't set sh-sci pdata scscr TIE and RIE bits

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The scscr platform data field is used by the driver in three locations.
> One of them masks out all bits except SCSCR_REIE. The two other are the
> set_termios handler and the console write handler.
>
> The set_termios handler calls sci_start_rx() to enable the receiver,
> which sets the RIE bit unconditionally. It then calls sci_port_disable()
> that effectively disables both the transmitter and the receiver. The
> TIE bit will thus get set later when the serial cores reenables the
> serial port.
>
> The console write handler runs with interrupts disabled, and saves and
> restores the SCSCR register value. The RIE and TIE bits are thus not
> needed there.
>
> The bits are thus not necessary in platform data, remove them.
>
> Signed-off-by: Laurent Pinchart 

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 03/19] sh: Don't set sh-sci pdata scscr TE and RE bits

[Geert Uytterhoeven]

On Wed, Jan 4, 2017 at 12:06 AM, Laurent Pinchart
 wrote:
> The bits are set by the driver internally, don't set them in platform
> data.
>
> Signed-off-by: Laurent Pinchart 

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 v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

[Jose Abreu]

Hi Laurent,


Sorry for the delayed answer but I am quite busy at the moment.


On 06-01-2017 01:48, Laurent Pinchart wrote:

[snip]

 The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
 output signal, but there seems to be no HDMI TX register from which its
 state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
 through I2C ? How long is the PHY expected to take to set TX_READY to 0
 ?
>>> TX_READY can be read from register 0x1A of phy, BIT(2) (through
>>> I2C).
>> That's what I thought, I'll poll that then. Do you have any idea how long
>> it's supposed to take, to set an appropriate timeout ?

For 3d tx phy and for 25 MHz input reference clock the power-up
time is ~1ms, there is no data in the docs to power-down time but
it should be similar. Reference clock value is board dependent
and the minimum value for HDMI shall be 13.5MHz.

> On i.MX6 (3D TX PHY) register 0x1a reads as 0x0007 before powering down the 
> PHY (by deasserting TXPWRON) and as 0x immediately after. On RK3288 (MHL 
> PHY) the register reads as 0x0207 and as 0x immediately after deasserting 
> TXPWRON. It seems that one I2C read is a sufficient delay for TX_READY to go 
> low.
>>> Not sure if same offset for all phys though.
>> Most probably not, it would be too easy :-) I'll investigate (which will
>> likely include lots of guesswork). If you can find any information about
>> that (and especially about the MHL and HDMI 2.0 PHYs) that would be very
>> appreciated, as I don't have access to any documentation that mentions a
>> TX_READY bit for those.
> I haven't tested the HDMI 2.0 PHY yet, but I'd be surprised if the TX_READY 
> bit was in the same register at the same position.
>

The info I got the register offset is from an HDMI 2.0 phy :)
Notice that there are a lot of phy versions and some of them
(used in dw-hdmi) maybe customized, I don't think I have access
to that custom phys documentation. Please test the HDMI 2.0 phy
and check if the register is the same, it should be. In the
meantime it would really be helpful if some of the developers
that used dw-hdmi supplied this info about the registers as they
should know exactly what phy was used.

Best regards,
Jose Miguel Abreu