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