Re: [linux-sunxi] [PATCH v5 09/15] clk: sunxi-ng: h6: Allow I2S to change parent rate

2019-08-20 Thread Code Kipper
ThanksI've added to my next patch series but if you could add it
when applying that would be great.
BR,
CK

On Wed, 21 Aug 2019 at 06:07, Chen-Yu Tsai  wrote:
>
> On Wed, Aug 14, 2019 at 2:09 PM  wrote:
> >
> > From: Jernej Skrabec 
> >
> > I2S doesn't work if parent rate couldn't be change. Difference between
> > wanted and actual rate is too big.
> >
> > Fix this by adding CLK_SET_RATE_PARENT flag to I2S clocks.
> >
> > Signed-off-by: Jernej Skrabec 
>
> This lacks your SoB. Please reply and I can add it when applying.
>
> ChenYu

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


Re: [linux-sunxi] [PATCH v5 09/15] clk: sunxi-ng: h6: Allow I2S to change parent rate

2019-08-20 Thread Chen-Yu Tsai
On Wed, Aug 14, 2019 at 2:09 PM  wrote:
>
> From: Jernej Skrabec 
>
> I2S doesn't work if parent rate couldn't be change. Difference between
> wanted and actual rate is too big.
>
> Fix this by adding CLK_SET_RATE_PARENT flag to I2S clocks.
>
> Signed-off-by: Jernej Skrabec 

This lacks your SoB. Please reply and I can add it when applying.

ChenYu

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


[linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC

2019-08-20 Thread megous
From: Ondrej Jirman 

RTC on H6 is mostly the same as on H5 and H3. It has slight differences
mostly in features that are not yet supported by this driver.

Some differences are already stated in the comments in existing code.
One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
EXT_LOSC_EN to enable/disable external low speed crystal oscillator.

It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
external low speed oscillator is working correctly.

This patch adds support for enabling LOSC when necessary:

- during reparenting
- when probing the clock

H6 also has capacbility to automatically reparent RTC clock from
external crystal oscillator, to internal RC oscillator, if external
oscillator fails. This is enabled by default. Disable it during
probe.

Signed-off-by: Ondrej Jirman 
Reviewed-by: Chen-Yu Tsai 
---
 drivers/rtc/rtc-sun6i.c | 40 ++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index d50ee023b559..b0c3752bed3f 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -32,9 +32,11 @@
 /* Control register */
 #define SUN6I_LOSC_CTRL0x
 #define SUN6I_LOSC_CTRL_KEY(0x16aa << 16)
+#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15)
 #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC   BIT(9)
 #define SUN6I_LOSC_CTRL_RTC_HMS_ACCBIT(8)
 #define SUN6I_LOSC_CTRL_RTC_YMD_ACCBIT(7)
+#define SUN6I_LOSC_CTRL_EXT_LOSC_ENBIT(4)
 #define SUN6I_LOSC_CTRL_EXT_OSCBIT(0)
 #define SUN6I_LOSC_CTRL_ACC_MASK   GENMASK(9, 7)
 
@@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
unsigned int has_prescaler : 1;
unsigned int has_out_clk : 1;
unsigned int export_iosc : 1;
+   unsigned int has_losc_en : 1;
+   unsigned int has_auto_swt : 1;
 };
 
 struct sun6i_rtc_dev {
@@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw, u8 
index)
val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
val |= SUN6I_LOSC_CTRL_KEY;
val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
+   if (rtc->data->has_losc_en) {
+   val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
+   val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
+   }
writel(val, rtc->base + SUN6I_LOSC_CTRL);
spin_unlock_irqrestore(>lock, flags);
 
@@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node,
const char *iosc_name = "rtc-int-osc";
const char *clkout_name = "osc32k-out";
const char *parents[2];
+   u32 reg;
 
rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
if (!rtc)
@@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node,
goto err;
}
 
+   reg = SUN6I_LOSC_CTRL_KEY;
+   if (rtc->data->has_auto_swt) {
+   /* Bypass auto-switch to int osc, on ext losc failure */
+   reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
+   writel(reg, rtc->base + SUN6I_LOSC_CTRL);
+   }
+
/* Switch to the external, more precise, oscillator */
-   writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
-  rtc->base + SUN6I_LOSC_CTRL);
+   reg |= SUN6I_LOSC_CTRL_EXT_OSC;
+   if (rtc->data->has_losc_en)
+   reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
+   writel(reg, rtc->base + SUN6I_LOSC_CTRL);
 
/* Yes, I know, this is ugly. */
sun6i_rtc = rtc;
@@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk, 
"allwinner,sun8i-h3-rtc",
 CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk, "allwinner,sun50i-h5-rtc",
  sun8i_h3_rtc_clk_init);
 
+static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
+   .rc_osc_rate = 1600,
+   .fixed_prescaler = 32,
+   .has_prescaler = 1,
+   .has_out_clk = 1,
+   .export_iosc = 1,
+   .has_losc_en = 1,
+   .has_auto_swt = 1,
+};
+
+static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
+{
+   sun6i_rtc_clk_init(node, _h6_rtc_data);
+}
+CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
+ sun50i_h6_rtc_clk_init);
+
 static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
.rc_osc_rate = 32000,
.has_out_clk = 1,
@@ -675,6 +710,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
{ .compatible = "allwinner,sun8i-r40-rtc" },
{ .compatible = "allwinner,sun8i-v3-rtc" },
{ .compatible = "allwinner,sun50i-h5-rtc" },
+   { .compatible = "allwinner,sun50i-h6-rtc" },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
-- 
2.22.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

[linux-sunxi] [PATCH v2 3/3] arm64: dts: sun50i-h6: Add support for RTC and fix the clock tree

2019-08-20 Thread megous
From: Ondrej Jirman 

This patch adds RTC node and fixes the clock properties and nodes
to reflect the real clock tree.

The device nodes for the internal oscillator and osc32k are removed,
as these clocks are now provided by the RTC device. Clock references
are fixed accordingly, too.

Signed-off-by: Ondrej Jirman 
---
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 30 +++-
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 67b732e34091..67f920e0fc33 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -56,14 +56,6 @@
status = "disabled";
};
 
-   iosc: internal-osc-clk {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <1600>;
-   clock-accuracy = <3>;
-   clock-output-names = "iosc";
-   };
-
osc24M: osc24M_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -71,11 +63,11 @@
clock-output-names = "osc24M";
};
 
-   osc32k: osc32k_clk {
+   ext_osc32k: ext_osc32k_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
-   clock-output-names = "osc32k";
+   clock-output-names = "ext_osc32k";
};
 
psci {
@@ -197,7 +189,7 @@
ccu: clock@3001000 {
compatible = "allwinner,sun50i-h6-ccu";
reg = <0x03001000 0x1000>;
-   clocks = <>, <>, <>;
+   clocks = <>, < 0>, < 2>;
clock-names = "hosc", "losc", "iosc";
#clock-cells = <1>;
#reset-cells = <1>;
@@ -236,7 +228,7 @@
 ,
 ,
 ;
-   clocks = < CLK_APB1>, <>, <>;
+   clocks = < CLK_APB1>, <>, < 0>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
#gpio-cells = <3>;
@@ -710,10 +702,20 @@
};
};
 
+   rtc: rtc@700 {
+   compatible = "allwinner,sun50i-h6-rtc";
+   reg = <0x0700 0x400>;
+   interrupts = ,
+;
+   clock-output-names = "osc32k", "osc32k-out", "iosc";
+   clocks = <_osc32k>;
+   #clock-cells = <1>;
+   };
+
r_ccu: clock@701 {
compatible = "allwinner,sun50i-h6-r-ccu";
reg = <0x0701 0x400>;
-   clocks = <>, <>, <>,
+   clocks = <>, < 0>, < 2>,
 < CLK_PLL_PERIPH0>;
clock-names = "hosc", "losc", "iosc", "pll-periph";
#clock-cells = <1>;
@@ -741,7 +743,7 @@
reg = <0x07022000 0x400>;
interrupts = ,
 ;
-   clocks = <_ccu CLK_R_APB1>, <>, <>;
+   clocks = <_ccu CLK_R_APB1>, <>, < 0>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
#gpio-cells = <3>;
-- 
2.22.1

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


[linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC

2019-08-20 Thread megous
From: Ondrej Jirman 

I went through the datasheets for H6 and H5, and compared the differences.
RTCs are largely similar, but not entirely compatible. Incompatibilities
are in details not yet implemented by the rtc driver though.

I also corrected the clock tree in H6 DTSI.

This patchset is necessary for implementing the WiFi/Bluetooth support
on boards using H6 SoC.

There was some discussion previously of describing HOSC, DCXO and XO
oscillators and clocks as part of RTC in DT, but I decided against it
because it's not necessary, becuse information that would be provided
as a part of DT can already be determined at runtime from RTC registers,
so this woudn't add any value and would only introduce complications
to the driver. See: https://patchwork.kernel.org/cover/10898083/

Please take a look.


Thank you and regards,
  Ondrej Jirman


Changes in v2:
- bindings converted to yaml
- added reviewed by tags

Ondrej Jirman (3):
  dt-bindings: Add compatible for H6 RTC
  rtc: sun6i: Add support for H6 RTC
  arm64: dts: sun50i-h6: Add support for RTC and fix the clock tree

 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 13 ++
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 30 +++---
 drivers/rtc/rtc-sun6i.c   | 40 ++-
 3 files changed, 67 insertions(+), 16 deletions(-)

-- 
2.22.1

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


[linux-sunxi] [PATCH v2 1/3] dt-bindings: Add compatible for H6 RTC

2019-08-20 Thread megous
From: Ondrej Jirman 

RTC on H6 is similar to the one on H5 SoC, but incompatible in small
details. See the driver for description of differences. For example
H6 RTC needs to enable the external low speed oscillator. Add new
compatible for this RTC.

Signed-off-by: Ondrej Jirman 
---
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml   | 13 +
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index 924622f39c44..d7a57ec4a640 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -25,6 +25,7 @@ properties:
   - items:
   - const: allwinner,sun50i-a64-rtc
   - const: allwinner,sun8i-h3-rtc
+  - const: allwinner,sun50i-h6-rtc
 
   reg:
 maxItems: 1
@@ -92,6 +93,18 @@ allOf:
   minItems: 3
   maxItems: 3
 
+  - if:
+  properties:
+compatible:
+  contains:
+const: allwinner,sun50i-h6-rtc
+
+then:
+  properties:
+clock-output-names:
+  minItems: 3
+  maxItems: 3
+
   - if:
   properties:
 compatible:
-- 
2.22.1

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


[linux-sunxi] Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver

2019-08-20 Thread Ondřej Jirman
Hi,

On Tue, Aug 20, 2019 at 08:07:53AM -0500, Samuel Holland wrote:
> On 8/20/19 6:18 AM, Ondřej Jirman wrote:
> > Hi Samuel,
> > 
> > On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
> >> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
> >> used for communication between the ARM CPUs and the ARISC management
> >> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
> >>
> >> Add a driver for it, so it can be used for SCPI or other communication
> >> protocols.
> >>
> >> Signed-off-by: Samuel Holland 
> >> ---
> >>  drivers/mailbox/Kconfig|  10 +
> >>  drivers/mailbox/Makefile   |   2 +
> >>  drivers/mailbox/sunxi-msgbox.c | 323 +
> >>  3 files changed, 335 insertions(+)
> >>  create mode 100644 drivers/mailbox/sunxi-msgbox.c
> >>
> >> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> >> index ab4eb750bbdd..57d12936175e 100644
> >> --- a/drivers/mailbox/Kconfig
> >> +++ b/drivers/mailbox/Kconfig
> >> @@ -227,4 +227,14 @@ config ZYNQMP_IPI_MBOX
> >>  message to the IPI buffer and will access the IPI control
> >>  registers to kick the other processor or enquire status.
> >>  
> >> +config SUNXI_MSGBOX
> >> +  tristate "Allwinner sunxi Message Box"
> >> +  depends on ARCH_SUNXI || COMPILE_TEST
> >> +  default ARCH_SUNXI
> >> +  help
> >> +Mailbox implementation for the hardware message box present in
> >> +Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
> >> +used for communication between the application CPUs and the power
> >> +management coprocessor.
> >> +
> >>  endif
> >> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> >> index c22fad6f696b..bec2d50b0976 100644
> >> --- a/drivers/mailbox/Makefile
> >> +++ b/drivers/mailbox/Makefile
> >> @@ -48,3 +48,5 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
> >>  obj-$(CONFIG_MTK_CMDQ_MBOX)   += mtk-cmdq-mailbox.o
> >>  
> >>  obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o
> >> +
> >> +obj-$(CONFIG_SUNXI_MSGBOX)+= sunxi-msgbox.o
> >> diff --git a/drivers/mailbox/sunxi-msgbox.c 
> >> b/drivers/mailbox/sunxi-msgbox.c
> >> new file mode 100644
> >> index ..29a5101a5390
> >> --- /dev/null
> >> +++ b/drivers/mailbox/sunxi-msgbox.c
> >> @@ -0,0 +1,323 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +//
> >> +// Copyright (c) 2017-2019 Samuel Holland 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#define NUM_CHANS 8
> >> +
> >> +#define CTRL_REG(n)   (0x + 0x4 * ((n) / 4))
> >> +#define CTRL_RX(n)BIT(0 + 8 * ((n) % 4))
> >> +#define CTRL_TX(n)BIT(4 + 8 * ((n) % 4))
> >> +
> >> +#define REMOTE_IRQ_EN_REG 0x0040
> >> +#define REMOTE_IRQ_STAT_REG   0x0050
> >> +#define LOCAL_IRQ_EN_REG  0x0060
> >> +#define LOCAL_IRQ_STAT_REG0x0070
> >> +
> >> +#define RX_IRQ(n) BIT(0 + 2 * (n))
> >> +#define RX_IRQ_MASK   0x
> >> +#define TX_IRQ(n) BIT(1 + 2 * (n))
> >> +#define TX_IRQ_MASK   0x
> >> +
> >> +#define FIFO_STAT_REG(n)  (0x0100 + 0x4 * (n))
> >> +#define FIFO_STAT_MASKGENMASK(0, 0)
> >> +
> >> +#define MSG_STAT_REG(n)   (0x0140 + 0x4 * (n))
> >> +#define MSG_STAT_MASK GENMASK(2, 0)
> >> +
> >> +#define MSG_DATA_REG(n)   (0x0180 + 0x4 * (n))
> >> +
> >> +#define mbox_dbg(mbox, ...)   dev_dbg((mbox)->controller.dev, 
> >> __VA_ARGS__)
> >> +
> >> +struct sunxi_msgbox {
> >> +  struct mbox_controller controller;
> >> +  struct clk *clk;
> >> +  spinlock_t lock;
> >> +  void __iomem *regs;
> >> +};
> >> +
> >> +static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
> >> +static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
> >> +
> >> +static inline int channel_number(struct mbox_chan *chan)
> >> +{
> >> +  return chan - chan->mbox->chans;
> >> +}
> >> +
> >> +static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan 
> >> *chan)
> >> +{
> >> +  return chan->con_priv;
> >> +}
> >> +
> >> +static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
> >> +{
> >> +  struct sunxi_msgbox *mbox = dev_id;
> >> +  uint32_t status;
> >> +  int n;
> >> +
> >> +  /* Only examine channels that are currently enabled. */
> >> +  status = readl(mbox->regs + LOCAL_IRQ_EN_REG) &
> >> +   readl(mbox->regs + LOCAL_IRQ_STAT_REG);
> >> +
> >> +  if (!(status & RX_IRQ_MASK))
> >> +  return IRQ_NONE;
> >> +
> >> +  for (n = 0; n < NUM_CHANS; ++n) {
> >> +  struct mbox_chan *chan = >controller.chans[n];
> >> +
> >> +  if (!(status & RX_IRQ(n)))
> >> +  continue;
> >> +
> >> +  while (sunxi_msgbox_peek_data(chan)) {
> >> +  uint32_t msg = 

[linux-sunxi] Re: [PATCH v4 05/10] ARM: dts: sunxi: a80: Add msgbox node

2019-08-20 Thread Samuel Holland
Hi,

On 8/20/19 3:15 AM, Maxime Ripard wrote:
> On Mon, Aug 19, 2019 at 10:23:06PM -0500, Samuel Holland wrote:
>> The A80 SoC contains a message box that can be used to send messages and
>> interrupts back and forth between the ARM application CPUs and the ARISC
>> coprocessor. Add a device tree node for it.
>>
>> Signed-off-by: Samuel Holland 
> 
> I think you mentionned that crust has been tested only on the A64 and
> the H3/H5, did you test the mailbox on those other SoCs as well?

No, I only have A64/H3/H5, and recently H6, hardware to test. I've looked
through the manuals to verify that the registers are all the same, but I haven't
run the driver on earlier SoCs.

On 32-bit SoCs, where there's no other user of SRAM A2, it should be easy to get
the toy firmware running. All you should need to do is:
  1) Update the MMIO base/clock addresses in drivers/msgbox/sunxi-msgbox.c
  2) Update the load address in platform/sun50i/include/platform/memory.h
  3) Load the firmware to SRAM A2 (can be done from a U-Boot shell)
  4) Initialize the reset vector (algorithm is in tools/test.c:109)
  5) Deassert AR100 reset (again, these last two steps can be done from U-Boot)

Thanks,
Samuel

-- 
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/f3e3420e-450a-7d41-edf8-776c0cd5a320%40sholland.org.


[linux-sunxi] Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver

2019-08-20 Thread Samuel Holland
On 8/20/19 6:18 AM, Ondřej Jirman wrote:
> Hi Samuel,
> 
> On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
>> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
>> used for communication between the ARM CPUs and the ARISC management
>> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
>>
>> Add a driver for it, so it can be used for SCPI or other communication
>> protocols.
>>
>> Signed-off-by: Samuel Holland 
>> ---
>>  drivers/mailbox/Kconfig|  10 +
>>  drivers/mailbox/Makefile   |   2 +
>>  drivers/mailbox/sunxi-msgbox.c | 323 +
>>  3 files changed, 335 insertions(+)
>>  create mode 100644 drivers/mailbox/sunxi-msgbox.c
>>
>> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
>> index ab4eb750bbdd..57d12936175e 100644
>> --- a/drivers/mailbox/Kconfig
>> +++ b/drivers/mailbox/Kconfig
>> @@ -227,4 +227,14 @@ config ZYNQMP_IPI_MBOX
>>message to the IPI buffer and will access the IPI control
>>registers to kick the other processor or enquire status.
>>  
>> +config SUNXI_MSGBOX
>> +tristate "Allwinner sunxi Message Box"
>> +depends on ARCH_SUNXI || COMPILE_TEST
>> +default ARCH_SUNXI
>> +help
>> +  Mailbox implementation for the hardware message box present in
>> +  Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
>> +  used for communication between the application CPUs and the power
>> +  management coprocessor.
>> +
>>  endif
>> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
>> index c22fad6f696b..bec2d50b0976 100644
>> --- a/drivers/mailbox/Makefile
>> +++ b/drivers/mailbox/Makefile
>> @@ -48,3 +48,5 @@ obj-$(CONFIG_STM32_IPCC)   += stm32-ipcc.o
>>  obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o
>>  
>>  obj-$(CONFIG_ZYNQMP_IPI_MBOX)   += zynqmp-ipi-mailbox.o
>> +
>> +obj-$(CONFIG_SUNXI_MSGBOX)  += sunxi-msgbox.o
>> diff --git a/drivers/mailbox/sunxi-msgbox.c b/drivers/mailbox/sunxi-msgbox.c
>> new file mode 100644
>> index ..29a5101a5390
>> --- /dev/null
>> +++ b/drivers/mailbox/sunxi-msgbox.c
>> @@ -0,0 +1,323 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +//
>> +// Copyright (c) 2017-2019 Samuel Holland 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define NUM_CHANS   8
>> +
>> +#define CTRL_REG(n) (0x + 0x4 * ((n) / 4))
>> +#define CTRL_RX(n)  BIT(0 + 8 * ((n) % 4))
>> +#define CTRL_TX(n)  BIT(4 + 8 * ((n) % 4))
>> +
>> +#define REMOTE_IRQ_EN_REG   0x0040
>> +#define REMOTE_IRQ_STAT_REG 0x0050
>> +#define LOCAL_IRQ_EN_REG0x0060
>> +#define LOCAL_IRQ_STAT_REG  0x0070
>> +
>> +#define RX_IRQ(n)   BIT(0 + 2 * (n))
>> +#define RX_IRQ_MASK 0x
>> +#define TX_IRQ(n)   BIT(1 + 2 * (n))
>> +#define TX_IRQ_MASK 0x
>> +
>> +#define FIFO_STAT_REG(n)(0x0100 + 0x4 * (n))
>> +#define FIFO_STAT_MASK  GENMASK(0, 0)
>> +
>> +#define MSG_STAT_REG(n) (0x0140 + 0x4 * (n))
>> +#define MSG_STAT_MASK   GENMASK(2, 0)
>> +
>> +#define MSG_DATA_REG(n) (0x0180 + 0x4 * (n))
>> +
>> +#define mbox_dbg(mbox, ...) dev_dbg((mbox)->controller.dev, __VA_ARGS__)
>> +
>> +struct sunxi_msgbox {
>> +struct mbox_controller controller;
>> +struct clk *clk;
>> +spinlock_t lock;
>> +void __iomem *regs;
>> +};
>> +
>> +static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
>> +static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
>> +
>> +static inline int channel_number(struct mbox_chan *chan)
>> +{
>> +return chan - chan->mbox->chans;
>> +}
>> +
>> +static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan *chan)
>> +{
>> +return chan->con_priv;
>> +}
>> +
>> +static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
>> +{
>> +struct sunxi_msgbox *mbox = dev_id;
>> +uint32_t status;
>> +int n;
>> +
>> +/* Only examine channels that are currently enabled. */
>> +status = readl(mbox->regs + LOCAL_IRQ_EN_REG) &
>> + readl(mbox->regs + LOCAL_IRQ_STAT_REG);
>> +
>> +if (!(status & RX_IRQ_MASK))
>> +return IRQ_NONE;
>> +
>> +for (n = 0; n < NUM_CHANS; ++n) {
>> +struct mbox_chan *chan = >controller.chans[n];
>> +
>> +if (!(status & RX_IRQ(n)))
>> +continue;
>> +
>> +while (sunxi_msgbox_peek_data(chan)) {
>> +uint32_t msg = readl(mbox->regs + MSG_DATA_REG(n));
>> +
>> +mbox_dbg(mbox, "Channel %d received 0x%08x\n", n, msg);
>> +mbox_chan_received_data(chan, );
>> +}
>> +
>> +/* The IRQ can be cleared only once the FIFO is empty. */
>> +writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STAT_REG);
>> +

[linux-sunxi] Re: [PATCH v4 03/10] dt-bindings: mailbox: Add a sunxi message box binding

2019-08-20 Thread Samuel Holland
On 8/20/19 2:14 AM, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Aug 19, 2019 at 10:23:04PM -0500, Samuel Holland wrote:
>> This mailbox hardware is present in Allwinner sun8i, sun9i, and sun50i
>> SoCs. Add a device tree binding for it.
>>
>> Reviewed-by: Rob Herring 
>> Signed-off-by: Samuel Holland 
>> ---
>>  .../mailbox/allwinner,sunxi-msgbox.yaml   | 79 +++
>>  1 file changed, 79 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml
> 
> So we merged a bunch of schemas already, with the convention that the
> name was the first compatible to use that binding.
> 
> That would be allwinner,sun6i-a31-msgbox.yaml in that case

Okay, I'll rename the binding and driver (and Kconfig symbol?).

Thanks,
Samuel

-- 
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/8947f4d1-3bb4-11b8-b114-5016339514b8%40sholland.org.


[linux-sunxi] Re: [PATCH v4 02/10] clk: sunxi-ng: Mark AR100 clocks as critical

2019-08-20 Thread Samuel Holland
On 8/20/19 2:11 AM, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Aug 19, 2019 at 10:23:03PM -0500, Samuel Holland wrote:
>> On sun8i, sun9i, and sun50i SoCs, system suspend/resume support requires
>> firmware running on the AR100 coprocessor (the "SCP"). Such firmware can
>> provide additional features, such as thermal monitoring and poweron/off
>> support for boards without a PMIC.
>>
>> Since the AR100 may be running critical firmware, even if Linux does not
>> know about it or directly interact with it (all requests may go through
>> an intermediary interface such as PSCI), Linux must not turn off its
>> clock.

This paragraph here is the key. The firmware won't necessarily have a device
tree node, and in the current design it will not, since Linux never communicates
with it directly. All communication goes through ATF via PSCI.

>> At this time, such power management firmware only exists for the A64 and
>> H5 SoCs.  However, it makes sense to take care of all CCU drivers now
>> for consistency, and to ease the transition in the future once firmware
>> is ported to the other SoCs.
>>
>> Leaving the clock running is safe even if no firmware is present, since
>> the AR100 stays in reset by default. In most cases, the AR100 clock is
>> kept enabled by Linux anyway, since it is the parent of all APB0 bus
>> peripherals. This change only prevents Linux from turning off the AR100
>> clock in the rare case that no peripherals are in use.
>>
>> Signed-off-by: Samuel Holland 
> 
> So I'm not really sure where you want to go with this.
> 
> That clock is only useful where you're having a firmware running on
> the AR100, and that firmware would have a device tree node of its own,
> where we could list the clocks needed for the firmware to keep
> running, if it ever runs. If the driver has not been compiled in /
> loaded, then we don't care either.

See above. I don't expect that the firmware would have a device tree node,
because the firmware doesn't need any Linux drivers.

> But more fundamentally, if we're going to use SCPI, then those clocks
> will not be handled by that driver anyway, but by the firmware, right?

In the future, we might use SCPI clocks/sensors/regulators/etc. from Linux, but
that's not the plan at the moment. Given that it's already been two years since
I started this project, I'm trying to limit its scope so I can get at least some
part merged. The first step is to integrate a firmware that provides
suspend/resume functionality only. That firmware does implement SCPI, and if the
top-level Linux SCPI driver worked with multiple mailbox channels, it could
query the firmware's version and fetures. But all of the SCPI commands used for
suspend/resume must go through ATF via PSCI.

> So I'm not really sure that we should do it statically this way, and
> that we should do it at all.

Do you have a better way to model "firmware uses this clock behind the scenes,
so Linux please don't touch it"? It's unfortunate that we have Linux and
firmware fighting over the R_CCU, but since we didn't have firmware (e.g. SCPI
clocks) in the beginning, it's where we are today.

The AR100 clock doesn't actually have a gate, and it generally has dependencies
like R_INTC in use. So as I mentioned in the commit message, the clock will
normally be on anyway. The goal was to model the fact that there are users of
this clock that Linux doesn't/can't know about.

> Maxime

Thanks,
Samuel

-- 
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/3b67534a-eb1b-c1e8-b5e8-e0a74ae85792%40sholland.org.


[linux-sunxi] Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver

2019-08-20 Thread Ondřej Jirman
Hi Samuel,

On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
> used for communication between the ARM CPUs and the ARISC management
> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
> 
> Add a driver for it, so it can be used for SCPI or other communication
> protocols.
> 
> Signed-off-by: Samuel Holland 
> ---
>  drivers/mailbox/Kconfig|  10 +
>  drivers/mailbox/Makefile   |   2 +
>  drivers/mailbox/sunxi-msgbox.c | 323 +
>  3 files changed, 335 insertions(+)
>  create mode 100644 drivers/mailbox/sunxi-msgbox.c
> 
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index ab4eb750bbdd..57d12936175e 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -227,4 +227,14 @@ config ZYNQMP_IPI_MBOX
> message to the IPI buffer and will access the IPI control
> registers to kick the other processor or enquire status.
>  
> +config SUNXI_MSGBOX
> + tristate "Allwinner sunxi Message Box"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + default ARCH_SUNXI
> + help
> +   Mailbox implementation for the hardware message box present in
> +   Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
> +   used for communication between the application CPUs and the power
> +   management coprocessor.
> +
>  endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index c22fad6f696b..bec2d50b0976 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -48,3 +48,5 @@ obj-$(CONFIG_STM32_IPCC)+= stm32-ipcc.o
>  obj-$(CONFIG_MTK_CMDQ_MBOX)  += mtk-cmdq-mailbox.o
>  
>  obj-$(CONFIG_ZYNQMP_IPI_MBOX)+= zynqmp-ipi-mailbox.o
> +
> +obj-$(CONFIG_SUNXI_MSGBOX)   += sunxi-msgbox.o
> diff --git a/drivers/mailbox/sunxi-msgbox.c b/drivers/mailbox/sunxi-msgbox.c
> new file mode 100644
> index ..29a5101a5390
> --- /dev/null
> +++ b/drivers/mailbox/sunxi-msgbox.c
> @@ -0,0 +1,323 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2017-2019 Samuel Holland 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define NUM_CHANS8
> +
> +#define CTRL_REG(n)  (0x + 0x4 * ((n) / 4))
> +#define CTRL_RX(n)   BIT(0 + 8 * ((n) % 4))
> +#define CTRL_TX(n)   BIT(4 + 8 * ((n) % 4))
> +
> +#define REMOTE_IRQ_EN_REG0x0040
> +#define REMOTE_IRQ_STAT_REG  0x0050
> +#define LOCAL_IRQ_EN_REG 0x0060
> +#define LOCAL_IRQ_STAT_REG   0x0070
> +
> +#define RX_IRQ(n)BIT(0 + 2 * (n))
> +#define RX_IRQ_MASK  0x
> +#define TX_IRQ(n)BIT(1 + 2 * (n))
> +#define TX_IRQ_MASK  0x
> +
> +#define FIFO_STAT_REG(n) (0x0100 + 0x4 * (n))
> +#define FIFO_STAT_MASK   GENMASK(0, 0)
> +
> +#define MSG_STAT_REG(n)  (0x0140 + 0x4 * (n))
> +#define MSG_STAT_MASKGENMASK(2, 0)
> +
> +#define MSG_DATA_REG(n)  (0x0180 + 0x4 * (n))
> +
> +#define mbox_dbg(mbox, ...)  dev_dbg((mbox)->controller.dev, __VA_ARGS__)
> +
> +struct sunxi_msgbox {
> + struct mbox_controller controller;
> + struct clk *clk;
> + spinlock_t lock;
> + void __iomem *regs;
> +};
> +
> +static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
> +static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
> +
> +static inline int channel_number(struct mbox_chan *chan)
> +{
> + return chan - chan->mbox->chans;
> +}
> +
> +static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan *chan)
> +{
> + return chan->con_priv;
> +}
> +
> +static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
> +{
> + struct sunxi_msgbox *mbox = dev_id;
> + uint32_t status;
> + int n;
> +
> + /* Only examine channels that are currently enabled. */
> + status = readl(mbox->regs + LOCAL_IRQ_EN_REG) &
> +  readl(mbox->regs + LOCAL_IRQ_STAT_REG);
> +
> + if (!(status & RX_IRQ_MASK))
> + return IRQ_NONE;
> +
> + for (n = 0; n < NUM_CHANS; ++n) {
> + struct mbox_chan *chan = >controller.chans[n];
> +
> + if (!(status & RX_IRQ(n)))
> + continue;
> +
> + while (sunxi_msgbox_peek_data(chan)) {
> + uint32_t msg = readl(mbox->regs + MSG_DATA_REG(n));
> +
> + mbox_dbg(mbox, "Channel %d received 0x%08x\n", n, msg);
> + mbox_chan_received_data(chan, );
> + }
> +
> + /* The IRQ can be cleared only once the FIFO is empty. */
> + writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STAT_REG);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int sunxi_msgbox_send_data(struct mbox_chan *chan, void *data)
> +{
> + 

[linux-sunxi] Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver

2019-08-20 Thread Maxime Ripard
Hi,

On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
> used for communication between the ARM CPUs and the ARISC management
> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
>
> Add a driver for it, so it can be used for SCPI or other communication
> protocols.
>
> Signed-off-by: Samuel Holland 
> ---
>  drivers/mailbox/Kconfig|  10 +
>  drivers/mailbox/Makefile   |   2 +
>  drivers/mailbox/sunxi-msgbox.c | 323 +
>  3 files changed, 335 insertions(+)
>  create mode 100644 drivers/mailbox/sunxi-msgbox.c

It's pretty much the same remark than for the name of the binding
file, but sunxi in itself is pretty confusing, it covers a range of
SoCs going from armv5 to armv8, some with a single CPU and some with
more, and some with an OpenRISC core and some without.

It would be less confusing (albeit not perfect) to use sun6i there,
the family that IP was first introduced in.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v4 05/10] ARM: dts: sunxi: a80: Add msgbox node

2019-08-20 Thread Maxime Ripard
Hi,

On Mon, Aug 19, 2019 at 10:23:06PM -0500, Samuel Holland wrote:
> The A80 SoC contains a message box that can be used to send messages and
> interrupts back and forth between the ARM application CPUs and the ARISC
> coprocessor. Add a device tree node for it.
>
> Signed-off-by: Samuel Holland 

I think you mentionned that crust has been tested only on the A64 and
the H3/H5, did you test the mailbox on those other SoCs as well?

Thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v4 03/10] dt-bindings: mailbox: Add a sunxi message box binding

2019-08-20 Thread Maxime Ripard
Hi,

On Mon, Aug 19, 2019 at 10:23:04PM -0500, Samuel Holland wrote:
> This mailbox hardware is present in Allwinner sun8i, sun9i, and sun50i
> SoCs. Add a device tree binding for it.
>
> Reviewed-by: Rob Herring 
> Signed-off-by: Samuel Holland 
> ---
>  .../mailbox/allwinner,sunxi-msgbox.yaml   | 79 +++
>  1 file changed, 79 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml

So we merged a bunch of schemas already, with the convention that the
name was the first compatible to use that binding.

That would be allwinner,sun6i-a31-msgbox.yaml in that case

Thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v4 02/10] clk: sunxi-ng: Mark AR100 clocks as critical

2019-08-20 Thread Maxime Ripard
Hi,

On Mon, Aug 19, 2019 at 10:23:03PM -0500, Samuel Holland wrote:
> On sun8i, sun9i, and sun50i SoCs, system suspend/resume support requires
> firmware running on the AR100 coprocessor (the "SCP"). Such firmware can
> provide additional features, such as thermal monitoring and poweron/off
> support for boards without a PMIC.
>
> Since the AR100 may be running critical firmware, even if Linux does not
> know about it or directly interact with it (all requests may go through
> an intermediary interface such as PSCI), Linux must not turn off its
> clock.
>
> At this time, such power management firmware only exists for the A64 and
> H5 SoCs.  However, it makes sense to take care of all CCU drivers now
> for consistency, and to ease the transition in the future once firmware
> is ported to the other SoCs.
>
> Leaving the clock running is safe even if no firmware is present, since
> the AR100 stays in reset by default. In most cases, the AR100 clock is
> kept enabled by Linux anyway, since it is the parent of all APB0 bus
> peripherals. This change only prevents Linux from turning off the AR100
> clock in the rare case that no peripherals are in use.
>
> Signed-off-by: Samuel Holland 

So I'm not really sure where you want to go with this.

That clock is only useful where you're having a firmware running on
the AR100, and that firmware would have a device tree node of its own,
where we could list the clocks needed for the firmware to keep
running, if it ever runs. If the driver has not been compiled in /
loaded, then we don't care either.

But more fundamentally, if we're going to use SCPI, then those clocks
will not be handled by that driver anyway, but by the firmware, right?

So I'm not really sure that we should do it statically this way, and
that we should do it at all.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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


signature.asc
Description: PGP signature