History log of /freebsd-11.0-release/sys/mips/atheros/ar724x_pci.c
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 303975 11-Aug-2016 gjb

Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE
cycle.

Prune svn:mergeinfo from the new branch, and rename it to RC1.

Update __FreeBSD_version.

Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and
the dvd1.iso packages population.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 302408 08-Jul-2016 gjb

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation


# 295880 22-Feb-2016 skra

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


# 294883 27-Jan-2016 jhibbits

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


# 287911 17-Sep-2015 bz

Remove more unused variables leading to compile time errors.


# 287882 16-Sep-2015 zbb

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


# 285121 04-Jul-2015 adrian

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".


# 272239 28-Sep-2014 adrian

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


# 272237 28-Sep-2014 adrian

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.


# 261870 14-Feb-2014 adrian

Disable this check for now; it fails on the AR9344 PCI fixup code.

I'll make it conditional later.

Tested:

* DB120


# 257338 29-Oct-2013 nwhitehorn

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


# 239706 26-Aug-2012 adrian

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.


# 234485 20-Apr-2012 adrian

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.


# 229765 07-Jan-2012 adrian

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.


# 227843 22-Nov-2011 marius

- 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.


# 221307 01-May-2011 adrian

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


# 221255 30-Apr-2011 adrian

Flip off debugging for now.


# 221254 30-Apr-2011 adrian

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