291 Commits

Author SHA1 Message Date
andrew
e2a65d5cfa Add support for the uart classes to set their default register shift value.
This is needed with the pl011 driver. Before this change it would default
to a shift of 0, however the hardware places the registers at 4-byte
addresses meaning the value should be 2.

This patch fixes this for the pl011 when configured using the fdt. The
other drivers have a default value of 0 to keep this a no-op.

MFC after:	1 week
2015-04-11 17:16:23 +00:00
adrian
11776dfc59 Begin moving support for board MAC addresses over to being explicitly defined.
A lot of these dinky atheros based MIPS boards don't have a nice, well,
anything consistent defining their MAC addresses for things.

The Atheros reference design boards will happily put MAC addresses
into the wifi module calibration data like they should, and individual
ethernet MAC addresses into the calibration area in flash.
That makes my life easy - "hint.arge.X.eeprommac=<addr>" reads from
that flash address to extract a MAC, and everything works fine.

However, aside from some very well behaved vendors (eg the Carambola 2
board), everyone else does something odd.

eg:

* a MAC address in the environment (eg ubiquiti routerstation/RSPRO)
   that you derive arge0/arge1 MAC addresses from.
* a MAC address in flash that you derive arge0/arge1 MAC addresses from.
* The wifi devices having their own MAC addresses in calibration data,
  like normal.
* The wifi devices having a fixed, default or garbage value for a MAC
  address in calibration data, and it has to be derived from the
  system MAC.

So to support this complete nonsense of a situation, there needs to be
a few hacks:

* The "board" MAC address needs to be derived from somewhere and squirreled
  away.  For now it's either redboot or a MAC address stored in calibration
  flash.

* Then, a "map" set of hints to populate kenv with some MAC addresses
  that are derived/local, based on the board address.  Each board has
  a totally different idea of what you do to derive things, so each
  map entry has an "offset" (+ve or -ve) that's added to the board
  MAC address.

* Then if_arge (and later, if_ath) should check kenv for said hint and
  if it's found, use that rather than the EEPROM MAC address - which may
  be totally garbage and not actually work right.

In order to do this, I've undone some of the custom redboot expecting
hacks in if_arge and the stuff that magically adds one to the MAC
address supplied by the board - instead, as I continue to test this
out on more hardware, I'll update the hints file with a map explaining
(a) where the board MAC should come from, and (b) what offsets to use
for each device.

The aim is to have all of the tplink, dlink and other random hardware
we run on have valid MAC addresses at boot, so (a) people don't get
random B:S:Dx:x ethernet MACs, and (b) the wifi MAC is valid
so it works rather than trying to use an invalid address that
actually upsets systems (think: multicast bit set in BSSID.)

Tested:

* TP-Link TL_WDR3600 - subsequent commits will add the hints map
  and the if_ath support.

TODO:

* Since this is -HEAD, and I'm all for debugging, there's a lot of
  printf()s in here.  They'll eventually go under bootverbose.
* I'd like to turn the macaddr routines into something available
  to all drivers - too many places hand-roll random MAC addresses
  and parser stuff.  I'd rather it just be shared code.
  However, that'll require more formal review.
* More boards.
2015-03-28 23:40:29 +00:00
adrian
0e84465cb2 Add GPIO function mux configuration for AR934x SoCs.
The AR934x (and maybe others in this family) have a more complicated
GPIO mux.  The AR71xx just has a single function register for a handful
of "GPIO or X" options, however the AR934x allows for one of roughly
100 behaviours for each GPIO pin.

So, this adds a quick hints based mechanism to configure the output
functions, which is required for some of the more interesting board
configurations.  Specifically, some use external LNAs to improve
RX, and without the MUX/output configured right, the 2GHz RX side
will be plain terrible.

It doesn't yet configure the "input" side yet; I'll add that if
it's required.

Tested:

* TP-Link TL-WDR3600, testing 2GHz STA/AP modes, checking some
  basic RX sensitivity things (ie, "can I see the AP on the other
  side of the apartment that intentionally has poor signal reception
  from where I am right now.")

Whilst here, fix a silly bug in the maxpin routine; I was missing
a break.
2015-03-21 06:08:35 +00:00
adrian
f5a9460e2b add QCA955x PCIe configuration registers.
These are /not/ absolute addresses, as the QCA955x SoC has 2 PCIe RC's
(and 1 PCIe EP.)
2015-03-21 06:00:46 +00:00
adrian
9ce94e7c25 Note that the AR724x PCIe registers are actually from the PCI_CTRL
register range.
2015-03-21 05:59:45 +00:00
adrian
af70fecfb9 Use ar71xx_mac_addr_random_init() instead of a hand-rolled random
MAC address.
2015-03-15 21:56:41 +00:00
adrian
74b6ad6fe4 Start fleshing out some MAC address helper functions.
A lot of these embedded boards don't have a unique MAC address per
device stored somewhere unique - sometimes they'll have one MAC
for both arge NICs; someties they'll have one MAC for both arge NICs
/and/ the ath NICs.  In these instances, we need to derive device
specific MAC addresses from the base MAC address.

These functions will be used by some follow-up code that'll slot
into if_arge and if_ath.
2015-03-15 21:56:12 +00:00
adrian
92c375f66c Modify the if_arge code to use a /fixed/ media mode when it's configured.
Otherwise, the initial media speed would change if a PHY is hooked up,
sending PHY speed notifications.  For the AP135 at least, the RGMII
PHY has a static speed/duplex configured and if the PHY plumbing
attaches the PHY to the if_arge interface, the first link speed change
from 1000/full will set the MAC to something that isn't useful.

This shouldn't affect any other platforms - everything I looked at is
using hard-coded speed/duplex as static, as they're facing a switch
with no PHY attached.
2015-03-08 22:03:54 +00:00
adrian
8f1977d6ce Add ethernet MAC DDR flush hookups for QCA955x.
Tested:

* AP135
2015-03-04 03:52:50 +00:00
adrian
bc2ba88d1c Add DDR flush registers for QCA955x. 2015-03-04 03:51:54 +00:00
adrian
b865675364 [QCA955x] make the USB EHCI interrupts shareable.
There's two EHCI controllers in the QCA955x SoCs - they have different
interrupts available via various demux registers, but they both tie to
IP3.

So for now, allow them to be sharable so they can hang off of IP3.
2015-03-02 02:08:43 +00:00
adrian
1ee8c32e32 Add initial QCA955x support to if_arge.c.
Tested:

* AP135 development board, QCA9558 SoC.
2015-03-02 01:53:47 +00:00
adrian
b5a61383ac Add a MII mode for SGMII.
This appears on the AR934x and later chips, although it's not
something that's programmed via the arge0/arge1 register space.
It's just cosmetic.
2015-03-02 01:23:59 +00:00
adrian
a065c9d2dc Add very initial QCA955x awareness to the GPIO code.
There's a lot more to come - the QCA955x has a bunch more GPIO MUX
configuration, reminiscent of what the ARM chips let you do - but
it'll have to come later.
2015-03-01 07:00:34 +00:00
adrian
90aba284a2 Flesh out some more QCA955x ethernet PLL setup. 2015-03-01 06:59:32 +00:00
adrian
3664d4bf70 Add Ethernet PLL values for the QCA955x.
These are the same as the AR934x.

Obtained from:	Linux openwrt
2015-03-01 06:54:59 +00:00
adrian
0525b8f3b9 Make QCA955X_GMAC_REG_ETH_CFG defined like most other registers like this. 2015-03-01 06:52:23 +00:00
adrian
9709e28ab3 Add QCA955x support to the EHCI setup path.
Tested:

* QCA AP135 development board, USB rootfs.
2015-03-01 06:05:01 +00:00
sbruno
fce5f51901 The linux driver code for the MDIO bus does a read-after-write
which seems to be required on MIPS74k platforms for correct
behaviour.

Reviewed by:	adrian
2015-02-02 17:33:00 +00:00
loos
5e1a593992 Implement GPIO_GET_BUS() method for all GPIO drivers.
Add helper routines to deal with attach and detach of gpiobus and gpioc
devices that are common to all drivers.
2015-01-31 19:32:14 +00:00
loos
b76f0f0c1f Replace spaces with tabs, this will easier future changes on softc
structure.

No functional changes.
2015-01-31 12:43:30 +00:00
loos
a2924f5fee Clean up and fix the device detach routine and the failure path on GPIO
drivers.

This paves the way for upcoming work.
2015-01-31 12:17:07 +00:00
adrian
be883ba4fe Make the apb.c code optional behind ar71xx_apb rather than standard.
The QCA955x has more mux interrupts going on - and the AR934x actually does,
but I cheated and assigned wlan and pcie to the same interrupt line.
They are, there's just a status register mux that I should've been using.

Luckily this isn't too bad a change in itself - almost all of the
Atheros MIPS configurations use a _BASE file to inherit from.
Except PB92, which I should really fix up at some point.

The AR934x will use the legacy apb for now until I write its replacement.

The QCA955x SoC I'm doing bring-up on will have a separate qca955x_apb.c
implementation that includes hooking into IP2/IP3 and doing further
interrupt demuxing as appropriate.
2015-01-06 07:43:07 +00:00
adrian
e8134b8e7d Add an APB base/size for the QCA955X for an upcoming QCA955x specific
APB mux.

It's larger than the AR71xx because it needs to replace the nexus
for some devices (notably wifi) and the wifi driver (if_ath_ahb.c)
reads the SPI data directly at early boot whilst it's memory mapped
in.

I'm eventually going to rip it out and replace it with a firmware
interface similar to what exists for the if_ath_pci.c path -
something early on (likely something new that I'll write) will
suck in the calibration data into a firmware API blob and that'll
be accessed from if_ath_ahb.c.

But, one thing at a time.

Tested:

* QCA955x SoC, AP135 development board
2015-01-06 07:37:33 +00:00
adrian
eeb397aba0 The QCA955x USB init path doesn't require any of this, so delete it.
Obtained from:	Linux/OpenWRT
2015-01-06 07:35:05 +00:00
hselasky
63ec340209 Add 64-bit DMA support in the XHCI controller driver.
- Fix some comments and whitespace while at it.

MFC after:	1 month
Submitted by:	marius@
2015-01-05 20:22:18 +00:00
adrian
72a716f320 Remove the remnants of the OpenWRT/Linux bits that this was based off
of.

Obtained from:	Linux/OpenWRT
2015-01-05 05:30:07 +00:00
adrian
ad79abc364 Oops - missed refclk.
Tested:

* AP135, QCA955x SoC
2015-01-05 05:26:57 +00:00
adrian
d119230495 Add initial Qualcomm Atheros QCA955x SoC support.
This adds the initial frequency poking and configures up enough
for it to boot and spit out data over the console.

There's still a whole bunch of work to do in the reset path
and devices to support this thing, but hey, it's alive!

ath> go 0x80050100
## Starting application at 0x80050100 ...
CPU platform: Atheros AR9558 rev 0
CPU Frequency=720 MHz
CPU DDR Frequency=600 MHz
CPU AHB Frequency=200 MHz
platform frequency: 720 MHz
CPU reference clock: 0 MHz
CPU MDIO clock: 40 MHz

Done at:	hackathon
Obtained from:	Linux OpenWRT, Qualcomm Atheros
2015-01-05 02:06:26 +00:00
adrian
fca8e06eab ACK interrupts on the new SoCs. 2015-01-05 02:00:41 +00:00
adrian
d2d1da27e3 add QCA955x SoC types. 2015-01-05 01:59:44 +00:00
adrian
8a2fc581eb Add QCA955x series register definitions.
There's likely a bunch of register offsets that I have to add the
register window base to before I use them.

Done at:	Hackathon
Obtained from:	Linux OpenWRT
2015-01-05 01:44:23 +00:00
adrian
92005e6093 Add a GPIO output mux configuration method.
The AR934x and later (which will turn up eventually) have a new GPIO
output configuration option - a real MUX rather than a "GPIO or this
function."

For now I'm squirreling it away in the CPU code just so it's done -
I may move this to the GPIO layer later.

Specifically, this is required for setting up some boards that have
external receive side LNA (low noise amplifier) that gets switched on/off
by the on-chip wireless MAC.  If we don't add this support for those
boards then we'll end up with really poor performance.

(I don't yet have one of those APs, but it'll likely show up in a week.)

Obtained from:	Linux OpenWRT
2015-01-03 06:55:58 +00:00
adrian
a505f86799 Add AR934x specific GPIO functions and output MUX configuration.
Obtained from:	Linux OpenWRT
2015-01-03 06:35:53 +00:00
adrian
1bc6b102d6 Add AR934x GPIO function configuration.
Obtained from:	Linux OpenWRT
2015-01-03 06:30:30 +00:00
loos
9ad347c496 Moves all the duplicate code to a single function.
Verify for invalid modes and unwanted flags before pass the new flags to
driver.
2014-11-18 17:22:08 +00:00
loos
7dd1b73c38 Make the GPIO children attach to the first unit available and not only to
unit 0.

It seems that this 'simplification' was copied to all GPIO drivers in tree.

This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.
2014-10-28 18:33:59 +00:00
davide
e88bd26b3f Follow up to r225617. In order to maximize the re-usability of kernel code
in userland rename in-kernel getenv()/setenv() to kern_setenv()/kern_getenv().
This fixes a namespace collision with libc symbols.

Submitted by:   kmacy
Tested by:      make universe
2014-10-16 18:04:43 +00:00
adrian
9d3af9561f Fix the AR724x PCIe glue to correctly probe the BAR on AR7240 devices.
There's a bug in the AR7240 PCIe hardware where a correct BAR will end
up having the device disappear.

It turns out that for the device address it should be all 0's.

However, this meant that the PCI probe code would try writing 0xffffffff
in to see how big the window was, read back 0x0, and think the window
was 32 bits.  It then ended up calculating a resource size of 0 bytes,
failed to find anything via an rman call, and this would fail to attach.

I have quite absolutely no idea how in the various planes of existence
this particular bit of code and how it worked with the PCI bus code
ever worked.  But, well, it did.

Tested:

* Atheros AP93 - AR7240 + AR9280 reference board
2014-09-28 07:27:58 +00:00
adrian
16e362e70a Fix the ar724x PCI config space register read.
It was doing incorrect things with masks.  This was fixed in the
AR71xx codebase but it wasn't yet fixed in the AR724x code.

This ended up having config space reads return larger/incorrect values
in some situations.

Tested:

* AR7240

TODO:

* test ar7241, AR7242, and AR934x.
2014-09-28 05:28:11 +00:00
glebius
375a1fa081 Mechanically convert to if_inc_counter(). 2014-09-19 09:19:49 +00:00
adrian
7a71bbe497 Commit some sins in the name of "oh god oh god I don't really want to
be able to claim I know how the UART code works."

* Just return 115200 as the current baud rate. I should cache it in the
  device struct and return that but I'm lazy right now.
* don't error out on other ioctl settings for now, just silently ignore them.
* remove some code that was copied from the 8250 driver that isn't needed
  any longer.

Tested:

* AR9331, Carambola-2 board.
2014-07-27 05:44:42 +00:00
loos
b8da8e9a79 Properly advertise that if_arge can handle long frames (if_arge is set to
handle packets up to 1536 bytes)

This fixes the need to frag that could happen when using vlans on top of
if_arge (which is a common case for the use the switch ports as individual
NICs).

Previously to this commit any vlan setup with if_arge as parent would have
the MTU of the parent interface reduced by the size of dot1q header
(4 bytes).

Tested on TP-Link 1043ND (where the WAN port is just a switch port setup to
tag packets in a different VLAN than the LAN ports).

Reported and tested by:	Harm Weites (harm at weites.com)
2014-07-03 20:16:48 +00:00
jhb
e8769d6be2 Fix various NIC drivers to properly cleanup static DMA resources.
In particular, don't check the value of the bus_dma map against NULL
to determine if either bus_dmamem_alloc() or bus_dmamap_load() succeeded.
Instead, assume that bus_dmamap_load() succeeeded (and thus that
bus_dmamap_unload() should be called) if the bus address for a resource
is non-zero, and assume that bus_dmamem_alloc() succeeded (and thus
that bus_dmamem_free() should be called) if the virtual address for a
resource is not NULL.

In many cases these bugs could result in leaks when a driver was detached.

Reviewed by:	yongari
MFC after:	2 weeks
2014-06-11 14:53:58 +00:00
loos
d36599654d Do not configure all pins as outputs as this can lead to short circuits when
the GPIO pin is connected to a push button (or other devices).

Instead keep the boot loader settings.

Calling ar71xx_gpio_pin_configure() with DEFAULT_CAPS was probably a
mistake and was causing all the pins to be set as outputs.
2014-05-10 13:16:04 +00:00
loos
20e87023bd Remove an old mistake of mine. This has sneak in the code i sent to gonzo
at that time, but AFAIK it is only used on routerboards.

Enabling GPIO_FUNC_SPI_CS[1|2]_EN will claim the use of gpio pins 0 and 1
respectivelly for use as SPI CS pins.

When really needed, this can still be enabled on kernel hints using the
function_set and function_clear knobs.
2014-05-10 12:58:18 +00:00
loos
2cc32d626a Add support for reading RouterBoard's memory which is passed by the loader
(RouterBOOT).

Tested on RouterBoards, various and on RSPRO, TP-Link MR3x20
(for regressions).
2014-05-09 14:02:18 +00:00
loos
d57ffd9d8e When a GPIO pin is set to be turned on by kernel hints (hint.gpio.X.pinon)
make sure the GPIO pin is configured as an output as this is not always the
case.
2014-05-09 13:44:42 +00:00
adrian
8b24253e00 Extend the Atheros SoC support to include a method to enable/disable
the NAND flash controller.

Add the AR934x NAND flash controller reset routines.
(It's different on subsequent SoCs.)

Tested:

* AR9344, Atheros DB120 reference platform

Obtained from:	OpenWRT
2014-03-18 12:19:39 +00:00
adrian
97d88da1c6 Add the AR934x NAND flash controller register definitions.
Obtained from:	OpenWRT
2014-03-18 12:18:35 +00:00