Re: [linux-sunxi] [PATCH v3 0/4] uboot sata support for sunxi platform

2014-03-07 Thread Ian Campbell 
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.

Re: [linux-sunxi] Re: How to decide NAND boot address?

2014-03-07 Thread hunter hu 
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.

[linux-sunxi] Re: [PATCH 2/7] mfd: AXP20x: Add bindings documentation

2014-03-07 Thread Maxime Ripard 
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 
> ---
>  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

[linux-sunxi] Re: [PATCH 6/7] regulator: AXP20x: Add support for regulators subsystem

2014-03-07 Thread Maxime Ripard 
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 4/7] input: misc: Add driver for AXP20x Power Enable Key

2014-03-07 Thread Maxime Ripard 
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 
> ---
>  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 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#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 = get_axp_ext_attr(attr);
> + unsigned int val;
>

[linux-sunxi] Re: [PATCH 1/7] mfd: AXP20x: Add mfd driver for AXP20x PMIC

2014-03-07 Thread Maxime Ripard 
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 
> ---
>  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 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#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 = (_off), .mask = BIT(_mask) }
> +
> +static const struct regmap_irq axp20x_regmap

[linux-sunxi] Re: [PATCH 3/7] ARM: dts: cubieboard2: Add AXP209 support

2014-03-07 Thread Maxime Ripard 
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 
> ---
>  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

Re: [linux-sunxi] [PATCH v3 0/4] uboot sata support for sunxi platform

2014-03-07 Thread Ezaul Zillmer 
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.

Re: [linux-sunxi] Looking for a 3rd book reviewer!

2014-03-07 Thread alex allss 
oh nice!


2014-03-07 21:10 GMT+06:00 Olliver Schinagl :

> 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] Looking for a 3rd book reviewer!

2014-03-07 Thread Olliver Schinagl 

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] Re: Unable to play 720p video in Ubuntu

2014-03-07 Thread Olliver Schinagl 

On 03/07/14 06:15, 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.

yes, but you'd still use the mplayer/mpv command line.

For my presentation at FOSDEM (did you watch it? :p) I used mplayer2 I 
think, and it used /etc/mplayer.conf or something along the lines.


But this absolutely is something for a different place to solve. That 
said, tab completion should solve it mostly for you ;)


Olliver



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.


--
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] Looking for a 3rd book reviewer!

2014-03-07 Thread Olliver Schinagl 

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] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Maxime Ripard 
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

[linux-sunxi] Re: Unable to play 720p video in Ubuntu

2014-03-07 Thread Rosimildo DaSilva 
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

2014-03-07 Thread Wolfram Sang 

> > 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

Re: [linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Chen-Yu Tsai 
On Fri, Mar 7, 2014 at 6:34 PM, Russell King - ARM Linux
 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 
>> > > Reviewed-by: Gregory CLEMENT 
>> > > Tested-by: Gregory CLEMENT 
>> >
>> > 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.

[linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Wolfram Sang 

> 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

[linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Russell King - ARM Linux 
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 
> > > Reviewed-by: Gregory CLEMENT 
> > > Tested-by: Gregory CLEMENT 
> > 
> > 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.

-- 
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 2/5] i2c: mv64xxx: Add support for the Allwinner A31 I2C driver

2014-03-07 Thread Maxime Ripard 
Hi Wolfram,

On Wed, Mar 05, 2014 at 05:34:30PM +0100, Wolfram Sang wrote:
> On Tue, Mar 04, 2014 at 05:28:38PM +0100, Maxime Ripard wrote:
> > The Allwinner A31 I2C controller is almost identical to the one used in the
> > other Allwinner SoCs, except for the fact that it needs to clear the 
> > interrupt
> > by setting the INT_FLAGS bit in the control register, instead of clearing 
> > it.
> > 
> > Signed-off-by: Maxime Ripard 
> > Reviewed-by: Gregory CLEMENT 
> > Tested-by: Gregory CLEMENT 
> 
> Applied to for-next, thanks!
> 
> Still...
> 
> > +   if (of_device_is_compatible(np, "allwinner,sun6i-a31-i2c"))
> > +   drv_data->irq_clear_inverted = true;
> 
> ... next time an errata is needed, I think it makes sense to refactor all
> these checks into one struct which can be used as match->data directly.

Yep, it makes sense. Thanks!

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

2014-03-07 Thread Maxime Ripard 
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 
> > Reviewed-by: Gregory CLEMENT 
> > Tested-by: Gregory CLEMENT 
> 
> 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

2014-03-07 Thread Russell King - ARM Linux 
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 
> Reviewed-by: Gregory CLEMENT 
> Tested-by: Gregory CLEMENT 

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] Is OLinuXino A13 Micro support broken in sunxi-3.4?

2014-03-07 Thread Daniel Mosquera 
Hi,

I've been trying to compile the last 
https://github.com/linux-sunxi/linux-sunxi sunxi-3.4 version (3.4.79) and 
I found that with sun5i_defconfig OLinuXino A13 Micro support is broken.
*A13 Micro does not use any AXP chip*, so it hangs when booting a default 
sun5i_deficonfig compiled kernel
when it tries to load AXP20 driver.

If I try to disable AXP driver then I get error messages then I need to 
disable Sunxi USB 2.0 Sunxi Dual Role 
Controller support in order to compile uImage, but then it throws errors 
trying to compile some USB Wifi Modules
throw error compiling.

Please can anybody help me?


-- 
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: Build sunxi-next for A20

2014-03-07 Thread hmandevteam 
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.