Deepak M [Wed, 30 Mar 2016 14:03:39 +0000 (17:03 +0300)]
drm: Add new DCS commands in the enum list
Adding new DCS commands which are specified in the
DCS 1.3 spec related to CABC.
v2: Sorted the Macro`s by value (Andrzej)
v3 by Jani: sort all of enum, refer to MIPI DCS 1.3
Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: <dri-devel@lists.freedesktop.org> Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Deepak M <m.deepak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459346623-30752-1-git-send-email-jani.nikula@intel.com
Daniel Vetter [Wed, 30 Mar 2016 09:26:35 +0000 (11:26 +0200)]
vgacon: dummy implementation for vgacon_text_force
This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
drivers.
v2: Make the dummy function actually return a sane value, spotted by
Ville.
v3: Because the patch is still in limbo there's no more drivers to
convert, noticed by Emil.
v4: Rebase once more, because hooray. I'll just go ahead an apply this
one later on to drm-misc.
Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
But it seems to be completely unused. Only i915 and nouveau even
register these properties, and the corresponding DDX don't even look
at them. Also the sysfs files are read-only, so not useful to
configure anything.
I suspect that this was added with the goal to have read-only access
to all properties in sysfs, but we never followed through on that.
Also, that should be done in a more generic fashion.
Since it would be real work to fix up the locking (with atomic we're
now chasing pointers when reading properties) and it seems unused lets
just nuke this all. It's easier. Of course we'll keep the properties
themselves, those are still exposed through the KMS ioctls.
Daniel Vetter [Wed, 30 Mar 2016 11:24:06 +0000 (13:24 +0200)]
drm/ttm: Remove TTM_HAS_AGP
It tries to do fancy things with excluding agp support if ttm is
built-in, but agp isn't. Instead just express this depency like drm
does and use CONFIG_AGP everywhere.
Also use the neat Makefile magic to make the entire ttm_agp_backend
file optional.
v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville
We don't need to keep empty callbacks for the (pre/post) enable/disable
drm_bridge ops anymore. Remove the nop callback used here for
pre_enable and post_disable ops.
ktime: Kill non-scalar ktime_t implementation for 2038
there is no longer a 32bit version that's unsigned, and we don't have
to jump through ridiculous hoops to make the calculations correct.
I didn't look whether there's more of this pattern in the kernel.
Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459249942-21589-1-git-send-email-daniel.vetter@ffwll.ch
Alexey Brodkin [Wed, 23 Mar 2016 08:42:54 +0000 (11:42 +0300)]
drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()
Current name is a bit misleading because what that helper function
really does it calls drm_connector_unregister() for all connectors.
This all has nothing to do with hotplugging so let's name things
properly.
And while at it remove potentially dangerous locking around
drm_connector_unregister() in rcar_du_remove() as mentioned
in kerneldoc for drm_connector_unregister_all().
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: linux-renesas-soc@vger.kernel.org Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1458722577-20283-2-git-send-email-abrodkin@synopsys.com
Chris Wilson [Fri, 18 Mar 2016 20:02:39 +0000 (20:02 +0000)]
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
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.
Ville Syrjälä [Wed, 9 Mar 2016 20:07:46 +0000 (22:07 +0200)]
drm/edid: Extract SADs properly from multiple audio data blocks
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.
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: 5488dc16fde7 ("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.
drm/atomic: Handle encoder assignment conflicts in a separate check, v3.
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.
drm/atomic: Handle encoder stealing from set_config better.
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.
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.
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.
Liu Ying [Mon, 29 Feb 2016 03:21:10 +0000 (11:21 +0800)]
drm/crtc: Use drm_mode_object_put() in __drm_framebuffer_unregister()
The function __drm_framebuffer_unregister() has boilerplate code to drop idr
reference. Let's replace it with drm_mode_object_put() to simplify the code.
Stefan Agner [Fri, 15 Jan 2016 01:24:29 +0000 (17:24 -0800)]
drm/fsl-dcu: fix register initialization
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.
Stefan Agner [Wed, 18 Nov 2015 03:10:29 +0000 (19:10 -0800)]
drm/fsl-dcu: use mode flags for hsync/vsync polarity
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>
Stefan Agner [Wed, 18 Nov 2015 22:47:35 +0000 (14:47 -0800)]
drm/fsl-dcu: fix alpha blending
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.
Stefan Agner [Thu, 19 Nov 2015 01:27:04 +0000 (17:27 -0800)]
drm/fsl-dcu: mask all interrupts on initialization
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.
Stefan Agner [Thu, 19 Nov 2015 00:50:55 +0000 (16:50 -0800)]
drm/fsl-dcu: remove regmap return value checks
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.
Stefan Agner [Wed, 18 Nov 2015 02:05:25 +0000 (18:05 -0800)]
drm/fsl-dcu: specify volatile registers
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.
Dave Airlie [Thu, 25 Feb 2016 00:30:59 +0000 (10:30 +1000)]
Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-next
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
...
drm: rcar-du: Output the DISP signal on the ODDF pin
The ODDF signal, output by default on the ODDF pin, isn't used on any
board supported in the kernel. As the Gen3 Salvator-X board uses the
ODDF pin as a DISP signal, hardcode that configuration in the driver.
Use of the ODDF signal will be implemented later through proper DT-based
configuration of the DU pins.
drm: rcar-du: Output the DISP signal on the DISP pin
The DE signal is currently configured to be identical to the DISP
signal and is used for the same purpose. To make it clearer that the
DISP pin outputs the DISP signal, select it explicitly.
drm: rcar-du: Expose the VSP1 compositor through KMS planes
On R-Car Gen3 SoCs the DU lost its ability to access memory directly and
needs to work in conjunction with the VSP to do so. This commit handles
the VSP internally to hide it from the user.
Laurent Pinchart [Sat, 24 Aug 2013 00:17:03 +0000 (02:17 +0200)]
drm: rcar-du: Restart the DU group when a plane source changes
Plane sources are configured by the VSPS bit in the PnDDCR4 register.
Although the datasheet states that the bit is updated during vertical
blanking, it seems that updates only occur when the DU group is held in
reset through the DSYSR.DRES bit. Restart the group if the source
changes.
Laurent Pinchart [Fri, 21 Jun 2013 15:36:15 +0000 (17:36 +0200)]
drm: rcar-du: Add VSP1 support to the planes allocator
The R8A7790 DU can source frames directly from the VSP1 devices VSPD0
and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0
or DU0/1 plane 1.
Allocate the correct fixed plane when sourcing frames from VSPD0 or
VSPD1, and allocate planes in reverse index order otherwise to ensure
maximum availability of planes 0 and 1.
Rename plane setup functions using more explicit names, and use local
variables to store intermediate values to increase readability. This
also prepares for VSP compositor support.
drm: rcar-du: Don't update planes on disabled CRTCs
A disabled CRTC can't display planes, the driver shouldn't try to
configure it when updating planes. The DRM core will store the plane
state for us, and the plane will be configured appropriately the next
time the CRTC is enabled.
Laurent Pinchart [Sun, 24 Jan 2016 22:28:11 +0000 (00:28 +0200)]
drm: rcar-du: Remove local CRTC enabled state
The atomic framework guarantees that the CRTC enable and disable
functions will only be called when needed, there's no need to duplicate
the CRTC state check. By replacing the local CRTC enabled state check at
resume time with the CRTC active state we can remove the local CRTC
enabled state altogether.
drm: rcar-du: Perform initialization/cleanup at probe/remove time
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the remove function as
well.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/media/platform/vsp1/vsp1_drm.c:47:5: warning: no previous prototype for 'vsp1_du_init' [-Wmissing-prototypes]
int vsp1_du_init(struct device *dev)
^
drivers/media/platform/vsp1/vsp1_drm.c:76:5: warning: no previous prototype for 'vsp1_du_setup_lif' [-Wmissing-prototypes]
int vsp1_du_setup_lif(struct device *dev, unsigned int width,
^
drivers/media/platform/vsp1/vsp1_drm.c:221:6: warning: no previous prototype for 'vsp1_du_atomic_begin' [-Wmissing-prototypes]
void vsp1_du_atomic_begin(struct device *dev)
^
drivers/media/platform/vsp1/vsp1_drm.c:273:5: warning: no previous prototype for 'vsp1_du_atomic_update' [-Wmissing-prototypes]
int vsp1_du_atomic_update(struct device *dev, unsigned int rpf_index,
^
drivers/media/platform/vsp1/vsp1_drm.c:451:6: warning: no previous prototype for 'vsp1_du_atomic_flush' [-Wmissing-prototypes]
void vsp1_du_atomic_flush(struct device *dev)
^
[media] v4l: vsp1: Configure device based on IP version
The IP version number carries enough information to identify the exact
device instance features. Drop the related DT properties and use the IP
version instead.
Display lists contain lists of registers and associated values to be
applied atomically by the hardware. They lower the pressure on interrupt
processing delays when reprogramming the device as settings can be
prepared well in advance and queued to the hardware without waiting for
the end of the current frame.
Display list support is currently limited to the DRM pipeline.
[media] v4l: vsp1: Implement atomic update for the DRM driver
Add two API functions named vsp1_du_atomic_begin() and
vsp1_du_atomic_flush() to signal the start and end of an atomic update.
The vsp1_du_setup_rpf() function is renamed to vsp1_du_atomic_update()
for consistency.
With this new API, the driver will reprogram all modified inputs
atomically before restarting the video stream.
Implement internal control of the VSP pipeline to be used by the DU
DRM/KMS driver when using the VSP as an internal composer handled
through DRM/KMS only.
[media] v4l: vsp1: Don't validate links when the userspace API is disabled
As the pipeline is configured internally by the driver when the
userspace API is disabled its configuration can be trusted and link
validation isn't needed.
[media] v4l: vsp1: Set the alpha value manually in RPF and WPF s_stream handlers
The RPF and WPF alpha values are set through V4L2 controls and applied
when starting the video stream by a call to v4l2_ctrl_handler_setup().
As that function uses the control handler mutex it can't be called in
interrupt context, where the VSP+DU pipeline handler might need to
reconfigure the pipeline.
Set the alpha value manually in the RPF and WPF s_stream handler to
ensure that the hardware is properly configured even when controlled
without the userspace API. If the userspace API is enabled protect that
with the control lock to avoid race conditions with userspace.
[media] v4l: vsp1: Make pipeline inputs array index by RPF index
The pipeline inputs array stores pointers to all RPFs contained in the
pipeline. It's currently indexed contiguously by adding RPFs in the
order they are found during graph walk. This can't easily support
dynamic addition and removal of RPFs while streaming, which will be
required for combined VSP+DU support.
Make the array indexed by RPF index instead and skip NULL elements when
iterating over RPFs.
[media] v4l: vsp1: Make the userspace API optional
The R-Car Gen3 SoCs include VSP instances dedicated to the DU that will
be controlled entirely by the rcar-du-drm driver through the KMS API. To
support that use case make the userspace V4L2 API optional.
Laurent Pinchart [Fri, 14 Aug 2015 16:53:45 +0000 (13:53 -0300)]
[media] v4l: vsp1: Make the BRU optional
Not all VSP instances have a BRU on R-Car Gen3, make it optional. Set
the feature unconditionally for now, this will be fixed when adding Gen3
support.
[media] v4l: vsp1: Make number of BRU inputs configurable
The R-Car Gen3 family has 5-inputs BRUs, support them by making the
number of BRU inputs configurable.
As the driver assumes that the number of BRU inputs is equal to the
number of RPFs, replace the BRU_MAX_INPUTS macro with VSP1_MAX_RPF to
make the assumption apparent.
projects / linux-beck.git / log