* [PATCH v3 08/12] regulator: axp20x-regulator: add support for AXP803
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-1-icenowy@aosc.io>
AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
controllable via I2C/RSB bus.
Add support for them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v2:
- Place AXP803 codes before AXP806/809 ones.
- Fixed some errors in regulator description.
- Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.
drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++++++++++++++-----
include/linux/mfd/axp20x.h | 37 +++++++++
2 files changed, 168 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 0b9d4e3e52c7..2ed15e4a7a82 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,82 @@ static const struct regulator_desc axp22x_drivevbus_regulator = {
.ops = &axp20x_ops_sw,
};
+static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
+ REGULATOR_LINEAR_RANGE(500000, 0x0, 0x46, 10000),
+ REGULATOR_LINEAR_RANGE(1220000, 0x47, 0x4b, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
+ REGULATOR_LINEAR_RANGE(800000, 0x0, 0x20, 10000),
+ REGULATOR_LINEAR_RANGE(1140000, 0x21, 0x44, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
+ REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
+};
+
+/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
+static const struct regulator_linear_range axp803_dldo2_ranges[] = {
+ REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
+ REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
+};
+
+static const struct regulator_desc axp803_regulators[] = {
+ AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+ AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+ AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(1)),
+ AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(2)),
+ AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(3)),
+ AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
+ 68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(4)),
+ AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
+ 72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(5)),
+ /* secondary switchable output of DCDC1 */
+ AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+ BIT(7)),
+ AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+ AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
+ AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+ AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
+ AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+ AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
+ AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
+ AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
+ AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
+ 32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+ BIT(4)),
+ AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
+ AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+ AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
+ AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
+ AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
+ AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+ AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
+ AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+ AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
+ AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+ AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
+ AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
+ AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
+ AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
+ AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+ AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+ AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+ AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+ AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
+ AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+ AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc_ldo", "ips", 3000),
+};
+
static const struct regulator_linear_range axp806_dcdca_ranges[] = {
REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
@@ -254,11 +330,6 @@ static const struct regulator_linear_range axp806_dcdcd_ranges[] = {
REGULATOR_LINEAR_RANGE(1600000, 0x2e, 0x3f, 100000),
};
-static const struct regulator_linear_range axp806_cldo2_ranges[] = {
- REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
- REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
-};
-
static const struct regulator_desc axp806_regulators[] = {
AXP_DESC_RANGES(AXP806, DCDCA, "dcdca", "vina", axp806_dcdca_ranges,
72, AXP806_DCDCA_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
@@ -289,7 +360,7 @@ static const struct regulator_desc axp806_regulators[] = {
AXP806_BLDO4_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(3)),
AXP_DESC(AXP806, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
AXP806_CLDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(4)),
- AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp806_cldo2_ranges,
+ AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp803_dldo2_ranges,
32, AXP806_CLDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2,
BIT(5)),
AXP_DESC(AXP806, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
@@ -326,7 +397,7 @@ static const struct regulator_desc axp809_regulators[] = {
AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
- AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp806_cldo2_ranges,
+ AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp803_dldo2_ranges,
32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
BIT(3)),
AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
@@ -369,14 +440,21 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
def = 1500;
step = 75;
break;
- case AXP806_ID:
+ case AXP803_ID:
/*
- * AXP806 DCDC work frequency setting has the same range and
+ * AXP803 DCDC work frequency setting has the same range and
* step as AXP22X, but at a different register.
* Fall through to the check below.
* (See include/linux/mfd/axp20x.h)
*/
- reg = AXP806_DCDC_FREQ_CTRL;
+ reg = AXP803_DCDC_FREQ_CTRL;
+ case AXP806_ID:
+ /*
+ * AXP806 also have DCDC work frequency setting register at a
+ * different position.
+ */
+ if (axp20x->variant == AXP806_ID)
+ reg = AXP806_DCDC_FREQ_CTRL;
case AXP221_ID:
case AXP223_ID:
case AXP809_ID:
@@ -475,6 +553,14 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
workmode <<= id - AXP22X_DCDC1;
break;
+ case AXP803_ID:
+ if (id < AXP803_DCDC1 || id > AXP803_DCDC6)
+ return -EINVAL;
+
+ mask = AXP22X_WORKMODE_DCDCX_MASK(id - AXP803_DCDC1);
+ workmode <<= id - AXP803_DCDC1;
+ break;
+
default:
/* should not happen */
WARN_ON(1);
@@ -492,20 +578,38 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
{
u32 reg = 0;
- /* Only AXP806 has poly-phase outputs */
- if (axp20x->variant != AXP806_ID)
- return false;
+ /*
+ * Currently in our supported AXP variants, only AXP806 and AXP803
+ * have polyphase regulators.
+ */
+ switch (axp20x->variant) {
+ case AXP803_ID:
+ regmap_read(axp20x->regmap, AXP803_POLYPHASE_CTRL, ®);
+
+ switch (id) {
+ case AXP803_DCDC3:
+ return !!(reg & BIT(6));
+ case AXP803_DCDC6:
+ return !!(reg & BIT(7));
+ }
+ break;
- regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, ®);
+ case AXP806_ID:
+ regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, ®);
+
+ switch (id) {
+ case AXP806_DCDCB:
+ return (((reg & GENMASK(7, 6)) == BIT(6)) ||
+ ((reg & GENMASK(7, 6)) == BIT(7)));
+ case AXP806_DCDCC:
+ return ((reg & GENMASK(7, 6)) == BIT(7));
+ case AXP806_DCDCE:
+ return !!(reg & BIT(5));
+ }
+ break;
- switch (id) {
- case AXP806_DCDCB:
- return (((reg & GENMASK(7, 6)) == BIT(6)) ||
- ((reg & GENMASK(7, 6)) == BIT(7)));
- case AXP806_DCDCC:
- return ((reg & GENMASK(7, 6)) == BIT(7));
- case AXP806_DCDCE:
- return !!(reg & BIT(5));
+ default:
+ return false;
}
return false;
@@ -540,6 +644,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
"x-powers,drive-vbus-en");
break;
+ case AXP803_ID:
+ regulators = axp803_regulators;
+ nregulators = AXP803_REG_ID_MAX;
+ break;
case AXP806_ID:
regulators = axp806_regulators;
nregulators = AXP806_REG_ID_MAX;
@@ -579,6 +687,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
* name.
*/
if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
+ (regulators == axp803_regulators && i == AXP803_DC1SW) ||
(regulators == axp809_regulators && i == AXP809_DC1SW)) {
new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
GFP_KERNEL);
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index cde56cfe8446..965b027e31b3 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -119,6 +119,17 @@ enum axp20x_variants {
#define AXP806_BUS_ADDR_EXT 0xfe
#define AXP806_REG_ADDR_EXT 0xff
+#define AXP803_POLYPHASE_CTRL 0x14
+#define AXP803_FLDO1_V_OUT 0x1c
+#define AXP803_FLDO2_V_OUT 0x1d
+#define AXP803_DCDC1_V_OUT 0x20
+#define AXP803_DCDC2_V_OUT 0x21
+#define AXP803_DCDC3_V_OUT 0x22
+#define AXP803_DCDC4_V_OUT 0x23
+#define AXP803_DCDC5_V_OUT 0x24
+#define AXP803_DCDC6_V_OUT 0x25
+#define AXP803_DCDC_FREQ_CTRL 0x3b
+
/* Interrupt */
#define AXP152_IRQ1_EN 0x40
#define AXP152_IRQ2_EN 0x41
@@ -350,6 +361,32 @@ enum {
AXP809_REG_ID_MAX,
};
+enum {
+ AXP803_DCDC1 = 0,
+ AXP803_DCDC2,
+ AXP803_DCDC3,
+ AXP803_DCDC4,
+ AXP803_DCDC5,
+ AXP803_DCDC6,
+ AXP803_DC1SW,
+ AXP803_ALDO1,
+ AXP803_ALDO2,
+ AXP803_ALDO3,
+ AXP803_DLDO1,
+ AXP803_DLDO2,
+ AXP803_DLDO3,
+ AXP803_DLDO4,
+ AXP803_ELDO1,
+ AXP803_ELDO2,
+ AXP803_ELDO3,
+ AXP803_FLDO1,
+ AXP803_FLDO2,
+ AXP803_RTC_LDO,
+ AXP803_LDO_IO0,
+ AXP803_LDO_IO1,
+ AXP803_REG_ID_MAX,
+};
+
/* IRQs */
enum {
AXP152_IRQ_LDO0IN_CONNECT = 1,
--
2.12.2
^ permalink raw reply related
* [PATCH v3 07/12] dt-bindings: add AXP803's regulator info
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-1-icenowy@aosc.io>
AXP803 have the most regulators in currently supported AXP PMICs.
Add info for the regulators in the dt-bindings document.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v3:
- Added Rob's ACK.
Changes in v2:
- Place AXP803 regulators before AXP806/809 ones.
Documentation/devicetree/bindings/mfd/axp20x.txt | 27 ++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 44df88be3c89..aca09af66514 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -96,6 +96,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
RTC_LDO : LDO : ips-supply : always on
DRIVEVBUS : Enable output : drivevbus-supply : external regulator
+AXP803 regulators, type, and corresponding input supply names:
+
+Regulator Type Supply Name Notes
+--------- ---- ----------- -----
+DCDC1 : DC-DC buck : vin1-supply
+DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
+DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
+DCDC4 : DC-DC buck : vin4-supply
+DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
+DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
+DC1SW : On/Off Switch : : DCDC1 secondary output
+ALDO1 : LDO : aldoin-supply : shared supply
+ALDO2 : LDO : aldoin-supply : shared supply
+ALDO3 : LDO : aldoin-supply : shared supply
+DLDO1 : LDO : dldoin-supply : shared supply
+DLDO2 : LDO : dldoin-supply : shared supply
+DLDO3 : LDO : dldoin-supply : shared supply
+DLDO4 : LDO : dldoin-supply : shared supply
+ELDO1 : LDO : eldoin-supply : shared supply
+ELDO2 : LDO : eldoin-supply : shared supply
+ELDO3 : LDO : eldoin-supply : shared supply
+FLDO1 : LDO : fldoin-supply : shared supply
+FLDO2 : LDO : fldoin-supply : shared supply
+LDO_IO0 : LDO : ips-supply : GPIO 0
+LDO_IO1 : LDO : ips-supply : GPIO 1
+RTC_LDO : LDO : ips-supply : always on
+
AXP806 regulators, type, and corresponding input supply names:
Regulator Type Supply Name Notes
--
2.12.2
^ permalink raw reply related
* [PATCH v3 06/12] arm64: allwinner: a64: add AXP803 node to Pine64 device tree
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-1-icenowy@aosc.io>
The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
Add its device node.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c680ed385da3..2132d8e6cb3d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -95,6 +95,17 @@
status = "okay";
};
+&r_rsb {
+ status = "okay";
+
+ axp803: pmic at 3a3 {
+ compatible = "x-powers,axp803";
+ reg = <0x3a3>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.12.2
^ permalink raw reply related
* [PATCH v3 05/12] mfd: axp20x: support AXP803 variant
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-1-icenowy@aosc.io>
AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
via RSB bus. The PMIC itself is like AXP288, but with RSB support and
dedicated VBUS and ACIN.
Add support for it in the axp20x mfd driver.
Currently only power key function is supported.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
This patch is said to be applied by Lee Jones, however, I didn't see it
in the linux-next, so I included it in the patchset now.
Changes in v2:
- Share regmap configs with AXP288.
- Place AXP803 bits before AXP806/809.
drivers/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/axp20x.h | 40 ++++++++++++++++++++++-
3 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index a732cb50bcff..fd5c7267b136 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+ { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
{ .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
{ },
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index e6f55079876e..1dc6235778eb 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+ "AXP803",
"AXP806",
"AXP809",
};
@@ -117,6 +118,7 @@ static const struct regmap_access_table axp22x_volatile_table = {
.n_yes_ranges = ARRAY_SIZE(axp22x_volatile_ranges),
};
+/* AXP288 ranges are shared with the AXP803, as they cover the same range */
static const struct regmap_range axp288_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
@@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
},
};
+static struct resource axp803_pek_resources[] = {
+ {
+ .name = "PEK_DBR",
+ .start = AXP803_IRQ_PEK_RIS_EDGE,
+ .end = AXP803_IRQ_PEK_RIS_EDGE,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .name = "PEK_DBF",
+ .start = AXP803_IRQ_PEK_FAL_EDGE,
+ .end = AXP803_IRQ_PEK_FAL_EDGE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static struct resource axp809_pek_resources[] = {
{
.name = "PEK_DBR",
@@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG, 5, 1),
};
+static const struct regmap_irq axp803_regmap_irqs[] = {
+ INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V, 0, 7),
+ INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN, 0, 6),
+ INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL, 0, 5),
+ INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V, 0, 4),
+ INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN, 0, 3),
+ INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL, 0, 2),
+ INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN, 1, 7),
+ INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL, 1, 6),
+ INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE, 1, 5),
+ INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
+ INIT_REGMAP_IRQ(AXP803, CHARG, 1, 3),
+ INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
+ INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
+ INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
+ INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW, 2, 5),
+ INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END, 2, 4),
+ INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
+ INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
+ INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW, 2, 1),
+ INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END, 2, 0),
+ INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH, 3, 7),
+ INIT_REGMAP_IRQ(AXP803, GPADC, 3, 2),
+ INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1, 3, 1),
+ INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2, 3, 0),
+ INIT_REGMAP_IRQ(AXP803, TIMER, 4, 7),
+ INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE, 4, 6),
+ INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE, 4, 5),
+ INIT_REGMAP_IRQ(AXP803, PEK_SHORT, 4, 4),
+ INIT_REGMAP_IRQ(AXP803, PEK_LONG, 4, 3),
+ INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF, 4, 2),
+ INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT, 4, 1),
+ INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT, 4, 0),
+ INIT_REGMAP_IRQ(AXP803, BC_USB_CHNG, 5, 1),
+ INIT_REGMAP_IRQ(AXP803, MV_CHNG, 5, 0),
+};
+
static const struct regmap_irq axp806_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1, 0, 0),
INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2, 0, 1),
@@ -557,6 +610,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
};
+static const struct regmap_irq_chip axp803_regmap_irq_chip = {
+ .name = "axp803",
+ .status_base = AXP20X_IRQ1_STATE,
+ .ack_base = AXP20X_IRQ1_STATE,
+ .mask_base = AXP20X_IRQ1_EN,
+ .mask_invert = true,
+ .init_ack_masked = true,
+ .irqs = axp803_regmap_irqs,
+ .num_irqs = ARRAY_SIZE(axp803_regmap_irqs),
+ .num_regs = 6,
+};
+
static const struct regmap_irq_chip axp806_regmap_irq_chip = {
.name = "axp806",
.status_base = AXP20X_IRQ1_STATE,
@@ -778,6 +843,14 @@ static struct mfd_cell axp288_cells[] = {
},
};
+static struct mfd_cell axp803_cells[] = {
+ {
+ .name = "axp20x-pek",
+ .num_resources = ARRAY_SIZE(axp803_pek_resources),
+ .resources = axp803_pek_resources,
+ }
+};
+
static struct mfd_cell axp806_cells[] = {
{
.id = 2,
@@ -864,6 +937,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
axp20x->irq_flags = IRQF_TRIGGER_LOW;
break;
+ case AXP803_ID:
+ axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
+ axp20x->cells = axp803_cells;
+ axp20x->regmap_cfg = &axp288_regmap_config;
+ axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
+ break;
case AXP806_ID:
axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
axp20x->cells = axp806_cells;
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index dc8798cf2a24..cde56cfe8446 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -20,6 +20,7 @@ enum axp20x_variants {
AXP221_ID,
AXP223_ID,
AXP288_ID,
+ AXP803_ID,
AXP806_ID,
AXP809_ID,
NR_AXP20X_VARIANTS,
@@ -234,7 +235,7 @@ enum axp20x_variants {
#define AXP22X_TS_ADC_L 0x59
#define AXP22X_BATLOW_THRES1 0xe6
-/* AXP288 specific registers */
+/* AXP288/AXP803 specific registers */
#define AXP288_POWER_REASON 0x02
#define AXP288_BC_GLOBAL 0x2c
#define AXP288_BC_VBUS_CNTL 0x2d
@@ -475,6 +476,43 @@ enum axp288_irqs {
AXP288_IRQ_BC_USB_CHNG,
};
+enum axp803_irqs {
+ AXP803_IRQ_ACIN_OVER_V = 1,
+ AXP803_IRQ_ACIN_PLUGIN,
+ AXP803_IRQ_ACIN_REMOVAL,
+ AXP803_IRQ_VBUS_OVER_V,
+ AXP803_IRQ_VBUS_PLUGIN,
+ AXP803_IRQ_VBUS_REMOVAL,
+ AXP803_IRQ_BATT_PLUGIN,
+ AXP803_IRQ_BATT_REMOVAL,
+ AXP803_IRQ_BATT_ENT_ACT_MODE,
+ AXP803_IRQ_BATT_EXIT_ACT_MODE,
+ AXP803_IRQ_CHARG,
+ AXP803_IRQ_CHARG_DONE,
+ AXP803_IRQ_BATT_CHG_TEMP_HIGH,
+ AXP803_IRQ_BATT_CHG_TEMP_HIGH_END,
+ AXP803_IRQ_BATT_CHG_TEMP_LOW,
+ AXP803_IRQ_BATT_CHG_TEMP_LOW_END,
+ AXP803_IRQ_BATT_ACT_TEMP_HIGH,
+ AXP803_IRQ_BATT_ACT_TEMP_HIGH_END,
+ AXP803_IRQ_BATT_ACT_TEMP_LOW,
+ AXP803_IRQ_BATT_ACT_TEMP_LOW_END,
+ AXP803_IRQ_DIE_TEMP_HIGH,
+ AXP803_IRQ_GPADC,
+ AXP803_IRQ_LOW_PWR_LVL1,
+ AXP803_IRQ_LOW_PWR_LVL2,
+ AXP803_IRQ_TIMER,
+ AXP803_IRQ_PEK_RIS_EDGE,
+ AXP803_IRQ_PEK_FAL_EDGE,
+ AXP803_IRQ_PEK_SHORT,
+ AXP803_IRQ_PEK_LONG,
+ AXP803_IRQ_PEK_OVER_OFF,
+ AXP803_IRQ_GPIO1_INPUT,
+ AXP803_IRQ_GPIO0_INPUT,
+ AXP803_IRQ_BC_USB_CHNG,
+ AXP803_IRQ_MV_CHNG,
+};
+
enum axp806_irqs {
AXP806_IRQ_DIE_TEMP_HIGH_LV1,
AXP806_IRQ_DIE_TEMP_HIGH_LV2,
--
2.12.2
^ permalink raw reply related
* [PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-1-icenowy@aosc.io>
AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
bus.
Add a compatible for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v3:
- Make the compatible one-liner.
Changes in v2:
- Place AXP803 before AXP806/809.
- Added Chen-Yu's ACK.
Documentation/devicetree/bindings/mfd/axp20x.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index a3e813f6060a..44df88be3c89 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,6 +6,7 @@ axp202 (X-Powers)
axp209 (X-Powers)
axp221 (X-Powers)
axp223 (X-Powers)
+axp803 (X-Powers)
axp809 (X-Powers)
Required properties:
@@ -15,6 +16,7 @@ Required properties:
* "x-powers,axp209"
* "x-powers,axp221"
* "x-powers,axp223"
+ * "x-powers,axp803"
* "x-powers,axp806"
* "x-powers,axp809"
- reg: The I2C slave address or RSB hardware address for the AXP chip
--
2.12.2
^ permalink raw reply related
* [PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-1-icenowy@aosc.io>
In the binding documentation of AXP20X mfd, the compatible strings used
to be listed for three per line, which leads to some mess when trying to
add AXP803 compatible string (as we have already AXP806 and AXP809
compatibles, which is after AXP803 in ascending order).
Make the compatible strings one per line, so that inserting a new
compatible string will be directly a new line.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
New patch in v3.
Documentation/devicetree/bindings/mfd/axp20x.txt | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index b41d2601c6ba..a3e813f6060a 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -9,9 +9,14 @@ axp223 (X-Powers)
axp809 (X-Powers)
Required properties:
-- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
- "x-powers,axp809"
+- compatible: should be one of:
+ * "x-powers,axp152"
+ * "x-powers,axp202"
+ * "x-powers,axp209"
+ * "x-powers,axp221"
+ * "x-powers,axp223"
+ * "x-powers,axp806"
+ * "x-powers,axp809"
- reg: The I2C slave address or RSB hardware address for the AXP chip
- interrupt-parent: The parent interrupt controller
- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
--
2.12.2
^ permalink raw reply related
* [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-1-icenowy@aosc.io>
Allwinner A64 SoC features a NMI controller, which is usually connected
to the AXP PMIC.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v2:
- Added Chen-Yu's ACK.
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 05ec9fc5e81f..53c18ca372ea 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -403,6 +403,14 @@
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
};
+ nmi_intc: interrupt-controller at 01f00c0c {
+ compatible = "allwinner,sun6i-a31-sc-nmi";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01f00c0c 0x38>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
r_ccu: clock at 1f01400 {
compatible = "allwinner,sun50i-a64-r-ccu";
reg = <0x01f01400 0x100>;
--
2.12.2
^ permalink raw reply related
* [PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-1-icenowy@aosc.io>
Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
Add it and its pinmux.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v2:
- Removed bonus properties in pio node.
- Added Chen-Yu's ACK.
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index c7f669f5884f..05ec9fc5e81f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -422,6 +422,25 @@
#gpio-cells = <3>;
interrupt-controller;
#interrupt-cells = <3>;
+
+ r_rsb_pins: rsb at 0 {
+ pins = "PL0", "PL1";
+ function = "s_rsb";
+ };
+ };
+
+ r_rsb: rsb at 1f03400 {
+ compatible = "allwinner,sun8i-a23-rsb";
+ reg = <0x01f03400 0x400>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu 6>;
+ clock-frequency = <3000000>;
+ resets = <&r_ccu 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
};
};
};
--
2.12.2
^ permalink raw reply related
* [PATCH v3 00/12] AXP803 PMIC support for Pine64
From: Icenowy Zheng @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).
This patchset adds support for it and enabled it in Pine64 device tree.
This patchset can be splitted into two big parts:
- Part1: PATCH 1/11 to PATCH 6/12, which are enabling the MFD (and the
power key functionality) of AXP803.
- Part2: PATCH 7/12 to PATCH 12/12, which are enabling the regulator
function of the AXP803 PMIC. Finally Wi-Fi function is added
as a usage of regulators function.
PATCH 1 and 2 added RSB and NMI device nodes, which are used for the
communication between A64 and AXP803.
PATCH 3 re-arranged the compatible strings in AXP20x device tree binding,
for easier insertion of AXP803 compatible. This is based on the suggestion
by device tree maintainer Rob Herring.
PATCH 4 adds basical devicetree binding for AXP803.
PATCH 5 adds support for the AXP803 variant in axp20x-rsb mfd driver. It's
said to be applied already by Lee Jones, but I didn't see it in linux-next
now, so it's kept in this series.
PATCH 6 enabled the AXP803 MFD in Pine64 device tree.
PATCH 7 adds devicetree binding for the regulators in AXP803.
PATCH 8 adds support for the regulators in AXP803 in the axp20x-regulator
driver.
PATCH 9 enabled the regulator MFD cell in AXP803.
PATCH 10 adds a DTSI file for AXP803, just like what have been done for other
AXPs.
PATCH 11 enabled the regulators on Pine64.
PATCH 12 enabled Wi-Fi support on Pine64, which required DLDO4 and ELDO1
regulators.
Icenowy Zheng (12):
arm64: allwinner: a64: enable RSB on A64
arm64: allwinner: a64: add NMI controller on A64
dt-bindings: make AXP20X compatible strings one per line
dt-bindings: add device tree binding for X-Powers AXP803 PMIC
mfd: axp20x: support AXP803 variant
arm64: allwinner: a64: add AXP803 node to Pine64 device tree
dt-bindings: add AXP803's regulator info
regulator: axp20x-regulator: add support for AXP803
mfd: axp20x: add axp20x-regulator cell for AXP803
arm64: allwinner: a64: add DTSI file for AXP803 PMIC
arm64: allwinner: a64: enable AXP803 regulators for Pine64
arm64: allwinner: a64: enable Wi-Fi for Pine64
Documentation/devicetree/bindings/mfd/axp20x.txt | 40 +++++-
arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 27 ++++
drivers/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 80 +++++++++++
drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++---
include/linux/mfd/axp20x.h | 77 ++++++++++-
8 files changed, 638 insertions(+), 26 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
--
2.12.2
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: sunil.kovvuri at gmail.com @ 2017-04-17 11:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Sunil Goutham <sgoutham@cavium.com>
For software initiated address translation, when domain type is
IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
i.e return the same IOVA as translated address.
This patch is an extension to Will Deacon's patchset
"Implement SMMU passthrough using the default domain".
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
drivers/iommu/arm-smmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 41afb07..2f4a130 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
+ if (domain->type == IOMMU_DOMAIN_IDENTITY)
+ return iova;
+
if (!ops)
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] arm64: Fix power-of-ten vs. power-of-two prefixes in comments etc.
From: Geert Uytterhoeven @ 2017-04-17 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170416231223.GA31693@verge.net.au>
On Mon, Apr 17, 2017 at 1:12 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Apr 13, 2017 at 01:18:58PM +0100, David Woodhouse wrote:
>> Less important than in user-visible messages, but still good practice as
>> there's still no excuse for ARM64 code to look like it was written before
>> 1996.
>>
>> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>
> Hi David,
>
> I'd be happy to take the Renesas portions of this change if they were
> broken out into a separate patch. The reason I would prefer a separate
> patch is to avoid the possibility of conflicts, even trivial ones.
s/possibility/reality/, unless this series goes in before v4.12-rc1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] net: thunderx: Fix set_max_bgx_per_node for 81xx rgx
From: Sunil Kovvuri @ 2017-04-17 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492068301-1141-1-git-send-email-george.cherian@cavium.com>
On Thu, Apr 13, 2017 at 12:55 PM, George Cherian
<george.cherian@cavium.com> wrote:
> Add the PCI_SUBSYS_DEVID_81XX_RGX and use the same to set
> the max bgx per node count.
>
> This fixes the issue intoduced by following commit
> 78aacb6f6 net: thunderx: Fix invalid mac addresses for node1 interfaces
> With this commit the max_bgx_per_node for 81xx is set as 2 instead of 3
> because of which num_vfs is always calculated as zero.
>
> Signed-off-by: George Cherian <george.cherian@cavium.com>
> ---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 1 +
> drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 64a1095..a0ca68c 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -134,6 +134,7 @@ static void set_max_bgx_per_node(struct pci_dev *pdev)
> pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &sdevid);
> switch (sdevid) {
> case PCI_SUBSYS_DEVID_81XX_BGX:
> + case PCI_SUBSYS_DEVID_81XX_RGX:
> max_bgx_per_node = MAX_BGX_PER_CN81XX;
> break;
> case PCI_SUBSYS_DEVID_83XX_BGX:
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> index c5080f2c..6b7fe6fd 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
> @@ -16,6 +16,7 @@
> /* Subsystem device IDs */
> #define PCI_SUBSYS_DEVID_88XX_BGX 0xA126
> #define PCI_SUBSYS_DEVID_81XX_BGX 0xA226
> +#define PCI_SUBSYS_DEVID_81XX_RGX 0xA254
> #define PCI_SUBSYS_DEVID_83XX_BGX 0xA326
>
> #define MAX_BGX_THUNDER 8 /* Max 2 nodes, 4 per node */
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Looks good, thanks.
Sunil.
^ permalink raw reply
* [PATCH] arm64: allwinner: h5: add support for NanoPi NEO2 board
From: Icenowy Zheng @ 2017-04-17 11:15 UTC (permalink / raw)
To: linux-arm-kernel
NanoPi NEO2 is a board with the same size factor with the original
NanoPi NEO by FriendlyELEC.
It has a H5 instead of H3 on NanoPi NEO, and the ethernet is upgraded to
1Gbps (with external RTL8211E PHY).
Add support for this board.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts | 134 +++++++++++++++++++++
2 files changed, 135 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 92a84eea6b96..546720096aef 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo2.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
new file mode 100644
index 000000000000..f6d71b0d482a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun50i-h5.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "FriendlyARM NanoPi NEO 2";
+ compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ pwr {
+ label = "nanopi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status {
+ label = "nanopi:blue:status";
+ gpios = <&pio 0 10 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ reg_usb0_vbus: usb0-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb0-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */
+ status = "okay";
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ /* USB Type-A port's VBUS is always on */
+ usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ status = "okay";
+};
--
2.12.2
^ permalink raw reply related
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Stefan Wahren @ 2017-04-17 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1795308650.27171.9a53158f-312d-40ce-80ce-8bf792d8db34.open-xchange@email.1und1.de>
Hi,
> Stefan Wahren <stefan.wahren@i2se.com> hat am 31. Oktober 2016 um 21:34 geschrieben:
>
>
> I inspired by this issue [1] i build up a slightly modified setup with a
> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 Prolific
> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
> only tries to open all ttyUSB devices one after the other.
>
> Unfortunately the complete system stuck after opening the first ttyUSB device (
> heartbeat LED stop blinking, no reaction to debug UART). The only way to
> reanimate the system is to powerdown the USB hub with the USB to serial
> convertors.
>
> [1] - https://github.com/raspberrypi/linux/issues/1692
> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
since this issue still exists with 4.11 (even without or with microframe scheduler enabled), i want to ask some additional questions:
Is this issue reproducible with other dwc2 platforms than bcm2835?
Does the soft lockup also occurs after opening the second serial convertor or later?
Regards
Stefan
>
> pi at raspberrypi:~$ lsusb -t
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx,
> 480M
> |__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 2: Dev 14, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 3: Dev 16, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
>
> pi at raspberrypi:~$ ./usb_test
> idle
> opening [/dev/ttyUSB0] ok
> [ 232.658768] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s!
> [usb_test:522]
> [ 232.678443] Modules linked in: pwm_bcm2835 vchiq(C)
> [ 232.678481] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
> 4.9.0-rc3+ #33
> [ 232.678486] Hardware name: BCM2835
> [ 232.678498] task: cab54e40 task.stack: c688c000
> [ 232.678520] PC is at __do_softirq+0x68/0x2a8
> [ 232.678538] LR is at irq_exit+0xb8/0x120
> [ 232.678552] pc : [<c01014d0>] lr : [<c0121270>] psr: 60000113
> sp : c688da60 ip : c688daa8 fp : c688daa4
> [ 232.678560] r10: c0b7f800 r9 : c688c000 r8 : 00400000
> [ 232.678567] r7 : 0000000a r6 : cb802400 r5 : 00000000 r4 : 00000001
> [ 232.678575] r3 : 00000000 r2 : 00000100 r1 : 00400000 r0 : 00000000
> [ 232.678585] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 232.678593] Control: 00c5387d Table: 068a4008 DAC: 00000051
> [ 232.678604] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
> 4.9.0-rc3+ #33
> [ 232.678609] Hardware name: BCM2835
> [ 232.678667] [<c010ecc0>] (unwind_backtrace) from [<c010bc28>]
> (show_stack+0x20/0x24)
> [ 232.678695] [<c010bc28>] (show_stack) from [<c03684e0>]
> (dump_stack+0x20/0x28)
> [ 232.678718] [<c03684e0>] (dump_stack) from [<c0108ee4>] (show_regs+0x1c/0x20)
> [ 232.678752] [<c0108ee4>] (show_regs) from [<c018ea00>]
> (watchdog_timer_fn+0x140/0x19c)
> [ 232.678779] [<c018ea00>] (watchdog_timer_fn) from [<c015eefc>]
> (__hrtimer_run_queues.constprop.3+0xec/0x210)
> [ 232.678798] [<c015eefc>] (__hrtimer_run_queues.constprop.3) from [<c015f210>]
> (hrtimer_interrupt+0xa4/0x1cc)
> [ 232.678827] [<c015f210>] (hrtimer_interrupt) from [<c04eff58>]
> (bcm2835_time_interrupt+0x40/0x48)
> [ 232.678865] [<c04eff58>] (bcm2835_time_interrupt) from [<c01537ec>]
> (__handle_irq_event_percpu+0x68/0x1b8)
> [ 232.678891] [<c01537ec>] (__handle_irq_event_percpu) from [<c0153968>]
> (handle_irq_event_percpu+0x2c/0x68)
> [ 232.678915] [<c0153968>] (handle_irq_event_percpu) from [<c01539dc>]
> (handle_irq_event+0x38/0x4c)
> [ 232.678939] [<c01539dc>] (handle_irq_event) from [<c0156df8>]
> (handle_level_irq+0xc4/0xf8)
> [ 232.678960] [<c0156df8>] (handle_level_irq) from [<c0152fd8>]
> (generic_handle_irq+0x28/0x38)
> [ 232.678983] [<c0152fd8>] (generic_handle_irq) from [<c0153144>]
> (__handle_domain_irq+0x90/0xb8)
> [ 232.679004] [<c0153144>] (__handle_domain_irq) from [<c01013f4>]
> (bcm2835_handle_irq+0x30/0x48)
> [ 232.679022] [<c01013f4>] (bcm2835_handle_irq) from [<c010c7cc>]
> (__irq_svc+0x6c/0x90)
> [ 232.679031] Exception stack(0xc688da10 to 0xc688da58)
> [ 232.679044] da00: 00000000 00400000
> 00000100 00000000
> [ 232.679062] da20: 00000001 00000000 cb802400 0000000a 00400000 c688c000
> c0b7f800 c688daa4
> [ 232.679078] da40: c688daa8 c688da60 c0121270 c01014d0 60000113 fffff000000
> c687a300 c9374900 ca918b00 caff1200 c688db84
> [ 232.679235] db20: c688db28 c688db40 c04a1cf8 c049cb64 60000013 ffffffff
> [ 232.679272] [<c010c7cc>] (__irq_svc) from [<c049cb64>]
> (_dwc2_hcd_urb_enqueue+0x414/0x560)
> [ 232.679302] [<c049cb64>] (_dwc2_hcd_urb_enqueue) from [<c04849ac>]
> (usb_hcd_submit_urb+0x704/0x8c4)
> [ 232.679327] [<c04849ac>] (usb_hcd_submit_urb) from [<c048628c>]
> (usb_submit_urb+0x438/0x4e0)
> [ 232.679358] [<c048628c>] (usb_submit_urb) from [<c04a9d60>]
> (usb_serial_generic_submit_read_urb+0x50/0xc8)
> [ 232.679382] [<c04a9d60>] (usb_serial_generic_submit_read_urb) from
> [<c04aa0a8>] (usb_serial_generic_submit_read_urbs+0x28/0x70)
> [ 232.679407] [<c04aa0a8>] (usb_serial_generic_submit_read_urbs) from
> [<c04aa298>] (usb_serial_generic_open+0x44/0x4c)
> [ 232.679435] [<c04aa298>] (usb_serial_generic_open) from [<c04aebc4>]
> (pl2303_open+0xc0/0xe0)
> [ 232.679458] [<c04aebc4>] (pl2303_open) from [<c04a744c>]
> (serial_port_activate+0x54/0x8c)
> [ 232.679486] [<c04a744c>] (serial_port_activate) from [<c03c4014>]
> (tty_port_open+0x84/0xd4)
> [ 232.679509] [<c03c4014>] (tty_port_open) from [<c04a7d40>]
> (serial_open+0x34/0x5c)
> [ 232.679546] [<c04a7d40>] (serial_open) from [<c03bd3a8>]
> (tty_open+0x380/0x534)
> [ 232.679578] [<c03bd3a8>] (tty_open) from [<c021e188>]
> (chrdev_open+0x120/0x14c)
> [ 232.679612] [<c021e188>] (chrdev_open) from [<c0217368>]
> (do_dentry_open+0x1b8/0x304)
> [ 232.679638] [<c0217368>] (do_dentry_open) from [<c021876c>]
> (vfs_open+0x7c/0x80)
> [ 232.679663] [<c021876c>] (vfs_open) from [<c022834c>]
> (path_openat+0xb60/0xd88)
> [ 232.679682] [<c022834c>] (path_openat) from [<c02285bc>]
> (do_filp_open+0x48/0x94)
> [ 232.679704] [<c02285bc>] (do_filp_open) from [<c0218af4>]
> (do_sys_open+0x12c/0x1cc)
> [ 232.679728] [<c0218af4>] (do_sys_open) from [<c0218bc4>] (SyS_open+0x30/0x34)
> [ 232.679754] [<c0218bc4>] (SyS_open) from [<c0108280>]
> (ret_fast_syscall+0x0/0x3c)
> [ 233.852571] usb 1-1.2: clear tt 1 (9063) error -110
> [ 233.853046] usb 1-1.2.1: clear tt 1 (9073) error -110
> [ 234.892554] usb 1-1.2.1: clear tt 1 (9071) error -110
> [ 234.892995] usb 1-1.2: clear tt 1 (9061) error -110
> [ 235.932574] usb 1-1.2.1: clear tt 1 (9073) error -110
> [ 235.933542] usb 1-1.2: clear tt 1 (9063) error -110
> [ 236.972595] usb 1-1.2.1: clear tt 1 (9071) error -110
> [ 236.973235] usb 1-1.2: clear tt 1 (9061) error -110
> [ 238.012573] usb 1-1.2: clear tt 1 (9063) error -110
> [ 238.013052] usb 1-1.2.1: clear tt 1 (9073) error -110
> [ 238.013456] hub 1-1:1.0: hub_ext_port_status failed (err = -110)
> [ 239.052567] usb 1-1.2.1: clear tt 1 (9071) error -110
> [ 239.053076] usb 1-1.2: clear tt 1 (9061) error -110
> [ 240.092573] usb 1-1.2: clear tt 1 (9063) error -110
> [ 240.093050] usb 1-1.2.1: clear tt 1 (9073) error -110
> [ 240.239643] usb 1-1.2.1: USB disconnect, device number 5
> [ 240.239685] usb 1-1.2.1.2: USB disconnect, device number 7
> [ 240.262707] usb 1-1.2: clear tt 1 (9061) error -71
> [ 240.263123] usb 1-1.2.1: clear tt 1 (9071) error -71
> [ 240.263708] usb 1-1.2: USB disconnect, device number 4
> [ 694304] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
> [ 251.694645] pl2303 1-1.2.2:1.0: device disconnected
> [ 251.704668] usb 1-1.2.3: USB disconnect, device number 8
> [ 251.706468] pl2303 ttyUSB2: pl2303 converter now disconnected from ttyUSB2
> [ 251.706894] pl2303 1-1.2.3:1.0: device disconnected
> [ 251.714720] usb 1-1.2.4: USB disconnect, device number 10
> [ 251.733019] pl2303 ttyUSB4: pl2303 converter now disconnected from ttyUSB4
> [ 251.733459] pl2303 1-1.2.4:1.0: device disconnected
> [ 251.852767] hub 1-1.2:1.0: activate --> -19
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
^ permalink raw reply
* [PATCH] Revert "arm64: Increase the max granular size"
From: Sunil Kovvuri @ 2017-04-17 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <93d2819a-95b1-6606-74d4-0bc0a64db29e@codeaurora.org>
>> >> Do you have an explanation on the performance variation when
>> >> L1_CACHE_BYTES is changed? We'd need to understand how the network stack
>> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for
>> >> non-coherent DMA?).
>> >
>> > network stack use SKB_DATA_ALIGN to align.
>> > ---
>> > #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
>> > ~(SMP_CACHE_BYTES - 1))
>> >
>> > #define SMP_CACHE_BYTES L1_CACHE_BYTES
>> > ---
>> > I think this is the reason of performance regression.
>> >
>>
>> Yes this is the reason for performance regression. Due to increases L1 cache alignment the
>> object is coming from next kmalloc slab and skb->truesize is changing from 2304 bytes to
>> 4352 bytes. This in turn increases sk_wmem_alloc which causes queuing of less send buffers.
With what traffic did you check 'skb->truesize' ?
Increase from 2304 to 4352 bytes doesn't seem to be real. I checked
with ICMP pkts with maximum
size possible with 1500byte MTU and I don't see such a bump. If the
bump is observed with Iperf
sending TCP packets then I suggest to check if TSO is playing a part over here.
And for 'sk_wmem_alloc', I have done Iperf benchmarking on a 40G
interface and I hit linerate irrespective
of cache line size being 64 or 128 bytes. I guess transmit completion
latency on your HW or driver is very
high and that seems to be the real issue for low performance and not
due to cache line size, basically you are
not able to freeup skbs/buffers fast enough so that new ones get queued up.
Doesn't skb_orphan() solve your issue ?
FYI,
https://patchwork.ozlabs.org/patch/455134/
http://lxr.free-electrons.com/source/drivers/net/ethernet/chelsio/cxgb3/sge.c#L1288
>>
>> We tried different benchmarks and found none which really affects with Cache line change. If there is no correctness issue,
>> I think we are fine with reverting the patch.
>>
> So, can we revert the patch that makes L1_CACHE_SHIFT 7 or should the patch suggested by Catalin should be mainlined.
This doesn't seem right, as someone said earlier what if there is
another arm64 platform with 32bytes
cacheline size and wants to reduce this further. Either this should be
made platform dependent or left as is
i.e that is maximum of all.
Thanks,
Sunil.
^ permalink raw reply
* [PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU
From: Icenowy Zheng @ 2017-04-17 10:34 UTC (permalink / raw)
To: linux-arm-kernel
The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible.
Fix it by changing it to the correct H3 compatible.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 1aeeacb3a884..d0067fec99de 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -558,7 +558,7 @@
};
r_ccu: clock at 1f01400 {
- compatible = "allwinner,sun50i-a64-r-ccu";
+ compatible = "allwinner,sun8i-h3-r-ccu";
reg = <0x01f01400 0x100>;
clocks = <&osc24M>, <&osc32k>, <&iosc>;
clock-names = "hosc", "losc", "iosc";
--
2.12.2
^ permalink raw reply related
* [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page
From: Russell King - ARM Linux @ 2017-04-17 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4c51bf1a-00cb-84bb-f661-6bb6c83d8134@osg.samsung.com>
On Sun, Apr 16, 2017 at 07:10:21PM -0600, Shuah Khan wrote:
> On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote:
> > On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote:
> >>>> This would be however quite large task, especially taking into account
> >>>> all current users of DMA-buf framework...
> >>> Yeah it will be a large task.
> >>
> >> Maybe once scatterlist are switched to pfns, changing dmabuf internal
> >> memory representation to pfn array might be much easier.
> >
> > Switching to a PFN array won't work either as we have no cross-arch
> > way to translate PFNs to a DMA address and vice versa. Yes, we have
> > them in ARM, but they are an _implementation detail_ of ARM's
> > DMA API support, they are not for use by drivers.
> >
> > So, the very first problem that needs solving is this:
> >
> > How do we go from a coherent DMA allocation for device X to a set
> > of DMA addresses for device Y.
> >
> > Essentially, we need a way of remapping the DMA buffer for use with
> > another device, and returning a DMA address suitable for that device.
> > This could well mean that we need to deal with setting up an IOMMU
> > mapping. My guess is that this needs to happen at the DMA coherent
> > API level - the DMA coherent API needs to be augmented with support
> > for this. I'll call this "DMA coherent remap".
> >
> > We then need to think about how to pass this through the dma-buf API.
> > dma_map_sg() is done by the exporter, who should know what kind of
> > memory is being exported. The exporter can avoid calling dma_map_sg()
> > if it knows in advance that it is exporting DMA coherent memory.
> > Instead, the exporter can simply create a scatterlist with the DMA
> > address and DMA length prepopulated with the results of the DMA
> > coherent remap operation above.
>
> The only way to conclusively say that it is coming from coherent area
> is at the time it is getting allocated in dma_alloc_from_coherent().
> Since dma_alloc_attrs() will go on to find memory from other areas if
> dma_alloc_from_coherent() doesn't allocate memory.
Sorry, I disagree.
The only thing that matters is "did this memory come from
dma_alloc_coherent()". It doesn't matter where dma_alloc_coherent()
ultimately got the memory from, it's memory from the coherent allocator
interface, and it should not be passed back into the streaming APIs.
It is, after all, DMA _coherent_ memory, passing it into the streaming
APIs which is for DMA _noncoherent_ memory is insane - the streaming APIs
can bring extra expensive cache flushes, which are not required for
DMA _coherent_ memory.
The exporter should know where it got the memory from. It's really not
sane for anyone except the _original_ allocator to be exporting memory
through a DMA buffer - only the original allocator knows the properties
of that memory, and how to map it, whether that be for DMA, kmap or
mmap.
If a dmabuf is imported into a driver and then re-exported, the original
dmabuf should be what is re-exported, not some creation of the driver -
the re-exporting driver can't know what the properties of the memory
backing the dmabuf are, so anything else is just insane.
> How about adding get_sgtable, map_sg, unmap_sg to dma_buf_ops. The right
> ops need to be installed based on buffer type. As I mentioned before, we
> don't know which memory we got until dma_alloc_from_coherent() finds
> memory in dev->mem area. So how about using the dma_check_dev_coherent()
> to determine which ops we need. These could be set based on buffer type.
> vb2_dc_get_dmabuf() can do that.
Given my statement above, I don't believe any of that is necessary. All
memory allocated from dma_alloc_coherent() is DMA coherent. So, if
memory was obtained from dma_alloc_coherent() or similar, then it must
not be passed to the streaming DMA API. It doesn't matter where it
ultimately came from.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space
From: Ard Biesheuvel @ 2017-04-17 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417093201.10181-1-ard.biesheuvel@linaro.org>
As reported by James, Catalin and Mark, commit e69176d68d26
("ef/libstub/arm/arm64: Randomize the base of the UEFI rt services
region") results in a crash in the firmware regardless of whether KASLR
is in effect or not, and whether the firmware implements EFI_RNG_PROTOCOL
or not.
Mark has identified the root cause to be the inappropriate use of
TASK_SIZE in the stub, which arm64 defines as
#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
TASK_SIZE_32 : TASK_SIZE_64)
and testing thread flags at this point results in the dereference of
pointers in uninitialized structures.
So instead, introduce a preprocessor symbol EFI_RT_VIRTUAL_LIMIT and
define it to TASK_SIZE_64 on arm64 and TASK_SIZE on ARM, both of which
are compile time constants. Also, change the 'headroom' variable to
static const to force an error if this might change in the future.
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: James Morse <james.morse@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/arm-stub.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 1e45ec51b094..34010ff3b77e 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -32,6 +32,12 @@
#define EFI_RT_VIRTUAL_BASE SZ_512M
#define EFI_RT_VIRTUAL_SIZE SZ_512M
+#ifdef CONFIG_ARM64
+#define EFI_RT_VIRTUAL_LIMIT TASK_SIZE_64
+#else
+#define EFI_RT_VIRTUAL_LIMIT TASK_SIZE
+#endif
+
static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
@@ -236,8 +242,9 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
* shift of 21 bit positions into account when scaling
* the headroom value using a 32-bit random value.
*/
- u64 headroom = TASK_SIZE - EFI_RT_VIRTUAL_BASE -
- EFI_RT_VIRTUAL_SIZE;
+ static const u64 headroom = EFI_RT_VIRTUAL_LIMIT -
+ EFI_RT_VIRTUAL_BASE -
+ EFI_RT_VIRTUAL_SIZE;
u32 rnd;
status = efi_get_random_bytes(sys_table, sizeof(rnd),
--
2.9.3
^ permalink raw reply related
* [GIT PULL] EFI fixup for v4.12 queue
From: Ard Biesheuvel @ 2017-04-17 9:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Please merge this onto the v4.12 EFI queue: it fixes an issue reported with
-next where arm64 machines fail to boot due to a premature dereference of the
'current' pointer.
The following changes since commit efc491b0f06f65ea588f6591f0bc31db779e0594:
ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region (2017-04-02 16:36:29 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next
for you to fetch changes up to d3e759649e1b057da72a8981aaafcd2f34f10681:
efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space (2017-04-17 08:16:25 +0100)
----------------------------------------------------------------
A single fix for a regression caused by changes that are queued for v4.12:
- don't use TASK_SIZE in the stub on arm64, as it depends on thread flags
----------------------------------------------------------------
Ard Biesheuvel (1):
efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space
drivers/firmware/efi/libstub/arm-stub.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH v2 11/11] arm64: allwinner: a64: enable Wi-Fi for Pine64
From: Maxime Ripard @ 2017-04-17 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e51897d2-aa9d-1f4b-3fe0-e88246a9e438@suse.de>
On Fri, Apr 14, 2017 at 06:56:16PM +0200, Andreas F?rber wrote:
> > one provides I/O voltage).
> >
> > Add device node for it.
> >
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > index 7da074f95065..9d90bb32aa87 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > @@ -64,6 +64,11 @@
> > regulator-min-microvolt = <3300000>;
> > regulator-max-microvolt = <3300000>;
> > };
> > +
> > + wifi_pwrseq: wifi_pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> > + };
> > };
> >
> > &ehci1 {
> > @@ -91,6 +96,17 @@
> > status = "okay";
> > };
> >
> > +&mmc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
> > + vmmc-supply = <®_dldo4>;
> > + vqmmc-supply = <®_eldo1>;
> > + mmc-pwrseq = <&wifi_pwrseq>;
> > + non-removable;
> > + bus-width = <4>;
> > + status = "okay";
> > +};
>
> As you mention above, Wi-Fi is a module, so may be absent. Is it really
> correct to enable this node and hardcode a certain power sequence? In
> theory other modules could be attached.
>
> To me that calls for an overlay instead.
Agreed.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170417/ff7de77c/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm64: allwinner: h5: add support for Orange Pi Prime board
From: Maxime Ripard @ 2017-04-17 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413163807.28931-1-icenowy@aosc.io>
On Fri, Apr 14, 2017 at 12:38:07AM +0800, Icenowy Zheng wrote:
> Orange Pi Prime is a new Allwinner H5-based SBC by Xunlong.
>
> It's like a Orange Pi Plus 2E with H3 replaced with H5, eMMC replaced
> with onboard SPI NOR Flash and wireless card changed to Realtek
> RTL8723BS (with Bluetooth functionality).
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170417/69acc42b/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] arm64: allwinner: a64: enable EHCI0/OHCI0 for Pine64
From: Maxime Ripard @ 2017-04-17 7:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414131555.9431-2-icenowy@aosc.io>
On Fri, Apr 14, 2017 at 09:15:55PM +0800, Icenowy Zheng wrote:
> As we have USB0 controller switch available on A64, we should now enable
> the EHCI0/OHCI0 controllers for Pine64.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170417/421147a0/attachment.sig>
^ permalink raw reply
* [PATCH 4/5] ARM: sun8i: h3: add operating-points-v2 table for CPU
From: Maxime Ripard @ 2017-04-17 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <40F4D1F2-EA59-4BD1-9A00-4C0AA7FED9D3@aosc.io>
On Mon, Apr 17, 2017 at 05:00:00AM +0800, Icenowy Zheng wrote:
>
>
> ? 2017?4?17? GMT+08:00 ??4:57:40, Maxime Ripard <maxime.ripard@free-electrons.com> ??:
> >On Tue, Apr 11, 2017 at 09:28:55PM +0800, icenowy at aosc.io wrote:
> >> ? 2017-04-11 17:13?Maxime Ripard ???
> >> > On Sun, Apr 09, 2017 at 02:50:24AM +0800, Icenowy Zheng wrote:
> >> > > The CPU on Allwinner H3 can do dynamic frequency scaling.
> >> > >
> >> > > Add a DVFS table based on the one tweaked by Armbian developers,
> >which
> >> > > are proven to work stably on BSP kernels.
> >> > >
> >> > > Frequencies higher than 1008MHz are temporarily dropped in the
> >> > > table, as
> >> > > they may lead to over voltage on boards without proper regulator
> >> > > settings or over temperature on boards with proper regulator
> >settings.
> >> > > They will be added back once regulator settings are ready and
> >thermal
> >> > > sensor driver is merged.
> >> > >
> >> > > In order to satisfy all different regulators (SY8106A which is
> >50mV
> >> > > per
> >> > > level, SY8113B which have two states: 1.1V and 1.3V, and some
> >board
> >> > > with
> >> > > non-tweakable regulators), all the OPPs are defined with a range
> >> > > which has
> >> > > the target value as the minimum allowed value, and 1.3V (the
> >highest
> >> > > VDD-CPUX voltage suggested by the datasheet) as the maximum
> >allowed
> >> > > value.
> >> > > It's proven to work well with a board with SY8113B.
> >> > >
> >> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> > > ---
> >> > > arch/arm/boot/dts/sun8i-h3.dtsi | 38
> >> > > +++++++++++++++++++++++++++++++++++++-
> >> > > 1 file changed, 37 insertions(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> >> > > b/arch/arm/boot/dts/sun8i-h3.dtsi
> >> > > index b36f9f423c39..a0cee17fe44b 100644
> >> > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> >> > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> >> > > @@ -43,32 +43,68 @@
> >> > > #include "sunxi-h3-h5.dtsi"
> >> > >
> >> > > / {
> >> > > + cpu0_opp_table: opp_table0 {
> >> > > + compatible = "operating-points-v2";
> >> > > + opp-shared;
> >> > > +
> >> > > + opp at 480000000 {
> >> > > + opp-hz = /bits/ 64 <480000000>;
> >> > > + opp-microvolt = <980000 980000 1300000>;
> >> > > + clock-latency-ns = <244144>; /* 8 32k periods */
> >> > > + };
> >> > > +
> >> > > + opp at 648000000 {
> >> > > + opp-hz = /bits/ 64 <816000000>;
> >> > > + opp-microvolt = <1020000 1020000 1300000>;
> >> > > + clock-latency-ns = <244144>; /* 8 32k periods */
> >> > > + };
> >> > > +
> >> > > + opp at 912000000 {
> >> > > + opp-hz = /bits/ 64 <960000000>;
> >> > > + opp-microvolt = <1080000 1080000 1300000>;
> >> > > + clock-latency-ns = <244144>; /* 8 32k periods */
> >> > > + };
> >> > > +
> >> > > + opp at 1008000000 {
> >> > > + opp-hz = /bits/ 64 <1008000000>;
> >> > > + opp-microvolt = <1140000 1140000 1300000>;
> >> > > + clock-latency-ns = <244144>; /* 8 32k periods */
> >> > > + };
> >> > > + };
> >> > > +
> >> >
> >> > From your serie, I guess you never actually tested those OPPs on
> >any
> >> > board without SY8113B, right?
> >>
> >> Yes. But I will test them on an Orange Pi PC (newly got) soon.
> >
> >The orange pi pc also uses the SY8113B.
>
> I remember in H3 Orange Pi's only One, Lite and Zero uses SY8113B,
> and PC is SY8106A.
Ah, my bad, I confused the two.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170417/516cd3a6/attachment-0001.sig>
^ permalink raw reply
* [PATCH] Revert "arm64: Increase the max granular size"
From: Imran Khan @ 2017-04-17 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <725F073F-025B-48B9-9935-24EFEBF2B7DC@caviumnetworks.com>
On 4/12/2017 7:30 PM, Chalamarla, Tirumalesh wrote:
>
>
> On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan" <linux-arm-kernel-bounces at lists.infradead.org on behalf of kimran@codeaurora.org> wrote:
>
> On 4/7/2017 7:36 AM, Ganesh Mahendran wrote:
> > 2017-04-06 23:58 GMT+08:00 Catalin Marinas <catalin.marinas@arm.com>:
> >> On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote:
> >>> On 4/5/2017 10:13 AM, Imran Khan wrote:
> >>>>> We may have to revisit this logic and consider L1_CACHE_BYTES the
> >>>>> _minimum_ of cache line sizes in arm64 systems supported by the kernel.
> >>>>> Do you have any benchmarks on Cavium boards that would show significant
> >>>>> degradation with 64-byte L1_CACHE_BYTES vs 128?
> >>>>>
> >>>>> For non-coherent DMA, the simplest is to make ARCH_DMA_MINALIGN the
> >>>>> _maximum_ of the supported systems:
> >>>>>
> >>>>> diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
> >>>>> index 5082b30bc2c0..4b5d7b27edaf 100644
> >>>>> --- a/arch/arm64/include/asm/cache.h
> >>>>> +++ b/arch/arm64/include/asm/cache.h
> >>>>> @@ -18,17 +18,17 @@
> >>>>>
> >>>>> #include <asm/cachetype.h>
> >>>>>
> >>>>> -#define L1_CACHE_SHIFT 7
> >>>>> +#define L1_CACHE_SHIFT 6
> >>>>> #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
> >>>>>
> >>>>> /*
> >>>>> * Memory returned by kmalloc() may be used for DMA, so we must make
> >>>>> - * sure that all such allocations are cache aligned. Otherwise,
> >>>>> - * unrelated code may cause parts of the buffer to be read into the
> >>>>> - * cache before the transfer is done, causing old data to be seen by
> >>>>> - * the CPU.
> >>>>> + * sure that all such allocations are aligned to the maximum *known*
> >>>>> + * cache line size on ARMv8 systems. Otherwise, unrelated code may cause
> >>>>> + * parts of the buffer to be read into the cache before the transfer is
> >>>>> + * done, causing old data to be seen by the CPU.
> >>>>> */
> >>>>> -#define ARCH_DMA_MINALIGN L1_CACHE_BYTES
> >>>>> +#define ARCH_DMA_MINALIGN (128)
> >>>>>
> >>>>> #ifndef __ASSEMBLY__
> >>>>>
> >>>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> >>>>> index 392c67eb9fa6..30bafca1aebf 100644
> >>>>> --- a/arch/arm64/kernel/cpufeature.c
> >>>>> +++ b/arch/arm64/kernel/cpufeature.c
> >>>>> @@ -976,9 +976,9 @@ void __init setup_cpu_features(void)
> >>>>> if (!cwg)
> >>>>> pr_warn("No Cache Writeback Granule information, assuming
> >>>>> cache line size %d\n",
> >>>>> cls);
> >>>>> - if (L1_CACHE_BYTES < cls)
> >>>>> - pr_warn("L1_CACHE_BYTES smaller than the Cache Writeback Granule (%d < %d)\n",
> >>>>> - L1_CACHE_BYTES, cls);
> >>>>> + if (ARCH_DMA_MINALIGN < cls)
> >>>>> + pr_warn("ARCH_DMA_MINALIGN smaller than the Cache Writeback Granule (%d < %d)\n",
> >>>>> + ARCH_DMA_MINALIGN, cls);
> >>>>> }
> >>>>>
> >>>>> static bool __maybe_unused
> >>>>
> >>>> This change was discussed at: [1] but was not concluded as apparently no one
> >>>> came back with test report and numbers. After including this change in our
> >>>> local kernel we are seeing significant throughput improvement. For example with:
> >>>>
> >>>> iperf -c 192.168.1.181 -i 1 -w 128K -t 60
> >>>>
> >>>> The average throughput is improving by about 30% (230Mbps from 180Mbps).
> >>>> Could you please let us know if this change can be included in upstream kernel.
> >>>>
> >>>> [1]: https://groups.google.com/forum/#!topic/linux.kernel/P40yDB90ePs
> >>>
> >>> Could you please provide some feedback about the above mentioned query ?
> >>
> >> Do you have an explanation on the performance variation when
> >> L1_CACHE_BYTES is changed? We'd need to understand how the network stack
> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for
> >> non-coherent DMA?).
> >
> > network stack use SKB_DATA_ALIGN to align.
> > ---
> > #define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
> > ~(SMP_CACHE_BYTES - 1))
> >
> > #define SMP_CACHE_BYTES L1_CACHE_BYTES
> > ---
> > I think this is the reason of performance regression.
> >
>
> Yes this is the reason for performance regression. Due to increases L1 cache alignment the
> object is coming from next kmalloc slab and skb->truesize is changing from 2304 bytes to
> 4352 bytes. This in turn increases sk_wmem_alloc which causes queuing of less send buffers.
>
> We tried different benchmarks and found none which really affects with Cache line change. If there is no correctness issue,
> I think we are fine with reverting the patch.
>
So, can we revert the patch that makes L1_CACHE_SHIFT 7 or should the patch suggested by Catalin should be mainlined.
We have verified the throughput degradation on 3.18 and 4.4 but I am afraid that this issue will be seen on other
kernels too.
> Though I still think it is beneficiary to do some more investigation for the perf loss, who knows 32 bit align or no align might
> Give even more perf benefit.
>
Which perf loss you are referring to here. Did you mean throughput loss here or some other perf benchmarking ?
Thanks,
Imran
>
> Thanks,
> Tirumalesh.
> >>
> >> The Cavium guys haven't shown any numbers (IIUC) to back the
> >> L1_CACHE_BYTES performance improvement but I would not revert the
> >> original commit since ARCH_DMA_MINALIGN definitely needs to cover the
> >> maximum available cache line size, which is 128 for them.
> >
> > how about define L1_CACHE_SHIFT like below:
> > ---
> > #ifdef CONFIG_ARM64_L1_CACHE_SHIFT
> > #define L1_CACHE_SHIFT CONFIG_ARM64_L1_CACHE_SHIFT
> > #else
> > #define L1_CACHE_SHIFT 7
> > endif
> > ---
> >
> > Thanks
> >
> >>
> >> --
> >> Catalin
>
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 0/5] arm: spear6xx: DT cleanups and improvements
From: Viresh Kumar @ 2017-04-17 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417091016.1f0732a9@free-electrons.com>
On 17-04-17, 09:10, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 17 Apr 2017 09:36:55 +0530, Viresh Kumar wrote:
>
> > Yes, that would be the normal flow and I did that initially. But then the number
> > of patches really decreased and its better to send the patches directly to ARM
> > maintainers so that they can apply them. No need of PULL requests really.
> >
> > Send them to: arm-soc <arm@kernel.org>
>
> OK, thanks. I more recently sent two other SPEAr600 patches, one adding
> the ADC to the DT, one fixing the clock driver for the ADC clock.
>
> Could you have a look at them, and hopefully give your Acked-by, so
> that I can get send them to arm-soc at the same time?
Already done this morning.
--
viresh
^ 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