[linux-sunxi] Issue with high-speed UART on Allwinner A20

[Piotr Król]

Hi all,
we have custom board with Allwinner A20 and we try to configure
ttyS1-ttyS7 to use high speed configuration and set 921600 using:

stty -F /dev/ttyS1 921600

Unfortunately max what we can see using oscilloscope is 75. Since source
clock for UART defined by device tree on this platform is osc24M (24MHz
oscillator):

# cat /sys/class/tty/ttyS1/uartclk 
2400

If this is correct then only way to get 75 is 64 divisor (CLK_RAT_N and
CLK_RAT_M). Not sure if value in sysfs should reflect that:

# cat /sys/class/tty/ttyS1/custom_divisor 
0

I also can't change that value from root account getting 'permission denied'.

Anyone know what maybe issue with speed capped to 75 ?

I found that some people had problems with error rate on higher speed
[1], but it was for legacy kernel. Is there a way to change APB1 clock
in device tree to something higher ? At this point in sun7i-a20.dtsi I
see pll6 which also seems to use osc24M.

Does anyone had experience in setting higher speed for UARTs using A20
chip ? What should approach for that ?

We have 4.7 kernel put together with uboot and rootfs using buildroot.
If I confuse something please let me know.

[1] http://linux-sunxi.narkive.com/thhIDej9/a20-high-speed-uart-problem

-- 
Best Regards,
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_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.

[linux-sunxi] Re: [PATCH v4 5/7] arm64: dts: add Allwinner A64 SoC .dtsi

[Maxime Ripard]

Hi,

On Mon, Aug 08, 2016 at 06:21:47PM +0100, Andre Przywara wrote:
> + pmu {
> + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
> + interrupts = ,
> +  ,
> +  ,
> +  ;
> + interrupt-affinity = <>,
> +  <>,
> +  <>,
> +  <>;
> + };

The indentation looks off.

> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x4000 0>;
> + };
> +
> + gic: interrupt-controller@1c81000 {
> + compatible = "arm,gic-400";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> +
> + reg = <0x01c81000 0x1000>,
> +   <0x01c82000 0x2000>,
> +   <0x01c84000 0x2000>,
> +   <0x01c86000 0x2000>;
> + interrupts =  +   (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts =  + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +   + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +   + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +   + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + /include/ "sun50i-a64-clocks.dtsi"
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + pio: pinctrl@1c20800 {
> + compatible = "allwinner,sun50i-a64-pinctrl";
> + reg = <0x01c20800 0x400>;
> + interrupts = ,
> +  ,
> +  ;
> + clocks = <_gates 69>;
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + uart0_pins_a: uart0@0 {
> + allwinner,pins = "PB8", "PB9";
> + allwinner,function = "uart0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart0_pins_b: uart0@1 {
> + allwinner,pins = "PF2", "PF3";
> + allwinner,function = "uart0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart1_2pins: uart1_2@0 {
> + allwinner,pins = "PG6", "PG7";
> + allwinner,function = "uart1";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart1_4pins: uart1_4@0 {
> + allwinner,pins = "PG6", "PG7", "PG8", "PG9";
> + allwinner,function = "uart1";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart2_2pins: uart2_2@0 {
> + allwinner,pins = "PB0", "PB1";
> + allwinner,function = "uart2";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart2_4pins: uart2_4@0 {
> + allwinner,pins = "PB0", "PB1", "PB2", "PB3";
> + allwinner,function = "uart2";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart3_pins_a: uart3@0 {
> + allwinner,pins = "PD0", "PD1";
> + allwinner,function = "uart3";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart3_2pins_b: uart3_2@1 {
> + allwinner,pins = "PH4", "PH5";
> + allwinner,function = "uart3";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart3_4pins_b: uart3_4@1 

[linux-sunxi] Re: [PATCH v4 1/7] arm64: sunxi: Kconfig: add essential pinctrl driver

[Maxime Ripard]

On Mon, Aug 08, 2016 at 06:21:43PM +0100, Andre Przywara wrote:
> The pinctrl driver is essential for the Allwinner SoCs to work.
> Add the driver's config symbol to the Kconfig entry to always compile
> it in. We can't use the arm approach to make the _driver's_ Kconfig
> symbol def_bool, because we lack the MACH_* symbols in arm64.
> That line was in the original pinctrl driver patch, but got removed
> to avoid the dependency on the Kconfig patch [1].
> Also add the general PINCTRL symbol, which isn't selected automatically
> for the same reason.
> 
> Reported-by: Jeroen Dekien 
> Signed-off-by: Andre Przywara 
> 
> [1]: 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414086.html

Applied, thanks

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel 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: PGP signature

[linux-sunxi] Re: [PATCH 1/9] mfd: axp20x: Add bindings for AXP806 PMIC

[Rob Herring]

On Sun, Aug 21, 2016 at 10:11:17AM +0800, Chen-Yu Tsai wrote:
> This patch adds the basic and regulator bindings for the X-Powers AXP809
> PMIC.

Looks like you're adding the AXP806 to me.

> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 28 
> ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 585a95546288..8f3ad9ab4637 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -10,7 +10,8 @@ axp809 (X-Powers)
>  
>  Required properties:
>  - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> -   "x-powers,axp221", "x-powers,axp223", "x-powers,axp809"
> +   "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> +   "x-powers,axp809"

Reformat this to one valid combination per line.

>  - reg: The I2C slave address or RSB hardware address for the AXP chip
>  - interrupt-parent: The parent interrupt controller
>  - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> @@ -47,7 +48,6 @@ Optional properties for DCDC regulators:
> probably makes sense for HiFi audio related
> applications that aren't battery constrained.
>  
> -
>  AXP202/AXP209 regulators, type, and corresponding input supply names:
>  
>  Regulator  TypeSupply Name Notes
> @@ -86,6 +86,30 @@ LDO_IO1: LDO   : ips-supply
> : GPIO 1
>  RTC_LDO  : LDO   : ips-supply: always on
>  DRIVEVBUS: Enable output : drivevbus-supply  : external regulator
>  
> +AXP806 regulators, type, and corresponding input supply names:
> +
> +Regulator  TypeSupply Name Notes
> +-  --- -
> +DCDCA: DC-DC buck: vina-supply   : poly-phase 
> capable
> +DCDCB: DC-DC buck: vinb-supply   : poly-phase 
> capable
> +DCDCC: DC-DC buck: vinc-supply   : poly-phase 
> capable
> +DCDCD: DC-DC buck: vind-supply   : poly-phase 
> capable
> +DCDCE: DC-DC buck: vine-supply   : poly-phase 
> capable
> +ALDO1: LDO   : aldoin-supply : shared supply
> +ALDO2: LDO   : aldoin-supply : shared supply
> +ALDO3: LDO   : aldoin-supply : shared supply
> +BLDO1: LDO   : bldoin-supply : shared supply
> +BLDO2: LDO   : bldoin-supply : shared supply
> +BLDO3: LDO   : bldoin-supply : shared supply
> +BLDO4: LDO   : bldoin-supply : shared supply
> +CLDO1: LDO   : cldoin-supply : shared supply
> +CLDO2: LDO   : cldoin-supply : shared supply
> +CLDO3: LDO   : cldoin-supply : shared supply
> +SW   : On/Off Switch : swin-supply
> +
> +Additionally, the AXP806 DC-DC regulators support poly-phase arrangements
> +for higher output current. The possible groupings are: A+B, A+B+C, D+E.
> +
>  AXP809 regulators, type, and corresponding input supply names:
>  
>  Regulator  TypeSupply Name Notes
> -- 
> 2.9.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: [PATCH 3/9] regulator: core: Try full range when adjusting regulators to constraints

[Mark Brown]

On Tue, Aug 23, 2016 at 12:17:23PM +0800, Chen-Yu Tsai wrote:
> On Tue, Aug 23, 2016 at 2:09 AM, Mark Brown  wrote:

> > Sure, but the constraints also say that you can do 1.32V which the
> > system is not physically capable of delivering.  That's not a good sign
> > for the constraints, it suggests that at least the capabilities of the
> > regulator have not been taken into consideration when setting up the
> > constraints.

> So to be clear, the constraints should be the intersection of the
> recommended operating parameters of the consumer and the regulator's
> output, with the voltage/current steps taken in to consideration.

The constraints are there to say what the *system* can deliver.  That
includes the limitations of the consumers, the regulators and the
physical design of the board.  Just as one shouldn't just throw in the
maximum voltage range that the regulator can deliver one also shouldn't
just use the maximum voltage range a consumer can support for similar
reasons.

-- 
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: PGP signature

[linux-sunxi] Re: [PATCH v2] mmc: sunxi: Handle the 'New Timings'

[Maxime Ripard]

Hi Mark,

On Mon, Aug 01, 2016 at 04:30:19PM +0100, Mark Rutland wrote:
> On Mon, Aug 01, 2016 at 03:10:29PM +0200, Jean-Francois Moine wrote:
> > Some MMC devices as mmc2 in the A83T or mmc1 and mmc2 in the H3 have
> > a 'New Timings' mode.
> > Set this capacity in the DT and use it when possible.
> 
> What exactly is this "New Timings" mode?
> 
> Why do we wnat to set it? Improved performance, power?

Allwinner calls it under a rather generic name: "new mode" (which is
of course the opposite of the old mode).

In the old mode, the rate and phase controls were all handled by the
functional clock feeding the MMC controller.

In the new mode, the MMC controller itself is able to do some sort of
auto-calibration to adjust the rate and phase of the clock output on
the MMC bus.

> Is it *necessary* to use it?

Yes. Allwinner recommends to use it to enhance the compatibility with
MMC cards, and they say that it also improves the performances, even
though no one really checked. The main point for us at the moment is
that some eMMCs at least require the new mode to operate properly.

> > Signed-off-by: Jean-Francois Moine 
> > ---
> > I don't know if this mode works or is needed at 25MHz.
> > ---
> >  Documentation/devicetree/bindings/mmc/sunxi-mmc.txt |  1 +
> >  drivers/mmc/host/sunxi-mmc.c| 21 
> > +++--
> >  2 files changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt 
> > b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > index 4bf41d8..a541bf4 100644
> > --- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > @@ -19,6 +19,7 @@ Optional properties:
> >   - reset-names : must contain "ahb"
> >   - for cd, bus-width and additional generic mmc parameters
> > please refer to mmc.txt within this directory
> > + - allwinner,new-timings: the controller may accept the "New Timings" mode
> 
> It's not at all clear to me what this means. This needs a better
> description.
> 
> Which devices have this? Can we determine this based on compatible
> string?

On some SoCs, yes, on some, no.

The older SoCs (everything up to A80) only have the old mode, so the
compatible works there. The newer SoCs (H3, A64) support the new mode
on all their MMC controllers, so the compatible works too. However, in
the SoC Jean-Francois is currently working on, the A83T, the new mode
is only found in one (over three) controller.

So I really think we need a property to express this, at least in the
A83T case.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel 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: PGP signature

[linux-sunxi] [PATCH RESEND] mmc: sunxi: Check the value returned by clk_round_rate

[Jean-Francois Moine]

clk_round_rate() may return an error. Check it.

Signed-off-by: Jean-Francois Moine 
Acked-by: Maxime Ripard 
---
Rebase on linux-next
---
 drivers/mmc/host/sunxi-mmc.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 2ec91ce..142ab3f 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -692,7 +692,8 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host 
*host,
 static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
  struct mmc_ios *ios)
 {
-   u32 rate, rval, clock = ios->clock;
+   long rate;
+   u32 rval, clock = ios->clock;
int ret;
 
/* 8 bit DDR requires a higher module clock */
@@ -701,13 +702,18 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
*host,
clock <<= 1;
 
rate = clk_round_rate(host->clk_mmc, clock);
-   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %d\n",
+   if (rate < 0) {
+   dev_err(mmc_dev(host->mmc), "error rounding clk to %d: %ld\n",
+   clock, rate);
+   return rate;
+   }
+   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %ld\n",
clock, rate);
 
/* setting clock rate */
ret = clk_set_rate(host->clk_mmc, rate);
if (ret) {
-   dev_err(mmc_dev(host->mmc), "error setting clk to %d: %d\n",
+   dev_err(mmc_dev(host->mmc), "error setting clk to %ld: %d\n",
rate, ret);
return ret;
}
-- 
2.9.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.