[PATCH v2 2/2] PCI: rcar-pcie: Fix memory leak when no PCIe card is inserted

[Harunobu Kurokawa]

When no PCIe card is inserted, there is a memory leak as
pci_free_resource_list is not called before returning.

Signed-off-by: Harunobu Kurokawa 
---
 drivers/pci/host/pcie-rcar.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 6b73981..70b487c 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1196,6 +1196,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
 
 err_free_bridge:
pci_free_host_bridge(bridge);
+   pci_free_resource_list(>resources);
 
return err;
 }
-- 
2.9.2

[PATCH v2 0/2] PCI: rcar-pcie: Fix memory leak

[Harunobu Kurokawa]

When no PCIe card is inserted, there is a memory leak as
pci_free_resource_list is not called before returning.

v2:
 separate the patch to two files.

Harunobu Kurokawa (1):
  PCI: rcar-pcie: Fix memory leak when no PCIe card is inserted

Lorenzo Pieralisi (1):
  PCI: rcar: Fix error exit path

 drivers/pci/host/pcie-rcar.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

-- 
2.9.2

[PATCH v2 1/2] PCI: rcar: Fix error exit path

[Harunobu Kurokawa]

From: Lorenzo Pieralisi 

Commit 90634e854079 ("PCI: rcar: Convert PCI scan API to
pci_scan_root_bus_bridge()") converted PCI root bus scan API
to the new pci_scan_root_bus_bridge() API; in the process
some error paths were not updated correctly which may cause
memory leaks.

Fix the driver error exit path reinstating the previous correct
error exit behaviour.

Fixes: 90634e854079 ("PCI: rcar: Convert PCI scan API to 
pci_scan_root_bus_bridge()")
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Harunobu Kurokawa 
---
 drivers/pci/host/pcie-rcar.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index ac80fbb..6b73981 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -471,10 +471,8 @@ static int rcar_pcie_enable(struct rcar_pcie *pcie)
bridge->msi = >msi.chip;
 
ret = pci_scan_root_bus_bridge(bridge);
-   if (ret < 0) {
-   kfree(bridge);
+   if (ret < 0)
return ret;
-   }
 
bus = bridge->bus;
 
@@ -1190,14 +1188,15 @@ static int rcar_pcie_probe(struct platform_device *pdev)
 
return 0;
 
-err_free_bridge:
-   pci_free_host_bridge(bridge);
-
 err_pm_put:
pm_runtime_put(dev);
 
 err_pm_disable:
pm_runtime_disable(dev);
+
+err_free_bridge:
+   pci_free_host_bridge(bridge);
+
return err;
 }
 
-- 
2.9.2

[PATCH v2 2/3] usb: gadget: udc: renesas_usb3: add support for R-Car H3 ES2.0

[Yoshihiro Shimoda]

This patch adds support for R-Car H3 ES2.0. Since this SoC revision
doesn't need workaround for vbus detection and number of ramif is
increased. So, this driver uses soc_device_match() to detect it.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/renesas_usb3.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 3415d32..aa2b185 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2487,22 +2488,36 @@ static void renesas_usb3_init_ram(struct renesas_usb3 
*usb3, struct device *dev,
}
 }
 
-static const struct renesas_usb3_priv renesas_usb3_priv_r8a7795 = {
+static const struct renesas_usb3_priv renesas_usb3_priv_r8a7795_es1 = {
.ramsize_per_ramif = SZ_16K,
.num_ramif = 2,
.ramsize_per_pipe = SZ_4K,
.workaround_for_vbus = true,
 };
 
+static const struct renesas_usb3_priv renesas_usb3_priv_gen3 = {
+   .ramsize_per_ramif = SZ_16K,
+   .num_ramif = 4,
+   .ramsize_per_pipe = SZ_4K,
+};
+
 static const struct of_device_id usb3_of_match[] = {
{
.compatible = "renesas,r8a7795-usb3-peri",
-   .data = _usb3_priv_r8a7795,
+   .data = _usb3_priv_gen3,
},
{ },
 };
 MODULE_DEVICE_TABLE(of, usb3_of_match);
 
+static const struct soc_device_attribute renesas_usb3_quirks_match[] = {
+   {
+   .soc_id = "r8a7795", .revision = "ES1.*",
+   .data = _usb3_priv_r8a7795_es1,
+   },
+   { /* sentinel */ },
+};
+
 static const unsigned int renesas_usb3_cable[] = {
EXTCON_USB,
EXTCON_USB_HOST,
@@ -2516,11 +2531,17 @@ static int renesas_usb3_probe(struct platform_device 
*pdev)
const struct of_device_id *match;
int irq, ret;
const struct renesas_usb3_priv *priv;
+   const struct soc_device_attribute *attr;
 
match = of_match_node(usb3_of_match, pdev->dev.of_node);
if (!match)
return -ENODEV;
-   priv = match->data;
+
+   attr = soc_device_match(renesas_usb3_quirks_match);
+   if (attr)
+   priv = attr->data;
+   else
+   priv = match->data;
 
irq = platform_get_irq(pdev, 0);
if (irq < 0)
-- 
1.9.1

[PATCH v2 3/3] usb: gadget: udc: renesas_usb3: add support for R-Car M3-W

[Yoshihiro Shimoda]

This patch adds support for R-Car M3-W. This patch also adds R-Car
Gen3 generic version's compatible and changes ".compatible" in
the usb3_of_match from "renesas,r8a7796-usb3-peri" to
"renesas,rcar-gen3-usb3-peri".

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/usb/renesas_usb3.txt | 16 +---
 drivers/usb/gadget/udc/renesas_usb3.c  |  2 +-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt 
b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
index 8d52766..e280258 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
@@ -3,20 +3,30 @@ Renesas Electronics USB3.0 Peripheral driver
 Required properties:
   - compatible: Must contain one of the following:
- "renesas,r8a7795-usb3-peri"
+   - "renesas,r8a7796-usb3-peri"
+   - "renesas,rcar-gen3-usb3-peri" for a generic R-Car Gen3 compatible
+ device
+
+When compatible with the generic version, nodes must list the
+SoC-specific version corresponding to the platform first
+followed by the generic version.
+
   - reg: Base address and length of the register for the USB3.0 Peripheral
   - interrupts: Interrupt specifier for the USB3.0 Peripheral
   - clocks: clock phandle and specifier pair
 
-Example:
+Example of R-Car H3 ES1.x:
usb3_peri0: usb@ee02 {
-   compatible = "renesas,r8a7795-usb3-peri";
+   compatible = "renesas,r8a7795-usb3-peri",
+"renesas,rcar-gen3-usb3-peri";
reg = <0 0xee02 0 0x400>;
interrupts = ;
clocks = < CPG_MOD 328>;
};
 
usb3_peri1: usb@ee06 {
-   compatible = "renesas,r8a7795-usb3-peri";
+   compatible = "renesas,r8a7795-usb3-peri",
+"renesas,rcar-gen3-usb3-peri";
reg = <0 0xee06 0 0x400>;
interrupts = ;
clocks = < CPG_MOD 327>;
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index aa2b185..b1e166c 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -2503,7 +2503,7 @@ static void renesas_usb3_init_ram(struct renesas_usb3 
*usb3, struct device *dev,
 
 static const struct of_device_id usb3_of_match[] = {
{
-   .compatible = "renesas,r8a7795-usb3-peri",
+   .compatible = "renesas,rcar-gen3-usb3-peri",
.data = _usb3_priv_gen3,
},
{ },
-- 
1.9.1

[PATCH v2 1/3] usb: gadget: udc: renesas_usb3: add debugfs to set the b-device mode

[Yoshihiro Shimoda]

This patch adds debugfs to set the "b-device" mode for using a board
which is not connected to the ID pin (e.g. CN11 on Salvator-X).
If we want to use peripheral mode on such a board, we have to disable
VBUS output first. So, this patch can set such a mode as the following:

 # mount -t debugfs none /sys/kernel/debug
 # modprobe renesas_usb3
 # modprobe g_mass_storage file=/dev/shm/test.bin
 # echo 1 > /sys/kernel/debug/ee02.usb/b_device

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/renesas_usb3.c | 78 ++-
 1 file changed, 76 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index d827832..3415d32 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -8,6 +8,7 @@
  * the Free Software Foundation; version 2 of the License.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -344,6 +346,7 @@ struct renesas_usb3 {
bool workaround_for_vbus;
bool extcon_host;   /* check id and set EXTCON_USB_HOST */
bool extcon_usb;/* check vbus and set EXTCON_USB */
+   bool forced_b_device;
 };
 
 #define gadget_to_renesas_usb3(_gadget)\
@@ -660,7 +663,9 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
bool host, bool a_dev)
spin_lock_irqsave(>lock, flags);
usb3_set_mode(usb3, host);
usb3_vbus_out(usb3, a_dev);
-   if (!host && a_dev) /* for A-Peripheral */
+   /* for A-Peripheral or forced B-device mode */
+   if ((!host && a_dev) ||
+   (usb3->workaround_for_vbus && usb3->forced_b_device))
usb3_connect(usb3);
spin_unlock_irqrestore(>lock, flags);
 }
@@ -674,7 +679,7 @@ static void usb3_check_id(struct renesas_usb3 *usb3)
 {
usb3->extcon_host = usb3_is_a_device(usb3);
 
-   if (usb3->extcon_host)
+   if (usb3->extcon_host && !usb3->forced_b_device)
usb3_mode_config(usb3, true, true);
else
usb3_mode_config(usb3, false, false);
@@ -2266,6 +2271,9 @@ static ssize_t role_store(struct device *dev, struct 
device_attribute *attr,
if (!usb3->driver)
return -ENODEV;
 
+   if (usb3->forced_b_device)
+   return -EBUSY;
+
if (!strncmp(buf, "host", strlen("host")))
new_mode_is_host = true;
else if (!strncmp(buf, "peripheral", strlen("peripheral")))
@@ -2293,6 +2301,70 @@ static ssize_t role_show(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RW(role);
 
+static int renesas_usb3_b_device_show(struct seq_file *s, void *unused)
+{
+   struct renesas_usb3 *usb3 = s->private;
+
+   seq_printf(s, "%d\n", usb3->forced_b_device);
+
+   return 0;
+}
+
+static int renesas_usb3_b_device_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, renesas_usb3_b_device_show, inode->i_private);
+}
+
+static ssize_t renesas_usb3_b_device_write(struct file *file,
+  const char __user *ubuf,
+  size_t count, loff_t *ppos)
+{
+   struct seq_file *s = file->private_data;
+   struct renesas_usb3 *usb3 = s->private;
+   char buf[32];
+
+   if (!usb3->driver)
+   return -ENODEV;
+
+   if (copy_from_user(, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
+   return -EFAULT;
+
+   if (!strncmp(buf, "1", 1))
+   usb3->forced_b_device = true;
+   else
+   usb3->forced_b_device = false;
+
+   /* Let this driver call usb3_connect() anyway */
+   usb3_check_id(usb3);
+
+   return count;
+}
+
+static const struct file_operations renesas_usb3_b_device_fops = {
+   .open = renesas_usb3_b_device_open,
+   .write = renesas_usb3_b_device_write,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
+
+static void renesas_usb3_debugfs_init(struct renesas_usb3 *usb3,
+ struct device *dev)
+{
+   struct dentry *root, *file;
+
+   root = debugfs_create_dir(dev_name(dev), NULL);
+   if (IS_ERR_OR_NULL(root)) {
+   dev_info(dev, "%s: Can't create the root\n", __func__);
+   return;
+   }
+
+   file = debugfs_create_file("b_device", 0644, root, usb3,
+  _usb3_b_device_fops);
+   if (!file)
+   dev_info(dev, "%s: Can't create debugfs mode\n", __func__);
+}
+
 /*--- platform_driver */
 static int renesas_usb3_remove(struct platform_device *pdev)
 {
@@ -2510,6 +2582,8 @@ static int renesas_usb3_probe(struct platform_device 
*pdev)
 
usb3->workaround_for_vbus = 

[PATCH v2 0/3] usb: gadget: udc: renesas_usb3: add support for some R-Car Gen3 SoCs

[Yoshihiro Shimoda]

This patch set is based on the latest Felipe's usb.git / testing/next branch
(the commit id = 5771a8c08880cdca3bfb4a3fc6d309d6bba20877)

Changes from v1:
 - The usb3_of_match has "renesas,rcar-gen3-usb3-peri" only in patch 3.

Yoshihiro Shimoda (3):
  usb: gadget: udc: renesas_usb3: add debugfs to set the b-device mode
  usb: gadget: udc: renesas_usb3: add support for R-Car H3 ES2.0
  usb: gadget: udc: renesas_usb3: add support for R-Car M3-W

 .../devicetree/bindings/usb/renesas_usb3.txt   |  16 ++-
 drivers/usb/gadget/udc/renesas_usb3.c  | 107 +++--
 2 files changed, 114 insertions(+), 9 deletions(-)

-- 
1.9.1

RE: [PATCH 3/3] usb: gadget: udc: renesas_usb3: add support for R-Car M3-W

[Yoshihiro Shimoda]

Hi Rob,

> -Original Message-
> From: Rob Herring
> Sent: Friday, August 4, 2017 7:28 AM
> 
> On Fri, Jul 28, 2017 at 09:16:59PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds support for R-Car M3-W. This patch also adds R-Car
> > Gen3 generic version's compatible.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  Documentation/devicetree/bindings/usb/renesas_usb3.txt | 16 
> > +---
> >  drivers/usb/gadget/udc/renesas_usb3.c  |  8 
> >  2 files changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> > index 8d52766..e280258 100644
> > --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> > +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> > @@ -3,20 +3,30 @@ Renesas Electronics USB3.0 Peripheral driver
> >  Required properties:
> >- compatible: Must contain one of the following:
> > - "renesas,r8a7795-usb3-peri"
> > +   - "renesas,r8a7796-usb3-peri"
> > +   - "renesas,rcar-gen3-usb3-peri" for a generic R-Car Gen3 compatible
> > + device
> > +
> > +When compatible with the generic version, nodes must list the
> > +SoC-specific version corresponding to the platform first
> > +followed by the generic version.
> > +
> >- reg: Base address and length of the register for the USB3.0 Peripheral
> >- interrupts: Interrupt specifier for the USB3.0 Peripheral
> >- clocks: clock phandle and specifier pair
> >
> > -Example:
> > +Example of R-Car H3 ES1.x:
> > usb3_peri0: usb@ee02 {
> > -   compatible = "renesas,r8a7795-usb3-peri";
> > +   compatible = "renesas,r8a7795-usb3-peri",
> > +"renesas,rcar-gen3-usb3-peri";
> > reg = <0 0xee02 0 0x400>;
> > interrupts = ;
> > clocks = < CPG_MOD 328>;
> > };
> >
> > usb3_peri1: usb@ee06 {
> > -   compatible = "renesas,r8a7795-usb3-peri";
> > +   compatible = "renesas,r8a7795-usb3-peri",
> > +"renesas,rcar-gen3-usb3-peri";
> > reg = <0 0xee06 0 0x400>;
> > interrupts = ;
> > clocks = < CPG_MOD 327>;
> > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > b/drivers/usb/gadget/udc/renesas_usb3.c
> > index aa2b185..45410f3 100644
> > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > @@ -2506,6 +2506,14 @@ static void renesas_usb3_init_ram(struct 
> > renesas_usb3 *usb3, struct device *dev,
> > .compatible = "renesas,r8a7795-usb3-peri",
> > .data = _usb3_priv_gen3,
> > },
> > +   {
> > +   .compatible = "renesas,r8a7796-usb3-peri",
> > +   .data = _usb3_priv_gen3,
> > +   },
> > +   {
> > +   .compatible = "renesas,rcar-gen3-usb3-peri",
> > +   .data = _usb3_priv_gen3,
> 
> What's the point of a common fallback if you list all the compatibles in
> the driver?

Thank you for the comment!
The renesas,r8a779[56]-usb3-peri don't need anymore.
So, I will fix this patch.

Best regards,
Yoshihiro Shimoda

> > +   },
> > { },
> >  };
> >  MODULE_DEVICE_TABLE(of, usb3_of_match);
> > --
> > 1.9.1
> >

Re: [PATCH 1/4] dt-bindings: adi,adv7511.txt: document cec clock

[Rob Herring]

On Sun, Jul 30, 2017 at 03:07:40PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Document the cec clock binding.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring 

Re: [RFT] arm64: dts: renesas: salvator-common: enable SDR104 for SD cards

[Simon Horman]

On Thu, Aug 03, 2017 at 05:54:00PM +0200, Simon Horman wrote:
> On Thu, Aug 03, 2017 at 09:43:51AM +0200, Simon Horman wrote:
> > On Wed, Aug 02, 2017 at 10:13:11PM +0200, Wolfram Sang wrote:
> > > Tests showed that SDHI driver problems have been solved and SDR104 works
> > > now reliably on both Salvator-X SD card slots, both with an R-Car H3
> > > (r8a7795 ES1.0) and R-Car M3 (r8a7796 ES 1.0). So, finally, enable it.
> > > 
> > > Signed-off-by: Wolfram Sang 
> > > ---
> > > 
> > > Awesome, awesome! For the last two days, I did various tests with my 
> > > boards and
> > > SD cards and SDR104 worked absolutely reliably :D Even the problematic 
> > > card I
> > > had works flawlessly. I couldn't trigger the known failures anymore. 
> > > Although I
> > > tried, I can't point to a single patch which "fixed" the issue. It is the
> > > constant work on dealing with smaller issues which makes SDR104 work at 
> > > the end
> > > of the day. However, two patches are likely a bigger part of the cake:
> > > 
> > > 43b0b361b01700 ("mmc: tmio: always get number of taps")
> > > -> Already upstream. This fixed retuning on card changes.
> > > 
> > > 85b81aa16ec4ed ("mmc: tmio: fix CMD12 (STOP) handling")
> > > -> In mmc/next. This allows to handle tuning errors gracefully and to 
> > > retune.
> > > 
> > > With the freshly submitted Gen3 DMA patches, we also get nice transfer 
> > > speeds :)
> > > 
> > > This patch is based on renesas-drivers/master as of today. A branch for 
> > > testing
> > > can be found here:
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
> > > renesas/v8-sdr104
> > > 
> > > All patches needed for reliable SDR104 are already upstream or in 
> > > mmc/next. The
> > > above branch only adds another patch to enable DMA on Gen3. It is not 
> > > strictly
> > > needed, but very nice to have. I think it would be cool to get both 
> > > patches
> > > into v4.14.
> > > 
> > > Looking forward to other testers. Simon, do you have some time for this?
> > 
> > Yes, I should be able to run this through my - until now thought to be
> > broken - test case this week.
> > 
> > It would be very nice to be able to get closure on this :)
> 
> Awesome indeed!
> 
> I have tested this using my test-case which is to remove and then
> re-insert a Samsung MB-SD32D/EU card. Slot SDHI3 was used although I expect
> that is not an important parameter.
> 
> A bisection indicates the above test works since
> 85b81aa16ec4ed ("mmc: tmio: fix CMD12 (STOP) handling")
> which was included in v4.12 and highlighted by you above.
> 
> Tested-by: Simon Horman 
> 
> I will apply this for v4.14 in the near future.

Oops, I got a little excited there.
As it is an "RFT" I'm happy to apply it if you repost
it or otherwise indicate that is what you would like to happen.

Re: [RFT] arm64: dts: renesas: salvator-common: enable SDR104 for SD cards

[Simon Horman]

On Thu, Aug 03, 2017 at 09:43:51AM +0200, Simon Horman wrote:
> On Wed, Aug 02, 2017 at 10:13:11PM +0200, Wolfram Sang wrote:
> > Tests showed that SDHI driver problems have been solved and SDR104 works
> > now reliably on both Salvator-X SD card slots, both with an R-Car H3
> > (r8a7795 ES1.0) and R-Car M3 (r8a7796 ES 1.0). So, finally, enable it.
> > 
> > Signed-off-by: Wolfram Sang 
> > ---
> > 
> > Awesome, awesome! For the last two days, I did various tests with my boards 
> > and
> > SD cards and SDR104 worked absolutely reliably :D Even the problematic card 
> > I
> > had works flawlessly. I couldn't trigger the known failures anymore. 
> > Although I
> > tried, I can't point to a single patch which "fixed" the issue. It is the
> > constant work on dealing with smaller issues which makes SDR104 work at the 
> > end
> > of the day. However, two patches are likely a bigger part of the cake:
> > 
> > 43b0b361b01700 ("mmc: tmio: always get number of taps")
> > -> Already upstream. This fixed retuning on card changes.
> > 
> > 85b81aa16ec4ed ("mmc: tmio: fix CMD12 (STOP) handling")
> > -> In mmc/next. This allows to handle tuning errors gracefully and to 
> > retune.
> > 
> > With the freshly submitted Gen3 DMA patches, we also get nice transfer 
> > speeds :)
> > 
> > This patch is based on renesas-drivers/master as of today. A branch for 
> > testing
> > can be found here:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
> > renesas/v8-sdr104
> > 
> > All patches needed for reliable SDR104 are already upstream or in mmc/next. 
> > The
> > above branch only adds another patch to enable DMA on Gen3. It is not 
> > strictly
> > needed, but very nice to have. I think it would be cool to get both patches
> > into v4.14.
> > 
> > Looking forward to other testers. Simon, do you have some time for this?
> 
> Yes, I should be able to run this through my - until now thought to be
> broken - test case this week.
> 
> It would be very nice to be able to get closure on this :)

Awesome indeed!

I have tested this using my test-case which is to remove and then
re-insert a Samsung MB-SD32D/EU card. Slot SDHI3 was used although I expect
that is not an important parameter.

A bisection indicates the above test works since
85b81aa16ec4ed ("mmc: tmio: fix CMD12 (STOP) handling")
which was included in v4.12 and highlighted by you above.

Tested-by: Simon Horman 

I will apply this for v4.14 in the near future.

Re: [PATCH] media: i2c: adv748x: Store the pixel rate ctrl on CSI objects

[Niklas Söderlund]

Hi Kieran,

On 2017-08-03 14:50:23 +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The current implementation has to search the list of controls for the
> pixel rate control, each time it is set.  This can be optimised easily
> by storing the ctrl pointer in the CSI/TX object, and referencing that
> directly.
> 
> While at it, fix up a missing blank line also highlighted in review
> comments.
> 
> Signed-off-by: Kieran Bingham 

It won't apply cleanly to the media-tree since there already is a commit 
there which cleans-up the unused variable in dv748x_csi2_init_controls()

Apart from that:

Tested-by: Niklas Söderlund 

> ---
> Small enhancement and fixup as suggested by Sakari, after driver acceptance.
> 
> Niklas, with my current 8 Camera set up - I can't fully test this change.
> Could you give it a spin if you get chance please?
> 
>  drivers/media/i2c/adv748x/adv748x-afe.c  |  1 +
>  drivers/media/i2c/adv748x/adv748x-csi2.c | 15 +++
>  drivers/media/i2c/adv748x/adv748x.h  |  1 +
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
> b/drivers/media/i2c/adv748x/adv748x-afe.c
> index b33ccfc08708..134d981d69d3 100644
> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> @@ -262,6 +262,7 @@ static int adv748x_afe_g_input_status(struct v4l2_subdev 
> *sd, u32 *status)
>   ret = adv748x_afe_status(afe, status, NULL);
>  
>   mutex_unlock(>mutex);
> +
>   return ret;
>  }
>  
> diff --git a/drivers/media/i2c/adv748x/adv748x-csi2.c 
> b/drivers/media/i2c/adv748x/adv748x-csi2.c
> index b4fee7f52d6a..609d960c0749 100644
> --- a/drivers/media/i2c/adv748x/adv748x-csi2.c
> +++ b/drivers/media/i2c/adv748x/adv748x-csi2.c
> @@ -223,13 +223,12 @@ static const struct v4l2_subdev_ops adv748x_csi2_ops = {
>  
>  int adv748x_csi2_set_pixelrate(struct v4l2_subdev *sd, s64 rate)
>  {
> - struct v4l2_ctrl *ctrl;
> + struct adv748x_csi2 *tx = adv748x_sd_to_csi2(sd);
>  
> - ctrl = v4l2_ctrl_find(sd->ctrl_handler, V4L2_CID_PIXEL_RATE);
> - if (!ctrl)
> + if (!tx->pixel_rate)
>   return -EINVAL;
>  
> - return v4l2_ctrl_s_ctrl_int64(ctrl, rate);
> + return v4l2_ctrl_s_ctrl_int64(tx->pixel_rate, rate);
>  }
>  
>  static int adv748x_csi2_s_ctrl(struct v4l2_ctrl *ctrl)
> @@ -248,12 +247,12 @@ static const struct v4l2_ctrl_ops adv748x_csi2_ctrl_ops 
> = {
>  
>  static int adv748x_csi2_init_controls(struct adv748x_csi2 *tx)
>  {
> - struct v4l2_ctrl *ctrl;
> -
>   v4l2_ctrl_handler_init(>ctrl_hdl, 1);
>  
> - ctrl = v4l2_ctrl_new_std(>ctrl_hdl, _csi2_ctrl_ops,
> -  V4L2_CID_PIXEL_RATE, 1, INT_MAX, 1, 1);
> + tx->pixel_rate = v4l2_ctrl_new_std(>ctrl_hdl,
> +_csi2_ctrl_ops,
> +V4L2_CID_PIXEL_RATE, 1, INT_MAX,
> +1, 1);
>  
>   tx->sd.ctrl_handler = >ctrl_hdl;
>   if (tx->ctrl_hdl.error) {
> diff --git a/drivers/media/i2c/adv748x/adv748x.h 
> b/drivers/media/i2c/adv748x/adv748x.h
> index cc4151b5b31e..6789e2f3bc8c 100644
> --- a/drivers/media/i2c/adv748x/adv748x.h
> +++ b/drivers/media/i2c/adv748x/adv748x.h
> @@ -97,6 +97,7 @@ struct adv748x_csi2 {
>  
>   struct media_pad pads[ADV748X_CSI2_NR_PADS];
>   struct v4l2_ctrl_handler ctrl_hdl;
> + struct v4l2_ctrl *pixel_rate;
>   struct v4l2_subdev sd;
>  };
>  
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

[PATCH] media: i2c: adv748x: Store the pixel rate ctrl on CSI objects

[Kieran Bingham]

From: Kieran Bingham 

The current implementation has to search the list of controls for the
pixel rate control, each time it is set.  This can be optimised easily
by storing the ctrl pointer in the CSI/TX object, and referencing that
directly.

While at it, fix up a missing blank line also highlighted in review
comments.

Signed-off-by: Kieran Bingham 
---
Small enhancement and fixup as suggested by Sakari, after driver acceptance.

Niklas, with my current 8 Camera set up - I can't fully test this change.
Could you give it a spin if you get chance please?

 drivers/media/i2c/adv748x/adv748x-afe.c  |  1 +
 drivers/media/i2c/adv748x/adv748x-csi2.c | 15 +++
 drivers/media/i2c/adv748x/adv748x.h  |  1 +
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
b/drivers/media/i2c/adv748x/adv748x-afe.c
index b33ccfc08708..134d981d69d3 100644
--- a/drivers/media/i2c/adv748x/adv748x-afe.c
+++ b/drivers/media/i2c/adv748x/adv748x-afe.c
@@ -262,6 +262,7 @@ static int adv748x_afe_g_input_status(struct v4l2_subdev 
*sd, u32 *status)
ret = adv748x_afe_status(afe, status, NULL);
 
mutex_unlock(>mutex);
+
return ret;
 }
 
diff --git a/drivers/media/i2c/adv748x/adv748x-csi2.c 
b/drivers/media/i2c/adv748x/adv748x-csi2.c
index b4fee7f52d6a..609d960c0749 100644
--- a/drivers/media/i2c/adv748x/adv748x-csi2.c
+++ b/drivers/media/i2c/adv748x/adv748x-csi2.c
@@ -223,13 +223,12 @@ static const struct v4l2_subdev_ops adv748x_csi2_ops = {
 
 int adv748x_csi2_set_pixelrate(struct v4l2_subdev *sd, s64 rate)
 {
-   struct v4l2_ctrl *ctrl;
+   struct adv748x_csi2 *tx = adv748x_sd_to_csi2(sd);
 
-   ctrl = v4l2_ctrl_find(sd->ctrl_handler, V4L2_CID_PIXEL_RATE);
-   if (!ctrl)
+   if (!tx->pixel_rate)
return -EINVAL;
 
-   return v4l2_ctrl_s_ctrl_int64(ctrl, rate);
+   return v4l2_ctrl_s_ctrl_int64(tx->pixel_rate, rate);
 }
 
 static int adv748x_csi2_s_ctrl(struct v4l2_ctrl *ctrl)
@@ -248,12 +247,12 @@ static const struct v4l2_ctrl_ops adv748x_csi2_ctrl_ops = 
{
 
 static int adv748x_csi2_init_controls(struct adv748x_csi2 *tx)
 {
-   struct v4l2_ctrl *ctrl;
-
v4l2_ctrl_handler_init(>ctrl_hdl, 1);
 
-   ctrl = v4l2_ctrl_new_std(>ctrl_hdl, _csi2_ctrl_ops,
-V4L2_CID_PIXEL_RATE, 1, INT_MAX, 1, 1);
+   tx->pixel_rate = v4l2_ctrl_new_std(>ctrl_hdl,
+  _csi2_ctrl_ops,
+  V4L2_CID_PIXEL_RATE, 1, INT_MAX,
+  1, 1);
 
tx->sd.ctrl_handler = >ctrl_hdl;
if (tx->ctrl_hdl.error) {
diff --git a/drivers/media/i2c/adv748x/adv748x.h 
b/drivers/media/i2c/adv748x/adv748x.h
index cc4151b5b31e..6789e2f3bc8c 100644
--- a/drivers/media/i2c/adv748x/adv748x.h
+++ b/drivers/media/i2c/adv748x/adv748x.h
@@ -97,6 +97,7 @@ struct adv748x_csi2 {
 
struct media_pad pads[ADV748X_CSI2_NR_PADS];
struct v4l2_ctrl_handler ctrl_hdl;
+   struct v4l2_ctrl *pixel_rate;
struct v4l2_subdev sd;
 };
 
-- 
2.7.4

Re: [PATCH v3 3/4] drm: rcar-du: Fix race condition when disabling planes at CRTC stop

[Kieran Bingham]

Hi Laurent,

On 29/07/17 22:08, Laurent Pinchart wrote:
> When stopping the CRTC the driver must disable all planes and wait for
> the change to take effect at the next vblank. Merely calling
> drm_crtc_wait_one_vblank() is not enough, as the function doesn't
> include any mechanism to handle the race with vblank interrupts.
> 
> Replace the drm_crtc_wait_one_vblank() call with a manual mechanism that
> handles the vblank interrupt race.

This looks like a nasty hidden race
 (though I understand I unintentionally helped make it more prominent  :D )

Fix looks good to me.

> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 58 
> ++
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  8 +
>  2 files changed, 60 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 17fd1cd5212c..6e5bd0b92dfa 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -490,23 +490,51 @@ static void rcar_du_crtc_start(struct rcar_du_crtc 
> *rcrtc)
>   rcar_du_group_start_stop(rcrtc->group, true);
>  }
>  
> +static void rcar_du_crtc_disable_planes(struct rcar_du_crtc *rcrtc)
> +{
> + struct rcar_du_device *rcdu = rcrtc->group->dev;
> + struct drm_crtc *crtc = >crtc;
> + u32 status;
> +
> + /* Make sure vblank interrupts are enabled. */
> + drm_crtc_vblank_get(crtc);
> +
> + /*
> +  * Disable planes and calculate how many vertical blanking interrupts we
> +  * have to wait for. If a vertical blanking interrupt has been triggered
> +  * but not processed yet, we don't know whether it occurred before or
> +  * after the planes got disabled. We thus have to wait for two vblank
> +  * interrupts in that case.
> +  */
> + spin_lock_irq(>vblank_lock);
> + rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
> + status = rcar_du_crtc_read(rcrtc, DSSR);
> + rcrtc->vblank_count = status & DSSR_VBK ? 2 : 1;
> + spin_unlock_irq(>vblank_lock);
> +
> + if (!wait_event_timeout(rcrtc->vblank_wait, rcrtc->vblank_count == 0,
> + msecs_to_jiffies(100)))
> + dev_warn(rcdu->dev, "vertical blanking timeout\n");
> +
> + drm_crtc_vblank_put(crtc);
> +}
> +
>  static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
>  {
>   struct drm_crtc *crtc = >crtc;
>  
>   /*
>* Disable all planes and wait for the change to take effect. This is
> -  * required as the DSnPR registers are updated on vblank, and no vblank
> -  * will occur once the CRTC is stopped. Disabling planes when starting
> -  * the CRTC thus wouldn't be enough as it would start scanning out
> -  * immediately from old frame buffers until the next vblank.
> +  * required as the plane enable registers are updated on vblank, and no
> +  * vblank will occur once the CRTC is stopped. Disabling planes when
> +  * starting the CRTC thus wouldn't be enough as it would start scanning
> +  * out immediately from old frame buffers until the next vblank.
>*
>* This increases the CRTC stop delay, especially when multiple CRTCs
>* are stopped in one operation as we now wait for one vblank per CRTC.
>* Whether this can be improved needs to be researched.
>*/
> - rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
> - drm_crtc_wait_one_vblank(crtc);
> + rcar_du_crtc_disable_planes(rcrtc);
>  
>   /*
>* Disable vertical blanking interrupt reporting. We first need to wait
> @@ -695,10 +723,26 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
>   irqreturn_t ret = IRQ_NONE;
>   u32 status;
>  
> + spin_lock(>vblank_lock);
> +
>   status = rcar_du_crtc_read(rcrtc, DSSR);
>   rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
>  
>   if (status & DSSR_VBK) {
> + /*
> +  * Wake up the vblank wait if the counter reaches 0. This must
> +  * be protected by the vblank_lock to avoid races in
> +  * rcar_du_crtc_disable_planes().
> +  */
> + if (rcrtc->vblank_count) {
> + if (--rcrtc->vblank_count == 0)
> + wake_up(>vblank_wait);
> + }
> + }
> +
> + spin_unlock(>vblank_lock);
> +
> + if (status & DSSR_VBK) {
>   drm_crtc_handle_vblank(>crtc);
>  
>   if (rcdu->info->gen < 3)
> @@ -756,6 +800,8 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
> unsigned int index)
>   }
>  
>   init_waitqueue_head(>flip_wait);
> + init_waitqueue_head(>vblank_wait);
> + spin_lock_init(>vblank_lock);
>  
>   rcrtc->group = rgrp;
>   

[PATCH 2/2] arm64: dts: r8a7796: Add HSUSB device node

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 445a3d9..d738d4b 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1252,7 +1252,20 @@
};
 
hsusb: usb@e659 {
-   /* placeholder */
+   compatible = "renesas,usbhs-r8a7796",
+"renesas,rcar-gen3-usbhs";
+   reg = <0 0xe659 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 704>;
+   dmas = <_dmac0 0>, <_dmac0 1>,
+  <_dmac1 0>, <_dmac1 1>;
+   dma-names = "ch0", "ch1", "ch2", "ch3";
+   renesas,buswait = <11>;
+   phys = <_phy0>;
+   phy-names = "usb";
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 704>;
+   status = "disabled";
};
 
xhci0: usb@ee00 {
-- 
1.9.1

[PATCH 2/3] arm64: dts: r8a7796: add USB2.0 Host (EHCI/OHCI) device nodes

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 42 +---
 1 file changed, 38 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index efaf941..5301bfc 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1232,11 +1232,28 @@
};
 
ohci0: usb@ee08 {
-   /* placeholder */
+   compatible = "generic-ohci";
+   reg = <0 0xee08 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 703>;
+   phys = <_phy0>;
+   phy-names = "usb";
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 703>;
+   status = "disabled";
};
 
ehci0: usb@ee080100 {
-   /* placeholder */
+   compatible = "generic-ehci";
+   reg = <0 0xee080100 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 703>;
+   phys = <_phy0>;
+   phy-names = "usb";
+   companion= <>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 703>;
+   status = "disabled";
};
 
usb2_phy0: usb-phy@ee080200 {
@@ -1252,11 +1269,28 @@
};
 
ohci1: usb@ee0a {
-   /* placeholder */
+   compatible = "generic-ohci";
+   reg = <0 0xee0a 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 702>;
+   phys = <_phy1>;
+   phy-names = "usb";
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 702>;
+   status = "disabled";
};
 
ehci1: usb@ee0a0100 {
-   /* placeholder */
+   compatible = "generic-ehci";
+   reg = <0 0xee0a0100 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 702>;
+   phys = <_phy1>;
+   phy-names = "usb";
+   companion= <>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 702>;
+   status = "disabled";
};
 
usb2_phy1: usb-phy@ee0a0200 {
-- 
1.9.1

[PATCH 1/2] arm64: dts: r8a7796: Add USB-DMAC device nodes

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index ef1120f..445a3d9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1223,6 +1223,34 @@
dma-channels = <16>;
};
 
+   usb_dmac0: dma-controller@e65a {
+   compatible = "renesas,r8a7796-usb-dmac",
+"renesas,usb-dmac";
+   reg = <0 0xe65a 0 0x100>;
+   interrupts = ;
+   interrupt-names = "ch0", "ch1";
+   clocks = < CPG_MOD 330>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 330>;
+   #dma-cells = <1>;
+   dma-channels = <2>;
+   };
+
+   usb_dmac1: dma-controller@e65b {
+   compatible = "renesas,r8a7796-usb-dmac",
+"renesas,usb-dmac";
+   reg = <0 0xe65b 0 0x100>;
+   interrupts = ;
+   interrupt-names = "ch0", "ch1";
+   clocks = < CPG_MOD 331>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 331>;
+   #dma-cells = <1>;
+   dma-channels = <2>;
+   };
+
hsusb: usb@e659 {
/* placeholder */
};
-- 
1.9.1

[PATCH 0/2] arm64: dts: r8a7796: add USB-DMAC and HSUSB device nodes

[Yoshihiro Shimoda]

This patch is based on the renesas.git / renesas-devel-20170731v2-v4.13-rc3 tag.

For usb-dmac, we should wait for the following patch (even if we don't apply
the patch, the usb-dmac driver can be probed correctly though.)
 https://patchwork.kernel.org/patch/9876639/

For hsusb, we need the "arm64: dts: r8a7796: add usb host device nodes" patch
set for using usb2_phy0.

Yoshihiro Shimoda (2):
  arm64: dts: r8a7796: Add USB-DMAC device nodes
  arm64: dts: r8a7796: Add HSUSB device node

 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 43 +++-
 1 file changed, 42 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH 0/3] arm64: dts: r8a7796: add usb host device nodes

[Yoshihiro Shimoda]

This patch is based on the renesas.git / renesas-devel-20170731v2-v4.13-rc3 tag.

For usb2.0 host, we need the following patch:
 https://patchwork.kernel.org/patch/9864583/

For usb3.0 host, we need the following patch:
 https://patchwork.kernel.org/patch/9864579/

Yoshihiro Shimoda (3):
  arm64: dts: r8a7796: add usb2_phy device nodes
  arm64: dts: r8a7796: add USB2.0 Host (EHCI/OHCI) device nodes
  arm64: dts: r8a7795: Add USB3.0 host device node

 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 70 
 1 file changed, 63 insertions(+), 7 deletions(-)

-- 
1.9.1

[PATCH 3/3] arm64: dts: r8a7795: Add USB3.0 host device node

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 5301bfc..882a556 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1228,7 +1228,14 @@
};
 
xhci0: usb@ee00 {
-   /* placeholder */
+   compatible = "renesas,xhci-r8a7796",
+"renesas,rcar-gen3-xhci";
+   reg = <0 0xee00 0 0xc00>;
+   interrupts = ;
+   clocks = < CPG_MOD 328>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 328>;
+   status = "disabled";
};
 
ohci0: usb@ee08 {
-- 
1.9.1

Re: [PATCH v3 2/4] drm: rcar-du: Wait for flip completion instead of vblank in commit tail

[Kieran Bingham]

Hi Laurent,

On 29/07/17 22:08, Laurent Pinchart wrote:
> Page flips can take more than one vertical blanking to complete if
> arming the page flips races with the vertical blanking interrupt.
> Waiting for one vblank to complete the atomic commit in the commit tail
> handler is thus incorrect, and can lead to framebuffers being released
> while still being scanned out.
> 
> Fix this by waiting for flip completion instead, using the
> drm_atomic_helper_wait_for_flip_done() helper.
> 
> Fixes: 0d230422d256 ("drm: rcar-du: Register a completion callback with VSP1")
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index b91257dee98f..221e22922396 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -262,7 +262,7 @@ static void rcar_du_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>   drm_atomic_helper_commit_modeset_enables(dev, old_state);
>  
>   drm_atomic_helper_commit_hw_done(old_state);
> - drm_atomic_helper_wait_for_vblanks(dev, old_state);
> + drm_atomic_helper_wait_for_flip_done(dev, old_state);

Ahh yes, that makes sense!

Reviewed-by: Kieran Bingham 


>   drm_atomic_helper_cleanup_planes(dev, old_state);
>  }
> 

Re: [PATCH] Revert "mmc: sdhi: use maximum width for the sdbuf register"

[Ulf Hansson]

On 3 August 2017 at 11:53, Wolfram Sang  wrote:
> On Thu, Aug 03, 2017 at 11:49:47AM +0200, Wolfram Sang wrote:
>> This reverts commit 785b215250310c690142abb1bdbb0767b8487c49. There is a
>> secondary SDHI instance on Gen2 with has a 32-bit wide SDBUF register
>> while all other registers are 16 bit apart. So, the logic used here does
>> not apply and we need to rethink this and start cleanly from scratch.
>>
>> Signed-off-by: Wolfram Sang 
>
> Extra info for Ulf: I can't work on that in the next days, so I thought
> it would be good to ASAP fix the regression in mmc/next at least.
>

Instead of applying this revert, I decided to just drop the original
commit from my next branch.

While working on new version of how to deal with the 32/16 bit
register correctly, please try to include Biju Das in the changelog as
to give him cred from his help with testing.

Kind regards
Uffe

Re: [PATCH mmc/next] mmc: renesas-sdhi: provide a whitelist for Gen3 SoC ES versions

[Ulf Hansson]

On 2 August 2017 at 14:48, Simon Horman  wrote:
> Provide a whitelist for Gen3 SoC ES versions for both the SYS DMAC and
> internal DMAC variants of the SDHI driver.  This is to allow drivers to
> only initialise for Gen3 SoC ES versions for which they are the appropriate
> DMAC implementation.  Currently internal DMAC is the appropriate
> implementation for all supported Gen3 SoC ES versions.
>
> Signed-off-by: Simon Horman 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c | 15 +++
>  drivers/mmc/host/renesas_sdhi_sys_dmac.c  | 15 +++
>  2 files changed, 30 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index a26c6ed8e029..6717003888e2 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "renesas_sdhi.h"
>  #include "tmio_mmc.h"
> @@ -241,8 +242,22 @@ static struct tmio_mmc_dma_ops 
> renesas_sdhi_internal_dmac_dma_ops = {
> .dataend = renesas_sdhi_internal_dmac_dataend_dma,
>  };
>
> +/*
> + * Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
> + * implementation as others may use a different implementation.
> + */
> +static const struct soc_device_attribute gen3_soc_whitelist[] = {
> +{ .soc_id = "r8a7795", .revision = "ES1.*" },
> +{ .soc_id = "r8a7795", .revision = "ES2.0" },
> +{ .soc_id = "r8a7796", .revision = "ES1.0" },
> +{ /* sentinel */ }
> +};
> +
>  static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
>  {
> +   if (!soc_device_match(gen3_soc_whitelist))
> +   return -ENODEV;
> +
> return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
>  }
>
> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index b6789f5197b3..718cb8a9d2ce 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> @@ -18,8 +18,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>
>  #include "renesas_sdhi.h"
>  #include "tmio_mmc.h"
> @@ -459,8 +461,21 @@ static const struct tmio_mmc_dma_ops 
> renesas_sdhi_sys_dmac_dma_ops = {
> .dataend = renesas_sdhi_sys_dmac_dataend_dma,
>  };
>
> +/*
> + * Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
> + * implementation. Currently empty as all supported ES versions use
> + * the internal DMAC.
> + */
> +static const struct soc_device_attribute gen3_soc_whitelist[] = {
> +{ /* sentinel */ }
> +};
> +
>  static int renesas_sdhi_sys_dmac_probe(struct platform_device *pdev)
>  {
> +   if (of_device_get_match_data(>dev) == _rcar_gen3_compatible 
> &&
> +   !soc_device_match(gen3_soc_whitelist))
> +   return -ENODEV;
> +
> return renesas_sdhi_probe(pdev, _sdhi_sys_dmac_dma_ops);
>  }
>
> --
> 2.1.4
>

RE: [PATCH] Revert "mmc: sdhi: use maximum width for the sdbuf register"

[Biju Das]

Tested this patch on iWave RZ/G1M platform.

Tested-by: Biju Das 

Regards,
Biju

> -Original Message-
> From: Wolfram Sang [mailto:wsa+rene...@sang-engineering.com]
> Sent: 03 August 2017 10:50
> To: linux-...@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org; Simon Horman ;
> Biju Das ; Ulf Hansson ;
> Wolfram Sang 
> Subject: [PATCH] Revert "mmc: sdhi: use maximum width for the sdbuf
> register"
>
> This reverts commit 785b215250310c690142abb1bdbb0767b8487c49. There is
> a secondary SDHI instance on Gen2 with has a 32-bit wide SDBUF register while
> all other registers are 16 bit apart. So, the logic used here does not apply 
> and
> we need to rethink this and start cleanly from scratch.
>
> Signed-off-by: Wolfram Sang 
> ---
>  drivers/mmc/host/renesas_sdhi_core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> b/drivers/mmc/host/renesas_sdhi_core.c
> index 48da28dfef6465..dd215723fa4312 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -461,7 +461,8 @@ static void renesas_sdhi_enable_dma(struct
> tmio_mmc_host *host, bool enable)  {
>  sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ?
> DMA_ENABLE_DMASDRW : 0);
>
> -renesas_sdhi_sdbuf_width(host, enable ? (16 << host->bus_shift) : 16);
> +/* enable 32bit access if DMA mode if possibile */
> +renesas_sdhi_sdbuf_width(host, enable ? 32 : 16);
>  }
>
>  int renesas_sdhi_probe(struct platform_device *pdev,
> --
> 2.11.0




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

Re: [PATCH] Revert "mmc: sdhi: use maximum width for the sdbuf register"

[Wolfram Sang]

On Thu, Aug 03, 2017 at 11:49:47AM +0200, Wolfram Sang wrote:
> This reverts commit 785b215250310c690142abb1bdbb0767b8487c49. There is a
> secondary SDHI instance on Gen2 with has a 32-bit wide SDBUF register
> while all other registers are 16 bit apart. So, the logic used here does
> not apply and we need to rethink this and start cleanly from scratch.
> 
> Signed-off-by: Wolfram Sang 

Extra info for Ulf: I can't work on that in the next days, so I thought
it would be good to ASAP fix the regression in mmc/next at least.



signature.asc
Description: PGP signature

[PATCH] Revert "mmc: sdhi: use maximum width for the sdbuf register"

[Wolfram Sang]

This reverts commit 785b215250310c690142abb1bdbb0767b8487c49. There is a
secondary SDHI instance on Gen2 with has a 32-bit wide SDBUF register
while all other registers are 16 bit apart. So, the logic used here does
not apply and we need to rethink this and start cleanly from scratch.

Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/renesas_sdhi_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index 48da28dfef6465..dd215723fa4312 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -461,7 +461,8 @@ static void renesas_sdhi_enable_dma(struct tmio_mmc_host 
*host, bool enable)
 {
sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
 
-   renesas_sdhi_sdbuf_width(host, enable ? (16 << host->bus_shift) : 16);
+   /* enable 32bit access if DMA mode if possibile */
+   renesas_sdhi_sdbuf_width(host, enable ? 32 : 16);
 }
 
 int renesas_sdhi_probe(struct platform_device *pdev,
-- 
2.11.0

RE: [PATCH 4/4] mmc: sdhi: use maximum width for the sdbuf register

[Biju Das]

> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 03 August 2017 09:57
> To: Biju Das 
> Cc: Wolfram Sang ; linux-renesas-
> s...@vger.kernel.org; Simon Horman ; Yoshihiro
> Shimoda ; linux-mmc-
> ow...@vger.kernel.org; Chris Paterson 
> Subject: Re: [PATCH 4/4] mmc: sdhi: use maximum width for the sdbuf register
>
>
> > > Which tree is this based on? I can't find SDHI nodes for r8a7743 in
> > > its dtsi file in linux-next? I'd think the node is not correct.
> >
> >
> > It is not upstreamed yet. I am going to upstream this patches with in a week
> or two.
> > Currently this patch is under internal review.
>
> Ok, I see the problem now. It is likely that we in deed need to revert the 
> patch
> because I missed that Gen2 has two versions of the SDHI controller and the
> second version has an exception with the SDBUF register.
>
> Thanks for the report! (one suggestion for next time: please describe which
> branch you tested)
>

Thanks for the feedback. I will do it next time.

> Regards,
>
>Wolfram




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

RE: [PATCH 4/4] mmc: sdhi: use maximum width for the sdbuf register

[Biju Das]

> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 03 August 2017 08:43
> To: Biju Das 
> Cc: Wolfram Sang ; linux-renesas-
> s...@vger.kernel.org; Simon Horman ; Yoshihiro
> Shimoda ; linux-mmc-
> ow...@vger.kernel.org
> Subject: Re: [PATCH 4/4] mmc: sdhi: use maximum width for the sdbuf register
>
> > [1.162808] sh_mobile_sdhi ee14.sd: Got CD GPIO
> > [1.167721] sh_mobile_sdhi ee14.sd: Got WP GPIO
> > [1.225803] bus_width: 0
>
> This should be '1'.
>

> Which tree is this based on? I can't find SDHI nodes for r8a7743 in its dtsi 
> file in
> linux-next? I'd think the node is not correct.


It is not upstreamed yet. I am going to upstream this patches with in a week or 
two.
Currently this patch is under internal review.
It is identical to R-Car M2.I believe this issue should reproducible with R-Car 
M2-W board(r8a7791).

I first rebased my SDHI patches with renesas-dev branch and it worked fine.

Then I rebased the same patches on linux-next + relevant patches from 
renesas-dev , it is started showing the issue.
Then I found that this patch is causing the issue.

Please find the  DT related entries here.

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt 
b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 4fd8b7a..0d507ec 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -15,6 +15,8 @@ Required properties:
 "renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC
 "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
 "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
+"renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
+"renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
 "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
 "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
 "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
@@ -34,8 +36,8 @@ Required properties:
   "core" and "cd". If the controller only has 1 clock, naming is not
   required.
   Below is the number clocks for each supported SoC:
-   1: SH73A0, R8A73A4, R8A7740, R8A7778, R8A7779, R8A7790
-  R8A7791, R8A7792, R8A7793, R8A7794, R8A7795, R8A7796
+   1: SH73A0, R8A73A4, R8A7740, R8A7743, R8A7745, R8A7778, R8A7779,
+  R8A7790, R8A7791, R8A7792, R8A7793, R8A7794, R8A7795, R8A7796
2: R7S72100

 Optional properties:
diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts 
b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index b3a1efa..b5ac0ff 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -19,6 +19,29 @@
 serial0 = 
 ethernet0 = 
 };
+
+vcc_sdhi1: regulator-vcc-sdhi1 {
+compatible = "regulator-fixed";
+
+regulator-name = "SDHI1 Vcc";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+
+gpio = < 16 GPIO_ACTIVE_LOW>;
+};
+
+vccq_sdhi1: regulator-vccq-sdhi1 {
+compatible = "regulator-gpio";
+
+regulator-name = "SDHI1 VccQ";
+regulator-min-microvolt = <180>;
+regulator-max-microvolt = <330>;
+
+gpios = < 30 GPIO_ACTIVE_LOW>;
+gpios-states = <1>;
+states = <330 1
+  180 0>;
+};
 };

  {
@@ -36,6 +59,18 @@
 groups = "i2c2";
 function = "i2c2";
 };
+
+sdhi1_pins: sd1 {
+groups = "sdhi1_data4", "sdhi1_ctrl";
+function = "sdhi1";
+power-source = <3300>;
+};
+
+sdhi1_pins_uhs: sd1_uhs {
+groups = "sdhi1_data4", "sdhi1_ctrl";
+function = "sdhi1";
+power-source = <1800>;
+};
 };

  {
@@ -72,3 +107,16 @@
 reg = <0x68>;
 };
 };
+
+ {
+pinctrl-0 = <_pins>;
+pinctrl-1 = <_pins_uhs>;
+pinctrl-names = "default", "state_uhs";
+
+vmmc-supply = <_sdhi1>;
+vqmmc-supply = <_sdhi1>;
+cd-gpios = < 14 GPIO_ACTIVE_LOW>;
+wp-gpios = < 15 GPIO_ACTIVE_HIGH>;
+sd-uhs-sdr50;
+status = "okay";
+};
diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi 
b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index ff79938..4119737 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -9,6 +9,7 @@
  */

 #include "r8a7743.dtsi"
+#include 

 / {
 compatible = "iwave,g20m", "renesas,r8a7743";
@@ -42,6 +43,12 @@
 groups = "mmc_data8_b", "mmc_ctrl";
 function = "mmc";
 };
+
+sdhi0_pins: sd0 {
+groups = "sdhi0_data4", "sdhi0_ctrl";
+function = "sdhi0";
+power-source = <3300>;
+};
 };

  {
@@ -53,3 +60,13 @@
 non-removable;
 status = "okay";
 };
+
+ {
+pinctrl-0 = <_pins>;
+pinctrl-names = "default";
+
+vmmc-supply = <_3p3v>;
+vqmmc-supply = <_3p3v>;
+cd-gpios = < 11 GPIO_ACTIVE_LOW>;
+status = "okay";
+};
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 5c2b140..8945cc7 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -834,6 +834,48 @@
 max-frequency = <9750>;
 status = "disabled";
 };
+
+sdhi0: sd@ee10 {
+compatible = "renesas,sdhi-r8a7743";
+reg = <0 0xee10 0 0x328>;
+interrupts = ;
+clocks = < CPG_MOD 314>;
+dmas = < 0xcd>, < 0xce>,
+   < 0xcd>, < 

Re: [LTSI-dev] [GIT PULL LTSI-4.9] Renesas SoCs and Drivers to v4.12

[Simon Horman]

On Wed, Aug 02, 2017 at 06:55:04PM -0700, Greg KH wrote:
> On Mon, Jul 10, 2017 at 03:33:34PM +0200, Simon Horman wrote:
> > Hi,
> > 
> > This is a submission to LTSI-v4.9.
> > 
> > This series is comprised of backports to v4.9 of the following
> > components to their standard as of v4.12:
> > 
> > It is a follow up to early preparatory work the main difference being
> > a rebase onto v4.9.36. This is a follow-up to a similar submission
> > backporting Renesas SoCs and Drivers to v4.10. I plan to follow-up with
> > a backport to v4.12.
> > 
> > I have tested for build regressions on a wide range of defconfigs
> > on a wide range of architectures.
> > 
> > There are 286 patches.
> > 
> > This is based on a similar backports to v4.11 which is in turn based on 
> > v4.9.36.
> > That work was posted as "[GIT PULL LTSI-4.9] Renesas SoCs and Drivers to 
> > v4.11"
> > and is tagged as tags/backport/v4.9.36/snapshot-to-v4.11-flattened
> > 
> > 
> > The following changes since commit 338ec844533e7bb1120f88f83a3fcc1d9618eef7:
> > 
> >   drm: bridge: dw-hdmi: fix building without CONFIG_OF (2017-07-10 14:51:26 
> > +0200)
> > 
> > are available in the git repository at:
> > 
> >   
> > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git 
> > tags/backport/v4.9.36/snapshot-to-v4.12-flattened
> 
> Hm, this was odd, I had to drop a number of patches in the middle here,
> but then got the rest to apply.  Did some patches end up already in the
> earlier series?
> 
> Anyway, all now applied, thanks.

Thanks Greg,

I'll look over what you have applied.
The likely explanation for the problem is that I messed things up somehow
when preparing the branch for you.

Re: [RFT] arm64: dts: renesas: salvator-common: enable SDR104 for SD cards

[Simon Horman]

On Wed, Aug 02, 2017 at 10:13:11PM +0200, Wolfram Sang wrote:
> Tests showed that SDHI driver problems have been solved and SDR104 works
> now reliably on both Salvator-X SD card slots, both with an R-Car H3
> (r8a7795 ES1.0) and R-Car M3 (r8a7796 ES 1.0). So, finally, enable it.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Awesome, awesome! For the last two days, I did various tests with my boards 
> and
> SD cards and SDR104 worked absolutely reliably :D Even the problematic card I
> had works flawlessly. I couldn't trigger the known failures anymore. Although 
> I
> tried, I can't point to a single patch which "fixed" the issue. It is the
> constant work on dealing with smaller issues which makes SDR104 work at the 
> end
> of the day. However, two patches are likely a bigger part of the cake:
> 
> 43b0b361b01700 ("mmc: tmio: always get number of taps")
> -> Already upstream. This fixed retuning on card changes.
> 
> 85b81aa16ec4ed ("mmc: tmio: fix CMD12 (STOP) handling")
> -> In mmc/next. This allows to handle tuning errors gracefully and to retune.
> 
> With the freshly submitted Gen3 DMA patches, we also get nice transfer speeds 
> :)
> 
> This patch is based on renesas-drivers/master as of today. A branch for 
> testing
> can be found here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/v8-sdr104
> 
> All patches needed for reliable SDR104 are already upstream or in mmc/next. 
> The
> above branch only adds another patch to enable DMA on Gen3. It is not strictly
> needed, but very nice to have. I think it would be cool to get both patches
> into v4.14.
> 
> Looking forward to other testers. Simon, do you have some time for this?

Yes, I should be able to run this through my - until now thought to be
broken - test case this week.

It would be very nice to be able to get closure on this :)

> 
> Thanks and kind regards,
> 
>   a very happy Wolfram
> 
> 
>  arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index a451996f590a51..18e2da9f866684 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -569,6 +569,7 @@
>   wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
>   bus-width = <4>;
>   sd-uhs-sdr50;
> + sd-uhs-sdr104;
>   status = "okay";
>  };
>  
> @@ -597,6 +598,7 @@
>   wp-gpios = < 16 GPIO_ACTIVE_HIGH>;
>   bus-width = <4>;
>   sd-uhs-sdr50;
> + sd-uhs-sdr104;
>   status = "okay";
>  };
>  
> -- 
> 2.11.0
> 

Re: [PATCH 4/4] mmc: sdhi: use maximum width for the sdbuf register

[Wolfram Sang]

> [1.162808] sh_mobile_sdhi ee14.sd: Got CD GPIO
> [1.167721] sh_mobile_sdhi ee14.sd: Got WP GPIO
> [1.225803] bus_width: 0

This should be '1'.

Which tree is this based on? I can't find SDHI nodes for r8a7743 in its
dtsi file in linux-next? I'd think the node is not correct.



signature.asc
Description: PGP signature

Re: [PATCH mmc/next] mmc: renesas-sdhi: provide a whitelist for Gen3 SoC ES versions

[Simon Horman]

On Wed, Aug 02, 2017 at 09:51:29PM +0200, Wolfram Sang wrote:
> On Wed, Aug 02, 2017 at 02:48:42PM +0200, Simon Horman wrote:
> > Provide a whitelist for Gen3 SoC ES versions for both the SYS DMAC and
> > internal DMAC variants of the SDHI driver.  This is to allow drivers to
> > only initialise for Gen3 SoC ES versions for which they are the appropriate
> > DMAC implementation.  Currently internal DMAC is the appropriate
> > implementation for all supported Gen3 SoC ES versions.
> > 
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Wolfram Sang 
> 
> > +/*
> > + * Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
> > + * implementation. Currently empty as all supported ES versions use
> > + * the internal DMAC.
> > + */
> > +static const struct soc_device_attribute gen3_soc_whitelist[] = {
> > +{ /* sentinel */ }
> > +};
> 
> It may look strange to add an empty list, but I think it is worth it. We
> have good reasons to believe the soc_device_match distinction is
> necessary and I think it is good to be clear from the beginning how we
> want to deal with the differences.

Hi Wolfram,

thanks for adding some colour to the motivation for this change.
I agree with your statements above.

Re: [PATCH] dmaengine: usb-dmac: Add soctype for R-Car M3-W

[Simon Horman]

On Wed, Aug 02, 2017 at 08:33:34PM +0900, Yoshihiro Shimoda wrote:
> This patch adds R-Car M3-W device tree bindings for usb-dmac driver.
> 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
>  Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt 
> b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
> index e7780a1..1be6941 100644
> --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
> +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
> @@ -8,6 +8,7 @@ Required Properties:
> - "renesas,r8a7793-usb-dmac" (R-Car M2-N)
> - "renesas,r8a7794-usb-dmac" (R-Car E2)
> - "renesas,r8a7795-usb-dmac" (R-Car H3)
> +   - "renesas,r8a7796-usb-dmac" (R-Car M3-W)
>  - reg: base address and length of the registers block for the DMAC
>  - interrupts: interrupt specifiers for the DMAC, one for each entry in
>interrupt-names.
> -- 
> 1.9.1
> 

RE: [PATCH 4/4] mmc: sdhi: use maximum width for the sdbuf register

[Biju Das]

> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 02 August 2017 20:04
> To: Biju Das 
> Cc: Wolfram Sang ; linux-renesas-
> s...@vger.kernel.org; Simon Horman ; Yoshihiro
> Shimoda ; linux-mmc-
> ow...@vger.kernel.org
> Subject: Re: [PATCH 4/4] mmc: sdhi: use maximum width for the sdbuf register
>
>
> > I am having issues with this patch(commitid:-
> 785b215250310c690142abb1bdbb0767b8487c49)
> > on iWave RZ/G1M board which is identical to R-Car M2.
>
> Uh, that's bad. Let's see, can you print out the bus_shift variable?
>
> Like this
>
> pr_info("bus_width: %u\n", host->bus_shift);
>

[0.890105] sh_mobile_sdhi ee10.sd: Got CD GPIO
[0.945805] bus_width: 1
[1.005912] sh_mobile_sdhi ee10.sd: mmc0 base at 0xee10 max clock 
rate 195 MHz
[1.014299] sh_mobile_sdhi ee14.sd: Got CD GPIO
[1.019228] sh_mobile_sdhi ee14.sd: Got WP GPIO
[1.026753] bus_width: 1
[1.029290] bus_width: 1
[1.033696] bus_width: 1
[1.036245] bus_width: 1
[1.044481] bus_width: 1
[1.047033] bus_width: 1
[1.051437] bus_width: 1
[1.053968] bus_width: 1
[1.058396] bus_width: 1
[1.060928] bus_width: 1
[1.065331] bus_width: 1
[1.067883] bus_width: 1
[1.075753] sh_mmcif ee20.mmc: Chip version 0x0003, clock rate 12MHz

[1.162808] sh_mobile_sdhi ee14.sd: Got CD GPIO
[1.167721] sh_mobile_sdhi ee14.sd: Got WP GPIO
[1.225803] bus_width: 0
[1.285896] sh_mobile_sdhi ee14.sd: mmc2 base at 0xee14 max clock 
rate 97 MHz
[1.295945] bus_width: 0
[1.295955] bus_width: 0
[1.310067] bus_width: 0
[1.312621] bus_width: 0
[1.315700] mmc0: new high speed SDHC card at address 
[1.321502] mmcblk0: mmc0: SL16G 14.8 GiB
[1.327974] bus_width: 0
[1.330512] bus_width: 0
[1.333120]  mmcblk0: p1 p2
[1.336043] bus_width: 0
[1.338578] bus_width: 0
[1.342913] bus_width: 0
[1.345449] bus_width: 0
[1.349814] bus_width: 0
[1.352349] bus_width: 0
[1.574048] mmc1: new high speed MMC card at address 0001
[1.579733] mmcblk1: mmc1:0001 MMC04G 3.52 GiB
[1.584354] mmcblk1boot0: mmc1:0001 MMC04G partition 1 16.0 MiB
[1.590373] mmcblk1boot1: mmc1:0001 MMC04G partition 2 16.0 MiB
[1.599432]  mmcblk1: p1 p2


[6.645766] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD51)
Configuring network interfaces... [6.705785] bus_width: 0
[6.708329] bus_width: 0
[6.710885] mmc2: error -110 whilst initialising SD card
[6.718189] bus_width: 0
[6.720735] bus_width: 0
[6.778163] bus_width: 0
[6.780732] bus_width: 0
[6.785697] bus_width: 0
[6.788305] bus_width: 0
[6.797313] bus_width: 0
[6.799924] bus_width: 0
[6.804870] bus_width: 0
[6.807504] bus_width: 0
[6.813239] bus_width: 0
[6.815864] bus_width: 0
[6.820826] bus_width: 0
[6.823447] bus_width: 0

 [   11.925733] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD51)
[   11.985731] bus_width: 0
[   11.988272] bus_width: 0
[   11.990827] mmc2: error -110 whilst initialising SD card
[   11.998720] bus_width: 0
[   12.001256] bus_width: 0
[   12.059276] bus_width: 0
[   12.061811] bus_width: 0
[   12.067902] bus_width: 0
[   12.070437] bus_width: 0
[   17.125730] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD5)
[   17.185731] bus_width: 0
[   17.188268] bus_width: 0
[   22.245732] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD5)
[   22.305737] bus_width: 0
[   22.308277] bus_width: 0
[   27.365728] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD5)
[   27.425736] bus_width: 0
[   27.428273] bus_width: 0
[   32.485727] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD5)
[   32.545735] bus_width: 0
[   32.548271] bus_width: 0
[   37.605729] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD55)
[   37.665737] bus_width: 0
[   37.668274] bus_width: 0
[   42.725727] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD55)
[   42.785736] bus_width: 0
[   42.788273] bus_width: 0
[   47.845726] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD55)
[   47.905735] bus_width: 0
[   47.908271] bus_width: 0
[   52.965725] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD55)
[   53.025735] bus_width: 0
[   53.028272] bus_width: 0
[   53.034530] bus_width: 0
[   53.037081] bus_width: 0
[   53.102796] bus_width: 0
[   53.105332] bus_width: 0
[   53.114998] bus_width: 0
[   53.117546] bus_width: 0
[   58.165726] sh_mobile_sdhi ee14.sd: timeout waiting for hardware 
interrupt (CMD5)
[   58.225729] bus_width: 0
[   58.228265] bus_width: 0
[   63.285727] sh_mobile_sdhi ee14.sd: timeout waiting for hardware