[PATCH v2 5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
Define the Condor/V3HSK board dependent parts of the DU and LVDS device
nodes. Also add the device nodes for Thine THC63LVD1024 LVDS decoder and
Analog Devices ADV7511W HDMI transmitter...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
Changes in version 2:
- added the V3HSK DT update, reworded the description, renamed the patch;
- added a space between the HDMI node name and a brace.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 +
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 120
2 files changed, 226 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -45,6 +45,56 @@
regulator-boot-on;
regulator-always-on;
};
+
+ d1_8v: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "D1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&d3_3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ x1_clk: x1-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <14850>;
+ };
};
&avb {
@@ -74,6 +124,13 @@
};
};
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+<&x1_clk>;
+ clock-names = "du.0", "dclkin.0";
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <1666>;
};
@@ -102,6 +159,55 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ hdmi@39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&d1_8v>;
+ dvdd-supply = <&d1_8v>;
+ pvdd-supply = <&d1_8v>;
+ bgvdd-supply = <&d1_8v>;
+ dvdd-3v-supply = <&d3_3v>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
};
&mmc0 {
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -27,6 +27,63 @@
/* first 128MB is reserved for secure area. */
reg = <0 0x4800 0 0x7800>;
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+
[PATCH v2 4/5] arm64: dts: renesas: r8a77980: add LVDS support
Define the generic R8A77980 part of the LVDS device node.
Signed-off-by: Sergei Shtylyov
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 29 +
1 file changed, 29 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -696,6 +696,35 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder@feb9 {
+ compatible = "renesas,r8a77980-lvds";
+ reg = <0 0xfeb9 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
+ <&du_out_lvds0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds0_out: endpoint {
};
};
};
[PATCH v2 3/5] arm64: dts: renesas: r8a77980: add DU support
Define the generic R8A77980 part of the DU device node.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 30 ++
1 file changed, 30 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -671,6 +671,36 @@
resets = <&cpg 603>;
};
+ du: display@feb0 {
+ compatible = "renesas,du-r8a77980",
+"renesas,du-r8a77970";
+ reg = <0 0xfeb0 0 0x8>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 724>;
+ clock-names = "du.0";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 724>;
+ vsps = <&vspd0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid@fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
[PATCH v2 2/5] arm64: dts: renesas: r8a77980: add VSPD support
Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
the next patch...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 10 ++
1 file changed, 10 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,16 @@
resets = <&cpg 408>;
};
+ vspd0: vsp@fea2 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea2 0 0x4000>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
fcpvd0: fcp@fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
[PATCH v2 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
the next patch...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi |8
1 file changed, 8 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,14 @@
resets = <&cpg 408>;
};
+ fcpvd0: fcp@fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ };
+
prr: chipid@fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
[PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
Hello! Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/ DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder connected to the LVDS output. These patches depend on the Thine THC63LVD1024 driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO DT patches in order to apply/compile... [1/5] arm64: dts: renesas: r8a77980: add FCPVD support [2/5] arm64: dts: renesas: r8a77980: add VSPD support [3/5] arm64: dts: renesas: r8a77980: add DU support [4/5] arm64: dts: renesas: r8a77980: add LVDS support [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support WBR, Sergei
Re: [PATCH] soc: renesas: rcar-sysc: Make PM domain initialization more robust
On 5 June 2018 at 17:05, Geert Uytterhoeven wrote:
> The quirk for R-Car E3 ES1.0 added in commit 086b399965a7ee7e ("soc:
> renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}") makes the 3DG-A
> PM domain a subdomain of the 3DG-B PM domain. However, registering
> 3DG-A with its parent fails silently, as the 3DG-B PM domain hasn't been
> registered yet, and such failures are never reported.
>
> Fix this by:
> 1. Splitting PM Domain initialization in two steps, so all PM domains
> are registered before any child-parent links are established,
> 2. Reporting any failures in establishing child-parent relations.
>
> Check for and report pm_genpd_init() failures, too, as that function
> gained a return value in commit 7eb231c337e00735 ("PM / Domains: Convert
> pm_genpd_init() to return an error code").
>
> Fixes: 086b399965a7ee7e ("soc: renesas: r8a77990-sysc: Add workaround for
> 3DG-{A,B}")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/soc/renesas/rcar-sysc.c | 35 +--
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
> index 4db53fa38abc5cf3..99e926f68299878d 100644
> --- a/drivers/soc/renesas/rcar-sysc.c
> +++ b/drivers/soc/renesas/rcar-sysc.c
> @@ -379,11 +379,12 @@ static int rcar_sysc_pd_power_on(struct
> generic_pm_domain *genpd)
>
> static bool has_cpg_mstp;
>
> -static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd *pd)
> +static int __init rcar_sysc_pd_setup(struct rcar_sysc_pd *pd)
> {
> struct generic_pm_domain *genpd = &pd->genpd;
> const char *name = pd->genpd.name;
> struct dev_power_governor *gov = &simple_qos_governor;
> + int error;
>
> if (pd->flags & PD_CPU) {
> /*
> @@ -436,7 +437,11 @@ static void __init rcar_sysc_pd_setup(struct
> rcar_sysc_pd *pd)
> rcar_sysc_power_up(&pd->ch);
>
> finalize:
> - pm_genpd_init(genpd, gov, false);
> + error = pm_genpd_init(genpd, gov, false);
> + if (error)
> + pr_err("Failed to init PM domain %s: %d\n", name, error);
> +
> + return error;
> }
>
> static const struct of_device_id rcar_sysc_matches[] __initconst = {
> @@ -560,6 +565,9 @@ static int __init rcar_sysc_pd_init(void)
> pr_debug("%pOF: syscier = 0x%08x\n", np, syscier);
> iowrite32(syscier, base + SYSCIER);
>
> + /*
> +* First, create all PM domains
> +*/
> for (i = 0; i < info->num_areas; i++) {
> const struct rcar_sysc_area *area = &info->areas[i];
> struct rcar_sysc_pd *pd;
> @@ -582,14 +590,29 @@ static int __init rcar_sysc_pd_init(void)
> pd->ch.isr_bit = area->isr_bit;
> pd->flags = area->flags;
>
> - rcar_sysc_pd_setup(pd);
> - if (area->parent >= 0)
> - pm_genpd_add_subdomain(domains->domains[area->parent],
> - &pd->genpd);
> + error = rcar_sysc_pd_setup(pd);
> + if (error)
> + goto out_put;
>
> domains->domains[area->isr_bit] = &pd->genpd;
> }
>
> + /*
> +* Second, link all PM domains to their parents
> +*/
> + for (i = 0; i < info->num_areas; i++) {
> + const struct rcar_sysc_area *area = &info->areas[i];
> +
> + if (!area->name || area->parent < 0)
> + continue;
> +
> + error = pm_genpd_add_subdomain(domains->domains[area->parent],
> +
> domains->domains[area->isr_bit]);
> + if (error)
> + pr_warn("Failed to add PM subdomain %s to parent
> %u\n",
> + area->name, area->parent);
> + }
> +
> error = of_genpd_add_provider_onecell(np, &domains->onecell_data);
>
> out_put:
> --
> 2.7.4
>
[PATCH/RFT 2/2] arm64: dts: renesas: r8a77965: Add PCIe device nodes
From: Takeshi Kihara
This patch adds PCIe{0,1} device nodes to R8A77965 SoC.
Based on a similar patches of the R8A7796 device tree
by Harunobu Kurokawa .
Signed-off-by: Takeshi Kihara
Signed-off-by: Yoshihiro Kaneko
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 48 +--
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index d740c79..0d39a31 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1433,13 +1433,57 @@
};
pciec0: pcie@fe00 {
+ compatible = "renesas,pcie-r8a77965",
+"renesas,pcie-rcar-gen3";
reg = <0 0xfe00 0 0x8>;
- /* placeholder */
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x0100 0 0x 0 0xfe10 0
0x0010
+ 0x0200 0 0xfe20 0 0xfe20 0
0x0020
+ 0x0200 0 0x3000 0 0x3000 0
0x0800
+ 0x4200 0 0x3800 0 0x3800 0
0x0800>;
+ /* Map all possible DDR as inbound ranges */
+ dma-ranges = <0x4200 0 0x4000 0 0x4000 0
0x8000>;
+ interrupts = ,
+ ,
+ ;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 116
IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 319>, <&pcie_bus_clk>;
+ clock-names = "pcie", "pcie_bus";
+ power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
+ resets = <&cpg 319>;
+ status = "disabled";
};
pciec1: pcie@ee80 {
+ compatible = "renesas,pcie-r8a77965",
+"renesas,pcie-rcar-gen3";
reg = <0 0xee80 0 0x8>;
- /* placeholder */
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x0100 0 0x 0 0xee90 0
0x0010
+ 0x0200 0 0xeea0 0 0xeea0 0
0x0020
+ 0x0200 0 0xc000 0 0xc000 0
0x0800
+ 0x4200 0 0xc800 0 0xc800 0
0x0800>;
+ /* Map all possible DDR as inbound ranges */
+ dma-ranges = <0x4200 0 0x4000 0 0x4000 0
0x8000>;
+ interrupts = ,
+ ,
+ ;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 148
IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 318>, <&pcie_bus_clk>;
+ clock-names = "pcie", "pcie_bus";
+ power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
+ resets = <&cpg 318>;
+ status = "disabled";
};
fcpf0: fcp@fe95 {
--
1.9.1
[PATCH/RFT 1/2] PCI: rcar: Add compatible string for r8a77965
This patch adds support for r8a77965 (R-Car M3-N) Signed-off-by: Yoshihiro Kaneko --- Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt index 1fb614e..dd71cfe 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt @@ -8,6 +8,7 @@ compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC; "renesas,pcie-r8a7793" for the R8A7793 SoC; "renesas,pcie-r8a7795" for the R8A7795 SoC; "renesas,pcie-r8a7796" for the R8A7796 SoC; + "renesas,pcie-r8a77965" for the R8A77965 SoC; "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 or RZ/G1 compatible device. "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device. -- 1.9.1
[PATCH/RFT 0/2] Add PCIe support for r8a77965
This series adds PCIe support for r8a77965 (R-Car M3-N). It is not necessary to update driver and PFC. This series is based on the devel branch of Simon Horman's renesas tree. Takeshi Kihara (1): arm64: dts: renesas: r8a77965: Add PCIe device nodes Yoshihiro Kaneko (1): PCI: rcar: Add compatible string for r8a77965 Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 + arch/arm64/boot/dts/renesas/r8a77965.dtsi | 48 +- 2 files changed, 47 insertions(+), 2 deletions(-) -- 1.9.1
Re: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
Hi Shimoda-san,
On Thu, Jun 7, 2018 at 7:36 AM, Yoshihiro Shimoda
wrote:
>> From: Yoshihiro Shimoda, Sent: Thursday, May 31, 2018 6:12 PM
>> > From: Geert Uytterhoeven, Sent: Thursday, May 31, 2018 5:45 PM
>> > On Wed, May 30, 2018 at 10:35 AM, Yoshihiro Shimoda
>> > wrote:
>> > >> From: Wolfram Sang, Sent: Tuesday, May 29, 2018 7:59 PM
>> > >> Subject: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
>> > >
>> > > If possible, I'd like to replace "bug" with "specification" or other
>> > > words :)
>> > >
>> > >
>> > >> @@ -743,6 +753,16 @@ static int rcar_i2c_master_xfer(struct i2c_adapter
>> > >> *adap,
>> > >>
>> > >> pm_runtime_get_sync(dev);
>> > >>
>> > >> + /* Gen3 has a HW bug which needs a reset before allowing RX DMA
>> > >> once */
>> > >> + if (priv->devtype == I2C_RCAR_GEN3) {
>> > >> + priv->flags |= ID_P_NO_RXDMA;
>> > >> + if (!IS_ERR(priv->rstc)) {
>> > >> + ret = reset_control_reset(priv->rstc);
>> > >
>> > > According to the datasheet Rev.1.00 page 57-69, we should do:
>> > > reset_control_assert();
>> > > udelay(1);
>> > > reset_control_deassert();
>> > > while (reset_control_status())
>> > > ;
>> > > instead of reset_control_reset(), I think.
>> >
>> > The i2c-specific procedure documented at page 57-69 thus differs from
>> > the generic one at page 8A-58, which is what cpg_mssr_reset() implements.
>> >
>> > The latter waits 35µs instead of 1µs, so that should be safe.
>> > But it doesn't check the status bit. Is the longer delay sufficient, or
>> > should
>> > a check polling the status bit be added to cpg_mssr_reset()?
>>
>> Thank you for the pointed out.
>> I agree we should wait 35us for safe.
>> But, anyway I'll ask HW team about this contradiction and really need
>> polling the status.
>
> I got information about this topic.
>
> < In CPG / MSSR point of view >
> - This needs 35 usec wait while asserting.
> - After deasserted a reset, no wait needs.
> - In other words, there is each hardware IP dependence.
Let's call the above procedure A.
> < In I2C point of view >
> - After deasserted the reset, this nees SRCR register polling.
Let's call the above procedure B.
> So, I don't think cpg_mssr_reset() checks the status bit after deasserted a
> reset.
> But, what do you think?
cpg_mssr_reset() indeed does not check the status bit after deasserting
the reset, as it follows procedure A.
Such a check could be added, though. Then it'll become
(let's call this procedure C):
/* Reset module */
spin_lock_irqsave(&priv->rmw_lock, flags);
value = readl(priv->base + SRCR(reg));
value |= bitmask;
writel(value, priv->base + SRCR(reg));
spin_unlock_irqrestore(&priv->rmw_lock, flags);
/* Wait for at least one cycle of the RCLK clock (@ ca. 32 kHz) */
udelay(35);
/* Release module from reset state */
writel(bitmask, priv->base + SRSTCLR(reg));
+ /* Wait until deassertion has completed */
+ while (readl(priv->base + SRCR(reg)) & bitmask)
+ cpu_relax();
Probably we need an upper limit on the number of loops, and call udelay(1)
after each iteration?
for (i 0; i < 35; i++) {
if (!(readl(priv->base + SRCR(reg)) & bitmask))
return 0;
udelay(1);
}
return -EIO;
Any advice from the hardware team about that?
But according to procedure A, the check is not needed?
Probably because 35µs is an upper limit satisfying all individual hardware
modules?
I'm wondering whether we could use procedure B in the general case,
as it explicitly checks for completion?
Procedure C is safest, though, so probably the way to go.
Thanks!
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 4/4] mmc: renesas_sdhi: Fix SCC error detection
On Wed, Jun 06, 2018 at 10:47:24PM +0200, Niklas Söderlund wrote: > From: Masaharu Hayakawa > > SDR104 and HS200 need to check SCC error. If SCC error is detected, > retuning is necessary. > > In addition SCC error checking during retuning is unnecessary. > > Signed-off-by: Masaharu Hayakawa > [Niklas: fix small style issue] > Signed-off-by: Niklas Söderlund Same here, needs more explanation in the commit message IMO. Thanks for working on this! signature.asc Description: PGP signature
Re: [PATCH 3/4] mmc: renesas_sdhi: Fix sampling clock position selecting
On Wed, Jun 06, 2018 at 10:47:23PM +0200, Niklas Söderlund wrote: > From: Masaharu Hayakawa > > When the result of tuning was different between the first set and the > second set, there was a case where the wrong sampling clock position was > selected. As a countermeasure, make the two results the same. > > Signed-off-by: Masaharu Hayakawa > [Niklas: update commit message] > Signed-off-by: Niklas Söderlund As mentioned on IRC, I think this needs an updated patch description IMHO. signature.asc Description: PGP signature
Re: [PATCH 2/4] mmc: tmio: Fix SCC error detection
On Wed, Jun 06, 2018 at 10:47:22PM +0200, Niklas Söderlund wrote: > From: Masaharu Hayakawa > > SDR104 and HS200 need to check for SCC error. If SCC error is detected, > retuning is necessary. > > Signed-off-by: Masaharu Hayakawa > [Niklas: update commit message] > Signed-off-by: Niklas Söderlund It makes sense to me. We don't have a testcase to test this against, however :( How do other people test stuff like this? Rare error paths? signature.asc Description: PGP signature
Re: [PATCH 1/4] mmc: tmio: Fix tuning flow
> - if (ret == 0) > + if (!mmc_send_tuning(mmc, opcode, NULL)) I'd prefer '== 0' here as it makes clearer that we are checking for the good case here. But in general, the patch makes sense to me. signature.asc Description: PGP signature
