Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Instead of busy waiting.

Also request the IRQ before starting the reset sequence.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Rob Herring <robh@kernel.org>

Signed-off-by: Rob Herring <robh@kernel.org>

Not working yet...

Signed-off-by: Rob Herring <robh@kernel.org>

This needs more work to handle different GPU models and revisions, but
should match what t860 r2p0 gets in the vendor driver.

Signed-off-by: Rob Herring <robh@kernel.org>

This is for debugging because we should never page fault.

Signed-off-by: Rob Herring <robh@kernel.org>

Signed-off-by: Rob Herring <robh@kernel.org>

On a prime import, we need to map the buffer into the gpu address space,
and only non-imported GEM objects should have their pages put.

These changes keep kmscube from hanging on exit.

Signed-off-by: Rob Herring <robh@kernel.org>

Signed-off-by: Rob Herring <robh@kernel.org>

Turn them on and never look back.

Signed-off-by: Rob Herring <robh@kernel.org>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Robin Murphy authored Feb 15, 2019 and Tomeu Vizoso committed Feb 18, 2019

Describe the Bluetooth portion of the Ampak combo module - this is
either an AP6356S or an AP6212 depending on the board variant, but
there are no relevant compatibility differences between the two.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

Robin Murphy authored Jan 14, 2019 and Tomeu Vizoso committed Feb 18, 2019

For whatever reason, the sdmmc_dectn function isn't working properly
as-is, and microSD insertion and removal goes unnoticed. Using the pin
as a GPIO interrupt instead is rather noisy without any debouncing, but
is good enough to make it useful until someone feels inclined to figure
out how the vendor kernel/firmware gets the dedicated function to work
with no obvious difference in the pinmux/GRF configuration. Let's also
take the opportunity to tweak the node name so that all related pins
end up grouped together in the compiled DTB.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

Robin Murphy authored Jan 14, 2019 and Tomeu Vizoso committed Feb 18, 2019

In common with most Rockchip reference designs, NanoPC-T4 has a passive
IR receiver connected to PWM3. In lieu of a specialised driver for
PWM-based IR pulse measurement, running the pin as a GPIO with the basic
driver works perfectly well.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

Robin Murphy authored Jan 14, 2019 and Tomeu Vizoso committed Feb 18, 2019

The nanopi4 boards differ primarily in their power trees, with the main
5V and 3.3V rails having very different topologies on the smaller USB-C
powered boards vs. the 12V-powered T4, as well as minor variation in
other regulators related to various external connectors.

Additionally, the recovery key is only present on the T4 - ADC_IN1 is
simply pulled high and not exposed on the other boards - and the lowest
common denominator for MMC speed is actually HS200 according to the
vendor DTs.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

Robin Murphy authored Jan 14, 2019 and Tomeu Vizoso committed Feb 18, 2019

There are a number of subtle differences between the nanopi4 variants,
and where they disagree, the common DTSI currently follows the details
of NanoPi M4. In order to improve matters even more, let's add a
separate DTS for the M4 to which we can start splitting things out
appropriately. The third variant, NanoPi NEO4, is a lot closer to the M4
than either is to the larger T4, so arguably could get away with just
sharing the M4 DT for now (plus I have neither of the smaller boards to
actually test with).

CC: Rob Herring <robh+dt@kernel.org>
CC: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

This adds a device tree for the NanoPC-T4 SBC, which is based on the
Rockchip RK3399 SoC and marketed by FriendlyELEC.

Known working:

- Serial
- Ethernet
- HDMI
- USB 2.0

All of the interesting stuff is in a .dtsi because there are at least
two other boards that share most of it: NanoPi M4 and NanoPi NEO4.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
[rm: various further cleanup]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Similar to changes for other subblocks, rework the register definitions to
be private to the .c file and avoid hidden variable access and token
pasting.

Signed-off-by: Rob Herring <robh@kernel.org>

Tomeu Vizoso authored Feb 14, 2019 and Rob Herring committed Feb 15, 2019

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>

Tomeu Vizoso authored Feb 13, 2019 and Rob Herring committed Feb 15, 2019

To match other drivers and to prepare for returning other information
about the hardware that userspace will need.

Also fixes GPU version detection.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>

There are some features which aren't discoverable and are based on the
GPU model. These are copied from the vendor driver and modified to use
kernel bitmaps.

Signed-off-by: Rob Herring <robh@kernel.org>

Signed-off-by: Rob Herring <robh@kernel.org>

Userspace headers need to have 'Linux-syscall-note' addition in order be
used by non-GPL code (e.g. mesa).

I replaced the copyright because 'Panfrost Team' is not an entity that
can hold a copyright and the only piece left which Marty wrote is the
info ioctl which Tomeu is replacing anyways with 'get param'.

Signed-off-by: Rob Herring <robh@kernel.org>

Sure yet what all these registers contain as the vendor driver just
exports them to userspace in some cases. GPU_AS_PRESENT and
GPU_JS_PRESENT contain a bitmask of address space contexts and job
slots, respectively. The SHADER_PRESENT register is used to determine
coherent groups which is in turn used to set affinity for jobs.

Signed-off-by: Rob Herring <robh@kernel.org>

There's no need to expose the GPU registers outside of the GPU related
code, so move the definitions to the .c file.

Get rid of the token pasting too. It doesn't work for variable register
defines and goes against kernel style.

Signed-off-by: Rob Herring <robh@kernel.org>

Doesn't yet do anything other than compile.

Signed-off-by: Rob Herring <robh@kernel.org>

The io-pgtable lib expects addresses and sizes aligned and matching
supported page sizes. For now, we only support 4K page size and assume
we are always at least page aligned. It's not clear in the vendor driver
is 2MB entries are supported.

The iommu core normally takes care of ensuring things are aligned and
using large pages when possible, so we probably should do a full iommu
driver instead.

Signed-off-by: Rob Herring <robh@kernel.org>

This is a rather simple implementation currently. There's only one
address space (48-bit though) and we don't support page faults. That
appears to be good enough for other GPU drivers. Currently the MMU
mapping is done when GEM object is created. This could be done when
BOs are submitted, but going with a simple implementation for now.

Mappings are also all inner and outer non-cacheable. The vendor driver
is inner cacheable. We'll need to revisit that.

Signed-off-by: Rob Herring <robh@kernel.org>

Move io-pgtable.h to include/linux/ and export alloc_io_pgtable_ops
and free_io_pgtable_ops. This enables drivers outside drivers/iommu/ to
use the ARM page table library. Specifically, some ARM Mali GPUs use the
ARM page table formats.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: iommu@lists.linux-foundation.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>