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