Re: [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

2017-07-02 Thread Marc Zyngier 
On Sun, 2 Jul 2017 15:08:12 +0800
 wrote:

> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> > On Fri, Jun 23, 2017 at 9:39 PM,   wrote:  
> >> 在 2017-06-23 21:35，Maxime Ripard 写道：  
> >>> 
> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@aosc.io wrote:  
>  
>  在 2017-06-07 20:51，Marc Zyngier 写道：  
>  > On 07/06/17 13:12, Icenowy Zheng wrote:  
>  > >
>  > >
>  > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
>  > >  写到:  
>  > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:  
>  > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>  > > > >  wrote:  
>  > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:  
>  > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
>  > > > > > >   
>  > > > wrote:  
>  > > > > > > >
>  > > > > > > >
>  > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
>  > > > > > > > Tsai  写到:  
>  > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
>  > > > > > > > >   
>  > > > wrote:  
>  > > > > > > > > > As we have now a basical implementation
>  > > > > > > > > > of PSCI for A83T, enable
>  > > > > > > > > > non-secure boot support and PSCI on A83T now.
>  > > > > > > > > >
>  > > > > > > > > > Signed-off-by: Icenowy Zheng 
>  > > > > > > > > > ---
>  > > > > > > > > >  arch/arm/mach-sunxi/Kconfig | 4 
>  > > > > > > > > >  1 file changed, 4 insertions(+)
>  > > > > > > > > >
>  > > > > > > > > > diff --git a/arch/arm/mach-sunxi/Kconfig  
>  > > > > > > > > b/arch/arm/mach-sunxi/Kconfig  
>  > > > > > > > > > index 7ced838d6a..31d29de428 100644
>  > > > > > > > > > --- a/arch/arm/mach-sunxi/Kconfig
>  > > > > > > > > > +++ b/arch/arm/mach-sunxi/Kconfig
>  > > > > > > > > > @@ -98,8 +98,12 @@ config MACH_SUN8I_A33
>  > > > > > > > > >  config MACH_SUN8I_A83T
>  > > > > > > > > > bool "sun8i (Allwinner A83T)"
>  > > > > > > > > > select CPU_V7
>  > > > > > > > > > +   select CPU_V7_HAS_NONSEC
>  > > > > > > > > > +   select CPU_V7_HAS_VIRT
>  > > > > > > > > > +   select ARCH_SUPPORT_PSCI
>  > > > > > > > > > select SUNXI_GEN_SUN6I
>  > > > > > > > > > select SUPPORT_SPL
>  > > > > > > > > > +   select ARMV7_BOOT_SEC_DEFAULT if
>  > > > > > > > > > OLD_SUNXI_KERNEL_COMPAT  
>  > > > > > > > >
>  > > > > > > > > The kernel does not work yet. Please have it boot to
>  > > > > > > > > secure by  
>  > > > default  
>  > > > > > > > > regardless of the kernel. We can have it
>  > > > > > > > > boot non-secure once the
>  > > > > > > > > kernel
>  > > > > > > > > has been working for a reasonable amount of time.
>  > > > > > > > >
>  > > > > > > > > I don't want clueless users coming and asking why it
>  > > > > > > > > suddenly  
>  > > > stopped  
>  > > > > > > > > working. This should be an experimental feature.  
>  > > > > > > >
>  > > > > > > > Maybe you should send out the fix, and tag them to also
>  > > > > > > > apply to
>  > > > > > > > stable tree.
>  > > > > > > >
>  > > > > > > > GIC is really broken, UP systems only work by chance. We
>  > > > > > > > shouldn't depend on this behavior.  
>  > > > > > >
>  > > > > > > As I previously explained, it is not the GIC that is broken.
>  > > > > > > I  
>  > > > believe  
>  > > > > > > the GIC is working exactly as it is supposed to with
>  > > > > > > regards to its
>  > > > > > > input signals.
>  > > > > > >
>  > > > > > > Allwinner's security extensions implementation simply does
>  > > > > > > not  
>  > > > properly  
>  > > > > > > forward the AXI secure bit when the e-fuse's secure bit 
>  > > > > > > isn't  
>  > > > burned.
>  > > >
>  > > > Arghh. Puke. Now I remember this, and I wish I didn't...
>  > > >  
>  > > > > > Is that on all revisions, or just the revB ?  
>  > > > >
>  > > > > It's the A80, but I'm guessing the same applies to the A83T. 
>  > > > > It's  
>  > > > more  
>  > > > > of a guess really, but I think it's a logical one. If the e-fuse 
>  > > > >  
>  > > > isn't  
>  > > > > programmed, the TZPC doesn't work, and access to all secure  
>  > > > peripherals  
>  > > > > still work, even from non-secure mode. The only one that
>  > > > > does work is
>  > > > > the secure SRAM.
>  > > > >
>  > > > > The GIC still has the banked secure/non-secure registers, just
>  > > > > that  
>  > > > all  
>  > > > > cores access the secure bank, even when in non-secure mode. The  
>  > > > workaround  
>  > > > > is to use the alias set of non-secure registers in

[linux-sunxi] [PATCH 6/6] net: stmmac: revert "support future possible different internal phy mode"

2017-07-02 Thread Corentin Labbe 
Since internal phy-mode is reserved for non-xMII protocol we cannot use
it with dwmac-sun8i
This reverts commit 1c2fa5f84683 ("net: stmmac: support future possible 
different internal phy mode")

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 6c2d1da05588..fffd6d5fc907 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -638,7 +638,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 {
struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
struct device_node *node = priv->device->of_node;
-   int ret, phy_interface;
+   int ret;
u32 reg, val;
 
regmap_read(gmac->regmap, SYSCON_EMAC_REG, );
@@ -718,11 +718,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
if (gmac->variant->support_rmii)
reg &= ~SYSCON_RMII_EN;
 
-   phy_interface = priv->plat->interface;
-   /* if PHY is internal, select the mode (xMII) used by the SoC */
-   if (gmac->use_internal_phy)
-   phy_interface = gmac->variant->internal_phy;
-   switch (phy_interface) {
+   switch (priv->plat->interface) {
case PHY_INTERFACE_MODE_MII:
/* default */
break;
@@ -936,7 +932,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
 
plat_dat->interface = of_get_phy_mode(dev->of_node);
-   if (plat_dat->interface == PHY_INTERFACE_MODE_INTERNAL) {
+   if (plat_dat->interface == gmac->variant->internal_phy) {
dev_info(>dev, "Will use internal PHY\n");
gmac->use_internal_phy = true;
gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
-- 
2.13.0

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

[linux-sunxi] [PATCH 1/6] arm: sun8i: nanopi-neo: revert use internal phy-mode

2017-07-02 Thread Corentin Labbe 
Since internal phy-mode is reserved for non-xMII protocol we cannot use
it with dwmac-sun8i
This reverts commit bdcc005beac9 ("arm: sun8i: nanopi-neo: use internal 
phy-mode")

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
index 5c5ba806e2f1..78f6c24952dd 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -49,7 +49,7 @@
 
  {
phy-handle = <_mii_phy>;
-   phy-mode = "internal";
+   phy-mode = "mii";
allwinner,leds-active-low;
status = "okay";
 };
-- 
2.13.0

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

[linux-sunxi] [PATCH 0/6] net: stmmac: revert "support future possible different internal phy mode"

2017-07-02 Thread Corentin Labbe 
Hello

The current way to find if the phy is internal is to compare DT phy-mode
and emac_variant/internal_phy.
But it will negate a possible future SoC where an external PHY use the
same phy mode than the internal one.

My first idea was to use phy-mode = "internal" but since internal phy-mode
is reserved for non-xMII protocol we cannot use it with dwmac-sun8i

I will send an additionnal patch for documenting more phy-mode = "internal"

Corentin Labbe (6):
  arm: sun8i: nanopi-neo: revert use internal phy-mode
  arm: sun8i: orangepi-2: revert "use internal phy-mode"
  arm: sun8i: orangepi-one: revert "use internal phy-mode"
  arm: sun8i: orangepi-zero: revert "use internal phy-mode"
  arm: sun8i: orangepipc: revert "use internal phy-mode"
  net: stmmac: revert "support future possible different internal phy
mode"

 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts |  2 +-
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts |  2 +-
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts |  2 +-
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts   |  2 +-
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts|  2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 10 +++---
 6 files changed, 8 insertions(+), 12 deletions(-)

-- 
2.13.0

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

[linux-sunxi] [PATCH 3/6] arm: sun8i: orangepi-one: revert "use internal phy-mode"

2017-07-02 Thread Corentin Labbe 
Since internal phy-mode is reserved for non-xMII protocol we cannot use
it with dwmac-sun8i
This reverts commit 4ac57180eab2 ("arm: sun8i: orangepi-one: use internal 
phy-mode")

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 27e7ef4e42f2..6880268e8b87 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -100,7 +100,7 @@
 
  {
phy-handle = <_mii_phy>;
-   phy-mode = "internal";
+   phy-mode = "mii";
allwinner,leds-active-low;
status = "okay";
 };
-- 
2.13.0

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

[linux-sunxi] [PATCH 5/6] arm: sun8i: orangepipc: revert "use internal phy-mode"

2017-07-02 Thread Corentin Labbe 
Since internal phy-mode is reserved for non-xMII protocol we cannot use
it with dwmac-sun8i
This reverts commit 3432a86e641c ("arm: sun8i: orangepipc: use internal 
phy-mode")

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 94edeb889e55..f5f0f15a2088 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -120,7 +120,7 @@
 
  {
phy-handle = <_mii_phy>;
-   phy-mode = "internal";
+   phy-mode = "mii";
allwinner,leds-active-low;
status = "okay";
 };
-- 
2.13.0

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

[linux-sunxi] [PATCH 4/6] arm: sun8i: orangepi-zero: revert "use internal phy-mode"

2017-07-02 Thread Corentin Labbe 
Since internal phy-mode is reserved for non-xMII protocol we cannot use
it with dwmac-sun8i
This reverts commit 6066de6848d4 ("arm: sun8i: orangepi-zero: use internal 
phy-mode")

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index 7c154b845baa..6713d0f2b3f4 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -106,7 +106,7 @@
 
  {
phy-handle = <_mii_phy>;
-   phy-mode = "internal";
+   phy-mode = "mii";
allwinner,leds-active-low;
status = "okay";
 };
-- 
2.13.0

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

[linux-sunxi] [PATCH 2/6] arm: sun8i: orangepi-2: revert "use internal phy-mode"

2017-07-02 Thread Corentin Labbe 
Since internal phy-mode is reserved for non-xMII protocol we cannot use
it with dwmac-sun8i
This reverts commit 5a79b4f2a5e7 ("arm: sun8i: orangepi-2: use internal 
phy-mode")

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index a2a2b11dfeed..17cdeae19c6f 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -120,7 +120,7 @@
 
  {
phy-handle = <_mii_phy>;
-   phy-mode = "internal";
+   phy-mode = "mii";
allwinner,leds-active-low;
status = "okay";
 };
-- 
2.13.0

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

Re: [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

2017-07-02 Thread Marc Zyngier 
On Sun, 2 Jul 2017 20:36:04 +0800
 wrote:

> 在 2017-07-02 19:22，Marc Zyngier 写道：
> > On Sun, 2 Jul 2017 15:08:12 +0800
> >  wrote:
> >   
> >> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：  
> >> > On Fri, Jun 23, 2017 at 9:39 PM,   wrote:  
> >> >> 在 2017-06-23 21:35，Maxime Ripard 写道：  
> >> >>>
> >> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@aosc.io wrote:  
> >> 
> >>  在 2017-06-07 20:51，Marc Zyngier 写道：  
> >>  > On 07/06/17 13:12, Icenowy Zheng wrote:  
> >>  > >
> >>  > >
> >>  > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
> >>  > >  写到:  
> >>  > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:  
> >>  > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> >>  > > > >  wrote:  
> >>  > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai 
> >>  > > > > > wrote:  
> >>  > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
> >>  > > > > > >   
> >>  > > > wrote:  
> >>  > > > > > > >
> >>  > > > > > > >
> >>  > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> >>  > > > > > > > Tsai  写到:  
> >>  > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
> >>  > > > > > > > >   
> >>  > > > wrote:  
> >>  > > > > > > > > > As we have now a basical implementation
> >>  > > > > > > > > > of PSCI for A83T, enable
> >>  > > > > > > > > > non-secure boot support and PSCI on A83T now.
> >>  > > > > > > > > >
> >>  > > > > > > > > > Signed-off-by: Icenowy Zheng 
> >>  > > > > > > > > > ---
> >>  > > > > > > > > >  arch/arm/mach-sunxi/Kconfig | 4 
> >>  > > > > > > > > >  1 file changed, 4 insertions(+)
> >>  > > > > > > > > >
> >>  > > > > > > > > > diff --git a/arch/arm/mach-sunxi/Kconfig  
> >>  > > > > > > > > b/arch/arm/mach-sunxi/Kconfig  
> >>  > > > > > > > > > index 7ced838d6a..31d29de428 100644
> >>  > > > > > > > > > --- a/arch/arm/mach-sunxi/Kconfig
> >>  > > > > > > > > > +++ b/arch/arm/mach-sunxi/Kconfig
> >>  > > > > > > > > > @@ -98,8 +98,12 @@ config MACH_SUN8I_A33
> >>  > > > > > > > > >  config MACH_SUN8I_A83T
> >>  > > > > > > > > > bool "sun8i (Allwinner A83T)"
> >>  > > > > > > > > > select CPU_V7
> >>  > > > > > > > > > +   select CPU_V7_HAS_NONSEC
> >>  > > > > > > > > > +   select CPU_V7_HAS_VIRT
> >>  > > > > > > > > > +   select ARCH_SUPPORT_PSCI
> >>  > > > > > > > > > select SUNXI_GEN_SUN6I
> >>  > > > > > > > > > select SUPPORT_SPL
> >>  > > > > > > > > > +   select ARMV7_BOOT_SEC_DEFAULT if
> >>  > > > > > > > > > OLD_SUNXI_KERNEL_COMPAT  
> >>  > > > > > > > >
> >>  > > > > > > > > The kernel does not work yet. Please have it boot to
> >>  > > > > > > > > secure by  
> >>  > > > default  
> >>  > > > > > > > > regardless of the kernel. We can have it
> >>  > > > > > > > > boot non-secure once the
> >>  > > > > > > > > kernel
> >>  > > > > > > > > has been working for a reasonable amount of time.
> >>  > > > > > > > >
> >>  > > > > > > > > I don't want clueless users coming and asking why it
> >>  > > > > > > > > suddenly  
> >>  > > > stopped  
> >>  > > > > > > > > working. This should be an experimental feature.  
> >>  > > > > > > >
> >>  > > > > > > > Maybe you should send out the fix, and tag them to also
> >>  > > > > > > > apply to
> >>  > > > > > > > stable tree.
> >>  > > > > > > >
> >>  > > > > > > > GIC is really broken, UP systems only work by chance. We
> >>  > > > > > > > shouldn't depend on this behavior.  
> >>  > > > > > >
> >>  > > > > > > As I previously explained, it is not the GIC that is 
> >>  > > > > > > broken.
> >>  > > > > > > I  
> >>  > > > believe  
> >>  > > > > > > the GIC is working exactly as it is supposed to with
> >>  > > > > > > regards to its
> >>  > > > > > > input signals.
> >>  > > > > > >
> >>  > > > > > > Allwinner's security extensions implementation simply does
> >>  > > > > > > not  
> >>  > > > properly  
> >>  > > > > > > forward the AXI secure bit when the e-fuse's secure bit 
> >>  > > > > > > isn't  
> >>  > > > burned.
> >>  > > >
> >>  > > > Arghh. Puke. Now I remember this, and I wish I didn't...
> >>  > > >  
> >>  > > > > > Is that on all revisions, or just the revB ?  
> >>  > > > >
> >>  > > > > It's the A80, but I'm guessing the same applies to the A83T. 
> >>  > > > > It's  
> >>  > > > more  
> >>  > > > > of a guess really, but I think it's a logical one. If the 
> >>  > > > > e-fuse  
> >>  > > > isn't  
> >>  > > > > programmed, the TZPC doesn't work, and access to all secure  
> >>  > > >

Re: [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

2017-07-02 Thread Maxime Ripard 
On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
> > If that is so fundamentally broken that this is the only benefit, I
> > guess we might as well use some old-style SMP ops.
> 
> Broken, for sure. Which is why I'm asking about the benefits of running
> non-secure on something that has evidently been very badly integrated,
> and for which non-secure is at best an afterthought.
> 
> Now, if someone could try and run guests on this turd and report whether
> this works correctly or not, that'd be an interesting data point.
> Because in the absence of a TEE running on the secure side,
> virtualization is basically the only thing you gain from running on the
> non-secure side.

I just tried running Xen on it, with an adjustment similar to what
Chen-Yu made in the kernel.

It fails at boot, and stops with:
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0

It looks like it won't be easy to support. I guess we could just go
for smp_ops, and if someone really cares one day about it, we'll
always have the option to support it then.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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


signature.asc
Description: PGP signature

Re: [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

2017-07-02 Thread icenowy 

在 2017-07-02 19:22，Marc Zyngier 写道：

On Sun, 2 Jul 2017 15:08:12 +0800
 wrote:


在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> On Fri, Jun 23, 2017 at 9:39 PM,   wrote:
>> 在 2017-06-23 21:35，Maxime Ripard 写道：
>>>
>>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@aosc.io wrote:

 在 2017-06-07 20:51，Marc Zyngier 写道：
 > On 07/06/17 13:12, Icenowy Zheng wrote:
 > >
 > >
 > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
 > >  写到:
 > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
 > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
 > > > >  wrote:
 > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
 > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
 > > > > > > 
 > > > wrote:
 > > > > > > >
 > > > > > > >
 > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
 > > > > > > > Tsai  写到:
 > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
 > > > > > > > > 
 > > > wrote:
 > > > > > > > > > As we have now a basical implementation
 > > > > > > > > > of PSCI for A83T, enable
 > > > > > > > > > non-secure boot support and PSCI on A83T now.
 > > > > > > > > >
 > > > > > > > > > Signed-off-by: Icenowy Zheng 
 > > > > > > > > > ---
 > > > > > > > > >  arch/arm/mach-sunxi/Kconfig | 4 
 > > > > > > > > >  1 file changed, 4 insertions(+)
 > > > > > > > > >
 > > > > > > > > > diff --git a/arch/arm/mach-sunxi/Kconfig
 > > > > > > > > b/arch/arm/mach-sunxi/Kconfig
 > > > > > > > > > index 7ced838d6a..31d29de428 100644
 > > > > > > > > > --- a/arch/arm/mach-sunxi/Kconfig
 > > > > > > > > > +++ b/arch/arm/mach-sunxi/Kconfig
 > > > > > > > > > @@ -98,8 +98,12 @@ config MACH_SUN8I_A33
 > > > > > > > > >  config MACH_SUN8I_A83T
 > > > > > > > > > bool "sun8i (Allwinner A83T)"
 > > > > > > > > > select CPU_V7
 > > > > > > > > > +   select CPU_V7_HAS_NONSEC
 > > > > > > > > > +   select CPU_V7_HAS_VIRT
 > > > > > > > > > +   select ARCH_SUPPORT_PSCI
 > > > > > > > > > select SUNXI_GEN_SUN6I
 > > > > > > > > > select SUPPORT_SPL
 > > > > > > > > > +   select ARMV7_BOOT_SEC_DEFAULT if
 > > > > > > > > > OLD_SUNXI_KERNEL_COMPAT
 > > > > > > > >
 > > > > > > > > The kernel does not work yet. Please have it boot to
 > > > > > > > > secure by
 > > > default
 > > > > > > > > regardless of the kernel. We can have it
 > > > > > > > > boot non-secure once the
 > > > > > > > > kernel
 > > > > > > > > has been working for a reasonable amount of time.
 > > > > > > > >
 > > > > > > > > I don't want clueless users coming and asking why it
 > > > > > > > > suddenly
 > > > stopped
 > > > > > > > > working. This should be an experimental feature.
 > > > > > > >
 > > > > > > > Maybe you should send out the fix, and tag them to also
 > > > > > > > apply to
 > > > > > > > stable tree.
 > > > > > > >
 > > > > > > > GIC is really broken, UP systems only work by chance. We
 > > > > > > > shouldn't depend on this behavior.
 > > > > > >
 > > > > > > As I previously explained, it is not the GIC that is broken.
 > > > > > > I
 > > > believe
 > > > > > > the GIC is working exactly as it is supposed to with
 > > > > > > regards to its
 > > > > > > input signals.
 > > > > > >
 > > > > > > Allwinner's security extensions implementation simply does
 > > > > > > not
 > > > properly
 > > > > > > forward the AXI secure bit when the e-fuse's secure bit isn't
 > > > burned.
 > > >
 > > > Arghh. Puke. Now I remember this, and I wish I didn't...
 > > >
 > > > > > Is that on all revisions, or just the revB ?
 > > > >
 > > > > It's the A80, but I'm guessing the same applies to the A83T. It's
 > > > more
 > > > > of a guess really, but I think it's a logical one. If the e-fuse
 > > > isn't
 > > > > programmed, the TZPC doesn't work, and access to all secure
 > > > peripherals
 > > > > still work, even from non-secure mode. The only one that
 > > > > does work is
 > > > > the secure SRAM.
 > > > >
 > > > > The GIC still has the banked secure/non-secure registers, just
 > > > > that
 > > > all
 > > > > cores access the secure bank, even when in non-secure mode. The
 > > > workaround
 > > > > is to use the alias set of non-secure registers in Linux.
 > > >
 > > > That's a pretty dire workaround. Also, I expect that secure writes
 > > > to
 > > > GICV/GICH will not do the right thing. At this point, what is the
 > > > requirement for running non-secure?
 > >
 > > Write Secure Boot eFUSE, which will break *all* existing

[linux-sunxi] [PATCH v8] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

2017-07-02 Thread Jonathan Liu 
The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
"As in the general case the DDC bus is accessible by the kernel at the I2C
level, drivers must make all reasonable efforts to expose it as an I2C
adapter and use drm_get_edid() instead of abusing this function."

Exposing the DDC bus as an I2C adapter is more beneficial as it can be used
for purposes other than reading the EDID such as modifying the EDID or
using the HDMI DDC pins as an I2C bus through the I2C dev interface from
userspace (e.g. i2c-tools).

Implement this for A10s.

Signed-off-by: Jonathan Liu 
---
Changes for v8:
 - Fix clock rate in comment being 100 MHz when it is actually 100 kHz
 - Fix clearing of bits in interrupt status register as they are cleared by
   writing 1 to the bit rather than 0
 - Set FIFO RX/TX thresholds so interrupt status register can be used to
   check if FIFO is ready instead of having to additionally check the FIFO
   status register
 - Remove unused linux/ktime.h include in sun4i_hdmi_i2c.c
 - Reduce timeout for clearing FIFO from 100 ms to 2 ms
 - Use BIT macro instead of GENMASK for SUN4I_HDMI_DDC_BYTE_COUNT_MAX to
   make it clearer that the maximum is derived from the field bit width rather
   than its position in the register

Changes for v7:
 - Fix mixed declarations and code compiler warning for level variable

Changes for v6:
 - Use fixed byte time of 100 us instead of dynamically calculating from DDC
   clock that is set to a fixed 100 MHz rate anyway
 - Change is_fifo_flag_unset to not read the status register as well to be
   more consistent with is_err_status

Changes for v5:
 - Use devm_kzalloc instead of devm_kmemdup and remove const struct i2c_adapter
 - Rework to use readl_poll_timeout for checking FIFO status

Changes for v4:
 - Carry over copyright from initial I2C code into sun4i_hdmi_i2c.c
 - Clean up indentation in sun4i_hdmi.h
 - Rename SUN4I_HDMI_DDC_MAX_TRANSFER_SIZE to SUN4I_HDMI_DDC_BYTE_COUNT_MAX
   and group it under the SUN4I_HDMI_DDC_BYTE_COUNT_REG define, changing the
   value to use the GENMASK macro to make it clear that it is derived from
   the width of the field in the register
 - Fix SUN4I_HDMI_DDC_INT_STATUS_DDC_TX_FIFO_UNDERFLOW typo which should be
   SUN4I_HDMI_DDC_INT_STATUS_DDC_TX_FIFO_OVERFLOW
 - Remove redundant rewriting of SUN4I_HDMI_DDC_INT_STATUS_REG register
 - Change struct i2c_adapter to be const by using devm_kmemdup on creation
 - Return -ETIMEDOUT instead of -EIO if there is timeout while transferring an
   I2C message
 - Instead of waiting for 1-2 bytes to transfer, wait for the time it would
   take for remaining bytes to transfer (limited by FIFO size)
 - Add additional comments

Changes for v3:
 - Explain why drm_do_get_edid should be used and why it's better to expose it
   as an I2C adapter in commit message
 - Reorder bit defines in descending order for consistency
 - Keep old unused macros instead of removing them
 - The v2 algorithm split large transfers into 16 byte transfers but this may
   cause a large single write to be treated as multiple writes causing data
   corruption. The algorithm has been reworked to not split larger transfers
   and make more use of the FIFO to avoid this.
 - Moved the creation of the DDC clock from sun4i_hdmi_enc.c to
   sun4i_hdmi_i2c.c
 - Reformatted code
 - Instead of masking bits that we don't want to check for errors, explicitly
   check the error bits
 - Clear error bits at start of transfer in case of error from previous transfer
 - Poll for completion of FIFO clear after setting FIFO clear bit

Changes for v2:
 - Rebased against Maxime's sunxi-drm/for-next branch
 - Fix up error paths in sun4i_hdmi_bind so that the I2C adapter is deleted if
   any of the calls after the I2C adapter is created fails
 - Remove unnecessary includes in sun4i_hdmi_i2c.c

 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  24 
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 101 ++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 220 +
 4 files changed, 256 insertions(+), 90 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index e29fd3a2ba9c..43c753cafc88 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -2,6 +2,7 @@ sun4i-drm-y += sun4i_drv.o
 sun4i-drm-y += sun4i_framebuffer.o
 
 sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
+sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
 sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
 sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 2f2f2ff1ea63..0957ff2076ac 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -96,6 +96,7 @@
 #define SUN4I_HDMI_DDC_CTRL_ENABLE BIT(31)
 #define SUN4I_HDMI_DDC_CTRL_START_CMD  BIT(30)
 #define

[linux-sunxi] Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i

2017-07-02 Thread Corentin Labbe 
On Sat, Jul 01, 2017 at 02:42:14PM -0700, Florian Fainelli wrote:
> On 30/06/2017 23:53, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
> >> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
>  On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> > Hi,
> >
> > On 27/06/17 11:23, Icenowy Zheng wrote:
> >>
> >>
> >> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara 
> >>  写到:
> >>> Hi,
> >>>
> >>> On 27/06/17 10:41, Maxime Ripard wrote:
>  On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> > Hi,
> >
> > (CC:ing some people from that Rockchip dmwac series)
> >
> > On 27/06/17 09:21, Corentin Labbe wrote:
> >> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>  wrote:
>  On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> > On 31/05/17 08:18, Corentin Labbe wrote:
> >> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >> allwinner.
> >> In fact the only common part is the descriptor management and
> >>> the first
> >> register function.
> >
> > Hi,
> >
> > I know I am a bit late with this, but while adapting the U-Boot
> >>> driver
> > to the new binding I was wondering about the internal PHY
> >>> detection:
> >
> >
> > So here you seem to deduce the usage of the internal PHY by the
> >>> PHY
> > interface specified in the DT (MII = internal, RGMII =
> >>> external).
> > I think I raised this question before, but isn't it perfectly
> >>> legal for
> > a board to use MII with an external PHY even on those SoCs that
> >>> feature
> > an internal PHY?
> > On the first glance that does not make too much sense, but apart
> >>> from
> > not being the correct binding to describe all of the SoCs
> >>> features I see
> > two scenarios:
> > 1) A board vendor might choose to not use the internal PHY
> >>> because it
> > has bugs, lacks features (configurability) or has other issues.
> >>> For
> > instance I have heard reports that the internal PHY makes the
> >>> SoC go
> > rather hot, possibly limiting the CPU frequency. By using an
> >>> external
> > MII PHY (which are still cheaper than RGMII PHYs) this can be
> >>> avoided.
> > 2) A PHY does not necessarily need to be directly connected to
> > magnetics. Indeed quite some boards use (RG)MII to connect to a
> >>> switch
> > IC or some other network circuitry, for instance fibre
> >>> connectors.
> >
> > So I was wondering if we would need an explicit:
> >   allwinner,use-internal-phy;
> > boolean DT property to signal the usage of the internal PHY?
> > Alternatively we could go with the negative version:
> >   allwinner,disable-internal-phy;
> >
> > Or what about introducing a new "allwinner,internal-mii-phy"
> >>> compatible
> > string for the *PHY* node and use that?
> >
> > I just want to avoid that we introduce a binding that causes us
> > headaches later. I think we can still fix this with a followup
> >>> patch
> > before the driver and its binding hit a release kernel.
> >
> > Cheers,
> > Andre.
> >
> 
>  I just see some patch, where "phy-mode = internal" is valid.
>  I will try to find a way to use it
> >>>
> >>> Can you provide a link?
> >>
> >> https://lkml.org/lkml/2017/6/23/479
> >>
> >>>
> >>> I'm not a fan of using phy-mode for this. There's no guarantee
> >>> what
> >>> mode the internal PHY uses. That's what phy-mode is for.
> >
> > I can understand Chen-Yu's concerns, but ...
> >
> >> For each soc the internal PHY mode is know and setted in
> >>> emac_variant/internal_phy
> >> So its not a problem.
> >
> > that is true as well, at least for now.
> >
> > So while I agree that having a separate property to indicate
> > the usage of the internal PHY would be nice, I am bit tempted
> > to use this easier approach and piggy back on the existing
> > phy-mode property.
> 
>  We're trying to fix an issue that works for now

Re: [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

2017-07-02 Thread André Przywara 
On 02/07/17 15:17, Maxime Ripard wrote:

Hi,

> On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
>>> If that is so fundamentally broken that this is the only benefit, I
>>> guess we might as well use some old-style SMP ops.
>>
>> Broken, for sure. Which is why I'm asking about the benefits of running
>> non-secure on something that has evidently been very badly integrated,
>> and for which non-secure is at best an afterthought.
>>
>> Now, if someone could try and run guests on this turd and report whether
>> this works correctly or not, that'd be an interesting data point.
>> Because in the absence of a TEE running on the secure side,
>> virtualization is basically the only thing you gain from running on the
>> non-secure side.
> 
> I just tried running Xen on it, with an adjustment similar to what
> Chen-Yu made in the kernel.
> 
> It fails at boot, and stops with:
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER20
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER24
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0

Those messages are normal and happen on every machine. The Xen VGIC
implementation cannot clear the active flag [1] (for more complex
reasons), and fortunately Linux and other OSes actually don't need it,
so we get away with it. What the kernel does here is to make sure that
no IRQ is active, which is basically a NOP on a pristine and just
initialized (V)GIC.

But you said that it stopped at boot? Are you sure that your Xen setup
works in the first place? Xen on A20 seems to be somewhat supported, by
maybe there is some other A83T speciality that gets in the way?

A more reliable and easier to debug test would be KVM, I guess.
You can use kvmtool[2] instead of QEMU if that is too complex to setup:
$ lkvm run -k zImage -p console=ttyS0
gives you a shell in a guest, if you want to have a proper rootfs:
$ lkvm run -k zImage -d somerootfs.img -p "console=ttyS0 root=/dev/vda"

Cheers,
Andre.

[1]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/vgic-v2.c;hb=HEAD#l487
[2] git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
(just checkout and "make" on the target)

> 
> It looks like it won't be easy to support. I guess we could just go
> for smp_ops, and if someone really cares one day about it, we'll
> always have the option to support it then.
> 
> 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] [PATCH 4/4] sunxi: enable EMAC for Banana Pi M3 board

2017-07-02 Thread Icenowy Zheng 
Banana Pi M3 board comes with the A83T EMAC connected to a Realtek
RTL8211E PHY, with a TX delay of 600ps.

Add the necessary DT parts and enable sun8i_emac in the defconfig.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/dts/sun8i-a83t-sinovoip-bpi-m3.dts | 13 +
 configs/Sinovoip_BPI_M3_defconfig   |  1 +
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/dts/sun8i-a83t-sinovoip-bpi-m3.dts 
b/arch/arm/dts/sun8i-a83t-sinovoip-bpi-m3.dts
index dfc16a0272..8e74227ad6 100644
--- a/arch/arm/dts/sun8i-a83t-sinovoip-bpi-m3.dts
+++ b/arch/arm/dts/sun8i-a83t-sinovoip-bpi-m3.dts
@@ -61,6 +61,19 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-mode = "rgmii";
+   phy = <>;
+   allwinner,tx-delay-ps = <600>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_b>;
diff --git a/configs/Sinovoip_BPI_M3_defconfig 
b/configs/Sinovoip_BPI_M3_defconfig
index 45eadcb443..ff068900a5 100644
--- a/configs/Sinovoip_BPI_M3_defconfig
+++ b/configs/Sinovoip_BPI_M3_defconfig
@@ -22,6 +22,7 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUN8I_EMAC=y
 CONFIG_AXP_DCDC5_VOLT=1200
 CONFIG_AXP_DLDO3_VOLT=2500
 CONFIG_AXP_SW_ON=y
-- 
2.13.0

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

[linux-sunxi] [PATCH 2/4] sun8i_emac: add support for setting EMAC TX/RX delay

2017-07-02 Thread Icenowy Zheng 
Some boards have the EMAC TX/RX lanes wired with a different length with
the clock lane, which can be workarounded by setting a TX/RX delay in
the EMAC.

This kind of delays are already defined in the newest device tree
binding of dwmac-sun8i, which has already entered linux-next.

Add support for setting these delays.

Signed-off-by: Icenowy Zheng 
---
 drivers/net/sun8i_emac.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index c071f5d3c3..4ba65c8a06 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -60,6 +60,10 @@
 #define SC_ETCS_MASK   GENMASK(1, 0)
 #define SC_ETCS_EXT_GMII   0x1
 #define SC_ETCS_INT_GMII   0x2
+#define SC_ETXDC_MASK  GENMASK(12, 10)
+#define SC_ETXDC_OFFSET10
+#define SC_ERXDC_MASK  GENMASK(9, 5)
+#define SC_ERXDC_OFFSET5
 
 #define CONFIG_MDIO_TIMEOUT(3 * CONFIG_SYS_HZ)
 
@@ -140,6 +144,8 @@ struct emac_eth_dev {
 struct sun8i_eth_pdata {
struct eth_pdata eth_pdata;
u32 reset_delays[3];
+   int tx_delay_ps;
+   int rx_delay_ps;
 };
 
 
@@ -273,7 +279,8 @@ static int sun8i_emac_set_syscon_ephy(struct emac_eth_dev 
*priv, u32 *reg)
return 0;
 }
 
-static int sun8i_emac_set_syscon(struct emac_eth_dev *priv)
+static int sun8i_emac_set_syscon(struct sun8i_eth_pdata *pdata,
+struct emac_eth_dev *priv)
 {
int ret;
u32 reg;
@@ -309,6 +316,14 @@ static int sun8i_emac_set_syscon(struct emac_eth_dev *priv)
return -EINVAL;
}
 
+   if (pdata->tx_delay_ps)
+   reg |= ((pdata->tx_delay_ps / 100) << SC_ETXDC_OFFSET)
+  & SC_ETXDC_MASK;
+
+   if (pdata->rx_delay_ps)
+   reg |= ((pdata->rx_delay_ps / 100) << SC_ERXDC_OFFSET)
+  & SC_ERXDC_MASK;
+
writel(reg, priv->sysctl_reg);
 
return 0;
@@ -748,7 +763,7 @@ static int sun8i_emac_eth_probe(struct udevice *dev)
priv->mac_reg = (void *)pdata->iobase;
 
sun8i_emac_board_setup(priv);
-   sun8i_emac_set_syscon(priv);
+   sun8i_emac_set_syscon((struct sun8i_eth_pdata *)pdata, priv);
 
sun8i_mdio_init(dev->name, dev);
priv->bus = miiphy_get_dev_by_name(dev->name);
@@ -821,6 +836,18 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct 
udevice *dev)
if (!priv->use_internal_phy)
parse_phy_pins(dev);
 
+   sun8i_pdata->tx_delay_ps = fdtdec_get_int(gd->fdt_blob, node,
+ "allwinner,tx-delay-ps", 0);
+   if (sun8i_pdata->tx_delay_ps < 0 || sun8i_pdata->tx_delay_ps > 700)
+   printf("%s: Invalid TX delay value %d\n", __func__,
+  sun8i_pdata->tx_delay_ps);
+
+   sun8i_pdata->rx_delay_ps = fdtdec_get_int(gd->fdt_blob, node,
+ "allwinner,rx-delay-ps", 0);
+   if (sun8i_pdata->rx_delay_ps < 0 || sun8i_pdata->rx_delay_ps > 3100)
+   printf("%s: Invalid RX delay value %d\n", __func__,
+  sun8i_pdata->rx_delay_ps);
+
 #ifdef CONFIG_DM_GPIO
if (fdtdec_get_bool(gd->fdt_blob, dev_of_offset(dev),
"snps,reset-active-low"))
-- 
2.13.0

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

[linux-sunxi] [PATCH 0/4] Allwinner A83T and Banana Pi M3 EMAC support

2017-07-02 Thread Icenowy Zheng 
This patchset is for Allwinner A83T and Banana Pi M3's Ethernet support.

The first and third patches are for A83T -- the first one enables the
sun8i_emac driver to be built on A83T, and the third one adds a stub
DT node.

The second patch is for all EMACs supported by sun8i_emac, which sets
the TX/RX delay. The TX delay is necessary on BPi M3 board for Ethernet
to behave properly.

The fourth patch is for BPi M3, including the DT part and the defconfig part.

With them enabled, we are now possible to use the Ethernet on BPi M3.
(I think PXE is possible, although my router doesn't support BOOTP and
I only tested pinging the router with fixed IP.)

Icenowy Zheng (4):
  sun8i_emac: disable build of EPHY clock code on non-H3/H5 platforms
  sun8i_emac: add support for setting EMAC TX/RX delay
  sunxi: add stub EMAC device node in A83T device tree
  sunxi: enable EMAC for Banana Pi M3 board

 arch/arm/dts/sun8i-a83t-sinovoip-bpi-m3.dts | 13 
 arch/arm/dts/sun8i-a83t.dtsi| 25 ++
 configs/Sinovoip_BPI_M3_defconfig   |  1 +
 drivers/net/sun8i_emac.c| 33 +++--
 4 files changed, 70 insertions(+), 2 deletions(-)

-- 
2.13.0

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

[linux-sunxi] [PATCH 1/4] sun8i_emac: disable build of EPHY clock code on non-H3/H5 platforms

2017-07-02 Thread Icenowy Zheng 
Sometimes the EPHY clock macros are not defined for non-H3/H5 platforms
(e.g. A83T), which makes the driver to fail to be built.

Only build the EPHY clock code when the SoC is H3/H5 by wrap them into
an #ifdef.

Signed-off-by: Icenowy Zheng 
---
 drivers/net/sun8i_emac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 09bbb2cdb5..c071f5d3c3 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -604,6 +604,7 @@ static void sun8i_emac_board_setup(struct emac_eth_dev 
*priv)
 {
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
+#if defined(CONFIG_MACH_SUNXI_H3_H5)
if (priv->use_internal_phy) {
/* Set clock gating for ephy */
setbits_le32(>bus_gate4, BIT(AHB_GATE_OFFSET_EPHY));
@@ -611,6 +612,7 @@ static void sun8i_emac_board_setup(struct emac_eth_dev 
*priv)
/* Deassert EPHY */
setbits_le32(>ahb_reset2_cfg, BIT(AHB_RESET_OFFSET_EPHY));
}
+#endif
 
/* Set clock gating for emac */
setbits_le32(>ahb_gate0, BIT(AHB_GATE_OFFSET_GMAC));
-- 
2.13.0

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

[linux-sunxi] [PATCH 3/4] sunxi: add stub EMAC device node in A83T device tree

2017-07-02 Thread Icenowy Zheng 
The Allwinner A83T SoC has an EMAC which is already supported by
sun8i_emac driver in U-Boot now.

Add a stub device node for it.

The device node cannot work for Linux, because it now lacks the proper
clock definition; however, it can satisfy sun8i_emac driver in U-Boot.

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

diff --git a/arch/arm/dts/sun8i-a83t.dtsi b/arch/arm/dts/sun8i-a83t.dtsi
index 0fe73e173f..9aac3a7929 100644
--- a/arch/arm/dts/sun8i-a83t.dtsi
+++ b/arch/arm/dts/sun8i-a83t.dtsi
@@ -52,6 +52,10 @@
 / {
interrupt-parent = <>;
 
+   aliases {
+   ethernet0 = 
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -166,6 +170,17 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
 
+   emac_rgmii_pins: emac-rgmii {
+   allwinner,pins = "PD2", "PD3", "PD4", "PD5",
+   "PD6", "PD7", "PD11",
+   "PD12", "PD13", "PD14",
+   "PD18", "PD19", "PD21",
+   "PD22", "PD23";
+   allwinner,function = "emac";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
mmc0_pins_a: mmc0@0 {
allwinner,pins = "PF0", "PF1", "PF2",
 "PF3", "PF4", "PF5";
@@ -214,6 +229,16 @@
status = "disabled";
};
 
+   emac: ethernet@1c3 {
+   compatible = "allwinner,sun8i-a83t-emac";
+   reg = <0x01c3 0x104>, <0x01c00030 0x4>;
+   reg-names = "emac", "syscon";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
-- 
2.13.0

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

Re: [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

2017-07-02 Thread icenowy 

在 2017-06-23 21:50，Chen-Yu Tsai 写道：

On Fri, Jun 23, 2017 at 9:39 PM,   wrote:

在 2017-06-23 21:35，Maxime Ripard 写道：


On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@aosc.io wrote:


在 2017-06-07 20:51，Marc Zyngier 写道：
> On 07/06/17 13:12, Icenowy Zheng wrote:
> >
> >
> > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
> >  写到:
> > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
> > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> > > >  wrote:
> > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
> > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
> > > > > > 
> > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> > > > > > > Tsai  写到:
> > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
> > > > > > > > 
> > > wrote:
> > > > > > > > > As we have now a basical implementation
> > > > > > > > > of PSCI for A83T, enable
> > > > > > > > > non-secure boot support and PSCI on A83T now.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Icenowy Zheng 
> > > > > > > > > ---
> > > > > > > > >  arch/arm/mach-sunxi/Kconfig | 4 
> > > > > > > > >  1 file changed, 4 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm/mach-sunxi/Kconfig
> > > > > > > > b/arch/arm/mach-sunxi/Kconfig
> > > > > > > > > index 7ced838d6a..31d29de428 100644
> > > > > > > > > --- a/arch/arm/mach-sunxi/Kconfig
> > > > > > > > > +++ b/arch/arm/mach-sunxi/Kconfig
> > > > > > > > > @@ -98,8 +98,12 @@ config MACH_SUN8I_A33
> > > > > > > > >  config MACH_SUN8I_A83T
> > > > > > > > > bool "sun8i (Allwinner A83T)"
> > > > > > > > > select CPU_V7
> > > > > > > > > +   select CPU_V7_HAS_NONSEC
> > > > > > > > > +   select CPU_V7_HAS_VIRT
> > > > > > > > > +   select ARCH_SUPPORT_PSCI
> > > > > > > > > select SUNXI_GEN_SUN6I
> > > > > > > > > select SUPPORT_SPL
> > > > > > > > > +   select ARMV7_BOOT_SEC_DEFAULT if
> > > > > > > > > OLD_SUNXI_KERNEL_COMPAT
> > > > > > > >
> > > > > > > > The kernel does not work yet. Please have it boot to
> > > > > > > > secure by
> > > default
> > > > > > > > regardless of the kernel. We can have it
> > > > > > > > boot non-secure once the
> > > > > > > > kernel
> > > > > > > > has been working for a reasonable amount of time.
> > > > > > > >
> > > > > > > > I don't want clueless users coming and asking why it
> > > > > > > > suddenly
> > > stopped
> > > > > > > > working. This should be an experimental feature.
> > > > > > >
> > > > > > > Maybe you should send out the fix, and tag them to also
> > > > > > > apply to
> > > > > > > stable tree.
> > > > > > >
> > > > > > > GIC is really broken, UP systems only work by chance. We
> > > > > > > shouldn't depend on this behavior.
> > > > > >
> > > > > > As I previously explained, it is not the GIC that is broken.
> > > > > > I
> > > believe
> > > > > > the GIC is working exactly as it is supposed to with
> > > > > > regards to its
> > > > > > input signals.
> > > > > >
> > > > > > Allwinner's security extensions implementation simply does
> > > > > > not
> > > properly
> > > > > > forward the AXI secure bit when the e-fuse's secure bit isn't
> > > burned.
> > >
> > > Arghh. Puke. Now I remember this, and I wish I didn't...
> > >
> > > > > Is that on all revisions, or just the revB ?
> > > >
> > > > It's the A80, but I'm guessing the same applies to the A83T. It's
> > > more
> > > > of a guess really, but I think it's a logical one. If the e-fuse
> > > isn't
> > > > programmed, the TZPC doesn't work, and access to all secure
> > > peripherals
> > > > still work, even from non-secure mode. The only one that
> > > > does work is
> > > > the secure SRAM.
> > > >
> > > > The GIC still has the banked secure/non-secure registers, just
> > > > that
> > > all
> > > > cores access the secure bank, even when in non-secure mode. The
> > > workaround
> > > > is to use the alias set of non-secure registers in Linux.
> > >
> > > That's a pretty dire workaround. Also, I expect that secure writes
> > > to
> > > GICV/GICH will not do the right thing. At this point, what is the
> > > requirement for running non-secure?
> >
> > Write Secure Boot eFUSE, which will break *all* existing softwares.
>
> Don't do it, then.
>
> Any other *real* use case for running non-secure? As in "Stuff that
> would benefit to a user"? Because if the answer is "none" as I suspect
> it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?



I guess it all depends on the answer to Marc's question. If
virtualization doesn't work, then we don't have any incentive anymore
to use PSCI and that would be a sensible option, yes.



I remember non-secure is a dependency for virtualization (HYP mode).

So if we do not do the workaround on GIC, we won't