I got confirmation that we can read and change the voltage with the same code.
The divider is also computed correctly on the gm204 we got our hands on.

Thanks to Yoshimo on IRC for executing the tests on his gm204!
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Let's ignore the other desktop Maxwells until I get my hands on one and confirm
that we still can change the voltage.
Signed-off-by: NMartin Peres <martin.peres@free.fr>

Most Keplers actually use the GPIO-based voltage management instead of the new
PWM-based one. Use the GPIO mode as a fallback as it already gracefully handles
the case where no GPIOs exist.

All the Maxwells seem to use the PWM method though.

v2:
 - Do not forget to commit the PWM configuration change!
Signed-off-by: NMartin Peres <martin.peres@free.fr>

This patch is not ideal but it definitely beats a rewrite of the current
interface and is very self-contained.
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

So far the DMA mask was not set for platform devices, which limited them
to a 32-bit physical space. Allow dma_set_mask() to be called for
non-PCI devices, and also take the IOMMU bit into account since it could
restrict the physically addressable space.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The pci_dma_* functions are now superseeded in the kernel by the DMA
API. Make the conversion to this more generic API.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Use the IOMMU bit specified in platform data instead of hardcoding it to
the bit used by current Tegra GPUs.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Current Tegra code taking advantage of the IOMMU assumes a hardcoded
value for the IOMMU bit. Make it a platform property instead for
flexibility.

v2 (Ben Skeggs): remove nvkm dependence on drm structures
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The Great Nouveau Refactoring Take II brought us a lot of goodness,
including acquire/release methods that are called before and after an
instobj is modified. These functions can be used as synchronization
points to manage CPU/GPU coherency if we modify an instobj using the
CPU.

This patch replaces the legacy and slow PRAMIN access for gk20a instmem
with CPU mappings and writes. A LRU list is used to unmap unused
mappings after a certain threshold (currently 1MB) of mapped instobjs is
reached. This allows mappings to be reused most of the time.

Accessing instobjs using the CPU requires to maintain the GPU L2 cache,
which we do in the acquire/release functions. This triggers a lot of L2
flushes/invalidates, but most of them are performed on an empty cache
(and thus return immediately), and overall context setup performance
greatly benefits from this (from 250ms to 160ms on Jetson TK1 for a
simple libdrm program).

Making L2 management more explicit should allow us to grab some more
performance in the future.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

No longer required in a lot of cases, as objects are identified over NVIF
via an alternate mechanism since the rework.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Allow clients to manually flush and invalidate L2. This will be useful
for Tegra systems for which we want to write instmem using the CPU.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These are useful for systems without a coherent CPU/GPU bus. For such
systems we may need to maintain the L2 ourselves.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reintroduce macros allowing us to test a register against a certain
mask, since this is the most common usage pattern for the more generic
nvkm_xsec macros and makes the code more concise and readable.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some devices may not have a PMU. Avoid a NULL pointer dereference in
such cases by checking whether the pointer given to nvkm_pmu_pgob() is
valid.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.

This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the
msm kms driver.

Replace this with the top level DRM_FBDEV_EMULATION config option where
applicable. This also prevents build breaks caused by undefined
drm_fb_helper_* functions when legacy fbdev support was disabled.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This change adds the basic MDP5 support for MSM8996.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In order to produce an image, the scalar needs to be fed extra
pixels. These top/bottom/left/right values depend on a various of
factors, including resolution, scaling type, phase step and
initial phase.

Pixel Extension are programmed by hardware in most targets - and
can be overwritten by software. For some targets (e.g.: msm8996),
software *must* program those registers.

In order to ease this computation, let's always use bilinear
filters, which are easier to program from kernel. Eventually,
all of these values will come down from user space for better
quality.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

When calculating phase steps, let's use the same enum
mdp_component_type in order to ease the readability; 0/1 indexes
are a bit confusing and we now have explicit values to index
this type of arrays.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The HDMI controller is new in MDP5 v1.7. As of now, this change
doesn't reflect the novelty and only adds the basics so the probe
gets triggered.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The current behavior is to try to get optional clocks and print a
dev_err message in case of failure. This looks rather confusing
and may increase with the amount of optional clocks.

We may need a cleaner way to handle per-device clocks but in the
meantime, let's reduce the amount of dev_err messages during the
probe.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

msm_iommu_new() can fail and this change makes sure that we
detect the failure and free the allocated domain before going
any further.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We want to make sure we control all the information being passed
down to SMP block. Having access to the cfg pointer here may create
bad things in the future.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The current settings for 28nm PHY data lane CFG4 registers do
not work with certain panels. This change is to modify them to
hw recommended values.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In some configurations the supplies are voltage switches and not LDOs,
making the set voltage call to fail. Check with the regulator framework
if the supply can change voltage before attempting.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

That's still small enough to not waste to much memory on PD/PTs.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add core VI enablement for Stoney.
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stoney is VCE 3.x single.

v2: Stoney is single pipe like Fiji
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stoney is UVD 6.x.
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stoney is GFX 8.1.

v2: update to latest golden settings
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stoney is SDMA 3.x.

v2: update to latest golden register settings
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stoney is DCE 11.x.
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stoney is SMC 8.x.
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stoney is GMC 8.x.
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stoney is based on Carrizo with some IP upgrades.
Signed-off-by: NSamuel Li <samuel.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The R8A7794 DU has a fixed output routing configuration with one RGB
output per CRTC and thus lacks the RGB output routing register field.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7793 DU is identical to the R8A7791 and thus only requires a new
DT compatible string.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>