* Re: [PATCH v2] dt-bindings: ata: ahci-da850: Convert to dtschema
From: Rob Herring @ 2024-03-27 6:21 UTC (permalink / raw)
To: Animesh Agarwal
Cc: Damien Le Moal, linux-ide, devicetree, linux-kernel,
Krzysztof Kozlowski, Conor Dooley, Rob Herring
In-Reply-To: <20240327054014.36864-1-animeshagarwal28@gmail.com>
On Wed, 27 Mar 2024 11:10:10 +0530, Animesh Agarwal wrote:
> Convert the ahci-da850 bindings to DT schema.
>
> Signed-off-by: Animesh Agarwal <animeshagarwal28@gmail.com>
>
> ---
> Changes in v2:
> - Added description for reg property items.
> ---
> .../devicetree/bindings/ata/ahci-da850.txt | 18 ---------
> .../bindings/ata/ti,da850-ahci.yaml | 38 +++++++++++++++++++
> 2 files changed, 38 insertions(+), 18 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
> create mode 100644 Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml:20:111: [warning] line too long (111 > 110 characters) (line-length)
./Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml:22:3: [error] syntax error: could not find expected ':' (syntax)
dtschema/dtc warnings/errors:
make[2]: *** Deleting file 'Documentation/devicetree/bindings/ata/ti,da850-ahci.example.dts'
Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml:22:3: could not find expected ':'
make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/ata/ti,da850-ahci.example.dts] Error 1
make[2]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml:22:3: could not find expected ':'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml: ignoring, error parsing file
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2
make: *** [Makefile:240: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240327054014.36864-1-animeshagarwal28@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH v2 3/3] pmdomain: mediatek: support smi clamp protection
From: yu-chang.lee @ 2024-03-27 5:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Matthias Brugger, AngeloGioacchino Del Regno, MandyJH Liu
Cc: devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, fan.chen,
xiufeng.li, yu-chang.lee
In-Reply-To: <20240327055732.28198-1-yu-chang.lee@mediatek.com>
In order to avoid power glitch, this patch use smi clamp
to disable/enable smi common port.
Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
---
drivers/pmdomain/mediatek/mt8188-pm-domains.h | 41 ++++++-
drivers/pmdomain/mediatek/mtk-pm-domains.c | 109 +++++++++++++-----
drivers/pmdomain/mediatek/mtk-pm-domains.h | 1 +
3 files changed, 115 insertions(+), 36 deletions(-)
diff --git a/drivers/pmdomain/mediatek/mt8188-pm-domains.h b/drivers/pmdomain/mediatek/mt8188-pm-domains.h
index 7bbba4d56a77..39f057dca92c 100644
--- a/drivers/pmdomain/mediatek/mt8188-pm-domains.h
+++ b/drivers/pmdomain/mediatek/mt8188-pm-domains.h
@@ -573,6 +573,18 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
.pwr_sta2nd_offs = 0x170,
.sram_pdn_bits = BIT(8),
.sram_pdn_ack_bits = BIT(12),
+ .bp_cfg = {
+ BUS_PROT_WR(SMI,
+ MT8188_SMI_COMMON_SMI_CLAMP_DIP_TO_VDO0,
+ MT8188_SMI_COMMON_CLAMP_EN_SET,
+ MT8188_SMI_COMMON_CLAMP_EN_CLR,
+ MT8188_SMI_COMMON_CLAMP_EN_STA),
+ BUS_PROT_WR(SMI,
+ MT8188_SMI_COMMON_SMI_CLAMP_DIP_TO_VPP1,
+ MT8188_SMI_COMMON_CLAMP_EN_SET,
+ MT8188_SMI_COMMON_CLAMP_EN_CLR,
+ MT8188_SMI_COMMON_CLAMP_EN_STA),
+ },
.reset_smi = {
SMI_RESET_WR(MT8188_SMI_LARB10_RESET,
MT8188_SMI_LARB10_RESET_ADDR),
@@ -585,7 +597,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
SMI_RESET_WR(MT8188_SMI_LARB15_RESET,
MT8188_SMI_LARB15_RESET_ADDR),
},
- .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
+ .caps = MTK_SCPD_KEEP_DEFAULT_OFF | MTK_SCPD_CLAMP_PROTECTION,
},
[MT8188_POWER_DOMAIN_IPE] = {
.name = "ipe",
@@ -595,11 +607,18 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
.pwr_sta2nd_offs = 0x170,
.sram_pdn_bits = BIT(8),
.sram_pdn_ack_bits = BIT(12),
+ .bp_cfg = {
+ BUS_PROT_WR(SMI,
+ MT8188_SMI_COMMON_SMI_CLAMP_IPE_TO_VPP1,
+ MT8188_SMI_COMMON_CLAMP_EN_SET,
+ MT8188_SMI_COMMON_CLAMP_EN_CLR,
+ MT8188_SMI_COMMON_CLAMP_EN_STA),
+ },
.reset_smi = {
SMI_RESET_WR(MT8188_SMI_LARB12_RESET,
MT8188_SMI_LARB12_RESET_ADDR),
},
- .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
+ .caps = MTK_SCPD_KEEP_DEFAULT_OFF | MTK_SCPD_CLAMP_PROTECTION,
},
[MT8188_POWER_DOMAIN_CAM_VCORE] = {
.name = "cam_vcore",
@@ -676,13 +695,20 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
.pwr_sta2nd_offs = 0x170,
.sram_pdn_bits = BIT(8),
.sram_pdn_ack_bits = BIT(12),
+ .bp_cfg = {
+ BUS_PROT_WR(SMI,
+ MT8188_SMI_COMMON_SMI_CLAMP_IPE_TO_VPP1,
+ MT8188_SMI_COMMON_CLAMP_EN_SET,
+ MT8188_SMI_COMMON_CLAMP_EN_CLR,
+ MT8188_SMI_COMMON_CLAMP_EN_STA),
+ },
.reset_smi = {
SMI_RESET_WR(MT8188_SMI_LARB16A_RESET,
MT8188_SMI_LARB16A_RESET_ADDR),
SMI_RESET_WR(MT8188_SMI_LARB17A_RESET,
MT8188_SMI_LARB17A_RESET_ADDR),
},
- .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
+ .caps = MTK_SCPD_KEEP_DEFAULT_OFF | MTK_SCPD_CLAMP_PROTECTION,
},
[MT8188_POWER_DOMAIN_CAM_SUBB] = {
.name = "cam_subb",
@@ -692,13 +718,20 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
.pwr_sta2nd_offs = 0x170,
.sram_pdn_bits = BIT(8),
.sram_pdn_ack_bits = BIT(12),
+ .bp_cfg = {
+ BUS_PROT_WR(SMI,
+ MT8188_SMI_COMMON_SMI_CLAMP_CAM_SUBB_TO_VDO0,
+ MT8188_SMI_COMMON_CLAMP_EN_SET,
+ MT8188_SMI_COMMON_CLAMP_EN_CLR,
+ MT8188_SMI_COMMON_CLAMP_EN_STA),
+ },
.reset_smi = {
SMI_RESET_WR(MT8188_SMI_LARB16B_RESET,
MT8188_SMI_LARB16B_RESET_ADDR),
SMI_RESET_WR(MT8188_SMI_LARB17B_RESET,
MT8188_SMI_LARB17B_RESET_ADDR),
},
- .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
+ .caps = MTK_SCPD_KEEP_DEFAULT_OFF | MTK_SCPD_CLAMP_PROTECTION,
},
};
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
index 9ab6fa105c8c..2a86ff4bf23e 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
@@ -47,9 +47,10 @@ struct scpsys_domain {
struct clk_bulk_data *subsys_clks;
struct regmap *infracfg_nao;
struct regmap *infracfg;
- struct regmap *smi;
+ struct regmap **smi;
struct regmap **larb;
int num_larb;
+ int num_smi;
struct regulator *supply;
};
@@ -122,29 +123,19 @@ static int scpsys_sram_disable(struct scpsys_domain *pd)
MTK_POLL_TIMEOUT);
}
-static struct regmap *scpsys_bus_protect_get_regmap(struct scpsys_domain *pd,
- const struct scpsys_bus_prot_data *bpd)
-{
- if (bpd->flags & BUS_PROT_COMPONENT_SMI)
- return pd->smi;
- else
- return pd->infracfg;
-}
-
static struct regmap *scpsys_bus_protect_get_sta_regmap(struct scpsys_domain *pd,
const struct scpsys_bus_prot_data *bpd)
{
if (bpd->flags & BUS_PROT_STA_COMPONENT_INFRA_NAO)
return pd->infracfg_nao;
else
- return scpsys_bus_protect_get_regmap(pd, bpd);
+ return pd->infracfg;
}
static int scpsys_bus_protect_clear(struct scpsys_domain *pd,
- const struct scpsys_bus_prot_data *bpd)
+ const struct scpsys_bus_prot_data *bpd,
+ struct regmap *sta_regmap, struct regmap *regmap)
{
- struct regmap *sta_regmap = scpsys_bus_protect_get_sta_regmap(pd, bpd);
- struct regmap *regmap = scpsys_bus_protect_get_regmap(pd, bpd);
u32 sta_mask = bpd->bus_prot_sta_mask;
u32 expected_ack;
u32 val;
@@ -165,10 +156,9 @@ static int scpsys_bus_protect_clear(struct scpsys_domain *pd,
}
static int scpsys_bus_protect_set(struct scpsys_domain *pd,
- const struct scpsys_bus_prot_data *bpd)
+ const struct scpsys_bus_prot_data *bpd,
+ struct regmap *sta_regmap, struct regmap *regmap)
{
- struct regmap *sta_regmap = scpsys_bus_protect_get_sta_regmap(pd, bpd);
- struct regmap *regmap = scpsys_bus_protect_get_regmap(pd, bpd);
u32 sta_mask = bpd->bus_prot_sta_mask;
u32 val;
@@ -182,19 +172,32 @@ static int scpsys_bus_protect_set(struct scpsys_domain *pd,
MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
}
-static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
+static int scpsys_clamp_bus_protection_enable(struct scpsys_domain *pd, bool is_smi)
{
+ int smi_count = 0;
+
for (int i = 0; i < SPM_MAX_BUS_PROT_DATA; i++) {
const struct scpsys_bus_prot_data *bpd = &pd->data->bp_cfg[i];
+ struct regmap *sta_regmap, *regmap;
+ bool is_smi = bpd->flags & BUS_PROT_COMPONENT_SMI;
int ret;
if (!bpd->bus_prot_set_clr_mask)
break;
+ if (is_smi) {
+ sta_regmap = pd->smi[smi_count];
+ regmap = pd->smi[smi_count];
+ smi_count++;
+ } else {
+ sta_regmap = scpsys_bus_protect_get_sta_regmap(pd, bpd);
+ regmap = pd->infracfg;
+ }
+
if (bpd->flags & BUS_PROT_INVERTED)
- ret = scpsys_bus_protect_clear(pd, bpd);
+ ret = scpsys_bus_protect_clear(pd, bpd, sta_regmap, regmap);
else
- ret = scpsys_bus_protect_set(pd, bpd);
+ ret = scpsys_bus_protect_set(pd, bpd, sta_regmap, regmap);
if (ret)
return ret;
}
@@ -202,19 +205,32 @@ static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
return 0;
}
-static int scpsys_bus_protect_disable(struct scpsys_domain *pd)
+static int scpsys_clamp_bus_protection_disable(struct scpsys_domain *pd, bool is_smi)
{
+ int smi_count = pd->num_smi - 1;
+
for (int i = SPM_MAX_BUS_PROT_DATA - 1; i >= 0; i--) {
const struct scpsys_bus_prot_data *bpd = &pd->data->bp_cfg[i];
+ struct regmap *sta_regmap, *regmap;
+ bool is_smi = bpd->flags & BUS_PROT_COMPONENT_SMI;
int ret;
if (!bpd->bus_prot_set_clr_mask)
continue;
+ if (is_smi) {
+ sta_regmap = pd->smi[smi_count];
+ regmap = pd->smi[smi_count];
+ smi_count--;
+ } else {
+ sta_regmap = scpsys_bus_protect_get_sta_regmap(pd, bpd);
+ regmap = pd->infracfg;
+ }
+
if (bpd->flags & BUS_PROT_INVERTED)
- ret = scpsys_bus_protect_set(pd, bpd);
+ ret = scpsys_bus_protect_set(pd, bpd, sta_regmap, regmap);
else
- ret = scpsys_bus_protect_clear(pd, bpd);
+ ret = scpsys_bus_protect_clear(pd, bpd, sta_regmap, regmap);
if (ret)
return ret;
}
@@ -272,6 +288,12 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
bool tmp;
int ret;
+ if (MTK_SCPD_CAPS(pd, MTK_SCPD_CLAMP_PROTECTION)) {
+ ret = scpsys_clamp_bus_protection_enable(pd, true);
+ if (ret)
+ return ret;
+ }
+
ret = scpsys_regulator_enable(pd->supply);
if (ret)
return ret;
@@ -318,7 +340,13 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
if (ret < 0)
goto err_disable_subsys_clks;
- ret = scpsys_bus_protect_disable(pd);
+ if (MTK_SCPD_CAPS(pd, MTK_SCPD_CLAMP_PROTECTION)) {
+ ret = scpsys_clamp_bus_protection_disable(pd, true);
+ if (ret)
+ return ret;
+ }
+
+ ret = scpsys_clamp_bus_protection_disable(pd, false);
if (ret < 0)
goto err_disable_sram;
@@ -332,7 +360,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
return 0;
err_enable_bus_protect:
- scpsys_bus_protect_enable(pd);
+ scpsys_clamp_bus_protection_enable(pd, false);
err_disable_sram:
scpsys_sram_disable(pd);
err_disable_subsys_clks:
@@ -353,7 +381,13 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
bool tmp;
int ret;
- ret = scpsys_bus_protect_enable(pd);
+ if (MTK_SCPD_CAPS(pd, MTK_SCPD_CLAMP_PROTECTION)) {
+ ret = scpsys_clamp_bus_protection_enable(pd, true);
+ if (ret)
+ return ret;
+ }
+
+ ret = scpsys_clamp_bus_protection_enable(pd, false);
if (ret < 0)
return ret;
@@ -450,12 +484,23 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
if (IS_ERR(pd->infracfg))
return ERR_CAST(pd->infracfg);
- smi_node = of_parse_phandle(node, "mediatek,smi", 0);
- if (smi_node) {
- pd->smi = device_node_to_regmap(smi_node);
- of_node_put(smi_node);
- if (IS_ERR(pd->smi))
- return ERR_CAST(pd->smi);
+ pd->num_smi = of_count_phandle_with_args(node, "mediatek,smi", NULL);
+ if (pd->num_smi > 0) {
+ pd->smi = devm_kcalloc(scpsys->dev, pd->num_smi, sizeof(*pd->smi), GFP_KERNEL);
+ if (!pd->smi)
+ return ERR_PTR(-ENOMEM);
+
+ for (i = 0; i < pd->num_smi; i++) {
+ smi_node = of_parse_phandle(node, "mediatek,smi", i);
+ if (!smi_node)
+ return ERR_PTR(-EINVAL);
+
+ pd->smi[i] = device_node_to_regmap(smi_node);
+ if (IS_ERR(pd->smi[i]))
+ return ERR_CAST(pd->smi[i]);
+ }
+ } else {
+ pd->num_smi = 0;
}
pd->num_larb = of_count_phandle_with_args(node, "mediatek,larb", NULL);
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.h b/drivers/pmdomain/mediatek/mtk-pm-domains.h
index 31c2a1bb500f..e0eb7214719e 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.h
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.h
@@ -13,6 +13,7 @@
#define MTK_SCPD_EXT_BUCK_ISO BIT(6)
#define MTK_SCPD_HAS_INFRA_NAO BIT(7)
#define MTK_SCPD_STRICT_BUS_PROTECTION BIT(8)
+#define MTK_SCPD_CLAMP_PROTECTION BIT(9)
#define MTK_SCPD_CAPS(_scpd, _x) ((_scpd)->data->caps & (_x))
#define SPM_VDE_PWR_CON 0x0210
--
2.18.0
^ permalink raw reply related
* [PATCH v2 1/3] pmdomain: mediatek: add smi_larb_reset function when power on
From: yu-chang.lee @ 2024-03-27 5:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Matthias Brugger, AngeloGioacchino Del Regno, MandyJH Liu
Cc: devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, fan.chen,
xiufeng.li, yu-chang.lee
In-Reply-To: <20240327055732.28198-1-yu-chang.lee@mediatek.com>
This patch avoid mtcmos power glitch from happening by set and clear
smi larb reset.
Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
---
drivers/pmdomain/mediatek/mt8188-pm-domains.h | 28 +++++++++
drivers/pmdomain/mediatek/mtk-pm-domains.c | 59 +++++++++++++++++++
drivers/pmdomain/mediatek/mtk-pm-domains.h | 12 ++++
3 files changed, 99 insertions(+)
diff --git a/drivers/pmdomain/mediatek/mt8188-pm-domains.h b/drivers/pmdomain/mediatek/mt8188-pm-domains.h
index 06834ab6597c..7bbba4d56a77 100644
--- a/drivers/pmdomain/mediatek/mt8188-pm-domains.h
+++ b/drivers/pmdomain/mediatek/mt8188-pm-domains.h
@@ -573,6 +573,18 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
.pwr_sta2nd_offs = 0x170,
.sram_pdn_bits = BIT(8),
.sram_pdn_ack_bits = BIT(12),
+ .reset_smi = {
+ SMI_RESET_WR(MT8188_SMI_LARB10_RESET,
+ MT8188_SMI_LARB10_RESET_ADDR),
+ SMI_RESET_WR(MT8188_SMI_LARB11A_RESET,
+ MT8188_SMI_LARB11A_RESET_ADDR),
+ SMI_RESET_WR(MT8188_SMI_LARB11C_RESET,
+ MT8188_SMI_LARB11C_RESET_ADDR),
+ SMI_RESET_WR(MT8188_SMI_LARB11B_RESET,
+ MT8188_SMI_LARB11B_RESET_ADDR),
+ SMI_RESET_WR(MT8188_SMI_LARB15_RESET,
+ MT8188_SMI_LARB15_RESET_ADDR),
+ },
.caps = MTK_SCPD_KEEP_DEFAULT_OFF,
},
[MT8188_POWER_DOMAIN_IPE] = {
@@ -583,6 +595,10 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
.pwr_sta2nd_offs = 0x170,
.sram_pdn_bits = BIT(8),
.sram_pdn_ack_bits = BIT(12),
+ .reset_smi = {
+ SMI_RESET_WR(MT8188_SMI_LARB12_RESET,
+ MT8188_SMI_LARB12_RESET_ADDR),
+ },
.caps = MTK_SCPD_KEEP_DEFAULT_OFF,
},
[MT8188_POWER_DOMAIN_CAM_VCORE] = {
@@ -660,6 +676,12 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
.pwr_sta2nd_offs = 0x170,
.sram_pdn_bits = BIT(8),
.sram_pdn_ack_bits = BIT(12),
+ .reset_smi = {
+ SMI_RESET_WR(MT8188_SMI_LARB16A_RESET,
+ MT8188_SMI_LARB16A_RESET_ADDR),
+ SMI_RESET_WR(MT8188_SMI_LARB17A_RESET,
+ MT8188_SMI_LARB17A_RESET_ADDR),
+ },
.caps = MTK_SCPD_KEEP_DEFAULT_OFF,
},
[MT8188_POWER_DOMAIN_CAM_SUBB] = {
@@ -670,6 +692,12 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8188[] = {
.pwr_sta2nd_offs = 0x170,
.sram_pdn_bits = BIT(8),
.sram_pdn_ack_bits = BIT(12),
+ .reset_smi = {
+ SMI_RESET_WR(MT8188_SMI_LARB16B_RESET,
+ MT8188_SMI_LARB16B_RESET_ADDR),
+ SMI_RESET_WR(MT8188_SMI_LARB17B_RESET,
+ MT8188_SMI_LARB17B_RESET_ADDR),
+ },
.caps = MTK_SCPD_KEEP_DEFAULT_OFF,
},
};
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
index e274e3315fe7..9ab6fa105c8c 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
@@ -48,6 +48,8 @@ struct scpsys_domain {
struct regmap *infracfg_nao;
struct regmap *infracfg;
struct regmap *smi;
+ struct regmap **larb;
+ int num_larb;
struct regulator *supply;
};
@@ -230,6 +232,39 @@ static int scpsys_regulator_disable(struct regulator *supply)
return supply ? regulator_disable(supply) : 0;
}
+static int _scpsys_smi_larb_reset(const struct smi_reset_data bpd,
+ struct regmap *regmap)
+{
+ int ret;
+ u32 mask = bpd.smi_reset_mask;
+
+ if (!mask)
+ return 0;
+
+ ret = regmap_set_bits(regmap, bpd.smi_reset_addr, mask);
+ if (ret)
+ return ret;
+
+ ret = regmap_clear_bits(regmap, bpd.smi_reset_addr, mask);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int scpsys_smi_larb_reset(struct scpsys_domain *pd)
+{
+ int ret, i;
+
+ for (i = 0; i < pd->num_larb; i++) {
+ ret = _scpsys_smi_larb_reset(pd->data->reset_smi[i], pd->larb[i]);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int scpsys_power_on(struct generic_pm_domain *genpd)
{
struct scpsys_domain *pd = container_of(genpd, struct scpsys_domain, genpd);
@@ -279,6 +314,10 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
if (ret < 0)
goto err_disable_subsys_clks;
+ ret = scpsys_smi_larb_reset(pd);
+ if (ret < 0)
+ goto err_disable_subsys_clks;
+
ret = scpsys_bus_protect_disable(pd);
if (ret < 0)
goto err_disable_sram;
@@ -355,6 +394,7 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
struct scpsys_domain *pd;
struct device_node *root_node = scpsys->dev->of_node;
struct device_node *smi_node;
+ struct device_node *larb_node;
struct property *prop;
const char *clk_name;
int i, ret, num_clks;
@@ -418,6 +458,25 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
return ERR_CAST(pd->smi);
}
+ pd->num_larb = of_count_phandle_with_args(node, "mediatek,larb", NULL);
+ if (pd->num_larb > 0) {
+ pd->larb = devm_kcalloc(scpsys->dev, pd->num_larb, sizeof(*pd->larb), GFP_KERNEL);
+ if (!pd->larb)
+ return ERR_PTR(-ENOMEM);
+
+ for (i = 0; i < pd->num_larb; i++) {
+ larb_node = of_parse_phandle(node, "mediatek,larb", i);
+ if (!larb_node)
+ return ERR_PTR(-EINVAL);
+
+ pd->larb[i] = device_node_to_regmap(larb_node);
+ if (IS_ERR(pd->larb[i]))
+ return ERR_CAST(pd->larb[i]);
+ }
+ } else {
+ pd->num_larb = 0;
+ }
+
if (MTK_SCPD_CAPS(pd, MTK_SCPD_HAS_INFRA_NAO)) {
pd->infracfg_nao = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg-nao");
if (IS_ERR(pd->infracfg_nao))
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.h b/drivers/pmdomain/mediatek/mtk-pm-domains.h
index aaba5e6b0536..31c2a1bb500f 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.h
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.h
@@ -43,6 +43,7 @@
#define PWR_STATUS_USB BIT(25)
#define SPM_MAX_BUS_PROT_DATA 6
+#define SPM_MAX_SMI_RESET_DATA 6
enum scpsys_bus_prot_flags {
BUS_PROT_REG_UPDATE = BIT(1),
@@ -79,6 +80,16 @@ enum scpsys_bus_prot_flags {
INFRA_TOPAXI_PROTECTEN, \
INFRA_TOPAXI_PROTECTSTA1)
+#define SMI_RESET_WR(_mask, _addr) { \
+ .smi_reset_mask = (_mask), \
+ .smi_reset_addr = _addr, \
+ }
+
+struct smi_reset_data {
+ u32 smi_reset_mask;
+ u32 smi_reset_addr;
+};
+
struct scpsys_bus_prot_data {
u32 bus_prot_set_clr_mask;
u32 bus_prot_set;
@@ -110,6 +121,7 @@ struct scpsys_domain_data {
u32 ext_buck_iso_mask;
u16 caps;
const struct scpsys_bus_prot_data bp_cfg[SPM_MAX_BUS_PROT_DATA];
+ const struct smi_reset_data reset_smi[SPM_MAX_SMI_RESET_DATA];
int pwr_sta_offs;
int pwr_sta2nd_offs;
};
--
2.18.0
^ permalink raw reply related
* [PATCH v2 0/3] pmdomain: mediatek: solve power domain glitch issue
From: yu-chang.lee @ 2024-03-27 5:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Matthias Brugger, AngeloGioacchino Del Regno, MandyJH Liu
Cc: devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, fan.chen,
xiufeng.li, yu-chang.lee
Hi,
This series aims to solve power-off failures and occasional SMI hang issues that
occur during camera stress tests. The issue arises because, when MTCMOS powers on
or off, signal glitches are sometimes produced. This is fairly normal, but the
software must address it to avoid mistaking the glitch for a transaction signal.
The solutions in these patches can be summarized as follows:
1. Disable the sub-common port after turning off the Larb CG and before turning
off the Larb MTCMOS.
2. Use CLAMP to disable/enable the SMI common port.
3. Implement an AXI reset.
For previous discussion on the direction of the code modifications, please refer
to: https://lore.kernel.org/linux-arm-kernel/c476cc48-17ec-4e14-98d8-35bdffb5d296@collabora.com/
Change in v2
- fix commit title to "pmdomain: mediatek:"
- add dt-binding definition
- remove unused function
yu-chang.lee (3):
pmdomain: mediatek: add smi_larb_reset function when power on
dt-bindings: power: Add mediatek larb definition
pmdomain: mediatek: support smi clamp protection
.../power/mediatek,power-controller.yaml | 4 +
drivers/pmdomain/mediatek/mt8188-pm-domains.h | 69 ++++++-
drivers/pmdomain/mediatek/mtk-pm-domains.c | 168 ++++++++++++++----
drivers/pmdomain/mediatek/mtk-pm-domains.h | 13 ++
4 files changed, 218 insertions(+), 36 deletions(-)
--
2.18.0
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: yu-chang.lee @ 2024-03-27 5:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Matthias Brugger, AngeloGioacchino Del Regno, MandyJH Liu
Cc: devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, fan.chen,
xiufeng.li, yu-chang.lee
In-Reply-To: <20240327055732.28198-1-yu-chang.lee@mediatek.com>
Add Smart Multimedia Interface Local Arbiter to mediatek
power domain.
Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
---
.../devicetree/bindings/power/mediatek,power-controller.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
index 8985e2df8a56..228c0dec5253 100644
--- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
@@ -125,6 +125,10 @@ $defs:
$ref: /schemas/types.yaml#/definitions/phandle
description: phandle to the device containing the SMI register range.
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the device containing the LARB register range.
+
required:
- reg
--
2.18.0
^ permalink raw reply related
* [PATCH v2] dt-bindings: crypto: ti,omap-sham: Convert to dtschema
From: Animesh Agarwal @ 2024-03-27 5:49 UTC (permalink / raw)
Cc: animeshagarwal28, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-crypto, devicetree,
linux-kernel
Convert the OMAP SoC SHA crypto Module bindings to DT Schema.
Signed-off-by: Animesh Agarwal <animeshagarwal28@gmail.com>
---
Changes in v2:
- Moved vendor specific property below more common properties.
---
.../devicetree/bindings/crypto/omap-sham.txt | 28 ----------
.../bindings/crypto/ti,omap-sham.yaml | 56 +++++++++++++++++++
2 files changed, 56 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt
create mode 100644 Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt
deleted file mode 100644
index ad9115569611..000000000000
--- a/Documentation/devicetree/bindings/crypto/omap-sham.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-OMAP SoC SHA crypto Module
-
-Required properties:
-
-- compatible : Should contain entries for this and backward compatible
- SHAM versions:
- - "ti,omap2-sham" for OMAP2 & OMAP3.
- - "ti,omap4-sham" for OMAP4 and AM33XX.
- - "ti,omap5-sham" for OMAP5, DRA7 and AM43XX.
-- ti,hwmods: Name of the hwmod associated with the SHAM module
-- reg : Offset and length of the register set for the module
-- interrupts : the interrupt-specifier for the SHAM module.
-
-Optional properties:
-- dmas: DMA specifiers for the rx dma. See the DMA client binding,
- Documentation/devicetree/bindings/dma/dma.txt
-- dma-names: DMA request name. Should be "rx" if a dma is present.
-
-Example:
- /* AM335x */
- sham: sham@53100000 {
- compatible = "ti,omap4-sham";
- ti,hwmods = "sham";
- reg = <0x53100000 0x200>;
- interrupts = <109>;
- dmas = <&edma 36>;
- dma-names = "rx";
- };
diff --git a/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml b/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
new file mode 100644
index 000000000000..d69b50228009
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/ti,omap-sham.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP SoC SHA crypto Module
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,omap2-sham
+ - ti,omap4-sham
+ - ti,omap5-sham
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx
+
+ ti,hwmods:
+ description: Name of the hwmod associated with the SHAM module
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [sham]
+
+dependencies:
+ dmas: [dma-names]
+
+additionalProperties: false
+
+required:
+ - compatible
+ - ti,hwmods
+ - reg
+ - interrupts
+
+examples:
+ - |
+ sham@53100000 {
+ compatible = "ti,omap4-sham";
+ ti,hwmods = "sham";
+ reg = <0x53100000 0x200>;
+ interrupts = <109>;
+ dmas = <&edma 36>;
+ dma-names = "rx";
+ };
--
2.44.0
^ permalink raw reply related
* [PATCH v2] dt-bindings: ata: ahci-da850: Convert to dtschema
From: Animesh Agarwal @ 2024-03-27 5:40 UTC (permalink / raw)
Cc: animeshagarwal28, Damien Le Moal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-ide, devicetree,
linux-kernel
Convert the ahci-da850 bindings to DT schema.
Signed-off-by: Animesh Agarwal <animeshagarwal28@gmail.com>
---
Changes in v2:
- Added description for reg property items.
---
.../devicetree/bindings/ata/ahci-da850.txt | 18 ---------
.../bindings/ata/ti,da850-ahci.yaml | 38 +++++++++++++++++++
2 files changed, 38 insertions(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
create mode 100644 Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt
deleted file mode 100644
index 5f8193417725..000000000000
--- a/Documentation/devicetree/bindings/ata/ahci-da850.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device tree binding for the TI DA850 AHCI SATA Controller
----------------------------------------------------------
-
-Required properties:
- - compatible: must be "ti,da850-ahci"
- - reg: physical base addresses and sizes of the two register regions
- used by the controller: the register map as defined by the
- AHCI 1.1 standard and the Power Down Control Register (PWRDN)
- for enabling/disabling the SATA clock receiver
- - interrupts: interrupt specifier (refer to the interrupt binding)
-
-Example:
-
- sata: sata@218000 {
- compatible = "ti,da850-ahci";
- reg = <0x218000 0x2000>, <0x22c018 0x4>;
- interrupts = <67>;
- };
diff --git a/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml b/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
new file mode 100644
index 000000000000..b8f31187f34b
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/ti,da850-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DA850 AHCI SATA Controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ const: ti,da850-ahci
+
+ reg:
+ items:
+ - description: Address and size of the register map as defined by the AHCI 1.1 standard.
+ - description: |
+ Address and size of Power Down Control Register (PWRDN) for enabling/disabling the SATA clock receiver.
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ sata@218000 {
+ compatible = "ti,da850-ahci";
+ reg = <0x218000 0x2000>, <0x22c018 0x4>;
+ interrupts = <67>;
+ };
--
2.44.0
^ permalink raw reply related
* RE: [PATCH v2 5/6] PCI: dwc: rcar-gen4: Add support for other R-Car Gen4 PCIe controller
From: Yoshihiro Shimoda @ 2024-03-27 5:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
bhelgaas@google.com, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, mani@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <20240326204842.GA1493890@bhelgaas>
Hi Bjorn,
> From: Bjorn Helgaas, Sent: Wednesday, March 27, 2024 5:49 AM
>
> The subject line should specify which controller(s) this adds support
> for.
I got it. I'll change the subject.
> On Tue, Mar 26, 2024 at 11:45:39AM +0900, Yoshihiro Shimoda wrote:
> > The PCIe controllers of R-Car V4H (r8a779g0) and one more SoC require
> > different initializing settings than R-Car S4-8 (r8a779f0). So, add
> > specific functions for them as "renesas,rcar-gen4-pcie{-ep}" compatible.
>
> I can't tell from this what's being added. This should say something
> like "this driver previously supported r8.... Add support for r8...."
> so it's clear what was existing and what is new.
I got it. I'll modify the description.
> Hmm... the first use of request_firmware() in drivers/pci/. That
> warrants a mention here as it's a pretty significant change.
I got it. I'll add such a description.
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > ---
> > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 188 +++++++++++++++++++-
> > 1 file changed, 187 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > index a37613dd9ff4..7f3b5e9ca405 100644
> > --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > @@ -5,8 +5,10 @@
> > */
> >
> > #include <linux/delay.h>
> > +#include <linux/firmware.h>
> > #include <linux/interrupt.h>
> > #include <linux/io.h>
> > +#include <linux/iopoll.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/pci.h>
> > @@ -20,9 +22,10 @@
> > /* Renesas-specific */
> > /* PCIe Mode Setting Register 0 */
> > #define PCIEMSR0 0x0000
> > -#define BIFUR_MOD_SET_ON BIT(0)
> > +#define APP_SRIS_MODE BIT(6)
> > #define DEVICE_TYPE_EP 0
> > #define DEVICE_TYPE_RC BIT(4)
> > +#define BIFUR_MOD_SET_ON BIT(0)
> >
> > /* PCIe Interrupt Status 0 */
> > #define PCIEINTSTS0 0x0084
> > @@ -37,33 +40,179 @@
> > #define PCIEDMAINTSTSEN 0x0314
> > #define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
> >
> > +/* Port Logic Registers 89 */
> > +#define PRTLGC89 0x0b70
> > +
> > +/* Port Logic Registers 90 */
> > +#define PRTLGC90 0x0b74
> > +
> > /* PCIe Reset Control Register 1 */
> > #define PCIERSTCTRL1 0x0014
> > #define APP_HOLD_PHY_RST BIT(16)
> > #define APP_LTSSM_ENABLE BIT(0)
> >
> > +/* PCIe Power Management Control */
> > +#define PCIEPWRMNGCTRL 0x0070
> > +#define APP_CLK_REQ_N BIT(11)
> > +#define APP_CLK_PM_EN BIT(10)
> > +
> > #define RCAR_NUM_SPEED_CHANGE_RETRIES 10
> > #define RCAR_MAX_LINK_SPEED 4
> >
> > #define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
> > #define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
> >
> > +#define RCAR_GEN4_PCIE_FIRMEARE_NAME "rcar_gen4_pcie.bin"
> > +#define RCAR_GEN4_PCIE_FIRMEARE_BASE_ADDR 0xc000
>
> s/FIRMEARE/FIRMWARE/
Oops. I'll fix it.
> > struct rcar_gen4_pcie {
> > struct dw_pcie dw;
> > void __iomem *base;
> > + /*
> > + * The R-Car Gen4 documents don't describe the PHY registers' name.
> > + * But, the initialization procedure describes these offsets. So,
> > + * this driver has "phy_base + magical offset number" for it.
>
> Make up your own #defines for the offsets. That would be better than
> magic hex offsets below.
I got it. I'll add #defines for it.
> > + void __iomem *phy_base;
> > struct platform_device *pdev;
> > enum dw_pcie_device_mode mode;
> >
> > int (*start_link_enable)(struct rcar_gen4_pcie *rcar);
> > + void (*additional_common_init)(struct rcar_gen4_pcie *rcar);
> > };
> > #define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
> >
> > struct rcar_gen4_pcie_platdata {
> > enum dw_pcie_device_mode mode;
> > int (*start_link_enable)(struct rcar_gen4_pcie *rcar);
> > + void (*additional_common_init)(struct rcar_gen4_pcie *rcar);
> > };
> >
> > /* Common */
> > +static void rcar_gen4_pcie_phy_reg_update_bits(struct rcar_gen4_pcie *rcar,
> > + u32 offset, u32 mask, u32 val)
> > +{
> > + u32 tmp;
> > +
> > + tmp = readl(rcar->phy_base + offset);
> > + tmp &= ~mask;
> > + tmp |= val;
> > + writel(tmp, rcar->phy_base + offset);
> > +}
> > +
> > +static int rcar_gen4_pcie_reg_check_bit(struct rcar_gen4_pcie *rcar,
> > + u32 offset, u32 mask)
> > +{
> > + struct dw_pcie *dw = &rcar->dw;
> > +
> > + if (dw_pcie_readl_dbi(dw, offset) & mask)
> > + return -EAGAIN;
> > +
> > + return 0;
> > +}
> > +
> > +static int rcar_gen4_pcie_update_phy_firmware(struct rcar_gen4_pcie *rcar)
> > +{
> > + const u32 check_addr[] = { 0x00101018, 0x00101118, 0x00101021, 0x00101121};
> > + struct dw_pcie *dw = &rcar->dw;
> > + const struct firmware *fw;
> > + unsigned int i, timeout;
> > + u32 data;
> > + int ret;
> > +
> > + ret = request_firmware(&fw, RCAR_GEN4_PCIE_FIRMEARE_NAME, dw->dev);
> > + if (ret)
> > + return ret;
>
> It looks like a failure here leads to a probe failure, so I think this
> needs a diagnostic message so the user has a hint about what went
> wrong.
I got it. I'll add such a code here.
> > + for (i = 0; i < (fw->size / 2); i++) {
> > + data = fw->data[i * 2] | fw->data[(i * 2) + 1] << 8;
> > + timeout = 100;
> > +retry_data:
> > + dw_pcie_writel_dbi(dw, PRTLGC89, RCAR_GEN4_PCIE_FIRMEARE_BASE_ADDR + i);
> > + dw_pcie_writel_dbi(dw, PRTLGC90, data);
> > + if (rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC89, BIT(30)) < 0) {
> > + if (!(--timeout)) {
> > + ret = -ETIMEDOUT;
> > + goto exit;
> > + }
> > + usleep_range(100, 200);
> > + goto retry_data;
> > + }
> > + }
> > +
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x0f8, BIT(17), BIT(17));
> > +
> > + for (i = 0; i < ARRAY_SIZE(check_addr); i++) {
> > + timeout = 100;
> > +retry_check:
> > + dw_pcie_writel_dbi(dw, PRTLGC89, check_addr[i]);
> > + ret = rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC89, BIT(30));
> > + ret |= rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC90, BIT(0));
> > + if (ret < 0) {
> > + if (!(--timeout)) {
> > + ret = -ETIMEDOUT;
> > + goto exit;
> > + }
> > + usleep_range(100, 200);
> > + goto retry_check;
> > + }
> > + }
> > +
> > + ret = 0;
> > +exit:
> > + release_firmware(fw);
> > +
> > + return ret;
> > +}
> > +
> > +static int rcar_gen4_pcie_enable_phy(struct rcar_gen4_pcie *rcar)
> > +{
> > + struct dw_pcie *dw = &rcar->dw;
> > + u32 val;
> > + int ret;
> > +
> > + val = dw_pcie_readl_dbi(dw, PCIE_PORT_FORCE);
> > + val |= PORT_FORCE_DO_DESKEW_FOR_SRIS;
> > + dw_pcie_writel_dbi(dw, PCIE_PORT_FORCE, val);
> > +
> > + val = readl(rcar->base + PCIEMSR0);
> > + val |= APP_SRIS_MODE;
> > + writel(val, rcar->base + PCIEMSR0);
> > +
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x700, BIT(28), 0);
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x700, BIT(20), 0);
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x700, BIT(12), 0);
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x700, BIT(4), 0);
> > +
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(23, 22), BIT(22));
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(18, 16), GENMASK(17, 16));
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(7, 6), BIT(6));
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(2, 0), GENMASK(11, 0));
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x1d4, GENMASK(16, 15), GENMASK(16, 15));
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x514, BIT(26), BIT(26));
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x0f8, BIT(16), 0);
> > + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x0f8, BIT(19), BIT(19));
> > +
> > + val = readl(rcar->base + PCIERSTCTRL1);
> > + val &= ~APP_HOLD_PHY_RST;
> > + writel(val, rcar->base + PCIERSTCTRL1);
> > +
> > + ret = readl_poll_timeout(rcar->phy_base + 0x0f8, val, !(val & BIT(18)),
> > + 100, 10000);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = rcar_gen4_pcie_update_phy_firmware(rcar);
> > + if (ret)
> > + return ret;
> > +
> > + val = readl(rcar->base + PCIERSTCTRL1);
> > + val |= APP_LTSSM_ENABLE;
> > + writel(val, rcar->base + PCIERSTCTRL1);
> > +
> > + return 0;
> > +}
> > +
> > static void rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar,
> > bool enable)
> > {
> > @@ -201,6 +350,9 @@ static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
> > if (ret)
> > goto err_unprepare;
> >
> > + if (rcar->additional_common_init)
> > + rcar->additional_common_init(rcar);
> >
> > return 0;
> >
> > err_unprepare:
> > @@ -242,6 +394,10 @@ static void rcar_gen4_pcie_unprepare(struct rcar_gen4_pcie *rcar)
> >
> > static int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar)
> > {
> > + rcar->phy_base = devm_platform_ioremap_resource_byname(rcar->pdev, "phy");
> > + if (IS_ERR(rcar->phy_base))
> > + return PTR_ERR(rcar->base);
>
> I don't get it. This imposes a new requirement (presence of "phy"
> resource) on the existing SoCs. That doesn't sound right.
According to the dt-binding doc, the existing SoCs are also required for the "phy".
That's why I didn't add any condition to simplify the code.
> > /* Renesas-specific registers */
> > rcar->base = devm_platform_ioremap_resource_byname(rcar->pdev, "app");
> >
> > @@ -452,6 +608,7 @@ static int rcar_gen4_add_dw_pcie(struct rcar_gen4_pcie *rcar)
> >
> > rcar->mode = pd->mode;
> > rcar->start_link_enable = pd->start_link_enable;
> > + rcar->additional_common_init = pd->additional_common_init;
> >
> > switch (rcar->mode) {
> > case DW_PCIE_RC_TYPE:
> > @@ -521,6 +678,31 @@ static int r8a779f0_pcie_start_link_enable(struct rcar_gen4_pcie *rcar)
> > return 0;
> > }
> >
> > +static int rcar_gen4_pcie_start_link_enable(struct rcar_gen4_pcie *rcar)
> > +{
> > + return rcar_gen4_pcie_enable_phy(rcar);
> > +}
> > +
> > +static void rcar_gen4_pcie_additional_common_init(struct rcar_gen4_pcie *rcar)
> > +{
> > + struct dw_pcie *dw = &rcar->dw;
> > + u32 val;
> > +
> > + /*
> > + * The SoC manual said the register setting is required. Otherwise,
> > + * linkup failed.
> > + */
> > + val = dw_pcie_readl_dbi(dw, PCIE_PORT_LANE_SKEW);
> > + val &= ~PORT_LANE_SKEW_INSERT_MASK;
> > + if (dw->num_lanes < 4)
> > + val |= BIT(6);
> > + dw_pcie_writel_dbi(dw, PCIE_PORT_LANE_SKEW, val);
> > +
> > + val = readl(rcar->base + PCIEPWRMNGCTRL);
> > + val |= APP_CLK_REQ_N | APP_CLK_PM_EN;
> > + writel(val, rcar->base + PCIEPWRMNGCTRL);
>
> I don't get this either. You do this "additional_common_init" part
> only for the existing "renesas,rcar-gen4-pcie" and
> "renesas,rcar-gen4-pcie-ep", but PCIE_PORT_LANE_SKEW and
> PCIEPWRMNGCTRL do not appear in the driver prior to these patches. I
> must be missing something. Or this is backwards and you meant to do
> this for the *new* SoC?
I'm sorry for the confusion. This is for the new SoC.
I should have explained before though, existing support SoC is:
- r8a779f0 as "renesas,rcar-gen4-pcie" and "renesas,rcar-gen4-pcie-ep".
After we applied the patch series:
- r8a779f0 as "renesas,r8a779f0-pcie" and "renesas,r8a779f0-pcie-ep".
- r8a779g0 as "renesas,rcar-gen4-pcie" and "renesas,rcar-gen4--pcie-ep".
Also, I have a plan to add r8a779h0 support in the future:
- r8a779f0 as "renesas,r8a779f0-pcie" and "renesas,r8a779f0-pcie-ep".
- r8a779g0 as "renesas,rcar-gen4-pcie" and "renesas,rcar-gen4--pcie-ep".
- r8a779h0 as "renesas,rcar-gen4-pcie" and "renesas,rcar-gen4--pcie-ep".
And r8a779[gh]0 need this additional_common_init.
> If you need to limit some functionality to existing SoCs and add new
> functionality for new SoCs, do those in separate patches if you can.
I got it. I'll make such a patch if I can.
Best regards,
Yoshihiro Shimoda
> > +}
> > +
> > static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie = {
> > .mode = DW_PCIE_RC_TYPE,
> > .start_link_enable = r8a779f0_pcie_start_link_enable,
> > @@ -533,10 +715,14 @@ static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie_ep = {
> >
> > static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
> > .mode = DW_PCIE_RC_TYPE,
> > + .start_link_enable = rcar_gen4_pcie_start_link_enable,
> > + .additional_common_init = rcar_gen4_pcie_additional_common_init,
> > };
> >
> > static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
> > .mode = DW_PCIE_EP_TYPE,
> > + .start_link_enable = rcar_gen4_pcie_start_link_enable,
> > + .additional_common_init = rcar_gen4_pcie_additional_common_init,
> > };
> >
> > static const struct of_device_id rcar_gen4_pcie_of_match[] = {
> > --
> > 2.25.1
> >
^ permalink raw reply
* [PATCH v2 2/2] dmaengine: dw-axi-dmac: Add support for StarFive JH8100 DMA
From: Tan Chun Hau @ 2024-03-27 2:51 UTC (permalink / raw)
To: Eugeniy Paltsev, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ley Foon Tan, Jee Heng Sia, dmaengine, devicetree, linux-kernel
In-Reply-To: <20240327025126.229475-1-chunhau.tan@starfivetech.com>
JH8100 requires reset operation only in device probe.
Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
---
drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index a86a81ff0caa..abb3523ba8ab 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -1653,6 +1653,9 @@ static const struct of_device_id dw_dma_of_id_table[] = {
}, {
.compatible = "starfive,jh7110-axi-dma",
.data = (void *)(AXI_DMA_FLAG_HAS_RESETS | AXI_DMA_FLAG_USE_CFG2),
+ }, {
+ .compatible = "starfive,jh8100-axi-dma",
+ .data = (void *)AXI_DMA_FLAG_HAS_RESETS,
},
{}
};
--
2.25.1
^ permalink raw reply related
* [PATCH v2 0/2] Add JH8100 support for snps,dw-axi-dmac
From: Tan Chun Hau @ 2024-03-27 2:51 UTC (permalink / raw)
To: Eugeniy Paltsev, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ley Foon Tan, Jee Heng Sia, dmaengine, devicetree, linux-kernel
Add StarFive JH8100 DMA support.
Changes in v2:
- Amended commit message according to feedback.
Tan Chun Hau (2):
dt-bindings: dma: snps,dw-axi-dmac: Add JH8100 support
dmaengine: dw-axi-dmac: Add support for StarFive JH8100 DMA
Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml | 1 +
drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 3 +++
2 files changed, 4 insertions(+)
--
2.25.1
^ permalink raw reply
* Re: [PATCH] dt-bindings: crypto: ti,omap-sham: Convert to dtschema
From: Animesh Agarwal @ 2024-03-27 5:17 UTC (permalink / raw)
To: Conor Dooley
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20240326-spectrum-talon-0fc977c32c5c@spud>
On Tue, Mar 26, 2024 at 11:50 PM Conor Dooley <conor@kernel.org> wrote:
> Is there really only one value possible here?
There aren't any ti,hwmod properties with value other than "sham" at
least in arch/arm/boot/dts/ti/omap for this module.
> Also, the convention is to put vendor properties like this after more
> common properties like reg, interrupts etc.
Thanks for letting me know I'll change it.
Thanks and Regards
Animesh Agarwal
^ permalink raw reply
* Re: 回复: [PATCH v2 1/2] ASoC: dt-bindings: Add bindings for Cadence I2S-MC controller
From: Krzysztof Kozlowski @ 2024-03-27 5:12 UTC (permalink / raw)
To: Xingyu Wu, Liam Girdwood, Mark Brown, Claudiu Beznea,
Jaroslav Kysela, Takashi Iwai, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org, linux-sound@vger.kernel.org
In-Reply-To: <NTZPR01MB0956230296D881F112F92D119F35A@NTZPR01MB0956.CHNPR01.prod.partner.outlook.cn>
On 26/03/2024 14:43, Xingyu Wu wrote:
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + enum:
>>>>> + - cdns,i2s-mc
>>>>
>>>> Why did this appear? Who asked for this? Usually these blocks are not
>>>> usable on their own.
>>>
>>> I wonder if I should keep the original IP compatible. Do I not need it?
>>
>> As I said, it is not usable on its own, so unless you have other arguments then no.
>> But my point was that no one asked for this.
>
> I want to keep the original IP compatible which can distinguish from the JH8100 SoC.
> Can I write it like this:
> compatible:
> enum:
> - starfive,jh8100-i2s
> const: cdns,i2s-mc
>
> and I write this in the DTS:
> compatible = "starfive,jh8100-i2s", "cdns,i2s-mc";
Can you provide any rationale for this? I asked "unless you have other
arguments", so where are the arguments?
Nothing was explained in patch changelog. Nothing was provided in this
email thread.
>
>>
>>>
>>>>
>>>>> + - starfive,jh8100-i2s
>>>>> +
>>>>> + reg:
>>>>> + maxItems: 1
>>>>> +
>>>>> + interrupts:
>>>>> + description:
>>>>> + The interrupt line number for the I2S controller. Add this
>>>>> + parameter if the I2S controller that you are using does not
>>>>> + using DMA.
>>>>
>>>> That's still wrong. You already got comment on this. Either you have interrupt
>> or not.
>>>> You do not add interrupts, based on your choice or not of having DMA.
>>>> Drop the comment.
>>>
>>> Do I keep this property and drop this description?
>>
>> Drop description. Keep property, if your hardware has interrupts.
>>
>
> Will drop.
>
>> ...
>>
>>>>
>>>>> + - compatible
>>>>> + - reg
>>>>> + - clocks
>>>>> + - clock-names
>>>>> + - resets
>>>>> +
>>>>> +oneOf:
>>>>> + - required:
>>>>> + - dmas
>>>>> + - dma-names
>>>>> + - required:
>>>>> + - interrupts
>>>>
>>>> This won't work. Provide both interrupts and dmas, and then test your DTS.
>>>
>>> I provided both properties in the DTS and test by dtbs_check. Then it printed
>> that:
>>> 'More than one condition true in one of shema: ...'
>>
>> Exactly. Having both properties is a correct DTS. Interrupts do not disappear just
>> because you decide to describe DMA. It is OS choice what to use if both are
>> provided.
>>
>
> But this I2S can only use either DMA or interrupts.
Just like many other components. DTS should reflect hardware. Hardware
has interrupts and DMA, right?
>
> Can I use the config (like SND_SOC_CADENCE_I2S_MC_PCM) to choose DMA or
> interrupt if having both them in DTS?
Don't know, I tend to focus here on bindings.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 00/38] ep93xx device tree conversion
From: Krzysztof Kozlowski @ 2024-03-27 5:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: nikita.shubin, Hartley Sweeten, Alexander Sverdlin, Russell King,
Lukasz Majewski, Linus Walleij, Bartosz Golaszewski,
Michael Turquette, Stephen Boyd, Sebastian Reichel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Wim Van Sebroeck,
Guenter Roeck, Thierry Reding, Uwe Kleine-König, Mark Brown,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Damien Le Moal, Sergey Shtylyov, Dmitry Torokhov, Liam Girdwood,
Jaroslav Kysela, Takashi Iwai, Ralf Baechle, Wu, Aaron, Lee Jones,
Olof Johansson, Niklas Cassel, linux-arm-kernel, linux-kernel,
linux-gpio, linux-clk, linux-pm, devicetree, dmaengine,
linux-watchdog, linux-pwm, linux-spi, netdev, linux-mtd,
linux-ide, linux-input, linux-sound, Arnd Bergmann,
Bartosz Golaszewski, Andrew Lunn
In-Reply-To: <ZgLgY11N8dkpTZJB@smile.fi.intel.com>
On 26/03/2024 15:49, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 11:19:54AM +0100, Krzysztof Kozlowski wrote:
>> On 26/03/2024 10:18, Nikita Shubin via B4 Relay wrote:
>>> The goal is to recieve ACKs for all patches in series to merge it via Arnd branch.
>>>
>>> Some changes since last version (v8):
>>>
>>> - Most important, fixed bug in Device Tree resulting in CS4271 not working by Alexander Sverdlin.
>>> - added #interrupt-cells to gpio nodes with interrupts-controller
>>> - fixed some EOF in dtsi files
>>> - fixed identation and type in ep93xx-keypad thanks to Andy Shevchenko
>>>
>>> Stephen Boyd, Vinod Koul PLEASE! give some comments on following, couse i hadn't one for a couple of iterations already:
>>>
>>> Following patches require attention from Stephen Boyd, as they were converted to aux_dev as suggested:
>>>
>>> - ARM: ep93xx: add regmap aux_dev
>>> - clk: ep93xx: add DT support for Cirrus EP93xx
>>>
>>> Following patches require attention from Vinod Koul:
>>>
>>> - dma: cirrus: Convert to DT for Cirrus EP93xx
>>> - dma: cirrus: remove platform code
>>
>> A lot of this could have been already merged if you split it... Just
>> saying...
>
> But you able to apply DT schema patches if you wish.
> Just doing? :-)
Me? Why? DT bindings are supposed to go via subsystem maintainers, not
DT tree. Plus, I do not apply any bindings patches, except for managed
subsystems and none of them are touched here.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v2 4/6] PCI: dwc: rcar-gen4: Add a new function pointer for other SoC support
From: Yoshihiro Shimoda @ 2024-03-27 5:06 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
bhelgaas@google.com, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, mani@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <20240326202116.GA1492492@bhelgaas>
Hi Bjorn,
> From: Bjorn Helgaas, Sent: Wednesday, March 27, 2024 5:21 AM
>
> Include the function pointer name in the subject so it's a little more
> specific.
I got it. I'll change the subject.
> On Tue, Mar 26, 2024 at 11:45:38AM +0900, Yoshihiro Shimoda wrote:
> > This driver can reuse other R-Car Gen4 SoC support. However, some
> > initializing settings differs between r8a779f0 and others. So, add
> > a new function pointer start_link_enable() to support other R-Car
> > Gen4 SoC in the future. No behavior changes.
>
> Make it clear here what the new SoC is. I think it's r8a779f0, but
> you have to read the patch and look for the new .compatible string to
> figure that out.
I got it. The new SoC is r8a779g0. So, I should add such description here.
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > ---
> > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 57 +++++++++++++++++++--
> > 1 file changed, 52 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > index 0be760ed420b..a37613dd9ff4 100644
> > --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > @@ -53,9 +53,16 @@ struct rcar_gen4_pcie {
> > void __iomem *base;
> > struct platform_device *pdev;
> > enum dw_pcie_device_mode mode;
> > +
> > + int (*start_link_enable)(struct rcar_gen4_pcie *rcar);
> > };
> > #define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
> >
> > +struct rcar_gen4_pcie_platdata {
> > + enum dw_pcie_device_mode mode;
> > + int (*start_link_enable)(struct rcar_gen4_pcie *rcar);
>
> I think it's confusing to repeat "mode" and "start_link_enable" in
> both rcar_gen4_pcie and rcar_gen4_pcie_platdata. I know several other
> drivers use this pattern, but I think it is simpler overall to just
> save the pointer directly, e.g.,
>
> imx6_pcie_probe
> imx6_pcie->drvdata = of_device_get_match_data(dev);
>
> ls_pcie_probe
> pcie->drvdata = of_device_get_match_data(dev);
>
> tegra_pcie_dw_probe
> data = of_device_get_match_data(dev);
> pcie->of_data = (struct tegra_pcie_dw_of_data *)data;
>
> So I think the best thing would be to add struct
> rcar_gen4_pcie_platdata, *move* rcar_gen4_pcie.mode there, and save a
> pointer to the rcar_gen4_pcie_platdata in struct rcar_gen4_pcie.
I got it. I'll modify the patch.
> That could be its own separate patch, which is nice on its own because
> it gets rid of the (void *) casts in rcar_gen4_pcie_of_match[].
>
> Then add .start_link_enable() (or .ltssm_enable(), see below) and the
> r8a779f0 bits in another patch.
I got it. I'll make such a patch at first.
> > +};
> > +
> > /* Common */
> > static void rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar,
> > bool enable)
> > @@ -123,9 +130,13 @@ static int rcar_gen4_pcie_speed_change(struct dw_pcie *dw)
> > static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
> > {
> > struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> > - int i, changes;
> > + int i, changes, ret;
> >
> > - rcar_gen4_pcie_ltssm_enable(rcar, true);
> > + if (rcar->start_link_enable) {
> > + ret = rcar->start_link_enable(rcar);
>
> This looks basically like what qcom does:
>
> qcom_pcie_start_link
> if (pcie->cfg->ops->ltssm_enable)
> pcie->cfg->ops->ltssm_enable(pcie)
>
> Can you copy that and use the same name for the pointer and function
> name (.ltssm_enable, .*_ltssm_enable())?
Yes, I can. I'll rename the pointer and function.
> > + if (ret)
> > + return ret;
> > + }
> >
> > /*
> > * Require direct speed change with retrying here if the link_gen is
> > @@ -437,7 +448,10 @@ static void rcar_gen4_remove_dw_pcie_ep(struct rcar_gen4_pcie *rcar)
> > /* Common */
> > static int rcar_gen4_add_dw_pcie(struct rcar_gen4_pcie *rcar)
> > {
> > - rcar->mode = (uintptr_t)of_device_get_match_data(&rcar->pdev->dev);
> > + const struct rcar_gen4_pcie_platdata *pd = of_device_get_match_data(&rcar->pdev->dev);
> > +
> > + rcar->mode = pd->mode;
> > + rcar->start_link_enable = pd->start_link_enable;
> >
> > switch (rcar->mode) {
> > case DW_PCIE_RC_TYPE:
> > @@ -500,14 +514,47 @@ static void rcar_gen4_pcie_remove(struct platform_device *pdev)
> > rcar_gen4_pcie_unprepare(rcar);
> > }
> >
> > +static int r8a779f0_pcie_start_link_enable(struct rcar_gen4_pcie *rcar)
> > +{
> > + rcar_gen4_pcie_ltssm_enable(rcar, true);
>
> Previously we called rcar_gen4_pcie_ltssm_enable() for
> "renesas,rcar-gen4-pcie" and "renesas,rcar-gen4-pcie-ep". But after
> this patch, it looks like we only call it for "renesas,r8a779f0-pcie"
> and "renesas,r8a779f0-pcie-ep"?
Yes.
Best regards,
Yoshihiro Shimoda
> > +
> > + return 0;
> > +}
> > +
> > +static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie = {
> > + .mode = DW_PCIE_RC_TYPE,
> > + .start_link_enable = r8a779f0_pcie_start_link_enable,
> > +};
> > +
> > +static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie_ep = {
> > + .mode = DW_PCIE_EP_TYPE,
> > + .start_link_enable = r8a779f0_pcie_start_link_enable,
> > +};
> > +
> > +static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
> > + .mode = DW_PCIE_RC_TYPE,
> > +};
> > +
> > +static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
> > + .mode = DW_PCIE_EP_TYPE,
> > +};
> > +
> > static const struct of_device_id rcar_gen4_pcie_of_match[] = {
> > + {
> > + .compatible = "renesas,r8a779f0-pcie",
> > + .data = &platdata_r8a779f0_pcie,
> > + },
> > + {
> > + .compatible = "renesas,r8a779f0-pcie-ep",
> > + .data = &platdata_r8a779f0_pcie_ep,
> > + },
> > {
> > .compatible = "renesas,rcar-gen4-pcie",
> > - .data = (void *)DW_PCIE_RC_TYPE,
> > + .data = &platdata_rcar_gen4_pcie,
> > },
> > {
> > .compatible = "renesas,rcar-gen4-pcie-ep",
> > - .data = (void *)DW_PCIE_EP_TYPE,
> > + .data = &platdata_rcar_gen4_pcie_ep,
> > },
> > {},
> > };
> > --
> > 2.25.1
> >
^ permalink raw reply
* Re: [PATCH v4 4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire
From: Krzysztof Kozlowski @ 2024-03-27 5:02 UTC (permalink / raw)
To: Lothar Rubusch
Cc: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <CAFXKEHYMiARxrN7=jqnJtEVREseZ-zmZmVeY1uNXZV6viwHbmw@mail.gmail.com>
On 26/03/2024 21:17, Lothar Rubusch wrote:
>>>
>>> V1: The first version of the 3wire patch. I have split the single
>>> patch upon some feedback (yours?!) - V2... So, my current
>>> interpretation is, that every feedback I need to mention as
>>> Reviewed-by tag, no?
>>
>> What? Feedback is not review. It's clearly explained in submitting
>> patches. Please read it.
>>
>
> Exactly. My missunderstanding here is this: Why did you send me a
> reminder that I forgot to add "Reviewed-by" tag in your last mail?
> Could you please clarify your last mail? You wrote:
> "(...)
> This is a friendly reminder during the review process.
>
> It looks like you received a tag and forgot to add it.
>
> If you do not know the process, here is a short explanation:
> Please add Acked-by/Reviewed-by/Tested-by tags when posting new
> versions, (...)"
>
> AFAIK noone literally had told me: "please add a Reviewed-by me tag",
> or did I miss something? I'm a bit lost here, sorry.
>
What was this then:
https://lore.kernel.org/all/9700cc88-bddb-480d-9417-04b2ff539a2f@linaro.org/
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v2 6/6] misc: pci_endpoint_test: Add Device ID for R-Car V4H PCIe controller
From: Yoshihiro Shimoda @ 2024-03-27 5:02 UTC (permalink / raw)
To: Frank Li
Cc: lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
bhelgaas@google.com, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, mani@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Geert Uytterhoeven
In-Reply-To: <ZgLW6CGYfUW6Uskz@lizhi-Precision-Tower-5810>
Hi Frank,
> From: Frank Li, Sent: Tuesday, March 26, 2024 11:09 PM
>
> On Tue, Mar 26, 2024 at 05:47:23AM +0000, Yoshihiro Shimoda wrote:
> > Hi Frank,
> >
> > > From: Frank Li, Sent: Tuesday, March 26, 2024 12:21 PM
> >
> > > On Tue, Mar 26, 2024 at 11:45:40AM +0900, Yoshihiro Shimoda wrote:
> > > > Add Renesas R8A779G0 in pci_device_id table so that pci-epf-test
> > > > can be used for testing PCIe EP on R-Car V4H.
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > ---
> > > > drivers/misc/pci_endpoint_test.c | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
> > > > index c38a6083f0a7..2fa3c6473c7d 100644
> > > > --- a/drivers/misc/pci_endpoint_test.c
> > > > +++ b/drivers/misc/pci_endpoint_test.c
> > > > @@ -83,6 +83,7 @@
> > > > #define PCI_DEVICE_ID_RENESAS_R8A774C0 0x002d
> > > > #define PCI_DEVICE_ID_RENESAS_R8A774E1 0x0025
> > > > #define PCI_DEVICE_ID_RENESAS_R8A779F0 0x0031
> > > > +#define PCI_DEVICE_ID_RENESAS_R8A779G0 0x0030
> > > >
> > > > static DEFINE_IDA(pci_endpoint_test_ida);
> > > >
> > > > @@ -1005,6 +1006,9 @@ static const struct pci_device_id pci_endpoint_test_tbl[] = {
> > > > { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A779F0),
> > > > .driver_data = (kernel_ulong_t)&default_data,
> > > > },
> > > > + { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A779G0),
> > > > + .driver_data = (kernel_ulong_t)&default_data,
> > > > + },
> > >
> > > You use default_data, why need new device_id? I think you can use 0x0031
> > > to do test.
> >
> > I thought we can add a new device_id freely like other devices.
> > Since the PCIe controller's endpoint mode can configure the device id,
> > I can use 0x0031 to do test though.
> >
> > If such a reusable entry exists, is adding a new device id into the driver prohibited?
>
> I just think it is not necessary. This list will become longer and longer.
> And difference device id can't help us at all.
I agreed. To record it, I'll make a patch to add such description in the pci_endpoint_test.c.
> We should use difference production as difference functions, or difference
> configuration. Such as usb gadget product id, we use 0x4545 for all mass
> storage.
I see.
> Using difference devices id for difference function, such as 0x31 for
> ep_test 0x30 for virtual net, 0x29 for virtual console ...
>
> Or using difference devices id indicate some features. For example, use
> 0x30 means support write to EP MSI ITS to trigger irq.
>
> Donate a device_id to more valuable things.
I think so.
Best regards,
Yoshihiro Shimoda
> Frank
>
> >
> > Best regards,
> > Yoshihiro Shimoda
> >
> > > Frank
> > >
> > > > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_J721E),
> > > > .driver_data = (kernel_ulong_t)&j721e_data,
> > > > },
> > > > --
> > > > 2.25.1
> > > >
^ permalink raw reply
* Re: [PATCH 4/5] dt-bindings: arm: Add Au-Zone Maivin AI Vision Starter Kit
From: Krzysztof Kozlowski @ 2024-03-27 5:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Li Yang
In-Reply-To: <20240327010156.GD14986@pendragon.ideasonboard.com>
On 27/03/2024 02:01, Laurent Pinchart wrote:
> Hi Krzysztof,
>
> On Tue, Mar 26, 2024 at 08:11:34AM +0100, Krzysztof Kozlowski wrote:
>> On 25/03/2024 21:32, Laurent Pinchart wrote:
>>> The Maivin board is an AI vision starter kit sold by Au-Zone
>>> Technologies, developed in collaboration with Toradex and Vision
>>> Components. It is based on a Toradex Verdin i.MX8MP SoM.
>>>
>>> Add a corresponding compatible string.
>>>
>>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
>>> index 0027201e19f8..d892c4f9fda3 100644
>>> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
>>> @@ -1064,6 +1064,13 @@ properties:
>>> - toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules
>>> - const: fsl,imx8mp
>>>
>>> + - description: Au-Zone Technologies i.MX8MP-based boards
>>> + items:
>>> + - const: au-zone,maivin-starter-kit # Au-Zone Maivin AI Vision Starter Kit
>>> + - const: toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Module without Wi-Fi / BT
>>> + - const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
>>
>> I think this should be part of existing "Toradex Boards with Verdin
>> iMX8M Plus Modules)", just renamed to "boards using Toradex Verdin ...".
>
> Is this what you have in mind ?
>
Yes.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: ata: ahci-da850: Convert to dtschema
From: Animesh Agarwal @ 2024-03-27 4:55 UTC (permalink / raw)
To: Conor Dooley
Cc: Damien Le Moal, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-ide, devicetree, linux-kernel
In-Reply-To: <20240326-rerun-flap-6d827f654453@spud>
On Tue, Mar 26, 2024 at 11:44 PM Conor Dooley <conor@kernel.org> wrote:
> Could you make this an items list with a pair of text descriptions
> please? The original text binding's text for each can be reused.
>
Sure I'll do it.
Thanks and regards
Animesh
^ permalink raw reply
* Re: [PATCH] dt-bindings: ata: ahci-da850: Convert to dtschema
From: Animesh Agarwal @ 2024-03-27 4:54 UTC (permalink / raw)
To: Damien Le Moal
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-ide,
devicetree, linux-kernel
In-Reply-To: <7567a9b5-fd6d-4729-964e-14c4e129bcd7@kernel.org>
Sorry for the typo, I'll add it.
On Tue, Mar 26, 2024 at 5:55 PM Damien Le Moal <dlemoal@kernel.org> wrote:
>
> On 3/26/24 21:17, Animesh Agarwal wrote:
> > Convert the ahci-da850 bindings to DT schema
>
> Missing a period at the end of the sentence.
>
> >
> > Signed-off-by: Animesh Agarwal <animeshagarwal28@gmail.com>
> > ---
> > .../devicetree/bindings/ata/ahci-da850.txt | 18 ----------
> > .../bindings/ata/ti,da850-ahci.yaml | 36 +++++++++++++++++++
> > 2 files changed, 36 insertions(+), 18 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
> > create mode 100644 Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt
> > deleted file mode 100644
> > index 5f8193417725..000000000000
> > --- a/Documentation/devicetree/bindings/ata/ahci-da850.txt
> > +++ /dev/null
> > @@ -1,18 +0,0 @@
> > -Device tree binding for the TI DA850 AHCI SATA Controller
> > ----------------------------------------------------------
> > -
> > -Required properties:
> > - - compatible: must be "ti,da850-ahci"
> > - - reg: physical base addresses and sizes of the two register regions
> > - used by the controller: the register map as defined by the
> > - AHCI 1.1 standard and the Power Down Control Register (PWRDN)
> > - for enabling/disabling the SATA clock receiver
> > - - interrupts: interrupt specifier (refer to the interrupt binding)
> > -
> > -Example:
> > -
> > - sata: sata@218000 {
> > - compatible = "ti,da850-ahci";
> > - reg = <0x218000 0x2000>, <0x22c018 0x4>;
> > - interrupts = <67>;
> > - };
> > diff --git a/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml b/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
> > new file mode 100644
> > index 000000000000..d54f58c12e78
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
> > @@ -0,0 +1,36 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/ata/ti,da850-ahci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: TI DA850 AHCI SATA Controller
> > +
> > +maintainers:
> > + - Animesh Agarwal <animeshagarwal28@gmail.com>
> > +
> > +properties:
> > + compatible:
> > + const: ti,da850-ahci
> > +
> > + reg:
> > + minItems: 2
> > + maxItems: 2
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + sata@218000 {
> > + compatible = "ti,da850-ahci";
> > + reg = <0x218000 0x2000>, <0x22c018 0x4>;
> > + interrupts = <67>;
> > + };
>
> --
> Damien Le Moal
> Western Digital Research
>
^ permalink raw reply
* Re: [PATCH v2 0/3] QCM2290 LMH
From: Krzysztof Kozlowski @ 2024-03-27 4:04 UTC (permalink / raw)
To: Nícolas F. R. A. Prado
Cc: Konrad Dybcio, Bjorn Andersson, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thara Gopinath, Amit Kucheria, Marijn Suijten,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
Dmitry Baryshkov, stable, Loic Poulain
In-Reply-To: <33cb5ab6-1b15-4903-a5fa-f0d2f86fb438@notapiano>
On 26/03/2024 15:07, Nícolas F. R. A. Prado wrote:
>> Other reports, like for cases when only parts of patch is applied, could
>> be also useful but I am afraid you will generate way too much of them.
>> Binding is supposed to go via subsystem, DTS via SoC, so basically 90%
>> of patchsets might have some sort of delays resulting in dtbs_check
>> false positive warnings.
>>
>> For my SoC I check my trees, mainline and next, and keep adding list of
>> exceptions for expected issues. What's useful for Qualcomm? Konrad,
>
> Is that list of exceptions in-tree? If there are known false-positives (issues
None of the warnings - C, sparse, smatch, coccinelle, Coverity, dtc,
dtbs_check - are stored in-tree. I don't think dtbs_check should be here
exception, because all these warnings can be fixed - it's just a matter
of effort. ARM64 Exynos is warning free since a year. ARM Exynos
similarly, but with one undocumented compatible and few bumps due to
intra-cycle DTS changes.
> that can't be "properly" fixed), they should be public knowledge. And if we all
They are "public":
https://github.com/krzk/tools/blob/master/buildbot/master_build_common.py#L26
but I don't know how to make them public and usable knowledge.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 6/8] cpufreq: sun50i: Add H616 support
From: Samuel Holland @ 2024-03-27 3:46 UTC (permalink / raw)
To: Andre Przywara
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin, Mark Rutland, Lorenzo Pieralisi, Sudeep Holla,
Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Rafael J . Wysocki
In-Reply-To: <20240326114743.712167-7-andre.przywara@arm.com>
Hi Andre,
On 3/26/24 06:47, Andre Przywara wrote:
> From: Martin Botka <martin.botka@somainline.org>
>
> The Allwinner H616/H618 SoCs have different OPP tables per SoC version
> and die revision. The SoC version is stored in NVMEM, as before, though
> encoded differently. The die revision is in a different register, in the
> SRAM controller. Firmware already exports that value in a standardised
> way, through the SMCCC SoCID mechanism. We need both values, as some chips
> have the same SoC version, but they don't support the same frequencies and
> they get differentiated by the die revision.
>
> Add the new compatible string and tie the new translation function to
> it. This mechanism not only covers the original H616 SoC, but also its
> very close sibling SoCs H618 and H700, so add them to the list as well.
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> drivers/cpufreq/sun50i-cpufreq-nvmem.c | 61 ++++++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
>
> diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> index bd170611c7906..f9e9fc340f848 100644
> --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> @@ -10,6 +10,7 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include <linux/arm-smccc.h>
> #include <linux/cpu.h>
> #include <linux/module.h>
> #include <linux/nvmem-consumer.h>
> @@ -46,14 +47,71 @@ static u32 sun50i_h6_efuse_xlate(u32 speedbin)
> return 0;
> }
>
> +/*
> + * Judging by the OPP tables in the vendor BSP, the quality order of the
> + * returned speedbin index is 4 -> 0/2 -> 3 -> 1, from worst to best.
> + * 0 and 2 seem identical from the OPP tables' point of view.
> + */
> +static u32 sun50i_h616_efuse_xlate(u32 speedbin)
> +{
> + int ver_bits = arm_smccc_get_soc_id_revision();
This needs a Kconfig dependency on ARM_SMCCC_SOC_ID.
Regards,
Samuel
> + u32 value = 0;
> +
> + switch (speedbin & 0xffff) {
> + case 0x2000:
> + value = 0;
> + break;
> + case 0x2400:
> + case 0x7400:
> + case 0x2c00:
> + case 0x7c00:
> + if (ver_bits != SMCCC_RET_NOT_SUPPORTED && ver_bits <= 1) {
> + /* ic version A/B */
> + value = 1;
> + } else {
> + /* ic version C and later version */
> + value = 2;
> + }
> + break;
> + case 0x5000:
> + case 0x5400:
> + case 0x6000:
> + value = 3;
> + break;
> + case 0x5c00:
> + value = 4;
> + break;
> + case 0x5d00:
> + value = 0;
> + break;
> + case 0x6c00:
> + value = 5;
> + break;
> + default:
> + pr_warn("sun50i-cpufreq-nvmem: unknown speed bin 0x%x, using default bin 0\n",
> + speedbin & 0xffff);
> + value = 0;
> + break;
> + }
> +
> + return value;
> +}
> +
> static struct sunxi_cpufreq_data sun50i_h6_cpufreq_data = {
> .efuse_xlate = sun50i_h6_efuse_xlate,
> };
>
> +static struct sunxi_cpufreq_data sun50i_h616_cpufreq_data = {
> + .efuse_xlate = sun50i_h616_efuse_xlate,
> +};
> +
> static const struct of_device_id cpu_opp_match_list[] = {
> { .compatible = "allwinner,sun50i-h6-operating-points",
> .data = &sun50i_h6_cpufreq_data,
> },
> + { .compatible = "allwinner,sun50i-h616-operating-points",
> + .data = &sun50i_h616_cpufreq_data,
> + },
> {}
> };
>
> @@ -230,6 +288,9 @@ static struct platform_driver sun50i_cpufreq_driver = {
>
> static const struct of_device_id sun50i_cpufreq_match_list[] = {
> { .compatible = "allwinner,sun50i-h6" },
> + { .compatible = "allwinner,sun50i-h616" },
> + { .compatible = "allwinner,sun50i-h618" },
> + { .compatible = "allwinner,sun50i-h700" },
> {}
> };
> MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
^ permalink raw reply
* RE: [PATCH v4 0/7] crypto: starfive: Add support for JH8100
From: JiaJie Ho @ 2024-03-27 1:55 UTC (permalink / raw)
To: 'Herbert Xu', 'David S . Miller',
'Rob Herring', 'Krzysztof Kozlowski',
'Conor Dooley', 'Eugeniy Paltsev',
'Vinod Koul', 'linux-crypto@vger.kernel.org',
'devicetree@vger.kernel.org',
'linux-kernel@vger.kernel.org',
'dmaengine@vger.kernel.org'
In-Reply-To: <20240305071006.2181158-1-jiajie.ho@starfivetech.com>
> This patch series add driver support for StarFive JH8100 SoC crypto engine.
> Patch 1 adds compatible string and update irq descriptions for
> JH8100 device. Subsequent patches update current driver implementations to
> support both 7110 and 8100 variants.
>
> v3->v4:
> - Updated interrupts descriptions for jh8100-crypto compatible. (Rob)
> - Added patch 3 to skip unneeded key freeing for RSA module.
>
> v2->v3:
> - Use of device data instead of #ifdef CONFIG_ for different device
> variants.
> - Updated dt bindings compatible and interrupts descriptions.
> - Added patch 4 to support hardware quirks for dw-axi-dmac driver.
>
> v1->v2:
> - Resolved build warnings reported by kernel test robot
> https://lore.kernel.org/oe-kbuild-all/202312170614.24rtwf9x-
> lkp@intel.com/
>
> Jia Jie Ho (7):
> dt-bindings: crypto: starfive: Add jh8100 support
> crypto: starfive: Update hash dma usage
> crypto: starfive: Skip unneeded key free
> crypto: starfive: Use dma for aes requests
> dmaengine: dw-axi-dmac: Support hardware quirks
> crypto: starfive: Add sm3 support for JH8100
> crypto: starfive: Add sm4 support for JH8100
>
> .../crypto/starfive,jh7110-crypto.yaml | 30 +-
> drivers/crypto/starfive/Kconfig | 30 +-
> drivers/crypto/starfive/Makefile | 5 +-
> drivers/crypto/starfive/jh7110-aes.c | 592 ++++++---
> drivers/crypto/starfive/jh7110-cryp.c | 77 +-
> drivers/crypto/starfive/jh7110-cryp.h | 114 +-
> drivers/crypto/starfive/jh7110-hash.c | 316 +++--
> drivers/crypto/starfive/jh7110-rsa.c | 3 +
> drivers/crypto/starfive/jh8100-sm3.c | 544 ++++++++
> drivers/crypto/starfive/jh8100-sm4.c | 1119 +++++++++++++++++
> .../dma/dw-axi-dmac/dw-axi-dmac-platform.c | 32 +-
> drivers/dma/dw-axi-dmac/dw-axi-dmac.h | 2 +
> include/linux/dma/dw_axi.h | 11 +
> 13 files changed, 2437 insertions(+), 438 deletions(-) create mode 100644
> drivers/crypto/starfive/jh8100-sm3.c
> create mode 100644 drivers/crypto/starfive/jh8100-sm4.c
> create mode 100644 include/linux/dma/dw_axi.h
>
Hi Herbert,
Could you please help review this patch series?
Thanks,
Jia Jie
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: dma: snps,dw-axi-dmac: Add JH8100 support
From: Tan Chun Hau @ 2024-03-27 2:51 UTC (permalink / raw)
To: Eugeniy Paltsev, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ley Foon Tan, Jee Heng Sia, dmaengine, devicetree, linux-kernel
In-Reply-To: <20240327025126.229475-1-chunhau.tan@starfivetech.com>
Add support for StarFive JH8100 SoC in Sysnopsys Designware AXI DMA
controller.
Both JH8100 and JH7110 require reset operation in device probe.
However, JH8100 doesn't need to apply different configuration on
CH_CFG registers.
Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
---
Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
index 363cf8bd150d..525f5f3932f5 100644
--- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
@@ -21,6 +21,7 @@ properties:
- snps,axi-dma-1.01a
- intel,kmb-axi-dma
- starfive,jh7110-axi-dma
+ - starfive,jh8100-axi-dma
reg:
minItems: 1
--
2.25.1
^ permalink raw reply related
* RE: [PATCH 1/2] dt-bindings: dma: snps,dw-axi-dmac: Add JH8100 support
From: ChunHau Tan @ 2024-03-27 2:50 UTC (permalink / raw)
To: Conor Dooley
Cc: Eugeniy Paltsev, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Leyfoon Tan, JeeHeng Sia, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20240326-maternity-alive-6cb8f6b2e037@spud>
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, 27 March, 2024 2:33 AM
> To: ChunHau Tan <chunhau.tan@starfivetech.com>
> Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>; Vinod Koul
> <vkoul@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>;
> Leyfoon Tan <leyfoon.tan@starfivetech.com>; JeeHeng Sia
> <jeeheng.sia@starfivetech.com>; dmaengine@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] dt-bindings: dma: snps,dw-axi-dmac: Add JH8100
> support
>
> On Tue, Mar 26, 2024 at 02:54:56AM -0700, Tan Chun Hau wrote:
> > Add support for StarFive JH8100 SoC in Sysnopsys Designware AXI DMA
> > controller.
>
> Your commit message should explain what makes this incompatible with existing
> devices. That inforatiion does appear to be in the driver patch, but should also be
> here. Otherwise,
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
Okay, thank you for the feedback.
>
> >
> > Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
> > ---
> > Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
> > b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
> > index 363cf8bd150d..525f5f3932f5 100644
> > --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
> > +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
> > @@ -21,6 +21,7 @@ properties:
> > - snps,axi-dma-1.01a
> > - intel,kmb-axi-dma
> > - starfive,jh7110-axi-dma
> > + - starfive,jh8100-axi-dma
> >
> > reg:
> > minItems: 1
> > --
> > 2.25.1
> >
^ permalink raw reply
* RE: [PATCH v4 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: ChunHau Tan @ 2024-03-27 1:56 UTC (permalink / raw)
To: Rob Herring
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Emil Renner Berthing, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Simon Horman,
Bartosz Golaszewski, Andrew Halaney, Jisheng Zhang,
Uwe Kleine-König, Russell King, Leyfoon Tan, JeeHeng Sia,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org
In-Reply-To: <20240326213426.GA3667606-robh@kernel.org>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Wednesday, 27 March, 2024 5:34 AM
> To: ChunHau Tan <chunhau.tan@starfivetech.com>
> Cc: David S . Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Emil Renner Berthing <kernel@esmil.dk>; Krzysztof
> Kozlowski <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> <conor+dt@kernel.org>; Maxime Coquelin <mcoquelin.stm32@gmail.com>;
> Alexandre Torgue <alexandre.torgue@foss.st.com>; Simon Horman
> <horms@kernel.org>; Bartosz Golaszewski <bartosz.golaszewski@linaro.org>;
> Andrew Halaney <ahalaney@redhat.com>; Jisheng Zhang <jszhang@kernel.org>;
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de>; Russell King
> <rmk+kernel@armlinux.org.uk>; Leyfoon Tan <leyfoon.tan@starfivetech.com>;
> JeeHeng Sia <jeeheng.sia@starfivetech.com>; netdev@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-stm32@st-md-mailman.stormreply.com;
> linux-arm-kernel@lists.infradead.org; linux-riscv@lists.infradead.org
> Subject: Re: [PATCH v4 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add
> StarFive JH8100 support
>
> On Mon, Mar 25, 2024 at 10:25:05PM -0700, Tan Chun Hau wrote:
> > Add StarFive JH8100 dwmac support.
> > The JH8100 dwmac shares the same driver code as the JH7110 dwmac and
> > has only one reset signal.
> >
> > Please refer to below:
> >
> > JH8100: reset-names = "stmmaceth";
> > JH7110: reset-names = "stmmaceth", "ahb";
> > JH7100: reset-names = "ahb";
> >
> > Example usage of JH8100 in the device tree:
> >
> > gmac0: ethernet@16030000 {
> > compatible = "starfive,jh8100-dwmac",
> > "starfive,jh7110-dwmac",
> > "snps,dwmac-5.20";
> > ...
> > };
> >
> > Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
> > ---
> > .../devicetree/bindings/net/snps,dwmac.yaml | 1 +
> > .../bindings/net/starfive,jh7110-dwmac.yaml | 54 ++++++++++++++-----
> > 2 files changed, 41 insertions(+), 14 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > index 6b0341a8e0ea..a6d596b7dcf4 100644
> > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > @@ -97,6 +97,7 @@ properties:
> > - snps,dwxgmac-2.10
> > - starfive,jh7100-dwmac
> > - starfive,jh7110-dwmac
> > + - starfive,jh8100-dwmac
> >
> > reg:
> > minItems: 1
> > diff --git
> > a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > index 0d1962980f57..ce018e9768d2 100644
> > --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > @@ -18,6 +18,7 @@ select:
> > enum:
> > - starfive,jh7100-dwmac
> > - starfive,jh7110-dwmac
> > + - starfive,jh8100-dwmac
> > required:
> > - compatible
> >
> > @@ -30,6 +31,10 @@ properties:
> > - items:
> > - const: starfive,jh7110-dwmac
> > - const: snps,dwmac-5.20
> > + - items:
> > + - const: starfive,jh8100-dwmac
> > + - const: starfive,jh7110-dwmac
> > + - const: snps,dwmac-5.20
> >
> > reg:
> > maxItems: 1
> > @@ -107,20 +112,41 @@ allOf:
> > contains:
> > const: starfive,jh7110-dwmac
> > then:
> > - properties:
> > - interrupts:
> > - minItems: 3
> > - maxItems: 3
> > -
> > - interrupt-names:
> > - minItems: 3
> > - maxItems: 3
>
> interrupts and interrupt-names are the same, so you can leave them here instead
> of duplicating them as you have.
Okay, thank you for the feedback.
>
> > -
> > - resets:
> > - minItems: 2
> > -
> > - reset-names:
> > - minItems: 2
> > + if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: starfive,jh8100-dwmac
> > + then:
> > + properties:
> > + interrupts:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + interrupt-names:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + const: stmmaceth
> > + else:
> > + properties:
> > + interrupts:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + interrupt-names:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + resets:
> > + minItems: 2
> > +
> > + reset-names:
> > + minItems: 2
> >
> > unevaluatedProperties: false
> >
> > --
> > 2.25.1
> >
^ 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