Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-05-02 Thread Hans Ulli Kroll
Hi

On Wed, 2 May 2018, Joel Wirāmu Pauling wrote:

> It's Cortina but arm7 IIRC; there was a NDA available SDK for it based on
> 2.6.something - which I started to go through the process of getting access
> too a few years ago, but the platform was bought out by Realtek who
> scuttled it as it was in competition with their own designs.
> 
> The Almond+ has Zwave and Zigbee on PCI bus and Qualcomm AR9880 AC and N
> radios, and a USB3 hub. Jtag fully exposed and there is even a Touchscreen
> (which I think is I2C based). It would be a nice target to get working with
> trunk.
> 

Looking at wikidevi, this should be this one
https://wikidevi.com/wiki/Securifi_Almond%2B

There is also a spec datasheet on 
http://www.cortina-access.com/dhp/download/203/996/61

Hans Ulli
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-05-02 Thread Joel Wirāmu Pauling
It's Cortina but arm7 IIRC; there was a NDA available SDK for it based on
2.6.something - which I started to go through the process of getting access
too a few years ago, but the platform was bought out by Realtek who
scuttled it as it was in competition with their own designs.

The Almond+ has Zwave and Zigbee on PCI bus and Qualcomm AR9880 AC and N
radios, and a USB3 hub. Jtag fully exposed and there is even a Touchscreen
(which I think is I2C based). It would be a nice target to get working with
trunk.

I can post uboot and jtag when I am back in front of it.

-Joel

On 2 May 2018 at 20:04, Linus Walleij  wrote:

> On Wed, May 2, 2018 at 12:41 AM, Joel Wirāmu Pauling 
> wrote:
>
> > any chance for support for the
> > Goldengate SoC found in the Almond+. Currently attempting to reuse it
> for a
> > home automation project but it's ancient kernel is terrible and even
> doing
> > basic things like vlans are horribly broken with the Securfi hacked up
> > NutsOS that runs on top of ancient openwrt.
>
> No idea what SoC that is, sorry, even less do I have any development
> board or anything for it... if it is a Cortina or StorLink SoC there is
> chance
> you can reuse some of the drivers for the basic IP blocks but that is
> as much as I can help.
>
> Yours,
> Linus Walleij
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-05-02 Thread Linus Walleij
On Wed, May 2, 2018 at 12:41 AM, Joel Wirāmu Pauling  wrote:

> any chance for support for the
> Goldengate SoC found in the Almond+. Currently attempting to reuse it for a
> home automation project but it's ancient kernel is terrible and even doing
> basic things like vlans are horribly broken with the Securfi hacked up
> NutsOS that runs on top of ancient openwrt.

No idea what SoC that is, sorry, even less do I have any development
board or anything for it... if it is a Cortina or StorLink SoC there is chance
you can reuse some of the drivers for the basic IP blocks but that is
as much as I can help.

Yours,
Linus Walleij
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-05-01 Thread Joel Wirāmu Pauling
I have been Eyeing your Gemni patches - any chance for support for the
Goldengate SoC found in the Almond+. Currently attempting to reuse it for a
home automation project but it's ancient kernel is terrible and even doing
basic things like vlans are horribly broken with the Securfi hacked up
NutsOS that runs on top of ancient openwrt.

-Joel

On 5 April 2018 at 08:34, Linus Walleij  wrote:

> This patch set forward-ports Gemini to v4.14 with as good
> support as I can get.
>
> I don't know if all or any patches actually make it through
> to the devel list. They are also posted here:
>
> https://dflund.se/~triad/krad/gemini/openwrt/
>
> It would be nice if we could apply this and get a working
> modernized base for the Gemini platforms.
>
> The v4.14 is a bit patchy. With v4.16 we will be looking
> pretty neat.
>
> Linus Walleij (4):
>   firmware-utils: Add the DNS-313 image header tool
>   gemini: Forward-port to v4.14
>   gemini: Add kernel v4.14 patches
>   gemini: Delete kernel 4.4 patches
>
>  target/linux/gemini/Makefile   |   15 +-
>  .../linux/gemini/base-files/etc/board.d/03_hdparm  |   14 +
>  .../base-files/lib/preinit/05_set_ether_mac_gemini |   25 +-
>  target/linux/gemini/config-4.14|  587 
>  target/linux/gemini/config-4.4 |  165 -
>  .../files/arch/arm/mach-gemini/include/mach/gmac.h |   21 -
>  .../linux/gemini/files/arch/arm/mach-gemini/pci.c  |  318 --
>  .../linux/gemini/files/drivers/ata/pata_gemini.c   |  234 --
>  .../files/drivers/net/ethernet/gemini/Kconfig  |   31 -
>  .../files/drivers/net/ethernet/gemini/Makefile |5 -
>  .../files/drivers/net/ethernet/gemini/sl351x.c | 2340 -
>  .../files/drivers/net/ethernet/gemini/sl351x_hw.h  | 1436 
>  .../gemini/files/drivers/usb/host/ehci-fotg2.c |  258 --
>  .../gemini/files/drivers/watchdog/gemini_wdt.c |  378 --
>  target/linux/gemini/image/Makefile |  166 +-
>  target/linux/gemini/image/dns313-header/Makefile   |   34 +
>  .../gemini/image/dns313-header/dns313-header.c |  239 ++
>  target/linux/gemini/image/slask.mk |   56 +
>  .../0001-cache-patch-from-OpenWRT.patch}   |9 +
>  ...0002-pinctrl-gemini-Add-missing-functions.patch |   33 +
>  ...ARM-dts-Add-TVE200-to-the-Gemini-SoC-DTSI.patch |   51 +
>  ...rl-Add-skew-delay-pin-config-and-bindings.patch |   73 +
>  ...0005-pinctrl-gemini-Use-generic-DT-parser.patch |  112 +
>  ...-gemini-Implement-clock-skew-delay-config.patch |  280 ++
>  .../0007-pinctrl-gemini-Fix-GMAC-groups.patch  |  186 +
>  ...nctrl-gemini-Fix-missing-pad-descriptions.patch |   27 +
>  ...inctrl-gemini-Add-two-missing-GPIO-groups.patch |   25 +
>  ...0-pinctrl-gemini-Fix-usage-of-3512-groups.patch |   25 +
>  ...trl-gemini-Support-drive-strength-setting.patch |  198 ++
>  ...d-ethernet-PHYs-to-the-a-bunch-of-Geminis.patch |  113 +
>  ...s-Add-basic-devicetree-for-D-Link-DNS-313.patch |  272 ++
>  ...RM-dts-Flags-D-Link-DIR-685-I2C-bus-gpios.patch |   27 +
>  ...0015-ARM-dts-Add-PCI-to-WBD111-and-WBD222.patch |   74 +
>  ...-Add-TVE-TVC-and-ILI9322-panel-to-DIR-685.patch |  113 +
>  ...tchdog-gemini-ftwdt010-rename-DT-bindings.patch |   88 +
>  ...gemini-ftwdt010-rename-driver-and-symbols.patch |  527 +++
>  ...watchdog-ftwdt010-Make-interrupt-optional.patch |   93 +
>  .../0020-soc-Add-SoC-driver-for-Gemini.patch   |  113 +
>  ...t-Add-DT-bindings-for-the-Gemini-ethernet.patch |  119 +
>  ...t-Add-a-driver-for-Gemini-gigabit-etherne.patch | 3661
> 
>  ...23-ARM-dts-Add-ethernet-to-the-Gemini-SoC.patch |   74 +
>  .../0024-net-gemini-Depend-on-HAS_IOMEM.patch  |   30 +
>  ...-dts-Set-D-Link-DNS-313-SATA-to-muxmode-0.patch |   36 +
>  ...r-gemini-poweroff-Avoid-spurious-poweroff.patch |   80 +
>  ...sb-host-add-DT-bindings-for-faraday-fotg2.patch |   65 +
>  ...28-usb-host-fotg2-add-device-tree-probing.patch |   61 +
>  ...usb-host-fotg2-add-silicon-clock-handling.patch |   99 +
>  ...b-host-fotg2-add-Gemini-specific-handling.patch |  131 +
>  ...RM-dts-Add-the-FOTG210-USB-host-to-Gemini.patch |  178 +
>  .../linux/gemini/patches-4.4/050-gpio-to-irq.patch |   21 -
>  .../110-watchdog-add-gemini_wdt-driver.patch   |   29 -
>  .../111-arm-gemini-add-watchdog-device.patch   |   33 -
>  .../112-arm-gemini-register-watchdog-devices.patch |   40 -
>  .../120-net-add-gemini-gmac-driver.patch   |   20 -
>  .../121-arm-gemini-add-gmac-device.patch   |   85 -
>  .../122-arm-gemini-register-ethernet.patch |  227 --
>  .../130-usb-ehci-add-fot2g-driver.patch|  133 -
>  .../131-arm-gemini-add-usb-device.patch|   77 -
>  .../patches-4.4/132-arm-gemini-register-usb.patch  |   65 -
>  .../140-arm-gemini-add-pci-support.patch   |   66 -
>  .../linux/gemini/patches-4.4/150-gemini-pata.patch |  192 -
>  target/linux/gemini/raidsonic/config-default   |5 -
>  target/linux/gemini/rai

Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-17 Thread Linus Walleij
On Tue, Apr 17, 2018 at 11:23 AM, Linus Walleij
 wrote:
> On Tue, Apr 17, 2018 at 12:34 AM, Roman Yeryomin  wrote:
>
>> I've found why it didn't work:
>> [5.845199] Warning! fotg210_hcd should always be loaded before uhci_hcd
>> and ohci_hcd, not after
>>
>> After fixing kernel config and applying your patch it works.
>> So your patch works and is needed indeed.
>
> I always wondered about that thing, it looks a bit puzzleing, something is not
> right...
>
> The SQ201 has a VIA Vectro VT6212LUSB 2.0 USB controller on PCI,
> which is of course EHCI. EHCI req

Damned google mail.

EHCI requires UHCI to be activated in Kconfig.

So to support all Geminis we are between a rock and a hard place
here... if I can get the fotg210 working on some board I can maybe
look into it.

But just supporting fotg210 is fine for now, the SQ201 is not a
regression, it's new stuff.

Yours,
Linus Walleij
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-17 Thread Linus Walleij
On Tue, Apr 17, 2018 at 12:34 AM, Roman Yeryomin  wrote:

> I've found why it didn't work:
> [5.845199] Warning! fotg210_hcd should always be loaded before uhci_hcd
> and ohci_hcd, not after
>
> After fixing kernel config and applying your patch it works.
> So your patch works and is needed indeed.

I always wondered about that thing, it looks a bit puzzleing, something is not
right...

The SQ201 has a VIA Vectro VT6212LUSB 2.0 USB controller on PCI,
which is of course EHCI. EHCI req
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-16 Thread Roman Yeryomin

On 2018-04-15 20:22, Roman Yeryomin wrote:

On 2018-04-14 20:36, Hans Ulli Kroll wrote:

Hi Roman

On Tue, 10 Apr 2018, Linus Walleij wrote:

On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin  
wrote:


> I have tested them quickly yesterday on nas4220b board. Although I've
> managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> And I didn't check anything else.
> I didn't yet look at the code but before I dive there I have a question: did
> you have a chance to test it yourself on any of the boards? And if yes,
> which one?



I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself

+diff --git a/drivers/usb/host/fotg210-hcd.c 
b/drivers/usb/host/fotg210-hcd.c

+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
 b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct usb_hcd
*hcd, u16 typeReq, u16 wValue,
+   /* see what we found out */
+   temp = check_reset_complete(fotg210, wIndex, status_reg,
+   fotg210_readl(fotg210, status_reg));
++
++  /* restart schedule */
++  fotg210->command |= CMD_RUN;
++			fotg210_writel(fotg210, fotg210->command, 
&fotg210->regs->command);

+   }
+
+   if (!(temp & (PORT_RESUME|PORT_RESET))) {
+--
+2.16.2
+


Didn't work for me :(



I've found why it didn't work:
[5.845199] Warning! fotg210_hcd should always be loaded before 
uhci_hcd and ohci_hcd, not after


After fixing kernel config and applying your patch it works.
So your patch works and is needed indeed.

But there are other problems.
Second USB (USB1) port cannot be initialized and only USB0 is working:
[5.843831] fotg210_hcd: FOTG210 Host Controller (EHCI) Driver
[5.844298] pinctrl-gemini 4000.syscon:pinctrl: ACTIVATE function 
"usb" with group "usbgrp"

[5.845067] fotg210-hcd 6800.usb: initialized Gemini PHY
[5.845095] fotg210-hcd 6800.usb: Faraday USB2.0 Host Controller
[5.845176] fotg210-hcd 6800.usb: new USB bus registered, 
assigned bus number 1

[5.845696] fotg210-hcd 6800.usb: irq 29, io mem 0x6800
[5.877212] fotg210-hcd 6800.usb: USB 2.0 started, EHCI 1.00
[5.880314] hub 1-0:1.0: USB hub found
[5.880546] hub 1-0:1.0: 1 port detected
[5.904768] pinctrl-gemini 4000.syscon:pinctrl: pin T6 USB GNDA 
U20 already requested by 6800.usb; cannot claim for 6900.usb
[5.904807] pinctrl-gemini 4000.syscon:pinctrl: pin-305 
(6900.usb) status -22
[5.904845] pinctrl-gemini 4000.syscon:pinctrl: could not request 
pin 305 (T6 USB GNDA U20) from group usbgrp  on device pinctrl-gemini
[5.904872] fotg210-hcd 6900.usb: Error applying setting, reverse 
things back

[5.904928] fotg210-hcd: probe of 6900.usb failed with error -22

After removing pinctrl from USB1 it is initialized but then only USB1 is 
working, USB0 is seen but there are no interrupts.
Didn't yet look at the code, maybe you will know where to fix right 
away.


Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-16 Thread Roman Yeryomin

On 2018-04-17 00:36, Linus Walleij wrote:

On Mon, Apr 16, 2018 at 2:00 AM, Roman Yeryomin  wrote:


Looking at your tree...
I don't see any (affecting) differences in ethernet driver itself.
Probably it's something else.. MDIO?



After looking into ethernet I've found several issues.
1. skew delay settings were not ported from old driver to dts for 
nas4220b

board
2. kernel config in you patches (accidentally?) disabled bridge 
support
3. driver crashes if you try to disable unused gmac in dts because of 
access

to uninitialized port(0|1) member of struct gemini_ethernet


Ouch. Sorry for my sucky backport. :(


So after fixing all above ethernet on nas4220b is working ok.


You are my hero :)


Can you confirm that after enabling bridge support back (just remove
CONFIG_BRIDGE from gemini kernel config and rebuild) ethernet comes up 
on

D-link boards? That is with default network config.


I think it's best if I test your entire set-up on the D-Link routers.
Do you have a git branch I can grab?


Will try to prepare that tomorrow.
Target kernel config must be cleaned up, it's redundant in some places 
and overrides some things which it should not.
I've managed to get usb working, it was kernel config error again (and 
Hans' patch he sent earlier is actually working). But still usb has 
problems, e.g. I couldn't get both ports working, only one of them.

SATA seems to be working out of the box, which is good!


Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-16 Thread Linus Walleij
On Mon, Apr 16, 2018 at 2:00 AM, Roman Yeryomin  wrote:

>> Looking at your tree...
>> I don't see any (affecting) differences in ethernet driver itself.
>> Probably it's something else.. MDIO?
>>
>
> After looking into ethernet I've found several issues.
> 1. skew delay settings were not ported from old driver to dts for nas4220b
> board
> 2. kernel config in you patches (accidentally?) disabled bridge support
> 3. driver crashes if you try to disable unused gmac in dts because of access
> to uninitialized port(0|1) member of struct gemini_ethernet

Ouch. Sorry for my sucky backport. :(

> So after fixing all above ethernet on nas4220b is working ok.

You are my hero :)

> Can you confirm that after enabling bridge support back (just remove
> CONFIG_BRIDGE from gemini kernel config and rebuild) ethernet comes up on
> D-link boards? That is with default network config.

I think it's best if I test your entire set-up on the D-Link routers.
Do you have a git branch I can grab?

DNS-313 has working ethernet, DIR-685 is not yet working because
of missing upstream RTL8366RB support (working on it!) so it is
still a bit of WIP.

Yours,
Linus Walleij
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-15 Thread Roman Yeryomin

On 2018-04-12 00:37, Roman Yeryomin wrote:

On 2018-04-11 00:51, Linus Walleij wrote:
On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin  
wrote:



I have tested them quickly yesterday on nas4220b board. Although I've
managed to boot it (had to fix rootfs image) ethernet and usb didn't 
work.

And I didn't check anything else.
I didn't yet look at the code but before I dive there I have a 
question: did
you have a chance to test it yourself on any of the boards? And if 
yes,

which one?


Hm I tested mostly the rootfs and that the kernel would get to prompt.
But for my D-Link devices I tested mostly with kernel v4.16 because
I'm working close to mainline. Testing now it seems network is not
coming up here either :/ as it works like a charm on v4.16 it must
be some minor issue.


Looking at your tree...
I don't see any (affecting) differences in ethernet driver itself.
Probably it's something else.. MDIO?



After looking into ethernet I've found several issues.
1. skew delay settings were not ported from old driver to dts for 
nas4220b board

2. kernel config in you patches (accidentally?) disabled bridge support
3. driver crashes if you try to disable unused gmac in dts because of 
access to uninitialized port(0|1) member of struct gemini_ethernet


So after fixing all above ethernet on nas4220b is working ok.

Can you confirm that after enabling bridge support back (just remove 
CONFIG_BRIDGE from gemini kernel config and rebuild) ethernet comes up 
on D-link boards? That is with default network config.



Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-15 Thread Roman Yeryomin

On 2018-04-14 20:36, Hans Ulli Kroll wrote:

Hi Roman

On Tue, 10 Apr 2018, Linus Walleij wrote:

On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin  
wrote:


> I have tested them quickly yesterday on nas4220b board. Although I've
> managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> And I didn't check anything else.
> I didn't yet look at the code but before I dive there I have a question: did
> you have a chance to test it yourself on any of the boards? And if yes,
> which one?



I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself

+diff --git a/drivers/usb/host/fotg210-hcd.c 
b/drivers/usb/host/fotg210-hcd.c

+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
 b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct usb_hcd
*hcd, u16 typeReq, u16 wValue,
+   /* see what we found out */
+   temp = check_reset_complete(fotg210, wIndex, status_reg,
+   fotg210_readl(fotg210, status_reg));
++
++  /* restart schedule */
++  fotg210->command |= CMD_RUN;
++			fotg210_writel(fotg210, fotg210->command, 
&fotg210->regs->command);

+   }
+
+   if (!(temp & (PORT_RESUME|PORT_RESET))) {
+--
+2.16.2
+


Didn't work for me :(


Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-14 Thread Hans Ulli Kroll
Hi Roman

On Tue, 10 Apr 2018, Linus Walleij wrote:

> On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin  wrote:
> 
> > I have tested them quickly yesterday on nas4220b board. Although I've
> > managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> > And I didn't check anything else.
> > I didn't yet look at the code but before I dive there I have a question: did
> > you have a chance to test it yourself on any of the boards? And if yes,
> > which one?
> 

I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself

From 10be6c15addac0bdb9c2d196d450aee1fcb2070b Mon Sep 17 00:00:00 2001
From: Hans Ulli Kroll 
Date: Sat, 14 Apr 2018 19:13:11 +0200
Subject: [PATCH] gemini: fix fotg2 stall after port reset

Signed-off-by: Hans Ulli Kroll 
---
 ...b-host-fotg2-restart-hcd-after-port-reset.patch | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch

diff --git 
a/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch
 
b/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch
new file mode 100644
index 00..3f1de0d107
--- /dev/null
+++ 
b/target/linux/gemini/patches-4.14/0032-usb-host-fotg2-restart-hcd-after-port-reset.patch
@@ -0,0 +1,31 @@
+From 731a2896e11b4e6a8d252e6c14edb1b09dbfcd46 Mon Sep 17 00:00:00 2001
+From: Hans Ulli Kroll 
+Date: Sat, 14 Apr 2018 18:49:57 +0200
+Subject: [PATCH 1/2] usb: host: fotg2: restart hcd after port reset
+
+on Gemini SoC FOTG2 stalls after port reset
+rerstart the hcd.
+
+Signed-off-by: Hans Ulli Kroll 
+---
+ drivers/usb/host/fotg210-hcd.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
 b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
+   /* see what we found out */
+   temp = check_reset_complete(fotg210, wIndex, status_reg,
+   fotg210_readl(fotg210, status_reg));
++
++  /* restart schedule */
++  fotg210->command |= CMD_RUN;
++  fotg210_writel(fotg210, fotg210->command, 
&fotg210->regs->command);
+   }
+ 
+   if (!(temp & (PORT_RESUME|PORT_RESET))) {
+-- 
+2.16.2
+
-- 
2.16.2

I have some other patch here which disable the resume after 
usb_hcd_resume_root_hub()
But this make no sence to me.

Greetings
Hans Ulli Kroll
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-11 Thread Roman Yeryomin

On 2018-04-11 00:51, Linus Walleij wrote:

On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin  wrote:


I have tested them quickly yesterday on nas4220b board. Although I've
managed to boot it (had to fix rootfs image) ethernet and usb didn't 
work.

And I didn't check anything else.
I didn't yet look at the code but before I dive there I have a 
question: did
you have a chance to test it yourself on any of the boards? And if 
yes,

which one?


Hm I tested mostly the rootfs and that the kernel would get to prompt.
But for my D-Link devices I tested mostly with kernel v4.16 because
I'm working close to mainline. Testing now it seems network is not
coming up here either :/ as it works like a charm on v4.16 it must
be some minor issue.


Looking at your tree...
I don't see any (affecting) differences in ethernet driver itself. 
Probably it's something else.. MDIO?



I would guess Hans Ulli Kroll can help with USB, I just applied the
patches and have nothing to test it with. I never used USB...


Hans, did you have a chance to test 4.14 (or 4.16) on any of gemini 
boards?



The v4.16 stack is pretty small and there the network for sure
works (not a finished patch set):
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=openwrt-v4.16

If it's hard to get v4.14 to backport we could maybe aim to
use v4.16 instead? Or is there some OpenWRT baselining involved?


Yeah, generic comes first and that's not 10min work :)


Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-10 Thread Linus Walleij
On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin  wrote:

> I have tested them quickly yesterday on nas4220b board. Although I've
> managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> And I didn't check anything else.
> I didn't yet look at the code but before I dive there I have a question: did
> you have a chance to test it yourself on any of the boards? And if yes,
> which one?

Hm I tested mostly the rootfs and that the kernel would get to prompt.
But for my D-Link devices I tested mostly with kernel v4.16 because
I'm working close to mainline. Testing now it seems network is not
coming up here either :/ as it works like a charm on v4.16 it must
be some minor issue.

I would guess Hans Ulli Kroll can help with USB, I just applied the
patches and have nothing to test it with. I never used USB...

The v4.16 stack is pretty small and there the network for sure
works (not a finished patch set):
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=openwrt-v4.16

If it's hard to get v4.14 to backport we could maybe aim to
use v4.16 instead? Or is there some OpenWRT baselining involved?

Yours,
Linus Walleij
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-09 Thread Roman Yeryomin

On 2018-04-04 23:34, Linus Walleij wrote:

This patch set forward-ports Gemini to v4.14 with as good
support as I can get.

I don't know if all or any patches actually make it through
to the devel list. They are also posted here:

https://dflund.se/~triad/krad/gemini/openwrt/

It would be nice if we could apply this and get a working
modernized base for the Gemini platforms.

The v4.14 is a bit patchy. With v4.16 we will be looking
pretty neat.

Linus Walleij (4):
  firmware-utils: Add the DNS-313 image header tool
  gemini: Forward-port to v4.14
  gemini: Add kernel v4.14 patches
  gemini: Delete kernel 4.4 patches



Hi Linus, thanks for the patches!
I have tested them quickly yesterday on nas4220b board. Although I've 
managed to boot it (had to fix rootfs image) ethernet and usb didn't 
work. And I didn't check anything else.
I didn't yet look at the code but before I dive there I have a question: 
did you have a chance to test it yourself on any of the boards? And if 
yes, which one?


Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel