Commit Graph

19 Commits

Author SHA1 Message Date
pfg
e75d1be6b3 sys/mips: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
2017-11-27 15:07:26 +00:00
adrian
0c3e9fef3e [ar724x] put in explicit memory barriers now that read/write register no longer
implicitly do them.

They were removed as part of my "fix this to actually work" a few commits
ago in this file.

Tested:

* AP93, AR7240 + AR9280 PCI
2017-07-06 04:56:23 +00:00
imp
ce9844cd72 Convert PCIe Hot Plug to using pci_request_feature
Convert PCIe hot plug support over to asking the firmware, if any, for
permission to use the HotPlug hardware. Implement pci_request_feature
for ACPI. All other host pci connections to allowing all valid feature
requests.

Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
skra
f4b6499ab5 As <machine/pmap.h> is included from <vm/pmap.h>, there is no need to
include it explicitly when <vm/pmap.h> is already included.

Reviewed by:	alc, kib
Differential Revision:	https://reviews.freebsd.org/D5373
2016-02-22 09:02:20 +00:00
jhibbits
31bb8ee5bd Convert rman to use rman_res_t instead of u_long
Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources.  For
now, this is still compatible with u_long.

This is step one in migrating rman to use uintmax_t for resources instead of
u_long.

Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.

This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.

Reviewed By: jhb
Sponsored by:	Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
bz
2fb4661e45 Remove more unused variables leading to compile time errors. 2015-09-17 12:04:41 +00:00
zbb
95f13176f5 Add domain support to PCI bus allocation
When the system has more than a single PCI domain, the bus numbers
are not unique, thus they cannot be used for "pci" device numbering.
Change bus numbers to -1 (i.e. to-be-determined automatically)
wherever the code did not care about domains.

Reviewed by:   jhb
Obtained from: Semihalf
Sponsored by:  The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3406
2015-09-16 23:34:51 +00:00
adrian
e44e1c10f7 Reshuffle all of the DDR flush operations into a single switch/mux,
and start teaching subsystems about it.

The Atheros MIPS platforms don't guarantee any kind of FIFO consistency
with interrupts in hardware.  So software needs to do a flush when it
receives an interrupt and before it calls the interrupt handler.

There are new ones for the QCA934x and QCA955x, so do a few things:

* Get rid of the individual ones (for ethernet and IP2);
* Create a mux and enum listing all the variations on DDR flushes;
* replace the uses of IP2 with the relevant one (which will typically
  be "PCI" here);
* call the USB DDR flush before calling the real USB interrupt handlers;
* call the ethernet one upon receiving an interrupt that's for us,
  rather than never calling it during operation.

Tested:

* QCA9558 (TP-Link archer c7 v2)
* AR9331 (Carambola 2)

TODO:

* PCI, USB, ethernet, etc need to do a double-check to see if the
  interrupt was truely for them before doing the DDR.  For now I
  prefer "correct" over "fast".
2015-07-04 03:05:57 +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
adrian
27f203fbd6 Disable this check for now; it fails on the AR9344 PCI fixup code.
I'll make it conditional later.

Tested:

* DB120
2014-02-14 05:22:28 +00:00
nwhitehorn
e0788b0985 Devices that rely on hints or identify routines for discovery need to
return BUS_PROBE_NOWILDCARD from their probe routines to avoid claiming
wildcard devices on their parent bus. Do a sweep through the MIPS tree.

MFC after: 2 weeks
2013-10-29 14:07:31 +00:00
adrian
c789e6f653 Ensure that BAR(0) is set for the PCI slot before the ath(4) PCI registers
are written out.

This allows EEPROM-less NICs on the AR7241 PCIe bus to be correctly
initialised.

Tested:

* AP91 (AR7240+AR9285) - the existing board support didn't break;
* AP99 (AR7241+AR9287) - this fixed the configuration of the AR9287 PCI.
2012-08-26 04:39:20 +00:00
adrian
6152dc39f2 Introduce the matching PCI ath(4) fixup code from ar71xx_pci into
ar724x_pci.c.

* Move out the code which populates the firmware into ar71xx_fixup.c
* Shuffle around the ar724x fixup code to match what the ar71xx fixup
  code does.

I've validated this on an AR7240 with AR9285 on-board NIC. It doesn't
yet load, as the AR9285 EEPROM code needs to be made "flash aware."

TODO:

* Validate that I haven't broken AR71xx
* Test AR9285/AR9287 onboard NICs, complete with EEPROM code changes
* Port over the needed BAR hacks for AR7240, AR7241 and AR7242 from
  Linux OpenWRT.  The current WAR has only been tested on the AR7240
  and I'm not sure the way the BAR register is treated is "right".
  The "fixup" method here is right when setting the BAR for local access -
  ie, the BAR address is either 0xffff (AR7240) or 0x1000ffff (AR7241/AR7242),
  but the ath9k-fixup.c code (Linux OpenWRT) does this when setting the
  initial "fixup" BAR.  It then restores the original BAR.
  I'll have to read the ar724x PCI bus glue to see what other special cases
  await.
2012-04-20 08:26:05 +00:00
adrian
6707636c2f Fix the ar724x shift calculation when writing to the PCI config space.
This was preventing the ath driver from being loaded at runtime.
It worked fine when compiled statically into the kernel but not when
kldload'ed after the system booted.

The root cause was that PCIR_INTLINE (register 60) was being
overwritten by zeros when register 62 was being written to.
A subsequent read of this register would return 0, and thus
the rest of the PCI glue assumed an IRQ resource had already
been allocated.  This caused the device to fail to attach at
runtime as the device itself didn't contain any IRQ resources.

TODO: go back over the ar71xx and ar724x PCI config read/write
code and ensure it's correct.
2012-01-07 04:13:25 +00:00
marius
17e14c6132 - There's no need to overwrite the default device method with the default
one. Interestingly, these are actually the default for quite some time
  (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
  since r52045) but even recently added device drivers do this unnecessarily.
  Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
  Discussed with: jhb
- Also while at it, use __FBSDID.
2011-11-22 21:28:20 +00:00
adrian
a10a894ed3 Some AR724x PCIe fixes, which should wrap up the first round
of endian-ness issues with the AR724x.

From Luiz:

* Fix the bus space tag used so endian-ness is correctly handled;
* Only do the workaround for the AR7240; AR7241/AR7242 (PB92)
  don't require this

From me:

* Add a read flush from openwrt

Submitted by:	Luiz Otavio O Souza
2011-05-01 23:32:37 +00:00
adrian
e032e84ff6 Flip off debugging for now. 2011-04-30 11:40:31 +00:00
adrian
ac09e9d74c Add some initial PCIe bridge support for the AR724x chipsets.
This is reported to work on the AR7240 based Ubiquiti Rocket M5
but I haven't tested it on that hardware. I also don't yet have
it fully working on the AR7242 based development board here;
probe/attach functions but the register space resource looks like
the endian-ness is wrong (0x10000000 instead of 0x00001000).o

Further digging will be required.

Submitted by:	Luiz Otavio O Souza
2011-04-30 11:36:16 +00:00