* [PATCH v4 0/3] PCI: qcom: Add support to msm8996 pcie controller.
From: Srinivas Kandagatla @ 2016-11-14 11:15 UTC (permalink / raw)
To: svarbanov, linux-pci, bhelgaas
Cc: robh+dt, linux-arm-msm, srinivas.kandagatla, devicetree
This patchset adds support to msm8996 pcie controller. I tested this patch on
v4.9-rc2 along with phy driver patch [1] and
"PCI: designware: check for iATU unroll support after initializing host"
fix [2] on DB820c APQ8096 board on port B and port C using sata and
ethernet controller.
Changes since v3:
- remove unnesessary variable initialization spotted by vivek.
- moved pipe clk disable before other clocks suggested by vivek.
- fixed dt example suggested by Rob.
Changes since v2:
- Removed regulators that belong to phy, spotted by Stephen
- Removed clocks in to simple pm bus driver, spotted by Stephen
- renamed msm8996 ops to v2 ops as suggested by Stephen.
- cleanups as suggested by Stephen.
- Add runtime pm support to driver.
- Added pm clk support to simple pm bus driver.
Changes since v1:
- Fixed dt example as suggested by Rob
- added smmu bus clk dependency as smmu sits in between
system NOC and PCIe.
- Removed smmu configuration from bindings and driver as
the smmu Level2 translation on this SOC is controlled by
the secure world, and level 1 translation is disabled,
so there is one-to-one mapping of the address space.
Thanks,
srini
[1] https://patchwork.kernel.org/patch/9384711/
[2] https://patchwork.kernel.org/patch/9377557/
Srinivas Kandagatla (3):
bus: simple-pm: add support to pm clocks
PCI: qcom: add support to msm8996 PCIE controller
PCI: qcom: add runtime pm support to pcie_port
.../devicetree/bindings/pci/qcom,pcie.txt | 67 +++++++-
drivers/bus/simple-pm-bus.c | 13 +-
drivers/pci/host/pcie-qcom.c | 181 ++++++++++++++++++++-
3 files changed, 254 insertions(+), 7 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH v4 1/3] bus: simple-pm: add support to pm clocks
From: Srinivas Kandagatla @ 2016-11-14 11:15 UTC (permalink / raw)
To: svarbanov, linux-pci, bhelgaas
Cc: robh+dt, linux-arm-msm, srinivas.kandagatla, devicetree
In-Reply-To: <1479122155-13393-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds support to pm clocks via device tree, so that the clocks
can be turned on and off during runtime pm. This patch is required for
Qualcomm msm8996 pcie controller which sits on a bus with its own
power-domain and clocks.
Without this patch the clock associated with the bus are never turned on.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/bus/simple-pm-bus.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
index c5eb46c..63b7e8c 100644
--- a/drivers/bus/simple-pm-bus.c
+++ b/drivers/bus/simple-pm-bus.c
@@ -11,6 +11,7 @@
#include <linux/module.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/pm_clock.h>
#include <linux/pm_runtime.h>
@@ -22,17 +23,26 @@ static int simple_pm_bus_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
- if (np)
+ if (np) {
+ of_pm_clk_add_clks(&pdev->dev);
of_platform_populate(np, NULL, NULL, &pdev->dev);
+ }
return 0;
}
+static const struct dev_pm_ops simple_pm_bus_pm_ops = {
+ SET_RUNTIME_PM_OPS(pm_clk_suspend,
+ pm_clk_resume, NULL)
+};
+
static int simple_pm_bus_remove(struct platform_device *pdev)
{
dev_dbg(&pdev->dev, "%s\n", __func__);
pm_runtime_disable(&pdev->dev);
+ pm_clk_destroy(&pdev->dev);
+
return 0;
}
@@ -48,6 +58,7 @@ static struct platform_driver simple_pm_bus_driver = {
.driver = {
.name = "simple-pm-bus",
.of_match_table = simple_pm_bus_of_match,
+ .pm = &simple_pm_bus_pm_ops,
},
};
--
2.10.1
^ permalink raw reply related
* [PATCH v4 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Srinivas Kandagatla @ 2016-11-14 11:15 UTC (permalink / raw)
To: svarbanov, linux-pci, bhelgaas
Cc: robh+dt, linux-arm-msm, srinivas.kandagatla, devicetree
In-Reply-To: <1479122155-13393-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
legacy interrupts and it conforms to PCI Express Base 2.1 specification.
This patch adds post_init callback to qcom_pcie_ops, as this is pcie
pipe clocks are only setup after the phy is powered on.
It also adds ltssm_enable callback as it is very much different to other
supported SOCs in the driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
.../devicetree/bindings/pci/qcom,pcie.txt | 67 +++++++-
drivers/pci/host/pcie-qcom.c | 177 ++++++++++++++++++++-
2 files changed, 238 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
index 4059a6f..141d8c3 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -7,6 +7,7 @@
- "qcom,pcie-ipq8064" for ipq8064
- "qcom,pcie-apq8064" for apq8064
- "qcom,pcie-apq8084" for apq8084
+ - "qcom,pcie-msm8996" for msm8996 or apq8096
- reg:
Usage: required
@@ -92,6 +93,17 @@
- "aux" Auxiliary (AUX) clock
- "bus_master" Master AXI clock
- "bus_slave" Slave AXI clock
+
+- clock-names:
+ Usage: required for msm8996/apq8096
+ Value type: <stringlist>
+ Definition: Should contain the following entries
+ - "pipe" Pipe Clock driving internal logic.
+ - "aux" Auxiliary (AUX) clock.
+ - "cfg" Configuration clk.
+ - "bus_master" Master AXI clock.
+ - "bus_slave" Slave AXI clock.
+
- resets:
Usage: required
Value type: <prop-encoded-array>
@@ -115,7 +127,7 @@
- "core" Core reset
- power-domains:
- Usage: required for apq8084
+ Usage: required for apq8084 and msm8996/apq8096
Value type: <prop-encoded-array>
Definition: A phandle and power domain specifier pair to the
power domain which is responsible for collapsing
@@ -231,3 +243,56 @@
pinctrl-0 = <&pcie0_pins_default>;
pinctrl-names = "default";
};
+
+* Example for apq8096:
+
+ pcie@608000{
+ compatible = "qcom,pcie-msm8996", "snps,dw-pcie";
+ power-domains = <&gcc PCIE1_GDSC>;
+ bus-range = <0x00 0xff>;
+ num-lanes = <1>;
+
+ reg = <0x00608000 0x2000>,
+ <0x0d000000 0xf1d>,
+ <0x0d000f20 0xa8>,
+ <0x0d100000 0x100000>;
+
+ reg-names = "parf", "dbi", "elbi", "config";
+
+ phys = <&pcie_phy 1>;
+ phy-names = "pciephy";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x0d200000 0x0d200000 0x0 0x100000>,
+ <0x02000000 0x0 0x0d300000 0x0d300000 0x0 0xd00000>;
+
+ interrupts = <GIC_SPI 413 IRQ_TYPE_NONE>;
+ interrupt-names = "msi";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 272 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 273 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 274 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 275 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pcie1_clkreq_default &pcie1_perst_default &pcie1_wake_default>;
+ pinctrl-1 = <&pcie1_clkreq_sleep &pcie1_perst_default &pcie1_wake_sleep>;
+
+ vdda-1p8-supply = <&pm8994_l12>;
+ vdda-supply = <&pm8994_l28>;
+ linux,pci-domain = <1>;
+
+ clocks = <&gcc GCC_PCIE_1_PIPE_CLK>,
+ <&gcc GCC_PCIE_1_AUX_CLK>,
+ <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_AXI_CLK>;
+
+ clock-names = "pipe",
+ "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave";
+ };
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
index 3593640..03ba6b1 100644
--- a/drivers/pci/host/pcie-qcom.c
+++ b/drivers/pci/host/pcie-qcom.c
@@ -36,11 +36,19 @@
#include "pcie-designware.h"
+#define PCIE20_PARF_DBI_BASE_ADDR 0x168
+
+#define PCIE20_PARF_SYS_CTRL 0x00
#define PCIE20_PARF_PHY_CTRL 0x40
#define PCIE20_PARF_PHY_REFCLK 0x4C
#define PCIE20_PARF_DBI_BASE_ADDR 0x168
#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE 0x16c
+#define PCIE20_PARF_MHI_CLOCK_RESET_CTRL 0x174
#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x178
+#define MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x1A8
+#define PCIE20_PARF_LTSSM 0x1B0
+#define PCIE20_PARF_SID_OFFSET 0x234
+#define PCIE20_PARF_BDF_TRANSLATE_CFG 0x24C
#define PCIE20_ELBI_SYS_CTRL 0x04
#define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
@@ -72,9 +80,18 @@ struct qcom_pcie_resources_v1 {
struct regulator *vdda;
};
+struct qcom_pcie_resources_v2 {
+ struct clk *aux_clk;
+ struct clk *master_clk;
+ struct clk *slave_clk;
+ struct clk *cfg_clk;
+ struct clk *pipe_clk;
+};
+
union qcom_pcie_resources {
struct qcom_pcie_resources_v0 v0;
struct qcom_pcie_resources_v1 v1;
+ struct qcom_pcie_resources_v2 v2;
};
struct qcom_pcie;
@@ -82,7 +99,9 @@ struct qcom_pcie;
struct qcom_pcie_ops {
int (*get_resources)(struct qcom_pcie *pcie);
int (*init)(struct qcom_pcie *pcie);
+ int (*post_init)(struct qcom_pcie *pcie);
void (*deinit)(struct qcom_pcie *pcie);
+ void (*ltssm_enable)(struct qcom_pcie *pcie);
};
struct qcom_pcie {
@@ -116,17 +135,33 @@ static irqreturn_t qcom_pcie_msi_irq_handler(int irq, void *arg)
return dw_handle_msi_irq(pp);
}
-static int qcom_pcie_establish_link(struct qcom_pcie *pcie)
+static void qcom_pcie_v0_v1_ltssm_enable(struct qcom_pcie *pcie)
{
u32 val;
-
- if (dw_pcie_link_up(&pcie->pp))
- return 0;
-
/* enable link training */
val = readl(pcie->elbi + PCIE20_ELBI_SYS_CTRL);
val |= PCIE20_ELBI_SYS_CTRL_LT_ENABLE;
writel(val, pcie->elbi + PCIE20_ELBI_SYS_CTRL);
+}
+
+static void qcom_pcie_v2_ltssm_enable(struct qcom_pcie *pcie)
+{
+ u32 val;
+ /* enable link training */
+ val = readl(pcie->parf + PCIE20_PARF_LTSSM);
+ val |= BIT(8);
+ writel(val, pcie->parf + PCIE20_PARF_LTSSM);
+}
+
+static int qcom_pcie_establish_link(struct qcom_pcie *pcie)
+{
+
+ if (dw_pcie_link_up(&pcie->pp))
+ return 0;
+
+ /* Enable Link Training state machine */
+ if (pcie->ops->ltssm_enable)
+ pcie->ops->ltssm_enable(pcie);
return dw_pcie_wait_for_link(&pcie->pp);
}
@@ -421,6 +456,113 @@ static int qcom_pcie_init_v1(struct qcom_pcie *pcie)
return ret;
}
+static int qcom_pcie_get_resources_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+
+ res->aux_clk = devm_clk_get(dev, "aux");
+ if (IS_ERR(res->aux_clk))
+ return PTR_ERR(res->aux_clk);
+
+ res->cfg_clk = devm_clk_get(dev, "cfg");
+ if (IS_ERR(res->cfg_clk))
+ return PTR_ERR(res->cfg_clk);
+
+ res->master_clk = devm_clk_get(dev, "bus_master");
+ if (IS_ERR(res->master_clk))
+ return PTR_ERR(res->master_clk);
+
+ res->slave_clk = devm_clk_get(dev, "bus_slave");
+ if (IS_ERR(res->slave_clk))
+ return PTR_ERR(res->slave_clk);
+
+ res->pipe_clk = devm_clk_get(dev, "pipe");
+ if (IS_ERR(res->pipe_clk))
+ return PTR_ERR(res->pipe_clk);
+
+ return 0;
+}
+
+static int qcom_pcie_init_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(res->aux_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable aux clock\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(res->cfg_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable cfg clock\n");
+ goto err_cfg_clk;
+ }
+
+ ret = clk_prepare_enable(res->master_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable master clock\n");
+ goto err_master_clk;
+ }
+
+ ret = clk_prepare_enable(res->slave_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable slave clock\n");
+ goto err_slave_clk;
+ }
+
+ /* enable PCIe clocks and resets */
+ val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
+ val &= ~BIT(0);
+ writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
+
+ /* change DBI base address */
+ writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
+
+ /* MAC PHY_POWERDOWN MUX DISABLE */
+ val = readl(pcie->parf + PCIE20_PARF_SYS_CTRL);
+ val &= ~BIT(29);
+ writel(val, pcie->parf + PCIE20_PARF_SYS_CTRL);
+
+ val = readl(pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
+ val |= BIT(4);
+ writel(val, pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
+
+ val = readl(pcie->parf + MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT);
+ val |= BIT(31);
+ writel(val, pcie->parf + MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT);
+
+ return 0;
+
+err_slave_clk:
+ clk_disable_unprepare(res->master_clk);
+err_master_clk:
+ clk_disable_unprepare(res->cfg_clk);
+err_cfg_clk:
+ clk_disable_unprepare(res->aux_clk);
+
+ return ret;
+}
+
+static int qcom_pcie_post_init_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+ int ret;
+
+ ret = clk_prepare_enable(res->pipe_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable pipe clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
static int qcom_pcie_link_up(struct pcie_port *pp)
{
struct qcom_pcie *pcie = to_qcom_pcie(pp);
@@ -429,6 +571,17 @@ static int qcom_pcie_link_up(struct pcie_port *pp)
return !!(val & PCI_EXP_LNKSTA_DLLLA);
}
+static void qcom_pcie_deinit_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+
+ clk_disable_unprepare(res->pipe_clk);
+ clk_disable_unprepare(res->slave_clk);
+ clk_disable_unprepare(res->master_clk);
+ clk_disable_unprepare(res->cfg_clk);
+ clk_disable_unprepare(res->aux_clk);
+}
+
static void qcom_pcie_host_init(struct pcie_port *pp)
{
struct qcom_pcie *pcie = to_qcom_pcie(pp);
@@ -444,6 +597,9 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
if (ret)
goto err_deinit;
+ if (pcie->ops->post_init)
+ pcie->ops->post_init(pcie);
+
dw_pcie_setup_rc(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
@@ -487,12 +643,22 @@ static const struct qcom_pcie_ops ops_v0 = {
.get_resources = qcom_pcie_get_resources_v0,
.init = qcom_pcie_init_v0,
.deinit = qcom_pcie_deinit_v0,
+ .ltssm_enable = qcom_pcie_v0_v1_ltssm_enable,
};
static const struct qcom_pcie_ops ops_v1 = {
.get_resources = qcom_pcie_get_resources_v1,
.init = qcom_pcie_init_v1,
.deinit = qcom_pcie_deinit_v1,
+ .ltssm_enable = qcom_pcie_v0_v1_ltssm_enable,
+};
+
+static const struct qcom_pcie_ops ops_v2 = {
+ .get_resources = qcom_pcie_get_resources_v2,
+ .init = qcom_pcie_init_v2,
+ .post_init = qcom_pcie_post_init_v2,
+ .deinit = qcom_pcie_deinit_v2,
+ .ltssm_enable = qcom_pcie_v2_ltssm_enable,
};
static int qcom_pcie_probe(struct platform_device *pdev)
@@ -572,6 +738,7 @@ static const struct of_device_id qcom_pcie_match[] = {
{ .compatible = "qcom,pcie-ipq8064", .data = &ops_v0 },
{ .compatible = "qcom,pcie-apq8064", .data = &ops_v0 },
{ .compatible = "qcom,pcie-apq8084", .data = &ops_v1 },
+ { .compatible = "qcom,pcie-msm8996", .data = &ops_v2 },
{ }
};
--
2.10.1
^ permalink raw reply related
* [PATCH v4 3/3] PCI: qcom: add runtime pm support to pcie_port
From: Srinivas Kandagatla @ 2016-11-14 11:15 UTC (permalink / raw)
To: svarbanov-NEYub+7Iv8PQT0dZR+AlfA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479122155-13393-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch is required when the pcie controller sits on a bus with
its own power domain and clocks which are controlled via a bus driver
like simple pm bus. As these bus driver have runtime pm enabled, it makes
sense to update the usage counter so that the runtime pm does not suspend
the clks or power domain associated with the bus driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/pci/host/pcie-qcom.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
index 03ba6b1..c2ca848 100644
--- a/drivers/pci/host/pcie-qcom.c
+++ b/drivers/pci/host/pcie-qcom.c
@@ -587,6 +587,8 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
struct qcom_pcie *pcie = to_qcom_pcie(pp);
int ret;
+ pm_runtime_get_sync(pp->dev);
+
qcom_ep_reset_assert(pcie);
ret = pcie->ops->init(pcie);
@@ -617,6 +619,7 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
phy_power_off(pcie->phy);
err_deinit:
pcie->ops->deinit(pcie);
+ pm_runtime_put_sync(pp->dev);
}
static int qcom_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
@@ -673,6 +676,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
if (!pcie)
return -ENOMEM;
+ pm_runtime_enable(dev);
pp = &pcie->pp;
pcie->ops = (struct qcom_pcie_ops *)of_device_get_match_data(dev);
--
2.10.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
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Tomi Valkeinen @ 2016-11-14 11:16 UTC (permalink / raw)
To: Laurent Pinchart, Jyri Sarha
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski
In-Reply-To: <1740464.TP0bE1PYbC@avalon>
[-- Attachment #1.1.1: Type: text/plain, Size: 1481 bytes --]
On 14/11/16 13:10, Laurent Pinchart wrote:
> Hi Jyri,
>
> On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
>> On 11/03/16 19:46, Laurent Pinchart wrote:
>>>> +Required properties:
>>>>> + - compatible: "ti,tfp410"
>>>
>>> The device is an I2C slave, it should have a reg property. Given that the
>>> chip can be used without being controlled through I2C, the reg property
>>> should be optional. You should document this clearly, and explain how the
>>> DT node can be instantiated as a child of an I2C controller when the I2C
>>> interface is used, or in other parts of the device tree otherwise.
>>
>> Shouldn't I have two different compatible strings if want to make both
>> platform driver probe and i2c client probe to work?
>
> I don't think so, it's still the same chip.
>
>> Or can it be done with single compatible string? Would you know of an
>> example of such a driver?
>
> You will need to register both a i2c_driver and a platform_driver in the
> tfp410 driver. Both will advertise the same compatible string. As you'll have
> two probe functions, it should be easy to handle the differences between the
If you have the same compatible string, won't both probes trigger? If
so, how does, e.g., the platform driver know this is actually i2c case,
and bail out? And if both probes don't trigger, why not? How does the
device probing machinery know that this DT node is actually an i2c node,
not a platform device node?
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-11-14 11:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev@lists.ozlabs.org, Geert Uytterhoeven,
Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org, Dirk Behme,
linux-kernel@vger.kernel.org, Linux-Renesas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdWavRFnYFmiL2jy3KWZnHG_F8qaxK29zHx6fsLmqXEwiA@mail.gmail.com>
On Monday, November 14, 2016 11:51:15 AM CET Geert Uytterhoeven wrote:
> On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> >> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> >> available, else fall back to hardcoded addresses for compatibility
> >> >> with existing DTBs,
>
> >> > It does seem wrong to have a device node for a specific register though.
> >> > Shouldn't the node be for the block of registers that these are inside
> >> > of?
> >>
> >> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> >> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
> >
> > It just seems odd to have it at address 0xff000044 when all the other
> > devices are at page-aligned addresses. Do you mean that accessing
> > 0xff000040 or 0xff000048 will result in a bus-level exception for a
> > missing register and just 0xff000044 is actually valid for access,
> > or is it just the only thing that is documented?
>
> For PRR, all other registers in the page read as all zeroes on all SoCs that
> have it. So it really is a lone register.
Ok.
> >> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> >> we further don't touch at all.
> >> On R-Car Gen2, it's not documented, but does exist.
> >
> > This is where the family names would come in handy ;-) I now have
> > no idea which chip(s) you are referring to.
>
> SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
> R-Car Gen2 are r8a779[0-4].
>
> > If you know the name of the register block, just put it into DT with
> > that name. The driver can trivially add the right offset.
>
> CCCR is different. The amount of registers that read as non-zero depends a lot
> on the actual SoC.
>
> HPB/APB is gonna need real DT bindings, which needs some more investigation.
> Hence if you don't mind, I'd like to postpone that part, which only affects
> the older SoCs. And I'll drop the "renesas,cccr" binding.
>
> For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
> most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
> waiting for this support. So I'd like to have that dependency in v4.10.
Ok, sounds good.
> >> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> >> Hence I always need to look at the root nodes.
> >
> > Not sure what that would protect you from. Could you have a renesas,cccr
>
> Looks like you forgot to finish your sentence?
Yes, and I forgot what I was going to say there now. It's probably covered
by what we discussed above.
Arnd
^ permalink raw reply
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Laurent Pinchart @ 2016-11-14 11:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
daniel-/w4YWyX8dFk, robdclark-Re5JQEeQqe8AvxtiuMwx3w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
khilman-rdvid1DuHRBWk0Htik3J/w, bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <ac8e0f72-fac2-45e5-0004-d6028ddeb221-l0cyMroinI0@public.gmane.org>
Hi Tomi,
On Monday 14 Nov 2016 13:16:49 Tomi Valkeinen wrote:
> On 14/11/16 13:10, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
> >> On 11/03/16 19:46, Laurent Pinchart wrote:
> >>>> +Required properties:
> >>>>> + - compatible: "ti,tfp410"
> >>>
> >>> The device is an I2C slave, it should have a reg property. Given that
> >>> the chip can be used without being controlled through I2C, the reg
> >>> property should be optional. You should document this clearly, and
> >>> explain how the DT node can be instantiated as a child of an I2C
> >>> controller when the I2C interface is used, or in other parts of the
> >>> device tree otherwise.
> >>
> >> Shouldn't I have two different compatible strings if want to make both
> >> platform driver probe and i2c client probe to work?
> >
> > I don't think so, it's still the same chip.
> >
> >> Or can it be done with single compatible string? Would you know of an
> >> example of such a driver?
> >
> > You will need to register both a i2c_driver and a platform_driver in the
> > tfp410 driver. Both will advertise the same compatible string. As you'll
> > have two probe functions, it should be easy to handle the differences
> > between the
>
> If you have the same compatible string, won't both probes trigger? If
> so, how does, e.g., the platform driver know this is actually i2c case,
> and bail out? And if both probes don't trigger, why not? How does the
> device probing machinery know that this DT node is actually an i2c node,
> not a platform device node?
The driver for the bus on which the device is sitting is responsible for
instantiating a struct device corresponding to the bus type, and for binding
the corresponding bus drivers. This will be a struct i2c_client for I2C buses,
and a struct platform_device for platform buses. Only the corresponding driver
type will be probed.
--
Regards,
Laurent Pinchart
--
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 v5 3/3] clocksource: Add clockevent support to NPS400 driver
From: Daniel Lezcano @ 2016-11-14 11:23 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479021872-14237-4-git-send-email-noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Sun, Nov 13, 2016 at 09:24:32AM +0200, Noam Camus wrote:
> From: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Till now we used clockevent from generic ARC driver.
> This was enough as long as we worked with simple multicore SoC.
> When we are working with multithread SoC each HW thread can be
> scheduled to receive timer interrupt using timer mask register.
> This patch will provide a way to control clock events per HW thread.
>
> The design idea is that for each core there is dedicated regirtser
s/regirtser/register/ (already spotted in v2).
> (TSI) serving all 16 HW threads.
> The register is a bitmask with one bit for each HW thread.
> When HW thread wants that next expiration of timer interrupt will
> hit it then the proper bit should be set in this dedicated register.
> When timer expires all HW threads within this core which their bit
> is set at the TSI register will be interrupted.
>
> Driver can be used from device tree by:
> compatible = "ezchip,nps400-timer0" <-- for clocksource
> compatible = "ezchip,nps400-timer1" <-- for clockevent
>
> Note that name convention for timer0/timer1 was taken from legacy
> ARC design. This design is our base before adding HW threads.
> For backward compatibility we keep "ezchip,nps400-timer" for clocksource
>
> Signed-off-by: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> .../bindings/timer/ezchip,nps400-timer.txt | 15 --
> .../bindings/timer/ezchip,nps400-timer0.txt | 17 ++
> .../bindings/timer/ezchip,nps400-timer1.txt | 15 ++
> drivers/clocksource/timer-nps.c | 213 ++++++++++++++++++++
> 4 files changed, 245 insertions(+), 15 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> deleted file mode 100644
> index c8c03d7..0000000
> --- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -NPS Network Processor
> -
> -Required properties:
> -
> -- compatible : should be "ezchip,nps400-timer"
> -
> -Clocks required for compatible = "ezchip,nps400-timer":
> -- clocks : Must contain a single entry describing the clock input
> -
> -Example:
> -
> -timer {
> - compatible = "ezchip,nps400-timer";
> - clocks = <&sysclk>;
> -};
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> new file mode 100644
> index 0000000..e3cfce8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> @@ -0,0 +1,17 @@
> +NPS Network Processor
> +
> +Required properties:
> +
> +- compatible : should be "ezchip,nps400-timer0"
> +
> +Clocks required for compatible = "ezchip,nps400-timer0":
> +- interrupts : The interrupt of the first timer
> +- clocks : Must contain a single entry describing the clock input
> +
> +Example:
> +
> +timer {
> + compatible = "ezchip,nps400-timer0";
> + interrupts = <3>;
> + clocks = <&sysclk>;
> +};
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> new file mode 100644
> index 0000000..c0ab419
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> @@ -0,0 +1,15 @@
> +NPS Network Processor
> +
> +Required properties:
> +
> +- compatible : should be "ezchip,nps400-timer1"
> +
> +Clocks required for compatible = "ezchip,nps400-timer1":
> +- clocks : Must contain a single entry describing the clock input
> +
> +Example:
> +
> +timer {
> + compatible = "ezchip,nps400-timer1";
> + clocks = <&sysclk>;
> +};
> diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
> index eeef9e9..ed4bce4 100644
> --- a/drivers/clocksource/timer-nps.c
> +++ b/drivers/clocksource/timer-nps.c
> @@ -109,3 +109,216 @@ static int __init nps_setup_clocksource(struct device_node *node)
>
> CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
> nps_setup_clocksource);
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
> + nps_setup_clocksource);
> +
> +#ifdef CONFIG_EZNPS_MTM_EXT
> +#include <soc/nps/mtm.h>
> +
> +/* Timer related Aux registers */
> +#define NPS_REG_TIMER0_TSI 0xFFFFF850
> +#define NPS_REG_TIMER0_LIMIT 0x23
> +#define NPS_REG_TIMER0_CTRL 0x22
> +#define NPS_REG_TIMER0_CNT 0x21
> +
> +/*
> + * Interrupt Enabled (IE) - re-arm the timer
> + * Not Halted (NH) - is cleared when working with JTAG (for debug)
> + */
> +#define TIMER0_CTRL_IE BIT(0)
> +#define TIMER0_CTRL_NH BIT(1)
> +
> +static unsigned long nps_timer0_freq;
> +static unsigned long nps_timer0_irq;
> +
> +/*
> + * Arm the timer to interrupt after @cycles
> + */
> +static void nps_clkevent_timer_event_setup(unsigned int cycles)
> +{
> + write_aux_reg(NPS_REG_TIMER0_LIMIT, cycles);
> + write_aux_reg(NPS_REG_TIMER0_CNT, 0);
> +
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +}
> +
> +/*
> + * Clear from TSI the bit for this thread (if not in periodic mode)
> + * If still there are pending HW treads set next timer event
s/treads/threads/
> + */
> +static void nps_clkevent_rm_thread(bool remove_thread)
> +{
> + unsigned int cflags;
> + unsigned int enabled_threads = 0;
> + int thread;
> +
> + hw_schd_save(&cflags);
I'm not used with hardware scheduling. Can you explain why this is needed
here ? What window race we want to close ?
> +
> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> +
> + /* remove thread from TSI1 */
> + if (remove_thread) {
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads &= ~(1 << thread);
> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> + }
> +
> + /* Re-arm the timer if needed */
> + if (!enabled_threads)
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_NH);
> + else
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> +}
> +
> +static void nps_clkevent_add_thread(bool set_event)
> +{
> + int thread;
> + unsigned int cflags, enabled_threads;
> +
> + hw_schd_save(&cflags);
> +
> + /* add thread to TSI1 */
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> + enabled_threads |= (1 << thread);
> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> +
> + /* set next timer event */
> + if (set_event)
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> +}
Not sure the boolean parameters for *_rm_thread and *_add_thread helps
to clarify the code. Depending on the race window with hw_schd_save/restore
We should be able to simplify it.
> +static int nps_clkevent_set_next_event(unsigned long delta,
> + struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(true);
> + enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
> +
> + return 0;
> +}
> +
> +/*
> + * Whenever anyone tries to change modes, we just mask interrupts
> + * and wait for the next event to get set.
> + */
> +static int nps_clkevent_timer_shutdown(struct clock_event_device *dev)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> +
> + return 0;
> +}
> +
> +/*
> + * For each HW thread set its relevant bit at the TSI register
> + * To arm the timer only thread 0 is needed since it is shared
> + * by all HW threads within same core.
> + */
> +static int nps_clkevent_set_periodic(struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(false);
> + if (read_aux_reg(CTOP_AUX_THREAD_ID) == 0)
> + nps_clkevent_timer_event_setup(nps_timer0_freq / HZ);
> +
> + return 0;
> +}
> +
> +static int nps_clkevent_set_oneshot(struct clock_event_device *dev)
> +{
> + nps_clkevent_rm_thread(true);
> + nps_clkevent_timer_shutdown(dev);
> +
> + return 0;
> +}
> +
> +static DEFINE_PER_CPU(struct clock_event_device, nps_clockevent_device) = {
> + .name = "NPS Timer0",
> + .features = CLOCK_EVT_FEAT_ONESHOT |
> + CLOCK_EVT_FEAT_PERIODIC,
> + .rating = 300,
> + .set_next_event = nps_clkevent_set_next_event,
> + .set_state_periodic = nps_clkevent_set_periodic,
> + .set_state_oneshot = nps_clkevent_set_oneshot,
> + .set_state_oneshot_stopped = nps_clkevent_timer_shutdown,
> + .set_state_shutdown = nps_clkevent_timer_shutdown,
Doesn't set_state_shutdown and set_state_oneshot_stopped need to remove
the HW thread from the TSI ?
> + .tick_resume = nps_clkevent_timer_shutdown,
> +};
> +
> +static irqreturn_t timer_irq_handler(int irq, void *dev_id)
> +{
> + struct clock_event_device *evt = dev_id;
> + int irq_reenable = clockevent_state_periodic(evt);
> +
> + /* Remove HW thread from TSI only if NOT in periodic state */
> + nps_clkevent_rm_thread(!irq_reenable);
> +
> + evt->event_handler(evt);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int nps_timer_starting_cpu(unsigned int cpu)
> +{
> + struct clock_event_device *evt = this_cpu_ptr(&nps_clockevent_device);
> +
> + evt->cpumask = cpumask_of(smp_processor_id());
> +
> + clockevents_config_and_register(evt, nps_timer0_freq, 0, ULONG_MAX);
> + enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
> +
> + return 0;
> +}
> +
> +static int nps_timer_dying_cpu(unsigned int cpu)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> + return 0;
> +}
> +
> +static int __init nps_setup_clockevent(struct device_node *node)
> +{
> + struct clk *clk;
> + int ret;
> +
> + nps_timer0_irq = irq_of_parse_and_map(node, 0);
> + if (nps_timer0_irq <= 0) {
> + pr_err("clockevent: missing irq");
> + return -EINVAL;
> + }
> +
> + ret = nps_get_timer_clk(node, &nps_timer0_freq, &clk);
> + if (ret)
> + return ret;
> +
> + /* Needs apriori irq_set_percpu_devid() done in intc map function */
> + ret = request_percpu_irq(nps_timer0_irq, timer_irq_handler,
> + "Timer0 (per-cpu-tick)",
> + &nps_clockevent_device);
> + if (ret) {
> + pr_err("Couldn't request irq\n");
> + clk_disable_unprepare(clk);
> + return ret;
> + }
> +
> + ret = cpuhp_setup_state(CPUHP_AP_ARC_TIMER_STARTING,
> + "clockevents/nps:starting",
> + nps_timer_starting_cpu,
> + nps_timer_dying_cpu);
> + if (ret) {
> + pr_err("Failed to setup hotplug state");
> + clk_disable_unprepare(clk);
> + free_percpu_irq(nps_timer0_irq, &nps_clockevent_device);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
> + nps_setup_clockevent);
> +#endif /* CONFIG_EZNPS_MTM_EXT */
> --
> 1.7.1
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
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 v5 0/3] Add clockevet for timer-nps driver to NPS400 SoC
From: Daniel Lezcano @ 2016-11-14 11:25 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <DB6PR0501MB251893C085505B65DFFF7BFCAABC0-wTfl6qNNZ1PL+HUNrKNnF8DSnupUy6xnnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Mon, Nov 14, 2016 at 09:35:59AM +0000, Noam Camus wrote:
> >From: Daniel Lezcano [mailto:daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org]
> >Sent: Monday, November 14, 2016 10:28 AM
>
> >Noam,
>
> >I know it is patch 0/3, but each time you send a change there are new typos.
>
> >Sending new versions as fast as possible without double checking the changes won't make them merged sooner.
>
> >Nobody is perfect but clearly you don't read your patch before sending and that does not make me confident about the code changes.
>
> >In the future, take some minutes to double-check and re-read your changes.
>
> Thank you Daniel,
> I will do an extra check next time.
Triple check then because there are still typos in v6.
--
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 V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau @ 2016-11-14 11:26 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, Yuanzhichang,
mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F90EA45@lhreml507-mbx>
On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote:
> Hi Liviu
>
[snip]
> > > >
> > > > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and
> > you
> > > > actually need another variable for "reserving" an area in the I/O
> > space
> > > > that can be used for physical addresses rather than I/O tokens.
> > > >
> > > > The one good example for using PCIBIOS_MIN_IO is when your
> > > > platform/architecture
> > > > does not support legacy ISA operations *at all*. In that case
> > someone
> > > > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O
> > range
> > > > so that it doesn't get used. With Zhichang's patch you now start
> > > > forcing
> > > > those platforms to have a valid address below PCIBIOS_MIN_IO.
> > >
> > > But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be
> > used
> > > by PCI controllers only...
> >
> > Nope, that is not what it means. It means that PCI devices can see I/O
> > addresses
> > on the bus that start from 0. There never was any usage for non-PCI
> > controllers
>
> So I am a bit confused...
> From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> It seems that ISA buses operate on cpu I/O address range [0, 0xFFF].
> I thought that was the reason why for most architectures we have
> PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers
> usually use [0, PCIBIOS_MIN_IO - 1] )
First of all, cpu I/O addresses is an x86-ism. ARM architectures and others
have no separate address space for I/O, it is all merged into one unified
address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean
that we don't care about ISA I/O because the platform does not support having
an ISA bus (e.g.).
>
> For those architectures whose PCIBIOS_MIN_IO != 0x1000 probably
> they are not fully compliant or they cannot fully support an ISA
> controller...?
Exactly. Not fully compliant is a bit strong, as ISA is a legacy feature and
when it comes to PCI-e you are allowed to ignore it. Having PCIBIOS_MIN_IO != 0x1000
is a way to signal that you don't fully support ISA.
>
> As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO)
> to allow special ISA controllers to use that range with special
> accessors.
> Having a variable threshold would make life much more difficult
> as there would be a probe dependency between the PCI controller and
> the special ISA one (PCI to wait for the special ISA device to be
> probed and set the right threshold value from DT or ACPI table).
>
> Instead using PCIBIOS_MIN_IO is easier and should not impose much
> constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to
> the PCI controller for I/O tokens...
What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves
space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve
space for your direct address I/O on top of PCIBIOS_MIN_IO.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
> > when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and
> > what
> > I think is not the right thing (and not enough anyway).
> >
> > > so if you have a special bus device using
> > > an I/O range in this case should be a PCI controller...
> >
> > That has always been the case. It is this series that wants to
> > introduce the
> > new meaning.
> >
> > > i.e. I would
> > > expect it to fall back into the case of I/O tokens redirection rather
> > than
> > > physical addresses redirection (as mentioned below from my previous
> > reply).
> > > What do you think?
> >
> > I think you have looked too much at the code *with* Zhichang's patches
> > applied.
> > Take a step back and look at how PCIBIOS_MIN_IO is used now, before you
> > apply
> > the patches. It is all about PCI addresses and there is no notion of
> > non-PCI
> > busses using PCI framework. Only platforms and architectures that try
> > to work
> > around some legacy standards (ISA) or HW restrictions.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > Thanks
> > >
> > > Gab
> > >
> > >
> > > >
> > > > For the general case you also have to bear in mind that
> > PCIBIOS_MIN_IO
> > > > could
> > > > be zero. In that case, what is your "forbidden" range? [0, 0) ? So
> > it
> > > > makes
> > > > sense to add a new #define that should only be defined by those
> > > > architectures/
> > > > platforms that want to reserve on top of PCIBIOS_MIN_IO another
> > region
> > > > where I/O tokens can't be generated for.
> > > >
> > > > Best regards,
> > > > Liviu
> > > >
> > > > >
> > > > > >
> > > > > > > > Your current version has
> > > > > > > >
> > > > > > > > if (arm64_extio_ops->pfout)
> > > > \
> > > > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > > > >devpara,\
> > > > > > > > addr, value, sizeof(type));
> > > > \
> > > > > > > >
> > > > > > > > Instead, just subtract the start of the range from the
> > logical
> > > > > > > > port number to transform it back into a bus-local port
> > number:
> > > > > > >
> > > > > > > These accessors do not operate on IO tokens:
> > > > > > >
> > > > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end <
> > addr)
> > > > > > > addr is not going to be an I/O token; in fact patch 2/3
> > imposes
> > > > that
> > > > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > > > PCIBIOS_MIN_IO
> > > > > > > we have free physical addresses that the accessors can
> > operate
> > > > on.
> > > > > >
> > > > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to
> > refer
> > > > to
> > > > > > the logical I/O tokens, the purpose of that macro is really
> > meant
> > > > > > for allocating PCI I/O port numbers within the address space of
> > > > > > one bus.
> > > > >
> > > > > As I mentioned above, special devices operate on CPU addresses
> > > > directly,
> > > > > not I/O tokens. For them there is no way to distinguish....
> > > > >
> > > > > >
> > > > > > Note that it's equally likely that whichever next platform
> > needs
> > > > > > non-mapped I/O access like this actually needs them for PCI I/O
> > > > space,
> > > > > > and that will use it on addresses registered to a PCI host
> > bridge.
> > > > >
> > > > > Ok so here you are talking about a platform that has got an I/O
> > range
> > > > > under the PCI host controller, right?
> > > > > And this I/O range cannot be directly memory mapped but needs
> > special
> > > > > redirections for the I/O tokens, right?
> > > > >
> > > > > In this scenario registering the I/O ranges with the forbidden
> > range
> > > > > implemented by the current patch would still allow to redirect
> > I/O
> > > > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > > > >
> > > > > So effectively the special PCI host controller
> > > > > 1) knows the physical range that needs special redirection
> > > > > 2) register such range
> > > > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > > > special accessors
> > > > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in
> > 3)
> > > > >
> > > > > So to be honest I think this patch can fit well both with
> > > > > special PCI controllers that need I/O tokens redirection and with
> > > > > special non-PCI controllers that need non-PCI I/O physical
> > > > > address redirection...
> > > > >
> > > > > Thanks (and sorry for the long reply but I didn't know how
> > > > > to make the explanation shorter :) )
> > > > >
> > > > > Gab
> > > > >
> > > > > >
> > > > > > If we separate the two steps:
> > > > > >
> > > > > > a) assign a range of logical I/O port numbers to a bus
> > > > > > b) register a set of helpers for redirecting logical I/O
> > > > > > port to a helper function
> > > > > >
> > > > > > then I think the code will get cleaner and more flexible.
> > > > > > It should actually then be able to replace the powerpc
> > > > > > specific implementation.
> > > > > >
> > > > > > Arnd
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Peter Griffin @ 2016-11-14 11:42 UTC (permalink / raw)
To: Vinod Koul
Cc: Bjorn Andersson, linux-arm-kernel, linux-kernel, kernel, ohad,
patrice.chotard, lee.jones, dmaengine, devicetree,
linux-remoteproc
In-Reply-To: <20161114051854.GW3000@localhost>
Hi Vinod,
On Mon, 14 Nov 2016, Vinod Koul wrote:
> On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > >
> > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > without providing Linus with a messy merge conflict.
> > >
> > > So the remoteproc parts now has to go through my tree.
> >
> > OK, I think the best approach is for Vinod to create an immutable
> > branch with the entire fdma series on, and then both of you merge that branch into
> > your respective trees.
>
> my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> tag, please do let me know
OK.
>
> >
> > That way there won't be any conflicts and you can both accept further changes
> > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> > because they have dependencies on each other.
> >
> > I will send a v11 series in a moment which includes the feedback in this email
> > and also include the additional fixes which Vinod has applied since the driver
> > has been in linux-next.
>
> WHY.. Stuff is already merged twice!
When the feedback is "there is an unrelated change in this patch", the only way
you can fix that is by having a new version of the patch.
>Please send updated on top of already
> merged code!
You have dropped the remoteproc parts which were updated in v11, so
it is no longer merged. Bjorn can now pick the v11 versions if he chooses which
incporporates his feedback.
>This is how kernel developement is done...
regards,
Peter.
^ permalink raw reply
* [PATCH v3] dts: omap5: board-common: fix wrong SMPS6 (VDD-DDR3) voltage
From: H. Nikolaus Schaller @ 2016-11-14 11:55 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Mark Rutland,
Russell King
Cc: linux-omap, devicetree, linux-kernel, kernel,
H. Nikolaus Schaller
DDR3L is usually specified as
JEDEC standard 1.35V(1.28V~1.45V) & 1.5V(1.425V~1.575V)
Therefore setting smps6 regulator to 1.2V is definitively below
minimum. It appears that real world chips are more forgiving than
data sheets indicate, but let's set the regulator right.
Note: a board that uses other voltages (DDR with 1.5V) can
overwrite by referencing &smps6_reg.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
index ab60a8e..e4a14d5 100644
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -476,8 +476,8 @@
smps6_reg: smps6 {
/* VDD_DDR3 - over VDD_SMPS6 */
regulator-name = "smps6";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
};
--
2.7.3
^ permalink raw reply related
* [PATCH v2 00/10] Add basic support for Rockchip RK1108 SOC
From: Andy Yan @ 2016-11-14 11:55 UTC (permalink / raw)
To: heiko
Cc: shawn.lin, linus.walleij, robh+dt, linux-clk, linux-rockchip,
devicetree, mturquette, sboyd, linux-gpio, linux,
linux-arm-kernel, ulf.hansson, linux-mmc, linux-kernel,
mark.rutland, Andy Yan
RK1108 is embedded with an ARM Cortex-A7 single core and a DSP core.
It is designed for varies application scenario such as car DVR, sports
DV, secure camera and UAV camera.
This patch series add basic support for it, which can boot a board with
initramfs into shell.
More new feathers will come soon.
Changes in v2:
- split dt-binding header from clk driver
- fix some CodingStyle issues
- add dt-binding documentation for pinctrl
- add pull and drive-strength functionality for pinctrl
- fix timer and gic dt description
- ordering devices by register address
- move the board in the rockchip.txt to the block of Rockchip boards
Andy Yan (6):
dt-bindings: add documentation for rk1108 pinctrl
pinctrl: rockchip: add support for rk1108
ARM: add low level debug uart for rk1108
ARM: dts: add basic support for Rockchip RK1108 SOC
ARM: rockchip: enable support for RK1108 SoC
ARM: dts: rockchip: add rockchip RK1108 Evaluation board
Shawn Lin (4):
dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
dt-bindings: add documentation for rk1108 cru
clk: rockchip: add dt-binding header for rk1108
clk: rockchip: add clock controller for rk1108
Documentation/devicetree/bindings/arm/rockchip.txt | 5 +-
.../bindings/clock/rockchip,rk1108-cru.txt | 60 +++
.../devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
.../bindings/pinctrl/rockchip,pinctrl.txt | 9 +-
arch/arm/Kconfig.debug | 30 ++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk1108-evb.dts | 69 ++++
arch/arm/boot/dts/rk1108.dtsi | 428 +++++++++++++++++++
arch/arm/mach-rockchip/rockchip.c | 1 +
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-rk1108.c | 451 +++++++++++++++++++++
drivers/clk/rockchip/clk.h | 14 +
drivers/pinctrl/pinctrl-rockchip.c | 87 +++-
include/dt-bindings/clock/rk1108-cru.h | 270 ++++++++++++
14 files changed, 1421 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
create mode 100644 arch/arm/boot/dts/rk1108.dtsi
create mode 100644 drivers/clk/rockchip/clk-rk1108.c
create mode 100644 include/dt-bindings/clock/rk1108-cru.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Michael Ellerman @ 2016-11-14 11:59 UTC (permalink / raw)
To: Reza Arbab, Benjamin Herrenschmidt, Paul Mackerras, Andrew Morton,
Rob Herring, Frank Rowand, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
Aneesh Kumar K.V, linux-kernel
In-Reply-To: <1478562276-25539-5-git-send-email-arbab@linux.vnet.ibm.com>
Reza Arbab <arbab@linux.vnet.ibm.com> writes:
> When movable nodes are enabled, any node containing only hotpluggable
> memory is made movable at boot time.
>
> On x86, hotpluggable memory is discovered by parsing the ACPI SRAT,
> making corresponding calls to memblock_mark_hotplug().
>
> If we introduce a dt property to describe memory as hotpluggable,
> configs supporting early fdt may then also do this marking and use
> movable nodes.
So I'm not opposed to this, but it is a little vague.
What does the "hotpluggable" property really mean?
Is it just a hint to the operating system? (which may or may not be
Linux).
Or is it a direction, "this memory must be able to be hotunplugged"?
I think you're intending the former, ie. a hint, which is probably OK.
But it needs to be documented clearly.
cheers
^ permalink raw reply
* [PATCH v2 01/10] dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
From: Andy Yan @ 2016-11-14 12:01 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Add "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc" for
dwmmc on rk1108 platform.
Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2: None
Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index 07184e8..ea9c1c9 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -13,6 +13,7 @@ Required Properties:
- "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following,
before RK3288
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
+ - "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK1108
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3368
- "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3399
--
2.7.4
^ permalink raw reply related
* [PATCH v2 02/10] dt-bindings: add documentation for rk1108 cru
From: Andy Yan @ 2016-11-14 12:03 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
Andy Yan
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
This adds the dt-binding documentation for the clock and reset unit
found on Rockchip rk1108 SoCs.
Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2: None
.../bindings/clock/rockchip,rk1108-cru.txt | 60 ++++++++++++++++++++++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
new file mode 100644
index 0000000..4d2356b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
@@ -0,0 +1,60 @@
+* Rockchip RK1108 Clock and Reset Unit
+
+The RK1108 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk1108-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk1108-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "cif_clkout" - output clock for the cif - optional
+ - "mipi_csi_clkout" - output clock for the mipi csi - optional
+ - "pclkin_vip" - external VIP clock - optional
+ - "ext_i2s" - external I2S clock - optional
+ - "ext_gmac" - external GMAC clock - optional
+ - "mac_ref_clkout" - output clock of the pll in the mac phy
+
+Example: Clock controller node:
+
+ cru: cru@20200000 {
+ compatible = "rockchip,rk1108-cru";
+ reg = <0x20200000 0x1000>;
+ rockchip,grf = <&grf>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@10230000 {
+ compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
+ reg = <0x10230000 0x100>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cru SCLK_UART0>;
+ };
--
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 v2 03/10] clk: rockchip: add dt-binding header for rk1108
From: Andy Yan @ 2016-11-14 12:04 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Andy Yan
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Add the dt-bindings header for the rk1108, that gets shared
between the clock controller and the clock references in the dts.
Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2:
- split dt-binding header from clk driver
include/dt-bindings/clock/rk1108-cru.h | 270 +++++++++++++++++++++++++++++++++
1 file changed, 270 insertions(+)
create mode 100644 include/dt-bindings/clock/rk1108-cru.h
diff --git a/include/dt-bindings/clock/rk1108-cru.h b/include/dt-bindings/clock/rk1108-cru.h
new file mode 100644
index 0000000..6f30008
--- /dev/null
+++ b/include/dt-bindings/clock/rk1108-cru.h
@@ -0,0 +1,270 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK1108_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK1108_H
+
+/* pll id */
+#define RK1108_APLL_ID 0
+#define RK1108_DPLL_ID 1
+#define RK1108_GPLL_ID 2
+#define RK1108_ARMCLK 3
+
+/* sclk gates (special clocks) */
+#define SCLK_SPI0 65
+#define SCLK_NANDC 67
+#define SCLK_SDMMC 68
+#define SCLK_SDIO 69
+#define SCLK_EMMC 71
+#define SCLK_UART0 72
+#define SCLK_UART1 73
+#define SCLK_UART2 74
+#define SCLK_I2S0 75
+#define SCLK_I2S1 76
+#define SCLK_I2S2 77
+#define SCLK_TIMER0 78
+#define SCLK_TIMER1 79
+#define SCLK_SFC 80
+#define SCLK_SDMMC_DRV 81
+#define SCLK_SDIO_DRV 82
+#define SCLK_EMMC_DRV 83
+#define SCLK_SDMMC_SAMPLE 84
+#define SCLK_SDIO_SAMPLE 85
+#define SCLK_EMMC_SAMPLE 86
+
+/* aclk gates */
+#define ACLK_DMAC 251
+#define ACLK_PRE 252
+#define ACLK_CORE 253
+#define ACLK_ENMCORE 254
+
+/* pclk gates */
+#define PCLK_GPIO1 321
+#define PCLK_GPIO2 322
+#define PCLK_GPIO3 323
+#define PCLK_GRF 329
+#define PCLK_I2C1 333
+#define PCLK_I2C2 334
+#define PCLK_I2C3 335
+#define PCLK_SPI 338
+#define PCLK_SFC 339
+#define PCLK_UART0 341
+#define PCLK_UART1 342
+#define PCLK_UART2 343
+#define PCLK_TSADC 344
+#define PCLK_PWM 350
+#define PCLK_TIMER 353
+#define PCLK_PERI 363
+
+/* hclk gates */
+#define HCLK_I2S0_8CH 442
+#define HCLK_I2S1_8CH 443
+#define HCLK_I2S2_2CH 444
+#define HCLK_NANDC 453
+#define HCLK_SDMMC 456
+#define HCLK_SDIO 457
+#define HCLK_EMMC 459
+#define HCLK_PERI 478
+#define HCLK_SFC 479
+
+#define CLK_NR_CLKS (HCLK_SFC + 1)
+
+/* reset id */
+#define SRST_CORE_PO_AD 0
+#define SRST_CORE_AD 1
+#define SRST_L2_AD 2
+#define SRST_CPU_NIU_AD 3
+#define SRST_CORE_PO 4
+#define SRST_CORE 5
+#define SRST_L2 6
+#define SRST_CORE_DBG 8
+#define PRST_DBG 9
+#define RST_DAP 10
+#define PRST_DBG_NIU 11
+#define ARST_STRC_SYS_AD 15
+
+#define SRST_DDRPHY_CLKDIV 16
+#define SRST_DDRPHY 17
+#define PRST_DDRPHY 18
+#define PRST_HDMIPHY 19
+#define PRST_VDACPHY 20
+#define PRST_VADCPHY 21
+#define PRST_MIPI_CSI_PHY 22
+#define PRST_MIPI_DSI_PHY 23
+#define PRST_ACODEC 24
+#define ARST_BUS_NIU 25
+#define PRST_TOP_NIU 26
+#define ARST_INTMEM 27
+#define HRST_ROM 28
+#define ARST_DMAC 29
+#define SRST_MSCH_NIU 30
+#define PRST_MSCH_NIU 31
+
+#define PRST_DDRUPCTL 32
+#define NRST_DDRUPCTL 33
+#define PRST_DDRMON 34
+#define HRST_I2S0_8CH 35
+#define MRST_I2S0_8CH 36
+#define HRST_I2S1_2CH 37
+#define MRST_IS21_2CH 38
+#define HRST_I2S2_2CH 39
+#define MRST_I2S2_2CH 40
+#define HRST_CRYPTO 41
+#define SRST_CRYPTO 42
+#define PRST_SPI 43
+#define SRST_SPI 44
+#define PRST_UART0 45
+#define PRST_UART1 46
+#define PRST_UART2 47
+
+#define SRST_UART0 48
+#define SRST_UART1 49
+#define SRST_UART2 50
+#define PRST_I2C1 51
+#define PRST_I2C2 52
+#define PRST_I2C3 53
+#define SRST_I2C1 54
+#define SRST_I2C2 55
+#define SRST_I2C3 56
+#define PRST_PWM1 58
+#define SRST_PWM1 60
+#define PRST_WDT 61
+#define PRST_GPIO1 62
+#define PRST_GPIO2 63
+
+#define PRST_GPIO3 64
+#define PRST_GRF 65
+#define PRST_EFUSE 66
+#define PRST_EFUSE512 67
+#define PRST_TIMER0 68
+#define SRST_TIMER0 69
+#define SRST_TIMER1 70
+#define PRST_TSADC 71
+#define SRST_TSADC 72
+#define PRST_SARADC 73
+#define SRST_SARADC 74
+#define HRST_SYSBUS 75
+#define PRST_USBGRF 76
+
+#define ARST_PERIPH_NIU 80
+#define HRST_PERIPH_NIU 81
+#define PRST_PERIPH_NIU 82
+#define HRST_PERIPH 83
+#define HRST_SDMMC 84
+#define HRST_SDIO 85
+#define HRST_EMMC 86
+#define HRST_NANDC 87
+#define NRST_NANDC 88
+#define HRST_SFC 89
+#define SRST_SFC 90
+#define ARST_GMAC 91
+#define HRST_OTG 92
+#define SRST_OTG 93
+#define SRST_OTG_ADP 94
+#define HRST_HOST0 95
+
+#define HRST_HOST0_AUX 96
+#define HRST_HOST0_ARB 97
+#define SRST_HOST0_EHCIPHY 98
+#define SRST_HOST0_UTMI 99
+#define SRST_USBPOR 100
+#define SRST_UTMI0 101
+#define SRST_UTMI1 102
+
+#define ARST_VIO0_NIU 102
+#define ARST_VIO1_NIU 103
+#define HRST_VIO_NIU 104
+#define PRST_VIO_NIU 105
+#define ARST_VOP 106
+#define HRST_VOP 107
+#define DRST_VOP 108
+#define ARST_IEP 109
+#define HRST_IEP 110
+#define ARST_RGA 111
+#define HRST_RGA 112
+#define SRST_RGA 113
+#define PRST_CVBS 114
+#define PRST_HDMI 115
+#define SRST_HDMI 116
+#define PRST_MIPI_DSI 117
+
+#define ARST_ISP_NIU 118
+#define HRST_ISP_NIU 119
+#define HRST_ISP 120
+#define SRST_ISP 121
+#define ARST_VIP0 122
+#define HRST_VIP0 123
+#define PRST_VIP0 124
+#define ARST_VIP1 125
+#define HRST_VIP1 126
+#define PRST_VIP1 127
+#define ARST_VIP2 128
+#define HRST_VIP2 129
+#define PRST_VIP2 120
+#define ARST_VIP3 121
+#define HRST_VIP3 122
+#define PRST_VIP4 123
+
+#define PRST_CIF1TO4 124
+#define SRST_CVBS_CLK 125
+#define HRST_CVBS 126
+
+#define ARST_VPU_NIU 140
+#define HRST_VPU_NIU 141
+#define ARST_VPU 142
+#define HRST_VPU 143
+#define ARST_RKVDEC_NIU 144
+#define HRST_RKVDEC_NIU 145
+#define ARST_RKVDEC 146
+#define HRST_RKVDEC 147
+#define SRST_RKVDEC_CABAC 148
+#define SRST_RKVDEC_CORE 149
+#define ARST_RKVENC_NIU 150
+#define HRST_RKVENC_NIU 151
+#define ARST_RKVENC 152
+#define HRST_RKVENC 153
+#define SRST_RKVENC_CORE 154
+
+#define SRST_DSP_CORE 156
+#define SRST_DSP_SYS 157
+#define SRST_DSP_GLOBAL 158
+#define SRST_DSP_OECM 159
+#define PRST_DSP_IOP_NIU 160
+#define ARST_DSP_EPP_NIU 161
+#define ARST_DSP_EDP_NIU 162
+#define PRST_DSP_DBG_NIU 163
+#define PRST_DSP_CFG_NIU 164
+#define PRST_DSP_GRF 165
+#define PRST_DSP_MAILBOX 166
+#define PRST_DSP_INTC 167
+#define PRST_DSP_PFM_MON 169
+#define SRST_DSP_PFM_MON 170
+#define ARST_DSP_EDAP_NIU 171
+
+#define SRST_PMU 172
+#define SRST_PMU_I2C0 173
+#define PRST_PMU_I2C0 174
+#define PRST_PMU_GPIO0 175
+#define PRST_PMU_INTMEM 176
+#define PRST_PMU_PWM0 177
+#define SRST_PMU_PWM0 178
+#define PRST_PMU_GRF 179
+#define SRST_PMU_NIU 180
+#define SRST_PMU_PVTM 181
+#define ARST_DSP_EDP_PERF 184
+#define ARST_DSP_EPP_PERF 185
+
+#endif /* _DT_BINDINGS_CLK_ROCKCHIP_RK1108_H */
+
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 3/6] iio: adc: Add support for STM32 ADC
From: Lars-Peter Clausen @ 2016-11-14 12:11 UTC (permalink / raw)
To: Fabrice Gasnier, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, knaack.h-Mmb7MZpHnFY,
pmeerw-jW+XmwGofnusTnJN9+BGXg
In-Reply-To: <1478794738-28933-4-git-send-email-fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
On 11/10/2016 05:18 PM, Fabrice Gasnier wrote:
[...]
> + static int stm32_adc_single_conv(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *res)
> +{
> + struct stm32_adc *adc = iio_priv(indio_dev);
> + long timeout;
> + u32 val;
> + u16 result;
> + int ret;
> +
> + reinit_completion(&adc->completion);
> +
> + adc->buffer = &result;
> +
> + /* Program chan number in regular sequence */
> + val = stm32_adc_readl(adc, STM32F4_ADCX_SQR3);
> + val &= ~STM32F4_SQ1_MASK;
> + val |= chan->channel << STM32F4_SQ1_SHIFT;
> + stm32_adc_writel(adc, STM32F4_ADCX_SQR3, val);
> +
> + /* Set regular sequence len (0 for 1 conversion) */
> + stm32_adc_clr_bits(adc, STM32F4_ADCX_SQR1, STM32F4_L_MASK);
> +
> + /* Trigger detection disabled (conversion can be launched in SW) */
> + stm32_adc_clr_bits(adc, STM32F4_ADCX_CR2, STM32F4_EXTEN_MASK);
> +
> + stm32_adc_conv_irq_enable(adc);
> +
> + stm32_adc_start_conv(adc);
> +
> + timeout = wait_for_completion_interruptible_timeout(
> + &adc->completion, STM32_ADC_TIMEOUT);
> + if (timeout == 0) {
> + dev_warn(&indio_dev->dev, "Conversion timed out!\n");
This should be dev_dbg() at most. This out of band reporting is not
particular useful for applications as it is impossible to match the error to
the action that triggered it. And you also report the error through the
error code, so the applications knows what is going on.
> + ret = -ETIMEDOUT;
> + } else if (timeout < 0) {
> + dev_warn(&indio_dev->dev, "Interrupted conversion!\n");
> + ret = -EINTR;
This should just propagate the error returned by wait_for_completion...().
This will make sure that the right behavior occurs based on the SA_RESTART
policy.
> + } else {
> + *res = result;
> + ret = IIO_VAL_INT;
> + }
> +
> + stm32_adc_stop_conv(adc);
> +
> + stm32_adc_conv_irq_disable(adc);
> +
> + return ret;
--
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 v2 08/10] ARM: dts: add basic support for Rockchip RK1108 SOC
From: Andy Yan @ 2016-11-14 12:14 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andy Yan
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
RK1108 is embedded with an ARM Cortex-A7 single core and a DSP core.
It is designed for varies application scenario such as car DVR, sports
DV, secure camera and UAV camera.
This patch add basic support for it with DMAC / UART / CRU / pinctrl / MMC
enabled.
Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Tested-by: Jacob Chen <jacob2.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v2:
- fix timer and gic dt description
- ordering devices by register address
arch/arm/boot/dts/rk1108.dtsi | 428 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 428 insertions(+)
create mode 100644 arch/arm/boot/dts/rk1108.dtsi
diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
new file mode 100644
index 0000000..636c294
--- /dev/null
+++ b/arch/arm/boot/dts/rk1108.dtsi
@@ -0,0 +1,428 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/rk1108-cru.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ compatible = "rockchip,rk1108";
+
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@f00 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf00>;
+ };
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
+ clock-frequency = <24000000>;
+ };
+
+ xin24m: oscillator {
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "xin24m";
+ #clock-cells = <0>;
+ };
+
+ bus_intmem@10080000 {
+ compatible = "mmio-sram";
+ reg = <0x10080000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x10080000 0x2000>;
+ };
+
+ amba {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pdma: pdma@102a0000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x102a0000 0x4000>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ arm,pl330-broken-no-flushp;
+ clocks = <&cru ACLK_DMAC>;
+ clock-names = "apb_pclk";
+ };
+ };
+
+ uart2: serial@10210000 {
+ compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
+ reg = <0x10210000 0x100>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <24000000>;
+ clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+ clock-names = "baudclk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2m0_xfer>;
+ status = "disabled";
+ };
+
+ uart1: serial@10220000 {
+ compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
+ reg = <0x10220000 0x100>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <24000000>;
+ clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+ clock-names = "baudclk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_xfer>;
+ status = "disabled";
+ };
+
+ uart0: serial@10230000 {
+ compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
+ reg = <0x10230000 0x100>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <24000000>;
+ clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+ clock-names = "baudclk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
+ status = "disabled";
+ };
+
+ grf: syscon@10300000 {
+ compatible = "rockchip,rk1108-grf", "syscon";
+ reg = <0x10300000 0x1000>;
+ };
+
+ pmugrf: syscon@20060000 {
+ compatible = "rockchip,rk1108-pmugrf", "syscon";
+ reg = <0x20060000 0x1000>;
+ };
+
+ cru: clock-controller@20200000 {
+ compatible = "rockchip,rk1108-cru";
+ reg = <0x20200000 0x1000>;
+ rockchip,grf = <&grf>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ emmc: dwmmc@30110000 {
+ compatible = "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc";
+ clock-freq-min-max = <400000 150000000>;
+ clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
+ <&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+ fifo-depth = <0x100>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x30110000 0x4000>;
+ status = "disabled";
+ };
+
+ sdio: dwmmc@30120000 {
+ compatible = "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc";
+ clock-freq-min-max = <400000 150000000>;
+ clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>,
+ <&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+ fifo-depth = <0x100>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x30120000 0x4000>;
+ status = "disabled";
+ };
+
+ sdmmc: dwmmc@30130000 {
+ compatible = "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc";
+ clock-freq-min-max = <400000 100000000>;
+ clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
+ <&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+ fifo-depth = <0x100>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x30130000 0x4000>;
+ status = "disabled";
+ };
+
+ gic: interrupt-controller@32010000 {
+ compatible = "arm,gic-400";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+
+ reg = <0x32011000 0x1000>,
+ <0x32012000 0x1000>,
+ <0x32014000 0x2000>,
+ <0x32016000 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ pinctrl: pinctrl {
+ compatible = "rockchip,rk1108-pinctrl";
+ rockchip,grf = <&grf>;
+ rockchip,pmu = <&pmugrf>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gpio0: gpio0@20030000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x20030000 0x100>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&xin24m>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio1: gpio1@10310000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x10310000 0x100>;
+ interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&xin24m>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio2: gpio2@10320000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x10320000 0x100>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&xin24m>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio3: gpio3@10330000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x10330000 0x100>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&xin24m>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ pcfg_pull_up: pcfg-pull-up {
+ bias-pull-up;
+ };
+
+ pcfg_pull_down: pcfg-pull-down {
+ bias-pull-down;
+ };
+
+ pcfg_pull_none: pcfg-pull-none {
+ bias-disable;
+ };
+
+ pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
+ drive-strength = <8>;
+ };
+
+ pcfg_pull_none_drv_12ma: pcfg-pull-none-drv-12ma {
+ drive-strength = <12>;
+ };
+
+ pcfg_pull_up_drv_8ma: pcfg-pull-up-drv-8ma {
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+
+ pcfg_pull_none_drv_4ma: pcfg-pull-none-drv-4ma {
+ drive-strength = <4>;
+ };
+
+ pcfg_pull_up_drv_4ma: pcfg-pull-up-drv-4ma {
+ bias-pull-up;
+ drive-strength = <4>;
+ };
+
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
+ };
+
+ pcfg_input_high: pcfg-input-high {
+ bias-pull-up;
+ input-enable;
+ };
+
+ i2c1 {
+ i2c1_xfer: i2c1-xfer {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_1 &pcfg_pull_up>,
+ <2 RK_PD4 RK_FUNC_1 &pcfg_pull_up>;
+ };
+ };
+
+ i2c2m1 {
+ i2c2m1_xfer: i2c2m1-xfer {
+ rockchip,pins = <0 RK_PC2 RK_FUNC_2 &pcfg_pull_none>,
+ <0 RK_PC6 RK_FUNC_3 &pcfg_pull_none>;
+ };
+
+ i2c2m1_gpio: i2c2m1-gpio {
+ rockchip,pins = <0 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>,
+ <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ i2c2m05v {
+ i2c2m05v_xfer: i2c2m05v-xfer {
+ rockchip,pins = <1 RK_PD5 RK_FUNC_2 &pcfg_pull_none>,
+ <1 RK_PD4 RK_FUNC_2 &pcfg_pull_none>;
+ };
+
+ i2c2m05v_gpio: i2c2m05v-gpio {
+ rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>,
+ <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ i2c3 {
+ i2c3_xfer: i2c3-xfer {
+ rockchip,pins = <0 RK_PB6 RK_FUNC_1 &pcfg_pull_none>,
+ <0 RK_PC4 RK_FUNC_2 &pcfg_pull_none>;
+ };
+ };
+
+ uart0 {
+ uart0_xfer: uart0-xfer {
+ rockchip,pins = <3 RK_PA6 RK_FUNC_1 &pcfg_pull_up>,
+ <3 RK_PA5 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart0_cts: uart0-cts {
+ rockchip,pins = <3 RK_PA4 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart0_rts: uart0-rts {
+ rockchip,pins = <3 RK_PA3 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart0_rts_gpio: uart0-rts-gpio {
+ rockchip,pins = <3 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ uart1 {
+ uart1_xfer: uart1-xfer {
+ rockchip,pins = <1 RK_PD3 RK_FUNC_1 &pcfg_pull_up>,
+ <1 RK_PD2 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart1_cts: uart1-cts {
+ rockchip,pins = <1 RK_PD0 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart1_rts: uart1-rts {
+ rockchip,pins = <1 RK_PD1 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ uart2m0 {
+ uart2m0_xfer: uart2m0-xfer {
+ rockchip,pins = <2 RK_PD2 RK_FUNC_1 &pcfg_pull_up>,
+ <2 RK_PD1 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ uart2m1 {
+ uart2m1_xfer: uart2m1-xfer {
+ rockchip,pins = <3 RK_PC3 RK_FUNC_2 &pcfg_pull_up>,
+ <3 RK_PC2 RK_FUNC_2 &pcfg_pull_none>;
+ };
+ };
+
+ uart2_5v {
+ uart2_5v_cts: uart2_5v-cts {
+ rockchip,pins = <1 RK_PD4 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart2_5v_rts: uart2_5v-rts {
+ rockchip,pins = <1 RK_PD5 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+ };
+};
--
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 v2 10/10] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Andy Yan @ 2016-11-14 12:17 UTC (permalink / raw)
To: heiko
Cc: linux-rockchip, mark.rutland, linux-arm-kernel, devicetree, linux,
linux-kernel, Andy Yan
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan@rock-chips.com>
RK1108 EVB is designed by Rockchip for CVR field.
This patch add basic support for it, which can boot with
initramfs into shell.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v2:
- move the board in the rockchip.txt to the block of Rockchip boards
Documentation/devicetree/bindings/arm/rockchip.txt | 5 +-
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk1108-evb.dts | 69 ++++++++++++++++++++++
3 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 10b92b5..e658b62 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -1,6 +1,5 @@
Rockchip platforms device tree bindings
---------------------------------------
-
- Kylin RK3036 board:
Required root node properties:
- compatible = "rockchip,kylin-rk3036", "rockchip,rk3036";
@@ -111,6 +110,10 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
+- Rockchip RK1108 Evaluation board
+ Required root node properties:
+ - compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
+
- Rockchip RK3368 evb:
Required root node properties:
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e49476a..249dca9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -635,6 +635,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pba8.dtb \
arm-realview-pbx-a9.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+ rk1108-evb.dtb \
rk3036-evb.dtb \
rk3036-kylin.dtb \
rk3066a-bqcurie2.dtb \
diff --git a/arch/arm/boot/dts/rk1108-evb.dts b/arch/arm/boot/dts/rk1108-evb.dts
new file mode 100644
index 0000000..3956cff
--- /dev/null
+++ b/arch/arm/boot/dts/rk1108-evb.dts
@@ -0,0 +1,69 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk1108.dtsi"
+
+/ {
+ model = "Rockchip RK1108 Evaluation board";
+ compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
+
+ memory@60000000 {
+ device_type = "memory";
+ reg = <0x60000000 0x08000000>;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek-x+rMaJPWets @ 2016-11-14 12:23 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Martin Strbačka, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161105203841.9661-1-uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
Hello Uwe and all!
On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-König
<uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org> wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
>
> Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> ---
>
> Hello,
>
> the following components are working:
>
> - WAN port
> - eMMC
But I not not sure about DDR50 mode. At least with kernel 4.4, that we
use in production, we had to limit to SDR50 to overcome I/O errors and
communication instability, if I can remember it correctly. So it might
need more testing with the current kernel.
>
> - UART0
> - USB
It is worth noting that the USB 2.0 interface of Armada 385 is wired to
USB pinout of the last (right-most) PCIe connector. The two USB3
interfaces routed through SERDES 1 and 3 go directly to the external
USB connectors.
>
> Still missing is support for the switch. Wireless fails to probe,
> didn't
> debug this up to now. SFP is untested as is UART1.
Actually SFP is connected to SGMII interface of eth1, which is routed
through SERDES 5. The SGMII line is shared between the SFP and metallic
PHY 88E1514. There is a autonomous high-speed switch connected to the
SFPDET signal from SFP cage. It disconnects the metallic SFP and
connects SGMII to SFP once the module is connected.
The SFP is also connected to the I2C mux port 4 and to GPIO expander
for reading/driving SFPDET, LOS, TXFLT, TXDIS signals:
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
status = "okay";
clock-frequency = <100000>;
i2cmux@70 {
compatible = "nxp,pca9547";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
status = "okay";
...
i2c@7 {
/* SFP+ GPIO expander */
#address-cells = <1>;
#size-cells = <0>;
reg = <7>;
sfpgpio: gpio@71 {
compatible = "nxp,pca9538";
reg = <0x71>;
interrupt-parent = <&gpio1>;
interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
gpio-controller;
#gpio-cells = <2>;
};
};
};
};
We have our proprietary support hacked onto mvneta driver for
disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore
SFP in this DTS altogether and let's wait till "phylink based SFP
module support" or something alike hits upstream, so we can base the
SFP support on solid code; unless somebody has a better idea, of course.
>
>
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 000000000000..d3cd8a4d713d
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,246 @@
...
> +
> + /* USB part of the eSATA/USB 2.0 port */
This comment is perhaps some error inherited from my development DTS.
We do not have any eSATA, perhaps PCIe/USB 2.0 slot.
>
> + usb@58000 {
> + status = "okay";
> + };
> +
> +
> +ð0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge0_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
> +ð1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge1_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
switch. The problem is that from what I have read so far the switch can
not operate in DSA mode with two CPU ports. We currently operate the
switch in "normal mode" with the eth0 and eth1 set to fixed-link
1000/full and with proprietary driver (derived from OpenWRT switch
drivers). I would say that these records for eth0 and eth1 are
therefore redundant, because it does nothing without the switch support
and it would most likely change once we have DSA driver (using only
eth0).
Tomas
--
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 v2] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Sanchayan Maity @ 2016-11-14 12:37 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: stefan-XLVq0VzYD2Y,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sanchayan Maity
In-Reply-To: <20161110114505.17618-1-maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Enable DMA for DSPI2 and DSPI3 on Vybrid.
Signed-off-by: Sanchayan Maity <maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes since v1:
Add signed-off-by missing in v1.
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 000550f..e9d2847 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -573,6 +573,9 @@
clocks = <&clks VF610_CLK_DSPI2>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 10>,
+ <&edma1 0 11>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -585,6 +588,9 @@
clocks = <&clks VF610_CLK_DSPI3>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 12>,
+ <&edma1 0 13>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.10.2
--
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
* Re: [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-14 13:10 UTC (permalink / raw)
To: tomas.hlavacek-x+rMaJPWets
Cc: Uwe Kleine-König, Mark Rutland, Jason Cooper,
Martin Strba??ka, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <1479126185.15557.5-TAvD023jEQEN+BqQ9rBEUg@public.gmane.org>
> Actually SFP is connected to SGMII interface of eth1, which is
> routed through SERDES 5.
You say eth1 here. Yet lower down you say got eth0 and eth1 are
connected to the switch?
> We have our proprietary support hacked onto mvneta driver for
> disconnecting PHY on the fly. It is a bit nasty, so I suggest to
> ignore SFP in this DTS altogether and let's wait till "phylink based
> SFP module support" or something alike hits upstream, so we can base
> the SFP support on solid code;
It would be great if you could work on getting the phylink patches
into mainline. It is something i have wanted to do for a long time,
but it is too low down on my priority list to get to. The code is high
quality, so i don't think there will be too many issues. It probably
just needs splitting up into smaller batches, submitting, and working
on any comments.
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
> switch. The problem is that from what I have read so far the switch
> can not operate in DSA mode with two CPU ports.
Again, this is something i wanted to do, and i did have a prototype at
one point. But again, not enough time. If you have resources to work
on this, i can find my code, explain my ideas, and let you complete
it.
Andrew
--
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: Re: [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-14 13:10 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, Icenowy Zheng, Jonathan Corbet, Rob Herring,
Mark Rutland, Russell King,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel, linux-kernel, devicetree, linux-sunxi
In-Reply-To: <cbbf8ae1-ff29-2a83-265b-a9ff5bacf97b-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
On Mon, Nov 14, 2016 at 11:00:32AM +0100, Hans de Goede wrote:
> > > > +&usbphy {
> > > > + /* USB VBUS is always on */
> > >
> > > You can put the always on regulators (I'm guessing reg_vcc5v0 ?) here.
> >
> > AFAIK the regulator properties are optional the the USB PHY.
> > So we probably don't need to add it. Hans (CC-ed) could explain
> > his original intent?
>
> I've made the regulators optional exactly for boards like these,
> where there is no regulator. Likely the Vbus is simply wired
> directly to the 5V DC-in jack. So IMHO adding something like
> the fixed reg_vcc5v0 a supply here just makes the dt
> harder to read.
It also makes the regulator tree more complete and accurate because
you'd list all the devices that are needing those regulators. That
would also make it easier to deal with in the future.
But fair enough.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/1] ARM: dts: enable GPIO-b for Broadcom NSP
From: Yendapally Reddy Dhananjaya Reddy @ 2016-11-14 13:30 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason
Cc: bcm-kernel-feedback-list, devicetree, linux-arm-kernel,
linux-kernel, Yendapally Reddy Dhananjaya Reddy
This enables the GPIO-b support for Broadcom NSP SoC
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 7c9e0fa..2f699a0 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -241,6 +241,16 @@
brcm,nand-has-wp;
};
+ gpiob: gpio@30000 {
+ compatible = "brcm,iproc-nsp-gpio", "brcm,iproc-gpio";
+ reg = <0x30000 0x50>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ ngpios = <4>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
pwm: pwm@31000 {
compatible = "brcm,iproc-pwm";
reg = <0x31000 0x28>;
--
2.1.0
^ permalink raw reply related
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