28 Feb, 2018
13 commits
-
This patch adds helper functions for YCBCR 420 handling.
These functions do:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 also mode.V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.
V4: EXPORT_SYMBOL(drm_find_hdmi_output_type)
V5: Addressed review comments from Danvet:
- %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type
- %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output
- %s/drm_can_support_this_ycbcr_output/
drm_display_supports_this_ycbcr_output
- pass drm_display_info instead of drm_connector for consistency
- For drm_get_highest_quality_ycbcr_supported doc, move the variable
description above, and then the function description.
V6: Add only YCBCR420 helpers (Ville)
V7: Addressed review comments from Ville
- Remove cea_vic_valid() check.
- Fix indentation.
- Make input parameters to helpers, const.Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Daniel Vetter
Signed-off-by: Shashank Sharma
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-9-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix sparse indentation warn]
Signed-off-by: Ville Syrjälä -
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc_modes into this patch, where its used
(Ville)
V5: Optimize function, if(conditions) not reqd (Ville)
V6: Rebase
V7: RebaseCc: Ville Syrjälä
Cc: Jose Abreu
Signed-off-by: Shashank Sharma
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-8-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix sparse indentation warn]
Signed-off-by: Ville Syrjälä -
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Emil VelikovV2: Addressed
Review comments from Emil:
- Use 1ULL<< 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
add a separate helper function to prune ycbcr420-only modes from
connector's probed modes.V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)
V8: Addressed review comments from Ville
- use cea_vic_valid check before adding cmdb/vdb modes
- add check for i < 64 while adding cmdb modes
- use 1ULL while checking bitmapSigned-off-by: Shashank Sharma
Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix checkpatch complaints and indentation]
Signed-off-by: Ville Syrjälä -
YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
connector. This function will help pruning the YCBCR420-only
modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connector structure.
While handling the EDID from HDMI 2.0 sinks, its important to know
if the source is capable of handling YCBCR420 output, so that no
YCBCR 420 modes will be listed for sources which can't handle it.
A driver should set this variable if it wants to see YCBCR420 modes
in the modedb.V5: Introduced the patch in series.
V6: Squashed two patches (validate YCBCR420 and add YCBCR420
identifier)
V7: Addressed review comments from Vile:
- Move this patch before we add 420 modes from EDID.
- No need for drm_valid_cea_vic() check, function back to non-static.
- Update MODE_STATUS with NO_420 condition.
- Introduce y420_vdb_modes variable in this patchCc: Ville Syrjala
Signed-off-by: Shashank Sharma
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com
[vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)]
Signed-off-by: Ville Syrjälä -
Signed-off-by: Laurentiu Palcu
-
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.Signed-off-by: Uma Shankar
-
EA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.Signed-off-by: Uma Shankar
-
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
- If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Addressed review comments from Ville
- Add clock rate calculations for 1/10 and 1/40 ratios
- Remove leftovers from old patchset
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.Signed-off-by: Shashank Sharma
Reviewed-by: Thierry Reding
Reviewed-by: Jose Abreu
Signed-off-by: Jani Nikula
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com -
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
- If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Rebase.
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.Signed-off-by: Shashank Sharma
Reviewed-by: Thierry Reding
Reviewed-by: Jose Abreu
Signed-off-by: Jani Nikula
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com -
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Addressed review comments from Ville
- Handle the I2c return values in a better way (dp_dual_mode)
- Make the macros for SCDC Major/Minor more readable, by adding
a 'GET' in the macro names
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: RebaseSigned-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
Signed-off-by: Jani Nikula
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-2-git-send-email-shashank.sharma@intel.com -
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requirements of the mode. Black screen follows.One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would
also conflict with the idea of making setcrtc asynchronous in the
future, returning before the actual mode setting and link training.Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on
practical not theoretical capabilities. However, the changes for link
training are pretty drastic, all for the sake of error handling and
DP compliance, when the most common happy day scenario is the current
approach of link training at mode setting time, using the optimal
parameters for the mode. It is also not certain all hardware could do
this without the pipe on; not even all our hardware can do this. Some
of this can be solved, but not trivially.Both of the above ideas also fail to address link degradation *during*
operation.The solution is to add a new "link-status" connector property in order
to address link training failure in a way that:
a) changes the current happy day scenario as little as possible, to
avoid regressions, b) can be implemented the same way by all drm
drivers, c) is still opt-in for the drivers and userspace, and opting
out doesn't regress the user experience, d) doesn't prevent drivers
from implementing better or alternate approaches, possibly without
userspace involvement. And, of course, handles all the issues presented.
In the usual happy day scenario, this is always "good". If something
fails during or after a mode set, the kernel driver can set the link
status to "bad" and issue a hotplug uevent for userspace to have it
re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
again. If the theoretical capabilities of the link can't be reached,
the mode list is trimmed based on that.v7 by Jani:
* Rebase, simplify set property while at it, checkpatch fix
v6:
* Fix a typo in kernel doc (Sean Paul)
v5:
* Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter)
v4:
* Add comments in kernel-doc format (Daniel Vetter)
* Update the kernel-doc for link-status (Sean Paul)
v3:
* Fixed a build error (Jani Saarinen)
v2:
* Removed connector->link_status (Daniel Vetter)
* Set connector->state->link_status in drm_mode_connector_set_link_status_property
(Daniel Vetter)
* Set the connector_changed flag to true if connector->state->link_status changed.
* Reset link_status to GOOD in update_output_state (Daniel Vetter)
* Never allow userspace to set link status from Good To Bad (Daniel Vetter)Reviewed-by: Sean Paul
Reviewed-by: Daniel Vetter
Reviewed-by: Jani Nikula
Acked-by: Tony Cheng
Acked-by: Harry Wentland
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Chris Wilson
Cc: Sean Paul
Signed-off-by: Manasi Navare
Signed-off-by: Jani Nikula
Acked-by: Eric Anholt (for the -modesetting patch)
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com -
Hardware may have HDR capability on certain plane
engines. Enabling the same in drm plane structure
so that this can be communicated to user space.Each drm driver should set this flag to true for planes
which support HDR.Signed-off-by: Uma Shankar
-
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.Signed-off-by: Uma Shankar
21 Dec, 2017
2 commits
-
Updated blob layout (Rob, Daniel, Kristian, xerpi)
v2:
* Removed __packed, and alignment (.+)
* Fix indent in drm_format_modifier fields (Liviu)
* Remove duplicated modifier > 64 check (Liviu)
* Change comment about modifier (Liviu)
* Remove arguments to blob creation, use plane instead (Liviu)
* Fix data types (Ben)
* Make the blob part of uapi (Daniel)v3:
Remove unused ret field.
Change i, and j to unsigned int (Emil)v4:
Use plane->modifier_count instead of recounting (Daniel)v5:
Rename modifiers to modifiers_property (Ville)
Use sizeof(__u32) instead to reflect UAPI nature (Ville)
Make BUILD_BUG_ON for blob header sizeCc: Rob Clark
Cc: Kristian H. Kristensen
Signed-off-by: Ben Widawsky
Reviewed-by: Daniel Stone (v2)
Reviewed-by: Liviu Dudau (v2)
Reviewed-by: Emil Velikov (v3)
Signed-off-by: Daniel Stone
Link: http://patchwork.freedesktop.org/patch/msgid/20170724034641.13369-2-ben@bwidawsk.net
(cherry picked from commit db1689aa61bd1efb5ce9b896e7aa860a85b7f1b6)Conflicts:
drivers/gpu/drm/drm_crtc.c
drivers/gpu/drm/drm_mode_config.c
include/drm/drm_crtc.h
include/drm/drm_mode_config.h -
This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.This patch simply allows the DRM drivers to initialize their list of
supported modifiers upon initializing the plane.v2: A minor addition from Daniel
v3:
* Updated commit message
* s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
* Remove some excess newlines (Liviu)
* Update comment for > 64 modifiers (Liviu)v4: Minor comment adjustments (Liviu)
v5: Some new platforms added due to rebase
v6: Add some missed plane inits (or maybe they're new - who knows at
this point) (Daniel)Signed-off-by: Ben Widawsky
Reviewed-by: Daniel Stone (v2)
Reviewed-by: Liviu Dudau
Signed-off-by: Daniel Stone
(cherry picked from commit e6fc3b68558e4c6d8d160b5daf2511b99afa8814)Conflicts:
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
drivers/gpu/drm/imx/dcss/dcss-plane.c
drivers/gpu/drm/imx/dpu/dpu-plane.c
drivers/gpu/drm/imx/ipuv3-plane.c
drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c
drivers/gpu/drm/meson/meson_plane.c
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
drivers/gpu/drm/mxsfb/mxsfb_drv.c
drivers/gpu/drm/nouveau/nv50_display.c
drivers/gpu/drm/omapdrm/omap_plane.c
drivers/gpu/drm/pl111/pl111_display.c
drivers/gpu/drm/qxl/qxl_display.c
drivers/gpu/drm/stm/ltdc.c
drivers/gpu/drm/sun4i/sun8i_layer.c
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
drivers/gpu/drm/zte/zx_plane.c
include/drm/drm_plane.h
19 Dec, 2017
1 commit
-
drm_universal_plane_init() and drm_plane_init() take "unsigned long
possible_crtcs" parameter, but then stuff it into uint32_t. Change the
parameter to uint32_t.Signed-off-by: Tomi Valkeinen
Cc: Ville Syrjälä
Reviewed-by: Laurent Pinchart
Reviewed-by: Ville Syrjälä
(cherry picked from commit 5cd57a46e3e3dc088b50bbfcdc85d9e0d9c22159)
11 Dec, 2017
7 commits
-
Currently, the Northwest Logic MIPI-DSI controller host specific code
resides under drm/bridge, but is not a real drm_bridge. It creates a
drm_bridge and adds itself to the drm_encoder that handles this file,
but this is wrong, since it does not implement the drm_bridge_funcs.The correct way to implement a drm_bridge is to add the drm_bridge and
let other components (another bridge or a drm_encoder) to attach to this
bridge.
Since we are doing this, a new compatible strings can be used for this
driver: "nwl,mipi-dsi".Since this was used by nwl_dsi-imx.c, update that driver to use this
bridge correctly.This is needed in order to add support for MIPI-DSI on 8MQ. The IMX_NWL
driver will either add a DSI encoder to DRM, or a DSI bridge.
The encoder will be used by imx-drm-core driver, while the bridge
will be used by MXSFB driver (which creates a simple display pipe).Signed-off-by: Robert Chiras
-
drm_mode_create_lease
Creates a lease for a list of drm mode objects, returning an
fd for the new drm_master and a 64-bit identifier for the lesseedrm_mode_list_lesees
List the identifiers of the lessees for a master file
drm_mode_get_lease
List the leased objects for a master file
drm_mode_revoke_lease
Erase the set of objects managed by a lease.
This should suffice to at least create and query leases.
Changes for v2 as suggested by Daniel Vetter :
* query ioctls only query the master associated with
the provided file.* 'mask_lease' value has been removed
* change ioctl has been removed.
Changes for v3 suggested in part by Dave Airlie
* Add revoke ioctl.
Changes for v4 suggested by Dave Airlie
* Expand on the comment about the magic use of &drm_lease_idr_object
* Pad lease ioctl structures to align on 64-bit boundariesChanges for v5 suggested by Dave Airlie
* Check for non-negative object_id in create_lease to avoid debug
output from the kernel.Changes for v6 provided by Dave Airlie
* For non-universal planes add primary/cursor planes to leaseIf we aren't exposing universal planes to this userspace client,
and it requests a lease on a crtc, we should implicitly export the
primary and cursor planes for the crtc.If the lessee doesn't request universal planes, it will just see
the crtc, but if it does request them it will then see the plane
objects as well.This also moves the object look ups earlier as a side effect, so
we'd exit the ioctl quicker for non-existant objects.* Restrict leases to crtc/connector/planes.
This only allows leasing for objects we wish to allow.
Changes for v7 provided by Dave Airlie
* Check pad args are 0
* Check create flags and object count are valid.
* Check return from fd allocation
* Refactor lease idr setup and add some simple validation
* Use idr_mutex uniformly (Keith)Signed-off-by: Keith Packard
Signed-off-by: Dave Airlie
Signed-off-by: Marius Vlad -
Attempts to modify un-leased objects are rejected with an error.
Information returned about unleased objects is modified to make them
appear unusable and/or disconnected.Changes for v2 as suggested by Daniel Vetter :
* With the change in the __drm_mode_object_find API to pass the
file_priv along, we can now centralize most of the lease-based
access checks in that function.* A few places skip that API and require in-line checks.
Changes for v3 provided by Dave Airlie
* remove support for leasing encoders.
* add support for leasing planes.Changes for v4
* Only call drm_lease_held if DRIVER_MODESET.
Signed-off-by: Keith Packard
Signed-off-by: Dave Airlie
Signed-off-by: Marius Vlad -
This provides new data structures to hold "lease" information about drm mode
setting objects, and provides for creating new drm_masters which have access to
a subset of the available drm resources.An 'owner' is a drm_master which is not leasing the objects from another
drm_master, and hence 'owns' them.A 'lessee' is a drm_master which is leasing objects from some other drm_master.
Each lessee holds the set of objects which it is leasing from the lessor.A 'lessor' is a drm_master which is leasing objects to another drm_master. This
is the same as the owner in the current code.The set of objects any drm_master 'controls' is limited to the set of objects it
leases (for lessees) or all objects (for owners).Objects not controlled by a drm_master cannot be modified through the various
state manipulating ioctls, and any state reported back to user space will be
edited to make them appear idle and/or unusable. For instance, connectors always
report 'disconnected', while encoders report no possible crtcs or clones.The full list of lessees leasing objects from an owner (either directly, or
indirectly through another lessee), can be searched from an idr
in the drm_master of the owner.Changes for v2 as suggested by Daniel Vetter :
* Sub-leasing has been disabled.
* BUG_ON for lock checking replaced with lockdep_assert_held
* 'change' ioctl has been removed.
* Leased objects can always be controlled by the lessor; the
'mask_lease' flag has been removed* Checking for leased status has been simplified, replacing
the drm_lease_check function with drm_lease_held.Changes in v3, some suggested by Dave Airlie
* Add revocation. This allows leases to be effectively revoked by
removing all of the objects they have access to. The lease itself
hangs around as it's hanging off a file.* Free the leases IDR when the master is destroyed
* _drm_lease_held should look at lessees, not lessor
* Allow non-master files to check for lease status
Changes in v4, suggested by Dave Airlie
* Formatting and whitespace changes
Changes in v5 (airlied)
* check DRIVER_MODESET before lease destroy call
* check DRIVER_MODESET for lease revoke (Chris)
* Use idr_mutex uniformly for all lease elements of struct drm_master. (Keith)Signed-off-by: Keith Packard
Signed-off-by: Marius Vlad -
This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.v2: Also fix up vboxvideo driver in staging
[airlied: merging early as this is an API change]
Suggested-by: Daniel Vetter
Signed-off-by: Keith Packard
Signed-off-by: Dave Airlie
Signed-off-by: Marius Vlad -
Separate out lease debugging from the core.
Signed-off-by: Keith Packard
Signed-off-by: Dave Airlie
Signed-off-by: Marius Vlad -
Add support for the NorthWest Logit MIPI-DSI controller found in mx8
platforms: i.MX8qm, i.MX8qxp and i.MX8mq.
The NWL MIPI-DSI driver is implemented as a DRM bridge.
The MIPI-DSI encoder will contain the platform specific changes and will
use this bridge.Signed-off-by: Robert Chiras
05 Oct, 2017
1 commit
-
A component master may have both OF based and non-OF based components to be
bound with. This patch adds a helper drm_of_component_probe_with_match()
similar to drm_of_component_probe() so that the new helper may get an
additional provided match pointer(contains match entries for non-OF based
components) to support this case.Tested-by: Meng Mingming
Signed-off-by: Liu Ying
17 Jun, 2017
2 commits
-
[ Upstream commit e6e7b48b295afa5a5ab440de0a94d9ad8b3ce2d0 ]
I was under the misconception that the sysfs dev stuff can be fully
set up, and then registered all in one step with device_add. That's
true for properties and property groups, but not for parents and child
devices. Those must be fully registered before you can register a
child.Add a bit of tracking to make sure that asynchronous mst connector
hotplugging gets this right. For consistency we rely upon the implicit
barriers of the connector->mutex, which is taken anyway, to ensure
that at least either the connector or device registration call will
work out.Mildly tested since I can't reliably reproduce this on my mst box
here.Reported-by: Dave Hansen
Cc: Dave Hansen
Acked-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1484237756-2720-1-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e ]
If we're unlucky then the registration from a hotplugged connector
might race with the final registration step on driver load. And since
MST topology discover is asynchronous that's even somewhat likely.v2: Also update the kerneldoc for @registered!
v3: Review from Chris:
- Improve kerneldoc for late_register/early_unregister callbacks.
- Use mutex_destroy.Reviewed-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Sean Paul
Reported-by: Chris Wilson
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161218133545.2106-1-daniel.vetter@ffwll.ch
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
12 Apr, 2017
3 commits
-
[ Upstream commit 0784bc624ae9be4269f8129572ee164ca680ca7c ]
Commit 8d9c20e1d1e3 ("drm/i915: Remove .is_mobile field from platform
struct") removed mobile vs desktop differences for HSW+, but forgot
the Broadwell reserved IDs, so do it now.It's interesting to notice that these IDs are used by early-quirks.c
but are *not* used by i915_pci.c.Cc: Carlos Santa
Cc: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
Reviewed-by: Rodrigo Vivi
Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-2-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 7fbd995ce4241e98d30859405504c3fb279c4ccb ]
Remove duplicated IDs from the list. Currently, this definition is
only used by early-quirks.c. From my understanding of the code, having
duplicated IDs shouldn't be causing any bugs.Fixes: 8d9c20e1d1e3 ("drm/i915: Remove .is_mobile field from platform struct")
Cc: Carlos Santa
Cc: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
Reviewed-by: Rodrigo Vivi
Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-1-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
commit fe25deb7737ce6c0879ccf79c99fa1221d428bf2 upstream.
Previously, when a surface was opened using a legacy (non prime) handle,
it was verified to have been created by a client in the same master realm.
Relax this so that opening is also allowed recursively if the client
already has the surface open.This works around a regression in svga mesa where opening of a shared
surface is used recursively to obtain surface information.Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
Signed-off-by: Greg Kroah-Hartman
30 Mar, 2017
1 commit
-
commit 24835e442f289813aa568d142a755672a740503c upstream.
When writing the generic nonblocking commit code I assumed that
through clever lifetime management I can assure that the completion
(stored in drm_crtc_commit) only gets freed after it is completed. And
that worked.I also wanted to make nonblocking helpers resilient against driver
bugs, by having timeouts everywhere. And that worked too.Unfortunately taking boths things together results in oopses :( Well,
at least sometimes: What seems to happen is that the drm event hangs
around forever stuck in limbo land. The nonblocking helpers eventually
time out, move on and release it. Now the bug I tested all this
against is drivers that just entirely fail to deliver the vblank
events like they should, and in those cases the event is simply
leaked. But what seems to happen, at least sometimes, on i915 is that
the event is set up correctly, but somohow the vblank fails to fire in
time. Which means the event isn't leaked, it's still there waiting for
eventually a vblank to fire. That tends to happen when re-enabling the
pipe, and then the trap springs and the kernel oopses.The correct fix here is simply to refcount the crtc commit to make
sure that the event sticks around even for drivers which only
sometimes fail to deliver vblanks for some arbitrary reasons. Since
crtc commits are already refcounted that's easy to do.References: https://bugs.freedesktop.org/show_bug.cgi?id=96781
Cc: Jim Rees
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Jani Nikula
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161221102331.31033-1-daniel.vetter@ffwll.ch
Cc: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman
27 Oct, 2016
1 commit
-
We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i915 actually falls into this
category right now since we've not yet added zpos support).Allow drivers more freedom by letting them deal with zpos
themselves instead of doing it in drm_atomic_helper_check_planes()
unconditionally. Let's just inline the required calls into all
the driver that currently depend on this.v2: Inline the stuff into the drivers instead of adding another
helper, document things better (Daniel)Cc: Daniel Vetter
Cc: Marek Szyprowski
Cc: Benjamin Gaignard
Cc: Vincent Abriou
Cc: Laurent Pinchart
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Lyude
Cc: Maarten Lankhorst
Cc: stable@vger.kernel.org
Fixes: 44d1240d006c ("drm: add generic zpos property")
Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
Acked-by: Benjamin Gaignard
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1476111056-12734-1-git-send-email-ville.syrjala@linux.intel.com
10 Oct, 2016
3 commits
-
Signed-off-by: Jani Nikula
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1476113170-13816-1-git-send-email-jani.nikula@intel.com -
There is no late_unregister(), it looks like the comment meant
late_register(). Also fix a typo while at it.Signed-off-by: Grazvydas Ignotas
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1476032820-3275-1-git-send-email-notasas@gmail.com -
Fix invalid sphinx markup in the comment for the newly added
DRM_FB_HELPER_DEFAULT_OPS.Signed-off-by: Stefan Christ
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1475692454-11543-1-git-send-email-contact@stefanchrist.eu
05 Oct, 2016
3 commits
-
dma_buf may live a long time, longer than the last direct user of the
driver. We already hold a reference to the owner module (that prevents
the object code from disappearing), but there is no reference to the
drm_dev - so the pointers to the driver backend themselves may vanish.v2: Resist temptation to fix the bug in armada_gem.c not setting the
correct flags on the exported dma-buf (it should pass the flags through
and not be arbitrarily setting O_RDWR).Use a common wrapper for exporting the dmabuf and acquiring the
reference to the drm_device.Testcase: igt/vgem_basic/unload
Suggested-by: Daniel Vetter
Signed-off-by: Chris Wilson
Cc: Petri Latvala
Cc: Daniel Vetter
Cc: stable@vger.kernel.org
Tested-by: Petri Latvala
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-2-chris@chris-wilson.co.uk -
dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right
owner from the device->fops instead.v2: Use C99 initializers to zero out unset elements of
dma_buf_export_info
v3: Extract the right module from dev->fops.Testcase: igt/vgem_basic/unload
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Petri Latvala
Cc: Christian König
Cc: stable@vger.kernel.org
Tested-by: Petri Latvala
Reviewed-by: Petri Latvala
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-1-chris@chris-wilson.co.uk -
Add .prepare_fb and .cleanup_fb plane hooks into the drm_simple_kms.
These can be used by drivers to call ie. the drm_fb_cma_setup_fence()
helper.Signed-off-by: Marek Vasut
Cc: Noralf Trønnes
Cc: Daniel Vetter
Cc: David Airlie
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161002170124.6099-1-marex@denx.de
04 Oct, 2016
3 commits
-
So users know whether PSR should be enabled or not.
Cc: Yakir Yang
Reviewed-by: Sean Paul
Signed-off-by: Tomeu Vizoso
Signed-off-by: Archit Taneja
Link: http://patchwork.freedesktop.org/patch/msgid/1474639600-30090-1-git-send-email-tomeu.vizoso@collabora.com -
The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
implementations for functions in struct fb_ops. A drm driver can use it
like:static struct fb_ops drm_fbdev_cma_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
/* driver specific implementations */
};Suggested-by: Daniel Vetter
Signed-off-by: Stefan Christ
Reviewed-by: Gustavo Padovan
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1475182136-15191-2-git-send-email-contact@stefanchrist.eu -
It's not that obvious how a driver can all race the atomic commit with
handling the completion event. And there's unfortunately a pile of
drivers with rather bad event handling which misdirect people into the
wrong direction.Try to remedy this by documenting everything better.
v2: Type fixes Alex spotted.
v3: More typos Alex spotted.
Cc: Andrzej Hajda
Cc: Alex Deucher
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1475229896-6047-1-git-send-email-daniel.vetter@ffwll.ch
