[linux-sunxi] Re: [PATCH 2/6] ARM: dts: sun7i: Enable USB DRC on Bananapi

2015-09-29 Thread Maxime Ripard 
On Tue, Sep 22, 2015 at 03:36:01PM +0200, Hans de Goede wrote:
> Enable the otg/drc usb controller on the Bananapi.
> 
> Signed-off-by: Hans de Goede 

Applied all the other patches but this one.

Since we dropped the patch adding the regulators support on the
Bananapi until we figure out why the board crash, it doesn't compile
anymore.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [linux-sunxi] Re: [PATCH 2/6] ARM: dts: sun7i: Enable USB DRC on Bananapi

2015-09-29 Thread Hans de Goede 

Hi,

On 29-09-15 10:04, Maxime Ripard wrote:

On Tue, Sep 22, 2015 at 03:36:01PM +0200, Hans de Goede wrote:

Enable the otg/drc usb controller on the Bananapi.

Signed-off-by: Hans de Goede 


Applied all the other patches but this one.


Thanks, seems you did not push this to your git.kernel.org repo though ?


Since we dropped the patch adding the regulators support on the
Bananapi until we figure out why the board crash, it doesn't compile
anymore.


How about me doing a v2 of the regulators patch which removes the

 {
cpu-supply = <_dcdc2>;
};

So that we do not get cpu voltage scaling, then the regulator
changes should be a NOP, everything should just keep the u-boot
set voltages, and we can enable oth support.

And then when we've figured out a safe way to enable cpu voltage
scaling we can do so with a follow up patch ?

Is that a plan ? If so say yes and I'll do a v2 of these patches :)

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v3 2/5] clk: sunxi: Add a driver for the PLL2

2015-09-29 Thread Maxime Ripard 
The PLL2 on the A10 and later SoCs is the clock used for all the audio
related operations.

This clock has a somewhat complex output tree, with three outputs (2X, 4X
and 8X) with a fixed divider from the base clock, and an output (1X) with a
post divider.

However, we can simplify things since the 1X divider can be fixed, and we
end up by having a base clock not exposed to any device (or at least
directly, since the 4X output doesn't have any divider), and 4 fixed
divider clocks that will be exposed.

This clock seems to have been introduced, at least in this form, in the
revision B of the A10, but we don't have any information on the clock used
on the revision A.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi/Makefile |   1 +
 drivers/clk/sunxi/clk-a10-pll2.c   | 188 +
 include/dt-bindings/clock/sun4i-a10-pll2.h |  53 
 3 files changed, 242 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-a10-pll2.c
 create mode 100644 include/dt-bindings/clock/sun4i-a10-pll2.h

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index f5a35b82cc1a..c658a18ba7cb 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -4,6 +4,7 @@
 
 obj-y += clk-sunxi.o clk-factors.o
 obj-y += clk-a10-hosc.o
+obj-y += clk-a10-pll2.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
diff --git a/drivers/clk/sunxi/clk-a10-pll2.c b/drivers/clk/sunxi/clk-a10-pll2.c
new file mode 100644
index ..b877cc6c3622
--- /dev/null
+++ b/drivers/clk/sunxi/clk-a10-pll2.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright 2013 Emilio López
+ * Emilio López 
+ *
+ * Copyright 2015 Maxime Ripard
+ * Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 
+
+#define SUN4I_PLL2_ENABLE  31
+
+#define SUN4I_PLL2_PRE_DIV_SHIFT   0
+#define SUN4I_PLL2_PRE_DIV_WIDTH   5
+#define SUN4I_PLL2_PRE_DIV_MASK
GENMASK(SUN4I_PLL2_PRE_DIV_WIDTH, 0)
+
+#define SUN4I_PLL2_N_SHIFT 8
+#define SUN4I_PLL2_N_WIDTH 7
+#define SUN4I_PLL2_N_MASK  GENMASK(SUN4I_PLL2_N_WIDTH, 0)
+
+#define SUN4I_PLL2_POST_DIV_SHIFT  26
+#define SUN4I_PLL2_POST_DIV_WIDTH  4
+#define SUN4I_PLL2_POST_DIV_MASK   GENMASK(SUN4I_PLL2_POST_DIV_WIDTH, 0)
+
+#define SUN4I_PLL2_POST_DIV_VALUE  4
+
+#define SUN4I_PLL2_OUTPUTS 4
+
+static DEFINE_SPINLOCK(sun4i_a10_pll2_lock);
+
+static void __init sun4i_pll2_setup(struct device_node *node)
+{
+   const char *clk_name = node->name, *parent;
+   struct clk **clks, *base_clk, *prediv_clk;
+   struct clk_onecell_data *clk_data;
+   struct clk_multiplier *mult;
+   struct clk_gate *gate;
+   void __iomem *reg;
+   u32 val;
+
+   reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+   if (IS_ERR(reg))
+   return;
+
+   clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
+   if (!clk_data)
+   goto err_unmap;
+
+   clks = kcalloc(SUN4I_PLL2_OUTPUTS, sizeof(struct clk *), GFP_KERNEL);
+   if (!clks)
+   goto err_free_data;
+
+   parent = of_clk_get_parent_name(node, 0);
+   prediv_clk = clk_register_divider(NULL, "pll2-prediv",
+ parent, 0, reg,
+ SUN4I_PLL2_PRE_DIV_SHIFT,
+ SUN4I_PLL2_PRE_DIV_WIDTH,
+ CLK_DIVIDER_ONE_BASED |
+ CLK_DIVIDER_ALLOW_ZERO,
+ _a10_pll2_lock);
+   if (!prediv_clk) {
+   pr_err("Couldn't register the prediv clock\n");
+   goto err_free_array;
+   }
+
+   /* Setup the gate part of the PLL2 */
+   gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+   if (!gate)
+   goto err_unregister_prediv;
+
+   gate->reg = reg;
+   gate->bit_idx = SUN4I_PLL2_ENABLE;
+   gate->lock = _a10_pll2_lock;
+
+   /* Setup the multiplier part of the PLL2 */
+   mult = kzalloc(sizeof(struct clk_multiplier), GFP_KERNEL);
+   if (!mult)
+   goto err_free_gate;
+
+   mult->reg = reg;
+   mult->shift = SUN4I_PLL2_N_SHIFT;
+   mult->width = 7;
+   mult->flags =

[linux-sunxi] [PATCH v3 1/5] clk: Add a basic multiplier clock

2015-09-29 Thread Maxime Ripard 
Some clocks are using a multiplier component, however, unlike their mux,
gate or divider counterpart, these factors don't have a basic clock
implementation.

This leads to code duplication across platforms that want to use that kind
of clocks, and the impossibility to use the composite clocks with such a
clock without defining your own rate operations.

Create such a driver in order to remove these issues, and hopefully factor
the implementations, reducing code size across platforms and consolidating
the various implementations.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/Makefile |   1 +
 drivers/clk/clk-multiplier.c | 176 +++
 include/linux/clk-provider.h |  42 +++
 3 files changed, 219 insertions(+)
 create mode 100644 drivers/clk/clk-multiplier.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d08b3e5985be..0b2101039508 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-divider.o
 obj-$(CONFIG_COMMON_CLK)   += clk-fixed-factor.o
 obj-$(CONFIG_COMMON_CLK)   += clk-fixed-rate.o
 obj-$(CONFIG_COMMON_CLK)   += clk-gate.o
+obj-$(CONFIG_COMMON_CLK)   += clk-multiplier.o
 obj-$(CONFIG_COMMON_CLK)   += clk-mux.o
 obj-$(CONFIG_COMMON_CLK)   += clk-composite.o
 obj-$(CONFIG_COMMON_CLK)   += clk-fractional-divider.o
diff --git a/drivers/clk/clk-multiplier.c b/drivers/clk/clk-multiplier.c
new file mode 100644
index ..61097e365d55
--- /dev/null
+++ b/drivers/clk/clk-multiplier.c
@@ -0,0 +1,176 @@
+/*
+ * Copyright (C) 2015 Maxime Ripard 
+ *
+ * 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 
+
+#define to_clk_multiplier(_hw) container_of(_hw, struct clk_multiplier, hw)
+
+static unsigned long __get_mult(struct clk_multiplier *mult,
+   unsigned long rate,
+   unsigned long parent_rate)
+{
+   if (mult->flags & CLK_MULTIPLIER_ROUND_CLOSEST)
+   return DIV_ROUND_CLOSEST(rate, parent_rate);
+
+   return rate / parent_rate;
+}
+
+static unsigned long clk_multiplier_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct clk_multiplier *mult = to_clk_multiplier(hw);
+   unsigned long val;
+   
+   val = clk_readl(mult->reg) >> mult->shift;
+   val &= GENMASK(mult->width, 0);
+
+   if (!val && mult->flags & CLK_MULTIPLIER_ZERO_BYPASS)
+   val = 1;
+   
+   return parent_rate * val;
+}
+
+static bool __is_best_rate(unsigned long rate, unsigned long new,
+  unsigned long best, unsigned long flags)
+{
+   if (flags & CLK_MULTIPLIER_ROUND_CLOSEST)
+   return abs(rate - new) < abs(rate - best);
+
+   return new >= rate && new < best;
+}
+
+static unsigned long __bestmult(struct clk_hw *hw, unsigned long rate,
+   unsigned long *best_parent_rate,
+   u8 width, unsigned long flags)
+{
+   unsigned long orig_parent_rate = *best_parent_rate;
+   unsigned long parent_rate, current_rate, best_rate = ~0;
+   unsigned int i, bestmult = 0;
+
+   if (!(__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT))
+   return rate / *best_parent_rate;
+
+   for (i = 1; i < ((1 << width) - 1); i++) {
+   if (rate * i == orig_parent_rate) {
+   /*
+* This is the best case for us if we have a
+* perfect match without changing the parent
+* rate.
+*/
+   *best_parent_rate = orig_parent_rate;
+   return i;
+   }
+
+   parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw),
+   rate / i);
+   current_rate = parent_rate * i;
+
+   if (__is_best_rate(rate, current_rate, best_rate, flags)) {
+   bestmult = i;
+   best_rate = current_rate;
+   *best_parent_rate = parent_rate;
+   }
+   }
+
+   return bestmult;
+}
+
+static long clk_multiplier_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+   struct clk_multiplier *mult = to_clk_multiplier(hw);
+   unsigned long factor = __bestmult(hw, rate, parent_rate,
+ mult->width, mult->flags);
+
+   return *parent_rate * factor;
+}
+
+static int clk_multiplier_set_rate(struct clk_hw *hw, unsigned long rate,
+

[linux-sunxi] [PATCH v3 5/5] clk: sunxi: mod1 clock support

2015-09-29 Thread Maxime Ripard 
From: Emilio López 

The module 1 type of clocks consist of a gate and a mux and are used on
the audio blocks to mux and gate the PLL2 outputs for AC97, IIS or
SPDIF. This commit adds support for them on the sunxi clock driver.

Signed-off-by: Emilio López 
Signed-off-by: Hans de Goede 
Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi/Makefile   |  1 +
 drivers/clk/sunxi/clk-a10-mod1.c | 84 
 2 files changed, 85 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-a10-mod1.c

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 70a449a419e6..cb4c299214ce 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -5,6 +5,7 @@
 obj-y += clk-sunxi.o clk-factors.o
 obj-y += clk-a10-codec.o
 obj-y += clk-a10-hosc.o
+obj-y += clk-a10-mod1.o
 obj-y += clk-a10-pll2.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
diff --git a/drivers/clk/sunxi/clk-a10-mod1.c b/drivers/clk/sunxi/clk-a10-mod1.c
new file mode 100644
index ..490f72432a1e
--- /dev/null
+++ b/drivers/clk/sunxi/clk-a10-mod1.c
@@ -0,0 +1,84 @@
+/*
+ * Copyright 2013 Emilio López
+ *
+ * Emilio López 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 
+
+static DEFINE_SPINLOCK(mod1_lock);
+
+#define SUN4I_MOD1_ENABLE  31
+#define SUN4I_MOD1_MUX 16
+#define SUN4I_MOD1_MUX_WIDTH   2
+#define SUN4I_MOD1_MAX_PARENTS 4
+
+static void __init sun4i_mod1_clk_setup(struct device_node *node)
+{
+   struct clk *clk;
+   struct clk_mux *mux;
+   struct clk_gate *gate;
+   const char *parents[4];
+   const char *clk_name = node->name;
+   void __iomem *reg;
+   int i = 0;
+
+   reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+   if (IS_ERR(reg))
+   return;
+
+   mux = kzalloc(sizeof(*mux), GFP_KERNEL);
+   if (!mux)
+   goto err_unmap;
+
+   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!gate)
+   goto err_free_mux;
+
+   of_property_read_string(node, "clock-output-names", _name);
+
+   while (i < SUN4I_MOD1_MAX_PARENTS &&
+  (parents[i] = of_clk_get_parent_name(node, i)) != NULL)
+   i++;
+
+   gate->reg = reg;
+   gate->bit_idx = SUN4I_MOD1_ENABLE;
+   gate->lock = _lock;
+   mux->reg = reg;
+   mux->shift = SUN4I_MOD1_MUX;
+   mux->mask = BIT(SUN4I_MOD1_MUX_WIDTH) - 1;
+   mux->lock = _lock;
+
+   clk = clk_register_composite(NULL, clk_name, parents, i,
+>hw, _mux_ops,
+NULL, NULL,
+>hw, _gate_ops, 0);
+   if (IS_ERR(clk))
+   goto err_free_gate;
+
+   of_clk_add_provider(node, of_clk_src_simple_get, clk);
+
+   return;
+
+err_free_gate:
+   kfree(gate);
+err_free_mux:
+   kfree(mux);
+err_unmap:
+   iounmap(reg);
+}
+CLK_OF_DECLARE(sun4i_mod1, "allwinner,sun4i-a10-mod1-clk",
+  sun4i_mod1_clk_setup);
-- 
2.5.3

-- 
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 v3 0/5] clk: sunxi: Add support for the Audio PLL

2015-09-29 Thread Maxime Ripard 
Hi,

This serie adds support for the PLL2 aka the Audio PLL on the
Allwinner A10 and the later SoCs.

This is the last part of the audio codec support.

This serie is built on top of a generic clk-multiplier driver to
handle clock that multiply their parent clock rate (mostly PLL's), in
order to provide the driver for the PLL2 base clock, and then adds the
drivers for the clock that derive from the Audio PLL.

Thanks!
Maxime

Changes from v2:
  - Renamed clk-factor to clk-multiplier
  - Added an exception for the A13 clock

Changes from v1:
  - Removed a bogus of_iomap in the mod1 clock driver
  - Wrote the clk-factor driver
  - Converted the PLL2 clock to that driver

Emilio López (2):
  clk: sunxi: codec clock support
  clk: sunxi: mod1 clock support

Maxime Ripard (3):
  clk: Add a basic multiplier clock
  clk: sunxi: Add a driver for the PLL2
  clk: sunxi: pll2: Add A13 support

 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-multiplier.c   | 176 +++
 drivers/clk/sunxi/Makefile |   3 +
 drivers/clk/sunxi/clk-a10-codec.c  |  45 ++
 drivers/clk/sunxi/clk-a10-mod1.c   |  84 +++
 drivers/clk/sunxi/clk-a10-pll2.c   | 216 +
 include/dt-bindings/clock/sun4i-a10-pll2.h |  53 +++
 include/linux/clk-provider.h   |  42 ++
 8 files changed, 620 insertions(+)
 create mode 100644 drivers/clk/clk-multiplier.c
 create mode 100644 drivers/clk/sunxi/clk-a10-codec.c
 create mode 100644 drivers/clk/sunxi/clk-a10-mod1.c
 create mode 100644 drivers/clk/sunxi/clk-a10-pll2.c
 create mode 100644 include/dt-bindings/clock/sun4i-a10-pll2.h

-- 
2.5.3

-- 
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 0/2] ASoC: Add support for the Allwinner A10 codec

2015-09-29 Thread Chen-Yu Tsai 
On Mon, Sep 28, 2015 at 3:42 PM, Maxime Ripard
 wrote:
> Hi Priit,
>
> On Tue, Sep 22, 2015 at 04:26:57PM +0300, Priit Laes wrote:
>> On Sat, 2015-09-12 at 15:26 +0200, Maxime Ripard wrote:
>> > Hi everyone,
>> >
>> > This patch set adds the support for what Allwinner calls the codec on
>> > their SoCs.
>> >
>> > This codec is actually a combination of a codec and DAI, tied
>> > together
>> > in a single memory-mapped IP. It is completely standalone, and
>> > outputs
>> > directly the analog signal.
>> >
>> > While it supports both playback and capture, the capture is not
>> > implemented in this patch, and will be posted eventually as a
>> > separate
>> > one.
>> >
>> > This set, in order to be functional, has a dependency on the audio
>> > clocks patch set posted separately. However, it doesn't needs this to
>> > compile properly, so I guess it can be merged without really caring
>> > for the merging status of the clock patches.
>>
>> It works on Gemei G9 tablet which has also extra chip that
>> automatically switches output over from internal speakers to headphones
>> when connector is inserted.
>>
>> Now I noticed some weird things:
>>
>> When I have all the switches as ON in alsamixer, and I start disabling
>> them, I get following weird results.
>>
>> Left Mixer Left - LML
>> Right Mixer Left - LMR
>> Right Mixer Right - RMR
>>
>> Very faint output:
>> LML - ON
>> RML - Mute
>> RMR - ON
>>
>> Output works fully:
>> LML - Mute
>> RML - Mute
>> RMR - Mute
>>
>> When I Mute Pre-Amplifier and fiddle any of LML, RML or RMR, the output
>> stays mute even after setting Pre-Amplifier Mute back on:
>>
>> 1. All switches on
>> 2. Mute pre-amplifier
>> 3. Mute RMR
>> 4. Pre-Amilifier Mute Off
>> .. Music stays off
>> 5. Toggle Pre-Amplifier twice - output turns on
>
> Unfortunately, I don't have access to that SoC or that setup.
>
> Do you have another A10 board with a simpler audio setup, like a
> cubieboard?
>
>> And also following in dmesg:
>> sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok
>> sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack
>> sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct -> 
>> Headphone Jack
>> sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack
>> sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct -> 
>> Headphone Jack
>
> That one is weird, I'll look into this.

This also appears on my Cubietruck, when using the dts patch from
Hans' sunxi-wip
branch, which is the same patch, albeit for a different dts file, as Priit.

The immediate culprit seems to be the routing property, though I'm not sure what
it should be set to, or what extra drivers might be needed.


Regards
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] [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs

2015-09-29 Thread Maxime Ripard 
On Sun, Sep 27, 2015 at 06:53:03PM +0200, Andrew Lunn wrote:
> > >+  if (of_device_is_compatible(np, "allwinner,sun4i-a10-i2c") ||
> > >+  of_device_is_compatible(np, "allwinner,sun6i-a31-i2c"))
> 
> Rather than have to extend this list every so often, how about adding
> a helper of_device_is_compatible_vendor(), so you can just have:

I don't know, I kind of like the fact that it's explicit. If we ever
have another SoC coming in with a different behaviour, we won't have
to expand it back.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [linux-sunxi] [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs

2015-09-29 Thread Maxime Ripard 
On Sun, Sep 27, 2015 at 06:05:35PM +0200, Olliver Schinagl wrote:
> Hey Hans,
> 
> On 27-09-15 16:57, Hans de Goede wrote:
> >According to the datasheets to n factor for dividing the tclk is
> >2 to the power n on Allwinner SoCs, not 2 to the power n + 1 as it is
> >on other mv64xxx implementations.
> Ah!
> >
> >I've contacted Allwinner about this and they have confirmed that the
> >datasheet is correct.
> >
> >This commit fixes the clk-divider calculations for Allwinner SoCs
> >accordingly.
> So this explains why all my i2c frequenties are double of what I setup.
> Thanks for taking the time of figuring it out! I'll give it a test hopefully
> soon.

It would have been great to let us know...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs

2015-09-29 Thread Maxime Ripard 
On Sun, Sep 27, 2015 at 04:57:08PM +0200, Hans de Goede wrote:
> According to the datasheets to n factor for dividing the tclk is
> 2 to the power n on Allwinner SoCs, not 2 to the power n + 1 as it is
> on other mv64xxx implementations.
> 
> I've contacted Allwinner about this and they have confirmed that the
> datasheet is correct.
> 
> This commit fixes the clk-divider calculations for Allwinner SoCs
> accordingly.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: [linux-sunxi] [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs

2015-09-29 Thread Hans de Goede 

Hi,

On 27-09-15 18:53, Andrew Lunn wrote:

On Sun, Sep 27, 2015 at 06:05:35PM +0200, Olliver Schinagl wrote:

Hey Hans,

On 27-09-15 16:57, Hans de Goede wrote:

According to the datasheets to n factor for dividing the tclk is
2 to the power n on Allwinner SoCs, not 2 to the power n + 1 as it is
on other mv64xxx implementations.

Ah!


Just to be sure, i checked Kirkwood, Armada XP and Armada 370
datasheets. They all say n+1.


Thanks.


+   if (of_device_is_compatible(np, "allwinner,sun4i-a10-i2c") ||
+   of_device_is_compatible(np, "allwinner,sun6i-a31-i2c"))


Rather than have to extend this list every so often, how about adding
a helper of_device_is_compatible_vendor(), so you can just have:


+   if (of_device_is_compatible_vendor(np, "allwinner")


I agree that if such a helper would already exist it would be a good
idea to use it, but it seems overkill to just at it for this.

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 resend 3/4] ARM: dts: sunxi: Enable PWM controller on Q8 format tablets

2015-09-29 Thread Hans de Goede 
From: Chen-Yu Tsai 

Q8 format tablets use channel 0 of the PWM controller for backlight dimming.

Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Enable the pwm controller in sunxi-q8-common.dtsi rather then in
 sun8i-q8-common.dtsi
---
 arch/arm/boot/dts/sunxi-q8-common.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-q8-common.dtsi 
b/arch/arm/boot/dts/sunxi-q8-common.dtsi
index 17b26ff..b824146 100644
--- a/arch/arm/boot/dts/sunxi-q8-common.dtsi
+++ b/arch/arm/boot/dts/sunxi-q8-common.dtsi
@@ -75,3 +75,9 @@
voltage = <40>;
};
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
-- 
2.5.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 resend 2/4] ARM: dts: sun5i: Add PWM channel 0 pinmux setting for A13/A10s

2015-09-29 Thread Hans de Goede 
Add a pinmux setting for the first pwm channel. This is often used for
backlight dimming on tablets.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 5e036a4..f0714d3 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -529,6 +529,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   pwm0_pins: pwm0 {
+   allwinner,pins = "PB2";
+   allwinner,function = "pwm";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};
 
timer@01c20c00 {
-- 
2.5.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 resend 1/4] ARM: dts: sun5i: Add PWM controller node for A13/A10s

2015-09-29 Thread Hans de Goede 
The sun5i die has a PWM controller that is compatible to the one on the A20.
Add a device node for it.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 78b993a..5e036a4 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -543,6 +543,14 @@
reg = <0x01c20c90 0x10>;
};
 
+   pwm: pwm@01c20e00 {
+   compatible = "allwinner,sun7i-a20-pwm";
+   reg = <0x01c20e00 0xc>;
+   clocks = <>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
lradc: lradc@01c22800 {
compatible = "allwinner,sun4i-a10-lradc-keys";
reg = <0x01c22800 0x100>;
-- 
2.5.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 resend 4/4] ARM: dts: sun5i: Add backlight node to sun5i-q8-common.dtsi

2015-09-29 Thread Hans de Goede 
All A13 based q8 formfactor tablets use the same backlight setup, add
a backlight devicetree node for controlling the backlight on these devices.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Drop the comment about DCDC1SW, the axp209 used on A13 boards does not
 have a DCDC1SW
---
 arch/arm/boot/dts/sun5i-q8-common.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-q8-common.dtsi 
b/arch/arm/boot/dts/sun5i-q8-common.dtsi
index 0641d68..a78e189 100644
--- a/arch/arm/boot/dts/sun5i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun5i-q8-common.dtsi
@@ -41,11 +41,21 @@
  */
 #include "sunxi-q8-common.dtsi"
 
+#include 
+
 / {
aliases {
serial0 = 
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <8>;
+   /* TODO: backlight uses axp gpio1 as enable pin */
+   };
+
chosen {
stdout-path = "serial0:115200n8";
};
-- 
2.5.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 resend 0/4] ARM: dts: sunxi: q8 A13 tablet backlight support

2015-09-29 Thread Hans de Goede 
Hi Maxime,

This series seems to have fallen through the cracks, hence this resend.

Regards,

Hans

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi][alsa-devel][PATCH 3/3] ASOC: sunxi: Add support for the spdif block

2015-09-29 Thread Mark Brown 
On Mon, Sep 28, 2015 at 10:25:33AM +0200, Maxime Ripard wrote:
> On Thu, Sep 24, 2015 at 04:30:05PM +0200, codekip...@gmail.com wrote:
> > From: Marcus Cooper 
> > 
> > The sun4i, sun6i and sun7i SoC families have an SPDIF
> > block which is capable of playback and capture.

Please delete unneeded context from replies, it makes it much easier to
find new content.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] [PATCH v4 2/3] sunxi-tools: implement persistent sram_info information

2015-09-29 Thread Bernhard Nortmann 
Information about the SoC-specific memory layout may be required across
several places in the fel utility code. To avoid having to retrieve this
information repeatedly, this patch modifies the aw_fel_get_sram_info()
function to cache its result (via an internal static pointer).

This makes it safe to call aw_fel_get_sram_info() wherever needed, while
avoiding additional aw_fel_get_version() lookups, and potential surplus
"no 'soc_sram_info' data for your SoC" warnings.

Signed-off-by: Bernhard Nortmann 
---
 fel.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/fel.c b/fel.c
index 52b785f..71d56c3 100644
--- a/fel.c
+++ b/fel.c
@@ -503,18 +503,27 @@ soc_sram_info generic_sram_info = {
 
 soc_sram_info *aw_fel_get_sram_info(libusb_device_handle *usb)
 {
-   int i;
-   struct aw_fel_version buf;
-
-   aw_fel_get_version(usb, );
-
-   for (i = 0; soc_sram_info_table[i].swap_buffers; i++)
-   if (soc_sram_info_table[i].soc_id == buf.soc_id)
-   return _sram_info_table[i];
+   /* persistent sram_info, retrieves result pointer once and caches it */
+   static soc_sram_info *result = NULL;
+   if (result == NULL) {
+   int i;
+
+   struct aw_fel_version buf;
+   aw_fel_get_version(usb, );
+
+   for (i = 0; soc_sram_info_table[i].swap_buffers; i++)
+   if (soc_sram_info_table[i].soc_id == buf.soc_id) {
+   result = _sram_info_table[i];
+   break;
+   }
 
-   printf("Warning: no 'soc_sram_info' data for your SoC (id=%04X)\n",
-  buf.soc_id);
-   return _sram_info;
+   if (!result) {
+   printf("Warning: no 'soc_sram_info' data for your SoC 
(id=%04X)\n",
+  buf.soc_id);
+   result = _sram_info;
+   }
+   }
+   return result;
 }
 
 static uint32_t fel_to_spl_thunk[] = {
-- 
2.4.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 2/3] sunxi-tools: factor out persistent version and sram_info information

2015-09-29 Thread Bernhard Nortmann 

Am 26.09.2015 um 22:06 schrieb Siarhei Siamashka:

What kind of problem are you trying to solve in the first place?
Is it just for suppressing multiple prints of the "unsupported soc
type" warning?


Basically: yes. Initially you got me triggered on that with your very
first comment. Admittedly I went overboard here - after all, the idea
of caching the aw_fel_get_sram_info() result already solves my "problem".
There's no need to rework and/or constrain the other USB operations,
namely retrieving aw_fel_version information.

I've prepared and submitted a v4 iteration of the series, that I would
consider 'final':
https://groups.google.com/forum/#!topic/linux-sunxi/1B3V7gmBnsk

Regards, B. Nortmann

--
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 0/3] sunxi-tools: usb boot patches

2015-09-29 Thread Bernhard Nortmann 
This is my "final" v4 of the series, that adds the desired functionality
without introducing a need for new global variables.

follows up on (and supersedes)
v3: https://groups.google.com/d/msg/linux-sunxi/XuwQF_cK2jA/ECozGooDAwAJ
v2: https://groups.google.com/forum/#!topic/linux-sunxi/XuwQF_cK2jA
v1: https://groups.google.com/forum/#!topic/linux-sunxi/npRCb49MCk4


These patches are closely related to some proposed changes in U-Boot,
namely http://lists.denx.de/pipermail/u-boot/2015-September/226515.html
and http://lists.denx.de/pipermail/u-boot/2015-September/226689.html

The new "sunxi" SPL header and some modifications to fel.c will allow
the fel utility to pass information to U-Boot. In case of an FEL boot,
our goal is to have a way of auto-executing a boot script that was
transferred to DRAM (via "fel") before actual U-Boot startup.

Regards, B. Nortmann

Bernhard Nortmann (3):
  sunxi-tools: refactor image type detection/query
  sunxi-tools: implement persistent sram_info information
  sunxi-tools: add a mechanism to provide boot information via FEL

 fel.c | 174 ++
 1 file changed, 143 insertions(+), 31 deletions(-)

-- 
2.4.6

-- 
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 1/3] sunxi-tools: refactor image type detection/query

2015-09-29 Thread Bernhard Nortmann 
This patch moves retrieving the image header type into a function
of its own. The idea is that fel "write" can and will also make
use of this function to detect boot scripts (by IH_TYPE_SCRIPT).

Signed-off-by: Bernhard Nortmann 
---
 fel.c | 78 ++-
 1 file changed, 59 insertions(+), 19 deletions(-)

diff --git a/fel.c b/fel.c
index 98e8d89..52b785f 100644
--- a/fel.c
+++ b/fel.c
@@ -108,6 +108,46 @@ void usb_bulk_recv(libusb_device_handle *usb, int ep, void 
*data, int length)
}
 }
 
+/* Constants taken from ${U-BOOT}/include/image.h */
+#define IH_MAGIC   0x27051956  /* Image Magic Number   */
+#define IH_ARCH_ARM2   /* ARM  */
+#define IH_TYPE_INVALID0   /* Invalid Image*/
+#define IH_TYPE_FIRMWARE   5   /* Firmware Image   */
+#define IH_TYPE_SCRIPT 6   /* Script file  */
+#define IH_NMLEN   32  /* Image Name Length*/
+
+/* Additional error codes, newly introduced for get_image_type() */
+#define IH_TYPE_ARCH_MISMATCH  -1
+
+#define HEADER_NAME_OFFSET 32  /* offset of name field */
+#define HEADER_SIZE(HEADER_NAME_OFFSET + IH_NMLEN)
+
+/*
+ * Utility function to determine the image type from a mkimage-compatible
+ * header at given buffer (address).
+ *
+ * For invalid headers (insufficient size or 'magic' mismatch) the function
+ * will return IH_TYPE_INVALID. Negative return values might indicate
+ * special error conditions, e.g. IH_TYPE_ARCH_MISMATCH signals that the
+ * image doesn't match the expected (ARM) architecture.
+ * Otherwise the function will return the "ih_type" field for valid headers.
+ */
+int get_image_type(const uint8_t *buf, size_t len)
+{
+   uint32_t *buf32 = (uint32_t *)buf;
+
+   if (len <= HEADER_SIZE) /* insufficient length/size */
+   return IH_TYPE_INVALID;
+   if (be32toh(buf32[0]) != IH_MAGIC) /* signature mismatch */
+   return IH_TYPE_INVALID;
+   /* For sunxi, we always expect ARM architecture here */
+   if (buf[29] != IH_ARCH_ARM)
+   return IH_TYPE_ARCH_MISMATCH;
+
+   /* assume a valid header, and return ih_type */
+   return buf[30];
+}
+
 void aw_send_usb_request(libusb_device_handle *usb, int type, int length)
 {
struct aw_usb_request req;
@@ -819,15 +859,6 @@ void aw_fel_write_and_execute_spl(libusb_device_handle 
*usb,
aw_restore_and_enable_mmu(usb, sram_info, tt);
 }
 
-/* Constants taken from ${U-BOOT}/include/image.h */
-#define IH_MAGIC   0x27051956  /* Image Magic Number   */
-#define IH_ARCH_ARM2   /* ARM  */
-#define IH_TYPE_FIRMWARE   5   /* Firmware Image   */
-#define IH_NMLEN   32  /* Image Name Length*/
-
-#define HEADER_NAME_OFFSET 32  /* offset of name field */
-#define HEADER_SIZE(HEADER_NAME_OFFSET + IH_NMLEN)
-
 /*
  * This function tests a given buffer address and length for a valid U-Boot
  * image. Upon success, the image data gets transferred to the default memory
@@ -840,25 +871,34 @@ void aw_fel_write_uboot_image(libusb_device_handle *usb,
if (len <= HEADER_SIZE)
return; /* Insufficient size (no actual data), just bail out */
 
-   /* Check for a valid mkimage header */
uint32_t *buf32 = (uint32_t *)buf;
 
-   if (be32toh(buf32[0]) != IH_MAGIC) {
-   fprintf(stderr, "U-Boot image verification failure: "
-   "expected IH_MAGIC, got 0x%X\n", be32toh(buf32[0]));
+   /* Check for a valid mkimage header */
+   int image_type = get_image_type(buf, len);
+   if (image_type <= IH_TYPE_INVALID) {
+   switch (image_type) {
+   case IH_TYPE_INVALID:
+   fprintf(stderr, "Invalid U-Boot image: bad size or 
signature\n");
+   break;
+   case IH_TYPE_ARCH_MISMATCH:
+   fprintf(stderr, "Invalid U-Boot image: wrong 
architecture\n");
+   break;
+   default:
+   fprintf(stderr, "Invalid U-Boot image: error code %d\n",
+   image_type);
+   }
exit(1);
}
-   if (buf[29] != IH_ARCH_ARM|| buf[30] != IH_TYPE_FIRMWARE) {
-   fprintf(stderr, "U-Boot image verification failure: "
-   "expected ARM firmware, got %02X %02X\n", buf[29], 
buf[30]);
+   if (image_type != IH_TYPE_FIRMWARE) {
+   fprintf(stderr, "U-Boot image type mismatch: "
+   "expected IH_TYPE_FIRMWARE, got %02X\n", image_type);
exit(1);
}
uint32_t data_size = be32toh(buf32[3]); /* Image Data Size */
uint32_t load_addr = be32toh(buf32[4]); /* Data Load Address */
-   if

[linux-sunxi] [PATCH v4 3/3] sunxi-tools: add a mechanism to provide boot information via FEL

2015-09-29 Thread Bernhard Nortmann 
This patch makes use of a new sunxi SPL header format, where
fields for passing data to U-Boot are reserved. This allows the
"fel" utility to provide specific pieces of information by
setting these fields (which will be evaluated by U-Boot then).

For now, we provide the memory location of the boot script file
(boot.scr) this way. A suitably modified U-Boot can adjust the
boot process accordingly and will auto-execute the script.

Signed-off-by: Bernhard Nortmann 
---
 fel.c | 65 -
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/fel.c b/fel.c
index 71d56c3..e9f6450 100644
--- a/fel.c
+++ b/fel.c
@@ -949,6 +949,61 @@ void aw_fel_process_spl_and_uboot(libusb_device_handle 
*usb,
aw_fel_write_uboot_image(usb, buf + SPL_LEN_LIMIT, size - 
SPL_LEN_LIMIT);
 }
 
+/*
+ * Test the SPL header for our "sunxi" variant. We want to make sure that
+ * we can safely use specific header fields to pass information to U-Boot.
+ * In case of a missing signature (e.g. Allwinner boot0) or header version
+ * mismatch, this function will return "false". If all seems fine,
+ * the result is "true".
+ */
+#define SPL_SIGNATURE  "SPL" /* marks "sunxi" header */
+#define SPL_MIN_VERSION1 /* minimum required version */
+#define SPL_MAX_VERSION1 /* maximum supported version 
*/
+int have_sunxi_spl(libusb_device_handle *usb, uint32_t spl_addr)
+{
+   uint8_t spl_signature[4];
+
+   aw_fel_read(usb, spl_addr + 0x14,
+   _signature, sizeof(spl_signature));
+
+   if (memcmp(spl_signature, SPL_SIGNATURE, 3) != 0)
+   return 0; /* signature mismatch, no "sunxi" SPL */
+
+   if (spl_signature[3] < SPL_MIN_VERSION) {
+   fprintf(stderr, "sunxi SPL version mismatch: "
+   "found 0x%02X < required minimum 0x%02X\n",
+   spl_signature[3], SPL_MIN_VERSION);
+   fprintf(stderr, "You need to update your U-Boot (mksunxiboot) 
to a more recent version.\n");
+   return 0;
+   }
+   if (spl_signature[3] > SPL_MAX_VERSION) {
+   fprintf(stderr, "sunxi SPL version mismatch: "
+   "found 0x%02X > maximum supported 0x%02X\n",
+   spl_signature[3], SPL_MAX_VERSION);
+   fprintf(stderr, "You need a more recent version of this 
(sunxi-tools) fel utility.\n");
+   return 0;
+   }
+   return 1; /* sunxi SPL and suitable version */
+}
+
+/*
+ * Pass information to U-Boot via specialized fields in the SPL header
+ * (see "boot_file_head" in ${U-BOOT}/tools/mksunxiboot.c), providing
+ * information about the boot script address (DRAM location of boot.scr).
+ */
+void pass_fel_information(libusb_device_handle *usb, uint32_t script_address)
+{
+   soc_sram_info *sram_info = aw_fel_get_sram_info(usb);
+
+   /* write something _only_ if we have a suitable SPL header */
+   if (have_sunxi_spl(usb, sram_info->spl_addr)) {
+   pr_info("Passing boot info via sunxi SPL: script address = 
0x%08X\n",
+   script_address);
+   aw_fel_write(usb, _address,
+   sram_info->spl_addr + 0x18, sizeof(script_address));
+   }
+}
+
 static int aw_fel_get_endpoint(libusb_device_handle *usb)
 {
struct libusb_device *dev = libusb_get_device(usb);
@@ -1085,13 +1140,21 @@ int main(int argc, char **argv)
double t1, t2;
size_t size;
void *buf = load_file(argv[3], );
+   uint32_t offset = strtoul(argv[2], NULL, 0);
t1 = gettime();
-   aw_fel_write(handle, buf, strtoul(argv[2], NULL, 0), 
size);
+   aw_fel_write(handle, buf, offset, size);
t2 = gettime();
if (t2 > t1)
pr_info("Written %.1f KB in %.1f sec (speed: 
%.1f KB/s)\n",
(double)size / 1000., t2 - t1,
(double)size / (t2 - t1) / 1000.);
+   /*
+* If we have transferred a script, try to inform U-Boot
+* about its address.
+*/
+   if (get_image_type(buf, size) == IH_TYPE_SCRIPT)
+   pass_fel_information(handle, offset);
+
free(buf);
skip=3;
} else if (strcmp(argv[1], "read") == 0 && argc > 4) {
-- 
2.4.6

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

[linux-sunxi] Re: [PATCH 0/2] mtd: nand: sunxi: cleanup

2015-09-29 Thread Brian Norris 
On Wed, Sep 16, 2015 at 09:46:35AM +0200, Boris Brezillon wrote:
> Hello,
> 
> Those two patches aim at cleaning up the sunxi_nand driver by first adding
> some consistency in the macro definitions, and then factorizing the code
> duplicated code found in hw_ecc and hw_syndrome_ecc implementations.
> 
> Best Regards,
> 
> Boris

I believe this series no longer applies cleanly

-- 
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 0/2] ASoC: Add support for the Allwinner A10 codec

2015-09-29 Thread Hans de Goede 

Hi,

On 09/28/2015 09:42 AM, Maxime Ripard wrote:

Hi Priit,

On Tue, Sep 22, 2015 at 04:26:57PM +0300, Priit Laes wrote:

On Sat, 2015-09-12 at 15:26 +0200, Maxime Ripard wrote:

Hi everyone,

This patch set adds the support for what Allwinner calls the codec on
their SoCs.

This codec is actually a combination of a codec and DAI, tied
together
in a single memory-mapped IP. It is completely standalone, and
outputs
directly the analog signal.

While it supports both playback and capture, the capture is not
implemented in this patch, and will be posted eventually as a
separate
one.

This set, in order to be functional, has a dependency on the audio
clocks patch set posted separately. However, it doesn't needs this to
compile properly, so I guess it can be merged without really caring
for the merging status of the clock patches.


It works on Gemei G9 tablet which has also extra chip that
automatically switches output over from internal speakers to headphones
when connector is inserted.

Now I noticed some weird things:

When I have all the switches as ON in alsamixer, and I start disabling
them, I get following weird results.

Left Mixer Left - LML
Right Mixer Left - LMR
Right Mixer Right - RMR

Very faint output:
LML - ON
RML - Mute
RMR - ON

Output works fully:
LML - Mute
RML - Mute
RMR - Mute

When I Mute Pre-Amplifier and fiddle any of LML, RML or RMR, the output
stays mute even after setting Pre-Amplifier Mute back on:

1. All switches on
2. Mute pre-amplifier
3. Mute RMR
4. Pre-Amilifier Mute Off
.. Music stays off
5. Toggle Pre-Amplifier twice - output turns on


Unfortunately, I don't have access to that SoC or that setup.


I'm seeing similar stuff on a cubieboard, both A10 and A20
based cubieboards, I have to fiddle a bit with the switches
to get things to work. At boot all switches are disabled.

On both A10 and A20 I need to enable to following for things to work:

unmute Pre-Amplifier DAC
unmute Pre-Amplifier Mute

I guess this is just a question if adding some mixer defaults to
the alsa userspace somewhere ?

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [fedora-arm] [linux-sunxi] cpufreq scaling broken on cubietruck

2015-09-29 Thread Peter Robinson 
>>> On Sun, 2015-09-27 at 12:37 +0200, Hans de Goede wrote:
>>>
 This is likely a problem with your kernel config, make sure that
 you've the axp209 mfd and regulator drivers enabled and loaded.
>>>
>>>
>>> Thanks, Hans. I really should have figured that out on my own!
>>>
>>> Do you think it's worth asking PeterR if he will change the default
>>> Fedora armv7 config to CONFIG_REGULATOR_AXP20X=y rather than the
>>> current CONFIG_REGULATOR_AXP20X=m? (I suspect that request might
>>> carry more weight if it comes from you rather than me. ;)
>>>
>>
>> Hans,
>>
>> Do you have an opinion, (or anyone else for that matter), on what would be
>> the upstream preferred way of getting the axp20x regulator driver to
>> auto-load, from a DT reference, assuming it is built as a module?
>> Something
>> like the attached patch? (Not tested, just thinking out loud.)
>
>
> This is already fixed by this patch:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/axp20x-regulator.c?id=d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec

I've pulled this patch into the F-23/4.2.x kernel, it'll be in the
4.2.2 build, it's already in rawhide.

Peter

-- 
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] DCDC2 (VDD-SYS) voltage for A23/A33?

2015-09-29 Thread wens Tsai 
Hi,

I've been looking into AXP223 usage as part of the RSB patches.
I found that the recommended voltage for VDD-SYS is 1.1V, but
we default to 1.2V in U-boot. Among the fex files, some use
1.1V and some use 1.2V.

Perhaps we could update the defconfigs with the values from
the fex files.

One thing that we have to be careful of is matching the settings
in U-boot and the kernel, or alternatively, not use a fixed value
but the recommended range for the VDD-SYS regulator. Accidentally
dropping the voltage on VDD-SYS results in some logic errors,
which likely lead to a crash.


Regards
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 v4] ARM: sun7i: dt: Add new Olimex A20 EVB device

2015-09-29 Thread Maxime Ripard 
On Sun, Sep 27, 2015 at 08:16:42AM +0200, codekip...@gmail.com wrote:
> From: Marcus Cooper 
> 
> The A20-SOM-EVB is a reference design of a 2-layer board for the
> A20-SOM.
> It expands the features of A20-SOM by adding VGA connector, HDMI
> connector, audio In/Out, LCD connector, 2 Mpix camera, gigabit
> Ethernet, SATA, USB-OTG and 2 USB hosts.
> 
> Signed-off-by: Marcus Cooper 
> ---
> Changes since v3:
> - removed i2c1 as it's not used
> - removed axp_ipsout regulator
> Changes since v2:
> - changed dcdc2 to have max voltage of 1.4V
> Changes since v1:
> - renamed dts from sun7i-a20-olinuxino-evb to sun7i-a20-olimex-som-evb
> - added "axp209 dtsi"
> - change regulator settings
> ---
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 202 
> +
>  2 files changed, 203 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 1c5f225..0e87a54 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -618,6 +618,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>   sun7i-a20-i12-tvbox.dtb \
>   sun7i-a20-m3.dtb \
>   sun7i-a20-mk808c.dtb \
> + sun7i-a20-olimex-som-evb.dtb \
>   sun7i-a20-olinuxino-lime.dtb \
>   sun7i-a20-olinuxino-lime2.dtb \
>   sun7i-a20-olinuxino-micro.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts 
> b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> new file mode 100644
> index 000..3317c22
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> @@ -0,0 +1,202 @@
> +/*
> + * Copyright 2015 - Marcus Cooper 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Olimex A20-Olimex-SOM-EVB";
> + compatible = "olimex,a20-olimex-som-evb", "allwinner,sun7i-a20";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_olimex_som_evb>;
> +
> + green {
> + label = "a20-olimex-som-evb:green:usr";
> + gpios = < 7 2 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> + };
> +};
> +
> + {
> + target-supply = <_ahci_5v>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_rgmii_a>;
> + phy = <>;
> + phy-mode = "rgmii";
> + status = "okay";
> +
> + phy1: ethernet-phy@1 {
> + reg =

Re: [linux-sunxi] Re: [PATCH 5/5] ARM: sun5i: Add C.H.I.P DTS

2015-09-29 Thread Maxime Ripard 
On Tue, Sep 22, 2015 at 04:30:04PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 22-09-15 16:04, Maxime Ripard wrote:
> >On Tue, Sep 22, 2015 at 03:01:58PM +0200, Hans de Goede wrote:
> >>>In short, this is not about "power supply" but VBUS detection. IIRC,
> >>>if no VBUS detection method is provided, the phy driver just waits a
> >>>period of time after an ID pin change and then considers VBUS invalid.
> >>
> >>Right, but that is a hack for boards with no / broken vbus detection
> >>(or vbus control), we really want to use vbus-det where available,
> >>so I agree that a TODO comment here would be good.
> >
> >What's so special in our SoCs that makes that we can't just rely on
> >the ID pin ? (which seems to be working just fine here)
> 
> There is nothing special, AFAIK all OTG ports (also for other SoCs)
> have some sort of vbus detection mechanism. We need the hack because
> vbus-det is broken on some of our boards.
> 
> And where it is not broken we should be using vbus-det normallu.

Ah, and most controllers embed that directly into the controller
itself and don't rely on a GPIO to do that. Understood.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH 2/3] ARM: dts: sun6i: Turn on gmac on Colombus

2015-09-29 Thread Hans de Goede 

Hi,

On 08/21/2015 12:12 AM, Maxime Ripard wrote:

On Thu, Aug 20, 2015 at 08:23:27AM +0200, Hans de Goede wrote:

Hi,

On 08/19/2015 05:17 PM, Maxime Ripard wrote:

On Fri, Aug 07, 2015 at 05:22:34PM +0200, Hans de Goede wrote:

We've everything we need to support the gmac on Colombus, turn it on.

Signed-off-by: Hans de Goede 


I recall that the phy was powered by one of the AXP221 regulators,
does it require some additional stuff (like a recent u-boot), or does
it just work and my memory is bad :) ?


I think it just works, it MAY be connected to aldo1 but according to
the git history for the u-boot defconfig that one is used for wifi not
for the gmac, and we do not enable any other "spare" regulators in the
u-boot config.

I do not have any schematics, so no way to say for sure.

I can confirm that the GMAC work fine with the latest u-boot
master. Looking in the history we've always enabled ALDO1
on the Colombus in upstream u-boot, so this should all just work.


Except that if it is the case, the DT was working fine with the stock
bootloader, and it doesn't anymore, while we have no way to upgrade
it.


Ok, I've finally made some time to test this, the gmac works fine
with aldo1 disabled, so I believe this patch can be merged as is.

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.