Re: [linux-sunxi] mac addresses
Would booting from a live usb with ubuntu or something help at all? On Thu, Apr 10, 2014 at 11:58 PM, Brian Beattie beat...@beattie-home.netwrote: Actually what I was more curious about, is does cubieboard assign a unique MAC address (if so how can I figure it out if I wiped the original software), do you pick one at random? I have sometimes in the past taken one form an obsolete or defunct ethernet board. But I can also see just making up a locally unique MAC address. On Thu, 2014-04-10 at 23:34 +0200, Gerardo Di Iorio wrote: Hi you can define mac address in 1)script.bin file(edit script.fex and convert to script.bin) 2) u-boot param 3) from linux cmd line for info read http://linux-sunxi.org/Manual_build_howto 2014-04-10 16:26 GMT+02:00 Brian Beattie beat...@beattie-home.net: What are people doing for MAC addresses on cubieboards? -- For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken Brian Beattiebeat...@beattie-home.net -- www.brian-beattie.com LFS12947 -- 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. -- For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken Brian Beattiebeat...@beattie-home.net -- www.brian-beattie.com LFS12947 -- 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. -- Jonathan Aquilina -- 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] mac addresses
Hi, On Fri, Apr 11, 2014 at 09:51:21AM +0200, Hans de Goede wrote: On 04/10/2014 04:26 PM, Brian Beattie wrote: What are people doing for MAC addresses on cubieboards? If you're running the 3.4 kernel then the MAC address gets based on the unique serial each A10 SOC has burned into the SID prom it has. So it will be unique and consistent across reboots / different distros. I still need to make some time to add similar code to u-boot, so that it will too use this as a base for the MAC. Once u-boot has code to base the MAC on this, then the upstream kernels should automatically pick up this value from u-boot. I finally took some time to work on my long-overdue eeprom framework, and the kernel should be able to retrieve these infos too in a foreseeable future. U-boot is another story though. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH v3 01/10] mfd: AXP20x: Add mfd driver for AXP20x PMIC
On Fri, Mar 28, 2014 at 10:21 AM, Lee Jones lee.jo...@linaro.org wrote:
[...]
+static struct resource axp20x_pek_resources[] = {
+ {
+ .name = PEK_DBR,
+ .start = AXP20X_IRQ_PEK_RIS_EDGE,
+ .end= AXP20X_IRQ_PEK_RIS_EDGE,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .name = PEK_DBF,
+ .start = AXP20X_IRQ_PEK_FAL_EDGE,
+ .end= AXP20X_IRQ_PEK_FAL_EDGE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
Have you considered doing this in the Device Tree? It's a lot less
code/overhead.
Hi Lee,
in v4 (I will send it soon) I left this code in since the resources
are well managed by the MFD core and adding it in the DT results in
pretty much the same code/overhead (atm the input device is not
present in the DT).
If you really think that it is the case to move the code in the DT,
please comment it in the v4.
Thanks,
--
Carlo Caione
--
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 v4 9/9] ARM: sunxi: Add AXP20x support multi_v7_defconfig
Signed-off-by: Carlo Caione ca...@caione.org --- arch/arm/configs/multi_v7_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index ee69829..239c014 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -134,6 +134,7 @@ CONFIG_KEYBOARD_SPEAR=y CONFIG_KEYBOARD_CROS_EC=y CONFIG_MOUSE_PS2_ELANTECH=y CONFIG_INPUT_MISC=y +CONFIG_INPUT_AXP20X_PEK=y CONFIG_INPUT_MPU3050=y CONFIG_SERIO_AMBAKMI=y CONFIG_SERIAL_8250=y @@ -189,6 +190,7 @@ CONFIG_SENSORS_LM90=y CONFIG_THERMAL=y CONFIG_ARMADA_THERMAL=y CONFIG_MFD_AS3722=y +CONFIG_MFD_AXP20X=y CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_SPI=y CONFIG_MFD_MAX8907=y @@ -199,6 +201,7 @@ CONFIG_MFD_TPS65910=y CONFIG_REGULATOR_VIRTUAL_CONSUMER=y CONFIG_REGULATOR_AB8500=y CONFIG_REGULATOR_AS3722=y +CONFIG_REGULATOR_AXP20X=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_PALMAS=y -- 1.8.3.2 -- 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 v4 5/9] input: misc: Add ABI docs for AXP20x PEK
Add ABI entries for the PEK found on PMU X-Powers AXP202 and AXP209. Signed-off-by: Carlo Caione ca...@caione.org --- Documentation/ABI/testing/sysfs-driver-input-axp-pek | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-input-axp-pek diff --git a/Documentation/ABI/testing/sysfs-driver-input-axp-pek b/Documentation/ABI/testing/sysfs-driver-input-axp-pek new file mode 100644 index 000..f8cdad2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-input-axp-pek @@ -0,0 +1,11 @@ +What: /sys/class/input/input(x)/startup +Date: March 2014 +Contact: Carlo Caione ca...@caione.org +Description: Startup time. Board is powered on if the button is pressed + for more than startup_time + +What: /sys/class/input/input(x)/shutdown +Date: March 2014 +Contact: Carlo Caione ca...@caione.org +Description: Shutdown time. Board is powered off if the button is pressed + for more than shutdown_time -- 1.8.3.2 -- 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 v4 3/9] mfd: AXP20x: Add bindings documentation
Bindings documentation for the AXP20x driver. In this file also
sub-nodes are documented.
Signed-off-by: Carlo Caione ca...@caione.org
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 96
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt
b/Documentation/devicetree/bindings/mfd/axp20x.txt
new file mode 100644
index 000..f0d894a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -0,0 +1,96 @@
+AXP202/AXP209 device tree bindings
+
+The axp20x family current members :-
+axp202 (X-Powers)
+axp209 (X-Powers)
+
+Required properties:
+- compatible: x-powers,axp202 or x-powers,axp209
+- reg: The I2C slave address for the AXP chip
+- interrupt-parent: The parent interrupt controller
+- interrupts: Interrupt specifiers for interrupt sources
+- interrupt-controller: axp20x has its own internal IRQs
+- #interrupt-cells: Should be set to 1
+- acin-supply: The input supply for LDO1
+- vin2-supply: The input supply for DCDC2
+- vin3-supply: The input supply for DCDC3
+- ldo24in-supply: The input supply for LDO2, LDO4
+- ldo3in-supply: The input supply for LDO3
+- ldo5in-supply: The input supply for LDO5
+
+- regulators: A node that houses a sub-node for each regulator. The regulators
are
+ bound using their name as listed here: dcdc2, dcdc3, ldo1, ldo2,
+ ldo3, ldo4, ldo5. The bindings details of individual regulator
+ device can be found in:
+ Documentation/devicetree/bindings/regulator/regulator.txt with
+ the exception of x-powers,dcdc-freq
+- compatible (for regulators): x-powers,axp20x-reg
+- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
+ (range: 750-1875). Default: 1.5MHz
+
+Optional properties for DCDCs:
+- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO mode
+ Default: AUTO mode
+
+Example:
+
+axp209: pmic@34 {
+ compatible = x-powers,axp209;
+ reg = 0x34;
+ interrupt-parent = nmi_intc;
+ interrupts = 0 8;
+
+ interrupt-controller;
+ #interrupt-cells = 1;
+
+ acin-supply = axp_ipsout_reg;
+ vin2-supply = axp_ipsout_reg;
+ vin3-supply = axp_ipsout_reg;
+ ldo24in-supply = axp_ipsout_reg;
+ ldo3in-supply = axp_ipsout_reg;
+ ldo5in-supply = axp_ipsout_reg;
+
+ regulators {
+ compatible = x-powers,axp20x-reg;
+
+ x-powers,dcdc-freq = 1500;
+
+ axp_vcore_reg: dcdc2 {
+ regulator-min-microvolt = 70;
+ regulator-max-microvolt = 2275000;
+ regulator-always-on;
+ };
+
+ axp_ddr_reg: dcdc3 {
+ regulator-min-microvolt = 70;
+ regulator-max-microvolt = 350;
+ regulator-always-on;
+ };
+
+ axp_rtc_reg: ldo1 {
+ regulator-always-on;
+ };
+
+ axp_analog_reg: ldo2 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ };
+
+ axp_pll_reg: ldo3 {
+ regulator-min-microvolt = 70;
+ regulator-max-microvolt = 350;
+ };
+
+ axp_hdmi_reg: ldo4 {
+ regulator-min-microvolt = 125;
+ regulator-max-microvolt = 330;
+ };
+
+ axp_mic_reg: ldo5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ };
+ };
+};
+
--
1.8.3.2
--
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 v4 6/9] regulator: AXP20x: Add support for regulators subsystem
AXP202 and AXP209 come with two synchronous step-down DC-DCs and five
LDOs. This patch introduces basic support for those regulators.
Signed-off-by: Carlo Caione ca...@caione.org
---
drivers/regulator/Kconfig| 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/axp20x-regulator.c | 285 +++
3 files changed, 293 insertions(+)
create mode 100644 drivers/regulator/axp20x-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6a79328..9f3bc48 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -139,6 +139,13 @@ config REGULATOR_AS3722
AS3722 PMIC. This will enable support for all the software
controllable DCDC/LDO regulators.
+config REGULATOR_AXP20X
+ tristate X-POWERS AXP20X PMIC Regulators
+ depends on MFD_AXP20X
+ help
+ This driver provides support for the voltage regulators on the
+ AXP20X PMIC.
+
config REGULATOR_DA903X
tristate Dialog Semiconductor DA9030/DA9034 regulators
depends on PMIC_DA903X
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 979f9dd..1dd084a 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o
obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
+obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
obj-$(CONFIG_REGULATOR_DA9055) += da9055-regulator.o
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
new file mode 100644
index 000..78a29e6
--- /dev/null
+++ b/drivers/regulator/axp20x-regulator.c
@@ -0,0 +1,285 @@
+/*
+ * AXP20x regulators driver.
+ *
+ * Copyright (C) 2013 Carlo Caione ca...@caione.org
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/init.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/mfd/axp20x.h
+#include linux/regulator/driver.h
+#include linux/regulator/of_regulator.h
+
+#define AXP20X_IO_ENABLED 0x03
+#define AXP20X_IO_DISABLED 0x07
+
+#define AXP20X_WORKMODE_DCDC2_MASK BIT(2)
+#define AXP20X_WORKMODE_DCDC3_MASK BIT(1)
+
+#define AXP20X_FREQ_DCDC_MASK 0x0f
+
+#define AXP20X_DESC_IO(_id, _supply, _min, _max, _step, _vreg, _vmask, _ereg,
\
+ _emask, _enable_val, _disable_val)
\
+ [AXP20X_##_id] = {
\
+ .name = #_id,
\
+ .supply_name= (_supply),
\
+ .type = REGULATOR_VOLTAGE,
\
+ .id = AXP20X_##_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),
\
+ .enable_val = (_enable_val),
\
+ .disable_val= (_disable_val),
\
+ .ops= axp20x_ops,
\
+ }
+
+#define AXP20X_DESC(_id, _supply, _min, _max, _step, _vreg, _vmask, _ereg,
\
+ _emask)
\
+ [AXP20X_##_id] = {
\
+ .name = #_id,
\
+ .supply_name= (_supply),
\
+ .type = REGULATOR_VOLTAGE,
\
+
[linux-sunxi] [PATCH v4 4/9] input: misc: Add driver for AXP20x Power Enable Key
This patch add support for the Power Enable Key found on MFD AXP202 and
AXP209. Besides the basic support for the button, the driver adds two
entries in sysfs to configure the time delay for power on/off.
Signed-off-by: Carlo Caione ca...@caione.org
---
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/axp20x-pek.c | 261
3 files changed, 273 insertions(+)
create mode 100644 drivers/input/misc/axp20x-pek.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7904ab0..87244fb 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -393,6 +393,17 @@ config INPUT_RETU_PWRBUTTON
To compile this driver as a module, choose M here. The module will
be called retu-pwrbutton.
+config INPUT_AXP20X_PEK
+ tristate X-Powers AXP20X power button driver
+ depends on MFD_AXP20X
+ help
+ Say Y here if you want to enable power key reporting via the
+ AXP20X PMIC.
+
+ To compile this driver as a module, choose M here. The module will
+ be called axp20x-pek.
+
+
config INPUT_TWL4030_PWRBUTTON
tristate TWL4030 Power button Driver
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index cda71fc..624abf5 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
+obj-$(CONFIG_INPUT_AXP20X_PEK) += axp20x-pek.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SIRFSOC_ONKEY) += sirfsoc-onkey.o
diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
new file mode 100644
index 000..a9112bd
--- /dev/null
+++ b/drivers/input/misc/axp20x-pek.c
@@ -0,0 +1,261 @@
+/*
+ * axp20x power button driver.
+ *
+ * Copyright (C) 2013 Carlo Caione ca...@caione.org
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/errno.h
+#include linux/irq.h
+#include linux/init.h
+#include linux/input.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mfd/axp20x.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/slab.h
+
+#define AXP20X_PEK_STARTUP_MASK(0xc0)
+#define AXP20X_PEK_SHUTDOWN_MASK (0x03)
+
+struct axp20x_pek {
+ struct axp20x_dev *axp20x;
+ struct input_dev *input;
+ int irq_dbr;
+ int irq_dbf;
+};
+
+struct axp20x_time {
+ unsigned int time;
+ unsigned int idx;
+};
+
+static const struct axp20x_time startup_time[] = {
+ { .time = 128, .idx = 0 },
+ { .time = 1000, .idx = 2 },
+ { .time = 3000, .idx = 1 },
+ { .time = 2000, .idx = 3 },
+};
+
+static const struct axp20x_time shutdown_time[] = {
+ { .time = 4000, .idx = 0 },
+ { .time = 6000, .idx = 1 },
+ { .time = 8000, .idx = 2 },
+ { .time = 1, .idx = 3 },
+};
+
+struct axp20x_pek_ext_attr {
+ const struct axp20x_time *p_time;
+ unsigned int mask;
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_startup_ext_attr = {
+ .p_time = startup_time,
+ .mask = AXP20X_PEK_STARTUP_MASK,
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_shutdown_ext_attr = {
+ .p_time = shutdown_time,
+ .mask = AXP20X_PEK_SHUTDOWN_MASK,
+};
+
+static struct axp20x_pek_ext_attr *get_axp_ext_attr(struct device_attribute
*attr)
+{
+ return container_of(attr, struct dev_ext_attribute, attr)-var;
+}
+
+static ssize_t axp20x_show_ext_attr(struct device *dev, struct
device_attribute *attr,
+ char *buf)
+{
+ struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
+ struct axp20x_pek_ext_attr *axp20x_ea = get_axp_ext_attr(attr);
+ unsigned int val;
+ int ret, i;
+
+ ret = regmap_read(axp20x_pek-axp20x-regmap, AXP20X_PEK_KEY, val);
+ if (ret != 0)
+ return ret;
+
+ val = axp20x_ea-mask;
+ val = ffs(axp20x_ea-mask) - 1;
+
+ for (i = 0; i 4; i++)
+ if (val == axp20x_ea-p_time[i].idx)
+ val = axp20x_ea-p_time[i].time;
+
+ return sprintf(buf, %ums\n, val);
+}
+
+static ssize_t axp20x_store_ext_attr(struct device *dev,
[linux-sunxi] [PATCH] net: sun4i-emac: add promiscuous support
The sun4i-emac driver is rather primitive, and doesn't support
promiscuous mode. This makes usage such as bridging impossible,
which is a shame on virtualization capable HW such as the
Allwinner A20.
The fix is fairly simple: move the RX setup code to the ndo_set_rx_mode
vector, and add the required HW configuration when IFF_PROMISC is passed
by the core code.
This has been tested on a generic A20 box running a few virtual
machines hanging off a bridge with the EMAC chip as the link to the
outside world.
Cc: Stefan Roese s...@denx.de
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 30 -
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index 511f6ee..6343beb 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -268,15 +268,6 @@ static unsigned int emac_setup(struct net_device *ndev)
writel(reg_val | EMAC_TX_MODE_ABORTED_FRAME_EN,
db-membase + EMAC_TX_MODE_REG);
- /* set up RX */
- reg_val = readl(db-membase + EMAC_RX_CTL_REG);
-
- writel(reg_val | EMAC_RX_CTL_PASS_LEN_OOR_EN |
- EMAC_RX_CTL_ACCEPT_UNICAST_EN | EMAC_RX_CTL_DA_FILTER_EN |
- EMAC_RX_CTL_ACCEPT_MULTICAST_EN |
- EMAC_RX_CTL_ACCEPT_BROADCAST_EN,
- db-membase + EMAC_RX_CTL_REG);
-
/* set MAC */
/* set MAC CTL0 */
reg_val = readl(db-membase + EMAC_MAC_CTL0_REG);
@@ -309,6 +300,26 @@ static unsigned int emac_setup(struct net_device *ndev)
return 0;
}
+static void emac_set_rx_mode(struct net_device *ndev)
+{
+ struct emac_board_info *db = netdev_priv(ndev);
+ unsigned int reg_val;
+
+ /* set up RX */
+ reg_val = readl(db-membase + EMAC_RX_CTL_REG);
+
+ if (ndev-flags IFF_PROMISC)
+ reg_val |= EMAC_RX_CTL_PASS_ALL_EN;
+ else
+ reg_val = ~EMAC_RX_CTL_PASS_ALL_EN;
+
+ writel(reg_val | EMAC_RX_CTL_PASS_LEN_OOR_EN |
+ EMAC_RX_CTL_ACCEPT_UNICAST_EN | EMAC_RX_CTL_DA_FILTER_EN |
+ EMAC_RX_CTL_ACCEPT_MULTICAST_EN |
+ EMAC_RX_CTL_ACCEPT_BROADCAST_EN,
+ db-membase + EMAC_RX_CTL_REG);
+}
+
static unsigned int emac_powerup(struct net_device *ndev)
{
struct emac_board_info *db = netdev_priv(ndev);
@@ -782,6 +793,7 @@ static const struct net_device_ops emac_netdev_ops = {
.ndo_stop = emac_stop,
.ndo_start_xmit = emac_start_xmit,
.ndo_tx_timeout = emac_timeout,
+ .ndo_set_rx_mode= emac_set_rx_mode,
.ndo_do_ioctl = emac_ioctl,
.ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
--
1.8.3.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] sunxi-3.4 Audio PA and Speaker Mute Patch
Dear All;
Interra-3 home automation board audio system consist of PAM8620 amplifier,
and PH15 controls PA_Shutdown, and PH25 controls SPK_MUTE.
Thanks to gzamboni and Turl, I have been able to get sound from the speaker
outputs of Interra-3 board.
To achieve this, we need two modifications:
1) In the sys_config.fex, modify audio as follows:
[audio_para]
audio_used = 1
audio_pa_ctrl = port:PH151defaultdefault0
audio_mute_ctrl = port:PH251defaultdefault0
2) Apply below patch to sound/soc/sunxi-codec.c
--- sunxi-codec.c 2014-04-10 17:46:47.918544495 +0300
+++ sunxi-codec.c-CALISAN 2014-04-11 12:40:25.651389407 +0300
@@ -37,6 +37,7 @@
#define SCRIPT_AUDIO_OK (0)
static int has_playback, has_capture;
static int gpio_pa_shutdown = 0;
+static int gpio_mute = 0; //stul...@gmail.com-for Interra-3 Board 10.4.2014
struct clk *codec_apbclk,*codec_pll2clk,*codec_moduleclk;
static volatile unsigned int capture_dmasrc = 0;
@@ -411,7 +412,12 @@
static int codec_play_start(void)
{
if (gpio_pa_shutdown)
- gpio_write_one_pin_value(gpio_pa_shutdown, 1, audio_pa_ctrl);
+ {
+ gpio_write_one_pin_value(gpio_pa_shutdown, 0, audio_pa_ctrl);
//stul...@gmail.com-for Interra-3 Board 8.4.2014
+ //printk(static int
CODEC_PLAY_START(void)\ngpio_write_one_pin_value(gpio_pa_shutdown, 0,
\audio_pa_ctrl\);\n); //stul...@gmail.com-for Interra-3 Board 8.4.2014
+ if (gpio_mute) //stul...@gmail.com-for Interra-3 Board 10.4.2014
+ gpio_write_one_pin_value(gpio_mute, 1, audio_mute_ctrl);
//stul...@gmail.com-for Interra-3 Board 10.4.2014
+ }
//flush TX FIFO
codec_wr_control(SUNXI_DAC_FIFOC ,0x1, DAC_FIFO_FLUSH, 0x1);
//enable dac drq
@@ -423,7 +429,12 @@
{
//pa mute
if (gpio_pa_shutdown)
- gpio_write_one_pin_value(gpio_pa_shutdown, 0, audio_pa_ctrl);
+ {
+ gpio_write_one_pin_value(gpio_pa_shutdown, 1, audio_pa_ctrl);
//stul...@gmail.com-for Interra-3 Board 8.4.2014
+ //printk(static int
CODEC_PLAY_STOP(void)\ngpio_write_one_pin_value(gpio_pa_shutdown, 1,
\audio_pa_ctrl\);\n); //stul...@gmail.com-for Interra-3 Board 8.4.2014
+ if (gpio_mute) //stul...@gmail.com-for Interra-3 Board 10.4.2014
+ gpio_write_one_pin_value(gpio_mute, 0, audio_mute_ctrl);
//stul...@gmail.com-for Interra-3 Board 10.4.2014
+ }
codec_wr_control(SUNXI_DAC_ACTL, 0x1, PA_MUTE, 0x0);
mdelay(5);
//disable dac drq
@@ -439,7 +450,12 @@
{
//enable adc drq
if (gpio_pa_shutdown)
- gpio_write_one_pin_value(gpio_pa_shutdown, 1, audio_pa_ctrl);
+ {
+ gpio_write_one_pin_value(gpio_pa_shutdown, 0, audio_pa_ctrl);
//stul...@gmail.com-for Interra-3 Board 8.4.2014
+ //printk(static int
CODEC_CAPTURE_START(void)\ngpio_write_one_pin_value(gpio_pa_shutdown, 0,
\audio_pa_ctrl\);\n); //stul...@gmail.com-for Interra-3 Board 8.4.2014
+ if (gpio_mute) //stul...@gmail.com-for Interra-3 Board 10.4.2014
+ gpio_write_one_pin_value(gpio_mute, 1, audio_mute_ctrl);
//stul...@gmail.com-for Interra-3 Board 10.4.2014
+ }
codec_wr_control(SUNXI_ADC_FIFOC ,0x1, ADC_DRQ, 0x1);
return 0;
}
@@ -1442,10 +1458,16 @@
codec_wr_control(SUNXI_DAC_ACTL, 0x1, DACPAS, 0x1);
}
- if (gpio_pa_shutdown) {
+ if (gpio_pa_shutdown)
+ {
msleep(50);
- gpio_write_one_pin_value(gpio_pa_shutdown, 1, audio_pa_ctrl);
+ gpio_write_one_pin_value(gpio_pa_shutdown, 0, audio_pa_ctrl);
//stul...@gmail.com-for Interra-3 Board 8.4.2014
+ //printk(static void CODEC_RESUME_EVENTS(struct work_struct
*work)\ngpio_write_one_pin_value(gpio_pa_shutdown, 0,
\audio_pa_ctrl\);\n); //stul...@gmail.com-for Interra-3 Board 8.4.2014
+ if (gpio_mute) //stul...@gmail.com-for Interra-3 Board 10.4.2014
+ gpio_write_one_pin_value(gpio_mute, 1, audio_mute_ctrl);
//stul...@gmail.com-for Interra-3 Board 10.4.2014
}
+
+
}
static int __devinit sunxi_codec_probe(struct platform_device *pdev)
@@ -1544,11 +1566,24 @@
kfree(db);
gpio_pa_shutdown = gpio_request_ex(audio_para, audio_pa_ctrl);
- if (gpio_pa_shutdown)
- gpio_write_one_pin_value(gpio_pa_shutdown, 0, audio_pa_ctrl);
+ gpio_mute = gpio_request_ex(audio_para, audio_mute_ctrl);
//stul...@gmail.com-for Interra-3 Board 10.4.2014
+ if (gpio_pa_shutdown){
+ gpio_write_one_pin_value(gpio_pa_shutdown, 1, audio_pa_ctrl);
//stul...@gmail.com-for Interra-3 Board 8.4.2014
+ //printk(static int __DEVINIT SUNXI_CODEC_PROBE(struct platform_device
*pdev)\ngpio_write_one_pin_value(gpio_pa_shutdown, 1,
\audio_pa_ctrl\);\n); //stul...@gmail.com-for Interra-3 Board 8.4.2014
+ if (gpio_mute) //stul...@gmail.com-for Interra-3 Board 10.4.2014
+ gpio_write_one_pin_value(gpio_mute, 0, audio_mute_ctrl);
//stul...@gmail.com-for Interra-3 Board 10.4.2014
+ }
+
+
+
+
codec_init();
- if (gpio_pa_shutdown)
- gpio_write_one_pin_value(gpio_pa_shutdown, 0, audio_pa_ctrl);
+ if (gpio_pa_shutdown){
+ gpio_write_one_pin_value(gpio_pa_shutdown, 1, audio_pa_ctrl);
//stul...@gmail.com-for Interra-3 Board 8.4.2014
+ //printk(222 static int __DEVINIT SUNXI_CODEC_PROBE(struct
platform_device
Re: [linux-sunxi] mac addresses
On an ethernet, every device shoukld have a unique MAC address and least unique to that ethernet. In a perfect world, every cubieboard would have a unique MAC address assigned by the manufacturer. I was curious 1. if that wrere the case. 2. if not 1 then what do others do to get a usable MAC address. I can figure out a way myself, I'm just trying to find the best solution by asking around. Booting is not a problem. On Fri, 2014-04-11 at 09:13 +0200, Jonathan Aquilina wrote: Would booting from a live usb with ubuntu or something help at all? On Thu, Apr 10, 2014 at 11:58 PM, Brian Beattie beat...@beattie-home.netwrote: Actually what I was more curious about, is does cubieboard assign a unique MAC address (if so how can I figure it out if I wiped the original software), do you pick one at random? I have sometimes in the past taken one form an obsolete or defunct ethernet board. But I can also see just making up a locally unique MAC address. On Thu, 2014-04-10 at 23:34 +0200, Gerardo Di Iorio wrote: Hi you can define mac address in 1)script.bin file(edit script.fex and convert to script.bin) 2) u-boot param 3) from linux cmd line for info read http://linux-sunxi.org/Manual_build_howto 2014-04-10 16:26 GMT+02:00 Brian Beattie beat...@beattie-home.net: What are people doing for MAC addresses on cubieboards? -- For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken Brian Beattiebeat...@beattie-home.net -- www.brian-beattie.com LFS12947 -- 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. -- For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken Brian Beattiebeat...@beattie-home.net -- www.brian-beattie.com LFS12947 -- 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. -- Jonathan Aquilina -- For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken Brian Beattiebeat...@beattie-home.net -- www.brian-beattie.com LFS12947 -- 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 v4 1/9] mfd: AXP20x: Add mfd driver for AXP20x PMIC
On Friday 11 April 2014 11:38:05 Carlo Caione wrote:
+#define AXP20X_IRQ(_irq, _off, _mask) \
+ [AXP20X_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
+
+static const struct regmap_irq axp20x_regmap_irqs[] = {
+ AXP20X_IRQ(ACIN_OVER_V, 0, 7),
+ AXP20X_IRQ(ACIN_PLUGIN, 0, 6),
+ AXP20X_IRQ(ACIN_REMOVAL,0, 5),
+ AXP20X_IRQ(VBUS_OVER_V, 0, 4),
+ AXP20X_IRQ(VBUS_PLUGIN, 0, 3),
+ AXP20X_IRQ(VBUS_REMOVAL,0, 2),
+ AXP20X_IRQ(VBUS_V_LOW, 0, 1),
+ AXP20X_IRQ(BATT_PLUGIN, 1, 7),
+ AXP20X_IRQ(BATT_REMOVAL,1, 6),
+ AXP20X_IRQ(BATT_ENT_ACT_MODE, 1, 5),
+ AXP20X_IRQ(BATT_EXIT_ACT_MODE, 1, 4),
+ AXP20X_IRQ(CHARG, 1, 3),
+ AXP20X_IRQ(CHARG_DONE, 1, 2),
+ AXP20X_IRQ(BATT_TEMP_HIGH, 1, 1),
Why do you have to enumerate the interrupts here? Can't you just
put all the numbers into the DT nodes of the devices using them?
In general, I would say that the mfd driver should not care about
what is connected to it.
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.
Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed
Regarding memory - I'm not much of the Linux developer - more of a HW engineer, so Linux concepts are still new to me. This with memory security certainly makes sense - I've already seen that something messes up with Disp driver when I modprobe Mali drivers, pretty sure it's memory related as everything is shared as you said. Basically I can't use layers anymore if I use Mali driver, which is just insane and I think UMP and DRM have something to do with it. Regarding CSI and DISP: as I said - not much of a Linux developer so I cannot actively be involved with the Sunxi stuff. I meant more in this passive way - I've made a thread regarding CSI in which I described my fixes and findings and also this thread where I did post how I solved my issue with overlay. If you look at them, I think you will also have only swearwords, as my fixes are pretty dirty - maybe in a year or two I will be able to contribute to the actual kernel development (obviously some other SoC, as A20 will be dead by then), but I feel that now I would only introduce more problems with my dirty contributions :) It's the same with simplicity - as I'm new to all this, Allwinner's simple drivers are much more suited for me to clean them up compared to Freescale, where everything is so abstract that I needed too much time for some rather simple mods. Regarding HW - I meant that I'm rather pleasantly surprised with the A20, because i.MX6 was full of HW errata and chip revisions. Also a major weak point of i.MX6 is its IPU - it has limitations which renders the image pipeline almost useless (100Mpix / sec max for IPU for instance = no Full-HD @60 fps possible, only 30fps). i.MX6 kernel is full of workarounds for these issues and it's really bloated in some places because of this (IPU split mode for instance - SW workaround for 100 Mpix limit - terrible tearing). In contrast, once something is working on Allwinner, it just works, which I really respect. -- 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] mac addresses
On Fri, Apr 11, 2014 at 11:28:34AM +0200, Koen Kooi wrote: Op 11 apr. 2014, om 11:01 heeft Maxime Ripard maxime.rip...@free-electrons.com het volgende geschreven: Hi, On Fri, Apr 11, 2014 at 09:51:21AM +0200, Hans de Goede wrote: On 04/10/2014 04:26 PM, Brian Beattie wrote: What are people doing for MAC addresses on cubieboards? If you're running the 3.4 kernel then the MAC address gets based on the unique serial each A10 SOC has burned into the SID prom it has. So it will be unique and consistent across reboots / different distros. I still need to make some time to add similar code to u-boot, so that it will too use this as a base for the MAC. Once u-boot has code to base the MAC on this, then the upstream kernels should automatically pick up this value from u-boot. I finally took some time to work on my long-overdue eeprom framework, and the kernel should be able to retrieve these infos too in a foreseeable future. U-boot is another story though. The last time this problem came up (for am335x cpsw) the kernel folks pushed back on having the kernel read the MAC and stated that it should get passed into the DT by $bootloaders. I'm fine with either, but be warned that the kernel networking guys are touchy about this :) Ok, we'll see how it turns out then :) Thanks for the warning, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH v4 1/9] mfd: AXP20x: Add mfd driver for AXP20x PMIC
On Fri, Apr 11, 2014 at 1:25 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 11 April 2014 11:38:05 Carlo Caione wrote:
+#define AXP20X_IRQ(_irq, _off, _mask) \
+ [AXP20X_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
+
+static const struct regmap_irq axp20x_regmap_irqs[] = {
+ AXP20X_IRQ(ACIN_OVER_V, 0, 7),
+ AXP20X_IRQ(ACIN_PLUGIN, 0, 6),
+ AXP20X_IRQ(ACIN_REMOVAL,0, 5),
+ AXP20X_IRQ(VBUS_OVER_V, 0, 4),
+ AXP20X_IRQ(VBUS_PLUGIN, 0, 3),
+ AXP20X_IRQ(VBUS_REMOVAL,0, 2),
+ AXP20X_IRQ(VBUS_V_LOW, 0, 1),
+ AXP20X_IRQ(BATT_PLUGIN, 1, 7),
+ AXP20X_IRQ(BATT_REMOVAL,1, 6),
+ AXP20X_IRQ(BATT_ENT_ACT_MODE, 1, 5),
+ AXP20X_IRQ(BATT_EXIT_ACT_MODE, 1, 4),
+ AXP20X_IRQ(CHARG, 1, 3),
+ AXP20X_IRQ(CHARG_DONE, 1, 2),
+ AXP20X_IRQ(BATT_TEMP_HIGH, 1, 1),
Why do you have to enumerate the interrupts here? Can't you just
put all the numbers into the DT nodes of the devices using them?
In general, I would say that the mfd driver should not care about
what is connected to it.
I need this for the regmap irq chip (to be used in regmap_add_irq_chip()).
I'm not sure if you are suggesting to get rid of the irq chip.
br,
--
Carlo Caione
--
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 v4 1/9] mfd: AXP20x: Add mfd driver for AXP20x PMIC
On Fri, Apr 11, 2014 at 01:25:03PM +0200, Arnd Bergmann wrote: Why do you have to enumerate the interrupts here? Can't you just put all the numbers into the DT nodes of the devices using them? In general, I would say that the mfd driver should not care about what is connected to it. This then means that all the machines using the device need to define the interrupt table and have the MFD cells represented in the DT which means encoding Linux abstractions into the DT. In cases where the device is also used with ACPI or platform data that's a definite issue since they have different idioms. That applies less to PMICs tightly bound to particular SoCs but is an issue in general, not all the world is DT. There's also issues here with us changing our subsystems. Things like clocks are a bit indistinct at present, they're sort of floating between clock and other subsystems. We've also done things like invent extcon, making completely new subdevices. Keeping the data out of DT avoids problems when this happens. The balance changes a bit if there are clearly reusable IPs within the device but sadly hardware designers don't always give us that and even then sometimes we don't want to use them like that. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v4 6/9] regulator: AXP20x: Add support for regulators subsystem
On Fri, Apr 11, 2014 at 11:38:10AM +0200, Carlo Caione wrote: AXP202 and AXP209 come with two synchronous step-down DC-DCs and five LDOs. This patch introduces basic support for those regulators. Applied, thanks, but I had to resolve some trivial add/add conflicts with the Broadcom regulator driver Makefile and Kconfig additions - please remember to submit patches against current code. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
On Fri, Apr 11, 2014 at 11:38:11AM +0200, Carlo Caione wrote:
In all the DTs the min and max microvolt allowed for each regulator are
actually
the min and max voltage possible for the regulator itself. This is not safe
but
we do not have the ranges allowed for each board and the original Allwinner
driver does exactly this way.
Is there any code in their kernel which varies the supply voltages? If
there isn't then simply omitting the voltage ranges is the best option,
leaving the supplies fixed. If there is then the range it uses is a
good starting point. In general supplies will be fixed voltage on a
given board unless there is a specific reason to vary them.
+ regulators {
+ compatible = x-powers,axp20x-reg;
This compatible isn't part of the driver.
signature.asc
Description: Digital signature
Re: [linux-sunxi] Re: [PATCH v4 6/9] regulator: AXP20x: Add support for regulators subsystem
On Fri, Apr 11, 2014 at 2:23 PM, Mark Brown broo...@kernel.org wrote: On Fri, Apr 11, 2014 at 11:38:10AM +0200, Carlo Caione wrote: AXP202 and AXP209 come with two synchronous step-down DC-DCs and five LDOs. This patch introduces basic support for those regulators. Applied, thanks, but I had to resolve some trivial add/add conflicts with the Broadcom regulator driver Makefile and Kconfig additions - please remember to submit patches against current code. Sorry, I'll do next time. Thank you, -- Carlo Caione -- 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 v3 6/7] pinctrl: sunxi: add reset control support
Hi, On Thu, Apr 10, 2014 at 03:52:45PM +0200, Boris BREZILLON wrote: The A31 SoC define a reset line for the R_PIO block which needs to be deasserted. Try to retrieve a reset control and deassert if one was found. Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Thanks! -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
On Fri, Apr 11, 2014 at 03:04:32PM +0200, Carlo Caione wrote:
On Fri, Apr 11, 2014 at 2:29 PM, Mark Brown broo...@kernel.org wrote:
+ regulators {
+ compatible = x-powers,axp20x-reg;
This compatible isn't part of the driver.
Yes I know. The problem here is that in v4 I had to fill in the field
.of_compatible of the mfd_cell with x-powers,axp20x-reg. This
because the regulator_dev_lookup() checks for dev-of_node when
looking for the supply so I needed the compatible string in the DT to
have the dev-of_node filled in by mfd_add_device().
What do you suggest? Modify the regulator driver?
You're looking for regulator_bulk_register_supply_alias() in the MFD
driver (via parent_supplies in the MFD cell probably).
signature.asc
Description: Digital signature
[linux-sunxi] Various Hardware acceleration question
Hi, I would like to know if, for an Olimex A20, there is some specific hardware acceleration : - jpeg decoding acceleration - hash acceleration (such as sha1 or md5) And if yes, does it need some manual configuration or specific compilation procedure (with kernel or the programs that I want to be accelerated) ? Best regards, -- 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.
