- 07 8月, 2014 2 次提交
-
-
由 Shobhit Kumar 提交于
Ensure that the DSI packets for a particular sequence are completely sent before going ahead in the enabling or disabling of the panel Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Pavel Machek 提交于
Gcc warns that addr might be used uninitialized. It may not, but I see why gcc gets confused. Additionally, hiding code with side-effects inside WARN_ON() argument seems uncool, so I moved it outside. Signed-off-by: NPavel Machek <pavel@ucw.cz> [danvet: Add obligatory /* shuts up gcc */ comment.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 8月, 2014 12 次提交
-
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Tetsuo Handa 提交于
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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@kernel.org> [2.6.35+] Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Tetsuo Handa 提交于
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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@kernel.org> [2.6.35+] Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Tetsuo Handa 提交于
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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@kernel.org> [3.3+] Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Tetsuo Handa 提交于
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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@kernel.org> [3.3+] Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Tetsuo Handa 提交于
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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@kernel.org> [3.3+] Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Merge branch 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next 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
-
git://ftp.arm.linux.org.uk/~rmk/linux-cubox由 Dave Airlie 提交于
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
-
git://people.freedesktop.org/~robclark/linux由 Dave Airlie 提交于
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
-
由 Dave Airlie 提交于
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
-
- 04 8月, 2014 26 次提交
-
-
由 Beeresh Gopal 提交于
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: NBeeresh Gopal <gbeeresh@codeaurora.org> Signed-off-by: NStephane Viau <sviau@codeaurora.org> Reviewed-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Beeresh Gopal 提交于
lpm-mux is programmed to enable HDMI connector on the docking station for S805 chipset based devices. Signed-off-by: NBeeresh Gopal <gbeeresh@codeaurora.org> Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Stephane Viau 提交于
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: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Downstream kernel holds this clk via a fake-parent relationship. Upstream clock framework requires that we hold it explicitly. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
由 Hai Li 提交于
This change implements msm drm specific fb_mmap function for fb device to properly map the fb address to userspace. Signed-off-by: NHai Li <hali@codeaurora.org> Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> (+ minor comment tweak)
-
由 Stephane Viau 提交于
This changes activates the iommu support for MDP5, through the platform config structure. Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Mutex is already grabbed in show_locked().. somehow this slipped through. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Dave Airlie 提交于
Merge tag 'drm-intel-next-2014-07-25-merged' of git://anongit.freedesktop.org/drm-intel into drm-next Final feature pull for 3.17. drm-intel-next-2014-07-25: - Ditch UMS support (well just the config option for now) - Prep work for future platforms (Sonika Jindal, Damien) - runtime pm/soix fixes (Paulo, Jesse) - psr tracking improvements, locking fixes, now enabled by default! - rps fixes for chv (Deepak, Ville) - drm core patches for rotation support (Ville, Sagar Kamble) - the i915 parts unfortunately didn't make it yet - userptr fixes (Chris) - minimum backlight brightness (Jani), acked long ago by Matthew Garret on irc - I've forgotten about this patch :( QA is a bit unhappy about the DP MST stuff since it broke hpd testing a bit, but otherwise looks sane. I've backmerged drm-next to resolve conflicts with the mst stuff, which means the new tag itself doesn't contain the overview as usual. * tag 'drm-intel-next-2014-07-25-merged' of git://anongit.freedesktop.org/drm-intel: (75 commits) drm/i915/userptr: Keep spin_lock/unlock in the same block drm/i915: Allow overlapping userptr objects drm/i915: Ditch UMS config option drm/i915: respect the VBT minimum backlight brightness drm/i915: extract backlight minimum brightness from VBT drm/i915: Replace HAS_PCH_SPLIT which incorrectly lets some platforms in drm/i915: Returning from increase/decrease of pllclock when invalid drm/i915: Setting legacy palette correctly for different platforms drm/i915: Avoid incorrect returning for some platforms drm/i915: Writing proper check for reading of pipe status reg drm/i915: Returning the right VGA control reg for platforms drm/i915: Allowing changing of wm latencies for valid platforms drm/i915: Adding HAS_GMCH_DISPLAY macro drm/i915: Fix possible overflow when recording semaphore states. drm/i915: Do not unmap object unless no other VMAs reference it drm/i915: remove plane/cursor/pipe assertions from intel_crtc_disable drm/i915: Reorder ctx unref on ppgtt cleanup drm/i915/error: Check the potential ctx obj's vm drm/i915: Fix printing proper min/min/rpe values in debugfs drm/i915: BDW can also detect unclaimed registers ...
-
由 Dave Airlie 提交于
Daniel pointed out with hotplug that userspace could be trying to oops us as root for lols, and that to be correct we shouldn't register the object with the idr before we have fully set the connector object up. His proposed solution was a lot more life changing, this seemed like a simpler proposition to me, get the connector object id from the idr, but don't register the object until the drm_connector_register callback. The open question is whether the drm_mode_object_register needs a bigger lock than just the idr one, but I can't see why it would, but I can be locking challenged. v2: fix bool noreg into sane - add comment. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Chris Wilson 提交于
On HSW+, the digital encoders are shared between HDMI and DP outputs, with one encoder masquerading as both. The VBT should tell us if we need to have DP or HDMI support on a particular port, but if we don't have DP support and we enable the DP hpd pulse handler then we cause an oops. Don't hook up the DP hpd handling if we don't have a DP port. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856 Reported-by: Intel QA Team. Signed-off-by: Dave Airlie <airlied@redhat.com> # v1 [ickle: Fix the error handling after a malloc failure] Reviewed-by: NDave Airlie <airlied@redhat.com> Cc: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next This pull request includes i80 interface support, module auto-loading ipp consolidation, and trivail fixups and cleanups. Summary: - Add i80 interface support. For this, we added some features to Exynos drm framework, which don't affect any other SoC and common framework because they are specific to Exynos drm. - Add module auto-loading support. For this, sub drivers of Exynos drm exports their of match tables to userspace. This allows modules to be loaded automatically based on devicetree information - Consolidate ipp driver. This patch just just includes cleanups and a littl bit refactoring codes. If there is any problem, please kindly let me know. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (38 commits) drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail drm/exynos: g2d: make ioctls more robust drm/exynos: hdmi: add null check for hdmiphy_port drm/exynos: control blending of mixer graphic layer 0 drm/exynos: Add MODULE_DEVICE_TABLE entries for various components Subject: Revert "drm/exynos: remove MODULE_DEVICE_TABLE definitions" Subject: Revert "drm/exynos: fix module build error" drm/exynos/ipp: simplify ipp_find_driver drm/exynos/ipp: simplify ipp_create_id drm/exynos/ipp: remove redundant messages drm/exynos/ipp: simplify ipp_find_obj drm/exynos/ipp: remove useless registration checks drm/exynos/ipp: simplify memory check function drm/exynos/ipp: remove incorrect checks of list_first_entry result drm/exynos/ipp: remove temporary variable drm/exynos/ipp: correct address type drm/exynos/ipp: remove struct exynos_drm_ipp_private drm/exynos/ipp: remove unused field from exynos_drm_ipp_private drm/exynos/ipp: remove type casting drm/exynos: g2d: add exynos4212 as a compatible device. ...
-
由 Tobias Jakobi 提交于
Currently the DRM_IOCTL_EXYNOS_G2D_GET_VER ioctl always succeeds, even if no G2D support is available. Let the ioctl fail when this is the case, so that userspace can accurately probe for G2D support. This also fixes the exynos tests in libdrm. There 'g2d_init' doesn't fail when G2D is absent, leading to a segfault later. Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by: NINki Dae <inki.dae@samsung.com>
-
由 Tobias Jakobi 提交于
Both exynos_g2d_set_cmdlist_ioctl and exynos_g2d_exec_ioctl don't check if the G2D was succesfully probe. If that is not the case, then g2d_priv is just NULL and extracting 'dev' from it in the next step is going to produce a kernel oops. Add proper checks and return ENODEV if the G2D is not available. Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by: NINki Dae <inki.dae@samsung.com>
-
由 Seung-Woo Kim 提交于
The hdmiphy can be apb and hdmiphy_port can be null. So before accessing hdmiphy_port, it should be checked. Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Joonyoung Shim 提交于
The mixer graphic layer 0 isn't blended as default by commit 0377f4ed(drm/exynos: Don't blend mixer layer 0). But it needs to be blended with graphic layer 0 if video layer is enabled by vp because video layer is bottom. Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Sjoerd Simons 提交于
Add MODULE_DEVICE_TABLE calls for the various OF match tables that currently don't have one. This allows the module to be autoloaded based on devicetree information. Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Sjoerd Simons 提交于
This reverts commit d0896218 was original to prevent multiple MODULE_DEVICE_TABLE in one module. Which, as a side-effect broke autoloading of the module. Since 21bdd17b it is possible to have multiple calls to MODULE_DEVICE_TABLE, so the patch can be reverted to restore support for autoloading Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Sjoerd Simons 提交于
Since 21bdd17b it is possible to have multiple calls to MODULE_DEVICE_TABLE, so the patch can be reverted to restore support for autoloading Conflicts: drivers/gpu/drm/exynos/exynos_drm_fimd.c drivers/gpu/drm/exynos/exynos_drm_g2d.c Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Linus Torvalds 提交于
-