Re: [linux-sunxi] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.

[Olliver Schinagl]

Hey Lub,

On 28-02-17 07:43, Lyubcho Haralanov wrote:

It seems like what Marcus suggested (turning off LDO3, setting voltage
to minimum 0.7V, then turning on LDO3 and then increasing the voltage to
2.8V) works fine with the LIME2:

i2c mw 0x34 0x12 0x1f
i2c mw 0x34 0x29 0x00
i2c mw 0x34 0x12 0x5f
i2c mw 0x34 0x29 0x58


Yeah, I ran the same tests and even 0x7f (3.6V) 'works fine'. The only 
problem herein is, that this solution can't be simply rolled out to all 
boards I think. (All meaning the CHIP, cubieboard etc). For one, it 
would change current behavior of boards that are not broken.


But more importantly, how does electronics behave that get this (fast) 
ramp up, rather than instant on power? Are there people using LDO3 with 
the assumption power is immediately available?


So I think this alternate behavior should live behind a toggle, which is 
enabled for all boards that need it. (Currently all Olimex boards?)


Olliver



I'm yet to test the other designs. Nothing is final at the moment since
we are still testing, but probably the future hardware revisions would
have 4.7 uF on LDO3 and LDO4 instead of 10 uF (LDO1 is always on, LDO2
is connected to the memory and turning it off naturally kills the board).

On Monday, February 27, 2017 at 9:11:18 PM UTC+2, oliver wrote:

Hey Lub

On , Lyubcho Haralanov wrote:
> Hi,
>
> VR1 is not assembled (NA). It is not placed. Only pads are
provided in
> case you don't want to power the camera from the AXP209 but
> externally, in which case you should place VR1 and disconnect the SMT
> jumper LDO3_2.8V_E.
>
> By original design the camera is powered only by the AXP209.
>
> Best regards,
> Lub

Thanks for the explanation of the EVB :)

Can you also elaborate on the 10 uF for all designs however?

Some extra information, I ran some current tests on the LDO3
power-up/shutdown and while 200 mA max sourcing current is never
reached, the chip does shut down before the max voltage has been
reached. For example setting ldo3 to max ( i2c mw 0x34 0x29 0x7f ) we
get screenshot 3v6.png where we can see the max voltage is only 2.32.

Repeating the same test however with 2.3 V ( i2c mw 0x34 0x29 0x40 )
yields 2V3.png, which also causes an AXP209 failure. This supprised
me a
little, as I expected the 2.3V to actually work, as that is the voltage
we failed before. Also failure happens sooner and max current is lower.

After some trial and error, we find that 1.95 V, in this case, still
works, but that I suppose really depends on the capacitance, but by no
means reliably!

Due to the small timebase (50 uS) we cannot clearly see the power rail
dropping, but be assured, for the 2V3 and 3V6, power slowly drops as
capacitors discharge.


While this can and should be solved in hardware (smaller capacitor)
there's hundreds of thousands of boards in the wild with this
configuration and thus a software solution is needed.

The AXP209 does have slew rate control, however this does not apply
when
toggling the LDO3 output switch. What I thus propose, is a quirk-flag,
for buggy boards, where we set the minimal voltage, enable power and
than set the desired voltage, letting the internal slew rate control
slowly ramp up voltage.



What I still would love to hear from you guys, is why this could be
happening. The spec-sheet does say 200 mA of sourcing capability.
But it
seems this is not exactly true? At least not when toggling LDO3 via
reg12 for sure.

Olliver

>
> On Monday, February 27, 2017 at 2:33:08 PM UTC+2, Marcus Weseloh
> wrote:
>
>> Hi,
>>
>> 2017-02-27 13:11 GMT+01:00 oliver :
>>
>>> One is to remove C185 (10 microF) and the problem went away.
>>> Looking at other designs, cubieboard 1 for example, uses the same
>>> layout, but only 4.7 microF. So it seems that charging of all the
>>> capacitance (input C106) the board itself, the output (C185) may
>>> be too much for the AXP209.
>>
>> Great, that confirms my suspicion that the capacitance is the main
>> problem on the A20-SOM. The reference design for the A20 from
>> Allwinner also suggests 4.7uF on LDO3, Olimex probably used 10uF
>> there to keep the BOM smaller?
>>
>> At least on the A20-SOM-EVB we have another problem though (as
>> explained in an earlier mail): When then SOM is attached to the EVB,
>> the LDO3_2.8V rail on the SOM is powered from the EVB via +5V and a
>> DC converter. Even with the LDO3 voltage set to it's minimum,
>> turning on LDO3 shuts down the AXP immediately. Probably because the
>> AXP sees an external voltage applied to it's input, it might even
>> see reverse current flowing into it's ouput. I'd say that this is a
>> design flaw on the EVB. So at least on the A20-SOM-EVB combination,
  

[linux-sunxi] Re: [PATCH v5 2/3] nvmem: sunxi-sid: add support for H3's SID controller

[Icenowy Zheng]

28.02.2017, 14:43, "Maxime Ripard" :
> On Tue, Feb 28, 2017 at 03:27:14AM +0800, Icenowy Zheng wrote:
>>  The H3 SoC have a bigger SID controller, which has its direct read
>>  address at 0x200 position in the SID block, not 0x0.
>>
>>  Also, H3 SID controller has some silicon bug that makes the direct read
>>  value wrong at cold boot, add code to workaround the bug. (This bug has
>>  already been fixed on A64 and later SoCs)
>>
>>  Signed-off-by: Icenowy Zheng 
>
> Acked-by: Maxime Ripard 

Who will finally apply these patches?

I have seen that you are one of the maintainers of NVMEM subsystem.

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

[linux-sunxi] Re: [PATCH 2/4] clk: sunxi-ng: Add sun7i-a20 CCU driver

[Maxime Ripard]

Hi,

On Mon, Feb 27, 2017 at 11:09:12PM +0200, Priit Laes wrote:
> Introduce a clock controller driver for sun7i A20 SoC.
> 
> Signed-off-by: Priit Laes 
> ---
>  drivers/clk/sunxi-ng/Kconfig |   11 +
>  drivers/clk/sunxi-ng/Makefile|1 +
>  drivers/clk/sunxi-ng/ccu-sun7i-a20.c | 1068 
> ++
>  drivers/clk/sunxi-ng/ccu-sun7i-a20.h |  121 
>  4 files changed, 1201 insertions(+)
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun7i-a20.c
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun7i-a20.h
> 
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> index 695bbf9..4f436ab 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -85,6 +85,17 @@ config SUN6I_A31_CCU
>   select SUNXI_CCU_PHASE
>   default MACH_SUN6I
>  
> +config SUN7I_A20_CCU
> + bool "Support for the Allwinner A20 CCU"
> + select SUNXI_CCU_DIV
> + select SUNXI_CCU_MULT
> + select SUNXI_CCU_NK
> + select SUNXI_CCU_NKM
> + select SUNXI_CCU_NM
> + select SUNXI_CCU_MP
> + select SUNXI_CCU_PHASE
> + default MACH_SUN7I
> +
>  config SUN8I_A23_CCU
>   bool "Support for the Allwinner A23 CCU"
>   select SUNXI_CCU_DIV
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
> index 6feaac0..bedda5b 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_SUNXI_CCU_MP)  += ccu_mp.o
>  obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
>  obj-$(CONFIG_SUN5I_CCU)  += ccu-sun5i.o
>  obj-$(CONFIG_SUN6I_A31_CCU)  += ccu-sun6i-a31.o
> +obj-$(CONFIG_SUN7I_A20_CCU)  += ccu-sun7i-a20.o
>  obj-$(CONFIG_SUN8I_A23_CCU)  += ccu-sun8i-a23.o
>  obj-$(CONFIG_SUN8I_A33_CCU)  += ccu-sun8i-a33.o
>  obj-$(CONFIG_SUN8I_H3_CCU)   += ccu-sun8i-h3.o
> diff --git a/drivers/clk/sunxi-ng/ccu-sun7i-a20.c 
> b/drivers/clk/sunxi-ng/ccu-sun7i-a20.c
> new file mode 100644
> index 000..90d2f13
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun7i-a20.c
> @@ -0,0 +1,1068 @@
> +/*
> + * Copyright (c) 2017 Priit Laes. All rights reserved.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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 "ccu_common.h"
> +#include "ccu_reset.h"
> +
> +#include "ccu_div.h"
> +#include "ccu_gate.h"
> +#include "ccu_mp.h"
> +#include "ccu_mult.h"
> +#include "ccu_nk.h"
> +#include "ccu_nkm.h"
> +#include "ccu_nkmp.h"
> +#include "ccu_nm.h"
> +#include "ccu_phase.h"
> +
> +#include "ccu-sun7i-a20.h"
> +
> +/*
> + * PLL1 - Core clock
> + *
> + * TODO: sigma-delta pattern bits 2 & 3
> + * TODO: PLL1 tuning register

I don't think we need those TODO's at all, and these comments too. If
the clock name is good enough (and it is), it's redundant.

> + */
> +static struct ccu_nkmp pll_core_clk = {
> + .enable = BIT(31),
> + .n  = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
> + .k  = _SUNXI_CCU_MULT(4, 2),
> + .m  = _SUNXI_CCU_DIV(0, 2),
> + .p  = _SUNXI_CCU_DIV(16, 2),
> + .common = {
> + .reg= 0x000,
> + .hw.init= CLK_HW_INIT("pll-core",
> +   "hosc",
> +   _nkmp_ops,
> +   0),
> + },
> +};
> +
> +/* PLL2 - Audio clock */
> +static struct ccu_nm pll_audio_base_clk = {
> + .enable = BIT(31),
> + .n  = _SUNXI_CCU_MULT_OFFSET(8, 7, 0),
> + .m  = _SUNXI_CCU_DIV_OFFSET(0, 5, 0),
> + .common = {
> + .reg= 0x008,
> + .hw.init= CLK_HW_INIT("pll-audio-base",
> +   "hosc",
> +   _nm_ops,
> +   0),
> + },
> +
> +};

You're forgetting the post-divider here

> +/* TODO: pll8 gpu 0x040 */

Please add all the clocks.

> +/* BIT(21 .. 31) - reserved */

I'm not sure we need those comments either.

> +/*
> + * TODO: SATA clock also supports external clock as parent.
> + * Currently we default to using PLL6 SATA gate.
> + */

Which external clock? It should be modelled anyway. If we have a
dependency on some other clock, it should be in our DT binding, and
listed in the mux there.

Otherwise, the clock framework will not be able to deal with that mux
being already set by the bootloader, and if we need to support that
clock in 

[linux-sunxi] Re: [PATCH v5 2/3] nvmem: sunxi-sid: add support for H3's SID controller

[Maxime Ripard]

On Tue, Feb 28, 2017 at 04:35:31PM +0800, Icenowy Zheng wrote:
> 
> 
> 28.02.2017, 14:43, "Maxime Ripard" :
> > On Tue, Feb 28, 2017 at 03:27:14AM +0800, Icenowy Zheng wrote:
> >>  The H3 SoC have a bigger SID controller, which has its direct read
> >>  address at 0x200 position in the SID block, not 0x0.
> >>
> >>  Also, H3 SID controller has some silicon bug that makes the direct read
> >>  value wrong at cold boot, add code to workaround the bug. (This bug has
> >>  already been fixed on A64 and later SoCs)
> >>
> >>  Signed-off-by: Icenowy Zheng 
> >
> > Acked-by: Maxime Ripard 
> 
> Who will finally apply these patches?
> 
> I have seen that you are one of the maintainers of NVMEM subsystem.

Srinivas usually merges the patches.

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

Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command

[Andre Przywara]

Hi,

On 28/02/17 03:08, Siarhei Siamashka wrote:
> On Mon, 27 Feb 2017 20:55:53 +
> Andre Przywara  wrote:
> 
>> On Mon, 27 Feb 2017 05:48:48 +0200
>> Siarhei Siamashka  wrote:
>>
>>> On Mon, 27 Feb 2017 02:22:08 +
>>> André Przywara  wrote:
>>>   
 On 27/02/17 01:20, Siarhei Siamashka wrote:  
> On Wed, 22 Feb 2017 17:08:47 +
> Andre Przywara  wrote:
> 
>> If an SoC has the "secure boot" fuse burned, it will enter FEL
>> mode in non-secure state, so with the SCR.NS bit set. Since in
>> this mode the secure/non-secure state restrictions are actually
>> observed, we suffer from several restrictions:
>> - No access to the SID information (both via memory mapped and
>> "register").
>> - No access to secure SRAM (SRAM A2 on H3/A64/H5).
>> - No access to the secure side of the GIC, so it can't be
>> configured to be accessible from non-secure world.
>> - No RMR trigger on ARMv8 cores to bring the core into AArch64.
>> Those limitations make a board pretty useless for many
>> applications.
>>
>> However it has been found out that a simple "smc" call will
>> immediately return from monitor mode, but with the NS bit
>> cleared, so access to all secure peripherals is suddenly
>> possible.
>>
>> Add a sunxi-fel command called "smc" which will issue exactly
>> this instruction to make those boards useful in "secure boot"
>> FEL mode.
>>
>> It should be given early in the command queue to given
>> subsequent code full access to the system:
>> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ...
>>
>> Signed-off-by: Andre Przywara 
>>
>> ---
>> Hi,
>>
>> if that sounds vaguely useful (it definitedly is for me to get
>> the Remix Mini PC started), I can follow the Github process if
>> you prefer that.
>>
>> Cheers,
>> Andre.
>
> Hi Andre,
>
> Why don't we just do this automatically without adding a new
> special command?
>
> We are not allowed to read the SCR register for detecting this
> state, right? But can we still use some other detection method?
> For example, maybe try to read SID and assume that we need the
> SMC workaround if it reads back as zero?

 Yes, indeed I was thinking about exactly that ;-)
 From actually using this feature I realized that its usage is error
 prone: non-secure boards crash on calling it, secure board just
 don't work without it.
 And indeed there is no architectural way of checking whether you are
 running secure or non-secure (as reading a secure-only register like
 NSACR or SCR will trap, which means crash in our case).

 So (trying to) read the SID is indeed the best workaround I came up
 with: If it's all zero, we are probably secure and need the smc.
 There is still a slight chance that the SID is all zero even on a
 non-secure board (I think this was the case for some older SoCs?),
 so maybe we need an option to suppress using this heuristic?  
>>>
>>> At least we should report every taken action in the sunxi-fel verbose
>>> log (about the SMC workaround getting applied) because it greatly
>>> simplifies troubleshooting.
>>>
>>> And IMHO having any options to suppress this workaround is a bit
>>> premature until we encounter a real A64/H64/H5 chip where it fails
>>> in the wild.
>>>
>>> Another variant of the detection heuristics could just use SRAM A2
>>> (well, not quite "SRAM", but the OpenRISC reset vector area). I'm
>>> getting the following output on my Jide Remix Mini (Allwinner H64):
>>>
>>> $ ./sunxi-fel readl 0x40004
>>> 0x
>>>
>>> $ ./sunxi-fel smc
>>>
>>> $ ./sunxi-fel readl 0x40004
>>> 0x1500
>>>
>>> We are either reading zero from there, or it is a hardwired OpenRISC
>>> instruction L.NOP.  
>>
>> Yeah, that sounds even better, but would be restricted to SoCs which
>> have an OpenRISC. Not sure if that is actually a super set of
>> secure-boot capable chips.
> 
> There is no obligation to implement exactly the same solution for every
> SoC.
> 
>> Only thing is that we need to add the address of "secure SRAM" to the
>> per-SoC data structure, but that may become useful for other purposes
>> in the future as well, I guess.
> 
> We can even implement it as a simple check with just a single address of
> a word (or even byte), which needs to be compared with zero. Some SoCs
> may make use of NOPs from the delay slots of the OpenRISC reset vector
> in SRAM A2. The other SoCs may use their SID.

That sounds like a good solution, yes.

> Once we come to an agreement, could you please submit a pull request
> at github? We have travis-ci enabled there, so patches are at least
> automatically compile tested (on non-Linux systems too).

Yes, will do, but please don't your 

[linux-sunxi] Re: [U-Boot] [PATCH v3 1/3] sunxi: add basic V3s support

[Jagan Teki]

On Mon, Feb 13, 2017 at 12:44 PM, Maxime Ripard
 wrote:
> On Sat, Feb 11, 2017 at 07:11:00PM +0800, Icenowy Zheng wrote:
>> Basic U-Boot support is now present for V3s.
>>
>> Some memory addresses are changed specially for V3s, as the original
>> address map cannot fit into a so small DRAM.
>>
>> As the DRAM controller code needs a big refactor, the SPL support is
>> disabled in this version.
>>
>> Signed-off-by: Icenowy Zheng 
>
> Acked-by: Maxime Ripard 


Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

-- 
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: [U-Boot] [PATCH v3 3/3] sunxi: add support for Lichee Pi Zero

[Jagan Teki]

On Sat, Feb 11, 2017 at 4:41 PM, Icenowy Zheng  wrote:
> Lichee Pi Zero is a development board with a V3s SoC.
>
> Add support for it.

Add some details about board/features ?

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

-- 
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 1/3] phy: sun4i-usb: support automatically switch PHY0 route to MUSB/HCI

[Icenowy Zheng]

On newer Allwinner SoCs (H3 and after), the PHY0 node is routed to both
MUSB controller for peripheral and host support (the host support is
slightly broken), and a pair of EHCI/OHCI controllers, which provide a
better support for host mode.

Add support for automatically switch the route of PHY0 according to the
status of dr_mode and id det pin.

Only H3 have this function enabled in this patch, as further SoCs will
be tested later and then have it enabled.

Signed-off-by: Icenowy Zheng 
---
 drivers/phy/phy-sun4i-usb.c | 55 +++--
 1 file changed, 38 insertions(+), 17 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index a21b5f24a340..8b91afe8f42d 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -49,12 +49,14 @@
 #define REG_PHYBIST0x08
 #define REG_PHYTUNE0x0c
 #define REG_PHYCTL_A33 0x10
-#define REG_PHY_UNK_H3 0x20
+#define REG_PHY_OTGCTL 0x20
 
 #define REG_PMU_UNK1   0x10
 
 #define PHYCTL_DATABIT(7)
 
+#define OTGCTL_ROUTE_MUSB  BIT(0)
+
 #define SUNXI_AHB_ICHR8_EN BIT(10)
 #define SUNXI_AHB_INCR4_BURST_EN   BIT(9)
 #define SUNXI_AHB_INCRX_ALIGN_EN   BIT(8)
@@ -110,6 +112,7 @@ struct sun4i_usb_phy_cfg {
u8 phyctl_offset;
bool dedicated_clocks;
bool enable_pmu_unk1;
+   bool phy0_dual_route;
 };
 
 struct sun4i_usb_phy_data {
@@ -271,23 +274,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val & ~2, phy->pmu + REG_PMU_UNK1);
}
 
-   if (data->cfg->type == sun8i_h3_phy) {
-   if (phy->index == 0) {
-   val = readl(data->base + REG_PHY_UNK_H3);
-   writel(val & ~1, data->base + REG_PHY_UNK_H3);
-   }
-   } else {
-   /* Enable USB 45 Ohm resistor calibration */
-   if (phy->index == 0)
-   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
+   /* Enable USB 45 Ohm resistor calibration */
+   if (phy->index == 0)
+   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
 
-   /* Adjust PHY's magnitude and rate */
-   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
+   /* Adjust PHY's magnitude and rate */
+   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
 
-   /* Disconnect threshold adjustment */
-   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
-   data->cfg->disc_thresh, 2);
-   }
+   /* Disconnect threshold adjustment */
+   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
+   data->cfg->disc_thresh, 2);
 
sun4i_usb_phy_passby(phy, 1);
 
@@ -486,6 +482,26 @@ static const struct phy_ops sun4i_usb_phy_ops = {
.owner  = THIS_MODULE,
 };
 
+static void sun4i_usb_phy0_reroute(struct sun4i_usb_phy_data *data, int id_det)
+{
+   u32 regval;
+
+   if (data->dr_mode == USB_DR_MODE_HOST)
+   id_det = 0; /* Force host */
+   if (data->dr_mode == USB_DR_MODE_PERIPHERAL)
+   id_det = 1; /* Force peripheral*/
+
+   regval = readl(data->base + REG_PHY_OTGCTL);
+   if (id_det == 0) {
+   /* Host mode. Route phy0 to EHCI/OHCI */
+   regval &= ~OTGCTL_ROUTE_MUSB;
+   } else {
+   /* Peripheral mode. Route phy0 to MUSB */
+   regval |= OTGCTL_ROUTE_MUSB;
+   }
+   writel(regval, data->base + REG_PHY_OTGCTL);
+}
+
 static void sun4i_usb_phy0_id_vbus_det_scan(struct work_struct *work)
 {
struct sun4i_usb_phy_data *data =
@@ -511,6 +527,10 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
data->force_session_end = false;
 
if (id_det != data->id_det) {
+   /* Re-route PHY0 if necessary */
+   if (data->cfg->phy0_dual_route)
+   sun4i_usb_phy0_reroute(data, id_det);
+
/* id-change, force session end if we've no vbus detection */
if (data->dr_mode == USB_DR_MODE_OTG &&
!sun4i_usb_phy0_have_vbus_det(data))
@@ -700,7 +720,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
return PTR_ERR(phy->reset);
}
 
-   if (i) { /* No pmu for usbc0 */
+   if (i || data->cfg->phy0_dual_route) { /* No pmu for musb */
snprintf(name, sizeof(name), "pmu%d", i);
res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
@@ -825,6 +845,7 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.disc_thresh = 3,
.dedicated_clocks = true,
.enable_pmu_unk1 = 

[linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: add usb_otg and OHCI/EHCI for usbc0 on H3

[Icenowy Zheng]

Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI
or MUSB controller.

Add device nodes for these controllers.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 27780b97c863..bc9a53edf371 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -206,6 +206,19 @@
#size-cells = <0>;
};
 
+   usb_otg: usb@01c19000 {
+   compatible = "allwinner,sun8i-h3-musb";
+   reg = <0x01c19000 0x0400>;
+   clocks = < CLK_BUS_OTG>;
+   resets = < RST_BUS_OTG>;
+   interrupts = ;
+   interrupt-names = "mc";
+   phys = < 0>;
+   phy-names = "usb";
+   extcon = < 0>;
+   status = "disabled";
+   };
+
usbphy: phy@01c19400 {
compatible = "allwinner,sun8i-h3-usb-phy";
reg = <0x01c19400 0x2c>,
@@ -238,6 +251,29 @@
#phy-cells = <1>;
};
 
+   ehci0: usb@01c1a000 {
+   compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
+   reg = <0x01c1a000 0x100>;
+   interrupts = ;
+   clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>;
+   resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
+   phys = < 0>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
+   ohci0: usb@01c1a400 {
+   compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
+   reg = <0x01c1a400 0x100>;
+   interrupts = ;
+   clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>,
+< CLK_USB_OHCI0>;
+   resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
+   phys = < 0>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
ehci1: usb@01c1b000 {
compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
reg = <0x01c1b000 0x100>;
-- 
2.11.1

-- 
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 1/9] pwm: sunxi: Use regmap API for register access.

[Maxime Ripard]

On Mon, Feb 27, 2017 at 02:22:02PM +0300, Siarhei Volkau wrote:
> Hi, Maxime
> 
> 2017-02-27 12:17 GMT+03:00 Maxime Ripard :
> > Hi Siarhei,
> >
> > On Fri, Feb 24, 2017 at 08:41:08AM +0300, lis8...@gmail.com wrote:
> >> From: Siarhei Volkau 
> >>
> >> The patch replaces iomem register access routines to regmap
> >> equivalents.
> >>
> >> Signed-off-by: Siarhei Volkau 
> >> ---
> >>  drivers/pwm/Kconfig |   2 +-
> >>  drivers/pwm/pwm-sun4i.c | 143 
> >> 
> >>  2 files changed, 110 insertions(+), 35 deletions(-)
> >>
> >> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> >> index 2d0cfaa..6b4dc1a 100644
> >> --- a/drivers/pwm/Kconfig
> >> +++ b/drivers/pwm/Kconfig
> >> @@ -416,7 +416,7 @@ config PWM_STMPE
> >>  config PWM_SUN4I
> >>   tristate "Allwinner PWM support"
> >>   depends on ARCH_SUNXI || COMPILE_TEST
> >> - depends on HAS_IOMEM && COMMON_CLK
> >> + depends on REGMAP_MMIO && COMMON_CLK
> >>   help
> >> Generic PWM framework driver for Allwinner SoCs.
> >>
> >> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> >> index b0803f6..5565f03 100644
> >> --- a/drivers/pwm/pwm-sun4i.c
> >> +++ b/drivers/pwm/pwm-sun4i.c
> >> @@ -9,7 +9,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> -#include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -74,7 +74,7 @@ struct sun4i_pwm_data {
> >>  struct sun4i_pwm_chip {
> >>   struct pwm_chip chip;
> >>   struct clk *clk;
> >> - void __iomem *base;
> >> + struct regmap *regmap;
> >>   spinlock_t ctrl_lock;
> >>   const struct sun4i_pwm_data *data;
> >>  };
> >> @@ -84,18 +84,6 @@ static inline struct sun4i_pwm_chip 
> >> *to_sun4i_pwm_chip(struct pwm_chip *chip)
> >>   return container_of(chip, struct sun4i_pwm_chip, chip);
> >>  }
> >>
> >> -static inline u32 sun4i_pwm_readl(struct sun4i_pwm_chip *chip,
> >> -   unsigned long offset)
> >> -{
> >> - return readl(chip->base + offset);
> >> -}
> >> -
> >> -static inline void sun4i_pwm_writel(struct sun4i_pwm_chip *chip,
> >> - u32 val, unsigned long offset)
> >> -{
> >> - writel(val, chip->base + offset);
> >> -}
> >> -
> >>  static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> >>   int duty_ns, int period_ns)
> >>  {
> >> @@ -152,7 +140,11 @@ static int sun4i_pwm_config(struct pwm_chip *chip, 
> >> struct pwm_device *pwm,
> >>   }
> >>
> >>   spin_lock(_pwm->ctrl_lock);
> >> - val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> >> + err = regmap_read(sun4i_pwm->regmap, PWM_CTRL_REG, );
> >> + if (err) {
> >> + dev_err(chip->dev, "failed to read from CTL register\n");
> >> + goto err_cleanup;
> >> + }
> >
> > I'm not sure you need those error checks. If there's an error when you
> > write to an MMIO bus, you have much more important issues than your
> > return code there.
> 
> This probably overkill for MMIO, but it helps when wrong parameters
> passed to regmap functions - mostly during debugging stage.

There's no way you can get it wrong with regmap_read / write here. And
what's useful during debugging may not be fit for real world use
case. We never had error checking before, it was working just fine,
this is just as true here.

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 v4 2/9] pwm: sunxi: Use regmap fields for bit operations.

[Maxime Ripard]

On Mon, Feb 27, 2017 at 02:41:10PM +0300, Siarhei Volkau wrote:
> Hi,
> 
> 2017-02-27 12:28 GMT+03:00 Maxime Ripard :
> >
> > Hi,
> >
> > On Fri, Feb 24, 2017 at 08:41:09AM +0300, lis8...@gmail.com wrote:
> > > +static const struct reg_field
> > > +sun4i_pwm_regfields[SUN4I_MAX_PWM_CHANNELS][NUM_FIELDS] = {
> > > + {
> > > + [FIELD_PRESCALER]  = REG_FIELD(PWM_CTRL_REG,  0,  3),
> > > + [FIELD_POLARITY]   = REG_FIELD(PWM_CTRL_REG,  5,  5),
> > > + [FIELD_CLK_GATING] = REG_FIELD(PWM_CTRL_REG,  6,  6),
> > > + [FIELD_READY]  = REG_FIELD(PWM_CTRL_REG, 28, 28),
> > > + },
> > > + {
> > > + [FIELD_PRESCALER]  = REG_FIELD(PWM_CTRL_REG, 15, 18),
> > > + [FIELD_POLARITY]   = REG_FIELD(PWM_CTRL_REG, 20, 20),
> > > + [FIELD_CLK_GATING] = REG_FIELD(PWM_CTRL_REG, 21, 21),
> > > + [FIELD_READY]  = REG_FIELD(PWM_CTRL_REG, 29, 29),
> > > + },
> > > +};
> > > +
> >
> > I'm not sure you need something that complicated.
> >
> > What about something like:
> >
> > struct sun4i_chan_fields {
> >struct reg_field prescaler;
> >struct reg_field polarity;
> >struct reg_field clk_gating;
> >struct reg_field ready;
> > };
> >
> > And in sun4i_pwm_data add an array of this struct.
> >
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
> 
> Code with struct looks cleaner, but in this case need to be
> written separate code for each reg_field entry allocation,
> please look at the sunxi_alloc_reg_fields() function.
> 
> Current solution allows adding new fields slightly easier.

Yet, you also end up with a similar pattern in your later patches,
with the pwmch_data structure. But since using that structure for that
was not as easy as it was supposed to be, you just dropped reg_field
entirely for those.

Really, consistency is key, and having a structure like this, even if
slightly less easy to initialise (but that's not rocket science
either) provides that consistency that makes it easier to review,
understand and maintain.

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

Re: [linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: add usb_otg and OHCI/EHCI for usbc0 on H3

[Icenowy Zheng]

28.02.2017, 23:46, "Chen-Yu Tsai" :
> On Tue, Feb 28, 2017 at 11:27 PM, Icenowy Zheng  wrote:
>>  Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI
>>  or MUSB controller.
>>
>>  Add device nodes for these controllers.
>>
>>  Signed-off-by: Icenowy Zheng 
>>  ---
>>   arch/arm/boot/dts/sun8i-h3.dtsi | 36 
>>   1 file changed, 36 insertions(+)
>>
>>  diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>  index 27780b97c863..bc9a53edf371 100644
>>  --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>  +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>  @@ -206,6 +206,19 @@
>>  #size-cells = <0>;
>>  };
>>
>>  + usb_otg: usb@01c19000 {
>>  + compatible = "allwinner,sun8i-h3-musb";
>>  + reg = <0x01c19000 0x0400>;
>>  + clocks = < CLK_BUS_OTG>;
>>  + resets = < RST_BUS_OTG>;
>>  + interrupts = ;
>>  + interrupt-names = "mc";
>>  + phys = < 0>;
>>  + phy-names = "usb";
>>  + extcon = < 0>;
>>  + status = "disabled";
>>  + };
>>  +
>>  usbphy: phy@01c19400 {
>>  compatible = "allwinner,sun8i-h3-usb-phy";
>>  reg = <0x01c19400 0x2c>,
>>  @@ -238,6 +251,29 @@
>>  #phy-cells = <1>;
>>  };
>>
>>  + ehci0: usb@01c1a000 {
>>  + compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
>>  + reg = <0x01c1a000 0x100>;
>>  + interrupts = ;
>>  + clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>;
>>  + resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
>>  + phys = < 0>;
>>  + phy-names = "usb";
>
> So this bit is slightly concerning. IIRC the xHCI drivers power on the phy 
> when
> probed, which means VBUS is _always_ going to be powered on, even when it's
> supposed to be in peripheral mode. You're probably going to need to rework
> either the phy or the musb driver to cope with this.
>
> Or maybe just dropping the phy handle here and letting the musb driver handle
> it would work, but that requires the musb driver be loaded.

In fact the MUSB driver is always needed -- to set the dr_mode.

And currently MUSB driver can take over the USB bus even if it's host-only by 
forcing
its mode in sysfs. 

>
> ChenYu
>
>>  + status = "disabled";
>>  + };
>>  +
>>  + ohci0: usb@01c1a400 {
>>  + compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
>>  + reg = <0x01c1a400 0x100>;
>>  + interrupts = ;
>>  + clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>,
>>  + < CLK_USB_OHCI0>;
>>  + resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
>>  + phys = < 0>;
>>  + phy-names = "usb";
>>  + status = "disabled";
>>  + };
>>  +
>>  ehci1: usb@01c1b000 {
>>  compatible = "allwinner,sun8i-h3-ehci", 
>> "generic-ehci";
>>  reg = <0x01c1b000 0x100>;
>>  --
>>  2.11.1
>>
>>  --
>>  You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>>  To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscr...@googlegroups.com.
>>  For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 3/3] ARM: dts: sun8i: enable USB OTG on Orange Pi One

[Icenowy Zheng]

Orange Pi One features a MicroUSB port that can work in both host mode
and peripheral mode.

When in host mode, its VBUS is controlled via a GPIO; when in peripheral
mode, its VBUS cannot be used to power up the board.

Add support for this port.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 34da853ee037..b87778d74239 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -90,6 +90,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -104,6 +108,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -127,6 +135,11 @@
};
 };
 
+_usb0_vbus {
+   gpio = <_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
@@ -151,7 +164,14 @@
status = "disabled";
 };
 
+_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
  {
-   /* USB VBUS is always on */
+   /* USB Type-A port's VBUS is always on */
+   usb0_id_det-gpios = < 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+   usb0_vbus-supply = <_usb0_vbus>;
status = "okay";
 };
-- 
2.11.1

-- 
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 8/9] pwm: sunxi: Code cleanup.

[Maxime Ripard]

On Mon, Feb 27, 2017 at 04:21:49PM +0300, Siarhei Volkau wrote:
> Hi,
> 
> 2017-02-27 12:32 GMT+03:00 Maxime Ripard :
> > On Fri, Feb 24, 2017 at 08:41:15AM +0300, lis8...@gmail.com wrote:
> >> From: Siarhei Volkau 
> >>
> >> This patch removes macros, which are not use anymore and
> >> fixes two extra -Wsign-compare warnings.
> >>
> >> Signed-off-by: Siarhei Volkau 
> >
> > You've been adding this code in your previous patches, why is that
> > even added there?
> >
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
> 
> Are you mean there are no needs in separate patch for that?

Yes

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

Re: [linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: add usb_otg and OHCI/EHCI for usbc0 on H3

[Chen-Yu Tsai]

On Tue, Feb 28, 2017 at 11:57 PM, Icenowy Zheng  wrote:
>
>
> 28.02.2017, 23:46, "Chen-Yu Tsai" :
>> On Tue, Feb 28, 2017 at 11:27 PM, Icenowy Zheng  wrote:
>>>  Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI
>>>  or MUSB controller.
>>>
>>>  Add device nodes for these controllers.
>>>
>>>  Signed-off-by: Icenowy Zheng 
>>>  ---
>>>   arch/arm/boot/dts/sun8i-h3.dtsi | 36 
>>>   1 file changed, 36 insertions(+)
>>>
>>>  diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>  index 27780b97c863..bc9a53edf371 100644
>>>  --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>  +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>  @@ -206,6 +206,19 @@
>>>  #size-cells = <0>;
>>>  };
>>>
>>>  + usb_otg: usb@01c19000 {
>>>  + compatible = "allwinner,sun8i-h3-musb";
>>>  + reg = <0x01c19000 0x0400>;
>>>  + clocks = < CLK_BUS_OTG>;
>>>  + resets = < RST_BUS_OTG>;
>>>  + interrupts = ;
>>>  + interrupt-names = "mc";
>>>  + phys = < 0>;
>>>  + phy-names = "usb";
>>>  + extcon = < 0>;
>>>  + status = "disabled";
>>>  + };
>>>  +
>>>  usbphy: phy@01c19400 {
>>>  compatible = "allwinner,sun8i-h3-usb-phy";
>>>  reg = <0x01c19400 0x2c>,
>>>  @@ -238,6 +251,29 @@
>>>  #phy-cells = <1>;
>>>  };
>>>
>>>  + ehci0: usb@01c1a000 {
>>>  + compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
>>>  + reg = <0x01c1a000 0x100>;
>>>  + interrupts = ;
>>>  + clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>;
>>>  + resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
>>>  + phys = < 0>;
>>>  + phy-names = "usb";
>>
>> So this bit is slightly concerning. IIRC the xHCI drivers power on the phy 
>> when
>> probed, which means VBUS is _always_ going to be powered on, even when it's
>> supposed to be in peripheral mode. You're probably going to need to rework
>> either the phy or the musb driver to cope with this.
>>
>> Or maybe just dropping the phy handle here and letting the musb driver handle
>> it would work, but that requires the musb driver be loaded.
>
> In fact the MUSB driver is always needed -- to set the dr_mode.

I guess it's the same with DWC2/3 that have host controller pairs.

> And currently MUSB driver can take over the USB bus even if it's host-only by 
> forcing
> its mode in sysfs.

IIUC that would also switch the phy muxing over to the HCI pairs.

ChenYu

>>
>> ChenYu
>>
>>>  + status = "disabled";
>>>  + };
>>>  +
>>>  + ohci0: usb@01c1a400 {
>>>  + compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
>>>  + reg = <0x01c1a400 0x100>;
>>>  + interrupts = ;
>>>  + clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>,
>>>  + < CLK_USB_OHCI0>;
>>>  + resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
>>>  + phys = < 0>;
>>>  + phy-names = "usb";
>>>  + status = "disabled";
>>>  + };
>>>  +
>>>  ehci1: usb@01c1b000 {
>>>  compatible = "allwinner,sun8i-h3-ehci", 
>>> "generic-ehci";
>>>  reg = <0x01c1b000 0x100>;
>>>  --
>>>  2.11.1
>>>
>>>  --
>>>  You received this message because you are subscribed to the Google Groups 
>>> "linux-sunxi" group.
>>>  To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to linux-sunxi+unsubscr...@googlegroups.com.
>>>  For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[linux-sunxi] Re: [PATCH v4 4/9] pwm: sunxi: Customizable control and period register position.

[Maxime Ripard]

On Mon, Feb 27, 2017 at 03:35:04PM +0300, Siarhei Volkau wrote:
> Hi,
> 
> 2017-02-27 12:30 GMT+03:00 Maxime Ripard :
> > On Fri, Feb 24, 2017 at 08:41:11AM +0300, lis8...@gmail.com wrote:
> >> From: Siarhei Volkau 
> >>
> >> sun6i has same registers as sun4i compatible chips, but its position
> >> in register map are different.
> >>
> >> This patch make register's position selectable for support sun6i in
> >> next patches.
> >>
> >> Signed-off-by: Siarhei Volkau 
> >> ---
> >>  drivers/pwm/pwm-sun4i.c | 57 
> >> ++---
> >>  1 file changed, 54 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> >> index 418a625..9ddc812 100644
> >> --- a/drivers/pwm/pwm-sun4i.c
> >> +++ b/drivers/pwm/pwm-sun4i.c
> >> @@ -79,11 +79,17 @@ static const u32 sun4i_prescaler_table[] = {
> >>   0, /* Actually 1 but tested separately */
> >>  };
> >>
> >> +struct sunxi_pwmch_data {
> >> + unsigned int ctl_reg;
> >> + unsigned int prd_reg;
> >> +};
> >> +
> >
> > Why don't you use regmap_fields for that too?
> >
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
> 
> Period register contains 2 fields (duty cycle and active period),
> A20 user manual says:
> (C) Note: the active cycles should be no larger than the period cycles.
> 
> I just try to avoid situation when active cycles can have bigger value
> than duty cycle. Regmap fields not allows update 2
> or more fields simultaneously, or maybe i'm not found this.
> 
> Same situation with enable/disable bitmask in control register.
> Updating these bits (clock gating and enable) in different moments
> in time can produce some artefacts on pwm output signal.

That really should be dealt with in the driver itself though, and not
in your accessor. It's up to the driver to use the accessor in a way
that makes sense for that particular device.

All these constraints should be documented, but you don't need to
change the way you access those registers to do that (unless you
really really really have no other way to do so).

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

Re: [linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: add usb_otg and OHCI/EHCI for usbc0 on H3

[Icenowy Zheng]

28.02.2017, 23:46, "Chen-Yu Tsai" :
> On Tue, Feb 28, 2017 at 11:27 PM, Icenowy Zheng  wrote:
>>  Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI
>>  or MUSB controller.
>>
>>  Add device nodes for these controllers.
>>
>>  Signed-off-by: Icenowy Zheng 
>>  ---
>>   arch/arm/boot/dts/sun8i-h3.dtsi | 36 
>>   1 file changed, 36 insertions(+)
>>
>>  diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>  index 27780b97c863..bc9a53edf371 100644
>>  --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>  +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>  @@ -206,6 +206,19 @@
>>  #size-cells = <0>;
>>  };
>>
>>  + usb_otg: usb@01c19000 {
>>  + compatible = "allwinner,sun8i-h3-musb";
>>  + reg = <0x01c19000 0x0400>;
>>  + clocks = < CLK_BUS_OTG>;
>>  + resets = < RST_BUS_OTG>;
>>  + interrupts = ;
>>  + interrupt-names = "mc";
>>  + phys = < 0>;
>>  + phy-names = "usb";
>>  + extcon = < 0>;
>>  + status = "disabled";
>>  + };
>>  +
>>  usbphy: phy@01c19400 {
>>  compatible = "allwinner,sun8i-h3-usb-phy";
>>  reg = <0x01c19400 0x2c>,
>>  @@ -238,6 +251,29 @@
>>  #phy-cells = <1>;
>>  };
>>
>>  + ehci0: usb@01c1a000 {
>>  + compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
>>  + reg = <0x01c1a000 0x100>;
>>  + interrupts = ;
>>  + clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>;
>>  + resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
>>  + phys = < 0>;
>>  + phy-names = "usb";
>
> So this bit is slightly concerning. IIRC the xHCI drivers power on the phy 
> when
> probed, which means VBUS is _always_ going to be powered on, even when it's
> supposed to be in peripheral mode. You're probably going to need to rework
> either the phy or the musb driver to cope with this.
>
> Or maybe just dropping the phy handle here and letting the musb driver handle
> it would work, but that requires the musb driver be loaded.

Tested this solution.

I may choose it in the next version.

Hans, how do you think of this solution?

>
> ChenYu
>
>>  + status = "disabled";
>>  + };
>>  +
>>  + ohci0: usb@01c1a400 {
>>  + compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
>>  + reg = <0x01c1a400 0x100>;
>>  + interrupts = ;
>>  + clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>,
>>  + < CLK_USB_OHCI0>;
>>  + resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
>>  + phys = < 0>;
>>  + phy-names = "usb";
>>  + status = "disabled";
>>  + };
>>  +
>>  ehci1: usb@01c1b000 {
>>  compatible = "allwinner,sun8i-h3-ehci", 
>> "generic-ehci";
>>  reg = <0x01c1b000 0x100>;
>>  --
>>  2.11.1
>>
>>  --
>>  You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>>  To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscr...@googlegroups.com.
>>  For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] phy: sun4i-usb: support automatically switch PHY0 route to MUSB/HCI

[Chen-Yu Tsai]

On Tue, Feb 28, 2017 at 11:27 PM, Icenowy Zheng  wrote:
> On newer Allwinner SoCs (H3 and after), the PHY0 node is routed to both
> MUSB controller for peripheral and host support (the host support is
> slightly broken), and a pair of EHCI/OHCI controllers, which provide a
> better support for host mode.
>
> Add support for automatically switch the route of PHY0 according to the
> status of dr_mode and id det pin.
>
> Only H3 have this function enabled in this patch, as further SoCs will
> be tested later and then have it enabled.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/phy/phy-sun4i-usb.c | 55 
> +++--
>  1 file changed, 38 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index a21b5f24a340..8b91afe8f42d 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -49,12 +49,14 @@
>  #define REG_PHYBIST0x08
>  #define REG_PHYTUNE0x0c
>  #define REG_PHYCTL_A33 0x10
> -#define REG_PHY_UNK_H3 0x20
> +#define REG_PHY_OTGCTL 0x20
>
>  #define REG_PMU_UNK1   0x10
>
>  #define PHYCTL_DATABIT(7)
>
> +#define OTGCTL_ROUTE_MUSB  BIT(0)
> +
>  #define SUNXI_AHB_ICHR8_EN BIT(10)
>  #define SUNXI_AHB_INCR4_BURST_EN   BIT(9)
>  #define SUNXI_AHB_INCRX_ALIGN_EN   BIT(8)
> @@ -110,6 +112,7 @@ struct sun4i_usb_phy_cfg {
> u8 phyctl_offset;
> bool dedicated_clocks;
> bool enable_pmu_unk1;
> +   bool phy0_dual_route;
>  };
>
>  struct sun4i_usb_phy_data {
> @@ -271,23 +274,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> }
>
> -   if (data->cfg->type == sun8i_h3_phy) {
> -   if (phy->index == 0) {
> -   val = readl(data->base + REG_PHY_UNK_H3);
> -   writel(val & ~1, data->base + REG_PHY_UNK_H3);
> -   }
> -   } else {
> -   /* Enable USB 45 Ohm resistor calibration */
> -   if (phy->index == 0)
> -   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> +   /* Enable USB 45 Ohm resistor calibration */
> +   if (phy->index == 0)
> +   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>
> -   /* Adjust PHY's magnitude and rate */
> -   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> +   /* Adjust PHY's magnitude and rate */
> +   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>
> -   /* Disconnect threshold adjustment */
> -   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> -   data->cfg->disc_thresh, 2);
> -   }
> +   /* Disconnect threshold adjustment */
> +   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> +   data->cfg->disc_thresh, 2);
>
> sun4i_usb_phy_passby(phy, 1);
>
> @@ -486,6 +482,26 @@ static const struct phy_ops sun4i_usb_phy_ops = {
> .owner  = THIS_MODULE,
>  };
>
> +static void sun4i_usb_phy0_reroute(struct sun4i_usb_phy_data *data, int 
> id_det)
> +{
> +   u32 regval;
> +
> +   if (data->dr_mode == USB_DR_MODE_HOST)
> +   id_det = 0; /* Force host */
> +   if (data->dr_mode == USB_DR_MODE_PERIPHERAL)
> +   id_det = 1; /* Force peripheral*/
> +
> +   regval = readl(data->base + REG_PHY_OTGCTL);
> +   if (id_det == 0) {
> +   /* Host mode. Route phy0 to EHCI/OHCI */
> +   regval &= ~OTGCTL_ROUTE_MUSB;
> +   } else {
> +   /* Peripheral mode. Route phy0 to MUSB */
> +   regval |= OTGCTL_ROUTE_MUSB;
> +   }
> +   writel(regval, data->base + REG_PHY_OTGCTL);
> +}
> +
>  static void sun4i_usb_phy0_id_vbus_det_scan(struct work_struct *work)
>  {
> struct sun4i_usb_phy_data *data =
> @@ -511,6 +527,10 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
> work_struct *work)
> data->force_session_end = false;
>
> if (id_det != data->id_det) {
> +   /* Re-route PHY0 if necessary */
> +   if (data->cfg->phy0_dual_route)
> +   sun4i_usb_phy0_reroute(data, id_det);
> +

Would it make sense to do this after force session end?

ChenYu

> /* id-change, force session end if we've no vbus detection */
> if (data->dr_mode == USB_DR_MODE_OTG &&
> !sun4i_usb_phy0_have_vbus_det(data))
> @@ -700,7 +720,7 @@ static int sun4i_usb_phy_probe(struct platform_device 
> *pdev)
> return PTR_ERR(phy->reset);
> }
>
> -   if (i) { /* No pmu for usbc0 */
> +   if (i || data->cfg->phy0_dual_route) { /* No pmu for musb */
> 

Re: [linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: add usb_otg and OHCI/EHCI for usbc0 on H3

[Chen-Yu Tsai]

On Tue, Feb 28, 2017 at 11:27 PM, Icenowy Zheng  wrote:
> Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI
> or MUSB controller.
>
> Add device nodes for these controllers.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 36 
>  1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 27780b97c863..bc9a53edf371 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -206,6 +206,19 @@
> #size-cells = <0>;
> };
>
> +   usb_otg: usb@01c19000 {
> +   compatible = "allwinner,sun8i-h3-musb";
> +   reg = <0x01c19000 0x0400>;
> +   clocks = < CLK_BUS_OTG>;
> +   resets = < RST_BUS_OTG>;
> +   interrupts = ;
> +   interrupt-names = "mc";
> +   phys = < 0>;
> +   phy-names = "usb";
> +   extcon = < 0>;
> +   status = "disabled";
> +   };
> +
> usbphy: phy@01c19400 {
> compatible = "allwinner,sun8i-h3-usb-phy";
> reg = <0x01c19400 0x2c>,
> @@ -238,6 +251,29 @@
> #phy-cells = <1>;
> };
>
> +   ehci0: usb@01c1a000 {
> +   compatible = "allwinner,sun8i-h3-ehci", 
> "generic-ehci";
> +   reg = <0x01c1a000 0x100>;
> +   interrupts = ;
> +   clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>;
> +   resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
> +   phys = < 0>;
> +   phy-names = "usb";

So this bit is slightly concerning. IIRC the xHCI drivers power on the phy when
probed, which means VBUS is _always_ going to be powered on, even when it's
supposed to be in peripheral mode. You're probably going to need to rework
either the phy or the musb driver to cope with this.

Or maybe just dropping the phy handle here and letting the musb driver handle
it would work, but that requires the musb driver be loaded.

ChenYu

> +   status = "disabled";
> +   };
> +
> +   ohci0: usb@01c1a400 {
> +   compatible = "allwinner,sun8i-h3-ohci", 
> "generic-ohci";
> +   reg = <0x01c1a400 0x100>;
> +   interrupts = ;
> +   clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>,
> +< CLK_USB_OHCI0>;
> +   resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
> +   phys = < 0>;
> +   phy-names = "usb";
> +   status = "disabled";
> +   };
> +
> ehci1: usb@01c1b000 {
> compatible = "allwinner,sun8i-h3-ehci", 
> "generic-ehci";
> reg = <0x01c1b000 0x100>;
> --
> 2.11.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [linux-sunxi] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.

[Lyubcho Haralanov]

The question that really bugs me is: why toggling LDO4 doesn't affect the 
board but toggling LDO3 kills it...

On Tuesday, February 28, 2017 at 10:43:08 AM UTC+2, Olliver Schinagl wrote:
>
> Hey Lub, 
>
> On 28-02-17 07:43, Lyubcho Haralanov wrote: 
> > It seems like what Marcus suggested (turning off LDO3, setting voltage 
> > to minimum 0.7V, then turning on LDO3 and then increasing the voltage to 
> > 2.8V) works fine with the LIME2: 
> > 
> > i2c mw 0x34 0x12 0x1f 
> > i2c mw 0x34 0x29 0x00 
> > i2c mw 0x34 0x12 0x5f 
> > i2c mw 0x34 0x29 0x58 
>
> Yeah, I ran the same tests and even 0x7f (3.6V) 'works fine'. The only 
> problem herein is, that this solution can't be simply rolled out to all 
> boards I think. (All meaning the CHIP, cubieboard etc). For one, it 
> would change current behavior of boards that are not broken. 
>
> But more importantly, how does electronics behave that get this (fast) 
> ramp up, rather than instant on power? Are there people using LDO3 with 
> the assumption power is immediately available? 
>
> So I think this alternate behavior should live behind a toggle, which is 
> enabled for all boards that need it. (Currently all Olimex boards?) 
>
> Olliver 
>
> > 
> > I'm yet to test the other designs. Nothing is final at the moment since 
> > we are still testing, but probably the future hardware revisions would 
> > have 4.7 uF on LDO3 and LDO4 instead of 10 uF (LDO1 is always on, LDO2 
> > is connected to the memory and turning it off naturally kills the 
> board). 
> > 
> > On Monday, February 27, 2017 at 9:11:18 PM UTC+2, oliver wrote: 
> > 
> > Hey Lub 
> > 
> > On , Lyubcho Haralanov wrote: 
> > > Hi, 
> > > 
> > > VR1 is not assembled (NA). It is not placed. Only pads are 
> > provided in 
> > > case you don't want to power the camera from the AXP209 but 
> > > externally, in which case you should place VR1 and disconnect the 
> SMT 
> > > jumper LDO3_2.8V_E. 
> > > 
> > > By original design the camera is powered only by the AXP209. 
> > > 
> > > Best regards, 
> > > Lub 
> > 
> > Thanks for the explanation of the EVB :) 
> > 
> > Can you also elaborate on the 10 uF for all designs however? 
> > 
> > Some extra information, I ran some current tests on the LDO3 
> > power-up/shutdown and while 200 mA max sourcing current is never 
> > reached, the chip does shut down before the max voltage has been 
> > reached. For example setting ldo3 to max ( i2c mw 0x34 0x29 0x7f ) 
> we 
> > get screenshot 3v6.png where we can see the max voltage is only 
> 2.32. 
> > 
> > Repeating the same test however with 2.3 V ( i2c mw 0x34 0x29 0x40 ) 
> > yields 2V3.png, which also causes an AXP209 failure. This supprised 
> > me a 
> > little, as I expected the 2.3V to actually work, as that is the 
> voltage 
> > we failed before. Also failure happens sooner and max current is 
> lower. 
> > 
> > After some trial and error, we find that 1.95 V, in this case, still 
> > works, but that I suppose really depends on the capacitance, but by 
> no 
> > means reliably! 
> > 
> > Due to the small timebase (50 uS) we cannot clearly see the power 
> rail 
> > dropping, but be assured, for the 2V3 and 3V6, power slowly drops as 
> > capacitors discharge. 
> > 
> > 
> > While this can and should be solved in hardware (smaller capacitor) 
> > there's hundreds of thousands of boards in the wild with this 
> > configuration and thus a software solution is needed. 
> > 
> > The AXP209 does have slew rate control, however this does not apply 
> > when 
> > toggling the LDO3 output switch. What I thus propose, is a 
> quirk-flag, 
> > for buggy boards, where we set the minimal voltage, enable power and 
> > than set the desired voltage, letting the internal slew rate control 
> > slowly ramp up voltage. 
> > 
> > 
> > 
> > What I still would love to hear from you guys, is why this could be 
> > happening. The spec-sheet does say 200 mA of sourcing capability. 
> > But it 
> > seems this is not exactly true? At least not when toggling LDO3 via 
> > reg12 for sure. 
> > 
> > Olliver 
> > 
> > > 
> > > On Monday, February 27, 2017 at 2:33:08 PM UTC+2, Marcus Weseloh 
> > > wrote: 
> > > 
> > >> Hi, 
> > >> 
> > >> 2017-02-27 13:11 GMT+01:00 oliver : 
> > >> 
> > >>> One is to remove C185 (10 microF) and the problem went away. 
> > >>> Looking at other designs, cubieboard 1 for example, uses the 
> same 
> > >>> layout, but only 4.7 microF. So it seems that charging of all 
> the 
> > >>> capacitance (input C106) the board itself, the output (C185) may 
> > >>> be too much for the AXP209. 
> > >> 
> > >> Great, that confirms my suspicion that the capacitance is the 
> main 
> > >> problem on the A20-SOM. The reference design for the A20 from 
> 

Re: [linux-sunxi] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.

[Marcus Weseloh]

2017-02-28 13:19 GMT+01:00 Lyubcho Haralanov :

> The question that really bugs me is: why toggling LDO4 doesn't affect the
> board but toggling LDO3 kills it...
>

Can you measure the time it takes LDO3 and LDO4 to ramp to up the their
final value? LDO4 seems to have a different architecture than LDO3, the
datasheet calls it "low noise LDO". Maybe the different architecture means
it has a much slower (or even just a working) slew rate than LDO3?

Olivers measurements also seem to suggest that the documented slew rate of
LDO3 (VRC, register 25H) of 1.6mV/us is actually not what's happening when
re-enabling LDO3? If my maths is correct, then it should take LDO3 about
1.75ms to go from 0V to 2.8V. But if the attached 10uF leads to current in
excess of 200mA, then it seems like the voltage rises much faster than that
(less than 100us)?

Cheers,

Marcus

-- 
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 2/3] ARM: dts: sun8i: add usb_otg and OHCI/EHCI for usbc0 on H3

[Icenowy Zheng]

01.03.2017, 00:10, "Chen-Yu Tsai" :
> On Tue, Feb 28, 2017 at 11:57 PM, Icenowy Zheng  wrote:
>>  28.02.2017, 23:46, "Chen-Yu Tsai" :
>>>  On Tue, Feb 28, 2017 at 11:27 PM, Icenowy Zheng  wrote:
   Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI
   or MUSB controller.

   Add device nodes for these controllers.

   Signed-off-by: Icenowy Zheng 
   ---
    arch/arm/boot/dts/sun8i-h3.dtsi | 36 
 
    1 file changed, 36 insertions(+)

   diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
 b/arch/arm/boot/dts/sun8i-h3.dtsi
   index 27780b97c863..bc9a53edf371 100644
   --- a/arch/arm/boot/dts/sun8i-h3.dtsi
   +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
   @@ -206,6 +206,19 @@
   #size-cells = <0>;
   };

   + usb_otg: usb@01c19000 {
   + compatible = "allwinner,sun8i-h3-musb";
   + reg = <0x01c19000 0x0400>;
   + clocks = < CLK_BUS_OTG>;
   + resets = < RST_BUS_OTG>;
   + interrupts = ;
   + interrupt-names = "mc";
   + phys = < 0>;
   + phy-names = "usb";
   + extcon = < 0>;
   + status = "disabled";
   + };
   +
   usbphy: phy@01c19400 {
   compatible = "allwinner,sun8i-h3-usb-phy";
   reg = <0x01c19400 0x2c>,
   @@ -238,6 +251,29 @@
   #phy-cells = <1>;
   };

   + ehci0: usb@01c1a000 {
   + compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
   + reg = <0x01c1a000 0x100>;
   + interrupts = ;
   + clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>;
   + resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
   + phys = < 0>;
   + phy-names = "usb";
>>>
>>>  So this bit is slightly concerning. IIRC the xHCI drivers power on the phy 
>>> when
>>>  probed, which means VBUS is _always_ going to be powered on, even when it's
>>>  supposed to be in peripheral mode. You're probably going to need to rework
>>>  either the phy or the musb driver to cope with this.
>>>
>>>  Or maybe just dropping the phy handle here and letting the musb driver 
>>> handle
>>>  it would work, but that requires the musb driver be loaded.
>>
>>  In fact the MUSB driver is always needed -- to set the dr_mode.
>
> I guess it's the same with DWC2/3 that have host controller pairs.
>
>>  And currently MUSB driver can take over the USB bus even if it's host-only 
>> by forcing
>>  its mode in sysfs.
>
> IIUC that would also switch the phy muxing over to the HCI pairs.

The MUSB mode setting code in fact sets the mode of PHY.

So then the PHY will return a id_det value based on its mode set
(Always 0 for host, Always 1 for peripheral, real GPIO value for otg),
then the id_det change code will be run and then re-route the PHY.

>
> ChenYu
>
>>>  ChenYu
>>>
   + status = "disabled";
   + };
   +
   + ohci0: usb@01c1a400 {
   + compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
   + reg = <0x01c1a400 0x100>;
   + interrupts = ;
   + clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>,
   + < CLK_USB_OHCI0>;
   + resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
   + phys = < 0>;
   + phy-names = "usb";
   + status = "disabled";
   + };
   +
   ehci1: usb@01c1b000 {
   compatible = "allwinner,sun8i-h3-ehci", 
 "generic-ehci";
   reg = <0x01c1b000 0x100>;
   --
   2.11.1

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

-- 
You received this message because you are subscribed to 

Re: [linux-sunxi] [PATCH 3/4] ARM: sun7i: Convert to CCU

[Emilio López]

Hi,

I spotted a couple of things here on a quick look, see below

El 27/02/17 a las 18:09, Priit Laes escribió:
> Convert sun7i-a20.dtsi to new CCU driver.
> 
> Signed-off-by: Priit Laes 
> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 719 
> +--
>  1 file changed, 86 insertions(+), 633 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 04c9977..6f80cb8 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -47,7 +47,8 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> @@ -67,19 +68,19 @@
>   compatible = "allwinner,simple-framebuffer",
>"simple-framebuffer";
>   allwinner,pipeline = "de_be0-lcd0-hdmi";
> - clocks = <_gates 36>, <_gates 43>,
> -  <_gates 44>, <_be0_clk>,
> -  <_ch1_clk>, <_gates 26>;
> + clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI1>,
> +  < CLK_AHB_DE_BE0>, < CLK_DE_BE0>,
> +  < CLK_TCON0_CH1>, < CLK_DRAM_DE_BE0>;
>   status = "disabled";
>   };
>  
> - framebuffer@1 {
> + framebuffer@0 {

This looks like an unrelated change

> @@ -184,21 +185,11 @@
>  
>   osc24M: clk@01c20050 {
>   #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-osc-clk";
> - reg = <0x01c20050 0x4>;
> + compatible = "fixed-clock";
>   clock-frequency = <2400>;
>   clock-output-names = "osc24M";
>   };

allwinner,sun4i-a10-osc-clk implements a gate apart from a fixed clock,
is the feature loss intended?

Cheers,
Emilio

-- 
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 3/5] dt-bindings: fix for Allwinner H5 pinctrl's compatible

[Icenowy Zheng]

The compatible for Allwinner H5 pin controller is wrong written as
allwinner,sun50i-h5-r-pinctrl, however, it's really a generic pinctrl
rather than a "r" one.

Fix this compatible string.

Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 2fd688c8dbdb..8177bb4d5f53 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -23,7 +23,7 @@ Required properties:
   "allwinner,sun8i-h3-pinctrl"
   "allwinner,sun8i-h3-r-pinctrl"
   "allwinner,sun50i-a64-pinctrl"
-  "allwinner,sun50i-h5-r-pinctrl"
+  "allwinner,sun50i-h5-pinctrl"
   "nextthing,gr8-pinctrl"
 
 - reg: Should contain the register physical address and length for the
-- 
2.11.1

-- 
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 1/5] pinctrl: sunxi: refactor pinctrl choice selecting for ARM64

[Icenowy Zheng]

ARM64 Allwinner SoCs used to have every pinctrl driver selected in
ARCH_SUNXI. Change this to make their default value to (ARM64 &&
ARCH_SUNXI).

Signed-off-by: Icenowy Zheng 
---
 drivers/pinctrl/sunxi/Kconfig | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 816015cf7053..92325736d953 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -48,8 +48,9 @@ config PINCTRL_SUN8I_H3
select PINCTRL_SUNXI
 
 config PINCTRL_SUN8I_H3_R
-   def_bool MACH_SUN8I
-   select PINCTRL_SUNXI_COMMON
+   def_bool MACH_SUN8I || (ARM64 && ARCH_SUNXI)
+   depends on RESET_CONTROLLER
+   select PINCTRL_SUNXI
 
 config PINCTRL_SUN8I_V3S
def_bool MACH_SUN8I
@@ -65,11 +66,11 @@ config PINCTRL_SUN9I_A80_R
select PINCTRL_SUNXI
 
 config PINCTRL_SUN50I_A64
-   bool
+   def_bool ARM64 && ARCH_SUNXI
select PINCTRL_SUNXI
 
 config PINCTRL_SUN50I_H5
-   bool
+   def_bool ARM64 && ARCH_SUNXI
select PINCTRL_SUNXI
 
 endif
-- 
2.11.1

-- 
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 2/5] arm64: only select PINCTRL_SUNXI for Allwinner platforms

[Icenowy Zheng]

As the pinctrl driver selecting is refactored in Kconfig file of
pinctrl-sunxi, now we can select only PINCTRL_SUNXI for Allwinner
platform, and the default value of several pinctrl drivers useful on
ARM64 Allwinner SoCs will become Y.

Drop the select of per-SoC pinctrl choices, but select PINCTRL_SUNXI.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/Kconfig.platforms | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 129cc5ae4091..f6db2a938b1e 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -4,7 +4,7 @@ config ARCH_SUNXI
bool "Allwinner sunxi 64-bit SoC Family"
select GENERIC_IRQ_CHIP
select PINCTRL
-   select PINCTRL_SUN50I_A64
+   select PINCTRL_SUNXI
help
  This enables support for Allwinner sunxi based SoCs like the A64.
 
-- 
2.11.1

-- 
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 5/5] pinctrl: sunxi: Add A64 R_PIO controller support

[Icenowy Zheng]

The A64 has a R_PIO pin controller, similar to the one found on the H3 SoC.
Add support for the pins controlled by the R_PIO controller.

Signed-off-by: Icenowy Zheng 
---
 drivers/pinctrl/sunxi/Kconfig|   5 +
 drivers/pinctrl/sunxi/Makefile   |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c | 143 +++
 3 files changed, 149 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c

diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 92325736d953..0738b0df5a0b 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -69,6 +69,11 @@ config PINCTRL_SUN50I_A64
def_bool ARM64 && ARCH_SUNXI
select PINCTRL_SUNXI
 
+config PINCTRL_SUN50I_A64_R
+   def_bool ARM64 && ARCH_SUNXI
+   depends on RESET_CONTROLLER
+   select PINCTRL_SUNXI
+
 config PINCTRL_SUN50I_H5
def_bool ARM64 && ARCH_SUNXI
select PINCTRL_SUNXI
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index 04ccb88ebd5f..df4ccd6cd44c 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23)   += 
pinctrl-sun8i-a23.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23_R)  += pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
 obj-$(CONFIG_PINCTRL_SUN50I_A64)   += pinctrl-sun50i-a64.o
+obj-$(CONFIG_PINCTRL_SUN50I_A64_R) += pinctrl-sun50i-a64-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)   += pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3_R)   += pinctrl-sun8i-h3-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c 
b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
new file mode 100644
index ..90996a63689b
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
@@ -0,0 +1,143 @@
+/*
+ * Allwinner A64 SoCs special pins pinctrl driver.
+ *
+ * Based on pinctrl-sun8i-a23-r.c
+ *
+ * Copyright (C) 2016 Icenowy Zheng
+ * Icenowy Zheng 
+ *
+ * Copyright (C) 2014 Chen-Yu Tsai
+ * Chen-Yu Tsai 
+ *
+ * Copyright (C) 2014 Boris Brezillon
+ * Boris Brezillon 
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ * Maxime Ripard 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun50i_a64_r_pins[] = {
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */
+ SUNXI_FUNCTION(0x3, "s_i2c"), /* SCK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),  /* PL_EINT0 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */
+ SUNXI_FUNCTION(0x3, "s_i2c"), /* SDA */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),  /* PL_EINT1 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart"),/* TX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),  /* PL_EINT2 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart"),/* RX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),  /* PL_EINT3 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag"),/* MS */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),  /* PL_EINT4 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag"),/* CK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),  /* PL_EINT5 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag"),/* DO */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),  /* PL_EINT6 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, 

[linux-sunxi] [PATCH 4/5] dt: bindings: add binding for Allwinner A64 R_PIO pinctrl

[Icenowy Zheng]

Allwinner A64 SoC has also a dedicated pin controller for Port L GPIOs,
which is called "Port Controller (CPUs-PORT)" in SoC User Manual.

Add a binding for this pin controller, like the ones in A23/33 and H3.

Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 8177bb4d5f53..b53224473672 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -23,6 +23,7 @@ Required properties:
   "allwinner,sun8i-h3-pinctrl"
   "allwinner,sun8i-h3-r-pinctrl"
   "allwinner,sun50i-a64-pinctrl"
+  "allwinner,sun50i-a64-r-pinctrl"
   "allwinner,sun50i-h5-pinctrl"
   "nextthing,gr8-pinctrl"
 
-- 
2.11.1

-- 
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 2/5] arm64: only select PINCTRL_SUNXI for Allwinner platforms

[Andre Przywara]

Hi,

On 28/02/17 17:24, Icenowy Zheng wrote:
> As the pinctrl driver selecting is refactored in Kconfig file of
> pinctrl-sunxi, now we can select only PINCTRL_SUNXI for Allwinner
> platform, and the default value of several pinctrl drivers useful on
> ARM64 Allwinner SoCs will become Y.
> 
> Drop the select of per-SoC pinctrl choices, but select PINCTRL_SUNXI.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/Kconfig.platforms | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 129cc5ae4091..f6db2a938b1e 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -4,7 +4,7 @@ config ARCH_SUNXI
>   bool "Allwinner sunxi 64-bit SoC Family"
>   select GENERIC_IRQ_CHIP
>   select PINCTRL
> - select PINCTRL_SUN50I_A64
> + select PINCTRL_SUNXI

Why do we need to add this generic PINCTRL_SUNXI here? This is selected
already by the SoC specific PINCTRL symbols (see your previous patch).

Cheers,
Andre.

>   help
> This enables support for Allwinner sunxi based SoCs like the A64.
>  
> 

-- 
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/5] pinctrl: sunxi: refactor pinctrl choice selecting for ARM64

[Andre Przywara]

Hi Icenowy,

(first thing: could you create your series with --cover-letter and fill
this in? There you could explain what this series is about and also
state things like dependencies from other patches and the commit that
you based that on.)

On 28/02/17 17:24, Icenowy Zheng wrote:
> ARM64 Allwinner SoCs used to have every pinctrl driver selected in
> ARCH_SUNXI. Change this to make their default value to (ARM64 &&
> ARCH_SUNXI).
> 
> Signed-off-by: Icenowy Zheng 

Overall this is a nice solution. Thanks for posting this.

> ---
>  drivers/pinctrl/sunxi/Kconfig | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index 816015cf7053..92325736d953 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -48,8 +48,9 @@ config PINCTRL_SUN8I_H3
>   select PINCTRL_SUNXI
>  
>  config PINCTRL_SUN8I_H3_R
> - def_bool MACH_SUN8I
> - select PINCTRL_SUNXI_COMMON
> + def_bool MACH_SUN8I || (ARM64 && ARCH_SUNXI)
> + depends on RESET_CONTROLLER

So this looks a bit odd. I take it this is for the extra reset register
in the PRCM block.
1) I don't think this belongs into this patch. If this has been
forgotten in the past, please make an extra patch for this. It's cheap
to do so ;-)
2) Is this really a "depends on"? Shouldn't this be a select? With
sunxi_ng clocks we don't need the reset controller for the normal
peripherals anymore, so this option might not be selected by default in
the future. And having this "depends on" leads to the PINCTRL_ option
being hidden if RESET_CONTROLLER isn't selected.
I think this bites us already in arm64, where ARCH_HAS_RESET_CONTROLLER
is not enabled for ARCH_SUNXI.


But as the rest of the patch is fine, if you remove this line:
Reviewed-by: Andre Przywara 

Cheers,
Andre.

> + select PINCTRL_SUNXI
>  
>  config PINCTRL_SUN8I_V3S
>   def_bool MACH_SUN8I
> @@ -65,11 +66,11 @@ config PINCTRL_SUN9I_A80_R
>   select PINCTRL_SUNXI
>  
>  config PINCTRL_SUN50I_A64
> - bool
> + def_bool ARM64 && ARCH_SUNXI
>   select PINCTRL_SUNXI
>  
>  config PINCTRL_SUN50I_H5
> - bool
> + def_bool ARM64 && ARCH_SUNXI
>   select PINCTRL_SUNXI
>  
>  endif
> 

-- 
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 5/5] pinctrl: sunxi: Add A64 R_PIO controller support

[Andre Przywara]

Hi,

On 28/02/17 17:24, Icenowy Zheng wrote:
> The A64 has a R_PIO pin controller, similar to the one found on the H3 SoC.
> Add support for the pins controlled by the R_PIO controller.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/pinctrl/sunxi/Kconfig|   5 +
>  drivers/pinctrl/sunxi/Makefile   |   1 +
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c | 143 
> +++
>  3 files changed, 149 insertions(+)
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
> 
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index 92325736d953..0738b0df5a0b 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -69,6 +69,11 @@ config PINCTRL_SUN50I_A64
>   def_bool ARM64 && ARCH_SUNXI
>   select PINCTRL_SUNXI
>  
> +config PINCTRL_SUN50I_A64_R
> + def_bool ARM64 && ARCH_SUNXI
> + depends on RESET_CONTROLLER

Same comment as on patch 1/5 (select instead of "depends on").
I take it this for drivers/reset/reset-sunxi.c?
Shouldn't this be the sunxi specific CONFIG_RESET_SUNXI then?
Also from from having a quick look at the driver this is broken for
arm64 (BITS_PER_LONG usage).
>From having a closer look this driver is actually not Allwinner specific
at all, since it just describes a number of bits in consecutive
32-bit(!) registers as reset cells.
As I today stumbled upon another SoC which has the same reset register
layout I was wondering if it's worth to generalise this? Possibly
renaming the driver, and allowing additional compatibles?
I can take a stab at this.

Cheers,
Andre.

> + select PINCTRL_SUNXI
> +
>  config PINCTRL_SUN50I_H5
>   def_bool ARM64 && ARCH_SUNXI
>   select PINCTRL_SUNXI
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 04ccb88ebd5f..df4ccd6cd44c 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23) += 
> pinctrl-sun8i-a23.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A23_R)+= pinctrl-sun8i-a23-r.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A33)  += pinctrl-sun8i-a33.o
>  obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o
> +obj-$(CONFIG_PINCTRL_SUN50I_A64_R)   += pinctrl-sun50i-a64-r.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
>  obj-$(CONFIG_PINCTRL_SUN8I_H3)   += pinctrl-sun8i-h3.o
>  obj-$(CONFIG_PINCTRL_SUN8I_H3_R) += pinctrl-sun8i-h3-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
> new file mode 100644
> index ..90996a63689b
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
> @@ -0,0 +1,143 @@
> +/*
> + * Allwinner A64 SoCs special pins pinctrl driver.
> + *
> + * Based on pinctrl-sun8i-a23-r.c
> + *
> + * Copyright (C) 2016 Icenowy Zheng
> + * Icenowy Zheng 
> + *
> + * Copyright (C) 2014 Chen-Yu Tsai
> + * Chen-Yu Tsai 
> + *
> + * Copyright (C) 2014 Boris Brezillon
> + * Boris Brezillon 
> + *
> + * Copyright (C) 2014 Maxime Ripard
> + * Maxime Ripard 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun50i_a64_r_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */
> +   SUNXI_FUNCTION(0x3, "s_i2c"), /* SCK */
> +   SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),  /* PL_EINT0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */
> +   SUNXI_FUNCTION(0x3, "s_i2c"), /* SDA */
> +   SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),  /* PL_EINT1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "s_uart"),/* TX */
> +   SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),  /* PL_EINT2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "s_uart"),/* RX */
> +   SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),  /* PL_EINT3 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   

Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command

[Siarhei Siamashka]

On Tue, 28 Feb 2017 09:16:11 +
Andre Przywara  wrote:

> Hi,
> 
> On 28/02/17 03:08, Siarhei Siamashka wrote:
> > On Mon, 27 Feb 2017 20:55:53 +
> > Andre Przywara  wrote:
> >   
> >> On Mon, 27 Feb 2017 05:48:48 +0200
> >> Siarhei Siamashka  wrote:
> >>  
> >>> On Mon, 27 Feb 2017 02:22:08 +
> >>> André Przywara  wrote:
> >>> 
>  On 27/02/17 01:20, Siarhei Siamashka wrote:
> > On Wed, 22 Feb 2017 17:08:47 +
> > Andre Przywara  wrote:
> >   
> >> If an SoC has the "secure boot" fuse burned, it will enter FEL
> >> mode in non-secure state, so with the SCR.NS bit set. Since in
> >> this mode the secure/non-secure state restrictions are actually
> >> observed, we suffer from several restrictions:
> >> - No access to the SID information (both via memory mapped and
> >> "register").
> >> - No access to secure SRAM (SRAM A2 on H3/A64/H5).
> >> - No access to the secure side of the GIC, so it can't be
> >> configured to be accessible from non-secure world.
> >> - No RMR trigger on ARMv8 cores to bring the core into AArch64.
> >> Those limitations make a board pretty useless for many
> >> applications.
> >>
> >> However it has been found out that a simple "smc" call will
> >> immediately return from monitor mode, but with the NS bit
> >> cleared, so access to all secure peripherals is suddenly
> >> possible.
> >>
> >> Add a sunxi-fel command called "smc" which will issue exactly
> >> this instruction to make those boards useful in "secure boot"
> >> FEL mode.
> >>
> >> It should be given early in the command queue to given
> >> subsequent code full access to the system:
> >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ...
> >>
> >> Signed-off-by: Andre Przywara 
> >>
> >> ---
> >> Hi,
> >>
> >> if that sounds vaguely useful (it definitedly is for me to get
> >> the Remix Mini PC started), I can follow the Github process if
> >> you prefer that.
> >>
> >> Cheers,
> >> Andre.  
> >
> > Hi Andre,
> >
> > Why don't we just do this automatically without adding a new
> > special command?
> >
> > We are not allowed to read the SCR register for detecting this
> > state, right? But can we still use some other detection method?
> > For example, maybe try to read SID and assume that we need the
> > SMC workaround if it reads back as zero?  
> 
>  Yes, indeed I was thinking about exactly that ;-)
>  From actually using this feature I realized that its usage is error
>  prone: non-secure boards crash on calling it, secure board just
>  don't work without it.
>  And indeed there is no architectural way of checking whether you are
>  running secure or non-secure (as reading a secure-only register like
>  NSACR or SCR will trap, which means crash in our case).
> 
>  So (trying to) read the SID is indeed the best workaround I came up
>  with: If it's all zero, we are probably secure and need the smc.
>  There is still a slight chance that the SID is all zero even on a
>  non-secure board (I think this was the case for some older SoCs?),
>  so maybe we need an option to suppress using this heuristic?
> >>>
> >>> At least we should report every taken action in the sunxi-fel verbose
> >>> log (about the SMC workaround getting applied) because it greatly
> >>> simplifies troubleshooting.
> >>>
> >>> And IMHO having any options to suppress this workaround is a bit
> >>> premature until we encounter a real A64/H64/H5 chip where it fails
> >>> in the wild.
> >>>
> >>> Another variant of the detection heuristics could just use SRAM A2
> >>> (well, not quite "SRAM", but the OpenRISC reset vector area). I'm
> >>> getting the following output on my Jide Remix Mini (Allwinner H64):
> >>>
> >>> $ ./sunxi-fel readl 0x40004
> >>> 0x
> >>>
> >>> $ ./sunxi-fel smc
> >>>
> >>> $ ./sunxi-fel readl 0x40004
> >>> 0x1500
> >>>
> >>> We are either reading zero from there, or it is a hardwired OpenRISC
> >>> instruction L.NOP.
> >>
> >> Yeah, that sounds even better, but would be restricted to SoCs which
> >> have an OpenRISC. Not sure if that is actually a super set of
> >> secure-boot capable chips.  
> > 
> > There is no obligation to implement exactly the same solution for every
> > SoC.
> >   
> >> Only thing is that we need to add the address of "secure SRAM" to the
> >> per-SoC data structure, but that may become useful for other purposes
> >> in the future as well, I guess.  
> > 
> > We can even implement it as a simple check with just a single address of
> > a word (or even byte), which needs to be compared with zero. Some SoCs
> > may make use of NOPs from the delay slots of the OpenRISC 

[linux-sunxi] Re: [PATCH 1/3] phy: sun4i-usb: support automatically switch PHY0 route to MUSB/HCI

[Hans de Goede]

Hi,

On 28-02-17 16:27, Icenowy Zheng wrote:

On newer Allwinner SoCs (H3 and after), the PHY0 node is routed to both
MUSB controller for peripheral and host support (the host support is
slightly broken), and a pair of EHCI/OHCI controllers, which provide a
better support for host mode.

Add support for automatically switch the route of PHY0 according to the
status of dr_mode and id det pin.

Only H3 have this function enabled in this patch, as further SoCs will
be tested later and then have it enabled.

Signed-off-by: Icenowy Zheng 
---
 drivers/phy/phy-sun4i-usb.c | 55 +++--
 1 file changed, 38 insertions(+), 17 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index a21b5f24a340..8b91afe8f42d 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -49,12 +49,14 @@
 #define REG_PHYBIST0x08
 #define REG_PHYTUNE0x0c
 #define REG_PHYCTL_A33 0x10
-#define REG_PHY_UNK_H3 0x20
+#define REG_PHY_OTGCTL 0x20

 #define REG_PMU_UNK1   0x10

 #define PHYCTL_DATABIT(7)

+#define OTGCTL_ROUTE_MUSB  BIT(0)
+
 #define SUNXI_AHB_ICHR8_EN BIT(10)
 #define SUNXI_AHB_INCR4_BURST_EN   BIT(9)
 #define SUNXI_AHB_INCRX_ALIGN_EN   BIT(8)
@@ -110,6 +112,7 @@ struct sun4i_usb_phy_cfg {
u8 phyctl_offset;
bool dedicated_clocks;
bool enable_pmu_unk1;
+   bool phy0_dual_route;
 };

 struct sun4i_usb_phy_data {
@@ -271,23 +274,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val & ~2, phy->pmu + REG_PMU_UNK1);
}

-   if (data->cfg->type == sun8i_h3_phy) {
-   if (phy->index == 0) {
-   val = readl(data->base + REG_PHY_UNK_H3);
-   writel(val & ~1, data->base + REG_PHY_UNK_H3);
-   }
-   } else {
-   /* Enable USB 45 Ohm resistor calibration */
-   if (phy->index == 0)
-   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
+   /* Enable USB 45 Ohm resistor calibration */
+   if (phy->index == 0)
+   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);

-   /* Adjust PHY's magnitude and rate */
-   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
+   /* Adjust PHY's magnitude and rate */
+   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);

-   /* Disconnect threshold adjustment */
-   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
-   data->cfg->disc_thresh, 2);
-   }
+   /* Disconnect threshold adjustment */
+   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
+   data->cfg->disc_thresh, 2);

sun4i_usb_phy_passby(phy, 1);

@@ -486,6 +482,26 @@ static const struct phy_ops sun4i_usb_phy_ops = {
.owner  = THIS_MODULE,
 };

+static void sun4i_usb_phy0_reroute(struct sun4i_usb_phy_data *data, int id_det)
+{
+   u32 regval;
+
+   if (data->dr_mode == USB_DR_MODE_HOST)
+   id_det = 0; /* Force host */
+   if (data->dr_mode == USB_DR_MODE_PERIPHERAL)
+   id_det = 1; /* Force peripheral*/


The passed in id_det comes from sun4i_usb_phy0_get_id_det() which already
does:

switch (data->dr_mode) {
case USB_DR_MODE_OTG:
if (data->id_det_gpio)
return gpiod_get_value_cansleep(data->id_det_gpio);
else
return 1; /* Fallback to peripheral mode */
case USB_DR_MODE_HOST:
return 0;
case USB_DR_MODE_PERIPHERAL:
default:
return 1;
}

So the above 4 lines are unnecessary and should be removed.

Otherwise looks good, thank you for doing this.

Regards,

Hans




+
+   regval = readl(data->base + REG_PHY_OTGCTL);
+   if (id_det == 0) {
+   /* Host mode. Route phy0 to EHCI/OHCI */
+   regval &= ~OTGCTL_ROUTE_MUSB;
+   } else {
+   /* Peripheral mode. Route phy0 to MUSB */
+   regval |= OTGCTL_ROUTE_MUSB;
+   }
+   writel(regval, data->base + REG_PHY_OTGCTL);
+}
+
 static void sun4i_usb_phy0_id_vbus_det_scan(struct work_struct *work)
 {
struct sun4i_usb_phy_data *data =
@@ -511,6 +527,10 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
data->force_session_end = false;

if (id_det != data->id_det) {
+   /* Re-route PHY0 if necessary */
+   if (data->cfg->phy0_dual_route)
+   sun4i_usb_phy0_reroute(data, id_det);
+
/* id-change, force session end if we've no vbus detection */
if (data->dr_mode == USB_DR_MODE_OTG &&

[linux-sunxi] Re: [PATCH] arm64: dts: allwinner: add support for Pinebook

[Rob Herring]

On Sat, Feb 25, 2017 at 1:00 AM, Icenowy Zheng  wrote:
> Pinebook is a A64-based laptop produced by Pine64, with the following
> peripherals:
>
> USB:
> - Two external USB ports (one is directly connected to A64's OTG
> controller, the other is under a internal hub connected to the host-only
> controller.)
> - USB HID keyboard and touchpad connected to the internal hub.
> - USB UVC camera connected to the internal hub.
>
> Power-related:
> - A DC IN jack connected to AXP803's DCIN pin.
> - A Li-Polymer battery connected to AXP803's battery pins.
>
> Storage:
> - An eMMC by Foresee on the main board (in the product revision of the
> main board it's designed to be switchable).
> - An external MicroSD card slot.
>
> Display:
> - An eDP LCD panel (1366x768) connected via an ANX6345/ANX9807 RGB-eDP
> bridge.
> - A mini HDMI jack.
>
> Misc:
> - A Hall sensor designed to detect the status of lid, connected to GPIO PH10.
> - A headphone jack connected to the SoC's internal codec.
> - A BMA223 gravity sensor connected to the SoC's I2C1 bus. (Not
> supported yet)
> - A debug UART port muxed with one of the USB ports, only available on
> product revision of the main board.
>
> This commit adds basical support for it, with out-of-tree patches for
> display support the laptop can be basically usable.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>  .../boot/dts/allwinner/sun50i-a64-pinebook.dts | 123 
> +
>  2 files changed, 124 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
> b/arch/arm64/boot/dts/allwinner/Makefile
> index bc6f342be59f..893520c39955 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,4 +1,5 @@
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>
>  always := $(dtb-y)
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> new file mode 100644
> index ..2dceba3132b0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> @@ -0,0 +1,123 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * 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 library 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 library 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.

Use SPDX tags here:

SPDX-License-Identifier: (GPL-2.0+ OR MIT)

While it says X11, this is really MIT license text.

-- 
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 2/5] arm64: only select PINCTRL_SUNXI for Allwinner platforms

[Icenowy Zheng]

01.03.2017, 02:17, "Andre Przywara" :
> Hi,
>
> On 28/02/17 17:24, Icenowy Zheng wrote:
>>  As the pinctrl driver selecting is refactored in Kconfig file of
>>  pinctrl-sunxi, now we can select only PINCTRL_SUNXI for Allwinner
>>  platform, and the default value of several pinctrl drivers useful on
>>  ARM64 Allwinner SoCs will become Y.
>>
>>  Drop the select of per-SoC pinctrl choices, but select PINCTRL_SUNXI.
>>
>>  Signed-off-by: Icenowy Zheng 
>>  ---
>>   arch/arm64/Kconfig.platforms | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>  diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>  index 129cc5ae4091..f6db2a938b1e 100644
>>  --- a/arch/arm64/Kconfig.platforms
>>  +++ b/arch/arm64/Kconfig.platforms
>>  @@ -4,7 +4,7 @@ config ARCH_SUNXI
>>   bool "Allwinner sunxi 64-bit SoC Family"
>>   select GENERIC_IRQ_CHIP
>>   select PINCTRL
>>  - select PINCTRL_SUN50I_A64
>>  + select PINCTRL_SUNXI
>
> Why do we need to add this generic PINCTRL_SUNXI here? This is selected
> already by the SoC specific PINCTRL symbols (see your previous patch).
>
> Cheers,
> Andre.

Oh yes... You're right...

>
>>   help
>> This enables support for Allwinner sunxi based SoCs like the A64.

-- 
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/5] pinctrl: sunxi: refactor pinctrl choice selecting for ARM64

[Icenowy Zheng]

01.03.2017, 02:15, "Andre Przywara" :
> Hi Icenowy,
>
> (first thing: could you create your series with --cover-letter and fill
> this in? There you could explain what this series is about and also
> state things like dependencies from other patches and the commit that
> you based that on.)
>
> On 28/02/17 17:24, Icenowy Zheng wrote:
>>  ARM64 Allwinner SoCs used to have every pinctrl driver selected in
>>  ARCH_SUNXI. Change this to make their default value to (ARM64 &&
>>  ARCH_SUNXI).
>>
>>  Signed-off-by: Icenowy Zheng 
>
> Overall this is a nice solution. Thanks for posting this.
>
>>  ---
>>   drivers/pinctrl/sunxi/Kconfig | 9 +
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>>  diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
>>  index 816015cf7053..92325736d953 100644
>>  --- a/drivers/pinctrl/sunxi/Kconfig
>>  +++ b/drivers/pinctrl/sunxi/Kconfig
>>  @@ -48,8 +48,9 @@ config PINCTRL_SUN8I_H3
>>   select PINCTRL_SUNXI
>>
>>   config PINCTRL_SUN8I_H3_R
>>  - def_bool MACH_SUN8I
>>  - select PINCTRL_SUNXI_COMMON
>>  + def_bool MACH_SUN8I || (ARM64 && ARCH_SUNXI)
>>  + depends on RESET_CONTROLLER
>
> So this looks a bit odd. I take it this is for the extra reset register
> in the PRCM block.
> 1) I don't think this belongs into this patch. If this has been
> forgotten in the past, please make an extra patch for this. It's cheap
> to do so ;-)
> 2) Is this really a "depends on"? Shouldn't this be a select? With
> sunxi_ng clocks we don't need the reset controller for the normal
> peripherals anymore, so this option might not be selected by default in
> the future. And having this "depends on" leads to the PINCTRL_ option
> being hidden if RESET_CONTROLLER isn't selected.
> I think this bites us already in arm64, where ARCH_HAS_RESET_CONTROLLER
> is not enabled for ARCH_SUNXI.

PINCTRL_ options are always hidden now, Maxime, do you
want to change that?

We should enable ARCH_HAS_RESET_CONTROLLER for
ARCH_SUNXI, as sunxi-ng ccu is a reset controller.

Without RESET_CONTROLLER enabled, errors will occur
when linking:
```
drivers/built-in.o: In function `sunxi_ccu_probe':
of_reserved_mem.c:(.text+0x16058): undefined reference to 
`reset_controller_register'
```

If you don't care, I will make it an additional patch.

And there's really a reset line for the R_PIO pinctrls.

But you're right, this line shouldn't occur in this patch.
I will make a more patch for it.

>
> But as the rest of the patch is fine, if you remove this line:
> Reviewed-by: Andre Przywara 
>
> Cheers,
> Andre.
>
>>  + select PINCTRL_SUNXI
>>
>>   config PINCTRL_SUN8I_V3S
>>   def_bool MACH_SUN8I
>>  @@ -65,11 +66,11 @@ config PINCTRL_SUN9I_A80_R
>>   select PINCTRL_SUNXI
>>
>>   config PINCTRL_SUN50I_A64
>>  - bool
>>  + def_bool ARM64 && ARCH_SUNXI
>>   select PINCTRL_SUNXI
>>
>>   config PINCTRL_SUN50I_H5
>>  - bool
>>  + def_bool ARM64 && ARCH_SUNXI
>>   select PINCTRL_SUNXI
>>
>>   endif

-- 
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 5/5] pinctrl: sunxi: Add A64 R_PIO controller support

[Icenowy Zheng]

01.03.2017, 02:27, "Andre Przywara" :
> Hi,
>
> On 28/02/17 17:24, Icenowy Zheng wrote:
>>  The A64 has a R_PIO pin controller, similar to the one found on the H3 SoC.
>>  Add support for the pins controlled by the R_PIO controller.
>>
>>  Signed-off-by: Icenowy Zheng 
>>  ---
>>   drivers/pinctrl/sunxi/Kconfig | 5 +
>>   drivers/pinctrl/sunxi/Makefile | 1 +
>>   drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c | 143 
>> +++
>>   3 files changed, 149 insertions(+)
>>   create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
>>
>>  diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
>>  index 92325736d953..0738b0df5a0b 100644
>>  --- a/drivers/pinctrl/sunxi/Kconfig
>>  +++ b/drivers/pinctrl/sunxi/Kconfig
>>  @@ -69,6 +69,11 @@ config PINCTRL_SUN50I_A64
>>   def_bool ARM64 && ARCH_SUNXI
>>   select PINCTRL_SUNXI
>>
>>  +config PINCTRL_SUN50I_A64_R
>>  + def_bool ARM64 && ARCH_SUNXI
>>  + depends on RESET_CONTROLLER
>
> Same comment as on patch 1/5 (select instead of "depends on").
> I take it this for drivers/reset/reset-sunxi.c?
> Shouldn't this be the sunxi specific CONFIG_RESET_SUNXI then?
> Also from from having a quick look at the driver this is broken for
> arm64 (BITS_PER_LONG usage).
> From having a closer look this driver is actually not Allwinner specific
> at all, since it just describes a number of bits in consecutive
> 32-bit(!) registers as reset cells.
> As I today stumbled upon another SoC which has the same reset register
> layout I was wondering if it's worth to generalise this? Possibly
> renaming the driver, and allowing additional compatibles?
> I can take a stab at this.

As I said, the driver now doesn't play under ARM64.
But, sunxi-ng ccu driver is now a reset controller.

>
> Cheers,
> Andre.
>
>>  + select PINCTRL_SUNXI
>>  +
>>   config PINCTRL_SUN50I_H5
>>   def_bool ARM64 && ARCH_SUNXI
>>   select PINCTRL_SUNXI
>>  diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
>>  index 04ccb88ebd5f..df4ccd6cd44c 100644
>>  --- a/drivers/pinctrl/sunxi/Makefile
>>  +++ b/drivers/pinctrl/sunxi/Makefile
>>  @@ -11,6 +11,7 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23) += pinctrl-sun8i-a23.o
>>   obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
>>   obj-$(CONFIG_PINCTRL_SUN8I_A33) += pinctrl-sun8i-a33.o
>>   obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o
>>  +obj-$(CONFIG_PINCTRL_SUN50I_A64_R) += pinctrl-sun50i-a64-r.o
>>   obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
>>   obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
>>   obj-$(CONFIG_PINCTRL_SUN8I_H3_R) += pinctrl-sun8i-h3-r.o
>>  diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c 
>> b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
>>  new file mode 100644
>>  index ..90996a63689b
>>  --- /dev/null
>>  +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
>>  @@ -0,0 +1,143 @@
>>  +/*
>>  + * Allwinner A64 SoCs special pins pinctrl driver.
>>  + *
>>  + * Based on pinctrl-sun8i-a23-r.c
>>  + *
>>  + * Copyright (C) 2016 Icenowy Zheng
>>  + * Icenowy Zheng 
>>  + *
>>  + * Copyright (C) 2014 Chen-Yu Tsai
>>  + * Chen-Yu Tsai 
>>  + *
>>  + * Copyright (C) 2014 Boris Brezillon
>>  + * Boris Brezillon 
>>  + *
>>  + * Copyright (C) 2014 Maxime Ripard
>>  + * Maxime Ripard 
>>  + *
>>  + * This file is licensed under the terms of the GNU General Public
>>  + * License version 2. This program is licensed "as is" without any
>>  + * warranty of any kind, whether express or implied.
>>  + */
>>  +
>>  +#include 
>>  +#include 
>>  +#include 
>>  +#include 
>>  +#include 
>>  +
>>  +#include "pinctrl-sunxi.h"
>>  +
>>  +static const struct sunxi_desc_pin sun50i_a64_r_pins[] = {
>>  + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
>>  + SUNXI_FUNCTION(0x0, "gpio_in"),
>>  + SUNXI_FUNCTION(0x1, "gpio_out"),
>>  + SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */
>>  + SUNXI_FUNCTION(0x3, "s_i2c"), /* SCK */
>>  + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PL_EINT0 */
>>  + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
>>  + SUNXI_FUNCTION(0x0, "gpio_in"),
>>  + SUNXI_FUNCTION(0x1, "gpio_out"),
>>  + SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */
>>  + SUNXI_FUNCTION(0x3, "s_i2c"), /* SDA */
>>  + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PL_EINT1 */
>>  + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
>>  + SUNXI_FUNCTION(0x0, "gpio_in"),
>>  + SUNXI_FUNCTION(0x1, "gpio_out"),
>>  + SUNXI_FUNCTION(0x2, "s_uart"), /* TX */
>>  + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /* PL_EINT2 */
>>  + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
>>  + SUNXI_FUNCTION(0x0, "gpio_in"),
>>  + SUNXI_FUNCTION(0x1, "gpio_out"),
>>  + SUNXI_FUNCTION(0x2, "s_uart"), /* RX */
>>  + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)), /* PL_EINT3 */
>>  + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
>>  + SUNXI_FUNCTION(0x0, "gpio_in"),
>>  + SUNXI_FUNCTION(0x1, "gpio_out"),
>>  

[linux-sunxi] [PATCH] pinctrl: sunxi: select GPIOLIB

[Icenowy Zheng]

Allwinner pin controllers are also GPIO controllers.

Currently, if GPIOLIB is forgot to be chosen, the build of
pinctrl-sunxi.c will fail for lacking a lot of gpiochip_* functions.

Select GPIOLIB to ensure this driver can be built.

Signed-off-by: Icenowy Zheng 
---
This bug is found when I try to add sunxi drivers on an ARM64
allnoconfig, in order to prove that sunxi-ng ccu driver depends on
reset_controller framework.

I proved the latter dependency, but how to satisfy it still needs
some discussion.

 drivers/pinctrl/sunxi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 816015cf7053..e25d0daa660a 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -4,6 +4,7 @@ config PINCTRL_SUNXI
bool
select PINMUX
select GENERIC_PINCONF
+   select GPIOLIB
 
 config PINCTRL_SUN4I_A10
def_bool MACH_SUN4I
-- 
2.11.1

-- 
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 13/17] sunxi: A64: Pine64: introduce FIT generator script

[Andre Przywara]

Now that the Makefile can call a generator script to build a more
advanced FIT image, let's use this feature to address the needs of
Allwinner A64 boards.
The (DTB stripped) U-Boot binary and the ATF are static, but we allow
an arbitrary number of supported device trees to be passed.
The script enters both a DT entry in the /images node and the respective
subnode in /configurations to support all listed DTBs.

This requires to copy the ARM Trusted Firmware build (bl31.bin) into
the U-Boot source directory (or to create a symlink to it).

Signed-off-by: Andre Przywara 
---
 board/sunxi/mksunxi_fit_atf.sh | 73 ++
 1 file changed, 73 insertions(+)
 create mode 100755 board/sunxi/mksunxi_fit_atf.sh

diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
new file mode 100755
index 000..afa22e8
--- /dev/null
+++ b/board/sunxi/mksunxi_fit_atf.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+#
+# script to generate FIT image source for 64-bit sunxi boards with
+# ARM Trusted Firmware and multiple device trees (given on the command line)
+#
+# usage: $0  [ [;
+
+   images {
+   uboot@1 {
+   description = "U-Boot (64-bit)";
+   data = /incbin/("u-boot-nodtb.bin");
+   type = "standalone";
+   arch = "arm64";
+   compression = "none";
+   load = <0x4a00>;
+   };
+   atf@1 {
+   description = "ARM Trusted Firmware";
+   data = /incbin/("bl31.bin");
+   type = "firmware";
+   arch = "arm64";
+   compression = "none";
+   load = <0x44000>;
+   entry = <0x44000>;
+   };
+__HEADER_EOF
+
+cnt=1
+for dtname in $*
+do
+   cat << __FDT_IMAGE_EOF
+   fdt@$cnt {
+   description = "$(basename $dtname .dtb)";
+   data = /incbin/("$dtname");
+   type = "flat_dt";
+   compression = "none";
+   };
+__FDT_IMAGE_EOF
+   cnt=$((cnt+1))
+done
+
+cat << __CONF_HEADER_EOF
+   };
+   configurations {
+   default = "config@1";
+
+__CONF_HEADER_EOF
+
+cnt=1
+for dtname in $*
+do
+   cat << __CONF_SECTION_EOF
+   config@$cnt {
+   description = "$(basename $dtname .dtb)";
+   firmware = "uboot@1";
+   loadables = "atf@1";
+   fdt = "fdt@$cnt";
+   };
+__CONF_SECTION_EOF
+   cnt=$((cnt+1))
+done
+
+cat << __ITS_EOF
+   };
+};
+__ITS_EOF
-- 
2.8.2

-- 
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 05/17] SPL: FIT: allow loading multiple images

[Andre Przywara]

So far we were not using the FIT image format to its full potential:
The SPL FIT loader was just loading the first image from the /images
node plus one of the listed DTBs.
Now with the refactored loader code it's easy to load an arbitrary
number of images in addition to the two mentioned above.
As described in the FIT image source file format description, iterate
over all images listed at the "loadables" property in the configuration
node and load every image at its desired location.
This allows to load any kind of images:
- firmware images to execute before U-Boot proper (for instance
  ARM Trusted Firmware (ATF))
- firmware images for management processors (SCP, arisc, ...)
- firmware images for devices like WiFi controllers
- bit files for FPGAs
- additional configuration data
- kernels and/or ramdisks
The actual usage of this feature would be platform and/or board specific.

Signed-off-by: Andre Przywara 
---
 common/spl/spl_fit.c | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ad5ba15..5583e09 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -178,10 +178,7 @@ static int spl_load_fit_image(struct spl_load_info *info, 
ulong sector,
if (image_info) {
image_info->load_addr = load_addr;
image_info->size = length;
-   if (entry == -1UL)
-   image_info->entry_point = load_addr;
-   else
-   image_info->entry_point = entry;
+   image_info->entry_point = entry;
}
 
return 0;
@@ -196,6 +193,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
struct spl_image_info image_info;
int node, images;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
+   int index = 0;
 
/*
 * Figure out where the external images start. This is the base for the
@@ -240,6 +238,11 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (node < 0) {
debug("could not find firmware image, trying loadables...\n");
node = spl_fit_get_image_node(fit, images, "loadables", 0);
+   /*
+* If we pick the U-Boot image from "loadables", start at
+* the second image when later loading additional images.
+*/
+   index = 1;
}
if (node < 0) {
debug("%s: Cannot find u-boot image node: %d\n",
@@ -265,5 +268,26 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
image_info.load_addr = spl_image->load_addr + spl_image->size;
spl_load_fit_image(info, sector, fit, base_offset, node, _info);
 
+   /* Now check if there are more images for us to load */
+   for (; ; index++) {
+   node = spl_fit_get_image_node(fit, images, "loadables", index);
+   if (node < 0)
+   break;
+
+   spl_load_fit_image(info, sector, fit, base_offset, node,
+  _info);
+
+   /*
+* If the "firmware" image did not provide an entry point,
+* use the first valid entry point from the loadables.
+*/
+   if (spl_image->entry_point == -1UL &&
+   image_info.entry_point != -1UL)
+   spl_image->entry_point = image_info.entry_point;
+   }
+
+   if (spl_image->entry_point == -1UL || spl_image->entry_point == 0)
+   spl_image->entry_point = spl_image->load_addr;
+
return 0;
 }
-- 
2.8.2

-- 
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 03/17] SPL: FIT: rework U-Boot image loading

[Andre Przywara]

Currently the SPL FIT loader always looks only for the first image in
the /images node a FIT tree, which it loads and later executes.

Generalize this by looking for a "firmware" property in the matched
configuration subnode, or, if that does not exist, for the first string
in the "loadables" property. Then using the string in that property,
load the image of that name from the /images node.
This still loads only one image at the moment, but refactors the code to
allow extending this in a following patch.
To simplify later re-usage, we also generalize the spl_fit_select_index()
function to not return the image location, but just the node offset.

Signed-off-by: Andre Przywara 
---
 common/spl/spl_fit.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ba45e65..572a5db 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -55,14 +55,13 @@ static int spl_fit_find_config_node(const void *fdt)
return -1;
 }
 
-static int spl_fit_select_index(const void *fit, int images, int *offsetp,
-   const char *type, int index)
+static int spl_fit_get_image_node(const void *fit, int images,
+ const char *type, int index)
 {
const char *name, *str;
int node, conf_node;
int len, i;
 
-   *offsetp = 0;
conf_node = spl_fit_find_config_node(fit);
if (conf_node < 0) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
@@ -99,10 +98,7 @@ static int spl_fit_select_index(const void *fit, int images, 
int *offsetp,
return -EINVAL;
}
 
-   *offsetp = fdt_getprop_u32(fit, node, "data-offset");
-   len = fdt_getprop_u32(fit, node, "data-size");
-
-   return len;
+   return node;
 }
 
 static int get_aligned_image_offset(struct spl_load_info *info, int offset)
@@ -188,15 +184,22 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (count == 0)
return -EIO;
 
-   /* find the firmware image to load */
+   /* find the node holding the images information */
images = fdt_path_offset(fit, FIT_IMAGES_PATH);
if (images < 0) {
debug("%s: Cannot find /images node: %d\n", __func__, images);
return -1;
}
-   node = fdt_first_subnode(fit, images);
+
+   /* find the U-Boot image */
+   node = spl_fit_get_image_node(fit, images, "firmware", 0);
+   if (node < 0) {
+   debug("could not find firmware image, trying loadables...\n");
+   node = spl_fit_get_image_node(fit, images, "loadables", 0);
+   }
if (node < 0) {
-   debug("%s: Cannot find first image node: %d\n", __func__, node);
+   debug("%s: Cannot find u-boot image node: %d\n",
+ __func__, node);
return -1;
}
 
@@ -238,10 +241,13 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
memcpy(dst, src, data_size);
 
/* Figure out which device tree the board wants to use */
-   fdt_len = spl_fit_select_index(fit, images, _offset,
-  FIT_FDT_PROP, 0);
-   if (fdt_len < 0)
-   return fdt_len;
+   node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, 0);
+   if (node < 0) {
+   debug("%s: cannot find FDT node\n", __func__);
+   return node;
+   }
+   fdt_offset = fdt_getprop_u32(fit, node, "data-offset");
+   fdt_len = fdt_getprop_u32(fit, node, "data-size");
 
/*
 * Read the device tree and place it after the image. There may be
-- 
2.8.2

-- 
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 02/17] SPL: FIT: refactor FDT loading

[Andre Przywara]

Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
find the offset to the right DTB within the FIT image.
For this it iterates over all subnodes of the /configuration node in
the FIT tree and compares all "description" strings therein using a
board specific matching function.
If that finds a match, it uses the string in the "fdt" property of that
subnode to locate the matching subnode in the /images node, which points
to the DTB data.
Now this works very well, but is quite specific to cover this particular
use case. To open up the door for a more generic usage, let's split this
function into:
1) a function that just returns the node offset for the matching
   configuration node (spl_fit_find_config_node())
2) a function that returns the image data any given property in a given
   configuration node points to, additionally using a given index into
   a possbile list of strings (spl_fit_select_index())
This allows us to replace the specific function above by asking for the
image the _first string of the "fdt" property_ in the matching
configuration subnode points to.

This patch introduces no functional changes, it just refactors the code
to allow reusing it later.

(diff is overly clever here and produces a hard-to-read patch, so I
recommend to throw a look at the result instead).

Signed-off-by: Andre Przywara 
---
 common/spl/spl_fit.c | 83 
 1 file changed, 52 insertions(+), 31 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index aae556f..ba45e65 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -22,13 +22,11 @@ static ulong fdt_getprop_u32(const void *fdt, int node, 
const char *prop)
return fdt32_to_cpu(*cell);
 }
 
-static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
+static int spl_fit_find_config_node(const void *fdt)
 {
-   const char *name, *fdt_name;
-   int conf, node, fdt_node;
-   int len;
+   const char *name;
+   int conf, node, len;
 
-   *fdt_offsetp = 0;
conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
if (conf < 0) {
debug("%s: Cannot find /configurations node: %d\n", __func__,
@@ -50,39 +48,61 @@ static int spl_fit_select_fdt(const void *fdt, int images, 
int *fdt_offsetp)
continue;
 
debug("Selecting config '%s'", name);
-   fdt_name = fdt_getprop(fdt, node, FIT_FDT_PROP, );
-   if (!fdt_name) {
-   debug("%s: Cannot find fdt name property: %d\n",
- __func__, len);
-   return -EINVAL;
-   }
 
-   debug(", fdt '%s'\n", fdt_name);
-   fdt_node = fdt_subnode_offset(fdt, images, fdt_name);
-   if (fdt_node < 0) {
-   debug("%s: Cannot find fdt node '%s': %d\n",
- __func__, fdt_name, fdt_node);
-   return -EINVAL;
+   return node;
+   }
+
+   return -1;
+}
+
+static int spl_fit_select_index(const void *fit, int images, int *offsetp,
+   const char *type, int index)
+{
+   const char *name, *str;
+   int node, conf_node;
+   int len, i;
+
+   *offsetp = 0;
+   conf_node = spl_fit_find_config_node(fit);
+   if (conf_node < 0) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+   printf("No matching DT out of these options:\n");
+   for (node = fdt_first_subnode(fit, conf_node);
+node >= 0;
+node = fdt_next_subnode(fit, node)) {
+   name = fdt_getprop(fit, node, "description", );
+   printf("   %s\n", name);
}
+#endif
+   return -ENOENT;
+   }
 
-   *fdt_offsetp = fdt_getprop_u32(fdt, fdt_node, "data-offset");
-   len = fdt_getprop_u32(fdt, fdt_node, "data-size");
-   debug("FIT: Selected '%s'\n", name);
+   name = fdt_getprop(fit, conf_node, type, );
+   if (!name) {
+   debug("cannot find property '%s': %d\n", type, len);
+   return -EINVAL;
+   }
 
-   return len;
+   str = name;
+   for (i = 0; i < index; i++) {
+   str = strchr(str, '\0') + 1;
+   if (!str || (str - name >= len)) {
+   debug("no string for index %d\n", index);
+   return -E2BIG;
+   }
}
 
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-   printf("No matching DT out of these options:\n");
-   for (node = fdt_first_subnode(fdt, conf);
-node >= 0;
-node = fdt_next_subnode(fdt, node)) {
-   name = fdt_getprop(fdt, node, "description", );
-   printf("   %s\n", name);
+   debug("%s: '%s'\n", type, str);
+   node = fdt_subnode_offset(fit, images, 

[linux-sunxi] [PATCH 15/17] sunxi: OrangePi-PC2: defconfig: enable SPL FIT support

[Andre Przywara]

Enable the SPL FIT support and the FIT generator script for the
OrangePi PC2 board, as it also need to load an ATF binary.

Signed-off-by: Andre Przywara 
---
 configs/orangepi_pc2_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig
index 19a5c2b..8a2d289 100644
--- a/configs/orangepi_pc2_defconfig
+++ b/configs/orangepi_pc2_defconfig
@@ -5,6 +5,12 @@ CONFIG_SPL=y
 CONFIG_DRAM_CLK=672
 CONFIG_DRAM_ZQ=3881977
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-pc2"
+CONFIG_OF_LIST="sun50i-h5-orangepi-pc2"
+CONFIG_FIT=y
+CONFIG_SPL_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_OF_LIBFDT=y
+CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
 # CONFIG_CMD_IMLS is not set
-- 
2.8.2

-- 
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 12/17] Makefile: add rules to generate SPL FIT images

[Andre Przywara]

Some platforms require more complex U-Boot images than we can easily
generate via the mkimage command line, for instance to load additional
image files.
Introduce a CONFIG_SPL_FIT_SOURCE and CONFIG_SPL_FIT_GENERATOR symbol,
which can either hold an .its source file describing the image layout,
or, in the second case, a generator tool (script) to create such
a source file. This script gets passed the list of device tree files
from the CONFIG_OF_LIST variable.
A platform or board can define either of those in their defconfig file
to allow an easy building of such an image.

Signed-off-by: Andre Przywara 
---
 Kconfig  | 17 +
 Makefile | 20 
 2 files changed, 37 insertions(+)

diff --git a/Kconfig b/Kconfig
index 81b4226..f3e4243 100644
--- a/Kconfig
+++ b/Kconfig
@@ -238,6 +238,23 @@ config SPL_FIT_IMAGE_POST_PROCESS
  injected into the FIT creation (i.e. the blobs would have been pre-
  processed before being added to the FIT image).
 
+config SPL_FIT_SOURCE
+   string ".its source file for U-Boot FIT image"
+   depends on SPL_FIT
+   help
+ Specifies a (platform specific) FIT source file to generate the
+ U-Boot FIT image. This could specify further image to load and/or
+ execute.
+
+config SPL_FIT_GENERATOR
+   string ".its file generator script for U-Boot FIT image"
+   depends on SPL_FIT
+   help
+ Specifies a (platform specific) script file to generate the FIT
+ source file used to build the U-Boot FIT image file. This gets
+ passed a list of supported device tree file stub names to
+ include in the generated image.
+
 endif # FIT
 
 config OF_BOARD_SETUP
diff --git a/Makefile b/Makefile
index 38b42da..e09b0d9 100644
--- a/Makefile
+++ b/Makefile
@@ -826,6 +826,10 @@ quiet_cmd_mkimage = MKIMAGE $@
 cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
$(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT))
 
+quiet_cmd_mkfitimage = MKIMAGE $@
+cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f 
$(U_BOOT_ITS) -E $@ \
+   $(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT))
+
 quiet_cmd_cat = CAT $@
 cmd_cat = cat $(filter-out $(PHONY), $^) > $@
 
@@ -945,6 +949,19 @@ quiet_cmd_cpp_cfg = CFG $@
 cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \
-DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $<
 
+# Boards with more complex image requirments can provide an .its source file
+# or a generator script
+ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
+U_BOOT_ITS = $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
+else
+ifneq ($(CONFIG_SPL_FIT_GENERATOR),"")
+U_BOOT_ITS := u-boot.its
+$(U_BOOT_ITS): FORCE
+   $(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \
+   $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@
+endif
+endif
+
 ifdef CONFIG_SPL_LOAD_FIT
 MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
@@ -977,6 +994,9 @@ u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl 
u-boot-ivt.img: \
$(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin 
dts/dt.dtb,u-boot.bin) FORCE
$(call if_changed,mkimage)
 
+u-boot.itb: u-boot-nodtb.bin dts/dt.dtb $(U_BOOT_ITS) FORCE
+   $(call if_changed,mkfitimage)
+
 u-boot-spl.kwb: u-boot.img spl/u-boot-spl.bin FORCE
$(call if_changed,mkimage)
 
-- 
2.8.2

-- 
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 09/17] sunxi: A64: move SPL stack to end of SRAM A2

[Andre Przywara]

The SPL stack is usually located at the end of SRAM A1, where it grows
towards the end of the SPL.
For the really big AArch64 binaries the stack overwrites code pretty
soon, so move the SPL stack to the end of SRAM A2, which is unused at this
time.

Signed-off-by: Andre Przywara 
---
 include/configs/sunxi-common.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 5fe886b..37c4a4d 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -186,7 +186,12 @@
 #ifdef CONFIG_SUNXI_HIGH_SRAM
 #define CONFIG_SPL_TEXT_BASE   0x10040 /* sram start+header */
 #define CONFIG_SPL_MAX_SIZE0x7fc0  /* 32 KiB */
+#ifdef CONFIG_ARM64
+/* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
+#define LOW_LEVEL_SRAM_STACK   0x00054000
+#else
 #define LOW_LEVEL_SRAM_STACK   0x00018000
+#endif /* !CONFIG_ARM64 */
 #else
 #define CONFIG_SPL_TEXT_BASE   0x40/* sram start+header */
 #define CONFIG_SPL_MAX_SIZE0x5fc0  /* 24KB on sun4i/sun7i 
*/
-- 
2.8.2

-- 
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 08/17] armv8: fsl: move ccn504 code into FSL Makefile

[Andre Przywara]

The generic ARMv8 assembly code contains routines for setting up
a CCN interconnect, though the Freescale SoCs are the only user.
Link this code only for Freescale targets, this saves some precious
bytes in the chronically tight SPL.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile | 1 +
 arch/arm/lib/Makefile  | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index c9ab93e..ca09973 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@
 obj-y += cpu.o
 obj-y += lowlevel.o
 obj-y += soc.o
+obj-y += ccn504.o
 obj-$(CONFIG_MP) += mp.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 71de1ca..60ffb4a 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -43,7 +43,6 @@ obj-y += stack.o
 ifdef CONFIG_CPU_V7M
 obj-y  += interrupts_m.o
 else ifdef CONFIG_ARM64
-obj-y  += ccn504.o
 ifneq ($(CONFIG_GICV2)$(CONFIG_GICV3),)
 obj-y  += gic_64.o
 endif
-- 
2.8.2

-- 
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 04/17] SPL: FIT: factor out spl_load_fit_image()

[Andre Przywara]

At the moment we load two images from a FIT image: the actual U-Boot
image and the DTB. Both times we have very similar code to deal with
alignment requirement the media we load from imposes upon us.
Factor out this code into a new function, which we just call twice.

Signed-off-by: Andre Przywara 
---
 common/spl/spl_fit.c | 129 +++
 1 file changed, 57 insertions(+), 72 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 572a5db..ad5ba15 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -18,7 +18,7 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const 
char *prop)
 
cell = fdt_getprop(fdt, node, prop, );
if (len != sizeof(*cell))
-   return -1U;
+   return -1UL;
return fdt32_to_cpu(*cell);
 }
 
@@ -139,19 +139,63 @@ static int get_aligned_image_size(struct spl_load_info 
*info, int data_size,
return (data_size + info->bl_len - 1) / info->bl_len;
 }
 
+static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
+ void *fit, ulong base_offset, int node,
+ struct spl_image_info *image_info)
+{
+   ulong offset;
+   size_t length;
+   ulong load_addr, load_ptr, entry;
+   void *src;
+   ulong overhead;
+   int nr_sectors;
+   int align_len = ARCH_DMA_MINALIGN - 1;
+
+   offset = fdt_getprop_u32(fit, node, "data-offset") + base_offset;
+   length = fdt_getprop_u32(fit, node, "data-size");
+   load_addr = fdt_getprop_u32(fit, node, "load");
+   if (load_addr == -1UL && image_info)
+   load_addr = image_info->load_addr;
+   load_ptr = (load_addr + align_len) & ~align_len;
+   entry = fdt_getprop_u32(fit, node, "entry");
+
+   overhead = get_aligned_image_overhead(info, offset);
+   nr_sectors = get_aligned_image_size(info, length, offset);
+
+   if (info->read(info, sector + get_aligned_image_offset(info, offset),
+  nr_sectors, (void*)load_ptr) != nr_sectors)
+   return -EIO;
+   debug("image: dst=%lx, offset=%lx, size=%lx\n", load_ptr, offset,
+ (unsigned long)length);
+
+   src = (void *)load_ptr + overhead;
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+   board_fit_image_post_process(, );
+#endif
+
+   memcpy((void*)load_addr, src, length);
+
+   if (image_info) {
+   image_info->load_addr = load_addr;
+   image_info->size = length;
+   if (entry == -1UL)
+   image_info->entry_point = load_addr;
+   else
+   image_info->entry_point = entry;
+   }
+
+   return 0;
+}
+
 int spl_load_simple_fit(struct spl_image_info *spl_image,
struct spl_load_info *info, ulong sector, void *fit)
 {
int sectors;
-   ulong size, load;
+   ulong size;
unsigned long count;
+   struct spl_image_info image_info;
int node, images;
-   void *load_ptr;
-   int fdt_offset, fdt_len;
-   int data_offset, data_size;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
-   int src_sector;
-   void *dst, *src;
 
/*
 * Figure out where the external images start. This is the base for the
@@ -203,82 +247,23 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
return -1;
}
 
-   /* Get its information and set up the spl_image structure */
-   data_offset = fdt_getprop_u32(fit, node, "data-offset");
-   data_size = fdt_getprop_u32(fit, node, "data-size");
-   load = fdt_getprop_u32(fit, node, "load");
-   debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
-   spl_image->load_addr = load;
-   spl_image->entry_point = load;
+   /* Load the image and set up the spl_image structure */
+   spl_load_fit_image(info, sector, fit, base_offset, node, spl_image);
spl_image->os = IH_OS_U_BOOT;
 
-   /*
-* Work out where to place the image. We read it so that the first
-* byte will be at 'load'. This may mean we need to load it starting
-* before then, since we can only read whole blocks.
-*/
-   data_offset += base_offset;
-   sectors = get_aligned_image_size(info, data_size, data_offset);
-   load_ptr = (void *)load;
-   debug("U-Boot size %x, data %p\n", data_size, load_ptr);
-   dst = load_ptr;
-
-   /* Read the image */
-   src_sector = sector + get_aligned_image_offset(info, data_offset);
-   debug("Aligned image read: dst=%p, src_sector=%x, sectors=%x\n",
- dst, src_sector, sectors);
-   count = info->read(info, src_sector, sectors, dst);
-   if (count != sectors)
-   return -EIO;
-   debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
- data_size);
-   src = 

[linux-sunxi] [PATCH 00/17] SPL: extend FIT loading support

[Andre Przywara]

This is an updated and slightly extended version of the SPL FIT loading
series I posted as an RFC some weeks ago.
I tried to fix all bugs that have been pointed out by the diligent
reviewers, also added patches to automatically build the FIT images.

The first patch is a bug fix for a regression introduced with -rc1.
I put this in there to allow people testing the series and to provide
an actual patch for this fix, which should make it still into 2017.03.
The next four patches introduce the core of the extened SPL FIT loading
support, see below for a description.
Patches 6-9 make some room in the sunxi 64-bit SPL to allow
compiling in the FIT loading bits. Patch 10 and 11 let the SPL choose
the proper DT from the FIT image.
The next two patches add the infrastructure and an actual generator script,
so the FIT image is automatically created at build time.
Patches 14 and 15 enable the SPL FIT support in the Pine64 and the
OrangePi PC 2 defconfigs.
The last two patches are new and eventually store a DT file name in the
SPL header, so U-Boot can easily pick the proper DT when scanning the
FIT image. The idea is that this DT name should stay with the board,
ideally on eMMC or SPI flash. So both U-Boot and a firmware update tool
could identify a board, updating with compatible firmware while keeping
the DT name in place. Ideally a board vendor would once seed this name
onto on-board storage like SPI flash.

Let me know what you think!

Cheers,
Andre.

Based on top of sunxi/master (35affe7698e9).

---
Currently the FIT format is not used to its full potential in the SPL:
It only loads the first image from the /images node and appends the
proper FDT.
Some boards and platforms would benefit from loading more images before
starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot.

This series tries to solve this in a board agnostic and generic way:
We extend the SPL FIT loading scheme to allow loading multiple images.
So apart from loading the image which is referenced by the "firmware"
property in the respective configuration node and placing the DTB right
behind it, we iterate over all strings in the "loadable" property.
Each image referenced there will be loaded to its specified load address.
The entry point U-Boot eventually branches to will be taken from the
first image to explicitly provide the "entry" property, or, if none
of them does so, from the load address of the "firmware" image.
This keeps the scheme compatible with the FIT images our Makefile creates
automatically at the moment.
Apart from the already mentioned ATF scenario this opens up more usage
scenarios, of which the commit message of patch 04/11 lists some.
The remaining patches prepare ane finally enable this scheme for the 64-bit
Allwinner boards.

Andre Przywara (15):
  SPL: FIT: refactor FDT loading
  SPL: FIT: rework U-Boot image loading
  SPL: FIT: factor out spl_load_fit_image()
  SPL: FIT: allow loading multiple images
  tools: mksunxiboot: allow larger SPL binaries
  armv8: SPL: only compile GIC code if needed
  armv8: fsl: move ccn504 code into FSL Makefile
  sunxi: A64: move SPL stack to end of SRAM A2
  sunxi: SPL: store RAM size in gd
  sunxi: SPL: add FIT config selector for Pine64 boards
  Makefile: add rules to generate SPL FIT images
  sunxi: A64: Pine64: introduce FIT generator script
  sunxi: Pine64: defconfig: enable SPL FIT support
  sunxi: OrangePi-PC2: defconfig: enable SPL FIT support
  sunxi: use SPL header DT name for FIT board matching

Philipp Tomsich (1):
  armv8: spl: Call spl_relocate_stack_gd for ARMv8

Siarhei Siamashka (1):
  sunxi: Store the device tree name in the SPL header

 Kconfig|  17 ++
 Makefile   |  20 +++
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   1 +
 arch/arm/include/asm/arch-sunxi/spl.h  |  19 ++-
 arch/arm/lib/Makefile  |   3 +-
 arch/arm/lib/crt0_64.S |  14 +-
 board/sunxi/board.c|  36 -
 board/sunxi/mksunxi_fit_atf.sh |  73 +
 common/spl/spl_fit.c   | 246 +
 configs/orangepi_pc2_defconfig |   6 +
 configs/pine64_plus_defconfig  |   6 +
 include/configs/sunxi-common.h |  17 +-
 scripts/Makefile.spl   |   3 +-
 tools/mksunxiboot.c|  51 +-
 14 files changed, 387 insertions(+), 125 deletions(-)
 create mode 100755 board/sunxi/mksunxi_fit_atf.sh

-- 
2.8.2

-- 
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 16/17] sunxi: Store the device tree name in the SPL header

[Andre Przywara]

From: Siarhei Siamashka 

This patch updates the mksunxiboot tool to optionally add
the default device tree name string to the SPL header. This
information can be used by the firmware upgrade tools to
protect users from harming themselves by trying to upgrade
to an incompatible bootloader.

The primary use case here is a non-removable bootable media
(such as NAND, eMMC or SPI flash), which already may have
a properly working, but a little bit outdated bootloader
installed. For example, the user may download or build a
new U-Boot image for "Cubieboard", and then attemept to
install it on a "Cubieboard2" hardware by mistake as a
replacement for the already existing bootloader. If this
happens, the flash programming tool can identify this
problem and warn the user.

The size of the SPL header is also increased from 64 bytes
to 96 bytes to provide enough space for the device tree name
string.
[Andre: split patch to remove OF_LIST hash feature]

Signed-off-by: Siarhei Siamashka 
Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/spl.h | 19 +++---
 include/configs/sunxi-common.h|  8 +++---
 scripts/Makefile.spl  |  3 ++-
 tools/mksunxiboot.c   | 49 ---
 4 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/spl.h 
b/arch/arm/include/asm/arch-sunxi/spl.h
index 831d0c0..9358397 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -10,7 +10,7 @@
 
 #define BOOT0_MAGIC"eGON.BT0"
 #define SPL_SIGNATURE  "SPL" /* marks "sunxi" SPL header */
-#define SPL_HEADER_VERSION 1
+#define SPL_HEADER_VERSION 2
 
 #ifdef CONFIG_SUNXI_HIGH_SRAM
 #define SPL_ADDR   0x1
@@ -58,11 +58,24 @@ struct boot_file_head {
 * compatible format, ready to be imported via "env import -t".
 */
uint32_t fel_uEnv_length;
-   uint32_t reserved1[2];
+   /*
+* Offset of an ASCIIZ string (relative to the SPL header), which
+* contains the default device tree name (CONFIG_DEFAULT_DEVICE_TREE).
+* This is optional and may be set to NULL. Is intended to be used
+* by flash programming tools for providing nice informative messages
+* to the users.
+*/
+   uint32_t dt_name_offset;
+   uint32_t reserved1;
uint32_t boot_media;/* written here by the boot ROM */
-   uint32_t reserved2[5];  /* padding, align to 64 bytes */
+   /* A padding area (may be used for storing text strings) */
+   uint32_t string_pool[13];
+   /* The header must be a multiple of 32 bytes (for VBAR alignment) */
 };
 
+/* Compile time check to assure proper alignment of structure */
+typedef char boot_file_head_not_multiple_of_32[1 - 2*(sizeof(struct 
boot_file_head) % 32)];
+
 #define is_boot0_magic(addr)   (memcmp((void *)addr, BOOT0_MAGIC, 8) == 0)
 
 #endif
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 06d03d4..e37bf6a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -188,8 +188,8 @@
 #endif
 
 #ifdef CONFIG_SUNXI_HIGH_SRAM
-#define CONFIG_SPL_TEXT_BASE   0x10040 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x7fc0  /* 32 KiB */
+#define CONFIG_SPL_TEXT_BASE   0x10060 /* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x7fa0  /* 32 KiB */
 #ifdef CONFIG_ARM64
 /* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
 #define LOW_LEVEL_SRAM_STACK   0x00054000
@@ -197,8 +197,8 @@
 #define LOW_LEVEL_SRAM_STACK   0x00018000
 #endif /* !CONFIG_ARM64 */
 #else
-#define CONFIG_SPL_TEXT_BASE   0x40/* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fc0  /* 24KB on sun4i/sun7i 
*/
+#define CONFIG_SPL_TEXT_BASE   0x60/* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x5fa0  /* 24KB on sun4i/sun7i 
*/
 #define LOW_LEVEL_SRAM_STACK   0x8000  /* End of sram */
 #endif
 
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index b52f996..fe827ce 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -285,7 +285,8 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mkimage)
 
 quiet_cmd_mksunxiboot = MKSUNXI $@
-cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
+cmd_mksunxiboot = $(objtree)/tools/mksunxiboot \
+   --default-dt $(CONFIG_DEFAULT_DEVICE_TREE) $< $@
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mksunxiboot)
 
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 6bb649c..4ac2791 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -70,11 +70,40 @@ int main(int 

[linux-sunxi] [PATCH 14/17] sunxi: Pine64: defconfig: enable SPL FIT support

[Andre Przywara]

The Pine64 (and all other 64-bit Allwinner boards) need to load an
ARM Trusted Firmware image beside the actual U-Boot proper.
This can now be easily achieved by using the just extended SPL FIT
loading support, so enable it in the Pine64 defconfig.
Also add the FIT image as a build target to 64-bit sunxi board to
trigger the respective Makefile rules.

Signed-off-by: Andre Przywara 
---
 configs/pine64_plus_defconfig  | 6 ++
 include/configs/sunxi-common.h | 4 
 2 files changed, 10 insertions(+)

diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 7c7d86f..2b47157 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN50I=y
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
+CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
 CONFIG_SPL=y
+CONFIG_FIT=y
+CONFIG_SPL_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_OF_LIBFDT=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
@@ -14,3 +19,4 @@ CONFIG_SPL=y
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh"
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 37c4a4d..06d03d4 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -39,6 +39,10 @@
 #define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */
 #endif
 
+#ifdef CONFIG_ARM64
+#define CONFIG_BUILD_TARGET "u-boot.itb"
+#endif
+
 /* Serial & console */
 #define CONFIG_SYS_NS16550_SERIAL
 /* ns16550 reg in the low bits of cpu reg */
-- 
2.8.2

-- 
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 17/17] sunxi: use SPL header DT name for FIT board matching

[Andre Przywara]

Now that we can store a DT name in the SPL header, use this string (if
available) when finding the right DT blob to load for U-Boot proper.
This allows a generic U-Boot (proper) image to be combined with a bunch
of supported DTs, with just the SPL (possibly only that string) to be
different.
Eventually this string can be written after the build process by some
firmware update tool.

Signed-off-by: Andre Przywara 
---
 board/sunxi/board.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 2ddff28..714f8fd 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -729,13 +729,19 @@ int ft_board_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
-   const char *cmp_str;
+   struct boot_file_head *spl = (void *)(ulong)SPL_ADDR;
+   const char *cmp_str = (void *)(ulong)SPL_ADDR;
 
+   /* Check if there is a DT name stored in the SPL header and use that. */
+   if (spl->dt_name_offset) {
+   cmp_str += spl->dt_name_offset;
+   } else {
 #ifdef CONFIG_DEFAULT_DEVICE_TREE
-   cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
+   cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
 #else
-   return 0;
+   return 0;
 #endif
+   };
 
 /* Differentiate the two Pine64 board DTs by their DRAM size. */
if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
-- 
2.8.2

-- 
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 07/17] armv8: SPL: only compile GIC code if needed

[Andre Przywara]

Not every SoC needs to set up the GIC interrupt controller, so link
think code only when the respective config option is set.
This shaves off some bytes from the SPL code size.

Signed-off-by: Andre Przywara 
---
 arch/arm/lib/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 166fa9e..71de1ca 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -44,7 +44,9 @@ ifdef CONFIG_CPU_V7M
 obj-y  += interrupts_m.o
 else ifdef CONFIG_ARM64
 obj-y  += ccn504.o
+ifneq ($(CONFIG_GICV2)$(CONFIG_GICV3),)
 obj-y  += gic_64.o
+endif
 obj-y  += interrupts_64.o
 else
 obj-y  += interrupts.o
-- 
2.8.2

-- 
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 10/17] sunxi: SPL: store RAM size in gd

[Andre Przywara]

The sunxi SPL was holding the detected RAM size in some local variable
only, so it wasn't accessible for other functions.
Store the value in gd->ram_size instead, so it can be used later on.

Signed-off-by: Andre Przywara 
---
 board/sunxi/board.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index b966012..a510422 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -480,7 +480,6 @@ void i2c_init_board(void)
 void sunxi_board_init(void)
 {
int power_failed = 0;
-   unsigned long ramsize;
 
 #ifdef CONFIG_SY8106A_POWER
power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
@@ -541,9 +540,9 @@ void sunxi_board_init(void)
 #endif
 #endif
printf("DRAM:");
-   ramsize = sunxi_dram_init();
-   printf(" %d MiB\n", (int)(ramsize >> 20));
-   if (!ramsize)
+   gd->ram_size = sunxi_dram_init();
+   printf(" %d MiB\n", (int)(gd->ram_size >> 20));
+   if (!gd->ram_size)
hang();
 
/*
-- 
2.8.2

-- 
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 11/17] sunxi: SPL: add FIT config selector for Pine64 boards

[Andre Przywara]

For a board or platform to support FIT loading in the SPL, it has to
provide a board_fit_config_name_match() routine, which helps to select
one of possibly multiple DTBs contained in a FIT image.
Provide a simple function which chooses the DT name U-Boot was
configured with.
If the DT name is one of the two Pine64 versions, determine the exact
model by checking the DRAM size.

Signed-off-by: Andre Przywara 
---
 board/sunxi/board.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index a510422..2ddff28 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -725,3 +725,26 @@ int ft_board_setup(void *blob, bd_t *bd)
 #endif
return 0;
 }
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+   const char *cmp_str;
+
+#ifdef CONFIG_DEFAULT_DEVICE_TREE
+   cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
+#else
+   return 0;
+#endif
+
+/* Differentiate the two Pine64 board DTs by their DRAM size. */
+   if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
+   if ((gd->ram_size > 512 * 1024 * 1024))
+   return !strstr(name, "plus");
+   else
+   return !!strstr(name, "plus");
+   } else {
+   return strcmp(name, cmp_str);
+   }
+}
+#endif
-- 
2.8.2

-- 
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 01/17] armv8: spl: Call spl_relocate_stack_gd for ARMv8

[Andre Przywara]

From: Philipp Tomsich 

As part of the startup process for boards using the SPL, we need to
call spl_relocate_stack_gd. This is needed to set up malloc with its
DRAM buffer.
[Andre: fix comment]

Signed-off-by: Philipp Tomsich 
Reviewed-by: Andre Przywara 
Reviewed-by: Simon Glass 
Signed-off-by: Andre Przywara 
---
 arch/arm/lib/crt0_64.S | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index 19c6a98..e59fd3e 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -109,8 +109,18 @@ relocation_return:
  */
bl  c_runtime_cpu_setup /* still call old routine */
 #endif /* !CONFIG_SPL_BUILD */
-
-/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
+#if defined(CONFIG_SPL_BUILD)
+   bl  spl_relocate_stack_gd   /* may return NULL */
+   /*
+* Perform 'sp = (x0 != NULL) ? x0 : sp' while working
+* around the constraint that most arm64 instructions cannot
+* have 'sp' as an operand.
+*/
+   mov x1, sp
+   cmp x0, #0
+   cselx0, x0, x1, ne
+   mov sp, x0
+#endif
 
 /*
  * Clear BSS section
-- 
2.8.2

-- 
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 06/17] tools: mksunxiboot: allow larger SPL binaries

[Andre Przywara]

mksunxiboot limits the size of the resulting SPL binaries to pretty
conservative values to cover all SoCs and all boot media (NAND).
It turns out that we have limit checks in place in the build process,
so mksunxiboot can be relaxed and allow packaging binaries up to the
actual 32KB the mask boot ROM actually imposes.
This allows to have a bigger SPL, which is crucial for AArch64 builds.

Signed-off-by: Andre Przywara 
---
 tools/mksunxiboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 0f0b003..6bb649c 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -48,7 +48,7 @@ int gen_check_sum(struct boot_file_head *head_p)
 #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1)
 #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask))
 
-#define SUN4I_SRAM_SIZE 0x7600 /* 0x7748+ is used by BROM */
+#define SUN4I_SRAM_SIZE 0x8000 /* SoC with smaller size are limited before */
 #define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
 
 /*
-- 
2.8.2

-- 
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 5/5] pinctrl: sunxi: Add A64 R_PIO controller support

[Icenowy Zheng]

2017年3月1日 10:34于 Chen-Yu Tsai 写道：
>
> On Wed, Mar 1, 2017 at 2:29 AM, Andre Przywara  
> wrote: 
> > Hi, 
> > 
> > On 28/02/17 17:24, Icenowy Zheng wrote: 
> >> The A64 has a R_PIO pin controller, similar to the one found on the H3 
> >> SoC. 
> >> Add support for the pins controlled by the R_PIO controller. 
> >> 
> >> Signed-off-by: Icenowy Zheng  
> >> --- 
> >>  drivers/pinctrl/sunxi/Kconfig    |   5 + 
> >>  drivers/pinctrl/sunxi/Makefile   |   1 + 
> >>  drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c | 143 
> >>+++ 
> >>  3 files changed, 149 insertions(+) 
> >>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c 
> >> 
> >> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig 
> >> index 92325736d953..0738b0df5a0b 100644 
> >> --- a/drivers/pinctrl/sunxi/Kconfig 
> >> +++ b/drivers/pinctrl/sunxi/Kconfig 
> >> @@ -69,6 +69,11 @@ config PINCTRL_SUN50I_A64 
> >>   def_bool ARM64 && ARCH_SUNXI 
> >>   select PINCTRL_SUNXI 
> >> 
> >> +config PINCTRL_SUN50I_A64_R 
> >> + def_bool ARM64 && ARCH_SUNXI 
> >> + depends on RESET_CONTROLLER 
> > 
> > Same comment as on patch 1/5 (select instead of "depends on"). 
> > I take it this for drivers/reset/reset-sunxi.c? 
> > Shouldn't this be the sunxi specific CONFIG_RESET_SUNXI then? 
> > Also from from having a quick look at the driver this is broken for 
> > arm64 (BITS_PER_LONG usage). 
> > From having a closer look this driver is actually not Allwinner specific 
> > at all, since it just describes a number of bits in consecutive 
> > 32-bit(!) registers as reset cells. 
> > As I today stumbled upon another SoC which has the same reset register 
> > layout I was wondering if it's worth to generalise this? Possibly 
> > renaming the driver, and allowing additional compatibles? 
> > I can take a stab at this. 
>
> CONFIG_RESET_SUNXI enables the old (pre-sunxi-ng) reset controller driver. 
> This driver was never used for ARM64 sunxi. As for it being generic, 
> I guess it's pretty standard, as it's just a bunch of registers with each 
> bit assigned to some peripheral. 
>
> CONFIG_RESET enables the reset control subsystem, which we need. This 
> is enabled by default if the platform selects ARCH_HAS_RESET_CONTROLLER, 
> which we do. 
>

On ARM64 ARCH_SUNXI  ARCH_HAS_RESET_CONTROLLER
is forgot to be selected.

I will soon send out a patch for it.

P.S. I think thus sunxi-ng should select RESET_CONTROLLER again, as it may be 
built with COMPILE_TEST.

> Regards 
> ChenYu 
>
> > Cheers, 
> > Andre. 
> > 
> >> + select PINCTRL_SUNXI 
> >> + 
> >>  config PINCTRL_SUN50I_H5 
> >>   def_bool ARM64 && ARCH_SUNXI 
> >>   select PINCTRL_SUNXI 
> >> diff --git a/drivers/pinctrl/sunxi/Makefile 
> >> b/drivers/pinctrl/sunxi/Makefile 
> >> index 04ccb88ebd5f..df4ccd6cd44c 100644 
> >> --- a/drivers/pinctrl/sunxi/Makefile 
> >> +++ b/drivers/pinctrl/sunxi/Makefile 
> >> @@ -11,6 +11,7 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23) += 
> >> pinctrl-sun8i-a23.o 
> >>  obj-$(CONFIG_PINCTRL_SUN8I_A23_R)    += pinctrl-sun8i-a23-r.o 
> >>  obj-$(CONFIG_PINCTRL_SUN8I_A33)  += pinctrl-sun8i-a33.o 
> >>  obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o 
> >> +obj-$(CONFIG_PINCTRL_SUN50I_A64_R)   += pinctrl-sun50i-a64-r.o 
> >>  obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o 
> >>  obj-$(CONFIG_PINCTRL_SUN8I_H3)   += pinctrl-sun8i-h3.o 
> >>  obj-$(CONFIG_PINCTRL_SUN8I_H3_R) += pinctrl-sun8i-h3-r.o 
> >> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c 
> >> b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c 
> >> new file mode 100644 
> >> index ..90996a63689b 
> >> --- /dev/null 
> >> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c 
> >> @@ -0,0 +1,143 @@ 
> >> +/* 
> >> + * Allwinner A64 SoCs special pins pinctrl driver. 
> >> + * 
> >> + * Based on pinctrl-sun8i-a23-r.c 
> >> + * 
> >> + * Copyright (C) 2016 Icenowy Zheng 
> >> + * Icenowy Zheng  
> >> + * 
> >> + * Copyright (C) 2014 Chen-Yu Tsai 
> >> + * Chen-Yu Tsai  
> >> + * 
> >> + * Copyright (C) 2014 Boris Brezillon 
> >> + * Boris Brezillon  
> >> + * 
> >> + * Copyright (C) 2014 Maxime Ripard 
> >> + * Maxime Ripard  
> >> + * 
> >> + * This file is licensed under the terms of the GNU General Public 
> >> + * License version 2.  This program is licensed "as is" without any 
> >> + * warranty of any kind, whether express or implied. 
> >> + */ 
> >> + 
> >> +#include  
> >> +#include  
> >> +#include  
> >> +#include  
> >> +#include  
> >> + 
> >> +#include "pinctrl-sunxi.h" 
> >> + 
> >> +static const struct sunxi_desc_pin sun50i_a64_r_pins[] = { 
> >> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0), 
> >> +   SUNXI_FUNCTION(0x0, "gpio_in"), 
> >> +   

[linux-sunxi] [PATCH 3/3] arm64: dts: allwinner: add r_ccu node

[Icenowy Zheng]

A64 SoC have a CCU (r_ccu) in PRCM block.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1c64ea2d23f9..e8be100b91a0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -43,8 +43,10 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 / {
interrupt-parent = <>;
@@ -392,5 +394,14 @@
interrupts = ,
 ;
};
+
+   r_ccu: clock@1f01400 {
+   compatible = "allwinner,sun50i-a64-r-ccu";
+   reg = <0x01cf01400 0x100>;
+   clocks = <>, <>;
+   clock-names = "hosc", "losc";
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
};
 };
-- 
2.11.1

-- 
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 02/12] sunxi: Enable AXP221s in I2C mode with the R40 SoC

[Chen-Yu Tsai]

The R40 SoC uses the AXP221s in I2C mode to supply power.

Some regulator's common usages have changed, and also the recommended
voltage for existing usages have changed. Update the defaults to match.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-sunxi/pmic_bus.c |  7 +++
 board/sunxi/Kconfig|  2 +-
 drivers/power/Kconfig  | 16 ++--
 3 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
index 7c57f02792b9..f917c3e070a5 100644
--- a/arch/arm/mach-sunxi/pmic_bus.c
+++ b/arch/arm/mach-sunxi/pmic_bus.c
@@ -41,6 +41,9 @@ int pmic_bus_init(void)
p2wi_init();
ret = p2wi_change_to_p2wi_mode(AXP221_CHIP_ADDR, AXP221_CTRL_ADDR,
   AXP221_INIT_DATA);
+# elif defined CONFIG_MACH_SUN8I_R40
+   /* Nothing. R40 uses the AXP221s in I2C mode */
+   ret = 0;
 # else
ret = rsb_init();
if (ret)
@@ -65,6 +68,8 @@ int pmic_bus_read(u8 reg, u8 *data)
 #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined 
CONFIG_AXP818_POWER
 # ifdef CONFIG_MACH_SUN6I
return p2wi_read(reg, data);
+# elif defined CONFIG_MACH_SUN8I_R40
+   return i2c_read(AXP209_I2C_ADDR, reg, 1, data, 1);
 # else
return rsb_read(AXP223_RUNTIME_ADDR, reg, data);
 # endif
@@ -80,6 +85,8 @@ int pmic_bus_write(u8 reg, u8 data)
 #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined 
CONFIG_AXP818_POWER
 # ifdef CONFIG_MACH_SUN6I
return p2wi_write(reg, data);
+# elif defined CONFIG_MACH_SUN8I_R40
+   return i2c_write(AXP209_I2C_ADDR, reg, 1, , 1);
 # else
return rsb_write(AXP223_RUNTIME_ADDR, reg, data);
 # endif
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 8e8b9cd0d5fd..e89ddf626289 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -456,7 +456,7 @@ config USB3_VBUS_PIN
 
 config I2C0_ENABLE
bool "Enable I2C/TWI controller 0"
-   default y if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
+   default y if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUN8I_R40
default n if MACH_SUN6I || MACH_SUN8I
select CMD_I2C
---help---
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 64e5bc2f74b4..911ecb1144a6 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -10,7 +10,7 @@ choice
prompt "Select Sunxi PMIC Variant"
depends on ARCH_SUNXI
default AXP209_POWER if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
-   default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33
+   default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 
|| MACH_SUN8I_R40
default AXP818_POWER if MACH_SUN8I_A83T
default SUNXI_NO_PMIC if MACH_SUNXI_H3_H5 || MACH_SUN50I
 
@@ -37,7 +37,7 @@ config AXP209_POWER
 
 config AXP221_POWER
bool "axp221 / axp223 pmic support"
-   depends on MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33
+   depends on MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 || 
MACH_SUN8I_R40
select CMD_POWEROFF
---help---
Select this to enable support for the axp221/axp223 pmic found on most
@@ -70,7 +70,7 @@ endchoice
 config AXP_DCDC1_VOLT
int "axp pmic dcdc1 voltage"
depends on AXP221_POWER || AXP809_POWER || AXP818_POWER
-   default 3300 if AXP818_POWER
+   default 3300 if AXP818_POWER || MACH_SUN8I_R40
default 3000 if MACH_SUN6I || MACH_SUN8I || MACH_SUN9I
---help---
Set the voltage (mV) to program the axp pmic dcdc1 at, set to 0 to
@@ -97,6 +97,7 @@ config AXP_DCDC2_VOLT
On A23/A33 boards dcdc2 is used for VDD-SYS and should be 1.1V.
On A80 boards dcdc2 powers the GPU and can be left off.
On A83T boards dcdc2 is used for VDD-CPUA(cluster 0) and should be 0.9V.
+   On R40 boards dcdc2 is VDD-CPU and should be 1.1V
 
 config AXP_DCDC3_VOLT
int "axp pmic dcdc3 voltage"
@@ -104,6 +105,7 @@ config AXP_DCDC3_VOLT
default 900 if AXP809_POWER || AXP818_POWER
default 1500 if AXP152_POWER
default 1250 if AXP209_POWER
+   default 1100 if MACH_SUN8I_R40
default 1200 if MACH_SUN6I || MACH_SUN8I
---help---
Set the voltage (mV) to program the axp pmic dcdc3 at, set to 0 to
@@ -114,6 +116,7 @@ config AXP_DCDC3_VOLT
On A23 / A31 / A33 boards dcdc3 is VDD-CPU and should be 1.2V.
On A80 boards dcdc3 is used for VDD-CPUA(cluster 0) and should be 0.9V.
On A83T boards dcdc3 is used for VDD-CPUB(cluster 1) and should be 0.9V.
+   On R40 boards dcdc3 is VDD-SYS and VDD-GPU and should be 1.1V.
 
 config AXP_DCDC4_VOLT
int "axp pmic dcdc4 voltage"
@@ -138,13 +141,13 @@ config AXP_DCDC5_VOLT
---help---
Set the voltage (mV) to program the axp pmic dcdc5 at, set to 0 to
disable dcdc5.
-   On A23 / A31 / A33 / A80 / A83T boards dcdc5 is 

[linux-sunxi] [PATCH 04/12] sunxi: Add mmc[1-3] pinmux settings for R40

[Chen-Yu Tsai]

The PIO is generally compatible with the A20, except that it routes the
full 8 bits and eMMC reset pins for mmc2.

Signed-off-by: Chen-Yu Tsai 
---
 board/sunxi/board.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 495cb591a9fb..21ce8348922c 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -199,7 +199,8 @@ static void mmc_pinmux_setup(int sdc)
case 1:
pins = sunxi_name_to_gpio_bank(CONFIG_MMC1_PINS);
 
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
if (pins == SUNXI_GPIO_H) {
/* SDC1: PH22-PH-27 */
for (pin = SUNXI_GPH(22); pin <= SUNXI_GPH(27); pin++) {
@@ -294,6 +295,17 @@ static void mmc_pinmux_setup(int sdc)
sunxi_gpio_set_pull(SUNXI_GPC(24), SUNXI_GPIO_PULL_UP);
sunxi_gpio_set_drv(SUNXI_GPC(24), 2);
}
+#elif defined(CONFIG_MACH_SUN8I_R40)
+   /* SDC2: PC6-PC15, PC24 */
+   for (pin = SUNXI_GPC(6); pin <= SUNXI_GPC(15); pin++) {
+   sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SDC2);
+   sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+   sunxi_gpio_set_drv(pin, 2);
+   }
+
+   sunxi_gpio_set_cfgpin(SUNXI_GPC(24), SUNXI_GPC_SDC2);
+   sunxi_gpio_set_pull(SUNXI_GPC(24), SUNXI_GPIO_PULL_UP);
+   sunxi_gpio_set_drv(SUNXI_GPC(24), 2);
 #elif defined(CONFIG_MACH_SUN8I) || defined(CONFIG_MACH_SUN50I)
/* SDC2: PC5-PC6, PC8-PC16 */
for (pin = SUNXI_GPC(5); pin <= SUNXI_GPC(6); pin++) {
@@ -320,7 +332,8 @@ static void mmc_pinmux_setup(int sdc)
case 3:
pins = sunxi_name_to_gpio_bank(CONFIG_MMC3_PINS);
 
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
/* SDC3: PI4-PI9 */
for (pin = SUNXI_GPI(4); pin <= SUNXI_GPI(9); pin++) {
sunxi_gpio_set_cfgpin(pin, SUNXI_GPI_SDC3);
-- 
2.11.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 10/12] sunxi: Fix CPUCFG address for R40

[Chen-Yu Tsai]

The R40 has the CPUCFG block at the same address as the A20.
Fix it.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index ea672fe8449a..88c3f138173f 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -108,7 +108,7 @@ defined(CONFIG_MACH_SUN50I)
 #define SUNXI_TP_BASE  0x01c25000
 #define SUNXI_PMU_BASE 0x01c25400
 
-#ifdef CONFIG_MACH_SUN7I
+#if defined CONFIG_MACH_SUN7I || defined CONFIG_MACH_SUN8I_R40
 #define SUNXI_CPUCFG_BASE  0x01c25c00
 #endif
 
@@ -167,7 +167,9 @@ defined(CONFIG_MACH_SUN50I)
 #define SUNXI_RTC_BASE 0x01f0
 #define SUNXI_PRCM_BASE0x01f01400
 
-#if defined CONFIG_SUNXI_GEN_SUN6I && !defined CONFIG_MACH_SUN8I_A83T
+#if defined CONFIG_SUNXI_GEN_SUN6I && \
+!defined CONFIG_MACH_SUN8I_A83T && \
+!defined CONFIG_MACH_SUN8I_R40
 #define SUNXI_CPUCFG_BASE  0x01f01c00
 #endif
 
-- 
2.11.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 05/12] sunxi: Set PLL lock enable bits for R40

[Chen-Yu Tsai]

According to the BSP released by Banana Pi, the R40 (sun8iw11p1) has
an extra "PLL lock control" register in the CCU, which controls whether
the individual PLL lock status bits in each PLL's control register work
or not.

This patch enables it for all the PLLs.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 2 ++
 arch/arm/mach-sunxi/clock_sun6i.c | 5 +
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index 1bfb48bd52df..1aefd5a64c1f 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -142,6 +142,8 @@ struct sunxi_ccm_reg {
u32 apb2_reset_cfg; /* 0x2d8 APB2 Reset config */
u32 reserved25[5];
u32 ccu_sec_switch; /* 0x2f0 CCU Security Switch, H3 only */
+   u32 reserved26[11];
+   u32 pll_lock_ctrl;  /* 0x320 PLL lock control, R40 only */
 };
 
 /* apb2 bit field */
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index 4762fbf0c3f0..3c8c53fcf76b 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -35,6 +35,11 @@ void clock_init_safe(void)
clrbits_le32(>pll_ctrl1, PRCM_PLL_CTRL_LDO_KEY_MASK);
 #endif
 
+#ifdef CONFIG_MACH_SUN8I_R40
+   /* Set PLL lock enable bits and switch to old lock mode */
+   writel(GENMASK(12, 0), >pll_lock_ctrl);
+#endif
+
clock_set_pll1(40800);
 
writel(PLL6_CFG_DEFAULT, >pll6_cfg);
-- 
2.11.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 00/12] sunxi: Add support for R40 SoC

[Chen-Yu Tsai]

Hi everyone,

This series adds support for the new R40 SoC. The R40 is marketed as the
successor to the A20. It is mostly pin compatible (in software) with the
A20. It has a somewhat similar memory layout, a hybrid of A20 and newer
sun6i gen.. Like the A20, it does not have a PRCM block.

This series makes checkpatch throw out a lot of errors, mostly "no spaces
at the start of a line" or "space prohibited after that open parenthesis
'('", but fixing them does not improve the readability of the code.

Patch 1 introduces the R40 to U-boot, by adding a Kconfig symbol, fixing
up any SoC depends on in Kconfig to disable unsupported features, and
reworking board level pinmuxes.

Patch 2 enables using the AXP221s PMIC in I2C mode. The R40 is paired
with this PMIC, but it does not have a P2WI controller.

Patch 3 fixes the watchdog reset function for R40. The R40's watchdog
register layout is like the A10/A20.

Patch 4 adds mmc pinmux settings for R40.

Patch 5 fixes the PLL lock settings for the R40. The R40's CCU has a
new mode for PLL lock, which can be configured and also switched back
to the old mode. Here we just use the old mode, which is the same as
the other sun6i gen. SoCs.

Patch 6 provides some default DRAM settings for the R40. These were
taken from the Bananapi M2 Ultra, the only R40 board available.

Patch 7 adds the compatible string for the R40 PIO. It is mostly
compatible with the A20, with a few functions gone, and a few new
ones.

Patch 8 adds DRAM initialization support for the R40. The DRAM
controller is very similar to the A64 and H5, however the A15 line
and CSC1 line are muxed on the same pin. Also the PIR_QSGATE bit
must not be set, or DRAM init fails.

Patch 9 enables SPL for R40.

Patch 10 fixes the address of the CPUCFG block on the R40. It is
the same as on the A20.

Patch 11 adds a PSCI implementation for the R40. As the register
layout is slightly erratic, we just use a macro for the ones that
can't fit into the cpucfg register definition structure.

Patch 12 adds a board dts and defconfig for the Bananapi M2 Ultra.

Please have a look.

Regards
ChenYu

Chen-Yu Tsai (12):
  sunxi: Add initial support for R40
  sunxi: Enable AXP221s in I2C mode with the R40 SoC
  sunxi: Fix watchdog reset function for R40
  sunxi: Add mmc[1-3] pinmux settings for R40
  sunxi: Set PLL lock enable bits for R40
  sunxi: Provide defaults for R40 DRAM settings
  gpio: sunxi: Add compatible string for R40 PIO
  sunxi: Use H3/A64 DRAM initialization code for R40
  sunxi: Enable SPL for R40
  sunxi: Fix CPUCFG address for R40
  sunxi: Add PSCI support for R40
  sunxi: Add support for Bananapi M2 Ultra

 arch/arm/cpu/armv7/sunxi/psci.c |  35 -
 arch/arm/dts/Makefile   |   2 +
 arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts|  69 +
 arch/arm/dts/sun8i-r40.dtsi | 183 
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h   |   2 +
 arch/arm/include/asm/arch-sunxi/cpu.h   |   1 +
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h |   6 +-
 arch/arm/include/asm/arch-sunxi/dram.h  |   4 +-
 arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h |  20 ++-
 arch/arm/include/asm/arch-sunxi/timer.h |   5 +-
 arch/arm/include/asm/arch-sunxi/watchdog.h  |   5 +-
 arch/arm/mach-sunxi/Makefile|   1 +
 arch/arm/mach-sunxi/board.c |  15 +-
 arch/arm/mach-sunxi/clock_sun6i.c   |   9 +-
 arch/arm/mach-sunxi/cpu_info.c  |   2 +
 arch/arm/mach-sunxi/dram_sun8i_h3.c | 121 ++--
 arch/arm/mach-sunxi/pmic_bus.c  |   7 +
 board/sunxi/Kconfig |  18 ++-
 board/sunxi/MAINTAINERS |   6 +
 board/sunxi/board.c |  36 -
 configs/Bananapi_M2_Ultra_defconfig |  15 ++
 drivers/gpio/sunxi_gpio.c   |   1 +
 drivers/power/Kconfig   |  16 ++-
 23 files changed, 530 insertions(+), 49 deletions(-)
 create mode 100644 arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
 create mode 100644 arch/arm/dts/sun8i-r40.dtsi
 create mode 100644 configs/Bananapi_M2_Ultra_defconfig

-- 
2.11.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 03/12] sunxi: Fix watchdog reset function for R40

[Chen-Yu Tsai]

The watchdog found on the R40 SoC is the older variant found on the A20.
Add the proper "#if defines" to make it work.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/timer.h| 5 ++---
 arch/arm/include/asm/arch-sunxi/watchdog.h | 5 -
 arch/arm/mach-sunxi/board.c| 5 ++---
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/timer.h 
b/arch/arm/include/asm/arch-sunxi/timer.h
index a665309803cb..ccdf942534a4 100644
--- a/arch/arm/include/asm/arch-sunxi/timer.h
+++ b/arch/arm/include/asm/arch-sunxi/timer.h
@@ -67,7 +67,7 @@ struct sunxi_timer_reg {
struct sunxi_timer timer[6];/* We have 6 timers */
u8 res2[16];
struct sunxi_avs avs;
-#ifdef CONFIG_SUNXI_GEN_SUN4I
+#if defined(CONFIG_SUNXI_GEN_SUN4I) || defined(CONFIG_MACH_SUN8I_R40)
struct sunxi_wdog wdog; /* 0x90 */
/* XXX the following is not accurate for sun5i/sun7i */
struct sunxi_64cnt cnt64;   /* 0xa0 */
@@ -77,8 +77,7 @@ struct sunxi_timer_reg {
struct sunxi_tgp tgp[4];
u8 res5[8];
u32 cpu_cfg;
-#endif
-#ifdef CONFIG_SUNXI_GEN_SUN6I
+#elif defined(CONFIG_SUNXI_GEN_SUN6I)
u8 res3[16];
struct sunxi_wdog wdog[5];  /* We have 5 watchdogs */
 #endif
diff --git a/arch/arm/include/asm/arch-sunxi/watchdog.h 
b/arch/arm/include/asm/arch-sunxi/watchdog.h
index 8108be97bab0..ce6d66485609 100644
--- a/arch/arm/include/asm/arch-sunxi/watchdog.h
+++ b/arch/arm/include/asm/arch-sunxi/watchdog.h
@@ -13,7 +13,10 @@
 #define WDT_CTRL_RESTART   (0x1 << 0)
 #define WDT_CTRL_KEY   (0x0a57 << 1)
 
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I) || 
defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN5I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
 
 #define WDT_MODE_EN(0x1 << 0)
 #define WDT_MODE_RESET_EN  (0x1 << 1)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 5a74c9717d84..6ce07dfe0fd7 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -270,7 +270,7 @@ void board_init_f(ulong dummy)
 
 void reset_cpu(ulong addr)
 {
-#ifdef CONFIG_SUNXI_GEN_SUN4I
+#if defined(CONFIG_SUNXI_GEN_SUN4I) || defined(CONFIG_MACH_SUN8I_R40)
static const struct sunxi_wdog *wdog =
 &((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->wdog;
 
@@ -282,8 +282,7 @@ void reset_cpu(ulong addr)
/* sun5i sometimes gets stuck without this */
writel(WDT_MODE_RESET_EN | WDT_MODE_EN, >mode);
}
-#endif
-#ifdef CONFIG_SUNXI_GEN_SUN6I
+#elif defined(CONFIG_SUNXI_GEN_SUN6I)
static const struct sunxi_wdog *wdog =
 ((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->wdog;
 
-- 
2.11.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 11/12] sunxi: Add PSCI support for R40

[Chen-Yu Tsai]

The R40's CPU controls are a combination of sun6i and sun7i.

All controls are in the CPUCFG block, and it seems the R40 does not
have a PRCM block. The core reset, power gating and clamp controls
are grouped like sun6i.

Last, the R40 does not have a secure SRAM block.

This patch adds a PSCI implementation for CPU bring-up and hotplug
for the R40.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/cpu/armv7/sunxi/psci.c | 35 ---
 board/sunxi/Kconfig |  3 +++
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 104dc909bc53..b3a34de1aafe 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -27,6 +27,17 @@
 #defineGICD_BASE   (SUNXI_GIC400_BASE + GIC_DIST_OFFSET)
 #defineGICC_BASE   (SUNXI_GIC400_BASE + GIC_CPU_OFFSET_A15)
 
+/*
+ * R40 is different from other single cluster SoCs.
+ *
+ * The power clamps are located in the unused space after the per-core
+ * reset controls for core 3. The secondary core entry address register
+ * is in the SRAM controller address range.
+ */
+#define SUN8I_R40_PWROFF   (0x110)
+#define SUN8I_R40_PWR_CLAMP(cpu)   (0x120 + (cpu) * 0x4)
+#define SUN8I_R40_SRAMC_SOFT_ENTRY_REG0(0xbc)
+
 static void __secure cp15_write_cntp_tval(u32 tval)
 {
asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
@@ -68,7 +79,8 @@ static void __secure __mdelay(u32 ms)
 static void __secure clamp_release(u32 __maybe_unused *clamp)
 {
 #if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
-   defined(CONFIG_MACH_SUN8I_H3)
+   defined(CONFIG_MACH_SUN8I_H3) || \
+   defined(CONFIG_MACH_SUN8I_R40)
u32 tmp = 0x1ff;
do {
tmp >>= 1;
@@ -82,7 +94,8 @@ static void __secure clamp_release(u32 __maybe_unused *clamp)
 static void __secure clamp_set(u32 __maybe_unused *clamp)
 {
 #if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
-   defined(CONFIG_MACH_SUN8I_H3)
+   defined(CONFIG_MACH_SUN8I_H3) || \
+   defined(CONFIG_MACH_SUN8I_R40)
writel(0xff, clamp);
 #endif
 }
@@ -115,7 +128,17 @@ static void __secure sunxi_cpu_set_power(int 
__always_unused cpu, bool on)
sunxi_power_switch(>cpu1_pwr_clamp, >cpu1_pwroff,
   on, 0);
 }
-#else /* ! CONFIG_MACH_SUN7I */
+#elif defined CONFIG_MACH_SUN8I_R40
+static void __secure sunxi_cpu_set_power(int cpu, bool on)
+{
+   struct sunxi_cpucfg_reg *cpucfg =
+   (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+   sunxi_power_switch((void *)cpucfg + SUN8I_R40_PWR_CLAMP(cpu),
+  (void *)cpucfg + SUN8I_R40_PWROFF,
+  on, 0);
+}
+#else /* ! CONFIG_MACH_SUN7I && ! CONFIG_MACH_SUN8I_R40 */
 static void __secure sunxi_cpu_set_power(int cpu, bool on)
 {
struct sunxi_prcm_reg *prcm =
@@ -213,7 +236,13 @@ int __secure psci_cpu_on(u32 __always_unused unused, u32 
mpidr, u32 pc)
psci_save_target_pc(cpu, pc);
 
/* Set secondary core power on PC */
+#ifdef CONFIG_MACH_SUN8I_R40
+   /* secondary core entry address is programmed differently */
+   writel((u32)_cpu_entry,
+  SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
+#else
writel((u32)_cpu_entry, >priv0);
+#endif
 
/* Assert reset on target CPU */
writel(0, >cpu[cpu].rst);
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 3df9f8197c57..1967625f7c4f 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -135,6 +135,9 @@ config MACH_SUN8I_H3
 config MACH_SUN8I_R40
bool "sun8i (Allwinner R40)"
select CPU_V7
+   select CPU_V7_HAS_NONSEC
+   select CPU_V7_HAS_VIRT
+   select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
 
-- 
2.11.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 07/12] gpio: sunxi: Add compatible string for R40 PIO

[Chen-Yu Tsai]

The PIO on the R40 SoC is mostly compatible with the A20.
Only a few pin functions for mmc2 were added to the PC
pingroup, to support 8 bit eMMCs.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpio/sunxi_gpio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 8d2bb18504ae..3f40e8383001 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -352,6 +352,7 @@ static const struct udevice_id sunxi_gpio_ids[] = {
ID("allwinner,sun8i-a33-pinctrl",   a_all),
ID("allwinner,sun8i-a83t-pinctrl",  a_all),
ID("allwinner,sun8i-h3-pinctrl",a_all),
+   ID("allwinner,sun8i-r40-pinctrl",   a_all),
ID("allwinner,sun9i-a80-pinctrl",   a_all),
ID("allwinner,sun6i-a31-r-pinctrl", l_2),
ID("allwinner,sun8i-a23-r-pinctrl", l_1),
-- 
2.11.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 08/12] sunxi: Use H3/A64 DRAM initialization code for R40

[Chen-Yu Tsai]

The R40 seems to have a variant of the memory controller found in
the H3 and A64 SoCs. Adapt the code for use on the R40. The changes
are based on released DRAM code and comparing register dumps from
boot0.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/cpu.h   |   1 +
 arch/arm/include/asm/arch-sunxi/dram.h  |   4 +-
 arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h |  20 +++-
 arch/arm/mach-sunxi/Makefile|   1 +
 arch/arm/mach-sunxi/clock_sun6i.c   |   4 +-
 arch/arm/mach-sunxi/dram_sun8i_h3.c | 121 +---
 6 files changed, 133 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h 
b/arch/arm/include/asm/arch-sunxi/cpu.h
index e8e670e7e903..caec86526417 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -16,5 +16,6 @@
 #define SOCID_A64  0x1689
 #define SOCID_H3   0x1680
 #define SOCID_H5   0x1718
+#define SOCID_R40  0x1701
 
 #endif /* _SUNXI_CPU_H */
diff --git a/arch/arm/include/asm/arch-sunxi/dram.h 
b/arch/arm/include/asm/arch-sunxi/dram.h
index 1dc82205b7df..f452f889f928 100644
--- a/arch/arm/include/asm/arch-sunxi/dram.h
+++ b/arch/arm/include/asm/arch-sunxi/dram.h
@@ -24,7 +24,9 @@
 #include 
 #elif defined(CONFIG_MACH_SUN8I_A83T)
 #include 
-#elif defined(CONFIG_MACH_SUNXI_H3_H5) || defined(CONFIG_MACH_SUN50I)
+#elif defined(CONFIG_MACH_SUNXI_H3_H5) || \
+  defined(CONFIG_MACH_SUN8I_R40) || \
+  defined(CONFIG_MACH_SUN50I)
 #include 
 #elif defined(CONFIG_MACH_SUN9I)
 #include 
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h 
b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
index 25d07d9863c9..2770986b613f 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
@@ -15,7 +15,8 @@
 
 struct sunxi_mctl_com_reg {
u32 cr; /* 0x00 control register */
-   u8 res0[0x8];   /* 0x04 */
+   u32 cr_r1;  /* 0x04 rank 1 control register (R40 only) */
+   u8 res0[0x4];   /* 0x08 */
u32 tmr;/* 0x0c (unused on H3) */
u32 mcr[16][2]; /* 0x10 */
u32 bwcr;   /* 0x90 bandwidth control register */
@@ -63,6 +64,17 @@ struct sunxi_mctl_com_reg {
 #define MCTL_CR_DUAL_RANK  (0x1 << 0)
 #define MCTL_CR_SINGLE_RANK(0x0 << 0)
 
+/*
+ * CR_R1 is a register found in the R40's DRAM controller. It sets various
+ * parameters for rank 1. Bits [11:0] have the same meaning as the bits in
+ * MCTL_CR, but they apply to rank 1 only. This implies we can have
+ * different chips for rank 1 than rank 0.
+ *
+ * As address line A15 and CS1 chip select for rank 1 are muxed on the same
+ * pin, if single rank is used, A15 must be muxed in.
+ */
+#define MCTL_CR_R1_MUX_A15 (0x1 << 21)
+
 #define PROTECT_MAGIC  (0x94be6fa3)
 
 struct sunxi_mctl_ctl_reg {
@@ -72,7 +84,8 @@ struct sunxi_mctl_ctl_reg {
u32 clken;  /* 0x0c */
u32 pgsr[2];/* 0x10 PHY general status registers */
u32 statr;  /* 0x18 */
-   u8 res1[0x14];  /* 0x1c */
+   u8 res1[0x10];  /* 0x1c */
+   u32 lp3mr11;/* 0x2c */
u32 mr[4];  /* 0x30 mode registers */
u32 pllgcr; /* 0x40 */
u32 ptr[5]; /* 0x44 PHY timing registers */
@@ -120,7 +133,8 @@ struct sunxi_mctl_ctl_reg {
struct {/* 0x300 DATX8 modules*/
u32 mdlr;   /* 0x00 master delay line register */
u32 lcdlr[3];   /* 0x04 local calibrated delay line 
registers */
-   u32 bdlr[12];   /* 0x10 bit delay line registers */
+   u32 bdlr[11];   /* 0x10 bit delay line registers */
+   u32 sdlr;   /* 0x3c output enable bit delay 
registers */
u32 gtr;/* 0x40 general timing register */
u32 gcr;/* 0x44 general configuration register 
*/
u32 gsr[3]; /* 0x48 general status registers */
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index efab4811ee54..5510aa54353f 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_MACH_SUN8I_A23)  += dram_sun8i_a23.o
 obj-$(CONFIG_MACH_SUN8I_A33)   += dram_sun8i_a33.o
 obj-$(CONFIG_MACH_SUN8I_A83T)  += dram_sun8i_a83t.o
 obj-$(CONFIG_MACH_SUNXI_H3_H5) += dram_sun8i_h3.o
+obj-$(CONFIG_MACH_SUN8I_R40)   += dram_sun8i_h3.o
 obj-$(CONFIG_MACH_SUN9I)   += dram_sun9i.o
 obj-$(CONFIG_MACH_SUN50I)  += dram_sun8i_h3.o
 endif
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index 3c8c53fcf76b..9068c88ab2f8 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ 

[linux-sunxi] [PATCH 01/12] sunxi: Add initial support for R40

[Chen-Yu Tsai]

The R40 is the successor to the A20. It is a hybrid of the A20, A33
and the H3.

The R40's PIO controller is compatible with the A20,
Reuse the A20 UART and I2C muxing code by adding the R40's macro.

The display pipeline is the newer DE 2.0 variant.
Block enabling video on R40 for now.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-sunxi/board.c| 10 +++---
 arch/arm/mach-sunxi/cpu_info.c |  2 ++
 board/sunxi/Kconfig|  9 +++--
 board/sunxi/board.c| 19 ++-
 4 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 5e03d039433a..5a74c9717d84 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -69,12 +69,14 @@ struct mm_region *mem_map = sunxi_mem_map;
 static int gpio_init(void)
 {
 #if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
/* disable GPB22,23 as uart0 tx,rx to avoid conflict */
sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUNXI_GPIO_INPUT);
sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT);
 #endif
-#if defined(CONFIG_MACH_SUN8I)
+#if defined(CONFIG_MACH_SUN8I) && !defined(CONFIG_MACH_SUN8I_R40)
sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
 #else
@@ -82,7 +84,9 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0);
 #endif
sunxi_gpio_set_pull(SUNXI_GPF(4), 1);
-#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || 
defined(CONFIG_MACH_SUN7I))
+#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40))
sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(23), SUNXI_GPIO_PULL_UP);
diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index 85633ccec216..7851de299ab5 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -87,6 +87,8 @@ int print_cpuinfo(void)
printf("CPU:   Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
 #elif defined CONFIG_MACH_SUN8I_H3
printf("CPU:   Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
+#elif defined CONFIG_MACH_SUN8I_R40
+   printf("CPU:   Allwinner R40 (SUN8I %04x)\n", sunxi_get_sram_id());
 #elif defined CONFIG_MACH_SUN9I
puts("CPU:   Allwinner A80 (SUN9I)\n");
 #elif defined CONFIG_MACH_SUN50I
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 3e0e2624737e..8e8b9cd0d5fd 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -132,6 +132,11 @@ config MACH_SUN8I_H3
select MACH_SUNXI_H3_H5
select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
 
+config MACH_SUN8I_R40
+   bool "sun8i (Allwinner R40)"
+   select CPU_V7
+   select SUNXI_GEN_SUN6I
+
 config MACH_SUN9I
bool "sun9i (Allwinner A80)"
select CPU_V7
@@ -157,7 +162,7 @@ endchoice
 # The sun8i SoCs share a lot, this helps to avoid a lot of "if A23 || A33"
 config MACH_SUN8I
bool
-   default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUNXI_H3_H5 || 
MACH_SUN8I_A83T
+   default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUNXI_H3_H5 || 
MACH_SUN8I_A83T || MACH_SUN8I_R40
 
 config RESERVE_ALLWINNER_BOOT0_HEADER
bool "reserve space for Allwinner boot0 header"
@@ -510,7 +515,7 @@ config AXP_GPIO
 
 config VIDEO
bool "Enable graphical uboot console on HDMI, LCD or VGA"
-   depends on !MACH_SUN8I_A83T && !MACH_SUNXI_H3_H5 && !MACH_SUN9I && 
!MACH_SUN50I
+   depends on !MACH_SUN8I_A83T && !MACH_SUNXI_H3_H5 && !MACH_SUN8I_R40 && 
!MACH_SUN9I && !MACH_SUN50I
default y
---help---
Say Y here to add support for using a cfb console on the HDMI, LCD
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index b9660128e5e7..495cb591a9fb 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -394,7 +394,10 @@ int board_mmc_init(bd_t *bis)
 void i2c_init_board(void)
 {
 #ifdef CONFIG_I2C0_ENABLE
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I) || 
defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN5I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN4I_GPB_TWI0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN4I_GPB_TWI0);
clock_twi_onoff(0, 1);
@@ -410,7 +413,9 @@ void i2c_init_board(void)
 #endif
 
 #ifdef CONFIG_I2C1_ENABLE
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || \
+

[linux-sunxi] [PATCH 09/12] sunxi: Enable SPL for R40

[Chen-Yu Tsai]

Now that we can do DRAM initialization for the R40, we can enable
SPL support for it.

Signed-off-by: Chen-Yu Tsai 
---
 board/sunxi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 9854ef0a599e..3df9f8197c57 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -136,6 +136,7 @@ config MACH_SUN8I_R40
bool "sun8i (Allwinner R40)"
select CPU_V7
select SUNXI_GEN_SUN6I
+   select SUPPORT_SPL
 
 config MACH_SUN9I
bool "sun9i (Allwinner A80)"
-- 
2.11.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 12/12] sunxi: Add support for Bananapi M2 Ultra

[Chen-Yu Tsai]

The Bananapi M2 Ultra is the first publicly available development board
featuring the R40 SoC.

This patch add barebone dtsi/dts files for the R40 and Bananapi M2 Ultra,
as well as a defconfig for it.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/Makefile|   2 +
 arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts |  69 ++
 arch/arm/dts/sun8i-r40.dtsi  | 183 +++
 board/sunxi/MAINTAINERS  |   6 +
 configs/Bananapi_M2_Ultra_defconfig  |  15 +++
 5 files changed, 275 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
 create mode 100644 arch/arm/dts/sun8i-r40.dtsi
 create mode 100644 configs/Bananapi_M2_Ultra_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eeaa9e028457..683cbdca6238 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -295,6 +295,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-orangepi-plus2e.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-nanopi-neo-air.dtb
+dtb-$(CONFIG_MACH_SUN8I_R40) += \
+   sun8i-r40-bananapi-m2-ultra.dtb
 dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-pc2.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
diff --git a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts 
b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
new file mode 100644
index ..ab471ab0bffb
--- /dev/null
+++ b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2016 Chen-Yu Tsai 
+ *
+ * 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 "sun8i-r40.dtsi"
+
+/ {
+   model = "Banana Pi BPI-M2-Ultra";
+   compatible = "sinovoip,bpi-m2-ultra", "allwinner,sun8i-r40";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pb_pins>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/sun8i-r40.dtsi b/arch/arm/dts/sun8i-r40.dtsi
new file mode 100644
index ..48ec2e855a2c
--- /dev/null
+++ b/arch/arm/dts/sun8i-r40.dtsi
@@ -0,0 +1,183 @@
+/*
+ * Copyright 2016 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai 
+ *
+ * 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 

[linux-sunxi] [PATCH 06/12] sunxi: Provide defaults for R40 DRAM settings

[Chen-Yu Tsai]

These values were taken from the Banana Pi M2 Ultra fex file
found in the released vendor BSP. This is the only publicly
available R40 device at the time of this writing.

Signed-off-by: Chen-Yu Tsai 
---
 board/sunxi/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e89ddf626289..9854ef0a599e 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -197,6 +197,7 @@ config DRAM_TYPE
 config DRAM_CLK
int "sunxi dram clock speed"
default 792 if MACH_SUN9I
+   default 648 if MACH_SUN8I_R40
default 312 if MACH_SUN6I || MACH_SUN8I
default 360 if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
default 672 if MACH_SUN50I
@@ -218,6 +219,7 @@ config DRAM_ZQ
int "sunxi dram zq value"
default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I
default 127 if MACH_SUN7I
+   default 3881979 if MACH_SUN8I_R40
default 4145117 if MACH_SUN9I
default 3881915 if MACH_SUN50I
---help---
@@ -227,6 +229,7 @@ config DRAM_ODT_EN
bool "sunxi dram odt enable"
default n if !MACH_SUN8I_A23
default y if MACH_SUN8I_A23
+   default y if MACH_SUN8I_R40
default y if MACH_SUN50I
---help---
Select this to enable dram odt (on die termination).
-- 
2.11.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.

Re: [linux-sunxi] Re: [U-Boot] [PATCH v2] sunxi: add NanoPi NEO Air defconfig

[Chen-Yu Tsai]

On Sat, Feb 25, 2017 at 4:26 PM, Jagan Teki  wrote:
> On Mon, Feb 13, 2017 at 1:22 PM, Maxime Ripard
>  wrote:
>> On Sun, Feb 12, 2017 at 04:21:40PM +0100, Jelle van der Waa wrote:
>>> Add support for the NanoPi NEO Air H3 board from friendlyarm.com . This
>>> board contains WiFi, Bluetooth, 8GB eMMC storage and 512 MB DDR3 ram.
>>>
>>> Signed-off-by: Jelle van der Waa 
>>
>> Acked-by: Maxime Ripard 
>
> Fixed, error while 'git am' and
>
> Applied to u-boot-sunxi/master

This is missing an entry to boards/sunxi/MAINTAINERS though.

Jelle, can you send another patch adding yourself as a board maintainer?

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] [PATCH 0/3] Add support for the R_CCU on Allwinner H3/A64 SoCs

[Icenowy Zheng]

Allwinner SoCs after sun6i-a31 nearly all have a R_CCU in PRCM part.
(V3s and R40 do not have it, as they have even no PRCM)

This patch adds support for the ones on H3/A64.

Some clock/reset values are reserved for easier extending the support to
A31/A23, but for this I think some changes to the PRCM MFD should be made,
see [1] (Although this is only a sketch).

[1] https://github.com/wens/linux/commits/sunxi-ng-prcm

Icenowy Zheng (3):
  dt-bindings: update device tree binding for Allwinner PRCM CCUs
  clk: sunxi-ng: add support for PRCM CCUs
  arm64: dts: allwinner: add r_ccu node

 .../devicetree/bindings/clock/sunxi-ccu.txt|   2 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  |  11 ++
 drivers/clk/sunxi-ng/Kconfig   |   6 +
 drivers/clk/sunxi-ng/Makefile  |   1 +
 drivers/clk/sunxi-ng/ccu-sun6i-r.c | 209 +
 drivers/clk/sunxi-ng/ccu-sun6i-r.h |  27 +++
 include/dt-bindings/clock/sun6i-r-ccu.h|  58 ++
 include/dt-bindings/reset/sun6i-r-ccu.h|  54 ++
 8 files changed, 368 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun6i-r.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun6i-r.h
 create mode 100644 include/dt-bindings/clock/sun6i-r-ccu.h
 create mode 100644 include/dt-bindings/reset/sun6i-r-ccu.h

-- 
2.11.1

-- 
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 1/3] dt-bindings: update device tree binding for Allwinner PRCM CCUs

[Icenowy Zheng]

Many Allwinner SoCs after A31 have a CCU in PRCM block.

Give the ones on H3 and A64 compatible strings.

Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt 
b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
index bae5668cf427..c774d55740f5 100644
--- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
@@ -7,9 +7,11 @@ Required properties :
- "allwinner,sun8i-a23-ccu"
- "allwinner,sun8i-a33-ccu"
- "allwinner,sun8i-h3-ccu"
+   - "allwinner,sun8i-h3-r-ccu"
- "allwinner,sun8i-v3s-ccu"
- "allwinner,sun9i-a80-ccu"
- "allwinner,sun50i-a64-ccu"
+   - "allwinner,sun50i-a64-r-ccu"
 
 - reg: Must contain the registers base address and length
 - clocks: phandle to the oscillators feeding the CCU. Two are needed:
-- 
2.11.1

-- 
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] sunxi: Add boards/sunxi and arch/arm/mach-sunxi to sunxi MAINTAINERS entry

[Chen-Yu Tsai]

Recently some sunxi related code was moved to arch/arm/mach-sunxi, but
the MAINTAINERS entry was not updated to reflect this. Add this, and
the board level boards/sunxi directory to our entry.

While at it, also update its status, to reflect the current active
maintainership.

Signed-off-by: Chen-Yu Tsai 
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index eaa2c3bbb860..4eee53f5a9f6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -168,9 +168,12 @@ F: arch/arm/include/asm/arch-stv0991/
 ARM SUNXI
 M: Jagan Teki 
 M: Maxime Ripard 
+S: Maintained
 T: git git://git.denx.de/u-boot-sunxi.git
 F: arch/arm/cpu/armv7/sunxi/
 F: arch/arm/include/asm/arch-sunxi/
+F: arch/arm/mach-sunxi/
+F: board/sunxi/
 
 ARM TEGRA
 M: Tom Warren 
-- 
2.11.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.

Re: [linux-sunxi] [PATCH 11/17] sunxi: SPL: add FIT config selector for Pine64 boards

[Icenowy Zheng]

01.03.2017, 10:26, "Andre Przywara" :
> For a board or platform to support FIT loading in the SPL, it has to
> provide a board_fit_config_name_match() routine, which helps to select
> one of possibly multiple DTBs contained in a FIT image.
> Provide a simple function which chooses the DT name U-Boot was
> configured with.
> If the DT name is one of the two Pine64 versions, determine the exact
> model by checking the DRAM size.
>

I think we shouldn't have is specially for Pine64 here, but make a framework
for other boards that can be easily checked.

Then make Pine64 series the first user of this framework.

> Signed-off-by: Andre Przywara 
> ---
>  board/sunxi/board.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index a510422..2ddff28 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -725,3 +725,26 @@ int ft_board_setup(void *blob, bd_t *bd)
>  #endif
>  return 0;
>  }
> +
> +#ifdef CONFIG_SPL_LOAD_FIT
> +int board_fit_config_name_match(const char *name)
> +{
> + const char *cmp_str;
> +
> +#ifdef CONFIG_DEFAULT_DEVICE_TREE
> + cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
> +#else
> + return 0;
> +#endif
> +
> +/* Differentiate the two Pine64 board DTs by their DRAM size. */
> + if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
> + if ((gd->ram_size > 512 * 1024 * 1024))
> + return !strstr(name, "plus");
> + else
> + return !!strstr(name, "plus");
> + } else {
> + return strcmp(name, cmp_str);
> + }
> +}
> +#endif
> --
> 2.8.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [linux-sunxi] [PATCH 1/5] pinctrl: sunxi: refactor pinctrl choice selecting for ARM64

[Chen-Yu Tsai]

On Wed, Mar 1, 2017 at 2:55 AM, Icenowy Zheng  wrote:
>
>
> 01.03.2017, 02:15, "Andre Przywara" :
>> Hi Icenowy,
>>
>> (first thing: could you create your series with --cover-letter and fill
>> this in? There you could explain what this series is about and also
>> state things like dependencies from other patches and the commit that
>> you based that on.)
>>
>> On 28/02/17 17:24, Icenowy Zheng wrote:
>>>  ARM64 Allwinner SoCs used to have every pinctrl driver selected in
>>>  ARCH_SUNXI. Change this to make their default value to (ARM64 &&
>>>  ARCH_SUNXI).
>>>
>>>  Signed-off-by: Icenowy Zheng 
>>
>> Overall this is a nice solution. Thanks for posting this.
>>
>>>  ---
>>>   drivers/pinctrl/sunxi/Kconfig | 9 +
>>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>>  diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
>>>  index 816015cf7053..92325736d953 100644
>>>  --- a/drivers/pinctrl/sunxi/Kconfig
>>>  +++ b/drivers/pinctrl/sunxi/Kconfig
>>>  @@ -48,8 +48,9 @@ config PINCTRL_SUN8I_H3
>>>   select PINCTRL_SUNXI
>>>
>>>   config PINCTRL_SUN8I_H3_R
>>>  - def_bool MACH_SUN8I
>>>  - select PINCTRL_SUNXI_COMMON
>>>  + def_bool MACH_SUN8I || (ARM64 && ARCH_SUNXI)
>>>  + depends on RESET_CONTROLLER
>>
>> So this looks a bit odd. I take it this is for the extra reset register
>> in the PRCM block.
>> 1) I don't think this belongs into this patch. If this has been
>> forgotten in the past, please make an extra patch for this. It's cheap
>> to do so ;-)
>> 2) Is this really a "depends on"? Shouldn't this be a select? With
>> sunxi_ng clocks we don't need the reset controller for the normal
>> peripherals anymore, so this option might not be selected by default in
>> the future. And having this "depends on" leads to the PINCTRL_ option
>> being hidden if RESET_CONTROLLER isn't selected.
>> I think this bites us already in arm64, where ARCH_HAS_RESET_CONTROLLER
>> is not enabled for ARCH_SUNXI.
>
> PINCTRL_ options are always hidden now, Maxime, do you
> want to change that?
>
> We should enable ARCH_HAS_RESET_CONTROLLER for
> ARCH_SUNXI, as sunxi-ng ccu is a reset controller.

Agreed.

> Without RESET_CONTROLLER enabled, errors will occur
> when linking:
> ```
> drivers/built-in.o: In function `sunxi_ccu_probe':
> of_reserved_mem.c:(.text+0x16058): undefined reference to 
> `reset_controller_register'
> ```
>
> If you don't care, I will make it an additional patch.
>
> And there's really a reset line for the R_PIO pinctrls.

Depends on is the right thing here, since this driver depends
on the reset controller subsystem to be present for any
devm_reset_control_get calls. Now if this pinctrl has a reset
line, but is missing that call, it needs to be fixed.

It seems only A23 and A31 R_PIO drivers have them.

Regards
ChenYu

>
> But you're right, this line shouldn't occur in this patch.
> I will make a more patch for it.
>
>>
>> But as the rest of the patch is fine, if you remove this line:
>> Reviewed-by: Andre Przywara 
>>
>> Cheers,
>> Andre.
>>
>>>  + select PINCTRL_SUNXI
>>>
>>>   config PINCTRL_SUN8I_V3S
>>>   def_bool MACH_SUN8I
>>>  @@ -65,11 +66,11 @@ config PINCTRL_SUN9I_A80_R
>>>   select PINCTRL_SUNXI
>>>
>>>   config PINCTRL_SUN50I_A64
>>>  - bool
>>>  + def_bool ARM64 && ARCH_SUNXI
>>>   select PINCTRL_SUNXI
>>>
>>>   config PINCTRL_SUN50I_H5
>>>  - bool
>>>  + def_bool ARM64 && ARCH_SUNXI
>>>   select PINCTRL_SUNXI
>>>
>>>   endif

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