[linux-sunxi] [PATCH v5 07/12] regulator: axp20x: add support for AXP22X regulators
From: Boris BREZILLON boris.brezil...@free-electrons.com
Add AXP22X regulator definitions and variant id associations.
This introduces a new switch type output for one of the regulators.
It is a switchable secondary output of one regulator, with the same
voltage level as the primary output.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
[w...@csie.org: Moved variant choosing to multi family support patch]
[w...@csie.org: Add dc-dc work frequency range]
[w...@csie.org: Add switch type output regulator DC1SW]
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
drivers/regulator/axp20x-regulator.c | 96
1 file changed, 96 insertions(+)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 50ae0b5f2c0c..646829132b59 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -27,8 +27,12 @@
#define AXP20X_IO_ENABLED 0x03
#define AXP20X_IO_DISABLED 0x07
+#define AXP22X_IO_ENABLED 0x04
+#define AXP22X_IO_DISABLED 0x03
+
#define AXP20X_WORKMODE_DCDC2_MASK BIT(2)
#define AXP20X_WORKMODE_DCDC3_MASK BIT(1)
+#define AXP22X_WORKMODE_DCDCX_MASK(x) BIT(x)
#define AXP20X_FREQ_DCDC_MASK 0x0f
@@ -74,6 +78,26 @@
.ops= axp20x_ops,
\
}
+#define AXP_DESC_SW(_family, _id, _match, _supply, _min, _max, _step, _vreg,
\
+ _vmask, _ereg, _emask)
\
+ [_family##_##_id] = {
\
+ .name = #_id,
\
+ .supply_name= (_supply),
\
+ .of_match = of_match_ptr(_match),
\
+ .regulators_node = of_match_ptr(regulators),
\
+ .type = REGULATOR_VOLTAGE,
\
+ .id = _family##_##_id,
\
+ .n_voltages = (((_max) - (_min)) / (_step) + 1),
\
+ .owner = THIS_MODULE,
\
+ .min_uV = (_min) * 1000,
\
+ .uV_step= (_step) * 1000,
\
+ .vsel_reg = (_vreg),
\
+ .vsel_mask = (_vmask),
\
+ .enable_reg = (_ereg),
\
+ .enable_mask= (_emask),
\
+ .ops= axp20x_ops_sw,
\
+ }
+
#define AXP_DESC_FIXED(_family, _id, _match, _supply, _volt)
\
[_family##_##_id] = {
\
.name = #_id,
\
@@ -135,6 +159,14 @@ static struct regulator_ops axp20x_ops = {
.is_enabled = regulator_is_enabled_regmap,
};
+static struct regulator_ops axp20x_ops_sw = {
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_linear,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+};
+
static const struct regulator_desc axp20x_regulators[] = {
AXP_DESC(AXP20X, DCDC2, dcdc2, vin2, 700, 2275, 25,
AXP20X_DCDC2_V_OUT, 0x3f, AXP20X_PWR_OUT_CTRL, 0x10),
@@ -152,6 +184,52 @@ static const struct regulator_desc axp20x_regulators[] = {
AXP20X_IO_ENABLED, AXP20X_IO_DISABLED),
};
+static const struct regulator_desc axp22x_regulators[] = {
+ AXP_DESC(AXP22X, DCDC1, dcdc1, vin1, 1600, 3400, 100,
+AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(1)),
+ AXP_DESC(AXP22X, DCDC2, dcdc2, vin2, 600, 1540, 20,
+AXP22X_DCDC2_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(2)),
+ AXP_DESC(AXP22X, DCDC3, dcdc3, vin3, 600, 1860, 20,
+AXP22X_DCDC3_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(3)),
+ AXP_DESC(AXP22X, DCDC4, dcdc4, vin4, 600, 1540, 20,
+AXP22X_DCDC4_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(3)),
+ AXP_DESC(AXP22X, DCDC5, dcdc5, vin5, 1000, 2550, 50,
+AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(4)),
+ /* secondary switchable output of DCDC1 */
+ AXP_DESC_SW(AXP22X, DC1SW, dc1sw, dcdc1, 1600, 3400, 100,
+ AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(7)),
+ /* LDO regulator internally chained to DCDC5 */
+
[linux-sunxi] [PATCH v5 06/12] regulator: axp20x: prepare support for multiple AXP chip families
From: Boris BREZILLON boris.brezil...@free-electrons.com
Rework the AXP20X_ macros and probe function to support the several chip
families, so that each family can define it's own set of regulators.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
[w...@csie.org: Support different DC-DC work frequency ranges]
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
I realize this patch and the next set off a whole bunch of alarms with
lines longer than 80 characters, but I really don't want to introduce
a whole bunch of whitespace changes together.
---
drivers/regulator/axp20x-regulator.c | 143 +++
1 file changed, 94 insertions(+), 49 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index e4331f5e5d7d..50ae0b5f2c0c 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -32,15 +32,15 @@
#define AXP20X_FREQ_DCDC_MASK 0x0f
-#define AXP20X_DESC_IO(_id, _match, _supply, _min, _max, _step, _vreg, _vmask,
\
- _ereg, _emask, _enable_val, _disable_val)
\
- [AXP20X_##_id] = {
\
+#define AXP_DESC_IO(_family, _id, _match, _supply, _min, _max, _step, _vreg,
\
+ _vmask, _ereg, _emask, _enable_val, _disable_val)
\
+ [_family##_##_id] = {
\
.name = #_id,
\
.supply_name= (_supply),
\
.of_match = of_match_ptr(_match),
\
.regulators_node = of_match_ptr(regulators),
\
.type = REGULATOR_VOLTAGE,
\
- .id = AXP20X_##_id,
\
+ .id = _family##_##_id,
\
.n_voltages = (((_max) - (_min)) / (_step) + 1),
\
.owner = THIS_MODULE,
\
.min_uV = (_min) * 1000,
\
@@ -54,15 +54,15 @@
.ops= axp20x_ops,
\
}
-#define AXP20X_DESC(_id, _match, _supply, _min, _max, _step, _vreg, _vmask,
\
- _ereg, _emask)
\
- [AXP20X_##_id] = {
\
+#define AXP_DESC(_family, _id, _match, _supply, _min, _max, _step, _vreg,
\
+_vmask, _ereg, _emask)
\
+ [_family##_##_id] = {
\
.name = #_id,
\
.supply_name= (_supply),
\
.of_match = of_match_ptr(_match),
\
.regulators_node = of_match_ptr(regulators),
\
.type = REGULATOR_VOLTAGE,
\
- .id = AXP20X_##_id,
\
+ .id = _family##_##_id,
\
.n_voltages = (((_max) - (_min)) / (_step) + 1),
\
.owner = THIS_MODULE,
\
.min_uV = (_min) * 1000,
\
@@ -74,29 +74,29 @@
.ops= axp20x_ops,
\
}
-#define AXP20X_DESC_FIXED(_id, _match, _supply, _volt)
\
- [AXP20X_##_id] = {
\
+#define AXP_DESC_FIXED(_family, _id, _match, _supply, _volt)
\
+ [_family##_##_id] = {
\
.name = #_id,
\
.supply_name= (_supply),
\
.of_match = of_match_ptr(_match),
\
.regulators_node = of_match_ptr(regulators),
\
.type = REGULATOR_VOLTAGE,
\
- .id = AXP20X_##_id,
\
+ .id = _family##_##_id,
\
.n_voltages = 1,
\
.owner = THIS_MODULE,
\
.min_uV = (_volt) * 1000,
[linux-sunxi] [PATCH v5 01/12] ARM: dts: sun6i: add p2wi controller node to dtsi
From: Boris BREZILLON boris.brezil...@free-electrons.com
The p2wi controller has only one possible pinmux setting. Use it by
default in the dtsi, instead of having to set it in each board's dts.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
[w...@csie.org: reformat commit title; rename p2wi pins and use as default]
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun6i-a31.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index fa2f403ccf28..92abea20b946 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -973,6 +973,27 @@
allwinner,drive = SUN4I_PINCTRL_10_MA;
allwinner,pull = SUN4I_PINCTRL_NO_PULL;
};
+
+ p2wi_pins: p2wi {
+ allwinner,pins = PL0, PL1;
+ allwinner,function = s_p2wi;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+ };
+ };
+
+ p2wi: i2c@01f03400 {
+ compatible = allwinner,sun6i-a31-p2wi;
+ reg = 0x01f03400 0x400;
+ interrupts = GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH;
+ clocks = apb0_gates 3;
+ clock-frequency = 10;
+ resets = apb0_rst 3;
+ pinctrl-names = default;
+ pinctrl-0 = p2wi_pins;
+ status = disabled;
+ #address-cells = 1;
+ #size-cells = 0;
};
};
};
--
2.1.4
--
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] [PATCH v5 03/12] mfd: axp20x: add AXP22x PMIC support
From: Boris BREZILLON boris.brezil...@free-electrons.com
Add support for the AXP22x PMIC devices to the existing AXP20x driver.
This includes the AXP221 and AXP223, which are identical except for
the external data bus. Only AXP221 is added for now. AXP223 will be
added after it's Reduced Serial Bus (RSB) interface is supported.
AXP22x defines a new set of registers, power supplies and regulators,
but most of the API is similar to the AXP20x ones.
A new irq chip definition is used, even though the available interrupts
on AXP22x is a subset of those on AXP20x. This is done so the interrupt
numbers match those on the datasheet.
This patch only enables the interrupts, system power-off function, and PEK
sub-device. The regulator driver must first support different variants
before we enable it from the mfd driver.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
[w...@csie.org: fix interrupts and move regulators to separate patch]
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
drivers/mfd/axp20x.c | 98 ++
include/linux/mfd/axp20x.h | 86
2 files changed, 184 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index b1b580a88654..0ec27d5023df 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -32,6 +32,7 @@
static const char const *axp20x_model_names[] = {
AXP202,
AXP209,
+ AXP221,
AXP288,
};
@@ -54,6 +55,25 @@ static const struct regmap_access_table
axp20x_volatile_table = {
.n_yes_ranges = ARRAY_SIZE(axp20x_volatile_ranges),
};
+static const struct regmap_range axp22x_writeable_ranges[] = {
+ regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
+ regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
+};
+
+static const struct regmap_range axp22x_volatile_ranges[] = {
+ regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
+};
+
+static const struct regmap_access_table axp22x_writeable_table = {
+ .yes_ranges = axp22x_writeable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(axp22x_writeable_ranges),
+};
+
+static const struct regmap_access_table axp22x_volatile_table = {
+ .yes_ranges = axp22x_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(axp22x_volatile_ranges),
+};
+
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),
@@ -87,6 +107,20 @@ static struct resource axp20x_pek_resources[] = {
},
};
+static struct resource axp22x_pek_resources[] = {
+ {
+ .name = PEK_DBR,
+ .start = AXP22X_IRQ_PEK_RIS_EDGE,
+ .end= AXP22X_IRQ_PEK_RIS_EDGE,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .name = PEK_DBF,
+ .start = AXP22X_IRQ_PEK_FAL_EDGE,
+ .end= AXP22X_IRQ_PEK_FAL_EDGE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static struct resource axp288_battery_resources[] = {
{
.start = AXP288_IRQ_QWBTU,
@@ -129,6 +163,15 @@ static const struct regmap_config axp20x_regmap_config = {
.cache_type = REGCACHE_RBTREE,
};
+static const struct regmap_config axp22x_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .wr_table = axp22x_writeable_table,
+ .volatile_table = axp22x_volatile_table,
+ .max_register = AXP22X_BATLOW_THRES1,
+ .cache_type = REGCACHE_RBTREE,
+};
+
static const struct regmap_config axp288_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -181,6 +224,34 @@ static const struct regmap_irq axp20x_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP20X, GPIO0_INPUT,4, 0),
};
+static const struct regmap_irq axp22x_regmap_irqs[] = {
+ INIT_REGMAP_IRQ(AXP22X, ACIN_OVER_V,0, 7),
+ INIT_REGMAP_IRQ(AXP22X, ACIN_PLUGIN,0, 6),
+ INIT_REGMAP_IRQ(AXP22X, ACIN_REMOVAL, 0, 5),
+ INIT_REGMAP_IRQ(AXP22X, VBUS_OVER_V,0, 4),
+ INIT_REGMAP_IRQ(AXP22X, VBUS_PLUGIN,0, 3),
+ INIT_REGMAP_IRQ(AXP22X, VBUS_REMOVAL, 0, 2),
+ INIT_REGMAP_IRQ(AXP22X, VBUS_V_LOW, 0, 1),
+ INIT_REGMAP_IRQ(AXP22X, BATT_PLUGIN,1, 7),
+ INIT_REGMAP_IRQ(AXP22X, BATT_REMOVAL, 1, 6),
+ INIT_REGMAP_IRQ(AXP22X, BATT_ENT_ACT_MODE, 1, 5),
+ INIT_REGMAP_IRQ(AXP22X, BATT_EXIT_ACT_MODE, 1, 4),
+ INIT_REGMAP_IRQ(AXP22X, CHARG, 1, 3),
+ INIT_REGMAP_IRQ(AXP22X, CHARG_DONE, 1, 2),
+ INIT_REGMAP_IRQ(AXP22X, BATT_TEMP_HIGH, 1, 1),
+ INIT_REGMAP_IRQ(AXP22X, BATT_TEMP_LOW, 1, 0),
+ INIT_REGMAP_IRQ(AXP22X, DIE_TEMP_HIGH, 2, 7),
+ INIT_REGMAP_IRQ(AXP22X, PEK_SHORT,
[linux-sunxi] [PATCH v5 10/12] ARM: dts: sun6i: hummingbird: Add AXP221 regulator nodes
This patch adds the AXP221 regulators. Only the ones directly used
on the board are added.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56 -
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 486ffc69ac96..d13c88c6509a 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -115,7 +115,7 @@
mmc0 {
pinctrl-names = default;
pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_hummingbird;
- vmmc-supply = reg_vcc3v0;
+ vmmc-supply = vcc_3v0;
bus-width = 4;
cd-gpios = pio 0 8 GPIO_ACTIVE_HIGH; /* PA8 */
cd-inverted;
@@ -150,6 +150,60 @@
interrupts = 0 IRQ_TYPE_LEVEL_LOW;
interrupt-controller;
#interrupt-cells = 1;
+ dcdc1-supply = vcc_3v0;
+ dcdc5-supply = vcc_dram;
+
+ regulators {
+ x-powers,dcdc-freq = 3000;
+
+ vcc_3v0: dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-name = vcc-3v0;
+ };
+
+ vdd_cpu: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = 70;
+ regulator-max-microvolt = 132;
+ regulator-name = vdd-cpu;
+ };
+
+ vdd_gpu: dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = 70;
+ regulator-max-microvolt = 132;
+ regulator-name = vdd-gpu;
+ };
+
+ vdd_sys_dll: dcdc4 {
+ regulator-always-on;
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 110;
+ regulator-name = vdd-sys-dll;
+ };
+
+ vcc_dram: dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-name = vcc-dram;
+ };
+
+ vcc_wifi: aldo1 {
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-name = vcc_wifi;
+ };
+
+ avcc: aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-name = avcc;
+ };
+ };
};
};
--
2.1.4
--
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] [PATCH v5 08/12] mfd: axp20x: Add AXP22x regulator information to DT bindings
Add the list of regulators for AXP22x to the DT bindings.
This includes the names and supply names.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
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 3914a3f91ff6..0fc2f1f35cef 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -49,6 +49,33 @@ LDO3 : LDO : ldo3in-supply
LDO4 : LDO : ldo24in-supply: shared supply
LDO5 : LDO : ldo5in-supply
+
+AXP221 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDC1 : DC-DC buck: vin1-supply
+DCDC2 : DC-DC buck: vin2-supply
+DCDC3 : DC-DC buck: vin3-supply
+DCDC4 : DC-DC buck: vin4-supply
+DCDC5 : DC-DC buck: vin5-supply
+DC1SW : On/Off Switch : dcdc1-supply : DCDC1 secondary output
+DC5LDO : LDO : dcdc5-supply : input from DCDC5
+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
+LDO_IO0: LDO : ips-supply: GPIO 0
+LDO_IO1: LDO : ips-supply: GPIO 1
+RTC_LDO: LDO : ips-supply: always on
+
+
Example:
axp209: pmic@34 {
--
2.1.4
--
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] [PATCH v5 04/12] mfd: axp20x: update DT bindings with AXP22x compatibles
Add AXP221 to the list of supported devices. Also replace any mention of AXP20x in the document with a generic PMIC. Signed-off-by: Chen-Yu Tsai w...@csie.org --- Documentation/devicetree/bindings/mfd/axp20x.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index 98685f291a72..3914a3f91ff6 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -1,15 +1,16 @@ -AXP202/AXP209 device tree bindings +AXP family PMIC device tree bindings The axp20x family current members : axp202 (X-Powers) axp209 (X-Powers) +axp221 (X-Powers) Required properties: -- compatible: x-powers,axp202 or x-powers,axp209 +- compatible: x-powers,axp202, x-powers,axp209, x-powers,axp221 - reg: The I2C slave address for the AXP chip - interrupt-parent: The parent interrupt controller - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin -- interrupt-controller: axp20x has its own internal IRQs +- interrupt-controller: The PMIC has its own internal IRQs - #interrupt-cells: Should be set to 1 Optional properties: -- 2.1.4 -- 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] [PATCH v5 00/12] mfd: axp20x: add AXP221 PMIC support
Hi everyone, This is v5 of the AXP221 series. I've taken over the work from Boris. This version is based on v4.0-rc1, plus mfd: AXP20x: Add bindings documentation which was posted a few weeks ago. I've worked on this series for some time, so the changelog might not be completely accurate. The AXP221 is a member of X-Powers' AXP PMIC family. They share the same basic functionality and structure. The series adds system poweroff, power button and regulator support for the AXP221. When Reduced Serial Bus (RSB) support is introduced, the same code can be reused (except for the probe interface) for the AXP223, which has the same core and a different external host interface. The p2wi controller dts patches have no dependency, and can go in Maxime's tree. The regulator bits depend on the mfd patches, which introduce new enums and register definitions. The regulator dts patches should also be merged _after_ the regulator bits, as the original axp20x regulator driver did not check for supported variants. Maybe Lee and Mark can work out a shared branch, or have Lee take all the driver bits? Regards ChenYu Changes since v4: - Rebased onto v4.0-rc1 and axp20x bindings v10 - Dropped regulator set registration patches - Group regmap ranges/tables by AXP variant - Fix AXP221 interrupt numbers to match datasheet - Handle AXP variants when setting DC-DC regulator work mode - Add switch type regulator DC1SW, which is a secondary output of DCDC1 with a separate on/off switch. - Add AXP221 to DT bindings Boris BREZILLON (4): ARM: dts: sun6i: add p2wi controller node to dtsi mfd: axp20x: add AXP22x PMIC support regulator: axp20x: prepare support for multiple AXP chip families regulator: axp20x: add support for AXP22X regulators Chen-Yu Tsai (8): ARM: dts: sun6i: hummingbird: Enable P2WI controller mfd: axp20x: update DT bindings with AXP22x compatibles ARM: dts: sun6i: hummingbird: Add AXP221 PMIC device node mfd: axp20x: Add AXP22x regulator information to DT bindings mfd: axp20x: Enable AXP22X regulators ARM: dts: sun6i: hummingbird: Add AXP221 regulator nodes ARM: dts: sun6i: Add pinmux settings for mmc1 to dtsi ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module Documentation/devicetree/bindings/mfd/axp20x.txt | 34 +++- arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 91 - arch/arm/boot/dts/sun6i-a31.dtsi | 29 +++ drivers/mfd/axp20x.c | 100 ++ drivers/regulator/axp20x-regulator.c | 239 ++- include/linux/mfd/axp20x.h | 86 6 files changed, 526 insertions(+), 53 deletions(-) -- 2.1.4 -- 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] [PATCH v5 09/12] mfd: axp20x: Enable AXP22X regulators
Now that the axp20x-regulators driver supports different variants of the
AXP family, we can enable regulator support for AXP22X without the risk
of incorrectly configuring regulators.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
drivers/mfd/axp20x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 0ec27d5023df..8d2dbb7eb588 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -370,6 +370,8 @@ static struct mfd_cell axp22x_cells[] = {
.name = axp20x-pek,
.num_resources = ARRAY_SIZE(axp22x_pek_resources),
.resources = axp22x_pek_resources,
+ }, {
+ .name = axp20x-regulator,
},
};
--
2.1.4
--
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] [PATCH v5 12/12] ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module
The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The
WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO.
The IC also takes a power enable signal via GPIO. This is supported
with the new power sequencing bindings.
The WiFi module supports out-of-band interrupt signaling via GPIO,
but this is buggy and not enabled yet.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index d13c88c6509a..25a3ef49bb71 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -61,6 +61,11 @@
chosen {
bootargs = earlyprintk console=ttyS0,115200;
};
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = mmc-pwrseq-simple;
+ reset-gpios = pio 6 10 GPIO_ACTIVE_LOW; /* PG10 */
+ };
};
ehci0 {
@@ -127,6 +132,16 @@
allwinner,pull = SUN4I_PINCTRL_PULL_UP;
};
+mmc1 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins_a, wifi_reset_pin_hummingbird;
+ vmmc-supply = vcc_wifi;
+ mmc-pwrseq = wifi_pwrseq;
+ bus-width = 4;
+ non-removable;
+ status = okay;
+};
+
ohci0 {
status = okay;
};
@@ -138,6 +153,13 @@
allwinner,drive = SUN4I_PINCTRL_10_MA;
allwinner,pull = SUN4I_PINCTRL_PULL_UP;
};
+
+ wifi_reset_pin_hummingbird: wifi_reset_pin@0 {
+ allwinner,pins = PG10;
+ allwinner,function = gpio_out;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+ };
};
p2wi {
--
2.1.4
--
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] [PATCH v5 02/12] ARM: dts: sun6i: hummingbird: Enable P2WI controller
The Hummingbird A31 has an AXP221 PMIC hooked up to the P2WI controller.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 65ddaf4c72d2..533bedc5dd95 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -140,6 +140,10 @@
};
};
+p2wi {
+ status = okay;
+};
+
reg_usb1_vbus {
gpio = pio 7 24 GPIO_ACTIVE_HIGH; /* PH24 */
status = okay;
--
2.1.4
--
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] [PATCH v5 11/12] ARM: dts: sun6i: Add pinmux settings for mmc1 to dtsi
mmc1 is used to connect to the WiFi chip on the Hummingbird A31.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun6i-a31.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 92abea20b946..39d87a901b46 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -581,6 +581,14 @@
allwinner,pull = SUN4I_PINCTRL_NO_PULL;
};
+ mmc1_pins_a: mmc1@0 {
+ allwinner,pins = PG0, PG1, PG2, PG3,
+PG4, PG5;
+ allwinner,function = mmc1;
+ allwinner,drive = 2;
+ allwinner,pull = 0;
+ };
+
gmac_pins_mii_a: gmac_mii@0 {
allwinner,pins = PA0, PA1, PA2, PA3,
PA8, PA9, PA11,
--
2.1.4
--
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] sunxi: Add Wexler TAB7200 support
Hi, On 04-03-15 08:44, Aleksei Mamlin wrote: This patch add support for Wexler TAB7200 tablet. The Wexler TAB7200 is a A20 based tablet with 7 inch display(800x480), capacitive touchscreen(5 fingers), 1G RAM, 4G NAND, micro SD card slot, mini HDMI port, 3.5mm audio plug, 1 USB OTG port and 1 USB 2.0 port. Signed-off-by: Aleksei Mamlin mamli...@gmail.com Thanks, I've queued this up in u-boot-sunxi/next for merging upstream. Regards, Hans --- board/sunxi/MAINTAINERS | 5 + configs/Wexler_TAB7200_defconfig | 13 + 2 files changed, 18 insertions(+) create mode 100644 configs/Wexler_TAB7200_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 3e6ce88..53a9fea 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -130,3 +130,8 @@ TZX-Q8-713B7 BOARD M:Paul Kocialkowski cont...@paulk.fr S:Maintained F:configs/TZX-Q8-713B7_defconfig + +WEXLER-TAB7200 BOARD +M: Aleksei Mamlin mamli...@gmail.com +S: Maintained +F: configs/Wexler_TAB7200_defconfig diff --git a/configs/Wexler_TAB7200_defconfig b/configs/Wexler_TAB7200_defconfig new file mode 100644 index 000..6c15dc8 --- /dev/null +++ b/configs/Wexler_TAB7200_defconfig @@ -0,0 +1,13 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,USB_EHCI +CONFIG_FDTFILE=sun7i-a20-wexler-tab7200.dtb +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:24,pclk_khz:33000,le:45,ri:210,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0 +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_EN=PH7 +CONFIG_VIDEO_LCD_BL_PWM=PB2 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_DRAM_CLK=384 ++S:CONFIG_DRAM_ZQ=127 ++S:CONFIG_DRAM_EMR1=4 -- 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: Reviewing the book Getting Started with Cubieboard (Packt Publishing Ltd)
On Tue, Mar 10, 2015 at 09:41:14AM +0200, Simos Xenitellis wrote: On Wed, Mar 4, 2015 at 11:43 AM, Simos Xenitellis simos.li...@googlemail.com wrote: Hi All, As you may know, there is an introductory book about the A-Series of Allwinner SoCs (specifically A10, A13 and A20), called Getting Started with Cubieboard, written by Olliver Schinagl and published by Packt Publishing Ltd. Read more at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard Packt is doing some publicity for this book. What they are doing is that they give the e-book version of the book in exchange for an online review. The idea is that by having several online reviews for the book, it helps prospective buyers to decide whether to buy or not. Obviously, you are free to write whatever you want in the review. I offered them my help in finding such reviewers, and they are looking for 3 persons. Here are the details: 1. Have a look at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard to decide if you are interested to go through this. 2. Write a review on Amazon, Google Books and goodreads. For Amazon, you need to have an account and have bought something in order to be able to post reviews. 3. Write a review on your personal blog or similar social media. If you are interested in taking part, please send me a private email. Please also add a sentence describing why it would be helpful to you to get a copy (to be used in case there are more than 3 replies). I'll collect replies until this Friday. If there are any general questions, reply here. I have no affiliation with Packt Publishing Ltd. I got some good replies and forwarded them to Packt. They confirmed that they will be contacting you (if they did not do already) with further details. I also suggested to Packt to get someone from either CubieTech or Allwinner to review the book. Obviously, such a thing would be mutually beneficial in terms of marketing. So, if you are from CubieTech or Allwinner, do contact me in private. Simos Did you involve the author of the book in this action, at all? Luc Verhaegen. -- 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 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
Hi,
On Tuesday 10 March 2015 03:43 PM, Hans de Goede wrote:
Hi,
On 10-03-15 09:57, Arnd Bergmann wrote:
On Tuesday 10 March 2015 09:04:43 Hans de Goede wrote:
Hi,
On 09-03-15 22:47, Arnd Bergmann wrote:
On Monday 09 March 2015 21:40:15 Hans de Goede wrote:
+void sun4i_usb_phy_update_iscr(struct phy *_phy, u32 clr, u32 set)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ u32 iscr;
+
+ iscr = readl(data-base + REG_ISCR);
+ iscr = ~clr;
+ iscr |= set;
+ writel(iscr, data-base + REG_ISCR);
+}
+EXPORT_SYMBOL(sun4i_usb_phy_update_iscr);
+
I would generally consider this a bad design. What is the purpose of
calling sun4i_usb_phy_update_iscr()
right. That would bind the PHY driver and the controller driver and would
start creating problems when a different PHY is connected with the
controller.
There are 2 different use cases for this one is to enable the dataline
pull-ups at driver init and disable them at driver exit, this could /
should probably be moved to the phy_init / phy_exit code for the usb0 phy
removing the need to do this from within the sunxi musb glue.
The second use-case is more tricky, for some reasons Allwinner has decided
to not use the dedicated id-detect and vusb-sense pins of the phy they are
using (these pins are not routed to the outside).
Instead id-detect and vusb-sense are done through any $random gpio pins
(including non irq capable pins on some designs requiring polling).
The polling can still be done in PHY driver and can use the extcon framework
to report the status to controller driver no?
But the musb-core still needs to know the status of the id and vbus pins,
musb-core or the musb-glue (musb/sunxi.c in this case)?
and gets this from the usb0-phy iscr register, which reflects the status of
the not connected dedicated pins of the phy. The reason this can still
work at all is because the iscr register allows the user to override
whatever the not connected phy pins are seeing and forcing a value to
report to the musb core as id and vbus status.
This is done by these 2 functions in the musb sunxi glue:
static void sunxi_musb_force_id(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_ID_HIGH;
else
val = SUNXI_ISCR_FORCE_ID_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_ID_MASK, val);
What will writing to this register lead to? call to sunxi_musb_id_vbus_det_irq
interrupt handler?
}
static void sunxi_musb_force_vbus(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_VBUS_HIGH;
else
val = SUNXI_ISCR_FORCE_VBUS_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_VBUS_MASK,
val);
}
I will happily admit that these 2 functions are a better API between the
sunxi musb
glue and the sunxi usb phy driver. I started with the minimal
sun4i_usb_phy_update_iscr
approach as I wanted to keep the API as small as possible, but having 2
functions like
the one above, which actually reflect what is happening would indeed be better.
Ok, that would definitely improve things.
Note that the polling of the pins cannot (easily) be moved into the phy
driver for various
reasons:
1) It depends on dr_mode, the otg may be used in host only mode in which
case there are no
pins at all.
2) the musb set_vbus callback needs access to the pins
3) When id changes some musb core state changes are necessary.
I'll respin the patch set to do things this way as soon as we've agreement on
your second point.
and why can't there be a high-level
PHY API for this?
The current generic phy API seems to not have any bus specific methods, I
know that
in the long run people want to get rid of struct usb_phy, so maybe we should
consider
adding bus specific methods to the generic phy API for things like otg.
If we decide to add bus specific methods, then the question becomes if having
int phy_usb_set_id_detect(struct phy *phy, bool val);
int phy_usb_set_vbus_detect(struct phy *phy, bool val);
Functions in the generic phy API is a good idea, or if this is too sunxi
specific,
I'm fine with doing this either way. If we want to go the generic phy route
I'll split this in 2 patches, one adding these 2 generic functions
phy-ops, and
1 doing the sunxi implementation.
Please don't do that. We don't want to be bloating phy framework with platform
specific hooks.
Cheers
Kishon
--
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 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
Hi,
On 10-03-15 09:57, Arnd Bergmann wrote:
On Tuesday 10 March 2015 09:04:43 Hans de Goede wrote:
Hi,
On 09-03-15 22:47, Arnd Bergmann wrote:
On Monday 09 March 2015 21:40:15 Hans de Goede wrote:
+void sun4i_usb_phy_update_iscr(struct phy *_phy, u32 clr, u32 set)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ u32 iscr;
+
+ iscr = readl(data-base + REG_ISCR);
+ iscr = ~clr;
+ iscr |= set;
+ writel(iscr, data-base + REG_ISCR);
+}
+EXPORT_SYMBOL(sun4i_usb_phy_update_iscr);
+
I would generally consider this a bad design. What is the purpose of
calling sun4i_usb_phy_update_iscr()
There are 2 different use cases for this one is to enable the dataline
pull-ups at driver init and disable them at driver exit, this could /
should probably be moved to the phy_init / phy_exit code for the usb0 phy
removing the need to do this from within the sunxi musb glue.
The second use-case is more tricky, for some reasons Allwinner has decided
to not use the dedicated id-detect and vusb-sense pins of the phy they are
using (these pins are not routed to the outside).
Instead id-detect and vusb-sense are done through any $random gpio pins
(including non irq capable pins on some designs requiring polling).
But the musb-core still needs to know the status of the id and vbus pins,
and gets this from the usb0-phy iscr register, which reflects the status of
the not connected dedicated pins of the phy. The reason this can still
work at all is because the iscr register allows the user to override
whatever the not connected phy pins are seeing and forcing a value to
report to the musb core as id and vbus status.
This is done by these 2 functions in the musb sunxi glue:
static void sunxi_musb_force_id(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_ID_HIGH;
else
val = SUNXI_ISCR_FORCE_ID_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_ID_MASK, val);
}
static void sunxi_musb_force_vbus(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_VBUS_HIGH;
else
val = SUNXI_ISCR_FORCE_VBUS_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_VBUS_MASK, val);
}
I will happily admit that these 2 functions are a better API between the sunxi
musb
glue and the sunxi usb phy driver. I started with the minimal
sun4i_usb_phy_update_iscr
approach as I wanted to keep the API as small as possible, but having 2
functions like
the one above, which actually reflect what is happening would indeed be better.
Ok, that would definitely improve things.
Note that the polling of the pins cannot (easily) be moved into the phy driver
for various
reasons:
1) It depends on dr_mode, the otg may be used in host only mode in which case
there are no
pins at all.
2) the musb set_vbus callback needs access to the pins
3) When id changes some musb core state changes are necessary.
I'll respin the patch set to do things this way as soon as we've agreement on
your second point.
and why can't there be a high-level
PHY API for this?
The current generic phy API seems to not have any bus specific methods, I know
that
in the long run people want to get rid of struct usb_phy, so maybe we should
consider
adding bus specific methods to the generic phy API for things like otg.
If we decide to add bus specific methods, then the question becomes if having
int phy_usb_set_id_detect(struct phy *phy, bool val);
int phy_usb_set_vbus_detect(struct phy *phy, bool val);
Functions in the generic phy API is a good idea, or if this is too sunxi
specific,
I'm fine with doing this either way. If we want to go the generic phy route
I'll split this in 2 patches, one adding these 2 generic functions phy-ops,
and
1 doing the sunxi implementation.
If people believe this is too sunxi specific (I believe it is, but as said I'm
fine with doing this either way). I'll respin this patch to remove the too
generic sun4i_usb_phy_update_iscr function, and instead add these 2:
void sun4i_usb_phy_set_id_detect(struct phy *phy, bool val);
void sun4i_usb_phy_set_vbus_detect(struct phy *phy, bool val);
Thanks for your detailed explanations. I think this is something for
Kishon to decide, based on where he wants to take the phy API in the
long run. I'm fine with it either way, and it seems easy enough to
change between those two interfaces if we make up our minds about it
later.
Ok, so I've fixed things in my personal tree to use 2 sun4i private functions
for
now:
void sun4i_usb_phy_set_id_detect(struct phy *phy, bool val);
void sun4i_usb_phy_set_vbus_detect(struct phy *phy, bool val);
You can find this change here:
Re: [linux-sunxi] Derailed thread
Dear S.J.R., Thanks for taking the time to reply in detail. Perhaps you are right about linux-exynos. No, actually I accept you are right. In a war of attrition, it's bound to get to such results. On Thu, Mar 5, 2015 at 2:47 PM, S.J.R. van Schaik step...@synkhronix.com wrote: Concerning the linux-sunxi wiki, if you want to get somewhere, then first of all stop throwing a bunch of argumenta ad hominem into an e-mail to a public mailing list. It simply won't get you anywhere. Rather than editing the wiki as you see fit, it is usually better to address the issues of the wiki, propose some changes and talk about your proposal with active members of the community, such as Luc. I am quite sure that if you do this properly, that you can reach a point of consensus in that regard. Community building is not about blaming one single person within a community, it is a matter of working as a community, talking to each other, and trying to get somewhere. It's great to work with consensus. If everyone plays nice and you are happy to apologize if something goes wrong, is perfect for the ideal community. For the case of the sunxi wiki, I would like to ask you whether there was a discussion or a consensus when parts about GPL violations were added to several places. In addition, the text around the GPL violations was far from neutral, which Also, the main page of the wiki features the text Allwinner does not actively participate in or support this community. In fact, it is violating the GPLv2 license in several ways and has so far not shown willingness to resolve this. That's a big statement to make. The http://linux-sunxi.org/Talk:Main_Page does not mention any relevant discussion for that statement. Finally, if you don't like how someone is reacting to you, then remember that it is hard to read someone's feelings from an e-mail, and that you can always change your own approach to get a different reaction. In the worst case you have to let it rest for a while, instead of adding more fuel to the blazing fire. That way you also get yourself some time to think about it. I think the current situation is that of a stalemate. This fire has been burning for more than six months, with no attempts of an intervention. I do not think it is something that will be forgotten or attitudes will change. I think I can read the feelings from an e-mail, and get a good picture from several emails. By reading the mail titled Formal request for source code for LGPL licensed software, I can see that the text is very hard to read. The text makes sense to the writer but it's the reader who is important. If those previous e-mails were written in the same way, I can fully understand why they were ineffective. Getting no result from those requests to resolve violations, is frustrating. And it's frustrating enough that it becomes emotional, and it was has led to the current situation. Personally I would help a friend of mine not to get stuck in such a situation. A more proactive attitude would be to get to a statement like 1. any license violation to free/opensource software is unacceptable 2. there are cases of avoidable violations. What do we do there? Select a direction and follow it. 3. pursuing GPL violations on the linux-sunxi mailing list is unacceptable. If you have a case, then sue (the right target). As others mentioned (and their message was drown out), try to get the support of something like the SFC so that they can evaluate the merits of pursuing. And then the SFC would do the talking. All the best, Simos -- 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 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
Hi,
On 10-03-15 11:53, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 10 March 2015 03:43 PM, Hans de Goede wrote:
Hi,
On 10-03-15 09:57, Arnd Bergmann wrote:
On Tuesday 10 March 2015 09:04:43 Hans de Goede wrote:
Hi,
On 09-03-15 22:47, Arnd Bergmann wrote:
On Monday 09 March 2015 21:40:15 Hans de Goede wrote:
+void sun4i_usb_phy_update_iscr(struct phy *_phy, u32 clr, u32 set)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ u32 iscr;
+
+ iscr = readl(data-base + REG_ISCR);
+ iscr = ~clr;
+ iscr |= set;
+ writel(iscr, data-base + REG_ISCR);
+}
+EXPORT_SYMBOL(sun4i_usb_phy_update_iscr);
+
I would generally consider this a bad design. What is the purpose of
calling sun4i_usb_phy_update_iscr()
right. That would bind the PHY driver and the controller driver and would
start creating problems when a different PHY is connected with the
controller.
There are 2 different use cases for this one is to enable the dataline
pull-ups at driver init and disable them at driver exit, this could /
should probably be moved to the phy_init / phy_exit code for the usb0 phy
removing the need to do this from within the sunxi musb glue.
The second use-case is more tricky, for some reasons Allwinner has decided
to not use the dedicated id-detect and vusb-sense pins of the phy they are
using (these pins are not routed to the outside).
Instead id-detect and vusb-sense are done through any $random gpio pins
(including non irq capable pins on some designs requiring polling).
The polling can still be done in PHY driver and can use the extcon framework
to report the status to controller driver no?
Technically the polling can be moved to the phy driver yes, but it is not easy,
e.g. we only need to poll when we're in otg mode rather then host-only
or peripheral-only mode, and the mode gets set by the musb driver not phy
the phy driver. The sunxi musb implementation uses an integrated phy, so it
is just much easier and more logical to have all control / polling happening
from a single module rather then from 2 different modules.
But the musb-core still needs to know the status of the id and vbus pins,
musb-core or the musb-glue (musb/sunxi.c in this case)?
and gets this from the usb0-phy iscr register, which reflects the status of
the not connected dedicated pins of the phy. The reason this can still
work at all is because the iscr register allows the user to override
whatever the not connected phy pins are seeing and forcing a value to
report to the musb core as id and vbus status.
This is done by these 2 functions in the musb sunxi glue:
static void sunxi_musb_force_id(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_ID_HIGH;
else
val = SUNXI_ISCR_FORCE_ID_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_ID_MASK, val);
What will writing to this register lead to? call to sunxi_musb_id_vbus_det_irq
interrupt handler?
No this changes the vbus and id status as seen by the musb core, and the musb
responds to this, by e.g. starting a session, or when vbus does not get high
after a session request by reporting a vbus-error interrupt.
The sunxi_musb_id_vbus_det_irq handler gets triggered by edges on the gpio
pins which are used to monitor the id and vbus status.
}
static void sunxi_musb_force_vbus(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_VBUS_HIGH;
else
val = SUNXI_ISCR_FORCE_VBUS_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_VBUS_MASK,
val);
}
I will happily admit that these 2 functions are a better API between the
sunxi musb
glue and the sunxi usb phy driver. I started with the minimal
sun4i_usb_phy_update_iscr
approach as I wanted to keep the API as small as possible, but having 2
functions like
the one above, which actually reflect what is happening would indeed be better.
Ok, that would definitely improve things.
Note that the polling of the pins cannot (easily) be moved into the phy
driver for various
reasons:
1) It depends on dr_mode, the otg may be used in host only mode in which
case there are no
pins at all.
2) the musb set_vbus callback needs access to the pins
3) When id changes some musb core state changes are necessary.
I'll respin the patch set to do things this way as soon as we've agreement on
your second point.
and why can't there be a high-level
PHY API for this?
The current generic phy API seems to not have any bus specific methods, I
know that
in the long run people want to get rid of struct usb_phy, so maybe we should
consider
adding bus specific methods to the generic phy API for things like otg.
If we decide to add
Re: [linux-sunxi] Re: [PATCH] ARM: sun6i: dt: Add new Mele I7 device
Hi,
On 03-03-15 14:58, Maxime Ripard wrote:
On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote:
Hi,
On 03-03-15 09:22, Maxime Ripard wrote:
On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote:
+/ {
+ model = Mele I7 Quad top set box;
+ compatible = mele,i7, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
Using earlyprintk by default is a bad idea if the kernel is configured
with DEBUG_LL support for another SoC.
While on this subject, u-boot now sets the chosen/stdout-path property
up by default, which means that the kernel will do the right thing by
default. So we we really do not need any bootargs= in our dts files.
I just tested that this weekend, and it turned out that the kernel
couldn't use it so far (ie, no output until init takes over and setup
a TTY on ttyS0).
Was it working for you?
Yes, note that the kernel only honors the stdout-path property if
there is no console= argument present if there is a console= argument
present on the kernel cmdline then that will overrule the stdout-path
property
Yeah, I removed the bootargs entirely.
Which board did you test with, and what u-boot and kernel version ?
I tested it on my A31 hummingbird, with allwinner's u-boot, but with
/chosen/stdout-path hardcoded to serial0:115200n8, with a 4.0-rc1
kernel.
I'm not sure if stdout-path supports aliases this is what u-boot is using,
and which works fine (with 4.0-rc1 kernel):
/soc@01c0/serial@01c28000:115200
But it might very well just be me. We just tested it on a Marvell
board (that uses the same serial driver) this morning and it was fine,
so I don't think it's really worth worrying about this :)
Currently we've a random mix where we do have bootargs in some, but
not in most sunxi dts files. I believe we should simply remove it
everywhere...
We used to set them in SoCs that are not supported by U-boot yet, and
where the bootloader won't come and patch the DT (A31, A23, A80).
Ah, so that is (was) the logic, following that logic we should probably
remove bootargs= from at least the a23 and a31 boards (basically
from all boards but a80).
I'm not so sure about the A31, since most boards won't even boot by
default on the SD card
True.
and we have no way to replace U-Boot in NAND
so far (afaik). But replacing them by stdout-path is a very good
solution too.
You mean putting stdout-path in the dts, I'm not sure if I like that,
to me both bootargs and stdout-path are something which should be
left to the bootloader to set. But I understand that when not
using upstream u-boot that may be an issue.
Regards,
Hans
--
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] ARM: sun6i: dt: Add new Mele I7 device
On Tue, 2015-03-10 at 12:16 +0100, Hans de Goede wrote: I'm not sure if stdout-path supports aliases I thought it did but ePAPR section 3.5 says A string that specifies the full path to the node which suggests not, and AFAICT the code doesn't try to handle alias. Ian. -- 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: Reviewing the book Getting Started with Cubieboard (Packt Publishing Ltd)
On Tue, Mar 10, 2015 at 11:09 AM, Olliver Schinagl oli...@schinagl.nl wrote: Hey all, On 10-03-15 08:41, Simos Xenitellis wrote: On Wed, Mar 4, 2015 at 11:43 AM, Simos Xenitellis simos.li...@googlemail.com wrote: Hi All, As you may know, there is an introductory book about the A-Series of Allwinner SoCs (specifically A10, A13 and A20), called Getting Started with Cubieboard, written by Olliver Schinagl and published by Packt Publishing Ltd. Read more at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard Packt is doing some publicity for this book. What they are doing is that they give the e-book version of the book in exchange for an online review. The idea is that by having several online reviews for the book, it helps prospective buyers to decide whether to buy or not. Obviously, you are free to write whatever you want in the review. I offered them my help in finding such reviewers, and they are looking for 3 persons. Here are the details: 1. Have a look at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard to decide if you are interested to go through this. 2. Write a review on Amazon, Google Books and goodreads. For Amazon, you need to have an account and have bought something in order to be able to post reviews. 3. Write a review on your personal blog or similar social media. If you are interested in taking part, please send me a private email. Please also add a sentence describing why it would be helpful to you to get a copy (to be used in case there are more than 3 replies). I'll collect replies until this Friday. If there are any general questions, reply here. I have no affiliation with Packt Publishing Ltd. I got some good replies and forwarded them to Packt. They confirmed that they will be contacting you (if they did not do already) with further details. I also suggested to Packt to get someone from either CubieTech or Allwinner to review the book. Obviously, such a thing would be mutually beneficial in terms of marketing. So, if you are from CubieTech or Allwinner, do contact me in private. Why have I not been contacted about this at all yet (by packt mostly). While I think it's good that you are putting in effort, it feels a little as being passed by. In any case, it's good that the book is being pushed, and if you are from CubieTech or Allwinner, please atleast CC me, as I am the author after all. For the part for asking someone from CubieTech or Allwinner, it was something I suggested in my last message to them and got a positive reply. Most probably a private message will not work and you will need to contact both directly. In my initial email I got a positive reply from you, thanking me for this post. It makes sense for these things to be done by someone else than the author. When I replied to you, I mentioned that it would be good for this email to make it both the Olimex and Lemaker forums. I did not offer to do that, and it's something that you may want to pursue. I cc:ed Tom in these emails considering that a review from him would be nice. I did not act on that, so you may want to ping him as well. Simos -- 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] [PATCH] sun6i: Add support for the Mixtile LOFT-Q board
From: Han Pengfei pengp...@sina.com The Mixtile LOFT-Q is an A31 based board with 2G RAM, 8G EMMC, sdio wifi, 1Gbit ethernet, HDMI display, toslink audio plug, 4 USB2.0 port, external USB2SATA connector, sd card plug, 3x60 external fpic expansion connector, NXP JN5168 zigbee gw, remote support. Also see http://focalcrest.com/en/pc.html#pro02 --- configs/mixtile_loftq_defconfig | 17 + 1 file changed, 17 insertions(+) create mode 100644 configs/mixtile_loftq_defconfig diff --git a/configs/mixtile_loftq_defconfig b/configs/mixtile_loftq_defconfig new file mode 100644 index 000..7d4229b --- /dev/null +++ b/configs/mixtile_loftq_defconfig @@ -0,0 +1,17 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPA(21) +CONFIG_MACH_TYPE=3892 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN6I=y ++S:CONFIG_TARGET_MIXTILE_LOFTQ=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=251 ++S:CONFIG_MMC_SUNXI_SLOT=0 ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +# Wifi power ++S:CONFIG_AXP221_ALDO1_VOLT=3300 +# Vbus gpio for usb1 ++S:CONFIG_USB1_VBUS_PIN=PH24 +# No Vbus gpio for usb2 ++S:CONFIG_USB2_VBUS_PIN= -- 1.9.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] [PATCH] sun6i: Add support for the Mixtile LOFT-Q board
From: Han Pengfei pengp...@sina.com The Mixtile LOFT-Q is an A31 based board with 2G RAM, 8G EMMC, sdio wifi, 1Gbit ethernet, HDMI display, toslink audio plug, 4 USB2.0 port, external USB2SATA connector, sd card plug, 3x60 external fpic expansion connector, NXP JN5168 zigbee gw, remote support. Also see http://focalcrest.com/en/pc.html#pro02 --- configs/mixtile_loftq_defconfig | 17 + 1 file changed, 17 insertions(+) create mode 100644 configs/mixtile_loftq_defconfig diff --git a/configs/mixtile_loftq_defconfig b/configs/mixtile_loftq_defconfig new file mode 100644 index 000..7d4229b --- /dev/null +++ b/configs/mixtile_loftq_defconfig @@ -0,0 +1,17 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPA(21) +CONFIG_MACH_TYPE=3892 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN6I=y ++S:CONFIG_TARGET_MIXTILE_LOFTQ=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=251 ++S:CONFIG_MMC_SUNXI_SLOT=0 ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +# Wifi power ++S:CONFIG_AXP221_ALDO1_VOLT=3300 +# Vbus gpio for usb1 ++S:CONFIG_USB1_VBUS_PIN=PH24 +# No Vbus gpio for usb2 ++S:CONFIG_USB2_VBUS_PIN= -- 1.9.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 v5 06/12] regulator: axp20x: prepare support for multiple AXP chip families
On Tue, Mar 10, 2015 at 07:59:17PM +0800, Chen-Yu Tsai wrote: From: Boris BREZILLON boris.brezil...@free-electrons.com Rework the AXP20X_ macros and probe function to support the several chip families, so that each family can define it's own set of regulators. Applied, thanks. -- 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: Digital signature
[linux-sunxi] Re: [PATCH v5 07/12] regulator: axp20x: add support for AXP22X regulators
On Tue, Mar 10, 2015 at 07:59:18PM +0800, Chen-Yu Tsai wrote: From: Boris BREZILLON boris.brezil...@free-electrons.com Add AXP22X regulator definitions and variant id associations. This introduces a new switch type output for one of the regulators. It is a switchable secondary output of one regulator, with the same voltage level as the primary output. Applied, thanks. -- 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: Digital signature
[linux-sunxi] Re: [PATCH v5 07/12] regulator: axp20x: add support for AXP22X regulators
On Tue, Mar 10, 2015 at 07:59:18PM +0800, Chen-Yu Tsai wrote: From: Boris BREZILLON boris.brezil...@free-electrons.com Add AXP22X regulator definitions and variant id associations. This introduces a new switch type output for one of the regulators. It is a switchable secondary output of one regulator, with the same voltage level as the primary output. Wait, no - sorry. I'd missed the defines being added earlier on. Instead: Reviewed-by: Mark Brown broo...@kernel.org -- 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: Digital signature
[linux-sunxi] Re: [PATCH v5 06/12] regulator: axp20x: prepare support for multiple AXP chip families
On Tue, Mar 10, 2015 at 07:59:17PM +0800, Chen-Yu Tsai wrote: From: Boris BREZILLON boris.brezil...@free-electrons.com Rework the AXP20X_ macros and probe function to support the several chip families, so that each family can define it's own set of regulators. Wait, no - sorry. I'd missed the defines being added earlier on. Instead: Reviewed-by: Mark Brown broo...@kernel.org -- 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: Digital signature
[linux-sunxi] Re: [PATCH 00/15] musb: Add support for the Allwinner sunxi musb controller
On Mon, Mar 09, 2015 at 09:40:13PM +0100, Hans de Goede wrote: Hi All, This patch set has been a while in the making, so I'm very happy to present the end result here, and I hope everyone likes it. Before talking about merging this there are 2 things which I would like to point out: a) The musb controller in the sunxi SoCs uses some SRAM which needs to be mapped to the musb controller by poking some bits in the SRAM controller, just like the EMAC patches which were send a while back I've chosen to use syscon for this, actually 2 of the patches in this set come directly from the SRAM mapping patchset for the EMAC. I know that Maxime is not 100% in favor of using syscon: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320221.html But I disagree with his arguments for writing a special driver for the SRAM controller: And I disagree with your disagreement :) 1) syscon was specifically designed for global system control registers like this and is fine to use as long as there are no conflicts where 1 bit is of interest to multiple drivers, and there is no such conflict here No. Syscon has been designed for being lazy. This is a huge abstraction non-sense. You have to put all the logic of dealing with some external register layout in clients drivers, including dealing with the different revisions/SoC that are different from that aspect, and duplicating that code across all client drivers. 2) Maxime's other arguments seem to boil down to it would be nice / prettier to have a specific driver for this, without really proving a hard need for such a driver. But writing such a driver is going to be a lot of work, and we've a ton of other work to do, and as said there is no real need for a separate driver, syscon works fine for this. Actually, I already wrote some prototype for this. I'll clean this up and send it tonight/tomorrow. 3) I actually believe that having a specific driver for this is a bad idea, because that means inventing a whole new cross driver API for this, and getting those right is, hard, a lot of work, and even then one is still likely to get it wrong. We can avoid all this by going with the proven syscon solution. Except that modifying an in-kernel API, especially when we have two users, is easy. Moving back from syscon is not. Maxime, can we please have your ack for moving forward with this using syscon? (see above for my arguments why) If you can address my objections above, sure. Thanks for your awesome work on this, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: Digital signature
[linux-sunxi] [PATCH v2 2/2] ARM: dts: sun7i: Add OOB irq support to boards with broadcom sdio wifi
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 8
arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 8
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 012c337..d85ae00 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -173,6 +173,14 @@
bus-width = 4;
non-removable;
status = okay;
+
+ brcmf: bcrmf@1 {
+ reg = 1;
+ compatible = brcm,bcm4329-fmac;
+ interrupt-parent = pio;
+ interrupts = 10 IRQ_TYPE_LEVEL_LOW; /* PH10 / EINT10 */
+ interrupt-names = host-wake;
+ };
};
mmc3_pins_a {
diff --git a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
index baee563..c11574c 100644
--- a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
+++ b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
@@ -170,6 +170,14 @@
bus-width = 4;
non-removable;
status = okay;
+
+ brcmf: bcrmf@1 {
+ reg = 1;
+ compatible = brcm,bcm4329-fmac;
+ interrupt-parent = pio;
+ interrupts = 10 IRQ_TYPE_LEVEL_LOW; /* PH10 / EINT10 */
+ interrupt-names = host-wake;
+ };
};
mmc3_pins_a {
--
2.3.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.
Re: [linux-sunxi] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Hi Jens, On Fri, Feb 27, 2015 at 8:41 PM, Jens Thiele ka...@karme.de wrote: Julian Calaby julian.cal...@gmail.com writes: Hi Jens, Hi, On Fri, Feb 27, 2015 at 1:41 AM, Jens Thiele ka...@karme.de wrote: Do you think it is reasonable to expect the display/touchscreen of two Allwinner based tablets sold by the same name (including model number) are identical, or do they use different displays / touchscreen elements all the time? I think the answer is It depends I have two Allwinner SoC based tablets, one is a generic board that has been put into at least three different tablets I'm aware of. The FEX file and Android instance for it have configuration and drivers for at least three different models of touch screen. are those resistive touchscreens = sun4i-ts driver? are the fex files available on git://github.com/linux-sunxi/sunxi-boards.git ? (see also below) They're all i2c touch screens. See https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a10/inet_3fbt.fex I'm planning to get the mainline kernel / u-boot running on it shortly and will probably end up with a DTS specific to the tablet I have, however if someone happens to add support for one of the other tablets with the same board we're going to have to figure out a solution for all the duplication. (The only thing in the FEX that has multiple options is the touch screen - it might get customised per tablet, but I doubt it, apart from the boot screens, some pre-installed apps and sticking the name of the tablet in the About section of Android, no tablet-specific customisation of the ROM appears to have happened.) The other is manufactured by HP and I believe that while the particular board is put into at least 2 different models, they're all slight variations on the same thing (different / cheaper LCD) and consequently should all have the same touch screen chip. The differences I see are with the resistive touchscreen panels / cover themself / even the surface feels different ... hard to explain those parts: https://www.olimex.com/Products/OLinuXino/LCD/A13-TS7/ https://www.olimex.com/Products/OLinuXino/LCD/A13-TS10/ My point is that we now have a product that can have two different resistive touch screens added to it. This makes things complicated =) I think the general consensus is that one can assume that all tablets with the same name and details will have the same touch screen. In your case, with development boards, that's less viable and we possibly should be using device tree overlays (or whatever they're called) to separate peripheral configuration (the LCD + touch screen board) from system configuration (the development board itself) but I'm hazy on the details. IMHO, you should write the patch to get the value from device tree and worry about the board configuration details when submitting that. Just wanted to start with this, but then had look at the fex files from git://github.com/linux-sunxi/sunxi-boards.git having rtp_used = 1. They nearly all have the same rtp_para block: [rtp_para] rtp_used = 1 rtp_screen_size = 5 rtp_regidity_level = 5 rtp_press_threshold_enable = 0 rtp_press_threshold = 0x1f40 rtp_sensitive_level = 0xf rtp_exchange_x_y_flag = 0 The exceptions are: ./a10/iteaduino_plus_a10.fex [rtp_para] rtp_used = 1 rtp_screen_size = 7 rtp_regidity_level = 5 rtp_press_threshold_enable = 1 rtp_press_threshold = 0x1f40 rtp_sensitive_level = 0xf rtp_exchange_x_y_flag = 0 ./a13/ampe_a76.fex [rtp_para] rtp_used = 1 rtp_screen_size = 7 rtp_regidity_level = 5 rtp_press_threshold_enable = 0 rtp_press_threshold = 0x1f40 rtp_sensitive_level = 0xf rtp_exchange_x_y_flag = 0 But both use rtp_sensitive_level = 0xf, too. Now I am not sure, it is really worth it. And I believe that they're all for tablets which have fixed touch screens. IMHO we should have access to all the parameters that can be configured per-device in the DTS. That we don't is a bug that arguably should be fixed. Again, I urge you to make that parameter available in device tree as it'll be useful for you in conjunction with device tree overlays. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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 v5 12/12] ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module
On Wed, Mar 11, 2015 at 5:32 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Mar 10, 2015 at 07:59:24PM +0800, Chen-Yu Tsai wrote: The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO. The IC also takes a power enable signal via GPIO. This is supported with the new power sequencing bindings. The WiFi module supports out-of-band interrupt signaling via GPIO, but this is buggy and not enabled yet. Signed-off-by: Chen-Yu Tsai w...@csie.org There's two almost identical patches 12/12. Which one am I suppose to apply? This one is the right one. I forgot to clear the patches after changing the description. The buggy part in the description is probably not needed. Hans explained that the SD resets have nothing to do with interrupt handling. 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.
[linux-sunxi] [PATCH v2 0/2] ARM: dts: sun7i: Add OOB irq support to boards with sdio wifi
Hi Maxime, Here is v2 of the dts patches to add OOB irq support to boards with sdio wifi. Changes since v1: -New patch to set the address / size cells in the dtsi -Use macro for the irq type Regards, Hans -- 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] Derailed thread
On Tue, Mar 10, 2015 at 01:38:30PM +, Manuel Braga wrote: Hi, That was a joke mail, in response to the joke that allwinner gave us when allwinner added the LGPL license to source code that includes a binary accused of being in noncompliance. This was not a joke email. Its contents was very serious, and it should be interpreted as such. Allwinner needs/needed to know what it had just done, and that it has to fullfill its obligations. The fact that I did so, _after_ the facts had been often and openly discussed, and after allwinner had been explained their obligations countless times, does make it less than serious. The contents however is nothing to be laughed about. try to get the support of something like the SFC so that they can evaluate the merits of pursuing. And then the SFC would do the talking. I heared (but don't have the details), and this looks to be true. SFC or someone from SFC is aware of this issue. But maybe others can make this more clear. But nobody is here to sue, (why do i have to keep saying this) i think i can speak for all and say that we want to resolve this in a friendly way, but for that, there most be dialog between parties. Not excuse to ignore the issues. And Simos look at the news, with SFC and vmware, look at the time it took and no result. People tried talking to VMWare for 7-8 years. We have been trying to talk to Allwinner at least since 2012 (i am sure that LKCL would be happy to divulge his conversations with allwinner if it comes to legal action). Allwinners case is pretty open and shut, especially since they actively use both the kernel and uboot, and the symbols in cedar are clearly visible. And unlike VMWare Allwinner has its _whole_ business to lose. When there is any legal action, it could be a lot swifter. Perhaps Allwinner should act quickly and do so in an all encompassing way. If not, it stands to lose quite a lot. Luc Verhaegen. -- 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 12/15] ARM: dts: sun4i: Enable USB DRC on Chuwi V7 CW0825
On Tue, Mar 10, 2015 at 04:23:09PM +0100, Hans de Goede wrote:
Hi,
On 03/10/2015 04:07 PM, Maxime Ripard wrote:
Hi Hans,
On Mon, Mar 09, 2015 at 09:40:25PM +0100, Hans de Goede wrote:
Enable the otg/drc usb controller on the Chuwi V7 CW0825 tablet.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 31
+
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
index 97fca89..034396c 100644
--- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
+++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
@@ -111,6 +111,26 @@
status = okay;
};
+pio {
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = PH4;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+ allwinner,pins = PH5;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_DOWN;
+ };
+};
+
+reg_usb0_vbus {
+ status = okay;
+};
+
reg_usb2_vbus {
status = okay;
};
@@ -121,7 +141,18 @@
status = okay;
};
+usb_otg {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_id_detect_pin
+usb0_vbus_detect_pin;
+ id_det-gpio = pio 7 4 GPIO_ACTIVE_HIGH; /* PH4 */
+ vbus_det-gpio = pio 7 5 GPIO_ACTIVE_HIGH; /* PH5 */
+ dr_mode = otg;
Is there a reason to not put that in the DTSI?
This is not in the dtsi because it is board specific.
All the users seem to be wiring it as OTG.
Sofar I've only enabled the otg on a handful of boards,
the otg on the Mele-M9 for example is connected to a usb-sata
bridge and as such should be brought up in host only mode.
And on the wobo-i5 (which I still need to create a dts file for)
the otg is connected to an usb wifi module.
Ok, that seems like a good reason :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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: Digital signature
Re: [linux-sunxi] Re: [PATCH] ARM: sun6i: dt: Add new Mele I7 device
On Tue, Mar 10, 2015 at 12:16:07PM +0100, Hans de Goede wrote:
Hi,
On 03-03-15 14:58, Maxime Ripard wrote:
On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote:
Hi,
On 03-03-15 09:22, Maxime Ripard wrote:
On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote:
+/ {
+ model = Mele I7 Quad top set box;
+ compatible = mele,i7, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
Using earlyprintk by default is a bad idea if the kernel is configured
with DEBUG_LL support for another SoC.
While on this subject, u-boot now sets the chosen/stdout-path property
up by default, which means that the kernel will do the right thing by
default. So we we really do not need any bootargs= in our dts files.
I just tested that this weekend, and it turned out that the kernel
couldn't use it so far (ie, no output until init takes over and setup
a TTY on ttyS0).
Was it working for you?
Yes, note that the kernel only honors the stdout-path property if
there is no console= argument present if there is a console= argument
present on the kernel cmdline then that will overrule the stdout-path
property
Yeah, I removed the bootargs entirely.
Which board did you test with, and what u-boot and kernel version ?
I tested it on my A31 hummingbird, with allwinner's u-boot, but with
/chosen/stdout-path hardcoded to serial0:115200n8, with a 4.0-rc1
kernel.
I'm not sure if stdout-path supports aliases this is what u-boot is using,
and which works fine (with 4.0-rc1 kernel):
/soc@01c0/serial@01c28000:115200
I gave that another try, and it worked like a charm, so it really
looks like an instance of PEBKAC.
But it might very well just be me. We just tested it on a Marvell
board (that uses the same serial driver) this morning and it was fine,
so I don't think it's really worth worrying about this :)
Currently we've a random mix where we do have bootargs in some, but
not in most sunxi dts files. I believe we should simply remove it
everywhere...
We used to set them in SoCs that are not supported by U-boot yet, and
where the bootloader won't come and patch the DT (A31, A23, A80).
Ah, so that is (was) the logic, following that logic we should probably
remove bootargs= from at least the a23 and a31 boards (basically
from all boards but a80).
I'm not so sure about the A31, since most boards won't even boot by
default on the SD card
True.
and we have no way to replace U-Boot in NAND
so far (afaik). But replacing them by stdout-path is a very good
solution too.
You mean putting stdout-path in the dts, I'm not sure if I like that,
to me both bootargs and stdout-path are something which should be
left to the bootloader to set. But I understand that when not
using upstream u-boot that may be an issue.
I know that some other platforms ask for stdout-path when they review
it, because iirc, barebox uses it to know on which console to output
its log and export its shell, which is also a valid interpretation of
that property, and, contrary to bootargs, doesn't really imply that
the bootloader should update it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH 05/15] musb: Do not use musb_read[b|w] / _write[b|w] wrappers in generic fifo functions
Hi, On 09-03-15 22:50, Arnd Bergmann wrote: On Monday 09 March 2015 21:40:18 Hans de Goede wrote: The generic fifo functions already use non wrapped accesses in various cases through the iowrite#_rep functions, and all platforms which override the default musb_read[b|w] / _write[b|w] functions also provide their own fifo access functions, so we can safely drop the unnecessary indirection from the fifo access functions. Signed-off-by: Hans de Goede hdego...@redhat.com The patch looks reasonably, but the description seem misleading. I believe the real reason why it's ok to use __raw_writew for the FIFO is that a FIFO by definition is using CPU endian access for copying byte streams from memory, which is unlike any other MMIO register that requires fixed-endian accessors. I'm not sure that that is the case here, this fifo allows reading 4 bytes at a time using 32 bit word access, so endianness may come into play. This patch is safe however since all existing users of the generic fifo_read / write helpers which this patch touches, are also using the generic musb_read[b|w] / _write[b|w] functions which are just __raw_foo wrappers, so there is no functional change, which is what the commit message tries to say. Note that sunxi needs this function because of the register address translation the sunxi_musb_readb / writeb wrappers are doing which does not know how to deal with fifo data, and besides that it should make the generic read / write fifo helpers somewhat faster by removing an indirect function call. Regards, Hans -- 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: Reviewing the book Getting Started with Cubieboard (Packt Publishing Ltd)
On Wed, Mar 4, 2015 at 11:43 AM, Simos Xenitellis simos.li...@googlemail.com wrote: Hi All, As you may know, there is an introductory book about the A-Series of Allwinner SoCs (specifically A10, A13 and A20), called Getting Started with Cubieboard, written by Olliver Schinagl and published by Packt Publishing Ltd. Read more at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard Packt is doing some publicity for this book. What they are doing is that they give the e-book version of the book in exchange for an online review. The idea is that by having several online reviews for the book, it helps prospective buyers to decide whether to buy or not. Obviously, you are free to write whatever you want in the review. I offered them my help in finding such reviewers, and they are looking for 3 persons. Here are the details: 1. Have a look at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard to decide if you are interested to go through this. 2. Write a review on Amazon, Google Books and goodreads. For Amazon, you need to have an account and have bought something in order to be able to post reviews. 3. Write a review on your personal blog or similar social media. If you are interested in taking part, please send me a private email. Please also add a sentence describing why it would be helpful to you to get a copy (to be used in case there are more than 3 replies). I'll collect replies until this Friday. If there are any general questions, reply here. I have no affiliation with Packt Publishing Ltd. I got some good replies and forwarded them to Packt. They confirmed that they will be contacting you (if they did not do already) with further details. I also suggested to Packt to get someone from either CubieTech or Allwinner to review the book. Obviously, such a thing would be mutually beneficial in terms of marketing. So, if you are from CubieTech or Allwinner, do contact me in private. Simos -- 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 00/15] musb: Add support for the Allwinner sunxi musb controller
Hi, On 10-03-15 02:46, Chen-Yu Tsai wrote: Hi Arnd, On Tue, Mar 10, 2015 at 5:44 AM, Arnd Bergmann a...@arndb.de wrote: On Monday 09 March 2015 21:40:13 Hans de Goede wrote: Hi All, This patch set has been a while in the making, so I'm very happy to present the end result here, and I hope everyone likes it. Awesome work! Before talking about merging this there are 2 things which I would like to point out: a) The musb controller in the sunxi SoCs uses some SRAM which needs to be mapped to the musb controller by poking some bits in the SRAM controller, just like the EMAC patches which were send a while back I've chosen to use syscon for this, actually 2 of the patches in this set come directly from the SRAM mapping patchset for the EMAC. I know that Maxime is not 100% in favor of using syscon: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320221.html But I disagree with his arguments for writing a special driver for the SRAM controller: 1) syscon was specifically designed for global system control registers like this and is fine to use as long as there are no conflicts where 1 bit is of interest to multiple drivers, and there is no such conflict here 2) Maxime's other arguments seem to boil down to it would be nice / prettier to have a specific driver for this, without really proving a hard need for such a driver. But writing such a driver is going to be a lot of work, and we've a ton of other work to do, and as said there is no real need for a separate driver, syscon works fine for this. 3) I actually believe that having a specific driver for this is a bad idea, because that means inventing a whole new cross driver API for this, and getting those right is, hard, a lot of work, and even then one is still likely to get it wrong. We can avoid all this by going with the proven syscon solution. Maxime, can we please have your ack for moving forward with this using syscon? (see above for my arguments why) I'd like to understand here why we can't use the existing SRAM DT binding instead of the syscon binding. I believe you are talking about mmio-sram? The syscon here represents a switch, to toggle whether a block of SRAM is mapped into the CPU memory space, or to a specific devices private address space. It is not the actual SRAM. The SRAM DT binding is orthogonal to this, if not irrelevant when the block is mapped privately, as it is no longer visible from the DT's PoV. Coincidentally, on the A23 this is no longer needed. The SRAM for the FIFO is wholly owned by MUSB and not available to the CPU. What ChenYu said :) Regards, Hans -- 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 v5 01/12] ARM: dts: sun6i: add p2wi controller node to dtsi
On Tue, Mar 10, 2015 at 07:59:12PM +0800, Chen-Yu Tsai wrote: From: Boris BREZILLON boris.brezil...@free-electrons.com The p2wi controller has only one possible pinmux setting. Use it by default in the dtsi, instead of having to set it in each board's dts. Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com [w...@csie.org: reformat commit title; rename p2wi pins and use as default] Signed-off-by: Chen-Yu Tsai w...@csie.org Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH v5 02/12] ARM: dts: sun6i: hummingbird: Enable P2WI controller
On Tue, Mar 10, 2015 at 07:59:13PM +0800, Chen-Yu Tsai wrote: The Hummingbird A31 has an AXP221 PMIC hooked up to the P2WI controller. Signed-off-by: Chen-Yu Tsai w...@csie.org Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH v5 05/12] ARM: dts: sun6i: hummingbird: Add AXP221 PMIC device node
On Tue, Mar 10, 2015 at 07:59:16PM +0800, Chen-Yu Tsai wrote: The Hummingbird A31 has an AXP221 PMIC hooked up to the P2WI controller. Signed-off-by: Chen-Yu Tsai w...@csie.org Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH v5 10/12] ARM: dts: sun6i: hummingbird: Add AXP221 regulator nodes
On Tue, Mar 10, 2015 at 07:59:21PM +0800, Chen-Yu Tsai wrote: This patch adds the AXP221 regulators. Only the ones directly used on the board are added. Signed-off-by: Chen-Yu Tsai w...@csie.org Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH v5 11/12] ARM: dts: sun6i: Add pinmux settings for mmc1 to dtsi
On Tue, Mar 10, 2015 at 07:59:22PM +0800, Chen-Yu Tsai wrote:
mmc1 is used to connect to the WiFi chip on the Hummingbird A31.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun6i-a31.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi
b/arch/arm/boot/dts/sun6i-a31.dtsi
index 92abea20b946..39d87a901b46 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -581,6 +581,14 @@
allwinner,pull = SUN4I_PINCTRL_NO_PULL;
};
+ mmc1_pins_a: mmc1@0 {
+ allwinner,pins = PG0, PG1, PG2, PG3,
+ PG4, PG5;
+ allwinner,function = mmc1;
+ allwinner,drive = 2;
+ allwinner,pull = 0;
You should use the defines here.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH v2 1/2] ARM: dts: sunxi: Add address- and size-cells properties to the mmc ctrl nodes
On Tue, Mar 10, 2015 at 04:27:09PM +0100, Hans de Goede wrote: Sometimes we need to specify non-probably information for sdio devices in the devicetree, this is done through child nodes addressed by the reg property, whereby the reg property refers to the sdio function number, see; Documentation/devicetree/bindings/mmc/mmc.txt This commit adds the necessary address- and size-cells properties to the mmc controller nodes in the dtsi files, so that dts files needing such a child node do not need to specify these themselves. Signed-off-by: Hans de Goede hdego...@redhat.com Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH v5 12/12] ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module
On Tue, Mar 10, 2015 at 07:59:24PM +0800, Chen-Yu Tsai wrote: The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO. The IC also takes a power enable signal via GPIO. This is supported with the new power sequencing bindings. The WiFi module supports out-of-band interrupt signaling via GPIO, but this is buggy and not enabled yet. Signed-off-by: Chen-Yu Tsai w...@csie.org There's two almost identical patches 12/12. Which one am I suppose to apply? Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH v2 2/2] ARM: dts: sun7i: Add OOB irq support to boards with broadcom sdio wifi
On Tue, Mar 10, 2015 at 04:27:10PM +0100, Hans de Goede wrote: Signed-off-by: Hans de Goede hdego...@redhat.com Some commit log would have been nice, but I just applied the patch. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: Digital signature
[linux-sunxi] Re: [PATCH 00/15] musb: Add support for the Allwinner sunxi musb controller
Hi, On 03/10/2015 06:41 PM, Maxime Ripard wrote: On Mon, Mar 09, 2015 at 09:40:13PM +0100, Hans de Goede wrote: Hi All, This patch set has been a while in the making, so I'm very happy to present the end result here, and I hope everyone likes it. Before talking about merging this there are 2 things which I would like to point out: a) The musb controller in the sunxi SoCs uses some SRAM which needs to be mapped to the musb controller by poking some bits in the SRAM controller, just like the EMAC patches which were send a while back I've chosen to use syscon for this, actually 2 of the patches in this set come directly from the SRAM mapping patchset for the EMAC. I know that Maxime is not 100% in favor of using syscon: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320221.html But I disagree with his arguments for writing a special driver for the SRAM controller: And I disagree with your disagreement :) 1) syscon was specifically designed for global system control registers like this and is fine to use as long as there are no conflicts where 1 bit is of interest to multiple drivers, and there is no such conflict here No. Syscon has been designed for being lazy. This is a huge abstraction non-sense. You have to put all the logic of dealing with some external register layout in clients drivers, including dealing with the different revisions/SoC that are different from that aspect, and duplicating that code across all client drivers. 2) Maxime's other arguments seem to boil down to it would be nice / prettier to have a specific driver for this, without really proving a hard need for such a driver. But writing such a driver is going to be a lot of work, and we've a ton of other work to do, and as said there is no real need for a separate driver, syscon works fine for this. Actually, I already wrote some prototype for this. I'll clean this up and send it tonight/tomorrow. Ok, lets see your prototype and then we'll go from there. Regards, Hans -- 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] ARM: sun6i: dt: Add new Mele I7 device
Hi,
On 03/10/2015 07:44 PM, Maxime Ripard wrote:
On Tue, Mar 10, 2015 at 12:16:07PM +0100, Hans de Goede wrote:
Hi,
On 03-03-15 14:58, Maxime Ripard wrote:
On Tue, Mar 03, 2015 at 02:20:31PM +0100, Hans de Goede wrote:
Hi,
On 03-03-15 09:22, Maxime Ripard wrote:
On Tue, Mar 03, 2015 at 08:55:36AM +0100, Hans de Goede wrote:
+/ {
+ model = Mele I7 Quad top set box;
+ compatible = mele,i7, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
Using earlyprintk by default is a bad idea if the kernel is configured
with DEBUG_LL support for another SoC.
While on this subject, u-boot now sets the chosen/stdout-path property
up by default, which means that the kernel will do the right thing by
default. So we we really do not need any bootargs= in our dts files.
I just tested that this weekend, and it turned out that the kernel
couldn't use it so far (ie, no output until init takes over and setup
a TTY on ttyS0).
Was it working for you?
Yes, note that the kernel only honors the stdout-path property if
there is no console= argument present if there is a console= argument
present on the kernel cmdline then that will overrule the stdout-path
property
Yeah, I removed the bootargs entirely.
Which board did you test with, and what u-boot and kernel version ?
I tested it on my A31 hummingbird, with allwinner's u-boot, but with
/chosen/stdout-path hardcoded to serial0:115200n8, with a 4.0-rc1
kernel.
I'm not sure if stdout-path supports aliases this is what u-boot is using,
and which works fine (with 4.0-rc1 kernel):
/soc@01c0/serial@01c28000:115200
I gave that another try, and it worked like a charm, so it really
looks like an instance of PEBKAC.
But it might very well just be me. We just tested it on a Marvell
board (that uses the same serial driver) this morning and it was fine,
so I don't think it's really worth worrying about this :)
Currently we've a random mix where we do have bootargs in some, but
not in most sunxi dts files. I believe we should simply remove it
everywhere...
We used to set them in SoCs that are not supported by U-boot yet, and
where the bootloader won't come and patch the DT (A31, A23, A80).
Ah, so that is (was) the logic, following that logic we should probably
remove bootargs= from at least the a23 and a31 boards (basically
from all boards but a80).
I'm not so sure about the A31, since most boards won't even boot by
default on the SD card
True.
and we have no way to replace U-Boot in NAND
so far (afaik). But replacing them by stdout-path is a very good
solution too.
You mean putting stdout-path in the dts, I'm not sure if I like that,
to me both bootargs and stdout-path are something which should be
left to the bootloader to set. But I understand that when not
using upstream u-boot that may be an issue.
I know that some other platforms ask for stdout-path when they review
it, because iirc, barebox uses it to know on which console to output
its log and export its shell, which is also a valid interpretation of
that property, and, contrary to bootargs, doesn't really imply that
the bootloader should update it.
Hmm, that is interesting we should probably start doing the same in
all the sunxi dts files, as eventually I would like to move all u-boot
board config to devicetree, so that we only need to maintain dts files
and not both dts files and u-boot board configs.
Regards,
Hans
--
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 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
Hi,
On 09-03-15 22:47, Arnd Bergmann wrote:
On Monday 09 March 2015 21:40:15 Hans de Goede wrote:
+void sun4i_usb_phy_update_iscr(struct phy *_phy, u32 clr, u32 set)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ u32 iscr;
+
+ iscr = readl(data-base + REG_ISCR);
+ iscr = ~clr;
+ iscr |= set;
+ writel(iscr, data-base + REG_ISCR);
+}
+EXPORT_SYMBOL(sun4i_usb_phy_update_iscr);
+
I would generally consider this a bad design. What is the purpose of
calling sun4i_usb_phy_update_iscr()
There are 2 different use cases for this one is to enable the dataline
pull-ups at driver init and disable them at driver exit, this could /
should probably be moved to the phy_init / phy_exit code for the usb0 phy
removing the need to do this from within the sunxi musb glue.
The second use-case is more tricky, for some reasons Allwinner has decided
to not use the dedicated id-detect and vusb-sense pins of the phy they are
using (these pins are not routed to the outside).
Instead id-detect and vusb-sense are done through any $random gpio pins
(including non irq capable pins on some designs requiring polling).
But the musb-core still needs to know the status of the id and vbus pins,
and gets this from the usb0-phy iscr register, which reflects the status of
the not connected dedicated pins of the phy. The reason this can still
work at all is because the iscr register allows the user to override
whatever the not connected phy pins are seeing and forcing a value to
report to the musb core as id and vbus status.
This is done by these 2 functions in the musb sunxi glue:
static void sunxi_musb_force_id(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_ID_HIGH;
else
val = SUNXI_ISCR_FORCE_ID_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_ID_MASK, val);
}
static void sunxi_musb_force_vbus(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_VBUS_HIGH;
else
val = SUNXI_ISCR_FORCE_VBUS_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_VBUS_MASK, val);
}
I will happily admit that these 2 functions are a better API between the sunxi
musb
glue and the sunxi usb phy driver. I started with the minimal
sun4i_usb_phy_update_iscr
approach as I wanted to keep the API as small as possible, but having 2
functions like
the one above, which actually reflect what is happening would indeed be better.
Note that the polling of the pins cannot (easily) be moved into the phy driver
for various
reasons:
1) It depends on dr_mode, the otg may be used in host only mode in which case
there are no
pins at all.
2) the musb set_vbus callback needs access to the pins
3) When id changes some musb core state changes are necessary.
I'll respin the patch set to do things this way as soon as we've agreement on
your second point.
and why can't there be a high-level
PHY API for this?
The current generic phy API seems to not have any bus specific methods, I know
that
in the long run people want to get rid of struct usb_phy, so maybe we should
consider
adding bus specific methods to the generic phy API for things like otg.
If we decide to add bus specific methods, then the question becomes if having
int phy_usb_set_id_detect(struct phy *phy, bool val);
int phy_usb_set_vbus_detect(struct phy *phy, bool val);
Functions in the generic phy API is a good idea, or if this is too sunxi
specific,
I'm fine with doing this either way. If we want to go the generic phy route
I'll split this in 2 patches, one adding these 2 generic functions phy-ops,
and
1 doing the sunxi implementation.
If people believe this is too sunxi specific (I believe it is, but as said I'm
fine with doing this either way). I'll respin this patch to remove the too
generic sun4i_usb_phy_update_iscr function, and instead add these 2:
void sun4i_usb_phy_set_id_detect(struct phy *phy, bool val);
void sun4i_usb_phy_set_vbus_detect(struct phy *phy, bool val);
Regards,
Hans
--
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 00/15] musb: Add support for the Allwinner sunxi musb controller
On Tuesday 10 March 2015 09:46:24 Chen-Yu Tsai wrote: I believe you are talking about mmio-sram? Yes. The syscon here represents a switch, to toggle whether a block of SRAM is mapped into the CPU memory space, or to a specific devices private address space. It is not the actual SRAM. The SRAM DT binding is orthogonal to this, if not irrelevant when the block is mapped privately, as it is no longer visible from the DT's PoV. Ok, got it. I missed this part when reading the introduction. syscon seems fine to me then. Arnd -- 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 05/15] musb: Do not use musb_read[b|w] / _write[b|w] wrappers in generic fifo functions
On Tuesday 10 March 2015 08:43:22 Hans de Goede wrote: On 09-03-15 22:50, Arnd Bergmann wrote: On Monday 09 March 2015 21:40:18 Hans de Goede wrote: The generic fifo functions already use non wrapped accesses in various cases through the iowrite#_rep functions, and all platforms which override the default musb_read[b|w] / _write[b|w] functions also provide their own fifo access functions, so we can safely drop the unnecessary indirection from the fifo access functions. Signed-off-by: Hans de Goede hdego...@redhat.com The patch looks reasonably, but the description seem misleading. I believe the real reason why it's ok to use __raw_writew for the FIFO is that a FIFO by definition is using CPU endian access for copying byte streams from memory, which is unlike any other MMIO register that requires fixed-endian accessors. I'm not sure that that is the case here, this fifo allows reading 4 bytes at a time using 32 bit word access, so endianness may come into play. This patch is safe however since all existing users of the generic fifo_read / write helpers which this patch touches, are also using the generic musb_read[b|w] / _write[b|w] functions which are just __raw_foo wrappers, so there is no functional change, which is what the commit message tries to say. This probably means that the generic musb helpers are not safe to use on big-endian ARM systems (but may work on MIPS). The only one currently not using the generic helpers is blackfin, which is fixed to little endian. Note that sunxi needs this function because of the register address translation the sunxi_musb_readb / writeb wrappers are doing which does not know how to deal with fifo data, and besides that it should make the generic read / write fifo helpers somewhat faster by removing an indirect function call. Your sunxi_musb_readw/writew functions however also are endian-safe and seem to get this part right, unlike all other platforms that use the generic __raw_*() accessors. With this patch applied, it should actually work fine, and it would work on other platforms as well if we change all __raw_*() calls outside of musb_default_write_fifo() and musb_default_read_fifo() to use *_relaxed() instead. Arnd -- 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 05/15] musb: Do not use musb_read[b|w] / _write[b|w] wrappers in generic fifo functions
Hi, On 10-03-15 09:50, Arnd Bergmann wrote: On Tuesday 10 March 2015 08:43:22 Hans de Goede wrote: On 09-03-15 22:50, Arnd Bergmann wrote: On Monday 09 March 2015 21:40:18 Hans de Goede wrote: The generic fifo functions already use non wrapped accesses in various cases through the iowrite#_rep functions, and all platforms which override the default musb_read[b|w] / _write[b|w] functions also provide their own fifo access functions, so we can safely drop the unnecessary indirection from the fifo access functions. Signed-off-by: Hans de Goede hdego...@redhat.com The patch looks reasonably, but the description seem misleading. I believe the real reason why it's ok to use __raw_writew for the FIFO is that a FIFO by definition is using CPU endian access for copying byte streams from memory, which is unlike any other MMIO register that requires fixed-endian accessors. I'm not sure that that is the case here, this fifo allows reading 4 bytes at a time using 32 bit word access, so endianness may come into play. This patch is safe however since all existing users of the generic fifo_read / write helpers which this patch touches, are also using the generic musb_read[b|w] / _write[b|w] functions which are just __raw_foo wrappers, so there is no functional change, which is what the commit message tries to say. This probably means that the generic musb helpers are not safe to use on big-endian ARM systems (but may work on MIPS). The only one currently not using the generic helpers is blackfin, which is fixed to little endian. Note that sunxi needs this function because of the register address translation the sunxi_musb_readb / writeb wrappers are doing which does not know how to deal with fifo data, and besides that it should make the generic read / write fifo helpers somewhat faster by removing an indirect function call. Your sunxi_musb_readw/writew functions however also are endian-safe and seem to get this part right, unlike all other platforms that use the generic __raw_*() accessors. With this patch applied, it should actually work fine, and it would work on other platforms as well if we change all __raw_*() calls outside of musb_default_write_fifo() and musb_default_read_fifo() to use *_relaxed() instead. I think that that change falls outside of the scope of this patchset. I agree that it would be probably a good idea to get rid of the __raw_foo usage in musb, which is why I've used the non __raw versions in the sunxi glue, but as said I believe this falls outside of the scope of this patchset. All my preparation patches for adding sunxi support carefully do not make any functional changes, as I do not want to cause regressions on hardware which I cannot test. Regards, Hans -- 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 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
On Tuesday 10 March 2015 09:04:43 Hans de Goede wrote:
Hi,
On 09-03-15 22:47, Arnd Bergmann wrote:
On Monday 09 March 2015 21:40:15 Hans de Goede wrote:
+void sun4i_usb_phy_update_iscr(struct phy *_phy, u32 clr, u32 set)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ u32 iscr;
+
+ iscr = readl(data-base + REG_ISCR);
+ iscr = ~clr;
+ iscr |= set;
+ writel(iscr, data-base + REG_ISCR);
+}
+EXPORT_SYMBOL(sun4i_usb_phy_update_iscr);
+
I would generally consider this a bad design. What is the purpose of
calling sun4i_usb_phy_update_iscr()
There are 2 different use cases for this one is to enable the dataline
pull-ups at driver init and disable them at driver exit, this could /
should probably be moved to the phy_init / phy_exit code for the usb0 phy
removing the need to do this from within the sunxi musb glue.
The second use-case is more tricky, for some reasons Allwinner has decided
to not use the dedicated id-detect and vusb-sense pins of the phy they are
using (these pins are not routed to the outside).
Instead id-detect and vusb-sense are done through any $random gpio pins
(including non irq capable pins on some designs requiring polling).
But the musb-core still needs to know the status of the id and vbus pins,
and gets this from the usb0-phy iscr register, which reflects the status of
the not connected dedicated pins of the phy. The reason this can still
work at all is because the iscr register allows the user to override
whatever the not connected phy pins are seeing and forcing a value to
report to the musb core as id and vbus status.
This is done by these 2 functions in the musb sunxi glue:
static void sunxi_musb_force_id(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_ID_HIGH;
else
val = SUNXI_ISCR_FORCE_ID_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_ID_MASK, val);
}
static void sunxi_musb_force_vbus(struct musb *musb, u32 val)
{
struct sunxi_glue *glue = dev_get_drvdata(musb-controller-parent);
if (val)
val = SUNXI_ISCR_FORCE_VBUS_HIGH;
else
val = SUNXI_ISCR_FORCE_VBUS_LOW;
sun4i_usb_phy_update_iscr(glue-phy, SUNXI_ISCR_FORCE_VBUS_MASK,
val);
}
I will happily admit that these 2 functions are a better API between the
sunxi musb
glue and the sunxi usb phy driver. I started with the minimal
sun4i_usb_phy_update_iscr
approach as I wanted to keep the API as small as possible, but having 2
functions like
the one above, which actually reflect what is happening would indeed be
better.
Ok, that would definitely improve things.
Note that the polling of the pins cannot (easily) be moved into the phy
driver for various
reasons:
1) It depends on dr_mode, the otg may be used in host only mode in which case
there are no
pins at all.
2) the musb set_vbus callback needs access to the pins
3) When id changes some musb core state changes are necessary.
I'll respin the patch set to do things this way as soon as we've agreement on
your second point.
and why can't there be a high-level
PHY API for this?
The current generic phy API seems to not have any bus specific methods, I
know that
in the long run people want to get rid of struct usb_phy, so maybe we should
consider
adding bus specific methods to the generic phy API for things like otg.
If we decide to add bus specific methods, then the question becomes if having
int phy_usb_set_id_detect(struct phy *phy, bool val);
int phy_usb_set_vbus_detect(struct phy *phy, bool val);
Functions in the generic phy API is a good idea, or if this is too sunxi
specific,
I'm fine with doing this either way. If we want to go the generic phy route
I'll split this in 2 patches, one adding these 2 generic functions phy-ops,
and
1 doing the sunxi implementation.
If people believe this is too sunxi specific (I believe it is, but as said I'm
fine with doing this either way). I'll respin this patch to remove the too
generic sun4i_usb_phy_update_iscr function, and instead add these 2:
void sun4i_usb_phy_set_id_detect(struct phy *phy, bool val);
void sun4i_usb_phy_set_vbus_detect(struct phy *phy, bool val);
Thanks for your detailed explanations. I think this is something for
Kishon to decide, based on where he wants to take the phy API in the
long run. I'm fine with it either way, and it seems easy enough to
change between those two interfaces if we make up our minds about it
later.
Arnd
--
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] Re: Reviewing the book Getting Started with Cubieboard (Packt Publishing Ltd)
Hey all, On 10-03-15 08:41, Simos Xenitellis wrote: On Wed, Mar 4, 2015 at 11:43 AM, Simos Xenitellis simos.li...@googlemail.com wrote: Hi All, As you may know, there is an introductory book about the A-Series of Allwinner SoCs (specifically A10, A13 and A20), called Getting Started with Cubieboard, written by Olliver Schinagl and published by Packt Publishing Ltd. Read more at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard Packt is doing some publicity for this book. What they are doing is that they give the e-book version of the book in exchange for an online review. The idea is that by having several online reviews for the book, it helps prospective buyers to decide whether to buy or not. Obviously, you are free to write whatever you want in the review. I offered them my help in finding such reviewers, and they are looking for 3 persons. Here are the details: 1. Have a look at https://www.packtpub.com/hardware-and-creative/getting-started-cubieboard to decide if you are interested to go through this. 2. Write a review on Amazon, Google Books and goodreads. For Amazon, you need to have an account and have bought something in order to be able to post reviews. 3. Write a review on your personal blog or similar social media. If you are interested in taking part, please send me a private email. Please also add a sentence describing why it would be helpful to you to get a copy (to be used in case there are more than 3 replies). I'll collect replies until this Friday. If there are any general questions, reply here. I have no affiliation with Packt Publishing Ltd. I got some good replies and forwarded them to Packt. They confirmed that they will be contacting you (if they did not do already) with further details. I also suggested to Packt to get someone from either CubieTech or Allwinner to review the book. Obviously, such a thing would be mutually beneficial in terms of marketing. So, if you are from CubieTech or Allwinner, do contact me in private. Why have I not been contacted about this at all yet (by packt mostly). While I think it's good that you are putting in effort, it feels a little as being passed by. In any case, it's good that the book is being pushed, and if you are from CubieTech or Allwinner, please atleast CC me, as I am the author after all. Olliver Simos -- 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] [PATCH 09/15] ARM: dts: sun4i: Add USB Dual Role Controller
Hi, On 10-03-15 00:31, Julian Calaby wrote: Hi Hans, On Tue, Mar 10, 2015 at 7:40 AM, Hans de Goede hdego...@redhat.com wrote: Add a node for the otg/drc usb controller to sun4i-a10.dtsi. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/boot/dts/sun4i-a10.dtsi | 12 drivers/usb/musb/Kconfig | 1 + 2 files changed, 13 insertions(+) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 8180a3a..fab8e9a 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -65,6 +65,7 @@ comment Platform Glue Layer config USB_MUSB_SUNXI tristate Allwinner (sunxi) depends on ARCH_SUNXI + depends on NOP_USB_XCEIV Shouldn't this be in a different patch? Yes, this was a later fixup commit which got squashed into the wrong patch, thanks for catching this. This has been fixed in my personal tree, and will be in v2 of this set: https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-wip Regards, Hans -- 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.
