[linux-sunxi] [RFT PATCH 2/9] power: supply: axp20x_usb_power: Fix typo in VBUS current limit macros
The VBUS current limit value macros have VBUS typed as VBUC, while
the bitmask macro is named correctly. Fix it.
Fixes: 69fb4dcada77 ("power: Add an axp20x-usb-power driver")
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index f52fe77edb6f..cd9b90d79839 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -36,10 +36,10 @@
#define AXP20X_VBUS_VHOLD_MASK GENMASK(5, 3)
#define AXP20X_VBUS_VHOLD_OFFSET 3
#define AXP20X_VBUS_CLIMIT_MASK3
-#define AXP20X_VBUC_CLIMIT_900mA 0
-#define AXP20X_VBUC_CLIMIT_500mA 1
-#define AXP20X_VBUC_CLIMIT_100mA 2
-#define AXP20X_VBUC_CLIMIT_NONE3
+#define AXP20X_VBUS_CLIMIT_900mA 0
+#define AXP20X_VBUS_CLIMIT_500mA 1
+#define AXP20X_VBUS_CLIMIT_100mA 2
+#define AXP20X_VBUS_CLIMIT_NONE3
#define AXP20X_ADC_EN1_VBUS_CURR BIT(2)
#define AXP20X_ADC_EN1_VBUS_VOLT BIT(3)
@@ -107,19 +107,19 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
return ret;
switch (v & AXP20X_VBUS_CLIMIT_MASK) {
- case AXP20X_VBUC_CLIMIT_100mA:
+ case AXP20X_VBUS_CLIMIT_100mA:
if (power->axp20x_id == AXP221_ID)
val->intval = -1; /* No 100mA limit */
else
val->intval = 10;
break;
- case AXP20X_VBUC_CLIMIT_500mA:
+ case AXP20X_VBUS_CLIMIT_500mA:
val->intval = 50;
break;
- case AXP20X_VBUC_CLIMIT_900mA:
+ case AXP20X_VBUS_CLIMIT_900mA:
val->intval = 90;
break;
- case AXP20X_VBUC_CLIMIT_NONE:
+ case AXP20X_VBUS_CLIMIT_NONE:
val->intval = -1;
break;
}
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFT PATCH 9/9] ARM: dts: sun8i: a83t: Enable USB OTG controller on some boards
The Bananapi M3 and Cubietruck Plus both have USB OTG ports wired to the
SoC and PMIC in the same way, with the N_VBUSEN pin on the PMIC
controlling VBUS output, the PMIC's VBUS input for sensing VBUS, and
PH11 on the SoC for sensing the ID pin.
Enable OTG on both boards.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 12
arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 12
2 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 838be7b3715f..9d34eabba121 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -389,7 +389,19 @@
};
};
+_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+_power_supply {
+ status = "okay";
+};
+
{
+ usb0_id_det-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
+ usb0_vbus_power-supply = <_power_supply>;
+ usb0_vbus-supply = <_drivevbus>;
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index fcbec3d7ccd7..ea299d3d84d0 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -420,7 +420,19 @@
};
};
+_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+_power_supply {
+ status = "okay";
+};
+
{
+ usb0_id_det-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
+ usb0_vbus_power-supply = <_power_supply>;
+ usb0_vbus-supply = <_drivevbus>;
usb1_vbus-supply = <_usb1_vbus>;
usb2_vbus-supply = <_usb2_vbus>;
status = "okay";
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFT PATCH 6/9] power: supply: axp20x_usb_power: add support for AXP813
From: Quentin Schulz
This adds support for AXP813 PMIC. It is almost the same as AXP22X but
has a different current limit.
Signed-off-by: Quentin Schulz
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 66 -
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index 90d06027bf98..d39c450b14c6 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -42,6 +42,11 @@
#define AXP20X_VBUS_CLIMIT_100mA 2
#define AXP20X_VBUS_CLIMIT_NONE3
+#define AXP813_VBUS_CLIMIT_900mA 0
+#define AXP813_VBUS_CLIMIT_1500mA 1
+#define AXP813_VBUS_CLIMIT_2000mA 2
+#define AXP813_VBUS_CLIMIT_2500mA 3
+
#define AXP20X_ADC_EN1_VBUS_CURR BIT(2)
#define AXP20X_ADC_EN1_VBUS_VOLT BIT(3)
@@ -131,6 +136,31 @@ static int axp20x_get_current_max(struct axp20x_usb_power
*power, int *val)
return 0;
}
+static int axp813_get_current_max(struct axp20x_usb_power *power, int *val)
+{
+ unsigned int v;
+ int ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
+
+ if (ret)
+ return ret;
+
+ switch (v & AXP20X_VBUS_CLIMIT_MASK) {
+ case AXP813_VBUS_CLIMIT_900mA:
+ *val = 90;
+ break;
+ case AXP813_VBUS_CLIMIT_1500mA:
+ *val = 150;
+ break;
+ case AXP813_VBUS_CLIMIT_2000mA:
+ *val = 200;
+ break;
+ case AXP813_VBUS_CLIMIT_2500mA:
+ *val = 250;
+ break;
+ }
+ return 0;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -169,6 +199,8 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
val->intval = ret * 1700; /* 1 step = 1.7 mV */
return 0;
case POWER_SUPPLY_PROP_CURRENT_MAX:
+ if (power->axp20x_id == AXP813_ID)
+ return axp813_get_current_max(power, >intval);
return axp20x_get_current_max(power, >intval);
case POWER_SUPPLY_PROP_CURRENT_NOW:
if (IS_ENABLED(CONFIG_AXP20X_ADC)) {
@@ -260,6 +292,31 @@ static int axp20x_usb_power_set_voltage_min(struct
axp20x_usb_power *power,
return -EINVAL;
}
+static int axp813_usb_power_set_current_max(struct axp20x_usb_power *power,
+ int intval)
+{
+ int val;
+
+ switch (intval) {
+ case 90:
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK,
+ AXP813_VBUS_CLIMIT_900mA);
+ case 150:
+ case 200:
+ case 250:
+ val = (intval - 100) / 50;
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK, val);
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
static int axp20x_usb_power_set_current_max(struct axp20x_usb_power *power,
int intval)
{
@@ -299,6 +356,9 @@ static int axp20x_usb_power_set_property(struct
power_supply *psy,
return axp20x_usb_power_set_voltage_min(power, val->intval);
case POWER_SUPPLY_PROP_CURRENT_MAX:
+ if (power->axp20x_id == AXP813_ID)
+ return axp813_usb_power_set_current_max(power,
+ val->intval);
return axp20x_usb_power_set_current_max(power, val->intval);
default:
@@ -434,7 +494,8 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
usb_power_desc = _usb_power_desc;
irq_names = axp20x_irq_names;
} else if (power->axp20x_id == AXP221_ID ||
- power->axp20x_id == AXP223_ID) {
+ power->axp20x_id == AXP223_ID ||
+ power->axp20x_id == AXP813_ID) {
usb_power_desc = _usb_power_desc;
irq_names = axp22x_irq_names;
} else {
@@ -493,6 +554,9 @@ static const struct of_device_id axp20x_usb_power_match[] =
{
}, {
.compatible = "x-powers,axp223-usb-power-supply",
.data = (void *)AXP223_ID,
+ }, {
+ .compatible = "x-powers,axp813-usb-power-supply",
+ .data = (void *)AXP813_ID,
}, { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
--
2.20.1
--
You received this message because you are subscribed to the
[linux-sunxi] [RFT PATCH 0/9] ARM: sun8i: a83t: Enable USB OTG
Hi everyone, This series enables USB OTG on the A83T boards. The AXP813/AXP818 PMICs used with the A83T have the same behavior as the AXP221 and AXP223, where if the N_VBUSEN pin is driven high, the VBUS sensing interrupts stop working. In the past Hans made a polling workaround in the USB PHY driver. In this series polling is added to the power supply driver. The power supply driver work was started by Quentin, and shared with me when I expressed interest in getting USB OTG to work some time ago. Neither of us got around to finishing it, until now that is. Patch 1 adds a new compatible string for the AXP813 VBUS power supply part. Patch 2 is a bit of cleanup work for the driver. Patch 3 allows disabling VBUS input current limiting on the AXP20x / AXP22x PMICs. While not strictly related to this series, I found it easier to just send everything together. This patch depends on the previous one. Patch 4 adds the VBUS status polling feature. This is enabled on AXP221 and all later PMICs. Patch 5 factors out code to read out the configured input current limit for the AXP20x and AXP22x PMICs. As the AXP813 uses different values, factoring out the code based on model will make the main function more readable. Patch 6 adds support for the AXP813 VBUS power supply. checkpatch.pl reports a few warnings for this patch: WARNING: Possible switch case/default not preceded by break or fallthrough comment #100: FILE: drivers/power/supply/axp20x_usb_power.c:306: + case 150: WARNING: Possible switch case/default not preceded by break or fallthrough comment #101: FILE: drivers/power/supply/axp20x_usb_power.c:307: + case 200: WARNING: Possible switch case/default not preceded by break or fallthrough comment #102: FILE: drivers/power/supply/axp20x_usb_power.c:308: + case 250: However they seem to be a false positive. The preceding line of the reported lines is a return statement, which is definitely not a fallthrough. Patch 7 adds an mfd cell for the newly supported VBUS power supply. Patch 8 adds a device node for the VBUS power supply to the common axp81x dtsi file. Patch 9 enables USB OTG on the Cubietruck Plus and Bananapi M3. Please have a look, and also test it on boards you have, and don't limit it to just the A83T ones. As mentioned above, the polling feature affects all boards that have an AXP221 or newer PMIC. I haven't removed the polling workaround from the USB PHY driver yet. That would be the next step after this series is merged, and preferrably a release has passed. Regards ChenYu Chen-Yu Tsai (5): dt-bindings: power: supply: axp20x_usb_power: add axp813 compatible power: supply: axp20x_usb_power: Fix typo in VBUS current limit macros power: supply: axp20x_usb_power: allow disabling input current limiting power: supply: axp20x_usb_power: use polling to detect vbus status change ARM: dts: sun8i: a83t: Enable USB OTG controller on some boards Quentin Schulz (4): power: supply: axp20x_usb_power: add function to get max current power: supply: axp20x_usb_power: add support for AXP813 mfd: axp20x: add USB power supply mfd cell to AXP813 ARM: dtsi: axp81x: add USB power supply node .../power/supply/axp20x_usb_power.txt | 1 + arch/arm/boot/dts/axp81x.dtsi | 4 + arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 12 ++ .../boot/dts/sun8i-a83t-cubietruck-plus.dts | 12 ++ drivers/mfd/axp20x.c | 11 ++ drivers/power/supply/axp20x_usb_power.c | 184 +++--- 6 files changed, 197 insertions(+), 27 deletions(-) -- 2.20.1 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFT PATCH 4/9] power: supply: axp20x_usb_power: use polling to detect vbus status change
On AXP221 and later AXP PMICs that have the N_VBUSEN pin, when this pin
is high, either due to the PMIC driving it high or as an input, the VBUS
detection related interrupt mechanisms are disabled.
Previously this was worked around in the phy-sun4i-usb driver, which
needed to sense VBUS changes and report them to the musb driver in a
timely matter. However this workaround was only for the A31 and A33 type
USB PHYs. To support newer platforms we would have to enable it for
almost all the post-A31 SoCs.
However, since this is actually the result of the PMIC's behavior, the
workaround would be better if done in the PMIC driver, in this case the
VBUS power supply driver.
Add the same workqueue-based polling to the VBUS power supply driver.
The polling interval is chosen to be the debounce interval from the USB
PHY driver, as this short interval is needed in some cases, but the
power supply driver would not know when.
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 53 +
1 file changed, 53 insertions(+)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index e2f353906bb1..ac061bcdc056 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define DRVNAME "axp20x-usb-power-supply"
@@ -46,6 +47,12 @@
#define AXP20X_VBUS_MON_VBUS_VALID BIT(3)
+/*
+ * Note do not raise the debounce time, we must report Vusb high within
+ * 100ms otherwise we get Vbus errors in musb.
+ */
+#define DEBOUNCE_TIME msecs_to_jiffies(50)
+
struct axp20x_usb_power {
struct device_node *np;
struct regmap *regmap;
@@ -53,6 +60,8 @@ struct axp20x_usb_power {
enum axp20x_variants axp20x_id;
struct iio_channel *vbus_v;
struct iio_channel *vbus_i;
+ struct delayed_work vbus_detect;
+ unsigned int old_status;
};
static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
@@ -64,6 +73,35 @@ static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
return IRQ_HANDLED;
}
+static void axp20x_usb_power_poll_vbus(struct work_struct *work)
+{
+ struct axp20x_usb_power *power =
+ container_of(work, struct axp20x_usb_power, vbus_detect.work);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, );
+ if (ret)
+ goto out;
+
+ val &= (AXP20X_PWR_STATUS_VBUS_PRESENT | AXP20X_PWR_STATUS_VBUS_USED);
+ if (val != power->old_status)
+ power_supply_changed(power->supply);
+
+ power->old_status = val;
+
+out:
+ mod_delayed_work(system_wq, >vbus_detect, DEBOUNCE_TIME);
+}
+
+static bool axp20x_usb_vbus_needs_polling(struct axp20x_usb_power *power)
+{
+ if (power->axp20x_id >= AXP221_ID)
+ return true;
+
+ return false;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -362,6 +400,7 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
if (!power)
return -ENOMEM;
+ platform_set_drvdata(pdev, power);
power->axp20x_id = (enum axp20x_variants)of_device_get_match_data(
>dev);
@@ -420,6 +459,19 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
irq_names[i], ret);
}
+ INIT_DELAYED_WORK(>vbus_detect, axp20x_usb_power_poll_vbus);
+ if (axp20x_usb_vbus_needs_polling(power))
+ queue_delayed_work(system_wq, >vbus_detect, 0);
+
+ return 0;
+}
+
+static int axp20x_usb_power_remove(struct platform_device *pdev)
+{
+ struct axp20x_usb_power *power = platform_get_drvdata(pdev);
+
+ cancel_delayed_work_sync(>vbus_detect);
+
return 0;
}
@@ -439,6 +491,7 @@ MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
static struct platform_driver axp20x_usb_power_driver = {
.probe = axp20x_usb_power_probe,
+ .remove = axp20x_usb_power_remove,
.driver = {
.name = DRVNAME,
.of_match_table = axp20x_usb_power_match,
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFT PATCH 5/9] power: supply: axp20x_usb_power: add function to get max current
From: Quentin Schulz
To prepare for a new PMIC, factor out the code responsible of returning
the maximum current to axp20x_get_current_max.
Signed-off-by: Quentin Schulz
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 52 ++---
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index ac061bcdc056..90d06027bf98 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -102,6 +102,35 @@ static bool axp20x_usb_vbus_needs_polling(struct
axp20x_usb_power *power)
return false;
}
+static int axp20x_get_current_max(struct axp20x_usb_power *power, int *val)
+{
+ unsigned int v;
+ int ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
+
+ if (ret)
+ return ret;
+
+ switch (v & AXP20X_VBUS_CLIMIT_MASK) {
+ case AXP20X_VBUS_CLIMIT_100mA:
+ if (power->axp20x_id == AXP221_ID)
+ *val = -1; /* No 100mA limit */
+ else
+ *val = 10;
+ break;
+ case AXP20X_VBUS_CLIMIT_500mA:
+ *val = 50;
+ break;
+ case AXP20X_VBUS_CLIMIT_900mA:
+ *val = 90;
+ break;
+ case AXP20X_VBUS_CLIMIT_NONE:
+ *val = -1;
+ break;
+ }
+
+ return 0;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -140,28 +169,7 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
val->intval = ret * 1700; /* 1 step = 1.7 mV */
return 0;
case POWER_SUPPLY_PROP_CURRENT_MAX:
- ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
- if (ret)
- return ret;
-
- switch (v & AXP20X_VBUS_CLIMIT_MASK) {
- case AXP20X_VBUS_CLIMIT_100mA:
- if (power->axp20x_id == AXP221_ID)
- val->intval = -1; /* No 100mA limit */
- else
- val->intval = 10;
- break;
- case AXP20X_VBUS_CLIMIT_500mA:
- val->intval = 50;
- break;
- case AXP20X_VBUS_CLIMIT_900mA:
- val->intval = 90;
- break;
- case AXP20X_VBUS_CLIMIT_NONE:
- val->intval = -1;
- break;
- }
- return 0;
+ return axp20x_get_current_max(power, >intval);
case POWER_SUPPLY_PROP_CURRENT_NOW:
if (IS_ENABLED(CONFIG_AXP20X_ADC)) {
ret = iio_read_channel_processed(power->vbus_i,
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFT PATCH 3/9] power: supply: axp20x_usb_power: allow disabling input current limiting
The AXP PMICs allow the user to disable current limiting on the VBUS input. While read-out of this setting was already supported by the driver, it did not allow the user to configure the PMIC to disable current limiting. Add support for this. Signed-off-by: Chen-Yu Tsai --- drivers/power/supply/axp20x_usb_power.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c index cd9b90d79839..e2f353906bb1 100644 --- a/drivers/power/supply/axp20x_usb_power.c +++ b/drivers/power/supply/axp20x_usb_power.c @@ -230,6 +230,11 @@ static int axp20x_usb_power_set_current_max(struct axp20x_usb_power *power, return regmap_update_bits(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_CLIMIT_MASK, val); + case -1: + return regmap_update_bits(power->regmap, + AXP20X_VBUS_IPSOUT_MGMT, + AXP20X_VBUS_CLIMIT_MASK, + AXP20X_VBUS_CLIMIT_NONE); default: return -EINVAL; } -- 2.20.1 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFT PATCH 8/9] ARM: dtsi: axp81x: add USB power supply node
From: Quentin Schulz
The AXP813/818 has a VBUS power input. Add a device node for it, now
that we support it.
Signed-off-by: Quentin Schulz
[w...@csie.org: Add commit message]
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/axp81x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
index bd83962d3627..1dfeeceabf4c 100644
--- a/arch/arm/boot/dts/axp81x.dtsi
+++ b/arch/arm/boot/dts/axp81x.dtsi
@@ -171,4 +171,8 @@
status = "disabled";
};
};
+
+ usb_power_supply: usb-power-supply {
+ compatible = "x-powers,axp813-usb-power-supply";
+ };
};
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFT PATCH 1/9] dt-bindings: power: supply: axp20x_usb_power: add axp813 compatible
This adds the "x-powers,axp813-usb-power-supply" to the list of compatibles for AXP20X VBUS power supply driver. Signed-off-by: Chen-Yu Tsai --- .../devicetree/bindings/power/supply/axp20x_usb_power.txt| 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt index ba8d35f66cbe..b2d4968fde7d 100644 --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt @@ -4,6 +4,7 @@ Required Properties: -compatible: One of: "x-powers,axp202-usb-power-supply" "x-powers,axp221-usb-power-supply" "x-powers,axp223-usb-power-supply" +"x-powers,axp813-usb-power-supply" The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight variations such as the former being able to set the VBUS power supply max -- 2.20.1 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFT PATCH 7/9] mfd: axp20x: add USB power supply mfd cell to AXP813
From: Quentin Schulz
The AXP813 has a VBUS power input. Now that the axp20x_usb_power driver
supports this variant, we can add an mfd cell for it to use it.
Signed-off-by: Quentin Schulz
[w...@csie.org: add commit message]
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3c97f2c0fdfe..17b115845993 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -198,6 +198,12 @@ static const struct resource
axp22x_usb_power_supply_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
};
+/* AXP803 and AXP813/AXP818 share the same interrupts */
+static struct resource axp803_usb_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP803_IRQ_VBUS_PLUGIN, "VBUS_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP803_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
+};
+
static const struct resource axp22x_pek_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
@@ -793,6 +799,11 @@ static const struct mfd_cell axp813_cells[] = {
.of_compatible = "x-powers,axp813-ac-power-supply",
.num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
.resources = axp20x_ac_power_supply_resources,
+ }, {
+ .name = "axp20x-usb-power-supply",
+ .num_resources = ARRAY_SIZE(axp803_usb_power_supply_resources),
+ .resources = axp803_usb_power_supply_resources,
+ .of_compatible = "x-powers,axp813-usb-power-supply",
},
};
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/3] arm: introduce _relaxed MMIO accessors
On 06/02/2019 12:46, Philipp Tomsich wrote: > On 11.01.2019, at 01:31, Andre Przywara wrote: Hi, >> >> The normal MMIO accessor macros (readX/writeX) guarantee a strong ordering, >> even with normal memory accesses [1]. >> For some MMIO operations (framebuffers being a prominent example) this is >> not needed, and the rather costly barrier inserted on weakly ordered >> systems like ARM costs some performance. >> To mitigate this issue, Linux introduced readX_relaxed and >> writeX_relaxed primitives, which only guarantee ordering between each >> other, so are typically faster due to the missing barrier. >> >> We probably do not care so much about performance in U-Boot, but want to >> have those primitives for two other reasons: >> - Being able to use the _relaxed macros simplifies porting drivers from >> Linux. >> - The missing barrier typically allows to generate smaller code, which can >> relieve some chronically tight SPL builds. >> >> Add those macros definitions by using the __raw versions of the >> accessors, which matches an earlier (and less complicated) version of >> the Linux implementation. >> >> [1] https://lwn.net/Articles/698014/ > > No Signed-off-by? Doh, indeed. Got so excited about my commit message, that I forgot the obvious (and I only think about -s *after* hitting Enter). > Reviewed-by: Philipp Tomsich > [On my experimental RK3399 after modifying a few drivers:] > Tested-by: Philipp Tomsich Cool, many thanks for that! Out of curiosity, did you really need *_relaxed for some reason? Cheers, Andre. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 1/3] mmc: sunxi: Disable HS-DDR mode for H5 eMMC controller by default
On Tue, 5 Feb 2019 at 16:42, Chen-Yu Tsai wrote:
>
> Some H5 boards seem to not have proper trace lengths for eMMC to be able
> to use the default setting for the delay chains under HS-DDR mode. These
> include the Bananapi M2+ H5 and NanoPi NEO Core2. However the Libre
> Computer ALL-H3-CC-H5 works just fine.
>
> For the H5 (at least for now), default to not enabling HS-DDR modes in
> the driver, and expect the device tree to signal HS-DDR capability on
> boards that work.
>
> Reported-by: Chris Blake
> Fixes: 07bafc1e3536 ("mmc: sunxi: Use new timing mode for A64 eMMC
> controller")
> Cc:
> Acked-by: Maxime Ripard
> Signed-off-by: Chen-Yu Tsai
Applied for fixes, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sunxi-mmc.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 279e326e397e..7415af8c8ff6 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1399,7 +1399,16 @@ static int sunxi_mmc_probe(struct platform_device
> *pdev)
> mmc->caps |= MMC_CAP_MMC_HIGHSPEED |
> MMC_CAP_SD_HIGHSPEED |
> MMC_CAP_ERASE | MMC_CAP_SDIO_IRQ;
>
> - if (host->cfg->clk_delays || host->use_new_timings)
> + /*
> +* Some H5 devices do not have signal traces precise enough to
> +* use HS DDR mode for their eMMC chips.
> +*
> +* We still enable HS DDR modes for all the other controller
> +* variants that support them.
> +*/
> + if ((host->cfg->clk_delays || host->use_new_timings) &&
> + !of_device_is_compatible(pdev->dev.of_node,
> +"allwinner,sun50i-h5-emmc"))
> mmc->caps |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
>
> ret = mmc_of_parse(mmc);
> --
> 2.20.1
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 2/3] mmc: sunxi: Filter out unsupported modes declared in the device tree
On Tue, 5 Feb 2019 at 16:42, Chen-Yu Tsai wrote:
>
> The MMC device tree bindings include properties used to signal various
> signalling speed modes. Until now the sunxi driver was accepting them
> without any further filtering, while the sunxi device trees were not
> actually using them.
>
> Since some of the H5 boards can not run at higher speed modes stably,
> we are resorting to declaring the higher speed modes per-board.
>
> Regardless, having boards declare modes and blindly following them,
> even without proper support in the driver, is generally a bad thing.
>
> Filter out all unsupported modes from the capabilities mask after
> the device tree properties have been parsed.
>
> Cc:
> Signed-off-by: Chen-Yu Tsai
>
Applied for fixes, thanks!
Kind regards
Uffe
> ---
>
> This should be backported to stable kernels in case people try to run
> new device trees (that declare newly supported modes) with old kernels.
> ---
> drivers/mmc/host/sunxi-mmc.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 7415af8c8ff6..70fadc976795 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1415,6 +1415,21 @@ static int sunxi_mmc_probe(struct platform_device
> *pdev)
> if (ret)
> goto error_free_dma;
>
> + /*
> +* If we don't support delay chains in the SoC, we can't use any
> +* of the higher speed modes. Mask them out in case the device
> +* tree specifies the properties for them, which gets added to
> +* the caps by mmc_of_parse() above.
> +*/
> + if (!(host->cfg->clk_delays || host->use_new_timings)) {
> + mmc->caps &= ~(MMC_CAP_3_3V_DDR | MMC_CAP_1_8V_DDR |
> + MMC_CAP_1_2V_DDR | MMC_CAP_UHS);
> + mmc->caps2 &= ~MMC_CAP2_HS200;
> + }
> +
> + /* TODO: This driver doesn't support HS400 mode yet */
> + mmc->caps2 &= ~MMC_CAP2_HS400;
> +
> ret = sunxi_mmc_init_host(host);
> if (ret)
> goto error_free_dma;
> --
> 2.20.1
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 3/3] arm64: dts: allwinner: h5: libretech-all-h3-cc: Mark eMMC HS-DDR 3.3V capable
On Tue, Feb 05, 2019 at 11:42:25PM +0800, Chen-Yu Tsai wrote: > The Libre Computer ALL-H3-CC H5 is one of the few boards that can have > its eMMC run at HS-DDR speed mode. Mark it as such. > > Signed-off-by: Chen-Yu Tsai Applied, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH v2 2/3] mmc: sunxi: Filter out unsupported modes declared in the device tree
On Tue, Feb 05, 2019 at 11:42:24PM +0800, Chen-Yu Tsai wrote: > The MMC device tree bindings include properties used to signal various > signalling speed modes. Until now the sunxi driver was accepting them > without any further filtering, while the sunxi device trees were not > actually using them. > > Since some of the H5 boards can not run at higher speed modes stably, > we are resorting to declaring the higher speed modes per-board. > > Regardless, having boards declare modes and blindly following them, > even without proper support in the driver, is generally a bad thing. > > Filter out all unsupported modes from the capabilities mask after > the device tree properties have been parsed. > > Cc: > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH 2/2] arm64: dts: allwinner: a64: Enable PMIC power supplies on various boards
On Tue, Feb 05, 2019 at 11:00:40PM +0800, Chen-Yu Tsai wrote: > On these A64 devices, the DC input jacks are wired to the ACIN pins of > the PMIC, which is represented by the AC power supply. With the > exception of the Nanopi A64, all devices include LiPo batteries or have > connectors for them, which are represented by the battery power supply. > > Enable these power supplies in the device tree. > > Signed-off-by: Chen-Yu Tsai Applied both, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH 1/9] pinctrl: sunxi: Support I/O bias voltage setting on A80
On Wed, Feb 06, 2019 at 11:32:31AM +0800, Chen-Yu Tsai wrote: > The A80 SoC has configuration registers for I/O bias voltage. Incorrect > settings would make the affected peripherals inoperable in some cases, > such as Ethernet RGMII signals biased at 2.5V with the settings still > at 3.3V. However low speed signals such as MDIO on the same group of > pins seem to be unaffected. > > Previously there was no way to know what the actual voltage used was, > short of hard-coding a value in the device tree. With the new pin bank > regulator supply support in place, the driver can now query the > regulator for its voltage, and if it's valid (as opposed to being the > dummy regulator), set the bias voltage setting accordingly. > > Add a quirk to denote the presence of the configuration registers, and > a function to set the correct setting based on the voltage read back > from the regulator. > > This is only done when the regulator is first acquired and enabled. > While it would be nice to have a notifier on the regulator so that when > the voltage changes, the driver can update the setting, in practice no > board currently supports dynamic changing of the I/O voltages. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH 0/9] ARM: sun9i: a80: Enable GMAC
On Wed, Feb 06, 2019 at 11:32:30AM +0800, Chen-Yu Tsai wrote: > Hi everyone, > > On the Allwinner A80, the PIO pin controller includes configuration > registers to set the I/O voltage. These must match the actual voltage > provided externally. A mismatch results in signals not being passed > through. > > With the new PIO pin-bank regulator supply support in place, we can > tack on support for setting up these registers. > > This in turn allows us to enable the GMAC, which runs at a reduced > 2.5V for RGMII, instead of the standard 3.0V or 3.3V. > > Please have a look. Applied the patches 2-9, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
On Wed, Feb 06, 2019 at 10:16:08AM +0100, Maxime Ripard wrote: > On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote: > > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard > > wrote: > > > > > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote: > > > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote: > > > > > >> IIRC, from the previous discussion, HDMI had a tolerancy > > > > > >> requirement > > > > > >> in the standard. Do you know if there's such a thing for eDP? That > > > > > >> would solve the issue for all the eDP displays at once. > > > > > > > > > > > >I don't have access to eDP standard - vesa.org says it's available to > > > > > >members only. > > > > > > > > > > Try out to grab an old version? > > > > > > > > > > I remember 1.0 is open. > > > > > > > > I can't find anything regarding dot clock tolerance in DisplayPort > > > > specification. > > > > > > I guess since the DP is a VESA spec, it's probably .5%, just like on > > > the EDID (well, CVT). > > > > Unfortunately that's not enough for Pinebook. It needs 1% for 768p > > panel. > > And that mode is stored in the EDID as a standard (or established) > timing, or a detailed timing? > > If the latter, then it should also provide the tolerancies as part of > the panel timing description. The simple-panel driver can, in addition to a struct drm_display_mode take a struct display_timings to specify the modes. These allow to define triplets for each parameter, which are usually found in panel datasheets. Of course that's not going to help you much if all you have is EDID and if that doesn't provide tolerances. Thierry > If the former, then what would be the advertised pixel clock and the > one we can compute? Maybe we have a bug somewhere. > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [linux-sunxi] Re: [PATCH 1/9] pinctrl: sunxi: Support I/O bias voltage setting on A80
On Wed, Feb 6, 2019 at 4:14 PM Linus Walleij wrote: > > On Wed, Feb 6, 2019 at 4:32 AM Chen-Yu Tsai wrote: > > > The A80 SoC has configuration registers for I/O bias voltage. Incorrect > > settings would make the affected peripherals inoperable in some cases, > > such as Ethernet RGMII signals biased at 2.5V with the settings still > > at 3.3V. However low speed signals such as MDIO on the same group of > > pins seem to be unaffected. > > > > Previously there was no way to know what the actual voltage used was, > > short of hard-coding a value in the device tree. With the new pin bank > > regulator supply support in place, the driver can now query the > > regulator for its voltage, and if it's valid (as opposed to being the > > dummy regulator), set the bias voltage setting accordingly. > > > > Add a quirk to denote the presence of the configuration registers, and > > a function to set the correct setting based on the voltage read back > > from the regulator. > > > > This is only done when the regulator is first acquired and enabled. > > While it would be nice to have a notifier on the regulator so that when > > the voltage changes, the driver can update the setting, in practice no > > board currently supports dynamic changing of the I/O voltages. > > > > Signed-off-by: Chen-Yu Tsai > > Hi Chen-Yu, > > thanks for the patch! I tried to apply it on the pinctrl devel branch > (for v5.1) but it failed to apply, I assume because it depends on > the fixes that I just sent to Torvalds. > > Shall we proceed like this that I merge v5.0-rc6 as soon as it is > out and then try to apply this on top of that instead, so we get > rid of this conflict? Sure. That sounds like a good plan. ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote: > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard > wrote: > > > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote: > > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote: > > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement > > > > >> in the standard. Do you know if there's such a thing for eDP? That > > > > >> would solve the issue for all the eDP displays at once. > > > > > > > > > >I don't have access to eDP standard - vesa.org says it's available to > > > > >members only. > > > > > > > > Try out to grab an old version? > > > > > > > > I remember 1.0 is open. > > > > > > I can't find anything regarding dot clock tolerance in DisplayPort > > > specification. > > > > I guess since the DP is a VESA spec, it's probably .5%, just like on > > the EDID (well, CVT). > > Unfortunately that's not enough for Pinebook. It needs 1% for 768p > panel. And that mode is stored in the EDID as a standard (or established) timing, or a detailed timing? If the latter, then it should also provide the tolerancies as part of the panel timing description. If the former, then what would be the advertised pixel clock and the one we can compute? Maybe we have a bug somewhere. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH 1/9] pinctrl: sunxi: Support I/O bias voltage setting on A80
On Wed, Feb 6, 2019 at 4:32 AM Chen-Yu Tsai wrote: > The A80 SoC has configuration registers for I/O bias voltage. Incorrect > settings would make the affected peripherals inoperable in some cases, > such as Ethernet RGMII signals biased at 2.5V with the settings still > at 3.3V. However low speed signals such as MDIO on the same group of > pins seem to be unaffected. > > Previously there was no way to know what the actual voltage used was, > short of hard-coding a value in the device tree. With the new pin bank > regulator supply support in place, the driver can now query the > regulator for its voltage, and if it's valid (as opposed to being the > dummy regulator), set the bias voltage setting accordingly. > > Add a quirk to denote the presence of the configuration registers, and > a function to set the correct setting based on the voltage read back > from the regulator. > > This is only done when the regulator is first acquired and enabled. > While it would be nice to have a notifier on the regulator so that when > the voltage changes, the driver can update the setting, in practice no > board currently supports dynamic changing of the I/O voltages. > > Signed-off-by: Chen-Yu Tsai Hi Chen-Yu, thanks for the patch! I tried to apply it on the pinctrl devel branch (for v5.1) but it failed to apply, I assume because it depends on the fixes that I just sent to Torvalds. Shall we proceed like this that I merge v5.0-rc6 as soon as it is out and then try to apply this on top of that instead, so we get rid of this conflict? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
