qcom_gcc: begin refactoring sys/dev/qcom_gcc to support multiple chipsets

Although the driver structure is almost supportive of multiple
chipsets, there's a lot of subtle hard coded IPQ4018 assumpti

qcom_gcc: begin refactoring sys/dev/qcom_gcc to support multiple chipsets

Although the driver structure is almost supportive of multiple
chipsets, there's a lot of subtle hard coded IPQ4018 assumptions
here.

This is a partial refactor of the driver in order to have a single
qcom_gcc driver that will eventually support multiple chipsets.

* rename qcom_gcc_ipq4018 -> qcom_gcc
* remove the ipq4018 specific naming from things
* create a table to drive probe/attach, with a chipset id to
use during attach
* migrate the clock register accessors to not be ipq4018 specific
* migrate the reset register accessors to not be ipq4018 specific

Note this won't compile (yet) for an arm64 kernel because there's
a hard-coded clock tree for an earlier 64 bit MSM part in
sys/arm64/qualcomm/qcom_gcc.c . That will need to be rolled into this
driver.

Differential Revision: https://reviews.freebsd.org/D49683

show more ...

arm kernel config: clean up whitespace

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

arm kernel config: clean up whitespace

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.

show more ...

arm: conf: Remove options EXT_RESOURCES

It is now unused in kernel code.

MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33837

ar40xx_switch: add initial switch for the IPQ4018/IPQ4019.

Summary:

This switch is based off of the AR8327/AR8337 external switch/PHY.
However unlike the AR8327/AR8337 it itself doesn't have any PH

ar40xx_switch: add initial switch for the IPQ4018/IPQ4019.

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.

show more ...

qcom_mdio: add initial IPQ4018 MDIO support

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/IPQ40

qcom_mdio: add initial IPQ4018 MDIO support

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

show more ...

qcom_dwc3: add initial Qualcomm SoC DWC3 controller glue

This adds some very simple DWC3 glue for the IPQ4018/IPQ4019.
Other chipsets introduce reset line iteration, some further
clock line iteratio

qcom_dwc3: add initial Qualcomm SoC DWC3 controller glue

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.

show more ...

ipq4018_usb_phy: add USB 2.0 and 3.0 PHY support

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 w

ipq4018_usb_phy: add USB 2.0 and 3.0 PHY support

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.

show more ...

qcom_tcsr: add initial top control and status register (TCSR) support

The Qualcomm TCSR is some top level glue between multiple IP blocks,
both for doing configuration of said IP blocks, some IPC be

qcom_tcsr: add initial top control and status register (TCSR) support

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.

show more ...

qcom_qup: add initial v1/v2 QUP SPI driver

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

qcom_qup: add initial v1/v2 QUP SPI driver

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

show more ...

qca: add cpufreq into the build

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 fr

qca: add cpufreq into the build

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.

show more ...

qca: add the TLMM code into the build

This adds the IPQ4018 TLMM code into the IPQ4018 build.

Differential Revision: https://reviews.freebsd.org/D33554

ipq4018: add qcom-gcc-ipq4018 and dependencies into the build

* 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

ipq4018: add qcom-gcc-ipq4018 and dependencies into the build

* 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

show more ...

qcom: add initial SCM legacy API

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

qcom: add initial SCM legacy API

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

show more ...

ipq4018: add SoC reset and qcom_rnd driver

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 ha

ipq4018: add SoC reset and qcom_rnd driver

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

show more ...

arm: add a std.qca for 32 bit armv7 platforms

This is the minimal config required to boot on the IPQ4018 SoC
and likely future ones as well in this family.

qcom_gcc: begin refactoring sys/dev/qcom_gcc to support multiple chipsets

Although the driver structure is almost supportive of multiple
chipsets, there's a lot of subtle hard coded IPQ4018 assumpti

qcom_gcc: begin refactoring sys/dev/qcom_gcc to support multiple chipsets

Although the driver structure is almost supportive of multiple
chipsets, there's a lot of subtle hard coded IPQ4018 assumptions
here.

This is a partial refactor of the driver in order to have a single
qcom_gcc driver that will eventually support multiple chipsets.

* rename qcom_gcc_ipq4018 -> qcom_gcc
* remove the ipq4018 specific naming from things
* create a table to drive probe/attach, with a chipset id to
use during attach
* migrate the clock register accessors to not be ipq4018 specific
* migrate the reset register accessors to not be ipq4018 specific

Note this won't compile (yet) for an arm64 kernel because there's
a hard-coded clock tree for an earlier 64 bit MSM part in
sys/arm64/qualcomm/qcom_gcc.c . That will need to be rolled into this
driver.

Differential Revision: https://reviews.freebsd.org/D49683

show more ...

arm kernel config: clean up whitespace

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

arm kernel config: clean up whitespace

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.

show more ...

arm: conf: Remove options EXT_RESOURCES

It is now unused in kernel code.

MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33837

ar40xx_switch: add initial switch for the IPQ4018/IPQ4019.

Summary:

This switch is based off of the AR8327/AR8337 external switch/PHY.
However unlike the AR8327/AR8337 it itself doesn't have any PH

ar40xx_switch: add initial switch for the IPQ4018/IPQ4019.

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.

show more ...

qcom_mdio: add initial IPQ4018 MDIO support

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/IPQ40

qcom_mdio: add initial IPQ4018 MDIO support

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

show more ...

qcom_dwc3: add initial Qualcomm SoC DWC3 controller glue

This adds some very simple DWC3 glue for the IPQ4018/IPQ4019.
Other chipsets introduce reset line iteration, some further
clock line iteratio

qcom_dwc3: add initial Qualcomm SoC DWC3 controller glue

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.

show more ...

ipq4018_usb_phy: add USB 2.0 and 3.0 PHY support

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 w

ipq4018_usb_phy: add USB 2.0 and 3.0 PHY support

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.

show more ...

qcom_tcsr: add initial top control and status register (TCSR) support

The Qualcomm TCSR is some top level glue between multiple IP blocks,
both for doing configuration of said IP blocks, some IPC be

qcom_tcsr: add initial top control and status register (TCSR) support

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.

show more ...

qcom_qup: add initial v1/v2 QUP SPI driver

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

qcom_qup: add initial v1/v2 QUP SPI driver

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

show more ...

qca: add cpufreq into the build

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 fr

qca: add cpufreq into the build

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.

show more ...