Dave Airlie [Thu, 26 Sep 2019 01:57:53 +0000 (11:57 +1000)]
Merge tag 'drm-fixes-5.4-2019-09-25' of git://people.freedesktop.org/~agd5f/linux into drm-next
drm-fixes-5.4-2019-09-25:
amdgpu:
- Fix a 64 bit divide
- Prevent a memory leak in a failure case in dc
- Load proper gfx firmware on navi14 variants
drm-fixes-5.4-2019-09-19:
amdgpu:
- Add more navi12 and navi14 PCI ids
- Misc fixes for renoir
- Fix bandwidth issues with multiple displays on vega20
- Support for Dali
- Fix a possible oops with KFD on hawaii
- Fix for backlight level after resume on some APUs
- Other misc fixes
Dave Airlie [Wed, 25 Sep 2019 22:48:16 +0000 (08:48 +1000)]
Merge tag 'drm-misc-next-fixes-2019-09-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
- Multiple panfrost fixes for regulator support and page fault handling
- Some cleanups and fixes in the self-refresh helpers
- Some cleanups and fixes in the atomic helpers
Steven Price [Fri, 13 Sep 2019 16:03:10 +0000 (17:03 +0100)]
drm/panfrost: Prevent race when handling page fault
When handling a GPU page fault addr_to_drm_mm_node() is used to
translate the GPU address to a buffer object. However it is possible for
the buffer object to be freed after the function has returned resulting
in a use-after-free of the BO.
Change addr_to_drm_mm_node to return the panfrost_gem_object with an
extra reference on it, preventing the BO from being freed until after
the page fault has been handled.
Steven Price [Fri, 6 Sep 2019 14:20:53 +0000 (15:20 +0100)]
drm/panfrost: Remove NULL checks for regulator
devm_regulator_get() is now used to populate pfdev->regulator which
ensures that this cannot be NULL (a dummy regulator will be returned if
necessary). So remove the checks in panfrost_devfreq_target().
Mark Brown [Wed, 4 Sep 2019 12:30:32 +0000 (13:30 +0100)]
drm/panfrost: Fix regulator_get_optional() misuse
The panfrost driver requests a supply using regulator_get_optional()
but both the name of the supply and the usage pattern suggest that it is
being used for the main power for the device and is not at all optional
for the device for function, there is no meaningful handling for absent
supplies. Such regulators should use the vanilla regulator_get()
interface, it will ensure that even if a supply is not described in the
system integration one will be provided in software.
Sean Paul [Wed, 18 Sep 2019 20:07:29 +0000 (16:07 -0400)]
drm: Measure Self Refresh Entry/Exit times to avoid thrashing
Currently the self refresh idle timer is a const set by the crtc. This
is fine if the self refresh entry/exit times are well-known for all
panels used on that crtc. However panels and workloads can vary quite a
bit, and a timeout which works well for one doesn't work well for
another.
In the extreme, if the timeout is too short we could get in a situation
where the self refresh exits are taking so long we queue up a self refresh
entry before the exit commit is even finished.
This patch changes the idle timeout to a moving average of the entry
times + a moving average of exit times + the crtc constant.
This patch was tested on rockchip, with a kevin CrOS panel the idle
delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On
the same board, the bob panel idle delay lands around ~340ms (90 entry
+ 150 exit + 100 const).
WRT the dedicated mutex in self_refresh_data, it would be nice if we
could rely on drm_crtc.mutex to protect the average times, but there are
a few reasons why a separate lock is a better choice:
- We can't rely on drm_crtc.mutex being held if we're doing a nonblocking
commit
- We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us
whether the lock was already held in the acquire context (it eats
-EALREADY), so we can't tell if we should drop it or not
- We don't need such a heavy-handed lock for what we're trying to do,
commit ordering doesn't matter, so a point-of-use lock will be less
contentious
Daniel Vetter [Tue, 3 Sep 2019 19:06:42 +0000 (21:06 +0200)]
drm/atomic: Rename crtc_state->pageflip_flags to async_flip
It's the only flag anyone actually cares about. Plus if we're unlucky,
the atomic ioctl might need a different flag for async flips. So
better to abstract this away from the uapi a bit.
Daniel Vetter [Tue, 3 Sep 2019 19:06:41 +0000 (21:06 +0200)]
drm/atomic: Reject FLIP_ASYNC unconditionally
It's never been wired up. Only userspace that tried to use it (and
didn't actually check whether anything works, but hey it builds) is
the -modesetting atomic implementation. And we just shut that up.
If there's anyone else then we need to silently accept this flag no
matter what, and find a new one. Because once a flag is tainted, it's
lost.
Daniel Vetter [Thu, 5 Sep 2019 18:53:18 +0000 (20:53 +0200)]
drm/atomic: Take the atomic toys away from X
The -modesetting ddx has a totally broken idea of how atomic works:
- doesn't disable old connectors, assuming they get auto-disable like
with the legacy setcrtc
- assumes ASYNC_FLIP is wired through for the atomic ioctl
- not a single call to TEST_ONLY
Iow the implementation is a 1:1 translation of legacy ioctls to
atomic, which is a) broken b) pointless.
We already have bugs in both i915 and amdgpu-DC where this prevents us
from enabling neat features.
If anyone ever cares about atomic in X we can easily add a new atomic
level (req->value == 2) for X to get back the shiny toys.
Since these broken versions of -modesetting have been shipping,
there's really no other way to get out of this bind.
v2:
- add an informational dmesg output (Rob, Ajax)
- reorder after the DRIVER_ATOMIC check to avoid useless noise (Ilia)
- allow req->value > 2 so that X can do another attempt at atomic in
the future
v3: Go with paranoid, insist that the X should be first (suggested by
Rob)
uncovered a bit a mess in dp drivers. Most drivers (from a quick look,
all except i915) register all the dp stuff in their init code, which
is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up,
because drm_dp_aux_register tries to add a child to a device in sysfs
(the connector) which doesn't even exist yet.
No one seems to have cared thus far. But with the above change I also
moved the setting of dev->registered after the ->load callback, in an
attempt to keep old drivers from hitting any WARN_ON backtraces. But
that moved radeon.ko from the "working, by accident" to "now also
broken" category.
Since this is a huge mess I figured a revert would be simplest. But
this check has already caught issues in i915:
drm/i915: Do not create a new max_bpc prop for MST connectors
Hence I'd like to retain it. Fix the radeon regression by moving the
setting of dev->registered back to were it was, and stop the
backtraces with an explicit check for dev->driver->load.
Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The
next patch will improve the kerneldoc and add a todo entry for this.
Felix Kuehling [Thu, 5 Sep 2019 23:22:02 +0000 (19:22 -0400)]
drm/amdgpu: Fix KFD-related kernel oops on Hawaii
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job") Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Trek [Sat, 31 Aug 2019 19:25:36 +0000 (21:25 +0200)]
drm/amdgpu: Check for valid number of registers to read
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).
Hans de Goede [Sat, 7 Sep 2019 20:32:38 +0000 (22:32 +0200)]
drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.
Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59
Note that despite that being an userspace bug, not sending unnecessary
udev events is a good idea in general.
Zhan Liu [Thu, 22 Aug 2019 18:54:18 +0000 (14:54 -0400)]
drm/amd/display: Add missing HBM support and raise Vega20's uclk.
[Why]
When more than 2 displays are connected to the graphics card,
only the minimum memory clock is needed. However, when more
displays are connected, the minimum memory clock is not
sufficient enough to support the overwhelming bandwidth.
System will hang under this circumstance.
Also, the old code didn't address HBM cards, which has 2
pseudo channels. We need to add the HBM part here.
[How]
When graphics card connects to 2 or more displays,
switch to high memory clock. Also, choose memory
multiplier based on whether its regular DRAM or HBM.
Aaron Liu [Wed, 4 Sep 2019 03:47:48 +0000 (11:47 +0800)]
drm/amdgpu: disable stutter mode for renoir
With stutter mode enabled, NMI prints frequently.
Disable stutter for the moment because NMI warning storm, and will
enable it back till the issue is addressed
Dave Airlie [Tue, 17 Sep 2019 06:31:30 +0000 (16:31 +1000)]
Merge branch 'linux-5.4' of git://github.com/skeggsb/linux into drm-next
A couple of fixes from Thierry fixing issues as a result of the
reservation object rework in this cycle, as well as a fix from Lyude
to allow the driver to load on Thinkpad P71.
Dave Airlie [Thu, 12 Sep 2019 13:56:12 +0000 (23:56 +1000)]
Merge tag 'drm-msm-next-2019-09-06' of https://gitlab.freedesktop.org/drm/msm into drm-next
+ move msm8998 (snapdragon 835) display support
+ dpu fixes/cleanup
+ better async commit support for cursor updates
(for dpu for now, I'll add mdp5 and possibly
mdp4 once the movers deliver boxes full of my
older hardware, so for v5.5)
drm/nouveau/bar/gm20b: Avoid BAR1 teardown during init
Writing the 0x1704 (BUS_BAR1_BLOCK) register causes the GPU to probe the
memory region at the programmed address. The result is an address decode
error in the external memory controller because address 0, which is what
is written to the register, is not designated as accessible to devices.
Avoid triggering DMA from the GPU by removing teardown of the BAR1.
drm/nouveau: Fix ordering between TTM and GEM release
When the last reference to a TTM BO is dropped, ttm_bo_release() will
acquire the DMA reservation object's wound/wait mutex while trying to
clean up (ttm_bo_cleanup_refs_or_queue() via ttm_bo_release()). It is
therefore essential that drm_gem_object_release() be called after the
TTM BO has been uninitialized, otherwise drm_gem_object_release() has
already destroyed the wound/wait mutex (via dma_resv_fini()).
Prior to commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before
TTM object"), the reservation object was locked across all of the buffer
object creation.
After splitting nouveau_bo_new() into separate nouveau_bo_alloc() and
nouveau_bo_init() functions, the reservation object is passed to the
latter, so the lock needs to be held across that function as well.
Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
drm/nouveau: Fix fallout from reservation object rework
Commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM
object") introduced a subtle change in how the buffer allocation size is
handled. Prior to that change, the size would get aligned to at least a
page, whereas after that change a non-page-aligned size would get passed
through unmodified. This ultimately causes a BUG_ON() to trigger in
drm_gem_private_object_init() and crashes the system.
Fix this by restoring the code that align the allocation size.
Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Reported-by: Ilia Mirkin <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
Lyude Paul [Fri, 13 Sep 2019 22:03:50 +0000 (18:03 -0400)]
drm/nouveau/kms/nv50-: Don't create MSTMs for eDP connectors
On the ThinkPad P71, we have one eDP connector exposed along with 5 DP
connectors, resulting in a total of 11 TMDS encoders. Since the GPU on
this system is also capable of MST, we create an additional 4 fake MST
encoders for each DP port. Unfortunately, we also do this for the eDP
port as well, resulting in:
Which breaks things, since DRM has a hard coded limit of 32 encoders.
So, fix this by not creating MSTMs for any eDP connectors. This brings
us down to 31 encoders, although we can do better.
This fixes driver probing for nouveau on the ThinkPad P71.
There are at least two DSI controller drivers which relies on the old
behaviour of adv7511 driver. To avoid platform breakage this patch
should be reverted. This is a temporary solution, as it blocks adv7511
usage with other platforms.
Assumption that DSI device driver (bridge/panel) should first expose
drm_bridge/drm_panel object, then look for DSI bus is just incorrect -
it can work with devices controlled via i2c but it cannot work with
devices controlled via DSI - they will not be able to probe.
To solve the issue following steps should be performed:
- rework reverted patch allowing co-operation with broken DSI controller
drivers - with simple/ugly workaround,
- fix controller drivers and then remove workaround.
Chris Wilson [Mon, 26 Aug 2019 13:07:50 +0000 (14:07 +0100)]
drm/i915: Use NOEVICT for first pass on attemping to pin a GGTT mmap
The intention is that we first try to pin the current vma into the
mappable aperture only if it is already in use or it fits in the free
space and will not cause contention. The first attempt was meant to be
using PIN_NOEVICT to reuse the current vma if possible, following up
with different eviction strategies.
Xiaolin Zhang [Fri, 23 Aug 2019 06:57:31 +0000 (14:57 +0800)]
drm/i915: to make vgpu ppgtt notificaiton as atomic operation
vgpu ppgtt notification was split into 2 steps, the first step is to
update PVINFO's pdp register and then write PVINFO's g2v_notify register
with action code to tirgger ppgtt notification to GVT side.
currently these steps were not atomic operations due to no any protection,
so it is easy to enter race condition state during the MTBF, stress and
IGT test to cause GPU hang.
the solution is to add a lock to make vgpu ppgtt notication as atomic
operation.
Chris Wilson [Fri, 23 Aug 2019 15:39:44 +0000 (16:39 +0100)]
drm/i915: Flush the existing fence before GGTT read/write
Our fence management is lazy, very lazy. If the user marks an object as
untiled, we do not immediately flush the fence but merely mark it as
dirty. On the next use we have to remember to check and remove the fence,
by which time we hope it is idle and we do not have to wait.
v2: Throw away the old fence on the next ggtt_pin.
Chris Wilson [Fri, 23 Aug 2019 13:26:46 +0000 (14:26 +0100)]
drm/i915: Hold irq-off for the entire fake lock period
Sadly lockdep records when the irqs are re-enabled and then marks up the
fake lock as being irq-unsafe. Our hand is forced and so we must mark up
the entire fake lock critical section as irq-off.
Hopefully this is the last tweak required!
v2: Not quite, we need to mark the timeline spinlock as irqsafe. That
was a genuine bug being hidden by the earlier lockdep splat.
Dave Airlie [Fri, 6 Sep 2019 06:40:28 +0000 (16:40 +1000)]
Merge tag 'drm-next-5.4-2019-08-30' of git://people.freedesktop.org/~agd5f/linux into drm-next
drm-next-5.4-2019-08-30:
amdgpu:
- Add DC support for Renoir
- Add some GPUVM hw bug workarounds
- add support for the smu11 i2c controller
- GPU reset vram lost bug fixes
- Navi1x powergating fixes
- Navi12 power fixes
- Renoir power fixes
- Misc bug fixes and cleanups
Weinan Li [Mon, 2 Sep 2019 05:57:59 +0000 (13:57 +0800)]
drm/i915/gvt: update RING_START reg of vGPU when the context is submitted to i915
The guest may use this register to identify the running state of one
context. Emulate it as the value in context image as if the context runs
on the GPU hardware.
Xiaolin Zhang [Tue, 27 Aug 2019 08:39:23 +0000 (16:39 +0800)]
drm/i915/gvt: update vgpu workload head pointer correctly
when creating a vGPU workload, the guest context head pointer should
be updated correctly by comparing with the exsiting workload in the
guest worklod queue including the current running context.
in some situation, there is a running context A and then received 2 new
vGPU workload context B and A. in the new workload context A, it's head
pointer should be updated with the running context A's tail.
v2: walk through guest workload list in backward way.
There were bugs in the DSI transfer (read and write) function
as it was only tested with displays ever needing a single byte
to be written. Fixed it up and tested so we can now write
messages of up to 16 bytes and read up to 4 bytes from the
display.
Tested with a Sony ACX424AKP display: this display now self-
identifies and can control backlight in command mode.
Signed-off-by: Rob Clark <[email protected]> Fixes: 3de433c5b38a ("drm/msm: Use the correct dma_sync calls in msm_gem") Tested-by: Fabio Estevam <[email protected]>
Sean Paul [Wed, 7 Aug 2019 18:51:50 +0000 (14:51 -0400)]
drm/msm/dsi: Fix return value check for clk_get_parent
clk_get_parent returns an error pointer upon failure, not NULL. So the
checks as they exist won't catch a failure. This patch changes the
checks and the return values to properly handle an error pointer.
Rob Clark [Thu, 29 Aug 2019 16:45:16 +0000 (09:45 -0700)]
drm/msm: async commit support
Now that flush/wait/complete is decoupled from the "synchronous" part of
atomic commit_tail(), add support to defer flush to a timer that expires
shortly before vblank for async commits. In this way, multiple atomic
commits (for example, cursor updates) can be coalesced into a single
flush at the end of the frame.
v2: don't hold lock over ->wait_flush(), to avoid locking interaction
that was causing fps drop when combining page flips or non-async
atomic commits and lots of legacy cursor updates
Rob Clark [Thu, 29 Aug 2019 16:45:15 +0000 (09:45 -0700)]
drm/msm: split power control from prepare/complete_commit
With atomic commit, ->prepare_commit() and ->complete_commit() may not
be evenly balanced (although ->complete_commit() will complete each
crtc that had been previously prepared). So these will no longer be
a good place to enable/disable clocks needed for hw access.
Rob Clark [Thu, 29 Aug 2019 16:45:14 +0000 (09:45 -0700)]
drm/msm: add kms->flush_commit()
Add ->flush_commit(crtc_mask). Currently a no-op, but kms backends
should migrate writing flush registers to this hook, so we can decouple
pushing updates to hardware, and flushing the updates.
Once we add async commit support, the hw updates will be pushed down to
the hw synchronously, but flushing the updates will be deferred until as
close to vblank as possible, so that multiple updates can be combined in
a single frame.
Rob Clark [Thu, 29 Aug 2019 16:45:12 +0000 (09:45 -0700)]
drm/msm: add kms->wait_flush()
First step in re-working the atomic related internal API to prepare for
async updates pending.. ->wait_flush() is intended to block until there
is no in-progress flush.
A crtc_mask is used, rather than an atomic state object, as this will
later be used for async flush after the atomic state is destroyed.
Rob Clark [Thu, 29 Aug 2019 16:45:11 +0000 (09:45 -0700)]
drm/msm/dpu: handle_frame_done() from vblank irq
Previously the callback was called from whoever called wait_for_vblank(),
but that isn't a great plan when wait_for_vblank() stops getting called,
and results in frame_done_timer expiring.
Rob Clark [Thu, 29 Aug 2019 16:45:10 +0000 (09:45 -0700)]
drm/msm/dpu: add real wait_for_commit_done()
Just waiting for next vblank isn't ideal.. we should really be looking
at the hw FLUSH register value to know if there is still an in-progress
flush without stalling unnecessarily when there is no pending flush.
Rob Clark [Thu, 29 Aug 2019 16:45:09 +0000 (09:45 -0700)]
drm/msm/dpu: unwind async commit handling
It attempted to avoid fps drops in the presence of cursor updates. But
it is racing, and can result in hw updates after flush before vblank,
which leads to underruns.
Rob Clark [Tue, 20 Aug 2019 23:12:28 +0000 (16:12 -0700)]
drm/msm/dpu: fix "frame done" timeouts
Previously, dpu_crtc_frame_event_work() would try to aquire all the
modeset locks in order to check whether it can release bandwidth. (If
we only have cmd-mode display, bandwidth can be released at frame-done
time.)
The problem with this is that it is also responsible for signalling
frame_done_comp, which dpu_crtc_commit_kickoff() waits on if there is
already a frame pending. This is called in the msm_atomic_commit_tail()
path.. which means that for non-nonblock commits, at least some of the
modeset locks are already held.
Re-work this scheme to use a reference count to track our need to have
clocks enabled. It is incremented for each atomic commit, and
decremented in the corresponding frame-done. Additionally, any crtc
used in video mode hold an extra reference while they are enabled. The
net effect is that we can determine in frame-done whether it is safe to
drop bandwidth without needing to aquire any modeset locks.
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
Jeffrey Hugo [Mon, 8 Jul 2019 15:12:24 +0000 (08:12 -0700)]
drm/msm/mdp5: Find correct node for creating gem address space
Creating the msm gem address space requires a reference to the dev where
the iommu is located. The driver currently assumes this is the same as
the platform device, which breaks when the iommu is outside of the
platform device (ie in the parent). Default to using the platform device,
but check to see if that has an iommu reference, and if not, use the parent
device instead. This should handle all the various iommu designs for
mdp5 supported systems.
The following errors show up when booting the Nexus 5:
msm_dsi_phy fd922a00.dsi-phy: [drm:dsi_phy_driver_probe] *ERROR*
dsi_phy_regulator_init: failed to init regulator, ret=-517
msm_dsi_phy fd922a00.dsi-phy: [drm:dsi_phy_driver_probe] *ERROR*
dsi_phy_driver_probe: failed to init regulator
dsi_phy_regulator_init() already logs the error, so no need to log
the same error a second time in dsi_phy_driver_probe(). This patch
also changes dsi_phy_regulator_init() to not log the error if the
error code is -EPROBE_DEFER to reduce noise in dmesg.
Rob Clark [Sun, 30 Jun 2019 13:14:42 +0000 (06:14 -0700)]
drm/msm/dpu: remove dpu_mdss:hwversion
Unused and the extra rpm get/put interferes with handover from
bootloader (ie. happens before we have a chance to check if
things are already enabled).
Jeffrey Hugo [Fri, 28 Jun 2019 16:28:31 +0000 (09:28 -0700)]
drm/msm: Transition console to msm framebuffer
If booting a device using EFI, efifb will likely come up and claim the
console. When the msm display stack finally comes up, we want the
console to move over to the msm fb, so add support to kick out any
firmware based framebuffers to accomplish the console transition.
Linus Walleij [Sat, 29 Jun 2019 12:59:31 +0000 (14:59 +0200)]
drm/msm/hdmi: Convert to use GPIO descriptors
This switches the MSM HDMI code to use GPIO descriptors.
Normally we would fetch the GPIOs from the device with the
flags GPIOD_IN or GPIOD_OUT_[LOW|HIGH] to set up the lines
immediately, but since the code seems eager to actively
drive the lines high/low when turning HDMI on and off, we
just fetch the GPIOs as-is and keep the code explicitly
driving them.
The old code would try legacy bindings (GPIOs without any
"-gpios" suffix) but this has been moved to the gpiolib
as a quirk by the previous patch.
Linus Walleij [Sat, 29 Jun 2019 12:59:29 +0000 (14:59 +0200)]
drm/msm/dpu: Drop unused GPIO code
The DPU has some kind of idea that it wants to be able to
bring up power using GPIO lines. The struct dss_gpio is however
completely unused and should this be done, it should be done
using the GPIO descriptor framework rather than this API
which relies on the global GPIO numberspace. Delete this
code before anyone hurt themselves.
The inclusion of <linux/gpio.h> was abused to get some OF
and IRQ headers implicitly included into the DPU utilities,
make these includes explicit and push them down into the actual
implementation.
Sam Ravnborg [Sun, 4 Aug 2019 06:55:51 +0000 (08:55 +0200)]
drm/msm: drop use of drmP.h
Drop the deprecated drmP.h header file, and trim msm_drv.h
to the relevant include files.
This resulted in a suprisingly many edits as many files relied
on headers included via msm_drv.h.
But msm_drv.h is not supposed to carry include files it do not need, so
the individual files have to include what extra they needs.
v2:
- Rebased on top of https://gitlab.freedesktop.org/drm/msm.git msm-next
Aaron Liu [Fri, 14 Dec 2018 03:21:41 +0000 (11:21 +0800)]
drm/amdgpu: fix no interrupt issue for renoir emu (v2)
In renoir's vega10_ih model, there's a security change in mmIH_CHICKEN
register, that limits IH to use physical address (FBPA, GPA) directly.
Those chicken bits need to be programmed first.
With the introduction of the as_lock to serialize address space registers,
the hwaccess_lock is only used within the job code and is not protecting
anything. panfrost_job_hw_submit() only accesses registers for 1 job slot
and it's already serialized by drm_sched.
Rob Herring [Mon, 26 Aug 2019 22:33:16 +0000 (17:33 -0500)]
drm/panfrost: Flush and disable address space when freeing page tables
Currently, page tables are freed without disabling the address space first.
This probably is fine as we'll switch to new page tables when the address
space is allocated again and runtime PM suspend will reset the GPU
clearing the registers. However, it's better to clean up after ourselves.
There is also a problem that we could be accessing the h/w in
tlb_inv_context() when suspended.
Rework the disable code to make sure we flush caches/TLBs and disable the
address space before freeing the page tables if we are not suspended. As
the tlb_inv_context() hook is only called when freeing the page tables and
we do a flush before disabling the AS, lets remove the flush from
tlb_inv_context and avoid any runtime PM issues.
projects / linux.git / log