Most options in kernel config files use "options<space><tab>OPTION".
This allows the option to be commented out without shifting columns.
A few options had two tabs, and some had spaces. Make them consistent.
Summary:
This switch is based off of the AR8327/AR8337 external switch/PHY.
However unlike the AR8327/AR8337 it itself doesn't have any PHYs;
instead an external PHY connects to it using the PSGMII port.
Differential Revision: https://reviews.freebsd.org/D34112
Reviewed by: manu
This code is inspired by the ar40xx code in openwrt, which itself
is based on the Qualcomm QCA-SSDK. Both of these sources are, amusingly,
BSD licenced - and thus I have included some of the comments in the
hardware workaround paths to document some of the magic numbers.
This adds support for the IPQ4018/IPQ4019 MDIO bus. This is used to
talk to external PHYs and switches. (There's an internal switch
in the IPQ4018/IPQ4019 as well, but it's accessible via MMIO/AXI.)
Differential Revision: https://reviews.freebsd.org/D34110
Reviewed by: manu
This adds some very simple DWC3 glue for the IPQ4018/IPQ4019.
Other chipsets introduce reset line iteration, some further
clock line iteration and some customisations; I'll look at adding
those later.
This is enough to finally bring up USB 3.0 on my IPQ4018 ASUS
RT-58U router.
This adds the USB 2.0 and 3.0 PHY support for the IPQ4018/IPQ4019.
All it really needs to do is gate the relevant clocks on/off in the
right order with the right delays.
The Qualcomm TCSR is some top level glue between multiple IP blocks,
both for doing configuration of said IP blocks, some IPC between
them (mostly between multiple execution environments - eg trustzone
and non-TZ), and interrupt status bits for them.
However, for the IPQ4018/IPQ4019, it only is used as a small subset
of IP block configuration. As for what it actually gets used as
for other Qualcomm chipsets? Well, that'll have to wait.
It's a bit of a mess in linux and openwrt. See, every different
SoC support branch ends up with some different TCSR code for it.
So instead, I'm going to land a single TCSR driver that I'm going
to use for the IPQ4018/IPQ4019. When I add the next chipset, I'll
figure out how to organise things so there's a single TCSR driver
that works for multiple platforms.
The Qualcomm Universal Peripherals Engine (QUP) is a unified SPI and I2C
peripheral that ships with a variety of Qualcomm SoCs.
It supports three transfer modes - single PIO, block PIO and DMA.
This driver only supports the single PIO mode, which is enough to
bootstrap the rest of the SPI NAND/NOR support and means I can do
things like read the Wifi calibration data from NOR. It has some
hardware support code for the other transfer modes as well as
some support for split transfers (ie, transfers with no read or
write phase), but I haven't yet implemented those.
This driver is based on four sources - the linux driver, the u-boot
driver, some initial work done for APQ8064 by mmel@, and the APQ8064
Technical Reference Manual which is surprisingly free and open to
read. The linux and u-boot drivers approach a variety of things
completely differently, from how PIO is done, the hardware support
for re-ordering bytes in a transfer word and how the CS lines
are used.
Tested:
* IPQ4018, SPI to NAND/NOR flash, PIO only
Now that the clock drivers are in the tree, the cpufreq driver will
"just work".
Tested:
* IPQ4018, testing performance of dd from /dev/zero->/dev/null at
each frequency step.
* add the extres stuff into the build, I'm going to end up leveraging
all of it
* include the qcom-gcc-ipq4018 driver which currently implements the hwreset
side of the API.
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
This is a very simple implementation of Qualcomm's SCM API.
It is just the structure/field definitions and the atomic SCM
call which doesn't use the structs yet - it uses the field
definitions inside registers.
I've tested that setting the cold boot address via the atomic
API is fine - Linux does the same thing. But not all SCM calls
can be done via the legacy API.
This is a reimplementation based on the Linux qualcomm SCM legacy
code and definitions.
Tested:
* Qualcomm IPQ4018 AP, as part of other changes for doing SMP bring-up
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
Summary:
This is enough to allow this ASUS router to reboot successfully.
I tried the watchdog path and although it fires, it isn't rebooting!
It's just hanging, likely somewhere in TZ.
This is the MVP required to initialise and consume random data from
the QCA PRNG hardware found on the IPQ401x.
Test Plan: * ASUS RT-AC58U router, IPQ4019
Subscribers: imp, andrew
Differential Revision: https://reviews.freebsd.org/D32723
