- 27 7月, 2015 1 次提交
-
-
由 Maarten Lankhorst 提交于
This can be a separate case from mode_changed, when connectors stay the same but only the mode is different. Drivers may choose to implement specific optimizations to prevent a full modeset for this case. Changes since v1: - Update kerneldocs slightly. Cc: dri-devel@lists.freedesktop.org Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 7月, 2015 6 次提交
-
-
由 Daniel Vetter 提交于
Two nice things here: - drm_dev_register will truly register everything in the right order if the driver doesn't have a ->load callback. Before this we had to init the primary mode_group after the device nodes where already registered. - Less things to keep track of when reworking the connector locking, yay! Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
Now that dp mst hotplug takes all locks we can amend the locking rules for the iterators. This is needed before we can roll these out in the atomic code to avoid getting burried in WARNINGs. v2: Rebase onto the extracted list locking assert and add a comment to explain the rules. v3: Fixup German->English translation fail in the comment. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
Ever since framebuffers are reference counted we have a special lock for the global fb list. Make sure users of that list do hold that lock when using the new iterators. Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
Because of DP MST connectors can now be hotplugged and we must hold the right lock when walking the connector lists. Enforce this by checking the locking in our shiny new list walking macros. v2: Extract the locking check into a small static inline helper to help readability. This will be more important when we make the read list access rules more complicated in later patches. Inspired by comments from Chris. Unfortunately, due to header loops around the definition of struct drm_device the function interface is a bit funny. v3: Encoders aren't hotadded/removed. For each dp mst encoder we statically create one fake encoder per pipe so that we can support as many mst sinks as the hw can (Dave). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
And roll them out across drm_* files. The point here isn't code prettification (it helps with that too) but that some of these lists aren't static any more. And having macros will gives us a convenient place to put locking checks into. I didn't add an iterator for props since that's only used by a list_for_each_entry_safe in the driver teardown code. Search&replace was done with the below cocci spatch. Note that there's a bunch more places that didn't match and which would need some manual changes, but I've intentially left these out for this mostly automated patch. iterator name drm_for_each_crtc; struct drm_crtc *crtc; struct drm_device *dev; expression head; @@ - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { + drm_for_each_crtc (crtc, dev) { ... } @@ iterator name drm_for_each_encoder; struct drm_encoder *encoder; struct drm_device *dev; expression head; @@ - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) { + drm_for_each_encoder (encoder, dev) { ... } @@ iterator name drm_for_each_fb; struct drm_framebuffer *fb; struct drm_device *dev; expression head; @@ - list_for_each_entry(fb, &dev->mode_config.fb_list, head) { + drm_for_each_fb (fb, dev) { ... } @@ iterator name drm_for_each_connector; struct drm_connector *connector; struct drm_device *dev; expression head; @@ - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { + drm_for_each_connector (connector, dev) { ... } Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
No need to pass the planelist when everyone just uses dev->mode_config.plane_list anyway. I want to add a pile more of iterators with unified (obj, dev) arguments. This is just prep. Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 25 6月, 2015 1 次提交
-
-
由 Dave Airlie 提交于
I've only seen this once, and I failed to capture the lockdep backtrace, but I did some investigations. If we are calling into the MST layer from EDID probing, we have the mode_config mutex held, if during that EDID probing, the MST hub goes away, then we can get a deadlock where the connector destruction function in the driver tries to retake the mode config mutex. This offloads connector destruction to a workqueue, and avoid the subsequenct lock ordering issue. Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 26 5月, 2015 2 次提交
-
-
由 Daniel Stone 提交于
Atomic modesetting: now with modesetting support. v2: Moved drm_atomic_set_mode_prop_for_crtc from previous patch; removed state->active fiddling, documented return code. Changed property type to DRM_MODE_PROP_BLOB. Signed-off-by: NDaniel Stone <daniels@collabora.com> Tested-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Stone 提交于
Add a blob property tracking the current mode to the CRTC state, and ensure it is properly updated and referenced. v2: Continue using crtc_state->mode inside getcrtc, instead of reading out the mode blob. Use IS_ERR and PTR_ERR from create_blob. Move set_mode_prop_for_crtc to later patch where it actually gets used. Enforce !!state->enable == !!state->mode_blob inside drm_atomic_crtc_check. Signed-off-by: NDaniel Stone <daniels@collabora.com> Tested-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 5月, 2015 1 次提交
-
-
由 Daniel Stone 提交于
Add an ioctl which allows users to create blob properties from supplied data. Currently this only supports modes, creating a drm_display_mode from the userspace drm_mode_modeinfo. v2: Removed size/type checks. Rebased on new patches to allow error propagation from create_blob, as well as avoiding double-allocation. Signed-off-by: NDaniel Stone <daniels@collabora.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@intel.com> Tested-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 5月, 2015 1 次提交
-
-
由 Archit Taneja 提交于
Allow drm_bridge objects to link to each other in order to form an encoder chain. The requirement for creating a chain of bridges comes because the MSM drm driver uses up its encoder and bridge objects for blocks within the SoC itself. There isn't anything left to use if the SoC display output is connected to an external encoder IC. Having an additional bridge connected to the existing bridge helps here. In general, it is possible for platforms to have multiple devices between the encoder and the connector/panel that require some sort of configuration. We create drm bridge helper functions corresponding to each op in 'drm_bridge_funcs'. These helpers call the corresponding 'drm_bridge_funcs' op for the entire chain of bridges. These helpers are used internally by drm_atomic_helper.c and drm_crtc_helper.c. The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of the bridge closet to the encoder, and proceed until the last bridge in the chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup helpers. The drm_bridge_disable/post_disable helpers disable the last bridge in the chain first, and proceed until the first bridge in the chain is disabled. drm_bridge_attach() remains the same. As before, the driver calling this function should make sure it has set the links correctly. The order in which the bridges are connected to each other determines the order in which the calls are made. One requirement is that every bridge in the chain should point the parent encoder object. This is required since bridge drivers expect a valid encoder pointer in drm_bridge. For example, consider a chain where an encoder's output is connected to bridge1, and bridge1's output is connected to bridge2: /* Like before, attach bridge to an encoder */ bridge1->encoder = encoder; ret = drm_bridge_attach(dev, bridge1); .. /* * set the first bridge's 'next' bridge to bridge2, set its encoder * as bridge1's encoder */ bridge1->next = bridge2 bridge2->encoder = bridge1->encoder; ret = drm_bridge_attach(dev, bridge2); ... ... This method of bridge chaining isn't intrusive and existing drivers that use drm_bridge will behave the same way as before. The bridge helpers also cleans up the atomic and crtc helper files a bit. Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NDaniel Vetter <daniel@ffwll.ch> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 5月, 2015 1 次提交
-
-
由 Maarten Lankhorst 提交于
Drivers may need to store the state of shared resources, such as PLLs or FIFO space, into the atomic state. Allow this by making it possible to subclass drm_atomic_state. Changes since v1: - Change member names for functions to atomic_state_(alloc,clear) - Change __drm_atomic_state_new to drm_atomic_state_init - Allow free function to be overridden too, in case extra memory is allocated in alloc. Changes since v2: - Rename *_default_free to default_release, to make clear it doesn't free the state object itself. Cc: dri-devel@lists.freedesktop.org Acked-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 5月, 2015 1 次提交
-
-
由 Daniel Stone 提交于
Reference-count drm_property_blob objects, changing the API to ref/unref. Signed-off-by: NDaniel Stone <daniels@collabora.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Squash in kerneldoc fixup from Daniel Stone.] [danvet: Squash in Oops fix from Thiery Reding.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 5月, 2015 3 次提交
-
-
由 Daniel Vetter 提交于
Also treat it as a proper boolean. Cc: Todd Previte <tprevite@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Stone 提交于
Create a new global blob_lock mutex, which protects the blob property list from insertion and/or deletion. Signed-off-by: NDaniel Stone <daniels@collabora.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Todd Previte 提交于
Displayport compliance test 4.2.2.6 requires that a source device be capable of detecting a corrupt EDID. The test specification states that the sink device sets up the EDID with an invalid checksum. To do this, the sink sets up an invalid EDID header, expecting the source device to generate the checksum and compare it to the value stored in the last byte of the block data. Unfortunately, the DRM EDID reading and parsing functions are actually too good in this case; the header is fixed before the checksum is computed and thus the test never sees the invalid checksum. This results in a failure to pass the compliance test. To correct this issue, when the EDID code detects that the header is invalid, a flag is set to indicate that the EDID is corrupted. In this case, it sets edid_corrupt flag and continues with its fix-up code. This flag is also set in the case of a more seriously damaged header (fixup score less than the threshold). For consistency, the edid_corrupt flag is also set when the checksum is invalid as well. V2: - Removed the static bool global - Added a bool to the drm_connector struct to reaplce the static one for holding the status of raw edid header corruption detection - Modified the function signature of the is_valid function to take an additional parameter to store the corruption detected value - Fixed the other callers of the above is_valid function V3: - Updated the commit message to be more clear about what and why this patch does what it does. - Added comment in code to clarify the operations there - Removed compliance variable and check_link_status update; those have been moved to a later patch - Removed variable assignment from the bottom of the test handler V4: - Removed i915 tag from subject line as the patch is not i915-specific V5: - Moved code causing a compilation error to this patch where the variable is actually declared - Maintained blank lines / spacing so as to not contaminate the patch V6: - Removed extra debug messages - Added documentation to for the added parameter on drm_edid_block_valid - Fixed more whitespace issues in check_link_status - Added a clear of the header_corrupt flag to the end of the test handler in intel_dp.c - Changed the usage of the new function prototype in several places to use NULL where it is not needed by compliance testing V7: - Updated to account for long_pulse flag propagation V8: - Removed clearing of header_corrupt flag from the test handler in intel_dp.c - Added clearing of header_corrupt flag in the drm_edid_block_valid function V9: - Renamed header_corrupt flag to edid_corrupt to more accurately reflect its value and purpose - Updated commit message V10: - Updated for versioning and patch swizzle - Revised the title to more accurately reflect the nature and contents of the patch - Fixed formatting/whitespace problems - Added set flag when computed checksum is invalid Signed-off-by: NTodd Previte <tprevite@gmail.com> Cc: dri-devel@lists.freedesktop.org Acked-by: NDave Airlie <airlied@redhat.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 4月, 2015 1 次提交
-
-
由 John Hunter 提交于
Signed-off-by: NJohn Hunter <zhjwpku@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 13 4月, 2015 1 次提交
-
-
由 Jani Nikula 提交于
They're only used to store const pointers anyway. This helps to keep Ville and the compiler happy. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 4月, 2015 1 次提交
-
-
由 Chandra Konduru 提交于
Adding drm helper function to return plane pointer from index where index is a returned by drm_plane_index. v2: -avoided nested loop by adding loop count (Daniel) v3: -updated patch header prefix to 'drm' (Matt) v4: -fixed a kerneldoc issue (kbuild-internal) Cc: dri-devel@lists.freedesktop.org Signed-off-by: NChandra Konduru <chandra.konduru@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Acked-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 3月, 2015 1 次提交
-
-
由 Thierry Reding 提交于
With bridges now moving to a separate registry they are no longer DRM objects, hence this define is no longer needed. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
- 12 3月, 2015 1 次提交
-
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 3月, 2015 2 次提交
-
-
由 Laurent Pinchart 提交于
Drivers implementing the universal planes API report the list of supported pixel formats for the primary plane. Make sure the fb passed to the setcrtc ioctl is compatible. Drivers not implementing the universal planes API will have no format reported for the primary plane, skip the check in that case. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Laurent Pinchart 提交于
Both the legacy and atomic helpers need to check whether a plane supports a given pixel format. The code is currently duplicated, share it. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> [danvet: Slightly extend the docbook.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 2月, 2015 1 次提交
-
-
由 Rob Clark 提交于
In DRM/KMS we are lacking a good way to deal with tiled/compressed formats. Especially in the case of dmabuf/prime buffer sharing, where we cannot always rely on under-the-hood flags passed to driver specific gem-create ioctl to pass around these extra flags. The proposal is to add a per-plane format modifier. This allows to, if necessary, use different tiling patters for sub-sampled planes, etc. The format modifiers are added at the end of the ioctl struct, so for legacy userspace it will be zero padded. v1: original v1.5: increase modifier to 64b v2: Incorporate review comments from the big thread, plus a few more. - Add a getcap so that userspace doesn't have to jump through hoops. - Allow modifiers only when a flag is set. That way drivers know when they're dealing with old userspace and need to fish out e.g. tiling from other information. - After rolling out checks for ->modifier to all drivers I've decided that this is way too fragile and needs an explicit opt-in flag. So do that instead. - Add a define (just for documentation really) for the "NONE" modifier. Imo we don't need to add mask #defines since drivers really should only do exact matches against values defined with fourcc_mod_code. - Drop the Samsung tiling modifier on Rob's request since he's not yet sure whether that one is accurate. v3: - Also add a new ->modifier[] array to struct drm_framebuffer and fill it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin. - Remove TODO in comment and add code comment that modifiers should be properly documented, requested by Rob. Cc: Rob Clark <robdclark@gmail.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by: Rob Clark <robdclark@gmail.com> (v1.5) Reviewed-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NDaniel Stone <daniels@collabora.com> Acked-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 28 1月, 2015 2 次提交
-
-
由 Ajay Kumar 提交于
Currently, third party bridge drivers(ptn3460) are dependent on the corresponding encoder driver init, since bridge driver needs a drm_device pointer to finish drm initializations. The encoder driver passes the drm_device pointer to the bridge driver. Because of this dependency, third party drivers like ptn3460 doesn't adhere to the driver model. In this patch, we reframe the bridge registration framework so that bridge initialization is split into 2 steps, and bridge registration happens independent of drm flow: --Step 1: gather all the bridge settings independent of drm and add the bridge onto a global list of bridges. --Step 2: when the encoder driver is probed, call drm_bridge_attach for the corresponding bridge so that the bridge receives drm_device pointer and continues with connector and other drm initializations. The old set of bridge helpers are removed, and a set of new helpers are added to accomplish the 2 step initialization. The bridge devices register themselves onto global list of bridges when they get probed by calling "drm_bridge_add". The parent encoder driver waits till the bridge is available in the lookup table(by calling "of_drm_find_bridge") and then continues with its initialization. The encoder driver should also call "drm_bridge_attach" to pass on the drm_device to the bridge object. drm_bridge_attach inturn calls "bridge->funcs->attach" so that bridge can continue with drm related initializations. Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com> Acked-by: NInki Dae <inki.dae@samsung.com> Tested-by: NRahul Sharma <rahul.sharma@samsung.com> Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Tested-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Ajay Kumar 提交于
Assign the pointer to bridge ops structure(drm_bridge_funcs) in the bridge driver itself, instead of passing it to drm_bridge_init. This will allow bridge driver developer to pack bridge private information inside the bridge object and pass only the drm-relevant information to drm_bridge_init. Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com> Acked-by: NInki Dae <inki.dae@samsung.com> Tested-by: NRahul Sharma <rahul.sharma@samsung.com> Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Tested-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
- 27 1月, 2015 4 次提交
-
-
由 Daniel Vetter 提交于
Cursor plane updates have historically been fully async and mutliple updates batched together for the next vsync. And userspace relies upon that. Since implementing a full queue of async atomic updates is a bit of work lets just recover the cursor specific behaviour with a hint flag and some hacks to drop the vblank wait. v2: Fix kerneldoc, reported by Wu Fengguang. Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
This is the infrastructure for DPMS ported to the atomic world. Fundamental changes compare to legacy DPMS are: - No more per-connector dpms state, instead there's just one per each display pipeline. So if you clone either you have to unclone first if you only want to switch off one screen, or you just switch of everything (like all desktops do). This massively reduces complexity for cloning since now there's no more half-enabled cloned configs to consider. - Only on/off, dpms standby/suspend are as dead as real CRTs. Again reduces complexity a lot. Now especially for backwards compat the really important part for dpms support is that dpms on always succeeds (except for hw death and unplugged cables ofc). Which means everything that could fail (like configuration checking, resources assignments and buffer management) must be done irrespective from ->active. ->active is really only a toggle to change the hardware state. More precisely: - Drivers MUST NOT look at ->active in their ->atomic_check callbacks. Changes to ->active MUST always suceed if nothing else changes. - Drivers using the atomic helpers MUST NOT look at ->active anywhere, period. The helpers will take care of calling the respective enable/modeset/disable hooks as necessary. As before the helpers will carefully keep track of the state and not call any hooks unecessarily, so still no double-disables or enables like with crtc helpers. - ->mode_set hooks are only called when the mode or output configuration changes, not for changes in ->active state. - Drivers which reconstruct the state objects in their ->reset hooks or through some other hw state readout infrastructure must ensure that ->active reflects actual hw state. This just implements the core bits and helper logic, a subsequent patch will implement the helper code to implement legacy dpms with this. v2: Rebase on top of the drm ioctl work: - Move crtc checks to the core check function. - Also check for ->active_changed when deciding whether a modeset might happen (for the ALLOW_MODESET mode). - Expose the ->active state with an atomic prop. v3: Review from Rob - Spelling fix in comment. - Extract needs_modeset helper to consolidate the ->mode_changed || ->active_changed checks. v4: Fixup fumble between crtc->state and crtc_state. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Tested-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
Not a new type exposed to userspace, just a standard way to create them since between range, bitmask and enum there's 3 different ways to pull out a boolean prop. Also add the kerneldoc for the recently added new prop types, which Rob forgot all about. v2: Fixup kerneldoc, spotted by Rob. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Matt Roper 提交于
The rotation property is shared by multiple drivers, so it makes sense to store the rotation value (for atomic-converted drivers) in the common plane state so that core code can eventually access it as well. Cc: dri-devel@lists.freedesktop.org Suggested-by: NDaniel Vetter <daniel@ffwll.ch> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 22 1月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
There's a race window (small for hpd, 10s large for polled outputs) where userspace could sneak in with an unrelated connnector probe ioctl call and eat the hotplug event (since neither the hpd nor the poll code see a state change). To avoid this, check whether the connector state changes in all other ->detect calls (in the current helper code that's only probe_single) and if that's the case, fire off a hotplug event. Note that we can't directly call the hotplug event handler, since that expects that no locks are held (due to reentrancy with the fb code to update the kms console). Also, this requires that drivers using the probe_single helper function set up the poll work. All current drivers do that already, and with the reworked hpd handling there'll be no downside to unconditionally setting up the poll work any more. v2: Review from Rob Clark - Don't bail out of the output poll work immediately if it's disabled to make sure we deliver the delayed hoptplug events. Instead just jump to the tail. - Don't scheduel the work when it's not set up. Would be a driver bug since using probe helpers for anything dynamic without them initialized makes them all noops. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Tested-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 1月, 2015 1 次提交
-
-
由 Boris Brezillon 提交于
Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw RGB or LVDS busses). Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de> Acked-by: NThierry Reding <treding@nvidia.com>
-
- 05 1月, 2015 3 次提交
-
-
由 Rob Clark 提交于
The atomic modeset ioctl can be used to push any number of new values for object properties. The driver can then check the full device configuration as single unit, and try to apply the changes atomically. The ioctl simply takes a list of object IDs and property IDs and their values. Originally based on a patch from Ville Syrjälä, although it has mutated (mutilated?) enough since then that you probably shouldn't blame it on him ;-) The atomic support is hidden behind the DRM_CLIENT_CAP_ATOMIC cap (to protect legacy userspace) and drm.atomic module param (for now). v2: Check for file_priv->atomic to make sure we only allow userspace in-the-know to use atomic. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Expose the core plane state as properties, so they can be updated via atomic ioctl. v2: atomic property flag Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Once a driver is using atomic helpers for modeset, the next step is to switch over to atomic properties. To do this, make sure that any modeset objects have their ->atomic_{get,set}_property() vfuncs suitably populated if they have custom properties (you did already remember to plug in atomic-helper func for the legacy ->set_property() vfuncs, right?), and then set DRIVER_ATOMIC bit in driver_features flag. A new cap is introduced, DRM_CLIENT_CAP_ATOMIC, for the purposes of shielding legacy userspace from atomic properties. Mostly for the benefit of legacy DDX drivers that do silly things like getting/setting each property at startup (since some of the new atomic properties will be able to trigger modeset). Signed-off-by: NRob Clark <robdclark@gmail.com> [danvet: Squash in fixup patch to check for DRM_MODE_PROP_ATOMIC instaed of the CAP define when filtering properties. Reported by Tvrtko Uruslin, acked by Rob.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 19 12月, 2014 2 次提交
-
-
由 Rob Clark 提交于
Since we won't be using the obj->properties->values[] array to shadow property values for atomic drivers, we are going to need a vfunc for getting prop values. Add that along w/ mandatory wrapper fxns. v2: more comments and copypasta comment typo fix Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
As we add properties for all the standard plane/crtc/connector attributes (in preperation for the atomic ioctl), we are going to want to handle core state in core (rather than per driver). Intercepting the core properties will be easier if the atomic_set_property vfuncs are not called directly, but instead have a mandatory wrapper function (which will later serve as the point to intercept core properties). v2: more verbose comments and copypasta comment fix Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 12月, 2014 2 次提交
-
-
由 Rob Clark 提交于
For atomic drivers, we won't use the values array but instead shunt things off to obj->atomic_get_property(). So to simplify things make all read/write of properties values go through the accessors. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
Keep property pointer, instead of id, in per mode-object attachments. This will simplify things in later patches. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-