Re: [linux-sunxi] Re: Build sunxi-next for A20
here http://en.wikipedia.org/wiki/Linux_kernel i saw that latest stable longterm kernels are 3.10 (30 June 2013) and 3.12 (3 November 2013) so, as for 3.2 and 3.4, i suppose that this will be next stable sunxi kernels, i would like to know an estimate release date -- 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 1/5] i2c: mv64xxx: Add reset deassert call
On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote: The Allwinner A31 SoC using that IP has a reset controller maintaining it reset unless told otherwise. Add some optional reset support to the driver. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Reviewed-by: Gregory CLEMENT gregory.clem...@free-electrons.com Tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com This appears to be causing some build errors in Olof's next builder for many of the ARM platforms which make use of this: drivers/i2c/busses/i2c-mv64xxx.c:924: undefined reference to `reset_control_assert' drivers/i2c/busses/i2c-mv64xxx.c:904: undefined reference to `reset_control_assert' drivers/i2c/busses/i2c-mv64xxx.c:771: undefined reference to `devm_reset_control_get' drivers/i2c/busses/i2c-mv64xxx.c:778: undefined reference to `reset_control_deassert' -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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 1/5] i2c: mv64xxx: Add reset deassert call
Hi Russell, On Fri, Mar 07, 2014 at 09:52:23AM +, Russell King - ARM Linux wrote: On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote: The Allwinner A31 SoC using that IP has a reset controller maintaining it reset unless told otherwise. Add some optional reset support to the driver. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Reviewed-by: Gregory CLEMENT gregory.clem...@free-electrons.com Tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com This appears to be causing some build errors in Olof's next builder for many of the ARM platforms which make use of this: drivers/i2c/busses/i2c-mv64xxx.c:924: undefined reference to `reset_control_assert' drivers/i2c/busses/i2c-mv64xxx.c:904: undefined reference to `reset_control_assert' drivers/i2c/busses/i2c-mv64xxx.c:771: undefined reference to `devm_reset_control_get' drivers/i2c/busses/i2c-mv64xxx.c:778: undefined reference to `reset_control_deassert' The reset framework doesn't define its functions when its not selected, and somehow I think it was not here. What's odd is that there is an explicit select on RESET_CONTROLLER in the Kconfig. Maybe it's the circular dependency issue that has been reported that cause this and Wolfram sent a patch for: http://patchwork.ozlabs.org/patch/327573/ Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call
Since RESET_CONTROLLER is not required for those platforms, it really should be optional - and I think the real fix is for the reset controller support to provide stub functions. I agree; and I assumed it already does. Will resend a patch posted earlier [1] to fix the issue. And still debugging why my build-tests didn't get it :( [1] https://lkml.org/lkml/2013/8/9/442 signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call
On Fri, Mar 7, 2014 at 6:34 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Mar 07, 2014 at 11:07:51AM +0100, Maxime Ripard wrote: Hi Russell, On Fri, Mar 07, 2014 at 09:52:23AM +, Russell King - ARM Linux wrote: On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote: The Allwinner A31 SoC using that IP has a reset controller maintaining it reset unless told otherwise. Add some optional reset support to the driver. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Reviewed-by: Gregory CLEMENT gregory.clem...@free-electrons.com Tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com This appears to be causing some build errors in Olof's next builder for many of the ARM platforms which make use of this: drivers/i2c/busses/i2c-mv64xxx.c:924: undefined reference to `reset_control_assert' drivers/i2c/busses/i2c-mv64xxx.c:904: undefined reference to `reset_control_assert' drivers/i2c/busses/i2c-mv64xxx.c:771: undefined reference to `devm_reset_control_get' drivers/i2c/busses/i2c-mv64xxx.c:778: undefined reference to `reset_control_deassert' The reset framework doesn't define its functions when its not selected, and somehow I think it was not here. What's odd is that there is an explicit select on RESET_CONTROLLER in the Kconfig. Maybe it's the circular dependency issue that has been reported that cause this and Wolfram sent a patch for: http://patchwork.ozlabs.org/patch/327573/ If that patch has been taken, then yes, it will have caused the above - because now we have Dove and Kirkwood platforms trying to build this driver without RESET_CONTROLLER being set. The problem with depending on RESET_CONTROLLER is that then these platforms end up without their I2C controller - because there's nothing which enables RESET_CONTROLLER in their configuration. Since RESET_CONTROLLER is not required for those platforms, it really should be optional - and I think the real fix is for the reset controller support to provide stub functions. Philipp Zabel suggested that adding a _optional variant that provides stubs and doesn't depend on RESET_CONTROLLER is probably better. This keeps the compile time checks for drivers requiring it. See: https://lkml.org/lkml/2014/1/10/220 I ended up dropping my patch though. Cheers, ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call
Since RESET_CONTROLLER is not required for those platforms, it really should be optional - and I think the real fix is for the reset controller support to provide stub functions. Philipp Zabel suggested that adding a _optional variant that provides stubs and doesn't depend on RESET_CONTROLLER is probably better. This keeps the compile time checks for drivers requiring it. See: https://lkml.org/lkml/2014/1/10/220 I ended up dropping my patch though. Thanks for the pointer. Well, looks like I need to revert the offending i2c patches then until this issue is fixed? We can't have RESET_CONTROLLER (circular dependency) and we can't skip it (build failures). signature.asc Description: Digital signature
[linux-sunxi] Re: Unable to play 720p video in Ubuntu
I am glad you solved. I just point you to a place that could be easier to find answers. On Thursday, March 6, 2014 11:15:18 PM UTC-6, Puneet B wrote: Dude, I just asking mpv --vo=vdpau --hwdec=vdpau --hwdec-codecs=all [filename] *(export VDPAU_DRIVER=sunxi)*Is it possible to assign these things in config file. so we can play videos from gui. Regards Punith -- 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 v3 1/5] i2c: mv64xxx: Add reset deassert call
Hi, On Fri, Mar 07, 2014 at 12:18:58PM +0100, Wolfram Sang wrote: Since RESET_CONTROLLER is not required for those platforms, it really should be optional - and I think the real fix is for the reset controller support to provide stub functions. Philipp Zabel suggested that adding a _optional variant that provides stubs and doesn't depend on RESET_CONTROLLER is probably better. This keeps the compile time checks for drivers requiring it. See: https://lkml.org/lkml/2014/1/10/220 I ended up dropping my patch though. Thanks for the pointer. Well, looks like I need to revert the offending i2c patches then until this issue is fixed? We can't have RESET_CONTROLLER (circular dependency) and we can't skip it (build failures). I just sent a fix in reply to your mail that should fix the issue without having to revert the patches. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Looking for a 3rd book reviewer!
Thanks for the people responding! I am set for now, no more queries on this :) Olliver On 03/07/14 10:55, Olliver Schinagl wrote: Hey List, I have tried poking in the IRC channel for a technical reviewer for my up coming book. Two nice gents have agreed to free some of their time to review my book, follow the tutorials etc. However a third reviewer is still needed and so I decided to write to the Mailing list to find a third person. What we are after is a person who is literate in reading the English language, as the book will obviously be written in English. You don't have to be able to write perfect English, as I will have to do that ;) Also the book is written in LibreOffice and uses .odt files, so those will have to be used ideally, but shouldn't be a problem to most of the people here. Finally having an OLinuXino or a cubieboard is kinda needed, as otherwise following the examples will be really hard ;) A mele or what not should do the trick as well of course, so bonus points for trying it on different hardware! The book is aimed at a beginner and well focuses more about general Linux usage mostly, since while it is ARM, it's still 'just linux' and there's really nothing that special ;) So if your interested as a reviewer, send me a note (on or off list) and I'll forward your contact details to Packt Publishing http://packtpub.com Thanks, Olliver -- 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] Looking for a 3rd book reviewer!
oh nice! 2014-03-07 21:10 GMT+06:00 Olliver Schinagl oliver+l...@schinagl.nl: Thanks for the people responding! I am set for now, no more queries on this :) Olliver On 03/07/14 10:55, Olliver Schinagl wrote: Hey List, I have tried poking in the IRC channel for a technical reviewer for my up coming book. Two nice gents have agreed to free some of their time to review my book, follow the tutorials etc. However a third reviewer is still needed and so I decided to write to the Mailing list to find a third person. What we are after is a person who is literate in reading the English language, as the book will obviously be written in English. You don't have to be able to write perfect English, as I will have to do that ;) Also the book is written in LibreOffice and uses .odt files, so those will have to be used ideally, but shouldn't be a problem to most of the people here. Finally having an OLinuXino or a cubieboard is kinda needed, as otherwise following the examples will be really hard ;) A mele or what not should do the trick as well of course, so bonus points for trying it on different hardware! The book is aimed at a beginner and well focuses more about general Linux usage mostly, since while it is ARM, it's still 'just linux' and there's really nothing that special ;) So if your interested as a reviewer, send me a note (on or off list) and I'll forward your contact details to Packt Publishing http://packtpub.com Thanks, Olliver -- 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. -- 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 v3 0/4] uboot sata support for sunxi platform
Hi Ian .. You would have a repository with these updates where I could play with git, compile and test my cubieboard2 using kernel 3.14.rc5 I'm waiting! to test your boot! thank you -- 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 3/7] ARM: dts: cubieboard2: Add AXP209 support
On Sat, Mar 01, 2014 at 05:45:48PM +0100, Carlo Caione wrote:
AXP209 is the PMU used by Cubieboard2. This patch enable the core
support in the dts file.
This patch requires: ARM: sun7i/sun6i: irqchip: Add irqchip driver for
NMI controller
That shouldn't be in the commit log itself.
Signed-off-by: Carlo Caione ca...@caione.org
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 5c51cb8..234b14b 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -53,6 +53,20 @@
pinctrl-names = default;
pinctrl-0 = i2c0_pins_a;
status = okay;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ axp: axp20x@34 {
+ reg = 0x34;
+ interrupt-parent = nmi_intc;
+ interrupts = 0 8;
+
+ axp,system-power-controller;
+
+ compatible = x-powers,axp209;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ };
};
i2c1: i2c@01c2b000 {
--
1.8.3.2
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH 1/7] mfd: AXP20x: Add mfd driver for AXP20x PMIC
Hi,
On Sat, Mar 01, 2014 at 05:45:46PM +0100, Carlo Caione wrote:
This patch introduces the preliminary support for PMICs X-Powers AXP202
and AXP209. The AXP209 and AXP202 are the PMUs (Power Management Unit)
used by A10, A13 and A20 SoCs and developed by X-Powers, a sister company
of Allwinner.
The core enables support for two subsystems:
- PEK (Power Enable Key)
- Regulators
Signed-off-by: Carlo Caione ca...@caione.org
---
arch/arm/configs/sunxi_defconfig | 1 +
drivers/mfd/Kconfig | 12 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/axp20x.c | 250
+++
include/linux/mfd/axp20x.h | 180
5 files changed, 444 insertions(+)
create mode 100644 drivers/mfd/axp20x.c
create mode 100644 include/linux/mfd/axp20x.h
diff --git a/arch/arm/configs/sunxi_defconfig
b/arch/arm/configs/sunxi_defconfig
index 3e2259b..f8aa7e6 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -52,6 +52,7 @@ CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=y
+CONFIG_MFD_AXP20X=y
# CONFIG_USB_SUPPORT is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
Please provide a separate patch for both sunxi_defconfig and
multi_v7_defconfig.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index dd67158..33d38c4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -59,6 +59,18 @@ config MFD_AAT2870_CORE
additional drivers must be enabled in order to use the
functionality of the device.
+config MFD_AXP20X
+ bool X-Powers AXP20X
+ select MFD_CORE
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ depends on I2C=y
+ help
+ If you say Y here you get support for the AXP20X.
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the
+ functionality of the device.
+
config MFD_CROS_EC
tristate ChromeOS Embedded Controller
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8a28dc9..371020e 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-irq.o
obj-$(CONFIG_PMIC_DA9052)+= da9052-core.o
obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
+obj-$(CONFIG_MFD_AXP20X) += axp20x.o
obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
new file mode 100644
index 000..92e5b0f
--- /dev/null
+++ b/drivers/mfd/axp20x.c
@@ -0,0 +1,250 @@
+/*
+ * axp20x.c - mfd core driver for the X-Powers AXP202 and AXP209
+ *
+ * Author: Carlo Caione ca...@caione.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/regmap.h
+#include linux/slab.h
+#include linux/regulator/consumer.h
+#include linux/mfd/axp20x.h
+#include linux/mfd/core.h
+#include linux/of_device.h
+#include linux/of_irq.h
+
+#define AXP20X_OFF 0x80
+
+static const struct regmap_range axp20x_writeable_ranges[] = {
+ regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
+ regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
+};
+
+static const struct regmap_range axp20x_volatile_ranges[] = {
+ regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
+};
+
+static const struct regmap_access_table axp20x_writeable_table = {
+ .yes_ranges = axp20x_writeable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(axp20x_writeable_ranges),
+};
+
+static const struct regmap_access_table axp20x_volatile_table = {
+ .yes_ranges = axp20x_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(axp20x_volatile_ranges),
+};
+
+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,
+ },
+};
+
+static const struct regmap_config axp20x_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .wr_table = axp20x_writeable_table,
+ .volatile_table = axp20x_volatile_table,
+ .max_register = AXP20X_FG_RES,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+#define AXP20X_IRQ(_irq, _off, _mask) \
+ [AXP20X_IRQ_##_irq] = { .reg_offset =
[linux-sunxi] Re: [PATCH 4/7] input: misc: Add driver for AXP20x Power Enable Key
On Sat, Mar 01, 2014 at 05:45:49PM +0100, Carlo Caione wrote:
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
---
arch/arm/configs/sunxi_defconfig | 2 +
Again, please provide a separate patch for both sunxi_defconfig and
multi_v7_defconfig.
(This can be the same patches than the one enabling the MFD though)
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/axp20x-pek.c | 265
+++
4 files changed, 279 insertions(+)
create mode 100644 drivers/input/misc/axp20x-pek.c
diff --git a/arch/arm/configs/sunxi_defconfig
b/arch/arm/configs/sunxi_defconfig
index f8aa7e6..d59c826 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -39,6 +39,8 @@ CONFIG_SUN4I_EMAC=y
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_WLAN is not set
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=8
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 5f4967d..c9438ac 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -384,6 +384,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 0ebfb6d..41d5403 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -49,6 +49,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..799275d
--- /dev/null
+++ b/drivers/input/misc/axp20x-pek.c
@@ -0,0 +1,265 @@
+/*
+ * 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)
+
+static const char const *startup_time[] = { 128mS, 3S , 1S, 2S };
+static const char const *shutdown_time[] = { 4S, 6S , 8S, 10S };
I guess these are seconds. If so, a lowercase s in needed.
+
+struct axp20x_pek {
+ struct axp20x_dev *axp20x;
+ struct input_dev *input;
+ int irq_dbr;
+ int irq_dbf;
+};
+
+struct axp20x_pek_ext_attr {
+ const char const **str;
+ unsigned int mask;
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_startup_ext_attr = {
+ .str= startup_time,
+ .mask = AXP20X_PEK_STARTUP_MASK,
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_shutdown_ext_attr = {
+ .str= 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;
+}
+
+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 =
[linux-sunxi] Re: [PATCH 6/7] regulator: AXP20x: Add support for regulators subsystem
On Sat, Mar 01, 2014 at 05:45:51PM +0100, Carlo Caione wrote:
+static struct platform_driver axp20x_regulator_driver = {
+ .probe = axp20x_regulator_probe,
+ .remove = axp20x_regulator_remove,
+ .driver = {
+ .name = axp20x-regulator,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init axp20x_regulator_init(void)
+{
+ return platform_driver_register(axp20x_regulator_driver);
+}
+
+subsys_initcall(axp20x_regulator_init);
Hmmm, really?
I thought the AXP was only connected through I2C? How is that a
platform device then?
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH 2/7] mfd: AXP20x: Add bindings documentation
On Sat, Mar 01, 2014 at 05:45:47PM +0100, Carlo Caione wrote:
Bindings documentation for the AXP20x driver. In this file also two
sub-nodes (PEK and regulators) are documented.
Signed-off-by: Carlo Caione ca...@caione.org
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 93
1 file changed, 93 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..ae3e3c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -0,0 +1,93 @@
+* axp20x device tree bindings
+
+The axp20x family current members :-
+axp202 (X-Powers)
+axp209 (X-Powers)
+
+Required properties:
+- compatible : Should be x-powers,axp202 or
x-powers,axp209
+- interrupt-controller : axp20x has its own internal IRQs
+- #interrupt-cells : Should be set to 1
+- interrupt-parent : The parent interrupt controller
+- interrupts : Interrupt specifiers for interrupt
sources
+- reg: The I2C slave address for the AXP chip
+- axp,system-power-controller: Telling whether or not this pmic is
+ controlling the system power
+
+Sub-nodes:
+* regulators : Contain the regulator nodes. 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:
+
+ - dcdc-freq : defines the work frequency of DC-DC in KHz
+ (range: 750-1875)
+ - dcdc-workmode : 1 for PWM mode, 0 for AUTO mode
You don't seem to always set this. You should mention that it is
optional, and which default value it has.
+
+* axp20x-pek : Power Enable Key
+ - compatible: should be x-powers,axp20x-pek
Why is this needed for?
Plus, please don't use any generic, or pattern matching compatibles,
but rather precise ones, so that if it is needed, we can add any quirk
we want.
+Example:
+
+axp: axp20x@34 {
+ reg = 0x34;
+ interrupt-parent = nmi_intc;
+ interrupts = 0 8;
+
+ axp,system-power-controller;
+
+ compatible = x-powers,axp209;
+ interrupt-controller;
+ #interrupt-cells = 1;
+
+ axp20x-pek {
+ compatible = x-powers,axp20x-pek;
+ };
+
+ regulators {
+ dcdc-freq = 8;
+
+ axp_dcdc2: dcdc2 {
+ regulator-min-microvolt = 70;
+ regulator-max-microvolt = 2275000;
+ dcdc-workmode = 0;
+ regulator-always-on;
+ };
+
+ axp_dcdc3: dcdc3 {
+ regulator-min-microvolt = 70;
+ regulator-max-microvolt = 350;
+ dcdc-workmode = 0;
+ regulator-always-on;
+ };
+
+ axp_ldo1: ldo1 {
+ regulator-min-microvolt = 130;
+ regulator-max-microvolt = 130;
+ };
+
+ axp_ldo2: ldo2 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ };
+
+ axp_ldo3: ldo3 {
+ regulator-min-microvolt = 70;
+ regulator-max-microvolt = 350;
+ };
+
+ axp_ldo4: ldo4 {
+ regulator-min-microvolt = 125;
+ regulator-max-microvolt = 330;
+ };
+
+ axp_ldo5: ldo5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ };
+ };
+};
+
--
1.8.3.2
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [linux-sunxi] Re: How to decide NAND boot address?
Hi, I finally got the serial port working on my board, just a side note, we need a pull up resistor at the Rx pin, and I am using UART1 with SD card approach, anyone struggles with serial port, here is the thread that helped me: https://www.olimex.com/forum/index.php?topic=1788.0 All goes well with the SD u-boot and I can stop at u-boot prompt and play with it, booting up as usual too by typing boot. However when I set the NAND stuff up with lichee-dev u-boot built out of sun5i_a13, there is no serial output at all upon boot and stuck at logo, which indicates something is wrong with the u-boot image and it didn't run as expected. I also tried just use the stock android u-boot, some posts say we can stop android u-boot when booting up, I didn't see that happen either. Any ideas how to proceed from here would be greatly appreciated. Thanks in advance, -Hunter On Wednesday, March 5, 2014 10:13:45 PM UTC-6, hunter hu wrote: Thanks Pat, I have used the correct syntax, but still, stuck at the SUNXI logo; at this moment I have a few questions: 1 my cpu is A13, your u-boot is for A20, I would think that is not working for me? 2 I have been using lichee-dev, sun5i_a13 board, trying to modify the configurations as shown before; when I was adding my board to the u-boot-sunxi, I had to add a dram_myboard.c to configure the DRAM by following the sunxi wiki instructions, I tried to do with and without the DRAM stuff, the same, stuck at the logo, I believe I have to get the serial port working first. Thank you very much for all help so far, I greatly appreciated. -Hunter On Wednesday, March 5, 2014 9:35:06 PM UTC-6, Patrick Wood wrote: fatload nand 0 kernel_address kernel_file Note that my u-boot is based on a heavily-modified version of the one used by android. On Wednesday, March 5, 2014 10:10:03 PM UTC-5, hunter hu wrote: Hi Pat, I was not be able to get serial port access yet, work in progress. Regarding the syntax, what are the correct ones? thanks, -Hunter On Wednesday, March 5, 2014 8:51:22 PM UTC-6, Patrick Wood wrote: That's not the right syntax for file access. Don't you have a serial port you can get boot logs from? -- 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 v3 0/4] uboot sata support for sunxi platform
On Fri, 2014-03-07 at 08:44 -0800, Ezaul Zillmer wrote: You would have a repository with these updates where I could play with git, compile and test my cubieboard2 using kernel 3.14.rc5 git://gitorious.org/ijc/u-boot.git ahci-sunxi It is based on jwrdegoede/sunxi-next. 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.
