Not sure if this helps, but the recent Cisco Meraki AP drop includes a newish PHY driver for the at8033/8035.
The GPL source is at http://dl.meraki.net/linux/meraki-firmware-sources-r23-20150601.tar.bz2 and a copy of the actual file can be found at https://github.com/riptidewave93/meraki-linux/blob/linux-3.4-r23-20150601/drivers/net/ethernet/atheros/ag7240/phys/athr_ar8033_phy.c On Mon, Jul 6, 2015 at 6:26 AM, Christian Lamparter <chunk...@googlemail.com > wrote: > On Friday, July 03, 2015 12:29:32 PM Sven Eckelmann wrote: > > > Sven, I've seen you did quite a bit of work on the OM5P-AN > > > with the same F1E-PHY. I went through the code from Atheros' > > > original driver SDK v17 (which was part of the GPL source > > > for the mynet). Apart from tx delay handling, everything > > > else matches perfectly, so the tx/rx delay code should be > > > enabled by default for this chip on all platforms without > > > needing any platform data overwrites. > > > > Interesting, I don't have the SDK and I am only using OpenWrt. So I > cannot say > > anything about the Atheros driver. But sounds like you are right. At > least all > > recent devices I had in my hand required this change. > Oh, I figured you have access to some of Qualcomm Atheros' SDKs > and most importantly: some documentations from Qualcomm Atheros? > I hoped you could confirm or disconfirm based on the documents. > > > I also saw your fixup_rgmii_tx_delay delay change. I would ack when you > submit > > a change like this. Just don't forget that the pll_1000 has also to be > changed > > (especially when you move the default values to at803x.c): > > > > --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-om5p.c > > +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om5p.c > > @@ -154,7 +154,8 @@ static struct i2c_board_info om5pan_i2c_devs[] > __initdata = { > > static struct at803x_platform_data om5p_an_at803x_data = { > > .disable_smarteee = 1, > > .enable_rgmii_rx_delay = 1, > > - .enable_rgmii_tx_delay = 1, > > + .enable_rgmii_tx_delay = 0, > > + .fixup_rgmii_tx_delay = 1, > > }; > > > > static struct mdio_board_info om5p_an_mdio0_info[] = { > > @@ -201,7 +202,7 @@ static void __init om5p_an_setup(void) > > ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; > > ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev; > > ath79_eth0_data.phy_mask = BIT(7); > > - ath79_eth0_pll_data.pll_1000 = 0x02000000; > > + ath79_eth0_pll_data.pll_1000 = 0x0e000000; > > ath79_eth0_pll_data.pll_100 = 0x00000101; > > ath79_eth0_pll_data.pll_10 = 0x00001313; > > ath79_register_eth(0); > > > > > > I don't have the equipment to check the actual signals (as you said in an > > earlier mail) - only some people which complained very loud when their > long > > cable setup didn't work. :) > Long cable... That's a good point, I think I never tested the AT8035 with > anything beyond a 5m / 16 feet cable. > > > Maybe there are some non atheros SoC's out there which would have > problems > > when you would change the default behavior of the AT8035. > I've been looking around for devices with an AT8035. And I found a few > gems. > > < > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/200978.html > > > <https://forum.openwrt.org/viewtopic.php?id=42896>< > https://dev.openwrt.org/ticket/13203> > ... > (The AT8035 is also used in some of the new HomePlug AV2 equipment) > > As far as I can tell, the defaults only seem to work for the 100mbps. > This makes sense, since the F1E has different PLLs and rx/tx delay > settings. Fixing this "globally" might actually be a good thing. At > least I'll give it a try. > > > I'm interested to hear from any other devices which have > > > a AT803x. Also, please let me know where to get the GPL > > > tars for the devices. > > > > I have forwarded your mail to the person which is handling the actual > > firmware builds of the OM5P-AN. He will contact you later and provide > > the sources. > Oh, that might be helpful yes. I can also post the sources from Western > Digital's S17_SSDK [The Ethernet driver SDK is part of their GPL.tar.gz]. > > Thanks, > Christian > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
