With the recent patch to unify VRAM address for driver
table(a83f82e). VF cannot dump table info any more because
SMU_MSG_SetDriverDramAddrHigh/Low were deleted in the
function of smu_update_table.
Therefore, VF also needs to set driver_table address
in smu_hw_init to fix this regression issue.
Signed-off-by: Jack Zhang <Jack.Zhang1@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is no real reason to require drivers to set and use
dev->dev_private. Indeed, the current recommendation, as documented in
drm_device.h, is to embed struct drm_device in the per-device struct
instead of using dev_private.
Remove the requirement for dev_private to have been set to indicate
driver initialization.
For background, quoting Daniel Vetter:
Now there might be some hilarious races this papers over, but:
- Proper drivers should only call drm_dev_register once everything is
set up, including this stuff here. No race possible with anything else
really.
- Slightly more wobbly drivers, including the legacy ones, all use
drm_global_mutex. This was the former BKL, which means that it was
impossible for soeone to go through the load/unload/reload (between
lastclose and firstopen) paths and also run the ioctl. But the ioctl
had to be made unlocked because blocking there killed X:
commit 8f4ff2b06a
Author: Ilija Hadzic <ihadzic@research.bell-labs.com>
Date: Mon Oct 31 17:46:18 2011 -0400
drm: do not sleep on vblank while holding a mutex
The even more legacy DRM_CONTROL ioctl stayed fully locked. But the
file open/close paths are still fully locked, and that's the only
place legacy drivers should call drm_irq_install/uninstall, so should
all still be fully ordered and protected and happy.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211144753.3175-1-jani.nikula@intel.com
Commit e812744c5f ("drm: msm: a6xx: Add support for A618") missed
updating the VBIF flush in a6xx_gmu_shutdown and instead
inserted the new sequence into a6xx_pm_suspend along with a redundant
GMU idle.
Move a6xx_bus_clear_pending_transactions to a6xx_gmu.c and use it in
the appropriate place in the shutdown routine and remove the redundant
idle call.
v2: Remove newly unused variable that was triggering a warning
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Fixes: e812744c5f ("drm: msm: a6xx: Add support for A618")
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Commit e812744c5f ("drm: msm: a6xx: Add support for A618") added a
universal GBIF un-halt into a6xx_start(). This can cause problems for
a630 targets which do not use GBIF and might have access protection
enabled on the region now occupied by the GBIF registers.
But it turns out that we didn't need to unhalt the GBIF in this path
since the stop function already takes care of that after executing a flush
but before turning off the headswitch. We should be confident that the
GBIF is open for business when we restart the hardware.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Fixes: e812744c5f ("drm: msm: a6xx: Add support for A618")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Highest bank bit configuration is different for a618 gpu. Update
it with the correct configuration which is the reset value incidentally.
Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org>
Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
Fixes: e812744c5f ("drm: msm: a6xx: Add support for A618")
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Add rate limiting of the 'pp done time out' warnings since these
warnings can quickly fill the dmesg buffer.
Signed-off-by: Brian Masney <masneyb@onstation.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
This catches the majority of drivers (unfortunately not if we take
users into account, because all the big drivers have at least a
lastclose hook).
With the prep patches out of the way all drm state is fully protected
and either prevents or can deal with the races from dropping the BKL
around open/close. The only thing left to audit are the various driver
hooks - by keeping the BKL around if any of them are set we have a
very simple cop-out!
Note that one of the biggest prep pieces to get here was making
dev->open_count atomic, which was done in
commit 7e13ad8964
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jan 24 13:01:07 2020 +0000
drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
v2:
- Rebase and fix locking in drm_open() (Chris)
- Indentation fix in drm_release
- Typo fix in the commit message (Sam)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-6-daniel.vetter@ffwll.ch
We want to only take the BKL on crap drivers, but to know whether
we have a crap driver we first need to look it up. Split this shuffle
out from the main BKL-disabling patch, for more clarity. Historical
aside: When the kernel-wide BKL was removed, it was replaced by
drm_global_mutex within the scope of the drm subsystem hence why these
two things are (almost) interchangeable as concepts here.
Since the minors are refcounted drm_minor_acquire is purely internal
and this does not have a driver visible effect.
v2: Push the locking even further into drm_open(), suggested by Chris.
This gives us more symmetry with drm_release(), and maybe a futuer
avenue where we make drm_global_mutex locking (partially) opt-in like
with drm_release_noglobal().
v3:
- Actually push this stuff correctly, don't unlock twice (Chris)
- Fix typo on commit message, plus explain why BKL = drm_global_mutex
(Sam)
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-5-daniel.vetter@ffwll.ch
Instead check for master status, in case we've raced.
This is the last exception to the general rule that we restore fbcon
only when there's no master active. Compositors are supposed to drop
their master status before they switch to a different console back to
text mode (or just switch to text mode directly, without a vt switch).
This is known to break some subtests of kms_fbcon_fbt in igt, but they're
just wrong - it does a graphics/text mode switch for the vt without
updating the master status.
Also add a comment to the drm_client->restore hook that this is expected
going forward from all clients (there's currently just one).
v2: Also drop the force in pan_display
v3: Restore the _force to pan_display, this actually means _locked in that
path. Spotted by Noralf.
Cc: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-3-daniel.vetter@ffwll.ch
1.
Provides a callback (i.e. mtk_hdmi_audio_hook_plugged_cb) to hdmi-codec.
When ASoC machine driver calls hdmi_codec_set_jack_detect(), the
callback will be invoked to save plugged_cb and codec_dev parameters.
+---------+ set_jack_ +------------+ plugged_cb +----------+
| machine | ----------> | hdmi-codec | ----------> | mtk-hdmi |
+---------+ detect() +------------+ codec_dev +----------+
2.
When there is any jack status changes, mtk-hdmi will call the
plugged_cb() to notify hdmi-codec. And then hdmi-codec will call
snd_soc_jack_report().
+----------+ plugged_cb +------------+
| mtk-hdmi | ----------> | hdmi-codec | -> snd_soc_jack_report()
+----------+ codec_dev +------------+
connector_status
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200206102509.2.I230fd59de28e73934a91cb01424e25b9e84727f4@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently we create a new mmap_offset for every call to
mmap_offset_ioctl. This exposes ourselves to an abusive client that may
simply create new mmap_offsets ad infinitum, which will exhaust physical
memory and the virtual address space. In addition to the exhaustion, a
very long linear list of mmap_offsets causes other clients using the
object to incur long list walks -- these long lists can also be
generated by simply having many clients generate their own mmap_offset.
However, we can simply use the drm_vma_node itself to manage the file
association (allow/revoke) dropping our need to keep an mmo per-file.
Then if we keep a small rbtree of per-type mmap_offsets, we can lookup
duplicate requests quickly.
Fixes: cc662126b4 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120104924.4000706-3-chris@chris-wilson.co.uk
(cherry picked from commit 7865559872)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently the cursor is placed on the first overlay plane, which means
it will be at the bottom of the stack when the hw does the compositing
with anything other than primary plane. Since mtk doesn't support plane
zpos, change the cursor location to the top-most plane.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
The cursor and primary planes were hard coded.
Now search for them for passing to drm_crtc_init_with_planes
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
