* [PATCH v7 01/13] dt-bindings: mediatek: Add property to mt8183 smi-common
From: Weiyi Lu @ 2019-08-28 9:11 UTC (permalink / raw)
To: Nicolas Boichat, Matthias Brugger, Rob Herring
Cc: James Liao, Weiyi Lu, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-1-git-send-email-weiyi.lu@mediatek.com>
For scpsys driver using regmap based syscon driver API.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
.../devicetree/bindings/memory-controllers/mediatek,smi-common.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
index b478ade..01744ec 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -20,7 +20,7 @@ Required properties:
"mediatek,mt2712-smi-common"
"mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
"mediatek,mt8173-smi-common"
- "mediatek,mt8183-smi-common"
+ "mediatek,mt8183-smi-common", "syscon"
- reg : the register and size of the SMI block.
- power-domains : a phandle to the power domain of this local arbiter.
- clocks : Must contain an entry for each entry in clock-names.
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 08/13] soc: mediatek: Add basic_clk_id to scp_power_data
From: Weiyi Lu @ 2019-08-28 9:11 UTC (permalink / raw)
To: Nicolas Boichat, Matthias Brugger, Rob Herring
Cc: James Liao, Weiyi Lu, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-1-git-send-email-weiyi.lu@mediatek.com>
Try to stop extending the clk_id or clk_names if there are
more and more new BASIC clocks. To get its own clocks by the
basic_clk_id of each power domain.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
drivers/soc/mediatek/mtk-scpsys.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index fb2b027..d31e1a4 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -117,6 +117,8 @@ enum clk_id {
* @sram_pdn_ack_bits: The mask for sram power control acked bits.
* @bus_prot_mask: The mask for single step bus protection.
* @clk_id: The basic clocks required by this power domain.
+ * @basic_clk_id: provide the same purpose with field "clk_id"
+ * by declaring basic clock prefix name rather than clk_id.
* @caps: The flag for active wake-up action.
*/
struct scp_domain_data {
@@ -127,6 +129,7 @@ struct scp_domain_data {
u32 sram_pdn_ack_bits;
u32 bus_prot_mask;
enum clk_id clk_id[MAX_CLKS];
+ const char *basic_clk_id[MAX_CLKS];
u8 caps;
};
@@ -490,16 +493,26 @@ static struct scp *init_scp(struct platform_device *pdev,
scpd->data = data;
- for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
- struct clk *c = clk[data->clk_id[j]];
+ if (data->clk_id[0]) {
+ WARN_ON(data->basic_clk_id[0]);
- if (IS_ERR(c)) {
- dev_err(&pdev->dev, "%s: clk unavailable\n",
- data->name);
- return ERR_CAST(c);
- }
+ for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
+ struct clk *c = clk[data->clk_id[j]];
+
+ if (IS_ERR(c)) {
+ dev_err(&pdev->dev,
+ "%s: clk unavailable\n",
+ data->name);
+ return ERR_CAST(c);
+ }
- scpd->clk[j] = c;
+ scpd->clk[j] = c;
+ }
+ } else if (data->basic_clk_id[0]) {
+ for (j = 0; j < MAX_CLKS &&
+ data->basic_clk_id[j]; j++)
+ scpd->clk[j] = devm_clk_get(&pdev->dev,
+ data->basic_clk_id[j]);
}
genpd->name = data->name;
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 10/13] soc: mediatek: Add subsys clock control for bus protection
From: Weiyi Lu @ 2019-08-28 9:11 UTC (permalink / raw)
To: Nicolas Boichat, Matthias Brugger, Rob Herring
Cc: James Liao, Weiyi Lu, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-1-git-send-email-weiyi.lu@mediatek.com>
Add subsys CG control flow before/after the bus protect control
due to bus protection need SMI bus relative CGs enabled to feedback
its ack.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
drivers/soc/mediatek/mtk-scpsys.c | 72 +++++++++++++++++++++++++++++++++++++--
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index f25101f..33c4034 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -108,6 +108,7 @@ enum clk_id {
};
#define MAX_CLKS 3
+#define MAX_SUBSYS_CLKS 10
/**
* struct scp_domain_data - scp domain data for power on/off flow
@@ -120,6 +121,8 @@ enum clk_id {
* @clk_id: The basic clocks required by this power domain.
* @basic_clk_id: provide the same purpose with field "clk_id"
* by declaring basic clock prefix name rather than clk_id.
+ * @subsys_clk_prefix: The prefix name of the clocks need to be enabled
+ * before releasing bus protection.
* @caps: The flag for active wake-up action.
* @bp_table: The mask table for multiple step bus protection.
*/
@@ -132,6 +135,7 @@ struct scp_domain_data {
u32 bus_prot_mask;
enum clk_id clk_id[MAX_CLKS];
const char *basic_clk_id[MAX_CLKS];
+ const char *subsys_clk_prefix;
u8 caps;
struct bus_prot bp_table[MAX_STEPS];
};
@@ -142,6 +146,7 @@ struct scp_domain {
struct generic_pm_domain genpd;
struct scp *scp;
struct clk *clk[MAX_CLKS];
+ struct clk *subsys_clk[MAX_SUBSYS_CLKS];
const struct scp_domain_data *data;
struct regulator *supply;
};
@@ -347,16 +352,22 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
val |= PWR_RST_B_BIT;
writel(val, ctl_addr);
- ret = scpsys_sram_enable(scpd, ctl_addr);
+ ret = scpsys_clk_enable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
if (ret < 0)
goto err_pwr_ack;
+ ret = scpsys_sram_enable(scpd, ctl_addr);
+ if (ret < 0)
+ goto err_sram;
+
ret = scpsys_bus_protect_disable(scpd);
if (ret < 0)
- goto err_pwr_ack;
+ goto err_sram;
return 0;
+err_sram:
+ scpsys_clk_disable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
err_pwr_ack:
scpsys_clk_disable(scpd->clk, MAX_CLKS);
err_clk:
@@ -383,6 +394,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
if (ret < 0)
goto out;
+ scpsys_clk_disable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
+
/* subsys power off */
val = readl(ctl_addr) | PWR_ISO_BIT;
writel(val, ctl_addr);
@@ -419,6 +432,48 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
return ret;
}
+static int init_subsys_clks(struct platform_device *pdev,
+ const char *prefix, struct clk **clk)
+{
+ struct device_node *node = pdev->dev.of_node;
+ u32 prefix_len, sub_clk_cnt = 0;
+ struct property *prop;
+ const char *clk_name;
+
+ if (!node) {
+ dev_err(&pdev->dev, "Cannot find scpsys node: %ld\n",
+ PTR_ERR(node));
+ return PTR_ERR(node);
+ }
+
+ prefix_len = strlen(prefix);
+
+ of_property_for_each_string(node, "clock-names", prop, clk_name) {
+ if (!strncmp(clk_name, prefix, prefix_len) &&
+ (clk_name[prefix_len] == '-')) {
+ if (sub_clk_cnt >= MAX_SUBSYS_CLKS) {
+ dev_err(&pdev->dev,
+ "subsys clk out of range %d\n",
+ sub_clk_cnt);
+ return -ENOMEM;
+ }
+
+ clk[sub_clk_cnt] = devm_clk_get(&pdev->dev,
+ clk_name);
+
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev,
+ "Subsys clk read fail %ld\n",
+ PTR_ERR(clk));
+ return PTR_ERR(clk);
+ }
+ sub_clk_cnt++;
+ }
+ }
+
+ return sub_clk_cnt;
+}
+
static void init_clks(struct platform_device *pdev, struct clk **clk)
{
int i;
@@ -506,6 +561,7 @@ static struct scp *init_scp(struct platform_device *pdev,
struct scp_domain *scpd = &scp->domains[i];
struct generic_pm_domain *genpd = &scpd->genpd;
const struct scp_domain_data *data = &scp_domain_data[i];
+ int clk_cnt;
pd_data->domains[i] = genpd;
scpd->scp = scp;
@@ -534,6 +590,18 @@ static struct scp *init_scp(struct platform_device *pdev,
data->basic_clk_id[j]);
}
+ if (data->subsys_clk_prefix) {
+ clk_cnt = init_subsys_clks(pdev,
+ data->subsys_clk_prefix,
+ scpd->subsys_clk);
+ if (clk_cnt < 0) {
+ dev_err(&pdev->dev,
+ "%s: subsys clk unavailable\n",
+ data->name);
+ return ERR_PTR(clk_cnt);
+ }
+ }
+
genpd->name = data->name;
genpd->power_off = scpsys_power_off;
genpd->power_on = scpsys_power_on;
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 06/13] soc: mediatek: Refactor sram control
From: Weiyi Lu @ 2019-08-28 9:11 UTC (permalink / raw)
To: Nicolas Boichat, Matthias Brugger, Rob Herring
Cc: James Liao, Weiyi Lu, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-1-git-send-email-weiyi.lu@mediatek.com>
Put sram enable and disable control in separate functions.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
---
drivers/soc/mediatek/mtk-scpsys.c | 79 +++++++++++++++++++++++++--------------
1 file changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index 73e4a1a..ad0f619 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -230,12 +230,55 @@ static int scpsys_clk_enable(struct clk *clk[], int max_num)
return ret;
}
+static int scpsys_sram_enable(struct scp_domain *scpd, void __iomem *ctl_addr)
+{
+ u32 val;
+ u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
+ int tmp;
+
+ val = readl(ctl_addr) & ~scpd->data->sram_pdn_bits;
+ writel(val, ctl_addr);
+
+ /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
+ if (MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
+ /*
+ * Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
+ * MT7622_POWER_DOMAIN_WB and thus just a trivial setup
+ * is applied here.
+ */
+ usleep_range(12000, 12100);
+ } else {
+ /* Either wait until SRAM_PDN_ACK all 1 or 0 */
+ int ret = readl_poll_timeout(ctl_addr, tmp,
+ (tmp & pdn_ack) == 0,
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem *ctl_addr)
+{
+ u32 val;
+ u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
+ int tmp;
+
+ val = readl(ctl_addr) | scpd->data->sram_pdn_bits;
+ writel(val, ctl_addr);
+
+ /* Either wait until SRAM_PDN_ACK all 1 or 0 */
+ return readl_poll_timeout(ctl_addr, tmp,
+ (tmp & pdn_ack) == pdn_ack,
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+}
+
static int scpsys_power_on(struct generic_pm_domain *genpd)
{
struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
struct scp *scp = scpd->scp;
void __iomem *ctl_addr = scp->base + scpd->data->ctl_offs;
- u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
u32 val;
int ret, tmp;
@@ -247,6 +290,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
if (ret)
goto err_clk;
+ /* subsys power on */
val = readl(ctl_addr);
val |= PWR_ON_BIT;
writel(val, ctl_addr);
@@ -268,24 +312,9 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
val |= PWR_RST_B_BIT;
writel(val, ctl_addr);
- val &= ~scpd->data->sram_pdn_bits;
- writel(val, ctl_addr);
-
- /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
- if (MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
- /*
- * Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
- * MT7622_POWER_DOMAIN_WB and thus just a trivial setup is
- * applied here.
- */
- usleep_range(12000, 12100);
-
- } else {
- ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
- if (ret < 0)
- goto err_pwr_ack;
- }
+ ret = scpsys_sram_enable(scpd, ctl_addr);
+ if (ret < 0)
+ goto err_pwr_ack;
if (scpd->data->bus_prot_mask) {
ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
@@ -312,7 +341,6 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
struct scp *scp = scpd->scp;
void __iomem *ctl_addr = scp->base + scpd->data->ctl_offs;
- u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
u32 val;
int ret, tmp;
@@ -324,17 +352,12 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
goto out;
}
- val = readl(ctl_addr);
- val |= scpd->data->sram_pdn_bits;
- writel(val, ctl_addr);
-
- /* wait until SRAM_PDN_ACK all 1 */
- ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == pdn_ack,
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+ ret = scpsys_sram_disable(scpd, ctl_addr);
if (ret < 0)
goto out;
- val |= PWR_ISO_BIT;
+ /* subsys power off */
+ val = readl(ctl_addr) | PWR_ISO_BIT;
writel(val, ctl_addr);
val &= ~PWR_RST_B_BIT;
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 04/13] soc: mediatek: Refactor regulator control
From: Weiyi Lu @ 2019-08-28 9:11 UTC (permalink / raw)
To: Nicolas Boichat, Matthias Brugger, Rob Herring
Cc: James Liao, Weiyi Lu, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-1-git-send-email-weiyi.lu@mediatek.com>
Put regulator enable and disable control in separate functions.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
drivers/soc/mediatek/mtk-scpsys.c | 32 +++++++++++++++++++++++---------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index e97fc0e..aed540d 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -191,6 +191,22 @@ static int scpsys_domain_is_on(struct scp_domain *scpd)
return -EINVAL;
}
+static int scpsys_regulator_enable(struct scp_domain *scpd)
+{
+ if (!scpd->supply)
+ return 0;
+
+ return regulator_enable(scpd->supply);
+}
+
+static int scpsys_regulator_disable(struct scp_domain *scpd)
+{
+ if (!scpd->supply)
+ return 0;
+
+ return regulator_disable(scpd->supply);
+}
+
static int scpsys_power_on(struct generic_pm_domain *genpd)
{
struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
@@ -201,11 +217,9 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
int ret, tmp;
int i;
- if (scpd->supply) {
- ret = regulator_enable(scpd->supply);
- if (ret)
- return ret;
- }
+ ret = scpsys_regulator_enable(scpd);
+ if (ret < 0)
+ return ret;
for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++) {
ret = clk_prepare_enable(scpd->clk[i]);
@@ -273,8 +287,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
clk_disable_unprepare(scpd->clk[i]);
}
err_clk:
- if (scpd->supply)
- regulator_disable(scpd->supply);
+ scpsys_regulator_disable(scpd);
dev_err(scp->dev, "Failed to power on domain %s\n", genpd->name);
@@ -333,8 +346,9 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++)
clk_disable_unprepare(scpd->clk[i]);
- if (scpd->supply)
- regulator_disable(scpd->supply);
+ ret = scpsys_regulator_disable(scpd);
+ if (ret < 0)
+ goto out;
return 0;
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/6] PCI: tegra: Enable PCIe C5 controller of Tegra194 in p2972-0000 platform
From: Thierry Reding @ 2019-08-28 9:10 UTC (permalink / raw)
To: Vidya Sagar
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, kishon, linux-tegra, robh+dt,
linux-pci, bhelgaas, digetx, jonathanh, linux-arm-kernel,
sagar.tv
In-Reply-To: <20190826073143.4582-1-vidyas@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]
On Mon, Aug 26, 2019 at 01:01:37PM +0530, Vidya Sagar wrote:
> This patch series enables Tegra194's C5 controller which owns x16 slot in
> p2972-0000 platform. C5 controller's PERST# and CLKREQ# are not configured as
> output and bi-directional signals by default and hence they need to be
> configured explicitly. Also, x16 slot's 3.3V and 12V supplies are controlled
> through GPIOs and hence they need to be enabled through regulator framework.
> This patch series adds required infrastructural support to address both the
> aforementioned requirements.
> Testing done on p2972-0000 platform
> - Able to enumerate devices connected to x16 slot (owned by C5 controller)
> - Enumerated device's functionality verified
> - Suspend-Resume sequence is verified with device connected to x16 slot
>
> Vidya Sagar (6):
> dt-bindings: PCI: tegra: Add sideband pins configuration entries
> arm64: tegra: Add configuration for PCIe C5 sideband signals
> PCI: tegra: Add support to configure sideband pins
> dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
> arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
> PCI: tegra: Add support to enable slot regulators
Hi Vidya,
when you resend with review comments addressed, can you please reorder
the patches slightly? I think it's more natural to order them like this:
dt-bindings: PCI: tegra: Add sideband pins configuration entries
PCI: tegra: Add support to configure sideband pins
dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
PCI: tegra: Add support to enable slot regulators
arm64: tegra: Add configuration for PCIe C5 sideband signals
arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
Or perhaps even like this:
dt-bindings: PCI: tegra: Add sideband pins configuration entries
dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
PCI: tegra: Add support to configure sideband pins
PCI: tegra: Add support to enable slot regulators
arm64: tegra: Add configuration for PCIe C5 sideband signals
arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
That makes it more obvious that patches 1-2 need an Acked-by from Rob
and patches 1-4 need to go through Lorenzo's tree and that I'll pick up
patches 5-6.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] PCI: tegra: Add support to enable slot regulators
From: Thierry Reding @ 2019-08-28 9:07 UTC (permalink / raw)
To: Andrew Murray
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, Vidya Sagar, linux-kernel, kishon, linux-tegra,
robh+dt, linux-pci, bhelgaas, digetx, jonathanh, linux-arm-kernel,
sagar.tv
In-Reply-To: <20190827171333.GQ14582@e119886-lin.cambridge.arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 4128 bytes --]
On Tue, Aug 27, 2019 at 06:13:34PM +0100, Andrew Murray wrote:
> On Tue, Aug 27, 2019 at 09:54:17PM +0530, Vidya Sagar wrote:
> > On 8/27/2019 9:17 PM, Andrew Murray wrote:
> > > On Mon, Aug 26, 2019 at 01:01:43PM +0530, Vidya Sagar wrote:
> > > > Add support to get regulator information of 3.3V and 12V supplies of a PCIe
> > > > slot from the respective controller's device-tree node and enable those
> > > > supplies. This is required in platforms like p2972-0000 where the supplies
> > > > to x16 slot owned by C5 controller need to be enabled before attempting to
> > > > enumerate the devices.
> > > >
> > > > Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pcie-tegra194.c | 65 ++++++++++++++++++++++
> > > > 1 file changed, 65 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > index 8a27b25893c9..97de2151a738 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > @@ -278,6 +278,8 @@ struct tegra_pcie_dw {
> > > > u32 aspm_l0s_enter_lat;
> > > > struct regulator *pex_ctl_supply;
> > > > + struct regulator *slot_ctl_3v3;
> > > > + struct regulator *slot_ctl_12v;
> > > > unsigned int phy_count;
> > > > struct phy **phys;
> > > > @@ -1047,6 +1049,59 @@ static void tegra_pcie_downstream_dev_to_D0(struct tegra_pcie_dw *pcie)
> > > > }
> > > > }
> > > > +static void tegra_pcie_get_slot_regulators(struct tegra_pcie_dw *pcie)
> > > > +{
> > > > + pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
> > > > + if (IS_ERR(pcie->slot_ctl_3v3))
> > > > + pcie->slot_ctl_3v3 = NULL;
> > > > +
> > > > + pcie->slot_ctl_12v = devm_regulator_get_optional(pcie->dev, "vpcie12v");
> > > > + if (IS_ERR(pcie->slot_ctl_12v))
> > > > + pcie->slot_ctl_12v = NULL;
> > >
> > > Do these need to take into consideration -EPROBE_DEFER?
> > Since these are devm_* APIs, isn't it taken care of automatically?
>
> devm_regulator_get_optional can still return -EPROBE_DEFER - for times when
> "lookup could succeed in the future".
>
> It's probably helpful here for your driver to distinguish between there not
> being a regulator specified in the DT, and there being a regulator but there
> is no device for it yet. For the latter case - your driver would probe but
> nothing would enumerate.
>
> See pcie-rockchip-host.c for an example of where this is handled.
>
> Of course if, for whatever reason it is unlikely you'll ever get -EPROBE_DEFER
> then maybe it's OK as it is.
Let's not assume that. We've just recently encountered a case where we
did not handle -EPROBE_DEFER because we had assumed too much, and that
turned into a bit of a hassle to fix.
Vidya, I think what Andrew is saying is that you need to propagate the
-EPROBE_DEFER error to the caller (i.e. the ->probe() callback) so that
the PCI controller driver can be properly added to the defer queue in
case the regulator isn't ready yet.
I think what we want here is something like:
pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
if (IS_ERR(pcie->slot_ctl_3v3)) {
if (PTR_ERR(pcie->slot_ctl_3v3) != -ENODEV)
return PTR_ERR(pcie->slot_ctl_3v3);
pcie->slot_ctl_3v3 = NULL;
}
Andrew, I'm not sure the handling in rockchip_pcie_parse_host_dt() is
correct. It singles out -EPROBE_DEFER, which I think is the wrong way
around. We should be special-casing -ENODEV, because regulator_get()
can return a wide array of error cases, not all of which we actually
want to consider successes. For example we could be getting -ENOMEM,
which, I would argue, is something that we should propagate. I think
it'd be very confusing to take that as meaning "optional regulator
wasn't specified", because in that case the DTS file would've had the
regulator hooked up (we have to assume that it is needed in that case)
but we won't be enabling it, so it's unlikely that devices will
enumerate.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mmc: mediatek: enable SDIO IRQ low level trigger function
From: Yong Mao @ 2019-08-28 9:07 UTC (permalink / raw)
To: Ulf Hansson
Cc: srv_heupstream, linux-mmc, linux-kernel, yong mao, linux-mediatek,
Chaotian Jing, Matthias Brugger, linux-arm-kernel
From: yong mao <yong.mao@mediatek.com>
SDIO IRQ is not defaultly triggered by low level,
but by falling edge. It needs to set related register
to enable SDIO IRQ low level trigger function.
Otherwise the SDIO IRQ may be lost in some specail condition.
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
---
drivers/mmc/host/mtk-sd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 33f4b63..2444268 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -192,6 +192,7 @@
#define SDC_STS_CMDBUSY (0x1 << 1) /* RW */
#define SDC_STS_SWR_COMPL (0x1 << 31) /* RW */
+#define SDC_DAT1_IRQ_TRIGGER (0x1 << 20) /* RW */
/* SDC_ADV_CFG0 mask */
#define SDC_RX_ENHANCE_EN (0x1 << 20) /* RW */
@@ -1568,6 +1569,7 @@ static void msdc_init_hw(struct msdc_host *host)
/* Config SDIO device detect interrupt function */
sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
+ sdr_set_bits(host->base + SDC_ADV_CFG0, SDC_DAT1_IRQ_TRIGGER);
/* Configure to default data timeout */
sdr_set_field(host->base + SDC_CFG, SDC_CFG_DTOC, 3);
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 0/5] arm64: avoid out-of-line ll/sc atomics
From: Andrew Murray @ 2019-08-28 9:04 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Peter Zijlstra, Catalin Marinas, Boqun Feng,
Will Deacon, Ard.Biesheuvel, linux-arm-kernel
In-Reply-To: <20190827164944.qxk32uas7hx5pjgz@willie-the-truck>
On Tue, Aug 27, 2019 at 05:49:45PM +0100, Will Deacon wrote:
> Hi Andrew,
>
> On Mon, Aug 12, 2019 at 03:36:20PM +0100, Andrew Murray wrote:
> > When building for LSE atomics (CONFIG_ARM64_LSE_ATOMICS), if the hardware
> > or toolchain doesn't support it the existing code will fallback to ll/sc
> > atomics. It achieves this by branching from inline assembly to a function
> > that is built with specical compile flags. Further this results in the
> > clobbering of registers even when the fallback isn't used increasing
> > register pressure.
> >
> > Let's improve this by providing inline implementatins of both LSE and
> > ll/sc and use a static key to select between them. This allows for the
> > compiler to generate better atomics code.
> >
> > Whilst it may be difficult to understand the performance impact, we gain
> > improved code readability, ability to use Clang, and improved backtrace
> > reliability.
> >
> > Build and boot tested, along with atomic_64_test.
>
> I think this series is really close now and I was hoping to get something
> queued for 5.4. Would you be able to respin, addressing Mark's comments
> please? It would be a shame for this to miss another release.
Sure, I'm working on this now.
Thanks,
Andrew Murray
>
> Thanks,
>
> Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Andrew Murray @ 2019-08-28 9:01 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gustavo.pimentel@synopsys.com, jingoohan1@gmail.com,
bhelgaas@google.com, Leo Li, shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB3310F78C86F775BB1F5B7E0CF5A30@VI1PR04MB3310.eurprd04.prod.outlook.com>
On Wed, Aug 28, 2019 at 04:29:32AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年8月27日 21:34
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for
> > ls1088a and ls2088a
> >
> > On Mon, Aug 26, 2019 at 09:49:35AM +0000, Xiaowei Bao wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Andrew Murray <andrew.murray@arm.com>
> > > > Sent: 2019年8月23日 22:28
> > > > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > > > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > > > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org;
> > M.h.
> > > > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > > > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > > > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > > > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support
> > > > for ls1088a and ls2088a
> > > >
> > > > On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
> > > > > Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > > > > difference between LS1 and LS2 platform, so refactor the code of
> > > > > the EP driver.
> > > > >
> > > > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > > ---
> > > > > v2:
> > > > > - New mechanism for layerscape EP driver.
> > > >
> > > > Was there a v1 of this patch?
> > > >
> > > > >
> > > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 76
> > > > > ++++++++++++++++++++------
> > > > > 1 file changed, 58 insertions(+), 18 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > index 7ca5fe8..2a66f07 100644
> > > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > @@ -20,27 +20,29 @@
> > > > >
> > > > > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > > > >
> > > > > -struct ls_pcie_ep {
> > > > > - struct dw_pcie *pci;
> > > > > - struct pci_epc_features *ls_epc;
> > > > > +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > +
> > > > > +struct ls_pcie_ep_drvdata {
> > > > > + u32 func_offset;
> > > > > + const struct dw_pcie_ep_ops *ops;
> > > > > + const struct dw_pcie_ops *dw_pcie_ops;
> > > > > };
> > > > >
> > > > > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > +struct ls_pcie_ep {
> > > > > + struct dw_pcie *pci;
> > > > > + struct pci_epc_features *ls_epc;
> > > > > + const struct ls_pcie_ep_drvdata *drvdata; };
> > > > >
> > > > > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > > > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > > > .start_link = ls_pcie_establish_link, };
> > > > >
> > > > > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > > - { .compatible = "fsl,ls-pcie-ep",},
> > > > > - { },
> > > > > -};
> > > > > -
> > > > > static const struct pci_epc_features*
> > > > > ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -82,10 +84,44
> > > > > @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > > > }
> > > > > }
> > > > >
> > > > > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > > > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> > *ep,
> > > > > + u8 func_no)
> > > > > +{
> > > > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > > > + u8 header_type;
> > > > > +
> > > > > + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > > > > +
> > > > > + if (header_type & (1 << 7))
> > > > > + return pcie->drvdata->func_offset * func_no;
> > > > > + else
> > > > > + return 0;
> > > >
> > > > It looks like there isn't a PCI define for multi function, the
> > > > nearest I could find was PCI_HEADER_TYPE_MULTIDEVICE in
> > > > hotplug/ibmphp.h. A comment above the test might be helpful to explain
> > the test.
> > >
> > > OK, I will add a comment above this code.
> > >
> > > >
> > > > As the ls_pcie_ep_drvdata structures are static, the unset
> > > > .func_offset will be initialised to 0, so you could just drop the test above.
> > >
> > > Due to the different PCIe controller have different property, e.g.
> > > PCIe controller1 support multiple function feature, but PCIe
> > > controller2 don't support this feature, so I need to check which
> > > controller support it and return the correct offset value, but each board only
> > have one ls_pcie_ep_drvdata, ^_^.
> >
> > Yes but if they don't support the feature then func_offset will be 0.
> >
> > >
> > > >
> > > > However something to the effect of the following may help spot
> > > > misconfiguration:
> > > >
> > > > WARN_ON(func_no && !pcie->drvdata->func_offset); return
> > > > pcie->drvdata->func_offset * func_no;
> > > >
> > > > The WARN is probably quite useful as if you are attempting to use
> > > > non-zero functions and func_offset isn't set - then things may
> > > > appear to work normally but actually will break horribly.
> > >
> > > As discussion before, I think the func_offset should not depends on
> > > the function number, even if other platforms of NXP may be use write
> > > registers way to access the different function config space.
> >
> > I agree that func_offset is an optional parameter. But if you are attempting to
> > determine the offset of a function and you are given a non-zero function
> > number - then something has gone wrong if func_offset is 0.
>
> I have understood you means, maybe I need to set a flag in the driver_data struct,
> because I may add other platform of NXP, these platform use the write register
> method to access different function, e.g.
> write func_num to register, then we can access this func_num config space.
>
> I will modify the code like this? Do you have better advice?
> Case1:
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index 004a7e8..8a0d6df 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -23,6 +23,7 @@
> #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
>
> struct ls_pcie_ep_drvdata {
> + u8 func_config_flag;
> u32 func_offset;
> const struct dw_pcie_ep_ops *ops;
> const struct dw_pcie_ops *dw_pcie_ops;
> @@ -97,8 +98,14 @@ static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> * Read the Header Type register of config space to check
> * whether this PCI device support the multiple function.
> */
> - if (header_type & (1 << 7))
> - return pcie->drvdata->func_offset * func_no;
> + if (header_type & (1 << 7)) {
> + if (pcie->drvdata->func_config_flag) {
> + iowrite32((func_num << n), pci->dbi_base + PCI_XXXX_XXX);
> + } else {
> + WARN_ON(func_no && !pcie->drvdata->func_offset);
> + return pcie->drvdata->func_offset * func_no;
> + }
> + }
>
> return 0;
> }
>
> Of course, I don't need to set the flag this time, because I don't use the second method(write
> register method), so the code like this:
> case2:
> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> u8 func_no) {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> u8 header_type;
>
> of course, this code is not requied, due to the
> pcie->drvdata->func_offset is 0, but I think this is more clear
> if use this code.
> header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
>
> /*
> * Read the Header Type register of config space to check
> * whether this PCI device support the multiple function.
> */
> if (header_type & (1 << 7)) {
> WARN_ON(func_no && !pcie->drvdata->func_offset);
> return pcie->drvdata->func_offset * func_no;
> }
>
> return 0;
> }
>
> Or like this:
> Case3:
> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> u8 func_no) {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
>
> WARN_ON(func_no && !pcie->drvdata->func_offset);
> return pcie->drvdata->func_offset * func_no;
This is better. Given there is only currently one method of calculating
an offset for layerscape, I'd recommend you add additional methods when
the need arises.
Thanks,
Andrew Murray
>
> }
> Of course, we can return a -1 by adjuring the (func_no && !pcie->drvdata->func_offset)
> Valu in case1
>
> Thanks
> Xiaowei
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > >
> > > I have added the comments above the code, as follow, do you have any
> > advice?
> > > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> > > + u8 func_no) {
> > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > + u8 header_type;
> > > +
> > > + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > > +
> > > + /*
> > > + * Read the Header Type register of config space to check
> > > + * whether this PCI device support the multiple function.
> > > + */
> > > + if (header_type & (1 << 7))
> > > + return pcie->drvdata->func_offset * func_no;
> > > +
> > > + return 0;
> > > +}
> > >
> > > Thanks a lot for your detail comments.
> > >
> > > >
> > > > Thanks,
> > > >
> > > > Andrew Murray
> > > >
> > > > > +}
> > > > > +
> > > > > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > > > > .ep_init = ls_pcie_ep_init,
> > > > > .raise_irq = ls_pcie_ep_raise_irq,
> > > > > .get_features = ls_pcie_ep_get_features,
> > > > > + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > > > > +
> > > > > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > > > > + .ops = &ls_pcie_ep_ops,
> > > > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > > > > +
> > > > > +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > > > > + .func_offset = 0x20000,
> > > > > + .ops = &ls_pcie_ep_ops,
> > > > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > > > > +
> > > > > +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > > + { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
> > > > > + { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
> > > > > + { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
> > > > > + { },
> > > > > };
> > > > >
> > > > > static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@
> > > > > -98,7
> > > > > +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep
> > > > > +*pcie,
> > > > > int ret;
> > > > >
> > > > > ep = &pci->ep;
> > > > > - ep->ops = &pcie_ep_ops;
> > > > > + ep->ops = pcie->drvdata->ops;
> > > > >
> > > > > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > > > "addr_space");
> > > > > if (!res)
> > > > > @@ -137,14 +173,11 @@ static int __init ls_pcie_ep_probe(struct
> > > > platform_device *pdev)
> > > > > if (!ls_epc)
> > > > > return -ENOMEM;
> > > > >
> > > > > - dbi_base = platform_get_resource_byname(pdev,
> > IORESOURCE_MEM,
> > > > "regs");
> > > > > - pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > > > > - if (IS_ERR(pci->dbi_base))
> > > > > - return PTR_ERR(pci->dbi_base);
> > > > > + pcie->drvdata = of_device_get_match_data(dev);
> > > > >
> > > > > - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > > > pci->dev = dev;
> > > > > - pci->ops = &ls_pcie_ep_ops;
> > > > > + pci->ops = pcie->drvdata->dw_pcie_ops;
> > > > > +
> > > > > pcie->pci = pci;
> > > > >
> > > > > ls_epc->linkup_notifier = false, @@ -152,6 +185,13 @@ static int
> > > > > __init ls_pcie_ep_probe(struct platform_device *pdev)
> > > > >
> > > > > pcie->ls_epc = ls_epc;
> > > > >
> > > > > + dbi_base = platform_get_resource_byname(pdev,
> > IORESOURCE_MEM,
> > > > "regs");
> > > > > + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > > > > + if (IS_ERR(pci->dbi_base))
> > > > > + return PTR_ERR(pci->dbi_base);
> > > > > +
> > > > > + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > > > +
> > > > > platform_set_drvdata(pdev, pcie);
> > > > >
> > > > > ret = ls_add_pcie_ep(pcie, pdev);
> > > > > --
> > > > > 2.9.5
> > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/6] arm: dts: Change PCIe INTx mapping for NSP
From: Srinath Mannam @ 2019-08-28 8:54 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Mark Rutland,
Andy Shevchenko, Arnd Bergmann
Cc: devicetree, linux-pci, Srinath Mannam, linux-kernel, Ray Jui,
bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
From: Ray Jui <ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 45 ++++++++++++++++++++++++++++++++++++------
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 6925b30..0e28817 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -532,8 +532,11 @@
reg = <0x18012000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0_intc 1>,
+ <0 0 0 2 &pcie0_intc 2>,
+ <0 0 0 3 &pcie0_intc 3>,
+ <0 0 0 4 &pcie0_intc 4>;
linux,pci-domain = <0>;
@@ -562,6 +565,14 @@
<GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
brcm,pcie-msi-inten;
};
+
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
pcie1: pcie@18013000 {
@@ -569,8 +580,11 @@
reg = <0x18013000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1_intc 1>,
+ <0 0 0 2 &pcie1_intc 2>,
+ <0 0 0 3 &pcie1_intc 3>,
+ <0 0 0 4 &pcie1_intc 4>;
linux,pci-domain = <1>;
@@ -599,6 +613,14 @@
<GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
brcm,pcie-msi-inten;
};
+
+ pcie1_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
pcie2: pcie@18014000 {
@@ -606,8 +628,11 @@
reg = <0x18014000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie2_intc 1>,
+ <0 0 0 2 &pcie2_intc 2>,
+ <0 0 0 3 &pcie2_intc 3>,
+ <0 0 0 4 &pcie2_intc 4>;
linux,pci-domain = <2>;
@@ -636,6 +661,14 @@
<GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
brcm,pcie-msi-inten;
};
+
+ pcie2_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
thermal-zones {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/6] PCI: iproc: Add INTx support with better modeling
From: Srinath Mannam @ 2019-08-28 8:54 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Mark Rutland,
Andy Shevchenko, Arnd Bergmann
Cc: devicetree, linux-pci, Srinath Mannam, linux-kernel, Ray Jui,
bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
From: Ray Jui <ray.jui@broadcom.com>
Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
INTD share the same interrupt line connected to the GIC in the system,
while the status of each INTx can be obtained through the INTX CSR
register
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
---
drivers/pci/controller/pcie-iproc.c | 100 +++++++++++++++++++++++++++++++++++-
drivers/pci/controller/pcie-iproc.h | 6 +++
2 files changed, 104 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
index e3ca464..f8edd28 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -14,6 +14,7 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/irqchip/arm-gic-v3.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/platform_device.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
@@ -270,6 +271,7 @@ enum iproc_pcie_reg {
/* enable INTx */
IPROC_PCIE_INTX_EN,
+ IPROC_PCIE_INTX_CSR,
/* outbound address mapping */
IPROC_PCIE_OARR0,
@@ -314,6 +316,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_LINK_STATUS] = 0xf0c,
};
@@ -325,6 +328,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_OARR0] = 0xd20,
[IPROC_PCIE_OMAP0] = 0xd40,
[IPROC_PCIE_OARR1] = 0xd28,
@@ -341,6 +345,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_OARR0] = 0xd20,
[IPROC_PCIE_OMAP0] = 0xd40,
[IPROC_PCIE_OARR1] = 0xd28,
@@ -846,9 +851,95 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
return link_is_active ? 0 : -ENODEV;
}
-static void iproc_pcie_enable(struct iproc_pcie *pcie)
+static int iproc_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
+ irq_hw_number_t hwirq)
{
+ irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_simple_irq);
+ irq_set_chip_data(irq, domain->host_data);
+
+ return 0;
+}
+
+static const struct irq_domain_ops intx_domain_ops = {
+ .map = iproc_pcie_intx_map,
+};
+
+static void iproc_pcie_isr(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct iproc_pcie *pcie;
+ struct device *dev;
+ unsigned long status;
+ u32 bit, virq;
+
+ chained_irq_enter(chip, desc);
+ pcie = irq_desc_get_handler_data(desc);
+ dev = pcie->dev;
+
+ /* go through INTx A, B, C, D until all interrupts are handled */
+ do {
+ status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR);
+ for_each_set_bit(bit, &status, PCI_NUM_INTX) {
+ virq = irq_find_mapping(pcie->irq_domain, bit + 1);
+ if (virq)
+ generic_handle_irq(virq);
+ else
+ dev_err(dev, "unexpected INTx%u\n", bit);
+ }
+ } while ((status & SYS_RC_INTX_MASK) != 0);
+
+ chained_irq_exit(chip, desc);
+}
+
+static int iproc_pcie_intx_enable(struct iproc_pcie *pcie)
+{
+ struct device *dev = pcie->dev;
+ struct device_node *node;
+ int ret;
+
iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, SYS_RC_INTX_MASK);
+ /*
+ * BCMA devices do not map INTx the same way as platform devices. All
+ * BCMA needs is the above code to enable INTx
+ */
+
+ node = of_get_compatible_child(dev->of_node, "brcm,iproc-intc");
+ if (node)
+ pcie->irq = of_irq_get(node, 0);
+
+ if (!node || pcie->irq <= 0)
+ return 0;
+
+ /* set IRQ handler */
+ irq_set_chained_handler_and_data(pcie->irq, iproc_pcie_isr, pcie);
+
+ /* add IRQ domain for INTx */
+ pcie->irq_domain = irq_domain_add_linear(node, PCI_NUM_INTX + 1,
+ &intx_domain_ops, pcie);
+ if (!pcie->irq_domain) {
+ dev_err(dev, "failed to add INTx IRQ domain\n");
+ ret = -ENOMEM;
+ goto err_rm_handler_data;
+ }
+
+ return 0;
+
+err_rm_handler_data:
+ of_node_put(node);
+ irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
+
+ return ret;
+}
+
+static void iproc_pcie_intx_disable(struct iproc_pcie *pcie)
+{
+ iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, 0x0);
+
+ if (pcie->irq <= 0)
+ return;
+
+ irq_domain_remove(pcie->irq_domain);
+ irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
}
static inline bool iproc_pcie_ob_is_valid(struct iproc_pcie *pcie,
@@ -1537,7 +1628,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
goto err_power_off_phy;
}
- iproc_pcie_enable(pcie);
+ ret = iproc_pcie_intx_enable(pcie);
+ if (ret) {
+ dev_err(dev, "failed to enable INTx\n");
+ goto err_power_off_phy;
+ }
if (IS_ENABLED(CONFIG_PCI_MSI))
if (iproc_pcie_msi_enable(pcie))
@@ -1582,6 +1677,7 @@ int iproc_pcie_remove(struct iproc_pcie *pcie)
pci_remove_root_bus(pcie->root_bus);
iproc_pcie_msi_disable(pcie);
+ iproc_pcie_intx_disable(pcie);
phy_power_off(pcie->phy);
phy_exit(pcie->phy);
diff --git a/drivers/pci/controller/pcie-iproc.h b/drivers/pci/controller/pcie-iproc.h
index 4f03ea5..103e568 100644
--- a/drivers/pci/controller/pcie-iproc.h
+++ b/drivers/pci/controller/pcie-iproc.h
@@ -74,6 +74,9 @@ struct iproc_msi;
* @ib: inbound mapping related parameters
* @ib_map: outbound mapping region related parameters
*
+ * @irq: interrupt line wired to the generic GIC for INTx
+ * @irq_domain: IRQ domain for INTx
+ *
* @need_msi_steer: indicates additional configuration of the iProc PCIe
* controller is required to steer MSI writes to external interrupt controller
* @msi: MSI data
@@ -102,6 +105,9 @@ struct iproc_pcie {
struct iproc_pcie_ib ib;
const struct iproc_pcie_ib_map *ib_map;
+ int irq;
+ struct irq_domain *irq_domain;
+
bool need_msi_steer;
struct iproc_msi *msi;
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/6] arm64: dts: Change PCIe INTx mapping for NS2
From: Srinath Mannam @ 2019-08-28 8:54 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Mark Rutland,
Andy Shevchenko, Arnd Bergmann
Cc: devicetree, linux-pci, Srinath Mannam, linux-kernel, Ray Jui,
bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
From: Ray Jui <ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 28 ++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index 15f7b0e..d639928 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -117,8 +117,11 @@
dma-coherent;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 281 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0_intc 1>,
+ <0 0 0 2 &pcie0_intc 2>,
+ <0 0 0 3 &pcie0_intc 3>,
+ <0 0 0 4 &pcie0_intc 4>;
linux,pci-domain = <0>;
@@ -140,6 +143,13 @@
phy-names = "pcie-phy";
msi-parent = <&v2m0>;
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 281 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
pcie4: pcie@50020000 {
@@ -148,8 +158,11 @@
dma-coherent;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie4_intc 1>,
+ <0 0 0 2 &pcie4_intc 2>,
+ <0 0 0 3 &pcie4_intc 3>,
+ <0 0 0 4 &pcie4_intc 4>;
linux,pci-domain = <4>;
@@ -171,6 +184,13 @@
phy-names = "pcie-phy";
msi-parent = <&v2m0>;
+ pcie4_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
pcie8: pcie@60c00000 {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/6] arm: dts: Change PCIe INTx mapping for HR2
From: Srinath Mannam @ 2019-08-28 8:54 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Mark Rutland,
Andy Shevchenko, Arnd Bergmann
Cc: devicetree, linux-pci, Srinath Mannam, linux-kernel, Ray Jui,
bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
From: Ray Jui <ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
---
arch/arm/boot/dts/bcm-hr2.dtsi | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
index e4d4973..eb449d0 100644
--- a/arch/arm/boot/dts/bcm-hr2.dtsi
+++ b/arch/arm/boot/dts/bcm-hr2.dtsi
@@ -299,8 +299,11 @@
reg = <0x18012000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0_intc 1>,
+ <0 0 0 2 &pcie0_intc 2>,
+ <0 0 0 3 &pcie0_intc 3>,
+ <0 0 0 4 &pcie0_intc 4>;
linux,pci-domain = <0>;
@@ -328,6 +331,14 @@
<GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
brcm,pcie-msi-inten;
};
+
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
pcie1: pcie@18013000 {
@@ -335,8 +346,11 @@
reg = <0x18013000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1_intc 1>,
+ <0 0 0 2 &pcie1_intc 2>,
+ <0 0 0 3 &pcie1_intc 3>,
+ <0 0 0 4 &pcie1_intc 4>;
linux,pci-domain = <1>;
@@ -364,5 +378,13 @@
<GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>;
brcm,pcie-msi-inten;
};
+
+ pcie1_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/6] arm: dts: Change PCIe INTx mapping for Cygnus
From: Srinath Mannam @ 2019-08-28 8:54 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Mark Rutland,
Andy Shevchenko, Arnd Bergmann
Cc: devicetree, linux-pci, Srinath Mannam, linux-kernel, Ray Jui,
bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
From: Ray Jui <ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5f7b465..9d3d9ef 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -264,8 +264,11 @@
reg = <0x18012000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0_intc 1>,
+ <0 0 0 2 &pcie0_intc 2>,
+ <0 0 0 3 &pcie0_intc 3>,
+ <0 0 0 4 &pcie0_intc 4>;
linux,pci-domain = <0>;
@@ -292,6 +295,14 @@
<GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
pcie1: pcie@18013000 {
@@ -299,8 +310,11 @@
reg = <0x18013000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1_intc 1>,
+ <0 0 0 2 &pcie1_intc 2>,
+ <0 0 0 3 &pcie1_intc 3>,
+ <0 0 0 4 &pcie1_intc 4>;
linux,pci-domain = <1>;
@@ -327,6 +341,14 @@
<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ pcie1_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
dma0: dma@18018000 {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/6] dt-bindings: pci: Update iProc PCI binding for INTx support
From: Srinath Mannam @ 2019-08-28 8:54 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Mark Rutland,
Andy Shevchenko, Arnd Bergmann
Cc: devicetree, linux-pci, Srinath Mannam, linux-kernel, Ray Jui,
bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
From: Ray Jui <ray.jui@broadcom.com>
Update the iProc PCIe binding document for better modeling of the legacy
interrupt (INTx) support
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
---
.../devicetree/bindings/pci/brcm,iproc-pcie.txt | 48 ++++++++++++++++++----
1 file changed, 41 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index df065aa..f23decb 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -13,9 +13,6 @@ controller, used in Stingray
PAXB-based root complex is used for external endpoint devices. PAXC-based
root complex is connected to emulated endpoint devices internal to the ASIC
- reg: base address and length of the PCIe controller I/O register space
-- #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map, standard PCI properties to define the
- mapping of the PCIe interface to interrupt numbers
- linux,pci-domain: PCI domain ID. Should be unique for each host controller
- bus-range: PCI bus numbers covered
- #address-cells: set to <3>
@@ -41,6 +38,21 @@ Required:
- brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal
address used by the iProc PCIe core (not the PCIe address)
+Legacy interrupt (INTx) support (optional):
+
+Note INTx is for PAXB only.
+- interrupt-map-mask and interrupt-map, standard PCI properties to define
+the mapping of the PCIe interface to interrupt numbers
+
+In addition, a sub-node that describes the legacy interrupt controller built
+into the PCIe controller.
+This sub-node must have the following properties:
+ - compatible: must be "brcm,iproc-intc"
+ - interrupt-controller: claims itself as an interrupt controller for INTx
+ - #interrupt-cells: set to <1>
+ - interrupts: interrupt line wired to the generic GIC for INTx support
+ - interrupt-parent: Phandle to the parent interrupt controller
+
MSI support (optional):
For older platforms without MSI integrated in the GIC, iProc PCIe core provides
@@ -77,8 +89,11 @@ Example:
reg = <0x18012000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0_intc 1>,
+ <0 0 0 2 &pcie0_intc 2>,
+ <0 0 0 3 &pcie0_intc 3>,
+ <0 0 0 4 &pcie0_intc 4>;
linux,pci-domain = <0>;
@@ -98,6 +113,14 @@ Example:
msi-parent = <&msi0>;
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
+ };
+
/* iProc event queue based MSI */
msi0: msi@18012000 {
compatible = "brcm,iproc-msi";
@@ -115,8 +138,11 @@ Example:
reg = <0x18013000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1_intc 1>,
+ <0 0 0 2 &pcie1_intc 2>,
+ <0 0 0 3 &pcie1_intc 3>,
+ <0 0 0 4 &pcie1_intc 4>;
linux,pci-domain = <1>;
@@ -130,4 +156,12 @@ Example:
phys = <&phy 1 6>;
phy-names = "pcie-phy";
+
+ pcie1_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
+ };
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/6] PAXB INTx support with proper model
From: Srinath Mannam @ 2019-08-28 8:54 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Mark Rutland,
Andy Shevchenko, Arnd Bergmann
Cc: devicetree, linux-pci, linux-kernel, Srinath Mannam,
bcm-kernel-feedback-list, linux-arm-kernel
This patch series adds PCIe legacy interrupt (INTx) support to the iProc
PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA,
INTB, INTC, INTD share the same interrupt line connected to the GIC
in the system. This is now modeled by using its own IRQ domain.
Also update all relevant devicetree files to adapt to the new model.
This patch set is based on Linux-5.2-rc4.
Changes from v1:
- Addressed Rob, Lorenzo, Arnd's comments
- Used child node for interrupt controller.
- Addressed Andy Shevchenko's comments
- Replaced while loop with do-while.
Ray Jui (6):
dt-bindings: pci: Update iProc PCI binding for INTx support
PCI: iproc: Add INTx support with better modeling
arm: dts: Change PCIe INTx mapping for Cygnus
arm: dts: Change PCIe INTx mapping for NSP
arm: dts: Change PCIe INTx mapping for HR2
arm64: dts: Change PCIe INTx mapping for NS2
.../devicetree/bindings/pci/brcm,iproc-pcie.txt | 48 ++++++++--
arch/arm/boot/dts/bcm-cygnus.dtsi | 30 ++++++-
arch/arm/boot/dts/bcm-hr2.dtsi | 30 ++++++-
arch/arm/boot/dts/bcm-nsp.dtsi | 45 ++++++++--
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 28 +++++-
drivers/pci/controller/pcie-iproc.c | 100 ++++++++++++++++++++-
drivers/pci/controller/pcie-iproc.h | 6 ++
7 files changed, 260 insertions(+), 27 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 9/9] drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register
From: Sylwester Nawrocki @ 2019-08-28 8:39 UTC (permalink / raw)
To: Dariusz Marcinkiewicz, dri-devel, linux-media, hverkuil-cisco
Cc: linux-samsung-soc, Joonyoung Shim, David Airlie, Seung-Woo Kim,
linux-kernel, Krzysztof Kozlowski, Inki Dae, Kyungmin Park,
Kukjin Kim, Daniel Vetter, linux-arm-kernel
In-Reply-To: <20190814104520.6001-10-darekm@google.com>
On 8/14/19 12:45, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill in
> the cec_connector_info.
>
> Changes since v2:
> - removed unnecessary call to invalidate phys address before
> deregistering the notifier,
> - use cec_notifier_phys_addr_invalidate instead of setting
> invalid address on a notifier.
>
> Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com>
> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index bc1565f1822ab..d532b468d9af5 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2006,12 +2020,6 @@ static int hdmi_probe(struct platform_device *pdev)
> }
> }
>
> - hdata->notifier = cec_notifier_get(&pdev->dev);
> - if (hdata->notifier == NULL) {
> - ret = -ENOMEM;
> - goto err_hdmiphy;
> - }
> -
> pm_runtime_enable(dev);
>
> audio_infoframe = &hdata->audio.infoframe;
> @@ -2023,7 +2031,7 @@ static int hdmi_probe(struct platform_device *pdev)
>
> ret = hdmi_register_audio_device(hdata);
> if (ret)
> - goto err_notifier_put;
> + goto err_runtime_disable;
> -err_notifier_put:
> - cec_notifier_put(hdata->notifier);
> +err_runtime_disable:
> pm_runtime_disable(dev);
nit: I think err_rpm_disable or err_pm_runtime_disable could be better
label names.
--
Thanks,
Sylwester
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Bibby Hsieh @ 2019-08-28 8:32 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
linux-arm-kernel, ginny.chen
In-Reply-To: <f8945f1b-aaa7-4f4a-59e5-8e817aeb46ae@gmail.com>
On Tue, 2019-08-27 at 12:13 +0200, Matthias Brugger wrote:
>
> On 27/08/2019 05:59, Bibby Hsieh wrote:
> > On Fri, 2019-08-23 at 16:21 +0200, Matthias Brugger wrote:
> >>
> >> On 20/08/2019 10:49, Bibby Hsieh wrote:
> >>> GCE cannot know the register base address, this function
> >>> can help cmdq client to get the cmdq_client_reg structure.
> >>>
> >>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> >>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> >>> ---
> >>> drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++++++++++++++++++++++++++
> >>> include/linux/soc/mediatek/mtk-cmdq.h | 21 +++++++++++++++++++
> >>> 2 files changed, 50 insertions(+)
> >>>
> >>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> index c53f8476c68d..80f75a1075b4 100644
> >>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> @@ -27,6 +27,35 @@ struct cmdq_instruction {
> >>> u8 op;
> >>> };
> >>>
> >>> +int cmdq_dev_get_client_reg(struct device *dev,
> >>> + struct cmdq_client_reg *client_reg, int idx)
> >>> +{
> >>
> >> Can't we do/call this in cmdq_mbox_create parsing the number of gce-client-reg
> >> properties we have and allocating these using a pointer to cmdq_client_reg in
> >> cmdq_client?
> >> We will have to free the pointer then in cmdq_mbox_destroy.
> >>
> >> Regards,
> >> Matthias
> >
> > I don't think we need to keep the cmdq_client_reg in cmdq_client
> > structure.
> > Because our client will have own data structure, they will copy the
> > client_reg information into their own structure.
> >
> > In the design now, we do not allocate the cmdq_client_reg, client pass
> > the cmdq_client_reg pointer into this API.
> > Client will destroy the pointer after they get the information they
> > want.
> >
>
> My point wasn't so much about the lifecycle of the object, but the fact that we
> add another call, which can be already full-filled by a necessary previous call
> to cmdq_mbox_create. So I would prefer to add the information gathering for
> cmdq_client_reg in this call, and let it live there for the time cmdq_client
> lives. In the end we are talking about 40 bits of memory.
>
Thanks for the comments. :D
Actually, I'm working for developing the chandes for MTK DRM apply cmdq
interface.
For MTK DRM, all the components included in MTK_CRTC use one mailbox
channel. According to [1], we create mailbox channel by mmsys device
node after get all the informations (include cmdq_client_reg) about
every device node of display components respectively. Please refer to
[2], [3] and [4], I'm going to upstream them recently.
If create mailbox channel and get the cmdq_client_reg in the same device
node, your suggestion is good for me.
But from display and mdp's viewpoint now, I don't think it is convenient
for them.
So I still prefer separate this function out of cmdq_mbox_create.:D
[1]
https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/mediatek/mt8173.dtsi#907
[2] get cmdq_client_reg in mtk_ddp_comp_init()
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1746354/12/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c#431
[3] create mailbox channel in mtk_drm_crtc_create()
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1746354/12/drivers/gpu/drm/mediatek/mtk_drm_crtc.c#814
[4] After component_bind_all(), the mtk_drm_crtc_create will be called
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e15c2dc6ceb4810a2090cd11a512932095866559/drivers/gpu/drm/mediatek/mtk_drm_drv.c#452
Thanks.
Bibby
> Regards,
> Matthias
>
> > Thanks for the comments so much.
> >
> > Bibby
> >
> >>
> >>> + struct of_phandle_args spec;
> >>> + int err;
> >>> +
> >>> + if (!client_reg)
> >>> + return -ENOENT;
> >>> +
> >>> + err = of_parse_phandle_with_fixed_args(dev->of_node,
> >>> + "mediatek,gce-client-reg",
> >>> + 3, idx, &spec);
> >>> + if (err < 0) {
> >>> + dev_err(dev,
> >>> + "error %d can't parse gce-client-reg property (%d)",
> >>> + err, idx);
> >>> +
> >>> + return err;
> >>> + }
> >>> +
> >>> + client_reg->subsys = (u8)spec.args[0];
> >>> + client_reg->offset = (u16)spec.args[1];
> >>> + client_reg->size = (u16)spec.args[2];
> >>> + of_node_put(spec.np);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> >>> +
> >>> static void cmdq_client_timeout(struct timer_list *t)
> >>> {
> >>> struct cmdq_client *client = from_timer(client, t, timer);
> >>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> >>> index a345870a6d10..02ddd60b212f 100644
> >>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> >>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> >>> @@ -15,6 +15,12 @@
> >>>
> >>> struct cmdq_pkt;
> >>>
> >>> +struct cmdq_client_reg {
> >>> + u8 subsys;
> >>> + u16 offset;
> >>> + u16 size;
> >>> +};
> >>> +
> >>> struct cmdq_client {
> >>> spinlock_t lock;
> >>> u32 pkt_cnt;
> >>> @@ -24,6 +30,21 @@ struct cmdq_client {
> >>> u32 timeout_ms; /* in unit of microsecond */
> >>> };
> >>>
> >>> +/**
> >>> + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
> >>> + * node of CMDQ client
> >>> + * @dev: device of CMDQ mailbox client
> >>> + * @client_reg: CMDQ client reg pointer
> >>> + * @idx: the index of desired reg
> >>> + *
> >>> + * Return: 0 for success; else the error code is returned
> >>> + *
> >>> + * Help CMDQ client parsing the cmdq client reg
> >>> + * from the device node of CMDQ client.
> >>> + */
> >>> +int cmdq_dev_get_client_reg(struct device *dev,
> >>> + struct cmdq_client_reg *client_reg, int idx);
> >>> +
> >>> /**
> >>> * cmdq_mbox_create() - create CMDQ mailbox client and channel
> >>> * @dev: device of CMDQ mailbox client
> >>>
> >
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: clock: mediatek: add pericfg for MT8183
From: Chunfeng Yun @ 2019-08-28 8:22 UTC (permalink / raw)
To: Rob Herring, Stephen Boyd
Cc: Mark Rutland, devicetree, Ryder Lee, Weiyi Lu, Michael Turquette,
linux-kernel, linux-clk, Chunfeng Yun, Nicolas Boichat,
linux-mediatek, Matthias Brugger, Erin Lo, linux-arm-kernel
This patch adds binding of pericfg for MT8183.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v2: no changes
---
.../devicetree/bindings/arm/mediatek/mediatek,pericfg.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
index 4c7e478117a0..ecf027a9003a 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
@@ -14,6 +14,7 @@ Required Properties:
- "mediatek,mt7629-pericfg", "syscon"
- "mediatek,mt8135-pericfg", "syscon"
- "mediatek,mt8173-pericfg", "syscon"
+ - "mediatek,mt8183-pericfg", "syscon"
- #clock-cells: Must be 1
- #reset-cells: Must be 1
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] clk: mediatek: add pericfg clocks for MT8183
From: Chunfeng Yun @ 2019-08-28 8:22 UTC (permalink / raw)
To: Rob Herring, Stephen Boyd
Cc: Mark Rutland, devicetree, Ryder Lee, Weiyi Lu, Michael Turquette,
linux-kernel, linux-clk, Chunfeng Yun, Nicolas Boichat,
linux-mediatek, Matthias Brugger, Erin Lo, linux-arm-kernel
In-Reply-To: <1566980533-28282-1-git-send-email-chunfeng.yun@mediatek.com>
Add pericfg clocks for MT8183, it's used when support USB
remote wakeup
Cc: Weiyi Lu <weiyi.lu@mediatek.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v2:
use GATE_MTK to define GATE_PERI suggested by Weiyi
---
drivers/clk/mediatek/clk-mt8183.c | 30 ++++++++++++++++++++++++++
include/dt-bindings/clock/mt8183-clk.h | 4 ++++
2 files changed, 34 insertions(+)
diff --git a/drivers/clk/mediatek/clk-mt8183.c b/drivers/clk/mediatek/clk-mt8183.c
index 1aa5f4059251..f3765bbdbe85 100644
--- a/drivers/clk/mediatek/clk-mt8183.c
+++ b/drivers/clk/mediatek/clk-mt8183.c
@@ -999,6 +999,20 @@ static const struct mtk_gate infra_clks[] = {
"msdc50_0_sel", 24),
};
+static const struct mtk_gate_regs peri_cg_regs = {
+ .set_ofs = 0x20c,
+ .clr_ofs = 0x20c,
+ .sta_ofs = 0x20c,
+};
+
+#define GATE_PERI(_id, _name, _parent, _shift) \
+ GATE_MTK(_id, _name, _parent, &peri_cg_regs, _shift, \
+ &mtk_clk_gate_ops_no_setclr_inv)
+
+static const struct mtk_gate peri_clks[] = {
+ GATE_PERI(CLK_PERI_AXI, "peri_axi", "axi_sel", 31),
+};
+
static const struct mtk_gate_regs apmixed_cg_regs = {
.set_ofs = 0x20,
.clr_ofs = 0x20,
@@ -1194,6 +1208,19 @@ static int clk_mt8183_infra_probe(struct platform_device *pdev)
return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
}
+static int clk_mt8183_peri_probe(struct platform_device *pdev)
+{
+ struct clk_onecell_data *clk_data;
+ struct device_node *node = pdev->dev.of_node;
+
+ clk_data = mtk_alloc_clk_data(CLK_PERI_NR_CLK);
+
+ mtk_clk_register_gates(node, peri_clks, ARRAY_SIZE(peri_clks),
+ clk_data);
+
+ return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+}
+
static int clk_mt8183_mcu_probe(struct platform_device *pdev)
{
struct clk_onecell_data *clk_data;
@@ -1223,6 +1250,9 @@ static const struct of_device_id of_match_clk_mt8183[] = {
}, {
.compatible = "mediatek,mt8183-infracfg",
.data = clk_mt8183_infra_probe,
+ }, {
+ .compatible = "mediatek,mt8183-pericfg",
+ .data = clk_mt8183_peri_probe,
}, {
.compatible = "mediatek,mt8183-mcucfg",
.data = clk_mt8183_mcu_probe,
diff --git a/include/dt-bindings/clock/mt8183-clk.h b/include/dt-bindings/clock/mt8183-clk.h
index 0046506eb24c..a7b470b0ec8a 100644
--- a/include/dt-bindings/clock/mt8183-clk.h
+++ b/include/dt-bindings/clock/mt8183-clk.h
@@ -284,6 +284,10 @@
#define CLK_INFRA_FBIST2FPC 100
#define CLK_INFRA_NR_CLK 101
+/* PERICFG */
+#define CLK_PERI_AXI 0
+#define CLK_PERI_NR_CLK 1
+
/* MFGCFG */
#define CLK_MFG_BG3D 0
#define CLK_MFG_NR_CLK 1
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/2] ARM: exynos: Enable support for ARM architected timers
From: Marek Szyprowski @ 2019-08-28 8:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: Chanwoo Choi, linux-samsung-soc, Krzysztof Kozlowski,
linux-arm-kernel, Bartlomiej Zolnierkiewicz
In-Reply-To: <d286053b6f4b4783d0638dc2dbd5858e@www.loen.fr>
Hi Marc,
On 2019-08-26 12:49, Marc Zyngier wrote:
> On 2019-08-26 11:31, Marek Szyprowski wrote:
>> ARM architected timer can be used together with Exynos MultiCore Timer
>> driver, so enable support for it. Support for ARM architected timers is
>> essential for enabling proper KVM support.
>
> How can you say that this is to "enable KVM support", while in the
> previous
> patch, you set "arm,cpu-registers-not-fw-configured" which implies
> that you're
> booting in secure mode with the timer's CP15 registers left to
> undefined values?
Thanks for asking a good question!
I've did my KVM research mainly on Exynos5422-based OdroidXU3/XU4 boards
family. After some recently merged patches they all now boot correctly
in HYP mode.
On all of those boards arch timers are indeed partially not configured
(CNTFRQ is zero). I was convinced that this also requires adding
"arm,cpu-registers-not-fw-configured" property to make timers fully
operational, but it looks that this only disables VDSO on arm32 and
switches to phys timers if booted in SVC mode.
I've checked and KVM works fine on the mentioned boards regardless of
the "arm,cpu-registers-not-fw-configured" property. The only issue is
the lack of proper value in CNTFRQ register, what requires patching
timer node by adding "clock-frequency = <24000000>" property also to the
guest dtb.
I've did my test of KVM with QEMU emulator version 3.1.0 (Debian
1:3.1+dfsg-8) virtualizing vexpress-a15 machine, with patched
vexpress-v2p-ca15-tc1.dtb and the following command line on OdroidXU3:
taskset 0x30 qemu-system-arm -M vexpress-a15 -smp 2 -cpu host
-enable-kvm -m 512 -kernel zImage -dtb vexpress-v2p-ca15-tc1.dtb -append
"console=ttyAMA0 root=/dev/vda rw rootwait" -serial stdio -display none
-monitor null -device virtio-blk-device,drive=virtio-blk -drive
file=rootfs.raw,id=virtio-blk,if=none,format=raw -netdev user,id=user
-device virtio-net-device,netdev=user
Then I've checked other boards that are capable of running in HYP mode.
Exynos5250 Arndale board with mainline uboot boots to HYP fine.
Exynos5250-based Snow Chromebook with stock bootloader boots only to SVC
mode. There exists a way to upgrade uboot to enable HYP, but this
requires HW fix to enable write access to nvram. Both boards however
also don't configure CNTFRQ register, but otherwise the arch timer
registers seems to be configured fine (virt counters are in sync between
CPUs).
The last group of boards are Exynos5420-based Pit and Exynos5800-based
Pi Chromebooks. In theory they are capable in running HYP mode with a
patched bootloader, but stock bootloader boots only to SVC. They also
truly don't have arch timer registers correctly configured, as virt
timers are out of sync between CPUs.
I will send v3 with "arm,cpu-registers-not-fw-configured" property moved
from the timer nodes in dtsi files to respective effected boards.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND v2 1/6] dt-bindings: watchdog: Add YAML schemas for the generic watchdog bindings
From: Maxime Ripard @ 2019-08-28 8:18 UTC (permalink / raw)
To: linux, wim
Cc: Mark Rutland, devicetree, linux-watchdog, linux-kernel,
Chen-Yu Tsai, Rob Herring, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190821143835.7294-1-mripard@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 439 bytes --]
On Wed, Aug 21, 2019 at 04:38:30PM +0200, Maxime Ripard wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The watchdogs have a bunch of generic properties that are needed in a
> device tree. Add a YAML schemas for those.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Ping?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: imx6q-pcie: add "fsl,pcie-phy-refclk-internal" for i.MX7D
From: André Draszik @ 2019-08-28 8:17 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Richard Zhu, Fabio Estevam,
Sascha Hauer, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team, linux-pci, Bjorn Helgaas, Shawn Guo,
linux-arm-kernel, Lucas Stach
In-Reply-To: <20190827155626.GA29948@bogus>
Hi Rob,
On Tue, 2019-08-27 at 10:56 -0500, Rob Herring wrote:
> On Tue, Aug 13, 2019 at 11:37:59AM +0100, André Draszik wrote:
> > The i.MX7D variant of the IP can use either an external
> > crystal oscillator input or an internal clock input as
> > a reference clock input for the PCIe PHY.
> >
> > Document the optional property 'fsl,pcie-phy-refclk-internal'
> >
> > Signed-off-by: André Draszik <git@andred.net>
> > Cc: Richard Zhu <hongxing.zhu@nxp.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > Cc: NXP Linux Team <linux-imx@nxp.com>
> > Cc: linux-pci@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > index a7f5f5afa0e6..985d7083df9f 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > @@ -56,6 +56,11 @@ Additional required properties for imx7d-pcie and imx8mq-pcie:
> > - "turnoff"
> > - fsl,imx7d-pcie-phy: A phandle to an fsl,imx7d-pcie-phy node.
>
> Not sure how this got in, but why is the phy binding not used here?
>
> >
> > +Additional optional properties for imx7d-pcie:
> > +- fsl,pcie-phy-refclk-internal: If present then an internal PLL input is used
> > + as PCIe PHY reference clock source. By default an external ocsillator input
> > + is used.
>
> Can't the clock binding and maybe 'assigned-clocks' be used here?
>
> Also, this is a property of the PHY, so it belongs in the PHY's node.
Thanks for pointing this out. I'll have a look.
Andre'
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/5] 0/6] arm64: meson-sm1: add support for DVFS
From: Jerome Brunet @ 2019-08-28 8:11 UTC (permalink / raw)
To: Kevin Hilman, Neil Armstrong
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <7h1rx6uti8.fsf@baylibre.com>
On Tue 27 Aug 2019 at 15:35, Kevin Hilman <khilman@baylibre.com> wrote:
> Kevin Hilman <khilman@baylibre.com> writes:
>
>> Jerome Brunet <jbrunet@baylibre.com> writes:
>>
>>> On Mon 26 Aug 2019 at 09:25, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>
>>>> Following DVFS support for the Amlogic G12A and G12B SoCs, this serie
>>>> enables DVFS on the SM1 SoC for the SEI610 board.
>>>>
>>>> The SM1 Clock structure is slightly different because of the Cortex-A55
>>>> core used, having the capability for each core of a same cluster to run
>>>> at a different frequency thanks to the newly used DynamIQ Shared Unit.
>>>>
>>>> This is why SM1 has a CPU clock tree for each core and for DynamIQ Shared Unit,
>>>> with a bypass mux to use the CPU0 instead of the dedicated trees.
>>>>
>>>> The DSU uses a new GP1 PLL as default clock, thus GP1 is added as read-only.
>>>>
>>>> The SM1 OPPs has been taken from the Amlogic Vendor tree, and unlike
>>>> G12A only a single version of the SoC is available.
>>>>
>>>> Dependencies:
>>>> - patch 6 is based on the "arm64: meson: add support for SM1 Power Domains" serie,
>>>> but is not a strong dependency, it will work without
>>>>
>>>> Changes since v1:
>>>> - exposed GP1, DSU and CPU 1,2,3 clock in patch 1
>>>>
>>>> Neil Armstrong (5):
>>>> dt-bindings: clk: meson: add sm1 periph clock controller bindings
>>>> clk: meson: g12a: add support for SM1 GP1 PLL
>>>> clk: meson: g12a: add support for SM1 DynamIQ Shared Unit clock
>>>> clk: meson: g12a: add support for SM1 CPU 1, 2 & 3 clocks
>>>> arm64: dts: meson-sm1-sei610: enable DVFS
>>>>
>>>> .../bindings/clock/amlogic,gxbb-clkc.txt | 1 +
>>>> .../boot/dts/amlogic/meson-sm1-sei610.dts | 59 +-
>>>> arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 69 +++
>>>> drivers/clk/meson/g12a.c | 544 ++++++++++++++++++
>>>> drivers/clk/meson/g12a.h | 24 +-
>>>> include/dt-bindings/clock/g12a-clkc.h | 5 +
>>>> 6 files changed, 697 insertions(+), 5 deletions(-)
>>>
>>> Applied 1 to 4
>>
>> Will there be a stable tag I can use for that so I can apply patch 5?
>
> Ah, I should've finished reading the list before asking. I now see your
> clock PR. I'll use this tag[1] unless there's a different one I should
> use.
I just pushed clk-meson-dt-v5.4-3 for you, with dt changes only.
>
> Kevin
>
> [1] git://github.com/BayLibre/clk-meson.git tags/clk-meson-v5.4-2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox