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
Linux 3.16
backmerge requested by i915, nouveau and radeon authors
Conflicts:
drivers/gpu/drm/i915/i915_gem_render_state.c
drivers/gpu/drm/i915/intel_drv.h
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>
This change implements msm drm specific fb_mmap function for fb device
to properly map the fb address to userspace.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com> (+ minor comment tweak)
This changes activates the iommu support for MDP5, through the
platform config structure.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Alex Deucher
Tetsuo Handa
Dave Airlie
Beeresh Gopal
Stephane Viau
Rob Clark
Hai Li