From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:22
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. This gains one fix patch for the existing RTC driver.
For a complete changelog, see below.
Based on 5.14-rc1. Let me know if you need a different base.
Relies on this pinctrl fix:
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-July/672813.html
Also available here: https://github.com/apritzel/linux/commits/h616-v8
Thanks!
Andre
==================
This series gathers patches to support the Allwinner H616 SoC. This is
a rather uninspired SoC (Quad-A53 with the usual peripherals), but
allows for some cheap development boards and TV boxes, and supports
up to 4GB of DRAM.
Some DT binding patches are sprinkled throughout the series, to add
the new compatible names right before they are used.
Patch 3-7 add support for the new RTC: the date is now stored as a
linear number, not broken down into day-month-year. The benefit is that
this lifts the limit of the old date counter, which would have rolled
over around 2032. Also the alarm setting is using the same storage
format as the current time, compared to the number of seconds left used
in existing SoCs.
Eventually we get the .dtsi for the SoC in patch 8, and the .dts for
the OrangePi Zero2 board[1] in the penultimate patch, followed by
the .dts for the X96 Mate TV box[2] in the final commit.
U-Boot and Trusted Firmware support is now merged in released versions,
it allows booting via FEL or SD card, also you can TFTP kernels in on
the OrangePi Zero 2 board.
Many thanks to Jernej for his tremendous help on this, also for the
awesome input and help from the #linux-sunxi Freenode channel.
The whole series (including the pinctrl fix) can also be found here:
https://github.com/apritzel/linux/commits/h616-v8
Happy reviewing!
Cheers,
Andre
[1] https://linux-sunxi.org/Orange_Pi_Zero_2
[2] https://linux-sunxi.org/X96_Mate
Changelog v7 .. v8:
- Rebase on top of 5.14-rc1, which already includes the previous v7 02/19
- Drop USB and Ethernet patches (to keep series small)
- Use "clocks: false" in RTC DT binding (2/11)
- Include fix for RTC overflow check (3/11)
- Use div_64() to avoid linking error on some 32-bit platforms (4+5/11)
- Adjust to changed RTC overflow check (5/11)
- Drop USB nodes from .dtsi file
- Move mmc-ddr-1_8v property from .dtsi file into board .dts
- Fix DTC warnings (underscore in node name, soc@0, #a-c in IRQ controllers)
Changelog v6 .. v7:
- Fix AXP305 binding documentation blunder (01/19)
- Improve new linear day support (use existing conversion functions) (04/19)
- Add support for changed RTC alarm registers (05/19)
- Add support for RTCs without a LOSC clock (06/19)
- Rework USB PHY2 SIDDQ quirk to use PHY clocks directly (14/19)
- Add X96 Mate compatible string to binding doc (17/19)
- Add Rob's ACKs
Changelog v5 .. v6:
- Drop already merged clock, pinctrl and MMC support from this series
- Properly fix AXP support by skipping power key initialisation
- Add patch to support new RTC date storage encoding
- Re-add USB HCI PHY refactoring
- Add patch to allow USB reset line sharing
- Add patch to introduce quirk for PHY2 SIDDQ clearing
- Re-add USB nodes to the .dtsi
- Add USB gadget support
- Add DT for X96 Mate TV box
Changelog v4 .. v5:
- Fix CCU binding to pass dtbs_check
- Add RSB compatible string to binding doc
- Rename IR pin name to pass dtbs_check
- Add EMAC compatible string to binding doc
- Drop USB PHY support and binding doc patches
- Drop USB nodes from .dtsi and .dts
- Drop second EMAC node from .dtsi
Changelog v3 .. v4:
- Drop MMC and pinctrl matches (already in some -next trees)
- Add Maxime's Acks
- Add patch to update the AXP MFD DT bindings
- Add new patch (05/21) to fix axp20x-pek driver
- Change AXP IRQ fix to check for invalid IRQ line number
- Split joint DT bindings patch (v3 18/21) into subsystems
- move dwmac variable to keep christmas tree
- Use enums for USB PHY compatible strings in DT binding
- Enable watchdog (briefly verified to work)
- Add PHY2 to HCI1&3, this fixes USB
- limit r-ccu register frame length to not collide with NMI controller
- add interrupt-controller property to AXP DT node
Changelog v2 .. v3:
- Add Rob's Acks
- Drop redundant maxItems from pinctrl DT binding
- Rename h_i2s* to just i2s* in pinctrl names
- Use more declarative i2s0_d{in,out}{0,1} names
- Add RSB pins to pinctrl
- Include RSB clocks (sharing with newly added H6 versions)
- Fix CEC clock (add 2nd enable bit, also fix predivider flag)
- Rename PMU_UNK1 register in USB PHY
- Add USB and MUSB DT binding patches
- Add MMC/SD speed modes to .dtsi
Changelog 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 (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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:25
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 <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
@@ -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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Lee Jones <hidden> Date: 2021-08-16 12:42:12
On Fri, 23 Jul 2021, 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 <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:26
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 <andre.przywara@arm.com>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 22:34:22
On Fri, 23 Jul 2021 16:38:29 +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 <andre.przywara@arm.com>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
From: Maxime Ripard <hidden> Date: 2021-07-26 14:41:46
Hi,
On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
quoted hunk
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 <andre.przywara@arm.com>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
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?
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?
Maxime
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-08-02 00:40:25
On Mon, 26 Jul 2021 16:41:37 +0200
Maxime Ripard [off-list ref] wrote:
Hi,
On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
quoted
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 <andre.przywara@arm.com>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Maxime Ripard <hidden> Date: 2021-08-17 07:38:18
Hi,
On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
On Mon, 26 Jul 2021 16:41:37 +0200
Maxime Ripard [off-list ref] wrote:
quoted
Hi,
On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
quoted
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 <andre.przywara@arm.com>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
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
Either way, what this list is must be documented.
quoted
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
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
Shouldn't they be exposed to be able to use assigned-clock?
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Maxime Ripard <hidden> Date: 2021-08-19 07:56:37
Salut Alex,
On Tue, Aug 17, 2021 at 10:13:11AM +0200, Alexandre Belloni wrote:
On 17/08/2021 09:38:10+0200, Maxime Ripard wrote:
quoted
quoted
quoted
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
Shouldn't they be exposed to be able to use assigned-clock?
I'm not sure we would even need that? If it's an internal clock to the
RTC, then we probably won't ever need to change it from the device tree?
Maxime
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-08-18 09:04:21
On Tue, 17 Aug 2021 09:38:10 +0200
Maxime Ripard [off-list ref] wrote:
Hi Maxime,
On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
quoted
On Mon, 26 Jul 2021 16:41:37 +0200
Maxime Ripard [off-list ref] wrote:
quoted
Hi,
On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
quoted
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 <andre.przywara@arm.com>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
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
quoted
quoted
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
From: Samuel Holland <samuel@sholland.org> Date: 2021-08-20 03:57:25
On 8/18/21 4:04 AM, Andre Przywara wrote:
On Tue, 17 Aug 2021 09:38:10 +0200
Maxime Ripard [off-list ref] wrote:
Hi Maxime,
quoted
On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
quoted
On Mon, 26 Jul 2021 16:41:37 +0200
Maxime Ripard [off-list ref] wrote:
quoted
Hi,
On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
quoted
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 <andre.przywara@arm.com>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
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?
I'm pretty sure this is the debounce for the NMI and the SoC reset signal, not
the pinctrl. The pinctrl debounce clock pretty clearly references 32 kHz.
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.
Plus RC16M/IOSC (and depending on how you look at it, DCXO24M/HOSC).
quoted
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
quoted
quoted
quoted
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?
Do you suggest we fix this for the existing bindings?
quoted
quoted
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?
This is my fault for not sending anything yet. Since the initial version of the
driver had the RTC providing HOSC, it depended on converting the existing A100,
H6, and H616 CCU drivers to use .fw_name for parents, since those drivers
hardcode two different global names for HOSC. And I had no opportunit to do that
yet.
However, I should really send something that 100% matches the current binding
for SoCs where that exists (i.e. osc24M is a fixed clock), and doing so is a
smaller job.
On the other hand, having osc24M as an RTC *output* neatly sidesteps the fact
that it has been missing from the input list :)
(But on the other-other hand, A50 gets even more fun, as the HOSC crystal may
not be 24MHz anymore. So the RTC has to choose one of three possible HOSC->LOSC
dividers based on the HOSC frequency. But there is no register for HOSC
frequency. So in this case it is convenient to have HOSC as a separate fixed
clock input.)
The basic idea of my patch is that using the CCU library code lets us cleanly
have slightly different clock trees for each of the RTC variants that Allwinner
comes up with.
The secondary goal is to add support for osc32k calibration.
An early version of the patch is here[1], and I will send something as soon as I
have made the modifications described above. But I know you were skeptical about
moving the clock part out of the RTC driver. So if you NACK that, somebody will
have to add all of the variants to the RTC driver.
Regards,
Samuel
[1]: https://github.com/smaeul/linux/commit/9510ca9e95cb.patch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Maxime Ripard <hidden> Date: 2021-09-01 07:21:40
On Wed, Aug 18, 2021 at 10:04:07AM +0100, Andre Przywara wrote:
On Tue, 17 Aug 2021 09:38:10 +0200
Maxime Ripard [off-list ref] wrote:
Hi Maxime,
quoted
On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
quoted
On Mon, 26 Jul 2021 16:41:37 +0200
Maxime Ripard [off-list ref] wrote:
quoted
Hi,
On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
quoted
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 <andre.przywara@arm.com>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
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?
I don't think that's it.
The Debounce circuit is after the 32 divider, so we have a clock rate of
1kHz (Figure 3-35, page 275)
The PIO Interrupt debouncing can use either a 32kHz or 24MHz clock, so
the rates don't match, and given the naming would rather be clocked from
CLK32K_LOSC.
The DCXO_CTRL_REG (Section 3.13.6.13) hints at something different
though, it says:
"
CLK16M_RC_EN
1: Enable
0: Disable
The related register configuration is necessary to ensure the reset debounce
circuit has a stable clock source.
The first time SoC starts up, by default, the reset debounce circuit of SoC
uses 32K divided by RC16M. In power-off, software reads the related bit to
ensure whether EXT32K is working normally, if it is normal, first switch the
clock source of debounce circuit to EXT32K, then close RC16M.
Without EXT32K scenario or external RTC scenario, software confirms firstly
whether EXT32K is working normally before switching, or software does not
close RC16M.
"
I'm not sure why it would be useful for though
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.
My concern is the pretty much the opposite: if we ever need to remove it
for whatever reason, if it's in the DT, we can't. While we can totally
add it if we need it.
quoted
Either way, what this list is must be documented.
You mean to overwrite the "description" stanza for clock-output-names?
Yes
And can this be done in the per-SoC parts in the later part of the
binding, keeping the existing description?
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:30
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
@@ -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;}
Hi Andre!
Dne petek, 23. julij 2021 ob 17:38:30 CEST je Andre Przywara napisal(a):
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:32
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 66 +++++++++++++++++++++++++++--------------
1 file changed, 44 insertions(+), 22 deletions(-)
Hi Andre!
Dne petek, 23. julij 2021 ob 17:38:31 CEST je Andre Przywara napisal(a):
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 66 +++++++++++++++++++++++++++--------------
1 file changed, 44 insertions(+), 22 deletions(-)
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:35
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 60 +++++++++++++++++++++++++++++------------
1 file changed, 43 insertions(+), 17 deletions(-)
@@ -523,32 +524,57 @@ static int sun6i_rtc_setalarm(struct device *dev, struct rtc_wkalrm *wkalrm)structsun6i_rtc_dev*chip=dev_get_drvdata(dev);structrtc_time*alrm_tm=&wkalrm->time;structrtc_timetm_now;-time64_ttime_now,time_set;+time64_ttime_set;+u32counter_val,counter_val_hms;intret;-ret=sun6i_rtc_gettime(dev,&tm_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(&tm_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_tseconds;++/*+*Thealarmregistersholdtheactualalarmtime,encoded+*inthesameway(linearday+HMS)asthecurrenttime.+*/+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_ttime_now;++ret=sun6i_rtc_gettime(dev,&tm_now);+if(ret<0){+dev_err(dev,"Error in getting time\n");+return-EINVAL;+}++time_now=rtc_tm_to_time64(&tm_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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Andre!
Dne petek, 23. julij 2021 ob 17:38:32 CEST je Andre Przywara napisal(a):
quoted hunk
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 60 +++++++++++++++++++++++++++++------------
1 file changed, 43 insertions(+), 17 deletions(-)
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. 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.
Once fixed:
Reviewed by: Jernej Skrabec [off-list ref]
Best regards,
Jernej
+ 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, &tm_now);
+ if (ret < 0) {
+ dev_err(dev, "Error in getting time\n");
+ return -EINVAL;
+ }
+
+ time_now = rtc_tm_to_time64(&tm_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 +
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-08-02 00:39:49
On Sun, 25 Jul 2021 08:11:49 +0200
Jernej Škrabec [off-list ref] wrote:
Hi Jernej,
Dne petek, 23. julij 2021 ob 17:38:32 CEST je Andre Przywara napisal(a):
quoted
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 60 +++++++++++++++++++++++++++++------------
1 file changed, 43 insertions(+), 17 deletions(-)
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 [off-list ref]
Many thanks for the reviews!
Cheers,
Andre
quoted
+ counter_val = div_u64(seconds, SECS_PER_DAY);
+ } else {
+ /* The alarm register holds the number of seconds left.
*/
quoted
+ time64_t time_now;
+
+ ret = sun6i_rtc_gettime(dev, &tm_now);
+ if (ret < 0) {
+ dev_err(dev, "Error in getting time\n");
+ return -EINVAL;
+ }
+
+ time_now = rtc_tm_to_time64(&tm_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 +
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:37
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
@@ -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;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,&init.name);
--
2.17.6
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Andre!
Dne petek, 23. julij 2021 ob 17:38:33 CEST je Andre Przywara napisal(a):
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:41
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 <andre.przywara@arm.com>
---
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 575 ++++++++++++++++++
1 file changed, 575 insertions(+)
create mode 100644 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 <icenowy@aosc.io>++#include<dt-bindings/interrupt-controller/arm-gic.h>+#include<dt-bindings/clock/sun50i-h616-ccu.h>+#include<dt-bindings/clock/sun50i-h6-r-ccu.h>+#include<dt-bindings/reset/sun50i-h616-ccu.h>+#include<dt-bindings/reset/sun50i-h6-r-ccu.h>++/{+interrupt-parent=<&gic>;+#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=<&ccuCLK_CPUX>;+};++cpu1:cpu@1{+compatible="arm,cortex-a53";+device_type="cpu";+reg=<1>;+enable-method="psci";+clocks=<&ccuCLK_CPUX>;+};++cpu2:cpu@2{+compatible="arm,cortex-a53";+device_type="cpu";+reg=<2>;+enable-method="psci";+clocks=<&ccuCLK_CPUX>;+};++cpu3:cpu@3{+compatible="arm,cortex-a53";+device_type="cpu";+reg=<3>;+enable-method="psci";+clocks=<&ccuCLK_CPUX>;+};+};++reserved-memory{+#address-cells=<2>;+#size-cells=<2>;+ranges;++/* 512KiB reserved for ARM Trusted Firmware (BL31) */+secmon_reserved:secmon@40000000{+reg=<0x00x400000000x00x80000>;+no-map;+};+};++osc24M:osc24M-clk{+#clock-cells=<0>;+compatible="fixed-clock";+clock-frequency=<24000000>;+clock-output-names="osc24M";+};++pmu{+compatible="arm,cortex-a53-pmu";+interrupts=<GIC_SPI140IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI141IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI142IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI143IRQ_TYPE_LEVEL_HIGH>;+interrupt-affinity=<&cpu0>,<&cpu1>,<&cpu2>,<&cpu3>;+};++psci{+compatible="arm,psci-0.2";+method="smc";+};++timer{+compatible="arm,armv8-timer";+arm,no-tick-in-suspend;+interrupts=<GIC_PPI13+(GIC_CPU_MASK_SIMPLE(4)|IRQ_TYPE_LEVEL_HIGH)>,+<GIC_PPI14+(GIC_CPU_MASK_SIMPLE(4)|IRQ_TYPE_LEVEL_HIGH)>,+<GIC_PPI11+(GIC_CPU_MASK_SIMPLE(4)|IRQ_TYPE_LEVEL_HIGH)>,+<GIC_PPI10+(GIC_CPU_MASK_SIMPLE(4)|IRQ_TYPE_LEVEL_HIGH)>;+};++soc@0{+compatible="simple-bus";+#address-cells=<1>;+#size-cells=<1>;+ranges=<0x00x00x00x40000000>;++syscon:syscon@3000000{+compatible="allwinner,sun50i-h616-system-control";+reg=<0x030000000x1000>;+#address-cells=<1>;+#size-cells=<1>;+ranges;++sram_c:sram@28000{+compatible="mmio-sram";+reg=<0x000280000x30000>;+#address-cells=<1>;+#size-cells=<1>;+ranges=<00x000280000x30000>;+};+};++ccu:clock@3001000{+compatible="allwinner,sun50i-h616-ccu";+reg=<0x030010000x1000>;+clocks=<&osc24M>,<&rtc0>,<&rtc2>;+clock-names="hosc","losc","iosc";+#clock-cells=<1>;+#reset-cells=<1>;+};++watchdog:watchdog@30090a0{+compatible="allwinner,sun50i-h616-wdt",+"allwinner,sun6i-a31-wdt";+reg=<0x030090a00x20>;+interrupts=<GIC_SPI50IRQ_TYPE_LEVEL_HIGH>;+clocks=<&osc24M>;+status="okay";+};++pio:pinctrl@300b000{+compatible="allwinner,sun50i-h616-pinctrl";+reg=<0x0300b0000x400>;+interrupts=<GIC_SPI51IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI52IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI53IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI43IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI54IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI55IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI56IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI57IRQ_TYPE_LEVEL_HIGH>;+clocks=<&ccuCLK_APB1>,<&osc24M>,<&rtc0>;+clock-names="apb","hosc","losc";+gpio-controller;+#gpio-cells=<3>;+interrupt-controller;+#interrupt-cells=<3>;+#address-cells=<0>;++ext_rgmii_pins:rgmii-pins{+pins="PI0","PI1","PI2","PI3","PI4",+"PI5","PI7","PI8","PI9","PI10",+"PI11","PI12","PI13","PI14","PI15",+"PI16";+function="emac0";+drive-strength=<40>;+};++i2c0_pins:i2c0-pins{+pins="PI6","PI7";+function="i2c0";+};++i2c3_ph_pins:i2c3-ph-pins{+pins="PH4","PH5";+function="i2c3";+};++ir_rx_pin:ir-rx-pin{+pins="PH10";+function="ir_rx";+};++mmc0_pins:mmc0-pins{+pins="PF0","PF1","PF2","PF3",+"PF4","PF5";+function="mmc0";+drive-strength=<30>;+bias-pull-up;+};++mmc1_pins:mmc1-pins{+pins="PG0","PG1","PG2","PG3",+"PG4","PG5";+function="mmc1";+drive-strength=<30>;+bias-pull-up;+};++mmc2_pins:mmc2-pins{+pins="PC0","PC1","PC5","PC6",+"PC8","PC9","PC10","PC11",+"PC13","PC14","PC15","PC16";+function="mmc2";+drive-strength=<30>;+bias-pull-up;+};++spi0_pins:spi0-pins{+pins="PC0","PC2","PC3","PC4";+function="spi0";+};++spi1_pins:spi1-pins{+pins="PH6","PH7","PH8";+function="spi1";+};++spi1_cs_pin:spi1-cs-pin{+pins="PH5";+function="spi1";+};++uart0_ph_pins:uart0-ph-pins{+pins="PH0","PH1";+function="uart0";+};++uart1_pins:uart1-pins{+pins="PG6","PG7";+function="uart1";+};++uart1_rts_cts_pins:uart1-rts-cts-pins{+pins="PG8","PG9";+function="uart1";+};+};++gic:interrupt-controller@3021000{+compatible="arm,gic-400";+reg=<0x030210000x1000>,+<0x030220000x2000>,+<0x030240000x2000>,+<0x030260000x2000>;+interrupts=<GIC_PPI9(GIC_CPU_MASK_SIMPLE(4)|IRQ_TYPE_LEVEL_HIGH)>;+interrupt-controller;+#interrupt-cells=<3>;+#address-cells=<0>;+};++mmc0:mmc@4020000{+compatible="allwinner,sun50i-h616-mmc",+"allwinner,sun50i-a100-mmc";+reg=<0x040200000x1000>;+clocks=<&ccuCLK_BUS_MMC0>,<&ccuCLK_MMC0>;+clock-names="ahb","mmc";+resets=<&ccuRST_BUS_MMC0>;+reset-names="ahb";+interrupts=<GIC_SPI35IRQ_TYPE_LEVEL_HIGH>;+pinctrl-names="default";+pinctrl-0=<&mmc0_pins>;+status="disabled";+max-frequency=<150000000>;+cap-sd-highspeed;+cap-mmc-highspeed;+mmc-ddr-3_3v;+cap-sdio-irq;+#address-cells=<1>;+#size-cells=<0>;+};++mmc1:mmc@4021000{+compatible="allwinner,sun50i-h616-mmc",+"allwinner,sun50i-a100-mmc";+reg=<0x040210000x1000>;+clocks=<&ccuCLK_BUS_MMC1>,<&ccuCLK_MMC1>;+clock-names="ahb","mmc";+resets=<&ccuRST_BUS_MMC1>;+reset-names="ahb";+interrupts=<GIC_SPI36IRQ_TYPE_LEVEL_HIGH>;+pinctrl-names="default";+pinctrl-0=<&mmc1_pins>;+status="disabled";+max-frequency=<150000000>;+cap-sd-highspeed;+cap-mmc-highspeed;+mmc-ddr-3_3v;+cap-sdio-irq;+#address-cells=<1>;+#size-cells=<0>;+};++mmc2:mmc@4022000{+compatible="allwinner,sun50i-h616-emmc",+"allwinner,sun50i-a100-emmc";+reg=<0x040220000x1000>;+clocks=<&ccuCLK_BUS_MMC2>,<&ccuCLK_MMC2>;+clock-names="ahb","mmc";+resets=<&ccuRST_BUS_MMC2>;+reset-names="ahb";+interrupts=<GIC_SPI37IRQ_TYPE_LEVEL_HIGH>;+pinctrl-names="default";+pinctrl-0=<&mmc2_pins>;+status="disabled";+max-frequency=<150000000>;+cap-sd-highspeed;+cap-mmc-highspeed;+mmc-ddr-3_3v;+cap-sdio-irq;+#address-cells=<1>;+#size-cells=<0>;+};++uart0:serial@5000000{+compatible="snps,dw-apb-uart";+reg=<0x050000000x400>;+interrupts=<GIC_SPI0IRQ_TYPE_LEVEL_HIGH>;+reg-shift=<2>;+reg-io-width=<4>;+clocks=<&ccuCLK_BUS_UART0>;+resets=<&ccuRST_BUS_UART0>;+status="disabled";+};++uart1:serial@5000400{+compatible="snps,dw-apb-uart";+reg=<0x050004000x400>;+interrupts=<GIC_SPI1IRQ_TYPE_LEVEL_HIGH>;+reg-shift=<2>;+reg-io-width=<4>;+clocks=<&ccuCLK_BUS_UART1>;+resets=<&ccuRST_BUS_UART1>;+status="disabled";+};++uart2:serial@5000800{+compatible="snps,dw-apb-uart";+reg=<0x050008000x400>;+interrupts=<GIC_SPI2IRQ_TYPE_LEVEL_HIGH>;+reg-shift=<2>;+reg-io-width=<4>;+clocks=<&ccuCLK_BUS_UART2>;+resets=<&ccuRST_BUS_UART2>;+status="disabled";+};++uart3:serial@5000c00{+compatible="snps,dw-apb-uart";+reg=<0x05000c000x400>;+interrupts=<GIC_SPI3IRQ_TYPE_LEVEL_HIGH>;+reg-shift=<2>;+reg-io-width=<4>;+clocks=<&ccuCLK_BUS_UART3>;+resets=<&ccuRST_BUS_UART3>;+status="disabled";+};++uart4:serial@5001000{+compatible="snps,dw-apb-uart";+reg=<0x050010000x400>;+interrupts=<GIC_SPI4IRQ_TYPE_LEVEL_HIGH>;+reg-shift=<2>;+reg-io-width=<4>;+clocks=<&ccuCLK_BUS_UART4>;+resets=<&ccuRST_BUS_UART4>;+status="disabled";+};++uart5:serial@5001400{+compatible="snps,dw-apb-uart";+reg=<0x050014000x400>;+interrupts=<GIC_SPI5IRQ_TYPE_LEVEL_HIGH>;+reg-shift=<2>;+reg-io-width=<4>;+clocks=<&ccuCLK_BUS_UART5>;+resets=<&ccuRST_BUS_UART5>;+status="disabled";+};++i2c0:i2c@5002000{+compatible="allwinner,sun50i-h616-i2c",+"allwinner,sun6i-a31-i2c";+reg=<0x050020000x400>;+interrupts=<GIC_SPI6IRQ_TYPE_LEVEL_HIGH>;+clocks=<&ccuCLK_BUS_I2C0>;+resets=<&ccuRST_BUS_I2C0>;+pinctrl-names="default";+pinctrl-0=<&i2c0_pins>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};++i2c1:i2c@5002400{+compatible="allwinner,sun50i-h616-i2c",+"allwinner,sun6i-a31-i2c";+reg=<0x050024000x400>;+interrupts=<GIC_SPI7IRQ_TYPE_LEVEL_HIGH>;+clocks=<&ccuCLK_BUS_I2C1>;+resets=<&ccuRST_BUS_I2C1>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};++i2c2:i2c@5002800{+compatible="allwinner,sun50i-h616-i2c",+"allwinner,sun6i-a31-i2c";+reg=<0x050028000x400>;+interrupts=<GIC_SPI8IRQ_TYPE_LEVEL_HIGH>;+clocks=<&ccuCLK_BUS_I2C2>;+resets=<&ccuRST_BUS_I2C2>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};++i2c3:i2c@5002c00{+compatible="allwinner,sun50i-h616-i2c",+"allwinner,sun6i-a31-i2c";+reg=<0x05002c000x400>;+interrupts=<GIC_SPI9IRQ_TYPE_LEVEL_HIGH>;+clocks=<&ccuCLK_BUS_I2C3>;+resets=<&ccuRST_BUS_I2C3>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};++i2c4:i2c@5003000{+compatible="allwinner,sun50i-h616-i2c",+"allwinner,sun6i-a31-i2c";+reg=<0x050030000x400>;+interrupts=<GIC_SPI10IRQ_TYPE_LEVEL_HIGH>;+clocks=<&ccuCLK_BUS_I2C4>;+resets=<&ccuRST_BUS_I2C4>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};++spi0:spi@5010000{+compatible="allwinner,sun50i-h616-spi",+"allwinner,sun8i-h3-spi";+reg=<0x050100000x1000>;+interrupts=<GIC_SPI12IRQ_TYPE_LEVEL_HIGH>;+clocks=<&ccuCLK_BUS_SPI0>,<&ccuCLK_SPI0>;+clock-names="ahb","mod";+resets=<&ccuRST_BUS_SPI0>;+pinctrl-names="default";+pinctrl-0=<&spi0_pins>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};++spi1:spi@5011000{+compatible="allwinner,sun50i-h616-spi",+"allwinner,sun8i-h3-spi";+reg=<0x050110000x1000>;+interrupts=<GIC_SPI13IRQ_TYPE_LEVEL_HIGH>;+clocks=<&ccuCLK_BUS_SPI1>,<&ccuCLK_SPI1>;+clock-names="ahb","mod";+resets=<&ccuRST_BUS_SPI1>;+pinctrl-names="default";+pinctrl-0=<&spi1_pins>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};++emac0:ethernet@5020000{+compatible="allwinner,sun50i-h616-emac",+"allwinner,sun50i-a64-emac";+syscon=<&syscon>;+reg=<0x050200000x10000>;+interrupts=<GIC_SPI14IRQ_TYPE_LEVEL_HIGH>;+interrupt-names="macirq";+resets=<&ccuRST_BUS_EMAC0>;+reset-names="stmmaceth";+clocks=<&ccuCLK_BUS_EMAC0>;+clock-names="stmmaceth";+status="disabled";++mdio0:mdio{+compatible="snps,dwmac-mdio";+#address-cells=<1>;+#size-cells=<0>;+};+};++rtc:rtc@7000000{+compatible="allwinner,sun50i-h616-rtc";+reg=<0x070000000x400>;+interrupts=<GIC_SPI101IRQ_TYPE_LEVEL_HIGH>,+<GIC_SPI102IRQ_TYPE_LEVEL_HIGH>;+clock-output-names="osc32k","osc32k-out","iosc";+#clock-cells=<1>;+};++r_ccu:clock@7010000{+compatible="allwinner,sun50i-h616-r-ccu";+reg=<0x070100000x210>;+clocks=<&osc24M>,<&rtc0>,<&rtc2>,+<&ccuCLK_PLL_PERIPH0>;+clock-names="hosc","losc","iosc","pll-periph";+#clock-cells=<1>;+#reset-cells=<1>;+};++r_pio:pinctrl@7022000{+compatible="allwinner,sun50i-h616-r-pinctrl";+reg=<0x070220000x400>;+interrupts=<GIC_SPI43IRQ_TYPE_LEVEL_HIGH>;+clocks=<&r_ccuCLK_R_APB1>,<&osc24M>,<&rtc0>;+clock-names="apb","hosc","losc";+gpio-controller;+#gpio-cells=<3>;+interrupt-controller;+#interrupt-cells=<3>;+#address-cells=<0>;++r_i2c_pins:r-i2c-pins{+pins="PL0","PL1";+function="s_i2c";+};++r_rsb_pins:r-rsb-pins{+pins="PL0","PL1";+function="s_rsb";+};+};++ir:ir@7040000{+compatible="allwinner,sun50i-h616-ir",+"allwinner,sun6i-a31-ir";+reg=<0x070400000x400>;+interrupts=<GIC_SPI106IRQ_TYPE_LEVEL_HIGH>;+clocks=<&r_ccuCLK_R_APB1_IR>,+<&r_ccuCLK_IR>;+clock-names="apb","ir";+resets=<&r_ccuRST_R_APB1_IR>;+pinctrl-names="default";+pinctrl-0=<&ir_rx_pin>;+status="disabled";+};++r_i2c:i2c@7081400{+compatible="allwinner,sun50i-h616-i2c",+"allwinner,sun6i-a31-i2c";+reg=<0x070814000x400>;+interrupts=<GIC_SPI105IRQ_TYPE_LEVEL_HIGH>;+clocks=<&r_ccuCLK_R_APB2_I2C>;+resets=<&r_ccuRST_R_APB2_I2C>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};++r_rsb:rsb@7083000{+compatible="allwinner,sun50i-h616-rsb",+"allwinner,sun8i-a23-rsb";+reg=<0x070830000x400>;+interrupts=<GIC_SPI109IRQ_TYPE_LEVEL_HIGH>;+clocks=<&r_ccuCLK_R_APB2_RSB>;+clock-frequency=<3000000>;+resets=<&r_ccuRST_R_APB2_RSB>;+pinctrl-names="default";+pinctrl-0=<&r_rsb_pins>;+status="disabled";+#address-cells=<1>;+#size-cells=<0>;+};+};+};
--
2.17.6
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:43
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Hi Andre!
Dne petek, 23. julij 2021 ob 17:38:34 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.
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 <andre.przywara@arm.com>
---
drivers/rtc/rtc-sun6i.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:50
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 <andre.przywara@arm.com>
---
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
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-07-23 15:39:53
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 <andre.przywara@arm.com>
---
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
@@ -0,0 +1,178 @@+// SPDX-License-Identifier: (GPL-2.0+ or MIT)+/*+*Copyright(C)2021ArmLtd.+*/++/dts-v1/;++#include"sun50i-h616.dtsi"++#include<dt-bindings/gpio/gpio.h>+#include<dt-bindings/interrupt-controller/arm-gic.h>++/{+model="X96 Mate";+compatible="hechuang,x96-mate","allwinner,sun50i-h616";++aliases{+serial0=&uart0;+};++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=<5000000>;+regulator-max-microvolt=<5000000>;+regulator-always-on;+};+};++&ir{+status="okay";+};++&mmc0{+vmmc-supply=<®_dcdce>;+cd-gpios=<&pio56GPIO_ACTIVE_LOW>;/* PF6 */+bus-width=<4>;+status="okay";+};++&mmc2{+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";+};++&r_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=<3300000>;+regulator-max-microvolt=<3300000>;+regulator-name="vcc-sys";+};++/* Enabled by the Android BSP */+reg_aldo2:aldo2{+regulator-min-microvolt=<3300000>;+regulator-max-microvolt=<3300000>;+regulator-name="vcc3v3-ext";+status="disabled";+};++/* Enabled by the Android BSP */+reg_aldo3:aldo3{+regulator-min-microvolt=<3300000>;+regulator-max-microvolt=<3300000>;+regulator-name="vcc3v3-ext2";+status="disabled";+};++reg_bldo1:bldo1{+regulator-always-on;+regulator-min-microvolt=<1800000>;+regulator-max-microvolt=<1800000>;+regulator-name="vcc1v8";+};++/* Enabled by the Android BSP */+reg_bldo2:bldo2{+regulator-min-microvolt=<1800000>;+regulator-max-microvolt=<1800000>;+regulator-name="vcc1v8-2";+status="disabled";+};++bldo3{+/* unused */+};++bldo4{+/* unused */+};++cldo1{+regulator-min-microvolt=<2500000>;+regulator-max-microvolt=<2500000>;+regulator-name="vcc2v5";+};++cldo2{+/* unused */+};++cldo3{+/* unused */+};++reg_dcdca:dcdca{+regulator-always-on;+regulator-min-microvolt=<810000>;+regulator-max-microvolt=<1080000>;+regulator-name="vdd-cpu";+};++reg_dcdcc:dcdcc{+regulator-always-on;+regulator-min-microvolt=<810000>;+regulator-max-microvolt=<1080000>;+regulator-name="vdd-gpu-sys";+};++reg_dcdcd:dcdcd{+regulator-always-on;+regulator-min-microvolt=<1360000>;+regulator-max-microvolt=<1360000>;+regulator-name="vdd-dram";+};++reg_dcdce:dcdce{+regulator-boot-on;+regulator-min-microvolt=<3300000>;+regulator-max-microvolt=<3300000>;+regulator-name="vcc-eth-mmc";+};++sw{+/* unused */+};+};+};+};++&uart0{+pinctrl-names="default";+pinctrl-0=<&uart0_ph_pins>;+status="okay";+};
--
2.17.6
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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. This gains one fix patch for the existing RTC driver.
Well, I think RTC is really a fundmental part of SoC support now.
I think if I post my R329 patchset, it will depend on this patchset's
RTC part (R329 has linear day too, although it still has external LOSC
(and even LOSC fanout) ).
BTW Thanks for your code ;-)
For a complete changelog, see below.
Based on 5.14-rc1. Let me know if you need a different base.
Relies on this pinctrl fix:
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-July/672813.html
Also available here:
https://github.com/apritzel/linux/commits/h616-v8
Thanks!
Andre
==================
This series gathers patches to support the Allwinner H616 SoC. This
is
a rather uninspired SoC (Quad-A53 with the usual peripherals), but
allows for some cheap development boards and TV boxes, and supports
up to 4GB of DRAM.
Some DT binding patches are sprinkled throughout the series, to add
the new compatible names right before they are used.
Patch 3-7 add support for the new RTC: the date is now stored as a
linear number, not broken down into day-month-year. The benefit is
that
this lifts the limit of the old date counter, which would have rolled
over around 2032. Also the alarm setting is using the same storage
format as the current time, compared to the number of seconds left
used
in existing SoCs.
Eventually we get the .dtsi for the SoC in patch 8, and the .dts for
the OrangePi Zero2 board[1] in the penultimate patch, followed by
the .dts for the X96 Mate TV box[2] in the final commit.
U-Boot and Trusted Firmware support is now merged in released
versions,
it allows booting via FEL or SD card, also you can TFTP kernels in on
the OrangePi Zero 2 board.
Many thanks to Jernej for his tremendous help on this, also for the
awesome input and help from the #linux-sunxi Freenode channel.
The whole series (including the pinctrl fix) can also be found here:
https://github.com/apritzel/linux/commits/h616-v8
Happy reviewing!
Cheers,
Andre
[1] https://linux-sunxi.org/Orange_Pi_Zero_2
[2] https://linux-sunxi.org/X96_Mate
Changelog v7 .. v8:
- Rebase on top of 5.14-rc1, which already includes the previous v7
02/19
- Drop USB and Ethernet patches (to keep series small)
- Use "clocks: false" in RTC DT binding (2/11)
- Include fix for RTC overflow check (3/11)
- Use div_64() to avoid linking error on some 32-bit platforms
(4+5/11)
- Adjust to changed RTC overflow check (5/11)
- Drop USB nodes from .dtsi file
- Move mmc-ddr-1_8v property from .dtsi file into board .dts
- Fix DTC warnings (underscore in node name, soc@0, #a-c in IRQ
controllers)
Changelog v6 .. v7:
- Fix AXP305 binding documentation blunder (01/19)
- Improve new linear day support (use existing conversion functions)
(04/19)
- Add support for changed RTC alarm registers (05/19)
- Add support for RTCs without a LOSC clock (06/19)
- Rework USB PHY2 SIDDQ quirk to use PHY clocks directly (14/19)
- Add X96 Mate compatible string to binding doc (17/19)
- Add Rob's ACKs
Changelog v5 .. v6:
- Drop already merged clock, pinctrl and MMC support from this series
- Properly fix AXP support by skipping power key initialisation
- Add patch to support new RTC date storage encoding
- Re-add USB HCI PHY refactoring
- Add patch to allow USB reset line sharing
- Add patch to introduce quirk for PHY2 SIDDQ clearing
- Re-add USB nodes to the .dtsi
- Add USB gadget support
- Add DT for X96 Mate TV box
Changelog v4 .. v5:
- Fix CCU binding to pass dtbs_check
- Add RSB compatible string to binding doc
- Rename IR pin name to pass dtbs_check
- Add EMAC compatible string to binding doc
- Drop USB PHY support and binding doc patches
- Drop USB nodes from .dtsi and .dts
- Drop second EMAC node from .dtsi
Changelog v3 .. v4:
- Drop MMC and pinctrl matches (already in some -next trees)
- Add Maxime's Acks
- Add patch to update the AXP MFD DT bindings
- Add new patch (05/21) to fix axp20x-pek driver
- Change AXP IRQ fix to check for invalid IRQ line number
- Split joint DT bindings patch (v3 18/21) into subsystems
- move dwmac variable to keep christmas tree
- Use enums for USB PHY compatible strings in DT binding
- Enable watchdog (briefly verified to work)
- Add PHY2 to HCI1&3, this fixes USB
- limit r-ccu register frame length to not collide with NMI
controller
- add interrupt-controller property to AXP DT node
Changelog v2 .. v3:
- Add Rob's Acks
- Drop redundant maxItems from pinctrl DT binding
- Rename h_i2s* to just i2s* in pinctrl names
- Use more declarative i2s0_d{in,out}{0,1} names
- Add RSB pins to pinctrl
- Include RSB clocks (sharing with newly added H6 versions)
- Fix CEC clock (add 2nd enable bit, also fix predivider flag)
- Rename PMU_UNK1 register in USB PHY
- Add USB and MUSB DT binding patches
- Add MMC/SD speed modes to .dtsi
Changelog 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 (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
From: Maxime Ripard <hidden> Date: 2021-07-26 14:52:51
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.
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.
Maxime
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-08-02 00:39:48
On Mon, 26 Jul 2021 16:52:30 +0200
Maxime Ripard [off-list ref] wrote:
Hi,
On Fri, Jul 23, 2021 at 04:38:27PM +0100, Andre Przywara wrote:
quoted
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Maxime Ripard <hidden> Date: 2021-08-17 07:30:38
Hi Andre,
On Mon, Aug 02, 2021 at 01:38:51AM +0100, Andre Przywara wrote:
On Mon, 26 Jul 2021 16:52:30 +0200
Maxime Ripard [off-list ref] wrote:
quoted
On Fri, Jul 23, 2021 at 04:38:27PM +0100, Andre Przywara wrote:
quoted
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.
Again, at the expense of having to deal with more bindings combinations
in the driver. This driver is already a nightmare to get all the one we
have to support already. You asked to keep the same driver, fair enough,
but then let's do our best to not make the situation worse there.
quoted
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.
I mean, we didn't really try though? The whole clock tree has basically
a big TODO all over it.
I know that it can be hard to figure out. It's why I suggested to rely
on fixed clock for the moment as placeholders to get the rest of the
series in. But for some reason you don't want to do that either.
Maxime