A fence is never later than itself. This caused a bunch of overhead for AMDGPU.
v2: simplify check as suggested by Michel.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just a bit of wording polish plus mentioning that it can fail and must
be restarted.
Requested by Sumit.
v2: Fix them typos (Hans).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
562c5b4d89 didn't quite fix the issue of dealing with an error
pointer. We can't free/unref an error pointer so reset it to NULL.
Many thanks to Dan Carpenter for pointing this out again.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: dri-devel@lists.freedesktop.org
Fixes: 562c5b4d89 ("drm: fix blob pointer check")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457698646-22231-1-git-send-email-lionel.g.landwerlin@intel.com
SADs may span multiple CEA audio data blocks in the EDID.
CEA-861-E says:
"The order of the Data Blocks is not constrained. It is also possible
to have more than one of a specific type of data block if necessary to
include all of the descriptors needed to describe the sink’s capabilities."
Each audio data block can carry up to 10 SADs, whereas the ELD SAD limit
is 15 according to HDA 1.0a spec. So we should support at least two data
blocks. And apparently some devices take a more liberal interpretation
and stuff only one SAD per data block even when they would fit into one.
So let's try to extract all the SADs we can fit into the ELD even when
they span multiple data blocks.
While at it, toss in a comment to explain the 13 byte monitor name
string limit which confused me at first.
Cc: Arturo Pérez <artur999555@gmail.com>
Tested-by: Arturo Pérez <artur999555@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197
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>
Link: http://patchwork.freedesktop.org/patch/msgid/1457554066-8739-1-git-send-email-ville.syrjala@linux.intel.com
Check properly that the allocated blob's pointer is valid.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Stone <daniels@collabora.com>
Fixes: 5488dc16fd ("drm: introduce pipe color correction properties")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457611461-9116-1-git-send-email-lionel.g.landwerlin@intel.com
Patch based on a previous series by Shashank Sharma.
This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix and finally another lookup into
a gamma table.
The following properties can be added to a pipe :
- DEGAMMA_LUT : blob containing degamma LUT
- DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
- CTM : transformation matrix applied after the degamma LUT
- GAMMA_LUT : blob containing gamma LUT
- GAMMA_LUT_SIZE : number of elements in GAMMA_LUT
DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
the driver to tell userspace applications what sizes should be the
lookup tables in DEGAMMA_LUT and GAMMA_LUT.
A helper is also provided so legacy gamma correction is redirected
through these new properties.
v2: Register LUT size properties as range
v3: Fix round in drm_color_lut_get_value() helper
More docs on how degamma/gamma properties are used
v4: Update contributors
v5: Rename CTM_MATRIX property to CTM (Doh!)
Add legacy gamma_set atomic helper
Describe CTM/LUT acronyms in the kernel doc
v6: Fix missing blob unref in drm_atomic_helper_crtc_reset
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Kumar, Kiran S <kiran.s.kumar@intel.com>
Signed-off-by: Kausal Malladi <kausalmalladi@gmail.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Rob Bradford <robert.bradford@intel.com>
[danvet: CrOS maintainers are also happy with the userspacde side:
https://codereview.chromium.org/1182063002/ ]
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1456506302-640-4-git-send-email-lionel.g.landwerlin@intel.com
connector_state->crtc can no longer be unset by accident,
so that check can be removed. The other code open-codes
drm_atomic_get_existing_crtc_state, so use that.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve tiny conflict due to gcc warning fix on previous
patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that only encoders can be stolen that are part of the state
steal_encoder no longer needs to inspect all connectors,
just those that are part of the atomic state.
Changes since v1:
- Change return value to void, can no longer fail.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Appease gcc, reported by kbuild.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1456996662-8704-7-git-send-email-maarten.lankhorst@linux.intel.com
The current check doesn't handle the case where we don't steal an
encoder, but keep it on the current connector. If we repurpose
disable_conflicting_encoders to do the checking, we just have
to reject the ones that conflict.
Changes since v1:
- Return early with empty encoder_mask, drm_for_each_connector
requires connection_mutex held.
Changes since v2:
- Add comments for the loops.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Testcase: kms_setmode.invalid-clone-single-crtc-stealing
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1456996662-8704-6-git-send-email-maarten.lankhorst@linux.intel.com
Instead of failing with -EINVAL when conflicting encoders are found,
the legacy set_config will disable other connectors when encoders
conflict.
With the previous commit this becomes a lot easier to implement.
set_config only adds connectors to the state that are modified,
and because of the previous commit that calls add_affected_connectors
only on set->crtc it means any connector not part of the modeset can
be stolen from. We disable the connector in that case, and possibly
the crtc if required.
Atomic modeset itself still doesn't allow encoder stealing, the results
would be too unpredictable.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1456996662-8704-5-git-send-email-maarten.lankhorst@linux.intel.com
There's no need to have a separate function to get the crtc
which is stolen, this can already be found when actually
stealing the encoder.
drm_for_each_connector already checks for connection_mutex, so
use that macro now.
Changes since v1:
- Do not check for NULL crtc in connector_state,
this may happen when a crtc is disabled and its encoder stolen.
- Because of this, use connector->state->crtc instead of conn_state->crtc.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1456996662-8704-4-git-send-email-maarten.lankhorst@linux.intel.com
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the addition of crtc_state->connector_mask other connectors from
different crtc's aren't needed any more to determine if a crtc has
connectors, so only call add_affected_connectors on the target crtc.
This allows a cleanup to first remove all current connectors, then
add all set->connectors to the target crtc.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1456303053-28806-2-git-send-email-maarten.lankhorst@linux.intel.com
As previously discussed, this is my first pull request for the DCU DRM
driver along with the change in MAINTAINERS.
https://lkml.org/lkml/2016/1/7/26
The pull contains some code cleanup changes (e.g. removing all error
handling for the regmap calls) and several fixes.
* 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu:
drm/fsl-dcu: fix register initialization
drm/fsl-dcu: use mode flags for hsync/vsync polarity
drm/fsl-dcu: fix alpha blending
drm/fsl-dcu: mask all interrupts on initialization
drm/fsl-dcu: handle initialization errors properly
drm/fsl-dcu: avoid memory leak on errors
drm/fsl-dcu: remove regmap return value checks
drm/fsl-dcu: specify volatile registers
drm: fsl-dcu: Fix no fb check bug
MAINTAINERS: update for Freescale DCU DRM driver
The layer enumeration start with 0 (0-15 for LS1021a and 0-63 for
Vybrid) whereas the register enumeration start from 1 (1-10 for
LS1021a and 1-9 for Vybrid). The loop started off from 0 for both
iterations and initialized the number of layers inclusive, which
is one layer too many.
All extensively written registers seem to be unassigned, it seems
that the write to those registers did not do any harm in practice.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The current default configuration is as follows:
- Invert VSYNC signal (active LOW)
- Invert HSYNC signal (active LOW)
The mode flags allow to specify the required polarity per
mode. Furthermore, none of the current driver settings is
actually a standard polarity.
This patch applies the current driver default polarities as
explicit flags to the display which has been introduced with
the driver (NEC WQVGA "nec,nl4827hc19-05b"). The driver now
also parses the flags field and applies the configuration
accordingly, by using the following values as standard
polarities: (e.g. when no flags are specified):
- VSYNC signal not inverted (active HIGH)
- HSYNC signal not inverted (active HIGH)
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Fix alpha blending by enabling alpha blending for the whole frame if
a color mode with alpha channel is selected (DRM_FORMAT_ARGB*). Also
support color modes without alpha channel (DRM_FORMAT_XRGB*) by just
not enabling alpha blending on layer level.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The state of the interrupt mask register on initialization is
unknown, e.g. U-Boot could already used the DCU. So depending on
the boot loader, the outcome of the interrupt mask register could
be different. A defined state is much more preferable. Also, there
is no value in keeping interrupts enabled which we don't need.
Therefor, mask all interrupts on initialization.
Signed-off-by: Stefan Agner <stefan@agner.ch>
If initialization fails (e.g. due to missing panel node or deferred
probe) make sure to roll-back all operations and return the error
code.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Improve error handling during CRTC initialization. Especially avoid
memory leaks in the primary plane initialization error path.
Signed-off-by: Stefan Agner <stefan@agner.ch>
It is not common to do regmap return value checks, especially not
for memory mapped device. We can rule out most error returns since
the conditions are static and we know they are ok (e.g. offset
aligned to register stride). Also without proper error handling
they are not really valuable for the user. Hence remove most of
them.
The check in the interrupt handler is worth keeping since a
volatile register won't be readable in case register caching is
still enabled.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Since we are using cached registers, we need to specify volatile
registers explicitly to avoid reading their value from the cache.
This allows to read the correct interrupt status in fsl_dcu_drm_irq
and clear the asserted bits only.
Signed-off-by: Stefan Agner <stefan@agner.ch>
For state->fb or state->crtc may be NULL in fsl_dcu_drm_plane_atomic_check
function, if so, return 0.
Signed-off-by: Meng Yi <meng.yi@nxp.com>
Signed-off-by: Jianwei Wang <jianwei.wang.chn@gmail.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Promote myself as new maintainer of the Freescale DCU DRM driver.
Acked-by: Jianwei Wang <jianwei.wang.chn@gmail.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
rcar-du updates.
* 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev: (281 commits)
drm: rcar-du: Add tri-planar memory formats support
drm: rcar-du: Add probe deferral debug messages
drm: rcar-du: lvds: Add R-Car Gen3 support
drm: rcar-du: lvds: Rename PLLEN bit to PLLON
drm: rcar-du: lvds: Fix PLL frequency-related configuration
drm: rcar-du: lvds: Avoid duplication of clock clamp code
drm: rcar-du: Add R8A7795 device support
drm: rcar-du: Output the DISP signal on the ODDF pin
drm: rcar-du: Output the DISP signal on the DISP pin
drm: rcar-du: Support up to 4 CRTCs
drm: rcar-du: Drop LVDS double dependency on OF
drm: rcar-du: Enable compilation on ARM64
drm: rcar-du: Fix compile warning on 64-bit platforms
drm: rcar-du: Expose the VSP1 compositor through KMS planes
drm: rcar-du: Move plane allocator to rcar_du_plane.c
drm: rcar-du: Restart the DU group when a plane source changes
drm: rcar-du: Add VSP1 compositor support
drm: rcar-du: Add VSP1 support to the planes allocator
drm: rcar-du: Refactor plane setup
drm: rcar-du: Compute plane DDCR4 register value directly
...
Print a message when the HDMI I2C slave encoder can't be found to help
debugging probe deferral issues.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The LVDS encoder differs slightly in Gen3 SoCs in its PLL configuration.
Add support for the Gen3 LVDS PLL parameters and startup procedure.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Laurent Pinchart