Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

[Andre Przywara]

On Thu, 18 Apr 2024 22:40:59 -0700 (PDT)
"'andrew g' via linux-sunxi"  wrote:

Hi Andrew,

> background: 
> 
> currently Armbian linux use the 'mainline u-boot' 
> https://source.denx.de/u-boot/u-boot

Thanks for using mainline!

> however, it has a '1.5GB' problem in that boards with 1.5GB DRAM is 
> detected incorrectly.
> It detects 2GB instead possibly due to address wraparound, so the boot 
> crashes mid stream.
> I'm trying to build a custom u-boot for a 'hack' i.e. to return 1.5GB dram 
> from the memory initialization and setup functions. in part to explore 
> solutions

So yes, as you figured, the 1.5GB setup is not supported yet, mostly
because no one with a board fixed that and sent a proper patch.

There is this patch here - but please note that this is hack:
https://lore.kernel.org/u-boot/20240413134352.46495-1-da...@189.cn/T/#u

However in his reply Jernej gives some hints on what to do for a proper
solution.

So you might want to try this. Bonus points for trying to follow Jernej's
hints and implementing that!

Cheers,
Andre

P.S. Your build sequence below looks correct, and nice work on digging into
the sequence. I sketched the U-Boot early code flow here:
https://linux-sunxi.org/U-Boot/Boot_process

> 
> what I tried and issues:
> I'm building u-boot from
> https://source.denx.de/u-boot/u-boot
> basically following these instructions
> https://docs.u-boot.org/en/latest/board/allwinner/sunxi.html
> 
> my shell script ot build u-boot is like
> #!/usr/bin/bash 
> export BL31=../arm-trusted-firmware/build/sun50i_h616/release/bl31.bin 
> make orangepi_zero3_defconfig 
> CROSS_COMPILE=aarch64-linux-gnu- make
> 
> where the bl31 module from arm-trusted-firmware is in its own directory 
> build with
> make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h616
> 
> I did succeed with building u-boot and flashed the u-boot SPL into the sd 
> card
> sudo dd if=u-boot-sunxi-with-spl.bin of=/de
> v/sde bs=1024 seek=8
> 
> and it actually boots, but :
> U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 12:46:06 +0800)
> DRAM: 0 MiB
> Trying to boot from MMC1
> NOTICE:  BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c
> NOTICE:  BL31: Built : 23:11:18, Apr 18 2024
> NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
> NOTICE:  BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3
> ERROR:   RSB: set run-time address: 0x10003
> U-Boot 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 12:46:06 +0800) 
> Allwinner Technology
> 
> size=30, ptr=590, limit=2000: 26370
> CPU:   Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM:  0 Bytes
> 
> So apparently the DRAM is not detected. I tried tracing flow execution by 
> placing 
> debug("tag"); or log_info("tag") in 
> board_init_f()
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/board.c?ref_type=heads#L457
> and
> sunxi_dram_init()
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1377
> 
> however, none of my tags are printed, which implies that the initialization 
> routines for both the board and sunxi_dram_init() are not called.
> 
> I did configure logging to be pretty verbose in .config
> # 
> # Logging 
> # 
> CONFIG_LOG=y 
> CONFIG_LOG_MAX_LEVEL=8 
> CONFIG_LOG_DEFAULT_LEVEL=8 
> CONFIG_LOG_CONSOLE=y
> 
> I'm not sure what else could be wrong or how to go about it further.
> 
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20240422151530.3f26073f%40donnerap.manchester.arm.com.

Re: [linux-sunxi] H618 USB "Performance" Issues by using g_audio module

[Andre Przywara]

On Mon, 12 Feb 2024 05:41:29 -0800 (PST)
"'Ricardo M.' via linux-sunxi"  wrote:

Hi,

> Hello folks,
> 
> I have an OrangePi Zero 2*W *actually running with Armbian 6.7.4 Kernel.
> When I setup g_audio module I can´t achieve settings higher than  84578 hz 
> samplerate with S24_3LE (3Byte) and no more than  127360 Hz with S16. Both 
> is nearly or exactly 512 Byte packet size tho. 

How many channels is that? And what rate do you expect? Did you get
that rate on any other Allwinner SoC? Or a SoC from another vendor,
like Rockchip?

The OTG performance under Linux on Allwinner SoCs is rather poor, since
we don't have DMA support, so the CPU has to do all the byte pushing,
which severely limits the performance.
Apparently the BSP does not use DMA either, so it's unclear whether
this is broken or not. No one has ever tried to implement it, although
many people are interested.
With just a simple UMS test in U-Boot, I could read with about 900 KB/s,
and this is probably the lower limit, since U-Boot is horribly
inefficient in this respect (and that SD card is slow as well).
So it does not look like a hardware limit, unless you have four
channels? Your rate above suggests you hit 256 KB/s per channel.

> Tuning and optimising packet sizes and intervalls did not helped. I think 
> it is an issue with the USB implementation in the device tree. Althought 2W 
> is a H618 in the dtb/dts is still H616 modules used (I decompilied dtb) and 
> I already using Zero 3 (H618) device tree.

This has nothing to do with the DT, and the H616 and H618 are basically
the same chip, with some very minor implementation differences, and
with the H618 having 1MB of L2 cache instead of just 512KB.
And please don't just use a DTB from another board, this is dangerous,
and also not necessary, since the OPi Zero2W DT is already in mainline.

> Errors when setup g_audio comes from UDC musb-hdrc.4.auto and it states 
> "couldn´t find an available UDC"

That message is a pr_info, so that shouldn't be a problem. 

> or "[ 7020.314150] g_audio gadget.0: FS 
> Capture: Req. wMaxPacketSize 1158 at bInterval 1 > max ISOC 1023, may drop 
> data!"

I really have no clue, but 1023 is the packet size limit for Full
Speed, so are you running with USB 1.1 speeds?
 
> Maybe someone can help!
> *Maybe @Andre Przywara can help!*

Why not use CC: in an email? Surely "@" doesn't work as you'd expect ;-)

Cheers,
Andre

> 
> BR Ricardo
> 
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20240219234911.77a81b00%40minigeek.lan.

Re: [linux-sunxi] T113-S3/D1S : Mainline MIPI-DSI Driver "sun6i-mipi-dsi 5450000.dsi: Couldn't get the DSI mod clock"

[Andre Przywara]

On Tue, 26 Dec 2023 19:00:58 -0800 (PST)
"K. James"  wrote:

Hi,

please try to avoid HTML email on lists, that makes it hard to reply
inline and messes up the text view - and there is little need to provide
links to every identifier anyway.

> Hi All,
> 
> Been working on getting T113-s3 on mainline as I prepare to update a 
> project from a v3s. One of the benefits has been the ability to move from a 
> 18bit RGB LCD to a MIPI-DSI display, with the interface available on the 
> T113-s3 , which has given some better display choices.
> 
> The DSI driver was on mainline from 6.2, however building from sources on 
> init I am getting the following error:
> 
> *"sun6i-mipi-dsi 545.dsi: Couldn't get the DSI mod clock"*
> 
> Its tripping at the following init in sun6i_mipi_dsi.c 
> 
> 
> 
> if (variant-> has_mod_clk) { 
>   dsi->mod_clk = devm_clk_get(dev, "mod"); 
>   if (IS_ERR (dsi->mod_clk)) {
>   dev_err(dev, "Couldn't get the DSI mod clock\n");
>   ret = PTR_ERR(dsi->mod_clk);
>   goto err_attach_clk;
>}

But since this comes from the DSI driver, this refers to the DT node of
the DSI device, not the DE2 clock, doesn't it?

> The display modclock is registered from the following DTS node in 
> sunxi-d1s-t113.dtsi 
> 
> 
> 
> display_clocks: clock-controller@500 {
>   compatible = "allwinner,sun20i-d1-de2-clk",
>"allwinner,sun50i-h5-de2-clk";
>   reg = <0x500 0x1>;
>   clocks = < CLK_BUS_DE>, < CLK_DE>;
>   clock-names = "bus", *"mod"*;
>   resets = < RST_BUS_DE>;
>   #clock-cells = <1>;
>   #reset-cells = <1>;
> };

So those are the clocks from:
dsi: dsi@545 {
...
clocks = < CLK_BUS_MIPI_DSI>,
 <_top CLK_TCON_TOP_DSI>;
clock-names = "bus", "mod";
...
};

So the "mod" clock here points to the tcon_top device, the one with the
"allwinner,sun20i-d1-tcon-top" compatible string. Which is implemented
by drivers/gpu/drm/sun4i/sun8i_tcon_top.c, controlled by the
DRM_SUN8I_TCON_TOP Kconfig symbol. Do you have that enabled?

You can check /sys/kernel/debug/clk/clk_summary (with debugfs mounted)
to see what clocks are there and how they are used.

Cheers,
Andre

> I checked the buildroot config and the CCU for sun8i DE2 is being
> built and included, the registration should occur and give an
> exception if it's not happening: ccu-sun8i-de2.c 
> 
> 
> mod_clk  = 
> devm_clk_get
> (
> >dev, "mod"); if (IS_ERR
> (mod_clk
> )) return
> dev_err_probe
> (>dev,
> PTR_ERR
> (mod_clk
> ), "Couldn't
> get mod clk\n");
> 
> ret = clk_prepare_enable 
> (mod_clk 
> ); if (ret)
> { dev_err
> (>dev
> , "Couldn't enable mod clk: %d\n", ret); goto err_disable_bus_clk; }
> 
> I don't see dmesg print any clock errors, but at the same time, I 
> understand that linux common clock framework also won't print
> anything by default.
> 
> I can't see anything in either driver that would cause an error other
> than the clock not existing, if anyone has any ideas - i'm all ears. 
> 
> At the moment I am leaning towards the clock-controller; Is there a 
> userspace or debug option to check (mod) clock status' under the
> common clock framework?
> 
> Thanks
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20231227232842.5c1c9ed8%40minigeek.lan.

Re: [linux-sunxi] Allwinner A40i USB-OTG host GPIO pin ID interrupt doesn't run handler

[Andre Przywara]

On Thu, 21 Dec 2023 11:24:57 +0400
Сергей Мосолов  wrote:

(adding the proper sunxi mailing list for a wider audience)

Hi Sergej,

> I kindly ask for an advice about interrupt working with USB-OTG usb0 on
> Allwinner A40i.
> I need to make work usb0 as USB-OTG.
> 
> Looks like it's possible somehow:
> https://lore.kernel.org/linux-arm-kernel/daf5c543-a1d1-04d2-6486-6cc9cd72d...@sholland.org/T/#md5e9ce01feb201041467c136f09e80628f414557
> 
> I've used usb-phy driver with support of muxing ohci0(host) and
> usb0(client) on usb0 pins, mentioned in the link above:
> https://github.com/wirenboard/linux/blob/dev/v5.10.y/drivers/phy/allwinner/phy-sun4i-usb.c

some good checking and detective work!

I am afraid the problem is somewhere deeper, though, in the way our sunxi
PHY interacts with the OTG framework. I actually believe it's broken
for every Allwinner system at the moment. Some months ago I spent some
time in the code, and it looks like there is some race between the
OHCI/EHCI controllers and the MUSB controller for the PHY. Both the MUSB
and the HCI drivers claim the PHY and set their preferred mode (OTG and
host, respectively), but if I remember correctly, the HCI driver always
wins, regardless of the order. I can't remember exactly, but I think the
problem was in sun4i_usb_phy_set_mode. You can try to insert debug
messages there to see what's going on.
The short summary at the moment seems to be: forcing the mode (peripheral
or host) works, but the dynamic switching does not.

You might want to try disabling the ehci0/ohci0 nodes, as a quick check, to
see if that improves thing. I haven't tried that, though, as doing so is
not correct and breaks U-Boot.
Also keep an eye on the interrupt counter in /proc/interrupts, you should
see some non-zero number if you connect and disconnect the cable a few
times. But if the PHY is in host mode, then it won't activate the IRQ, I
believe.

Пока,
Andre

> In my case I have pin ID USB OTG = PI11.
> 
> Some excerpts from my dts file:
> [quote]
> / {
> ...
>/* ohci0 and ehci0 need to be included to work with USB OTG */
>ohci0: usb@1c14400 {
>   compatible = "allwinner,sun8i-r40-ohci", "generic-ohci";
>   reg = <0x01c14400 0x100>;
>   interrupts = ;
>   clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>,
>   < CLK_USB_OHCI0>;
>   resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
>   status = "okay";
>};
> 
>ehci0: usb@1c14000 {
>   compatible = "allwinner,sun8i-r40-ehci", "generic-ehci";
>   reg = <0x01c14000 0x100>;
>   interrupts = ;
>   clocks = < CLK_BUS_EHCI0>, < CLK_BUS_OHCI0>;
>   resets = < RST_BUS_EHCI0>, < RST_BUS_OHCI0>;
>   status = "okay";
>};
> ...
> }
> ...
> _otg {
> /* в dtsi defines of usb_otg as dr_mode = "peripheral"; */
>status = "okay";
> };
> 
>  {
>dr_mode = "otg";
>usb0_id_det-gpios = ;
>usb0_vbus-supply = <_vcc5v0>;
>status = "okay";
> };
> [/quote]
> 
> USB-OTG works, but the problem is USB-OTG reads pin ID and choose client or
> host only on OS startup once.
> 
> After adding many printk and -DDEBUG for several subsystems it seems to me
> that the problem is PI11 GPIO irq just doesn't run it's handler requested
> here:
> https://github.com/wirenboard/linux/blob/dev/v5.10.y/drivers/phy/allwinner/phy-sun4i-usb.c#L951
> 
> I observed EINT23 registration in pinctrl sunxi driver:
> [quote]
> [   11.578919] sun4i-pinctrl 1c20800.pinctrl: 1c20800.pinctrl: request IRQ
> for GPIO 267, return 23
> [   11.587657] devm_request_irq data->id_det_irq: 74, ret: 0
> 
>  74:  0  0  0  0  sunxi_pio_edge  23 Edge
>usb0-id-det
> 
> # cat /proc/interrupts
>CPU0   CPU1   CPU2   CPU3
>  26:  0  0  0  0 GICv2  54 Level
> timer@1c20c00
>  27:  0  0  0  0 GICv2  29 Level
> arch_timer
>  28: 198416  45783  21540  10341 GICv2  30 Level
> arch_timer
>  31:  0  0  0  0 GICv2 152 Level
> arm-pmu
>  32:  0  0  0  0 GICv2 153 Level
> arm-pmu
>  33:  0  0  0  0 GICv2 154 Level
> arm-pmu
>  34:  0  0  0  0 GICv2 155 Level
> arm-pmu
>  35:  0  0  0  0 GICv2  59 Level
> 1c02000.dma-controller
>  37:  0  0  0  0 GICv2 102 Level
> gpmmu
>  38:  0  0  0  0 GICv2 104 Level
> ppmmu0
>  39:  0  0  0  0 GICv2 107 Level
> ppmmu1
>  40:175  0  0  0 GICv2 101 Level gp
>  41:128  0  0  0 GICv2 103 Level pp0
>  42:128  0  0  0 GICv2 106 Level pp1
>  43:  0  0  0  0 GICv2  71 Level
> ehci_hcd:usb1
>  44:  0  0 

Re: [linux-sunxi] H3 Ethernet: RX DMA can't acquire the next RX descriptor

[Andre Przywara]

On Wed, 18 Oct 2023 17:22:30 -0700 (PDT)
Mitchell Augustin  wrote:

Hi,

> Hello, I'm writing an ethernet driver for a small embedded os called Xinu 
> on the Orange Pi (allwinner H3) and am running into an issue. I have set up 
> my RX ring and enabled the interrupts, and sometimes a few packets will get 
> received correctly, but after at most a few correct packets, I will start 
> receiving an RX_BUF_UA_INT interrupt. The hardware documentation says this 
> means "the RX DMA can't acquire the next RX descriptor". 
> 
> *Question: What would cause the DMA to be unable to acquire an RX 
> descriptor?*
> 
> For context, my OS does not use any sort of virtual memory, so addresses

But are you running with the MMU and caches enabled? Do you do the
proper cache maintenance for the buffers? The platform peripherals in
the H3 (as in most ARM based devices) are not cache coherent, so you
(the CPU) or the device might read stale data.
This applies both to the DMA descriptors and the actual packets, because
they both live in normal memory.

Happy to explain in more detail if that might be your issue, just let me
know.

Cheers,
Andre

> are directly mapped. My RX ring is a DMA-aligned, circular array of 
> descriptors in the descriptor format specified by the datasheet, and I have 
> set rx_dma_desc_list (address 0x34 in the EMAC CSR) to that descriptor list.
> 
> Any insight would be greatly appreciated. Thanks!
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20231026232937.773fa155%40slackpad.lan.

Re: [linux-sunxi] Orange Pi Zero 3

[Andre Przywara]

Hi Andrew,

On 11/07/2023 19:29, andrew g wrote:
> Has anyone ordered and/or played with this
> 
> https://www.cnx-software.com/2023/07/03/orange-pi-zero-3-allwinner-h618-sbc-ships-with-up-to-4gb-ram/
>  
> 

Please look here:
https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3
and here:
https://lore.kernel.org/linux-arm-kernel/20230731011725.7228-1-andre.przyw...@arm.com/T/#u

In short, it boots existing mainline Linux v6.5-rc1, given the right DTB,
which is in the patch series above. U-Boot support is work in progress.
For now you could use the firmware binary from one of the official images, 
that's actually not too bad (because based on just two year old 
mainline, and without too many custom hacks, it seems).

> 
> https://liliputing.com/orange-pi-zero-3-is-a-cheap-tiny-single-board-pc-with-up-to-4gb-ram-gigabit-ethernet-and-allwinner-h618/
>  
> 
> 
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3.html
>  
> 
> 
> even the linux images is very 'fresh' as in that they are just released 
> *yesterday* [Click and drag to move]

"Freshly built" doesn't mean it's fresh software. On the SPI flash I 
found some kernel 4.9.170 (4.9 is out of LTS support for a while now), 
compiled with GCC 5.3 in a 2016 build.

In general I would disregard any official software offering, and just 
focus on fixing problems in mainline, and supporting more hardware.
For instance graphics support is missing from H616, even though patches
for the display engine, HDMI, and the GPU are floating around. Same goes
for DVFS, so defining voltage/frequency pairs for the CPU.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/fce8aef7-9a12-a18e-f2f1-62b4bb9199d1%40arm.com.

Re: [linux-sunxi] [Need Guidance] - Seeking head start pointer in Kernel Open source contribution

[Andre Przywara]

On Tue, 24 Jan 2023 00:34:52 -0800 (PST)
Rutvij Trivedi  wrote:

Hi Rutvij,

> I am Rutvij  - newbie in open source area and following v4l2 community of 
> Linux Kernel,
> 
> I am enthusiastic about the open source contribution.
> 
> I just want to request that, I am not able to figure out where should I get 
> the issues and try to fix them and start contributing.

One approach could be to just try to do things on your hardware, and
see what works and if there are any problems, then trying to diagnose
and fix them. You would be surprised how many issues you can find this
way. This could be as simple as running a Linux distribution, and for
instance trying to play back a video file.

Some known shortcomings and TODO items are listed on the linux-sunxi
Wiki's Linux mainlining effort page:
https://linux-sunxi.org/Linux_mainlining_effort#Work_In_Progress

Since you mentioned v4l2 and H5, it looks like HDMI audio support for
the H5 is still missing, for instance, although there are patches
out there. You could pick them up, and push them for mainlining.

Another issue that popped up lately is USB-OTG support. Most H5 boards
seem to have a properly wired micro-USB socket, so you could try if
switching between host and peripheral mode works (I guess it doesn't).
Then try to find the problem - between the USB PHY, the MUSB driver, and
the generic Linux OTG code.

If you have any questions, I suggest you join the #linux-sunxi IRC
channel on OFTC: https://www.oftc.net/
If you don't have an IRC client, you can use the web service:
https://webchat.oftc.net/
There are logs of previous conversations here:
https://oftc.irclog.whitequark.org/linux-sunxi/

Cheers,
Andre

> I do have sunxi (H5) hardware available, can anyone advise/suggest anything 
> to take up as a head start ?
> 
> Appreciate your help.
> 
> --
> Thanks & Regards,
> Rutvij H Trivedi
> +91-94087 30545 
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20230201001220.626da780%40slackpad.lan.

Re: [linux-sunxi] Allwinner H3 (Opi PC) USB OTG - Multiple gadgets issue

[Andre Przywara]

On Sun, 27 Nov 2022 01:28:30 -0800 (PST)
Artem Komissarov  wrote:

Hi Artem,

> I apologize in advance if this has been brought up before or discussed, I'm 
> new here and did not find it in the previous posts. 
> I'm working on a port of PiKVM to Orange Pi (PC in this case) among other 
> SBC's and having an issue running multiple USB gadgets (config-fs) at the 
> same time. The most i can seem to run is Keyboard(HID)+Mouse(HID)+ either 
> USB Ethernet or MSD. If i try to do USB Ethernet and MSD the UDC crashes 
> and nothing works. This is on Armbian BTW, and I'm wondering if there is a 
> limit to how many USB gadget devices you can run on Allwinner chips

Yes, there is a hardware limit in the Allwinner implementation of the MUSB
USB controller. The H3 only supports four endpoints (most other
Allwinner SoCs can do five), each with an RX and FX FIFO. So depending on
how much resources your gadget needs, you run out very quickly. For
instance you will be limited to just two serial gadgets, since the normal
one requires three streams (bulk in, bulk out, control), which consumes
two endpoints.
If you dig deeper into the USB setup, it should say somewhere how many
resources your gadgets use, I bet you run into the limit here.

Cheers,
Andre


> or if
> it's a kernel compilation misconfiguration on my part (perhaps a patch?). 
> This setup works perfectly fine on RK3328 for example and of course of 
> native hardware for PiKVM the RPI4. 
> I can provide logs if need be, but i figured someone on here would know the 
> answer simply by explaining the situation. 
> Thank you in advance and appreciate you taking the time to read this!
> 
> Artem Komissarov
> 
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20221128172145.14eb5858%40donnerap.cambridge.arm.com.

[linux-sunxi] Pull request: u-boot-sunxi/master for v2022.07

[Andre Przywara]

Hi Tom,

please pull the sunxi/master branch, containing the first part of the
2022.07 changes.

A big part is the DM pinctrl driver, which allows us to get rid of quite
some custom pinmux code and make the whole port much more robust. Many
thanks to Samuel for that nice contribution! There are some more or less
cosmetic warnings about missing clocks right now, I will send the trivial
fixes for that later.
Another big chunk is the mkimage upgrade, which adds RISC-V and TOC0
(secure images) support. Both features are unused at the moment, but I
have an always-secure board that will use that once the DT lands in the
kernel.
On top of those big things we have some smaller fixes, improving the
I2C DM support, fixing some H6/H616 early clock setup and improving the
eMMC boot partition support.

The gitlab CI completed successfully, including the build test for all
161 sunxi boards. I also boot tested on a A64, A20, H3, H6, and F1C100
board. USB, SD card, eMMC, and Ethernet all work there (where applicable).

Thanks,
Andre
===
The following changes since commit e4b6ebd3de982ae7185dbf689a030e73fd06e0d2:

  Prepare v2022.04 (2022-04-04 10:31:32 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master

for you to fetch changes up to 69a0ea007826bf27584943591e61ee087683fdca:

  sunxi: defconfig: enable eMMC boot partition support (2022-04-05 00:08:46 
+0100)


Andre Przywara (3):
  spl: mmc: extend spl_mmc_boot_mode() to take mmc argument
  sunxi: eMMC: Improve automatic boot source detection
  sunxi: defconfig: enable eMMC boot partition support

Angelo Dureghello (1):
  sunxi: H3: fix non working console on uart2

Baltazar Radics (1):
  Add ethernet0 alias in Nanopi NEO's device tree

Icenowy Zheng (4):
  mkimage: add a flag to describe whether -A is specified
  mkimage: sunxi_egon: refactor for multi-architecture support
  mkimage: sunxi_egon: add support for riscv
  sunxi: specify architecture when generating SPL boot image

Jernej Skrabec (3):
  sunxi: prcm: Add a few registers
  sunxi: clock: H6/H616: Add resistor calibration
  sunxi: clock: H6: Adjust PLL LDO before clock setup

Samuel Holland (28):
  sunxi: pinctrl: Create the driver skeleton
  sunxi: pinctrl: Implement pin muxing functions
  sunxi: pinctrl: Implement get_pin_muxing function
  sunxi: pinctrl: Implement pin configuration
  pinctrl: sunxi: Add UART pinmuxes
  pinctrl: sunxi: Add sun4i EMAC pinmuxes
  net: sunxi_emac: Remove non-DM pin setup
  pinctrl: sunxi: Add sunxi GMAC pinmuxes
  sunxi: Remove non-DM GMAC pin setup
  pinctrl: sunxi: Add sun8i EMAC pinmuxes
  net: sun8i_emac: Remove non-DM pin setup
  pinctrl: sunxi: Add I2C pinmuxes
  sunxi: Remove options and setup code for I2C2-I2C4
  i2c: sun6i_p2wi: Only do non-DM pin setup for non-DM I2C
  i2c: sun8i_rsb: Only do non-DM pin setup for non-DM I2C
  pinctrl: sunxi: Add MMC pinmuxes
  sunxi: Remove non-DM MMC pin setup
  pinctrl: sunxi: Add the A64 PWM pinmux
  pwm: sunxi: Remove non-DM pin setup
  pinctrl: sunxi: Add SPI0 pinmuxes
  spi: sun4i_spi: Remove non-DM pin setup
  tools: mkimage: Add Allwinner TOC0 support
  sunxi: Support SPL in both eGON and TOC0 images
  sunxi: Support building a SPL as a TOC0 image
  i2c: sun6i_p2wi: Initialize chips in .child_pre_probe
  i2c: sun6i_p2wi: Add support for DM clocks and resets
  i2c: sun8i_rsb: Initialize chips in .child_pre_probe
  i2c: sun8i_rsb: Add support for DM clocks and resets

 MAINTAINERS   |   2 +
 arch/arm/Kconfig  |   1 +
 arch/arm/dts/sun8i-h3-nanopi-neo.dts  |   4 +
 arch/arm/include/asm/arch-sunxi/gpio.h|  18 +-
 arch/arm/include/asm/arch-sunxi/i2c.h |  11 +-
 arch/arm/include/asm/arch-sunxi/prcm_sun50i.h |  10 +
 arch/arm/include/asm/arch-sunxi/spl.h |   3 +-
 arch/arm/mach-imx/spl.c   |   2 +-
 arch/arm/mach-k3/am642_init.c |   2 +-
 arch/arm/mach-k3/am6_init.c   |   2 +-
 arch/arm/mach-k3/j721e_init.c |   2 +-
 arch/arm/mach-k3/j721s2_init.c|   2 +-
 arch/arm/mach-mvebu/spl.c |   2 +-
 arch/arm/mach-omap2/boot-common.c |   2 +-
 arch/arm/mach-rockchip/spl.c  |   2 +-
 arch/arm/mach-socfpga/spl_a10.c   |   2 +-
 arch/arm/mach-socfpga/spl_gen5.c  |   2 +-
 arch/arm/mach-stm32mp/spl.c   |   2 +-
 arch/arm/mach-sunxi/Kconfig   |  24 +-
 arch/arm/mach-sunxi/board.c   | 126 +++-
 arch/arm/mach-sunxi/clock_sun50i_h6.c |  20 +-
 arch/arm/mach-sunxi/dram_sun50i_h6.c  |   8 +-
 arch/arm/mach-sunxi/dram_sun50i_h616.c

Re: [linux-sunxi] Help understanding SPL and booting

[Andre Przywara]

On Mon, 7 Feb 2022 15:10:45 -0800
Peter Watkins  wrote:

Hi Peter,

> From an earlier email:
> > See https://lists.denx.de/pipermail/u-boot/2022-January/473568.html 
> >  for a
> > recent example, which is actually much bigger, since it also introduces
> > ARMv5 support to the sunxi port.  
> Oh my. That’s a huge patch. We’ll I’ll just take it a step at a time and look 
> at it a little bit at a time.

Yeah, support for new SoCs *can* be a bit daunting, I always feel we
should clean that up. However this is one of the bad examples, since it
needs to move code around to accommodate a new ARM architecture
revision. Support for a new 32-bit v7 SoC should be much easier.

> > That was referring to your original problem: to get your own build booted.
> > So ideally there is some working image somewhere (could be Android, or
> > whatever), provided by the board vendor. And yes, you compare the UART
> > output of this one to your self-built image, and see what would come next.  
> 
> Ah. OK. I can get a pre-built Linux image, but it’s for eMMC not an SD card.

This is actually a good argument for mainline: we use the very same
image for all boot media: SD card, eMMC, SPI flash, FEL.

> I have the eMMC hardware on order. From images on Lindenis’ site, I
> can see what should come next. I get the following:
> 
> [388][mmc]: ***SD/MMC %u init OK!!!***
> [394]error:bad magic.
> [398]error:bad magic.
> [400]Loading boot-pkg fail(error=4)
> 
> I should get:
> 
> [321][mmc]: ***SD/MMC %u init OK!!!***
> [449]Loading boot-pkg Succeed(index=0)
> 
> 
> However, that doesn’t tell me what the magic number is or where its
> looking for the boot package.

I see. And this is the part were I reckon reverse engineering this is
not worth the time: You will decode some weird image format that
Allwinner came up with (and they like to change that!), and which is
totally irrelevant for mainline operation. There is nothing in the
hardware that would dictate this format, it's a pure invention from the
slightly misguided software troops in AW.

> > So that part is pretty easy: the BROM starts at the beginning of the
> > image. This is a branch instruction to jump over the eGON header and
> > probably some other data parts of boot0. In this case it's:
> >  0:   eaccb   0x338
> > and then continues down there:
> > 338:   eaffb   0x33c
> > 33c:   e10fmrs r0, CPSR
> > 340:   e3c0001fbic r0, r0, #31
> > 
> > And yeah, having some software help you to unwind this is probably
> > mandatory in understanding that. Still takes a lot of time, and asking in
> > IRC is always faster ;-)  
> 
> I have a question out on IRC but it’s pretty silent right now.

Really? I didn't see any post, also nothing in the logs. You are
watkipet, I guess? Please note that OFTC and the channel setup requires
you to be authenticated to post something.

> Your disassembly helped. So far I have this in Ghidra:
> 
>  LAB_0338
> XREF[1]: (j)  
> 0338 ff ff ff ea bLAB_033c
>  LAB_033c
> XREF[1]: 0338(j)  
> 033c 00 00 0f e1 mrs  r0,cpsr
> 0340 1f 00 c0 e3 bic  r0,r0,#ARMV7_MODE_MASK
> 0344 13 00 80 e3 orr  r0,r0,#ARMV7_SVC_MODE
> 0348 c0 00 80 e3 orr  r0,r0,#( ARMV7_IRQ_MASK | 
> ARMV7_FIQ_MASK )   // After reset, ARM automaticly disables IRQ and FIQ, 
> and runs in SVC mode.
> 034c 02 0c c0 e3 bic  r0,r0,#ARMV7_CC_E_BIT   
>  // set little-endian
> 0350 00 f0 21 e1 msr  cpsr_c,r0
>  ;// configure memory system : disable MMU,cache 
> and write buf
> 0354 10 0f 11 ee mrc  p15,0x0,r0,cr1,cr0,0x0
> 0358 02 0a c0 e3 bic  r0,r0,#0x2000
> 035c 07 00 c0 e3 bic  r0,r0,#( ARMV7_C1_M_BIT | 
> ARMV7_C1_A_BIT | ARM
> 0360 02 0b 80 e3 orr  r0,r0,#0x800
> 0364 01 0a c0 e3 bic  r0,r0,#0x1000
> 0368 10 0f 01 ee mcr  p15,0x0,r0,cr1,cr0,0x0
>  // set SP for C language
> 036c 24 d0 9f e5 ldr  sp,[BOOT0_STACK_BOTTOM] 
>  = 00058800h
> 0370 01 00 00 eb bl   FUN_037c
>  undefined FUN_037c()
> 0374 bf 0d 00 fa blx  FUN_3a78
>  undefined FUN_3a78()
> 0378 f7 0d 00 fa blx  FUN_3b5c
>  undefined FUN_3b5c()
> 
> 
> I was hoping to use the msg() calls to 

Re: [linux-sunxi] Help understanding SPL and booting

[Andre Przywara]

On Mon, 7 Feb 2022 09:20:25 -0800
Peter Watkins  wrote:

Hi Peter,

> > How did you build it? I guess using some vendor provided BSP sources?  
> 
> Yes. I used the code Lindenis supplies for that specific board:
> http://wiki.lindeni.org/index.php/Lindenis_V536#Downloading 
> 
> 
> > Shouldn't those contain the magic binary blobs then?  
> 
> The ones that contain the compiled boot0 code? Yes, the one the config file 
> picked for my compilation run is here:
> https://github.com/lindenis-org/lindenis-v536-device/blob/master/config/chips/v536/bin/boot0_sdcard_sun8iw16p1_ddr3.bin
>  
> 
> 
> The compilation process changes a few bytes in the header of that image 
> (inserts build timestamps, maybe?) but otherwise what I have on my SD card is 
> the same as what’s above.

So yeah, this is a bog standard boot0 image, with what we call an "eGON"
header (check the hexdump). The header format is documented in
include/sunxi_image.h in the (mainline) U-Boot tree. For instance you can
see the size (at 0x10: "00 e0 00 00") matching the file size.
The changes it does might be to the DRAM parameters (type, configuration,
timing, ...), we have seen those to be contained in this file in some data
structure somewhere, and the code reads them at runtime.
Then it needs to recalculate the checksum.

> > Well, not quite. boot0 is a proprietary piece of software that serves the
> > same purpose as the SPL part in U-Boot:
> > The on-chip BootROM loads some code from one of the various boot sources
> > (SD card, SPI flash, eMMC ...) into SRAM and executes this. This is
> > typically very limited in size (32KB), though later SoCs tend to support
> > larger images, but not by much. The purpose of this code is then to
> > initialise the DRAM controller, and load the actual U-Boot code.
> > The SPL is part of mainline U-Boot, however boot0 is not, not in mainline
> > and not in AW's BSP versions. In the distant past the boot0 source was
> > "available" for some SoCs/boards, but in general Allwinner tends to keep
> > that closed. I don't know how the situation is in your case, I am afraid
> > you have to dig through all those BSP code drops. Also the existence of
> > a "boot1" stage seemed to vary across the generations, I believe some SoC
> > do not use that, and jump straight into U-Boot.  
> 
> Ah! OK. This is starting to make sense now. The following is one of those 
> code drops, right?
> https://github.com/hno/allwinner-boot/tree/lichee-a20-dev/boot0 
> 

Yes, this is one of the better known examples. But the A20 is 10 years
old, and a lot has changed since then. And the A20 is pretty much reverse
engineered by now and fully support mainline, so we don't need any of this
anymore, it was just used as a source of information.

> I guess part of what you said is mentioned in the note at the bottom of this 
> wiki page:
> https://linux-sunxi.org/Boot_Process 
> 
> In my case, however, I don’t think boot0 loads boot1. Perhaps it goes 
> directly to U-Boot? I never found the string “eGON.BT1” in boot0 or anywhere 
> else in the SD card image.

Yeah, I think boot1 was only used for some older SoCs, which had even more
limited SRAM.

> > The critical part that boot0 does is to initialise the DRAM controller.
> > There is no public documentation about the IP used, and it tends to be
> > different between each SoC, sometimes only slightly so, sometimes
> > dramatically. For the mainline supported SoCs, this was reverse
> > engineered, see arch/arm/mach-sunxi/dram* in a mainline U-Boot source tree
> > near you.  
> OK. So look through here:
> https://github.com/u-boot/u-boot/tree/master/arch/arm/mach-sunxi 
> 
> 
> …for register addresses and values which match what’s in sun8iw16p1_ddr3.bin 
> ?
> Sounds challenging. I’ll give it a try though.

It is indeed challenging, and you won't probably understand much without
help. I am trying to wrap my head around this for 5 years, and have
barely scratched the surface. If you could join the #linux-sunxi IRC
channel on OFTC, there are the some of the people who wrote the DRAM
controller parts in mainline U-Boot in there. Chances are they know a bit
or two about the V536. If you are lucky, one of the existing driver works,
probably with some smaller changes. Just ask if anyone knows about the
V536 DRAM.

Having said that: to get things started, we did in the past use mainline
U-Boot (the non-SPL part: "U-Boot proper") along with some boot0 blob as an
SPL replacement, only as a temporary measure, to get things moving. For a
32-bit 

Re: [linux-sunxi] Help understanding SPL and booting

[Andre Przywara]

On Fri, 4 Feb 2022 17:33:47 -0800 (PST)
Peter Watkins  wrote:

Hi Peter,

> I'm using a Lindenis v536 SBC. I've built an image, loaded it on an SD 

How did you build it? I guess using some vendor provided BSP sources?
Shouldn't those contain the magic binary blobs then?

> card, and now I can observe these messages over a UART interface:
> 
> [70]HELLO! BOOT0 is starting!
> [72]boot0 commit : edb664ec9618b2388deb8d5658aa223a2f47d641
>  
> [90]rsb_send_initseq: rsb clk 400Khz -> 3Mhz
> [94]PMU: AXP2101
> [97]set pll start
> [99]set pll end
> [101]DRAM BOOT DRIVE INFO: V0.41
> [104]the chip id is 0x0004
> [107]the chip id is 0x0004
> [110]the chip id is 0x0004
> [113]the chip id is 0x0004
> [116]the chip id is 0x0004
> [119]chip id check OK
> [121]DRAM_VCC set to 1500 mv
> [156]Training result is = 00ff
> [159]DRAM training fail !
> [195]Training result is = 0007
> [198][AUTO DEBUG]32bit,1 ranks training success!
> [236]Training result is = 0007
> [274]Training result is = 0007
> [277]DRAM CLK =792 MHZ
> [280]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)
> [318]Training result is = 0007
> [322]Actual DRAM SIZE =1024 M
> [325]DRAM SIZE =1024 MBytes, para1 = 30fa, para2 = 0400, dram_tpr13 
> = 08006843
> [342]DRAM simple test OK.
> [344]dram size =1024
> [348]card no is 0
> [350]sdcard 0 line count 4
> [352][mmc]: mmc driver ver 2017-09-26 15:04
> [357][mmc]: sdc0 spd mode error, 2
> [360][mmc]: mmc 0 bias 
> [368][mmc]: Wrong media type 0x
> [372][mmc]: ***Try SD card %u***
> [382][mmc]: HSSDR52/SDR25 %u bit
> [385][mmc]: %u Hz
> [387][mmc]: %u MB
> [388][mmc]: ***SD/MMC %u init OK!!!***
> [394]error:bad magic.
> [398]error:bad magic.
> [400]Loading boot-pkg fail(error=4)
> [404]Ready to disable icache.
> 
> 
> My understanding is that I'm seeing the Boot0 portion of U-Boot executing. 
> This is called the SPL, right? This starts at the 8k address on the SD card.

Well, not quite. boot0 is a proprietary piece of software that serves the
same purpose as the SPL part in U-Boot:
The on-chip BootROM loads some code from one of the various boot sources
(SD card, SPI flash, eMMC ...) into SRAM and executes this. This is
typically very limited in size (32KB), though later SoCs tend to support
larger images, but not by much. The purpose of this code is then to
initialise the DRAM controller, and load the actual U-Boot code.
The SPL is part of mainline U-Boot, however boot0 is not, not in mainline
and not in AW's BSP versions. In the distant past the boot0 source was
"available" for some SoCs/boards, but in general Allwinner tends to keep
that closed. I don't know how the situation is in your case, I am afraid
you have to dig through all those BSP code drops. Also the existence of
a "boot1" stage seemed to vary across the generations, I believe some SoC
do not use that, and jump straight into U-Boot.

The critical part that boot0 does is to initialise the DRAM controller.
There is no public documentation about the IP used, and it tends to be
different between each SoC, sometimes only slightly so, sometimes
dramatically. For the mainline supported SoCs, this was reverse
engineered, see arch/arm/mach-sunxi/dram* in a mainline U-Boot source tree
near you.

>From my experience dealing with the BSP code is a complete waste of time.
>From briefly looking into the github, this release seems to be based on a
2014 U-Boot version, which is outdated beyond all hopes.
If we could find out if the DRAM controller is close to something
existing, we could attempt a mainline port. Apart from the DRAM parts this
is mostly a matter of diligence to sort out the address map and clock bits
and stuff them into the existing code.
See https://lists.denx.de/pipermail/u-boot/2022-January/473568.html for a
recent example, which is actually much bigger, since it also introduces
ARMv5 support to the sunxi port.

> I'm guessing it can't find Boot1 at the location it expects on the SD card. 
> However, I can't seem to find this code in the U-boot sources. When I look 
> through the sources in the Lindenis GitHub repo I only find these strings 
> in binary files. Is this something that Allwinner compiled and only 
> released as a binary?
> 
> Any pointers of where I could look next to troubleshoot this?

Can you try to harvest those bits from an existing (pre-built) binary
image? Or at least compare the output of such a build to see what you are
missing.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20220207113051.132bf63c%40donnerap.cambridge.arm.com.

[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Tue, 17 Aug 2021 09:38:10 +0200
Maxime Ripard  wrote:

Hi Maxime,

> On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
> > On Mon, 26 Jul 2021 16:41:37 +0200
> > Maxime Ripard  wrote:
> >   
> > > Hi,
> > > 
> > > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:  
> > > > Add the obvious compatible name to the existing RTC binding.
> > > > The actual RTC part of the device uses a different day/month/year
> > > > storage scheme, so it's not compatible with the previous devices.
> > > > Also the clock part is quite different, as there is no external 32K LOSC
> > > > oscillator input.
> > > > 
> > > > Signed-off-by: Andre Przywara 
> > > >
> > > > ---
> > > >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml  | 14 ++
> > > >  1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> > > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > index beeb90e55727..d8a6500e5840 100644
> > > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > @@ -26,6 +26,7 @@ properties:
> > > >- const: allwinner,sun50i-a64-rtc
> > > >- const: allwinner,sun8i-h3-rtc
> > > >- const: allwinner,sun50i-h6-rtc
> > > > +  - const: allwinner,sun50i-h616-rtc
> > > >  
> > > >reg:
> > > >  maxItems: 1
> > > > @@ -104,6 +105,19 @@ allOf:
> > > >minItems: 3
> > > >maxItems: 3
> > > >  
> > > > +  - if:
> > > > +  properties:
> > > > +compatible:
> > > > +  contains:
> > > > +const: allwinner,sun50i-h616-rtc
> > > > +
> > > > +then:
> > > > +  properties:
> > > > +clock-output-names:
> > > > +  minItems: 3
> > > > +  maxItems: 3
> > > 
> > > You don't need both of them when they are equal
> > >   
> > > > +clocks: false
> > > > +
> > > 
> > > It's not entirely clear to me what those clocks are about though. If we
> > > look at the clock output in the user manual, it looks like there's only
> > > two clocks that are actually being output: the 32k "fanout" clock and
> > > the losc. What are the 3 you're talking about?]  
> > 
> > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> > clock (/32), and the multiplexed PAD.  
> 
> But the input and debounce clock is only for the RTC itself right? So it
> should be local to the driver and doesn't need to be made available to
> the other drivers

I understood "debounce" as being the clock used for the pinctrl
debouncer. What would it debounce otherwise? Do you think that this
"debounce circuit" is something internal to the RTC and is totally
irrelevant for us?

But in general I looked at how many *different* clocks this diagram
describes, and I count: one unaltered ("SYSTEM"), one "div by
32" (RTC/debounce), and one multiplexed. My aim was to avoid
DT binding changes when we later discover we do need one of them for
something (as happened in the past). So three seemed to be the safe
choice here, to avoid surprises. In the worst case we just will never
reference one of them.

> Either way, what this list is must be documented.

You mean to overwrite the "description" stanza for clock-output-names?
And can this be done in the per-SoC parts in the later part of the
binding, keeping the existing description?

Cheers,
Andre

> 
> > > Also, it looks like the 32k fanout clock needs at least the hosc or
> > > pll-periph in input, so we probably don't want to ask for no parent
> > > clock?  
> > 
> > Well, we never seem to reference the HOSC this way, this was always
> > somewhat explicit. And yes, there is PLL-PERIPH as an input, but we
> > don't support this yet. So I went with 0 input clocks *for now*: the
> > driver can then ignore all clocks, so any clock referenced in the DT
> > later won't cause any harm. This will all be addressed by Samuel's RTC
> > clock patch, which will also touch the H6, IIRC. And it looks like we
> > will need to touch the binding anyway then, but can then just *extend*
> > this.  
> 
> You mentioned that series several times already and never provided an
> explanation for what it was supposed to be doing except fixing
> everything. What's the general plan for that series?
> 
> Maxime

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210818100407.7cf7cfb7%40slackpad.fritz.box.

[linux-sunxi] [PATCH v9 11/11] arm64: dts: allwinner: h616: Add X96 Mate TV box support

[Andre Przywara]

The X96 Mate is an Allwinner H616 based TV box, featuring:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 2GiB/4GiB RAM (fully usable!)
  - 16/32/64GiB eMMC
  - 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
  - Unsupported Allwinner WiFi chip
  - 2 x USB 2.0 host ports
  - HDMI port
  - IR receiver
  - 5V/2A DC power supply via barrel plug

For more information see: https://linux-sunxi.org/X96_Mate

Add a basic devicetree for it, with SD card and eMMC working, as
well as serial and the essential peripherals, like the AXP PMIC.

This DT is somewhat minimal, and should work on many other similar TV
boxes with the Allwinner H616 chip.

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/Makefile|   1 +
 .../dts/allwinner/sun50i-h616-x96-mate.dts| 178 ++
 2 files changed, 179 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 62f8d43cf84d..14053c566601 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -38,3 +38,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
new file mode 100644
index ..6334f4e20fd0
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2021 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "X96 Mate";
+   compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc5v: vcc5v {
+   /* board wide 5V supply directly from the DC input */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;  /* PF6 */
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   vqmmc-supply = <_bldo1>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp305: pmic@745 {
+   compatible = "x-powers,axp305", "x-powers,axp805",
+"x-powers,axp806";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #address-cells = <0>;
+   reg = <0x745>;
+
+   x-powers,self-working-mode;
+   vina-supply = <_vcc5v>;
+   vinb-supply = <_vcc5v>;
+   vinc-supply = <_vcc5v>;
+   vind-supply = <_vcc5v>;
+   vine-supply = <_vcc5v>;
+   aldoin-supply = <_vcc5v>;
+   bldoin-supply = <_vcc5v>;
+   cldoin-supply = <_vcc5v>;
+
+   regulators {
+   reg_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-sys";
+   };
+
+   /* Enabled by the Android BSP */
+   reg_aldo2: aldo2 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc3v3-ext";
+   status = "disabled";
+   };
+
+   /* Enabled by the Android BSP */
+   reg_aldo3: aldo3 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc3v3-ext2";
+   status = &

[linux-sunxi] [PATCH v9 10/11] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support

[Andre Przywara]

The OrangePi Zero 2 is a development board with the new H616 SoC. It
comes with the following features:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 512MiB/1GiB DDR3 DRAM
  - AXP305 PMIC
  - Raspberry-Pi-1 compatible GPIO header
  - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
  - 1 USB 2.0 host port
  - 1 USB 2.0 type C port (power supply + OTG)
  - MicroSD slot
  - on-board 2MiB bootable SPI NOR flash
  - 1Gbps Ethernet port (via RTL8211F PHY)
  - micro-HDMI port
  - unsupported Allwinner WiFi/BT chip

For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/Makefile|   1 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 204 ++
 2 files changed, 205 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index a96d9d2d8dd8..62f8d43cf84d 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -37,3 +37,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
new file mode 100644
index ..0132c06be96a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "OrangePi Zero2";
+   compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
+
+   aliases {
+   ethernet0 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led-0 {
+   function = LED_FUNCTION_POWER;
+   color = ;
+   gpios = < 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+   default-state = "on";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   gpios = < 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+   };
+   };
+
+   reg_vcc5v: vcc5v {
+   /* board wide 5V supply directly from the USB-C socket */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-mode = "rgmii";
+   phy-handle = <_rgmii_phy>;
+   phy-supply = <_dcdce>;
+   allwinner,rx-delay-ps = <3100>;
+   allwinner,tx-delay-ps = <700>;
+   status = "okay";
+};
+
+ {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;  /* PF6 */
+   bus-width = <4>;
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp305: pmic@745 {
+   compatible = "x-powers,axp305", "x-powers,axp805",
+"x-powers,axp806";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #address-cells = <0>;
+   reg = <0x745>;
+
+   x-powers,self-working-mode;
+   vina-supply = <_vcc5v>;
+   vinb-supply = <_vcc5v>;
+   vinc-supply = <_vcc5v>;
+   vind-supply = <_vcc5v>;
+   vine-supply = <_vcc5v>;
+   aldoin-supply = <_vcc5v>;
+   bldoin-supply = <_vcc5v>;
+   cldoin-supply = <_vcc5v>;
+
+   regulators {
+   reg_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-sys";
+   

[linux-sunxi] [PATCH v9 09/11] dt-bindings: arm: sunxi: Add two H616 board compatible strings

[Andre Przywara]

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml 
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 889128acf49a..1c557a736d86 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -848,6 +848,11 @@ properties:
   - const: yones-toptech,bs1078-v2
   - const: allwinner,sun6i-a31s
 
+  - description: X96 Mate TV box
+items:
+  - const: hechuang,x96-mate
+  - const: allwinner,sun50i-h616
+
   - description: Xunlong OrangePi
 items:
   - const: xunlong,orangepi
@@ -948,4 +953,9 @@ properties:
   - const: xunlong,orangepi-zero-plus2-h3
   - const: allwinner,sun8i-h3
 
+  - description: Xunlong OrangePi Zero 2
+items:
+  - const: xunlong,orangepi-zero2
+  - const: allwinner,sun50i-h616
+
 additionalProperties: true
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802003952.19942-10-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v9 08/11] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Andre Przywara]

This (relatively) new SoC is similar to the H6, but drops the (broken)
PCIe support and the USB 3.0 controller. It also gets the management
controller removed, which in turn removes *some*, but not all of the
devices formerly dedicated to the ARISC (CPUS).
And while there is still the extra sunxi interrupt controller, the
package lacks the corresponding NMI pin, so no interrupts for the PMIC.

The reserved memory node is actually handled by Trusted Firmware now,
but U-Boot fails to propagate this to a separately loaded DTB, so we
keep it in here for now, until U-Boot learns to do this properly.

Signed-off-by: Andre Przywara 
---
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 575 ++
 1 file changed, 575 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
new file mode 100644
index ..6a15ff2e7ebf
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -0,0 +1,575 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Arm Ltd.
+// based on the H6 dtsi, which is:
+//   Copyright (C) 2017 Icenowy Zheng 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <0>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <1>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <2>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu3: cpu@3 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <3>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+   };
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* 512KiB reserved for ARM Trusted Firmware (BL31) */
+   secmon_reserved: secmon@4000 {
+   reg = <0x0 0x4000 0x0 0x8>;
+   no-map;
+   };
+   };
+
+   osc24M: osc24M-clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ,
+,
+,
+;
+   interrupt-affinity = <>, <>, <>, <>;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   arm,no-tick-in-suspend;
+   interrupts = ,
+,
+,
+;
+   };
+
+   soc@0 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x0 0x4000>;
+
+   syscon: syscon@300 {
+   compatible = "allwinner,sun50i-h616-system-control";
+   reg = <0x0300 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   sram_c: sram@28000 {
+   compatible = "mmio-sram";
+   reg = <0x00028000 0x3>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x00028000 0x3&g

[linux-sunxi] [PATCH v9 07/11] rtc: sun6i: Add Allwinner H616 support

[Andre Przywara]

The H616 RTC changes its day storage to the newly introduced linear day
scheme, so pair the new compatible string with this feature flag.
The clock part is missing an external 32768 Hz oscillator input pin,
for future expansion we must thus ignore any provided clock for now.

Signed-off-by: Andre Przywara 
Reviewed-by: Jernej Skrabec 
---
 drivers/rtc/rtc-sun6i.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index fe1bee3a4ec6..77db4f0a042c 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -392,6 +392,23 @@ static void __init sun50i_h6_rtc_clk_init(struct 
device_node *node)
 CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
  sun50i_h6_rtc_clk_init);
 
+static const struct sun6i_rtc_clk_data sun50i_h616_rtc_data = {
+   .rc_osc_rate = 1600,
+   .fixed_prescaler = 32,
+   .has_prescaler = 1,
+   .has_out_clk = 1,
+   .export_iosc = 1,
+   .no_ext_losc = 1,
+};
+
+static void __init sun50i_h616_rtc_clk_init(struct device_node *node)
+{
+   sun6i_rtc_clk_init(node, _h616_rtc_data);
+}
+
+CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
+ sun50i_h616_rtc_clk_init);
+
 /*
  * The R40 user manual is self-conflicting on whether the prescaler is
  * fixed or configurable. The clock diagram shows it as fixed, but there
@@ -797,6 +814,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
{ .compatible = "allwinner,sun8i-v3-rtc" },
{ .compatible = "allwinner,sun50i-h5-rtc" },
{ .compatible = "allwinner,sun50i-h6-rtc" },
+   { .compatible = "allwinner,sun50i-h616-rtc",
+   .data = (void *)RTC_LINEAR_DAY },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802003952.19942-8-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v9 06/11] rtc: sun6i: Add support for RTCs without external LOSCs

[Andre Przywara]

Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack
a pin for an external 32768 Hz oscillator. As a consequence, this LOSC
can't be selected as the RTC clock source, and we must rely on the
internal RC oscillator.
To allow additions of clocks to the RTC node, add a feature bit to ignore
any provided clocks for now (the current code would think this is the
external LOSC). Later DTs and code can then for instance add the PLL
based clock input, and older kernel won't get confused.

Signed-off-by: Andre Przywara 
Acked-by: Jernej Skrabec 
---
 drivers/rtc/rtc-sun6i.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 752bea949050..fe1bee3a4ec6 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -134,6 +134,7 @@ struct sun6i_rtc_clk_data {
unsigned int export_iosc : 1;
unsigned int has_losc_en : 1;
unsigned int has_auto_swt : 1;
+   unsigned int no_ext_losc : 1;
 };
 
 #define RTC_LINEAR_DAY BIT(0)
@@ -256,7 +257,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node,
}
 
/* Switch to the external, more precise, oscillator, if present */
-   if (of_get_property(node, "clocks", NULL)) {
+   if (!rtc->data->no_ext_losc && of_get_property(node, "clocks", NULL)) {
reg |= SUN6I_LOSC_CTRL_EXT_OSC;
if (rtc->data->has_losc_en)
reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
@@ -282,14 +283,19 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node,
}
 
parents[0] = clk_hw_get_name(rtc->int_osc);
-   /* If there is no external oscillator, this will be NULL and ... */
-   parents[1] = of_clk_get_parent_name(node, 0);
+   if (rtc->data->no_ext_losc) {
+   parents[1] = NULL;
+   init.num_parents = 1;
+   } else {
+   /* If there is no external oscillator, this will be NULL and */
+   parents[1] = of_clk_get_parent_name(node, 0);
+   /* ... number of clock parents will be 1. */
+   init.num_parents = of_clk_get_parent_count(node) + 1;
+   }
 
rtc->hw.init = 
 
init.parent_names = parents;
-   /* ... number of clock parents will be 1. */
-   init.num_parents = of_clk_get_parent_count(node) + 1;
of_property_read_string_index(node, "clock-output-names", 0,
  );
 
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802003952.19942-7-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v9 05/11] rtc: sun6i: Add support for broken-down alarm registers

[Andre Przywara]

Newer versions of the Allwinner RTC, for instance as found in the H616
SoC, not only store the current day as a linear number, but also change
the way the alarm is handled: There are now two registers, that
explicitly store the wakeup time, in the same format as the current
time.

Add support for that variant by writing the requested wakeup time
directly into the registers, instead of programming the seconds left, as
the old SoCs required.

Signed-off-by: Andre Przywara 
Reviewed by: Jernej Skrabec 
---
 drivers/rtc/rtc-sun6i.c | 57 +
 1 file changed, 40 insertions(+), 17 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index a980d4e7408d..752bea949050 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -48,7 +48,8 @@
 
 /* Alarm 0 (counter) */
 #define SUN6I_ALRM_COUNTER 0x0020
-#define SUN6I_ALRM_CUR_VAL 0x0024
+/* This holds the remaining alarm seconds on older SoCs (current value) */
+#define SUN6I_ALRM_COUNTER_HMS 0x0024
 #define SUN6I_ALRM_EN  0x0028
 #define SUN6I_ALRM_EN_CNT_EN   BIT(0)
 #define SUN6I_ALRM_IRQ_EN  0x002c
@@ -523,32 +524,54 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
struct rtc_time *alrm_tm = >time;
struct rtc_time tm_now;
-   time64_t time_now, time_set;
+   time64_t time_set;
+   u32 counter_val, counter_val_hms;
int ret;
 
-   ret = sun6i_rtc_gettime(dev, _now);
-   if (ret < 0) {
-   dev_err(dev, "Error in getting time\n");
-   return -EINVAL;
-   }
-
time_set = rtc_tm_to_time64(alrm_tm);
-   time_now = rtc_tm_to_time64(_now);
-   if (time_set <= time_now) {
-   dev_err(dev, "Date to set in the past\n");
-   return -EINVAL;
-   }
 
-   if ((time_set - time_now) > U32_MAX) {
-   dev_err(dev, "Date too far in the future\n");
-   return -EINVAL;
+   if (chip->flags & RTC_LINEAR_DAY) {
+   /*
+* The alarm registers hold the actual alarm time, encoded
+* in the same way (linear day + HMS) as the current time.
+*/
+   counter_val_hms = SUN6I_TIME_SET_SEC_VALUE(alrm_tm->tm_sec)  |
+ SUN6I_TIME_SET_MIN_VALUE(alrm_tm->tm_min)  |
+ SUN6I_TIME_SET_HOUR_VALUE(alrm_tm->tm_hour);
+   /* The division will cut off the H:M:S part of alrm_tm. */
+   counter_val = div_u64(rtc_tm_to_time64(alrm_tm), SECS_PER_DAY);
+   } else {
+   /* The alarm register holds the number of seconds left. */
+   time64_t time_now;
+
+   ret = sun6i_rtc_gettime(dev, _now);
+   if (ret < 0) {
+   dev_err(dev, "Error in getting time\n");
+   return -EINVAL;
+   }
+
+   time_now = rtc_tm_to_time64(_now);
+   if (time_set <= time_now) {
+   dev_err(dev, "Date to set in the past\n");
+   return -EINVAL;
+   }
+   if ((time_set - time_now) > U32_MAX) {
+   dev_err(dev, "Date too far in the future\n");
+   return -EINVAL;
+   }
+
+   counter_val = time_set - time_now;
}
 
sun6i_rtc_setaie(0, chip);
writel(0, chip->base + SUN6I_ALRM_COUNTER);
+   if (chip->flags & RTC_LINEAR_DAY)
+   writel(0, chip->base + SUN6I_ALRM_COUNTER_HMS);
usleep_range(100, 300);
 
-   writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
+   writel(counter_val, chip->base + SUN6I_ALRM_COUNTER);
+   if (chip->flags & RTC_LINEAR_DAY)
+   writel(counter_val_hms, chip->base + SUN6I_ALRM_COUNTER_HMS);
chip->alarm = time_set;
 
sun6i_rtc_setaie(wkalrm->enabled, chip);
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802003952.19942-6-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v9 04/11] rtc: sun6i: Add support for linear day storage

[Andre Przywara]

Newer versions of the Allwinner RTC, as for instance found in the H616
SoC, no longer store a broken-down day/month/year representation in the
RTC_DAY_REG, but just a linear day number.
The user manual does not give any indication about the expected epoch
time of this day count, but the BSP kernel uses the UNIX epoch, which
allows easy support due to existing conversion functions in the kernel.

Allow tagging a compatible string with a flag, and use that to mark
those new RTCs. Then convert between a UNIX day number (converted into
seconds) and the broken-down day representation using mktime64() and
time64_to_tm() in the set_time/get_time functions.

That enables support for the RTC in those new chips.

Signed-off-by: Andre Przywara 
Reviewed-by: Jernej Skrabec 
---
 drivers/rtc/rtc-sun6i.c | 69 +++--
 1 file changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index c551ebf0ac00..a980d4e7408d 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -110,6 +110,8 @@
 #define SUN6I_YEAR_MIN 1970
 #define SUN6I_YEAR_OFF (SUN6I_YEAR_MIN - 1900)
 
+#define SECS_PER_DAY   (24 * 3600ULL)
+
 /*
  * There are other differences between models, including:
  *
@@ -133,12 +135,15 @@ struct sun6i_rtc_clk_data {
unsigned int has_auto_swt : 1;
 };
 
+#define RTC_LINEAR_DAY BIT(0)
+
 struct sun6i_rtc_dev {
struct rtc_device *rtc;
const struct sun6i_rtc_clk_data *data;
void __iomem *base;
int irq;
time64_t alarm;
+   unsigned long flags;
 
struct clk_hw hw;
struct clk_hw *int_osc;
@@ -467,22 +472,30 @@ static int sun6i_rtc_gettime(struct device *dev, struct 
rtc_time *rtc_tm)
} while ((date != readl(chip->base + SUN6I_RTC_YMD)) ||
 (time != readl(chip->base + SUN6I_RTC_HMS)));
 
+   if (chip->flags & RTC_LINEAR_DAY) {
+   /*
+* Newer chips store a linear day number, the manual
+* does not mandate any epoch base. The BSP driver uses
+* the UNIX epoch, let's just copy that, as it's the
+* easiest anyway.
+*/
+   rtc_time64_to_tm((date & 0x) * SECS_PER_DAY, rtc_tm);
+   } else {
+   rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
+   rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date) - 1;
+   rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
+
+   /*
+* switch from (data_year->min)-relative offset to
+* a (1900)-relative one
+*/
+   rtc_tm->tm_year += SUN6I_YEAR_OFF;
+   }
+
rtc_tm->tm_sec  = SUN6I_TIME_GET_SEC_VALUE(time);
rtc_tm->tm_min  = SUN6I_TIME_GET_MIN_VALUE(time);
rtc_tm->tm_hour = SUN6I_TIME_GET_HOUR_VALUE(time);
 
-   rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
-   rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date);
-   rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
-
-   rtc_tm->tm_mon  -= 1;
-
-   /*
-* switch from (data_year->min)-relative offset to
-* a (1900)-relative one
-*/
-   rtc_tm->tm_year += SUN6I_YEAR_OFF;
-
return 0;
 }
 
@@ -567,20 +580,25 @@ static int sun6i_rtc_settime(struct device *dev, struct 
rtc_time *rtc_tm)
u32 date = 0;
u32 time = 0;
 
-   rtc_tm->tm_year -= SUN6I_YEAR_OFF;
-   rtc_tm->tm_mon += 1;
-
-   date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
-   SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
-   SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
-
-   if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
-   date |= SUN6I_LEAP_SET_VALUE(1);
-
time = SUN6I_TIME_SET_SEC_VALUE(rtc_tm->tm_sec)  |
SUN6I_TIME_SET_MIN_VALUE(rtc_tm->tm_min)  |
SUN6I_TIME_SET_HOUR_VALUE(rtc_tm->tm_hour);
 
+   if (chip->flags & RTC_LINEAR_DAY) {
+   /* The division will cut off the H:M:S part of rtc_tm. */
+   date = div_u64(rtc_tm_to_time64(rtc_tm), SECS_PER_DAY);
+   } else {
+   rtc_tm->tm_year -= SUN6I_YEAR_OFF;
+   rtc_tm->tm_mon += 1;
+
+   date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
+   SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
+   SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
+
+   if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
+   date |= SUN6I_LEAP_SET_VALUE(1);
+   }
+
/* Check whether registers are writable */
if (sun6i_rtc_wait(chip, SUN6I_LOSC_CTRL,
   SUN6I_LOSC_CTRL_ACC_MASK, 50)) {
@@ -674,6 +692,8 @@ static int 

[linux-sunxi] [PATCH v9 03/11] rtc: sun6i: Fix time overflow handling

[Andre Przywara]

Using "unsigned long" for UNIX timestamps is never a good idea, and
comparing the value of such a variable against U32_MAX does not do
anything useful on 32-bit systems.

Use the proper time64_t type when dealing with timestamps, and avoid
cutting down the time range unnecessarily. This also fixes the flawed
check for the alarm time being too far into the future.

The check for this condition is actually somewhat theoretical, as the
RTC counts till 2033 only anyways, and 2^32 seconds from now is not
before the year 2157 - at which point I hope nobody will be using this
hardware anymore.

Signed-off-by: Andre Przywara 
Reviewed-by: Jernej Skrabec 
---
 drivers/rtc/rtc-sun6i.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index adec1b14a8de..c551ebf0ac00 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -138,7 +138,7 @@ struct sun6i_rtc_dev {
const struct sun6i_rtc_clk_data *data;
void __iomem *base;
int irq;
-   unsigned long alarm;
+   time64_t alarm;
 
struct clk_hw hw;
struct clk_hw *int_osc;
@@ -510,10 +510,8 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
struct rtc_time *alrm_tm = >time;
struct rtc_time tm_now;
-   unsigned long time_now = 0;
-   unsigned long time_set = 0;
-   unsigned long time_gap = 0;
-   int ret = 0;
+   time64_t time_now, time_set;
+   int ret;
 
ret = sun6i_rtc_gettime(dev, _now);
if (ret < 0) {
@@ -528,9 +526,7 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
return -EINVAL;
}
 
-   time_gap = time_set - time_now;
-
-   if (time_gap > U32_MAX) {
+   if ((time_set - time_now) > U32_MAX) {
dev_err(dev, "Date too far in the future\n");
return -EINVAL;
}
@@ -539,7 +535,7 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
writel(0, chip->base + SUN6I_ALRM_COUNTER);
usleep_range(100, 300);
 
-   writel(time_gap, chip->base + SUN6I_ALRM_COUNTER);
+   writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
chip->alarm = time_set;
 
sun6i_rtc_setaie(wkalrm->enabled, chip);
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802003952.19942-4-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v9 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing RTC binding.
The actual RTC part of the device uses a different day/month/year
storage scheme, so it's not compatible with the previous devices.
Also the clock part is quite different, as there is no external 32K LOSC
oscillator input.

Signed-off-by: Andre Przywara 
Reviewed-by: Rob Herring 
---
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml  | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index beeb90e55727..d8a6500e5840 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -26,6 +26,7 @@ properties:
   - const: allwinner,sun50i-a64-rtc
   - const: allwinner,sun8i-h3-rtc
   - const: allwinner,sun50i-h6-rtc
+  - const: allwinner,sun50i-h616-rtc
 
   reg:
 maxItems: 1
@@ -104,6 +105,19 @@ allOf:
   minItems: 3
   maxItems: 3
 
+  - if:
+  properties:
+compatible:
+  contains:
+const: allwinner,sun50i-h616-rtc
+
+then:
+  properties:
+clock-output-names:
+  minItems: 3
+  maxItems: 3
+clocks: false
+
   - if:
   properties:
 compatible:
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802003952.19942-3-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v9 01/11] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Andre Przywara]

The AXP305 PMIC used on many boards with the H616 SoC seems to be fully
compatible to the AXP805 PMIC, so add the proper chain of compatible
strings.

Also at least on one board (Orangepi Zero2) there is no interrupt line
connected to the CPU, so make the "interrupts" property optional.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 4991a6415796..2b53dcc0ea61 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -26,10 +26,10 @@ Required properties:
 * "x-powers,axp803"
 * "x-powers,axp806"
 * "x-powers,axp805", "x-powers,axp806"
+* "x-powers,axp305", "x-powers,axp805", "x-powers,axp806"
 * "x-powers,axp809"
 * "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
-- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
 - #interrupt-cells: Should be set to 1
 
@@ -43,6 +43,7 @@ more information:
AXP20x/LDO3: software-based implementation
 
 Optional properties:
+- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
  AXP152/20X: range:  750-1875, Default: 1.5 MHz
  AXP22X/8XX: range: 1800-4050, Default: 3   MHz
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802003952.19942-2-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v9 00/11] arm64: sunxi: Initial Allwinner H616 SoC support

[Andre Przywara]

tput names
- r-ccu: fix number of used clocks
- ccu: remove PLL-PERIPHy(4X)
- ccu: fix gpu1 divider range
- ccu: fix usb-phy3 parent
- ccu: add missing TV clocks
- ccu: rework to CLK_OF_DECLARE style
- ccu: enable output bit for PLL clocks
- ccu: renumber clocks
- .dtsi: drop sun50i-a64-system-control fallback
- .dtsi: drop unknown SRAM regions
- .dtsi: add more (undocumented) GPIO interrupts
- .dtsi: fix I2C3 pin names
- .dtsi: use a100-emmc fallback for MMC2
- .dtsi: add second EMAC controller
- .dtsi: use H3 MUSB controller fallback
- .dtsi: fix frame size for USB PHY PMU registers
- .dtsi: add USB0 PHY references
- .dtsi: fix IR controller clock source
- .dts: fix LED naming and swap pins
- .dts: use 5V supply parent for USB supply
- .dts: drop dummy IRQ for AXP
- .dts: enable 3V3 header pin power rail
- .dts: add SPI flash node
- .dts: make USB-C port peripheral only
- add IRQ-less AXP support
- add two patches to support more than one EMAC clock
- add patch to rework and extend USB PHY support
- add DT binding documentation patches

Andre Przywara (11):
  dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  dt-bindings: rtc: sun6i: Add H616 compatible string
  rtc: sun6i: Fix time overflow handling
  rtc: sun6i: Add support for linear day storage
  rtc: sun6i: Add support for broken-down alarm registers
  rtc: sun6i: Add support for RTCs without external LOSCs
  rtc: sun6i: Add Allwinner H616 support
  arm64: dts: allwinner: Add Allwinner H616 .dtsi file
  dt-bindings: arm: sunxi: Add two H616 board compatible strings
  arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
  arm64: dts: allwinner: h616: Add X96 Mate TV box support

 .../devicetree/bindings/arm/sunxi.yaml|  10 +
 .../devicetree/bindings/mfd/axp20x.txt|   3 +-
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml |  14 +
 arch/arm64/boot/dts/allwinner/Makefile|   2 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 204 +++
 .../dts/allwinner/sun50i-h616-x96-mate.dts| 178 ++
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 575 ++
 drivers/rtc/rtc-sun6i.c   | 169 +++--
 8 files changed, 1103 insertions(+), 52 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi

-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802003952.19942-1-andre.przywara%40arm.com.

[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Mon, 26 Jul 2021 16:41:37 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
> > Add the obvious compatible name to the existing RTC binding.
> > The actual RTC part of the device uses a different day/month/year
> > storage scheme, so it's not compatible with the previous devices.
> > Also the clock part is quite different, as there is no external 32K LOSC
> > oscillator input.
> > 
> > Signed-off-by: Andre Przywara 
> >
> > ---
> >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml  | 14 ++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > index beeb90e55727..d8a6500e5840 100644
> > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > @@ -26,6 +26,7 @@ properties:
> >- const: allwinner,sun50i-a64-rtc
> >- const: allwinner,sun8i-h3-rtc
> >- const: allwinner,sun50i-h6-rtc
> > +  - const: allwinner,sun50i-h616-rtc
> >  
> >reg:
> >  maxItems: 1
> > @@ -104,6 +105,19 @@ allOf:
> >minItems: 3
> >maxItems: 3
> >  
> > +  - if:
> > +  properties:
> > +compatible:
> > +  contains:
> > +const: allwinner,sun50i-h616-rtc
> > +
> > +then:
> > +  properties:
> > +clock-output-names:
> > +  minItems: 3
> > +  maxItems: 3  
> 
> You don't need both of them when they are equal
> 
> > +clocks: false
> > +  
> 
> It's not entirely clear to me what those clocks are about though. If we
> look at the clock output in the user manual, it looks like there's only
> two clocks that are actually being output: the 32k "fanout" clock and
> the losc. What are the 3 you're talking about?]

I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
clock (/32), and the multiplexed PAD.

> Also, it looks like the 32k fanout clock needs at least the hosc or
> pll-periph in input, so we probably don't want to ask for no parent
> clock?

Well, we never seem to reference the HOSC this way, this was always
somewhat explicit. And yes, there is PLL-PERIPH as an input, but we
don't support this yet. So I went with 0 input clocks *for now*: the
driver can then ignore all clocks, so any clock referenced in the DT
later won't cause any harm. This will all be addressed by Samuel's RTC
clock patch, which will also touch the H6, IIRC. And it looks like we
will need to touch the binding anyway then, but can then just *extend*
this.

The point is that everything works(TM) as of now: The consumers
(pinctrl) get their LOSC clock, and can go ahead. This is in the
interest to get us moving now, and refine the actual implementation
later. In this case this will only change the accuracy of the LOSC
frequency (HOSC/x, PLL/y, calibrated RC), but won't change the
semantics.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802013938.29fa18ed%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v8 05/11] rtc: sun6i: Add support for broken-down alarm registers

[Andre Przywara]

On Sun, 25 Jul 2021 08:11:49 +0200
Jernej Škrabec  wrote:

Hi Jernej,

> Dne petek, 23. julij 2021 ob 17:38:32 CEST je Andre Przywara napisal(a):
> > Newer versions of the Allwinner RTC, for instance as found in the H616
> > SoC, not only store the current day as a linear number, but also change
> > the way the alarm is handled: There are now two registers, that
> > explicitly store the wakeup time, in the same format as the current
> > time.
> > 
> > Add support for that variant by writing the requested wakeup time
> > directly into the registers, instead of programming the seconds left, as
> > the old SoCs required.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  drivers/rtc/rtc-sun6i.c | 60 +
> >  1 file changed, 43 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > index a02be8bca6f3..f0ee20bfdccb 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -48,7 +48,8 @@
> >  
> >  /* Alarm 0 (counter) */
> >  #define SUN6I_ALRM_COUNTER 0x0020
> > -#define SUN6I_ALRM_CUR_VAL 0x0024
> > +/* This holds the remaining alarm seconds on older SoCs (current value) */
> > +#define SUN6I_ALRM_COUNTER_HMS 0x0024
> >  #define SUN6I_ALRM_EN  0x0028
> >  #define SUN6I_ALRM_EN_CNT_EN   BIT(0)
> >  #define SUN6I_ALRM_IRQ_EN  0x002c
> > @@ -523,32 +524,57 @@ static int sun6i_rtc_setalarm(struct device *dev,   
> struct rtc_wkalrm *wkalrm)
> > struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
> > struct rtc_time *alrm_tm = >time;
> > struct rtc_time tm_now;
> > -   time64_t time_now, time_set;
> > +   time64_t time_set;
> > +   u32 counter_val, counter_val_hms;
> > int ret;
> >  
> > -   ret = sun6i_rtc_gettime(dev, _now);
> > -   if (ret < 0) {
> > -   dev_err(dev, "Error in getting time\n");
> > -   return -EINVAL;
> > -   }
> > -
> > time_set = rtc_tm_to_time64(alrm_tm);
> > -   time_now = rtc_tm_to_time64(_now);
> > -   if (time_set <= time_now) {
> > -   dev_err(dev, "Date to set in the past\n");
> > -   return -EINVAL;
> > -   }
> >  
> > -   if ((time_set - time_now) > U32_MAX) {
> > -   dev_err(dev, "Date too far in the future\n");
> > -   return -EINVAL;
> > +   if (chip->flags & RTC_LINEAR_DAY) {
> > +   time64_t seconds;
> > +
> > +   /*
> > +* The alarm registers hold the actual alarm time,   
> encoded
> > +* in the same way (linear day + HMS) as the current   
> time.
> > +*/
> > +   counter_val_hms = SUN6I_TIME_SET_SEC_VALUE(alrm_tm-
> >tm_sec)  |
> > +   
> SUN6I_TIME_SET_MIN_VALUE(alrm_tm->tm_min)  |
> > +   
> SUN6I_TIME_SET_HOUR_VALUE(alrm_tm->tm_hour);
> > +   seconds = mktime64(alrm_tm->tm_year + 1900, alrm_tm-
> >tm_mon,
> > +  alrm_tm->tm_mday, 0, 0, 0);  
> 
> While above line should work, it's confusing why you're adding 1900 to years. 
> In my opinion it would be better to use same trick you used in patch 4 - 
> rtc_tm_to_time64() with hours, minutes and seconds set to 0.

IIRC setalarm does not want the time struct to be changed, but this is
OK in settime. But anyway ...

> Or maybe you 
> don't even need to do that, since division by SECS_PER_DAY will round down 
> anyway. In such way you hide RTC internal representation detail which doesn't 
> need to be exposed here.

That is indeed a very clever idea! I changed both settime and setalarm
accordingly now, adding a comment about this.

> 
> Once fixed:
> Reviewed by: Jernej Skrabec 

Many thanks for the reviews!

Cheers,
Andre

> > +   counter_val = div_u64(seconds, SECS_PER_DAY);
> > +   } else {
> > +   /* The alarm register holds the number of seconds left.   
> */
> > +   time64_t time_now;
> > +
> > +   ret = sun6i_rtc_gettime(dev, _now);
> > +   if (ret < 0) {
> > +   dev_err(dev, "Error in getting time\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   time_now = rtc_tm_to_time64(_now);
> > +   if (time_set <= time_now) {
> > +   dev_err(dev

[linux-sunxi] Re: [PATCH v8 00/11] arm64: sunxi: Initial Allwinner H616 SoC support

[Andre Przywara]

On Mon, 26 Jul 2021 16:52:30 +0200
Maxime Ripard  wrote:

Hi,

> On Fri, Jul 23, 2021 at 04:38:27PM +0100, Andre Przywara wrote:
> > Hi,
> > 
> > another try on the basic Allwinner H616 support, now on top of 5.14-rc1.
> > 
> > This time I dropped the USB support from the basic series, to split off
> > the discussion, and simplify the core SoC support. I will post the USB
> > series soon, to be applied on top.
> > I kept the RTC support in, even though this is still under discussion,
> > because this is important to keep future DT files compatible with this
> > kernel.  
> 
> Honestly, I don't want to support something we don't guarantee if it's
> at the expense of making something we do guarantee more complicated.

I don't ask for or provide guarantees, but I think we can at least *try*
to keep this compatible. This version works at the moment, and should
also work with future DTs - within the limits of the current driver, so
only using the RC clock. It allows to later improve the accuracy by
adding better input clocks - and later DT/driver combinations can make
use of this.

> Delaying the clock tree description to sometime in the future will only
> further complicate the probe part of the driver, and there's far too
> many special cases already.

I don't see how this would complicate probing beyond what Allwinner
brought upon us already anyway: no LOSC crystal input in this package
version, but having this pin in some other SoC sharing this die
(according to some BSP) sources. We can't expect a super clean driver
with those HW design choices.

If we really cannot keep the DT compatible, fair enough: that's what
it is (there is no guarantee!), but at least we have tried.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210802013851.13375f0f%40slackpad.fritz.box.

[linux-sunxi] [PATCH] video: Hitachi panel: Drop bogus dependency on CONFIG_VIDEO

[Andre Przywara]

The Hitachi tx18d42vm LCD panel driver is really just initialising the
device, using bitbanged SPI, during operation there is nothing to do.
This makes the driver self contained, so drop the bogus dependency on
the legacy CONFIG_VIDEO.

This avoids the warning when building Chuwi_V7_CW0825_defconfig, since
we switched to DM_VIDEO recently.

Signed-off-by: Andre Przywara 
---
 drivers/video/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index b69ffcae4b2..173b9c99399 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -470,7 +470,6 @@ config VIDEO_LCD_TDO_TL070WSH30
 
 config VIDEO_LCD_HITACHI_TX18D42VM
bool "Hitachi tx18d42vm LVDS LCD panel support"
-   depends on VIDEO
default n
---help---
Support for Hitachi tx18d42vm LVDS LCD panels, these panels have a
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210727144750.27414-1-andre.przywara%40arm.com.

Re: [linux-sunxi] Re: Mainlining Linux Sunxi SoC AW USB

[Andre Przywara]

On Sat, 24 Jul 2021 18:27:53 +0200
Petr Vorel  wrote:

Hi Petr,

> [ Dropping Greg and linux-...@vger.kernel.org ]
> > Peter,  
> 
> > On Sat, 24 Jul 2021 at 15:22, Petr Vorel  wrote:  
> 
> > > Hi Greg,  
> 
> > > > On Sat, Jul 24, 2021 at 03:41:42PM +0200, Petr Vorel wrote:  
> > > > > > Why is this even a driver at all, it looks like you can write a 
> > > > > > small
> > > > > > userspace program using libusb to do everything it does, right?  
> > > > > > What
> > > > > > exactly is this driver needed for?  
> 
> > > > > I'm sorry for not providing more info at the beginning. This is a 
> > > > > driver for
> > > > > host computer (i.e. developers laptop) used by LiveSuit tool [2] to 
> > > > > flash Images
> > > > > to the NAND of Allwinner devices. LiveSuit itself [3] is 
> > > > > unfortunately provided
> > > > > only in binary form. The only open source code with GPL v2 license is 
> > > > > awusb
> > > > > driver. Thus I thought I could ease my life with upstreaming at least 
> > > > > the
> > > > > kernel driver. But maybe it's not a good idea. I'm using LiveSuit for 
> > > > > flashing
> > > > > Allwinner A31, but it requires quite old distro due libqtgui4. Maybe 
> > > > > sunxi folks
> > > > > use something newer nowadays, but I haven't found anything in their 
> > > > > wiki.  
> 
> > > > Ah, that's not going to be good then.  Really, this doesn't seem to need
> > > > to be a driver at all, and the ioctls are really strange so we would
> > > > need to change them anyway before it could be merged.  But with no
> > > > access to userspace code, that will be quite difficult, so I would push
> > > > back on allwinner and have them work on resolving this.  
> > > Understand, it makes sense. Thanks for your time!  
> 
> > > @Sunxi community: am I missing something? Using LiveSuit with old distro 
> > > chroot
> > > and Xephyr with out-of-tree module isn't fun :(.  
> 
> > Suggest you take a look at sunxi-tools - specifically the sunxi-fel
> > tool. This is a libusb-based userland tool to talk to these devices.
> > I'm not sure if it supports flashing to nand on A31 - never tried it -
> > but have used it to flash to eMMC and SPI flash on their other chips.  
> Thanks for a tip. Looking into sources it does not look like sunxi-fel 
> supports
> NAND.
> 
> Also from Debian wiki [1] (which describes bootable SD Card) it looks like 
> only
> old Allwinner u-boot supported access to NAND, thus I'd be surprised if
> sunxi-tools supported it. sunxi-bootinfo does not implement NAND,
> sunxi-nand-image-builder (which is not built by default) creates raw NAND
> images, but now word about flashing.
> 
> I wonder why NAND is (probably) not supported by sunxi? Lack of documentation?

Pure NAND is getting rarer these days, on modern boards we see mostly
eMMC now (maybe SPI NAND). So NAND is only a concern for older SoCs.

There is (limited) NAND support for mainline U-Boot on the C.H.I.P.
boards[1], which use an A13 (derivative). But reliable operation is
only possible with SLC NAND, which means only on the Chip Pro board,
IIUC. Most boards will probably utilise MLC (or worse) NAND these days,
where effects like write and read disturb make operation more
complicated. Maxime has some stories to tell about this.
So it would be first good to know if you have SLC NAND or not.

Because of this direct support for NAND in the tools is understandably
"limited" (as in: non-existent). Except for SPI NOR flash there is no
"direct" flashing support (for eMMC) in the tools anyway, it just relies
on U-Boot support.
How this works is that you use sunxi-fel to upload a (mainline) U-Boot
binary directly into DRAM, and launch that. Then you can use the full
functionality of U-Boot to load your image. Most popular for NAND
support seems to be U-Boot's Android Fastboot implementation over a USB
gadget device, so you can use the off-the-shelf fastboot tool on your
host computer to flash the NAND. Other possibilities would be to use
USB host support or TFTP to first load an image into DRAM, then use
U-Boot commands to write that into the NAND flash.
To my knowledge NAND flash in U-Boot *only* works on the A13/R8/GR8
chips with SLC NAND, and is only enabled and tested on the Chip boards.
Every other combination would require some work; much more work the
farther you move from there (other SoC, MLC, ...).

Cheers,
Andre

[1] https://linux-sunxi.org/NextThingCo_CHIP

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210724180432.4423b9e3%40slackpad.fritz.box.

[linux-sunxi] [PATCH v8 11/11] arm64: dts: allwinner: h616: Add X96 Mate TV box support

[Andre Przywara]

The X96 Mate is an Allwinner H616 based TV box, featuring:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 2GiB/4GiB RAM (fully usable!)
  - 16/32/64GiB eMMC
  - 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
  - Unsupported Allwinner WiFi chip
  - 2 x USB 2.0 host ports
  - HDMI port
  - IR receiver
  - 5V/2A DC power supply via barrel plug

For more information see: https://linux-sunxi.org/X96_Mate

Add a basic devicetree for it, with SD card and eMMC working, as
well as serial and the essential peripherals, like the AXP PMIC.

This DT is somewhat minimal, and should work on many other similar TV
boxes with the Allwinner H616 chip.

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/Makefile|   1 +
 .../dts/allwinner/sun50i-h616-x96-mate.dts| 178 ++
 2 files changed, 179 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 62f8d43cf84d..14053c566601 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -38,3 +38,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
new file mode 100644
index ..6334f4e20fd0
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2021 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "X96 Mate";
+   compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc5v: vcc5v {
+   /* board wide 5V supply directly from the DC input */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;  /* PF6 */
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   vqmmc-supply = <_bldo1>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp305: pmic@745 {
+   compatible = "x-powers,axp305", "x-powers,axp805",
+"x-powers,axp806";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #address-cells = <0>;
+   reg = <0x745>;
+
+   x-powers,self-working-mode;
+   vina-supply = <_vcc5v>;
+   vinb-supply = <_vcc5v>;
+   vinc-supply = <_vcc5v>;
+   vind-supply = <_vcc5v>;
+   vine-supply = <_vcc5v>;
+   aldoin-supply = <_vcc5v>;
+   bldoin-supply = <_vcc5v>;
+   cldoin-supply = <_vcc5v>;
+
+   regulators {
+   reg_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-sys";
+   };
+
+   /* Enabled by the Android BSP */
+   reg_aldo2: aldo2 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc3v3-ext";
+   status = "disabled";
+   };
+
+   /* Enabled by the Android BSP */
+   reg_aldo3: aldo3 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc3v3-ext2";
+   status = &

[linux-sunxi] [PATCH v8 10/11] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support

[Andre Przywara]

The OrangePi Zero 2 is a development board with the new H616 SoC. It
comes with the following features:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 512MiB/1GiB DDR3 DRAM
  - AXP305 PMIC
  - Raspberry-Pi-1 compatible GPIO header
  - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
  - 1 USB 2.0 host port
  - 1 USB 2.0 type C port (power supply + OTG)
  - MicroSD slot
  - on-board 2MiB bootable SPI NOR flash
  - 1Gbps Ethernet port (via RTL8211F PHY)
  - micro-HDMI port
  - unsupported Allwinner WiFi/BT chip

For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/Makefile|   1 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 204 ++
 2 files changed, 205 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index a96d9d2d8dd8..62f8d43cf84d 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -37,3 +37,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
new file mode 100644
index ..0132c06be96a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "OrangePi Zero2";
+   compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
+
+   aliases {
+   ethernet0 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led-0 {
+   function = LED_FUNCTION_POWER;
+   color = ;
+   gpios = < 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+   default-state = "on";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   gpios = < 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+   };
+   };
+
+   reg_vcc5v: vcc5v {
+   /* board wide 5V supply directly from the USB-C socket */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-mode = "rgmii";
+   phy-handle = <_rgmii_phy>;
+   phy-supply = <_dcdce>;
+   allwinner,rx-delay-ps = <3100>;
+   allwinner,tx-delay-ps = <700>;
+   status = "okay";
+};
+
+ {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;  /* PF6 */
+   bus-width = <4>;
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp305: pmic@745 {
+   compatible = "x-powers,axp305", "x-powers,axp805",
+"x-powers,axp806";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #address-cells = <0>;
+   reg = <0x745>;
+
+   x-powers,self-working-mode;
+   vina-supply = <_vcc5v>;
+   vinb-supply = <_vcc5v>;
+   vinc-supply = <_vcc5v>;
+   vind-supply = <_vcc5v>;
+   vine-supply = <_vcc5v>;
+   aldoin-supply = <_vcc5v>;
+   bldoin-supply = <_vcc5v>;
+   cldoin-supply = <_vcc5v>;
+
+   regulators {
+   reg_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-sys";
+   

[linux-sunxi] [PATCH v8 09/11] dt-bindings: arm: sunxi: Add two H616 board compatible strings

[Andre Przywara]

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml 
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 889128acf49a..1c557a736d86 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -848,6 +848,11 @@ properties:
   - const: yones-toptech,bs1078-v2
   - const: allwinner,sun6i-a31s
 
+  - description: X96 Mate TV box
+items:
+  - const: hechuang,x96-mate
+  - const: allwinner,sun50i-h616
+
   - description: Xunlong OrangePi
 items:
   - const: xunlong,orangepi
@@ -948,4 +953,9 @@ properties:
   - const: xunlong,orangepi-zero-plus2-h3
   - const: allwinner,sun8i-h3
 
+  - description: Xunlong OrangePi Zero 2
+items:
+  - const: xunlong,orangepi-zero2
+  - const: allwinner,sun50i-h616
+
 additionalProperties: true
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723153838.6785-10-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v8 08/11] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Andre Przywara]

This (relatively) new SoC is similar to the H6, but drops the (broken)
PCIe support and the USB 3.0 controller. It also gets the management
controller removed, which in turn removes *some*, but not all of the
devices formerly dedicated to the ARISC (CPUS).
And while there is still the extra sunxi interrupt controller, the
package lacks the corresponding NMI pin, so no interrupts for the PMIC.

The reserved memory node is actually handled by Trusted Firmware now,
but U-Boot fails to propagate this to a separately loaded DTB, so we
keep it in here for now, until U-Boot learns to do this properly.

Signed-off-by: Andre Przywara 
---
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 575 ++
 1 file changed, 575 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
new file mode 100644
index ..6a15ff2e7ebf
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -0,0 +1,575 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Arm Ltd.
+// based on the H6 dtsi, which is:
+//   Copyright (C) 2017 Icenowy Zheng 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <0>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <1>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <2>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu3: cpu@3 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <3>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+   };
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* 512KiB reserved for ARM Trusted Firmware (BL31) */
+   secmon_reserved: secmon@4000 {
+   reg = <0x0 0x4000 0x0 0x8>;
+   no-map;
+   };
+   };
+
+   osc24M: osc24M-clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ,
+,
+,
+;
+   interrupt-affinity = <>, <>, <>, <>;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   arm,no-tick-in-suspend;
+   interrupts = ,
+,
+,
+;
+   };
+
+   soc@0 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x0 0x4000>;
+
+   syscon: syscon@300 {
+   compatible = "allwinner,sun50i-h616-system-control";
+   reg = <0x0300 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   sram_c: sram@28000 {
+   compatible = "mmio-sram";
+   reg = <0x00028000 0x3>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x00028000 0x3&g

[linux-sunxi] [PATCH v8 07/11] rtc: sun6i: Add Allwinner H616 support

[Andre Przywara]

The H616 RTC changes its day storage to the newly introduced linear day
scheme, so pair the new compatible string with this feature flag.
The clock part is missing an external 32768 Hz oscillator input pin,
for future expansion we must thus ignore any provided clock for now.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index ef2b1027ce4c..db65273c6f59 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -392,6 +392,23 @@ static void __init sun50i_h6_rtc_clk_init(struct 
device_node *node)
 CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
  sun50i_h6_rtc_clk_init);
 
+static const struct sun6i_rtc_clk_data sun50i_h616_rtc_data = {
+   .rc_osc_rate = 1600,
+   .fixed_prescaler = 32,
+   .has_prescaler = 1,
+   .has_out_clk = 1,
+   .export_iosc = 1,
+   .no_ext_losc = 1,
+};
+
+static void __init sun50i_h616_rtc_clk_init(struct device_node *node)
+{
+   sun6i_rtc_clk_init(node, _h616_rtc_data);
+}
+
+CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
+ sun50i_h616_rtc_clk_init);
+
 /*
  * The R40 user manual is self-conflicting on whether the prescaler is
  * fixed or configurable. The clock diagram shows it as fixed, but there
@@ -799,6 +816,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
{ .compatible = "allwinner,sun8i-v3-rtc" },
{ .compatible = "allwinner,sun50i-h5-rtc" },
{ .compatible = "allwinner,sun50i-h6-rtc" },
+   { .compatible = "allwinner,sun50i-h616-rtc",
+   .data = (void *)RTC_LINEAR_DAY },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723153838.6785-8-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v8 06/11] rtc: sun6i: Add support for RTCs without external LOSCs

[Andre Przywara]

Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack
a pin for an external 32768 Hz oscillator. As a consequence, this LOSC
can't be selected as the RTC clock source, and we must rely on the
internal RC oscillator.
To allow additions of clocks to the RTC node, add a feature bit to ignore
any provided clocks for now (the current code would think this is the
external LOSC). Later DTs and code can then for instance add the PLL
based clock input, and older kernel won't get confused.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index f0ee20bfdccb..ef2b1027ce4c 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -134,6 +134,7 @@ struct sun6i_rtc_clk_data {
unsigned int export_iosc : 1;
unsigned int has_losc_en : 1;
unsigned int has_auto_swt : 1;
+   unsigned int no_ext_losc : 1;
 };
 
 #define RTC_LINEAR_DAY BIT(0)
@@ -256,7 +257,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node,
}
 
/* Switch to the external, more precise, oscillator, if present */
-   if (of_get_property(node, "clocks", NULL)) {
+   if (!rtc->data->no_ext_losc && of_get_property(node, "clocks", NULL)) {
reg |= SUN6I_LOSC_CTRL_EXT_OSC;
if (rtc->data->has_losc_en)
reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
@@ -282,14 +283,19 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node,
}
 
parents[0] = clk_hw_get_name(rtc->int_osc);
-   /* If there is no external oscillator, this will be NULL and ... */
-   parents[1] = of_clk_get_parent_name(node, 0);
+   if (rtc->data->no_ext_losc) {
+   parents[1] = NULL;
+   init.num_parents = 1;
+   } else {
+   /* If there is no external oscillator, this will be NULL and */
+   parents[1] = of_clk_get_parent_name(node, 0);
+   /* ... number of clock parents will be 1. */
+   init.num_parents = of_clk_get_parent_count(node) + 1;
+   }
 
rtc->hw.init = 
 
init.parent_names = parents;
-   /* ... number of clock parents will be 1. */
-   init.num_parents = of_clk_get_parent_count(node) + 1;
of_property_read_string_index(node, "clock-output-names", 0,
  );
 
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723153838.6785-7-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v8 05/11] rtc: sun6i: Add support for broken-down alarm registers

[Andre Przywara]

Newer versions of the Allwinner RTC, for instance as found in the H616
SoC, not only store the current day as a linear number, but also change
the way the alarm is handled: There are now two registers, that
explicitly store the wakeup time, in the same format as the current
time.

Add support for that variant by writing the requested wakeup time
directly into the registers, instead of programming the seconds left, as
the old SoCs required.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 60 +
 1 file changed, 43 insertions(+), 17 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index a02be8bca6f3..f0ee20bfdccb 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -48,7 +48,8 @@
 
 /* Alarm 0 (counter) */
 #define SUN6I_ALRM_COUNTER 0x0020
-#define SUN6I_ALRM_CUR_VAL 0x0024
+/* This holds the remaining alarm seconds on older SoCs (current value) */
+#define SUN6I_ALRM_COUNTER_HMS 0x0024
 #define SUN6I_ALRM_EN  0x0028
 #define SUN6I_ALRM_EN_CNT_EN   BIT(0)
 #define SUN6I_ALRM_IRQ_EN  0x002c
@@ -523,32 +524,57 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
struct rtc_time *alrm_tm = >time;
struct rtc_time tm_now;
-   time64_t time_now, time_set;
+   time64_t time_set;
+   u32 counter_val, counter_val_hms;
int ret;
 
-   ret = sun6i_rtc_gettime(dev, _now);
-   if (ret < 0) {
-   dev_err(dev, "Error in getting time\n");
-   return -EINVAL;
-   }
-
time_set = rtc_tm_to_time64(alrm_tm);
-   time_now = rtc_tm_to_time64(_now);
-   if (time_set <= time_now) {
-   dev_err(dev, "Date to set in the past\n");
-   return -EINVAL;
-   }
 
-   if ((time_set - time_now) > U32_MAX) {
-   dev_err(dev, "Date too far in the future\n");
-   return -EINVAL;
+   if (chip->flags & RTC_LINEAR_DAY) {
+   time64_t seconds;
+
+   /*
+* The alarm registers hold the actual alarm time, encoded
+* in the same way (linear day + HMS) as the current time.
+*/
+   counter_val_hms = SUN6I_TIME_SET_SEC_VALUE(alrm_tm->tm_sec)  |
+ SUN6I_TIME_SET_MIN_VALUE(alrm_tm->tm_min)  |
+ SUN6I_TIME_SET_HOUR_VALUE(alrm_tm->tm_hour);
+   seconds = mktime64(alrm_tm->tm_year + 1900, alrm_tm->tm_mon,
+  alrm_tm->tm_mday, 0, 0, 0);
+   counter_val = div_u64(seconds, SECS_PER_DAY);
+   } else {
+   /* The alarm register holds the number of seconds left. */
+   time64_t time_now;
+
+   ret = sun6i_rtc_gettime(dev, _now);
+   if (ret < 0) {
+   dev_err(dev, "Error in getting time\n");
+   return -EINVAL;
+   }
+
+   time_now = rtc_tm_to_time64(_now);
+   if (time_set <= time_now) {
+   dev_err(dev, "Date to set in the past\n");
+   return -EINVAL;
+   }
+   if ((time_set - time_now) > U32_MAX) {
+   dev_err(dev, "Date too far in the future\n");
+   return -EINVAL;
+   }
+
+   counter_val = time_set - time_now;
}
 
sun6i_rtc_setaie(0, chip);
writel(0, chip->base + SUN6I_ALRM_COUNTER);
+   if (chip->flags & RTC_LINEAR_DAY)
+   writel(0, chip->base + SUN6I_ALRM_COUNTER_HMS);
usleep_range(100, 300);
 
-   writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
+   writel(counter_val, chip->base + SUN6I_ALRM_COUNTER);
+   if (chip->flags & RTC_LINEAR_DAY)
+   writel(counter_val_hms, chip->base + SUN6I_ALRM_COUNTER_HMS);
chip->alarm = time_set;
 
sun6i_rtc_setaie(wkalrm->enabled, chip);
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723153838.6785-6-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v8 04/11] rtc: sun6i: Add support for linear day storage

[Andre Przywara]

Newer versions of the Allwinner RTC, as for instance found in the H616
SoC, no longer store a broken-down day/month/year representation in the
RTC_DAY_REG, but just a linear day number.
The user manual does not give any indication about the expected epoch
time of this day count, but the BSP kernel uses the UNIX epoch, which
allows easy support due to existing conversion functions in the kernel.

Allow tagging a compatible string with a flag, and use that to mark
those new RTCs. Then convert between a UNIX day number (converted into
seconds) and the broken-down day representation using mktime64() and
time64_to_tm() in the set_time/get_time functions.

That enables support for the RTC in those new chips.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 66 +++--
 1 file changed, 44 insertions(+), 22 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index c551ebf0ac00..a02be8bca6f3 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -110,6 +110,8 @@
 #define SUN6I_YEAR_MIN 1970
 #define SUN6I_YEAR_OFF (SUN6I_YEAR_MIN - 1900)
 
+#define SECS_PER_DAY   (24 * 3600ULL)
+
 /*
  * There are other differences between models, including:
  *
@@ -133,12 +135,15 @@ struct sun6i_rtc_clk_data {
unsigned int has_auto_swt : 1;
 };
 
+#define RTC_LINEAR_DAY BIT(0)
+
 struct sun6i_rtc_dev {
struct rtc_device *rtc;
const struct sun6i_rtc_clk_data *data;
void __iomem *base;
int irq;
time64_t alarm;
+   unsigned long flags;
 
struct clk_hw hw;
struct clk_hw *int_osc;
@@ -467,22 +472,30 @@ static int sun6i_rtc_gettime(struct device *dev, struct 
rtc_time *rtc_tm)
} while ((date != readl(chip->base + SUN6I_RTC_YMD)) ||
 (time != readl(chip->base + SUN6I_RTC_HMS)));
 
+   if (chip->flags & RTC_LINEAR_DAY) {
+   /*
+* Newer chips store a linear day number, the manual
+* does not mandate any epoch base. The BSP driver uses
+* the UNIX epoch, let's just copy that, as it's the
+* easiest anyway.
+*/
+   rtc_time64_to_tm((date & 0x) * SECS_PER_DAY, rtc_tm);
+   } else {
+   rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
+   rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date) - 1;
+   rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
+
+   /*
+* switch from (data_year->min)-relative offset to
+* a (1900)-relative one
+*/
+   rtc_tm->tm_year += SUN6I_YEAR_OFF;
+   }
+
rtc_tm->tm_sec  = SUN6I_TIME_GET_SEC_VALUE(time);
rtc_tm->tm_min  = SUN6I_TIME_GET_MIN_VALUE(time);
rtc_tm->tm_hour = SUN6I_TIME_GET_HOUR_VALUE(time);
 
-   rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
-   rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date);
-   rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
-
-   rtc_tm->tm_mon  -= 1;
-
-   /*
-* switch from (data_year->min)-relative offset to
-* a (1900)-relative one
-*/
-   rtc_tm->tm_year += SUN6I_YEAR_OFF;
-
return 0;
 }
 
@@ -567,20 +580,27 @@ static int sun6i_rtc_settime(struct device *dev, struct 
rtc_time *rtc_tm)
u32 date = 0;
u32 time = 0;
 
-   rtc_tm->tm_year -= SUN6I_YEAR_OFF;
-   rtc_tm->tm_mon += 1;
-
-   date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
-   SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
-   SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
-
-   if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
-   date |= SUN6I_LEAP_SET_VALUE(1);
-
time = SUN6I_TIME_SET_SEC_VALUE(rtc_tm->tm_sec)  |
SUN6I_TIME_SET_MIN_VALUE(rtc_tm->tm_min)  |
SUN6I_TIME_SET_HOUR_VALUE(rtc_tm->tm_hour);
 
+   if (chip->flags & RTC_LINEAR_DAY) {
+   rtc_tm->tm_sec = 0;
+   rtc_tm->tm_min = 0;
+   rtc_tm->tm_hour = 0;
+   date = div_u64(rtc_tm_to_time64(rtc_tm), SECS_PER_DAY);
+   } else {
+   rtc_tm->tm_year -= SUN6I_YEAR_OFF;
+   rtc_tm->tm_mon += 1;
+
+   date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
+   SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
+   SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
+
+   if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
+   date |= SUN6I_LEAP_SET_VALUE(1);
+   }
+
/* Check whether registers are writable */
if (sun6i_rtc_wait(chip, SUN6I_LOSC_CTRL,
   SUN6I_LOSC_CTRL_ACC_MASK, 50)) {
@@ -674,6 +694,

[linux-sunxi] [PATCH v8 03/11] rtc: sun6i: Fix time overflow handling

[Andre Przywara]

Using "unsigned long" for UNIX timestamps is never a good idea, and
comparing the value of such a variable against U32_MAX does not do
anything useful on 32-bit systems.

Use the proper time64_t type when dealing with timestamps, and avoid
cutting down the time range unnecessarily. This also fixes the flawed
check for the alarm time being too far into the future.

The check for this condition is actually somewhat theoretical, as the
RTC counts till 2033 only anyways, and 2^32 seconds from now is not
before the year 2157 - at which point I hope nobody will be using this
hardware anymore.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index adec1b14a8de..c551ebf0ac00 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -138,7 +138,7 @@ struct sun6i_rtc_dev {
const struct sun6i_rtc_clk_data *data;
void __iomem *base;
int irq;
-   unsigned long alarm;
+   time64_t alarm;
 
struct clk_hw hw;
struct clk_hw *int_osc;
@@ -510,10 +510,8 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
struct rtc_time *alrm_tm = >time;
struct rtc_time tm_now;
-   unsigned long time_now = 0;
-   unsigned long time_set = 0;
-   unsigned long time_gap = 0;
-   int ret = 0;
+   time64_t time_now, time_set;
+   int ret;
 
ret = sun6i_rtc_gettime(dev, _now);
if (ret < 0) {
@@ -528,9 +526,7 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
return -EINVAL;
}
 
-   time_gap = time_set - time_now;
-
-   if (time_gap > U32_MAX) {
+   if ((time_set - time_now) > U32_MAX) {
dev_err(dev, "Date too far in the future\n");
return -EINVAL;
}
@@ -539,7 +535,7 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
writel(0, chip->base + SUN6I_ALRM_COUNTER);
usleep_range(100, 300);
 
-   writel(time_gap, chip->base + SUN6I_ALRM_COUNTER);
+   writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
chip->alarm = time_set;
 
sun6i_rtc_setaie(wkalrm->enabled, chip);
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723153838.6785-4-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing RTC binding.
The actual RTC part of the device uses a different day/month/year
storage scheme, so it's not compatible with the previous devices.
Also the clock part is quite different, as there is no external 32K LOSC
oscillator input.

Signed-off-by: Andre Przywara 
---
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml  | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index beeb90e55727..d8a6500e5840 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -26,6 +26,7 @@ properties:
   - const: allwinner,sun50i-a64-rtc
   - const: allwinner,sun8i-h3-rtc
   - const: allwinner,sun50i-h6-rtc
+  - const: allwinner,sun50i-h616-rtc
 
   reg:
 maxItems: 1
@@ -104,6 +105,19 @@ allOf:
   minItems: 3
   maxItems: 3
 
+  - if:
+  properties:
+compatible:
+  contains:
+const: allwinner,sun50i-h616-rtc
+
+then:
+  properties:
+clock-output-names:
+  minItems: 3
+  maxItems: 3
+clocks: false
+
   - if:
   properties:
 compatible:
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723153838.6785-3-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v8 01/11] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Andre Przywara]

The AXP305 PMIC used on many boards with the H616 SoC seems to be fully
compatible to the AXP805 PMIC, so add the proper chain of compatible
strings.

Also at least on one board (Orangepi Zero2) there is no interrupt line
connected to the CPU, so make the "interrupts" property optional.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 4991a6415796..2b53dcc0ea61 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -26,10 +26,10 @@ Required properties:
 * "x-powers,axp803"
 * "x-powers,axp806"
 * "x-powers,axp805", "x-powers,axp806"
+* "x-powers,axp305", "x-powers,axp805", "x-powers,axp806"
 * "x-powers,axp809"
 * "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
-- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
 - #interrupt-cells: Should be set to 1
 
@@ -43,6 +43,7 @@ more information:
AXP20x/LDO3: software-based implementation
 
 Optional properties:
+- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
  AXP152/20X: range:  750-1875, Default: 1.5 MHz
  AXP22X/8XX: range: 1800-4050, Default: 3   MHz
-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723153838.6785-2-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v8 00/11] arm64: sunxi: Initial Allwinner H616 SoC support

[Andre Przywara]

k map to cover undocumented GPIO bank IRQs
- use differing h_i2s0 pin output names
- r-ccu: fix number of used clocks
- ccu: remove PLL-PERIPHy(4X)
- ccu: fix gpu1 divider range
- ccu: fix usb-phy3 parent
- ccu: add missing TV clocks
- ccu: rework to CLK_OF_DECLARE style
- ccu: enable output bit for PLL clocks
- ccu: renumber clocks
- .dtsi: drop sun50i-a64-system-control fallback
- .dtsi: drop unknown SRAM regions
- .dtsi: add more (undocumented) GPIO interrupts
- .dtsi: fix I2C3 pin names
- .dtsi: use a100-emmc fallback for MMC2
- .dtsi: add second EMAC controller
- .dtsi: use H3 MUSB controller fallback
- .dtsi: fix frame size for USB PHY PMU registers
- .dtsi: add USB0 PHY references
- .dtsi: fix IR controller clock source
- .dts: fix LED naming and swap pins
- .dts: use 5V supply parent for USB supply
- .dts: drop dummy IRQ for AXP
- .dts: enable 3V3 header pin power rail
- .dts: add SPI flash node
- .dts: make USB-C port peripheral only
- add IRQ-less AXP support
- add two patches to support more than one EMAC clock
- add patch to rework and extend USB PHY support
- add DT binding documentation patches

Andre Przywara (11):
  dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  dt-bindings: rtc: sun6i: Add H616 compatible string
  rtc: sun6i: Fix time overflow handling
  rtc: sun6i: Add support for linear day storage
  rtc: sun6i: Add support for broken-down alarm registers
  rtc: sun6i: Add support for RTCs without external LOSCs
  rtc: sun6i: Add Allwinner H616 support
  arm64: dts: allwinner: Add Allwinner H616 .dtsi file
  dt-bindings: arm: sunxi: Add two H616 board compatible strings
  arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
  arm64: dts: allwinner: h616: Add X96 Mate TV box support

 .../devicetree/bindings/arm/sunxi.yaml|  10 +
 .../devicetree/bindings/mfd/axp20x.txt|   3 +-
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml |  14 +
 arch/arm64/boot/dts/allwinner/Makefile|   2 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 204 +++
 .../dts/allwinner/sun50i-h616-x96-mate.dts| 178 ++
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 575 ++
 drivers/rtc/rtc-sun6i.c   | 169 +++--
 8 files changed, 1104 insertions(+), 51 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi

-- 
2.17.6

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723153838.6785-1-andre.przywara%40arm.com.

[linux-sunxi] Re: [PATCH v7 06/19] rtc: sun6i: Add support for RTCs without external LOSCs

[Andre Przywara]

On Wed, 16 Jun 2021 11:14:31 +0200
Maxime Ripard  wrote:

Hi Maxime,

> On Tue, Jun 15, 2021 at 12:06:23PM +0100, Andre Przywara wrote:
> > Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack
> > a pin for an external 32768 Hz oscillator. As a consequence, this LOSC
> > can't be selected as the RTC clock source, and we must rely on the
> > internal RC oscillator.
> > To allow additions of clocks to the RTC node, add a feature bit to ignore
> > any provided clocks for now (the current code would think this is the
> > external LOSC). Later DTs and code can then for instance add the PLL
> > based clock input, and older kernel won't get confused.
> > 
> > Signed-off-by: Andre Przywara   
> 
> Honestly, I don't really know if it's worth it at this point.
> 
> If we sums this up:
> 
>  - The RTC has 2 features that we use, mostly centered around 2
>registers set plus a global one
> 
>  - Those 2 features are programmed in a completely different way
> 
>  - Even the common part is different, given the discussion around the
>clocks that we have.
> 
> What is there to share in that driver aside from the probe, and maybe
> the interrupt handling? Instead of complicating this further with more
> special case that you were (rightfully) complaining about, shouldn't we
> just acknowledge the fact that it's a completely separate design and
> should be treated as such, with a completely separate driver?

So I had a look, and I don't think it justifies a separate driver:
- Indeed it looks like the core functionality is different, but there
  are a lot of commonalities, with all the RTC and driver boilerplate,
  register offsets, and also the special access pattern (rtc_wait and
  rtc_setaie).
- The actual difference is really in the way the *date* is stored
  (the time is still in 24h H/M/S format), and the missing LOSC input
  clock - which is already optional for existing devices. The two
  patches just make this obvious, by using if() statements at the parts
  where they differ.

So we would end up with possibly some shared .c file, and two driver
front-end files, which I am not sure is really worth it.

Next I thought about providing separate rtc_class_ops, but even they
share a lot of code, so they would be possibly be calling a shared
function each. I don't think that is really better.

If you dislike the rather large if/else branches in the previous two
patches, I could move that out into separate functions, but I feel this
is more code, for no real benefit.

So for now I am tempted to keep it shared. I think Samuel had ideas for
bigger changes in the clock part, at which point we could revisit this
decision - for instance keep the RTC part (still quite similar) mostly
in a shared file, while modelling the clocks in separate files - in a
more "common clock" style for the new SoCs.

Feel free to disagree, but when I tried to actually separate the drivers
it just felt wrong.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210723001721.0bb02cf2%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v7 14/19] phy: sun4i-usb: Introduce port2 SIDDQ quirk

[Andre Przywara]

On Mon, 21 Jun 2021 10:06:31 +0530
Vinod Koul  wrote:

Hi Vinod,

thanks for having a look!

> On 15-06-21, 12:06, Andre Przywara wrote:
> > At least the Allwinner H616 SoC requires a weird quirk to make most
> > USB PHYs work: Only port2 works out of the box, but all other ports
> > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > the PMU PHY control register needs to be cleared. For this register to
> > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask 
> > 
> > Instead of disguising this as some generic feature, do exactly that
> > in our PHY init:
> > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > this one special clock, and clear the SIDDQ bit. We can pull in the
> > other required clocks via the DT.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  drivers/phy/allwinner/phy-sun4i-usb.c | 59 +++
> >  1 file changed, 59 insertions(+)
> > 
> > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> > b/drivers/phy/allwinner/phy-sun4i-usb.c
> > index 126ef74d013c..316ef5fca831 100644
> > --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> > @@ -120,6 +120,7 @@ struct sun4i_usb_phy_cfg {
> > u8 phyctl_offset;
> > bool dedicated_clocks;
> > bool phy0_dual_route;
> > +   bool needs_phy2_siddq;
> > int missing_phys;
> >  };
> >  
> > @@ -289,6 +290,50 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> > return ret;
> > }
> >  
> > +   /* Some PHYs on some SoCs need the help of PHY2 to work. */
> > +   if (data->cfg->needs_phy2_siddq && phy->index != 2) {
> > +   struct sun4i_usb_phy *phy2 = >phys[2];
> > +
> > +   ret = clk_prepare_enable(phy2->clk);
> > +   if (ret) {
> > +   reset_control_assert(phy->reset);
> > +   clk_disable_unprepare(phy->clk2);
> > +   clk_disable_unprepare(phy->clk);
> > +   return ret;
> > +   }
> > +
> > +   ret = reset_control_deassert(phy2->reset);
> > +   if (ret) {
> > +   clk_disable_unprepare(phy2->clk);
> > +   reset_control_assert(phy->reset);
> > +   clk_disable_unprepare(phy->clk2);
> > +   clk_disable_unprepare(phy->clk);
> > +   return ret;
> > +   }  
> 
> no delay between deassert and assert... ?

Mmmh, not sure what you are after. This is just the clean-up path,
when the deassert failed, and we tear down what was brought up before.
And the assert is not for the same reset line that we tried to
deassert anyway, if that is what you mean?
Or do I miss something here?

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210621101436.3d1ce911%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v7 04/19] rtc: sun6i: Add support for linear day storage

[Andre Przywara]

On Fri, 18 Jun 2021 04:07:55 +0800
kernel test robot  wrote:

> Hi Andre,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on sunxi/sunxi/for-next]
> [also build test ERROR on v5.13-rc6]
> [cannot apply to lee-mfd/for-mfd-next mripard/sunxi/for-next next-20210617]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:
> https://github.com/0day-ci/linux/commits/Andre-Przywara/arm64-sunxi-Initial-Allwinner-H616-SoC-support/20210617-022925
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git 
> sunxi/for-next
> config: powerpc64-randconfig-c004-20210617 (attached as .config)
> compiler: powerpc-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://github.com/0day-ci/linux/commit/b0bd86f86f42049c6e19e25460b042fca7a7901d
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Andre-Przywara/arm64-sunxi-Initial-Allwinner-H616-SoC-support/20210617-022925
> git checkout b0bd86f86f42049c6e19e25460b042fca7a7901d
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
> ARCH=powerpc64 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
>powerpc-linux-ld: drivers/rtc/rtc-sun6i.o: in function `sun6i_rtc_settime':
> >> rtc-sun6i.c:(.text.sun6i_rtc_settime+0x218): undefined reference to 
> >> `__udivdi3'  

For the records, I am using div_u64() now, which compiles fine in both
ARM and arm64.
Also found some subtle bugs with the types used in that function on the
way.

Thanks dear bot for also caring about those "lesser" architectures ;-)

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210618164320.2aa0ec2d%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v7 03/19] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Tue, 15 Jun 2021 17:35:02 -0600
Rob Herring  wrote:

Hi,

> On Tue, Jun 15, 2021 at 12:06:20PM +0100, Andre Przywara wrote:
> > Add the obvious compatible name to the existing RTC binding.
> > The actual RTC part of the device uses a different day/month/year
> > storage scheme, so it's not compatible with the previous devices.
> > Also the clock part is quite different, as there is no external 32K LOSC
> > oscillator input.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 15 +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > index b1b0ee769b71..2c3fd72e17ee 100644
> > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > @@ -26,6 +26,7 @@ properties:
> >- const: allwinner,sun50i-a64-rtc
> >- const: allwinner,sun8i-h3-rtc
> >- const: allwinner,sun50i-h6-rtc
> > +  - const: allwinner,sun50i-h616-rtc
> >  
> >reg:
> >  maxItems: 1
> > @@ -105,6 +106,20 @@ allOf:
> >minItems: 3
> >maxItems: 3
> >  
> > +  - if:
> > +  properties:
> > +compatible:
> > +  contains:
> > +const: allwinner,sun50i-h616-rtc
> > +
> > +then:
> > +  properties:
> > +clock-output-names:
> > +  minItems: 3
> > +  maxItems: 3
> > +clocks:
> > +  maxItems: 0  
> 
> clocks: false
> 
> if forbidding clocks is what you want.

Yes, thanks for the hint!

Cheers,
Andre

> 
> > +
> >- if:
> >properties:
> >  compatible:
> > -- 
> > 2.17.5  
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210616155958.7c7a6a33%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v7 01/19] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Andre Przywara]

On Tue, 15 Jun 2021 17:33:45 -0600
Rob Herring  wrote:

> On Tue, 15 Jun 2021 12:06:18 +0100, Andre Przywara wrote:
> > The AXP305 PMIC used on many boards with the H616 SoC seems to be fully
> > compatible to the AXP805 PMIC, so add the proper chain of compatible
> > strings.
> > 
> > Also at least on one board (Orangepi Zero2) there is no interrupt line
> > connected to the CPU, so make the "interrupts" property optional.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >   
> 
> 
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
> 
> If a tag was not added on purpose, please state why and what changed.

Argh, sorry, I was still wondering whether I should try the YAML
conversion, so didn't apply your tag right away - and then missed it
when I decided to postpone this. Plus I actually fixed some blunder
(copy typo in the compatible), and I mostly drop tags upon
changes.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210616155715.7d8347c5%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Wed, 16 Jun 2021 11:07:00 +0200
Maxime Ripard  wrote:

Hi,

> On Tue, Jun 15, 2021 at 01:24:40PM +0100, Andre Przywara wrote:
> > > On 6/7/21 7:59 AM, Andre Przywara wrote:  
> > > > On Thu, 20 May 2021 21:37:34 -0500
> > > > Samuel Holland  wrote:
> > > > 
> > > > Hi,
> > > > 
> > > >> On 5/19/21 5:41 AM, Andre Przywara wrote:
> > > >>> Add the obvious compatible name to the existing RTC binding.
> > > >>> The actual RTC part of the device uses a different day/month/year
> > > >>> storage scheme, so it's not compatible with the previous devices.
> > > >>>
> > > >>> Signed-off-by: Andre Przywara 
> > > >>> ---
> > > >>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 5 
> > > >>> -
> > > >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git 
> > > >>> a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> > > >>> b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> index b1b0ee769b71..178c955f88bf 100644
> > > >>> --- 
> > > >>> a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> +++ 
> > > >>> b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> @@ -26,6 +26,7 @@ properties:
> > > >>>- const: allwinner,sun50i-a64-rtc
> > > >>>- const: allwinner,sun8i-h3-rtc
> > > >>>- const: allwinner,sun50i-h6-rtc
> > > >>> +  - const: allwinner,sun50i-h616-rtc
> > > >>>  
> > > >>>reg:
> > > >>>  maxItems: 1
> > > >>> @@ -97,7 +98,9 @@ allOf:
> > > >>>properties:
> > > >>>  compatible:
> > > >>>contains:
> > > >>> -const: allwinner,sun50i-h6-rtc
> > > >>> +enum:
> > > >>> +  - allwinner,sun50i-h6-rtc
> > > >>> +  - allwinner,sun50i-h616-rtc
> > > >>>  
> > > >>>  then:
> > > >>>properties:
> > > >>>   
> > > >>
> > > >> This binding is missing a clock reference for the pll-periph0-2x input
> > > >> to the 32kHz clock fanout.
> > > > 
> > > > Right. So do I get this correctly that we don't model the OSC24M input
> > > > explicitly so far in the DT? I only see one possible input clock, which
> > > > is for an optional 32K crystal oscillator.
> > > > And this means we need to change some code also? Because at the moment
> > > > a clock specified is assumed to be the 32K OSC, and having this clock
> > > > means we switch to the external 32K OSC.
> > > 
> > > Right. The code would need updates to follow the binding.  
> > 
> > I changed the binding for now to not allow any clock, and the code to
> > ignore any clocks when the H616 compatible is used. This way we can
> > extend this later without breaking anything.  
> 
> I'm not really a fan of this: it just creates one more special case that
> we'll have to take into account later on, complicating further the logic
> that is already way too complicated.

I see your point, but that's why I made it a no-clock choice: we can
add clocks any time later, older kernels finding them in newer DTs will
ignore them, older DTs on newer kernels wouldn't instantiate them in
the first place.

> 
> > > > And who would decide which clock source to use? What would be the
> > > > reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> > > > divided down 24MHz?
> > > 
> > > Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
> > > expects 32768 Hz.  
> > 
> > I thought about this as well, but this means there is no reason to not
> > use the PLL? At least not for Linux (normal operation with PLLs
> > running anyway)? This situation is different for the other SoCs, because
> > boards *might* have a separate and more precise 32K crystal.
> > So we could code this similar to the other SoCs: If we have a clock
> > property defined, we assume it's pointing to the PLL and switch to use
> > it?  
> 
> We have another o

[linux-sunxi] Re: [PATCH v7 06/19] rtc: sun6i: Add support for RTCs without external LOSCs

[Andre Przywara]

On Wed, 16 Jun 2021 11:14:31 +0200
Maxime Ripard  wrote:

Hi,

> On Tue, Jun 15, 2021 at 12:06:23PM +0100, Andre Przywara wrote:
> > Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack
> > a pin for an external 32768 Hz oscillator. As a consequence, this LOSC
> > can't be selected as the RTC clock source, and we must rely on the
> > internal RC oscillator.
> > To allow additions of clocks to the RTC node, add a feature bit to ignore
> > any provided clocks for now (the current code would think this is the
> > external LOSC). Later DTs and code can then for instance add the PLL
> > based clock input, and older kernel won't get confused.
> > 
> > Signed-off-by: Andre Przywara   
> 
> Honestly, I don't really know if it's worth it at this point.
> 
> If we sums this up:
> 
>  - The RTC has 2 features that we use, mostly centered around 2
>registers set plus a global one
> 
>  - Those 2 features are programmed in a completely different way
> 
>  - Even the common part is different, given the discussion around the
>clocks that we have.
> 
> What is there to share in that driver aside from the probe, and maybe
> the interrupt handling? Instead of complicating this further with more
> special case that you were (rightfully) complaining about, shouldn't we
> just acknowledge the fact that it's a completely separate design and
> should be treated as such, with a completely separate driver?

If you mean to have a separate clock driver, and one RTC driver: I
agree, and IIUC Samuel has a prototype, covering the H6 and D1 as well:
https://github.com/smaeul/linux/commit/6f8f761db1d8dd4b6abf006fb7e2427da79321c2

The only problem I see that they are sharing MMIO registers. Maybe it
works because the RTC part never touches anything below 0x10, and the
clock part just needs the first four registers?
But this means we can't easily change this for the H6, as the
existing H6 RTC code adds 0x10 to the MMIO base, and also old DTs will
have the RTC base address in their RTC reg property.

If we can somehow solve this (let the clock driver point to the RTC
node to get a regmap?) I am all in, for the reasons you mentioned.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210616111452.1d7f2423%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v7 16/19] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Andre Przywara]

On Wed, 16 Jun 2021 11:23:55 +0200
Maxime Ripard  wrote:

Hi Maxime,

> On Tue, Jun 15, 2021 at 12:06:33PM +0100, Andre Przywara wrote:
> > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > PCIe support and the USB 3.0 controller. It also gets the management
> > controller removed, which in turn removes *some*, but not all of the
> > devices formerly dedicated to the ARISC (CPUS).
> > And while there is still the extra sunxi interrupt controller, the
> > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> > 
> > The reserved memory node is actually handled by Trusted Firmware now,
> > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > keep it in here for now, until U-Boot learns to do this properly.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 735 ++
> >  1 file changed, 735 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi 
> > b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > new file mode 100644
> > index ..021b8597cfb8
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > @@ -0,0 +1,735 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2020 Arm Ltd.
> > +// based on the H6 dtsi, which is:
> > +//   Copyright (C) 2017 Icenowy Zheng 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/ {
> > +   interrupt-parent = <>;
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   cpus {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   cpu0: cpu@0 {
> > +   compatible = "arm,cortex-a53";
> > +   device_type = "cpu";
> > +   reg = <0>;
> > +   enable-method = "psci";
> > +   clocks = < CLK_CPUX>;
> > +   };
> > +
> > +   cpu1: cpu@1 {
> > +   compatible = "arm,cortex-a53";
> > +   device_type = "cpu";
> > +   reg = <1>;
> > +   enable-method = "psci";
> > +   clocks = < CLK_CPUX>;
> > +   };
> > +
> > +   cpu2: cpu@2 {
> > +   compatible = "arm,cortex-a53";
> > +   device_type = "cpu";
> > +   reg = <2>;
> > +   enable-method = "psci";
> > +   clocks = < CLK_CPUX>;
> > +   };
> > +
> > +   cpu3: cpu@3 {
> > +   compatible = "arm,cortex-a53";
> > +   device_type = "cpu";
> > +   reg = <3>;
> > +   enable-method = "psci";
> > +   clocks = < CLK_CPUX>;
> > +   };
> > +   };
> > +
> > +   reserved-memory {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +   ranges;
> > +
> > +   /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > +   secmon_reserved: secmon@4000 {
> > +   reg = <0x0 0x4000 0x0 0x8>;
> > +   no-map;
> > +   };
> > +   };  
> 
> Can't this be added by ATF directly?

It actually is, and if you use U-Boot's DT ($fdtcontroladdr), that
actually works. But as it stands right now, U-Boot fails to propagate
this to any DTB that gets *loaded*. Fixing this requires generic code
fixes, so I can't just hack this in for sunxi quickly.
So I wanted to keep this around for a while, as missing this is a
showstopper for booting Linux.

> > +   osc24M: osc24M_clk {  
> 
> underscores are not valid in the node names and trigger a DTC warning.

Oops, sorry for that.

> 
> > +   #clock-cells = <0>;
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <2400>;
> > +   clock-output-names = "osc24M";
> > +   };
> > +
> > +   pmu {
> > +   compatible = "arm,cortex-a53-pmu";
> > +   interrupts = ,
> > +  

[linux-sunxi] Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Mon, 7 Jun 2021 23:23:04 -0500
Samuel Holland  wrote:

Hi Samuel,

> On 6/7/21 7:59 AM, Andre Przywara wrote:
> > On Thu, 20 May 2021 21:37:34 -0500
> > Samuel Holland  wrote:
> > 
> > Hi,
> >   
> >> On 5/19/21 5:41 AM, Andre Przywara wrote:  
> >>> Add the obvious compatible name to the existing RTC binding.
> >>> The actual RTC part of the device uses a different day/month/year
> >>> storage scheme, so it's not compatible with the previous devices.
> >>>
> >>> Signed-off-by: Andre Przywara 
> >>> ---
> >>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 5 -
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git 
> >>> a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> >>> b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> index b1b0ee769b71..178c955f88bf 100644
> >>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> @@ -26,6 +26,7 @@ properties:
> >>>- const: allwinner,sun50i-a64-rtc
> >>>- const: allwinner,sun8i-h3-rtc
> >>>- const: allwinner,sun50i-h6-rtc
> >>> +  - const: allwinner,sun50i-h616-rtc
> >>>  
> >>>reg:
> >>>  maxItems: 1
> >>> @@ -97,7 +98,9 @@ allOf:
> >>>properties:
> >>>  compatible:
> >>>contains:
> >>> -const: allwinner,sun50i-h6-rtc
> >>> +enum:
> >>> +  - allwinner,sun50i-h6-rtc
> >>> +  - allwinner,sun50i-h616-rtc
> >>>  
> >>>  then:
> >>>properties:
> >>> 
> >>
> >> This binding is missing a clock reference for the pll-periph0-2x input
> >> to the 32kHz clock fanout.  
> > 
> > Right. So do I get this correctly that we don't model the OSC24M input
> > explicitly so far in the DT? I only see one possible input clock, which
> > is for an optional 32K crystal oscillator.
> > And this means we need to change some code also? Because at the moment
> > a clock specified is assumed to be the 32K OSC, and having this clock
> > means we switch to the external 32K OSC.  
> 
> Right. The code would need updates to follow the binding.

I changed the binding for now to not allow any clock, and the code to
ignore any clocks when the H616 compatible is used. This way we can
extend this later without breaking anything.

> > And who would decide which clock source to use? What would be the
> > reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> > divided down 24MHz?  
> 
> Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
> expects 32768 Hz.

I thought about this as well, but this means there is no reason to not
use the PLL? At least not for Linux (normal operation with PLLs
running anyway)? This situation is different for the other SoCs, because
boards *might* have a separate and more precise 32K crystal.
So we could code this similar to the other SoCs: If we have a clock
property defined, we assume it's pointing to the PLL and switch to use
it?

But, looking at the diagram in the manual (and assuming it's
correct), the PLL based clock can only be routed to the pad, but cannot
be used for the RTC. That seems to be also the case for the T5, which
has an external LOSC pin.
 
> > So shall we ignore the PLL based input clock for now, put "0 input
> > clocks" in the current binding, then later on extend this to allow
> > choosing the PLL? And have it that way that having the PLL reference
> > means we use it?  
> 
> No, the device tree represents the hardware, not whatever happens to be
> used by Linux drivers at the time. It should be in the binding
> regardless of what the driver does with it.

I understand that very well, but was just looking for a solution where
we can go ahead with an easier solution *now*. I am afraid implementing
this annoying RTC special snowflake properly will just delay the whole
series.
In the long run your "D1 & friends" extra RTC clock driver looks the
right way out, but it will probably take some more time to get this
merged.
 
> Though the circular dependency between the clock providers does cause
> problems. We cannot get a clk_hw for the PLL-based clock, so we would
> have to hardcode a global name for it, which means we aren't really
> using the device tree.

I start to wonder

[linux-sunxi] [PATCH v7 19/19] arm64: dts: allwinner: h616: Add X96 Mate TV box support

[Andre Przywara]

The X96 Mate is an Allwinner H616 based TV box, featuring:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 2GiB/4GiB RAM (fully usable!)
  - 16/32/64GiB eMMC
  - 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
  - Unsupported Allwinner WiFi chip
  - 2 x USB 2.0 host ports
  - HDMI port
  - IR receiver
  - 5V/2A DC power supply via barrel plug

For more information see: https://linux-sunxi.org/X96_Mate

Add a basic devicetree for it, with SD card, eMMC and USB working, as
well as serial and the essential peripherals, like the AXP PMIC.

This DT is somewhat minimal, and should work on many other similar TV
boxes with the Allwinner H616 chip.

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/Makefile|   1 +
 .../dts/allwinner/sun50i-h616-x96-mate.dts| 201 ++
 2 files changed, 202 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 9ba4b5d92657..370d24ebaacf 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -37,3 +37,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
new file mode 100644
index ..b960bb310289
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2021 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "X96 Mate";
+   compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc5v: vcc5v {
+   /* board wide 5V supply directly from the DC input */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;  /* PF6 */
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   vqmmc-supply = <_bldo1>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   mmc-hs200-1_8v;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp305: pmic@745 {
+   compatible = "x-powers,axp305", "x-powers,axp805",
+"x-powers,axp806";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x745>;
+
+   x-powers,self-working-mode;
+   vina-supply = <_vcc5v>;
+   vinb-supply = <_vcc5v>;
+   vinc-supply = <_vcc5v>;
+   vind-supply = <_vcc5v>;
+   vine-supply = <_vcc5v>;
+   aldoin-supply = <_vcc5v>;
+   bldoin-supply = <_vcc5v>;
+   cldoin-supply = <_vcc5v>;
+
+   regulators {
+   reg_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-sys";
+   };
+
+   /* Enabled by the Android BSP */
+   reg_aldo2: aldo2 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc3v3-ext";
+   status = "disabled";
+   };
+
+   /* Enabled by the Android BSP */
+   reg_aldo3: aldo3 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   

[linux-sunxi] [PATCH v7 18/19] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support

[Andre Przywara]

The OrangePi Zero 2 is a development board with the new H616 SoC. It
comes with the following features:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 512MiB/1GiB DDR3 DRAM
  - AXP305 PMIC
  - Raspberry-Pi-1 compatible GPIO header
  - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
  - 1 USB 2.0 host port
  - 1 USB 2.0 type C port (power supply + OTG)
  - MicroSD slot
  - on-board 2MiB bootable SPI NOR flash
  - 1Gbps Ethernet port (via RTL8211F PHY)
  - micro-HDMI port
  - unsupported Allwinner WiFi/BT chip

For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/Makefile|   1 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 245 ++
 2 files changed, 246 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 41ce680e5f8d..9ba4b5d92657 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -36,3 +36,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
new file mode 100644
index ..a26201288872
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "OrangePi Zero2";
+   compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
+
+   aliases {
+   ethernet0 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led-0 {
+   function = LED_FUNCTION_POWER;
+   color = ;
+   gpios = < 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+   default-state = "on";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   gpios = < 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+   };
+   };
+
+   reg_vcc5v: vcc5v {
+   /* board wide 5V supply directly from the USB-C socket */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+
+   reg_usb1_vbus: usb1-vbus {
+   compatible = "regulator-fixed";
+   regulator-name = "usb1-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_vcc5v>;
+   enable-active-high;
+   gpio = < 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
+   status = "okay";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+/* USB 2 & 3 are on headers only. */
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-mode = "rgmii";
+   phy-handle = <_rgmii_phy>;
+   phy-supply = <_dcdce>;
+   allwinner,rx-delay-ps = <3100>;
+   allwinner,tx-delay-ps = <700>;
+   status = "okay";
+};
+
+ {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;  /* PF6 */
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp305: pmic@745 {
+   compatible = "x-powers,axp305", "x-powers,axp805",
+"x-powers,axp806";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x745>;
+
+   x-powers,self-working-mode;
+   vina-supply = <_vcc5v>;
+   vinb-supply = <_vcc5v>;
+   vinc-supply = <_vcc5v>;
+   vind-supply = <

[linux-sunxi] [PATCH v7 17/19] dt-bindings: arm: sunxi: Add two H616 board compatible strings

[Andre Przywara]

Signed-off-by: Andre Przywara 
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml 
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index ac750025a2eb..0b20d2260d0b 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -837,6 +837,11 @@ properties:
   - const: yones-toptech,bs1078-v2
   - const: allwinner,sun6i-a31s
 
+  - description: X96 Mate TV box
+items:
+  - const: hechuang,x96-mate
+  - const: allwinner,sun50i-h616
+
   - description: Xunlong OrangePi
 items:
   - const: xunlong,orangepi
@@ -937,4 +942,9 @@ properties:
   - const: xunlong,orangepi-zero-plus2-h3
   - const: allwinner,sun8i-h3
 
+  - description: Xunlong OrangePi Zero 2
+items:
+  - const: xunlong,orangepi-zero2
+  - const: allwinner,sun50i-h616
+
 additionalProperties: true
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-18-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 16/19] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Andre Przywara]

This (relatively) new SoC is similar to the H6, but drops the (broken)
PCIe support and the USB 3.0 controller. It also gets the management
controller removed, which in turn removes *some*, but not all of the
devices formerly dedicated to the ARISC (CPUS).
And while there is still the extra sunxi interrupt controller, the
package lacks the corresponding NMI pin, so no interrupts for the PMIC.

The reserved memory node is actually handled by Trusted Firmware now,
but U-Boot fails to propagate this to a separately loaded DTB, so we
keep it in here for now, until U-Boot learns to do this properly.

Signed-off-by: Andre Przywara 
---
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 735 ++
 1 file changed, 735 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
new file mode 100644
index ..021b8597cfb8
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -0,0 +1,735 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Arm Ltd.
+// based on the H6 dtsi, which is:
+//   Copyright (C) 2017 Icenowy Zheng 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <0>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <1>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <2>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu3: cpu@3 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <3>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+   };
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* 512KiB reserved for ARM Trusted Firmware (BL31) */
+   secmon_reserved: secmon@4000 {
+   reg = <0x0 0x4000 0x0 0x8>;
+   no-map;
+   };
+   };
+
+   osc24M: osc24M_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ,
+,
+,
+;
+   interrupt-affinity = <>, <>, <>, <>;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   arm,no-tick-in-suspend;
+   interrupts = ,
+,
+,
+;
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x0 0x4000>;
+
+   syscon: syscon@300 {
+   compatible = "allwinner,sun50i-h616-system-control";
+   reg = <0x0300 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   sram_c: sram@28000 {
+   compatible = "mmio-sram";
+   reg = <0x00028000 0x3>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x00028000 0x3&g

[linux-sunxi] [PATCH v7 15/19] phy: sun4i-usb: Add support for the H616 USB PHY

[Andre Przywara]

The USB PHY used in the Allwinner H616 SoC inherits some traits from its
various predecessors: it has four full PHYs like the H3, needs some
extra bits to be set like the H6, and puts SIDDQ on a different bit like
the A100. Plus it needs this weird PHY2 quirk.

Name all those properties in a new config struct and assign a new
compatible name to it.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 316ef5fca831..85a9771280b7 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -1024,6 +1024,17 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
.missing_phys = BIT(1) | BIT(2),
 };
 
+static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = {
+   .num_phys = 4,
+   .type = sun50i_h6_phy,
+   .disc_thresh = 3,
+   .phyctl_offset = REG_PHYCTL_A33,
+   .dedicated_clocks = true,
+   .phy0_dual_route = true,
+   .hci_phy_ctl_clear = PHY_CTL_SIDDQ,
+   .needs_phy2_siddq = true,
+};
+
 static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-usb-phy", .data = _a10_cfg },
{ .compatible = "allwinner,sun5i-a13-usb-phy", .data = _a13_cfg },
@@ -1038,6 +1049,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] 
= {
{ .compatible = "allwinner,sun50i-a64-usb-phy",
  .data = _a64_cfg},
{ .compatible = "allwinner,sun50i-h6-usb-phy", .data = _h6_cfg },
+   { .compatible = "allwinner,sun50i-h616-usb-phy", .data = 
_h616_cfg },
{ },
 };
 MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-16-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 14/19] phy: sun4i-usb: Introduce port2 SIDDQ quirk

[Andre Przywara]

At least the Allwinner H616 SoC requires a weird quirk to make most
USB PHYs work: Only port2 works out of the box, but all other ports
need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
the PMU PHY control register needs to be cleared. For this register to
be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask 

Instead of disguising this as some generic feature, do exactly that
in our PHY init:
If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
this one special clock, and clear the SIDDQ bit. We can pull in the
other required clocks via the DT.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 126ef74d013c..316ef5fca831 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -120,6 +120,7 @@ struct sun4i_usb_phy_cfg {
u8 phyctl_offset;
bool dedicated_clocks;
bool phy0_dual_route;
+   bool needs_phy2_siddq;
int missing_phys;
 };
 
@@ -289,6 +290,50 @@ static int sun4i_usb_phy_init(struct phy *_phy)
return ret;
}
 
+   /* Some PHYs on some SoCs need the help of PHY2 to work. */
+   if (data->cfg->needs_phy2_siddq && phy->index != 2) {
+   struct sun4i_usb_phy *phy2 = >phys[2];
+
+   ret = clk_prepare_enable(phy2->clk);
+   if (ret) {
+   reset_control_assert(phy->reset);
+   clk_disable_unprepare(phy->clk2);
+   clk_disable_unprepare(phy->clk);
+   return ret;
+   }
+
+   ret = reset_control_deassert(phy2->reset);
+   if (ret) {
+   clk_disable_unprepare(phy2->clk);
+   reset_control_assert(phy->reset);
+   clk_disable_unprepare(phy->clk2);
+   clk_disable_unprepare(phy->clk);
+   return ret;
+   }
+
+   /*
+* This extra clock is just needed to access the
+* REG_HCI_PHY_CTL PMU register for PHY2.
+*/
+   ret = clk_prepare_enable(phy2->clk2);
+   if (ret) {
+   reset_control_assert(phy2->reset);
+   clk_disable_unprepare(phy2->clk);
+   reset_control_assert(phy->reset);
+   clk_disable_unprepare(phy->clk2);
+   clk_disable_unprepare(phy->clk);
+   return ret;
+   }
+
+   if (phy2->pmu && data->cfg->hci_phy_ctl_clear) {
+   val = readl(phy2->pmu + REG_HCI_PHY_CTL);
+   val &= ~data->cfg->hci_phy_ctl_clear;
+   writel(val, phy2->pmu + REG_HCI_PHY_CTL);
+   }
+
+   clk_disable_unprepare(phy->clk2);
+   }
+
if (phy->pmu && data->cfg->hci_phy_ctl_clear) {
val = readl(phy->pmu + REG_HCI_PHY_CTL);
val &= ~data->cfg->hci_phy_ctl_clear;
@@ -354,6 +399,13 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
data->phy0_init = false;
}
 
+   if (data->cfg->needs_phy2_siddq && phy->index != 2) {
+   struct sun4i_usb_phy *phy2 = >phys[2];
+
+   clk_disable_unprepare(phy2->clk);
+   reset_control_assert(phy2->reset);
+   }
+
sun4i_usb_phy_passby(phy, 0);
reset_control_assert(phy->reset);
clk_disable_unprepare(phy->clk2);
@@ -785,6 +837,13 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
dev_err(dev, "failed to get clock %s\n", name);
return PTR_ERR(phy->clk2);
}
+   } else {
+   snprintf(name, sizeof(name), "pmu%d_clk", i);
+   phy->clk2 = devm_clk_get_optional(dev, name);
+   if (IS_ERR(phy->clk2)) {
+   dev_err(dev, "failed to get clock %s\n", name);
+   return PTR_ERR(phy->clk2);
+   }
}
 
snprintf(name, sizeof(name), "usb%d_reset", i);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-15-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 13/19] phy: sun4i-usb: Allow reset line to be shared

[Andre Przywara]

The USB HCIs (and PHYs?) in Allwinner's newer generation SoCs (H616)
rely on the reset line of USB PHY 2 to be de-asserted, even when only
one of the other PHYs is actually in use.

To make those ports work, we include this reset line in the HCIs' resets
property, which requires this line to be shareable.

Change the call to allocate the reset line to mark it as shared, to
enable the other ports on those SoCs.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 142f4cafdc78..126ef74d013c 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -788,7 +788,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
}
 
snprintf(name, sizeof(name), "usb%d_reset", i);
-   phy->reset = devm_reset_control_get(dev, name);
+   phy->reset = devm_reset_control_get_shared(dev, name);
if (IS_ERR(phy->reset)) {
dev_err(dev, "failed to get reset %s\n", name);
return PTR_ERR(phy->reset);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-14-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 12/19] phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling

[Andre Przywara]

As Icenowy pointed out, newer manuals (starting with H6) actually
document the register block at offset 0x800 as "HCI controller and PHY
interface", also describe the bits in our "PMU_UNK1" register.
Let's put proper names to those "unknown" variables and symbols.

While we are at it, generalise the existing code by allowing a bitmap
of bits to clear and set, to cover newer SoCs: The A100 and H616 use a
different bit for the SIDDQ control.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 30 ---
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 788dd5cdbb7d..142f4cafdc78 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -43,7 +43,7 @@
 #define REG_PHYCTL_A33 0x10
 #define REG_PHY_OTGCTL 0x20
 
-#define REG_PMU_UNK1   0x10
+#define REG_HCI_PHY_CTL0x10
 
 #define PHYCTL_DATABIT(7)
 
@@ -82,6 +82,7 @@
 /* A83T specific control bits for PHY0 */
 #define PHY_CTL_VBUSVLDEXT BIT(5)
 #define PHY_CTL_SIDDQ  BIT(3)
+#define PHY_CTL_H3_SIDDQ   BIT(1)
 
 /* A83T specific control bits for PHY2 HSIC */
 #define SUNXI_EHCI_HS_FORCEBIT(20)
@@ -115,9 +116,9 @@ struct sun4i_usb_phy_cfg {
int hsic_index;
enum sun4i_usb_phy_type type;
u32 disc_thresh;
+   u32 hci_phy_ctl_clear;
u8 phyctl_offset;
bool dedicated_clocks;
-   bool enable_pmu_unk1;
bool phy0_dual_route;
int missing_phys;
 };
@@ -288,6 +289,12 @@ static int sun4i_usb_phy_init(struct phy *_phy)
return ret;
}
 
+   if (phy->pmu && data->cfg->hci_phy_ctl_clear) {
+   val = readl(phy->pmu + REG_HCI_PHY_CTL);
+   val &= ~data->cfg->hci_phy_ctl_clear;
+   writel(val, phy->pmu + REG_HCI_PHY_CTL);
+   }
+
if (data->cfg->type == sun8i_a83t_phy ||
data->cfg->type == sun50i_h6_phy) {
if (phy->index == 0) {
@@ -297,11 +304,6 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val, data->base + data->cfg->phyctl_offset);
}
} else {
-   if (phy->pmu && data->cfg->enable_pmu_unk1) {
-   val = readl(phy->pmu + REG_PMU_UNK1);
-   writel(val & ~2, phy->pmu + REG_PMU_UNK1);
-   }
-
/* Enable USB 45 Ohm resistor calibration */
if (phy->index == 0)
sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
@@ -863,7 +865,6 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
@@ -872,7 +873,6 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
.disc_thresh = 2,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
@@ -881,7 +881,6 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
@@ -890,7 +889,6 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
.disc_thresh = 2,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
@@ -899,7 +897,6 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
@@ -908,7 +905,6 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a83t_cfg = {
@@ -925,7 +921,7 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
-   .enable_pmu_unk1 = true,
+   .hci_phy_ctl_clear = PHY_CTL_H3_SIDDQ,
.phy0_dual_route = true,
 };
 
@@ -935,7 +931,7 @@ static const struct sun4i_usb_phy_cfg sun8i_r40_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
-   .enable_pm

[linux-sunxi] [PATCH v7 11/19] dt-bindings: usb: sunxi-musb: Add H616 compatible string

[Andre Przywara]

The H616 MUSB peripheral is compatible to the H3 one (8 endpoints).

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml 
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
index 0f520f17735e..933fa356d2ce 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
@@ -22,6 +22,9 @@ properties:
   - allwinner,sun8i-a83t-musb
   - allwinner,sun50i-h6-musb
   - const: allwinner,sun8i-a33-musb
+  - items:
+  - const: allwinner,sun50i-h616-musb
+  - const: allwinner,sun8i-h3-musb
 
   reg:
 maxItems: 1
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-12-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 10/19] dt-bindings: usb: Add H616 compatible string

[Andre Przywara]

The H616 has four PHYs as the H3, along with their respective clock
gates and resets, so the property description is identical.

However the PHYs itself need some special bits, so we need a new
compatible string for it.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml 
b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
index f80431060803..e288450e0844 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
@@ -15,7 +15,9 @@ properties:
 const: 1
 
   compatible:
-const: allwinner,sun8i-h3-usb-phy
+enum:
+  - allwinner,sun8i-h3-usb-phy
+  - allwinner,sun50i-h616-usb-phy
 
   reg:
 items:
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-11-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 09/19] net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register

[Andre Przywara]

The Allwinner H616 SoC has two EMAC controllers, with the second one
being tied to the internal PHY, but also using a separate EMAC clock
register.

To tell the driver about which clock register to use, we add a parameter
to our syscon phandle. The driver will use this value as an index into
the regmap, so that we can address more than the first register, if
needed.

Signed-off-by: Andre Przywara 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4422baeed3d8..5f3fefd9a74e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1147,11 +1147,13 @@ static int sun8i_dwmac_probe(struct platform_device 
*pdev)
struct stmmac_resources stmmac_res;
struct sunxi_priv_data *gmac;
struct device *dev = >dev;
+   struct reg_field syscon_field;
phy_interface_t interface;
int ret;
struct stmmac_priv *priv;
struct net_device *ndev;
struct regmap *regmap;
+   u32 syscon_idx = 0;
 
ret = stmmac_get_platform_resources(pdev, _res);
if (ret)
@@ -1209,8 +1211,12 @@ static int sun8i_dwmac_probe(struct platform_device 
*pdev)
return ret;
}
 
-   gmac->regmap_field = devm_regmap_field_alloc(dev, regmap,
-
*gmac->variant->syscon_field);
+   syscon_field = *gmac->variant->syscon_field;
+   ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1,
+_idx);
+   if (!ret)
+   syscon_field.reg += syscon_idx * sizeof(u32);
+   gmac->regmap_field = devm_regmap_field_alloc(dev, regmap, syscon_field);
if (IS_ERR(gmac->regmap_field)) {
ret = PTR_ERR(gmac->regmap_field);
dev_err(dev, "Unable to map syscon register: %d\n", ret);
@@ -1330,6 +1336,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
.data = _variant_a64 },
{ .compatible = "allwinner,sun50i-h6-emac",
.data = _variant_h6 },
+   { .compatible = "allwinner,sun50i-h616-emac",
+   .data = _variant_h6 },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-10-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 08/19] dt-bindings: net: sun8i-emac: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing EMAC binding, and pair
it with the existing A64 fallback compatible string, as the devices are
compatible.

On the way use enums to group the compatible devices together.

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml| 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml 
b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 7f2578d48e3f..0ccdab103f59 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -19,7 +19,9 @@ properties:
   - const: allwinner,sun8i-v3s-emac
   - const: allwinner,sun50i-a64-emac
   - items:
-  - const: allwinner,sun50i-h6-emac
+  - enum:
+  - allwinner,sun50i-h6-emac
+  - allwinner,sun50i-h616-emac
   - const: allwinner,sun50i-a64-emac
 
   reg:
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-9-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 07/19] rtc: sun6i: Add Allwinner H616 support

[Andre Przywara]

The H616 RTC changes its day storage to the newly introduced linear day
scheme, so pair the new compatible string with this feature flag.
The clock part is missing an external 32768 Hz oscillator input pin,
for future expansion we must thus ignore any provided clock for now.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 1fabb3c69041..25dae50019af 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -392,6 +392,23 @@ static void __init sun50i_h6_rtc_clk_init(struct 
device_node *node)
 CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
  sun50i_h6_rtc_clk_init);
 
+static const struct sun6i_rtc_clk_data sun50i_h616_rtc_data = {
+   .rc_osc_rate = 1600,
+   .fixed_prescaler = 32,
+   .has_prescaler = 1,
+   .has_out_clk = 1,
+   .export_iosc = 1,
+   .no_ext_losc = 1,
+};
+
+static void __init sun50i_h616_rtc_clk_init(struct device_node *node)
+{
+   sun6i_rtc_clk_init(node, _h616_rtc_data);
+}
+
+CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
+ sun50i_h616_rtc_clk_init);
+
 /*
  * The R40 user manual is self-conflicting on whether the prescaler is
  * fixed or configurable. The clock diagram shows it as fixed, but there
@@ -797,6 +814,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
{ .compatible = "allwinner,sun8i-v3-rtc" },
{ .compatible = "allwinner,sun50i-h5-rtc" },
{ .compatible = "allwinner,sun50i-h6-rtc" },
+   { .compatible = "allwinner,sun50i-h616-rtc",
+   .data = (void *)RTC_LINEAR_DAY },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-8-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 04/19] rtc: sun6i: Add support for linear day storage

[Andre Przywara]

Newer versions of the Allwinner RTC, as for instance found in the H616
SoC, no longer store a broken-down day/month/year representation in the
RTC_DAY_REG, but just a linear day number.
The user manual does not give any indication about the expected epoch
time of this day count, but the BSP kernel uses the UNIX epoch, which
allows easy support due to existing conversion functions in the kernel.

Allow tagging a compatible string with a flag, and use that to mark
those new RTCs. Then convert between a UNIX day number (converted into
seconds) and the broken-down day representation using mktime64() and
time64_to_tm() in the set_time/get_time functions.

That enables support for the RTC in those new chips.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 66 +++--
 1 file changed, 44 insertions(+), 22 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index adec1b14a8de..e4fc6e4f2bfb 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -110,6 +110,8 @@
 #define SUN6I_YEAR_MIN 1970
 #define SUN6I_YEAR_OFF (SUN6I_YEAR_MIN - 1900)
 
+#define SEC_PER_DAY(24 * 3600ULL)
+
 /*
  * There are other differences between models, including:
  *
@@ -133,12 +135,15 @@ struct sun6i_rtc_clk_data {
unsigned int has_auto_swt : 1;
 };
 
+#define RTC_LINEAR_DAY BIT(0)
+
 struct sun6i_rtc_dev {
struct rtc_device *rtc;
const struct sun6i_rtc_clk_data *data;
void __iomem *base;
int irq;
unsigned long alarm;
+   unsigned long flags;
 
struct clk_hw hw;
struct clk_hw *int_osc;
@@ -467,22 +472,30 @@ static int sun6i_rtc_gettime(struct device *dev, struct 
rtc_time *rtc_tm)
} while ((date != readl(chip->base + SUN6I_RTC_YMD)) ||
 (time != readl(chip->base + SUN6I_RTC_HMS)));
 
+   if (chip->flags & RTC_LINEAR_DAY) {
+   /*
+* Newer chips store a linear day number, the manual
+* does not mandate any epoch base. The BSP driver uses
+* the UNIX epoch, let's just copy that, as it's the
+* easiest anyway.
+*/
+   rtc_time64_to_tm((date & 0x) * SEC_PER_DAY, rtc_tm);
+   } else {
+   rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
+   rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date) - 1;
+   rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
+
+   /*
+* switch from (data_year->min)-relative offset to
+* a (1900)-relative one
+*/
+   rtc_tm->tm_year += SUN6I_YEAR_OFF;
+   }
+
rtc_tm->tm_sec  = SUN6I_TIME_GET_SEC_VALUE(time);
rtc_tm->tm_min  = SUN6I_TIME_GET_MIN_VALUE(time);
rtc_tm->tm_hour = SUN6I_TIME_GET_HOUR_VALUE(time);
 
-   rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
-   rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date);
-   rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
-
-   rtc_tm->tm_mon  -= 1;
-
-   /*
-* switch from (data_year->min)-relative offset to
-* a (1900)-relative one
-*/
-   rtc_tm->tm_year += SUN6I_YEAR_OFF;
-
return 0;
 }
 
@@ -571,20 +584,27 @@ static int sun6i_rtc_settime(struct device *dev, struct 
rtc_time *rtc_tm)
u32 date = 0;
u32 time = 0;
 
-   rtc_tm->tm_year -= SUN6I_YEAR_OFF;
-   rtc_tm->tm_mon += 1;
-
-   date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
-   SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
-   SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
-
-   if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
-   date |= SUN6I_LEAP_SET_VALUE(1);
-
time = SUN6I_TIME_SET_SEC_VALUE(rtc_tm->tm_sec)  |
SUN6I_TIME_SET_MIN_VALUE(rtc_tm->tm_min)  |
SUN6I_TIME_SET_HOUR_VALUE(rtc_tm->tm_hour);
 
+   if (chip->flags & RTC_LINEAR_DAY) {
+   rtc_tm->tm_sec = 0;
+   rtc_tm->tm_min = 0;
+   rtc_tm->tm_hour = 0;
+   date = rtc_tm_to_time64(rtc_tm) / SEC_PER_DAY;
+   } else {
+   rtc_tm->tm_year -= SUN6I_YEAR_OFF;
+   rtc_tm->tm_mon += 1;
+
+   date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
+   SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
+   SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
+
+   if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
+   date |= SUN6I_LEAP_SET_VALUE(1);
+   }
+
/* Check whether registers are writable */
if (sun6i_rtc_wait(chip, SUN6I_LOSC_CTRL,
   SUN6I_LOSC_CTRL_ACC_MASK, 50)) {
@@ -678,6 +698,8 @@ st

[linux-sunxi] [PATCH v7 06/19] rtc: sun6i: Add support for RTCs without external LOSCs

[Andre Przywara]

Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack
a pin for an external 32768 Hz oscillator. As a consequence, this LOSC
can't be selected as the RTC clock source, and we must rely on the
internal RC oscillator.
To allow additions of clocks to the RTC node, add a feature bit to ignore
any provided clocks for now (the current code would think this is the
external LOSC). Later DTs and code can then for instance add the PLL
based clock input, and older kernel won't get confused.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 54bd47fb0a5f..1fabb3c69041 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -134,6 +134,7 @@ struct sun6i_rtc_clk_data {
unsigned int export_iosc : 1;
unsigned int has_losc_en : 1;
unsigned int has_auto_swt : 1;
+   unsigned int no_ext_losc : 1;
 };
 
 #define RTC_LINEAR_DAY BIT(0)
@@ -256,7 +257,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node,
}
 
/* Switch to the external, more precise, oscillator, if present */
-   if (of_get_property(node, "clocks", NULL)) {
+   if (!rtc->data->no_ext_losc && of_get_property(node, "clocks", NULL)) {
reg |= SUN6I_LOSC_CTRL_EXT_OSC;
if (rtc->data->has_losc_en)
reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
@@ -282,14 +283,19 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node,
}
 
parents[0] = clk_hw_get_name(rtc->int_osc);
-   /* If there is no external oscillator, this will be NULL and ... */
-   parents[1] = of_clk_get_parent_name(node, 0);
+   if (rtc->data->no_ext_losc) {
+   parents[1] = NULL;
+   init.num_parents = 1;
+   } else {
+   /* If there is no external oscillator, this will be NULL and */
+   parents[1] = of_clk_get_parent_name(node, 0);
+   /* ... number of clock parents will be 1. */
+   init.num_parents = of_clk_get_parent_count(node) + 1;
+   }
 
rtc->hw.init = 
 
init.parent_names = parents;
-   /* ... number of clock parents will be 1. */
-   init.num_parents = of_clk_get_parent_count(node) + 1;
of_property_read_string_index(node, "clock-output-names", 0,
  );
 
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-7-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 05/19] rtc: sun6i: Add support for broken-down alarm registers

[Andre Przywara]

Newer versions of the Allwinner RTC, for instance as found in the H616
SoC, not only store the current day as a linear number, but also change
the way the alarm is handled: There are now two registers, that
explicitly store the wakeup time, in the same format as the current
time.

Add support for that variant by writing the requested wakeup time
directly into the registers, instead of programming the seconds left, as
the old SoCs required.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 60 +++--
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index e4fc6e4f2bfb..54bd47fb0a5f 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -48,7 +48,8 @@
 
 /* Alarm 0 (counter) */
 #define SUN6I_ALRM_COUNTER 0x0020
-#define SUN6I_ALRM_CUR_VAL 0x0024
+/* This holds the remaining alarm seconds on older SoCs (current value) */
+#define SUN6I_ALRM_COUNTER_HMS 0x0024
 #define SUN6I_ALRM_EN  0x0028
 #define SUN6I_ALRM_EN_CNT_EN   BIT(0)
 #define SUN6I_ALRM_IRQ_EN  0x002c
@@ -523,36 +524,55 @@ static int sun6i_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
struct rtc_time *alrm_tm = >time;
struct rtc_time tm_now;
-   unsigned long time_now = 0;
unsigned long time_set = 0;
-   unsigned long time_gap = 0;
+   unsigned long counter_val, counter_val_hms;
int ret = 0;
 
-   ret = sun6i_rtc_gettime(dev, _now);
-   if (ret < 0) {
-   dev_err(dev, "Error in getting time\n");
-   return -EINVAL;
-   }
-
time_set = rtc_tm_to_time64(alrm_tm);
-   time_now = rtc_tm_to_time64(_now);
-   if (time_set <= time_now) {
-   dev_err(dev, "Date to set in the past\n");
-   return -EINVAL;
-   }
-
-   time_gap = time_set - time_now;
 
-   if (time_gap > U32_MAX) {
-   dev_err(dev, "Date too far in the future\n");
-   return -EINVAL;
+   if (chip->flags & RTC_LINEAR_DAY) {
+   /*
+* The alarm registers hold the actual alarm time, encoded
+* in the same way (linear day + HMS) as the current time.
+*/
+   counter_val_hms = SUN6I_TIME_SET_SEC_VALUE(alrm_tm->tm_sec)  |
+ SUN6I_TIME_SET_MIN_VALUE(alrm_tm->tm_min)  |
+ SUN6I_TIME_SET_HOUR_VALUE(alrm_tm->tm_hour);
+   counter_val = mktime64(alrm_tm->tm_year + 1900, alrm_tm->tm_mon,
+  alrm_tm->tm_mday, 0, 0, 0) / SEC_PER_DAY;
+   } else {
+   /* The alarm register holds the number of seconds left. */
+   unsigned long time_now;
+
+   ret = sun6i_rtc_gettime(dev, _now);
+   if (ret < 0) {
+   dev_err(dev, "Error in getting time\n");
+   return -EINVAL;
+   }
+
+   time_now = rtc_tm_to_time64(_now);
+   if (time_set <= time_now) {
+   dev_err(dev, "Date to set in the past\n");
+   return -EINVAL;
+   }
+
+   counter_val = time_set - time_now;
+
+   if (counter_val > U32_MAX) {
+   dev_err(dev, "Date too far in the future\n");
+   return -EINVAL;
+   }
}
 
sun6i_rtc_setaie(0, chip);
writel(0, chip->base + SUN6I_ALRM_COUNTER);
+   if (chip->flags & RTC_LINEAR_DAY)
+   writel(0, chip->base + SUN6I_ALRM_COUNTER_HMS);
usleep_range(100, 300);
 
-   writel(time_gap, chip->base + SUN6I_ALRM_COUNTER);
+   writel(counter_val, chip->base + SUN6I_ALRM_COUNTER);
+   if (chip->flags & RTC_LINEAR_DAY)
+   writel(counter_val_hms, chip->base + SUN6I_ALRM_COUNTER_HMS);
chip->alarm = time_set;
 
sun6i_rtc_setaie(wkalrm->enabled, chip);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-6-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 03/19] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing RTC binding.
The actual RTC part of the device uses a different day/month/year
storage scheme, so it's not compatible with the previous devices.
Also the clock part is quite different, as there is no external 32K LOSC
oscillator input.

Signed-off-by: Andre Przywara 
---
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index b1b0ee769b71..2c3fd72e17ee 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -26,6 +26,7 @@ properties:
   - const: allwinner,sun50i-a64-rtc
   - const: allwinner,sun8i-h3-rtc
   - const: allwinner,sun50i-h6-rtc
+  - const: allwinner,sun50i-h616-rtc
 
   reg:
 maxItems: 1
@@ -105,6 +106,20 @@ allOf:
   minItems: 3
   maxItems: 3
 
+  - if:
+  properties:
+compatible:
+  contains:
+const: allwinner,sun50i-h616-rtc
+
+then:
+  properties:
+clock-output-names:
+  minItems: 3
+  maxItems: 3
+clocks:
+  maxItems: 0
+
   - if:
   properties:
 compatible:
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-4-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 02/19] mfd: axp20x: Allow AXP 806 chips without interrupt lines

[Andre Przywara]

Currently the AXP chip requires to have its IRQ line connected to some
interrupt controller, and will fail probing when this is not the case.

On a new Allwinner SoC (H616) there is no NMI pin anymore, and at
least one board does not connect the AXP's IRQ pin to anything else,
so the interrupt functionality of the AXP chip is simply not available.

Check whether the interrupt line number returned by the platform code is
valid, before trying to register the irqchip. If not, we skip this
registration, to avoid the driver to bail out completely.
Also we need to skip the power key functionality, as this relies on
a valid IRQ as well.

Signed-off-by: Andre Przywara 
---
 drivers/mfd/axp20x.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3eae04e24ac8..4145a38b3890 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -884,8 +884,13 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP806_ID:
+   /*
+* Don't register the power key part if in slave mode or
+* if there is no interrupt line.
+*/
if (of_property_read_bool(axp20x->dev->of_node,
- "x-powers,self-working-mode")) {
+ "x-powers,self-working-mode") &&
+   axp20x->irq > 0) {
axp20x->nr_cells = 
ARRAY_SIZE(axp806_self_working_cells);
axp20x->cells = axp806_self_working_cells;
} else {
@@ -959,12 +964,17 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
 AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE);
}
 
-   ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
- IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
-  -1, axp20x->regmap_irq_chip, >regmap_irqc);
-   if (ret) {
-   dev_err(axp20x->dev, "failed to add irq chip: %d\n", ret);
-   return ret;
+   /* Only if there is an interrupt line connected towards the CPU. */
+   if (axp20x->irq > 0) {
+   ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
+   IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
+   -1, axp20x->regmap_irq_chip,
+   >regmap_irqc);
+   if (ret) {
+   dev_err(axp20x->dev, "failed to add irq chip: %d\n",
+   ret);
+   return ret;
+   }
}
 
ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-3-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 01/19] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Andre Przywara]

The AXP305 PMIC used on many boards with the H616 SoC seems to be fully
compatible to the AXP805 PMIC, so add the proper chain of compatible
strings.

Also at least on one board (Orangepi Zero2) there is no interrupt line
connected to the CPU, so make the "interrupts" property optional.

Signed-off-by: Andre Przywara 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 4991a6415796..2b53dcc0ea61 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -26,10 +26,10 @@ Required properties:
 * "x-powers,axp803"
 * "x-powers,axp806"
 * "x-powers,axp805", "x-powers,axp806"
+* "x-powers,axp305", "x-powers,axp805", "x-powers,axp806"
 * "x-powers,axp809"
 * "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
-- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
 - #interrupt-cells: Should be set to 1
 
@@ -43,6 +43,7 @@ more information:
AXP20x/LDO3: software-based implementation
 
 Optional properties:
+- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
  AXP152/20X: range:  750-1875, Default: 1.5 MHz
  AXP22X/8XX: range: 1800-4050, Default: 3   MHz
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-2-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v7 00/19] arm64: sunxi: Initial Allwinner H616 SoC support

[Andre Przywara]

elog v1 .. v2:
- pinctrl: adjust irq bank map to cover undocumented GPIO bank IRQs
- use differing h_i2s0 pin output names
- r-ccu: fix number of used clocks
- ccu: remove PLL-PERIPHy(4X)
- ccu: fix gpu1 divider range
- ccu: fix usb-phy3 parent
- ccu: add missing TV clocks
- ccu: rework to CLK_OF_DECLARE style
- ccu: enable output bit for PLL clocks
- ccu: renumber clocks
- .dtsi: drop sun50i-a64-system-control fallback
- .dtsi: drop unknown SRAM regions
- .dtsi: add more (undocumented) GPIO interrupts
- .dtsi: fix I2C3 pin names
- .dtsi: use a100-emmc fallback for MMC2
- .dtsi: add second EMAC controller
- .dtsi: use H3 MUSB controller fallback
- .dtsi: fix frame size for USB PHY PMU registers
- .dtsi: add USB0 PHY references
- .dtsi: fix IR controller clock source
- .dts: fix LED naming and swap pins
- .dts: use 5V supply parent for USB supply
- .dts: drop dummy IRQ for AXP
- .dts: enable 3V3 header pin power rail
- .dts: add SPI flash node
- .dts: make USB-C port peripheral only
- add IRQ-less AXP support
- add two patches to support more than one EMAC clock
- add patch to rework and extend USB PHY support
- add DT binding documentation patches

Andre Przywara (19):
  dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  mfd: axp20x: Allow AXP 806 chips without interrupt lines
  dt-bindings: rtc: sun6i: Add H616 compatible string
  rtc: sun6i: Add support for linear day storage
  rtc: sun6i: Add support for broken-down alarm registers
  rtc: sun6i: Add support for RTCs without external LOSCs
  rtc: sun6i: Add Allwinner H616 support
  dt-bindings: net: sun8i-emac: Add H616 compatible string
  net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register
  dt-bindings: usb: Add H616 compatible string
  dt-bindings: usb: sunxi-musb: Add H616 compatible string
  phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling
  phy: sun4i-usb: Allow reset line to be shared
  phy: sun4i-usb: Introduce port2 SIDDQ quirk
  phy: sun4i-usb: Add support for the H616 USB PHY
  arm64: dts: allwinner: Add Allwinner H616 .dtsi file
  dt-bindings: arm: sunxi: Add two H616 board compatible strings
  arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
  arm64: dts: allwinner: h616: Add X96 Mate TV box support

 .../devicetree/bindings/arm/sunxi.yaml|  10 +
 .../devicetree/bindings/mfd/axp20x.txt|   3 +-
 .../net/allwinner,sun8i-a83t-emac.yaml|   4 +-
 .../phy/allwinner,sun8i-h3-usb-phy.yaml   |   4 +-
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml |  15 +
 .../usb/allwinner,sun4i-a10-musb.yaml |   3 +
 arch/arm64/boot/dts/allwinner/Makefile|   2 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 245 ++
 .../dts/allwinner/sun50i-h616-x96-mate.dts| 201 +
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 735 ++
 drivers/mfd/axp20x.c  |  24 +-
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c |  12 +-
 drivers/phy/allwinner/phy-sun4i-usb.c | 103 ++-
 drivers/rtc/rtc-sun6i.c   | 161 ++--
 14 files changed, 1445 insertions(+), 77 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi

-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210615110636.23403-1-andre.przywara%40arm.com.

Re: [linux-sunxi] Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk

[Andre Przywara]

On Mon, 7 Jun 2021 22:26:02 +0800
Chen-Yu Tsai  wrote:

Hi Chen-Yu,

> On Mon, Jun 7, 2021 at 10:17 PM Andre Przywara  wrote:
> >
> > On Mon, 7 Jun 2021 15:22:55 +0200
> > Maxime Ripard  wrote:
> >
> > Hi Maxime,
> >  
> > > On Tue, May 25, 2021 at 12:29:01PM +0100, Andre Przywara wrote:  
> > > > On Mon, 24 May 2021 13:59:46 +0200
> > > > Maxime Ripard  wrote:
> > > >
> > > > Hi Maxime,
> > > >  
> > > > > On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:  
> > > > > > At least the Allwinner H616 SoC requires a weird quirk to make most
> > > > > > USB PHYs work: Only port2 works out of the box, but all other ports
> > > > > > need some help from this port2 to work correctly: The CLK_BUS_PHY2 
> > > > > > and
> > > > > > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit 
> > > > > > in
> > > > > > the PMU PHY control register needs to be cleared. For this register 
> > > > > > to
> > > > > > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask 
> > > > > >
> > > > > > Instead of disguising this as some generic feature, do exactly that
> > > > > > in our PHY init:
> > > > > > If the quirk bit is set, and we initialise a PHY other than PHY2, 
> > > > > > ungate
> > > > > > this one special clock, and clear the SIDDQ bit. We can pull in the
> > > > > > other required clocks via the DT.
> > > > > >
> > > > > > Signed-off-by: Andre Przywara   
> > > > >
> > > > > What is this SIDDQ bit doing exactly?  
> > > >
> > > > I probably know as much as you do, but as Jernej pointed out, in some
> > > > Rockchip code it's indeed documented as some analogue PHY supply switch:
> > > > ($ git grep -i siddq drivers/phy/rockchip)
> > > >
> > > > In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
> > > > our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.  
> > >
> > > Ok
> > >  
> > > > > I guess we could also expose this using a power-domain if it's 
> > > > > relevant?  
> > > >
> > > > Mmmh, interesting idea. So are you thinking about registering a genpd
> > > > provider in sun4i_usb_phy_probe(), then having a power-domains property
> > > > in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
> > > > the provider be a subnode of the USB PHY node, with a separate
> > > > compatible? That sounds a bit more involved, but would have the
> > > > advantage of allowing us to specify the resets and clocks from PHY2
> > > > there, and would look a bit cleaner than hacking them into the
> > > > other EHCI/OHCI nodes.  
> > >
> > > I'm not sure we need a separate device node, we could just register the
> > > phy driver as a genpd provider, and then with an arg (so with
> > > of_genpd_add_provider_onecell?) the index of the USB controller we want
> > > to power up.  
> >
> > Yeah, I figured that myself meanwhile ;-) I now have a fairly nice
> > implementation, which does away with the extra clocks and resets from
> > the EHCI/OHCI nodes, and just adds one extra clock to the PHY node. The
> > rest is power domains properties.  
> 
> I'm wondering, since SIDDQ refers to the analog power for USB, it shouldn't
> really affect the HCIs, only the PHYs. Is there any way to model it like
> this and test it?

That is actually a good point: it is indeed solely a PHY property. The
HCIs already connect to their PHYs, among other reasons to power them
on, so it should really be an internal PHY affair.
Which is actually what this patch here does.
So I can combine the best of both approaches: we already have the
PHY2 clock and reset references in the PHY node, so can just reach out
and enable them as well, alongside the actually associated PHY clock.
This allows us to get rid of the bogus PHY2 clock references from all
HCIs.
So all of this H616 quirk can be fully contained within the PHY driver,
with no impact on the HCI parts and no extra DT properties
(power-domains, clocks) needed there.

Seems to work on a quick test. I will send a version ASAP.

Thanks!
Andre

> 
> ChenYu
> 
> > > > I would not touch the existing SoCs (even though it seems to apply to
> > > > them as well, just not in the exact same way), but I ca

[linux-sunxi] Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk

[Andre Przywara]

On Mon, 7 Jun 2021 15:22:55 +0200
Maxime Ripard  wrote:

Hi Maxime,

> On Tue, May 25, 2021 at 12:29:01PM +0100, Andre Przywara wrote:
> > On Mon, 24 May 2021 13:59:46 +0200
> > Maxime Ripard  wrote:
> > 
> > Hi Maxime,
> >   
> > > On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:  
> > > > At least the Allwinner H616 SoC requires a weird quirk to make most
> > > > USB PHYs work: Only port2 works out of the box, but all other ports
> > > > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > > > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > > > the PMU PHY control register needs to be cleared. For this register to
> > > > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask 
> > > > 
> > > > Instead of disguising this as some generic feature, do exactly that
> > > > in our PHY init:
> > > > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > > > this one special clock, and clear the SIDDQ bit. We can pull in the
> > > > other required clocks via the DT.
> > > > 
> > > > Signed-off-by: Andre Przywara 
> > > 
> > > What is this SIDDQ bit doing exactly?  
> > 
> > I probably know as much as you do, but as Jernej pointed out, in some
> > Rockchip code it's indeed documented as some analogue PHY supply switch:
> > ($ git grep -i siddq drivers/phy/rockchip)
> > 
> > In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
> > our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.  
> 
> Ok
> 
> > > I guess we could also expose this using a power-domain if it's relevant?  
> > 
> > Mmmh, interesting idea. So are you thinking about registering a genpd
> > provider in sun4i_usb_phy_probe(), then having a power-domains property
> > in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
> > the provider be a subnode of the USB PHY node, with a separate
> > compatible? That sounds a bit more involved, but would have the
> > advantage of allowing us to specify the resets and clocks from PHY2
> > there, and would look a bit cleaner than hacking them into the
> > other EHCI/OHCI nodes.  
> 
> I'm not sure we need a separate device node, we could just register the
> phy driver as a genpd provider, and then with an arg (so with
> of_genpd_add_provider_onecell?) the index of the USB controller we want
> to power up.

Yeah, I figured that myself meanwhile ;-) I now have a fairly nice
implementation, which does away with the extra clocks and resets from
the EHCI/OHCI nodes, and just adds one extra clock to the PHY node. The
rest is power domains properties.

> > I would not touch the existing SoCs (even though it seems to apply to
> > them as well, just not in the exact same way), but I can give it a
> > try for the H616. It seems like the other SIDDQ bits (in the other
> > PHYs) are still needed for operation, but the PD provide could actually
> > take care of this as well.
> > 
> > Does that make sense or is this a bit over the top for just clearing an
> > extra bit?  
> 
> Using what I described above should be fairly simple, so if we can fit
> in an available and relevant abstraction, yeah, I guess :)

Thanks!
I will post what I have, just need to find some solution for the RTC
clock bits.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210607151742.2f05ff95%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Andre Przywara]

On Mon, 24 May 2021 14:02:20 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Wed, May 19, 2021 at 11:41:49AM +0100, Andre Przywara wrote:
> > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > PCIe support and the USB 3.0 controller. It also gets the management
> > controller removed, which in turn removes *some*, but not all of the
> > devices formerly dedicated to the ARISC (CPUS).
> > And while there is still the extra sunxi interrupt controller, the
> > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> > 
> > USB is a bit tricky: host controller 0, 1 and 3 depend on some help from
> > controller and PHY 2, so we need to include one reset line and one
> > clock gate from HCI 2 into every other HCI node, plus need some nasty
> > quirk.
> > 
> > The reserved memory node is actually handled by Trusted Firmware now,
> > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > keep it in here for now, until U-Boot learns to do this properly.
> > 
> > Signed-off-by: Andre Przywara   
> 
> As far as I can see, the IOMMU hasn't changed between the H6 and the
> H616, so it would be worth enabling

I would rather not include anything that can't be tested at this point.
IIUC the IOMMU is still only for the video devices, which I omitted at
all so far - the display engine definitely needs code changes (Jernej
has something in the making).
So I'd like to wait for the IOMMU nodes till we get DE or VE support.

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210607135927.65e98fc8%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

On Thu, 20 May 2021 21:37:34 -0500
Samuel Holland  wrote:

Hi,

> On 5/19/21 5:41 AM, Andre Przywara wrote:
> > Add the obvious compatible name to the existing RTC binding.
> > The actual RTC part of the device uses a different day/month/year
> > storage scheme, so it's not compatible with the previous devices.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > index b1b0ee769b71..178c955f88bf 100644
> > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > @@ -26,6 +26,7 @@ properties:
> >- const: allwinner,sun50i-a64-rtc
> >- const: allwinner,sun8i-h3-rtc
> >- const: allwinner,sun50i-h6-rtc
> > +  - const: allwinner,sun50i-h616-rtc
> >  
> >reg:
> >  maxItems: 1
> > @@ -97,7 +98,9 @@ allOf:
> >properties:
> >  compatible:
> >contains:
> > -const: allwinner,sun50i-h6-rtc
> > +enum:
> > +  - allwinner,sun50i-h6-rtc
> > +  - allwinner,sun50i-h616-rtc
> >  
> >  then:
> >properties:
> >   
> 
> This binding is missing a clock reference for the pll-periph0-2x input
> to the 32kHz clock fanout.

Right. So do I get this correctly that we don't model the OSC24M input
explicitly so far in the DT? I only see one possible input clock, which
is for an optional 32K crystal oscillator.
And this means we need to change some code also? Because at the moment
a clock specified is assumed to be the 32K OSC, and having this clock
means we switch to the external 32K OSC.
And who would decide which clock source to use? What would be the
reason to use PLL_PERIPH(2x) over the RC16M based clock or the
divided down 24MHz?

So shall we ignore the PLL based input clock for now, put "0 input
clocks" in the current binding, then later on extend this to allow
choosing the PLL? And have it that way that having the PLL reference
means we use it?

> It is also missing a clock reference to the RTC register gate (and that
> clock is in turn missing from the r_ccu driver).

Do you mean a gate bit somewhere in the PRCM? Do you have any
pointer/documentation for that?

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210607135910.63560ffc%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout

[Andre Przywara]

ng for PHY auto negotiation to complete.
> TIMEOUT !
> reset MAC done after: 0 us
> ethernet@1c3 Waiting for PHY auto negotiation to complete.
> TIMEOUT !
>  try2:
> reset MAC done after: 0 us
> Using ethernet@1c3 device
> TFTP from server 192.168.5.80; our IP address is 192.168.5.78
> Filename 'zImage'.
> Load address: 0x4200
> Loading:
> #
> #
> #
> ####
> 2.4 MiB/s
> done
> Bytes transferred = 3790520 (39d6b8 hex)
> reset MAC done after: 1001000 us
> sun8i_emac_eth_start: Timeout
> 
> 
> Am Do., 20. Mai 2021 um 02:18 Uhr schrieb Andre Przywara <
> andre.przyw...@arm.com>:  
> 
> > On Thu, 20 May 2021 00:10:47 +0200
> > Andreas Rehn  wrote:
> >  
> > > hey,
> > >
> > > sure. I give it a try tomorrow.
> > > with 250 ms, for example, I ran into timeouts after the first tftp  
> > download.  
> > > after a manual retry, it works fine but retry is not a valid production
> > > behavior.  
> >
> > Just read the arch timer after the SOFT_RST write and after the first
> > read of 0 again, and I got 17-18 ticks on my OrangePi Zero (H2+). So at
> > 24MHz this is less than a *micro*second for the MAC to reset. So the 10
> > ms are already plenty.
> > Are you sure that it's this timeout value that is improving things for
> > you?
> >
> > Cheers,
> > Andre
> >  
> > > greetings
> > > Andreas
> > >
> > > Am Mi., 19. Mai 2021 um 23:45 Uhr schrieb Andre Przywara <  
> > > andre.przyw...@arm.com>:  
> > >  
> > > > On Wed, 19 May 2021 21:42:08 +0200
> > > > Andreas Rehn  wrote:
> > > >
> > > > Hi,
> > > >  
> > > > > v3s emac soft reset tooks quit longer if autonegation is active
> > > > > on 100 Mbit full duplex pairs what can result in
> > > > > `sun8i_emac_eth_start: Timeout` error  
> > > >
> > > > Mmmh, why the 500ms? Can you figure out how long it typically
> > > > takes for you? By open-coding wait_for_bit_le32() and printing the time
> > > > it took to flip the bit back?
> > > >
> > > > Happy to change this then when we have some data.
> > > >
> > > > Cheers,
> > > > Andre
> > > >  
> > > > > wait_for_bit_le32 polls register value each ms.
> > > > > Increasing the timeout for setup do not effect current behavior
> > > > > but reduces unexpected behaviors (e.g. timeouts on tftp download).
> > > > >
> > > > > Signed-off-by: Andreas Rehn 
> > > > > ---
> > > > >  drivers/net/sun8i_emac.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> > > > > index 0e7ad3b0d4..23fd35f9e1 100644
> > > > > --- a/drivers/net/sun8i_emac.c
> > > > > +++ b/drivers/net/sun8i_emac.c
> > > > > @@ -475,7 +475,7 @@ static int sun8i_emac_eth_start(struct udevice  
> > *dev)  
> > > > >   /* Soft reset MAC */
> > > > >   writel(EMAC_CTL1_SOFT_RST, priv->mac_reg + EMAC_CTL1);
> > > > >   ret = wait_for_bit_le32(priv->mac_reg + EMAC_CTL1,
> > > > > - EMAC_CTL1_SOFT_RST, false, 10, true);
> > > > > + EMAC_CTL1_SOFT_RST, false, 500, true);
> > > > >   if (ret) {
> > > > >   printf("%s: Timeout\n", __func__);
> > > > >   return ret;  
> > > >
> > > >  
> > >  
> >
> >  
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210603145647.3e0ae706%40slackpad.fritz.box.

[linux-sunxi] Pull request: u-boot-sunxi/master for v2021.07

[Andre Przywara]

Hi Tom,

please pull the master branch from u-boot-sunxi, containing the fix
to bring back the SD card as MMC0. In the long run we are looking into a
more robust solution, but for now we need to fix this, as this breaks
the user experience left, right, and centre.
Also add the one MAINTAINERS path addition from Samuel.

Thanks,
Andre

==
The following changes since commit ffd810487ec2ff6095edf3f3d058d7ed6eb85ff3:

  Merge tag 'u-boot-stm32-20210528' of 
https://source.denx.de/u-boot/custodians/u-boot-stm (2021-05-28 14:11:06 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master

for you to fetch changes up to f264e796c06d7ce6c039bfc7255390309cbc5191:

  MAINTAINERS: Add allwinner/sunxi driver directories (2021-05-31 00:39:54 
+0100)


Andre Przywara (1):
  sunxi: Bring back SD card as MMC device 0

Samuel Holland (1):
  MAINTAINERS: Add allwinner/sunxi driver directories

 MAINTAINERS| 3 +++
 arch/arm/dts/sunxi-u-boot.dtsi | 1 +
 2 files changed, 4 insertions(+)

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210531002345.1335-1-andre.przywara%40arm.com.

[linux-sunxi] Re: [PATCH v2] sunxi: clock: H6/H616: Fix PLL clock factor encodings

[Andre Przywara]

On Wed,  5 May 2021 13:53:05 +0100
Andre Przywara  wrote:

Hi,

> Most clock factors and dividers in the H6 PLLs use a "+1 encoding",
> which we were missing on two occasions.

can someone please confirm that I didn't mess this up?

Cheers,
Andre

> 
> This fixes the MMC clock setup on the H6, which could be slightly off due
> to the wrong parent frequency:
> mmc 2 set mod-clk req 5200 parent 117600 n 2 m 12 rate 4900
> 
> Also the CPU frequency was a tad too high before.
> 
> Signed-off-by: Andre Przywara 
> ---
> Changelog v1 .. v2:
> - Also fix PLL5 factor calculation (video, currently unused)
> - Also fix PLL1 factor calculation (CPU clock)
> 
>  arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 4 ++--
>  arch/arm/mach-sunxi/clock_sun50i_h6.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h 
> b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> index 62abfc4ef6b..2e076cf594d 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> @@ -233,14 +233,14 @@ struct sunxi_ccm_reg {
>  #define CCM_PLL1_OUT_EN  BIT(27)
>  #define CCM_PLL1_CLOCK_TIME_2(2 << 24)
>  #define CCM_PLL1_CTRL_P(p)   ((p) << 16)
> -#define CCM_PLL1_CTRL_N(n)   ((n) << 8)
> +#define CCM_PLL1_CTRL_N(n)   (((n) - 1) << 8)
>  
>  /* pll5 bit field */
>  #define CCM_PLL5_CTRL_EN BIT(31)
>  #define CCM_PLL5_LOCK_EN BIT(29)
>  #define CCM_PLL5_LOCKBIT(28)
>  #define CCM_PLL5_OUT_EN  BIT(27)
> -#define CCM_PLL5_CTRL_N(n)   ((n) << 8)
> +#define CCM_PLL5_CTRL_N(n)   (((n) - 1) << 8)
>  #define CCM_PLL5_CTRL_DIV1(div1) ((div1) << 0)
>  #define CCM_PLL5_CTRL_DIV2(div0) ((div0) << 1)
>  
> diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c 
> b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> index 492fc4a3fca..a947463e0a5 100644
> --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> @@ -94,7 +94,7 @@ unsigned int clock_get_pll6(void)
>   int m = IS_ENABLED(CONFIG_MACH_SUN50I_H6) ? 4 : 2;
>  
>   uint32_t rval = readl(>pll6_cfg);
> - int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT);
> + int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 1;
>   int div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
>   CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
>   int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210527004948.0c2ef6b6%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v2 4/6] net: sun8i-emac: add v3s variant

[Andre Przywara]

On Sun, 23 May 2021 01:22:38 +0200
Andreas Rehn  wrote:

Hi,

> Add variant V3S_EMAC.
> Handle pinmux compile time error by skipping goio setup, because
> V3s uses internal phy and don't expose pins.
> 
> Signed-off-by: Andreas Rehn 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
> Changes in v2:
>   - skip pinmux and add proper description
>   - Add V3S variant add it to compatible list
>   - Skip (R)GMII flags and handle sun8i_handle_internal_phy
> 
>  drivers/net/sun8i_emac.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index 5a1b38bf80..ab9f61994c 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -145,6 +145,7 @@ enum emac_variant {
>   A64_EMAC,
>   R40_GMAC,
>   H6_EMAC,
> + V3S_EMAC,
>  };
>  
>  struct emac_dma_desc {
> @@ -303,7 +304,7 @@ static void sun8i_adjust_link(struct emac_eth_dev *priv,
>  static u32 sun8i_emac_set_syscon_ephy(struct emac_eth_dev *priv, u32 reg)
>  {
>   if (priv->use_internal_phy) {
> - /* H3 based SoC's that has an Internal 100MBit PHY
> + /* H3 and V3s based SoC's that has an Internal 100MBit PHY
>* needs to be configured and powered up before use
>   */
>   reg &= ~H3_EPHY_DEFAULT_MASK;
> @@ -354,7 +355,8 @@ static int sun8i_emac_set_syscon(struct sun8i_eth_pdata 
> *pdata,
>   case PHY_INTERFACE_MODE_RGMII_ID:
>   case PHY_INTERFACE_MODE_RGMII_RXID:
>   case PHY_INTERFACE_MODE_RGMII_TXID:
> - reg |= SC_EPIT | SC_ETCS_INT_GMII;
> + if (priv->variant != V3S_EMAC)
> + reg |= SC_EPIT | SC_ETCS_INT_GMII;
>   break;
>   case PHY_INTERFACE_MODE_RMII:
>   if (priv->variant == H3_EMAC ||
> @@ -566,6 +568,10 @@ static int parse_phy_pins(struct udevice *dev)
>   iomux = SUN8I_IOMUX;
>   else if (IS_ENABLED(CONFIG_MACH_SUN50I))
>   iomux = SUN8I_IOMUX;
> + else if (IS_ENABLED(CONFIG_MACH_SUN8I_V3S))
> + // V3s does not expose any MAC pins,
> + // but case is required to handle BUILD_BUG_ON_MSG.
> + return 0;
>   else
>   BUILD_BUG_ON_MSG(1, "missing pinmux value for Ethernet pins");
>  
> @@ -956,7 +962,8 @@ static int sun8i_emac_eth_of_to_plat(struct udevice *dev)
>   return -EINVAL;
>   }
>  
> - if (priv->variant == H3_EMAC) {
> + if (priv->variant == H3_EMAC ||
> + priv->variant == V3S_EMAC) {
>   ret = sun8i_handle_internal_phy(dev, priv);
>   if (ret)
>   return ret;
> @@ -1009,6 +1016,8 @@ static const struct udevice_id sun8i_emac_eth_ids[] = {
>   .data = (uintptr_t)R40_GMAC },
>   {.compatible = "allwinner,sun50i-h6-emac",
>   .data = (uintptr_t)H6_EMAC },
> + {.compatible = "allwinner,sun8i-v3s-emac",
> + .data = (uintptr_t)V3S_EMAC },
>   { }
>  };
>  

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210527002419.39cd8542%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v2 3/6] clk: sunxi: v3s: fix tabs / spaces

[Andre Przywara]

On Sun, 23 May 2021 01:17:29 +0200
Andreas Rehn  wrote:

> align CLK_USB_PHY0 with tabs
> 
> Signed-off-by: Andreas Rehn 

Reviewed-by: Andre Przywara 

Cheers,
Andre

P.S. Please send a whole v2 series next time, to make this easier to
sort out which patch still applies and which not.

> ---
> Changes in v2:
>   - revert CLK_SPI0 extra tab
> 
>  drivers/clk/sunxi/clk_v3s.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/sunxi/clk_v3s.c b/drivers/clk/sunxi/clk_v3s.c
> index 55fc597043..bc6b7b4870 100644
> --- a/drivers/clk/sunxi/clk_v3s.c
> +++ b/drivers/clk/sunxi/clk_v3s.c
> @@ -29,7 +29,7 @@ static struct ccu_clk_gate v3s_gates[] = {
>  
>   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
>  
> - [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
> + [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
>  };
>  
>  static struct ccu_reset v3s_resets[] = {

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210527001624.66ffeb28%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk

[Andre Przywara]

On Mon, 24 May 2021 13:59:46 +0200
Maxime Ripard  wrote:

Hi Maxime,

> On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:
> > At least the Allwinner H616 SoC requires a weird quirk to make most
> > USB PHYs work: Only port2 works out of the box, but all other ports
> > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > the PMU PHY control register needs to be cleared. For this register to
> > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask 
> > 
> > Instead of disguising this as some generic feature, do exactly that
> > in our PHY init:
> > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > this one special clock, and clear the SIDDQ bit. We can pull in the
> > other required clocks via the DT.
> > 
> > Signed-off-by: Andre Przywara   
> 
> What is this SIDDQ bit doing exactly?

I probably know as much as you do, but as Jernej pointed out, in some
Rockchip code it's indeed documented as some analogue PHY supply switch:
($ git grep -i siddq drivers/phy/rockchip)

In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.

> I guess we could also expose this using a power-domain if it's relevant?

Mmmh, interesting idea. So are you thinking about registering a genpd
provider in sun4i_usb_phy_probe(), then having a power-domains property
in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
the provider be a subnode of the USB PHY node, with a separate
compatible? That sounds a bit more involved, but would have the
advantage of allowing us to specify the resets and clocks from PHY2
there, and would look a bit cleaner than hacking them into the
other EHCI/OHCI nodes.

I would not touch the existing SoCs (even though it seems to apply to
them as well, just not in the exact same way), but I can give it a
try for the H616. It seems like the other SIDDQ bits (in the other
PHYs) are still needed for operation, but the PD provide could actually
take care of this as well.

Does that make sense or is this a bit over the top for just clearing an
extra bit?

Cheers,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210525122901.778bfccd%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH] sunxi: Bring back SD card as MMC device 0

[Andre Przywara]

On Mon, 26 Apr 2021 17:52:51 +0530
Jagan Teki  wrote:

Hi Jagan,

> On Mon, Apr 26, 2021 at 4:57 PM Andre Przywara  wrote:
> >
> > On Sun, 25 Apr 2021 18:03:05 +0530
> > Jagan Teki  wrote:
> >
> > Hi Jagan,
> >
> > thanks for your input!
> >  
> > > On Sun, Apr 25, 2021 at 3:30 PM Andre Przywara  
> > > wrote:  
> > > >
> > > > On Fri, 16 Apr 2021 12:08:09 +0100
> > > > Andre Przywara  wrote:
> > > >
> > > > Hi,
> > > >  
> > > > > Commit 2243d19e5618 ("mmc: mmc-uclass: Use dev_seq() to read aliases
> > > > > node's index") now actually enforces U-Boot's device enumeration 
> > > > > policy,
> > > > > where explicitly named devices come first, then any other non-named
> > > > > devices follow, without filling gaps.
> > > > >
> > > > > For quite a while we have had an "mmc1 = " alias in our
> > > > > sunxi-u-boot.dtsi, which now leads to the problem that the SD card
> > > > > (which was always mmc device 0) now gets to be number 2.
> > > > > I guess this breaks quite some boot scripts, and is confusing at 
> > > > > least.
> > > > >
> > > > > Just add an explicit mmc0 alias in the very same file to fix this and
> > > > > restore the old behaviour.  
> > > >
> > > > Can someone please say if this is the right solution?
> > > > I think the SD card has always been mmc device 0 in U-Boot, so I think
> > > > it's worth keeping that. Just not sure if this is the right way of
> > > > fixing that?  
> > >
> > > Playing with aliases always gets confused and might get a different
> > > behavior, IMHO.  
> >
> > I am not so sure about that, since aliases force a fixed numbering, so
> > it should be less confusing. We have the same problem in the kernel
> > now, and Samuel sent some patches to have aliases in the mainline DTs
> > as well [1].  
> 
> Okay.
> 
> >  
> > > Detect the dev number by U-Boot itself and look at
> > > traverse bootenv by all possible dev numbers in sunxi-common.h, but  
> >
> > OK, I will have a look at how the automatic distro boot behaves with
> > this change. My concern was more the interactive user, who is used to
> > have the SD card at device 0 (I certainly am).
> >  
> > > this has one slide effect that we mark mmc2 as devnum 1 for the sake
> > > of fastboot so if we mark fastboot number for specific board properly
> > > (by static or runtime) then explicit aliases wouldn't required.  
> >
> > Ah, good point, thanks for the heads up. I guess this is the actual
> > reason for the alias in our -u-boot.dtsi? Maybe we find a different way
> > to let fastboot find the eMMC? Then we can drop the extra mmc1 alias,
> > get our numbering back, and can cope with the incoming aliases from the
> > mainline DTs as well?  
> 
> Agreed.

So I had a look at fastboot, and posted an RFC[1] to try and fix this
properly. This seems to somewhat work, but there are more assumptions
in (sunxi) U-Boot about the eMMC being device 1 (boot source,
distro_boot scripts, ...). I agree that we should remove this
assumption, but this requires more work and scrutiny to find all those
cases.

For now the change in numbering breaks right, left, and centre: boot.scr
cannot be found anymore, fastboot cannot find the SD card, custom
scripts stop working.

So I would very much like to merge this patch here, to fix the
currently bad user experience and get a clean v2021.07 release.
We can meanwhile look into a proper solution for this problem, to
become more robust against enumeration changes (for instance due to
aliases).

Thanks,
Andre

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210524014838.0b313b40%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support

[Andre Przywara]

On Sat, 22 May 2021 09:29:26 +0200
Jernej Škrabec  wrote:

Hi,

> Dne sreda, 19. maj 2021 ob 12:41:40 CEST je Andre Przywara napisal(a):
> > The H616 RTC changes its day storage to the newly introduced linear day
> > scheme, so pair the new compatible string with this feature flag.
> > So far the clock parts seem to be the same as the H6, so combine the
> > compatible string with the existing H6 support bits.  
> 
> There is one more difference - H616 alarm value is now broken down to days, 
> hours, minutes and seconds.

That's a good point, that actually requires adjusting the driver in
this respect as well. And contrary to what the manual says ("Counter
Register will down count to zero"), and the previous RTCs do, those alarm
registers now need to be set to the actual wakeup time, not the time
left before wakeup.
Will fix the driver accordingly.

Thanks for the heads up!

Cheers,
Andre

> 
> Best regards,
> Jernej
> 
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  drivers/rtc/rtc-sun6i.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > index 0228e9dfd969..ec0cd0ee539a 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -382,6 +382,8 @@ static void __init sun50i_h6_rtc_clk_init(struct   
> device_node *node)
> >  }
> >  CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> >   sun50i_h6_rtc_clk_init);
> > +CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
> > + sun50i_h6_rtc_clk_init);
> >  
> >  /*
> >   * The R40 user manual is self-conflicting on whether the prescaler is
> > @@ -773,6 +775,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
> > { .compatible = "allwinner,sun8i-v3-rtc" },
> > { .compatible = "allwinner,sun50i-h5-rtc" },
> > { .compatible = "allwinner,sun50i-h6-rtc" },
> > +   { .compatible = "allwinner,sun50i-h616-rtc",
> > +   .data = (void *)RTC_LINEAR_DAY },
> > { /* sentinel */ },
> >  };
> >  MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
> > -- 
> > 2.17.5
> > 
> >   
> 
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210523010643.7fdfd419%40slackpad.fritz.box.

[linux-sunxi] Re: [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Andre Przywara]

On Sat, 22 May 2021 09:46:23 -0500
Samuel Holland  wrote:

> On 5/19/21 5:41 AM, Andre Przywara wrote:
> > The AXP305 PMIC used in AXP805 seems to be fully compatible to the  
>   ^^
> Typo? Do you mean "used with the H616 SoC"?

Ouch, yes. And even more embarrassingly Chen-Yu pointed that out already
in the previous version. Same for the compatible string.

Thanks for having a look!

Cheers,
Andre

> 
> > AXP805 PMIC, so add the proper chain of compatible strings.
> > 
> > Also at least on one board (Orangepi Zero2) there is no interrupt line
> > connected to the CPU, so make the "interrupts" property optional.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
> > b/Documentation/devicetree/bindings/mfd/axp20x.txt
> > index 4991a6415796..4fd748101e3c 100644
> > --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> > +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> > @@ -26,10 +26,10 @@ Required properties:
> >  * "x-powers,axp803"
> >  * "x-powers,axp806"
> >  * "x-powers,axp805", "x-powers,axp806"
> > +* "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"  
>^^
> This should be x-powers,axp305.
> 
> Regards,
> Samuel
> 
> >  * "x-powers,axp809"
> >  * "x-powers,axp813"
> >  - reg: The I2C slave address or RSB hardware address for the AXP chip
> > -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> >  - interrupt-controller: The PMIC has its own internal IRQs
> >  - #interrupt-cells: Should be set to 1
> >  
> > @@ -43,6 +43,7 @@ more information:
> > AXP20x/LDO3: software-based implementation
> >  
> >  Optional properties:
> > +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> >  - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
> >   AXP152/20X: range:  750-1875, Default: 1.5 MHz
> >   AXP22X/8XX: range: 1800-4050, Default: 3   MHz
> >   
> 
> 

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210523010124.2fb56fa5%40slackpad.fritz.box.

[linux-sunxi] [PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support

[Andre Przywara]

The X96 Mate is an Allwinner H616 based TV box, featuring:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 2GiB/4GiB RAM (fully usable!)
  - 16/32/64GiB eMMC
  - 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
  - Unsupported Allwinner WiFi chip
  - 2 x USB 2.0 host ports
  - HDMI port
  - IR receiver
  - 5V/2A DC power supply via barrel plug

For more information see: https://linux-sunxi.org/X96_Mate

Add a basic devicetree for it, with SD card, eMMC and USB working, as
well as serial and the essential peripherals, like the AXP PMIC.

This DT is somewhat minimal, and should work on many other similar TV
boxes with the Allwinner H616 chip.

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/Makefile|   1 +
 .../dts/allwinner/sun50i-h616-x96-mate.dts| 201 ++
 2 files changed, 202 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 9ba4b5d92657..370d24ebaacf 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -37,3 +37,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
new file mode 100644
index ..b960bb310289
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2021 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "X96 Mate";
+   compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc5v: vcc5v {
+   /* board wide 5V supply directly from the DC input */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;  /* PF6 */
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   vqmmc-supply = <_bldo1>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   mmc-hs200-1_8v;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp305: pmic@745 {
+   compatible = "x-powers,axp305", "x-powers,axp805",
+"x-powers,axp806";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x745>;
+
+   x-powers,self-working-mode;
+   vina-supply = <_vcc5v>;
+   vinb-supply = <_vcc5v>;
+   vinc-supply = <_vcc5v>;
+   vind-supply = <_vcc5v>;
+   vine-supply = <_vcc5v>;
+   aldoin-supply = <_vcc5v>;
+   bldoin-supply = <_vcc5v>;
+   cldoin-supply = <_vcc5v>;
+
+   regulators {
+   reg_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-sys";
+   };
+
+   /* Enabled by the Android BSP */
+   reg_aldo2: aldo2 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc3v3-ext";
+   status = "disabled";
+   };
+
+   /* Enabled by the Android BSP */
+   reg_aldo3: aldo3 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   

[linux-sunxi] [PATCH v6 15/17] dt-bindings: arm: sunxi: Add OrangePi Zero 2 binding

[Andre Przywara]

Signed-off-by: Andre Przywara 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml 
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index ac750025a2eb..1ca550062a85 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -937,4 +937,9 @@ properties:
   - const: xunlong,orangepi-zero-plus2-h3
   - const: allwinner,sun8i-h3
 
+  - description: Xunlong OrangePi Zero 2
+items:
+  - const: xunlong,orangepi-zero2
+  - const: allwinner,sun50i-h616
+
 additionalProperties: true
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-16-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Andre Przywara]

This (relatively) new SoC is similar to the H6, but drops the (broken)
PCIe support and the USB 3.0 controller. It also gets the management
controller removed, which in turn removes *some*, but not all of the
devices formerly dedicated to the ARISC (CPUS).
And while there is still the extra sunxi interrupt controller, the
package lacks the corresponding NMI pin, so no interrupts for the PMIC.

USB is a bit tricky: host controller 0, 1 and 3 depend on some help from
controller and PHY 2, so we need to include one reset line and one
clock gate from HCI 2 into every other HCI node, plus need some nasty
quirk.

The reserved memory node is actually handled by Trusted Firmware now,
but U-Boot fails to propagate this to a separately loaded DTB, so we
keep it in here for now, until U-Boot learns to do this properly.

Signed-off-by: Andre Przywara 
---
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 747 ++
 1 file changed, 747 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
new file mode 100644
index ..30195e4779de
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -0,0 +1,747 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Arm Ltd.
+// based on the H6 dtsi, which is:
+//   Copyright (C) 2017 Icenowy Zheng 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <0>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <1>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <2>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+
+   cpu3: cpu@3 {
+   compatible = "arm,cortex-a53";
+   device_type = "cpu";
+   reg = <3>;
+   enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   };
+   };
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* 512KiB reserved for ARM Trusted Firmware (BL31) */
+   secmon_reserved: secmon@4000 {
+   reg = <0x0 0x4000 0x0 0x8>;
+   no-map;
+   };
+   };
+
+   osc24M: osc24M_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ,
+,
+,
+;
+   interrupt-affinity = <>, <>, <>, <>;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   arm,no-tick-in-suspend;
+   interrupts = ,
+,
+,
+;
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x0 0x4000>;
+
+   syscon: syscon@300 {
+   compatible = "allwinner,sun50i-h616-system-control";
+   reg = <0x0300 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   sram_c: sram@28000 {
+   compatible = "mmio-sram";
+   reg = <0x

[linux-sunxi] [PATCH v6 16/17] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support

[Andre Przywara]

The OrangePi Zero 2 is a development board with the new H616 SoC. It
comes with the following features:
  - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
  - 512MiB/1GiB DDR3 DRAM
  - AXP305 PMIC
  - Raspberry-Pi-1 compatible GPIO header
  - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
  - 1 USB 2.0 host port
  - 1 USB 2.0 type C port (power supply + OTG)
  - MicroSD slot
  - on-board 2MiB bootable SPI NOR flash
  - 1Gbps Ethernet port (via RTL8211F PHY)
  - micro-HDMI port
  - unsupported Allwinner WiFi/BT chip

For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/Makefile|   1 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 245 ++
 2 files changed, 246 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index 41ce680e5f8d..9ba4b5d92657 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -36,3 +36,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
new file mode 100644
index ..a26201288872
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "OrangePi Zero2";
+   compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
+
+   aliases {
+   ethernet0 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led-0 {
+   function = LED_FUNCTION_POWER;
+   color = ;
+   gpios = < 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+   default-state = "on";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   gpios = < 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+   };
+   };
+
+   reg_vcc5v: vcc5v {
+   /* board wide 5V supply directly from the USB-C socket */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+
+   reg_usb1_vbus: usb1-vbus {
+   compatible = "regulator-fixed";
+   regulator-name = "usb1-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_vcc5v>;
+   enable-active-high;
+   gpio = < 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
+   status = "okay";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+/* USB 2 & 3 are on headers only. */
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-mode = "rgmii";
+   phy-handle = <_rgmii_phy>;
+   phy-supply = <_dcdce>;
+   allwinner,rx-delay-ps = <3100>;
+   allwinner,tx-delay-ps = <700>;
+   status = "okay";
+};
+
+ {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+};
+
+ {
+   vmmc-supply = <_dcdce>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;  /* PF6 */
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp305: pmic@745 {
+   compatible = "x-powers,axp305", "x-powers,axp805",
+"x-powers,axp806";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x745>;
+
+   x-powers,self-working-mode;
+   vina-supply = <_vcc5v>;
+   vinb-supply = <_vcc5v>;
+   vinc-supply = <_vcc5v>;
+   vind-supply = <

[linux-sunxi] [PATCH v6 13/17] phy: sun4i-usb: Add support for the H616 USB PHY

[Andre Przywara]

The USB PHY used in the Allwinner H616 SoC inherits some traits from its
various predecessors: it has four full PHYs like the H3, needs some
extra bits to be set like the H6, and puts SIDDQ on a different bit like
the A100. Plus it needs this weird PHY2 quirk.

Name all those properties in a new config struct and assign a new
compatible name to it.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index ed7b9cc5a424..a55765ad7bad 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -994,6 +994,17 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
.missing_phys = BIT(1) | BIT(2),
 };
 
+static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = {
+   .num_phys = 4,
+   .type = sun50i_h6_phy,
+   .disc_thresh = 3,
+   .phyctl_offset = REG_PHYCTL_A33,
+   .dedicated_clocks = true,
+   .phy0_dual_route = true,
+   .hci_phy_ctl_clear = PHY_CTL_SIDDQ,
+   .needs_phy2_siddq = true,
+};
+
 static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-usb-phy", .data = _a10_cfg },
{ .compatible = "allwinner,sun5i-a13-usb-phy", .data = _a13_cfg },
@@ -1008,6 +1019,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] 
= {
{ .compatible = "allwinner,sun50i-a64-usb-phy",
  .data = _a64_cfg},
{ .compatible = "allwinner,sun50i-h6-usb-phy", .data = _h6_cfg },
+   { .compatible = "allwinner,sun50i-h616-usb-phy", .data = 
_h616_cfg },
{ },
 };
 MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-14-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk

[Andre Przywara]

At least the Allwinner H616 SoC requires a weird quirk to make most
USB PHYs work: Only port2 works out of the box, but all other ports
need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
the PMU PHY control register needs to be cleared. For this register to
be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask 

Instead of disguising this as some generic feature, do exactly that
in our PHY init:
If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
this one special clock, and clear the SIDDQ bit. We can pull in the
other required clocks via the DT.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 126ef74d013c..ed7b9cc5a424 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -120,6 +120,7 @@ struct sun4i_usb_phy_cfg {
u8 phyctl_offset;
bool dedicated_clocks;
bool phy0_dual_route;
+   bool needs_phy2_siddq;
int missing_phys;
 };
 
@@ -331,6 +332,27 @@ static int sun4i_usb_phy_init(struct phy *_phy)
queue_delayed_work(system_wq, >detect, 0);
}
 
+   /* Some PHYs on some SoCs need the help of PHY2 to work. */
+   if (data->cfg->needs_phy2_siddq && phy->index != 2) {
+   struct sun4i_usb_phy *phy2 = >phys[2];
+
+   /*
+* This extra clock is just needed to access the
+* REG_HCI_PHY_CTL PMU register for PHY2.
+*/
+   ret = clk_prepare_enable(phy2->clk2);
+   if (ret)
+   return ret;
+
+   if (phy2->pmu && data->cfg->hci_phy_ctl_clear) {
+   val = readl(phy2->pmu + REG_HCI_PHY_CTL);
+   val &= ~data->cfg->hci_phy_ctl_clear;
+   writel(val, phy2->pmu + REG_HCI_PHY_CTL);
+   }
+
+   clk_disable_unprepare(phy->clk2);
+   }
+
return 0;
 }
 
@@ -785,6 +807,13 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
dev_err(dev, "failed to get clock %s\n", name);
return PTR_ERR(phy->clk2);
}
+   } else {
+   snprintf(name, sizeof(name), "pmu%d_clk", i);
+   phy->clk2 = devm_clk_get_optional(dev, name);
+   if (IS_ERR(phy->clk2)) {
+   dev_err(dev, "failed to get clock %s\n", name);
+   return PTR_ERR(phy->clk2);
+   }
}
 
snprintf(name, sizeof(name), "usb%d_reset", i);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-13-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 11/17] phy: sun4i-usb: Allow reset line to be shared

[Andre Przywara]

The USB HCIs (and PHYs?) in Allwinner's newer generation SoCs (H616)
rely on the reset line of USB PHY 2 to be de-asserted, even when only
one of the other PHYs is actually in use.

To make those ports work, we include this reset line in the HCIs' resets
property, which requires this line to be shareable.

Change the call to allocate the reset line to mark it as shared, to
enable the other ports on those SoCs.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 142f4cafdc78..126ef74d013c 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -788,7 +788,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
}
 
snprintf(name, sizeof(name), "usb%d_reset", i);
-   phy->reset = devm_reset_control_get(dev, name);
+   phy->reset = devm_reset_control_get_shared(dev, name);
if (IS_ERR(phy->reset)) {
dev_err(dev, "failed to get reset %s\n", name);
return PTR_ERR(phy->reset);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-12-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 10/17] phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling

[Andre Przywara]

As Icenowy pointed out, newer manuals (starting with H6) actually
document the register block at offset 0x800 as "HCI controller and PHY
interface", also describe the bits in our "PMU_UNK1" register.
Let's put proper names to those "unknown" variables and symbols.

While we are at it, generalise the existing code by allowing a bitmap
of bits to clear and set, to cover newer SoCs: The A100 and H616 use a
different bit for the SIDDQ control.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 30 ---
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 788dd5cdbb7d..142f4cafdc78 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -43,7 +43,7 @@
 #define REG_PHYCTL_A33 0x10
 #define REG_PHY_OTGCTL 0x20
 
-#define REG_PMU_UNK1   0x10
+#define REG_HCI_PHY_CTL0x10
 
 #define PHYCTL_DATABIT(7)
 
@@ -82,6 +82,7 @@
 /* A83T specific control bits for PHY0 */
 #define PHY_CTL_VBUSVLDEXT BIT(5)
 #define PHY_CTL_SIDDQ  BIT(3)
+#define PHY_CTL_H3_SIDDQ   BIT(1)
 
 /* A83T specific control bits for PHY2 HSIC */
 #define SUNXI_EHCI_HS_FORCEBIT(20)
@@ -115,9 +116,9 @@ struct sun4i_usb_phy_cfg {
int hsic_index;
enum sun4i_usb_phy_type type;
u32 disc_thresh;
+   u32 hci_phy_ctl_clear;
u8 phyctl_offset;
bool dedicated_clocks;
-   bool enable_pmu_unk1;
bool phy0_dual_route;
int missing_phys;
 };
@@ -288,6 +289,12 @@ static int sun4i_usb_phy_init(struct phy *_phy)
return ret;
}
 
+   if (phy->pmu && data->cfg->hci_phy_ctl_clear) {
+   val = readl(phy->pmu + REG_HCI_PHY_CTL);
+   val &= ~data->cfg->hci_phy_ctl_clear;
+   writel(val, phy->pmu + REG_HCI_PHY_CTL);
+   }
+
if (data->cfg->type == sun8i_a83t_phy ||
data->cfg->type == sun50i_h6_phy) {
if (phy->index == 0) {
@@ -297,11 +304,6 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val, data->base + data->cfg->phyctl_offset);
}
} else {
-   if (phy->pmu && data->cfg->enable_pmu_unk1) {
-   val = readl(phy->pmu + REG_PMU_UNK1);
-   writel(val & ~2, phy->pmu + REG_PMU_UNK1);
-   }
-
/* Enable USB 45 Ohm resistor calibration */
if (phy->index == 0)
sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
@@ -863,7 +865,6 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
@@ -872,7 +873,6 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
.disc_thresh = 2,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
@@ -881,7 +881,6 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
@@ -890,7 +889,6 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
.disc_thresh = 2,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
@@ -899,7 +897,6 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
@@ -908,7 +905,6 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
-   .enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a83t_cfg = {
@@ -925,7 +921,7 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
-   .enable_pmu_unk1 = true,
+   .hci_phy_ctl_clear = PHY_CTL_H3_SIDDQ,
.phy0_dual_route = true,
 };
 
@@ -935,7 +931,7 @@ static const struct sun4i_usb_phy_cfg sun8i_r40_cfg = {
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
-   .enable_pm

[linux-sunxi] [PATCH v6 09/17] dt-bindings: usb: sunxi-musb: Add H616 compatible string

[Andre Przywara]

The H616 MUSB peripheral is compatible to the H3 one (8 endpoints).

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml 
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
index 0f520f17735e..933fa356d2ce 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
@@ -22,6 +22,9 @@ properties:
   - allwinner,sun8i-a83t-musb
   - allwinner,sun50i-h6-musb
   - const: allwinner,sun8i-a33-musb
+  - items:
+  - const: allwinner,sun50i-h616-musb
+  - const: allwinner,sun8i-h3-musb
 
   reg:
 maxItems: 1
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-10-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string

[Andre Przywara]

The H616 has four PHYs as the H3, along with their respective clock
gates and resets, so the property description is identical.

However the PHYs itself need some special bits, so we need a new
compatible string for it.

Signed-off-by: Andre Przywara 
---
 .../devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml 
b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
index f80431060803..e288450e0844 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
@@ -15,7 +15,9 @@ properties:
 const: 1
 
   compatible:
-const: allwinner,sun8i-h3-usb-phy
+enum:
+  - allwinner,sun8i-h3-usb-phy
+  - allwinner,sun50i-h616-usb-phy
 
   reg:
 items:
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-9-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 07/17] net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register

[Andre Przywara]

The Allwinner H616 SoC has two EMAC controllers, with the second one
being tied to the internal PHY, but also using a separate EMAC clock
register.

To tell the driver about which clock register to use, we add a parameter
to our syscon phandle. The driver will use this value as an index into
the regmap, so that we can address more than the first register, if
needed.

Signed-off-by: Andre Przywara 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4422baeed3d8..5f3fefd9a74e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1147,11 +1147,13 @@ static int sun8i_dwmac_probe(struct platform_device 
*pdev)
struct stmmac_resources stmmac_res;
struct sunxi_priv_data *gmac;
struct device *dev = >dev;
+   struct reg_field syscon_field;
phy_interface_t interface;
int ret;
struct stmmac_priv *priv;
struct net_device *ndev;
struct regmap *regmap;
+   u32 syscon_idx = 0;
 
ret = stmmac_get_platform_resources(pdev, _res);
if (ret)
@@ -1209,8 +1211,12 @@ static int sun8i_dwmac_probe(struct platform_device 
*pdev)
return ret;
}
 
-   gmac->regmap_field = devm_regmap_field_alloc(dev, regmap,
-
*gmac->variant->syscon_field);
+   syscon_field = *gmac->variant->syscon_field;
+   ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1,
+_idx);
+   if (!ret)
+   syscon_field.reg += syscon_idx * sizeof(u32);
+   gmac->regmap_field = devm_regmap_field_alloc(dev, regmap, syscon_field);
if (IS_ERR(gmac->regmap_field)) {
ret = PTR_ERR(gmac->regmap_field);
dev_err(dev, "Unable to map syscon register: %d\n", ret);
@@ -1330,6 +1336,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
.data = _variant_a64 },
{ .compatible = "allwinner,sun50i-h6-emac",
.data = _variant_h6 },
+   { .compatible = "allwinner,sun50i-h616-emac",
+   .data = _variant_h6 },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-8-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing EMAC binding, and pair
it with the existing A64 fallback compatible string, as the devices are
compatible.

On the way use enums to group the compatible devices together.

Signed-off-by: Andre Przywara 
---
 .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml| 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml 
b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 7f2578d48e3f..0ccdab103f59 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -19,7 +19,9 @@ properties:
   - const: allwinner,sun8i-v3s-emac
   - const: allwinner,sun50i-a64-emac
   - items:
-  - const: allwinner,sun50i-h6-emac
+  - enum:
+  - allwinner,sun50i-h6-emac
+  - allwinner,sun50i-h616-emac
   - const: allwinner,sun50i-a64-emac
 
   reg:
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-7-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support

[Andre Przywara]

The H616 RTC changes its day storage to the newly introduced linear day
scheme, so pair the new compatible string with this feature flag.
So far the clock parts seem to be the same as the H6, so combine the
compatible string with the existing H6 support bits.

Signed-off-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 0228e9dfd969..ec0cd0ee539a 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -382,6 +382,8 @@ static void __init sun50i_h6_rtc_clk_init(struct 
device_node *node)
 }
 CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
  sun50i_h6_rtc_clk_init);
+CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
+ sun50i_h6_rtc_clk_init);
 
 /*
  * The R40 user manual is self-conflicting on whether the prescaler is
@@ -773,6 +775,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
{ .compatible = "allwinner,sun8i-v3-rtc" },
{ .compatible = "allwinner,sun50i-h5-rtc" },
{ .compatible = "allwinner,sun50i-h6-rtc" },
+   { .compatible = "allwinner,sun50i-h616-rtc",
+   .data = (void *)RTC_LINEAR_DAY },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-6-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 04/17] rtc: sun6i: Add support for linear day storage

[Andre Przywara]

Newer versions of the Allwinner RTC, as for instance found in the H616
SoC, no longer store a broken-down day/month/year representation in the
RTC_DAY_REG, but just a linear day number.
The user manual does not give any indication about the expected epoch
time of this day count, but the BSP kernel uses the UNIX epoch, which
allows easy support due to existing conversion functions in the kernel.

Allow tagging a compatible string with a flag, and use that to mark
those new RTCs. Then convert between a UNIX day number (converted into
seconds) and the broken-down day representation using mktime64() and
time64_to_tm() in the set_time/get_time functions.

That enables support for the RTC in those new chips.

Reviewed-by: Andre Przywara 
---
 drivers/rtc/rtc-sun6i.c | 58 +
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index adec1b14a8de..0228e9dfd969 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -133,12 +133,15 @@ struct sun6i_rtc_clk_data {
unsigned int has_auto_swt : 1;
 };
 
+#define RTC_LINEAR_DAY BIT(0)
+
 struct sun6i_rtc_dev {
struct rtc_device *rtc;
const struct sun6i_rtc_clk_data *data;
void __iomem *base;
int irq;
unsigned long alarm;
+   unsigned long flags;
 
struct clk_hw hw;
struct clk_hw *int_osc;
@@ -471,17 +474,30 @@ static int sun6i_rtc_gettime(struct device *dev, struct 
rtc_time *rtc_tm)
rtc_tm->tm_min  = SUN6I_TIME_GET_MIN_VALUE(time);
rtc_tm->tm_hour = SUN6I_TIME_GET_HOUR_VALUE(time);
 
-   rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
-   rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date);
-   rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
-
-   rtc_tm->tm_mon  -= 1;
-
-   /*
-* switch from (data_year->min)-relative offset to
-* a (1900)-relative one
-*/
-   rtc_tm->tm_year += SUN6I_YEAR_OFF;
+   if (chip->flags & RTC_LINEAR_DAY) {
+   struct tm tm;
+
+   /*
+* Newer chips store a linear day number, the manual
+* does not mandate any epoch base. The BSP driver uses
+* the UNIX epoch, let's just copy that, as it's the
+* easiest anyway.
+*/
+   time64_to_tm((date & 0x) * 3600ULL * 24, 0, );
+   rtc_tm->tm_mday = tm.tm_mday;
+   rtc_tm->tm_mon  = tm.tm_mon;
+   rtc_tm->tm_year = tm.tm_year;
+   } else {
+   rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
+   rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date) - 1;
+   rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
+
+   /*
+* switch from (data_year->min)-relative offset to
+* a (1900)-relative one
+*/
+   rtc_tm->tm_year += SUN6I_YEAR_OFF;
+   }
 
return 0;
 }
@@ -571,15 +587,21 @@ static int sun6i_rtc_settime(struct device *dev, struct 
rtc_time *rtc_tm)
u32 date = 0;
u32 time = 0;
 
-   rtc_tm->tm_year -= SUN6I_YEAR_OFF;
rtc_tm->tm_mon += 1;
 
-   date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
-   SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
-   SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
+   if (chip->flags & RTC_LINEAR_DAY) {
+   date = mktime64(rtc_tm->tm_year + 1900, rtc_tm->tm_mon,
+   rtc_tm->tm_mday, 0, 0, 0) / (3600ULL * 24);
+   } else {
+   rtc_tm->tm_year -= SUN6I_YEAR_OFF;
+
+   date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
+   SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
+   SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
 
-   if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
-   date |= SUN6I_LEAP_SET_VALUE(1);
+   if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
+   date |= SUN6I_LEAP_SET_VALUE(1);
+   }
 
time = SUN6I_TIME_SET_SEC_VALUE(rtc_tm->tm_sec)  |
SUN6I_TIME_SET_MIN_VALUE(rtc_tm->tm_min)  |
@@ -678,6 +700,8 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, chip);
 
+   chip->flags = (unsigned long)of_device_get_match_data(>dev);
+
chip->irq = platform_get_irq(pdev, 0);
if (chip->irq < 0)
return chip->irq;
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-5-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Andre Przywara]

Add the obvious compatible name to the existing RTC binding.
The actual RTC part of the device uses a different day/month/year
storage scheme, so it's not compatible with the previous devices.

Signed-off-by: Andre Przywara 
---
 .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index b1b0ee769b71..178c955f88bf 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -26,6 +26,7 @@ properties:
   - const: allwinner,sun50i-a64-rtc
   - const: allwinner,sun8i-h3-rtc
   - const: allwinner,sun50i-h6-rtc
+  - const: allwinner,sun50i-h616-rtc
 
   reg:
 maxItems: 1
@@ -97,7 +98,9 @@ allOf:
   properties:
 compatible:
   contains:
-const: allwinner,sun50i-h6-rtc
+enum:
+  - allwinner,sun50i-h6-rtc
+  - allwinner,sun50i-h616-rtc
 
 then:
   properties:
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-4-andre.przywara%40arm.com.

[linux-sunxi] [PATCH v6 02/17] mfd: axp20x: Allow AXP 806 chips without interrupt lines

[Andre Przywara]

Currently the AXP chip requires to have its IRQ line connected to some
interrupt controller, and will fail probing when this is not the case.

On a new Allwinner SoC (H616) there is no NMI pin anymore, and at
least one board does not connect the AXP's IRQ pin to anything else,
so the interrupt functionality of the AXP chip is simply not available.

Check whether the interrupt line number returned by the platform code is
valid, before trying to register the irqchip. If not, we skip this
registration, to avoid the driver to bail out completely.
Also we need to skip the power key functionality, as this relies on
a valid IRQ as well.

Signed-off-by: Andre Przywara 
---
 drivers/mfd/axp20x.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3eae04e24ac8..4145a38b3890 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -884,8 +884,13 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP806_ID:
+   /*
+* Don't register the power key part if in slave mode or
+* if there is no interrupt line.
+*/
if (of_property_read_bool(axp20x->dev->of_node,
- "x-powers,self-working-mode")) {
+ "x-powers,self-working-mode") &&
+   axp20x->irq > 0) {
axp20x->nr_cells = 
ARRAY_SIZE(axp806_self_working_cells);
axp20x->cells = axp806_self_working_cells;
} else {
@@ -959,12 +964,17 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
 AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE);
}
 
-   ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
- IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
-  -1, axp20x->regmap_irq_chip, >regmap_irqc);
-   if (ret) {
-   dev_err(axp20x->dev, "failed to add irq chip: %d\n", ret);
-   return ret;
+   /* Only if there is an interrupt line connected towards the CPU. */
+   if (axp20x->irq > 0) {
+   ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
+   IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
+   -1, axp20x->regmap_irq_chip,
+   >regmap_irqc);
+   if (ret) {
+   dev_err(axp20x->dev, "failed to add irq chip: %d\n",
+   ret);
+   return ret;
+   }
}
 
ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
-- 
2.17.5

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210519104152.21119-3-andre.przywara%40arm.com.