[linux-sunxi] Re: [PATCH v7 0/6] Add support for Orange Pi 3

[Ondřej Jirman]

On Mon, Jun 24, 2019 at 10:29:27AM -0700, David Miller wrote:
> From: meg...@megous.com
> Date: Thu, 20 Jun 2019 15:47:42 +0200
> 
> > From: Ondrej Jirman 
> > 
> > This series implements support for Xunlong Orange Pi 3 board.
> > 
> > - ethernet support (patches 1-3)
> > - HDMI support (patches 4-6)
> > 
> > For some people, ethernet doesn't work after reboot (but works on cold
> > boot), when the stmmac driver is built into the kernel. It works when
> > the driver is built as a module. It's either some timing issue, or power
> > supply issue or a combination of both. Module build induces a power
> > cycling of the phy.
> > 
> > I encourage people with this issue, to build the driver into the kernel,
> > and try to alter the reset timings for the phy in DTS or
> > startup-delay-us and report the findings.
> 
> This is a mixture of networking and non-networking changes so it really
> can't go through my tree.
> 
> I wonder how you expect this series to be merged?
> 
> Thanks.

This series was even longer before, with patches all around for various
maintainers. I'd expect that relevant maintainers pick the range of patches
meant for them. I don't know who's exactly responsible for what, but I think,
this should work:

- 2 stmmac patches should go together via some networking tree (is there
  something specific for stmmac?)
- all DTS patches should go via sunxi
- hdmi patches via some drm tree

thank you and regards,
o.

-- 
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/20190624174637.6sznc5ifiuh4c3sm%40core.my.home.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 0/6] Add support for Orange Pi 3

[Ondřej Jirman]

On Mon, Jun 24, 2019 at 01:24:56PM -0700, David Miller wrote:
> From: Ondřej Jirman 
> Date: Mon, 24 Jun 2019 19:46:37 +0200
> 
> > This series was even longer before, with patches all around for various
> > maintainers. I'd expect that relevant maintainers pick the range of patches
> > meant for them. I don't know who's exactly responsible for what, but I 
> > think,
> > this should work:
> > 
> > - 2 stmmac patches should go together via some networking tree (is there
> >   something specific for stmmac?)
> > - all DTS patches should go via sunxi
> > - hdmi patches via some drm tree
> 
> Thank you.  So I'll merge the first two patches that touch the stmmac
> driver via my net-next tree.

Thank you.

regards,
Ondrej

-- 
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/20190624202856.ij4ujey2z6j5doxj%40core.my.home.
For more options, visit https://groups.google.com/d/optout.

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

[Ondřej Jirman]

On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
>  wrote:
> >
> > 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 
> > ---
> >  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 11f56de52179..7375a530c565 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -41,9 +41,11 @@
> >  /* Control register */
> >  #define SUN6I_LOSC_CTRL0x
> >  #define SUN6I_LOSC_CTRL_KEY(0x16aa << 16)
> > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15)
> 
> Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> 
> The rest looks ok.

Yes, see H6 BSP:

drivers/rtc/rtc-sunxi.h

 20 #define REG_CLK32K_AUTO_SWT_EN  BIT(14)
 21 #define REG_CLK32K_AUTO_SWT_BYPASS  BIT(15)

regards,
Ondrej

> 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/20190805102001.guo7e52bl5agp2w4%40core.my.home.

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

[Ondřej Jirman]

On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
>  wrote:
> >
> > 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 
> > ---
> >  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 11f56de52179..7375a530c565 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -41,9 +41,11 @@
> >  /* Control register */
> >  #define SUN6I_LOSC_CTRL0x
> >  #define SUN6I_LOSC_CTRL_KEY(0x16aa << 16)
> > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15)
> 
> Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> 
> The rest looks ok.

To give you more information. This is a new thing in H6 BSP, compared
to BSPs for previous SoCs (H5/H3).

 20 #define REG_CLK32K_AUTO_SWT_EN  BIT(14)
 21 #define REG_CLK32K_AUTO_SWT_BYPASS  BIT(15)

Init sequence changed in H6 BSP to:

646 /*
647  * Step1: select RTC clock source
648  */
649 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
650 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
651
652 /* Disable auto switch function */
653 tmp_data |= REG_CLK32K_AUTO_SWT_BYPASS;
654 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
655
656 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
657 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
658 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
659
660 /* We need to set GSM after change clock source */
661 udelay(10);
662 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
663 tmp_data |= (EXT_LOSC_GSM | REG_LOSCCTRL_MAGIC);
664 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
665

For older BSPs, the init sequence looked like this:

482 /*
483  * Step1: select RTC clock source
484  */
485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
488 tmp_data |= (EXT_LOSC_GSM);
489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
490

EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
gain for the oscillator's amplifier in the feedback loop of the circuit.

So the new code, for some reason changed from single write to sequence
of individual writes/config steps:

1) disable auto-switch and enable auto-switch bypass
2) select RTC clock source (to LOSC)
  (wait)
3) configure gain on the LOSC

regards,
o.

> 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/20190805104529.z3mex3m2tss7lzlr%40core.my.home.

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

[Ondřej Jirman]

On Mon, Aug 05, 2019 at 06:54:17PM +0800, Chen-Yu Tsai wrote:
> On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman  wrote:
> >
> > On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> > >  wrote:
> > > >
> > > > 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 
> > > > ---
> > > >  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 11f56de52179..7375a530c565 100644
> > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > @@ -41,9 +41,11 @@
> > > >  /* Control register */
> > > >  #define SUN6I_LOSC_CTRL0x
> > > >  #define SUN6I_LOSC_CTRL_KEY(0x16aa << 16)
> > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15)
> > >
> > > Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> > >
> > > The rest looks ok.
> >
> > To give you more information. This is a new thing in H6 BSP, compared
> > to BSPs for previous SoCs (H5/H3).
> >
> >  20 #define REG_CLK32K_AUTO_SWT_EN  BIT(14)
> >  21 #define REG_CLK32K_AUTO_SWT_BYPASS  BIT(15)
> >
> > Init sequence changed in H6 BSP to:
> >
> > 646 /*
> > 647  * Step1: select RTC clock source
> > 648  */
> > 649 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 650 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > 651
> > 652 /* Disable auto switch function */
> > 653 tmp_data |= REG_CLK32K_AUTO_SWT_BYPASS;
> > 654 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 655
> > 656 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 657 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > 658 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 659
> > 660 /* We need to set GSM after change clock source */
> > 661 udelay(10);
> > 662 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 663 tmp_data |= (EXT_LOSC_GSM | REG_LOSCCTRL_MAGIC);
> > 664 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 665
> 
> I don't have this in my H6 BSPs. One is H6 Lichee v1.1 downloaded from Pine64.
> The link was from linux-sunxi wiki's H6 page.
> 
> The other is a 4.9 kernel tree, which I believe is from Allwinner's github:
> 
> https://github.com/Allwinner-Homlet/H6-BSP4.9-linux

Interesting. :) I have the BSP I was using saved here:

https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n649

It's based of 4.9.119

https://megous.com/git/linux/log/?h=h6-4.9-bsp

I don't remember where I found it. But I imported it fairly recently, and
the code you pointed to looks like an older version that I can found in some
beta H6 BSP, that I imported way earlier and is based on 4.9.56:

https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=linux-h6
https://megous.com/git/linux/log/?h=linux-h6

Hmm, archeology. :)

> > For older BSPs, the init sequence looked like this:
> >
> > 482 /*
> > 483  * Step1: select RTC clock source
> > 484  */
> &g

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

[Ondřej Jirman]

On Mon, Apr 15, 2019 at 04:18:12PM +0800, Chen-Yu Tsai wrote:
> On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
>  wrote:
> >
> > 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.
> 
> Please also add DCXO clock input/output and XO clock input to the bindings
> and DT, and also fix up the clock tree. You can skip them in the driver for
> now, but please add a TODO. As long as you don't change the clock-output-name
> of osc24M, everything should work as before.
> 
> We just want the DT to describe what is actually there. For the XO input,
> you could just directly reference the external crystal node. The gate for
> it is likely somewhere in the PRCM block, which we don't have docs for.

So I was thinking about this for a while, and came up with this:

- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi -
index 64c39f663d22..ac99ddbebe5c 100644
@@ -627,14 +635,15 @@

rtc: rtc@700 {
compatible = "allwinner,sun50i-h6-rtc";
reg = <0x0700 0x400>;
interrupts = ,
 ;
-   clock-output-names = "osc32k", "osc32k-out", "iosc";
-   clocks = <&ext_osc32k>;
+   clock-output-names = "osc32k", "osc32k-out", "iosc", 
"hosc";
+   clock-names = "losc", "dcxo";
+   clocks = <&ext_osc32k>, <&osc24M>;
#clock-cells = <1>;
};

r_ccu: clock@701 {
compatible = "allwinner,sun50i-h6-r-ccu";
reg = <0x0701 0x400>;

I'm not completely sure how (or why?) to describe in DTSI which oscillator the
designer used (XO vs DCXO). This information is signalled by the pad voltage and
can be determined at runtime from DCXO_CTRL_REG's OSC_CLK_SRC_SEL (bit 3). It's
not possible to change at runtime.

HOSC source selection is only material to the CPUS (ARISC) firmware when it
wants to turn off all PLLs and the main crystal oscillator so that it knows
which one to turn off. I don't see any other use for it. It's just
informational. I don't think (future) crust firmware has space to be reading
DTBs, so the detection will be using OSC_CLK_SRC_SEL anyway.

Maybe whether XO or DCXO is used also matters if you want to do some fine
tunning of DCXO (control register has pletny of options), but that's probably
better done in u-boot. And there's still no need to read HOSC source from DT.
The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 1,
it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
be using this info to gate/disable the osciallator.

If we really want this in DT, maybe we can model it by having just two input
clocks to RTC described in DTSI, and the DTSI for H6 would have this by default:

clock-names = "losc", "dcxo";
clocks = <&ext_osc32k>, <&osc24M>;

And the board designer could change it from a board file, like this:

&rtc {
clock-names = "losc", "xo";
clocks = <&ext_osc32k>, <&osc24M>;
};

The driver could decide which oscillator is used by the presence of either
dcxo or xo input clock.

But in any case, the driver can also get this info from DCXO_CTRL_REG's
OSC_CLK_SRC_SEL, so it doesn't need to read this from DT at all. So it's a bit
pointless.

So I see two options:

1) skip adding dcxo/xo to input clocks of RTC completely
2) the above

What do you think?

regards,
o.


> > There's a small detail here, that's not described absolutely correctly in
> > DTSI, but the difference is not really that material. ext_osc32k is
> > originally modelled as a fixed clock that feeds into RTC module, but in
> > reality it's the RTC module that implements via its registers enabling and
> > disabling of this oscillator/clock.
> >
> > Though:
> > - there's no other possible user of ext_osc32k than RTC module
> > - there's no other possible external configuration for the crystal
> >   circuit that would need to be handled in the dts per board
> >
> > So I guess, while the description is not perfect, this patch series still
> > improves the current situation. Or maybe I'm misunderstanding something,
> > and &ext_osc32k node just describes a fact that there's a crystal on
> > the board. Then, everything is perhaps fine. :)
> 
> Correct. The external clock nodes are modeling the crystal, not the internal
> clock gate / distributor.
> 
> Were the vendor to not include the crystal (for whatever reasons), the DT
> should be able to describe it via the absence of the clock input, and the
> driver should correctly use the internal (inaccurate) oscillator. I realize
> t

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

[Ondřej Jirman]

On Tue, Aug 06, 2019 at 08:30:45PM +0200, megous hlavni wrote:
> On Mon, Apr 15, 2019 at 04:18:12PM +0800, Chen-Yu Tsai wrote:
> > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> >  wrote:
> > >
> > > 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.
> > 
> > Please also add DCXO clock input/output and XO clock input to the bindings
> > and DT, and also fix up the clock tree. You can skip them in the driver for
> > now, but please add a TODO. As long as you don't change the 
> > clock-output-name
> > of osc24M, everything should work as before.
> > 
> > We just want the DT to describe what is actually there. For the XO input,
> > you could just directly reference the external crystal node. The gate for
> > it is likely somewhere in the PRCM block, which we don't have docs for.
> 
> So I was thinking about this for a while, and came up with this:
> 
> - arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
> -
> index 64c39f663d22..ac99ddbebe5c 100644
> @@ -627,14 +635,15 @@
> 
>   rtc: rtc@700 {
>   compatible = "allwinner,sun50i-h6-rtc";
>   reg = <0x0700 0x400>;
>   interrupts = ,
>;
> - clock-output-names = "osc32k", "osc32k-out", "iosc";
> - clocks = <&ext_osc32k>;
> + clock-output-names = "osc32k", "osc32k-out", "iosc", 
> "hosc";
> + clock-names = "losc", "dcxo";
> + clocks = <&ext_osc32k>, <&osc24M>;
>   #clock-cells = <1>;
>   };
> 
>   r_ccu: clock@701 {
>   compatible = "allwinner,sun50i-h6-r-ccu";
>   reg = <0x0701 0x400>;
> 
> I'm not completely sure how (or why?) to describe in DTSI which oscillator the
> designer used (XO vs DCXO). This information is signalled by the pad voltage 
> and
> can be determined at runtime from DCXO_CTRL_REG's OSC_CLK_SRC_SEL (bit 3). 
> It's
> not possible to change at runtime.
> 
> HOSC source selection is only material to the CPUS (ARISC) firmware when it
> wants to turn off all PLLs and the main crystal oscillator so that it knows
> which one to turn off. I don't see any other use for it. It's just
> informational. I don't think (future) crust firmware has space to be reading
> DTBs, so the detection will be using OSC_CLK_SRC_SEL anyway.
> 
> Maybe whether XO or DCXO is used also matters if you want to do some fine
> tunning of DCXO (control register has pletny of options), but that's probably
> better done in u-boot. And there's still no need to read HOSC source from DT.
> The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 
> 1,
> it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
> be using this info to gate/disable the osciallator.
> 
> If we really want this in DT, maybe we can model it by having just two input
> clocks to RTC described in DTSI, and the DTSI for H6 would have this by 
> default:
> 
>   clock-names = "losc", "dcxo";
>   clocks = <&ext_osc32k>, <&osc24M>;
> 
> And the board designer could change it from a board file, like this:
> 
> &rtc {
>   clock-names = "losc", "xo";
>   clocks = <&ext_osc32k>, <&osc24M>;
> };
> 
> The driver could decide which oscillator is used by the presence of either
> dcxo or xo input clock.
> 
> But in any case, the driver can also get this info from DCXO_CTRL_REG's
> OSC_CLK_SRC_SEL, so it doesn't need to read this from DT at all. So it's a bit
> pointless.
> 
> So I see two options:
> 
> 1) skip adding dcxo/xo to input clocks of RTC completely
> 2) the above
> 
> What do you think?

I tried option 2) and it feels pointless. It just creates this clock tree:

osc24M
  hosc
plls...

from:

osc24M
  plls...

and doesn't achieve anything else, other than complicating things, for no reason
because no driver will ever need or use this info from the DT.

So my preference is for keeping it simple and going with option 1).

regards,
o.


> regards,
>   o.
> 
> 
> > > There's a small detail here, that's not described absolutely correctly in
> > > DTSI, but the difference is not really that material. ext_osc32k is
> > > originally modelled as a fixed clock that feeds into RTC module, but in
> > > reality it's the RTC module that implements via its registers enabling and
> > > disabling of this oscillator/clock.
> > >
> > > Though:
> > > - there's no other possible user of ext_osc32k than RTC module
> > > - there's no other possible external configuration for the crystal
> > >   circuit that would need to be handled in the dts per board
> > >
> > > So I 

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

[Ondřej Jirman]

On Wed, Aug 07, 2019 at 12:55:02PM +0200, Alexandre Belloni wrote:
> Hi,
> 
> On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote:
> > Maybe whether XO or DCXO is used also matters if you want to do some fine
> > tunning of DCXO (control register has pletny of options), but that's 
> > probably
> > better done in u-boot. And there's still no need to read HOSC source from 
> > DT.
> > The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL 
> > is 1,
> > it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
> > be using this info to gate/disable the osciallator.
> > 
> 
> It is actually useful to be able to tweak the crystal tuning at
> runtime to be able to reduce clock drift and compare with a reliable
> source (e.g. NTP).

I don't think there's a Linux kernel API that you can use to achieve that, so
that's a rather theoretical concern at the moment.

Also there are multiple clocks, that can drive the RTC, and you usually don't
drive it from 24MHz DCXO oscillator. The reason is that you'd have to deal with
the fact that the clock for RTC then becomes 2400/750 (750 is fixed
divider), which is 32000.

So if you want to get 32768Hz for RTC by tuning the DCXO, it would have to have
24 576 000 Hz. And even if you could achieve that (doubtful), it would throw off
timings in the rest of the system (say UART, USB, CPU, display ctl) in a major 
way.

I guess you can try tuning 24MHz oscillator so that it's closer to the
real-world 24MHz via NTP reference for other reasons. But it would be
complicated, and require precise interaction with other components, like using
HW timers sourced from 24MHz HOSC clock, because you can't use CPU's timers,
because of inaccuracies introduced during DVFS, for example.

regards,
o.

> I'm curious, what kind of options does this RTC have?
> 
> -- 
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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/20190808121237.g6twq2nh3sayu3vx%40core.my.home.

Re: [linux-sunxi] [PATCH v8 4/4] arm64: dts: allwinner: orange-pi-3: Enable HDMI output

[Ondřej Jirman]

On Fri, Aug 09, 2019 at 10:25:32AM +0200, Code Kipper wrote:
> On Tue, 6 Aug 2019 at 17:57,  wrote:
> >
> > From: Ondrej Jirman 
> >
> > Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
> > I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
> > This is realized by the ddc-en-gpios property.
> Great work. Is there any chance you can move this to the
> arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?, as all the H6
> based orange-pi's have this feature.

I plan to do that as a followup patch, once this is merged.

regards,
o.

> BR,
> CK
> >
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  .../dts/allwinner/sun50i-h6-orangepi-3.dts| 26 +++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts 
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index 2c6807b74ff6..01bb1bafe284 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -22,6 +22,18 @@
> > stdout-path = "serial0:115200n8";
> > };
> >
> > +   connector {
> > +   compatible = "hdmi-connector";
> > +   ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> > +   type = "a";
> > +
> > +   port {
> > +   hdmi_con_in: endpoint {
> > +   remote-endpoint = <&hdmi_out_con>;
> > +   };
> > +   };
> > +   };
> > +
> > leds {
> > compatible = "gpio-leds";
> >
> > @@ -72,6 +84,10 @@
> > cpu-supply = <®_dcdca>;
> >  };
> >
> > +&de {
> > +   status = "okay";
> > +};
> > +
> >  &ehci0 {
> > status = "okay";
> >  };
> > @@ -91,6 +107,16 @@
> > status = "okay";
> >  };
> >
> > +&hdmi {
> > +   status = "okay";
> > +};
> > +
> > +&hdmi_out {
> > +   hdmi_out_con: endpoint {
> > +   remote-endpoint = <&hdmi_con_in>;
> > +   };
> > +};
> > +
> >  &mdio {
> > ext_rgmii_phy: ethernet-phy@1 {
> > compatible = "ethernet-phy-ieee802.3-c22";
> > --
> > 2.22.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to linux-sunxi+unsubscr...@googlegroups.com.
> > To view this discussion on the web, visit 
> > https://groups.google.com/d/msgid/linux-sunxi/20190806155744.10263-5-megous%40megous.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/20190809090443.kq5bnsrkgr746l2i%40core.my.home.

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

[Ondřej Jirman]

On Fri, Aug 09, 2019 at 01:39:30AM +0200, Alexandre Belloni wrote:
> On 08/08/2019 14:12:37+0200, Ondřej Jirman wrote:
> > On Wed, Aug 07, 2019 at 12:55:02PM +0200, Alexandre Belloni wrote:
> > > Hi,
> > > 
> > > On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote:
> > > > Maybe whether XO or DCXO is used also matters if you want to do some 
> > > > fine
> > > > tunning of DCXO (control register has pletny of options), but that's 
> > > > probably
> > > > better done in u-boot. And there's still no need to read HOSC source 
> > > > from DT.
> > > > The driver can just check compatible, and if it is H6 and 
> > > > OSC_CLK_SRC_SEL is 1,
> > > > it can do it's DCXO tunning, or whatever. But neither OS nor bootloader 
> > > > will
> > > > be using this info to gate/disable the osciallator.
> > > > 
> > > 
> > > It is actually useful to be able to tweak the crystal tuning at
> > > runtime to be able to reduce clock drift and compare with a reliable
> > > source (e.g. NTP).
> > 
> > I don't think there's a Linux kernel API that you can use to achieve that, 
> > so
> > that's a rather theoretical concern at the moment.
> > 
> 
> There is /sys/class/rtc/rtcX/offset which is even properly documented.
> 
> The reason I asked is that some RTCs have both analog (changing the
> oscillator capacitance) and digital (changing the RTC counter) so I'm
> wondering whether this interface should be extended.

As I wrote below, that can't be achieved by tuning DCXO.

> > Also there are multiple clocks, that can drive the RTC, and you usually 
> > don't
> > drive it from 24MHz DCXO oscillator. The reason is that you'd have to deal 
> > with
> > the fact that the clock for RTC then becomes 2400/750 (750 is fixed
> > divider), which is 32000.
> > 
> > So if you want to get 32768Hz for RTC by tuning the DCXO, it would have to 
> > have
> > 24 576 000 Hz. And even if you could achieve that (doubtful), it would 
> > throw off
> > timings in the rest of the system (say UART, USB, CPU, display ctl) in a 
> > major way.
> > 
> > I guess you can try tuning 24MHz oscillator so that it's closer to the
> > real-world 24MHz via NTP reference for other reasons. But it would be
> > complicated, and require precise interaction with other components, like 
> > using
> > HW timers sourced from 24MHz HOSC clock, because you can't use CPU's timers,
> > because of inaccuracies introduced during DVFS, for example.
> > 
> > regards,
> > o.
> > 
> > > I'm curious, what kind of options does this RTC have?
> > > 
> > > -- 
> > > Alexandre Belloni, Bootlin
> > > Embedded Linux and Kernel engineering
> > > https://bootlin.com
> > > 
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-ker...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> -- 
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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/20190809091626.6kanjbmvbi4oipco%40core.my.home.

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

[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 = &mbox->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, &msg);
> + }
> +
> + /* 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

[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);
>

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

[Ondřej Jirman]

Hi,

On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> Hi!
> 
> Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com napisal(a):
> > 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)
> 
> User manual says that above field is bit 14.

See the previous discussion, this is from BSP.

regards,
o.

> Best regards,
> Jernej
> 
> >  #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(&rtc->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, &sun50i_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 cons

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

[Ondřej Jirman]

Hi,

On Sat, Aug 24, 2019 at 10:06:14AM +0200, Jernej Škrabec wrote:
> Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a):
> > Hi!
> > 
> > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a):
> > > 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
> > 
> > Sorry for a bit late test, but with your patches on Tanix TX6 box I get this
> > in dmesg:
> > 
> > [   17.431742] sun6i-rtc 700.rtc: Failed to set rtc time.
> > [   20.439742] sun6i-rtc 700.rtc: rtc is still busy.
> > [   21.435744] sun6i-rtc 700.rtc: rtc is still busy.
> > [   24.055741] sun6i-rtc 700.rtc: rtc is still busy.
> > [   24.439752] sun6i-rtc 700.rtc: rtc is still busy.
> > 
> > Last line is repeated non-stop.
> > 
> > Any idea what could be wrong?
> 
> Additional info - this is on kernel 5.2.6 with your patches applied.

Do you have schematics, or a FEX file for the board or any other info on how the
RTC is set up on that board?

Can you dump the RTC register range?

regards,
o.

> Best regards,
> Jernej
> 
> 
> 
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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/20190824125612.zq5qsay2wv62wykt%40core.my.home.

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

[Ondřej Jirman]

On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote:
> Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> > Hi,
> > 
> > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > > Hi!
> > > 
> > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com 
> napisal(a):
> > > > 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)
> > > 
> > > User manual says that above field is bit 14.
> > 
> > See the previous discussion, this is from BSP.
> 
> I have two versions of BSP (don't ask me which) which have this set as bit 14 
> and changing this to 14 actually solves all my problems with LOSC (no more 
> issues with setting RTC and HDMI-CEC works now - it uses LOSC as parent) on 
> Tanix TX6 box.

Interesting. Is LOSC fed externally generated clock, or is it setup as a crystal
oscillator on your board?

Anyway, see here:

https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652

It would be nice to know what's really happening.

My output is:

[0.832252] sun6i-rtc 700.rtc: registered as rtc0
[0.832257] sun6i-rtc 700.rtc: RTC enabled
[1.728968] sun6i-rtc 700.rtc: setting system clock to 
1970-01-01T00:00:07 UTC (7)

I think, you may have just enabled the auto switch feature, and running the
clock from low precision RC oscillator with your patch.

The real issue probably is that the mainline driver is missing this:

https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n650

regards,
o.

> Best regards,
> Jernej
> 
> > 
> > regards,
> > o.
> > 
> > > Best regards,
> > > Jernej
> > > 
> > > >  #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;
> > > > 
> > > >  };
> >

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

[Ondřej Jirman]

On Sat, Aug 24, 2019 at 03:16:41PM +0200, Jernej Škrabec wrote:
> Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a):
> > On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote:
> > > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> > > > Hi,
> > > > 
> > > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > > > > Hi!
> > > > > 
> > > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com
> > > 
> > > napisal(a):
> > > > > > 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)
> > > > > 
> > > > > User manual says that above field is bit 14.
> > > > 
> > > > See the previous discussion, this is from BSP.
> > > 
> > > I have two versions of BSP (don't ask me which) which have this set as bit
> > > 14 and changing this to 14 actually solves all my problems with LOSC (no
> > > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as
> > > parent) on Tanix TX6 box.
> > 
> > Interesting. Is LOSC fed externally generated clock, or is it setup as a
> > crystal oscillator on your board?
> 
> I really don't know, but here is DT: http://ix.io/1ThI
> 
> > 
> > Anyway, see here:
> > 
> > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649
> > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652
> 
> Interesting, 4.9 BSP has additional bit definition, which is not documented 
> in 
> manual and 3.10 BSP to which I refer.
> 
> I was referring to 3.10 BSP, which uses only bit 14. I thought that you named 
> it differently.
> 
> > 
> > It would be nice to know what's really happening.
> > 
> > My output is:
> > 
> > [0.832252] sun6i-rtc 700.rtc: registered as rtc0
> > [0.832257] sun6i-rtc 700.rtc: RTC enabled
> > [1.728968] sun6i-rtc 700.rtc: setting system clock to
> > 1970-01-01T00:00:07 UTC (7)
> 
> With change, I get same output.
> 

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

[Ondřej Jirman]

Hello Jernej,

On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote:
> > Visually?
> > 
> > That would explain why it doesn't work for you. The mainline RTC driver
> > disables auto-switch feature, and if your board doesn't have a crystal for
> > LOSC, RTC will not generate a clock for the RTC.
> > 
> > H6's dtsi describes by default a situatiuon with external 32k crystal
> > oscillator. See ext_osc32k node. That's incorrect for your board if it
> > doesn't have the crystal. You need to fix this in the DTS for your board
> > instead of patching the driver.
> 
> I see that reparenting is supported, but I'm not sure how to fix that in DT. 
> Any suggestion?

You may try removing the clocks property from rtc node.

> > 
> > The driver has parent clock selection logic in case the LOSC crystal is not
> > used.
> > 
> > Your patch enables automatic detection of LOSC failure and RTC changes clock
> > to LOSC automatically, despite what's described in the DTS. That may fix
> > the issue, but is not the correct solution.
> > 
> > Registers on my board look like this (external 32k osc is used) for
> > reference:
> > 
> > LOSC_CTRL_REG[700]: 8011
> > KEY_FIELD  ???  (0)
> > LOSC_AUTO_SWT_BYPASS   EN   (1)
> > LOSC_AUTO_SWT_EN   DIS  (0)
> > EXT_LOSC_ENEN   (1)
> > EXT_LOSC_GSM   LOW  (0)
> > BATTERY_DIRDISCHARGE(0)
> > LOSC_SRC_SEL   EXT32k   (1)
> > 
> > LOSC_AUTO_SWT_STA_REG[704]: 1
> > EXT_LOSC_STA   OK   (0)
> > LOSC_AUTO_SWT_PEND NOEFF(0)
> > LOSC_SRC_SEL_STA   EXT32K   (1)
> > 
> 
> In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG
> has value 0x4, so there is issue with external crystal (it's missing) and RTC 
> switched to internal one.
> 
> BTW, what's wrong with automatic switching? Why is it disabled?

It always was disabled on mainline (bit 14 was set to 0 even before my patch).
H6 just probably has another extra undocummented bit, that's needed to disables
it properly.

You probably don't want a glitch to switch your RTC from high-precision
clock to a low precision one possibly without any indication in the userspace
or a kernel log.

Regardless of all this, DTS needs to have a correct description of the HW,
which means if RTC module is not connected to the 32.757kHz crystal/clock,
clocks property should be empty.

regards,
o.

> Best regards,
> Jernej
> 
> > regards,
> > o.
> > 
> > > > The real issue probably is that the mainline driver is missing this:
> > > > 
> > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n
> > > > 650
> > > 
> > > Not sure what you mean by that. ext vs. int source selection?
> > > 
> > > 
> > > 
> > > Best regards,
> > > Jernej
> > > 
> > > > regards,
> > > > 
> > > > o.
> 
> 
> 
> 

-- 
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/20190824212746.a5pyilkrrvysjjbd%40core.my.home.

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

[Ondřej Jirman]

On Sat, Aug 24, 2019 at 11:36:26PM +0200, Jernej Škrabec wrote:
> Dne sobota, 24. avgust 2019 ob 23:27:46 CEST je Ondřej Jirman napisal(a):
> > Hello Jernej,
> > 
> > On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote:
> > > > Visually?
> > > > 
> > > > That would explain why it doesn't work for you. The mainline RTC driver
> > > > disables auto-switch feature, and if your board doesn't have a crystal
> > > > for
> > > > LOSC, RTC will not generate a clock for the RTC.
> > > > 
> > > > H6's dtsi describes by default a situatiuon with external 32k crystal
> > > > oscillator. See ext_osc32k node. That's incorrect for your board if it
> > > > doesn't have the crystal. You need to fix this in the DTS for your board
> > > > instead of patching the driver.
> > > 
> > > I see that reparenting is supported, but I'm not sure how to fix that in
> > > DT. Any suggestion?
> > 
> > You may try removing the clocks property from rtc node.
> 
> I don't think this would work:
> https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L246

Well, I don't know. There has to be some way to make it work, since the code
deals with it here:

https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L270

Number of parents for LOSC is calculated from the DT somehow. Maybne something
to do with the #clock-cells property?

Sorry I can't be of more help here.

> > 
> > > > The driver has parent clock selection logic in case the LOSC crystal is
> > > > not
> > > > used.
> > > > 
> > > > Your patch enables automatic detection of LOSC failure and RTC changes
> > > > clock to LOSC automatically, despite what's described in the DTS. That
> > > > may fix the issue, but is not the correct solution.
> > > > 
> > > > Registers on my board look like this (external 32k osc is used) for
> > > > reference:
> > > > 
> > > > LOSC_CTRL_REG[700]: 8011
> > > > 
> > > > KEY_FIELD  ???  (0)
> > > > LOSC_AUTO_SWT_BYPASS   EN   (1)
> > > > LOSC_AUTO_SWT_EN   DIS  (0)
> > > > EXT_LOSC_ENEN   (1)
> > > > EXT_LOSC_GSM   LOW  (0)
> > > > BATTERY_DIRDISCHARGE(0)
> > > > LOSC_SRC_SEL   EXT32k   (1)
> > > > 
> > > > LOSC_AUTO_SWT_STA_REG[704]: 1
> > > > 
> > > > EXT_LOSC_STA   OK   (0)
> > > > LOSC_AUTO_SWT_PEND NOEFF(0)
> > > > LOSC_SRC_SEL_STA   EXT32K   (1)
> > > 
> > > In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG
> > > has value 0x4, so there is issue with external crystal (it's missing) and
> > > RTC switched to internal one.
> > > 
> > > BTW, what's wrong with automatic switching? Why is it disabled?
> > 
> > It always was disabled on mainline (bit 14 was set to 0 even before my
> > patch). H6 just probably has another extra undocummented bit, that's needed
> > to disables it properly.
> > 
> > You probably don't want a glitch to switch your RTC from high-precision
> > clock to a low precision one possibly without any indication in the
> > userspace or a kernel log.
> > 
> > Regardless of all this, DTS needs to have a correct description of the HW,
> > which means if RTC module is not connected to the 32.757kHz crystal/clock,
> > clocks property should be empty.
> 
> If we are talking about correct HW description, then clock property should 
> actually have possibility that two clocks are defined - one for internal RC 
> (always present) and one external crystal (optional). In such case I could 
> really just omit external clock and be done with it. But I'm not sure if such 

Internal RC is thought to be part of the RTC module, so it's not defined as an
input clock to the RTC module.

regards,
Ondrej

> 
> Best regards,
> Jernej
> 
> > 
> > regards,
> > o.
> > 
> > > Best regards,
> > > Jernej
> > > 
> > > > regards,
> > > > 
> > > > o.
> > > > 
> > > > > > The real issue probably is that the mainline driver is missing this:
> > > > > > 
> > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-b
> > > > > > sp#n
> > > > > > 650
> > > > > 
> > > > > Not sure what you mean by that. ext vs. int source selection?
> > > > > 
> > > > > 
> > > > > 
> > > > > Best regards,
> > > > > Jernej
> > > > > 
> > > > > > regards,
> > > > > > 
> > > > > > o.
> 
> 
> 
> 

-- 
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/20190824221638.ztoqpp5y6btshgit%40core.my.home.

[linux-sunxi] Re: [PATCH] arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delay

[Ondřej Jirman]

Hi,

On Tue, Aug 27, 2019 at 03:34:43PM +0200, Maxime Ripard wrote:
> On Sun, Aug 25, 2019 at 03:03:36PM +0200, Jernej Skrabec wrote:
> > Depending on kernel and bootloader configuration, it's possible that
> > Realtek ethernet PHY isn't powered on properly. It needs some time
> > before it can be used.
> >
> > Fix that by adding 100ms ramp delay to regulator responsible for
> > powering PHY.
> >
> > Fixes: 94dcfdc77fc5 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i")
> > Suggested-by: Ondrej Jirman 
> > Signed-off-by: Jernej Skrabec 
> 
> How was that delay found?

I suggested it. There's no delay in the dwmac-sun8i driver, so after enabling
the phy power, it will start accessing it over MDIO right away, which is not
good.

I suggested the value based on post-reset delay in the PHY's datasheet (30ms).
Multiplied ~3x (if I remember correctly) to get some safety margin. Chip has
more to do then after the HW reset, and regulator also needs some time to
ramp-up.

regards,
o.

> It should at least have a comment explaining why it's there.
> 
> 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/20190827134806.5l7dxyvzjrvabh7o%40core.my.home.

[linux-sunxi] Re: [PATCH 00/10] arm64: dts: allwinner: h5: Enable CPU DVFS (cpufreq)

[Ondřej Jirman]

Hi,

On Wed, Jan 30, 2019 at 04:41:53PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
> 
> This series enables DVFS for the CPU cores (aka cpufreq) on the
> Allwinner H5 SoC. The OPP table was taken from Armbian, with minor
> tweaks to the maximum voltage to account for slightly increased voltage
> on some of the boards.
> 
> This has been tested on the Bananapi M2+ v1.2 and Libre Computer
> ALL-H3-CC H5 ver..  I do not have the remaining boards so I've CC-ed
> people who did the original submission or have modified the board
> specifically later on.
> 
> Patch 1 fixes the voltages specified for the GPIO-controlled regulator
> on the Bananapi M2+ v1.2. The voltages are slightly higher than what
> was originally written.
> 
> Patch 2 adds a fixed regulator for the CPU on the original Bananapi M2+.
> This is for the retail version, not the engineering samples that had an
> even higher voltage setting.
> 
> Patch 3 hooks up the CPU regulator supply for H5 boards that already
> define the regulator, but were missing the property to tie it to the
> CPUs.
> 
> Patch 4 ~ 8 adds the CPU regulator for boards that don't have it
> defined. This is based on each vendor's schematics. I need people
> to test each of these specifically and the whole series.
> 
> Patch 9 ties the CPU clock to the CPU cores.
> 
> Patch 10 adds the OPP table, based on the one from Armbian.
> 
> Please have a look and please help test this.

Looks like this patch series got forgotten. Or is it waiting for some
user testing?

regards,
o.

> 
> Regards
> ChenYu
> 
> 
> Chen-Yu Tsai (10):
>   ARM: dts: sunxi: bananapi-m2-plus-v1.2: Fix CPU supply voltages
>   ARM: dts: bananapi-m2-plus: Add CPU supply regulator
>   arm64: dts: allwinner: h5: Hook up cpu regulator supplies
>   arm64: dts: allwinner: h5: nanopi-neo2: Add CPU regulator supply
>   arm64: dts: allwinner: h5: orange-pi-zero-plus: Add CPU regulator
> supply
>   arm64: dts: allwinner: h5: orange-pi-zero-plus2: Add CPU regulator
> supply
>   arm64: dts: allwinner: h5: orange-pi-pc2: Add CPU regulator supply
>   arm64: dts: allwinner: h5: orange-pi-prime: Add CPU regulator supply
>   arm64: dts: allwinner: h5: Add clock to CPU cores
>   arm64: dts: allwinner: h5: Add CPU Operating Performance Points table
> 
>  .../boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 30 +++-
>  arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 14 
>  .../sun50i-h5-emlid-neutis-n5-devboard.dts|  4 +
>  .../allwinner/sun50i-h5-nanopi-neo-plus2.dts  |  4 +
>  .../dts/allwinner/sun50i-h5-nanopi-neo2.dts   | 20 +
>  .../dts/allwinner/sun50i-h5-orangepi-pc2.dts  | 28 +++
>  .../allwinner/sun50i-h5-orangepi-prime.dts| 28 +++
>  .../sun50i-h5-orangepi-zero-plus.dts  | 20 +
>  .../sun50i-h5-orangepi-zero-plus2.dts | 20 +
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi  | 75 +++
>  10 files changed, 224 insertions(+), 19 deletions(-)
> 
> -- 
> 2.20.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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/20190902140323.fgfrifyow5qgoce4%40core.my.home.

Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?

[Ondřej Jirman]

On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote:
> Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a):
> > just check drm_mode_cursor_universal, cursor plane needs to support
> > DRM_FORMAT_ARGB
> > 
> > but VI layer doesn't support alpha, directly change VI layer to cursor
> > plane is not possible.
> > 
> > could we use UI layers?
> 
> Sure, but note that second mixer usually supports only one VI and one UI 
> plane. Note that primary plane is always on first UI, so you can run out of 
> UI 
> planes.
> 
> Most notable example of that combination is A64 HDMI, while LCD output on A64 
> has one VI and three UI planes. There is a switch in hardware to connect 1 VI/
> 3 UI mixer to A64 HDMI, but it's not implemented and user space would have to 
> be aware of that.

Each mixer channel has 4 sub-layers, so it should be possible even with one UI
channel to have a a cursor plane within it (with some constraints).

> Best regards,
> Jernej
> 
> > 
> > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote:
> > > Hi, Vasily
> > > 
> > > from source, it looks like VI layer is a video plane, right?
> > > 
> > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer is a way to
> > > support HW cursor,
> > > I want to ask whether it's possible to change VI layer type to cursor
> > > plane, then no changes in modesetting driver?
> > > 
> > > BR.
> > > Ning.
> > > 
> > > On Tuesday, September 3, 2019 at 11:21:48 PM UTC+8, Vasily Khoruzhick
> > > 
> > > wrote:
> > >> On Tue, Sep 3, 2019 at 1:49 AM 张宁  wrote:
> > >> > Hi, Maxime, Icenowy and other developers
> > >> > 
> > >> > In https://linux-sunxi.org/Xorg, it says legacy display engine driver
> > >> 
> > >> supports HW cursor, but there is no code actually creates a cursor plane
> > >> in
> > >> mainline linux, this is also said in:
> > >> https://groups.google.com/forum/#!searchin/linux-sunxi/subject$3A$20curso
> > >> r|sort:date/linux-sunxi/6dZVBtNgh5Q/dpBDfvEjBgAJ>> 
> > >> > currently,  lima usespace driver in mesa already has the basic function
> > >> 
> > >> for desktop, if lima is enabled, cursor rendering will possibly go GPU,
> > >> this will be less efficient than HW cursor.
> > >> 
> > >> > do you have plan to enable cursor plane?
> > >> 
> > >> That's up to X11 developers. sun4i-drm exposes UI and VI planes on
> > >> SoCs with DE2, and there's no dedicated cursor plane in hardware.
> > >> Basically sun4i-drm exposes what's available in hardware. But
> > >> xf86-video-modesetting doesn't use VI plane for anything while it
> > >> could use it for cursor.
> > >> 
> > >> Groups "linux-sunxi" group.
> > >> 
> > >> > To unsubscribe from this group and stop receiving emails from it, send
> > >> 
> > >> an email to linux...@googlegroups.com.
> > >> 
> > >> > To view this discussion on the web, visit
> > >> 
> > >> https://groups.google.com/d/msgid/linux-sunxi/8d091584-8e01-431d-b9b0-93d
> > >> d7e0f0cec%40googlegroups.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/8613808.bs98POC9MK%40jernej-laptop.

-- 
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/20190904204547.oizi6hzi6ftanunp%40core.my.home.

Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?

[Ondřej Jirman]

On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote:
> Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman napisal(a):
> > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote:
> > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a):
> > > > just check drm_mode_cursor_universal, cursor plane needs to support
> > > > DRM_FORMAT_ARGB
> > > > 
> > > > but VI layer doesn't support alpha, directly change VI layer to cursor
> > > > plane is not possible.
> > > > 
> > > > could we use UI layers?
> > > 
> > > Sure, but note that second mixer usually supports only one VI and one UI
> > > plane. Note that primary plane is always on first UI, so you can run out
> > > of UI planes.
> > > 
> > > Most notable example of that combination is A64 HDMI, while LCD output on
> > > A64 has one VI and three UI planes. There is a switch in hardware to
> > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented and user
> > > space would have to be aware of that.
> > 
> > Each mixer channel has 4 sub-layers, so it should be possible even with one
> > UI channel to have a a cursor plane within it (with some constraints).
> 
> If it's acceptable that cursor is square image then yes. There is no blending 
> between sub-layers.

Ah, bummer.

> > > Best regards,
> > > Jernej
> > > 
> > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote:
> > > > > Hi, Vasily
> > > > > 
> > > > > from source, it looks like VI layer is a video plane, right?
> > > > > 
> > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer is a
> > > > > way to
> > > > > support HW cursor,
> > > > > I want to ask whether it's possible to change VI layer type to cursor
> > > > > plane, then no changes in modesetting driver?
> > > > > 
> > > > > BR.
> > > > > Ning.
> > > > > 
> > > > > On Tuesday, September 3, 2019 at 11:21:48 PM UTC+8, Vasily Khoruzhick
> > > > > 
> > > > > wrote:
> > > > >> On Tue, Sep 3, 2019 at 1:49 AM 张宁  wrote:
> > > > >> > Hi, Maxime, Icenowy and other developers
> > > > >> > 
> > > > >> > In https://linux-sunxi.org/Xorg, it says legacy display engine
> > > > >> > driver
> > > > >> 
> > > > >> supports HW cursor, but there is no code actually creates a cursor
> > > > >> plane
> > > > >> in
> > > > >> mainline linux, this is also said in:
> > > > >> https://groups.google.com/forum/#!searchin/linux-sunxi/subject$3A$20c
> > > > >> urso
> > > > >> r|sort:date/linux-sunxi/6dZVBtNgh5Q/dpBDfvEjBgAJ>>
> > > > >> 
> > > > >> > currently,  lima usespace driver in mesa already has the basic
> > > > >> > function
> > > > >> 
> > > > >> for desktop, if lima is enabled, cursor rendering will possibly go
> > > > >> GPU,
> > > > >> this will be less efficient than HW cursor.
> > > > >> 
> > > > >> > do you have plan to enable cursor plane?
> > > > >> 
> > > > >> That's up to X11 developers. sun4i-drm exposes UI and VI planes on
> > > > >> SoCs with DE2, and there's no dedicated cursor plane in hardware.
> > > > >> Basically sun4i-drm exposes what's available in hardware. But
> > > > >> xf86-video-modesetting doesn't use VI plane for anything while it
> > > > >> could use it for cursor.
> > > > >> 
> > > > >> Groups "linux-sunxi" group.
> > > > >> 
> > > > >> > To unsubscribe from this group and stop receiving emails from it,
> > > > >> > send
> > > > >> 
> > > > >> an email to linux...@googlegroups.com.
> > > > >> 
> > > > >> > To view this discussion on the web, visit
> > > > >> 
> > > > >> https://groups.google.com/d/msgid/linux-sunxi/8d091584-8e01-431d-b9b0
> > > > >> -93d
> > > > >> d7e0f0cec%40googlegroups.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/20190904211015.r2nx5tohrhkxk7cc%40core.my.home.

Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?

[Ondřej Jirman]

On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote:
> Update my test result:
> 
> 1, use 1st UI layer as primary plane and 3rd UI layer as cursor plane.
> display normally but slow with fbdev
> display abnormally (only cursor shows) with modesetting (lima enabled)

You can "fix" this by switching to console and back. I've debugged this
somewhat and it the sun4i drm driver is probably buggy. The drm layers/
framebuffers are exactly same before and after the switch.

I have not yet dumped mixer registers before/after, but I suspect, there
will be some difference, for whatever reason.

regards,
o.

> 2, use VI layer as primary plane, and toppest UI layer as cursor plane
> display abnormal in both fbdev and modesetting( lima enabled)
> 
> so as said by Jernej: these sub-layers don't fit in current DRM design.
> 
> 
> On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec wrote:
> >
> > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman 
> > napisal(a): 
> > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote: 
> > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman 
> > napisal(a): 
> > > > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote: 
> > > > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a): 
> > > > > > > just check drm_mode_cursor_universal, cursor plane needs to 
> > support 
> > > > > > > DRM_FORMAT_ARGB 
> > > > > > > 
> > > > > > > but VI layer doesn't support alpha, directly change VI layer to 
> > > > > > > cursor 
> > > > > > > plane is not possible. 
> > > > > > > 
> > > > > > > could we use UI layers? 
> > > > > > 
> > > > > > Sure, but note that second mixer usually supports only one VI and 
> > one 
> > > > > > UI 
> > > > > > plane. Note that primary plane is always on first UI, so you can 
> > run 
> > > > > > out 
> > > > > > of UI planes. 
> > > > > > 
> > > > > > Most notable example of that combination is A64 HDMI, while LCD 
> > output 
> > > > > > on 
> > > > > > A64 has one VI and three UI planes. There is a switch in hardware 
> > to 
> > > > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented and 
> > > > > > user 
> > > > > > space would have to be aware of that. 
> > > > > 
> > > > > Each mixer channel has 4 sub-layers, so it should be possible even 
> > with 
> > > > > one 
> > > > > UI channel to have a a cursor plane within it (with some 
> > constraints). 
> > > > 
> > > > If it's acceptable that cursor is square image then yes. There is no 
> > > > blending between sub-layers. 
> > > 
> > > Ah, bummer. 
> > > 
> >
> > Looking at DE2 documentation, sub-layer concept is very simple from HW 
> > point 
> > of view. There is no adjustable Z-pos, scaling, blending or pixel format 
> > conversion (doc states that they must be in same format) between 
> > sub-layers. 
> > To no surprise DMA engine is not part of sub-layer according to mixer 
> > block 
> > diagram. It seems like that sub-layers part only feeds DMA with correct 
> > order 
> > of memory locations which DMA needs to transfer to the next unit (scaler 
> > in 
> > this case). 
> >
> > I don't think these sub-layers fit in current DRM design. I'm also not 
> > sure in 
> > which case they would be usable. 
> >
> > /offtopic 
> >
> > > > > > Best regards, 
> > > > > > Jernej 
> > > > > > 
> > > > > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote: 
> > > > > > > > Hi, Vasily 
> > > > > > > > 
> > > > > > > > from source, it looks like VI layer is a video plane, right? 
> > > > > > > > 
> > > > > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer 
> > is 
> > > > > > > > a 
> > > > > > > > way to 
> > > > > > > > support HW cursor, 
> > > > > > > > I want to ask whether it's possible to change VI layer type to 
> > > > > >

Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?

[Ondřej Jirman]

On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote:
> Update my test result:
> 
> 1, use 1st UI layer as primary plane and 3rd UI layer as cursor plane.
> display normally but slow with fbdev
> display abnormally (only cursor shows) with modesetting (lima enabled)

BTW, I use this patch:

https://megous.com/dl/tmp/0001-drm-sun4i-Mark-one-of-the-UI-planes-as-a-cursor-one.patch

o.

> 2, use VI layer as primary plane, and toppest UI layer as cursor plane
> display abnormal in both fbdev and modesetting( lima enabled)
> 
> so as said by Jernej: these sub-layers don't fit in current DRM design.
> 
> 
> On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec wrote:
> >
> > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman 
> > napisal(a): 
> > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote: 
> > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman 
> > napisal(a): 
> > > > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote: 
> > > > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a): 
> > > > > > > just check drm_mode_cursor_universal, cursor plane needs to 
> > support 
> > > > > > > DRM_FORMAT_ARGB 
> > > > > > > 
> > > > > > > but VI layer doesn't support alpha, directly change VI layer to 
> > > > > > > cursor 
> > > > > > > plane is not possible. 
> > > > > > > 
> > > > > > > could we use UI layers? 
> > > > > > 
> > > > > > Sure, but note that second mixer usually supports only one VI and 
> > one 
> > > > > > UI 
> > > > > > plane. Note that primary plane is always on first UI, so you can 
> > run 
> > > > > > out 
> > > > > > of UI planes. 
> > > > > > 
> > > > > > Most notable example of that combination is A64 HDMI, while LCD 
> > output 
> > > > > > on 
> > > > > > A64 has one VI and three UI planes. There is a switch in hardware 
> > to 
> > > > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented and 
> > > > > > user 
> > > > > > space would have to be aware of that. 
> > > > > 
> > > > > Each mixer channel has 4 sub-layers, so it should be possible even 
> > with 
> > > > > one 
> > > > > UI channel to have a a cursor plane within it (with some 
> > constraints). 
> > > > 
> > > > If it's acceptable that cursor is square image then yes. There is no 
> > > > blending between sub-layers. 
> > > 
> > > Ah, bummer. 
> > > 
> >
> > Looking at DE2 documentation, sub-layer concept is very simple from HW 
> > point 
> > of view. There is no adjustable Z-pos, scaling, blending or pixel format 
> > conversion (doc states that they must be in same format) between 
> > sub-layers. 
> > To no surprise DMA engine is not part of sub-layer according to mixer 
> > block 
> > diagram. It seems like that sub-layers part only feeds DMA with correct 
> > order 
> > of memory locations which DMA needs to transfer to the next unit (scaler 
> > in 
> > this case). 
> >
> > I don't think these sub-layers fit in current DRM design. I'm also not 
> > sure in 
> > which case they would be usable. 
> >
> > /offtopic 
> >
> > > > > > Best regards, 
> > > > > > Jernej 
> > > > > > 
> > > > > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote: 
> > > > > > > > Hi, Vasily 
> > > > > > > > 
> > > > > > > > from source, it looks like VI layer is a video plane, right? 
> > > > > > > > 
> > > > > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer 
> > is 
> > > > > > > > a 
> > > > > > > > way to 
> > > > > > > > support HW cursor, 
> > > > > > > > I want to ask whether it's possible to change VI layer type to 
> > > > > > > > cursor 
> > > > > > > > plane, then no changes in modesetting driver? 
> > > > > > > > 
> > > > > > > > BR. 
> > > > > > > > 

Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?

[Ondřej Jirman]

Hi,

On Sun, Sep 08, 2019 at 12:21:45AM +0200, megous hlavni wrote:
> On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote:
> > Update my test result:
> > 
> > 1, use 1st UI layer as primary plane and 3rd UI layer as cursor plane.
> > display normally but slow with fbdev
> > display abnormally (only cursor shows) with modesetting (lima enabled)
> 
> You can "fix" this by switching to console and back. I've debugged this
> somewhat and it the sun4i drm driver is probably buggy. The drm layers/
> framebuffers are exactly same before and after the switch.
> 
> I have not yet dumped mixer registers before/after, but I suspect, there
> will be some difference, for whatever reason.

So I have dumped registers, and found out this:

mixer0:

first Xorg run:

  0x01101000 : 0201
  0x01101080 : 0030

  BLD_FILL_COLOR_CTL: (aka SUN8I_MIXER_BLEND_PIPE_CTL)
P1_EN

  BLD_CH_RTCTL: (aka SUN8I_MIXER_BLEND_ROUTE)
P0_RTCTL channel0
P1_RTCTL channel3


after switch to console and back to Xorg:

0x01101000 : 0301
0x01101080 : 0031

  BLD_FILL_COLOR_CTL:
P1_EN and P0_EN

  BLD_CH_RTCTL:
P0_RTCTL channel1
P1_RTCTL channel3


This is despite the layers config being exactly the same as indicated
in /sys/kernel/debug/dri/0/{state,framebuffer}.

sun4i-drm driver just doesn't handle layer change correctly in all cases.

For example when enabling a layer, it may disable a different layer if
old_zpos matches the zpos of the other layer.

I've made a fix for this:

https://megous.com/git/linux/commit/?h=private-5.3&id=c186b256a869bab09103075a133f3c0d5f7b48cc
https://megous.com/git/linux/commit/?h=private-5.3&id=5af208e90de5ced30350fc0fba8419e9662e9bb7

So with these two patches, Xorg server/modesetting driver will use the cursor
plane, and plane enable/switching issues are gone (in general, even if you
don't use the cursor plane patch).

Anyway, this makes Xorg server work nicely with lima/panfrost without the
need to hack Xorg's modesetting driver to use non-cursor plane for cursor.

regards,
o.

> regards,
>   o.
> 
> > 2, use VI layer as primary plane, and toppest UI layer as cursor plane
> > display abnormal in both fbdev and modesetting( lima enabled)
> > 
> > so as said by Jernej: these sub-layers don't fit in current DRM design.
> > 
> > 
> > On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec wrote:
> > >
> > > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman 
> > > napisal(a): 
> > > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote: 
> > > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman 
> > > napisal(a): 
> > > > > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote: 
> > > > > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a): 
> > > > > > > > just check drm_mode_cursor_universal, cursor plane needs to 
> > > support 
> > > > > > > > DRM_FORMAT_ARGB 
> > > > > > > > 
> > > > > > > > but VI layer doesn't support alpha, directly change VI layer to 
> > > > > > > > cursor 
> > > > > > > > plane is not possible. 
> > > > > > > > 
> > > > > > > > could we use UI layers? 
> > > > > > > 
> > > > > > > Sure, but note that second mixer usually supports only one VI and 
> > > one 
> > > > > > > UI 
> > > > > > > plane. Note that primary plane is always on first UI, so you can 
> > > run 
> > > > > > > out 
> > > > > > > of UI planes. 
> > > > > > > 
> > > > > > > Most notable example of that combination is A64 HDMI, while LCD 
> > > output 
> > > > > > > on 
> > > > > > > A64 has one VI and three UI planes. There is a switch in hardware 
> > > to 
> > > > > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented 
> > > > > > > and 
> > > > > > > user 
> > > > > > > space would have to be aware of that. 
> > > > > > 
> > > > > > Each mixer channel has 4 sub-layers, so it should be possible even 
> > > with 
> > > > > > one 
> > > > > > UI channel to have a a cursor plane within it (with some 
> > > constraints). 
> > > > > 
> > > > > If it's acceptable that cursor is squar

Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?

[Ondřej Jirman]

Hi,

On Sun, Sep 08, 2019 at 07:01:42PM +0200, Jernej Škrabec wrote:
> Dne nedelja, 08. september 2019 ob 12:20:50 CEST je Ondřej Jirman napisal(a):
> > Hi,
> > 
> > On Sun, Sep 08, 2019 at 12:21:45AM +0200, megous hlavni wrote:
> > > On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote:
> > > > Update my test result:
> > > > 
> > > > 1, use 1st UI layer as primary plane and 3rd UI layer as cursor plane.
> > > > display normally but slow with fbdev
> > > > display abnormally (only cursor shows) with modesetting (lima enabled)
> > > 
> > > You can "fix" this by switching to console and back. I've debugged this
> > > somewhat and it the sun4i drm driver is probably buggy. The drm layers/
> > > framebuffers are exactly same before and after the switch.
> > > 
> > > I have not yet dumped mixer registers before/after, but I suspect, there
> > > will be some difference, for whatever reason.
> > 
> > So I have dumped registers, and found out this:
> > 
> > mixer0:
> > 
> > first Xorg run:
> > 
> >   0x01101000 : 0201
> >   0x01101080 : 0030
> > 
> >   BLD_FILL_COLOR_CTL: (aka SUN8I_MIXER_BLEND_PIPE_CTL)
> > P1_EN
> > 
> >   BLD_CH_RTCTL: (aka SUN8I_MIXER_BLEND_ROUTE)
> > P0_RTCTL channel0
> > P1_RTCTL channel3
> > 
> > 
> > after switch to console and back to Xorg:
> > 
> > 0x01101000 : 0301
> > 0x01101080 : 0031
> > 
> >   BLD_FILL_COLOR_CTL:
> > P1_EN and P0_EN
> > 
> >   BLD_CH_RTCTL:
> > P0_RTCTL channel1
> > P1_RTCTL channel3
> > 
> > 
> > This is despite the layers config being exactly the same as indicated
> > in /sys/kernel/debug/dri/0/{state,framebuffer}.
> > 
> > sun4i-drm driver just doesn't handle layer change correctly in all cases.
> > 
> > For example when enabling a layer, it may disable a different layer if
> > old_zpos matches the zpos of the other layer.
> > 
> > I've made a fix for this:
> > 
> > https://megous.com/git/linux/commit/?h=private-5.3&id=c186b256a869bab0910307
> > 5a133f3c0d5f7b48cc
> > https://megous.com/git/linux/commit/?h=private-5.3&id=5af208e90de5ced30350f
> > c0fba8419e9662e9bb7
> > 
> > So with these two patches, Xorg server/modesetting driver will use the
> > cursor plane, and plane enable/switching issues are gone (in general, even
> > if you don't use the cursor plane patch).
> > 
> > Anyway, this makes Xorg server work nicely with lima/panfrost without the
> > need to hack Xorg's modesetting driver to use non-cursor plane for cursor.
> 
> Why would that be a hack? AFAIK overlay plane has all and additional 
> functionality of cursor plane. I think it's better to change modesetting 
> driver to use overlay planes. Some (most?) cursor planes are limited and 
> really useful only for cursors, so apps might just skip them.

Read that as a synonym for "program". :)

Modesetting driver is a builtin and Xorg server releases are few and far
between, and I'm not going to wait for years and have to manage, compile, and
distribute my own patched Xorg server in the meantime if I don't have to. This
solution works and is pretty much equivalent. One layer would be lost to the
cursor use either way. And kernel change works with existing and legacy code.

I didn't even look at how hard it would be to change just for this reason alone.

Anyway, while having a special cursor plane is nice and lowers the CPU load
quite a bit while moving a mouse, the layer management bugs in the current code
need fixing first.

Maybe later we can add kernel command line option for optionally marking one of
the layers as a cursor one, so that people can choose what they want, depending
on their use case.

regards,
o.

> Best regards,
> Jernej
> 
> > 
> > regards,
> > o.
> > 
> > > regards,
> > > 
> > >   o.
> > >   
> > > > 2, use VI layer as primary plane, and toppest UI layer as cursor plane
> > > > display abnormal in both fbdev and modesetting( lima enabled)
> > > > 
> > > > so as said by Jernej: these sub-layers don't fit in current DRM design.
> > > > 
> > > > On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec 
> wrote:
> > > > > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman
> > > > > 
> > > > > napisal(a):
> > > > > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jerne

Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?

[Ondřej Jirman]

On Wed, Sep 04, 2019 at 11:38:01PM +0200, Jernej Škrabec wrote:
> Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman napisal(a):
> > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote:
> > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman 
> napisal(a):
> > > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote:
> > > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a):
> > > > > > just check drm_mode_cursor_universal, cursor plane needs to support
> > > > > > DRM_FORMAT_ARGB
> > > > > > 
> > > > > > but VI layer doesn't support alpha, directly change VI layer to
> > > > > > cursor
> > > > > > plane is not possible.
> > > > > > 
> > > > > > could we use UI layers?
> > > > > 
> > > > > Sure, but note that second mixer usually supports only one VI and one
> > > > > UI
> > > > > plane. Note that primary plane is always on first UI, so you can run
> > > > > out
> > > > > of UI planes.
> > > > > 
> > > > > Most notable example of that combination is A64 HDMI, while LCD output
> > > > > on
> > > > > A64 has one VI and three UI planes. There is a switch in hardware to
> > > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented and
> > > > > user
> > > > > space would have to be aware of that.
> > > > 
> > > > Each mixer channel has 4 sub-layers, so it should be possible even with
> > > > one
> > > > UI channel to have a a cursor plane within it (with some constraints).
> > > 
> > > If it's acceptable that cursor is square image then yes. There is no
> > > blending between sub-layers.
> > 
> > Ah, bummer.
> > 
> 
> Looking at DE2 documentation, sub-layer concept is very simple from HW point 
> of view. There is no adjustable Z-pos, scaling, blending or pixel format 
> conversion (doc states that they must be in same format) between sub-layers. 
> To no surprise DMA engine is not part of sub-layer according to mixer block 
> diagram. It seems like that sub-layers part only feeds DMA with correct order 
> of memory locations which DMA needs to transfer to the next unit (scaler in 
> this case).
> 
> I don't think these sub-layers fit in current DRM design. I'm also not sure 
> in 
> which case they would be usable.

It would probably be usable if you don't need transparency and scaling inside
the square areas for each sub-layer.

Myabe some hypothetical tiling WM would be able to use that many layers. The
layers would not even need to overlap, or have differnent FB formats.

Z-ordering can be done by not having a fixed mapping between DRM planes and DE2
layers/sub-layers and doing the mapping dynamically based on the desired zpos
for each sub-layer. Anyway if the sub-layers don't overlap there's no need for
Z-ordering.

I aggree that the current DRM API is not a great match for exposing this.

regards,
o.

> /offtopic
> 
> > > > > Best regards,
> > > > > Jernej
> > > > > 
> > > > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote:
> > > > > > > Hi, Vasily
> > > > > > > 
> > > > > > > from source, it looks like VI layer is a video plane, right?
> > > > > > > 
> > > > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer is
> > > > > > > a
> > > > > > > way to
> > > > > > > support HW cursor,
> > > > > > > I want to ask whether it's possible to change VI layer type to
> > > > > > > cursor
> > > > > > > plane, then no changes in modesetting driver?
> > > > > > > 
> > > > > > > BR.
> > > > > > > Ning.
> > > > > > > 
> > > > > > > On Tuesday, September 3, 2019 at 11:21:48 PM UTC+8, Vasily
> > > > > > > Khoruzhick
> > > > > > > 
> > > > > > > wrote:
> > > > > > >> On Tue, Sep 3, 2019 at 1:49 AM 张宁  wrote:
> > > > > > >> > Hi, Maxime, Icenowy and other developers
> > > > > > >> > 
> > > > > > >> > In https://linux-sunxi.org/Xorg, it says legacy display engine
> > > &

[linux-sunxi] Re: [PATCH v4 00/10] Allwinner sunxi message box support

[Ondřej Jirman]

Hello Samuel,

On Mon, Aug 19, 2019 at 10:23:01PM -0500, Samuel Holland wrote:
> This series adds support for the "hardware message box" in sun8i, sun9i,
> and sun50i SoCs, used for communication with the ARISC management
> processor (the platform's equivalent of the ARM SCP). The end goal is to
> use the arm_scpi driver as a client, communicating with firmware running
> on the AR100 CPU, or to use the mailbox to forward NMIs that the
> firmware picks up from R_INTC.
> 
> Unfortunately, the ARM SCPI client no longer works with this driver
> since it now exposes all 8 hardware FIFOs individually. The SCPI client
> could be made to work (and I posted proof-of-concept code to that effect
> with v1 of this series), but that is a low priority, as Linux does not
> directly use SCPI with the current firmware version; all SCPI use goes
> through ATF via PSCI.
> 
> As requested in the comments to v3 of this patchset, a demo client is
> provided in the final patch. This demo goes along with a toy firmware
> which shows that the driver does indeed work for two-way communication
> on all channels. To build the firmware component, run:

I've tried using this driver with mainline arm_scpi driver (which is probably
an expected future use, since crust provides SCPI interface).

The problem I've found is that arm_scpi expects message box to be
bi-directional, but this driver provides uni-directional interface.

What do you think about making this driver provide bi-directional interface?
We could halve the number of channels to 4 and mandate TX/RX configuration
(from main CPU's PoV) as ABI.

Otherwise it's impossible to use it with the arm_scpi driver.

Or do you have any other ideas? I guess arm_scpi can be fixed to add a
property that would make it possible to use single shmem with two
mailboxes, one for rx and one for tx, but making sun6i mailbox have
bi-directional interface sounds easier.

regards,
o.

>   git clone https://github.com/crust-firmware/meta meta
>   git clone -b mailbox-demo https://github.com/crust-firmware/crust meta/crust
>   cd meta
>   make
> 
> That will by default produce a U-Boot + ATF + SCP firmware image in
> [meta/]build/pinebook/u-boot-sunxi-with-spl.bin. See the top-level
> README.md for more information, such as cross-compiler setup.
> 
> I've now used this driver with three separate clients over the past two
> years, and they all work. If there are no remaining concerns with the
> driver, I'd like it to get merged.
> 
> Even without the driver, the clock patches (1-2) can go in at any time.
> 
> Changes from v3:
>   - Rebased on sunxi-next
>   - Added Rob's Reviewed-by for patch 3
>   - Fixed a crash when receiving a message on a disabled channel
>   - Cleaned up some comments/formatting in the driver
>   - Fixed #mbox-cells in sunxi-h3-h5.dtsi (patch 7)
>   - Removed the irqchip example (no longer relevant to the fw design)
>   - Added a demo/example client that uses the driver and a toy firmware
> 
> Changes from v2:
>   - Merge patches 1-3
>   - Add a comment in the code explaining the CLK_IS_CRITICAL usage
>   - Add a patch to mark the AR100 clocks as critical
>   - Use YAML for the device tree binding
>   - Include a not-for-merge example usage of the mailbox
> 
> Changes from v1:
>   - Marked message box clocks as critical instead of hacks in the driver
>   - 8 unidirectional channels instead of 4 bidirectional pairs
>   - Use per-SoC compatible strings and an A31 fallback compatible
>   - Dropped the mailbox framework patch
>   - Include DT patches for SoCs that document the message box
> 
> Samuel Holland (10):
>   clk: sunxi-ng: Mark msgbox clocks as critical
>   clk: sunxi-ng: Mark AR100 clocks as critical
>   dt-bindings: mailbox: Add a sunxi message box binding
>   mailbox: sunxi-msgbox: Add a new mailbox driver
>   ARM: dts: sunxi: a80: Add msgbox node
>   ARM: dts: sunxi: a83t: Add msgbox node
>   ARM: dts: sunxi: h3/h5: Add msgbox node
>   arm64: dts: allwinner: a64: Add msgbox node
>   arm64: dts: allwinner: h6: Add msgbox node
>   [DO NOT MERGE] drivers: firmware: msgbox demo
> 
>  .../mailbox/allwinner,sunxi-msgbox.yaml   |  79 +
>  arch/arm/boot/dts/sun8i-a83t.dtsi |  10 +
>  arch/arm/boot/dts/sun9i-a80.dtsi  |  10 +
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi|  10 +
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  34 ++
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi  |  24 ++
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  |  10 +
>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c |   3 +-
>  drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c|   2 +-
>  drivers/clk/sunxi-ng/ccu-sun50i-h6.c  |   3 +-
>  drivers/clk/sunxi-ng/ccu-sun8i-a23.c  |   3 +-
>  drivers/clk/sunxi-ng/ccu-sun8i-a33.c  |   3 +-
>  drivers/clk/sunxi-ng/ccu-sun8i-a83t.c |   3 +-
>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c   |   3 +-
>  drivers/clk/sunxi-ng/ccu-sun8i-r.c|   2 +-
>  drivers/clk/sunxi-ng/ccu-sun9i-a

[linux-sunxi] Re: [PATCH v4 00/10] Allwinner sunxi message box support

[Ondřej Jirman]

Hi,

On Sun, Sep 08, 2019 at 10:54:17PM -0500, Samuel Holland wrote:
> On 9/8/19 10:22 PM, Ondřej Jirman wrote:
> > Hello Samuel,
> > 
> > On Mon, Aug 19, 2019 at 10:23:01PM -0500, Samuel Holland wrote:
> >> This series adds support for the "hardware message box" in sun8i, sun9i,
> >> and sun50i SoCs, used for communication with the ARISC management
> >> processor (the platform's equivalent of the ARM SCP). The end goal is to
> >> use the arm_scpi driver as a client, communicating with firmware running
> >> on the AR100 CPU, or to use the mailbox to forward NMIs that the
> >> firmware picks up from R_INTC.
> >>
> >> Unfortunately, the ARM SCPI client no longer works with this driver
> >> since it now exposes all 8 hardware FIFOs individually. The SCPI client
> >> could be made to work (and I posted proof-of-concept code to that effect
> >> with v1 of this series), but that is a low priority, as Linux does not
> >> directly use SCPI with the current firmware version; all SCPI use goes
> >> through ATF via PSCI.
> >>
> >> As requested in the comments to v3 of this patchset, a demo client is
> >> provided in the final patch. This demo goes along with a toy firmware
> >> which shows that the driver does indeed work for two-way communication
> >> on all channels. To build the firmware component, run:
> > 
> > I've tried using this driver with mainline arm_scpi driver (which is 
> > probably
> > an expected future use, since crust provides SCPI interface).
> 
> If you've verified in some way that this driver works on A83T, I'd appreciate
> your Tested-by, so I can send a patch for the A83T device tree node.

Tested-by: Ondrej Jirman 

(on A83T)

> > The problem I've found is that arm_scpi expects message box to be
> > bi-directional, but this driver provides uni-directional interface.
> > 
> > What do you think about making this driver provide bi-directional interface?
> > We could halve the number of channels to 4 and mandate TX/RX configuration
> > (from main CPU's PoV) as ABI.
> 
> Funny you mention that. That's what I did originally for v1, but it got NAKed 
> by
> Maxime, Andre, and Jassi:
> 
> https://lkml.org/lkml/2018/2/28/125
> https://lkml.org/lkml/2018/2/28/944
> 
> > Otherwise it's impossible to use it with the arm_scpi driver.
> > 
> > Or do you have any other ideas? I guess arm_scpi can be fixed to add a
> > property that would make it possible to use single shmem with two
> > mailboxes, one for rx and one for tx, but making sun6i mailbox have
> > bi-directional interface sounds easier.
> 
> Yes, you can use the existence of the mbox-names property to determine if the
> driver needs one mailbox or two, as I did in this driver:
> 
> https://lkml.org/lkml/2019/3/1/789
> 
> I'll have a patch available soon that implements this for arm_scpi.

Yeah, I've patched arm_scpi too. :)

https://megous.com/git/linux/commit/?h=tbs-5.3&id=69a0cd0093a63039ace2f763e8d82009c50ff03c

(but that's just for the test, because it breaks the existing interface for
other uses)

Anyway, using mbox-names looks like a nice solution! Thanks! Though,
arm_scpi driver has a bit more complicated existing interface, where it can use
multiple mailboxes and rotates through them after every message.

BTW, I'm slowly laboring through understanding how to get suspend to ram working
on one A83T tablet. https://xnux.eu/tablet-hacking/ Which is how I tested this
driver.

regards,
o.

> Cheers,
> Samuel
> 
> > regards,
> > o.
> > 
> >>   git clone https://github.com/crust-firmware/meta meta
> >>   git clone -b mailbox-demo https://github.com/crust-firmware/crust 
> >> meta/crust
> >>   cd meta
> >>   make
> >>
> >> That will by default produce a U-Boot + ATF + SCP firmware image in
> >> [meta/]build/pinebook/u-boot-sunxi-with-spl.bin. See the top-level
> >> README.md for more information, such as cross-compiler setup.
> >>
> >> I've now used this driver with three separate clients over the past two
> >> years, and they all work. If there are no remaining concerns with the
> >> driver, I'd like it to get merged.
> >>
> >> Even without the driver, the clock patches (1-2) can go in at any time.
> >>
> >> Changes from v3:
> >>   - Rebased on sunxi-next
> >>   - Added Rob's Reviewed-by for patch 3
> >>   - Fixed a crash when receiving a message on a disabled channel
> >>   - Cleaned up some comments/for

Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?

[Ondřej Jirman]

On Tue, Sep 17, 2019 at 08:55:42AM -0700, security researcher wrote:
> What's the latest solution here? I see a few patches in the thread, but not 
> sure which ones to pick and choose?

Use both:

 
https://megous.com/git/linux/commit/?h=private-5.3&id=c186b256a869bab09103075a133f3c0d5f7b48cc
 
 
https://megous.com/git/linux/commit/?h=private-5.3&id=5af208e90de5ced30350fc0fba8419e9662e9bb7
 

> On Monday, September 9, 2019 at 1:27:08 AM UTC, 张宁 wrote:
> >
> > thanks for your patches.
> >
> > BR.
> > Ning.
> >
> > On Sunday, September 8, 2019 at 6:20:54 PM UTC+8, Ondřej Jirman wrote:
> >>
> >> Hi, 
> >>
> >> On Sun, Sep 08, 2019 at 12:21:45AM +0200, megous hlavni wrote: 
> >> > On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote: 
> >> > > Update my test result: 
> >> > > 
> >> > > 1, use 1st UI layer as primary plane and 3rd UI layer as cursor 
> >> plane. 
> >> > > display normally but slow with fbdev 
> >> > > display abnormally (only cursor shows) with modesetting (lima 
> >> enabled) 
> >> > 
> >> > You can "fix" this by switching to console and back. I've debugged this 
> >> > somewhat and it the sun4i drm driver is probably buggy. The drm layers/ 
> >> > framebuffers are exactly same before and after the switch. 
> >> > 
> >> > I have not yet dumped mixer registers before/after, but I suspect, 
> >> there 
> >> > will be some difference, for whatever reason. 
> >>
> >> So I have dumped registers, and found out this: 
> >>
> >> mixer0: 
> >>
> >> first Xorg run: 
> >>
> >>   0x01101000 : 0201 
> >>   0x01101080 : 0030 
> >>
> >>   BLD_FILL_COLOR_CTL: (aka SUN8I_MIXER_BLEND_PIPE_CTL) 
> >> P1_EN 
> >>
> >>   BLD_CH_RTCTL: (aka SUN8I_MIXER_BLEND_ROUTE) 
> >> P0_RTCTL channel0 
> >> P1_RTCTL channel3 
> >>
> >>
> >> after switch to console and back to Xorg: 
> >>
> >> 0x01101000 : 0301 
> >> 0x01101080 : 0031 
> >>
> >>   BLD_FILL_COLOR_CTL: 
> >> P1_EN and P0_EN 
> >>
> >>   BLD_CH_RTCTL: 
> >> P0_RTCTL channel1 
> >> P1_RTCTL channel3 
> >>
> >>
> >> This is despite the layers config being exactly the same as indicated 
> >> in /sys/kernel/debug/dri/0/{state,framebuffer}. 
> >>
> >> sun4i-drm driver just doesn't handle layer change correctly in all cases. 
> >>
> >> For example when enabling a layer, it may disable a different layer if 
> >> old_zpos matches the zpos of the other layer. 
> >>
> >> I've made a fix for this: 
> >>
> >>
> >> https://megous.com/git/linux/commit/?h=private-5.3&id=c186b256a869bab09103075a133f3c0d5f7b48cc
> >>  
> >>
> >> https://megous.com/git/linux/commit/?h=private-5.3&id=5af208e90de5ced30350fc0fba8419e9662e9bb7
> >>  
> >>
> >> So with these two patches, Xorg server/modesetting driver will use the 
> >> cursor 
> >> plane, and plane enable/switching issues are gone (in general, even if 
> >> you 
> >> don't use the cursor plane patch). 
> >>
> >> Anyway, this makes Xorg server work nicely with lima/panfrost without the 
> >> need to hack Xorg's modesetting driver to use non-cursor plane for 
> >> cursor. 
> >>
> >> regards, 
> >> o. 
> >>
> >> > regards, 
> >> > o. 
> >> > 
> >> > > 2, use VI layer as primary plane, and toppest UI layer as cursor 
> >> plane 
> >> > > display abnormal in both fbdev and modesetting( lima enabled) 
> >> > > 
> >> > > so as said by Jernej: these sub-layers don't fit in current DRM 
> >> design. 
> >> > > 
> >> > > 
> >> > > On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec 
> >> wrote: 
> >> > > > 
> >> > > > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman 
> >> > > > napisal(a): 
> >> > > > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote: 
> >> > > > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman 
> >> > > > napisal(a): 
> >> > > > > &

Re: [linux-sunxi] [PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"

[Ondřej Jirman]

HI Icenowy,

On Sun, Oct 06, 2019 at 11:12:43PM +0800, Icenowy Zheng wrote:
> 在 2019-10-06日的 22:44 +0800，Icenowy Zheng写道：
> > 在 2019-10-03四的 09:53 +0530，Jagan Teki写道：
> > > Hi Wens,
> > > 
> > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng 
> > > wrote:
> > > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b.
> > > > 
> > > > This commit, although claimed as a refactor, in fact changed the
> > > > formula.
> > > > 
> > > > By expanding the original formula, we can find that the const 10
> > > > is
> > > > not
> > > > substracted, instead it's added to the value (because 10 is
> > > > negative
> > > > when calculating hsa, and hsa itself is negative when calculating
> > > > hblk).
> > > > This breaks the similar pattern to other formulas, so restoring
> > > > the
> > > > original formula is more proper.
> > > > 
> > > > Signed-off-by: Icenowy Zheng 
> > > > ---
> > > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++---
> > > >  1 file changed, 2 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > index 2d3e822a7739..cb5fd19c0d0d 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct
> > > > sun6i_dsi *dsi,
> > > >   (mode->hsync_start - mode->hdisplay) *
> > > > Bpp - HFP_PACKET_OVERHEAD);
> > > > 
> > > > /*
> > > > -* The blanking is set using a sync event (4
> > > > bytes)
> > > > -* and a blanking packet (4 bytes + payload + 2
> > > > -* bytes). Its minimal size is therefore 10
> > > > bytes.
> > > > +* hblk seems to be the line + porches length.
> > > >  */
> > > > -#define HBLK_PACKET_OVERHEAD   10
> > > > -   hblk = max((unsigned int)HBLK_PACKET_OVERHEAD,
> > > > -  (mode->htotal - (mode->hsync_end -
> > > > mode-
> > > > > hsync_start)) * Bpp -
> > > > -  HBLK_PACKET_OVERHEAD);
> > > > +   hblk = mode->htotal * Bpp - hsa;
> > > 
> > > The original formula is correct according to BSP [1] and work with
> > > my
> > > panels which I have tested before. May be the horizontal timings on
> > > panels you have leads to negative value.
> > 
> > Do you tested the same timing with BSP kernel?
> > 
> > It's quite difficult to get a negative value here, because the value
> > is
> > quite big (includes mode->hdisplay * Bpp).
> 
> By re-checking with the BSP source code, I found that the constant in
> the HFP formula is indeed wrong -- it should be 16, not 6.

I'm not sure if it's relevant to the discussion, but I've recently found
a LCD configuration manual for A10, that may contain some useful info:

See this: 
https://github.com/pocketbook/Platform_A13/blob/master/Kernel/drivers/video/sun5i/lcd/a10_lcd_config_nanual_v1.0.pdf

regards,
o.

> > 
> > Strangely, only change the formula here back makes the timing
> > translated from FEX file works (tested on PineTab and PinePhone
> > production ver). The translation rule is from [1].
> > 
> > So I still insist on the patch because it's needed by experiment.
> > 
> > [1] http://linux-sunxi.org/LCD
> > 
> > > [1] 
> > > https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L919
> 
> -- 
> 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/14da3ae768c439e387f6609553bd465e945d4a33.camel%40aosc.io.

-- 
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/20191007151919.4uraoe374lui22gi%40core.my.home.

[linux-sunxi] Re: [U-Boot] [PATCH] sunxi: set PIO voltage to hardware-detected value on startup on H6

[Ondřej Jirman]

Hi,

On Wed, Apr 24, 2019 at 01:44:12PM +0800, Icenowy Zheng wrote:
> The Allwinner H6 SoC has a register to set the PIO banks' voltage. When
> it mismatches the real voltage supplied to the VCC to the PIO supply,
> the PIO will work improperly.
> 
> The PIO controller also has a register that contains the status of each
> VCC rail of the PIO supplies, and it has the same definition with the
> configuration register. so we can just copy the content of this register
> to the configuration register at startup, to ensure the configuration is
> correct at startup stage.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/include/asm/arch-sunxi/gpio.h | 3 +++
>  arch/arm/mach-sunxi/board.c| 9 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index 40a3f845d0..a646ea6a3c 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -73,6 +73,9 @@ struct sunxi_gpio_reg {
>   struct sunxi_gpio_int gpio_int;
>  };
>  
> +#define SUN50I_H6_GPIO_POW_MOD_SEL   0x340
> +#define SUN50I_H6_GPIO_POW_MOD_VAL   0x348
> +
>  #define BANK_TO_GPIO(bank)   (((bank) < SUNXI_GPIO_L) ? \
>   &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank] : \
>   &((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)->gpio_bank[(bank) - 
> SUNXI_GPIO_L])
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index c6dd7b8e54..bd3b5d8303 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -65,6 +65,7 @@ struct mm_region *mem_map = sunxi_mem_map;
>  
>  static int gpio_init(void)

Does this really run after regulators are turned on? If not, how will the SoC
detect voltages correctly?

regards,
o.

>  {
> + __maybe__unused uint val;
>  #if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
>  #if defined(CONFIG_MACH_SUN4I) || \
>  defined(CONFIG_MACH_SUN7I) || \
> @@ -139,6 +140,14 @@ static int gpio_init(void)
>  #error Unsupported console port number. Please fix pin mux settings in 
> board.c
>  #endif
>  
> +#ifdef CONFIG_MACH_SUN50I_H6
> + /* Update PIO power bias configuration by copy hardware detected value 
> */
> + val = readl(SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
> + writel(val, SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
> + val = readl(SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
> + writel(val, SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
> +#endif
> +
>   return 0;
>  }
>  
> -- 
> 2.18.1
> 
> ___
> U-Boot mailing list
> u-b...@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

-- 
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/20191025125917.grpeemrlq45pupjz%40core.my.home.

[linux-sunxi] Re: [PATCH] input: sun4i-lradc-keys: Add wakup support

[Ondřej Jirman]

Hello Dmitry,

On Mon, Oct 28, 2019 at 04:38:28PM -0700, Dmitry Torokhov wrote:
> Hi Ondrej,
> 
> On Mon, Oct 28, 2019 at 11:15:02PM +0100, Ondrej Jirman wrote:
> > Allow the driver to wakeup the system on key press.
> > 
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  drivers/input/keyboard/sun4i-lradc-keys.c | 22 ++
> >  1 file changed, 18 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c 
> > b/drivers/input/keyboard/sun4i-lradc-keys.c
> > index 4a796bed48ac..bba679d7b54b 100644
> > --- a/drivers/input/keyboard/sun4i-lradc-keys.c
> > +++ b/drivers/input/keyboard/sun4i-lradc-keys.c
> > @@ -22,6 +22,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -226,8 +228,7 @@ static int sun4i_lradc_probe(struct platform_device 
> > *pdev)
> >  {
> > struct sun4i_lradc_data *lradc;
> > struct device *dev = &pdev->dev;
> > -   int i;
> > -   int error;
> > +   int i, error, irq;
> >  
> > lradc = devm_kzalloc(dev, sizeof(struct sun4i_lradc_data), GFP_KERNEL);
> > if (!lradc)
> > @@ -272,8 +273,13 @@ static int sun4i_lradc_probe(struct platform_device 
> > *pdev)
> > if (IS_ERR(lradc->base))
> > return PTR_ERR(lradc->base);
> >  
> > -   error = devm_request_irq(dev, platform_get_irq(pdev, 0),
> > -sun4i_lradc_irq, 0,
> > +   irq = platform_get_irq(pdev, 0);
> > +   if (irq < 0) {
> > +   dev_err(&pdev->dev, "Failed to get IRQ\n");
> > +   return irq;
> > +   }
> > +
> > +   error = devm_request_irq(dev, irq, sun4i_lradc_irq, 0,
> >  "sun4i-a10-lradc-keys", lradc);
> > if (error)
> > return error;
> > @@ -282,6 +288,14 @@ static int sun4i_lradc_probe(struct platform_device 
> > *pdev)
> > if (error)
> > return error;
> >  
> > +   device_init_wakeup(dev, true);
> 
> I do not think we want to do this unconditionally. Can we maybe key off
> "wakeup-source" device property.

Sure thing.

> > +
> > +   error = dev_pm_set_wake_irq(dev, irq);
> > +   if (error) {
> > +   dev_err(dev, "Could not set wake IRQ\n");
> > +   return error;
> > +   }
> > +
> 
> I wonder if we could teach platform driver core to handle this for us.

Not sure, some drivers do enable/disable wake_irq by hand in suspend/resume
callbacks, so it would probably need to be opt-in somehow. I guess calling the
function like this is one way to make it opt-in.

The other way may be by passing a flag somewhere, like to
request_threaded_irq. Did you have something more concrete in mind?

regards,
o.

> Thanks.
> 
> -- 
> Dmitry

-- 
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/20191028235626.5afvszxtppsieywi%40core.my.home.

Re: [linux-sunxi] [PATCH] ARM: sunxi: Fix CPU powerdown on A83T

[Ondřej Jirman]

On Tue, Oct 29, 2019 at 09:09:40AM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 29, 2019 at 5:49 AM Ondrej Jirman  wrote:
> >
> > PRCM_PWROFF_GATING_REG has CPU0 at bit 4 on A83T. So without this
> > patch, instead of gating the CPU0, the whole cluster was power gated,
> > when shutting down first CPU in the cluster.
> >
> > Fixes: 6961275e72a8c1 ("ARM: sun8i: smp: Add support for A83T")
> > Signed-off-by: Ondrej Jirman 
> > Cc: sta...@vger.kernel.org
> 
> Acked-by: Chen-Yu Tsai 
> 
> Though I distinctly remember the BSP had some code dealing with chip
> revisions in which the two bits were reversed. :(

Actually, it's a bit more complicated. There's a special check in BSP
code (grep for SUN8IW6P1_REV_A) that instead of power gating, just
holds the core in reset for that revision.

regards,
o.

-- 
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/20191029012517.eddekmphtxyslevx%40core.my.home.

Re: [linux-sunxi] Re: [PATCH] input: sun4i-lradc-keys: Add wakup support

[Ondřej Jirman]

On Mon, Oct 28, 2019 at 05:12:50PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 29, 2019 at 12:56:26AM +0100, Ondřej Jirman wrote:
> > On Mon, Oct 28, 2019 at 04:38:28PM -0700, Dmitry Torokhov wrote:
> > > > +
> > > > +   error = dev_pm_set_wake_irq(dev, irq);
> > > > +   if (error) {
> > > > +   dev_err(dev, "Could not set wake IRQ\n");
> > > > +   return error;
> > > > +   }
> > > > +
> > > 
> > > I wonder if we could teach platform driver core to handle this for us.
> > 
> > Not sure, some drivers do enable/disable wake_irq by hand in suspend/resume
> > callbacks, so it would probably need to be opt-in somehow. I guess calling 
> > the
> > function like this is one way to make it opt-in.
> > 
> > The other way may be by passing a flag somewhere, like to
> > request_threaded_irq. Did you have something more concrete in mind?
> 
> I think it is perfectly fine to continue using enable_irq_wake and
> disable_irq_wake from the driver while marking irq as being wake irq
> form the core.

I see, it looks like irq_set_irq_wake will track the calls via wake_depth

https://elixir.bootlin.com/linux/latest/source/kernel/irq/manage.c#L714

But all irqs are not necessarily wake irqs, no? So it still may need to be
opt-in somehow.

Anyway, I'm no PM expert. I started looking at PM code about two weeks ago, and
I really don't feel like I can contribute much to these kinds of decisions with
my current level of understanding, right now.

regards,
o.

> Thanks.
> 
> -- 
> Dmitry
> 
> -- 
> 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/20191029001250.GB57214%40dtor-ws.

-- 
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/20191029014559.gif3ay7anq24un2i%40core.my.home.

[linux-sunxi] Re: [PATCH 3/3] arm: dts: sun8i: a83t: a711: Add touchscreen node

[Ondřej Jirman]

Hello Marco,

On Tue, Oct 29, 2019 at 10:08:01AM +0100, Marco Felsch wrote:
> Hi,
> 
> On 19-10-29 01:58, Ondrej Jirman wrote:
> > From: Mylčne Josserand 
> > 
> > Enable a FocalTech EDT-FT5x06 Polytouch touchscreen.
> > 
> > Signed-off-by: Ondrej Jirman 
> > Signed-off-by: Mylčne Josserand 
> > ---
> >  arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts 
> > b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > index 568b90ece342..19f520252dc5 100644
> > --- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > +++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > @@ -164,6 +164,22 @@
> > status = "okay";
> >  };
> >  
> > +&i2c0 {
> > +   clock-frequency = <40>;
> > +   status = "okay";
> > +
> > +   touchscreen@38 {
> > +   compatible = "edt,edt-ft5x06";
> > +   reg = <0x38>;
> > +   interrupt-parent = <&r_pio>;
> > +   interrupts = <0 7 IRQ_TYPE_EDGE_FALLING>; /* PL7 */
> > +   reset-gpios = <&pio 3 5 GPIO_ACTIVE_LOW>; /* PD5 */
> > +   vcc-supply = <®_ldo_io0>;
> > +   touchscreen-size-x = <1024>;
> > +   touchscreen-size-y = <600>;
> 
> Do you want this touchscreen as wakeup-src? If so please add the
> property here. I've send patches converting the driver from the default
> behaviour: https://patchwork.kernel.org/cover/11149039/ and all agreed
> to break backward compatibility.

Not at this moment, thank you.

regards,
o.

> Regards,
>   Marco
> 
> > +   };
> > +};
> > +
> >  &i2c1 {
> > clock-frequency = <40>;
> > status = "okay";
> > -- 
> > 2.23.0
> > 
> > 
> 
> -- 
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

-- 
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/20191029111339.7okiyig3tbehn5kj%40core.my.home.

[linux-sunxi] Re: [PATCH 1/3] input: edt-ft5x06: Add support for regulator

[Ondřej Jirman]

Hi Marco,

On Tue, Oct 29, 2019 at 09:55:45AM +0100, Marco Felsch wrote:
> Hi Dmitry,
> 
> On 19-10-28 21:12, Dmitry Torokhov wrote:
> > On Tue, Oct 29, 2019 at 01:58:04AM +0100, Ondrej Jirman wrote:
> > > From: Mylčne Josserand 
> > > 
> > > Add the support for enabling optional regulator that may be used as VCC
> > > source.
> > > 
> > > Signed-off-by: Ondrej Jirman 
> > > Signed-off-by: Mylčne Josserand 
> > 
> > Applied, thank you.
> 
> What happens with my vdd patches?

Sorry for not noticing your patches, I was only aware of Mylčne's older series.
It looks like you can just skip regulator enable support from your series, and
re-send the deep-sleep mechanism and wakeup source patches only.

I'll test it with my board, and give you a tested-by.

thank you and regards,
o.

> Regards,
>   Marco
> 
> > 
> > > ---
> > >  drivers/input/touchscreen/edt-ft5x06.c | 30 ++
> > >  1 file changed, 30 insertions(+)
> > > 
> > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> > > b/drivers/input/touchscreen/edt-ft5x06.c
> > > index 5525f1fb1526..d61731c0037d 100644
> > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > @@ -28,6 +28,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  #define WORK_REGISTER_THRESHOLD  0x00
> > >  #define WORK_REGISTER_REPORT_RATE0x08
> > > @@ -88,6 +89,7 @@ struct edt_ft5x06_ts_data {
> > >   struct touchscreen_properties prop;
> > >   u16 num_x;
> > >   u16 num_y;
> > > + struct regulator *vcc;
> > >  
> > >   struct gpio_desc *reset_gpio;
> > >   struct gpio_desc *wake_gpio;
> > > @@ -1036,6 +1038,13 @@ edt_ft5x06_ts_set_regs(struct edt_ft5x06_ts_data 
> > > *tsdata)
> > >   }
> > >  }
> > >  
> > > +static void edt_ft5x06_disable_regulator(void *arg)
> > > +{
> > > + struct edt_ft5x06_ts_data *data = arg;
> > > +
> > > + regulator_disable(data->vcc);
> > > +}
> > > +
> > >  static int edt_ft5x06_ts_probe(struct i2c_client *client,
> > >const struct i2c_device_id *id)
> > >  {
> > > @@ -1064,6 +1073,27 @@ static int edt_ft5x06_ts_probe(struct i2c_client 
> > > *client,
> > >  
> > >   tsdata->max_support_points = chip_data->max_support_points;
> > >  
> > > + tsdata->vcc = devm_regulator_get(&client->dev, "vcc");
> > > + if (IS_ERR(tsdata->vcc)) {
> > > + error = PTR_ERR(tsdata->vcc);
> > > + if (error != -EPROBE_DEFER)
> > > + dev_err(&client->dev,
> > > + "failed to request regulator: %d\n", error);
> > > + return error;
> > > + }
> > > +
> > > + error = regulator_enable(tsdata->vcc);
> > > + if (error < 0) {
> > > + dev_err(&client->dev, "failed to enable vcc: %d\n", error);
> > > + return error;
> > > + }
> > > +
> > > + error = devm_add_action_or_reset(&client->dev,
> > > +  edt_ft5x06_disable_regulator,
> > > +  tsdata);
> > > + if (error)
> > > + return error;
> > > +
> > >   tsdata->reset_gpio = devm_gpiod_get_optional(&client->dev,
> > >"reset", GPIOD_OUT_HIGH);
> > >   if (IS_ERR(tsdata->reset_gpio)) {
> > > -- 
> > > 2.23.0
> > > 
> > 
> > -- 
> > Dmitry
> > 
> 
> -- 
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

-- 
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/20191029112129.t4mxqyybltjbuyhj%40core.my.home.

Re: [linux-sunxi] Re: [PATCH] input: sun4i-lradc-keys: Add wakup support

[Ondřej Jirman]

On Mon, Oct 28, 2019 at 09:18:04PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 29, 2019 at 02:45:59AM +0100, Ondřej Jirman wrote:
> > On Mon, Oct 28, 2019 at 05:12:50PM -0700, Dmitry Torokhov wrote:
> > > On Tue, Oct 29, 2019 at 12:56:26AM +0100, Ondřej Jirman wrote:
> > > > On Mon, Oct 28, 2019 at 04:38:28PM -0700, Dmitry Torokhov wrote:
> > > > > > +
> > > > > > +   error = dev_pm_set_wake_irq(dev, irq);
> > > > > > +   if (error) {
> > > > > > +   dev_err(dev, "Could not set wake IRQ\n");
> > > > > > +   return error;
> > > > > > +   }
> > > > > > +
> > > > > 
> > > > > I wonder if we could teach platform driver core to handle this for us.
> > > > 
> > > > Not sure, some drivers do enable/disable wake_irq by hand in 
> > > > suspend/resume
> > > > callbacks, so it would probably need to be opt-in somehow. I guess 
> > > > calling the
> > > > function like this is one way to make it opt-in.
> > > > 
> > > > The other way may be by passing a flag somewhere, like to
> > > > request_threaded_irq. Did you have something more concrete in mind?
> > > 
> > > I think it is perfectly fine to continue using enable_irq_wake and
> > > disable_irq_wake from the driver while marking irq as being wake irq
> > > form the core.
> > 
> > I see, it looks like irq_set_irq_wake will track the calls via wake_depth
> > 
> > https://elixir.bootlin.com/linux/latest/source/kernel/irq/manage.c#L714
> > 
> > But all irqs are not necessarily wake irqs, no? So it still may need to be
> > opt-in somehow.
> 
> I thought we'd do that for IRQ named "wakeirq" or the very first IRQ if
> there is no named IRQ, and when we have the "wakeup-source" property,
> similarly to what we do in I2C bus.

I see. I've looked at drivers using dev_pm_set_wake_irq and
dev_pm_set_dedicated_wake_irq and not many platform drivers would potentially
benefit (~25 out of 2300), of those only some use OF and are platform
drivers, maybe 15-20:

https://elixir.bootlin.com/linux/latest/ident/dev_pm_set_wake_irq
https://elixir.bootlin.com/linux/latest/ident/dev_pm_set_dedicated_wake_irq

I don't think it's worth it.

regards,
o.

> Thanks.
> 
> -- 
> Dmitry
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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/20191029124331.7yh5kccsq2syxm47%40core.my.home.

Re: [linux-sunxi] [PATCH] cpufreq: sun50i: Fix CPU speed bin detection

[Ondřej Jirman]

Hi,

On Thu, Oct 31, 2019 at 07:55:43PM +0100, Clément Péron wrote:
> Hi Ondrej,
> 
> On Thu, 31 Oct 2019 at 19:14, Ondrej Jirman  wrote:
> >
> > I have failures to boot on Orange Pi 3, because this driver determined
> > that my SoC is from the normal bin, but my SoC only works reliably with
> > the OPP values for the slowest bin.
> >
> > Looking at BSP code, I found that efuse values have following meanings
> > on H6:
> >
> > - 0b000 invalid (interpreted in vendor's BSP as normal bin)
> > - 0b001 slowest bin
> > - 0b011 normal bin
> > - 0b111 fastest bin
> 
> Maybe have some defines will be more readable no ?
> https://megous.com/git/linux/tree/drivers/soc/sunxi/sunxi-sid.c?h=h6-4.9-bsp#n213

Hmm, Alwwinner is really funny. Unused macros that just confuse things.

#if defined(CONFIG_ARCH_SUN50IW6)
#define TYPE_SB (0b001)
#define TYPE_NB (0b010)
#define TYPE_FB (0b011)
#else
#define TYPE_SB (0b001)
#define TYPE_NB (0b011)
#define TYPE_FB (0b111)
#endif

So for H6 they define special bin values and actually use different ones
in code. Fun.

I've sent out some testing program to Armbian forums, so hopefully, we'll
collect some real efuse_values from real SoCs, to see what's really being
used in the wild. If we see value 0b010, the BSP code is probably just
wrong.

Interestingly, TYPE_NB 0b010 would be interpreted as normal bin even with
the current BSP code, and TYPE_FB would be misdetected as TYPE_NB.

> #define SUN50I_NVEM_INVALID_CPU_OPP (0b000)
> #define SUN50I_NVEM_LOW_CPU_OPP (0b001)
> #define SUN50I_NVEM_NORMAL_CPU_OPP (0b011)
> #define SUN50I_NVEM_HIGH_CPU_OPP (0b111)

I'd rather not describe meanings just yet, until we get some real-world
data from H6 owners.

https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/?do=findComment&comment=88439

regards,
o.

> Regards,
> Clément
> 
> >
> > Let's play it safe and interpret 0 as the slowest bin, but fix detection
> > of other bins to match vendor code.
> >
> > Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
> > Signed-off-by: Ondrej Jirman 
> > ---
> >
> > See 
> > https://megous.com/git/linux/tree/drivers/soc/sunxi/sunxi-sid.c?h=h6-4.9-bsp#n484
> > and 
> > https://megous.com/git/linux/tree/drivers/cpufreq/sunxi-cpufreq.c?h=h6-4.9-bsp#n428
> > (1 is substracted from soc_bin number here!)
> >
> >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c 
> > b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > index df35ef3ef567..41dad03e245c 100644
> > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > @@ -71,9 +71,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
> > efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
> > switch (efuse_value) {
> > case 0b0001:
> > -   *versions = 1;
> > +   *versions = 0;
> > break;
> > case 0b0011:
> > +   *versions = 1;
> > +   break;
> > +   case 0b0111:
> > *versions = 2;
> > break;
> > default:
> > --
> > 2.23.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to linux-sunxi+unsubscr...@googlegroups.com.
> > To view this discussion on the web, visit 
> > https://groups.google.com/d/msgid/linux-sunxi/20191031181359.282617-1-megous%40megous.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/20191031191257.j7bpxx5xyot2ay2i%40core.my.home.

[linux-sunxi] Re: [PATCH] cpufreq: sun50i: Fix CPU speed bin detection

[Ondřej Jirman]

On Fri, Nov 01, 2019 at 04:07:01PM +0100, Maxime Ripard wrote:
> On Thu, Oct 31, 2019 at 07:13:58PM +0100, Ondrej Jirman wrote:
> > I have failures to boot on Orange Pi 3, because this driver determined
> > that my SoC is from the normal bin, but my SoC only works reliably with
> > the OPP values for the slowest bin.
> >
> > Looking at BSP code, I found that efuse values have following meanings
> > on H6:
> >
> > - 0b000 invalid (interpreted in vendor's BSP as normal bin)
> > - 0b001 slowest bin
> > - 0b011 normal bin
> > - 0b111 fastest bin
> >
> > Let's play it safe and interpret 0 as the slowest bin, but fix detection
> > of other bins to match vendor code.
> >
> > Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
> > Signed-off-by: Ondrej Jirman 
> 
> Acked-by: Maxime Ripard 
> 
> Out of curiosity, which OPP table is being used? I guess it's one of
> the dozens of patches sitting there...

I'm using one from Orange Pi 3's fex file from Xunlong:

https://github.com/orangepi-xunlong/OrangePiH6_external/blob/master/sys_config/OrangePiH6_3_sys_config.fex
https://megous.com/git/linux/commit/?h=ths-5.4&id=7b409e83b4ac70f3435886da6a26cecf9af77213

This one doesn't really differentiate between normal/fast bins.

There's also another one in the Allwinner DTS files:

https://github.com/orangepi-xunlong/OrangePiH6_Linux4_9/blob/master/arch/arm64/boot/dts/sunxi/sun50iw6p1.dtsi#L349

which seems to be the one used by Yangtao Li in the dt-bindings
docummentation.

regards,
o.

> Maxime


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

Re: [linux-sunxi] [PATCH] cpufreq: sun50i: Fix CPU speed bin detection

[Ondřej Jirman]

Hi,

On Thu, Oct 31, 2019 at 08:12:57PM +0100, megous hlavni wrote:
> Hi,
> 
> On Thu, Oct 31, 2019 at 07:55:43PM +0100, Clément Péron wrote:
> > Hi Ondrej,
> > 
> > On Thu, 31 Oct 2019 at 19:14, Ondrej Jirman  wrote:
> > >
> > > I have failures to boot on Orange Pi 3, because this driver determined
> > > that my SoC is from the normal bin, but my SoC only works reliably with
> > > the OPP values for the slowest bin.
> > >
> > > Looking at BSP code, I found that efuse values have following meanings
> > > on H6:
> > >
> > > - 0b000 invalid (interpreted in vendor's BSP as normal bin)
> > > - 0b001 slowest bin
> > > - 0b011 normal bin
> > > - 0b111 fastest bin
> > 
> > Maybe have some defines will be more readable no ?
> > https://megous.com/git/linux/tree/drivers/soc/sunxi/sunxi-sid.c?h=h6-4.9-bsp#n213
> 
> Hmm, Alwwinner is really funny. Unused macros that just confuse things.
> 
> #if defined(CONFIG_ARCH_SUN50IW6)
> #define TYPE_SB (0b001)
> #define TYPE_NB (0b010)
> #define TYPE_FB (0b011)

So this table is likely used on H6, from my research I was able to find
no owners of H6 with efuse value of 0b111 and one owner with efuse value
of 0b010, and one with 0b011.

So the bins map directly to decimal numbers efuse=1 (slow bin),
efuse=2 (normal bin), efuse=3 (fast bin).

So it looks like vendor code is wrong and works accidentally, due to
fast bin being interpretted as normal bin, and normal bin being interpretted
as having a wrong efuse value, which is then interpretted alter as normal bin.

https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/page/24/#comments
https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/page/25/#comments

This will still need to be verified, by respective owners using the optimized
OPP tables for their supposed SoC bins successfully, but meanwhile I think
we should base the efuse->speed grade mapping based on values observed in the
wild. That seems most prudent at the moment.

I'll send v2 with speed grade selection matching these observations, so
please don't merge this yet.

regards,
o.

> #else
> #define TYPE_SB (0b001)
> #define TYPE_NB (0b011)
> #define TYPE_FB (0b111)
> #endif
> 
> So for H6 they define special bin values and actually use different ones
> in code. Fun.
> 
> I've sent out some testing program to Armbian forums, so hopefully, we'll
> collect some real efuse_values from real SoCs, to see what's really being
> used in the wild. If we see value 0b010, the BSP code is probably just
> wrong.
> 
> Interestingly, TYPE_NB 0b010 would be interpreted as normal bin even with
> the current BSP code, and TYPE_FB would be misdetected as TYPE_NB.
> 
> > #define SUN50I_NVEM_INVALID_CPU_OPP (0b000)
> > #define SUN50I_NVEM_LOW_CPU_OPP (0b001)
> > #define SUN50I_NVEM_NORMAL_CPU_OPP (0b011)
> > #define SUN50I_NVEM_HIGH_CPU_OPP (0b111)
> 
> I'd rather not describe meanings just yet, until we get some real-world
> data from H6 owners.
> 
> https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/?do=findComment&comment=88439
> 
> regards,
>   o.
> 
> > Regards,
> > Clément
> > 
> > >
> > > Let's play it safe and interpret 0 as the slowest bin, but fix detection
> > > of other bins to match vendor code.
> > >
> > > Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
> > > Signed-off-by: Ondrej Jirman 
> > > ---
> > >
> > > See 
> > > https://megous.com/git/linux/tree/drivers/soc/sunxi/sunxi-sid.c?h=h6-4.9-bsp#n484
> > > and 
> > > https://megous.com/git/linux/tree/drivers/cpufreq/sunxi-cpufreq.c?h=h6-4.9-bsp#n428
> > > (1 is substracted from soc_bin number here!)
> > >
> > >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c 
> > > b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > index df35ef3ef567..41dad03e245c 100644
> > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > @@ -71,9 +71,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
> > > efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
> > > switch (efuse_value) {
> > > case 0b0001:
> > > -   *versions = 1;
> > > +   *versions = 0;
> > > break;
> > > case 0b0011:
> > > +   *versions = 1;
> > > +   break;
> > > +   case 0b0111:
> > > *versions = 2;
> > > break;
> > > default:
> > > --
> > > 2.23.0
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "linux-sunxi" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to linux-sunxi+unsubscr...@googlegroups.com.
> > > To view this discussion on the web, visit 
> > > https://groups.google.com/d/msgid/linux-sunxi/20191031181359.282617-1-megous%40megous.com.

-- 
You received this message because you are subscri

[linux-sunxi] Re: [PATCH] cpufreq: sun50i: Fix CPU speed bin detection

[Ondřej Jirman]

On Fri, Nov 01, 2019 at 04:07:01PM +0100, Maxime Ripard wrote:
> On Thu, Oct 31, 2019 at 07:13:58PM +0100, Ondrej Jirman wrote:
> > I have failures to boot on Orange Pi 3, because this driver determined
> > that my SoC is from the normal bin, but my SoC only works reliably with
> > the OPP values for the slowest bin.
> >
> > Looking at BSP code, I found that efuse values have following meanings
> > on H6:
> >
> > - 0b000 invalid (interpreted in vendor's BSP as normal bin)
> > - 0b001 slowest bin
> > - 0b011 normal bin
> > - 0b111 fastest bin
> >
> > Let's play it safe and interpret 0 as the slowest bin, but fix detection
> > of other bins to match vendor code.
> >
> > Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
> > Signed-off-by: Ondrej Jirman 
> 
> Acked-by: Maxime Ripard 

Self-NACK :) Please don't merge.

Please see the other e-mail for why.

thank you and regards,
o.

> Out of curiosity, which OPP table is being used? I guess it's one of
> the dozens of patches sitting there...
> 
> Maxime


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

[linux-sunxi] Re: [PATCH 4/4] arm64: dts: allwinner: orange-pi-3: Enable USB 3.0 host support

[Ondřej Jirman]

Hello Maxime,

On Mon, Oct 21, 2019 at 01:09:46PM +0200, Maxime Ripard wrote:
> On Sun, Oct 20, 2019 at 03:42:29PM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman 
> >
> > Enable Allwinner's USB 3.0 phy and the host controller. Orange Pi 3
> > board has GL3510 USB 3.0 4-port hub connected to the SoC's USB 3.0
> > port. All four ports are exposed via USB3-A connectors. VBUS is
> > always on, since it's powered directly from DCIN (VCC-5V) and
> > not switchable.
> >
> > Signed-off-by: Ondrej Jirman 
> 
> Those last two patches are fine with me, I'll merge them once the phy
> driver will be merged.

PHY driver has been merged. You can now pull these patches too, when
you like.

See here: 
https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git/log/?h=next

Thank you,
o.

> Maxime


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

[linux-sunxi] Re: [PATCH] phy: allwinner: Fix GENMASK misuse

[Ondřej Jirman]

Hello Rikard,

On Thu, Nov 07, 2019 at 09:46:45PM +0100, Rikard Falkeborn wrote:
> Arguments are supposed to be ordered high then low.
> 
> Signed-off-by: Rikard Falkeborn 
> ---
> Spotted while trying to add compile time checks of GENMASK arguments.
> Patch has only been compile tested.

thank you!

Tested-by: Ondrej Jirman 

regards,
o.

>  drivers/phy/allwinner/phy-sun50i-usb3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/allwinner/phy-sun50i-usb3.c 
> b/drivers/phy/allwinner/phy-sun50i-usb3.c
> index 1169f3e83a6f..b1c04f71a31d 100644
> --- a/drivers/phy/allwinner/phy-sun50i-usb3.c
> +++ b/drivers/phy/allwinner/phy-sun50i-usb3.c
> @@ -49,7 +49,7 @@
>  #define SUNXI_LOS_BIAS(n)((n) << 3)
>  #define SUNXI_LOS_BIAS_MASK  GENMASK(5, 3)
>  #define SUNXI_TXVBOOSTLVL(n) ((n) << 0)
> -#define SUNXI_TXVBOOSTLVL_MASK   GENMASK(0, 2)
> +#define SUNXI_TXVBOOSTLVL_MASK   GENMASK(2, 0)
>  
>  struct sun50i_usb3_phy {
>   struct phy *phy;
> -- 
> 2.24.0
> 

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

[linux-sunxi] Re: [PATCH] phy: allwinner: Fix GENMASK misuse

[Ondřej Jirman]

On Fri, Nov 08, 2019 at 07:29:21PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2019年11月8日 GMT+08:00 上午5:45:14, "Ondřej Jirman"  写到:
> >Hello Rikard,
> >
> >On Thu, Nov 07, 2019 at 09:46:45PM +0100, Rikard Falkeborn wrote:
> >> Arguments are supposed to be ordered high then low.
> >> 
> >> Signed-off-by: Rikard Falkeborn 
> >> ---
> >> Spotted while trying to add compile time checks of GENMASK arguments.
> >> Patch has only been compile tested.
> >
> >thank you!
> >
> >Tested-by: Ondrej Jirman 
> 
> Does it affect or fix the performance?

See here: 
https://forum.armbian.com/topic/10131-orange-pi-lite2-usb3-now-working/?do=findComment&comment=88904

Quote:

> It may or may not help. On Opi3 I see no change, probably because HUB is
> really close to the SoC, but on boards without a HUB, SoC's USB3 phy will
> have to drive the signal over the longer cable and this patch might benefit
> those boards. 

Maybe someone with boards without PHY will test it more.

regards,
o.

> >
> >regards,
> > o.
> >
> >>  drivers/phy/allwinner/phy-sun50i-usb3.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/phy/allwinner/phy-sun50i-usb3.c
> >b/drivers/phy/allwinner/phy-sun50i-usb3.c
> >> index 1169f3e83a6f..b1c04f71a31d 100644
> >> --- a/drivers/phy/allwinner/phy-sun50i-usb3.c
> >> +++ b/drivers/phy/allwinner/phy-sun50i-usb3.c
> >> @@ -49,7 +49,7 @@
> >>  #define SUNXI_LOS_BIAS(n) ((n) << 3)
> >>  #define SUNXI_LOS_BIAS_MASK   GENMASK(5, 3)
> >>  #define SUNXI_TXVBOOSTLVL(n)  ((n) << 0)
> >> -#define SUNXI_TXVBOOSTLVL_MASKGENMASK(0, 2)
> >> +#define SUNXI_TXVBOOSTLVL_MASKGENMASK(2, 0)
> >>  
> >>  struct sun50i_usb3_phy {
> >>struct phy *phy;
> >> -- 
> >> 2.24.0
> >> 

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

[linux-sunxi] Re: [PATCH] phy: allwinner: Fix GENMASK misuse

[Ondřej Jirman]

On Fri, Nov 08, 2019 at 12:41:39PM +0100, megous hlavni wrote:
> On Fri, Nov 08, 2019 at 07:29:21PM +0800, Icenowy Zheng wrote:
> > 
> > 
> > 于 2019年11月8日 GMT+08:00 上午5:45:14, "Ondřej Jirman"  写到:
> > >Hello Rikard,
> > >
> > >On Thu, Nov 07, 2019 at 09:46:45PM +0100, Rikard Falkeborn wrote:
> > >> Arguments are supposed to be ordered high then low.
> > >> 
> > >> Signed-off-by: Rikard Falkeborn 
> > >> ---
> > >> Spotted while trying to add compile time checks of GENMASK arguments.
> > >> Patch has only been compile tested.
> > >
> > >thank you!
> > >
> > >Tested-by: Ondrej Jirman 
> > 
> > Does it affect or fix the performance?
> 
> See here: 
> https://forum.armbian.com/topic/10131-orange-pi-lite2-usb3-now-working/?do=findComment&comment=88904
> 
> Quote:
> 
> > It may or may not help. On Opi3 I see no change, probably because HUB is
> > really close to the SoC, but on boards without a HUB, SoC's USB3 phy will
> > have to drive the signal over the longer cable and this patch might benefit
> > those boards. 
> 
> Maybe someone with boards without PHY will test it more.

Eh, on boards without a USB3 HUB.

> regards,
>   o.
> 
> > >
> > >regards,
> > >   o.
> > >
> > >>  drivers/phy/allwinner/phy-sun50i-usb3.c | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >> 
> > >> diff --git a/drivers/phy/allwinner/phy-sun50i-usb3.c
> > >b/drivers/phy/allwinner/phy-sun50i-usb3.c
> > >> index 1169f3e83a6f..b1c04f71a31d 100644
> > >> --- a/drivers/phy/allwinner/phy-sun50i-usb3.c
> > >> +++ b/drivers/phy/allwinner/phy-sun50i-usb3.c
> > >> @@ -49,7 +49,7 @@
> > >>  #define SUNXI_LOS_BIAS(n)   ((n) << 3)
> > >>  #define SUNXI_LOS_BIAS_MASK GENMASK(5, 3)
> > >>  #define SUNXI_TXVBOOSTLVL(n)((n) << 0)
> > >> -#define SUNXI_TXVBOOSTLVL_MASK  GENMASK(0, 2)
> > >> +#define SUNXI_TXVBOOSTLVL_MASK  GENMASK(2, 0)
> > >>  
> > >>  struct sun50i_usb3_phy {
> > >>  struct phy *phy;
> > >> -- 
> > >> 2.24.0
> > >> 

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

Re: [linux-sunxi] [PATCH] media: sun6i-csi: Fix incorrect HSYNC/VSYNC/PCLK polarity configuration

[Ondřej Jirman]

Hi,

On Thu, Nov 28, 2019 at 10:26:08AM +0800, Yong wrote:
> Hi Ondrej,
> 
> This has been discussed.
> And Maxime sent a patch for this: 
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg127149.html

Thanks for pointing to the previous patch. But that patch doesn't make any
sense, and breaks things for me, and doesn't even match BSP code, which 
has no such reversal, and works fine with about 30 cam drivers.

Also how do you explain my findings?

My camera is sending correct signals, verified by looking at them actually (see
below), and CSI is not receiving the image. I have to flip HSYNC/VSYNC to be
oposite of that what CSI driver expects and I get a noisy image and if I fix
PCLK polarity too, the noise goes away, which means now I'm also sampling when
the data are stable and not when they're changing.

Here: (output from my cam, that I configured to have VSYNC ACTIVE LOW, HSYNC
ACTIVE LOW) And the signal is clearly that, as you can see yourself:

  https://megous.com/dl/tmp/98df81b7ed0126ec.png

The above signals are received with CSI driver configured with
V4L2_MBUS_VSYNC_ACTIVE_HIGH V4L2_MBUS_HSYNC_ACTIVE_HIGH. So CSI driver is
clearly wrong.

I think this is pretty clear the driver is buggy. At least for A83T SoC.

I'm not sure what Maxime found out, but he should probably re-check his
findings. Maxime, can you comment on this?

regards,
o.

> On Thu, 28 Nov 2019 03:02:59 +0100
> Ondrej Jirman  wrote:
> 
> > This was discovered by writing a new camera driver and wondering, why
> > hsync/vsync polarity setting behaves in reverse to what would be
> > expected. Verified by looking at the actual signals and the SoC
> > user manual.
> > 
> > Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
> > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > index f17e5550602d..98bbcca59a90 100644
> > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > @@ -417,12 +417,12 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev 
> > *sdev)
> > if (flags & V4L2_MBUS_FIELD_EVEN_LOW)
> > cfg |= CSI_IF_CFG_FIELD_POSITIVE;
> >  
> > -   if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> > +   if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
> > cfg |= CSI_IF_CFG_VREF_POL_POSITIVE;
> > -   if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> > +   if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> > cfg |= CSI_IF_CFG_HREF_POL_POSITIVE;
> >  
> > -   if (flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
> > +   if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
> > cfg |= CSI_IF_CFG_CLK_POL_FALLING_EDGE;
> > break;
> > case V4L2_MBUS_BT656:
> > -- 
> > 2.24.0
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to linux-sunxi+unsubscr...@googlegroups.com.
> > To view this discussion on the web, visit 
> > https://groups.google.com/d/msgid/linux-sunxi/20191128020259.1338188-1-megous%40megous.com.
> 
> 
> Thanks,
> Yong

-- 
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/20191128030653.5fhcolvib6tzf4zc%40core.my.home.

Re: [linux-sunxi] [PATCH] media: sun6i-csi: Fix incorrect HSYNC/VSYNC/PCLK polarity configuration

[Ondřej Jirman]

On Thu, Nov 28, 2019 at 11:26:24AM +0800, Chen-Yu Tsai wrote:
> On Thu, Nov 28, 2019 at 11:06 AM Ondřej Jirman  wrote:
> >
> > Hi,
> >
> > On Thu, Nov 28, 2019 at 10:26:08AM +0800, Yong wrote:
> > > Hi Ondrej,
> > >
> > > This has been discussed.
> > > And Maxime sent a patch for this:
> > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg127149.html
> >
> > Thanks for pointing to the previous patch. But that patch doesn't make any
> > sense, and breaks things for me, and doesn't even match BSP code, which
> > has no such reversal, and works fine with about 30 cam drivers.
> >
> > Also how do you explain my findings?
> >
> > My camera is sending correct signals, verified by looking at them actually 
> > (see
> > below), and CSI is not receiving the image. I have to flip HSYNC/VSYNC to be
> > oposite of that what CSI driver expects and I get a noisy image and if I fix
> > PCLK polarity too, the noise goes away, which means now I'm also sampling 
> > when
> > the data are stable and not when they're changing.
> >
> > Here: (output from my cam, that I configured to have VSYNC ACTIVE LOW, HSYNC
> > ACTIVE LOW) And the signal is clearly that, as you can see yourself:
> >
> >   https://megous.com/dl/tmp/98df81b7ed0126ec.png
> 
> From the looks of things you have active-high VSYNC with active-low HREF.
> HREF is not the same as HSYNC, in fact quite the opposite. V/H SYNC are
> pulses, active only when there should be no data and the line/frame switch
> happens, while V/H REF are held active when there is data. I personally
> find these terms very confusing. :(
> 
> Now the timing diagrams in the Allwinner manuals would suggest that when
> they are talking about H/V SYNC, they are actually referring to H/V REF.
> The HSYNC line is high/active when there is valid data, and the VSYNC line
> is high/active for the duration of the frame.
> 
> I think both sides need to be checked that they are using the correct
> polarity, and maybe also have the media maintainers clarify how the
> polarity should be interpreted when the hardware uses H/V ref instead
> of H/V sync.

Oh my, so it's just a terminology issue? :)

This probably should be docummented somewhere. I just thought xSYNC_ACTIVE_HIGH
meant the respective signals are supposed to be HIGH during active phase of data
transmission: that is VSYNC HIGH during entire frame, and HSYNC high during row.

DT bindings documentation doesn't help much either.

And obviously manufacturers are confused too.

  https://megous.com/dl/tmp/fae07dfb4897bbb3.png

HSYNC/VSYNC "low valid" produces what you see on the previous signal capture
I posted. ;)

regards,
o.

> 
> ChenYu
> 
> > The above signals are received with CSI driver configured with
> > V4L2_MBUS_VSYNC_ACTIVE_HIGH V4L2_MBUS_HSYNC_ACTIVE_HIGH. So CSI driver is
> > clearly wrong.
> >
> > I think this is pretty clear the driver is buggy. At least for A83T SoC.
> >
> > I'm not sure what Maxime found out, but he should probably re-check his
> > findings. Maxime, can you comment on this?
> >
> > regards,
> > o.
> >
> > > On Thu, 28 Nov 2019 03:02:59 +0100
> > > Ondrej Jirman  wrote:
> > >
> > > > This was discovered by writing a new camera driver and wondering, why
> > > > hsync/vsync polarity setting behaves in reverse to what would be
> > > > expected. Verified by looking at the actual signals and the SoC
> > > > user manual.
> > > >
> > > > Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
> > > > Signed-off-by: Ondrej Jirman 
> > > > ---
> > > >  drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
> > > > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > index f17e5550602d..98bbcca59a90 100644
> > > > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > @@ -417,12 +417,12 @@ static void sun6i_csi_setup_bus(struct 
> > > > sun6i_csi_dev *sdev)
> > > > if (flags & V4L2_MBUS_FIELD_EVEN_LOW)
> > > > cfg |= CSI_IF_CFG_FIELD_POSITIVE;
> > > >
> > > > -   if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> > > > +   if (flags & V4L2_MBUS_VS

[linux-sunxi] Re: [PATCH 01/14] ARM: dts: sun8i: Add SID node

[Ondřej Jirman]

Hello,

thank you for the review.

On 24.6.2016 04:41, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Josef Gajdusek 
>>
>> Add a node describing the Security ID memory to the Allwinner H3 .dtsi file.
>>
>> Signed-off-by: Josef Gajdusek 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 4a4926b..172576d 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -389,6 +389,13 @@
>> #size-cells = <0>;
>> };
>>
>> +   sid: eeprom@01c14000 {
>> +   compatible = "allwinner,sun4i-a10-sid";
> 
> This has been discussed before. The hardware is not compatible.
> The write control registers are at different offsets.

I'm not sure what you mean by write control registers. Code in
sunxi_sid.c implements only read access to the nvram. Can you pelase
elaborate?

  Ondrej

> 
> ChenYu
> 
>> +   reg = <0x01c14000 0x400>;
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +   };
>> +
>> usbphy: phy@01c19400 {
>> compatible = "allwinner,sun8i-h3-usb-phy";
>> reg = <0x01c19400 0x2c>,
>> --
>> 2.9.0
>>

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

[Ondřej Jirman]

Thanks, I've incorporated all the suggestions (and more :)), except for
the threaded IRQ, which si expalined below.

regards,
  Ondrej

On 24.6.2016 05:09, Chen-Yu Tsai wrote:
> Hi,
> 
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Ondrej Jirman 
>>
> 
> The subject could read:
> 
>   thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3
> 
>> This patch adds support for the sun8i thermal sensor on
>> Allwinner H3 SoC.
>>
>> Signed-off-by: Ondřej Jirman 
>> ---
>>  drivers/thermal/Kconfig |   7 ++
>>  drivers/thermal/Makefile|   1 +
>>  drivers/thermal/sun8i_ths.c | 295 
>> 
>>  3 files changed, 303 insertions(+)
>>  create mode 100644 drivers/thermal/sun8i_ths.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 2d702ca..3de0f8d 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -351,6 +351,13 @@ config MTK_THERMAL
>>   Enable this option if you want to have support for thermal 
>> management
>>   controller present in Mediatek SoCs
>>
>> +config SUN8I_THS
>> +   tristate "sun8i THS driver"
> 
> Explain THS.
> 
>> +   depends on MACH_SUN8I
>> +   depends on OF
>> +   help
>> + Enable this to support thermal reporting on some newer Allwinner 
>> SoCs.
>> +
>>  menu "Texas Instruments thermal drivers"
>>  depends on ARCH_HAS_BANDGAP || COMPILE_TEST
>>  depends on HAS_IOMEM
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 10b07c1..7261ee8 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM)  += tegra/
>>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>>  obj-$(CONFIG_MTK_THERMAL)  += mtk_thermal.o
>>  obj-$(CONFIG_GENERIC_ADC_THERMAL)  += thermal-generic-adc.o
>> +obj-$(CONFIG_SUN8I_THS)    += sun8i_ths.o
>> diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c
>> new file mode 100644
>> index 000..618ccc3
>> --- /dev/null
>> +++ b/drivers/thermal/sun8i_ths.c
>> @@ -0,0 +1,295 @@
>> +/*
>> + * sun8i THS driver
> 
> Explain THS.
> 
>> + *
>> + * Copyright (C) 2016 Ondřej Jirman
>> + * Based on the work of Josef Gajdusek 
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define THS_H3_CTRL0   0x00
>> +#define THS_H3_CTRL2   0x40
>> +#define THS_H3_INT_CTRL0x44
>> +#define THS_H3_STAT0x48
>> +#define THS_H3_FILTER  0x70
>> +#define THS_H3_CDATA   0x74
>> +#define THS_H3_DATA0x80
>> +
>> +#define THS_H3_CTRL0_SENSOR_ACQ0_OFFS   0
>> +#define THS_H3_CTRL0_SENSOR_ACQ0(x) \
>> +((x) << THS_H3_CTRL0_SENSOR_ACQ0_OFFS)
>> +#define THS_H3_CTRL2_SENSE_EN_OFFS  0
>> +#define THS_H3_CTRL2_SENSE_EN \
>> +BIT(THS_H3_CTRL2_SENSE_EN_OFFS)
>> +#define THS_H3_CTRL2_SENSOR_ACQ1_OFFS   16
>> +#define THS_H3_CTRL2_SENSOR_ACQ1(x) \
>> +((x) << THS_H3_CTRL2_SENSOR_ACQ1_OFFS)
>> +
>> +#define THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS8
>> +#define THS_H3_INT_CTRL_DATA_IRQ_EN \
>> +   BIT(THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS)
>> +#define THS_H3_INT_CTRL_THERMAL_PER_OFFS12
>> +#define THS_H3_INT_CTRL_THERMAL_PER(x) \
>> +   ((x) << THS_H3_INT_CTRL_THERMAL_PER_OFFS)
>> +
>> +#define THS_H3_STAT_DATA_IRQ_STS_OFFS   8
>> +#define THS_H3_STAT_DATA_IRQ_STS \
>> +BIT(THS_H3_STAT_DATA_IRQ_STS_OFFS)
>> +
>> +#define THS_H3_FILTER_TYPE_OFFS 0
>> +#define THS_H3_FILTER_TYPE(x) \
>> +((x) << THS_H3_FILTER_TYPE_OFFS)
&

Re: [linux-sunxi] [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One

[Ondřej Jirman]

Hi Julian,

thank you for the review. You're right. I added the pinctrl client
nodes. Also the patches were split incorrectly, so I fixed that too.

regards,
  Ondrej

On 24.6.2016 04:51, Julian Calaby wrote:
> Hi Ondrej,
> 
> On Fri, Jun 24, 2016 at 5:21 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> Xulong Orange Pi One uses GPIO based regulator that
>> switches between two voltages: 1.1V and 1.3V. The
>> regulator is controlled from the PL6 pin.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index 0adf932..ce4ba91 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -88,6 +88,25 @@
>> gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
>> };
>> };
>> +
>> +   vdd_soc: gpio-regulator {
>> +   compatible = "regulator-gpio";
>> +
>> +   regulator-name = "soc-vdd-supply";
>> +   regulator-min-microvolt = <110>;
>> +   regulator-max-microvolt = <130>;
>> +   regulator-boot-on;
>> +   regulator-type = "voltage";
>> +
>> +   gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>;
>> +   states = <110 0x0
>> + 130 0x1>;
>> +
>> +   startup-delay-us = <10>;
>> +   enable-active-high;
> 
> Don't you need to reference the new pinctl node in this one?
> 
> Thanks,
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

Hello,

comments below.

On 24.6.2016 05:48, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> Add label to the first cpu so that it can be referenced
>> from derived dts files.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 9938972..82faefc 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -52,7 +52,7 @@
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> -   cpu@0 {
>> +   cpu0: cpu@0 {
>> compatible = "arm,cortex-a7";
>> device_type = "cpu";
>> reg = <0>;
> 
> Can you also set the cpu clock here? It is part of the SoC
> and does not belong in the board DTS files.

Do you mean operating-points, or something else? Different SBCs will
probably require different combinations of operating points just for
safety's sake, because they have different regulators and [some have
botched] thermal designs, so it might make sense to customize it for
differnt boards, and I don't feel adventurous enough setting it for all
H3 boards out there.

Or is this comment related to the missing cpu clock rate message I see
on every boot?

[0.058912] /cpus/cpu@0 missing clock-frequency property

regards,
  Ondrej

> Otherwise this one looks good.
> 
> ChenYu
> 
>> --
>> 2.9.0
>>

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 07/14] regulator: SY8106A regulator driver

[Ondřej Jirman]

Hi,

thank you for the review. I've resolved most of the issues. Some more
comments below.

On 24.6.2016 05:41, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> SY8106A is I2C attached single output voltage regulator
>> made by Silergy.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  drivers/regulator/Kconfig |   8 +-
>>  drivers/regulator/Makefile|   2 +-
>>  drivers/regulator/sy8106a-regulator.c | 153 
>> ++
>>  3 files changed, 161 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>>
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index 144cbf5..fc3fae2 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -860,5 +860,11 @@ config REGULATOR_WM8994
>>   This driver provides support for the voltage regulators on the
>>   WM8994 CODEC.
>>
>> -endif
>> +config REGULATOR_SY8106A
>> +   tristate "Silergy SY8106A"
>> +   depends on I2C
> 
> Maybe you should also depend on OF since the driver is going to crippled
> without any constraints set, or (OF || COMPILE_TEST) if you want some
> compile test coverage.
> 
>> +   select REGMAP_I2C
>> +   help
>> + This driver provides support for the voltage regulator SY8106A.
>>
>> +endif
>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>> index 85a1d44..f382095 100644
>> --- a/drivers/regulator/Makefile
>> +++ b/drivers/regulator/Makefile
>> @@ -110,6 +110,6 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
>>  obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
>>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>> -
>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
> 
> Follow the existing ordering in the Makefile.
> 
>>
>>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>> diff --git a/drivers/regulator/sy8106a-regulator.c 
>> b/drivers/regulator/sy8106a-regulator.c
>> new file mode 100644
>> index 000..34bd69c
>> --- /dev/null
>> +++ b/drivers/regulator/sy8106a-regulator.c
>> @@ -0,0 +1,153 @@
>> +/*
>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>> + *
>> + * Copyright (C) 2016  Ondřej Jirman 
>> + *
>> + * This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Library General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2 of the License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Library General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Library General Public
>> + * License along with this library; if not, write to the
>> + * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
>> + * Boston, MA  02110-1301, USA.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> Do you need this one?
> 
>> +#include 
>> +#include 
> 
> And this one?
> 
>> +#include 
>> +#include 
> 
> Sort alphabetically please.
> 
>> +
>> +#define SY8106A_REG_VOUT1_SEL  0x01
>> +#define SY8106A_REG_VOUT_COM   0x02
>> +#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
>> +#define SY8106A_DISABLE_REG0x01
> 
> BIT(0) would be clearer.
> 
>> +
>> +struct sy8106a {
>> +   struct regulator_dev *rdev;
>> +   struct regmap *regmap;
>> +};
>> +
>> +static const struct regmap_config sy8106a_regmap_config = {
>> +   .reg_bits = 8,
>> +   .val_bits = 8,
>> +};
>> +
>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned sel)
>> +{
>> +   return regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
>> + 0xff, sel | 0x80);
> 
> Can you use .apply_bit / .apply_reg with regulator_set_voltage_sel_regmap?

I understand the code savings, but I'd rather avoid that, because it
would involve 2 needless readouts and rewrites of the voltage setting
register. I'd rather change this to regmap_write, so that th

[linux-sunxi] Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

[Ondřej Jirman]

On 24.6.2016 05:09, Chen-Yu Tsai wrote:
>> +static int sun8i_ths_h3_init(struct platform_device *pdev,
>> +struct sun8i_ths_data *data)
>> +{
>> +   int ret;
>> +   size_t callen;
>> +   s32 *caldata;
>> +
>> +   data->busclk = devm_clk_get(&pdev->dev, "ahb");
>> +   if (IS_ERR(data->busclk)) {
>> +   ret = PTR_ERR(data->busclk);
>> +   dev_err(&pdev->dev, "failed to get ahb clk: %d\n", ret);
>> +   return ret;
>> +   }
>> +
>> +   data->clk = devm_clk_get(&pdev->dev, "ths");
>> +   if (IS_ERR(data->clk)) {
>> +   ret = PTR_ERR(data->clk);
>> +   dev_err(&pdev->dev, "failed to get ths clk: %d\n", ret);
>> +   return ret;
>> +   }
>> +
>> +   data->reset = devm_reset_control_get(&pdev->dev, "ahb");
> 
> IIRC with the new shared reset control stuff merged, you are supposed
> to specify whether you want a shared or exclusive one when you ask for
> it.

Here devm_reset_control_get will get the exclusive reference. So this
should be ok.

regards,
  Ondrej

> 
> Regards
> ChenYu
> 
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.9.0
>>

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

[Ondřej Jirman]

On 25.6.2016 02:54, Chen-Yu Tsai wrote:
> On Sat, Jun 25, 2016 at 8:35 AM, Ondřej Jirman  wrote:
>> On 24.6.2016 05:09, Chen-Yu Tsai wrote:
>>>> +static int sun8i_ths_h3_init(struct platform_device *pdev,
>>>> +struct sun8i_ths_data *data)
>>>> +{
>>>> +   int ret;
>>>> +   size_t callen;
>>>> +   s32 *caldata;
>>>> +
>>>> +   data->busclk = devm_clk_get(&pdev->dev, "ahb");
>>>> +   if (IS_ERR(data->busclk)) {
>>>> +   ret = PTR_ERR(data->busclk);
>>>> +   dev_err(&pdev->dev, "failed to get ahb clk: %d\n", ret);
>>>> +   return ret;
>>>> +   }
>>>> +
>>>> +   data->clk = devm_clk_get(&pdev->dev, "ths");
>>>> +   if (IS_ERR(data->clk)) {
>>>> +   ret = PTR_ERR(data->clk);
>>>> +   dev_err(&pdev->dev, "failed to get ths clk: %d\n", ret);
>>>> +   return ret;
>>>> +   }
>>>> +
>>>> +   data->reset = devm_reset_control_get(&pdev->dev, "ahb");
>>>
>>> IIRC with the new shared reset control stuff merged, you are supposed
>>> to specify whether you want a shared or exclusive one when you ask for
>>> it.
>>
>> Here devm_reset_control_get will get the exclusive reference. So this
>> should be ok.
> 
> See https://patchwork.kernel.org/patch/9158691/
> 
> The generic ones might be removed later on. I remember in another thread
> it was asked that new users should use the explicit API, and avoid having
> to be converted.

I see, thank you, I'll change that.

regards,
  Ondrej

> ChenYu
> 
>>
>> regards,
>>   Ondrej
>>
>>>
>>> Regards
>>> ChenYu
>>>
>>>> +MODULE_LICENSE("GPL v2");
>>>> --
>>>> 2.9.0
>>>>
>>

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 25.6.2016 09:02, Maxime Ripard wrote:
> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
>> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
>>> Hello,
>>>
>>> comments below.
>>>
>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>>>> From: Ondrej Jirman 
>>>>>
>>>>> Add label to the first cpu so that it can be referenced
>>>>> from derived dts files.
>>>>>
>>>>> Signed-off-by: Ondrej Jirman 
>>>>> ---
>>>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> index 9938972..82faefc 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> @@ -52,7 +52,7 @@
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>>
>>>>> -   cpu@0 {
>>>>> +   cpu0: cpu@0 {
>>>>> compatible = "arm,cortex-a7";
>>>>> device_type = "cpu";
>>>>> reg = <0>;
>>>>
>>>> Can you also set the cpu clock here? It is part of the SoC
>>>> and does not belong in the board DTS files.
>>>
>>> Do you mean operating-points, or something else? Different SBCs will
>>> probably require different combinations of operating points just for
>>> safety's sake, because they have different regulators and [some have
>>> botched] thermal designs, so it might make sense to customize it for
>>> differnt boards, and I don't feel adventurous enough setting it for all
>>> H3 boards out there.
>>
>> I meant clocks = <...> and clock-latency = <...>.
>>
>> These 2 are part of the SoC.
>>
>> The OPP can stay in the board files. It's a pity there's no standard
>> OPP table for H3 though. :(
> 
> This has never been the case, and we always had some deviation in the
> FEX files for all the SoCs.
> 
> If we could come up with standard OPPs that work for every one,
> there's no reason it can't happen here.
> 
> I don't really see why the thermal design should change anything. If a
> boards heats faster, it will throttle down to a lower OPP faster, but
> those OPPs are not going to change.

I've no way to test, but I've been told some Sinovoip boards are really
bad in this regard (SoC is not even well thermally connected to the
PCB/PCB not having copper layer to spread the heat). Thermal sensor
readings happen at fixed intervals, so the question is if you can heat
up the soc from say 80°C (first trip point) to over 110°C in less than
that period (330ms currently).

I say it shouldn't be a problem, if that small thing is drawing say 2W
at max load. It will burn or trigger a second trip point before the
first one has a chance to trigger and the kernel will shut down. I
remember tkaiser saying that he has to run that board at 240MHz max. But
perhaps I'm misremembering.

I'm just speculating.

regards,
  Ondrej



> Maxime
> 

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

[linux-sunxi] Re: [PATCH v2 02/14] thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3

[Ondřej Jirman]

On 25.6.2016 09:10, Maxime Ripard wrote:
> On Sat, Jun 25, 2016 at 05:44:59AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> This patch adds support for the sun8i thermal sensor on
>> Allwinner H3 SoC.
>>
>> Signed-off-by: Ondřej Jirman 
>> ---
>> v2:
>> - removed incorrect use of SID driver in sun8i_ths
>> - read calibration data directly from iomem  
>> - better explanation for the thermal sensor driver
>> - dt documentation fixes
>> - dropped unncecessary macros and init code reorganization
>> - moved resource aquisition from init to probe function
>> - deassert reset after clock rate is set, not before
>> - enable irq after all other registers are configured
>> ---
>>  drivers/thermal/Kconfig |   7 ++
>>  drivers/thermal/Makefile|   1 +
>>  drivers/thermal/sun8i_ths.c | 260 
>> 
>>  3 files changed, 268 insertions(+)
>>  create mode 100644 drivers/thermal/sun8i_ths.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 2d702ca..d3209d9 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -351,6 +351,13 @@ config MTK_THERMAL
>>Enable this option if you want to have support for thermal management
>>controller present in Mediatek SoCs
>>  
>> +config SUN8I_THS
>> +tristate "Thermal sensor driver for Allwinner H3"
>> +depends on MACH_SUN8I
>> +depends on OF
>> +help
>> +  Enable this to support thermal reporting on some newer Allwinner SoCs.
>> +
>>  menu "Texas Instruments thermal drivers"
>>  depends on ARCH_HAS_BANDGAP || COMPILE_TEST
>>  depends on HAS_IOMEM
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 10b07c1..7261ee8 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra/
>>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>>  obj-$(CONFIG_MTK_THERMAL)   += mtk_thermal.o
>>  obj-$(CONFIG_GENERIC_ADC_THERMAL)   += thermal-generic-adc.o
>> +obj-$(CONFIG_SUN8I_THS) += sun8i_ths.o
>> diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c
>> new file mode 100644
>> index 000..9ba0f96
>> --- /dev/null
>> +++ b/drivers/thermal/sun8i_ths.c
>> @@ -0,0 +1,260 @@
>> +/*
>> + * Thermal sensor driver for Allwinner H3 SoC
>> + *
>> + * Copyright (C) 2016 Ondřej Jirman
>> + * Based on the work of Josef Gajdusek 
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define THS_H3_CTRL00x00
>> +#define THS_H3_CTRL20x40
>> +#define THS_H3_INT_CTRL 0x44
>> +#define THS_H3_STAT 0x48
>> +#define THS_H3_FILTER   0x70
>> +#define THS_H3_CDATA0x74
>> +#define THS_H3_DATA 0x80
>> +
>> +#define THS_H3_CTRL0_SENSOR_ACQ0(x) (x)
>> +#define THS_H3_CTRL2_SENSE_EN   BIT(0)
>> +#define THS_H3_CTRL2_SENSOR_ACQ1(x) ((x) << 16)
>> +#define THS_H3_INT_CTRL_DATA_IRQ_EN BIT(8)
>> +#define THS_H3_INT_CTRL_THERMAL_PER(x)  ((x) << 12)
>> +#define THS_H3_STAT_DATA_IRQ_STSBIT(8)
>> +#define THS_H3_FILTER_TYPE(x)   ((x) << 0)
>> +#define THS_H3_FILTER_ENBIT(2)
>> +
>> +#define THS_H3_CLK_IN 4000  /* Hz */
>> +#define THS_H3_DATA_PERIOD 330  /* ms */
>> +
>> +#define THS_H3_FILTER_TYPE_VALUE2  /* average over 2^(n+1) 
>> samples */
>> +#define THS_H3_FILTER_DIV   (1 << (THS_H3_FILTER_TYPE_VALUE 
>> + 1))
>> +#define THS_H3_INT_CTRL_THERMAL_PER_VALUE \
>> +(THS_H3_DATA_PERIOD * (THS_H3_CLK_IN / 1000) / THS_H3_FILTER_DIV / 4096 
>> - 1)
>> +#define THS_H3_

[linux-sunxi] Re: [PATCH v2 01/14] ARM: clk: sunxi: Add driver for the H3 THS clock

[Ondřej Jirman]

Hi Maxime,

I try to base everything on the torvalds's kernel.

I did notice the patches. Is there some main git tree/branch where this
work is tracked in? I'd gladly use it.

Also there's a PLL1 rate application patch, that would need to be ported
to the new CCU code, in the case I would use it as a base for this work.
Given that the new CCU code is your work and it's fresh in your mind, do
you have suggestion how to approach it?

It is [PATCH v2 06/14] in this series.

regards,
  o.

On 25.6.2016 09:13, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 05:44:58AM +0200, meg...@megous.com wrote:
>> From: Josef Gajdusek 
>>
>> This patch adds a driver for the THS clock which is present on the
>> Allwinner H3.
>>
>> Signed-off-by: Josef Gajdusek 
> 
> You might not have noticed, but we are currently rewriting the whole
> clock support for the Allwinner SoCs, targetting the H3 as the first
> SoC to use it.
> 
> There's already some support for the H3 THS clock, so please use that
> instead.
> 
> Thanks!
> Maxime
> 

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

[linux-sunxi] Re: [PATCH v2 04/14] regulator: SY8106A regulator driver

[Ondřej Jirman]

On 26.6.2016 13:26, Mark Brown wrote:
> On Sat, Jun 25, 2016 at 05:45:01AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> SY8106A is I2C attached single output voltage regulator
>> made by Silergy.
> 
> I'm missing almost all of this series, I've just got this and another
> patch which look like a standalone driver so it's hard to see any
> dependencies.  What's going on here?
> 

Sorry, it's this series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438981.html

And here's v1 intro letter:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438794.html

regards,
  Ondrej Jirman

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

[linux-sunxi] Re: [PATCH v2 05/14] dt-bindings: document SY8106A regulator driver

[Ondřej Jirman]

On 26.6.2016 13:27, Mark Brown wrote:
> On Sat, Jun 25, 2016 at 05:45:02AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> This patch adds the binding documentation for the
>> sy8106a regulator driver.
> 
> Please submit patches using subject lines reflecting the style for the
> subsystem.  This makes it easier for people to identify relevant
> patches.
> 

Hello, I assume that means "regulator: dt-bindings: ..." in this case.
I'll keep that in mind in the future. Thank you.

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

[linux-sunxi] Re: [PATCH v2 04/14] regulator: SY8106A regulator driver

[Ondřej Jirman]

On 27.6.2016 16:54, Mark Brown wrote:
> On Sun, Jun 26, 2016 at 05:07:16PM +0200, Ondřej Jirman wrote:
>> On 26.6.2016 13:26, Mark Brown wrote:
> 
>>> I'm missing almost all of this series, I've just got this and another
>>> patch which look like a standalone driver so it's hard to see any
>>> dependencies.  What's going on here?
> 
>> Sorry, it's this series:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438981.html
> 
>> And here's v1 intro letter:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438794.html
> 
> These aren't really enlightening I'm afraid, there's nothing in there
> about why these are a single series and no dependency information.
> Indeed it looks like something is really confused as the thread is
> missing at least patches 2 and 3.
> 

You're right there's not much about the regulator there. Xulong Orange
Pi PC is ARM SBC, that uses Allwinner H3 Soc, to which this regulator is
connected via I2C bus, to regulate the main CPU supply voltage. It is
used on some other SBC's from Xulong.

It is fairly simple single output, fixed I2C address voltage regulator.
It has just 3 registers, which allow for: slew rate control (not used in
this driver), setting and reading out the voltage, switching between
voltage set via I2C and via external resistor divider and
enabling/disabling output. It also has status reporting for
over-tempertature and over-current conditions. That's all the features
it has.

The patch series uses it to provide dynamic vltage scaling of the ARM
cores in the SoC to be able to achieve higher CPU frequency.

Datasheet is here:

https://01916271185794791722.googlegroups.com/attach/93415fbd5402/SY8106A_datasheet.pdf?part=0.1&vt=ANaJVrHMej8w8XRfd-7A3XoyiryMDDhrHU2SS-tYyHCpOIXRqIaICOIlZTWAUV74vToesmic457zPvODDuvrNnRpomPOPbtV8bMMFV65VX5aYb5NciMkh8E

I'll also include this information in the revised patch.

thank you and regards,
  Ondrej Jirman

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] USB OTG on Orange Pi PC

[Ondřej Jirman]

Hi,

if anyone wants to play with the OTG port support on Orange Pi PC, you
can try these patches:

https://files.megous.com/orange-pi-dvfs/linux-4.7-OrangePI/usb-otg/

I don't have much time to test it extensively, but it seems to work.

I'm not yet submitting them "formally". This is just a heads up that I'm
doing some work on configuring this and making it work on this SBC.

Early testing is very welcome. :)

regards,
  Ondrej Jirman

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH 1/3] clk: sunxi: Add a driver for the CCU

[Ondřej Jirman]

On 28.6.2016 17:37, Jean-Francois Moine wrote:
> Most of the clocks in the Allwinner's SoCs are configured in the CCU
> (Clock Configuration Unit).
> 
> The PLL clocks are driven from the main clock. Their rates are controlled
> by a set of multiply and divide factors, named from the Allwinner's
> documentation:
> - multipliers: 'n' and 'k'
> - dividers: 'd1', 'd2', 'm' and 'p'
> 
> The peripheral clocks may receive their inputs from one or more parents,
> thanks to a mux. Their rates are controlled by a set of divide factors
> only, named 'm' and 'p'.
> 
> This driver also handles:
> - fixed clocks,
> - the phase delays for the MMCs,
> - the clock gates,
> - the bus gates,
> - and the resets.
> 
> Signed-off-by: Jean-Francois Moine 
> ---
>  drivers/clk/sunxi/Makefile |   2 +
>  drivers/clk/sunxi/ccu.c| 980 
> +
>  drivers/clk/sunxi/ccu.h| 153 +++
>  3 files changed, 1135 insertions(+)
>  create mode 100644 drivers/clk/sunxi/ccu.c
>  create mode 100644 drivers/clk/sunxi/ccu.h
> 
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 39d2044..b8ca3e2 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -26,3 +26,5 @@ obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-cpus.o
>  obj-$(CONFIG_MFD_SUN6I_PRCM) += \
>   clk-sun6i-ar100.o clk-sun6i-apb0.o clk-sun6i-apb0-gates.o \
>   clk-sun8i-apb0.o
> +
> +obj-y += ccu.o
> diff --git a/drivers/clk/sunxi/ccu.c b/drivers/clk/sunxi/ccu.c
> new file mode 100644
> index 000..5749f9c
> --- /dev/null
> +++ b/drivers/clk/sunxi/ccu.c
> @@ -0,0 +1,980 @@
> +/*
> + * Allwinner system CCU
> + *
> + * Copyright (C) 2016 Jean-Francois Moine 
> + * Rewrite from 'sunxi-ng':
> + * Copyright (C) 2016 Maxime Ripard 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ccu.h"
> +
> +#define CCU_DEBUG 0
> +
> +#define CCU_MASK(shift, width) (((1 << width) - 1) << shift)
> +

You may use macros from:

http://lxr.free-electrons.com/source/include/linux/bitops.h

At least as a basis for the CCU_MASK macro.

> +/*
> + * factors:
> + *   n: multiplier (PLL)
> + *   d1, d2: boolean dividers by 2 (d2 is p with 1 bit width - PLL)
> + *   k: multiplier (PLL)
> + *   m: divider
> + *   p: divider by power of 2
> + */
> +struct values {
> + int n, d1, k, m, p;
> +};
> +
> +static DEFINE_SPINLOCK(ccu_lock);
> +
> +void ccu_set_clock(struct ccu *ccu, int reg, u32 mask, u32 val)
> +{
> +
> +#if CCU_DEBUG
> + pr_info("** ccu %s set %03x %08x\n",
> + clk_hw_get_name(&ccu->hw), reg,
> + (readl(ccu->base + reg) & ~mask) | val);
> +#endif
> + spin_lock(&ccu_lock);
> + writel((readl(ccu->base + reg) & ~mask) | val, ccu->base + reg);
> + spin_unlock(&ccu_lock);
> +}
> +
> +/* --- prepare / enable --- */
> +int ccu_prepare(struct clk_hw *hw)
> +{
> + struct ccu *ccu = hw2ccu(hw);
> +
> + if (!ccu->reset_reg && !ccu->bus_reg)
> + return 0;
> +
> +#if CCU_DEBUG
> + pr_info("** ccu %s prepare\n", clk_hw_get_name(&ccu->hw));
> +#endif
> + spin_lock(&ccu_lock);
> + if (ccu->reset_reg)
> + writel(readl(ccu->base + ccu->reset_reg) |
> + BIT(ccu->reset_bit),
> + ccu->base + ccu->reset_reg);
> + if (ccu->bus_reg)
> + writel(readl(ccu->base + ccu->bus_reg) | BIT(ccu->bus_bit),
> + ccu->base + ccu->bus_reg);
> + spin_unlock(&ccu_lock);
> +
> + return 0;
> +}
> +
> +void ccu_unprepare(struct clk_hw *hw)
> +{
> + struct ccu *ccu = hw2ccu(hw);
> +
> + if (!ccu->reset_reg && !ccu->bus_reg)
> + return;
> +
> +#if CCU_DEBUG
> + pr_info("** ccu %s unprepare\n", clk_hw_get_name(&ccu->hw));
> +#endif
> + spin_lock(&ccu_lock);
> + if (ccu->bus_reg)
> + writel(readl(ccu->base + ccu->bus_reg) & ~BIT(ccu->bus_bit),
> + ccu->base + ccu->bus_reg);
> + if (ccu->reset_reg)
> + writel(readl(ccu->base + ccu->reset_reg) &
> + ~BIT(ccu->reset_bit),
> + ccu->base + ccu->reset_reg);
> + spin_unlock(&ccu_lock);
> +}
> +
> +int ccu_enable(struct clk_hw *hw)
> +{
> + struct ccu *ccu = hw2ccu(hw);
> +
> + if (!ccu->has_gate)
> + return 0;
> +
> +#if CCU_DEBUG
> + pr_info("** ccu %s enable\n", clk_hw_get_name(&ccu->hw));
> +#endif
> + spin_lock(&ccu_lock);
> + writel(readl(ccu->base + ccu->reg) | BIT(ccu->gate_bit),
> + ccu->base + ccu->reg);
> + spin_unlock(&ccu_lock);
> 

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 29.6.2016 22:45, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote:
>> On 25.6.2016 09:02, Maxime Ripard wrote:
>>> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
>>>> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
>>>>> Hello,
>>>>>
>>>>> comments below.
>>>>>
>>>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>>>>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>>>>>> From: Ondrej Jirman 
>>>>>>>
>>>>>>> Add label to the first cpu so that it can be referenced
>>>>>>> from derived dts files.
>>>>>>>
>>>>>>> Signed-off-by: Ondrej Jirman 
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>>>>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>>>> index 9938972..82faefc 100644
>>>>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>>>> @@ -52,7 +52,7 @@
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>>
>>>>>>> -   cpu@0 {
>>>>>>> +   cpu0: cpu@0 {
>>>>>>> compatible = "arm,cortex-a7";
>>>>>>> device_type = "cpu";
>>>>>>> reg = <0>;
>>>>>>
>>>>>> Can you also set the cpu clock here? It is part of the SoC
>>>>>> and does not belong in the board DTS files.
>>>>>
>>>>> Do you mean operating-points, or something else? Different SBCs will
>>>>> probably require different combinations of operating points just for
>>>>> safety's sake, because they have different regulators and [some have
>>>>> botched] thermal designs, so it might make sense to customize it for
>>>>> differnt boards, and I don't feel adventurous enough setting it for all
>>>>> H3 boards out there.
>>>>
>>>> I meant clocks = <...> and clock-latency = <...>.
>>>>
>>>> These 2 are part of the SoC.
>>>>
>>>> The OPP can stay in the board files. It's a pity there's no standard
>>>> OPP table for H3 though. :(
>>>
>>> This has never been the case, and we always had some deviation in the
>>> FEX files for all the SoCs.
>>>
>>> If we could come up with standard OPPs that work for every one,
>>> there's no reason it can't happen here.
>>>
>>> I don't really see why the thermal design should change anything. If a
>>> boards heats faster, it will throttle down to a lower OPP faster, but
>>> those OPPs are not going to change.
>>
>> I've no way to test, but I've been told some Sinovoip boards are really
>> bad in this regard (SoC is not even well thermally connected to the
>> PCB/PCB not having copper layer to spread the heat). Thermal sensor
>> readings happen at fixed intervals, so the question is if you can heat
>> up the soc from say 80°C (first trip point) to over 110°C in less than
>> that period (330ms currently).
>>
>> I say it shouldn't be a problem, if that small thing is drawing say 2W
>> at max load. It will burn or trigger a second trip point before the
>> first one has a chance to trigger and the kernel will shut down. I
>> remember tkaiser saying that he has to run that board at 240MHz max. But
>> perhaps I'm misremembering.
>>
>> I'm just speculating.
> 
> Yes, but that's just poor thermal design. What I was saying is that
> even if we really need to throttle the SoC to 240 MHz on that board
> because it heats too much, the couple of the frequency and the voltage
> will likely be the same across all boards. It's just the amount of
> time we'll spend using it that will differ.
> 
> But that's just my understanding, I might be speaking non-sense :)
> 
> Maxime
> 

You're probably right. Operating points should be part of h3.dtsi, and
if some board is particularly bad, and can't handle being above certain
frequency safely, due to thermal design issues, we can override
operating points in its dts file.

regards,
  Ondrej

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

Hello,

On 30.6.2016 13:13, Michal Suchanek wrote:
> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
>> From: Ondrej Jirman 
>>
>> Use Xulong Orange Pi One GPIO based regulator for
>> passive cooling and thermal management.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>> +
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index b1bd6b0..a38d871 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -109,6 +109,45 @@
>> };
>>  };
>>
>> +&cpu0 {
>> +   operating-points = <
>> +   /* kHzuV */
>> +   1296000 130
>> +   120 130
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

Just to verify, did you test with the entire series applied? (especially
the PLL1 clk application changes)

You may try dropping the highest operating point, it's probably overly
optimistic for Orange Pi One.

Is the power supply/cable you're using hard enough?

Where during the boot process does it lock up?

regards,
  Ondrej

> Thanks
> 
> Michal
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: USB OTG on Orange Pi PC

[Ondřej Jirman]

Hi,

hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
phy code path for phy0. So I believe it was untested,
because I didn't find any dts file that would use phy0.

Good luck with the audio driver.

regards,
  o.



On 30.6.2016 07:17, boob...@gmail.com wrote:
> Nice work.
> Sure i will try your path, last time i tried otg i had kernel exception when 
> loading musb driver.
> I would like setup usb otg in device mode as g_ether or cdrom drive emulation 
> to loading bootable iso with gpio sw for iso selection yes i dream :)
> 
> But for now I try to translate audio codec driver from kernel 3.4,,,removing 
> lot of config from fex file, remove undocumented R-PRCM (0x01f01400) 
> read/Write (seem to be configuration area for current setting to restore 
> after a reboot, not vital..), setup PLL2 (audio_pll) directly in driver since 
> there isn't no clk driver PLL2 for now (I think it's related to I2S driver, 
> and it's a complex clock with multi factor to adjust PLL frequency). For now 
> i just configure it at 24.57Mhz/22.57Mhz and i have succes to have something 
> in /sys/class/device/sunxi_codec/ and /sunxi-pcm-codec/, no kernel exception 
> but no sound card available :(
> When i see in sun4i audio driver, there is lot of new code to create card in 
> /dev/snd/... 
> It's seem I'm lost deeply in nowhere for now, but I will try your work for 
> sure (just one source of kernel opps at the same time!).
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 17:16, Michal Suchanek wrote:
> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>> Hello,
>>
>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 25 June 2016 at 05:45,   wrote:
>>>> From: Ondrej Jirman 
>>>>
>>>> Use Xulong Orange Pi One GPIO based regulator for
>>>> passive cooling and thermal management.
>>>>
>>>> Signed-off-by: Ondrej Jirman 
>>>> ---
>>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>>> +
>>>>  1 file changed, 39 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>> index b1bd6b0..a38d871 100644
>>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>> @@ -109,6 +109,45 @@
>>>> };
>>>>  };
>>>>
>>>> +&cpu0 {
>>>> +   operating-points = <
>>>> +   /* kHzuV */
>>>> +   1296000 130
>>>> +   120 130
>>>
>>> First problem is that the board boots at 1008000 which is not listed
>>> and the kernel complains.
>>>
>>> Second problem is that the board locks up during boot with this enabled.
>>>
>>> Do you have some suggestion for alternate configuration to test?
>>
>> Just to verify, did you test with the entire series applied? (especially
>> the PLL1 clk application changes)
> 
> Yes, I applied the whole series.
> 
>>
>> You may try dropping the highest operating point, it's probably overly
>> optimistic for Orange Pi One.
>>
>> Is the power supply/cable you're using hard enough?
> 
> I use a 7 port hub to power the board. It worked with some other small
> devboards.
> 
> The cable is some random Chinese USB to power jack adaptor with an
> extra adaptor to fit the Pi socket. It looks ok but I did not test
> this particular combination thoroughly.
> 
>>
>> Where during the boot process does it lock up?
> 
> Usually sometime around enabling cpufreq  before getty starts.
> Different runs and settings give slightly different results. In
> particular adding the 1008000 point seems to make it go further.
> 
> Removing all traces of the regulator, cpufreq and thermal I can boot
> pretty much 100% to login prompt.
> 
> I don't think the difference between 1GHz and 1.3GHz frequency on the
> core would put much additional stress on the supply but I can try with
> 35W PSU and some alternative cabling to be sure.
> 
> I did some more tests and it seems 1008000@1.1V is fine but switching
> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
> there is need for some delay somewhere for the regulator to get
> stable?

Please try adding:

  regulator-ramp-delay = <10>

to the gpio regulator.

which will allow 100ms per 1V change, which should b enough for
determining, if this is the cause.

regards,
  Ondrej

> Thanks
> 
> Michal
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 17:50, Michal Suchanek wrote:
> On 30 June 2016 at 17:16, Michal Suchanek  wrote:
>> On 30 June 2016 at 16:19, Ondřej Jirman  wrote:
>>> Hello,
>>>
>>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>>> Hello,
>>>>
>>>> On 25 June 2016 at 05:45,   wrote:
>>>>> From: Ondrej Jirman 
>>>>>
>>>>> Use Xulong Orange Pi One GPIO based regulator for
>>>>> passive cooling and thermal management.
>>>>>
>>>>> Signed-off-by: Ondrej Jirman 
>>>>> ---
>>>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>>>> +
>>>>>  1 file changed, 39 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>>> index b1bd6b0..a38d871 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>>> @@ -109,6 +109,45 @@
>>>>> };
>>>>>  };
>>>>>
>>>>> +&cpu0 {
>>>>> +   operating-points = <
>>>>> +   /* kHzuV */
>>>>> +   1296000 130
>>>>> +   120 130
>>>>
>>>> First problem is that the board boots at 1008000 which is not listed
>>>> and the kernel complains.
>>>>
>>>> Second problem is that the board locks up during boot with this enabled.
>>>>
>>>> Do you have some suggestion for alternate configuration to test?
>>>
>>> Just to verify, did you test with the entire series applied? (especially
>>> the PLL1 clk application changes)
>>
>> Yes, I applied the whole series.
>>
>>>
>>> You may try dropping the highest operating point, it's probably overly
>>> optimistic for Orange Pi One.
>>>
>>> Is the power supply/cable you're using hard enough?
>>
>> I use a 7 port hub to power the board. It worked with some other small
>> devboards.
>>
>> The cable is some random Chinese USB to power jack adaptor with an
>> extra adaptor to fit the Pi socket. It looks ok but I did not test
>> this particular combination thoroughly.
>>
>>>
>>> Where during the boot process does it lock up?
>>
>> Usually sometime around enabling cpufreq  before getty starts.
>> Different runs and settings give slightly different results. In
>> particular adding the 1008000 point seems to make it go further.
>>
>> Removing all traces of the regulator, cpufreq and thermal I can boot
>> pretty much 100% to login prompt.
>>
>> I don't think the difference between 1GHz and 1.3GHz frequency on the
>> core would put much additional stress on the supply but I can try with
>> 35W PSU and some alternative cabling to be sure.
>>
>> I did some more tests and it seems 1008000@1.1V is fine but switching
>> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
>> there is need for some delay somewhere for the regulator to get
>> stable?
>>
> 
> Hm, the AW table shows 1008000@1.3V as supported state and it indeed
> works. So the voltage switching works or does nothing. Can I measure
> the regulator output somewhere? Clocking the chip higher does not
> work.

Regulator output is TP1 on the bottom of the board, next ot the CSI
connector.

regards,
  Ondrej

> I will try with another PSU later.
> 
> Thanks
> 
> Michal
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Ondřej Jirman]

On 30.6.2016 20:21, Michal Suchanek wrote:
> On 30 June 2016 at 20:06, Michal Suchanek  wrote:
>> Hello,
>>
>> On 30 June 2016 at 16:44, Ondřej Jirman  wrote:
>>> Hi,
>>>
>>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
>>> phy code path for phy0. So I believe it was untested,
>>> because I didn't find any dts file that would use phy0.
>>>
>>
>> This WorksForMe(TM).
> 
> There is still small problem left. When I boot with the USB cable
> connected I have to disconnect and reconnect the cable to get the
> gadget working.
> 

Good to know, I'll test this case. It will probably be something around
the iddet handling during phy0 initialization, which leads to the
connected cable being treated as OTG, which would turn the usb port into
host mode. You can verify that by looking into sysfs where there's an
attribute that tells the current mode (peripheral / host). I don't
rember where exactly it could be found.

Or you can force the mode to peripheral in the dts. That may be a
workaround for now.

regards,
  o.

>>
>>>
>>> On 30.6.2016 07:17, boob...@gmail.com wrote:
>>>> Nice work.
>>>> Sure i will try your path, last time i tried otg i had kernel exception 
>>>> when loading musb driver.
>>>> I would like setup usb otg in device mode as g_ether or cdrom drive 
>>>> emulation to loading bootable iso with gpio sw for iso selection yes i 
>>>> dream :)
> 
> Actually, the cdrom drive emulation is not out of question. You will
> need to tune the linux mass storage gadget to identify as CD-rom
> rather than USB stick. I wanted this for IDE CD-rom. The systems that
> boot from USB CD-rom usually can do USB stick too.
> 
> Thanks
> 
> Michal
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

Hi,

On 30.6.2016 22:40, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 05:45:03AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> PLL1 on H3 requires special factors application algorithm,
>> when the rate is changed. This algorithm was extracted
>> from the arisc code that handles frequency scaling
>> in the BSP kernel.
>>
>> This commit adds optional apply function to
>> struct factors_data, that can implement non-trivial
>> factors application method, when necessary.
>>
>> Also struct clk_factors_config is extended with position
>> of the PLL lock flag.
> 
> Have you tested the current implementation, and found that it was not
> working, or did you duplicate the arisc code directly?

I have tested the current implementation, and it was not working. It
depended on some other factors, like the initial setup done by u-boot.
It didn't work reliably.

Then I reverse engineered arisc, in an effort to see what's the
difference, between mainline and BSP code.

>>  /**
>> + * sun8i_h3_apply_pll1_factors() - applies n, k, m, p factors to the
>> + * register using an algorithm that tries to reserve the PLL lock
>> + */
>> +
>> +static void sun8i_h3_apply_pll1_factors(struct clk_factors *factors, struct 
>> factors_request *req)
>> +{
>> +const struct clk_factors_config *config = factors->config;
>> +u32 reg;
>> +
>> +/* Fetch the register value */
>> +reg = readl(factors->reg);
>> +
>> +if (FACTOR_GET(config->pshift, config->pwidth, reg) < req->p) {
>> +reg = FACTOR_SET(config->pshift, config->pwidth, reg, req->p);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
> 
> So there was some doubts about the fact that P was being used, or at
> least that it was useful.

p is necessary to reduce frequencies below 288 MHz according to the
datasheet.

>> +if (FACTOR_GET(config->mshift, config->mwidth, reg) < req->m) {
>> +reg = FACTOR_SET(config->mshift, config->mwidth, reg, req->m);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
>> +
>> +reg = FACTOR_SET(config->nshift, config->nwidth, reg, req->n);
>> +reg = FACTOR_SET(config->kshift, config->kwidth, reg, req->k);
>> +
>> +writel(reg, factors->reg);
>> +__delay(20);
>> +
>> +while (!(readl(factors->reg) & (1 << config->lock)));
> 
> So, they are applying the dividers first, and then applying the
> multipliers, and then wait for the PLL to stabilize.

Not exactly, first we are increasing dividers if the new dividers are
higher that that what's already set. This ensures that because
application of dividers is immediate by the design of the PLL, the
application of multipliers isn't. So the VCO would still run at the same
frequency for a while gradually rising to a new value for example,
while the dividers would be reduced immediately. Leading to crash.

PLL
--
PRE DIV(f0) -> VCO(f1) -> POST DIV(f2)
   P K,N   M

Example: (we set all factors at once, reducing dividers and multipliers
at the same time at 0ms - this should lead to no change in the output
frequency, but...)

-1ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz
 0ms: f0 = 24MHz, f1 = 2GHz,   f2 = 2GHz   - boom
 1ms: f0 = 24MHz, f1 = 1.5GHz, f2 = 1.5GHz
 2ms: f0 = 24MHz, f1 = 1GHz,   f2 = 1GHz

The current code crashes exactly at boom, you don't get any more
instructions to execute.

See.

So this patch first increases dividers (only if necessary), changes
multipliers and waits for change to happen (takes around 2000 cycles),
and then decreases dividers (only if necessary).

So we get:

-1ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz
 0ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz   - no boom, multiplier
 reduced
 1ms: f0 = 24MHz, f1 = 1.5GHz, f2 = 0.75GHz
1.9ms: f0 = 24MHz, f1 = 1GHz,   f2 = 0.5GHz - we got PLL sync
 2ms: f0 = 24MHz, f1 = 1GHz,   f2 = 1GHz   - and here we reduce divider
at last

>> +
>> +if (FACTOR_GET(config->mshift, config->mwidth, reg) > req->m) {
>> +reg = FACTOR_SET(config->mshift, config->mwidth, reg, req->m);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
>> +
>> +if (FACTOR_GET(config->pshift, config->pwidth, reg) > req->p) {
>> +reg = FACTOR_SET(config->pshift, config->pwidth, reg, req->p);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
> 
> However, this is kind of weird, why would you need to re-apply the
> dividers? Nothing really changes. Have you tried without that part?

See above, we either increase before PLL change, or reduce dividers
after the change. Nothing is re-applied.

> Since this is really specific, I guess you could simply make the
> clk_ops for the nkmp clocks public, and just re-implement set_rate
> using that logic.

I would argue that this may be necessary for other PLL clocks too, if
you can get out of bounds outp

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 30.6.2016 22:40, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 05:45:03AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> PLL1 on H3 requires special factors application algorithm,
>> when the rate is changed. This algorithm was extracted
>> from the arisc code that handles frequency scaling
>> in the BSP kernel.
>>
>> This commit adds optional apply function to
>> struct factors_data, that can implement non-trivial
>> factors application method, when necessary.
>>
>> Also struct clk_factors_config is extended with position
>> of the PLL lock flag.
> 
> Have you tested the current implementation, and found that it was not
> working, or did you duplicate the arisc code directly?

Also of note is that similar code probably doesn't crash in u-boot,
because there, before changing the PLL1 clock, the cpu is switched to
24MHz osc, so it is not overclocked, even if factors align in such a way
that you'd get the behavior I described in the other email.

>>  /**
>> + * sun8i_h3_apply_pll1_factors() - applies n, k, m, p factors to the
>> + * register using an algorithm that tries to reserve the PLL lock
>> + */
>> +
>> +static void sun8i_h3_apply_pll1_factors(struct clk_factors *factors, struct 
>> factors_request *req)
>> +{
>> +const struct clk_factors_config *config = factors->config;
>> +u32 reg;
>> +
>> +/* Fetch the register value */
>> +reg = readl(factors->reg);
>> +
>> +if (FACTOR_GET(config->pshift, config->pwidth, reg) < req->p) {
>> +reg = FACTOR_SET(config->pshift, config->pwidth, reg, req->p);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
> 
> So there was some doubts about the fact that P was being used, or at
> least that it was useful.
> 
>> +if (FACTOR_GET(config->mshift, config->mwidth, reg) < req->m) {
>> +reg = FACTOR_SET(config->mshift, config->mwidth, reg, req->m);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
>> +
>> +reg = FACTOR_SET(config->nshift, config->nwidth, reg, req->n);
>> +reg = FACTOR_SET(config->kshift, config->kwidth, reg, req->k);
>> +
>> +writel(reg, factors->reg);
>> +__delay(20);
>> +
>> +while (!(readl(factors->reg) & (1 << config->lock)));
> 
> So, they are applying the dividers first, and then applying the
> multipliers, and then wait for the PLL to stabilize.
> 
>> +
>> +if (FACTOR_GET(config->mshift, config->mwidth, reg) > req->m) {
>> +reg = FACTOR_SET(config->mshift, config->mwidth, reg, req->m);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
>> +
>> +if (FACTOR_GET(config->pshift, config->pwidth, reg) > req->p) {
>> +reg = FACTOR_SET(config->pshift, config->pwidth, reg, req->p);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
> 
> However, this is kind of weird, why would you need to re-apply the
> dividers? Nothing really changes. Have you tried without that part?
> 
> Since this is really specific, I guess you could simply make the
> clk_ops for the nkmp clocks public, and just re-implement set_rate
> using that logic.
> 
> You might also need to set an upper limit on P, since the last value
> (4) is not a valid one.
> 
> I guess you could do that by adding a max field in the __ccu_div
> structure.
> 
> Maxime
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

On 30.6.2016 16:23, Siarhei Siamashka wrote:
> On Thu, 30 Jun 2016 13:13:48 +0200
> Michal Suchanek  wrote:
> 
>> Hello,
>>
>> On 25 June 2016 at 05:45,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Use Xulong Orange Pi One GPIO based regulator for
>>> passive cooling and thermal management.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>> +
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> index b1bd6b0..a38d871 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> @@ -109,6 +109,45 @@
>>> };
>>>  };
>>>
>>> +&cpu0 {
>>> +   operating-points = <
>>> +   /* kHzuV */
>>> +   1296000 130
>>> +   120 130  
>>
>> First problem is that the board boots at 1008000 which is not listed
>> and the kernel complains.
>>
>> Second problem is that the board locks up during boot with this enabled.
>>
>> Do you have some suggestion for alternate configuration to test?
> 
> Maybe try the Allwinner's original DVFS table instead of these
> undervolted values and see if it helps?
> 
> https://linux-sunxi.org/index.php?title=Xunlong_Orange_Pi_PC&oldid=17753#CPU_clock_speed_limit

Thanks, I'll use these. I'm not sure what will happen if regulator is
not capable of providing the exact voltages specified in the operating
points, though. Will it do the sane thing? :)

Also LV6+ in the table is bellow specified minimum voltage in the
datasheet. But then Orange Pi works at much lower voltages for me.

Conversly LV1 is the absolute maximum. Recommended maximum is 1.4V So I
would not use that.

It might be nice to have something like that dram clock test, but for
cpux freq/voltage, and collect some statistics.

regards,
  Ondrej

> While undervolting is tempting because it helps to decrease the SoC
> temperature and avoid throttling, different units may have different
> tolerances and one needs to be very careful when picking defaults
> that are intended to work correctly on all boards. Some safety
> headroom exists there for a reason.
> 
> If I remember correctly, some people pushed for undervolting experiments
> at least twice in the past (on the Banana Pi and C.H.I.P.). In both
> cases this did not end up well and had to be fixed later to solve
> reliability problems.
> 
> In order to allow individual per-unit tuning, a concept of "speed
> grading" may be probably introduced later. So that the board is tested
> for reliability and then the speed grade rating is stored somewhere on
> the non-removable storage (EEPROM, SPI flash, eFUSE, ...). Some SoC
> manufacturers, such as Samsung, are already doing this with their chips.
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 1.7.2016 07:37, Jean-Francois Moine wrote:
> On Fri, 1 Jul 2016 02:50:57 +0200
> Ondřej Jirman  wrote:
> 
>>> Since this is really specific, I guess you could simply make the
>>> clk_ops for the nkmp clocks public, and just re-implement set_rate
>>> using that logic.
>>
>> I would argue that this may be necessary for other PLL clocks too, if
>> you can get out of bounds output frequency, by changing the dividers too
>> early or too late. So perhaps this code should be generalized for other
>> PLL clocks too, instead.
> 
> The documentation says that only the CPU and DDR PLLs can be dynamically
> changed after boot.

The question is what exactly is meant by after boot. :) Anyway, if the
kernel has no business changing some other PLLs, if there's code for
changing them, should it be dropped?

regards,
  Ondrej

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Ondřej Jirman]

On 1.7.2016 13:19, Michal Suchanek wrote:
> On 1 July 2016 at 13:02, Michal Suchanek  wrote:
>> On 30 June 2016 at 22:30, Ondřej Jirman  wrote:
>>> On 30.6.2016 20:21, Michal Suchanek wrote:
>>>> On 30 June 2016 at 20:06, Michal Suchanek  wrote:
>>>>> Hello,
>>>>>
>>>>> On 30 June 2016 at 16:44, Ondřej Jirman  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
>>>>>> phy code path for phy0. So I believe it was untested,
>>>>>> because I didn't find any dts file that would use phy0.
>>>>>>
>>>>>
>>>>> This WorksForMe(TM).
>>>>
>>>> There is still small problem left. When I boot with the USB cable
>>>> connected I have to disconnect and reconnect the cable to get the
>>>> gadget working.
>>>>
>>>
>>> Good to know, I'll test this case. It will probably be something around
>>> the iddet handling during phy0 initialization, which leads to the
>>> connected cable being treated as OTG, which would turn the usb port into
>>> host mode. You can verify that by looking into sysfs where there's an
>>> attribute that tells the current mode (peripheral / host). I don't
>>> rember where exactly it could be found.
>>>
>>
>> This is interesting. The USB gadget works (from the start without 
>> reconnecting)
>> with one PC + hub and fails with other PC + hub. Both pretty much 100%
>>
>> Ironically the broken hub provides sound voltage above 5.1V and the working
>> one should give about 4.75V given its 0.2V drop from the board power level.
> 
> For the record
> 
> /sys/devices/platform/soc/1c19000.usb/musb-hdrc.1.auto/mode is
> b_idle when gadget is broken
> b_peripherial when gadget is working

Hi, you may try adding printks to sun4i_usb_phy0_id_vbus_det_scan in
phy-sun4i-usb.c inside the if (id_notify) and if (vbus_notify), and try
if you can observe any differences between the two hubs in dmesg output.

Or first, I'd suggest to add unconditional "return true" to
sun4i_usb_phy0_poll, if that fixes anything. This will enable polling on
the iddet gpio. (Perhaps gpio interrupts are not very reliable?)

regards,
  Ondrej

> Thanks
> 
> Michal
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 15.7.2016 10:53, Maxime Ripard wrote:
> On Fri, Jul 01, 2016 at 02:50:57AM +0200, Ondřej Jirman wrote:
>>>>  /**
>>>> + * sun8i_h3_apply_pll1_factors() - applies n, k, m, p factors to the
>>>> + * register using an algorithm that tries to reserve the PLL lock
>>>> + */
>>>> +
>>>> +static void sun8i_h3_apply_pll1_factors(struct clk_factors *factors, 
>>>> struct factors_request *req)
>>>> +{
>>>> +  const struct clk_factors_config *config = factors->config;
>>>> +  u32 reg;
>>>> +
>>>> +  /* Fetch the register value */
>>>> +  reg = readl(factors->reg);
>>>> +
>>>> +  if (FACTOR_GET(config->pshift, config->pwidth, reg) < req->p) {
>>>> +  reg = FACTOR_SET(config->pshift, config->pwidth, reg, req->p);
>>>> +
>>>> +  writel(reg, factors->reg);
>>>> +  __delay(2000);
>>>> +  }
>>>
>>> So there was some doubts about the fact that P was being used, or at
>>> least that it was useful.
>>
>> p is necessary to reduce frequencies below 288 MHz according to the
>> datasheet.
> 
> Yes, but you could reach those frequencies without P, too, and it's
> not part of any OPP provided by Allwinner.

The arisc firmware for H3 contains table of factors for frequences from
0 to 2GHz and, P is used below 240MHz. M is never used, BTW. (other
datasheets specify M as for testing use only, whatever that means - not
H3, but it seems it's the same PLL block)


... snip ...
{ .n = 9, .k = 0, .m = 0, .p = 2 }, // 60 => 60 MHz
{ .n = 10, .k = 0, .m = 0, .p = 2 }, // 66 => 66 MHz
{ .n = 11, .k = 0, .m = 0, .p = 2 }, // 72 => 72 MHz
{ .n = 12, .k = 0, .m = 0, .p = 2 }, // 78 => 78 MHz
{ .n = 13, .k = 0, .m = 0, .p = 2 }, // 84 => 84 MHz
{ .n = 14, .k = 0, .m = 0, .p = 2 }, // 90 => 90 MHz
{ .n = 15, .k = 0, .m = 0, .p = 2 }, // 96 => 96 MHz
{ .n = 16, .k = 0, .m = 0, .p = 2 }, // 102 => 102 MHz
{ .n = 17, .k = 0, .m = 0, .p = 2 }, // 108 => 108 MHz
{ .n = 18, .k = 0, .m = 0, .p = 2 }, // 114 => 114 MHz
{ .n = 9, .k = 0, .m = 0, .p = 1 }, // 120 => 120 MHz
{ .n = 10, .k = 0, .m = 0, .p = 1 }, // 126 => 132 MHz
{ .n = 10, .k = 0, .m = 0, .p = 1 }, // 132 => 132 MHz
{ .n = 11, .k = 0, .m = 0, .p = 1 }, // 138 => 144 MHz
{ .n = 11, .k = 0, .m = 0, .p = 1 }, // 144 => 144 MHz
{ .n = 12, .k = 0, .m = 0, .p = 1 }, // 150 => 156 MHz
{ .n = 12, .k = 0, .m = 0, .p = 1 }, // 156 => 156 MHz
{ .n = 13, .k = 0, .m = 0, .p = 1 }, // 162 => 168 MHz
{ .n = 13, .k = 0, .m = 0, .p = 1 }, // 168 => 168 MHz
{ .n = 14, .k = 0, .m = 0, .p = 1 }, // 174 => 180 MHz
{ .n = 14, .k = 0, .m = 0, .p = 1 }, // 180 => 180 MHz
{ .n = 15, .k = 0, .m = 0, .p = 1 }, // 186 => 192 MHz
{ .n = 15, .k = 0, .m = 0, .p = 1 }, // 192 => 192 MHz
{ .n = 16, .k = 0, .m = 0, .p = 1 }, // 198 => 204 MHz
{ .n = 16, .k = 0, .m = 0, .p = 1 }, // 204 => 204 MHz
{ .n = 17, .k = 0, .m = 0, .p = 1 }, // 210 => 216 MHz
{ .n = 17, .k = 0, .m = 0, .p = 1 }, // 216 => 216 MHz
{ .n = 18, .k = 0, .m = 0, .p = 1 }, // 222 => 228 MHz
{ .n = 18, .k = 0, .m = 0, .p = 1 }, // 228 => 228 MHz
{ .n = 9, .k = 0, .m = 0, .p = 0 }, // 234 => 240 MHz
{ .n = 9, .k = 0, .m = 0, .p = 0 }, // 240 => 240 MHz
{ .n = 10, .k = 0, .m = 0, .p = 0 }, // 246 => 264 MHz
{ .n = 10, .k = 0, .m = 0, .p = 0 }, // 252 => 264 MHz
{ .n = 10, .k = 0, .m = 0, .p = 0 }, // 258 => 264 MHz
{ .n = 10, .k = 0, .m = 0, .p = 0 }, // 264 => 264 MHz
{ .n = 11, .k = 0, .m = 0, .p = 0 }, // 270 => 288 MHz
{ .n = 11, .k = 0, .m = 0, .p = 0 }, // 276 => 288 MHz
... snip ...


>>>> +  if (FACTOR_GET(config->mshift, config->mwidth, reg) < req->m) {
>>>> +  reg = FACTOR_SET(config->mshift, config->mwidth, reg, req->m);
>>>> +
>>>> +  writel(reg, factors->reg);
>>>> +  __delay(2000);
>>>> +  }
>>>> +
>>>> +  reg = FACTOR_SET(config->nshift, config->nwidth, reg, req->n);
>>>> +  reg = FACTOR_SET(config->kshift, config->kwidth, reg, req->k);
>>>> +
>>>> +  writel(reg, factors->reg);
>>>> +  __delay(20);
>>>> +
>>>> +  while (!(readl(factors->reg) & (1 << config->lock)));
>>>
>>> So, they are applying the dividers first, and the

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 15.7.2016 15:27, Jean-Francois Moine wrote:
> On Fri, 15 Jul 2016 12:38:54 +0200
> Ondřej Jirman  wrote:
> 
>>> If so, then yes, trying to switch to the 24MHz oscillator before
>>> applying the factors, and then switching back when the PLL is stable
>>> would be a nice solution.
>>>
>>> I just checked, and all the SoCs we've had so far have that
>>> possibility, so if it works, for now, I'd like to stick to that.
>>
>> It would need to be tested. U-boot does the change only once, while the
>> kernel would be doing it all the time and between various frequencies
>> and PLL settings. So the issues may show up with this solution too.
> 
> I don't think this is a good idea: the CPU clock may be changed at any
> time with the CPUFreq governor. I don't see the system moving from
> 1008MHz to 24MHz and then to 1200MHz when some computation is needed!

PLL lock time is around 10-20us, I'd guess based on the number of loops
in the PLL lock wait loop. So unless you'll be switching frequencies
many times per second, this should be barely noticeable.

But I'd like a different solution too.

> BTW, Ondřej, in my BPi M2+, I tried to change the CPU clock with your
> code at kernel start time from 792MHz to 1008MHz, but the hardware
> (arisc?) set an other value, and the system speed was lower than before
> (the PLL-CPUx register is 0x90031521 on boot, I want to set it to
> 1410 and I read 0x91031f33 - sorry, I did not have a look at the
> CPU SD pattern). Do you know why?

No idea. Arisc shouldn't do anything, unless you load some firmware into
it, and release its reset line.

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 15.7.2016 16:22, Michal Suchanek wrote:
> Hello,
> 
> On 15 July 2016 at 15:48, Ondřej Jirman  wrote:
>>
>>
>> On 15.7.2016 15:27, Jean-Francois Moine wrote:
>>> On Fri, 15 Jul 2016 12:38:54 +0200
>>> Ondřej Jirman  wrote:
>>>
>>>>> If so, then yes, trying to switch to the 24MHz oscillator before
>>>>> applying the factors, and then switching back when the PLL is stable
>>>>> would be a nice solution.
>>>>>
>>>>> I just checked, and all the SoCs we've had so far have that
>>>>> possibility, so if it works, for now, I'd like to stick to that.
>>>>
>>>> It would need to be tested. U-boot does the change only once, while the
>>>> kernel would be doing it all the time and between various frequencies
>>>> and PLL settings. So the issues may show up with this solution too.
>>>
>>> I don't think this is a good idea: the CPU clock may be changed at any
>>> time with the CPUFreq governor. I don't see the system moving from
>>> 1008MHz to 24MHz and then to 1200MHz when some computation is needed!
>>
>> PLL lock time is around 10-20us, I'd guess based on the number of loops
>> in the PLL lock wait loop. So unless you'll be switching frequencies
>> many times per second, this should be barely noticeable.
>>
>> But I'd like a different solution too.
> 
> Do you have a patch to test this?
> 
> For me changing CPU frequency on Orange Pi One always locks up the
> system. I keep running it on the u-boot setup 1.08GHz at 1.1V

Not anymore. But it's quite simple to hack it into the
drivers/clk/sunxi/clk-factors.c:clk_factors_set_rate()

You can look at u-boot arch/arm/mach-sunxi/clock_sun6i.c:clock_set_pll1
for how to change the CPU clock source.

> Thanks
> 
> Michal
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 25.6.2016 09:02, Maxime Ripard wrote:
> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
>> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
>>> Hello,
>>>
>>> comments below.
>>>
>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>>>> From: Ondrej Jirman 
>>>>>
>>>>> Add label to the first cpu so that it can be referenced
>>>>> from derived dts files.
>>>>>
>>>>> Signed-off-by: Ondrej Jirman 
>>>>> ---
>>>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> index 9938972..82faefc 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> @@ -52,7 +52,7 @@
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>>
>>>>> -   cpu@0 {
>>>>> +   cpu0: cpu@0 {
>>>>> compatible = "arm,cortex-a7";
>>>>> device_type = "cpu";
>>>>> reg = <0>;
>>>>
>>>> Can you also set the cpu clock here? It is part of the SoC
>>>> and does not belong in the board DTS files.
>>>
>>> Do you mean operating-points, or something else? Different SBCs will
>>> probably require different combinations of operating points just for
>>> safety's sake, because they have different regulators and [some have
>>> botched] thermal designs, so it might make sense to customize it for
>>> differnt boards, and I don't feel adventurous enough setting it for all
>>> H3 boards out there.
>>
>> I meant clocks = <...> and clock-latency = <...>.
>>
>> These 2 are part of the SoC.
>>
>> The OPP can stay in the board files. It's a pity there's no standard
>> OPP table for H3 though. :(
> 
> This has never been the case, and we always had some deviation in the
> FEX files for all the SoCs.
> 
> If we could come up with standard OPPs that work for every one,
> there's no reason it can't happen here.
> 
> I don't really see why the thermal design should change anything. If a
> boards heats faster, it will throttle down to a lower OPP faster, but
> those OPPs are not going to change.

So I tried, and found out that it will not be so easy. Different boards
have different regulators, and linux doesn't deal well with voltages
that are not supported by the regulator.

So even if the board can run at certain frequency if you round the
voltage to the next higher voltage supported by the regulator, opp
implementation doesn't do the rounding and just drops the operating
points that have no support in the voltage regulator.

We have boards that have 1.1/1.3V switching, only 1.3V, fine tuned
voltage regulation and every such board will need it's own set of
operating points.

I'd leave the OPP definitions in the board files for now.

cpu cpu0: _opp_add: OPP not supported by regulators (136800)
core: _opp_supported_by_regulators: OPP minuV: 134 maxuV: 134,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (134400)
core: _opp_supported_by_regulators: OPP minuV: 134 maxuV: 134,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (129600)
core: _opp_supported_by_regulators: OPP minuV: 120 maxuV: 120,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (110400)
core: _opp_supported_by_regulators: OPP minuV: 114 maxuV: 114,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (100800)

regards,
  o.

> Maxime
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 21.7.2016 11:48, Maxime Ripard wrote:
> On Fri, Jul 15, 2016 at 12:38:54PM +0200, Ondřej Jirman wrote:
>> On 15.7.2016 10:53, Maxime Ripard wrote:
>>> On Fri, Jul 01, 2016 at 02:50:57AM +0200, Ondřej Jirman wrote:
>>>>>>  /**
>>>>>> + * sun8i_h3_apply_pll1_factors() - applies n, k, m, p factors to the
>>>>>> + * register using an algorithm that tries to reserve the PLL lock
>>>>>> + */
>>>>>> +
>>>>>> +static void sun8i_h3_apply_pll1_factors(struct clk_factors *factors, 
>>>>>> struct factors_request *req)
>>>>>> +{
>>>>>> +const struct clk_factors_config *config = factors->config;
>>>>>> +u32 reg;
>>>>>> +
>>>>>> +/* Fetch the register value */
>>>>>> +reg = readl(factors->reg);
>>>>>> +
>>>>>> +if (FACTOR_GET(config->pshift, config->pwidth, reg) < req->p) {
>>>>>> +reg = FACTOR_SET(config->pshift, config->pwidth, reg, 
>>>>>> req->p);
>>>>>> +
>>>>>> +writel(reg, factors->reg);
>>>>>> +__delay(2000);
>>>>>> +}
>>>>>
>>>>> So there was some doubts about the fact that P was being used, or at
>>>>> least that it was useful.
>>>>
>>>> p is necessary to reduce frequencies below 288 MHz according to the
>>>> datasheet.
>>>
>>> Yes, but you could reach those frequencies without P, too, and it's
>>> not part of any OPP provided by Allwinner.
>>
>> The arisc firmware for H3 contains table of factors for frequences from
>> 0 to 2GHz and, P is used below 240MHz. M is never used, BTW. (other
>> datasheets specify M as for testing use only, whatever that means - not
>> H3, but it seems it's the same PLL block)
> 
> Interesting. Which SoCs in particular?
> 
>>>>>> +if (FACTOR_GET(config->mshift, config->mwidth, reg) < req->m) {
>>>>>> +reg = FACTOR_SET(config->mshift, config->mwidth, reg, 
>>>>>> req->m);
>>>>>> +
>>>>>> +writel(reg, factors->reg);
>>>>>> +__delay(2000);
>>>>>> +}
>>>>>> +
>>>>>> +reg = FACTOR_SET(config->nshift, config->nwidth, reg, req->n);
>>>>>> +reg = FACTOR_SET(config->kshift, config->kwidth, reg, req->k);
>>>>>> +
>>>>>> +writel(reg, factors->reg);
>>>>>> +__delay(20);
>>>>>> +
>>>>>> +while (!(readl(factors->reg) & (1 << config->lock)));
>>>>>
>>>>> So, they are applying the dividers first, and then applying the
>>>>> multipliers, and then wait for the PLL to stabilize.
>>>>
>>>> Not exactly, first we are increasing dividers if the new dividers are
>>>> higher that that what's already set. This ensures that because
>>>> application of dividers is immediate by the design of the PLL, the
>>>> application of multipliers isn't. So the VCO would still run at the same
>>>> frequency for a while gradually rising to a new value for example,
>>>> while the dividers would be reduced immediately. Leading to crash.
>>>>
>>>> PLL
>>>> --
>>>> PRE DIV(f0) -> VCO(f1) -> POST DIV(f2)
>>>>P K,N   M
>>>>
>>>> Example: (we set all factors at once, reducing dividers and multipliers
>>>> at the same time at 0ms - this should lead to no change in the output
>>>> frequency, but...)
>>>>
>>>> -1ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz
>>>>  0ms: f0 = 24MHz, f1 = 2GHz,   f2 = 2GHz   - boom
>>>>  1ms: f0 = 24MHz, f1 = 1.5GHz, f2 = 1.5GHz
>>>>  2ms: f0 = 24MHz, f1 = 1GHz,   f2 = 1GHz
>>>>
>>>> The current code crashes exactly at boom, you don't get any more
>>>> instructions to execute.
>>>>
>>>> See.
>>>>
>>>> So this patch first increases dividers (only if necessary), changes
>>>> multipliers and waits for change to happen (takes around 2000 cycles),
>>>

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

Hello Michal,

On 30.6.2016 13:13, Michal Suchanek wrote:
> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
>> From: Ondrej Jirman 
>>
>> Use Xulong Orange Pi One GPIO based regulator for
>> passive cooling and thermal management.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>> +
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index b1bd6b0..a38d871 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -109,6 +109,45 @@
>> };
>>  };
>>
>> +&cpu0 {
>> +   operating-points = <
>> +   /* kHzuV */
>> +   1296000 130
>> +   120 130
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

I've identified the problem as incorrectly set up gpio-regulator. During
boot, when it was probed, it would be initiualized with 1.1V for a
moment. This caused random non-specific lockups/crashes afterwards.

Fixed patches are in my branch on github, if you want to try again.

  https://github.com/megous/linux/commits/orange-pi-4.7

regards,
  o.

> Thanks
> 
> Michal
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 26.7.2016 08:32, Maxime Ripard wrote:
> On Thu, Jul 21, 2016 at 11:52:15AM +0200, Ondřej Jirman wrote:
>>>>> If so, then yes, trying to switch to the 24MHz oscillator before
>>>>> applying the factors, and then switching back when the PLL is stable
>>>>> would be a nice solution.
>>>>>
>>>>> I just checked, and all the SoCs we've had so far have that
>>>>> possibility, so if it works, for now, I'd like to stick to that.
>>>>
>>>> It would need to be tested. U-boot does the change only once, while the
>>>> kernel would be doing it all the time and between various frequencies
>>>> and PLL settings. So the issues may show up with this solution too.
>>>
>>> That would have the benefit of being quite easy to document, not be a
>>> huge amount of code and it would work on all the CPUs PLLs we have so
>>> far, so still, a pretty big win. If it doesn't, of course, we don't
>>> really have the choice.
>>
>> It's probably more code though. It has to access different register from
>> the one that is already defined in dts, which would add a lot of code
>> and require dts changes. The original patch I sent is simpler than that.
> 
> Why?

Because I don't understand internals of clk subsystem that much. :) So
my guess might be wrong.

Wens send patches implementing clock source switching in the new CCU
code, so hopefully it will work. Ultimately it's a hack. Some internal
parts of the soc may still get into out of the bounds operating state
even if they are gated off from other parts of the SoC, via clock
multiplexing, by improper factors change procedure.

So it doesn't really matter which is more concise in code. As long as
one solution is wrong and other is proper.

Anyway, I'll try with wens's patches, later and see if I trigger some
instability or not.

> You can use container_of to retrieve the parent structure of the clock
> notifier, and then you get a ccu_common structure pointer, with the
> CCU base address, the clock register, its lock, etc.
> 
> Look at what is done in drivers/clk/meson/clk-cpu.c. It's like 20 LoC.
> 
> I don't really get why anything should be changed in the DT, or why it
> would add a lot of code. Or maybe we're not talking about the same
> thing?
> 
> Maxime
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: Changed: sunxi-ng clock code - NKMP clock implementation is wrong

[Ondřej Jirman]

Hi Maxime,

I don't have your sunxi-ng clock patches in my mailbox, so I'm replying
to this.

On 26.7.2016 08:32, Maxime Ripard wrote:
> On Thu, Jul 21, 2016 at 11:52:15AM +0200, Ondřej Jirman wrote:
>>>>> If so, then yes, trying to switch to the 24MHz oscillator before
>>>>> applying the factors, and then switching back when the PLL is stable
>>>>> would be a nice solution.
>>>>>
>>>>> I just checked, and all the SoCs we've had so far have that
>>>>> possibility, so if it works, for now, I'd like to stick to that.
>>>>
>>>> It would need to be tested. U-boot does the change only once, while the
>>>> kernel would be doing it all the time and between various frequencies
>>>> and PLL settings. So the issues may show up with this solution too.
>>>
>>> That would have the benefit of being quite easy to document, not be a
>>> huge amount of code and it would work on all the CPUs PLLs we have so
>>> far, so still, a pretty big win. If it doesn't, of course, we don't
>>> really have the choice.
>>
>> It's probably more code though. It has to access different register from
>> the one that is already defined in dts, which would add a lot of code
>> and require dts changes. The original patch I sent is simpler than that.
> 
> Why?
> 
> You can use container_of to retrieve the parent structure of the clock
> notifier, and then you get a ccu_common structure pointer, with the
> CCU base address, the clock register, its lock, etc.
> 
> Look at what is done in drivers/clk/meson/clk-cpu.c. It's like 20 LoC.
> 
> I don't really get why anything should be changed in the DT, or why it
> would add a lot of code. Or maybe we're not talking about the same
> thing?

I've looked at the new CCU code, particularly ccu_nkmp.c, and found that
it very liberally uses divider parameters, even in situations that are
out of spec compared to the current code in the kernel.

In the current code and especially in the original vendor code, divider
parameters are used as last resort only. Presumably because, of the
inherent trouble in changing them, as I described to you in other email.

The new ccu code uses dividers often and even at very high frequencies,
which goes against the spec.

In the vendor code M is never anything else but 0, and P is used only
for frequencies below 288MHz, which matches the H3 datasheet, which says:

"The P factor only use in the condition that PLL output less than 288
MHz."

Also other datasheets of similar socs from Allwinner state that M should
not be used in production code. So it may be that they either forgot to
state it in the H3 datasheet, or it can be used. In any case, they never
use M in their code, so it may be wise to keep to that.

When I boot with the new CCU code I get this:

PLL_CPUX = 0x1B21 : M = 2, K = 3, N = 28, P = 1, EN = 0
PLL_CPUX : freq = 1008MHz

Mathematically it works, but it is against the spec.

Also, this:

analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 1.74 ms
  hardware limits: 120 MHz - 1.37 GHz
  available frequency steps:  120 MHz, 240 MHz, 480 MHz, 648 MHz, 816
MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22
GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz
  available cpufreq governors: conservative ondemand userspace powersave
performance
  current policy: frequency should be within 240 MHz and 240 MHz.
  The governor "performance" may decide which speed to use
  within this range.
  current CPU frequency: 24.0 MHz (asserted by call to hardware)


Somehow, the new CCU code sets the CPUX to 24MHz no matter what.

I'm using your pen/clk-rework branch without any other patches that were
later sent to the mailing list.

regards,
  Ondrej

> 
> Maxime
> 

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: Changed: sunxi-ng clock code - NKMP clock implementation is wrong

[Ondřej Jirman]

On 28.7.2016 23:00, Maxime Ripard wrote:
> Hi Ondrej,
> 
> On Thu, Jul 28, 2016 at 01:27:05PM +0200, Ondřej Jirman wrote:
>> Hi Maxime,
>>
>> I don't have your sunxi-ng clock patches in my mailbox, so I'm replying
>> to this.
> 
> You can find it in the clock maintainers tree:
> https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/log/?h=clk-sunxi-ng
> 
>> On 26.7.2016 08:32, Maxime Ripard wrote:
>>> On Thu, Jul 21, 2016 at 11:52:15AM +0200, Ondřej Jirman wrote:
>>>>>>> If so, then yes, trying to switch to the 24MHz oscillator before
>>>>>>> applying the factors, and then switching back when the PLL is stable
>>>>>>> would be a nice solution.
>>>>>>>
>>>>>>> I just checked, and all the SoCs we've had so far have that
>>>>>>> possibility, so if it works, for now, I'd like to stick to that.
>>>>>>
>>>>>> It would need to be tested. U-boot does the change only once, while the
>>>>>> kernel would be doing it all the time and between various frequencies
>>>>>> and PLL settings. So the issues may show up with this solution too.
>>>>>
>>>>> That would have the benefit of being quite easy to document, not be a
>>>>> huge amount of code and it would work on all the CPUs PLLs we have so
>>>>> far, so still, a pretty big win. If it doesn't, of course, we don't
>>>>> really have the choice.
>>>>
>>>> It's probably more code though. It has to access different register from
>>>> the one that is already defined in dts, which would add a lot of code
>>>> and require dts changes. The original patch I sent is simpler than that.
>>>
>>> Why?
>>>
>>> You can use container_of to retrieve the parent structure of the clock
>>> notifier, and then you get a ccu_common structure pointer, with the
>>> CCU base address, the clock register, its lock, etc.
>>>
>>> Look at what is done in drivers/clk/meson/clk-cpu.c. It's like 20 LoC.
>>>
>>> I don't really get why anything should be changed in the DT, or why it
>>> would add a lot of code. Or maybe we're not talking about the same
>>> thing?
>>
>> I've looked at the new CCU code, particularly ccu_nkmp.c, and found that
>> it very liberally uses divider parameters, even in situations that are
>> out of spec compared to the current code in the kernel.
>>
>> In the current code and especially in the original vendor code, divider
>> parameters are used as last resort only. Presumably because, of the
>> inherent trouble in changing them, as I described to you in other email.
>>
>> The new ccu code uses dividers often and even at very high frequencies,
>> which goes against the spec.
>>
>> In the vendor code M is never anything else but 0, and P is used only
>> for frequencies below 288MHz, which matches the H3 datasheet, which says:
> 
> In the vendor code, P is never used either. All the boards we had so
> far don't go that low, so we cannot make any of these assumptions,
> especially since the vendor code has had the bad habit of doing
> something wrong and / or useless in the past.

P is used in the arisc firmware according to the spec for the lower
frequencies.

> However, this implementation is a new thing, and it was using the H3
> precisely because of its early stage of support to use it as a testbed
> for the more established.
> 
> If you feel like we should use a different formula to favour the
> multipliers over the dividers (or want to change the class of the CPU
> PLL to an NKM or something else, this is totally doable.

I think the original formula that's currently in the mainline kernel is
better and avoids fiddling with dividers too much.

>> "The P factor only use in the condition that PLL output less than 288
>> MHz."
> 
> And the datasheet also had some issues, either misleading or wrong
> comments in the past. Don't get me wrong, I'm not saying that this is
> wrong, just that we should not follow it religiously, and that we
> should trust more the experiments than the datasheet.

I can believe that. :) Regardless, I think the reasons given for
avoiding dividers are quite reasonable. It's based on how PLL block
works, not what manual says.

>> Also other datasheets of similar socs from Allwinner state that M should
>> not be used in production code.
> 
> Which ones specifically?

A83T for example. You can search for "only for test&

[linux-sunxi] Re: Changed: sunxi-ng clock code - NKMP clock implementation is wrong

[Ondřej Jirman]

Hi,

On 31.7.2016 12:31, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Jul 29, 2016 at 12:01:09AM +0200, Ondřej Jirman wrote:
>> On 28.7.2016 23:00, Maxime Ripard wrote:
>>> Hi Ondrej,
>>>
>>> On Thu, Jul 28, 2016 at 01:27:05PM +0200, Ondřej Jirman wrote:
>>>> Hi Maxime,
>>>>
>>>> I don't have your sunxi-ng clock patches in my mailbox, so I'm replying
>>>> to this.
>>>
>>> You can find it in the clock maintainers tree:
>>> https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/log/?h=clk-sunxi-ng
>>>
>>>> On 26.7.2016 08:32, Maxime Ripard wrote:
>>>>> On Thu, Jul 21, 2016 at 11:52:15AM +0200, Ondřej Jirman wrote:
>>>>>>>>> If so, then yes, trying to switch to the 24MHz oscillator before
>>>>>>>>> applying the factors, and then switching back when the PLL is stable
>>>>>>>>> would be a nice solution.
>>>>>>>>>
>>>>>>>>> I just checked, and all the SoCs we've had so far have that
>>>>>>>>> possibility, so if it works, for now, I'd like to stick to that.
>>>>>>>>
>>>>>>>> It would need to be tested. U-boot does the change only once, while the
>>>>>>>> kernel would be doing it all the time and between various frequencies
>>>>>>>> and PLL settings. So the issues may show up with this solution too.
>>>>>>>
>>>>>>> That would have the benefit of being quite easy to document, not be a
>>>>>>> huge amount of code and it would work on all the CPUs PLLs we have so
>>>>>>> far, so still, a pretty big win. If it doesn't, of course, we don't
>>>>>>> really have the choice.
>>>>>>
>>>>>> It's probably more code though. It has to access different register from
>>>>>> the one that is already defined in dts, which would add a lot of code
>>>>>> and require dts changes. The original patch I sent is simpler than that.
>>>>>
>>>>> Why?
>>>>>
>>>>> You can use container_of to retrieve the parent structure of the clock
>>>>> notifier, and then you get a ccu_common structure pointer, with the
>>>>> CCU base address, the clock register, its lock, etc.
>>>>>
>>>>> Look at what is done in drivers/clk/meson/clk-cpu.c. It's like 20 LoC.
>>>>>
>>>>> I don't really get why anything should be changed in the DT, or why it
>>>>> would add a lot of code. Or maybe we're not talking about the same
>>>>> thing?
>>>>
>>>> I've looked at the new CCU code, particularly ccu_nkmp.c, and found that
>>>> it very liberally uses divider parameters, even in situations that are
>>>> out of spec compared to the current code in the kernel.
>>>>
>>>> In the current code and especially in the original vendor code, divider
>>>> parameters are used as last resort only. Presumably because, of the
>>>> inherent trouble in changing them, as I described to you in other email.
>>>>
>>>> The new ccu code uses dividers often and even at very high frequencies,
>>>> which goes against the spec.
>>>>
>>>> In the vendor code M is never anything else but 0, and P is used only
>>>> for frequencies below 288MHz, which matches the H3 datasheet, which says:
>>>
>>> In the vendor code, P is never used either. All the boards we had so
>>> far don't go that low, so we cannot make any of these assumptions,
>>> especially since the vendor code has had the bad habit of doing
>>> something wrong and / or useless in the past.
>>
>> P is used in the arisc firmware according to the spec for the lower
>> frequencies.
> 
> Yes, but has anyone actually tested those frequencies? Judging from
> the FEX files I could gather, cpufreq never actually goes lower than
> 480 MHz.
> 

I tested it. It works well down to 60MHz. You can even run on 24MHz if
you run directly from 24mhz osc. It's terribly slow, but it works ok.

I've rebased my working branch over the mainline kernel, which now
contains the sunxi-ng, and tested it. Cpufreq seems to work on orange pi
pc without any changes discussed in this thread. I didn't do any
extensive testing though. But it doesn't hang on boot or cpufreq config
changes.

You can see it here

Re: [linux-sunxi] Help getting I2C to work on sun8i-h3 on linux 4.8

[Ondřej Jirman]

Hi,

I think you may be hitting this issue:

  https://lkml.org/lkml/2016/8/26/150

regards,
  Ondrej

Dne 27.8.2016 v 00:07 Paulo Costa napsal(a):
> Hello, folks.
> 
> It's my first time working with this, please let me know if this isn't
> the right mailing list or not the right way to ask for help. 
> 
> I'm using an Orange Pi PC (sun8i-h3), with a Linux 4.8-rc3.
> I'm trying to enable it's I2C ports, but I haven't had any success yet.
> 
> Martin Ayotte's patch
> (https://groups.google.com/forum/#!topic/linux-sunxi/gd7S3meEAZM) worked
> fine on 4.7.
> I'm trying to convert it to the linux 4.8
> (https://github.com/paulo-raca/linux/commit/d32f1687b3fc21ab30388862f1737c69daef6aff
> -- It mostly involved replacing clocks and resets with the
> new sun8i-h3-ccu).
> Although the I2C ports are registered, whenever I try to access them I
> get this error:
> 
> i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0
> 
> I've been stuck at it for a few days, but I've made no progress. Am I
> missing something? Any suggestions?
> 
> Thank you
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to linux-sunxi+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v5 0/7] ARM: ASoC: drm: sun8i: Add DE2 HDMI audio and video

[Ondřej Jirman]

Dne 22.10.2016 v 15:28 Jean-Francois Moine napsal(a):
> This patchset series adds HDMI audio and video support to the Allwinner
> sun8i SoCs which include the display engine 2 (DE2).

Hi,

I've tested your patches on top of my 4.9-rc1 changes on Orange Pi PC,
and HDMI display output works well -- with some changes to sunxi-ng H3
clock driver. I've put those changes here:

  https://github.com/megous/linux/commits/orange-pi-4.9-hdmi

When I run firefox, it feels faster and less laggy than armbian 3.4
desktop. Very nice!

The only issue that I've found, is that clk setup for ASoC driver fails
with EINVAL.

When I run pulseaudio, dmesg is filled with this:

[   29.951468] sun8i-audio 1c22800.i2s: ASoC: can't set 1c22800.i2s hw
params: -22
[   29.969184] Setting sysclk rate failed -22
[   29.982440] sun8i-audio 1c22800.i2s: ASoC: can't set 1c22800.i2s hw
params: -22
[   30.000148] Setting sysclk rate failed -22
[   30.013398] sun8i-audio 1c22800.i2s: ASoC: can't set 1c22800.i2s hw
params: -22
[   30.032790] Setting sysclk rate failed -22
[   30.044411] sun8i-audio 1c22800.i2s: ASoC: can't set 1c22800.i2s hw
params: -22
[   30.062252] Setting sysclk rate failed -22

What do you base your patches on? Do you have some patches for the
sunxi-ng H3 clock driver that are required for this to work?

thank you and regards,
  o.

> A first submission in January for video on the H3 could not enter into
> the mainline kernel due to the lack of license headers in Allwinner's
> sources.
> 
> Recently, an announce about Tina OS for the R series
>   https://www.youtube.com/watch?v=h7KD-6HblAU
> was followed by the upload of a new linux-3.4 source tree
>   https://github.com/tinalinux/linux-3.4
> with files containing GPL headers.
> 
> Well, I don't know if these sources are really from Allwinner, but
> anyway, this is the opportunity to propose a new version of my DRM
> HDMI driver.
> 
> v5:
>   - add overlay plane
>   - add audio support
>   - add support for the A83T
>   - add back the HDMI driver
>   - many bug fixes
> v4: 
>   - drivers/clk/sunxi/Makefile was missing (Emil Velikov)
> v3:
>   - add the hardware cursor
>   - simplify and fix the DE2 init sequences
>   - generation for all SUNXI SoCs (Andre Przywara)
> v2:
>   - remove the HDMI driver
>   - remarks from Chen-Yu Tsai and Russell King
>   - DT documentation added
> 
> Jean-Francois Moine (7):
>   drm: sunxi: Add a basic DRM driver for Allwinner DE2
>   ASoC: sunxi: Add a simple HDMI CODEC
>   drm: sunxi: add DE2 HDMI support
>   ASoC: sunxi: Add sun8i I2S driver
>   ARM: dts: sun8i-h3: add HDMI audio and video nodes
>   ARM: dts: sun8i-h3: Add HDMI audio and video to the Banana Pi M2+
>   ARM: dts: sun8i-h3: Add HDMI audio and video to the Orange PI 2
> 
>  .../devicetree/bindings/display/sunxi/hdmi.txt |  52 ++
>  .../bindings/display/sunxi/sunxi-de2.txt   |  83 ++
>  .../devicetree/bindings/sound/sun4i-i2s.txt|  38 +-
>  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  17 +
>  arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  17 +
>  arch/arm/boot/dts/sun8i-h3.dtsi|  67 ++
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/sunxi/Kconfig  |  29 +
>  drivers/gpu/drm/sunxi/Makefile |   9 +
>  drivers/gpu/drm/sunxi/de2_crtc.c   | 475 +++
>  drivers/gpu/drm/sunxi/de2_crtc.h   |  63 ++
>  drivers/gpu/drm/sunxi/de2_de.c | 591 +
>  drivers/gpu/drm/sunxi/de2_drm.h|  47 ++
>  drivers/gpu/drm/sunxi/de2_drv.c| 378 +
>  drivers/gpu/drm/sunxi/de2_hdmi.c   | 396 +
>  drivers/gpu/drm/sunxi/de2_hdmi.h   |  40 +
>  drivers/gpu/drm/sunxi/de2_hdmi_io.c| 927 
> +
>  drivers/gpu/drm/sunxi/de2_hdmi_io.h|  25 +
>  drivers/gpu/drm/sunxi/de2_plane.c  | 119 +++
>  include/sound/sunxi_hdmi.h |  23 +
>  sound/soc/codecs/Kconfig   |   9 +
>  sound/soc/codecs/Makefile  |   2 +
>  sound/soc/codecs/sunxi-hdmi.c  | 106 +++
>  sound/soc/sunxi/Kconfig|   8 +
>  sound/soc/sunxi/Makefile   |   3 +
>  sound/soc/sunxi/sun8i-i2s.c| 700 
>  27 files changed, 4222 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
>  create mode 100644 drivers/gpu/drm/sunxi/Kconfig
>  create mode 100644 drivers/gpu/drm/sunxi/Makefile
>  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
>  create mode 100644 drivers/gpu/drm/sunxi/de2_crt

Re: [linux-sunxi] [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu

[Ondřej Jirman]

Dne 24.10.2016 v 05:59 Icenowy Zheng napsal(a):
> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
> The code that poke some unknown bit of PMU for H3/A64 didn't check
> the PHY, and will cause kernel oops when PHY 0 is used.
> 
> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/phy/phy-sun4i-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b9342a2..ff8e9dd 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> - if (data->cfg->enable_pmu_unk1) {
> + if (phy->index != 0 && data->cfg->enable_pmu_unk1) {

It might be better to check for phy->pmu directly.

regards,
  o.
>   val = readl(phy->pmu + REG_PMU_UNK1);
>   writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>   }
> 



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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] Mainline stability (overvolting/undervolting) etc. (u-boot/linux)

[Ondřej Jirman]

Dne 1.11.2016 v 00:55 Rune Petersen napsal(a):
> On 25/10/16 16:36, Olliver Schinagl wrote:
>> Hey all,
>>
>> as some of you are probably aware, some users occasionally experience
>> some
>> instability using the mainline components. I specifically only want to
>> focus on
>> mainline, as with the 3.4 stuff ... well lets just not even go there.
>>
>> [TL;DR] We should offer the user a stable u-boot/kernel combo. Playing
>> with
>> frequencies/voltages is up to the user (via overlay etc).
>>
>> So stability. First in case you haven't heard we released our product,
>> the
>> Ultimaker 3, which features an Olimex Lime2 board. During the past
>> development
>> year we noticed some stability issues but haven't pinpointed the exact
>> cause.
>>
>> For example, we noticed quite some stability problems with the ondemand
>> governor, especially as it was running on the medium ranges. Switching to
>> performance fixed this mostly for us, but we do very seldom still see
>> a crash.
>>
>> With olimex change request on the 11th of oktober to lower the memory
>> freq. [0],
>> we seem to have atleast some form of confirmation that there really is a
>> stability problem for others as well. With that request, they lowered
>> the DRAM
>> frequency of their A20 boards.
>>
>> Does that solve the stability? Or does that also reduce the failure
>> rate to be
>> less noticeable.
>>
>> Or are both a problem, cpu voltage/freq and dram freq.
>>
>> I think it is fair to say, before writing the next paragraph, that the
>> defaults
>> users get from mainline components should be rock solid and stable.
>> Playing with
>> settings is fine for a user to do, but the defaults should be solid.
>>
>> So one, is to investigate the memory claims of Olimex. Even lowering the
>> frequency to 384 MHz may not be as stable as some expect, but I'm sure
>> ssvb can
>> pitch in here :)
>>
>> Secondly, are our operating points sane and safe? For example this
>> patch [1]
>> from the banana-pi folks increased the voltages of the middle
>> frequencies. Now
>> this could have been because of two reasons, and unfortunately the
>> patch does
>> not mention this clearly. A larger user base found issues here and
>> changed it to
>> solve the issues. Or the banana-pi has a bad board design, where the
>> requested
>> voltage does not reach the SoC, and thus needs some compensation. If
>> the later
>> is the case, a comment in the dts should have been added and the
>> commit message
>> should have stated this.
>>
>> Since however, some people notice the same problem on other boards,
>> this may not
>> be a board routing issue. Anyway, we are just guessing in that regard
>> now.
>>
>> Digging a little deeper, what strikes me as odd, is that Allwinner
>> says in the
>> A20 datasheet, that 1.4V is the maximum recommended voltage for the
>> SoC, yet we
>> have 2 frequencies that operate on 1.4v. This, to me, indicates something
>> strange. Either 960 MHz is stable at 1.4 and thus the 912 Mhz voltage
>> should be
>> lower, or the 960 Mhz is slightly undervolted.
>>
>> We do not have reliable data from Allwinner, and we don't have the
>> resources to
>> properly test many boards to determine stable operating points. But by
>> going
>> with somewhat less reliable operating data from the Allwinner code
>> drop [2], we
>> see a different picture that is in the current dts.
>>
>> Here the voltage-frequencies match much closer to what bananapi is using.
>>
>> So what to do with our limited resources?
>>
>> Well over the next 2 weeks I will try to test as many lime2 boards
>> with various
>> settings and various benchmarks to get some more numbers here.
>> Depending on my
>> findings some changes will emerge. But even then, we'll have a small
>> sample size
>> as my resources and time is limited.
>>
>> For one, we know that 1.4 volt is the maximum voltage for the SoC. So
>> lets make
>> sure to not go over that. Further more, lowering the voltage on lower
>> frequencies is a power saving measure in our case. So having slightly
>> higher
>> voltages is not horrible.
>>
>> I think it is safe to say, that we should use the higher voltage for
>> the lower
>> frequencies between the Allwinner 3.4 reference code [2] and the
>> bananapi table
>> [1]. This should, in theory, yield a stable range of operating points.
>>
>> If someone has hard evidence that a large set of samples works
>> stability with
>> modified settings, we can always adopt this. But stability should be
>> our primary
>> concern.
>>
>> As for the DRAM frequencies, this is a little bit harder I think, but
>> even here,
>> we need to have fully stable settings, and not just 'lets just go a
>> bit lower
>> and it should be fine'.
>>
>> [0] https://patchwork.ozlabs.org/patch/680990/
>> [1]
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=a15b80fb0ad7ddab8d2668392cce3c12aff594bd
>>
>>
>> [2] http://linux-sunxi.org/A20#DVFS
>>
> 
> Some time ago I play

Re: [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support

[Ondřej Jirman]

Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
> This patchset series adds HDMI video support to the Allwinner
> sun8i SoCs which include the display engine 2 (DE2).
> The driver contains the code for the A83T and H3, but it could be
> used/extended for other SoCs as the A64, H2 and H5.

Hi,

I'm trying to test your patches on Orange Pi PC, and I've run into a few
issues: (I'm using sunxi-ng with the same patches as last time, to make
it work with your driver)

1] I just get pink output on the monitor - there's some signal, but it's
pink (or more like magenta).

dmesg ouput indicates no error:

[1.887823] [drm] Initialized
[1.888503] sun8i-de2 100.de-controller: bound
1c0c000.lcd-controller (ops 0xc0a63894)
[2.057298] sun8i-de2 100.de-controller: bound 1ee.hdmi (ops
0xc0a63b54)
[2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.057307] [drm] No driver support for vblank timestamp query.
[2.690862] Console: switching to colour frame buffer device 240x67
[2.723059] sun8i-de2 100.de-controller: fb0:  frame buffer device

> 
> v6:
>   - remove audio support (other patchset to come)
>   - use DRM modeset data for HDMI configuration
>   (thanks to Jernej Škrabec)
>   - more meaningfull register names
>   - use a mutex for DE I/O protection
>   - merge DE and plane into one file
>   - don't activate the video hardware when video not started
>   (Maxime Ripard)
>   - remove 'type = "video" in DT graph ports
>   (Rob Herring)
>   - change the I/O accesses by #define instead of struct
>   (Maxime Ripard, André Przywara)
>   - remove pm functions (Maxime Ripard)
>   - set the pll-de/de clocks in the DT (Maxime Ripard)

This change triggers this dmesg output I suppose:

[0.00] bad: scheduling from the idle thread!
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.9.0-rc6-00045-g5347f96 #29
[0.00] Hardware name: Allwinner sun8i Family
[0.00] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from []
(dump_stack+0x84/0x98)
[0.00] [] (dump_stack) from []
(dequeue_task_idle+0x34/0x40)
[0.00] [] (dequeue_task_idle) from []
(__schedule+0x244/0x52c)
[0.00] [] (__schedule) from []
(schedule+0x44/0x9c)
[0.00] [] (schedule) from []
(schedule_hrtimeout_range_clock+0xc4/0x138)
[0.00] [] (schedule_hrtimeout_range_clock) from
[] (schedule_hrtimeout_range+0x18/0x20)
[0.00] [] (schedule_hrtimeout_range) from []
(usleep_range+0x4c/0x54)
[0.00] [] (usleep_range) from []
(ccu_helper_wait_for_lock+0x58/0xc8)
[0.00] [] (ccu_helper_wait_for_lock) from []
(ccu_nm_set_rate+0x124/0x148)
[0.00] [] (ccu_nm_set_rate) from []
(clk_change_rate+0x194/0x248)
[0.00] [] (clk_change_rate) from []
(clk_core_set_rate_nolock+0x68/0xb0)
[0.00] [] (clk_core_set_rate_nolock) from []
(clk_set_rate+0x20/0x30)
[0.00] [] (clk_set_rate) from []
(of_clk_set_defaults+0x1fc/0x334)
[0.00] [] (of_clk_set_defaults) from []
(of_clk_add_hw_provider+0x74/0x9c)
[0.00] [] (of_clk_add_hw_provider) from []
(sunxi_ccu_probe+0xa8/0x130)
[0.00] [] (sunxi_ccu_probe) from []
(of_clk_init+0x15c/0x1e8)
[0.00] [] (of_clk_init) from []
(sun6i_timer_init+0xc/0x18)
[0.00] [] (sun6i_timer_init) from []
(start_kernel+0x248/0x398)
[0.00] [] (start_kernel) from [<4000807c>] (0x4000807c)
[0.00] arm_arch_timer: Architected cp15 timer(s) running at
24.00MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff
max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:179
sched_clock_register+0x44/0x1dc
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.9.0-rc6-00045-g5347f96 #29
[0.00] Hardware name: Allwinner sun8i Family
[0.00] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from []
(dump_stack+0x84/0x98)
[0.00] [] (dump_stack) from []
(__warn+0xe0/0xfc)
[0.00] [] (__warn) from []
(warn_slowpath_null+0x20/0x28)
[0.00] [] (warn_slowpath_null) from []
(sched_clock_register+0x44/0x1dc)
[0.00] [] (sched_clock_register) from []
(arch_timer_common_init+0x204/0x22c)
[0.00] [] (arch_timer_common_init) from []
(arch_timer_of_init+0x2e4/0x310)
[0.00] [] (arch_timer_of_init) from []
(clocksource_probe+0x58/0xac)
[0.00] [] (clocksource_probe) from []
(start_kernel+0x248/0x398)
[0.00] [] (start_kernel) from [<4000807c>] (0x4000807c)
[0.00] ---[ end trace  ]---
[0.04] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps
every 4398046511097ns
[0.10] Switching to timer-based delay loop, resolution 41ns
[0.000139] clocksource: timer: 

Re: [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support

[Ondřej Jirman]

Dne 21.11.2016 v 19:14 Jean-Francois Moine napsal(a):
> On Mon, 21 Nov 2016 01:54:53 +0100
> Ondřej Jirman  wrote:
> 
>> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
>>> This patchset series adds HDMI video support to the Allwinner
>>> sun8i SoCs which include the display engine 2 (DE2).
>>> The driver contains the code for the A83T and H3, but it could be
>>> used/extended for other SoCs as the A64, H2 and H5.
>>
>> Hi,
>>
>> I'm trying to test your patches on Orange Pi PC, and I've run into a few
>> issues: (I'm using sunxi-ng with the same patches as last time, to make
>> it work with your driver)
>>
>> 1] I just get pink output on the monitor - there's some signal, but it's
>> pink (or more like magenta).
>>
>> dmesg ouput indicates no error:
>>
>> [1.887823] [drm] Initialized
>> [1.888503] sun8i-de2 100.de-controller: bound
>> 1c0c000.lcd-controller (ops 0xc0a63894)
>> [2.057298] sun8i-de2 100.de-controller: bound 1ee.hdmi (ops
>> 0xc0a63b54)
>> [2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [2.057307] [drm] No driver support for vblank timestamp query.
>> [2.690862] Console: switching to colour frame buffer device 240x67
>> [2.723059] sun8i-de2 100.de-controller: fb0:  frame buffer device
>   [snip]
> 
> My H3 boards work correctly, except the Orange PI 2 when it cannot read
> the EDID (but it is OK after reboot).
> 
> Did you check if the EDID was correctly read?

EDID is correctly read (I verified that it is the same as with the v5
version of the driver), but there's one difference I noted. v5 says dpms
is Off, while v6 says dpms is On.

> Which resolution do you expect?
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes

[Ondřej Jirman]

Dne 25.11.2016 v 06:27 Icenowy Zheng napsal(a):
> 
> 
> 20.11.2016, 20:07, "Jean-Francois Moine" :
>> Signed-off-by: Jean-Francois Moine 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 51 
>> +
>>  1 file changed, 51 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 416b825..7c6b1d5 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -140,6 +140,16 @@
>>  #size-cells = <1>;
>>  ranges;
>>
>> + de: de-controller@0100 {
>> + compatible = "allwinner,sun8i-h3-display-engine";
>> + reg = <0x0100 0x40>;
>> + clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>;
>> + clock-names = "bus", "clock";
>> + resets = <&ccu RST_BUS_DE>;
>> + ports = <&lcd0_p>;
>> + status = "disabled";
>> + };
>> +
>>  dma: dma-controller@01c02000 {
>>  compatible = "allwinner,sun8i-h3-dma";
>>  reg = <0x01c02000 0x1000>;
>> @@ -149,6 +159,23 @@
>>  #dma-cells = <1>;
>>  };
>>
>> + lcd0: lcd-controller@01c0c000 {
>> + compatible = "allwinner,sun8i-a83t-tcon";
>> + reg = <0x01c0c000 0x400>;
>> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
>> + clock-names = "bus", "clock";
>> + resets = <&ccu RST_BUS_TCON0>;
>> + interrupts = ;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + lcd0_p: port {
>> + lcd0_hdmi: endpoint {
>> + remote-endpoint = <&hdmi_lcd0>;
>> + };
>> + };
>> + };
>> +
>>  mmc0: mmc@01c0f000 {
>>  compatible = "allwinner,sun7i-a20-mmc";
>>  reg = <0x01c0f000 0x1000>;
>> @@ -314,6 +341,11 @@
>>  clock-names = "hosc", "losc";
>>  #clock-cells = <1>;
>>  #reset-cells = <1>;
>> +
>> + assigned-clocks = <&ccu CLK_PLL_DE>,
> 
> Cannot get the patch built on 4.9-rc, as CLK_PLL_DE is not an exported clock.
> 
> Only CLK_DE is exported.

Jean-Francois uses his own clk driver for h3. Check out this branch,
which contains his latest HDMI patches with necessary fixes for it to
work with sunxi-ng clk driver:

  https://github.com/megous/linux/commits/orange-pi-4.9

There are more issues, than just a missing CLK_DE macro. I'll probably
send the patches out soon.

regards,
  o.

>> + <&ccu CLK_DE>;
>> + assigned-clock-rates = <86400>,
>> + <43200>;
>>  };
>>
>>  pio: pinctrl@01c20800 {
>> @@ -564,6 +596,25 @@
>>  interrupts = > IRQ_TYPE_LEVEL_HIGH)>;
>>  };
>>
>> + hdmi: hdmi@01ee {
>> + compatible = "allwinner,sun8i-h3-hdmi";
>> + reg = <0x01ee 0x2>;
>> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
>> + <&ccu CLK_HDMI_DDC>;
>> + clock-names = "bus", "clock", "ddc-clock";
>> + resets = <&ccu RST_BUS_HDMI0>, <&ccu RST_BUS_HDMI1>;
>> + reset-names = "hdmi0", "hdmi1";
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 { /* video */
>> + reg = <0>;
>> + hdmi_lcd0: endpoint {
>> + remote-endpoint = <&lcd0_hdmi>;
>> + };
>> + };
>> + };
>> +
>>  rtc: rtc@01f0 {
>>  compatible = "allwinner,sun6i-a31-rtc";
>>  reg = <0x01f0 0x54>;
>> --
>> 2.10.2
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

[Ondřej Jirman]

Maxime,

Dne 25.11.2016 v 01:28 meg...@megous.com napsal(a):
> From: Ondrej Jirman 
> 
> When adjusting PLL_CPUX on H3, the PLL is temporarily driven
> too high, and the system becomes unstable (oopses or hangs).
> 
> Add a notifier to avoid this situation by temporarily switching
> to a known stable 24 MHz oscillator.

I have done more thorough testing on H3 and this approach with switching
to 24MHz oscillator does not work. Motivation being that my Orange Pi
One still gets lockups even with this patch under certain circumstances.

So I have created a small test program for CPUS (additional OpenRISC CPU
on the SoC) which randomly changes PLL_CPUX settings while main CPU is
running a loop that sends messages to CPUS via msgbox.

Assumption being that while CPUS is successfully receiving messages via
msgbox, the main CPU didn't lock up, yet.

With this I am able to quickly and thoroughly test various PLL_CPUX
change and factor selection algorithms.

Results are that bypassing CPUX clock by switching to 24 MHz oscillator
does not work at all. Main CPU locks up in about 1 second into the test.
Don't ask me why.

What works is selecting NKMP factors so that M is always 1 and P is
anything other than /1 only for frequencies under 288MHz. As mandated by
the H3 datasheet. Mainline ccu_nkmp_find_best doesn't respect these
conditions. With that I can change CPUX frequencies randomly 20x a
second so far indefinitely without the main CPU ever locking up.

Please drop or revert this patch. It is not a correct approach to the
problem. I'd suggest dropping the entire clock notifier mechanism, too,
unless it can be proven to work reliably. The bypass makes some
intuitive sense, but for some reason it doesn't work in practice (on H3
at least).

Aside from this, uboot also needs to be changed to set that it uses M
and P factors correctly.

Whatever else I try, I always hit lockups sooner or later with the test
program. I tried 24MHz bypass and staged application of multipliers and
dividers as discussed before.

I'll send a proper patch for nkmp clock driver and u-boot later.

regards,
  o.

> Signed-off-by: Ondrej Jirman 
> Tested-by: Lutz Sammer 
> ---
>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
> b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> index 614d47c..cf266c9 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> @@ -809,6 +809,13 @@ static const struct sunxi_ccu_desc sun8i_h3_ccu_desc = {
>   .num_resets = ARRAY_SIZE(sun8i_h3_ccu_resets),
>  };
>  
> +static struct ccu_mux_nb sun8i_h3_cpu_nb = {
> + .common = &cpux_clk.common,
> + .cm = &cpux_clk.mux,
> + .delay_us   = 1, /* > 8 clock cycles at 24 MHz */
> + .bypass_index   = 1, /* index of 24 MHz oscillator */
> +};
> +
>  static void __init sun8i_h3_ccu_setup(struct device_node *node)
>  {
>   void __iomem *reg;
> @@ -827,6 +834,9 @@ static void __init sun8i_h3_ccu_setup(struct device_node 
> *node)
>   writel(val | (3 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);
>  
>   sunxi_ccu_probe(node, reg, &sun8i_h3_ccu_desc);
> +
> + ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> +   &sun8i_h3_cpu_nb);
>  }
>  CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
>  sun8i_h3_ccu_setup);
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

[Ondřej Jirman]

Dne 9.1.2017 v 10:59 Maxime Ripard napsal(a):
> On Sat, Jan 07, 2017 at 04:49:18PM +0100, Ondřej Jirman wrote:
>> Maxime,
>>
>> Dne 25.11.2016 v 01:28 meg...@megous.com napsal(a):
>>> From: Ondrej Jirman 
>>>
>>> When adjusting PLL_CPUX on H3, the PLL is temporarily driven
>>> too high, and the system becomes unstable (oopses or hangs).
>>>
>>> Add a notifier to avoid this situation by temporarily switching
>>> to a known stable 24 MHz oscillator.
>>
>> I have done more thorough testing on H3 and this approach with switching
>> to 24MHz oscillator does not work. Motivation being that my Orange Pi
>> One still gets lockups even with this patch under certain circumstances.
>>
>> So I have created a small test program for CPUS (additional OpenRISC CPU
>> on the SoC) which randomly changes PLL_CPUX settings while main CPU is
>> running a loop that sends messages to CPUS via msgbox.
>>
>> Assumption being that while CPUS is successfully receiving messages via
>> msgbox, the main CPU didn't lock up, yet.
>>
>> With this I am able to quickly and thoroughly test various PLL_CPUX
>> change and factor selection algorithms.
>>
>> Results are that bypassing CPUX clock by switching to 24 MHz oscillator
>> does not work at all. Main CPU locks up in about 1 second into the test.
>> Don't ask me why.
> 
> You mean that you are changing the frequency behind Linux' back? That
> won't work. There's more to cpufreq than just changing the frequency,
> but also adusting the number of loops per jiffy for the new frequency
> for example. I don't really expect that setup to work even on a
> perfectly stable system. CPUFreq *has* to be involved, otherwise, that
> alone might introduce bugs, and you cannot draw any conclusions
> anymore.

No, this has nothing to do with linux. I'm not running linux for this
test. I'm running a small program on CPUS (Open RISC CPU) on the SoC
loaded using FEL from USB.

The main cpu is just pushing messages into msgbox in a loop, so that
CPUS can determine that the main CPU is still running ok and give
feedback to me over UART. Not even DRAM is involved. The programs are
running from SRAM.

This is the most direct test of PLL change stability that can be done on
this SoC regardless of the OS. Not even CPU voltage switching is
involved. I just set the maximum voltage and fiddle with CPU_PLL
frequencies randomly, while waiting for the main CPU to lock up.

It does lock up quickly with mainline ccu_nkmp_find_best algorithm for
finding factors.

Even with linux kernel, it breaks. It's just more difficult to hit the
right conditions. I got oops only right after boot when running cpuburn
to trigger thermal_zone issued OPP change, if I first run some cpupower
commands. That's why I wrote this program to stress test various CPU_PLL
change/factor selection algorithms independently of everything else, to
get more predictable and quicker testing results.

>> What works is selecting NKMP factors so that M is always 1 and P is
>> anything other than /1 only for frequencies under 288MHz. As mandated by
>> the H3 datasheet. Mainline ccu_nkmp_find_best doesn't respect these
>> conditions. With that I can change CPUX frequencies randomly 20x a
>> second so far indefinitely without the main CPU ever locking up.
>>
>> Please drop or revert this patch. It is not a correct approach to the
>> problem. I'd suggest dropping the entire clock notifier mechanism, too,
>> unless it can be proven to work reliably.
> 
> It has been proven to work reliably on a number of other SoCs.

Unless it was stress tested like this with randomy changed settings, I
doubt you can call it reliable. It may just be very hard to hit the
issue on linux with particular OPP/thermal zone configuration. That's
because the issue is dependent on before and after NKMP values. People
may have just been lucky so far.

regards,
  o.

> Thanks!
> Maxime
> 

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

Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

[Ondřej Jirman]

Hi Maxime,

Dne 16.1.2017 v 17:43 Maxime Ripard napsal(a):
>> It does lock up quickly with mainline ccu_nkmp_find_best algorithm
>> for finding factors.
>>
>> Even with linux kernel, it breaks. It's just more difficult to hit the
>> right conditions. I got oops only right after boot when running cpuburn
>> to trigger thermal_zone issued OPP change, if I first run some cpupower
>> commands. That's why I wrote this program to stress test various CPU_PLL
>> change/factor selection algorithms independently of everything else, to
>> get more predictable and quicker testing results.
> 
> Understood. Do you have the code available somewhere?

It's a bit messy, but it's here:

https://github.com/megous/h3-firmware/blob/master/main.c

 What works is selecting NKMP factors so that M is always 1 and P is
 anything other than /1 only for frequencies under 288MHz. As mandated by
 the H3 datasheet. Mainline ccu_nkmp_find_best doesn't respect these
 conditions. With that I can change CPUX frequencies randomly 20x a
 second so far indefinitely without the main CPU ever locking up.

 Please drop or revert this patch. It is not a correct approach to the
 problem. I'd suggest dropping the entire clock notifier mechanism, too,
 unless it can be proven to work reliably.
>>>
>>> It has been proven to work reliably on a number of other SoCs.
>>
>> Unless it was stress tested like this with randomy changed settings, I
>> doubt you can call it reliable. It may just be very hard to hit the
>> issue on linux with particular OPP/thermal zone configuration. That's
>> because the issue is dependent on before and after NKMP values. People
>> may have just been lucky so far.
> 
> Yes, or maybe we just have OPPs that just don't trigger a low enough P
> factor.
> 
> There's no rush anyway, the H3 cpufreq support is not enabled at the
> moment, so that code basically does nothing for the moment.
> 
> What's your current plan to fix that? I guess the easiest (and most
> likely to be reusable) would be to allow for clock tables, instead of
> using the generic approach. We might have some other clocks (like
> audio or video) that would need such a precise tuning in the future
> too.

My proposed solution is this for M factor (H3 specific solution):

https://github.com/megous/linux/commit/88be3d421e958579026135d8acec4b3983958738

and this for P factor:

https://github.com/megous/linux/commit/d7f274ed0c13fa9b4099445cb6bf9b2f8f2cfa8a

Perhaps it should be configurable if the P limitation is not universal
for all NKMP clocks. But I haven't read all the datasheets.

It was verified with the above arisc firmware to work reliably, so it
should be enough. It is simpler and the factor table should not be
necessary in this case.

regards,
  o.

> Maxime
> 

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

Re: [linux-sunxi] [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode

[Ondřej Jirman]

Dne 16.1.2017 v 20:14 Icenowy Zheng napsal(a):
> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> controller.
> 
> The original driver wired it to OHCI/EHCI controller; however, as the
> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> unusable.
> 
> Rename the register (according to its function and the name in BSP
> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> can support both peripheral and host mode (although the host mode of
> MUSB is buggy).
> 
> The register that is renamed is now unused, as its initial value is just
> MUSB mode. However, when OHCI/EHCI mode support is added, the register
> can be used again.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/phy/phy-sun4i-usb.c | 25 +
>  1 file changed, 9 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index bf28a0fdd569..6b193a635c6b 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -49,7 +49,7 @@
>  #define REG_PHYBIST  0x08
>  #define REG_PHYTUNE  0x0c
>  #define REG_PHYCTL_A33   0x10
> -#define REG_PHY_UNK_H3   0x20
> +#define REG_PHY_OTGCTL   0x20

You have added REG_PHY_OTGCTL, but it is not used below.

regards,
  o.

>  #define REG_PMU_UNK1 0x10
>  
> @@ -269,23 +269,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>   }
>  
> - if (data->cfg->type == sun8i_h3_phy) {
> - if (phy->index == 0) {
> - val = readl(data->base + REG_PHY_UNK_H3);
> - writel(val & ~1, data->base + REG_PHY_UNK_H3);
> - }
> - } else {
> - /* Enable USB 45 Ohm resistor calibration */
> - if (phy->index == 0)
> - sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> + /* Enable USB 45 Ohm resistor calibration */
> + if (phy->index == 0)
> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>  
> - /* Adjust PHY's magnitude and rate */
> - sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>  
> - /* Disconnect threshold adjustment */
> - sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> - data->cfg->disc_thresh, 2);
> - }
> + /* Disconnect threshold adjustment */
> + sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> + data->cfg->disc_thresh, 2);
>  
>   sun4i_usb_phy_passby(phy, 1);
>  
> 

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

Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

[Ondřej Jirman]

Dne 18.1.2017 v 17:56 Maxime Ripard napsal(a):
>>> What's your current plan to fix that? I guess the easiest (and most
>>> likely to be reusable) would be to allow for clock tables, instead of
>>> using the generic approach. We might have some other clocks (like
>>> audio or video) that would need such a precise tuning in the future
>>> too.
>>
>> My proposed solution is this for M factor (H3 specific solution):
>>
>> https://github.com/megous/linux/commit/88be3d421e958579026135d8acec4b3983958738
> 
> This one is fine.
> 
>> and this for P factor:
>>
>> https://github.com/megous/linux/commit/d7f274ed0c13fa9b4099445cb6bf9b2f8f2cfa8a
>>
>> Perhaps it should be configurable if the P limitation is not universal
>> for all NKMP clocks. But I haven't read all the datasheets.
> 
> And this is exactly what I wanted to avoid, for the reason you're
> giving :)
> 
> This is some generic code, and yet you're putting a clock and SoC
> specific limit in there. You have two ways to deal with that. Either
> come up with some generic throttling mecanism to force a particular
> value above or below a given threshold, but that might be tedious to
> do, and require some significant rework.
> 
> Or you can use a table, which is generic and should be relatively
> easy. I really think this is the most straightforward solution, and
> even more so since we just want to support a limited number of
> frequencies in this case.

So I would add a pointer to a table to struct ccu_nkmp and define the
table itself in ccu-sun8i-h3.c?

If struct ccu_nkmp would have non-NULL pointer to a table, it would be
used instead of the math in ccu_nkmp.c.

Sounds ok?

regards,
  o.

> Maxime
> 

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

Re: [linux-sunxi] [PATCH v3 0/5] Add dual-role OTG support for Allwinner H3

[Ondřej Jirman]

Hi Icenowy,

when I was trying to add OTG support I found an issue with powercycling.
When I have USB cable connecting PC and the OTG port on the SBC, when
the board enables the vbus, it would become impossible to power cycle
the board after poweroff. The reason being that when vbus is enabled,
the board is powered from the OTG port even if you disconnect the barrel
plug.

Should kernel turn off the vbus before shutting down/restarting? What do
you think?

regards,
  o.

Dne 6.3.2017 v 23:34 Icenowy Zheng napsal(a):
> Allwinner H3 have a its USB PHY0 routed to two USB controllers: one is
> a MUSB controller, which can work in peripheral mode, but works badly in
> host mode (several hardware will fail on the MUSB controller, even connect
> one MUSB controller in peripheral mode to another one in host mode cannot
> work); the other is a pair of EHCI/OHCI controller, which can work only
> in host mode, but have better compatibillity. The route is controlled in
> a register, which we have set it to HCI only when we do not know about
> it well.
> 
> Add support to route to the best controller according to current USB mode
> (host/peripheral).
> 
> Note: Currently even if hardware only support hostmode, we should still
> enable the MUSB controller, as it controls the USB mode. (Some this kind
> of hardware can also work in peripheral mode by settings in the sysfs
> node of MUSB, then connect it to another host via a USB Type-A to Type-A
> cable.)
> 
> Patch 1 changes the device tree binding to include the "pmu0" for HCI pair.
> 
> Patch 2 adds support for auto routing of PHY0. It's currently only enabled
> on H3, but it's easy to extend it to other SoCs which feature this
> route control.
> 
> Patch 3 adds necessary device tree nodes to the H3 DTSI file. Note: The
> phy is not bind for OHCI/EHCI0, as OHCI/EHCI drivers will keep the VBUS
> on. Only MUSB driver can properly handle a dual-role PHY.
> 
> Patch 4 enables USB OTG functionality on Orange Pi One board, which is
> the only H3 board I have that have proper OTG function. It's easy to
> enable OTG on other boards with their schematics.
> 
> Patch 5 enables USB OTG functionality on Orange Pi Zero board, as the
> board cannot output power on Vbus, I only enabled peripheral mode by
> default.
> 
> The USB PHY on V3s/A64 SoCs also feature this capability, and it will
> be soon enabled on these SoCs after this patchset is merged.
> 
> Icenowy Zheng (5):
>   dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
>   phy: sun4i-usb: support automatically switch PHY0 route to MUSB/HCI
>   ARM: dts: sun8i: h3: add usb_otg and OHCI/EHCI for usbc0 on H3
>   ARM: dts: sun8i: h3: enable USB OTG on Orange Pi One
>   ARM: dts: sun8i: h2+: enable USB OTG for Orange Pi Zero board
> 
>  .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +
>  arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts  | 14 ++
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 22 +-
>  arch/arm/boot/dts/sun8i-h3.dtsi| 32 ++
>  drivers/phy/phy-sun4i-usb.c| 50 
> ++
>  5 files changed, 101 insertions(+), 18 deletions(-)
> 

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


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] [PATCH v2] arm64: dts: allwinner: h6: orangepi-3: Add eMMC node

[Ondřej Jirman]

Hi,

On Mon, Feb 10, 2020 at 06:40:07PM +0100, Jernej Skrabec wrote:
> OrangePi 3 can optionally have 8 GiB eMMC (soldered on board). Because
> those pins are dedicated to eMMC exclusively, node can be added for both
> variants (with and without eMMC). Kernel will then scan bus for presence
> of eMMC and act accordingly.

Tested-by: Ondrej Jirman  (on a variant without eMMC)

It didn't magically add extra 8GiB of storage, but it didn't break anything
either. :)

regards,
o.

> Signed-off-by: Jernej Skrabec 
> ---
> Changes since v1:
> - don't make separate DT just for -emmc variant - add node to existing
>   orangepi 3 DT
> 
>  arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index c311eee52a35..1e0abd9d047f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -144,6 +144,15 @@ brcm: sdio-wifi@1 {
>   };
>  };
>  
> +&mmc2 {
> + vmmc-supply = <®_cldo1>;
> + vqmmc-supply = <®_bldo2>;
> + cap-mmc-hw-reset;
> + non-removable;
> + bus-width = <8>;
> + status = "okay";
> +};
> +
>  &ohci0 {
>   status = "okay";
>  };
> -- 
> 2.25.0
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit 
> https://groups.google.com/d/msgid/linux-sunxi/20200210174007.118575-1-jernej.skrabec%40siol.net.

-- 
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/20200212122511.5gr6m4ppmytq4ajj%40core.my.home.

[linux-sunxi] Re: [PATCH] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads

[Ondřej Jirman]

On Wed, Feb 19, 2020 at 10:49:18AM +0800, Chen-Yu Tsai wrote:
> On Wed, Feb 19, 2020 at 9:10 AM Ondrej Jirman  wrote:
> >
> > When doing a 16-bit read that returns data in the MSB byte, the
> > RSB_DATA register will keep the MSB byte unchanged when doing
> > the following 8-bit read. sunxi_rsb_read() will then return
> > a result that contains high byte from 16-bit read mixed with
> > the 8-bit result.
> >
> > The consequence is that after this happens the PMIC's regmap will
> > look like this: (0x33 is the high byte from the 16-bit read)
> >
> > % cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
> > 00: 33
> > 01: 33
> > 02: 33
> > 03: 33
> > 04: 33
> > 05: 33
> > 06: 33
> > 07: 33
> > 08: 33
> > 09: 33
> > 0a: 33
> > 0b: 33
> > 0c: 33
> > 0d: 33
> > 0e: 33
> > [snip]
> >
> > Fix this by masking the result of the read with the correct mask
> > based on the size of the read. There are no 16-bit users in the
> > mainline kernel, so this doesn't need to get into the stable tree.
> >
> > Signed-off-by: Ondrej Jirman 
> 
> Acked-by: Chen-Yu Tsai 
> 
> for the fix, however it's not entirely clear to me how the MSB 0x33
> value got into the regmap. Looks like I expected the regmap core to
> handle any overflows, or didn't expect the lingering MSB from 16-bit
> reads, as I didn't have any 16-bit register devices back when I wrote
> this.

Now I feel like I masked some other bug. Though explanation may be quite simple.

For example when AXP core does regmap_read on some values for showing charging
current or battery voltage, because regmap_read works with unsigned int, it
will simply get a number that's too big. And that was the major symptom
I observed. I got readings from sysfs that my tablet is consuming 600A or 200A,
etc. And this value was jumping around based on AC100 activity (as the MSB
byte got changed).

In other places where the driver does regmap_update_bits, I think nothing bad
happened. The write after the read would simply discard the MSB byte.

And for the debugfs/regmap/*/registers, those are printed such:

https://elixir.bootlin.com/linux/latest/source/drivers/base/regmap/regmap-debugfs.c#L256

snprintf(buf + buf_pos, count - buf_pos,
"%.*x", map->debugfs_val_len, val);

This doesn't truncate values, so the larger number gets printed to (for 
example):

33fe

But regmap debugfs code truncates this by cutting off the formatted string to
this length:

  
https://elixir.bootlin.com/linux/latest/source/drivers/base/regmap/regmap-debugfs.c#L189

So in the end, only:

00: 33

remains, instead of the correct value of:

00: fe

So in the case of debugfs this is just a cosmetic/formatting issue, that didn't
affect anything else.

I think regmap_bus->reg_read API simply expects the returned value to not exceed
the sensible range.

regards,
o.


> ChenYu
> 
> 
> > ---
> >  drivers/bus/sunxi-rsb.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
> > index b8043b58568ac..8ab6a3865f569 100644
> > --- a/drivers/bus/sunxi-rsb.c
> > +++ b/drivers/bus/sunxi-rsb.c
> > @@ -316,6 +316,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 
> > rtaddr, u8 addr,
> >  {
> > u32 cmd;
> > int ret;
> > +   u32 mask;
> >
> > if (!buf)
> > return -EINVAL;
> > @@ -323,12 +324,15 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 
> > rtaddr, u8 addr,
> > switch (len) {
> > case 1:
> > cmd = RSB_CMD_RD8;
> > +   mask = 0xffu;
> > break;
> > case 2:
> > cmd = RSB_CMD_RD16;
> > +   mask = 0xu;
> > break;
> > case 4:
> > cmd = RSB_CMD_RD32;
> > +   mask = 0xu;
> > break;
> > default:
> > dev_err(rsb->dev, "Invalid access width: %zd\n", len);
> > @@ -345,7 +349,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 
> > rtaddr, u8 addr,
> > if (ret)
> > goto unlock;
> >
> > -   *buf = readl(rsb->regs + RSB_DATA);
> > +   *buf = readl(rsb->regs + RSB_DATA) & mask;
> >
> >  unlock:
> > mutex_unlock(&rsb->lock);
> > --
> > 2.25.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/20200219121424.dfvrwfcavupmwbvw%40core.my.home.

[linux-sunxi] Re: [PATCH] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads

[Ondřej Jirman]

Hi,

On Thu, Feb 20, 2020 at 06:32:13PM +0100, Maxime Ripard wrote:
> On Wed, Feb 19, 2020 at 02:09:50AM +0100, Ondrej Jirman wrote:
> > When doing a 16-bit read that returns data in the MSB byte, the
> > RSB_DATA register will keep the MSB byte unchanged when doing
> > the following 8-bit read. sunxi_rsb_read() will then return
> > a result that contains high byte from 16-bit read mixed with
> > the 8-bit result.
> >
> > The consequence is that after this happens the PMIC's regmap will
> > look like this: (0x33 is the high byte from the 16-bit read)
> >
> > % cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
> > 00: 33
> > 01: 33
> > 02: 33
> > 03: 33
> > 04: 33
> > 05: 33
> > 06: 33
> > 07: 33
> > 08: 33
> > 09: 33
> > 0a: 33
> > 0b: 33
> > 0c: 33
> > 0d: 33
> > 0e: 33
> > [snip]
> >
> > Fix this by masking the result of the read with the correct mask
> > based on the size of the read. There are no 16-bit users in the
> > mainline kernel, so this doesn't need to get into the stable tree.
> >
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  drivers/bus/sunxi-rsb.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
> > index b8043b58568ac..8ab6a3865f569 100644
> > --- a/drivers/bus/sunxi-rsb.c
> > +++ b/drivers/bus/sunxi-rsb.c
> > @@ -316,6 +316,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 
> > rtaddr, u8 addr,
> >  {
> > u32 cmd;
> > int ret;
> > +   u32 mask;
> >
> > if (!buf)
> > return -EINVAL;
> > @@ -323,12 +324,15 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 
> > rtaddr, u8 addr,
> > switch (len) {
> > case 1:
> > cmd = RSB_CMD_RD8;
> > +   mask = 0xffu;
> > break;
> > case 2:
> > cmd = RSB_CMD_RD16;
> > +   mask = 0xu;
> > break;
> > case 4:
> > cmd = RSB_CMD_RD32;
> > +   mask = 0xu;
> > break;
> > default:
> > dev_err(rsb->dev, "Invalid access width: %zd\n", len);
> > @@ -345,7 +349,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 
> > rtaddr, u8 addr,
> > if (ret)
> > goto unlock;
> >
> > -   *buf = readl(rsb->regs + RSB_DATA);
> > +   *buf = readl(rsb->regs + RSB_DATA) & mask;
> 
> Thanks for debugging this and the extensive commit log.
> 
> I guess it would be cleaner to just use GENMASK(len * 8, 0) here?

GENMASK most probably fails with value (32,0) I think.

#define GENMASK(h, l) \
(((~UL(0)) - (UL(1) << (l)) + 1) & \
 (~UL(0) >> (BITS_PER_LONG - 1 - (h

would give ~0 >> -1

regards,
o.

> Maxime


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