Chris Wilson [Wed, 6 Aug 2014 08:08:32 +0000 (10:08 +0200)]
drm: Perform cmdline mode parsing during connector initialisation
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed by drm_fb_helper_initial_config() which is called after
i915.ko's custom initial_config() as a fallback method. So in order for
us to honour it, we need to move the cmdline parser earlier. If we
perform the connector cmdline parsing as soon as we initialise the
connector, that cmdline mode and forced status is then available even if
the fbdev helper is not compiled in or never called.
We also then expose the cmdline user mode in the connector mode lists.
v2: Rebase after connector->name upheaval.
v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely
simplifies things while at that.
v4: Fix checkpatch.
v5: Select FB_CMDLINE to adapt to the changed fbdev patch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these 2 functions
and always build them in.
Whiel at it fix the checkpatch fail in this code.
v2: Also move fb_mode_option. Spotted by the kbuild.
v3: Review from Geert:
- Keep the old copyright notice from fb_mem.c, although I have no
idea what exactly applies.
- Only compile this when needed.
Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
--
I prefer if we can merge this through drm-next since we'll use it
there in follow-up patches.
-Daniel
Daniel Vetter [Wed, 6 Aug 2014 07:10:18 +0000 (09:10 +0200)]
drm: Don't grab an fb reference for the idr
The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
at module unload time.
But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.
The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.
Fix this by no longer holding a full fb reference for the idr, but
instead just have a weak reference using kref_get_unless_zero. But
that requires us to synchronize and clean up with the idr and fb_lock
in drm_framebuffer_free, so add that. It's a bit ugly that we have to
unconditionally grab the fb_lock, but without that someone might creep
through a race.
This leak was caught by the fb leak check in drm_mode_config_cleanup.
Originally the leak was introduced in
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>
Chris Wilson [Thu, 24 Jul 2014 13:23:10 +0000 (14:23 +0100)]
drm: Unlink dead file_priv from list of active files first
In order to prevent external observers walking the list of open DRM
files from seeing an invalid drm_file_private in the process of being
torndown, the first operation we need to take is to unlink the
drm_file_private from that list.
Tetsuo Handa [Sun, 3 Aug 2014 11:02:31 +0000 (20:02 +0900)]
drm/ttm: Pass GFP flags in order to avoid deadlock.
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.
Tetsuo Handa [Sun, 3 Aug 2014 11:02:03 +0000 (20:02 +0900)]
drm/ttm: Fix possible stack overflow by recursive shrinker calls.
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.
Tetsuo Handa [Sun, 3 Aug 2014 11:01:10 +0000 (20:01 +0900)]
drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions.
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.
Tetsuo Handa [Sun, 3 Aug 2014 11:00:40 +0000 (20:00 +0900)]
drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan().
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).
Tetsuo Handa [Sun, 3 Aug 2014 10:59:35 +0000 (19:59 +0900)]
drm/ttm: Fix possible division by 0 in ttm_dma_pool_shrink_scan().
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.
Dave Airlie [Mon, 4 Aug 2014 23:28:37 +0000 (09:28 +1000)]
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.
Dave Airlie [Mon, 4 Aug 2014 23:26:09 +0000 (09:26 +1000)]
Merge branch 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next
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
Dave Airlie [Mon, 4 Aug 2014 23:22:27 +0000 (09:22 +1000)]
Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next
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
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>
Rob Clark [Thu, 10 Jul 2014 02:08:15 +0000 (22:08 -0400)]
drm/msm: use upstream iommu
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.
Rob Clark [Wed, 25 Jun 2014 13:54:36 +0000 (09:54 -0400)]
drm/msm: hdmi phy 8960 phy pll
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.
Hai Li [Wed, 18 Jun 2014 20:55:27 +0000 (16:55 -0400)]
drm/msm: Implement msm drm fb_mmap callback function
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)
Dave Airlie [Mon, 4 Aug 2014 07:57:34 +0000 (17:57 +1000)]
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 [Thu, 24 Jul 2014 01:53:45 +0000 (11:53 +1000)]
drm: close race in connector registration (v2)
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: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Chris Wilson [Mon, 4 Aug 2014 06:15:09 +0000 (07:15 +0100)]
drm/i915: only hook up hpd pulse for DP outputs
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: Dave Airlie <airlied@redhat.com> Cc: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 4 Aug 2014 05:07:21 +0000 (15:07 +1000)]
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.
...
drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail
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.
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.
drm/exynos: control blending of mixer graphic layer 0
The mixer graphic layer 0 isn't blended as default by commit 0377f4ed9f1aed30292c4e3c87f24e028ae26f36(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.
drm/exynos: Add MODULE_DEVICE_TABLE entries for various components
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.
This reverts commit d089621896c3530a9bd309f96e9c9124d07f6c3f was
original to prevent multiple MODULE_DEVICE_TABLE in one module.
Which, as a side-effect broke autoloading of the module.
Since 21bdd17b21b45ea48e06e23918d681afbe0622e9 it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading
Since 21bdd17b21b45ea48e06e23918d681afbe0622e9 it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading
Linus Torvalds [Sun, 3 Aug 2014 16:58:20 +0000 (09:58 -0700)]
Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Thomas Gleixner:
"Two fixes in the timer area:
- a long-standing lock inversion due to a printk
- suspend-related hrtimer corruption in sched_clock"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
timer: Fix lock inversion between hrtimer_bases.lock and scheduler locks
sched_clock: Avoid corrupting hrtimer tree during suspend
Andrzej Hajda [Thu, 3 Jul 2014 13:10:31 +0000 (15:10 +0200)]
drm/exynos/ipp: remove incorrect checks of list_first_entry result
list_first_entry does not return NULL on empty list so this check
does not make sense. Moreover there is already code which prevents calling
list_first_entry on empty lists.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Thu, 17 Jul 2014 09:01:23 +0000 (18:01 +0900)]
drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs
The offset of register DSIM_PLLTMR_REG in Exynos5410 / 5420 / 5440
SoCs is different from the one in Exynos4 SoCs.
In case of Exynos5410 / 5420 / 5440 SoCs, there is no frequency
band bit in DSIM_PLLCTRL_REG, and it uses DSIM_PHYCTRL_REG and
DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Thu, 17 Jul 2014 09:01:21 +0000 (18:01 +0900)]
drm/exynos: fimd: support LCD I80 interface
To support MIPI command mode based I80 interface panel,
FIMD should do followings:
- Sets LCD I80 interface timings configuration.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Sets LCD block configuration for I80 interface.
- Sets ideal(pixel) clock is 2 times faster than the original one
to generate frame done IRQ prior to the next TE signal.
- Implements trigger feature that transfers image data if there is page
flip request, and implements TE handler to call trigger function.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Tue, 22 Jul 2014 10:49:44 +0000 (19:49 +0900)]
drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
This is a temporary solution and should be made by more
generic way.
To support LCD I80 interface, the DSI host should register
TE interrupt handler from the TE GPIO of attached panel.
So the panel generates a tearing effect synchronization signal
then the DSI host calls the CRTC device manager to trigger
to transfer video image.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Thu, 17 Jul 2014 09:01:19 +0000 (18:01 +0900)]
drm/exynos: add TE handler to support LCD I80 interface
To support LCD I80 interface, the panel should generate
Tearing Effect synchronization signal between MCU and FB
to display video images.
And the display controller should trigger to transfer
video image at this signal.
So the panel receives the TE IRQ, then calls these handler
chains to notify it to the display controller.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
YoungJun Cho [Thu, 17 Jul 2014 09:01:17 +0000 (18:01 +0900)]
drm/exynos: use wait_event_timeout() for safety usage
There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip()
when exynos_drm_crtc_mode_set_commit() is failed.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
drm/exynos: hdmi: enable exynos 4210 and 4x12 soc support
Configuration sets for Exynos 4210 and 4x12 SoC were already defined in
Exynos HDMI and Mixed drivers, but they lacked proper linking to device
tree 'compatible' values. This patch fixes this issue adding support for
following compatible values: samsung,exynos4210-mixer,
samsung,exynos4212-mixer and samsung,exynos4210-hdmi. It also corrects
access to sclk_mixer clock, which is available only on Exynos 4210.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
drm/exynos: hdmi: make 'hdmi-en' regulator optional and keep it enabled
HDMI_EN regulator is additional regulator for providing voltage source
for DCC lines available on HDMI connector. When there is no power
provided for DDC epprom, some TV-sets do not pulls up HPD (hot plug
detect) line, what causes HDMI block to stay turned off. This patch
enables HDMI_EN regulator (if available) on driver probe and keep it
enabled all the time to let TV-set correctly signal HPD event.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
drm/exynos: Fix NULL pointer exception when suspending without components
Fix a NULL pointer exception when main exynos drm driver was probed
successfully but no components were added (e.g. by incomplete DTS). In
such case the exynos_drm_load() is never called and drvdata is NULL.
The NULL pointer exception may theoretically also happen as a effect of race between
adding components and main driver: if suspend of the driver happens
before adding components.
Linus Torvalds [Sat, 2 Aug 2014 17:57:39 +0000 (10:57 -0700)]
Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm
Pull ARM fixes from Russell King:
"A few fixes for ARM. Some of these are correctness issues:
- TLBs must be flushed after the old mappings are removed by the DMA
mapping code, but before the new mappings are established.
- An off-by-one entry error in the Keystone LPAE setup code.
Fixes include:
- ensuring that the identity mapping for LPAE does not remove the
kernel image from the identity map.
- preventing userspace from trapping into kgdb.
- fixing a preemption issue in the Intel iwmmxt code.
- fixing a build error with nommu.
Other changes include:
- Adding a note about which areas of memory are expected to be
accessible while the identity mapping tables are in place"
* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
ARM: 8124/1: don't enter kgdb when userspace executes a kgdb break instruction
ARM: idmap: add identity mapping usage note
ARM: 8115/1: LPAE: reduce damage caused by idmap to virtual memory layout
ARM: fix alignment of keystone page table fixup
ARM: 8112/1: only select ARM_PATCH_PHYS_VIRT if MMU is enabled
ARM: 8100/1: Fix preemption disable in iwmmxt_task_enable()
ARM: DMA: ensure that old section mappings are flushed from the TLB
Omar Sandoval [Fri, 1 Aug 2014 17:14:06 +0000 (18:14 +0100)]
ARM: 8124/1: don't enter kgdb when userspace executes a kgdb break instruction
The kgdb breakpoint hooks (kgdb_brk_fn and kgdb_compiled_brk_fn)
should only be entered when a kgdb break instruction is executed
from the kernel. Otherwise, if kgdb is enabled, a userspace program
can cause the kernel to drop into the debugger by executing either
KGDB_BREAKINST or KGDB_COMPILED_BREAK.
Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Russell King [Tue, 29 Jul 2014 11:18:34 +0000 (12:18 +0100)]
ARM: idmap: add identity mapping usage note
Add a note about the usage of the identity mapping; we do not support
accesses outside of the identity map region and kernel image while a
CPU is using the identity map. This is because the identity mapping
may overwrite vmalloc space, IO mappings, the vectors pages, etc.
Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Linus Torvalds [Sat, 2 Aug 2014 00:37:01 +0000 (17:37 -0700)]
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Peter Anvin:
"A single fix to not invoke the espfix code on Xen PV, as it turns out
to oops the guest when invoked after all. This patch leaves some
amount of dead code, in particular unnecessary initialization of the
espfix stacks when they won't be used, but in the interest of keeping
the patch minimal that cleanup can wait for the next cycle"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86_64/entry/xen: Do not invoke espfix64 on Xen
Linus Torvalds [Sat, 2 Aug 2014 00:16:05 +0000 (17:16 -0700)]
Merge tag 'staging-3.16-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver bugfixes from Greg KH:
"Here are some tiny staging driver bugfixes that I've had in my tree
for the past week that resolve some reported issues. Nothing major at
all, but it would be good to get them merged for 3.16-rc8 or -final"
* tag 'staging-3.16-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: vt6655: Fix disassociated messages every 10 seconds
staging: vt6655: Fix Warning on boot handle_irq_event_percpu.
staging: rtl8723au: rtw_resume(): release semaphore before exit on error
iio:bma180: Missing check for frequency fractional part
iio:bma180: Fix scale factors to report correct acceleration units
iio: buffer: Fix demux table creation
David Herrmann [Wed, 23 Jul 2014 15:26:37 +0000 (17:26 +0200)]
drm: drop unused "struct drm_queue"
This object is unused, drop it.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
David Herrmann [Wed, 23 Jul 2014 15:26:36 +0000 (17:26 +0200)]
drm: remove unused "struct drm_freelist"
This object is not used except for static fields in drm_bufs *cough*.
Inline the watermark fields and drop the unused structure definition.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Linus Torvalds [Fri, 1 Aug 2014 19:49:02 +0000 (12:49 -0700)]
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM straggler SoC fix from Olof Johansson:
"A DT bugfix for Nomadik that had an ambigouos double-inversion of a
gpio line, and one MAINTAINER URL update that might as well go in now.
We could hold off until the merge window, but then we'll just have to
mark the DT fix for stable and it just seems like in total causing
more work"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
MAINTAINERS: Update Tegra Git URL
ARM: nomadik: fix up double inversion in DT
Anssi Hannula [Fri, 1 Aug 2014 15:55:47 +0000 (11:55 -0400)]
dm cache: fix race affecting dirty block count
nr_dirty is updated without locking, causing it to drift so that it is
non-zero (either a small positive integer, or a very large one when an
underflow occurs) even when there are no actual dirty blocks. This was
due to a race between the workqueue and map function accessing nr_dirty
in parallel without proper protection.
People were seeing under runs due to a race on increment/decrement of
nr_dirty, see: https://lkml.org/lkml/2014/6/3/648
Fix this by using an atomic_t for nr_dirty.
Reported-by: roma1390@gmail.com Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
Russell King [Fri, 7 Feb 2014 19:49:44 +0000 (19:49 +0000)]
drm/i2c: tda998x: add component support
Add component helper support to the tda998x driver. This permits the
TDA998x to be declared as a separate device in device tree, and bound
at the appropriate moment with a co-operating card driver.
The existing slave_encoder interfaces are kept while there are existing
users of it in order to prevent regressions.
Tested-by: Darren Etheridge <detheridge@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Russell King [Fri, 7 Feb 2014 19:17:21 +0000 (19:17 +0000)]
drm/i2c: tda998x: allow re-use of tda998x support code
Re-jig the TDA998x code so that we separate the functionality from the
drm slave encoder implementation. In several places, this is pretty
clearly the correct thing to do, because we can avoid repetitively
having to convert from the drm_encoder to the TDA998x private
structure, particularly with the driver internal functions.
The main motivation behind this change is to allow the code to be
re-used with a standard drm_encoder and drm_connector implementation
based on the component helpers, rather than the slave_encoder system.
The addition of this will be in the following patch.
We keep the slave_encoder interface as there are existing users of
this; we need to give them time to convert and test.
Tested-by: Darren Etheridge <detheridge@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
1d3d4437eae1 ("vmscan: per-node deferred work") added a flags field to
struct shrinker assuming that all shrinkers were zero filled. The dm
bufio shrinker is not zero filled, which leaves arbitrary kmalloc() data
in flags. So far the only defined flags bit is SHRINKER_NUMA_AWARE.
But there are proposed patches which add other bits to shrinker.flags
(e.g. memcg awareness).
Rather than simply initializing the shrinker, this patch uses kzalloc()
when allocating the dm_bufio_client to ensure that the embedded shrinker
and any other similar structures are zeroed.
This fixes theoretical over aggressive shrinking of dm bufio objects.
If the uninitialized dm_bufio_client.shrinker.flags contains
SHRINKER_NUMA_AWARE then shrink_slab() would call the dm shrinker for
each numa node rather than just once. This has been broken since 3.12.
Jan Kara [Fri, 1 Aug 2014 10:20:02 +0000 (12:20 +0200)]
timer: Fix lock inversion between hrtimer_bases.lock and scheduler locks
clockevents_increase_min_delta() calls printk() from under
hrtimer_bases.lock. That causes lock inversion on scheduler locks because
printk() can call into the scheduler. Lockdep puts it as:
======================================================
[ INFO: possible circular locking dependency detected ] 3.15.0-rc8-06195-g939f04b #2 Not tainted
-------------------------------------------------------
trinity-main/74 is trying to acquire lock:
(&port_lock_key){-.....}, at: [<811c60be>] serial8250_console_write+0x8c/0x10c
but task is already holding lock:
(hrtimer_bases.lock){-.-...}, at: [<8103caeb>] hrtimer_try_to_cancel+0x13/0x66
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
Fix the problem by using printk_deferred() which does not call into the
scheduler.
Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Jan Kara <jack@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Eric Biggers [Wed, 25 Jun 2014 04:45:08 +0000 (23:45 -0500)]
vfs: fix check for fallocate on active swapfile
Fix the broken check for calling sys_fallocate() on an active swapfile,
introduced by commit 0790b31b69374ddadefe ("fs: disallow all fallocate
operation on active swapfile").
Signed-off-by: Eric Biggers <ebiggers3@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The direct-io.c rewrite to use the iov_iter infrastructure stopped updating
the size field in struct dio_submit, and thus rendered the check for
allowing asynchronous completions to always return false. Fix this by
comparing it to the count of bytes in the iov_iter instead.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reported-by: Tim Chen <tim.c.chen@linux.intel.com> Tested-by: Tim Chen <tim.c.chen@linux.intel.com>
Merge tag 'pm+acpi-3.16-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"One commit that fixes a problem causing PNP devices to be associated
with wrong ACPI device objects sometimes during device enumeration due
to an incorrect check in a matching function.
That problem was uncovered by the ACPI device enumeration rework in
3.14"
* tag 'pm+acpi-3.16-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / PNP: Fix acpi_pnp_match()
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux
Pull clock driver fix from Mike Turquette:
"A single patch to re-enable audio which is broken on all DRA7
SoC-based platforms. Missed this one from the last set of fixes"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
clk: ti: clk-7xx: Correct ABE DPLL configuration
Pull crypto fix from Herbert Xu:
"This adds missing SELinux labeling to AF_ALG sockets which apparently
causes SELinux (or at least the SELinux people) to misbehave :)"
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI barrier fix from James Bottomley:
"This is a potential data corruption fix: If we get an error sending
down a barrier, we simply ignore it meaning the barrier semantics get
violated without anyone being any the wiser. If the system crashes at
this point, the filesystem potentially becomes corrupt. Fix is to
report errors on failed barriers"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: handle flush errors properly
Peter Ujfalusi [Wed, 2 Apr 2014 13:48:45 +0000 (16:48 +0300)]
clk: ti: clk-7xx: Correct ABE DPLL configuration
ABE DPLL frequency need to be lowered from 361267200
to 180633600 to facilitate the ATL requironments.
The dpll_abe_m2x2_ck clock need to be set to double
of ABE DPLL rate in order to have correct clocks
for audio.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
Milan Broz [Tue, 29 Jul 2014 18:41:09 +0000 (18:41 +0000)]
crypto: af_alg - properly label AF_ALG socket
Th AF_ALG socket was missing a security label (e.g. SELinux)
which means that socket was in "unlabeled" state.
This was recently demonstrated in the cryptsetup package
(cryptsetup v1.6.5 and later.)
See https://bugzilla.redhat.com/show_bug.cgi?id=1115120
This patch clones the sock's label from the parent sock
and resolves the issue (similar to AF_BLUETOOTH protocol family).
Cc: stable@vger.kernel.org Signed-off-by: Milan Broz <gmazyland@gmail.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Make the link between all the hardware drivers and DRM/KMS interface.
Create the driver itself and make it register all the sub-components.
Use GEM CMA helpers for buffer allocation.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Rob Clark <robdclark@gmail.com>
projects / linux-beck.git / log