Probably missing something here, doesn't make a lot of sense to write
or+link data into a register whose offset is calculated by the same
or+link info..
This is the all I've witnessed the binary driver and vbios doing so
far, so it'll do.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The binary driver has been doing this since GF119, and we've somehow
gotten away with it. But, TMDS that hasn't been initialised already
by the x86 vbios code is distorted without it on GM204.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Logging at trace level, rather than as en error, as it seems conceivable
that failure could be normal under certain circumstances (new bios,
older sink that doesn't support a particular DPCD address)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Starting from GM204, certain registers are no longer accessible by the host
(or unsigned PMU firmware).
This commit implements devinit on PMU, using a signed microcode image, and
devinit data, from the VBIOS.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The field at +0x2 is technically processor specific, though I don't know
that it's ever mattered in practice (yet).
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We're about to need to be able to fetch additional chunks of data beyond
the primary bios image, which makes fetching a lot more complicated.
This splits out the verious shadowing routines to be nothing more than
very dumb "fetch this much data from this offset" routines, and leaves
the logic of what and how much to fetch in common code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Just a couple of fixes for the fallout from the fence rework.
* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/gf116: remove copy1 engine
drm/nouveau: prevent stale fence->channel pointers, and protect with rcu
drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it
Indications are that no GF116's actually have a copy engine there, but
actually have the decompression engine. This engine can be made to do
copies, but that should be done separately.
Unclear why this didn't turn up on all GF116's, but perhaps the
non-mobile ones came with enough VRAM to not trigger ttm migrations in
test scenarios.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85465
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59168
Cc: stable@vger.kernel.org
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Closes a very unlikely race that can occur if another NonStallInterrupt
method passes between checking fences and acking the previous interrupt.
With this change, the interrupt will re-fire under such conditions.
Tested-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
add gpio bitbanging i2c adapter on LPC device of atom e6xx
gpu chipset to access lvds EDID
tested on SECO QuadMo747-E6xx-EXTREME Qseven platform
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Jan Safrata <jan.nikitenko@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So here's a pile of atomic fixes and improvements from various people.
There's still more patches in-flight, so I think I'll keep collecting them
in a separate branch.
* tag 'topic/core-stuff-2014-11-28' of git://anongit.freedesktop.org/drm-intel:
drm/atomic: clear plane's CRTC and FB when shutting down
drm: Handle atomic state properly in kms getfoo ioctl
drm: use mode_object_find helpers
drm: fix indentation
drm/msm: switch to atomic-helpers iterator macros
drm/atomic: add plane iterator macros
drm/atomic: track bitmask of planes attached to crtc
drm: Free atomic state during cleanup
drm: Make drm_atomic.h standalone includible
drm: Make drm_atomic_helper.h standalone includible
drm/plane: Add missing kerneldoc
drm/plane: Pass old state to ->atomic_update()
drm/atomic_helper: Cope with plane->crtc == NULL in disable helper
drm/atomic: Drop per-plane locking TODO
drm/atomic-helper: Skip vblank waits for unchanged fbs
drm: Document that drm_dev_alloc doesn't need a parent
The function will also be used by a later patch, so factor it out.
V2: make raw_edid const, define/declare before first use
V3: fix erroneuos removal of csum variable
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no need to dump the whole EDID block in case it contains no
information. Just print a single line stating the block is empty instead
of 8 lines containing only zeroes.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_edid_is_zero will be used by drm_edid_block valid, move it up.
raw_edid argument can be const.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull drm fixes from Dave Airlie:
"Two i915 regressions and one dual-gpu laptop radeon fix"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: report disconnected for LVDS/eDP with PX if ddc fails
drm/i915: Cancel vdd off work before suspend
drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset
Two regression fixes from Ville.
* tag 'drm-intel-fixes-2014-11-27' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Cancel vdd off work before suspend
drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset
Otherwise we'd still end up w/ the plane attached to the CRTC, and
seemingly active, but without an FB. Which ends up going *boom*
in the drivers.
Slightly modified version of Daniel's irc suggestion.
Note that the big problem isn't drivers going *boom* here (since we
already have the situation of planes being left enabled when the crtc
goes down). The real issue is that the core assumes the primary plane
always goes down when calling ->set_config with a NULL mode. Ignoring
that assumption leads to the legacy state pointers plane->fb/crtc
getting out of sync with atomic, and that then leads to the subsequent
*boom* all over the place.
CC: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet: Drop my opinion of what's going sidewides here into the
commit message as a note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So the problem with async commit (especially async modeset commit) is
that the legacy pointers only get updated after the point of no
return, in the async part of the modeset sequence. At least as
implemented by the current helper functions. This is done in the
set_routing_links function in drm_atomic_helper.c.
Which also means that access isn't protected by locks but only
coordinated by synchronizing with async workers. No problem thus far,
until we lock at the getconnector/encoder ioctls.
So fix this up by adding special cases for atomic drivers: For those
we need to look at state objects. Unfortunately digging out the
correct encoder->crtc link is a bit of work, so wrap this up in a
helper function.
Moving the assignments of connector->encoder and encoder->crtc earlier
isn't a good idea because the point of the atomic helpers is that we
stage the state updates. That way the disable functions can still
inspect the links and rely upon them.
v2: Extract full encoder->crtc lookup into helper (Rob).
v3: Extract drm_connector_get_encoder too since - we need to always
return state->best_encoder when there is a state otherwise we might
return stale data if there's a pending async disable (and chase
unlocked pointers, too). Same issue with encoder_get_crtc but there
it's a bit more tricky to handle.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Lightly-Tested-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.
Solve this by adding a bitmask of currently attached planes in the
crtc-state.
Note that the transitional helpers do not maintain the plane_mask. But
they only support the legacy ioctls, which have sufficient brute-force
locking around plane updates that they can continue to loop over all
planes to see what is attached to a crtc the old way.
Signed-off-by: Rob Clark <robdclark@gmail.com>
[danvet:
- Drop comments about locking in set_crtc_for_plane since they're a
bit misleading - we already should hold lock for the current crtc.
- Also WARN_ON if get_state on the old crtc fails since that should
have been done already.
- Squash in fixup to check get_plane_state return value, reported by
Dan Carpenter and acked by Rob Clark.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If ddc fails, presumably the i2c mux (and hopefully the signal
mux) are switched to the other GPU so don't fetch the edid from
the vbios so that the connector reports disconnected.
bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=904417
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The branch is based on a merge of drm-next and Simon's tags/renesas-dt-du-for-
v3.19 available at
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git, the latter
having been pulled in the ARM SoC tree for v3.19.
Compared to v1, I've rebased my branch on a later drm-next, added Julia's
error return code fix, and documented the "drm: Decouple EDID parsing from I2C
adapter" patch properly.
v1:
Here's a pull request that adds HDMI support to the R-Car DU driver, including
a new slave encoder driver for the adv7511.
* 'drm/du/adv7511' of git://linuxtv.org/pinchartl/fbdev:
drm: Add adv7511 encoder driver
video: Add ADV751[13] DT bindings documentation
drm: Decouple EDID parsing from I2C adapter
drm: rcar-du: Add HDMI encoder and connector support
drm: rcar-du: Replace drm_encoder with drm_slave_encoder
drm: rcar-du: Replace direct DRM encoder access with cast macro
drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init()
drm: rcar-du: Remove platform data support
drm: rcar-du: fix error return code
ARM: shmobile: koelsch: Enable DU device in DT
ARM: shmobile: koelsch-reference: Remove DU platform device
ARM: shmobile: lager: Enable DU device in DT
ARM: shmobile: lager-reference: Remove DU platform device
ARM: shmobile: marzen: Enable DU device in DT
ARM: shmobile: dts: Add common file for AA104XD12 panel
ARM: shmobile: r8a7791: Add DU node to device tree
ARM: shmobile: r8a7790: Add DU node to device tree
ARM: shmobile: r8a7779: Add DU node to device tree
ARM: shmobile: Remove FSF address from copyright headers
- Fixes for sparse warnings
- Memory leak fixes
- Fix for deadlock between amdkfd and iommu
* 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux:
amdkfd: delete some dead code
amdkfd: Fix memory leak of mqds on dqm fini
amdkfd: fix an error handling bug in pqm_create_queue()
amdkfd: fix some error handling in ioctl
amdkfd: Remove DRM_AMDGPU dependency from Kconfig
amdkfd: explicitely include io.h in kfd_doorbell.c
amdkfd: Clear ctx cb before suspend
amdkfd: Instead of using get function, use container_of
amdkfd: use schedule() in sync_with_hw
amdkfd: Fix memory leak on process deregistration
amdkfd: add __iomem attribute to doorbell_ptr
amdkfd: fence_wait_timeout() can be static
amdkfd: is_occupied() can be static
amdkfd: Fix sparse warnings in kfd_flat_memory.c
amdkfd: pqm_get_kernel_queue() can be static
amdkfd: test_kq() can be static
amdkfd: Fix sparse warnings in kfd_topology.c
amdkfd: Fix sparse warnings in kfd_chardev.c
