Modify exynos_dsi driver to support the new panel calls:
prepare and unprepare.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Modify exynos_dpi driver to support the new panel calls:
prepare and unprepare.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
simple-panel is not a valid panel model, so there is no data (video
timings, etc.) associated with it. Therefore drivers can't do anything
useful with it, so it should not appear in the table of OF matches.
Device trees will always need to specify the exact model of the panel.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Innolux N116BGE is an 11.6" WXGA TFT LCD panel connecting to an eDP
interface and with an integrated LED backlight unit.
It is used in the Tegra132 Norrin reference design.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Everyone agrees we should do this,
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
bunch of cleanups
* 'drm-next' of git://people.freedesktop.org/~dvdhrm/linux:
drm: mark drm_context support as legacy
drm: make sysfs device always available for minors
drm: make minor->index available early
drm: merge drm_drv.c into drm_ioctl.c
drm: move module initialization to drm_stub.c
drm: don't de-authenticate clients on master-close
drm: drop redundant drm_file->is_master
drm: extract legacy ctxbitmap flushing
We need to take the connection mutex around the link status
check for non-MST case, but also around the MST link training
on short HPDs.
I suspect we actually should have a dpcd lock in the future as
well, that just lock the local copies of dpcd and flags stored
from that.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Additional Hawaii fixes
- Support for using the display scaler on non-fixed mode displays
- Support for new firmware format that makes it easier to update
- Enable dpm by default on additional asics
- GPUVM improvements
- Support for uncached and write combined gtt buffers
- Allow allocation of BOs larger than visible vram
- Various other small fixes and improvements
* 'drm-next-3.17' of git://people.freedesktop.org/~agd5f/linux: (57 commits)
drm/radeon: Prevent hdmi deep color if max_tmds_clock is undefined.
drm/radeon: Use pflip irqs for pageflip completion if possible. (v2)
drm/radeon: tweak ACCEL_WORKING2 query for the new firmware for hawaii
drm/radeon: use packet3 for nop on hawaii with new firmware
drm/radeon: tweak ACCEL_WORKING2 query for hawaii
drm/radeon: use packet2 for nop on hawaii with old firmware
drm/radeon: update IB size estimation for VM
drm/radeon: split PT setup in more functions
drm/radeon: add VM GART copy optimization to NI as well
drm/radeon: take a BO reference on VM cleanup
drm/radeon: add radeon_bo_ref function
drm/radeon: remove taking mclk_lock from radeon_bo_unref
drm/radeon: adjust default radeon_vm_block_size v2
drm/radeon: try to enable VM flushing once more
drm/radeon: use an intervall tree to manage the VMA v2
drm/radeon: remove radeon_bo_clear_va
drm/radeon: invalidate moved BOs in the VM (v2)
drm/radeon: re-enable dpm by default on BTC
drm/radeon: re-enable dpm by default on cayman
drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM
...
This renames all drm-context helpers to drm_legacy_*() and moves the
internal definitions into the new drm_legacy.h header. This header is
local to DRM-core and drivers shouldn't access it.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
HDMI spec requires a valid max_tmds_clock from edid for hdmi
deep color modes. If a sink violates this, disable deep color.
Also add a hint to user about the deep_color module parameter if
deep color is disabled due to that.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For each minor we allocate a sysfs device as minor->kdev. Currently, this
is allocated and registered in drm_minor_register(). This makes it
impossible to add sysfs-attributes to the device before it is registered.
Therefore, they are not added atomically, nor can we move device_add()
*after* ->load() is called.
This patch makes minor->kdev available early, but only adds the device
during minor-registration. Note that the registration is still called
before ->load() as debugfs needs to be split, too. This will be fixed in
follow-ups.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Instead of allocating the minor-index during registration, we now do this
during allocation. This way, debug-messages between minor-allocation and
minor-registration will now use the correct minor instead of 0. Same is
done for unregistration vs. free, so debug-messages between
device-shutdown and device-destruction show proper indices.
Even though minor-indices are allocated early, we don't enable minor
lookup early. Instead, we keep the entry set to NULL and replace it during
registration / unregistration. This way, the index is allocated but lookup
only works if registered.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
All that is left in drm_drv.c is ioctl management. Merge it into
drm_ioctl.c so we have all ioctl management in one file (and the name is
much more fitting).
Maybe we should now rename drm_stub.c to drm_drv.c again?
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Most of the new DRM management functions are nowadays in drm_stub.c. By
moving the core module initialization to drm_stub.c we can make several
global variables static and keep the stub-open helper local.
The core files now look like this:
drm_stub.c: Core management
drm_drv.c: Ioctl dispatcher
drm_ioctl.c: Actual ioctl backends
drm_fops.c: Char-dev file-operations
A follow-up patch will move what is left from drm_drv.c into drm_ioctl.c.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
If an active DRM-Master closes its device, we deauthenticate all clients
on that master. However, if an inactive DRM-Master closes its device, we
do nothing. This is quite inconsistent and breaks several scenarios:
1) If this was used as security mechanism, it fails horribly if a master
closes a device while VT switched away. Furthermore, none of the few
drivers using ->master_*() callbacks seems to require it, anyway.
2) If you spawn weston (or any other non-UMS compositor) in background
while another compositor is active, both will get assigned to the
same "drm_master" object. If the foreground compositor now exits, all
clients of both the foreground AND background compositor will be
de-authenticated leading to unexpected behavior.
Stop this non-sense and keep clients authenticated. We don't do this when
dropping DRM-Master (i.e., switching VTs) so don't do it on active-close
either!
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
The drm_file->is_master field is redundant as it's equivalent to:
drm_file->master && drm_file->master == drm_file->minor->master
1) "=>"
Whenever we set drm_file->is_master, we also set:
drm_file->minor->master = drm_file->master;
Whenever we clear drm_file->is_master, we also call:
drm_master_put(&drm_file->minor->master);
which implicitly clears it to NULL.
2) "<="
minor->master cannot be set if it is non-NULL. Therefore, it stays as
is unless a file drops it.
If minor->master is NULL, it is only set by places that also adjust
drm_file->is_master.
Therefore, we can safely drop is_master and replace it by an inline helper
that matches:
drm_file->master && drm_file->master == drm_file->minor->master
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
The ctxbitmap code is only used by legacy drivers so lets try to keep it
as separated as possible. Furthermore, the locking is non-obvious and
kinda weird with ctxlist_mutex *and* struct_mutex. Keeping all ctxbitmap
access in one file is much easier to review and makes drm_release() more
readable.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Skip the "manual" pageflip completion checks via polling and
guessing in the vblank handler radeon_crtc_handle_vblank() on
asics which are known to reliably support hw pageflip completion
irqs. Those pflip irqs are a more reliable and race-free method
of handling pageflip completion detection, whereas the "classic"
polling method has some small races in combination with dpm on,
and with the reworked pageflip implementation since Linux 3.16.
On old asics without pflip irqs, the classic method is used.
On asics with known good pflip irqs, only pflip irqs are used
by default, but a new module parameter "use_pflipirqs" allows to
override this in case we encounter asics in the wild with
unreliable or faulty pflip irqs. A module parameter of 0 allows
to use the classic method only in such a case. A parameter of 1
allows to use both classic method and pflip irqs as additional
band-aid to avoid some small races which could happen with the
classic method alone. The setting 1 gives Linux 3.16 behaviour.
Hw pflip irqs are available since R600.
Tested on DCE-4, AMD Cedar - FirePro 2270.
v2: agd5f: only enable pflip interrupts on DCE4+ as they are not
reliable on older asics.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Adjust the previous tweak for hawaii to return 3 if the new firmware is used.
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Older firmware didn't support the new nop packet.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Return 2 so we can be sure the kernel has the necessary
changes for acceleration to work.
Note: This patch depends on these two commits:
- drm/radeon: fix cut and paste issue for hawaii.
- drm/radeon: use packet2 for nop on hawaii with old firmware
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Cc: stable@vger.kernel.org
Older firmware didn't support the new nop packet.
v2 (Andreas Boll):
- Drop usage of packet3 for new firmware
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Cc: stable@vger.kernel.org
That should allow us to allocate bigger BOs.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Move the decision what to use into the common VM code.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This closes a small window where the GPU might have accessed freed up memory.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To be consistent with radeon_bo_unref, needed in the following patch.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's causing lockdep warnings and why should
we access the memory that is freed up?
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
v2: rebase on vm_size scale change. Adjust vm_size default to 8,
Better handle the default and smaller values.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Let's try to fix bugs related to this instead of just disabling it.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Scales much better than scanning the address range linearly.
v2: store pfn instead of address
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Won't work anyway, instead WARN_ON if the VA list isn't
empty when we free the BO.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Don't wait for the BO to be used again, just
update the PT on the next VM use.
v2: remove stray semicolon.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The HDP cache only applies to CPU access to VRAM.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some hawaii boards use a different method for fetching the
voltage information from the vbios.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This ensures the GPU sees all previous CPU writes to VRAM, which makes it
safe:
* For userspace to stream data from CPU to GPU via VRAM instead of GTT
* For IBs to be stored in VRAM instead of GTT
* For ring buffers to be stored in VRAM instead of GTT, if the HPD flush
is performed via MMIO
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
And clean up the function comment a little.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Both on their own are complex enough.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to unblank the display when resuming the MC. No
functional change as this code path is not currently
hit. We always disable the displays entirely rather
than just blanking them.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Seems to make VM flushes more stable on SI and CIK.
v2: only use the PFP on the GFX ring on CIK
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For symmetry with other *_set_wptr hooks.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
PCI GART doesn't support unsnooped access. AGP GART already uses
write-combined CPU mappings.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
That didn't worked correctly any more and opened up a security problem.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Unused and unimplemented. Also fix specifying the
kernel flag incorrectly at one occasion.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Now that fallback to gtt is fixed for cpu access, we can
remove this limit.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78717
v2: use new gart_pin_size to accurately track available gtt.
v3: fix comment
v4: clarify comment
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Gives more accurate count and prevents failures when we can't
allocate memory for the tests.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Gives a more accurate limit than the previous code.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
So we know how large an allocation we can allow.
v2: incorporate Michel's comments
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
v2: fix rebase onto drm-fixes
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Doesn't seem necessary, the GART table memory should be persistent.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These clutter up dmesg during piglit runs. Userspace generally deals
gracefully with this failure.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We keep a cached version of the edid in radeon_connector which
we use for determining connectedness and when to enable certain
features like hdmi audio, etc. When the user uses the firmware
interface to override the driver with some other edid the driver's
copy is never updated. The fetch function will check if there
is a user supplied edid and update the driver's copy if there
is.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80691
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Split radeon_ddc_get_modes() and move it into
radeon_connectors.c since that is the only place
that uses it.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
No need to continue with the loops once we've matched
the appropriate connector.
See commit 8a992ee145
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Valid values are 1 to 251 for 0 to 500 ms latency, 0 for unknown
and 255 for audio/video unsupported by sink, according to HDMI 1.3 spec.
Also matches Radeon HDA verb 0xf7b documentation.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
Indeed, a first attempt at inlining it grew radeon.ko by 7%.
However, 2% of cpu is spent in this function. Simply inlining it gave 1% more fps
in Urban Terror.
v2: We know the minimum MMIO size. Adding it to the if allows the compiler to
optimize the branch out, improving both performance and size.
The v2 patch decreases radeon.ko size by 2%. I didn't re-benchmark, but common sense
says perf is now more than 1% better.
v3: Also change _wreg, make the threshold a define.
Inlining _wreg increased the size a bit compared to v2, so now radeon.ko
is only 1% smaller.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This enables the display scaler on all connectors for r5xx
and newer asics. Previously we only enabled the scaler for
fixed mode displays (eDP or LVDS) since they have to use the
scaler to support non-native modes. Most other displays
are multi-sync or have a built in scaler to support non-native
modes. The default scaling mode for non-fixed displays is
none which will use the scaler in the monitor. Note that
we do not populate any fake modes like we do for fixed
displays so it will only use the modes in the edid. For
other modes, you'll need to populate them manually.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80868
v2: properly handle scaling with no modes defined
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix checkpatch warning:
WARNING: kfree(NULL) is safe this check is probably not required
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This adds CIK support for the new ucode format.
v2: add size validation, integrate debug info
v3: add support for MEC2 on KV
v4: fix typos
v4: update to latest format
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This adds SI support for the new ucode format.
v2: add size validation, integrate debug info
v3: update to latest version
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These are needed to properly handle more frequently
updated firmware.
v2: add new firmware helper functions as well.
v3: update to latest format
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In my review of
commit 98f75de40e
Author: Rob Clark <robdclark@gmail.com>
Date: Fri May 30 11:37:03 2014 -0400
drm: add object property typ
I asked for a check to make sure that we never leak an fb from the
generic mode object lookup since those have completely different
lifetime rules. Rob added it, but outside of the idr mutex, which
means that our dereference of obj->type can already chase free'd
memory.
Somehow I didn't spot this, so fix this asap.
v2: Simplify the conditionals as suggested by Chris.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
are currently doing GFP_KERNEL allocation.
But these functions did not get updated to receive gfp_t argument.
This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions,
and removes the deadlock warning.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave Airlie <airlied@redhat.com>
While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL
allocation, ttm_pool_shrink_scan() does not do it. This can result in stack
overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to
memory pressure.
shrink_slab()
=> ttm_pool_shrink_scan()
=> ttm_page_pool_free()
=> kmalloc(GFP_KERNEL)
=> shrink_slab()
=> ttm_pool_shrink_scan()
=> ttm_page_pool_free()
=> kmalloc(GFP_KERNEL)
Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave Airlie <airlied@redhat.com>
I can observe that RHEL7 environment stalls with 100% CPU usage when a
certain type of memory pressure is given. While the shrinker functions
are called by shrink_slab() before the OOM killer is triggered, the stall
lasts for many minutes.
One of reasons of this stall is that
ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and
are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with
_manager->lock held causes someone (including kswapd) to deadlock when
these functions are called due to memory pressure. This patch changes
"mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to
avoid deadlock.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave Airlie <airlied@redhat.com>
We can use "unsigned int" instead of "atomic_t" by updating start_pool
variable under _manager->lock. This patch will make it possible to avoid
skipping when choosing a pool to shrink in round-robin style, after next
patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork).
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave Airlie <airlied@redhat.com>
list_empty(&_manager->pools) being false before taking _manager->lock
does not guarantee that _manager->npools != 0 after taking _manager->lock
because _manager->npools is updated under _manager->lock.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave Airlie <airlied@redhat.com>
This series of patches add the support of DRM/KMS drivers for STMicroelectronics
chipsets stih416 and stih407.
Hardware is split in two main blocks: Compositor and TVout. Each of them
includes specific hardware IPs and the display timing are controlled by a specific
Video Timing Generator hardware IP (VTG).
Compositor is made of the follow hardware IPs:
- GDP (Generic Display Pipeline) which is an entry point for graphic (RGB)
buffers
- VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers
- HQVDP (High Quality Video Display Processor) that supports scaling,
deinterlacing and some miscellaneous image quality improvements.
It fetches the Video decoded buffers from memory, processes them and pushes
them to the Compositor through a HW dedicated bus.
- Mixer is responsible of mixing all the entries depending of their
respective z-order and layout
TVout is divided in 3 parts:
- HDMI to generate HDMI signals, depending of chipset version HDMI phy can
change.
- HDA to generate signals for HD analog TV
- VIP to control/switch data path coming from Compositor
On stih416 compositor and Tvout are on different dies so a Video Trafic Advance
inter-die Communication mechanism (VTAC) is needed.
+---------------------------------------------+ +----------------------------------------+
| +-------------------------------+ +----+ | | +----+ +--------------------------+ |
| | | | | | | | | | +---------+ +----+ | |
| | +----+ +------+ | | | | | | | | | VIP |---->|HDMI| | |
| | |GPD +------------->| | | | | | | | | | | | +----+ | |
| | +----+ |Mixer |--|-->| | | | | |---|->| switcher| | |
| | | | | | | | | | | | | | +----+ | |
| | | | | | | | | | | | | |---->|HDA | | |
| | +------+ | |VTAC|========>|VTAC| | +---------+ +----+ | |
| | | | | | | | | | | |
| | Compositor | | | | | | | | TVout | |
| +-------------------------------+ | | | | | | +--------------------------+ |
| ^ | | | | | | ^ |
| | | | | | | | | |
| +--------------+ | | | | | | +-------------+ |
| | VTG (master) |----->| | | | | |----->| VTG (slave) | |
| +--------------+ +----+ | | +----+ +-------------+ |
|Digital die | | Analog Die|
+---------------------------------------------+ +----------------------------------------+
On stih407 Compositor and Tvout are on the same die
+-----------------------------------------------------------------+
| +-------------------------------+ +--------------------------+ |
| | | | +---------+ +----+ | |
| | +----+ +------+ | | | VIP |---->|HDMI| | |
| | |GPD +------------->| | | | | | +----+ | |
| | +----+ |Mixer |--|--|->| switcher| | |
| | +----+ +-----+ | | | | | | +----+ | |
| | |VDP +-->+HQVDP+--->| | | | | |---->|HDA | | |
| | +----+ +-----+ +------+ | | +---------+ +----+ | |
| | | | | |
| | Compositor | | TVout | |
| +-------------------------------+ +--------------------------+ |
| ^ ^ |
| | | |
| +--------------+ |
| | VTG | |
| +--------------+ |
|Digital die |
+-----------------------------------------------------------------+
In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used
by HDMI driver to retrieve EDID for monitor.
To unify interfaces of GDP and VDP we create a "layer" interface called by
compositor to control both GPD and VDP.
Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions
to allocate frame buffer.
File naming convention is:
- sti_* for IPs drivers
- sti_drm_* for drm functions implementation.
* 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel:
drm: sti: Add DRM driver itself
drm: sti: add Compositor
drm: sti: add Mixer
drm: sti: add VID layer
drm: sti: add GDP layer
drm: sti: add TVOut driver
drm: sti: add HDA driver
drm: sti: add HDMI driver
drm: sti: add VTAC drivers
drm: sti: add VTG driver
drm: sti: add bindings for DRM driver
This builds upon the previous set of fixes which were pulled on 6th July.
Included in this set are:
- an update from Jean-Francois to add the missing reg documentation entry
to the device tree documentation.
- conversion of the tda998x driver to the component helpers.
* 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox:
drm/i2c: tda998x: add component support
drm/i2c: tda998x: allow re-use of tda998x support code
drm/i2c: tda998x: fix lack of required reg in DT documentation
Conflicts:
drivers/gpu/drm/i2c/tda998x_drv.c
This time around we have a mix of new hw enablement (mdp5 v1.3 /
apq8084), plus devicetree and various upstream changes (mostly
adapting to CCF vs downstream clk driver differences) for mdp4 /
apq8064. With these drm/msm patches plus a few other small patchsets
(from linaro qcom integration branch.. mostly stuff queued up for
3.17) we have the inforce ifc6410 board working, with gpu. Much nicer
to work with than ancient vendor android branch :-)
* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
drm/msm/hdmi: fix HDMI_MUX_EN gpio request typo
drm/msm/hdmi: enable lpm-mux if it is present
drm/msm/mdp5: add support for MDP5 v1.3
drm/msm: fix potential deadlock in gpu init
drm/msm: use upstream iommu
drm/msm: no mmu is only error if not using vram carveout
drm/msm: fix BUG_ON() in error cleanup path
drm/msm/mdp4: add mdp axi clk
drm/msm: hdmi phy 8960 phy pll
drm/msm: update generated headers
drm/msm: DT support for 8960/8064 (v3)
drm/msm: Implement msm drm fb_mmap callback function
drm/msm: activate iommu support
drm/msm: fix double struct_mutex acquire
HDMI_MUX_EN gpio is requested. If an error occurs, the same name
should be printed (HDMI_MUX_EN) instead of HDMI_MUX_SEL (typo).
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Rob Clark <robdclark@gmail.com>
lpm-mux is programmed to enable HDMI connector
on the docking station for S805 chipset based
devices.
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
MDP5 has several functional blocks (ie: VIG/RGB pipes, LMs, ...).
From one revision to another, these blocks' base addresses might
change due to the number of instances present in the MDP5 hw.
A way of dealing with these offset changes is to introduce
dynamic offsets 'per block'.
This change adds support for the new revision of MDP5: v1.3.
The idea is to define one hw config per MDP version and select
either one of them at runtime, after reading the MDP5 version.
Once the MDP version is known, 'per block' dynamic offsets
are initialized through a global pointer, which is then used for
read/write register access.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Somewhere along the way, the firmware loader sprouted another lock
dependency, resulting in possible deadlock scenario:
&dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem
which is problematic vs things like gem mmap.
So introduce a separate mutex to synchronize gpu init.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Downstream kernel IOMMU had a non-standard way of dealing with multiple
devices and multiple ports/contexts. We don't need that on upstream
kernel, so rip out the crazy.
Note that we have to move the pinning of the ringbuffer to after the
IOMMU is attached. No idea how that managed to work properly on the
downstream kernel.
For now, I am leaving the IOMMU port name stuff in place, to simplify
things for folks trying to backport latest drm/msm to device kernels.
Once we no longer have to care about pre-DT kernels, we can drop this
and instead backport upstream IOMMU driver.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Downstream kernel holds this clk via a fake-parent relationship.
Upstream clock framework requires that we hold it explicitly.
Signed-off-by: Rob Clark <robdclark@gmail.com>
On downstream kernel the clk driver directly bangs hdmi phy registers.
For upstream kernel, we need to model this as a clock and register with
the clock framework.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
add necessary DT support so that we can use drm/msm on upstream kernel.
v2: update for review comments
v3: rebase on component helper changes
Signed-off-by: Rob Clark <robdclark@gmail.com>