| Age | Commit message (Collapse) | Author |
|---|
|
omap_gem_objects are added to dev->obj_list in omap_gem_new, and removed
in omap_gem_free_object. Unfortunately there's no locking for
dev->obj_list, which eventually leads to a crash:
WARNING: CPU: 1 PID: 1123 at lib/list_debug.c:59 __list_del_entry+0xa4/0xe0()
list_del corruption. prev->next should be e9281344, but was ea722b84
Add a spinlock to protect dev->obj_list.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
spin_is_locked(x) returns always 0 on uniprocessor, triggering BUG() in
omapdrm.
Change it to use assert_spin_locked() to fix the issue.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
We need to ignore DIGIT SYNC LOST error when enabling/disabling TV
output. The code does that, but it ignores the DIGI SYNC LOST when
enabling any output. Normally this does no harm, but it could make us
miss DIGIT SYNC LOST on some rare occasions.
Fix the code to only ignore DIGIT SYNC LOST when enabling/disabling TV.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
omapdrm tries to avoid error floods by unregistering the error irq when
an error happens, and then registering the error irq again later.
However, the code is racy, as it sometimes tries to unregister the error
irq when it's already unregistered, leading to WARN().
Also, the code only registers the error irq again when something is done
on that particular output, i.e. if only TV is used to flip the buffers,
and LCD is showing a same buffer, an error on LCD will cause the LCD
error irq to be unregistered and never registered again.
To fix this, let's keep the error irqs always enabled and trust the
DRM_ERROR_RATELIMITED to limit the flood.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
omapdrm uses normal DRM_ERROR() print when the HW reports an error. As
we sometimes may get a flood of errors, let's rather use
DRM_ERROR_RATELIMITED().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
When not using proper hotplug detection, DRM polls periodically the
connectors to find out if a cable is connected. This polling can happen
at any time, even very late in the suspend process.
This causes a problem with omapdrm, when the poll happens during the
suspend process after GPIOs have been disabled, leading to a crash in
gpio_get().
This patch fixes the issue by adding suspend and resume hooks to
omapdrm, in which we disable and enable, respectively, the polling.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
omapdrm has dummy functions for platform_device's
suspend/resume/shutdown. The functions don't do anything, and those
platform device functions are deprecated, so remove them from omapdrm.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The tiler irq handler uses engine->async value, but the code that sets
engine->async and enables the interrupt does not have a barrier. This
may cause the irq handler to see the old value of engine->async, causing
memory corruption.
Reported-by: Harinarayan Bhatta <harinarayan@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
omap_plane_pre_apply() sets the plane's output channel too late, only
after the plane has already been otherwise configured and enabled. This
causes problems, as at the configuration stage we need to make decisions
based on the output channel.
This may lead to bad plane settings or failing to setup the plane.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
On OMAP5 it is not possible to use TILER buffer with CPU when caching or
write-combining is used. Doing so leads to errors from the memory
manager.
However, on OMAP4, write-combining works fine.
This patch adds platform specific data for the TILER, and a function
tiler_get_cpu_cache_flags() which can be used to get the caching mode to
be used.
Note that without write-combining the use of the TILER buffer with CPU
is unusably slow. It's still good to have it operational for testing
purposes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
omapdrm doesn't check if the pitch of the framebuffer and the color
format's bits-per-pixel are compatible. omapdss requires that the stride
of a buffer is an integer number of pixels
For example, when using modetest with a display that has x resolution of
1280, and using packed 24 RGB mode (3 bytes per pixel), modetest
allocates a buffer with a byte stride of 4 * 1280 = 5120. But 5120 / 3 =
1706.666... pixels, which causes wrong colors and a tilt on the screen.
Add a check into omapdrm to return an error if the user tries to use
such a combination.
Note: this is not a HW requirement at least for non-rotation use cases,
but a SW driver requirement. In the future we should study if also
rotation use cases are fine with any stride size, and if so, change the
driver to allow these strides.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
When an error happens in omap_framebuffer_create(),
omap_framebuffer_create() calls omap_framebuffer_destroy() if the fb
struct has been allocated. However, that crashes, as
omap_framebuffer_destroy(), which calls drm_framebuffer_cleanup(),
should only be called after drm_framebuffer_init()
Fix this by just calling kfree() for the allocated fb when an error
happens.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
omapdrm should work fine even if fbdev is missing. The current driver
crashes in that case, though, as it is missing checks for the fbdev.
Add the checks so that we don't free fbdev or restore fbdev mode when
there's no fbdev.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
unpin_worker() calls omap_framebuffer_unpin() without any locks, which
looks very suspicious. However, both pin and unpin are always called via
the driver's private workqueue, so the access is synchronized that way.
Add a comment to make this clear.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
omap_framebuffer_pin() and omap_framebuffer_unpin() are currently
broken, as they cannot be called multiple times (i.e. pin, pin, unpin,
unpin), which is what happens in certain cases. This issue causes the
driver to possibly use 0 as an address for a displayed buffer, leading
to OCP error from DSS.
This patch fixes the issue by adding a simple pin_count, used to track
the number of pins.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Clear omap_obj's paddr when unmapping the memory, so that it's easier to
catch bad use of the paddr.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The DRM documentation says:
"If a page flip is already pending, the page_flip operation must return
-EBUSY."
Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning
-EBUSY.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
OMAP DSS hardware supports changing the output port to which an overlay
manager's video stream goes. For example, DPI video stream can come from
any of the four overlay managers on OMAP5.
However, as it's difficult to manage the change in the driver, the
omapdss driver does not support that at the moment, and has a hardcoded
overlay manager per output.
omapdrm, on the other hand, uses the hardware features to find out which
overlay manager to use for an output, which causes problems. For
example, on OMAP5, omapdrm tries to use DIGIT overlay manager for DPI
output, instead of the LCD3 required by the omapdss driver.
This patch changes the omapdrm to use the omapdss driver's hardcoded
overlay managers, which fixes the issue.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The ptn3460_bridge_attach symbol is never used outside this file, so it
should be static.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The ps8622_attach and ps8522_driver symbols are never used outside this
file, so they should be static.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
[treding@nvidia.com: break cyclic dependency, add KMS helper dependency]
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
As part of allocation of the drm_i915_private variable, drrs capability
enum is initialized to DRRS_NOT_SUPPORTED. Hence need not initialize at
each connector init.
Moreover initializing this enum at connector init will reset
the successful DRRS initialization of previous connector, as we have
the DRRS support for only one panel at a time.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The logical place for clearing the RPS latched interrupt bits is when
resetting the RPS interrupts, so move the corresponding part from the RPS
disable function to the reset function. During resetting we already
cleared the IIR bits, so the only thing missing there was clearing pm_iir.
Note that we call gen6_disable_rps_interrupts() also during driver load
and resume time via intel_uncore_sanitize() when i915 interrupts are
still not installed. If there are any pending RPS bits at this point
(which after this patch wouldn't be cleared) they will be cleared by the
reset code via the interrupt preinstall hooks.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When disabling RPS interrupts there is a race where we disable RPS
inerrupts while the interrupt handler is running and the handler has
already latched the pending RPS interrupt from the master IIR register.
Afterwards the disabling path clears the PM IIR bits, making the state
of pending interrupts inconsistent from the interrupt handler's point of
view. This triggers the following warning: "The master control interrupt
lied (PM)!".
To fix this make sure that any running interrupt handler (which may
have already latched the master IIR) finishes before clearing the IIR
bits.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87347
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Originally it was impossible to be dropping the last refcount in this
function since there was always one around still from the idr. But in
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Aug 6 09:10:18 2014 +0200
drm: Don't grab an fb reference for the idr
we've switched to weak references, broke that assumption but forgot to
fix it up.
Since we still force-disable planes it's only possible to hit this
when racing multiple rmfb with fbdev restoring or similar evil things.
As long as userspace is nice it's impossible to hit the BUG_ON.
But the BUG_ON would most likely be hit from fbdev code, which usually
invovles the console_lock besides all modeset locks. So very likely
we'd never get the bug reports if this was hit in the wild, hence
better be safe than sorry and backport.
Spotted by Matt Roper while reviewing other patches.
[airlied: pull this back into 4.0 - the oops happens there]
Cc: stable@vger.kernel.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
drm-intel-next-2015-03-13-rebased:
- EU count report param for gen9+ (Jeff McGee)
- piles of pll/wm/... fixes for chv, finally out of preliminary hw support
(Ville, Vijay)
- gen9 rps support from Akash
- more work to move towards atomic from Matt, Ander and others
- runtime pm support for skl (Damien)
- edp1.4 intermediate link clock support (Sonika)
- use frontbuffer tracking for fbc (Paulo)
- remove ilk rc6 (John Harrison)
- a bunch of smaller things and fixes all over
Includes backmerge because git rerere couldn't keep up any more.
* tag 'drm-intel-next-2015-03-13-merge' of git://anongit.freedesktop.org/drm-intel: (366 commits)
drm/i915: Make sure the primary plane is enabled before reading out the fb state
drm/i915: Update DRIVER_DATE to 20150313
drm/i915: Fix vmap_batch page iterator overrun
drm/i915: Export total subslice and EU counts
drm/i915: redefine WARN_ON_ONCE to include the condition
drm/i915/skl: Implement WaDisableHBR2
drm/i915: Remove the preliminary_hw_support shackles from CHV
drm/i915: Read CHV_PLL_DW8 from the correct offset
drm/i915: Rewrite IVB FDI bifurcation conflict checks
drm/i915: Rewrite some some of the FDI lane checks
drm/i915/skl: Enable the RPS interrupts programming
drm/i915/skl: Enabling processing of Turbo interrupts
drm/i915/skl: Updated the i915_frequency_info debugfs function
drm/i915: Simplify the way BC bifurcation state consistency is kept
drm/i915/skl: Updated the act_freq_mhz_show sysfs function
drm/i915/skl: Updated the gen9_enable_rps function
drm/i915/skl: Updated the gen6_rps_limits function
drm/i915/skl: Restructured the gen6_set_rps_thresholds function
drm/i915/skl: Updated the gen6_set_rps function
drm/i915/skl: Updated the gen6_init_rps_frequencies function
...
|
|
Before, we would set the property, but also return -EINVAL because of a
broken fallthrough.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Active was here, and we allowed users to set it, but not to get it as
well.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Just as we provide crtc->mode pre-populated with the requested mode,
move adjusted_mode into hwmode before we call the crtc's mode_set,
making sure to restore it on failure.
Allows drivers which thoughtlessly discard adjusted_mode in their
mode_set hooks (e.g. Exynos) to use hwmode directly, and also provides
some neat symmetry with crtc->mode.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Since we're now using mode == NULL to represent disabled, it's not
wholly surprising that we'd want to compare NULL modes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
mode is always NULL at this point in the function, so make our intention
clear.
Signed-off-by: Daniel Stone <daniels@collabora.com>
[danvet: Stop clearing mode too to enlist gcc in tracking
uninitialized usage. And remove a space while at it.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When doing a native or i2c aux write the sink will indicate the number
of bytes written even if it the nacks the transfer. When we receive a
nack we just return an error upwards, but it might still be interesting
to see how many bytes made it before the nack. So include that information
in the debug messages.
v2: Also print the message size (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
v2: Pass in rotation info to sprite plane updates as well.
v3: Use helper to determine 90/270 rotation. (Michel Thierry)
v4: Rebased for fb modifiers and atomic changes.
For: VIZ-4546
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v3)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Need to do this in order to support 90/270 rotated display.
v2: Pass in drm_plane instead of plane index to intel_obj_display_address.
v3:
* Renamed intel_obj_display_address to intel_plane_obj_offset.
(Chris Wilson)
* Simplified rotation check to bitwise AND. (Chris Wilson)
v4:
* Extracted 90/270 rotation check into a helper function. (Michel Thierry)
v5:
* Rebased for ggtt view changes.
For: VIZ-4545
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
90/270 rotated scanout needs a rotated GTT view of the framebuffer.
This is put in a separate VMA with a dedicated ggtt view and wired such that
it is created when a framebuffer is pinned to a 90/270 rotated plane.
Rotation is only possible with Yb/Yf buffers and error is propagated to
user space in case of a mismatch.
Special rotated page view is constructed at the VMA creation time by
borrowing the DMA addresses from obj->pages.
v2:
* Do not bother with pages for rotated sg list, just populate the DMA
addresses. (Daniel Vetter)
* Checkpatch cleanup.
v3:
* Rebased on top of new plane handling (create rotated mapping when
setting the rotation property).
* Unpin rotated VMA on unpinning from display plane.
* Simplify rotation check using bitwise AND. (Chris Wilson)
v4:
* Fix unpinning of optional rotated mapping so it is really considered
to be optional.
v5:
* Rebased for fb modifier changes.
* Rebased for atomic commit.
* Only pin needed view for display. (Ville Syrjälä, Daniel Vetter)
v6:
* Rebased after preparatory work has been extracted out. (Daniel Vetter)
v7:
* Slightly simplified tiling geometry calculation.
* Moved rotated GGTT view implementation into i915_gem_gtt.c (Daniel Vetter)
v8:
* Do not use i915_gem_obj_size to get object size since that actually
returns the size of an VMA which may not exist.
* Rebased for ggtt view changes.
v9:
* Rebased after code review changes on the preceding patches.
* Tidy function definitions. (Joonas Lahtinen)
For: VIZ-4726
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v4)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
For now only default implementation defaulting to normal view.
v2: Some code review cleanups. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Plane state carries the rotation information which is needed for determining
the appropriate GGTT view type.
This just adds the parameter with the actual usage coming in future patches.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
To support frame buffer rotation we need to be able to pass on the information
on what kind of GGTT view is required for display.
This patch just adds the parameter and makes all the callers default to the
normal view.
v2: Rebased for ggtt view changes.
v3: Don't limit PIN_MAPPABLE to normal views just yet. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v3)
[danvet: s/BUG/WARN/ in the patch hunk because. At least where the
BUG_ON isn't fatal right away.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
It will be used in a later patch and also convert all height parameters
from int to unsigned int.
v2: Rebased for fb modifiers.
v3: Fixed v2 rebase.
v4:
* Height should be unsigned int.
* Make it take pixel_format for consistency and simplicity.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v1)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v4)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
msleep() can sleep for way too long, so switch wait_for() to use
usleep_range() instead. Following a totally unscientific method
I just picked the range as W-2W.
This cuts the i915 init time on my BSW to almost half:
- initcall i915_init+0x0/0xa8 [i915] returned 0 after 419977 usecs
+ initcall i915_init+0x0/0xa8 [i915] returned 0 after 238419 usecs
Note that I didn't perform any other benchmarks on this so far.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
drm-next
rcar-du fixes
* 'drm/next/rcar-du' of git://linuxtv.org/pinchartl/fbdev:
drm: rcar-du: Enable the atomic updates API
drm: rcar-du: Don't initialize event->pipe field
drm: rcar-du: Fix framebuffer reference leak through plane state
MAINTAINERS: Remove rcar-du.h entry
|
|
drm-next
adv7511 fixes.
* 'drm/next/adv7511' of git://linuxtv.org/pinchartl/fbdev:
drm: adv7511: Refactor power management
drm: adv7511: Fix nested sleep when reading EDID
drm: adv7511: Fix DDC error interrupt handling
|
|
While running kmemleak chasing a different memleak, I saw that the
capture_error_state function was leaking some objects, for example:
unreferenced object 0xffff8800a9b72148 (size 8192):
comm "kworker/u16:0", pid 1499, jiffies 4295201243 (age 990.096s)
hex dump (first 32 bytes):
00 00 04 00 00 00 00 00 5d f4 ff ff 00 00 00 00 ........].......
00 30 b0 01 00 00 00 00 37 00 00 00 00 00 00 00 .0......7.......
backtrace:
[<ffffffff811e5ae4>] create_object+0x104/0x2c0
[<ffffffff8178f50a>] kmemleak_alloc+0x7a/0xc0
[<ffffffff811cde4b>] __kmalloc+0xeb/0x220
[<ffffffffa038f1d9>] kcalloc.constprop.12+0x2d/0x2f [i915]
[<ffffffffa0316064>] i915_capture_error_state+0x3f4/0x1660 [i915]
[<ffffffffa03207df>] i915_handle_error+0x7f/0x660 [i915]
[<ffffffffa03210f7>] i915_hangcheck_elapsed+0x2e7/0x470 [i915]
[<ffffffff8108d574>] process_one_work+0x144/0x490
[<ffffffff8108dfbd>] worker_thread+0x11d/0x530
[<ffffffff81094079>] kthread+0xc9/0xe0
[<ffffffff817a2398>] ret_from_fork+0x58/0x90
[<ffffffffffffffff>] 0xffffffffffffffff
The following objects are allocated in i915_gem_capture_buffers, but not
released in i915_error_state_free:
- error->active_bo_count
- error->pinned_bo
- error->pinned_bo_count
- error->active_bo[vm_count] (allocated in i915_gem_capture_vm).
The leaks were introduced by
commit 95f5301dd880da2dea2c9a9c29750064536d426a
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Wed Jul 31 17:00:15 2013 -0700
drm/i915: Update error capture for VMs
v2: Reuse iterator and add culprit commit details (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The next commit will need functions to be reordered. Do it separately to
help review.
This only moves functions without any change to the code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Planes are destroyed after framebuffers, which has the side effect of
disabling all planes. There is thus no need to disable planes explicitly
when destroying them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The function will convert the Q16 source coordinates to integers, avoid
converting integers to Q16 first and perform the opposite conversion.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This matches the rest of the file and clarifies the functions' purpose.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move the set_enabled function to avoid the forward declaration. While at
it prefix it with omap_crtc_ like most other functions in the file, and
fix the comment stating in which contexts the function is called.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The full_update field is always set to true before calling
omap_crtc_appy(), resulting in its value always being true in the single
location where it is tested, in omap_crtc_pre_apply(). Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
