[PATCH 1/1] i2c: rcar: handle RXDMA HW behaviour on Gen3
On Gen3, we can only do RXDMA once per transfer reliably. For that, we
must reset the device, then we can have RXDMA once. This patch
implements this. When there is no reset controller or the reset fails,
RXDMA will be blocked completely. Otherwise, it will be disabled after
the first RXDMA transfer. Based on a commit from the BSP by Hiromitsu
Yamasaki, yet completely refactored to handle multiple read messages
within one transfer.
Signed-off-by: Wolfram Sang
---
Changes since RFC:
* poll reset status bit after reset (special case for I2C IP core).
* refactor I2C reset into seperate function
* improved comments
* use newer reset API (devm_reset_control_get_exclusive)
drivers/i2c/busses/i2c-rcar.c | 54 ---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index c67c0b1a7fc9..b95900769a90 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
/* register offsets */
@@ -111,8 +112,9 @@
#define ID_ARBLOST (1 << 3)
#define ID_NACK(1 << 4)
/* persistent flags */
+#define ID_P_NO_RXDMA (1 << 30) /* HW forbids RXDMA sometimes */
#define ID_P_PM_BLOCKED(1 << 31)
-#define ID_P_MASK ID_P_PM_BLOCKED
+#define ID_P_MASK (ID_P_PM_BLOCKED | ID_P_NO_RXDMA)
enum rcar_i2c_type {
I2C_RCAR_GEN1,
@@ -141,6 +143,8 @@ struct rcar_i2c_priv {
struct dma_chan *dma_rx;
struct scatterlist sg;
enum dma_data_direction dma_direction;
+
+ struct reset_control *rstc;
};
#define rcar_i2c_priv_to_dev(p)((p)->adap.dev.parent)
@@ -371,6 +375,11 @@ static void rcar_i2c_dma_unmap(struct rcar_i2c_priv *priv)
dma_unmap_single(chan->device->dev, sg_dma_address(>sg),
sg_dma_len(>sg), priv->dma_direction);
+ /* Gen3 can only do one RXDMA per transfer and we just completed it */
+ if (priv->devtype == I2C_RCAR_GEN3 &&
+ priv->dma_direction == DMA_FROM_DEVICE)
+ priv->flags |= ID_P_NO_RXDMA;
+
priv->dma_direction = DMA_NONE;
}
@@ -408,8 +417,9 @@ static void rcar_i2c_dma(struct rcar_i2c_priv *priv)
unsigned char *buf;
int len;
- /* Do not use DMA if it's not available or for messages < 8 bytes */
- if (IS_ERR(chan) || msg->len < 8 || !(msg->flags & I2C_M_DMA_SAFE))
+ /* Do various checks to see if DMA is feasible at all */
+ if (IS_ERR(chan) || msg->len < 8 || !(msg->flags & I2C_M_DMA_SAFE) ||
+ (read && priv->flags & ID_P_NO_RXDMA))
return;
if (read) {
@@ -740,6 +750,25 @@ static void rcar_i2c_release_dma(struct rcar_i2c_priv
*priv)
}
}
+/* I2C is a special case, we need to poll the status of a reset */
+static int rcar_i2c_do_reset(struct rcar_i2c_priv *priv)
+{
+ int i, ret;
+
+ ret = reset_control_reset(priv->rstc);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < LOOP_TIMEOUT; i++) {
+ ret = reset_control_status(priv->rstc);
+ if (ret == 0)
+ return 0;
+ udelay(1);
+ }
+
+ return -ETIMEDOUT;
+}
+
static int rcar_i2c_master_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
int num)
@@ -751,6 +780,16 @@ static int rcar_i2c_master_xfer(struct i2c_adapter *adap,
pm_runtime_get_sync(dev);
+ /* Gen3 needs a reset before allowing RXDMA once */
+ if (priv->devtype == I2C_RCAR_GEN3) {
+ priv->flags |= ID_P_NO_RXDMA;
+ if (!IS_ERR(priv->rstc)) {
+ ret = rcar_i2c_do_reset(priv);
+ if (ret == 0)
+ priv->flags &= ~ID_P_NO_RXDMA;
+ }
+ }
+
rcar_i2c_init(priv);
ret = rcar_i2c_bus_barrier(priv);
@@ -921,6 +960,15 @@ static int rcar_i2c_probe(struct platform_device *pdev)
if (ret < 0)
goto out_pm_put;
+ if (priv->devtype == I2C_RCAR_GEN3) {
+ priv->rstc = devm_reset_control_get_exclusive(>dev, NULL);
+ if (!IS_ERR(priv->rstc)) {
+ ret = reset_control_status(priv->rstc);
+ if (ret < 0)
+ priv->rstc = ERR_PTR(-ENOTSUPP);
+ }
+ }
+
/* Stay always active when multi-master to keep arbitration working */
if (of_property_read_bool(dev->of_node, "multi-master"))
priv->flags |= ID_P_PM_BLOCKED;
--
2.11.0
[PATCH 0/1] i2c: rcar: handle RXDMA HW behaviour on Gen3
As mentioned in the patch description, this patch works around a HW issue on Renesas R-Car Gen3 SoCs. It had not been discovered yet because it only happens when clearing DMA enable bits is too late because of latency. To reproduce the problem reliably, the below patch was used [1]. To the best of my knowledge, all Gen3 SoCs are affected, so I didn't add any soc_device_match kind of matching for now. If the situation changes, we can add it. For now, priv->devtype is good. The improvement can be shown by using the following command. Before the patch, executed on a Salvator-XS / R-Car M3-N ES1.0: # i2ctransfer -y 2 w1@0x10 0 r16 w1 0 r16 0x0f 0x07 0x3f 0x20 0x20 0x55 0x05 0x07 0x0f 0x07 0x3f 0x00 0x00 0x00 0x00 0x00 0xfe 0x0f 0x07 0x3f 0x20 0x20 0x55 0x05 0x07 0x0f 0x07 0x3f 0x00 0x00 0x00 0x00 # i2ctransfer -y 2 w1@0x10 0 r16 w1 0 r16 0xfe 0x0f 0x07 0x3f 0x20 0x20 0x55 0x05 0x07 0x0f 0x07 0x3f 0x00 0x00 0x00 0x00 0xfe 0x0f 0x07 0x3f 0x20 0x20 0x55 0x05 0x07 0x0f 0x07 0x3f 0x00 0x00 0x00 0x00 Note the broken first byte (0xfe) after the first successful RXDMA transfer. After the patch (tested with and without CONFIG_RESET_CONTROLLER): # i2ctransfer -y 2 w1@0x10 0 r16 w1 0 r16 0x0f 0x07 0x3f 0x20 0x20 0x55 0x05 0x07 0x0f 0x07 0x3f 0x00 0x00 0x00 0x00 0x00 0x0f 0x07 0x3f 0x20 0x20 0x55 0x05 0x07 0x0f 0x07 0x3f 0x00 0x00 0x00 0x00 0x00 # i2ctransfer -y 2 w1@0x10 0 r16 w1 0 r16 0x0f 0x07 0x3f 0x20 0x20 0x55 0x05 0x07 0x0f 0x07 0x3f 0x00 0x00 0x00 0x00 0x00 0x0f 0x07 0x3f 0x20 0x20 0x55 0x05 0x07 0x0f 0x07 0x3f 0x00 0x00 0x00 0x00 0x00 Looks way better! Patch was tested with current renesas-drivers/master, but should also apply cleanly on i2c/for-next or v4.18-rc2. Please test and comment. Kind regards, Wolfram Wolfram Sang (1): i2c: rcar: handle RXDMA HW behaviour on Gen3 drivers/i2c/busses/i2c-rcar.c | 54 --- 1 file changed, 51 insertions(+), 3 deletions(-) [1] Testcase patch: diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c index d445b5891280..e42cd0121862 100644 --- a/drivers/i2c/busses/i2c-rcar.c +++ b/drivers/i2c/busses/i2c-rcar.c @@ -353,6 +353,7 @@ static void rcar_i2c_dma_unmap(struct rcar_i2c_priv *priv) struct dma_chan *chan = priv->dma_direction == DMA_FROM_DEVICE ? priv->dma_rx : priv->dma_tx; + mdelay(10); /* Disable DMA Master Received/Transmitted */ rcar_i2c_write(priv, ICDMAER, 0); -- 2.11.0
Re: [PATCH] pci: fix I/O space page leak
On Thu, Jun 28, 2018 at 08:22:59AM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 20, 2018 at 08:51:37PM +0300, Sergei Shtylyov wrote:
> > When testing the R-Car PCIe driver on the Condor board, I noticed that iff
> > I left the PCIe PHY driver disabled, the kernel crashed with this BUG:
> >
> > [1.225819] kernel BUG at lib/ioremap.c:72!
> > [1.230007] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> > [1.235496] Modules linked in:
> > [1.238561] CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty
> > #1092
> > [1.245526] Hardware name: Renesas Condor board based on r8a77980 (DT)
> > [1.252075] Workqueue: events deferred_probe_work_func
> > [1.257220] pstate: 8005 (Nzcv daif -PAN -UAO)
> > [1.262024] pc : ioremap_page_range+0x370/0x3c8
> > [1.266558] lr : ioremap_page_range+0x40/0x3c8
> > [1.271002] sp : 08da39e0
> > [1.274317] x29: 08da39e0 x28: 00e80f07
> > [1.279636] x27: 7dfffee0 x26: 0140
> > [1.284954] x25: 7dfffef0 x24: 000fe100
> > [1.290272] x23: 80007b906000 x22: 08ab8000
> > [1.295590] x21: 08bb1d58 x20: 7dfffef0
> > [1.300909] x19: 89c30fb8 x18: 0001
> > [1.306226] x17: 000152d0 x16: 014012d0
> > [1.311544] x15: x14: 0720072007200720
> > [1.316862] x13: 0720072007200720 x12: 0720072007200720
> > [1.322180] x11: 0720072007300730 x10: 00ae
> > [1.327498] x9 : x8 : 7d00
> >
> > [1.332816] x7 : x6 : 0100
> > [1.338134] x5 : x4 : 7b906000
> > [1.343452] x3 : 80007c61a880 x2 : 7dfffeef
> > [1.348770] x1 : 4000 x0 : 00e8fe100f07
> > [1.354090] Process kworker/0:1 (pid: 39, stack limit = 0x
> > (ptrval))
> > [1.361056] Call trace:
> > [1.363504] ioremap_page_range+0x370/0x3c8
> > [1.367695] pci_remap_iospace+0x7c/0xac
> > [1.371624] pci_parse_request_of_pci_ranges+0x13c/0x190
> > [1.376945] rcar_pcie_probe+0x4c/0xb04
> > [1.380786] platform_drv_probe+0x50/0xbc
> > [1.384799] driver_probe_device+0x21c/0x308
> > [1.389072] __device_attach_driver+0x98/0xc8
> > [1.393431] bus_for_each_drv+0x54/0x94
> > [1.397269] __device_attach+0xc4/0x12c
> > [1.401107] device_initial_probe+0x10/0x18
> > [1.405292] bus_probe_device+0x90/0x98
> > [1.409130] deferred_probe_work_func+0xb0/0x150
> > [1.413756] process_one_work+0x12c/0x29c
> > [1.417768] worker_thread+0x200/0x3fc
> > [1.421522] kthread+0x108/0x134
> > [1.424755] ret_from_fork+0x10/0x18
> > [1.428334] Code: f9004ba2 5480 aa0003fb 1748 (d421)
> >
> > It turned out that pci_remap_iospace() wasn't undone when the driver's
> > probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER,
> > the probe was retried, finally causing the BUG due to trying to remap
> > already remapped pages.
> >
> > The most feasible solution seems to introduce devm_pci_remap_iospace()
> > and call it instead of pci_remap_iospace(), so that the pages get unmapped
> > automagically on any probe failure.
> >
> > And while fixing pci_parse_request_of_pci_ranges(), aslo fix the other
> > drivers that have probably copied the bad example...
> >
> > Fixes: 4e64dbe226e7 ("PCI: generic: Expose pci_host_common_probe() for use
> > by other drivers")
> > Fixes: cbce7900598c ("PCI: designware: Make driver arch-agnostic")
> > Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller
> > driver")
> > Fixes: d3c68e0a7e34 ("PCI: faraday: Add Faraday Technology FTPCI100 PCI
> > Host Bridge driver")
> > Fixes: 68a15eb7bd0c ("PCI: v3-semi: Add V3 Semiconductor PCI host driver")
> > Fixes: b7e78170efd4 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe
> > host driver")
> > Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver")
> > Fixes: 637cfacae96f ("PCI: mediatek: Add MediaTek PCIe host controller
> > support")
> > Signed-off-by: Sergei Shtylyov
> > Cc: sta...@vger.kernel.org
>
> Let me know if you want me to take this, Lorenzo, otherwise:
> s/pci: fix/PCI: Fix/ and
>
> Acked-by: Bjorn Helgaas
Thank you Bjorn, yes it could go in as a fix but IMO it has to be split,
more so given the stable tag (and I think that each "Fixes" tag should
be self-contained), merging it as-is would give Greg (and us) a
headache when it comes to backporting it.
Honestly I think it is best to split it up and send it for v4.19 but
I am happy to hear other options.
Lorenzo
> > ---
> > The patch is against the 'master' branch of Bjorn Helgaas' 'pci.git' repo...
> > It has only been tested with the R-Car PCIe driver...
> >
> > drivers/pci/controller/dwc/pcie-designware-host.c |3 +
> > drivers/pci/controller/pci-aardvark.c |2 -
> >
Re: [PATCH] arm64: dts: renesas: r8a77965: Add second port to rcar_sound placeholder
On Thu, Jun 28, 2018 at 2:43 PM Simon Horman wrote:
> This node is just a placeholder but fills that function better if it does
> not trigger build warnings. This update satisfies the requirement that
> nodes with #address-cells/#size-cells properties have more than one child
> node.
>
> This is flagged by dtc as follows:
> # make dtbs W=1
> arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dtb: Warning
> (graph_child_address): /soc/sound@ec50/ports: graph node has single child
> node 'port@0', #address-cells/#size-cells are not necessary
> arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dtb: Warning
> (graph_child_address): /soc/sound@ec50/ports: graph node has single child
> node 'port@0', #address-cells/#size-cells are not necessary
>
> Signed-off-by: Simon Horman
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] pci: fix I/O space page leak
On Wed, Jun 20, 2018 at 08:51:37PM +0300, Sergei Shtylyov wrote:
> When testing the R-Car PCIe driver on the Condor board, I noticed that iff
> I left the PCIe PHY driver disabled, the kernel crashed with this BUG:
>
> [1.225819] kernel BUG at lib/ioremap.c:72!
> [1.230007] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [1.235496] Modules linked in:
> [1.238561] CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092
> [1.245526] Hardware name: Renesas Condor board based on r8a77980 (DT)
> [1.252075] Workqueue: events deferred_probe_work_func
> [1.257220] pstate: 8005 (Nzcv daif -PAN -UAO)
> [1.262024] pc : ioremap_page_range+0x370/0x3c8
> [1.266558] lr : ioremap_page_range+0x40/0x3c8
> [1.271002] sp : 08da39e0
> [1.274317] x29: 08da39e0 x28: 00e80f07
> [1.279636] x27: 7dfffee0 x26: 0140
> [1.284954] x25: 7dfffef0 x24: 000fe100
> [1.290272] x23: 80007b906000 x22: 08ab8000
> [1.295590] x21: 08bb1d58 x20: 7dfffef0
> [1.300909] x19: 89c30fb8 x18: 0001
> [1.306226] x17: 000152d0 x16: 014012d0
> [1.311544] x15: x14: 0720072007200720
> [1.316862] x13: 0720072007200720 x12: 0720072007200720
> [1.322180] x11: 0720072007300730 x10: 00ae
> [1.327498] x9 : x8 : 7d00
>
> [1.332816] x7 : x6 : 0100
> [1.338134] x5 : x4 : 7b906000
> [1.343452] x3 : 80007c61a880 x2 : 7dfffeef
> [1.348770] x1 : 4000 x0 : 00e8fe100f07
> [1.354090] Process kworker/0:1 (pid: 39, stack limit = 0x
> (ptrval))
> [1.361056] Call trace:
> [1.363504] ioremap_page_range+0x370/0x3c8
> [1.367695] pci_remap_iospace+0x7c/0xac
> [1.371624] pci_parse_request_of_pci_ranges+0x13c/0x190
> [1.376945] rcar_pcie_probe+0x4c/0xb04
> [1.380786] platform_drv_probe+0x50/0xbc
> [1.384799] driver_probe_device+0x21c/0x308
> [1.389072] __device_attach_driver+0x98/0xc8
> [1.393431] bus_for_each_drv+0x54/0x94
> [1.397269] __device_attach+0xc4/0x12c
> [1.401107] device_initial_probe+0x10/0x18
> [1.405292] bus_probe_device+0x90/0x98
> [1.409130] deferred_probe_work_func+0xb0/0x150
> [1.413756] process_one_work+0x12c/0x29c
> [1.417768] worker_thread+0x200/0x3fc
> [1.421522] kthread+0x108/0x134
> [1.424755] ret_from_fork+0x10/0x18
> [1.428334] Code: f9004ba2 5480 aa0003fb 1748 (d421)
>
> It turned out that pci_remap_iospace() wasn't undone when the driver's
> probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER,
> the probe was retried, finally causing the BUG due to trying to remap
> already remapped pages.
>
> The most feasible solution seems to introduce devm_pci_remap_iospace()
> and call it instead of pci_remap_iospace(), so that the pages get unmapped
> automagically on any probe failure.
>
> And while fixing pci_parse_request_of_pci_ranges(), aslo fix the other
> drivers that have probably copied the bad example...
>
> Fixes: 4e64dbe226e7 ("PCI: generic: Expose pci_host_common_probe() for use by
> other drivers")
> Fixes: cbce7900598c ("PCI: designware: Make driver arch-agnostic")
> Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
> Fixes: d3c68e0a7e34 ("PCI: faraday: Add Faraday Technology FTPCI100 PCI Host
> Bridge driver")
> Fixes: 68a15eb7bd0c ("PCI: v3-semi: Add V3 Semiconductor PCI host driver")
> Fixes: b7e78170efd4 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host
> driver")
> Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver")
> Fixes: 637cfacae96f ("PCI: mediatek: Add MediaTek PCIe host controller
> support")
> Signed-off-by: Sergei Shtylyov
> Cc: sta...@vger.kernel.org
Let me know if you want me to take this, Lorenzo, otherwise:
s/pci: fix/PCI: Fix/ and
Acked-by: Bjorn Helgaas
> ---
> The patch is against the 'master' branch of Bjorn Helgaas' 'pci.git' repo...
> It has only been tested with the R-Car PCIe driver...
>
> drivers/pci/controller/dwc/pcie-designware-host.c |3 +
> drivers/pci/controller/pci-aardvark.c |2 -
> drivers/pci/controller/pci-ftpci100.c |2 -
> drivers/pci/controller/pci-v3-semi.c |2 -
> drivers/pci/controller/pci-versatile.c|2 -
> drivers/pci/controller/pci-xgene.c|2 -
> drivers/pci/controller/pcie-mediatek.c|2 -
> drivers/pci/of.c |2 -
> drivers/pci/pci.c | 38
> ++
> include/linux/pci.h |2 +
> 10 files changed, 49 insertions(+), 8 deletions(-)
>
> Index: pci/drivers/pci/controller/dwc/pcie-designware-host.c
Re: [PATCH 2/2] mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in abort
On Thu, Jun 28, 2018 at 1:53 PM Yoshihiro Shimoda
wrote:
> This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE
> flag cannot be cleared because tmio_mmc_core sets the host->data
> to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma().
>
> So, this patch clears the SDHI_INTERNAL_DMAC_RX_IN_USE in
> the renesas_sdhi_internal_dmac_abort_dma() anyway. This doesn't
> cause any side effects.
>
> Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
> SoCs")
> Cc: # v4.17+
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch
Hi Shimoda-san,
On Thu, Jun 28, 2018 at 1:53 PM Yoshihiro Shimoda
wrote:
> This patch fixes an issue that lacks the dma_unmap_sg() calling in
> the error patch of renesas_sdhi_internal_dmac_start_dma().
Nice catch!
Thanks for your patch!
> Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
> SoCs")
> Cc: # v4.17+
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -173,8 +173,11 @@
> if (data->flags & MMC_DATA_READ) {
> dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
> if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
> - test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
> _flags))
> + test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
> _flags)) {
> + dma_unmap_sg(>pdev->dev, sg, host->sg_len,
> +mmc_get_dma_dir(data));
Given there is already a call to dma_unmap_sg() a few lines earlier , you
may want to introduce a new label before force_pio, and move the call to
dma_unmap_sg() there.
> goto force_pio;
> + }
> } else {
> dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
> }
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 v9 3/5] ARM: dts: Renesas R9A06G032 base device tree file
Hi Simon,
On Thu, Jun 28, 2018 at 2:16 PM Simon Horman wrote:
> On Thu, Jun 28, 2018 at 02:00:32PM +0200, Simon Horman wrote:
> > On Thu, Jun 14, 2018 at 11:56:32AM +0100, Michel Pollet wrote:
> > > This adds the Renesas R9A06G032 bare bone support.
> > >
> > > This currently only handles the SYSCTRL block note,
> > > generic parts (gic, architected timer) and a UART.
> > >
> > > Signed-off-by: Michel Pollet
> > > Reviewed-by: Geert Uytterhoeven
> > > Reviewed-by: Simon Horman
> >
> > Thanks, applied with the following appended:
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 9d5eeff51b5f..4c85ac04872d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1969,6 +1969,7 @@ S: Supported
> > F: arch/arm/boot/dts/emev2*
> > F: arch/arm/boot/dts/r7s*
> > F: arch/arm/boot/dts/r8a*
> > +F: arch/arm/boot/dts/r9a*
> > F: arch/arm/boot/dts/sh*
> > F: arch/arm/configs/shmobile_defconfig
> > F: arch/arm/include/debug/renesas-scif.S
>
> One more update.
>
> dt-bindings/clock/r9a06g032-sysctrl.h is not present in v4.18-rc1,
> current base of the renesas tree and likely base for the rest of the v4.19
> development cycle.
>
> Accordingly I have removed the include of that header and replaced
> the use of symbols it defines with numeric constants. The result is below.
Oh right. Thanks!
> Please:
> 1) Check that this is correct and
Looks good to me, except for the bogus "fixes" and "SoB" below
(bad squash?)
> From: Michel Pollet
> Subject: [PATCH] ARM: dts: Renesas R9A06G032 base device tree file
>
> This adds the Renesas R9A06G032 bare bone support.
>
> This currently only handles the SYSCTRL block note,
> generic parts (gic, architected timer) and a UART.
>
> Signed-off-by: Michel Pollet
> Reviewed-by: Geert Uytterhoeven
> [simon: updated MAINTAINERS file
> [simon: do not use r9a06g032-sysctrl.h as it is not in the renesas tree yet]
> Signed-off-by: Simon Horman
>
> fixes
^
>
> Signed-off-by: Simon Horman
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
[PATCH] arm64: dts: renesas: r8a77965: Add second port to rcar_sound placeholder
This node is just a placeholder but fills that function better if it does
not trigger build warnings. This update satisfies the requirement that
nodes with #address-cells/#size-cells properties have more than one child
node.
This is flagged by dtc as follows:
# make dtbs W=1
arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dtb: Warning
(graph_child_address): /soc/sound@ec50/ports: graph node has single child
node 'port@0', #address-cells/#size-cells are not necessary
arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dtb: Warning
(graph_child_address): /soc/sound@ec50/ports: graph node has single child
node 'port@0', #address-cells/#size-cells are not necessary
Signed-off-by: Simon Horman
---
Based on renesas-devel-20180628-v4.18-rc2
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index be8631dff1b4..a37749caf40e 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1269,6 +1269,9 @@
port@0 {
reg = <0>;
};
+ port@1 {
+ reg = <1>;
+ };
};
};
--
2.11.0
[PATCH 1/2] mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch
This patch fixes an issue that lacks the dma_unmap_sg() calling in
the error patch of renesas_sdhi_internal_dmac_start_dma().
Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
SoCs")
Cc: # v4.17+
Signed-off-by: Yoshihiro Shimoda
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index f7f9773..d503511 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -173,8 +173,11 @@
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
- test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
_flags))
+ test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE,
_flags)) {
+ dma_unmap_sg(>pdev->dev, sg, host->sg_len,
+mmc_get_dma_dir(data));
goto force_pio;
+ }
} else {
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
}
--
1.9.1
[PATCH 2/2] mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in abort
This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE
flag cannot be cleared because tmio_mmc_core sets the host->data
to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma().
So, this patch clears the SDHI_INTERNAL_DMAC_RX_IN_USE in
the renesas_sdhi_internal_dmac_abort_dma() anyway. This doesn't
cause any side effects.
Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old
SoCs")
Cc: # v4.17+
Signed-off-by: Yoshihiro Shimoda
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index d503511..3669981 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -139,8 +139,7 @@
renesas_sdhi_internal_dmac_dm_write(host, DM_CM_RST,
RST_RESERVED_BITS | val);
- if (host->data && host->data->flags & MMC_DATA_READ)
- clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
+ clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
renesas_sdhi_internal_dmac_enable_dma(host, true);
}
--
1.9.1
[PATCH 0/2] mmc: renesas_sdhi_internal_dmac: fix two issues for error path
This patch set is based on the mmc.git / fixes branch. Yoshihiro Shimoda (2): mmc: renesas_sdhi_internal_dmac: Fix missing unmap in error patch mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in abort drivers/mmc/host/renesas_sdhi_internal_dmac.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- 1.9.1
Re: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
> Note that reset controller support is optional, so we want to add > > select RESET_CONTROLLER if ARCH_RENESAS && ARM64 > > to the I2C_RCAR section drivers/i2c/busses/Kconfig. Else reset will fail > silently. Actually, no. I use a non-optional reset_controller_get[1], so I will get an ERR_PTR when !RESET_CONTROLLER. And I check for this ERR_PTR. So, it will work with !RESET_CONTROLLER, just without RXDMA always then. That worked fine with the old patch, need to test my new version now. [1] In fact, this function is deprecated and I replaced it with the now more explicit reset_control_get_exclusive(). Plus devm_*, of course. signature.asc Description: PGP signature
Re: [PATCH] pinctrl: sh-pfc: fix a null pointer dereference of drive strength information
Hi Niklas,
On Thu, Jun 28, 2018 at 2:41 AM Niklas Söderlund
wrote:
> On 2018-06-27 10:27:54 +0200, Geert Uytterhoeven wrote:
> > On Wed, Jun 27, 2018 at 8:01 AM Niklas Söderlund
> > wrote:
> > > Not all SoCs describes the drive strength registers. When reading the
> > > sysfs pinconf-pins file on such a SoC this results in a null pointer
> > > dereference. Protect against this dereference and allow reading of the
> > > pinconf-pins by adding a check if the drive strength registers are
> > > described or not.
> > >
> > > Signed-off-by: Niklas Söderlund
> >
> > Thanks for your patch!
> >
> > > This was found on the Eagle board and is based on the latest
> > > renesas/devel branch.
> >
> > I think the real issue is pfc-r8a77990.c setting
> > SH_PFC_PIN_CFG_DRIVE_STRENGTH
> > without providing sh_pfc.drive_regs[].
> > Without that flag set, sh_pfc_pinconf_validate(...,
> > PIN_CONFIG_DRIVE_STRENGTH)
> > would cause an earlier failure.
>
> Ahh I see, thanks for the pointer. I will explore this option as it
> seems like a nicer solution, thanks!
To be 100% clear: the proper solution is to add the missing drive_regs[],
not to remove the flags ;-)
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
