After the commit below the Broxton PLL IDs had an off-by-one error, so
fix this up. Also add a missing brace at intel_shared_dpll_init(), it
happened to compile only due to the way the IS_BROXTON macro is defined.
v2:
- remove debugging left-over
Fixes: a3c988ea06 ("drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll code")
CC: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457978134-12362-1-git-send-email-imre.deak@intel.com
Whenever there's an update to the primary plane,
fbc_pre_update and fbc_post_update are called. Kill off
intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
is empty, kill it off too.
Changes since v1:
- Add a intel_fbc_supports_rotation helper.
Changes since v2:
- Remove intel_fbc_supports_rotation_helper.
- Remove unrelated changes.
Changes since v3:
- Rebase
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457516145-32117-2-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
fb_bits is useful to have in the crtc_state for cs flips when
the code is updated to use intel_frontbuffer_flip_prepare/complete.
So calculate it in advance and move it to crtc_state. The other stuff
can be calculated in post_plane_update, and aren't useful elsewhere.
Changes since v1:
- Changing wording, remove comment about loop.
Changes since v2:
- Rebase.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457516145-32117-1-git-send-email-maarten.lankhorst@linux.intel.com
Backmerge because:
- Maarten needs latest atomic patches from drm-misc.
- Lionel needs the color manager core patch from drm-misc.
- Ander extracted intel_dpll_mgr.c, we need a backmerge to avoid git
losing track of things too often (right now it seems ok due to
cherry-picks).
- Tvrtko needs a stable baseline to apply some large-scale renaming
patches to i915 GEM code.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
gcc-6 warns about code in the nouveau driver that is obviously silly:
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 'nv40_perfctr_next':
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison always evaluats to false [-Wtautological-compare]
if (pm->sequence != pm->sequence) {
The behavior was accidentally introduced in a patch described as "This is
purely preparation for upcoming commits, there should be no code changes here.".
As far as I can tell, that was true for the rest of that patch except for
this one function, which has been changed to a NOP.
This patch restores the original behavior.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 8c1aeaa139 ("drm/nouveau/pm: cosmetic changes")
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* tag 'drm-amdkfd-next-fixes-2016-03-15' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers()
The recent changes which removed platform data support from panels &
encoders had a few mistakes, causing probes of DVI connector and DSI
command mode panels to fail every time due to missing '!'. Fix the
if()s.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
At the end of the function we expect "status" to be zero, but it's
either -EINVAL or uninitialized.
Fixes: 788bf83db3 ('drm/amdkfd: Add wave control operation to debugger')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
significant 3D performance improvement and a fix to HDMI hotplug
detection for the Pi2/3.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCgAGBQJW5vwnAAoJELXWKTbR/J7odK8P/iz8IxxPBwKUHvROxH1nZxbJ
1NMs6VlJGed+B7EzKKEDGKGYrvdJaLMjJdpUBB7lbywvgEMW8r7h9RQr8YWiNv7f
ZRjEJ3DL2tegwO4JtaNicKSWFqvUFKlEzg65iMiL25tbW0YDvEvjKXQjp8VDbTsX
dgdFWchUbS70JHkIOKQQtKzzSMfmtgfI7DZ2a0N78RDwq7JShgELzeNeX89m0KAO
5g3C/khpEqvTRcEuLgq96WnlibBJw42amSbv8fjtiCtDJVCQg3cS3iicrTil3nie
OK7P7YsJlCiNTNu0U2ZhYpNaem1hCQFH/qc57Fx/jlEFpgg4spyFSHCHQ7yY1Z5A
RIlM+wN4U3LzEqHoMC8vXWrUXlAHadiHUn4yVK3BELLDprCUTHZ20mgl9AP5jm34
wk1bNJ7hpWUiaHCIyptirj9I961+lrtMJO7Y8tFk/7xYW4Y49baHbPpBOnzB59ab
iMumgVS+8Kv4e5BATkXfLLKyH4iU5IxK63F3VA1AayVc0L5hELSuCbC14A7dXbTZ
ZVblIK0bGQ7BnyIzDPYzCGF8Iv5VTH89NHFXPtNy/bvfyZk7Qh7EpPzwoEplYwLL
d4yr4oqyhnqOT7WUzp+YJoI7C2dBOWYm7jveLfevGomdg4PSR9m21muq4JQgM7Jj
YMcldIFgeEfT5GkOMtPY
=SJqo
-----END PGP SIGNATURE-----
Merge tag 'drm-vc4-next-2016-03-14' of github.com:anholt/linux into drm-next
This pull request covers what's left for 4.6. Notably, it includes a
significant 3D performance improvement and a fix to HDMI hotplug
detection for the Pi2/3.
* tag 'drm-vc4-next-2016-03-14' of github.com:anholt/linux:
drm/vc4: Recognize a more specific compatible string for V3D.
dt-bindings: Add binding docs for V3D.
drm/vc4: Return -EFAULT on copy_from_user() failure
drm/vc4: Respect GPIO_ACTIVE_LOW on HDMI HPD if set in the devicetree.
drm/vc4: Let gpiolib know that we're OK with sleeping for HPD.
drm/vc4: improve throughput by pipelining binning and rendering jobs
The Raspberry Pi Foundation's firmware updates are shipping device
trees using the old string, so we'll keep recognizing that as this rev
of V3D. Still, we should use a more specific name in the upstream DT
to clarify which board is being supported, in case we do other revs of
V3D in the future.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Add a basic clock driver that reuses the GK20A logic.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Make functions/structures that the GM20B driver will reuse public.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Err on the safe side by setting the lowest frequency (and thus voltage)
during device init.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This allows to instanciate drivers that use the same logic as gk20a with
different parameters.
Add a constructor function to allow other chips that inherit from this
clock to easily initialize its members
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
pl_to_div may be done differently depending on the chip. Abstract this
operation so the same logic can be reused for them as well.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This allows us to read them using one single function and will be handy
to the GM20B driver.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Most users are probably not interested in this information.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Only restore the 1:1 divider if it is not set already. Also use the
proper masks for this operation and add a second write as done in the
Android code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
n_lo is used if we are going to slide. Compute it only if that condition
succeeds to avoid confusion about future usage of this computation.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fix the mask specified to switch to VCO mode was given as an (incorrect)
immediate value. Although the side-effect happens to be the same, this
is clearly incorrect.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
gk20a_pllg_disable() is only used in the context of gk20a_clk_fini().
Move its body there and rename _gk20a_pllg_enable() and
_gk20a_pllg_disable() to non-underscored versions.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Move some variables declarations to the scope where they are actually
used to make the code easier to follow.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Perform computations in Khz instead of Mhz for better precision.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add basic GM20B volt driver that reuses the GK20A logic.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Split the constructor function so we can reuse the same logic in other
chips.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The CVB calculation and voltage setting functions can be reused for the
future chips. So move the declaration to gk20a.h.
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This class supports a WFI method (0x0078) that's not present on the
KeplerChannelGpfifoA class.
The binary driver exposes both classes on these GPUs for some reason,
though there doesn't appear to be any difference in the setup that's
done for each (ie. even if you allocate GpfifoA, the WFI method will
still work).
We shall just expose GpfifoB, as I don't see a good reason to report
the presence of both.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It's supposed to always be 0, but at least nv_iowr() temporarily violates
this. Since the ih touches $r0, it should be stored.
Signed-off-by: Roy Spliet <rs855@cam.ac.uk>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
the macro deals with target specific differences and so we should always use
this
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
on gk208+ we can simply mov 32bits, so we should have a single mov there
v2: use or operator instead of add
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Most calls to nvkm_ramht_new use 0x8000 as the size. This results in a
fairly sizeable chunk of memory to be allocated, which may not be
available with kzalloc. Since this is done fairly rarely (once per
channel), use vzalloc instead.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A channel may still be processed by the PBDMA even after removal, unless
it is properly kicked. Some chips are more sensible to this than others,
with GM20B triggering the issue very easily (the PBDMA will try to fetch
methods from the previously-removed channel after a new one is added).
Make sure this cannot happen by kicking the channel right after it is
disabled, and before the new runlist is submitted.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When using the DMA-API for instmem, we may obtain a write-combined
mapping. For such cases, add a write barrier in
gk20a_instobj_release_dma() to make sure that all writes have reached
memory at this time.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Without this buffer inconsistencies may appear between the CPU
and GPU when using a PCI GPU on an ARM64 board.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Registration of the hwmon device will fail on non-PCI systems since
dev->pdev is NULL in that case. Use the more generic drm_device::dev
member that points to the same and is always set no matter the platform.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On non-PCI devices, nobody should really care if the device does not
provide HDMI...
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The DMA API has different semantics on different architectures.
Currently on arm64, it can only provide memory from a small pool which
dries up quickly if we attempt to allocate big buffers from it.
Do not consider that option when running on non-x86, since regular TTM
buffers are the (current) best-fit for ARM platforms.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
LTC operations timeout was set to 2ms, which may be too low for devices
that run at very low clocks (e.g. GM20B) and trigger timeout messages.
Set the timeout to the default 2s. Also remove the redundant error
messages since nvkm_wait_msec() will already display a warning.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set
it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system
memory.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set
it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system
memory.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fix the channel id bit mask in FIFO schedule timeout error handling.
FIFO_ENGINE_STATUS_NEXT_ID is bit 27:16 thus 0x0fff0000.
FIFO_ENGINE_STATUS_ID is bit 11:0 thus 0x00000fff.
Signed-off-by: Xia Yang <xiay@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
DMA mask is typically set in nouveau_ttm_init(), but this function is
called late during initialization and GK20A's instmem will have called
DMA functions before this happens.
Having a wrongly set DMA mask can result in the use of unneeded bounce
buffers. Set it early to avoid this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
based on Martins initial work
v3: fix ina2x9 calculations
v4: don't kmalloc(0), fix the lsb/pga stuff
v5: add a field to tell if the power reading may be invalid
add nkvm_iccsense_read_all function
check for the device on the i2c bus
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Karol Herbst:
v4: don't kmalloc(0)
v5: stricter validation
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Add secure boot support for the GM20B chip found in Tegra X1. Secure
boot on Tegra works slightly differently from desktop, notably in the
way the WPR region is set up.
In addition, the firmware bootloaders use a slightly different header
format.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add secure-boot for the dGPU set of GM20X chips, using the PMU as the
high-secure falcon.
This work is based on Deepak Goyal's initial port of Secure Boot to
Nouveau.
v2. use proper memory target function
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Secure falcons' firmware is managed by secboot. Do not load it in GR for
them.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Start securely-managed falcons using secboot functions since the process
for them is different from just writing CPUCTL.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On GM200 and later GPUs, firmware for some essential falcons (notably
GR ones) must be authenticated by a NVIDIA-produced signature and
loaded by a high-secure falcon in order to be able to access privileged
registers, in a process known as Secure Boot.
Secure Boot requires building a binary blob containing the firmwares
and signatures of the falcons to be loaded. This blob is then given to
a high-secure falcon running a signed loader firmware that copies the
blob into a write-protected region, checks that the signatures are
valid, and finally loads the verified firmware into the managed falcons
and switches them to privileged mode.
This patch adds infrastructure code to support this process on chips
that require it.
v2:
- The IRQ mask of the PMU falcon was left - replace it with the proper
irq_mask variable.
- The falcon reset procedure expecting a falcon in an initialized state,
which was accidentally provided by the PMU subdev. Make sure that
secboot can manage the falcon on its own.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Load firmware and bundles in GM200's constructor. The previously called
GF100 function did not care about the bundles.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There functions are going to be used by other chips that rely on
NVIDIA-provided firmware. Export them.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Make these functions easier to use by handling memory management from
within.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The firmwares required by GR may vary from chip to chip, especially with
the introduction of secure boot and NVIDIA-provided firmwares. Move the
firmware loading outside of gf100_gr_ctor so other chips may still call
it while managing their firmwares themselves.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some members of gf100_gr were freed by the gk20a driver. That's not
where it should be done - free them in gf100 so other chips that use
NVIDIA-provided firmware free these structures properly.
This also removes the need for a GK20A-specific destructor.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add memcpy functions to copy a buffer to a gpuobj and vice-versa. This
will be used by the secure boot code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Most of the per-chipset differences will go away when we fully switch
to using the register lists provided by the firmware files, which will
leave all the remaining code "belonging" to GM200.
This is a preemptive rename from GM204 to GM200.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Upon encountering an unknown condition code, the script interpreter
is supposed to skip 'size' bytes and continue at the next devinit
token.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It is not advisable to perform devinit if it has already been done.
VBIOS will very likely have invoked devinit if the GPU is the primary
graphics device, but there is no accurate way to detect this fact yet.
This patch adds such a method for gf100 and later chips, by means of the
NV_PTOP_SCRATCH1_DEVINIT_COMPLETED bit. This bit is set to 1 by devinit,
and reset to 0 when the GPU is powered.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We never use any nv50-specific member in this nv50_devinit_preinit().
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvkm_device_tegra_new initializes the irq member of the Tegra device
to -1 in order to signal that it is uninitialized. However,
nvkm_device_tegra_fini tests it against 0 to check whether an IRQ has
been allocated or not. This leads to free_irq being called on -1 during
device initialization.
Fix this by using 0 as the uninitialized value everywhere.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvkm_device_fini is never called if a failure occurs in
nvkm_device_init, even when unloading the module. This can lead to a
resources leak (one example is the Tegra interrupt which would never be
freed in that case). Fix this by calling nvkm_device_fini in
nvkm_device_init's failure path.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the nvkm_firmware_* functions when loading external firmware to
avoid duplicate code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add two functions nvkm_firmware_get() and nvkm_firmware_put() to load a
firmware file and free its resources, respectively. Since firmware files
are becoming a necessity for new GPUs, and their location has been
standardized to nvidia/chip/, this will prevent duplicate and
error-prone name-generation code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Patch "ltc/gm107: use nvkm_mask to set cbc_ctrl1" sets the 3rd bit
of the CTRL1 register instead of writing it entirely in
gm107_ltc_cbc_clear(). As a counterpart, gm107_ltc_cbc_wait() must also
be modified to wait on that single bit only, otherwise a timeout may
occur if some other bit of that register is set. This happened at least
on GM206 when running glmark2-drm.
While we are at it, use the more compact nvkm_wait_msec() to wait for
the bit to clear.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The copy_from_user() function returns the number of bytes not copied but
we want to return a negative error code.
Fixes: 463873d570 ('drm/vc4: Add an API for creating GPU shaders in GEM BOs.')
Cc: stable@vger.kernel.org
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
The original Raspberry Pi had the GPIO active high, but the later
models are active low. The DT GPIO bindings allow specifying the
active flag, except that it doesn't get propagated to the gpiodesc, so
you have to handle it yourself.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Daniel Stone <daniels@collabora.com>
Fixes an error thrown every few seconds when we poll HPD when it's on
a I2C to GPIO expander.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Daniel Stone <daniels@collabora.com>
The hardware provides us with separate threads for binning and
rendering, and the existing model waits for them both to complete
before submitting the next job.
Splitting the binning and rendering submissions reduces idle time and
gives us approx 20-30% speedup with some x11perf tests such as -line10
and -tilerect1. Improves openarena performance by 1.01897% +/-
0.247857% (n=16).
Thanks to anholt for suggesting this.
v2: Rebase on the spurious resets fix (change by anholt).
Signed-off-by: Varad Gautam <varadgautam@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
This pull request fixes the major VC4 HDMI modesetting bugs found when
the first wave of users showed up in Raspbian.
* tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux:
drm/vc4: Initialize scaler DISPBKGND on modeset.
drm/vc4: Fix setting of vertical timings in the CRTC.
drm/vc4: Fix the name of the VSYNCD_EVEN register.
drm/vc4: Add another reg to HDMI debug dumping.
drm/vc4: Bring HDMI up from power off if necessary.
drm/vc4: Fix a framebuffer reference leak on async flip interrupt.
562c5b4d89 didn't quite fix the issue of dealing with an error
pointer. We can't free/unref an error pointer so reset it to NULL.
Many thanks to Dan Carpenter for pointing this out again.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: dri-devel@lists.freedesktop.org
Fixes: 562c5b4d89 ("drm: fix blob pointer check")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457698646-22231-1-git-send-email-lionel.g.landwerlin@intel.com
SADs may span multiple CEA audio data blocks in the EDID.
CEA-861-E says:
"The order of the Data Blocks is not constrained. It is also possible
to have more than one of a specific type of data block if necessary to
include all of the descriptors needed to describe the sink’s capabilities."
Each audio data block can carry up to 10 SADs, whereas the ELD SAD limit
is 15 according to HDA 1.0a spec. So we should support at least two data
blocks. And apparently some devices take a more liberal interpretation
and stuff only one SAD per data block even when they would fit into one.
So let's try to extract all the SADs we can fit into the ELD even when
they span multiple data blocks.
While at it, toss in a comment to explain the 13 byte monitor name
string limit which confused me at first.
Cc: Arturo Pérez <artur999555@gmail.com>
Tested-by: Arturo Pérez <artur999555@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457554066-8739-1-git-send-email-ville.syrjala@linux.intel.com
The commit d931589c01 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
ioctl") removed it same with the ioctl that this patch adds. The reason
that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.
Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Two i915 regression fixes.
* tag 'drm-intel-fixes-2016-03-11' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Actually retry with bit-banging after GMBUS timeout
drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW
After the GMBUS transfer times out, we set force_bit=1 and
return -EAGAIN expecting the i2c core to call the .master_xfer
hook again so that we will retry the same transfer via bit-banging.
This is in case the gmbus hardware is somehow faulty.
Unfortunately we left adapter->retries to 0, meaning the i2c core
didn't actually do the retry. Let's tell the core we want one retry
when we return -EAGAIN.
Note that i2c-algo-bit also uses this retry count for some internal
retries, so we'll end up increasing those a bit as well.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: bffce907d6 ("drm/i915: abstract i2c bit banging fallback in gmbus xfer")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 8b1f165a4a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Check properly that the allocated blob's pointer is valid.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Stone <daniels@collabora.com>
Fixes: 5488dc16fd ("drm: introduce pipe color correction properties")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457611461-9116-1-git-send-email-lionel.g.landwerlin@intel.com
We must wait for the hardware to exit cxsr before doing the plane
update, so add the missing vblank wait to pre_plane_update after
disabling cxsr.
We have the wait for vblank in the pre_disable_primary hook, but not in
the pre_plane_update hook. Just move the code from (and comment) from
pre_disable_primary into pre_plane_update. Well, we still have to keep
it in pre_disable_primary for these strange _noatomic codepaths, so
let's do another version of pre_disable_primary for those. Also toss
in some FIXMEs in the hope that someone will eventually clean up this
pre_disable_primary mess.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
commit 92826fcdfc ("drm/i915: Calculate watermark related members in the crtc_state, v4.")
broke thigns by removing the pre vs. post wm update distinction. We also
lost the pre plane wm update entirely for VLV/CHV from the crtc enable
path.
This caused underruns on modeset and plane enable/disable on CHV,
and often those can lead to a dead pipe.
So let's bring back the pre vs. post thing, and let's toss in an
explicit wm update to valleyview_crtc_enable() to avoid having to
put it into the common code.
This is more or less a partial revert of the offending commit.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 92826fcdfc ("drm/i915: Calculate watermark related members in the crtc_state, v4.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Pass the current crtc state, not the old crtc state, to the
.update_plane() hook.
Noticed on BSW when PRIMSIZE was getting programmed to a stale value
which produced utter garbage on screen eg. wwhen going from 1920x1080
to 1024x768.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: a758e68458 ("drm/i915: Do not use commit_plane for sprite planes.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457543247-13987-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Pull drm fixes from Dave Airlie:
"A few imx fixes I missed from a couple of weeks ago, they still aren't
that big and fix some regression and a fail to boot problem.
Other than that, a couple of regression fixes for radeon/amdgpu, one
regression fix for vmwgfx and one regression fix for tda998x"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
Revert "drm/radeon/pm: adjust display configuration after powerstate"
drm/amdgpu/dp: add back special handling for NUTMEG
drm/radeon/dp: add back special handling for NUTMEG
drm/i2c: tda998x: Choose between atomic or non atomic dpms helper
drm/vmwgfx: Add back ->detect() and ->fill_modes()
drm/radeon: Fix error handling in radeon_flip_work_func.
drm/amdgpu: Fix error handling in amdgpu_flip_work_func.
drm/imx: Add missing DRM_FORMAT_RGB565 to ipu_plane_formats
drm/imx: notify DRM core about CRTC vblank state
gpu: ipu-v3: Reset IPU before activating IRQ
gpu: ipu-v3: Do not bail out on missing optional port nodes
After the GMBUS transfer times out, we set force_bit=1 and
return -EAGAIN expecting the i2c core to call the .master_xfer
hook again so that we will retry the same transfer via bit-banging.
This is in case the gmbus hardware is somehow faulty.
Unfortunately we left adapter->retries to 0, meaning the i2c core
didn't actually do the retry. Let's tell the core we want one retry
when we return -EAGAIN.
Note that i2c-algo-bit also uses this retry count for some internal
retries, so we'll end up increasing those a bit as well.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: bffce907d6 ("drm/i915: abstract i2c bit banging fallback in gmbus xfer")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept
enabled because of it driving CDCLK, it is better to special case that
inside the DPLL code than in the higher level.
v2: Use INTEL_DPLL_ALWAYS_ON flag. (Ander)
v3: Remove extremely paranoid WARN_ONs. (Maarten)
Handle DPLL0 in skylake_get_ddi_pll() properly. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-14-git-send-email-ander.conselvan.de.oliveira@intel.com
Manage the LCPLLs used with DisplayPort, so that all the HSW/BDW DPLLs
are managed by the shared dpll code.
v2: Introduce INTEL_DPLL_ALWAYS_ON flag to please state checker. (Ander)
v3: Initialize pll->flags in intel_shared_dpll_init(). (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-13-git-send-email-ander.conselvan.de.oliveira@intel.com
Move the code for selecting and configuring HSW/BDW DDI PLLs into the
shared dpll infrastructure. With this most of the PLL selection logic
for those platforms is in one place. DisplayPort is handled separately,
but that should be fixed on a follow up patch. It also allows a small
clean up of the SPLL logic.
v2: Rebase.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-10-git-send-email-ander.conselvan.de.oliveira@intel.com
The function intel_get_shared_dpll() had a more or less generic
implementation with some platform specific checks to handle smaller
differences between platforms. However, the minimalist approach forces
bigger differences between platforms to be implemented outside of the
shared dpll code (see the *_ddi_pll_select() functions in intel_ddi.c,
for instance).
This patch changes the implementation of intel_get_share_dpll() so that
a completely platform specific version can be used, providing helpers to
reduce code duplication. This should allow the code from the ddi pll
select functions to be moved, and also make room for making more dplls
managed by the shared dpll infrastructure.
v2: WARN_ON(!dpll_mgr) in intel_get_shared_dpll(). (Maarten)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-9-git-send-email-ander.conselvan.de.oliveira@intel.com
Move the declarations related to shared dplls from i915_drv.h to their
own header file.
The code that became the shared dpll infrastructre was first introcude
in commit ee7b9f93fd ("drm/i915: manage PCH PLLs separately from
pipes"), hence the 2012-2016 copyright years in the new header file.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-6-git-send-email-ander.conselvan.de.oliveira@intel.com
Change the type of intel_crtc_state->shared_dpll to be a pointer to a
shared dpll. With this there is no need to first convert the id stored
in the crtc state to a pointer in order to use it. It does introduce a
bit of hassle on doing the opposite.
The long term objective is to hide details about dpll ids behind the
shared dpll interface.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-5-git-send-email-ander.conselvan.de.oliveira@intel.com
Create the new file intel_dpll_mgr.c and move the shared dpll code to
it. Follow up patches that reorganize pll handling will move more code
there and tweak the interface.
No functional changes.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-2-git-send-email-ander.conselvan.de.oliveira@intel.com
The DSI power domain was missing from BXT power well 1 definitions,
failing to get the power well for DSI transcoders. As pipe A is in the
same power well as DSI transcoders, the problem should only occur with
pipes B and C.
According to Ville, this is basically a nop since pw1 is under dmc
control. But given that we still have this stuff defined here, it's
clearly correct to include DSI here.
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Deepak M <m.deepak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457463656-29357-1-git-send-email-jani.nikula@intel.com
- Fix ipu probe if optional port nodes are not present in the device tree
- Reset the ipu before initializing interrupts, not thereafter
- Notify DRM core about the state of vblank interrupts
- Add missing RGB565 format to the list of plate formats
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWxs28AAoJEFDCiBxwnmDre0IP/3f3EaTmFP8bSzCW4rtEMn26
t5+frIRg/y7waM/BC5iK9jbi98oqKGdWB2kiaA8uS4jowS3AdD8wHN/9/W20onBF
BVrNbMELRSNqOTGxgjouO7FB/2FwvlKRZzFJlIQ4Xci/PFDkyVZ+Bhva+4L4kvNg
iHanmUM3nVsgCukefvkboVUJTfAkMsT1jd64Z8UDa+Bl6zsVsnzIUtHQKOzD6lwk
Pq+/d6l4B9dFbZLkhITI+A3N7GbjJ20SEjn+LOYehjTz8B3BWw9K5BvWndr2x6yX
/hTYSE2nVdsGOdZrwuYZY2pOocLvApme7raB8CSgsXzktZ+BBbDprsxae08ecGEg
qyekFuVGTrMzvpuBkMk16Phh6g7F2oTNzJ9mdR3c9J3Eoolc3d7ZVN9ZUtjqiCk5
XArrQMG9WbW9e6pFWIc3tpYRfybNN7oIEUAJnI7VKpeh56osIUXTCtXreyVxBDu6
ycKE4ZNsX2Fu+XhDk2enMtOdmNm32x1waR3vbKdIfJY0fjSd+N9FOt5SUXNlwzSX
NhLOLPYRorQ7cj72RvavEQCAtOywsoHWRLwdMDj4BAND1o4KcXzANb2ZwGH8awMk
beG8+0ZKM3HWzkhrpqti7StCrhWQNlmfkUgTu6/PX++m+SplII27cScKqFQZuFWm
M4YCzksuVhO6dgAT05zt
=9nEz
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-2016-02-19' of git://git.pengutronix.de/git/pza/linux into drm-fixes
ipu-v3 probe and imx-drm crtc and plane fixes
- Fix ipu probe if optional port nodes are not present in the device tree
- Reset the ipu before initializing interrupts, not thereafter
- Notify DRM core about the state of vblank interrupts
- Add missing RGB565 format to the list of plate formats
* tag 'imx-drm-fixes-2016-02-19' of git://git.pengutronix.de/git/pza/linux:
drm/imx: Add missing DRM_FORMAT_RGB565 to ipu_plane_formats
drm/imx: notify DRM core about CRTC vblank state
gpu: ipu-v3: Reset IPU before activating IRQ
gpu: ipu-v3: Do not bail out on missing optional port nodes
radeon and amdgpu fixes for 4.5. Three regression fixes and
some fixups for the error handling in the vblank regression fixes
from earlier.
* 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux:
Revert "drm/radeon/pm: adjust display configuration after powerstate"
drm/amdgpu/dp: add back special handling for NUTMEG
drm/radeon/dp: add back special handling for NUTMEG
drm/radeon: Fix error handling in radeon_flip_work_func.
drm/amdgpu: Fix error handling in amdgpu_flip_work_func.
When I fixed the dp rate selection in:
3b73b168cffd9c392584d3f665021fa2190f8612
drm/amdgpu: fix dp link rate selection (v2)
I accidently dropped the special handling for NUTMEG
DP bridge chips. They require a fixed link rate.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Tvrtko Ursulin