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

2015-10-05 Thread Stephen Boyd 
On 10/05, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Oct 02, 2015 at 01:43:08PM -0700, Stephen Boyd wrote:
> > On 09/29, Maxime Ripard wrote:
> > > +
> > > + 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)
> > 
> > Is the only difference in this function vs the divider one that
> > flag? Maybe we should make this function generic to the framework
> > and pass a flag indicating closest or not.
> 
> Actually, the logic is also reversed.
> 
> The divider driver will always try to find some rate that is higher
> than the one we already have, without going above than the one
> requested.
> 
> Here, we're tring to be lower than the best rate, without going below
> the requested rate.

So then a tri-state flag that indicates, closest, less than,
greater than?

> 
> > 
> > > + unsigned long val;
> > > +
> > > + if (mult->lock)
> > > + spin_lock_irqsave(mult->lock, flags);
> > 
> > This needs the same "trick" that we did in the generic clock
> > types to avoid sparse warnings.
> 
> The __acquire call ?

Yes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

-- 
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] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

2015-10-05 Thread Timo Sigurdsson 
Hi Kevin,

Kevin Hilman schrieb am 24.09.2015 19:57:
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others.  I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> gets my bananapi booting again.
> 
> Note it's kind of an interesting boot failure.  The kernel boots fully
> to a shell, but panics after running a few commands.  In particular
> 'dmesg -n1' seems to trigger it usually[2].
> 
> Kevin
> 
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html

following up on my last email: I'm back from my vacation and I tried to
reproduce your problem, but my board doesn't seem to be affected, so I
cannot trigger it.

I still think that the lower voltages may be the cause of your problem
with that specific board, so could you please test the attached patch on
top of my patch that you first experienced the problem with? Please let 
us know whether this solves your issue or whether we need to dig deeper.

Has anybody else been able to reproduce Kevin's issue?

Kind regards,

Timo

-- 
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.
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 74382f3..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -94,6 +94,16 @@
 
  {
 	cpu-supply = <_dcdc2>;
+	operating-points = <
+		/* kHz	  uV */
+		96	140
+		912000	140
+		864000	135
+		72	125
+		528000	115
+		312000	110
+		144000	105
+		>;
 };
 
  {
-- 
2.1.4

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

2015-10-05 Thread xhero . gm 

> 
> They miss the input filter, but i don't know if there will be just more noise 
> or it will not work at all...
> 
> Enrico

I don't know, I will try the program on the Olimex board too and see what the 
output is, but I think that if the noise is too much the hw probably just shuts 
the channel and displays the blue/green screen.
Today I was able to stream from the TV using the tvin-hdmi program, with just 
some slight modifications. The video was very nice and quite fluid. It would be 
very nice if someone could test it on their hw so I'm sure it is not just a 
chance it works for me!
I could also draft something on the wiki so I can document what I understood 
(little...) so far about the TV in interface, would someone be interested?

Rodolfo

-- 
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 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

2015-10-05 Thread Siarhei Siamashka 
On Mon, 5 Oct 2015 08:39:40 +0300
Siarhei Siamashka  wrote:

> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai  wrote:
> 
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> >  wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> > 
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
> 
> That's a good question.
> 
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.
> 
> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
> 
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.
> Based on the schematics comparison, there do not seem to be any
> substantial differences between these boards if we ignore the PD2
> pin altogether. LinkSprite says that "Ubuntu images are same for
> both pcDuino1 and pcDuino2" at their website:
> http://www.linksprite.com/?page_id=809
> 
> And I actually like their decision to have the PD2 pin pulled-up.
> If every devboard manufacturer did a similar thing and had USB power
> always enabled by default without any need to configure anything (with
> or without the possibility to switch it off if necessary), then we
> would have a much easier job with generic device-independent bootable
> SD card installer images for Allwinner boards:
> 
> http://lists.denx.de/pipermail/u-boot/2015-January/202306.html
> 
> "USB host ports use dedicated pins and only enabling/disabling power
>  can be device specific. The missing USB power can be solved by
>  using a powered USB hub, which is not very convenient, but
>  still a workable solution."

(dropping the arm and devicetree lists from CC, because the rest is
deviating from the original patch discussion too much)

In fact, the initial SD card image release, which had been announced
in that old e-mail, deviated a bit from the clean and perfectly safe
generic device-independent model. One thing is that it still used
the UART serial console as an alternative to HDMI. And another thing
is that it assumed that PH3 and PH6 pins are used for enabling USB
power on Allwinner A10 and Allwinner A20 devices. This is not very
good, but in practice used to be safe for all the FEX files from the
sunxi-boards repository. Well, until the Banana Pro board showed up.
The Banana Pro board uses PH3 as the USB OTG ID pin, and hence it
is supposed to be configured for *input*. Setting it for output when
the OTG cable is connected (the ID pin is shorted to the ground) is a
bad idea. Why on earth did they decide to assign this particular pin
for USB OTG ID? For example, a user who is not very skilled at
differentiating various sorts of bananas, might try to use a Banana Pi
build of U-Boot and kernel on a Banana Pro board and get into a
trouble with PH3/PH6 pins.

I had added a warning about the Banana Pro incompatibility on the
downloads page as soon as this problem had been discovered some time
ago. Counting FEX files in the sunxi-boards repository, this is just 1
board where setting PH3/PH6 pins for output is unsafe. And we have 84
A10/A20 boards there. This is a perfect example of "one rotten apple
spoils the whole barrel" situation.

In the end, we don't really depend on UART and PH3/PH6 pins. Their
usage can be dropped any time. The board type selection stub uses
FEL button as an alternative input method. And the FEL button is
available on all popular Allwinner based devboards anyway. Some of
the boards have USB power enabled by default. Some users have a
spare powered USB hub easily available.

-- 
Best regards,
Siarhei Siamashka

-- 
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: sun7i_tvd in kernel 3.4

2015-10-05 Thread xhero . gm 
Yes you are right! I forgot the most important detail. I'm running a MarsBoard 
with Linux 3.4.90 and a Debian distro. When I have a sec I will post the 
complete uname. 
To capture the images I used yavta and a script to convert the frames to bmps. 
I was also able to encode videos with ffmpeg.
Does the CB board have all the necessary filters for the signal installed? 
AFAIK the Olimex boards cannot do TV in because they miss all the input 
electronics.

Rodolfo 

-- 
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 4/5] clk: sunxi: codec clock support

2015-10-05 Thread Maxime Ripard 
On Fri, Oct 02, 2015 at 01:44:27PM -0700, Stephen Boyd wrote:
> On 09/29, Maxime Ripard wrote:
> > diff --git a/drivers/clk/sunxi/clk-a10-codec.c 
> > b/drivers/clk/sunxi/clk-a10-codec.c
> > new file mode 100644
> > index ..aaeccf8cde39
> > --- /dev/null
> > +++ b/drivers/clk/sunxi/clk-a10-codec.c
> > @@ -0,0 +1,45 @@
> > +/*
> > + * 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 
> 
> Is this include used?

It isn't, I've removed it.

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 v3 5/5] clk: sunxi: mod1 clock support

2015-10-05 Thread Maxime Ripard 
On Fri, Oct 02, 2015 at 01:45:55PM -0700, Stephen Boyd wrote:
> On 09/29, Maxime Ripard wrote:
> > + * (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 
> 
> Is this include used?

Fixed.

> > +   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)
> 
> Can we use of_clk_parent_fill() here?

We can, I switched to it.

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 v2 5/5] ARM: sun5i: Add C.H.I.P DTS

2015-10-05 Thread Julian Calaby 
Hi Maxime,

On Tue, Oct 6, 2015 at 1:23 AM, Maxime Ripard
 wrote:
> The C.H.I.P. is a small SBC with an Allwinner R8, 8GB of NAND, 512MB of
> RAM, USB host and OTG, a wifi / bluetooth combo chip, an audio/video jack
> and two connectors to plug additional boards on top of it.

Sorry for the late review, but a couple of minor things stuck out at me.

> Signed-off-by: Maxime Ripard 
> Reviewed-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/Makefile  |   3 +-
>  arch/arm/boot/dts/sun5i-r8-chip.dts | 224 
> 
>  2 files changed, 226 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c7adaa85ef3f..2cf7e593270a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -600,7 +600,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a13-olinuxino.dtb \
> sun5i-a13-olinuxino-micro.dtb \
> sun5i-a13-q8-tablet.dtb \
> -   sun5i-a13-utoo-p66.dtb
> +   sun5i-a13-utoo-p66.dtb \
> +   sun5i-r8-chip.dtb
>  dtb-$(CONFIG_MACH_SUN6I) += \
> sun6i-a31-app4-evb1.dtb \
> sun6i-a31-colombus.dtb \
> diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts 
> b/arch/arm/boot/dts/sun5i-r8-chip.dts
> new file mode 100644
> index ..08ff70601c79
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
> @@ -0,1 +1,224 @@
> +/*
> + * Copyright 2015 Free Electrons
> + * Copyright 2015 NextThing Co
> + *
> + * Maxime Ripard 
> + *
> + * 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 "sun5i-a13.dtsi"

Am I missing something or should this include "sun5i-r8.dtsi" instead?

> +#include "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> +   model = "NextThing C.H.I.P.";
> +   compatible = "nextthing,chip", "allwinner,sun5i-r8";
> +
> +   aliases {
> +   i2c0 = 
> +   i2c1 = 
> +   i2c2 = 
> +   serial0 = 
> +   serial1 = 
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";

Should the composite output be enabled here too?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

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

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

2015-10-05 Thread Rosimildo DaSilva 
Anything you document, it is better then nothing. I would suggest to 
document on your "github", and put some link on the wiki, to your place.

R

On Monday, October 5, 2015 at 3:40:53 PM UTC-5, xher...@gmail.com wrote:
>
>
> > 
> > They miss the input filter, but i don't know if there will be just more 
> noise or it will not work at all... 
> > 
> > Enrico 
>
> I don't know, I will try the program on the Olimex board too and see what 
> the output is, but I think that if the noise is too much the hw probably 
> just shuts the channel and displays the blue/green screen. 
> Today I was able to stream from the TV using the tvin-hdmi program, with 
> just some slight modifications. The video was very nice and quite fluid. It 
> would be very nice if someone could test it on their hw so I'm sure it is 
> not just a chance it works for me! 
> I could also draft something on the wiki so I can document what I 
> understood (little...) so far about the TV in interface, would someone be 
> interested? 
>
> Rodolfo

-- 
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 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

2015-10-05 Thread Maxime Ripard 
Hi,

On Sun, Oct 04, 2015 at 09:58:45PM +0300, Siarhei Siamashka wrote:
> Hello,
> 
> This brings LinkSprite pcDuino1/2 boards up to date with the latest
> kernel features. And the first patch in this set is a bugfix for the
> PH3/PH6 pins misuse.
> 
> There is currently a single dts file for pcDuino1 and pcDuino2 boards.
> They obviously had been designed to be compatible with each other, but
> have some minor differences, as can be seen when comparing schematics:
> https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
> https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf

Usually, the way we handle this is simply by including just the other
DT that will only hold those differences.

What are those differences exactly ?

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 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

2015-10-05 Thread Maxime Ripard 
On Mon, Oct 05, 2015 at 08:39:40AM +0300, Siarhei Siamashka wrote:
> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai  wrote:
> 
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> >  wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> > 
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
> 
> That's a good question.
> 
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.

I do agree that this is the right solution for the pcduino1, but it's
definitely not the right one for the pcduino 2 then.

Declaring this as a regulator isn't just meant for the USB to be
working, it's also meant so that it keeps working. If the pin is not
claimed by anyone, the userspace and / or some other driver, will
actually be able to grab that pin and do whatever it wants with it,
effectively fiddling with the VBUS supply behind the USB driver's
back.

It also allows to disable the regulator if VBUS isn't going to be
used, for example because the driver has not be compiled in, or that
it's actually a module that might (or might not) be loaded later.

Finally, it also allows to keep track of who consumes what amount of
power in the system, which is a nice plus.

> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
> 
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.

You don't have to split them, if this is really the only difference,
just create a new dts for the pcduino2 that includes the first one,
and add the supply there.

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 3/3] ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2

2015-10-05 Thread Maxime Ripard 
On Sun, Oct 04, 2015 at 09:58:48PM +0300, Siarhei Siamashka wrote:
> This allows voltage-scaling with cpufreq-dt. The reliability of
> voltage-scaling has been checked by reducing the voltage of all
> operating points by 0.025V (for extra safety headroom) and running
> libjpeg-turbo decoding tests on 5 pcDuino2 boards. It means that
> the standard sun4i voltages should be perfectly fine too.
> 
> Signed-off-by: Siarhei Siamashka 

Applied, thanks!

Maxime

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

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


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v2 1/4] dt-bindings: add sunxi SPDIF transceiver bindings

2015-10-05 Thread Code Kipper 
On 5 October 2015 at 10:41, Maxime Ripard
 wrote:
> On Fri, Oct 02, 2015 at 07:24:20AM +0200, Code Kipper wrote:
>> >> +
>> >> +  - compatible   : should be one of the following:
>> >> +- "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
>> >> +- "allwinner,sun7i-a20-spdif": for the Allwinner A20 SoC
>> >> +- "allwinner,sun6i-a31-spdif": for the Allwinner A31 SoC
>> >
>> > Are all these compatibles really work? Is there any significant
>> > difference between the controller on all these SoCs?
>>
>> Let us assume that there isn't any difference. Remember SPDIF details
>> for all of these devices is sketchy. In the A10 User Manual, it's not
>> even mentioned although devices such as the Mele A2000 which I use
>> come with the physical connector. It's only when the A20 Manual was
>> released that we see the pin details and related components. We didn't
>> see a SPDIF block spec until the H3 User Manual was released.
>>
>> Looking at the SDK code I've only seen fifo level settings to be
>> different for the sun6i family. It was this release that also showed
>> Rx rotines. The fact of the matter is we won't know until these SoCs
>> have been tested and with that in mind I'm happy to remove all
>> capabilities for now until then.
>
> The point was more that you document compatibles that you are not
> actually supporting.
>
> You've only tested it on one SoC (and it actually works only on one
> SoC, or at least with one compatible), so only document that.

Fixed,
Thanks,
CK
>
> 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.

Re: [linux-sunxi] Autoload sun4i-dma module from DT

2015-10-05 Thread Maxime Ripard 
Hi Clive,

On Wed, Sep 30, 2015 at 06:30:51AM -0700, Clive Messer wrote:
> Can we have the sun4i-dma module auto-loading from the DT reference, please?

Sure, please submit that patch to the proper maintainer, and make sure
you follow Documentation/SubmittingPatches.

Most notably, please Cc the DMAengine maintainer that will pick up
that patches, don't forget your signed-off-by tag, and it would be
better if you added a commit log to that patch.

Thanks!
Maxime


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

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


signature.asc
Description: Digital signature

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

2015-10-05 Thread Maxime Ripard 
Hi,

On Fri, Oct 02, 2015 at 01:43:08PM -0700, Stephen Boyd wrote:
> On 09/29, Maxime Ripard wrote:
> > 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 
> 
> Maybe export.h is more appropriate?

Indeed.

> > +#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);
> 
> We should include kernel.h for this macro.

Ack.

> > +
> > +   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);
> 
> and bitops.h for GENMASK

Ack.

> > +
> > +   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)
> 
> Is the only difference in this function vs the divider one that
> flag? Maybe we should make this function generic to the framework
> and pass a flag indicating closest or not.

Actually, the logic is also reversed.

The divider driver will always try to find some rate that is higher
than the one we already have, without going above than the one
requested.

Here, we're tring to be lower than the best rate, without going below
the requested rate.

> 
> > +   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))
> 
> Please use clk_hw_get_flags. I'd *really* like to kill
> __clk_get_flags() but we still have one user in omap code.

Ack.

> 
> > +   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 int clk_multiplier_set_rate(struct clk_hw *hw, unsigned long rate,
> > +  unsigned long parent_rate)
> > +{
> > +   struct clk_multiplier *mult = to_clk_multiplier(hw);
> > +   unsigned long factor = __get_mult(mult, rate, parent_rate);
> > +   unsigned long uninitialized_var(flags);
> 
> hmmm ok. We set it to 0 in other drivers.

I'll change it then.

> 
> > +   unsigned long val;
> > +
> > +   if (mult->lock)
> > +   spin_lock_irqsave(mult->lock, flags);
> 
> This needs the same "trick" that we did in the generic clock
> types to avoid sparse warnings.

The __acquire call ?

> > +
> > +   val = clk_readl(mult->reg);
> > +   val &= ~GENMASK(mult->width + mult->shift, mult->shift);
> > +   val |= factor << mult->shift;
> > +   clk_writel(val, mult->reg);
> > +
> > +   if (mult->lock)
> > +   spin_unlock_irqrestore(mult->lock,

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

2015-10-05 Thread Maxime Ripard 
The C.H.I.P. is a small SBC with an Allwinner R8, 8GB of NAND, 512MB of
RAM, USB host and OTG, a wifi / bluetooth combo chip, an audio/video jack
and two connectors to plug additional boards on top of it.

Signed-off-by: Maxime Ripard 
Reviewed-by: Hans de Goede 
---
 arch/arm/boot/dts/Makefile  |   3 +-
 arch/arm/boot/dts/sun5i-r8-chip.dts | 224 
 2 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c7adaa85ef3f..2cf7e593270a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -600,7 +600,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
sun5i-a13-q8-tablet.dtb \
-   sun5i-a13-utoo-p66.dtb
+   sun5i-a13-utoo-p66.dtb \
+   sun5i-r8-chip.dtb
 dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts 
b/arch/arm/boot/dts/sun5i-r8-chip.dts
new file mode 100644
index ..08ff70601c79
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -0,1 +1,224 @@
+/*
+ * Copyright 2015 Free Electrons
+ * Copyright 2015 NextThing Co
+ *
+ * Maxime Ripard 
+ *
+ * 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 "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "NextThing C.H.I.P.";
+   compatible = "nextthing,chip", "allwinner,sun5i-r8";
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   serial0 = 
+   serial1 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   axp209: pmic@34 {
+   reg = <0x34>;
+
+   /*
+* The interrupt is routed through the "External Fast
+* Interrupt Request" pin (ball G13 of the module)
+* directly to the main interrupt controller, without
+* any other controller interfering.
+*/
+   interrupts = <0>;
+   };
+};
+
+#include "axp209.dtsi"
+
+/*
+ * i2c1 is routed to the external pins and doesn't have any device
+ * attached to it on the C.H.I.P itself.
+ */
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   xio: gpio@38 {
+   compatible = "nxp,pcf8574a";
+   reg = <0x38>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <6 0 IRQ_TYPE_EDGE_FALLING>;
+

[linux-sunxi] [PATCH v2 2/5] ARM: sun5i: Add R8 DTSI

2015-10-05 Thread Maxime Ripard 
The R8 is very close to the A13, but it still has a few differences,
notably a composite output, which the A13 lacks.

Add a DTSI based on the A13's to hold those differences.

Signed-off-by: Maxime Ripard 
Reviewed-by: Chen-Yu Tsai 
Reviewed-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-r8.dtsi | 59 +
 1 file changed, 59 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun5i-r8.dtsi

diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
new file mode 100644
index ..915de8145007
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-r8.dtsi
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2015 Free Electrons
+ * Copyright 2015 NextThing Co
+ *
+ * Maxime Ripard 
+ *
+ * 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.
+ */
+
+#include "sun5i-a13.dtsi"
+
+/ {
+   chosen {
+   framebuffer@1 {
+   compatible = "allwinner,simple-framebuffer",
+"simple-framebuffer";
+   allwinner,pipeline = "de_be0-lcd0-tve0";
+   clocks = < 1>, <_gates 34>, <_gates 36>,
+<_gates 44>;
+   status = "disabled";
+   }; 
+   };
+};
-- 
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 v2 1/5] ARM: sunxi: Add R8 support

2015-10-05 Thread Maxime Ripard 
The R8 is a new Allwinner SoC based on the A13. While both are very
similar, there's still a few differences. Introduce a new compatible to
deal with them.

In order to have a consistent naming, instead of mentionning the allwinner
A series as the machine name, switch to sun4i/sun5i like what is done for
the other families.

Signed-off-by: Maxime Ripard 
Reviewed-by: Hans de Goede 
Acked-by: Stephen Boyd 
---
 Documentation/arm/sunxi/README  | 2 +-
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c | 3 ++-
 drivers/clk/sunxi/clk-sunxi.c   | 1 +
 4 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index 5e38e1582f95..430d279a8df3 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -25,7 +25,7 @@ SunXi family
 + Datasheet
   
http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
 
-  - Allwinner A13 (sun5i)
+  - Allwinner A13 / R8 (sun5i)
 + Datasheet
  
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
 + User Manual
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index 67da20539540..bb9b0faa919d 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -6,6 +6,7 @@ using one of the following compatible strings:
   allwinner,sun4i-a10
   allwinner,sun5i-a10s
   allwinner,sun5i-a13
+  allwinner,sun5i-r8
   allwinner,sun6i-a31
   allwinner,sun7i-a20
   allwinner,sun8i-a23
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 65bab2876343..8583a9ca86bd 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -26,10 +26,11 @@ static const char * const sunxi_board_dt_compat[] = {
"allwinner,sun4i-a10",
"allwinner,sun5i-a10s",
"allwinner,sun5i-a13",
+   "allwinner,sun5i-r8",
NULL,
 };
 
-DT_MACHINE_START(SUNXI_DT, "Allwinner A1X (Device Tree)")
+DT_MACHINE_START(SUNXI_DT, "Allwinner sun4i/sun5i Families")
.dt_compat  = sunxi_board_dt_compat,
.init_late  = sunxi_dt_cpufreq_init,
 MACHINE_END
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 413070d07b3f..9c79af0c03b2 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1196,6 +1196,7 @@ static void __init sun5i_init_clocks(struct device_node 
*node)
 }
 CLK_OF_DECLARE(sun5i_a10s_clk_init, "allwinner,sun5i-a10s", sun5i_init_clocks);
 CLK_OF_DECLARE(sun5i_a13_clk_init, "allwinner,sun5i-a13", sun5i_init_clocks);
+CLK_OF_DECLARE(sun5i_r8_clk_init, "allwinner,sun5i-r8", sun5i_init_clocks);
 CLK_OF_DECLARE(sun7i_a20_clk_init, "allwinner,sun7i-a20", sun5i_init_clocks);
 
 static const char *sun6i_critical_clocks[] __initdata = {
-- 
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 v2 0/5] ARM: sunxi: Introduce CHIP support

2015-10-05 Thread Maxime Ripard 
Hi,

Here is a serie introducing the support for the Allwinner R8 and the
Nextthing's CHIP.

Support is almost complete for the CHIP itself, the only missing part
for now is the WiFi chip that needs to be powered through two combined
regulators (AXP209's LDO3 and LDO4). The audio codec is also missing
since it's not already enabled in the DT.

Both these features will be addressed eventually.

Let me know what you think,
Maxime

Changes from v1:
  - Collected tags
  - Removed unused include files
  - Removed ipsout, dram and vcc regulators
  - Added USB power supply

Maxime Ripard (5):
  ARM: sunxi: Add R8 support
  ARM: sun5i: Add R8 DTSI
  ARM: sun5i: dt: Move uart3 pinctrl node to common DTSI
  ARM: sun5i: dt: Add UART3 CTS and RTS pins
  ARM: sun5i: Add C.H.I.P DTS

 Documentation/arm/sunxi/README  |   2 +-
 Documentation/devicetree/bindings/arm/sunxi.txt |   1 +
 arch/arm/boot/dts/Makefile  |   3 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi   |   7 -
 arch/arm/boot/dts/sun5i-r8-chip.dts | 224 
 arch/arm/boot/dts/sun5i-r8.dtsi |  59 +++
 arch/arm/boot/dts/sun5i.dtsi|  14 ++
 arch/arm/mach-sunxi/sunxi.c |   3 +-
 drivers/clk/sunxi/clk-sunxi.c   |   1 +
 9 files changed, 304 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts
 create mode 100644 arch/arm/boot/dts/sun5i-r8.dtsi

-- 
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 v2 4/5] ARM: sun5i: dt: Add UART3 CTS and RTS pins

2015-10-05 Thread Maxime Ripard 
Add a separate pinctrl node for the UART3 CTS and RTS pins shared between
the A10s and A13.

Signed-off-by: Maxime Ripard 
Reviewed-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 433c83a321ca..7d355e52efe2 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -536,6 +536,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   uart3_pins_cts_rts_a: uart3-cts-rts@0 {
+   allwinner,pins = "PG11", "PG12";
+   allwinner,function = "uart3";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};
 
timer@01c20c00 {
-- 
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 v2 3/5] ARM: sun5i: dt: Move uart3 pinctrl node to common DTSI

2015-10-05 Thread Maxime Ripard 
The uart3 pins are shared between the A10s and A13, move the pinctrl node
to the common DTSI to avoid duplication.

Signed-off-by: Maxime Ripard 
Reviewed-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 7 ---
 arch/arm/boot/dts/sun5i.dtsi  | 7 +++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 0fdabe8eb9e8..2ebd32f5bc6e 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -204,13 +204,6 @@
allwinner,pull = ;
};
 
-   uart3_pins_a: uart3@0 {
-   allwinner,pins = "PG9", "PG10";
-   allwinner,function = "uart3";
-   allwinner,drive = ;
-   allwinner,pull = ;
-   };
-
emac_pins_a: emac0@0 {
allwinner,pins = "PA0", "PA1", "PA2",
"PA3", "PA4", "PA5", "PA6",
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 78b993abbaa3..433c83a321ca 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -529,6 +529,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   uart3_pins_a: uart3@0 {
+   allwinner,pins = "PG9", "PG10";
+   allwinner,function = "uart3";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};
 
timer@01c20c00 {
-- 
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] Re: sun7i_tvd in kernel 3.4

2015-10-05 Thread Enrico 
Il giorno lunedì 5 ottobre 2015 08:18:57 UTC+2, xher...@gmail.com ha 
scritto:
>
> Yes you are right! I forgot the most important detail. I'm running a 
> MarsBoard with Linux 3.4.90 and a Debian distro. When I have a sec I will 
> post the complete uname. 
> To capture the images I used yavta and a script to convert the frames to 
> bmps. I was also able to encode videos with ffmpeg. 
> Does the CB board have all the necessary filters for the signal installed? 
> AFAIK the Olimex boards cannot do TV in because they miss all the input 
> electronics. 
>
> Rodolfo 


They miss the input filter, but i don't know if there will be just more 
noise or it will not work at all...

Enrico

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

[linux-sunxi] Re: [PATCH v5 2/5] soc: sunxi: Add driver for Allwinner Reduced Serial Bus

2015-10-05 Thread Mark Brown 
On Thu, Oct 01, 2015 at 07:57:48PM +0800, Chen-Yu Tsai wrote:
> Reduced Serial Bus (RSB) is an Allwinner proprietery interface
> used to communicate with PMICs and other peripheral ICs.

Regmap bits

Reviewed-by: Mark Brown 

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


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v5 2/5] soc: sunxi: Add driver for Allwinner Reduced Serial Bus

2015-10-05 Thread Chen-Yu Tsai 
On Sun, Oct 4, 2015 at 10:16 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Thu, Oct 01, 2015 at 07:57:48PM +0800, Chen-Yu Tsai wrote:
>> Reduced Serial Bus (RSB) is an Allwinner proprietery interface
>> used to communicate with PMICs and other peripheral ICs.
>>
>> RSB is a two-wire push-pull serial bus that supports 1 master
>> device and up to 15 active slave devices.
>>
>> Signed-off-by: Chen-Yu Tsai 
>
> Acked-by: Maxime Ripard 

Slightly confused. Are we merging this through your tree or directly
through arm-soc?

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

2015-10-05 Thread wens Tsai 
On Thu, Oct 1, 2015 at 6:13 PM, Maxime Ripard
 wrote:
> On Wed, Sep 30, 2015 at 12:42:43PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 30-09-15 03:52, wens Tsai wrote:
>> >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.
>>
>> Right, I happened to be looking the same thing recently.
>>
>> I've recently bought a bunch of 2nd hand q8 tablets, and I've
>> pushed all the fex files I got from them to sunxi-boards yesterday.
>>
>> Looking at A23 devices only the ippo_q8h_v1.0.fex and
>> ippo_q8h_v1.2.fex files set VDD-SYS to 1.2 volt, the other
>> 7 use the recommended 1.1V value. Also note that the gt90h-v4
>> tablet which I have does not work with a VDD-SYS of 1.2 volt,
>> it only works with a VDD-SYS of 1.1 volt.
>>
>> I've tested my ippo_q8h_v1.2 and it works fine with a VDD-SYS
>> of 1.1 volt.
>>
>> Looking at A33 devices there are 2 outliers the TZX-723Qa4 and
>> astar_mid756.fex both set VDD-SYS to 1.26 V, rather then to 1.1 V.
>> The other 6 all use 1.1V so I believe that 1.1V indeed is a better
>> default.
>>
>> >Perhaps we could update the defconfigs with the values from
>> >the fex files.
>>
>> I think that we should switch the default to 1.1V and then if we see
>> any issues set it to 1.2V in individual defconfig-s.
>
> Agreed.
>
>> >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.
>>
>> I think it is best to set a range in the dts file and the kernel
>> just inherit whatever u-boot has set up, this way we don't end
>> up changing vdd-sys half-way through boot, and we only have one
>> place where to tweak it if necessary.
>
> And here too :)

Sounds good.

On the side, I'm wondering if we can put the voltage ranges for
important regulators directly in the axp dtsi. It's likely most
boards follow the reference design, and will use the regulators
accordingly.

We could also do this for A31/A31s paired with AXP221/AXP221s.
Since I already have a patch for axp221.dtsi, I can incorporate
the changes.

Let me know what you think.


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.