* [PATCH v2 08/14] sata: ahci-da850: implement a workaround for the softreset quirk
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, Bartosz Golaszewski, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
There's an issue with the da850 SATA controller: if port multiplier
support is compiled in, but we're connecting the drive directly to
the SATA port on the board, the drive can't be detected.
To make SATA work on the da850-lcdk board: first try to softreset
with pmp - if the operation fails with -EBUSY, retry without pmp.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/ata/ahci_da850.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index c071701..e0dc089 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -54,11 +54,42 @@ static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
writel(val, ahci_base + SATA_P0PHYCR_REG);
}
+static int ahci_da850_softreset(struct ata_link *link,
+ unsigned int *class, unsigned long deadline)
+{
+ int pmp, ret;
+
+ pmp = sata_srst_pmp(link);
+
+ /*
+ * There's an issue with the SATA controller on da850 SoCs: if we
+ * enable Port Multiplier support, but the drive is connected directly
+ * to the board, it can't be detected. As a workaround: if PMP is
+ * enabled, we first call ahci_do_softreset() and pass it the result of
+ * sata_srst_pmp(). If this call fails, we retry with pmp = 0.
+ */
+ ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
+ if (pmp && ret == -EBUSY)
+ return ahci_do_softreset(link, class, 0,
+ deadline, ahci_check_ready);
+
+ return ret;
+}
+
+static struct ata_port_operations ahci_da850_port_ops = {
+ .inherits = &ahci_platform_ops,
+ .softreset = ahci_da850_softreset,
+ /*
+ * No need to override .pmp_softreset - it's only used for actual
+ * PMP-enabled ports.
+ */
+};
+
static const struct ata_port_info ahci_da850_port_info = {
.flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
- .port_ops = &ahci_platform_ops,
+ .port_ops = &ahci_da850_port_ops,
};
static struct scsi_host_template ahci_platform_sht = {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 07/14] sata: ahci-da850: add device tree match table
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Bartosz Golaszewski
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
We're using device tree for da850-lcdk. Add the match table to allow
to probe the driver.
Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/ata/ahci_da850.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 18f57c2..c071701 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -121,11 +121,18 @@ static int ahci_da850_probe(struct platform_device *pdev)
static SIMPLE_DEV_PM_OPS(ahci_da850_pm_ops, ahci_platform_suspend,
ahci_platform_resume);
+static const struct of_device_id ahci_da850_of_match[] = {
+ { .compatible = "ti,da850-ahci", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ahci_da850_of_match);
+
static struct platform_driver ahci_da850_driver = {
.probe = ahci_da850_probe,
.remove = ata_platform_remove_one,
.driver = {
.name = DRV_NAME,
+ .of_match_table = ahci_da850_of_match,
.pm = &ahci_da850_pm_ops,
},
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 06/14] ARM: davinci: da850: model the SATA refclk
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, Bartosz Golaszewski, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
Register a dummy clock modelling the external SATA oscillator for
da850 DT mode. For non-DT boot we don't register the clock - instead
we rely on the default MPY value defined in the da850 ahci driver (as
is done currently).
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 8 ++++++++
arch/arm/mach-davinci/devices-da8xx.c | 23 +++++++++++++++++++++++
arch/arm/mach-davinci/include/mach/da8xx.h | 1 +
3 files changed, 32 insertions(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index b83e5d1..13137cb 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -61,6 +61,14 @@ static void __init da850_init_machine(void)
pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
__func__, ret);
+ if (of_machine_is_compatible("ti,da850-evm") ||
+ of_machine_is_compatible("ti,da850-lcdk")) {
+ ret = da850_register_sata_refclk(100000000);
+ if (ret)
+ pr_warn("%s: registering SATA_REFCLK clock failed: %d",
+ __func__, ret);
+ }
+
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
davinci_pm_init();
}
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index c2457b3..2bb5b69 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -24,6 +24,7 @@
#include <mach/common.h>
#include <mach/time.h>
#include <mach/da8xx.h>
+#include <mach/clock.h>
#include "cpuidle.h"
#include "sram.h"
@@ -1023,6 +1024,28 @@ int __init da8xx_register_spi_bus(int instance, unsigned num_chipselect)
}
#ifdef CONFIG_ARCH_DAVINCI_DA850
+static struct clk sata_refclk = {
+ .name = "sata_refclk",
+ .set_rate = davinci_simple_set_rate,
+};
+
+static struct clk_lookup sata_refclk_lookup =
+ CLK("ahci_da850", "refclk", &sata_refclk);
+
+int __init da850_register_sata_refclk(int rate)
+{
+ int ret;
+
+ sata_refclk.rate = rate;
+ ret = clk_register(&sata_refclk);
+ if (ret)
+ return ret;
+
+ clkdev_add(&sata_refclk_lookup);
+
+ return 0;
+}
+
static struct resource da850_sata_resources[] = {
{
.start = DA850_SATA_BASE,
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 85ff218..7e46422 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -95,6 +95,7 @@ int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
int da8xx_register_usb_refclkin(int rate);
int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
+int da850_register_sata_refclk(int rate);
int da8xx_register_emac(void);
int da8xx_register_uio_pruss(void);
int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 05/14] ARM: davinci: da850: add con_id for the SATA clock
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
The ahci-da850 SATA driver is now capable of retrieving clocks by
con_id. Add the connector id for the sysclk2-derived SATA clock.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 1d873d1..dbf1daa 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -571,7 +571,7 @@ static struct clk_lookup da850_clks[] = {
CLK("spi_davinci.0", NULL, &spi0_clk),
CLK("spi_davinci.1", NULL, &spi1_clk),
CLK("vpif", NULL, &vpif_clk),
- CLK("ahci_da850", NULL, &sata_clk),
+ CLK("ahci_da850", "sata", &sata_clk),
CLK("davinci-rproc.0", NULL, &dsp_clk),
CLK(NULL, NULL, &ehrpwm_clk),
CLK("ehrpwm.0", "fck", &ehrpwm0_clk),
--
2.9.3
^ permalink raw reply related
* [PATCH v2 04/14] sata: ahci-da850: get the sata clock using a connector id
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, Bartosz Golaszewski, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
In preparation for using two clocks in the driver (the sysclk2-based
clock and the external REFCLK), check if we got a functional clock
after calling ahci_platform_get_resources(). If not, retry calling
get_clk() with con_id specified.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/ata/ahci_da850.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 267a3d3..18f57c2 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -71,12 +71,28 @@ static int ahci_da850_probe(struct platform_device *pdev)
struct ahci_host_priv *hpriv;
struct resource *res;
void __iomem *pwrdn_reg;
+ struct clk *clk;
int rc;
hpriv = ahci_platform_get_resources(pdev);
if (IS_ERR(hpriv))
return PTR_ERR(hpriv);
+ /*
+ * Internally ahci_platform_get_resources() calls clk_get(dev, NULL)
+ * when trying to obtain the first clock. This SATA controller uses
+ * two clocks for which we specify two connector ids. If we don't
+ * have a clock at this point - call clk_get() again with
+ * con_id = "sata".
+ */
+ if (!hpriv->clks[0]) {
+ clk = clk_get(dev, "sata");
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ hpriv->clks[0] = clk;
+ }
+
rc = ahci_platform_enable_resources(hpriv);
if (rc)
return rc;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 03/14] ARM: davinci: add a clock lookup entry for the SATA clock
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
This entry is needed for the ahci driver to get a functional clock.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da..b83e5d1 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -42,6 +42,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
+ OF_DEV_AUXDATA("ti,da850-ahci", 0x01e18000, "ahci_da850", NULL),
{}
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 02/14] ARM: davinci_all_defconfig: enable SATA modules
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
Add the da850-ahci driver to davinci defconfig.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 8806754..a1b9c58 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -78,6 +78,8 @@ CONFIG_IDE=m
CONFIG_BLK_DEV_PALMCHIP_BK3710=m
CONFIG_SCSI=m
CONFIG_BLK_DEV_SD=m
+CONFIG_ATA=m
+CONFIG_AHCI_DA850=m
CONFIG_NETDEVICES=y
CONFIG_NETCONSOLE=y
CONFIG_TUN=m
--
2.9.3
^ permalink raw reply related
* [PATCH v2 01/14] devicetree: bindings: add bindings for ahci-da850
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
Add DT bindings for the TI DA850 AHCI SATA controller.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
Documentation/devicetree/bindings/ata/ahci-da850.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt
new file mode 100644
index 0000000..e7111b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
@@ -0,0 +1,18 @@
+Device tree binding for the TI DA850 AHCI SATA Controller
+---------------------------------------------------------
+
+Required properties:
+ - compatible: must be "ti,da850-ahci"
+ - reg: physical base addresses and sizes of the controller's register areas
+ - interrupts: interrupt specifier (refer to the interrupt binding)
+
+Optional properties:
+ - clocks: clock specifier (refer to the common clock binding)
+
+Example:
+
+ sata: ahci@218000 {
+ compatible = "ti,da850-ahci";
+ reg = <0x218000 0x2000>, <0x22c018 0x4>;
+ interrupts = <67>;
+ };
--
2.9.3
^ permalink raw reply related
* [PATCH v2 00/14] ARM: da850-lcdk: add SATA support
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
This series contains all the changes necessary to make SATA work on
the da850-lcdk board.
The first patch adds DT bindings for the ahci-da850 driver.
The second enables relevant modules in davinci_all_defconfig.
Patches 03/14-06/14 modify the way the clocks are handled regarding
SATA on the da850 platform. We modify the ahci driver to retrieve
the clock via con_id and model the external SATA oscillator as
a real clock.
Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
implement workarounds necessary to make SATA work on the da850-lcdk
board and un-hardcode the external clock multiplier.
Last three patches add device tree changes required to probe the
driver.
v1 -> v2:
- dropped patch 04/10 - replaced with local changes in the
ahci-da850 driver
- added comments explaining the workaround in ahci softreset
- s/0x218000/218000 in the sata DT node label
- added patches chaning the way clocks are handled in the da850 SATA
code both in arch/ and in the ahci driver
- dropped the clock multiplier property in the DT bindings in favor
of using struct clk to pass the refclk rate to the driver
- minor tweaks in commit messages
Bartosz Golaszewski (14):
devicetree: bindings: add bindings for ahci-da850
ARM: davinci_all_defconfig: enable SATA modules
ARM: davinci: add a clock lookup entry for the SATA clock
sata: ahci-da850: get the sata clock using a connector id
ARM: davinci: da850: add con_id for the SATA clock
ARM: davinci: da850: model the SATA refclk
sata: ahci-da850: add device tree match table
sata: ahci-da850: implement a workaround for the softreset quirk
sata: ahci: export ahci_do_hardreset() locally
sata: ahci-da850: add a workaround for controller instability
sata: ahci-da850: un-hardcode the MPY bits
ARM: dts: da850: add pinmux settings for the SATA controller
ARM: dts: da850: add the SATA node
ARM: dts: da850-lcdk: enable the SATA node
.../devicetree/bindings/ata/ahci-da850.txt | 18 +++
arch/arm/boot/dts/da850-lcdk.dts | 4 +
arch/arm/boot/dts/da850.dtsi | 30 ++++
arch/arm/configs/davinci_all_defconfig | 2 +
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 9 ++
arch/arm/mach-davinci/devices-da8xx.c | 23 +++
arch/arm/mach-davinci/include/mach/da8xx.h | 1 +
drivers/ata/ahci.h | 3 +
drivers/ata/ahci_da850.c | 172 +++++++++++++++++++--
drivers/ata/libahci.c | 18 ++-
11 files changed, 262 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
--
2.9.3
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: juno: add missing CoreSight STM component
From: Sudeep Holla @ 2017-01-17 12:15 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, Mike Leach, Mathieu Poirier, Lorenzo Pieralisi,
Suzuki K . Poulose, coresight-cunTk1MwBs8s++Sfvej+rw, Liviu Dudau,
devicetree-u79uwXL29TY76Z2rM5mHXA, Olof Johansson
In-Reply-To: <1484655313-9025-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
From: Mike Leach <mike.leach-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch adds the missing CoreSight STM component definition to the
device tree of all the juno variants(r0,r1,r2)
STM component is connected to different funnels depending on Juno
platform variant.
Reviewed-and-Tested-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Mike Leach <mike.leach-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[sudeep.holla-5wv7dgnIgG8@public.gmane.org: minor changelog update and reorganising the STM
node back into juno-base.dtsi to avoid duplication]
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 4 ++++
arch/arm64/boot/dts/arm/juno-r2.dts | 4 ++++
arch/arm64/boot/dts/arm/juno.dts | 16 ++++++++++++++++
4 files changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index faedf357db3b..58c1773c3aa4 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -185,6 +185,21 @@
};
};
+ stm@20100000 {
+ compatible = "arm,coresight-stm", "arm,primecell";
+ reg = <0 0x20100000 0 0x1000>,
+ <0 0x28000000 0 0x180000>;
+ reg-names = "stm-base", "stm-stimulus-base";
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ stm_out_port: endpoint {
+ };
+ };
+ };
+
etm0: etm@22040000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0 0x22040000 0 0x1000>;
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index aef138aa5765..0033c59a64b5 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -235,3 +235,7 @@
&replicator_in_port0 {
remote-endpoint = <&csys2_funnel_out_port>;
};
+
+&stm_out_port {
+ remote-endpoint = <&csys1_funnel_in_port0>;
+};
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index 827da7c92607..218d0e4736a8 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -235,3 +235,7 @@
&replicator_in_port0 {
remote-endpoint = <&csys2_funnel_out_port>;
};
+
+&stm_out_port {
+ remote-endpoint = <&csys1_funnel_in_port0>;
+};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 66fa4388d181..bb2820ef3d5b 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -210,3 +210,19 @@
&replicator_in_port0 {
remote-endpoint = <&etf0_out_port>;
};
+
+&stm_out_port {
+ remote-endpoint = <&main_funnel_in_port2>;
+};
+
+&main_funnel {
+ ports {
+ port@3 {
+ reg = <2>;
+ main_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&stm_out_port>;
+ };
+ };
+ };
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 3/4] arm64: dts: juno: add CoreSight support for Juno r1/r2 variants
From: Sudeep Holla @ 2017-01-17 12:15 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, Mike Leach, Mathieu Poirier, Lorenzo Pieralisi,
Suzuki K . Poulose, coresight-cunTk1MwBs8s++Sfvej+rw, Liviu Dudau,
devicetree-u79uwXL29TY76Z2rM5mHXA, Olof Johansson
In-Reply-To: <1484655313-9025-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
From: Mike Leach <mike.leach-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
The CoreSight support added for Juno is valid for only Juno r0.
The Juno r1 and r2 variants have additional components and alternative
connection routes between trace source and sinks.
This patch builds on top of the existing r0 support and extends it to
Juno r1/r2 variants.
Reviewed-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Mike Leach <mike.leach-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[sudeep.holla-5wv7dgnIgG8@public.gmane.org: minor changelog update and major reorganisation of
the common coresight components back into juno-base.dtsi to avoid
duplication, also renamed funnel node names]
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 100 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 9 +++
arch/arm64/boot/dts/arm/juno-r2.dts | 9 +++
3 files changed, 118 insertions(+)
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
new file mode 100644
index 000000000000..563463ed28c7
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -0,0 +1,100 @@
+/ {
+ funnel@20130000 { /* cssys2 */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20130000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* output port */
+ port@0 {
+ reg = <0>;
+ csys1_funnel_out_port: endpoint {
+ remote-endpoint = <&etf1_in_port>;
+ };
+ };
+
+ /* input port */
+ port@1 {
+ reg = <0>;
+ csys1_funnel_in_port0: endpoint {
+ slave-mode;
+ };
+ };
+
+ };
+ };
+
+ etf@20140000 { /* ETF 1 */
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20140000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port@0 {
+ reg = <0>;
+ etf1_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&csys1_funnel_out_port>;
+ };
+ };
+
+ /* output port */
+ port@1 {
+ reg = <0>;
+ etf1_out_port: endpoint {
+ remote-endpoint = <&csys2_funnel_in_port1>;
+ };
+ };
+ };
+ };
+
+ funnel@20150000 { /* cssys2 */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20150000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* output port */
+ port@0 {
+ reg = <0>;
+ csys2_funnel_out_port: endpoint {
+ remote-endpoint = <&replicator_in_port0>;
+ };
+ };
+
+ /* input ports */
+ port@1 {
+ reg = <0>;
+ csys2_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf0_out_port>;
+ };
+ };
+
+ port@2 {
+ reg = <1>;
+ csys2_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf1_out_port>;
+ };
+ };
+
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index b883a8afb6f4..aef138aa5765 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -10,6 +10,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include "juno-base.dtsi"
+#include "juno-cs-r1r2.dtsi"
/ {
model = "ARM Juno development board (r1)";
@@ -226,3 +227,11 @@
&gpu1_thermal_zone {
status = "okay";
};
+
+&etf0_out_port {
+ remote-endpoint = <&csys2_funnel_in_port0>;
+};
+
+&replicator_in_port0 {
+ remote-endpoint = <&csys2_funnel_out_port>;
+};
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index cfd8150bf30a..827da7c92607 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -10,6 +10,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include "juno-base.dtsi"
+#include "juno-cs-r1r2.dtsi"
/ {
model = "ARM Juno development board (r2)";
@@ -226,3 +227,11 @@
&gpu1_thermal_zone {
status = "okay";
};
+
+&etf0_out_port {
+ remote-endpoint = <&csys2_funnel_in_port0>;
+};
+
+&replicator_in_port0 {
+ remote-endpoint = <&csys2_funnel_out_port>;
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 2/4] arm64: dts: juno: refactor CoreSight support on Juno r0
From: Sudeep Holla @ 2017-01-17 12:15 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, Mike Leach, Mathieu Poirier, Lorenzo Pieralisi,
Suzuki K . Poulose, coresight-cunTk1MwBs8s++Sfvej+rw, Liviu Dudau,
devicetree-u79uwXL29TY76Z2rM5mHXA, Olof Johansson
In-Reply-To: <1484655313-9025-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Currently the Coresight components are supported only on Juno r0
variant. In preparation to add support to Juno r1/r2 variants, this
patch refactors the existing coresight device nodes so that r1/r2
support can be added easily.
It also cleans up some of the device node names which were previously
named so as they were confused as the labels rather than the node names.
Reviewed-and-Tested-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 20 ++++++++++----------
arch/arm64/boot/dts/arm/juno.dts | 8 ++++++++
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 580afaee978f..faedf357db3b 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -86,7 +86,7 @@
* The actual size is just 4K though 64K is reserved. Access to the
* unmapped reserved region results in a DECERR response.
*/
- etf@20010000 {
+ etf@20010000 { /* ETF 0 */
compatible = "arm,coresight-tmc", "arm,primecell";
reg = <0 0x20010000 0 0x1000>;
@@ -100,7 +100,7 @@
/* input port */
port@0 {
reg = <0>;
- etf_in_port: endpoint {
+ etf0_in_port: endpoint {
slave-mode;
remote-endpoint = <&main_funnel_out_port>;
};
@@ -109,8 +109,7 @@
/* output port */
port@1 {
reg = <0>;
- etf_out_port: endpoint {
- remote-endpoint = <&replicator_in_port0>;
+ etf0_out_port: endpoint {
};
};
};
@@ -131,7 +130,8 @@
};
};
- main-funnel@20040000 {
+ /* main funnel on Juno r0, cssys0 funnel on Juno r1/r2 as per TRM*/
+ main_funnel: funnel@20040000 {
compatible = "arm,coresight-funnel", "arm,primecell";
reg = <0 0x20040000 0 0x1000>;
@@ -142,13 +142,15 @@
#address-cells = <1>;
#size-cells = <0>;
+ /* output port */
port@0 {
reg = <0>;
main_funnel_out_port: endpoint {
- remote-endpoint = <&etf_in_port>;
+ remote-endpoint = <&etf0_in_port>;
};
};
+ /* input ports */
port@1 {
reg = <0>;
main_funnel_in_port0: endpoint {
@@ -164,7 +166,6 @@
remote-endpoint = <&cluster1_funnel_out_port>;
};
};
-
};
};
@@ -198,7 +199,7 @@
};
};
- cluster0-funnel@220c0000 {
+ funnel@220c0000 { /* cluster0 funnel */
compatible = "arm,coresight-funnel", "arm,primecell";
reg = <0 0x220c0000 0 0x1000>;
@@ -262,7 +263,7 @@
};
};
- cluster1-funnel@230c0000 {
+ funnel@230c0000 { /* cluster1 funnel */
compatible = "arm,coresight-funnel", "arm,primecell";
reg = <0 0x230c0000 0 0x1000>;
@@ -385,7 +386,6 @@
reg = <0>;
replicator_in_port0: endpoint {
slave-mode;
- remote-endpoint = <&etf_out_port>;
};
};
};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 9967c808a92d..66fa4388d181 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -202,3 +202,11 @@
&etm5 {
cpu = <&A53_3>;
};
+
+&etf0_out_port {
+ remote-endpoint = <&replicator_in_port0>;
+};
+
+&replicator_in_port0 {
+ remote-endpoint = <&etf0_out_port>;
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/4] arm64: dts: juno: remove dtsi nesting inside tree structure
From: Sudeep Holla @ 2017-01-17 12:15 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, Mike Leach, Mathieu Poirier, Lorenzo Pieralisi,
Suzuki K . Poulose, coresight-cunTk1MwBs8s++Sfvej+rw, Liviu Dudau,
devicetree-u79uwXL29TY76Z2rM5mHXA, Olof Johansson
In-Reply-To: <1484655313-9025-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Currently juno-clock.dtsi and juno-base.dtsi are nested badly inside
the device tree structure. It's generally good practice to ensure that
individual dtsi stand by themselves at the top of the file.
This patch removes the nesting of the above mentioned dtsi files and
makes them independent.
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 6 ++++--
arch/arm64/boot/dts/arm/juno-clocks.dtsi | 3 ++-
arch/arm64/boot/dts/arm/juno-r1.dts | 3 +--
arch/arm64/boot/dts/arm/juno-r2.dts | 3 +--
arch/arm64/boot/dts/arm/juno.dts | 3 +--
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 7d832247d0db..580afaee978f 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -1,3 +1,6 @@
+#include "juno-clocks.dtsi"
+
+/ {
/*
* Devices shared by all Juno boards
*/
@@ -507,8 +510,6 @@
};
};
- /include/ "juno-clocks.dtsi"
-
smmu_dma: iommu@7fb00000 {
compatible = "arm,mmu-401", "arm,smmu-v1";
reg = <0x0 0x7fb00000 0x0 0x10000>;
@@ -719,3 +720,4 @@
interrupt-map-mask = <0 0>;
interrupt-map = <0 0 &gic 0 0 0 168 IRQ_TYPE_LEVEL_HIGH>;
};
+};
diff --git a/arch/arm64/boot/dts/arm/juno-clocks.dtsi b/arch/arm64/boot/dts/arm/juno-clocks.dtsi
index 25352ed943e6..e5e265dfa902 100644
--- a/arch/arm64/boot/dts/arm/juno-clocks.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-clocks.dtsi
@@ -6,7 +6,7 @@
* This file is licensed under a dual GPLv2 or BSD license.
*
*/
-
+/ {
/* SoC fixed clocks */
soc_uartclk: refclk7273800hz {
compatible = "fixed-clock";
@@ -42,3 +42,4 @@
clock-frequency = <400000000>;
clock-output-names = "faxi_clk";
};
+};
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index eec37feee8fc..b883a8afb6f4 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -9,6 +9,7 @@
/dts-v1/;
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "juno-base.dtsi"
/ {
model = "ARM Juno development board (r1)";
@@ -176,8 +177,6 @@
<&A53_2>,
<&A53_3>;
};
-
- #include "juno-base.dtsi"
};
&memtimer {
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index 28f40ec44090..cfd8150bf30a 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -9,6 +9,7 @@
/dts-v1/;
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "juno-base.dtsi"
/ {
model = "ARM Juno development board (r2)";
@@ -176,8 +177,6 @@
<&A53_2>,
<&A53_3>;
};
-
- #include "juno-base.dtsi"
};
&memtimer {
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index ac5ceb73f45f..9967c808a92d 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -9,6 +9,7 @@
/dts-v1/;
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "juno-base.dtsi"
/ {
model = "ARM Juno development board (r0)";
@@ -176,8 +177,6 @@
<&A53_2>,
<&A53_3>;
};
-
- #include "juno-base.dtsi"
};
&etm0 {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 0/4] arm64: dts: juno: CoreSight support updates
From: Sudeep Holla @ 2017-01-17 12:15 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, Mike Leach, Mathieu Poirier, Lorenzo Pieralisi,
Suzuki K . Poulose, coresight-cunTk1MwBs8s++Sfvej+rw, Liviu Dudau,
devicetree-u79uwXL29TY76Z2rM5mHXA, Olof Johansson
Juno r1/r2 boards have different CoreSight infrastructure outside the
CPU clusters. This patchset adds the additional coreSight components to
separate .dtsi files to support these differences.
v1->v2:
- moved the addition of the STM component into a separate patch
v2->v3:
- moved the back the common coreSight components back into
juno-base.dtsi
v3->v4:
- removed dtsi nesting in the existing Juno dts file to avoid
further addition of such nesting
- renamed some of the funnel and etf node names(which were
previously named confusing them to the labels
Mike Leach (2):
arm64: dts: juno: add CoreSight support for Juno r1/r2 variants
arm64: dts: juno: add missing CoreSight STM component
Sudeep Holla (2):
arm64: dts: juno: remove dtsi nesting inside tree structure
arm64: dts: juno: refactor CoreSight support on Juno r0
arch/arm64/boot/dts/arm/juno-base.dtsi | 41 ++++++++----
arch/arm64/boot/dts/arm/juno-clocks.dtsi | 3 +-
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 100 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 16 ++++-
arch/arm64/boot/dts/arm/juno-r2.dts | 16 ++++-
arch/arm64/boot/dts/arm/juno.dts | 27 +++++++-
6 files changed, 184 insertions(+), 19 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] clk: meson-gxbb: Export HDMI clocks
From: Neil Armstrong @ 2017-01-17 12:08 UTC (permalink / raw)
To: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Export HDMI clock from internal to dt-bindings.
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/clk/meson/gxbb.h | 4 ++--
include/dt-bindings/clock/gxbb-clkc.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 0252939..2139e97 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -231,7 +231,7 @@
#define CLKID_AHB_DATA_BUS 60
#define CLKID_AHB_CTRL_BUS 61
#define CLKID_HDMI_INTR_SYNC 62
-#define CLKID_HDMI_PCLK 63
+/* CLKID_HDMI_PCLK */
/* CLKID_USB1_DDR_BRIDGE */
/* CLKID_USB0_DDR_BRIDGE */
#define CLKID_MMC_PCLK 66
@@ -245,7 +245,7 @@
#define CLKID_VCLK2_VENCI1 74
#define CLKID_VCLK2_VENCP0 75
#define CLKID_VCLK2_VENCP1 76
-#define CLKID_GCLK_VENCI_INT0 77
+/* CLKID_GCLK_VENCI_INT0 */
#define CLKID_GCLK_VENCI_INT 78
#define CLKID_DAC_CLK 79
#define CLKID_AOCLK_GATE 80
diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
index baade6f..da1d473 100644
--- a/include/dt-bindings/clock/gxbb-clkc.h
+++ b/include/dt-bindings/clock/gxbb-clkc.h
@@ -18,8 +18,10 @@
#define CLKID_USB0 50
#define CLKID_USB1 51
#define CLKID_USB 55
+#define CLKID_HDMI_PCLK 63
#define CLKID_USB1_DDR_BRIDGE 64
#define CLKID_USB0_DDR_BRIDGE 65
+#define CLKID_GCLK_VENCI_INT0 77
#define CLKID_AO_I2C 93
#define CLKID_SD_EMMC_A 94
#define CLKID_SD_EMMC_B 95
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] ARM64: dts: meson-gx: Add HDMI HPD/DDC pinctrl nodes
From: Neil Armstrong @ 2017-01-17 12:05 UTC (permalink / raw)
To: khilman, carlo, linus.walleij
Cc: devicetree, Neil Armstrong, linux-kernel, linux-gpio,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1484654738-5496-1-git-send-email-narmstrong@baylibre.com>
Add pinctrl nodes for HDMI HPD and DDC pins modes for Amlogic Meson GXL
and GXBB SoCs.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 14 ++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 14 ++++++++++++++
2 files changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 596240c..31d64a1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -463,6 +463,20 @@
function = "pwm_f_y";
};
};
+
+ hdmi_hpd_pins: hdmi_hpd {
+ mux {
+ groups = "hdmi_hpd";
+ function = "hdmi_hpd";
+ };
+ };
+
+ hdmi_i2c_pins: hdmi_i2c {
+ mux {
+ groups = "hdmi_sda", "hdmi_scl";
+ function = "hdmi_i2c";
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 6921624..17dbcf6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -229,6 +229,20 @@
function = "pwm_e";
};
};
+
+ hdmi_hpd_pins: hdmi_hpd {
+ mux {
+ groups = "hdmi_hpd";
+ function = "hdmi_hpd";
+ };
+ };
+
+ hdmi_i2c_pins: hdmi_i2c {
+ mux {
+ groups = "hdmi_sda", "hdmi_scl";
+ function = "hdmi_i2c";
+ };
+ };
};
eth-phy-mux {
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] pinctrl: meson: Add HDMI HPD/DDC pins functions
From: Neil Armstrong @ 2017-01-17 12:05 UTC (permalink / raw)
To: khilman, carlo, linus.walleij
Cc: devicetree, Neil Armstrong, linux-kernel, linux-gpio,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1484654738-5496-1-git-send-email-narmstrong@baylibre.com>
Add pinctrl functions for HDMI HPD pin and DDC pins on Amlogic Meson
GXL and GXBB SoCs.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 19 +++++++++++++++++++
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 19 +++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index c3928aa..0d9ad36 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -232,6 +232,10 @@
static const unsigned int pwm_f_x_pins[] = { PIN(GPIOX_7, EE_OFF) };
static const unsigned int pwm_f_y_pins[] = { PIN(GPIOY_15, EE_OFF) };
+static const unsigned int hdmi_hpd_pins[] = { PIN(GPIOH_0, EE_OFF) };
+static const unsigned int hdmi_sda_pins[] = { PIN(GPIOH_1, EE_OFF) };
+static const unsigned int hdmi_scl_pins[] = { PIN(GPIOH_2, EE_OFF) };
+
static const struct pinctrl_pin_desc meson_gxbb_aobus_pins[] = {
MESON_PIN(GPIOAO_0, 0),
MESON_PIN(GPIOAO_1, 0),
@@ -440,6 +444,11 @@
GROUP(eth_txd2, 6, 3),
GROUP(eth_txd3, 6, 2),
+ /* Bank H */
+ GROUP(hdmi_hpd, 1, 26),
+ GROUP(hdmi_sda, 1, 25),
+ GROUP(hdmi_scl, 1, 24),
+
/* Bank DV */
GROUP(uart_tx_b, 2, 29),
GROUP(uart_rx_b, 2, 28),
@@ -636,6 +645,14 @@
"pwm_f_y",
};
+static const char * const hdmi_hpd_groups[] = {
+ "hdmi_hpd",
+};
+
+static const char * const hdmi_i2c_groups[] = {
+ "hdmi_sda", "hdmi_scl",
+};
+
static const char * const gpio_aobus_groups[] = {
"GPIOAO_0", "GPIOAO_1", "GPIOAO_2", "GPIOAO_3", "GPIOAO_4",
"GPIOAO_5", "GPIOAO_6", "GPIOAO_7", "GPIOAO_8", "GPIOAO_9",
@@ -699,6 +716,8 @@
FUNCTION(pwm_e),
FUNCTION(pwm_f_x),
FUNCTION(pwm_f_y),
+ FUNCTION(hdmi_hpd),
+ FUNCTION(hdmi_i2c),
};
static struct meson_pmx_func meson_gxbb_aobus_functions[] = {
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxl.c b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
index 25694f7..7703a46 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxl.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
@@ -197,6 +197,10 @@
static const unsigned int pwm_e_pins[] = { PIN(GPIOX_16, EE_OFF) };
+static const unsigned int hdmi_hpd_pins[] = { PIN(GPIOH_0, EE_OFF) };
+static const unsigned int hdmi_sda_pins[] = { PIN(GPIOH_1, EE_OFF) };
+static const unsigned int hdmi_scl_pins[] = { PIN(GPIOH_2, EE_OFF) };
+
static const struct pinctrl_pin_desc meson_gxl_aobus_pins[] = {
MESON_PIN(GPIOAO_0, 0),
MESON_PIN(GPIOAO_1, 0),
@@ -363,6 +367,11 @@
GROUP(eth_txd2, 4, 11),
GROUP(eth_txd3, 4, 10),
+ /* Bank H */
+ GROUP(hdmi_hpd, 6, 31),
+ GROUP(hdmi_sda, 6, 30),
+ GROUP(hdmi_scl, 6, 29),
+
/* Bank DV */
GROUP(uart_tx_b, 2, 16),
GROUP(uart_rx_b, 2, 15),
@@ -506,6 +515,14 @@
"pwm_e",
};
+static const char * const hdmi_hpd_groups[] = {
+ "hdmi_hpd",
+};
+
+static const char * const hdmi_i2c_groups[] = {
+ "hdmi_sda", "hdmi_scl",
+};
+
static const char * const gpio_aobus_groups[] = {
"GPIOAO_0", "GPIOAO_1", "GPIOAO_2", "GPIOAO_3", "GPIOAO_4",
"GPIOAO_5", "GPIOAO_6", "GPIOAO_7", "GPIOAO_8", "GPIOAO_9",
@@ -537,6 +554,8 @@
FUNCTION(i2c_c),
FUNCTION(eth),
FUNCTION(pwm_e),
+ FUNCTION(hdmi_hpd),
+ FUNCTION(hdmi_i2c),
};
static struct meson_pmx_func meson_gxl_aobus_functions[] = {
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] pinctrl: meson-gx: Add HDMI HDP/DDC pins functions
From: Neil Armstrong @ 2017-01-17 12:05 UTC (permalink / raw)
To: khilman, carlo, linus.walleij
Cc: devicetree, Neil Armstrong, linux-kernel, linux-gpio,
linux-amlogic, linux-arm-kernel
In order to support HDMI HPD and DDC, add missing functions in pinctrl
driver and add corresponding nodes in dts for GXBB and GXL.
Neil Armstrong (2):
pinctrl: meson: Add HDMI HPD/DDC pins functions
ARM64: dts: meson-gx: Add HDMI HPD/DDC pinctrl nodes
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 14 ++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 14 ++++++++++++++
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 19 +++++++++++++++++++
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 19 +++++++++++++++++++
4 files changed, 66 insertions(+)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 03/10] devicetree: bindings: add bindings for ahci-da850
From: Sekhar Nori @ 2017-01-17 12:00 UTC (permalink / raw)
To: David Lechner, Bartosz Golaszewski
Cc: Kevin Hilman, Patrick Titiano, Michael Turquette, Tejun Heo,
Rob Herring, Mark Rutland, Russell King,
linux-ide-u79uwXL29TY76Z2rM5mHXA, linux-devicetree, LKML, arm-soc
In-Reply-To: <fb93275e-73ad-513b-6ac8-a39bbe43fd5c-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Tuesday 17 January 2017 12:17 AM, David Lechner wrote:
> On 01/16/2017 08:30 AM, Bartosz Golaszewski wrote:
>> 2017-01-16 13:45 GMT+01:00 Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>:
>>> On Monday 16 January 2017 03:43 PM, Bartosz Golaszewski wrote:
>>>> 2017-01-13 20:25 GMT+01:00 David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>:
>>>>>
>>>>> A clock multiplier property seems redundant if you are specifying a
>>>>> clock.
>>>>> It should be possible to get the rate from the clock to determine
>>>>> which
>>>>> multiplier is needed.
>>>>>
>>>>
>>>> I probably should have named it differently. This is not a multiplier
>>>> of a clock derived from PLL0 or PLL1. Instead it's a value set by
>>>> writing to the Port PHY Control Register (MPY bits) of the SATA
>>>> controller that configures the multiplier for the external low-jitter
>>>> clock. On the lcdk the signals (REFCLKP, REFCLKN) are provided by
>>>> CDCM61001 (SATA OSCILLATOR component on the schematics).
>>>>
>>>> I'll find a better name and comment the property accordingly.
>>>>
>>>> FYI: the da850 platform does not use the common clock framework, so I
>>>> don't specify the clock property on the sata node in the device tree.
>>>> Instead I add the clock lookup entry in patch [01/10]. This is
>>>> transparent for AHCI which can get the clock as usual by calling
>>>> clk_get() in ahci_platform_get_resources().
>>>
>>> I think David's point is that the SATA_REFCLK needs to be modeled as a
>>> actual clock input to the IP. You should be able to get the rate using
>>> clk_get_rate() and make the MPY bits calculation depending on the
>>> incoming rate.
>>>
>>> You should be able to model the clock even when not using common clock
>>> framework.
>>>
>>> DA850 AHCI does not use a con_id at the moment (it assumes a single
>>> clock), and that needs to change.
>>>
>>
>> It's true that once davinci gets ported (is this planned?) to using
>> the common clock framework, we could just create a fixed-clock node in
>> da850-lcdk for the SATA oscillator, so the new property is redundant.
>>
>
> I have some commits[1] where I started on converting da850 to use the
> common clock framework. But, I don't know anything about other davinci
> family devices, so I don't think I could really take that to completion
> without lots of help.
I can help with testing, reviewing and filling in any missing
information. But I wont have time to write the code itself.
>
> [1]: https://github.com/dlech/ev3dev-kernel/commits/wip-20160509
I see that you have made a copy of the keystone PSC driver. I think you
will need pretty strong reasons to not use the same driver with some
customization for DaVinci.
>> What I don't get is how should I model a clock that is not
>> configurable and is board-specific? Is hard-coding the relevant rate
>> in da850.c with a huge FIXME the right way?
>
> In arch/arm/mach-davinci/usb-da8xx.c, there is a "usb_refclkin" that is
> very similar to the situation with the sata refclk. You could do
> something like this to register the clock...
>
> ---
>
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
> b/arch/arm/mach-davinci/devices-da8xx.c
> index c2457b3..790efce9 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -1023,6 +1023,34 @@ int __init da8xx_register_spi_bus(int instance,
> unsigned num_chipselect)
> }
>
> #ifdef CONFIG_ARCH_DAVINCI_DA850
> +
> +static struct clk sata_refclkin = {
> + .name = "sata_refclkin",
> + .set_rate = davinci_simple_set_rate,
> +};
> +
> +static struct clk_lookup sata_refclkin_lookup =
> + CLK(NULL, "sata_refclkin", &sata_refclkin);
> +
> +/**
> + * da8xx_register_sata_refclkin - register SATA_REFCLKIN clock
> + *
> + * @rate: The clock rate in Hz
> + */
> +int __init da850_register_sata_refclkin(int rate)
> +{
> + int ret;
> +
> + sata_refclkin.rate = rate;
> + ret = clk_register(&sata_refclkin);
> + if (ret)
> + return ret;
> +
> + clkdev_add(&sata_refclkin_lookup);
> +
> + return 0;
> +}
> +
> static struct resource da850_sata_resources[] = {
> {
> .start = DA850_SATA_BASE,
> @@ -1055,8 +1083,11 @@ static struct platform_device da850_sata_device = {
>
> int __init da850_register_sata(unsigned long refclkpn)
> {
> - /* please see comment in drivers/ata/ahci_da850.c */
> - BUG_ON(refclkpn != 100 * 1000 * 1000);
> + int err;
> +
> + err = da850_register_sata_refclkin(refclkpn);
> + if (err)
> + return err;
>
> return platform_device_register(&da850_sata_device);
> }
>
> ---
>
> Then to get things working from device tree, add this...
>
> ---
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
> b/arch/arm/mach-davinci/da8xx-dt.c
> index d2be194..b54bdd6 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -60,6 +60,14 @@ static void __init da850_init_machine(void)
> pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
> __func__, ret);
>
> + if (of_machine_is_compatible("ti,da850-evm") ||
> + of_machine_is_compatible("ti,da850-lcdk")) {
> + ret = da850_register_sata_refclkin(100000000);
> + if (ret)
> + pr_warn("%s: registering SATA_REFCLK clock
> failed: %d",
> + __func__, ret);
> + }
> +
> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> davinci_pm_init();
> pdata_quirks_init();
This approach is fine.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
From: Joao Pinto @ 2017-01-17 11:48 UTC (permalink / raw)
To: Lukasz Majewski, Joao Pinto
Cc: Kishon Vijay Abraham I, jingoohan1@gmail.com, Bjorn Helgaas,
Rob Herring, Mark Rutland, linux-omap, linux-pci, devicetree,
linux-kernel, Finger, Robert
In-Reply-To: <20170117123845.5addb519@jawa>
Hello,
Às 11:38 AM de 1/17/2017, Lukasz Majewski escreveu:
> Hi Joao,
>
> Thank you for your reply.
>
>> Às 10:43 AM de 1/17/2017, Joao Pinto escreveu:
>>>
>>> Hi Lukasz,
>>>
>>> Às 9:44 PM de 1/16/2017, Lukasz Majewski escreveu:
>>>> Hi Joao,
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Às 10:13 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>>>>>> + Joao, Jingoo
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
>>>>>>> Hi Kishon,
>>>>>>>
>>>>>>>> Hi Łukasz,
>>>>>>>>
>>>>>>>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
>>>>>>>>> Hi Kishon,
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>>>>>>>>>> Some devices (due to e.g. bad PCIe signal integrity)
>>>>>>>>>>> require to run with forced GEN1 speed on PCIe bus.
>>>>>>>>>>>
>>>>>>>>>>> This patch changes the speed explicitly on dra7 based
>>>>>>>>>>> devices when proper device tree attribute is defined for
>>>>>>>>>>> the PCIe controller.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>>>>>>>>>
>>>>>>>>>> Bjorn has already queued a patch to do the same thing
>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_helgaas_pci.git_log_-3Fh-3Dpci_host-2Ddra7xx&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=E8zk1CbKxGH-f3fw_WpXxFU-A8BLkgA8NusCaxk1SvA&e=
>>>>>>>>>
>>>>>>>>> It seems like Bjorn only modifies CAP registers.
>>>>>>>>
>>>>>>>> The patch also modifies the LNKCTL2 register.
>>>>>>>>>
>>>>>>>>> He also needs to change register with 0x080C offset to
>>>>>>>>> actually ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>>>>>>>>
>>>>>>>> This bit is used to initiate speed change (after the link is
>>>>>>>> initialized in GEN1). Resetting the bit (like what you have
>>>>>>>> done here) prevents speed change.
>>>>>>>
>>>>>>> This is strange, but e2e advised me to do things as I did in the
>>>>>>> patch to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
>>>>>>>
>>>>>>> Link:
>>>>>>> [1]
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_arm_sitara-5Farm_f_791_t_566421&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=uXLwglyRYqKpwp1JSxkOWmKpQ2wjfhgofpm8DCfquNw&e=
>>>>>>>
>>>>>>> Both patches modify 0x5180 007C register to set GEN1 capability
>>>>>>> (PCI_EXP_LNKCAP_SLS_2_5GB)
>>>>>>>
>>>>>>> The problem is with second register (in your patch):
>>>>>>>
>>>>>>> From SPRUHZ6G TRM:
>>>>>>>
>>>>>>> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
>>>>>>> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
>>>>>>> description in TRM
>>>>>>>
>>>>>>> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same
>>>>>>> as default /reset value.
>>>>>>
>>>>>> The default value is 0x2 (or else none of the cards would have
>>>>>> enumerated in GEN2)
>>>>>>>
>>>>>>>
>>>>>>> Could you clarify which way to _force_ PCIe GEN1 operation is
>>>>>>> correct? Mine shows differences in lspci output (as posted in
>>>>>>> [1]).
>>>>>>
>>>>>> You'll see the difference even with the patch in Bjorn's tree ;-)
>>>>>>
>>>>>> I think these are 2 different approaches to keep the link at
>>>>>> GEN1. Joao or Jingoo, do you have any suggestion here?
>>>>>
>>>>> I studied the Databook,
>>>>
>>>> Could you reveal which databook do you have in mind? Is that the
>>>> TRM for AM5728?
>>>
>>> I checked the Designware PCIe Databook, since it is based on this
>>> IP.
>>>
>>>>
>>>>> and both approaches seem to be right,
>>>>> dependently of the Core configuration and setup.
>>>>>
>>>>> The standard manual speed change sequence is:
>>>>> a) Write to PCIE_CAP_TARGET_LINK_SPEED (indicating desired speed)
>>>>
>>>> Do you mean TRGT_LINK_SPEED @ 0x5180 00A0 ?
>>>
>>> Correct.
>>>
>>>>
>>>>> b) Clear "Directed Speed Change"
>>>>
>>>> CFG_DIRECTED_SPEED_CHANGE @ 0x5180 080C
>>>
>>> Correct.
>>>
>>>>
>>>>> c) Set "Directed Speed Change"
>>>>>
>>>>> If "Directed Speed Change" is set (DEFAULT_GEN2_SPEED_CHANGE is
>>>>> the default value), it will execute LTSSM to initiate speed
>>>>> change to Gen2 or Gen3, after link is started in Gen1, and then
>>>>> the bit is automatically cleared.
>>>>
>>>> Ok, so with default settings (after reset) we do have Gen1 speed
>>>> link and when we enable LTSSM (with LTSSM_EN bit setting) we
>>>> negotiate to Gen2/Gen3.
>>>
>>> Yes, that's the expected behavior. I submited this direct question
>>> to R&D and will have your doubt answered soon.
>>
>> According to R&D if you set "Target Link Speed" to Gen1 before
>> setting LTSSM_EN bit, the controller should stay in GEN1.
>
> I assume that this is the "recommended" and most robust possible
> approach?
>
> And the patch already submitted to ML is 100% correct (so I don't need
> to clear PCIECTRL_PL_WIDTH_SPEED_CTL) ?
>
Yes, according to R&D the approach available in Bjorn' tree should be ok, since
it sets GEN1 before enabling LTSSM. Of course this is from a standard designware
PCie RC ocre perspective.
Joao
> Our problem has been described here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_arm_sitara-5Farm_f_791_p_567936_2081573-232081573&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=0i9CSBYPpoLydd2AtYg7xapHfGpCvlyir1etY0ZbIwY&s=6f24idB3Pa7aqJEpfsuMpGxkyFUwWwyOFwQtnDztWLA&e=
>
> Best regards,
> Łukasz Majewski
>
>>
>>>
>>>>
>>>>>
>>>>> Lukasz is reseting this bit, in order to avoid the LTSSM to be
>>>>> executed, which is correct.
>>>>
>>>> So with CFG_DIRECTED_SPEED_CHANGE = 0, when I start LTSSM (with
>>>> LTSSM_EN) the state machine returns immediately and leaves link in
>>>> the Gen1?
>>>>
>>>> The pci-dra7 driver always sets LTSSM_EN bit to start link
>>>> negotiation.
>>>>
>>>>> There is another way to prevent this
>>>>> automatic speed change, which is to set GEN1 speed before link up
>>>>> which might be difficult in some setups, so Kishon's also right.
>>>>>
>>>>> In my opinion Lukasz approach would be the one that might be more
>>>>> universal and more "secure".
>>>>
>>>> The robustness is the key here since there are some devices, which
>>>> on particular HW must only work with Gen1 speed. When we start
>>>> LTSSM state machine and hence start negotiation to Gen2, not
>>>> always the result of LTSSM is correct and device is properly
>>>> recognized.
>>>>
>>>>>
>>>>> Joao
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> IMO the better way is to set the LNKCTL2 to GEN1 instead of
>>>>>>>> hacking the IP register.
>>>>>>>
>>>>>>> From the original patch description:
>>>>>>>
>>>>>>> "Add support to force Root Complex to work in GEN1 mode if so
>>>>>>> desired, but don't force GEN1 mode on any board just yet."
>>>>>>>
>>>>>>> Are there any (floating around) patches allowing forcing GEN1
>>>>>>> operation on any board (I would like to reuse/port them to my
>>>>>>> current solution)?
>>>>>>
>>>>>> For setting to GEN1 mode, "max-link-speed" should be set to 1 in
>>>>>> dt with the patch in Bjorn's tree.
>>>>>>
>>>>>> Thanks
>>>>>> Kishon
>>>>>>
>>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Lukasz Majewski
>>>>
>>>> --
>>>>
>>>> DENX Software Engineering GmbH, Managing Director: Wolfgang
>>>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
>>>> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
>>>> wd@denx.de
>>>>
>>>
>>
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
>
^ permalink raw reply
* Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
From: Lukasz Majewski @ 2017-01-17 11:38 UTC (permalink / raw)
To: Joao Pinto
Cc: Kishon Vijay Abraham I, jingoohan1@gmail.com, Bjorn Helgaas,
Rob Herring, Mark Rutland, linux-omap, linux-pci, devicetree,
linux-kernel, Finger, Robert
In-Reply-To: <0bc72557-5110-39bd-89b4-f28307bad71d@synopsys.com>
Hi Joao,
Thank you for your reply.
> Às 10:43 AM de 1/17/2017, Joao Pinto escreveu:
> >
> > Hi Lukasz,
> >
> > Às 9:44 PM de 1/16/2017, Lukasz Majewski escreveu:
> >> Hi Joao,
> >>
> >>>
> >>> Hi,
> >>>
> >>> Às 10:13 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
> >>>> + Joao, Jingoo
> >>>>
> >>>> Hi,
> >>>>
> >>>> On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
> >>>>> Hi Kishon,
> >>>>>
> >>>>>> Hi Łukasz,
> >>>>>>
> >>>>>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
> >>>>>>> Hi Kishon,
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
> >>>>>>>>> Some devices (due to e.g. bad PCIe signal integrity)
> >>>>>>>>> require to run with forced GEN1 speed on PCIe bus.
> >>>>>>>>>
> >>>>>>>>> This patch changes the speed explicitly on dra7 based
> >>>>>>>>> devices when proper device tree attribute is defined for
> >>>>>>>>> the PCIe controller.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
> >>>>>>>>
> >>>>>>>> Bjorn has already queued a patch to do the same thing
> >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_helgaas_pci.git_log_-3Fh-3Dpci_host-2Ddra7xx&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=E8zk1CbKxGH-f3fw_WpXxFU-A8BLkgA8NusCaxk1SvA&e=
> >>>>>>>
> >>>>>>> It seems like Bjorn only modifies CAP registers.
> >>>>>>
> >>>>>> The patch also modifies the LNKCTL2 register.
> >>>>>>>
> >>>>>>> He also needs to change register with 0x080C offset to
> >>>>>>> actually ( PCIECTRL_PL_WIDTH_SPEED_CTL )
> >>>>>>
> >>>>>> This bit is used to initiate speed change (after the link is
> >>>>>> initialized in GEN1). Resetting the bit (like what you have
> >>>>>> done here) prevents speed change.
> >>>>>
> >>>>> This is strange, but e2e advised me to do things as I did in the
> >>>>> patch to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
> >>>>>
> >>>>> Link:
> >>>>> [1]
> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_arm_sitara-5Farm_f_791_t_566421&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=uXLwglyRYqKpwp1JSxkOWmKpQ2wjfhgofpm8DCfquNw&e=
> >>>>>
> >>>>> Both patches modify 0x5180 007C register to set GEN1 capability
> >>>>> (PCI_EXP_LNKCAP_SLS_2_5GB)
> >>>>>
> >>>>> The problem is with second register (in your patch):
> >>>>>
> >>>>> From SPRUHZ6G TRM:
> >>>>>
> >>>>> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
> >>>>> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
> >>>>> description in TRM
> >>>>>
> >>>>> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same
> >>>>> as default /reset value.
> >>>>
> >>>> The default value is 0x2 (or else none of the cards would have
> >>>> enumerated in GEN2)
> >>>>>
> >>>>>
> >>>>> Could you clarify which way to _force_ PCIe GEN1 operation is
> >>>>> correct? Mine shows differences in lspci output (as posted in
> >>>>> [1]).
> >>>>
> >>>> You'll see the difference even with the patch in Bjorn's tree ;-)
> >>>>
> >>>> I think these are 2 different approaches to keep the link at
> >>>> GEN1. Joao or Jingoo, do you have any suggestion here?
> >>>
> >>> I studied the Databook,
> >>
> >> Could you reveal which databook do you have in mind? Is that the
> >> TRM for AM5728?
> >
> > I checked the Designware PCIe Databook, since it is based on this
> > IP.
> >
> >>
> >>> and both approaches seem to be right,
> >>> dependently of the Core configuration and setup.
> >>>
> >>> The standard manual speed change sequence is:
> >>> a) Write to PCIE_CAP_TARGET_LINK_SPEED (indicating desired speed)
> >>
> >> Do you mean TRGT_LINK_SPEED @ 0x5180 00A0 ?
> >
> > Correct.
> >
> >>
> >>> b) Clear "Directed Speed Change"
> >>
> >> CFG_DIRECTED_SPEED_CHANGE @ 0x5180 080C
> >
> > Correct.
> >
> >>
> >>> c) Set "Directed Speed Change"
> >>>
> >>> If "Directed Speed Change" is set (DEFAULT_GEN2_SPEED_CHANGE is
> >>> the default value), it will execute LTSSM to initiate speed
> >>> change to Gen2 or Gen3, after link is started in Gen1, and then
> >>> the bit is automatically cleared.
> >>
> >> Ok, so with default settings (after reset) we do have Gen1 speed
> >> link and when we enable LTSSM (with LTSSM_EN bit setting) we
> >> negotiate to Gen2/Gen3.
> >
> > Yes, that's the expected behavior. I submited this direct question
> > to R&D and will have your doubt answered soon.
>
> According to R&D if you set "Target Link Speed" to Gen1 before
> setting LTSSM_EN bit, the controller should stay in GEN1.
I assume that this is the "recommended" and most robust possible
approach?
And the patch already submitted to ML is 100% correct (so I don't need
to clear PCIECTRL_PL_WIDTH_SPEED_CTL) ?
Our problem has been described here:
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/567936/2081573#2081573
Best regards,
Łukasz Majewski
>
> >
> >>
> >>>
> >>> Lukasz is reseting this bit, in order to avoid the LTSSM to be
> >>> executed, which is correct.
> >>
> >> So with CFG_DIRECTED_SPEED_CHANGE = 0, when I start LTSSM (with
> >> LTSSM_EN) the state machine returns immediately and leaves link in
> >> the Gen1?
> >>
> >> The pci-dra7 driver always sets LTSSM_EN bit to start link
> >> negotiation.
> >>
> >>> There is another way to prevent this
> >>> automatic speed change, which is to set GEN1 speed before link up
> >>> which might be difficult in some setups, so Kishon's also right.
> >>>
> >>> In my opinion Lukasz approach would be the one that might be more
> >>> universal and more "secure".
> >>
> >> The robustness is the key here since there are some devices, which
> >> on particular HW must only work with Gen1 speed. When we start
> >> LTSSM state machine and hence start negotiation to Gen2, not
> >> always the result of LTSSM is correct and device is properly
> >> recognized.
> >>
> >>>
> >>> Joao
> >>>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> IMO the better way is to set the LNKCTL2 to GEN1 instead of
> >>>>>> hacking the IP register.
> >>>>>
> >>>>> From the original patch description:
> >>>>>
> >>>>> "Add support to force Root Complex to work in GEN1 mode if so
> >>>>> desired, but don't force GEN1 mode on any board just yet."
> >>>>>
> >>>>> Are there any (floating around) patches allowing forcing GEN1
> >>>>> operation on any board (I would like to reuse/port them to my
> >>>>> current solution)?
> >>>>
> >>>> For setting to GEN1 mode, "max-link-speed" should be set to 1 in
> >>>> dt with the patch in Bjorn's tree.
> >>>>
> >>>> Thanks
> >>>> Kishon
> >>>>
> >>>
> >>
> >> Best regards,
> >>
> >> Lukasz Majewski
> >>
> >> --
> >>
> >> DENX Software Engineering GmbH, Managing Director: Wolfgang
> >> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> >> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> >> wd@denx.de
> >>
> >
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Krzysztof Kozlowski @ 2017-01-17 11:33 UTC (permalink / raw)
To: Neil Armstrong
Cc: Maxime Ripard, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Heiko Stuebner, Javier Martinez Canillas, Kevin Hilman,
Linus Walleij, Boris Brezillon, Matthias Brugger, Chen-Yu Tsai,
Rob Herring, Alexandre Belloni, Kukjin Kim, Antoine Ténart,
Carlo Caione, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4f5b8608-af6c-3ef5-aaf0-e7e034d006cd-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Tue, Jan 17, 2017 at 12:22 PM, Neil Armstrong
<narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> On 01/17/2017 10:38 AM, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, Jan 16, 2017 at 08:49:06PM +0200, Krzysztof Kozlowski wrote:
>>> On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
>>>> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
>>>> Allwinner, Amlogic, Mediatek or Rockchip.
>>>>
>>>> Add a binding for the GPU of that family.
>>>>
>>>> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
>>>> 1 file changed, 76 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>>>
>>> Do you have a driver in kernel which will implement these bindings?
>>
>> No, but we have bindings for out-of-tree drivers already.
>>
>>> Defining them for out-of-tree driver does not bring any benefits
>>> (3rd party driver will not respect them anyway).
>>
>> You could see it the other way around too. The out-of-tree drivers
>> don't respect it at the moment because there's no binding to respect.
>>
>> And at least for us, we definitely plan on doing that.
>>
>> Maxime
>
> Hi Maxime, Krzysztof,
>
> We hope this will be accepted so it will solve the same issue we have on Amlogic SoCs
> and all the other mali powered SoCs.
It will be helpful also for other SoCs using Mali 400 (e.g.
Exynos3250, Exynos4412).
> Having mainline bindings will forcre out-of-tree driver to respect those bindings
> and remove a dts out-of-tree patch aswell.
I would argue here over the word "force". Having bindings defined here
does not force anyone into anything. The out-of-tree can do whatever
they want. It is a wish from kernel side - it might be respected but
it might not.
Just to be sure - I am not opposed against. Some time ago I wanted
Mali400 to be upstreamed but with current policy about user-space side
it is not possible.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Krzysztof Kozlowski @ 2017-01-17 11:31 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Heiko Stuebner,
Javier Martinez Canillas, Kevin Hilman, Linus Walleij,
Boris Brezillon, Matthias Brugger, Chen-Yu Tsai, Rob Herring,
Alexandre Belloni, Kukjin Kim, Antoine Ténart, Carlo Caione,
Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20170117093813.mxp2hgoxbgske6ru@lukather>
On Tue, Jan 17, 2017 at 11:38 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Mon, Jan 16, 2017 at 08:49:06PM +0200, Krzysztof Kozlowski wrote:
>> On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
>> > The ARM Mali Utgard GPU family is embedded into a number of SoCs from
>> > Allwinner, Amlogic, Mediatek or Rockchip.
>> >
>> > Add a binding for the GPU of that family.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> > ---
>> > .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
>> > 1 file changed, 76 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>>
>> Do you have a driver in kernel which will implement these bindings?
>
> No, but we have bindings for out-of-tree drivers already.
>
>> Defining them for out-of-tree driver does not bring any benefits
>> (3rd party driver will not respect them anyway).
>
> You could see it the other way around too. The out-of-tree drivers
> don't respect it at the moment because there's no binding to respect.
Indeed, that's a point. However valid only when the out-of-tree driver
will respect them, for example do not break them on next release.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] of: base: add support to find the level of the last cache
From: Will Deacon @ 2017-01-17 11:30 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, devicetree, Catalin Marinas, linux-kernel,
Rob Herring, linux-arm-kernel, Tan Xiaojun
In-Reply-To: <1484563244-14743-1-git-send-email-sudeep.holla@arm.com>
On Mon, Jan 16, 2017 at 10:40:43AM +0000, Sudeep Holla wrote:
> It is useful to have helper function just to get the number of cache
> levels for a given logical cpu. We can obtain the same by just checking
> the level at which the last cache is present. This patch adds support
> to find the level of the last cache for a given cpu.
>
> It will be used on ARM64 platform where the device tree provides the
> information for the additional non-architected/transparent/external
> last level caches that are not integrated with the processors.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Suggested-by: Rob Herring <robh+dt@kernel.org>
> Acked-by: Rob Herring <robh+dt@kernel.org>
> Tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/of/base.c | 26 ++++++++++++++++++++++++++
> include/linux/of.h | 1 +
> 2 files changed, 27 insertions(+)
Thanks, I've queued these two for 4.11.
Will
^ permalink raw reply
* Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
From: Joao Pinto @ 2017-01-17 11:23 UTC (permalink / raw)
To: Lukasz Majewski, Joao Pinto
Cc: Kishon Vijay Abraham I, jingoohan1@gmail.com, Bjorn Helgaas,
Rob Herring, Mark Rutland, linux-omap, linux-pci, devicetree,
linux-kernel
In-Reply-To: <4b18d08a-c2cc-3c32-35ed-8f4a759ef235@synopsys.com>
Às 10:43 AM de 1/17/2017, Joao Pinto escreveu:
>
> Hi Lukasz,
>
> Às 9:44 PM de 1/16/2017, Lukasz Majewski escreveu:
>> Hi Joao,
>>
>>>
>>> Hi,
>>>
>>> Às 10:13 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>>>> + Joao, Jingoo
>>>>
>>>> Hi,
>>>>
>>>> On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
>>>>> Hi Kishon,
>>>>>
>>>>>> Hi Łukasz,
>>>>>>
>>>>>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
>>>>>>> Hi Kishon,
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>>>>>>>> Some devices (due to e.g. bad PCIe signal integrity) require to
>>>>>>>>> run with forced GEN1 speed on PCIe bus.
>>>>>>>>>
>>>>>>>>> This patch changes the speed explicitly on dra7 based devices
>>>>>>>>> when proper device tree attribute is defined for the PCIe
>>>>>>>>> controller.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>>>>>>>
>>>>>>>> Bjorn has already queued a patch to do the same thing
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_helgaas_pci.git_log_-3Fh-3Dpci_host-2Ddra7xx&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=E8zk1CbKxGH-f3fw_WpXxFU-A8BLkgA8NusCaxk1SvA&e=
>>>>>>>
>>>>>>> It seems like Bjorn only modifies CAP registers.
>>>>>>
>>>>>> The patch also modifies the LNKCTL2 register.
>>>>>>>
>>>>>>> He also needs to change register with 0x080C offset to actually
>>>>>>> ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>>>>>>
>>>>>> This bit is used to initiate speed change (after the link is
>>>>>> initialized in GEN1). Resetting the bit (like what you have done
>>>>>> here) prevents speed change.
>>>>>
>>>>> This is strange, but e2e advised me to do things as I did in the
>>>>> patch to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
>>>>>
>>>>> Link:
>>>>> [1]
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_arm_sitara-5Farm_f_791_t_566421&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=uXLwglyRYqKpwp1JSxkOWmKpQ2wjfhgofpm8DCfquNw&e=
>>>>>
>>>>> Both patches modify 0x5180 007C register to set GEN1 capability
>>>>> (PCI_EXP_LNKCAP_SLS_2_5GB)
>>>>>
>>>>> The problem is with second register (in your patch):
>>>>>
>>>>> From SPRUHZ6G TRM:
>>>>>
>>>>> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
>>>>> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
>>>>> description in TRM
>>>>>
>>>>> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as
>>>>> default /reset value.
>>>>
>>>> The default value is 0x2 (or else none of the cards would have
>>>> enumerated in GEN2)
>>>>>
>>>>>
>>>>> Could you clarify which way to _force_ PCIe GEN1 operation is
>>>>> correct? Mine shows differences in lspci output (as posted in [1]).
>>>>
>>>> You'll see the difference even with the patch in Bjorn's tree ;-)
>>>>
>>>> I think these are 2 different approaches to keep the link at GEN1.
>>>> Joao or Jingoo, do you have any suggestion here?
>>>
>>> I studied the Databook,
>>
>> Could you reveal which databook do you have in mind? Is that the TRM for
>> AM5728?
>
> I checked the Designware PCIe Databook, since it is based on this IP.
>
>>
>>> and both approaches seem to be right,
>>> dependently of the Core configuration and setup.
>>>
>>> The standard manual speed change sequence is:
>>> a) Write to PCIE_CAP_TARGET_LINK_SPEED (indicating desired speed)
>>
>> Do you mean TRGT_LINK_SPEED @ 0x5180 00A0 ?
>
> Correct.
>
>>
>>> b) Clear "Directed Speed Change"
>>
>> CFG_DIRECTED_SPEED_CHANGE @ 0x5180 080C
>
> Correct.
>
>>
>>> c) Set "Directed Speed Change"
>>>
>>> If "Directed Speed Change" is set (DEFAULT_GEN2_SPEED_CHANGE is the
>>> default value), it will execute LTSSM to initiate speed change to
>>> Gen2 or Gen3, after link is started in Gen1, and then the bit is
>>> automatically cleared.
>>
>> Ok, so with default settings (after reset) we do have Gen1 speed link
>> and when we enable LTSSM (with LTSSM_EN bit setting) we negotiate to
>> Gen2/Gen3.
>
> Yes, that's the expected behavior. I submited this direct question to R&D and
> will have your doubt answered soon.
According to R&D if you set "Target Link Speed" to Gen1 before setting LTSSM_EN
bit, the controller should stay in GEN1.
>
>>
>>>
>>> Lukasz is reseting this bit, in order to avoid the LTSSM to be
>>> executed, which is correct.
>>
>> So with CFG_DIRECTED_SPEED_CHANGE = 0, when I start LTSSM (with
>> LTSSM_EN) the state machine returns immediately and leaves link in the
>> Gen1?
>>
>> The pci-dra7 driver always sets LTSSM_EN bit to start link negotiation.
>>
>>> There is another way to prevent this
>>> automatic speed change, which is to set GEN1 speed before link up
>>> which might be difficult in some setups, so Kishon's also right.
>>>
>>> In my opinion Lukasz approach would be the one that might be more
>>> universal and more "secure".
>>
>> The robustness is the key here since there are some devices, which on
>> particular HW must only work with Gen1 speed. When we start LTSSM state
>> machine and hence start negotiation to Gen2, not always the result of
>> LTSSM is correct and device is properly recognized.
>>
>>>
>>> Joao
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> IMO the better way is to set the LNKCTL2 to GEN1 instead of
>>>>>> hacking the IP register.
>>>>>
>>>>> From the original patch description:
>>>>>
>>>>> "Add support to force Root Complex to work in GEN1 mode if so
>>>>> desired, but don't force GEN1 mode on any board just yet."
>>>>>
>>>>> Are there any (floating around) patches allowing forcing GEN1
>>>>> operation on any board (I would like to reuse/port them to my
>>>>> current solution)?
>>>>
>>>> For setting to GEN1 mode, "max-link-speed" should be set to 1 in dt
>>>> with the patch in Bjorn's tree.
>>>>
>>>> Thanks
>>>> Kishon
>>>>
>>>
>>
>> Best regards,
>>
>> Lukasz Majewski
>>
>> --
>>
>> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
>>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox