- 10 3月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
When enabling atomic state object for this ioctl in commit abd69c55 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Nov 25 23:50:05 2014 +0100 drm: Handle atomic state properly in kms getfoo ioctl I've forgotten to remove this hunk in one of the later revisions. drm_encoder_get_crtc already does this. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 24 2月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
In commit ccfc0865 Author: Rob Clark <robdclark@gmail.com> Date: Thu Dec 18 16:01:48 2014 -0500 drm: tweak getconnector locking We need to extend the locking to cover connector->state reading for atomic drivers, but the above commit was a bit too eager and also included the fill_modes callback. Which on i915 on old platforms using load detection needs to acquire modeset locks, resulting in a deadlock on output probing. Reported-by: NMarc Finet <m.dreadlock@gmail.com> Cc: Marc Finet <m.dreadlock@gmail.com> Cc: robdclark@gmail.com Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 2月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
This way drivers fully converted to atomic don't need to update these legacy state variables in their modeset code any more. Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 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 3 次提交
-
-
由 Dan Carpenter 提交于
When setting the video bus supported formats for a display device using drm_display_info_set_bus_formats(), check for the proper variable after duplicating memory. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 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 3 次提交
-
-
由 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>
-
由 Boris Brezillon 提交于
formats and num_formats arguments were previously called fmts and nfmts. Fix the kernel doc comment so that it matches the new argument names. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 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>
-
- 13 1月, 2015 1 次提交
-
-
由 Dave Airlie 提交于
Daniel merged two things in 72a36970, but he merged this code twice, Dan's static checker spotted it. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 05 1月, 2015 5 次提交
-
-
由 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 connector state as properties so it can be updated via atomic ioctl. 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 提交于
Getting ready to add a lot more standard properties for atomic. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> [danvet: Realign function paramaters where the lines shrunk massively.] 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 提交于
Both need to iterate a mode objects properties. Split that out into a helper shared by both ioctl handlers, since this is going to become more complicated when we add atomic properties (which will need filtering from legacy userspace). Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rob Clark 提交于
We need to hold connection_mutex as we read the properties. Easiest thing is just widen the scope where connection_mutex is held. 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 4 次提交
-
-
由 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>
-
由 Rob Clark 提交于
We can already have object properties, which technically can be fb's. Switch the property validation logic over to a get/put style interface so it can take a ref to refcnt'd objects, and then drop that ref after the driver has a chance to take it's own ref. 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>
-
由 Ville Syrjälä 提交于
Currently userspace is allowed to pass in basiclly any kind of garbage to setcrtc. Try to catch the cases where the timings make no sense by passing the mode through drm_mode_validate_basic(). One concern here is that we now start to block some modes that have worked in the past. It's at least possible with when using i915 with LVDS/eDP. Previously we've just ignored everything but hdisplay/vdisplay from the user mode and just overwritten the rest with the panel fixed mode. So if someone has been passing a mode with just those populated that would now stop working. If that is a real problem, we can't add these checks to the core code and each driver would have to have its own sanity checks. So fingers crossed... Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 12月, 2014 8 次提交
-
-
由 Thierry Reding 提交于
sizeof(type) is the variant used most commonly and required by checkpatch. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thierry Reding 提交于
All prior conditional blocks return from the function, so the else block can be at the top level of the function. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thierry Reding 提交于
Single statement blocks don't need to be enclosed in a pair of braces. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thierry Reding 提交于
checkpatch requires the assignment and the check to be separate statements. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thierry Reding 提交于
Fixes a couple of checkpatch warnings regarding the use of kmalloc() with a multiplication. kmalloc_array() is the preferred API. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thierry Reding 提交于
Fixes a couple of checkpatch warnings regarding the use of kzalloc() with a multiplication. kcalloc() is the preferred API. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thierry Reding 提交于
A couple of whitespace changes required to silent various errors and warnings flagged by checkpatch. checkpatch requires that the opening brace be on the same line as a variable declaration. Furthermore an empty line is required after a block of variable declarations. Trailing whitespace as well as using spaces before tabs is considered an error or warning, respectively. Finally, the closing parenthesis of an if condition and the opening brace of the conditional block should be separated by a space. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thierry Reding 提交于
Drivers where the DRM objects have a lifetime that extends beyond that of the DRM device need to zero out the DRM object memory to void stale data such as properties. The DRM core code expects to operate on newly allocated and zeroed out objects and will behave unexpectedly, such as add duplicate properties, otherwise. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 12月, 2014 4 次提交
-
-
由 Martin Peres 提交于
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. CC: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NMartin Peres <martin.peres@free.fr> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Dave Airlie 提交于
This takes the tiling info from the connector and exposes it to userspace, as a blob object in a connector property. The contents of the blob is ABI. v2: add property + function documentation. v3: move property setup from previous patch. add boilerplate + fix long line (Daniel) Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This creates a tile group from DisplayID block, and stores the pieces of parsed info from the DisplayID block into the connector. v2: add missing signoff, add new connector bits to docs. v3: remove some debugging. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
A tile group is an identifier shared by a single monitor, DisplayID topology has 8 bytes we can use for this, just use those for now until something else comes up in the future. We assign these to an idr and use the idr to tell userspace what connectors are in the same tile group. DisplayID v1.3 says the serial number must be unique for displays from the same manufacturer. v2: destroy idr (dvdhrm) add docbook (danvet) airlied:- not sure how to make docbook add fns to tile group section. v3: fix missing unlock. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 06 12月, 2014 1 次提交
-
-
由 Gustavo Padovan 提交于
We need to get hdisplay and vdisplay in a few places so create a helper to make our job easier. Note that drm_crtc_check_viewport() and intel_modeset_pipe_config() were previously making adjustments for doublescan modes and vscan > 1 modes, which was incorrect. Using our new helper fixes this mistake. v2 (by Matt): Use new stereo doubling function (suggested by Ville) v3 (by Matt): - Add missing kerneldoc (Daniel) - Use drm_mode_copy() (Jani) v4 (by Matt): - Drop stereo doubling function again; add 'stereo only' flag to drm_mode_set_crtcinfo() instead (Ville) v5 (by Matt): - Note behavioral change in drm_crtc_check_viewport() and intel_modeset_pipe_config(). (Ander) - Describe new adjustment flags in drm_mode_set_crtcinfo()'s kerneldoc. (Ander) Cc: dri-devel@lists.freedesktop.org Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Acked-by: NDave Airlie <airlied@gmail.com> Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 11月, 2014 2 次提交
-
-
由 Daniel Vetter 提交于
So the problem with async commit (especially async modeset commit) is that the legacy pointers only get updated after the point of no return, in the async part of the modeset sequence. At least as implemented by the current helper functions. This is done in the set_routing_links function in drm_atomic_helper.c. Which also means that access isn't protected by locks but only coordinated by synchronizing with async workers. No problem thus far, until we lock at the getconnector/encoder ioctls. So fix this up by adding special cases for atomic drivers: For those we need to look at state objects. Unfortunately digging out the correct encoder->crtc link is a bit of work, so wrap this up in a helper function. Moving the assignments of connector->encoder and encoder->crtc earlier isn't a good idea because the point of the atomic helpers is that we stage the state updates. That way the disable functions can still inspect the links and rely upon them. v2: Extract full encoder->crtc lookup into helper (Rob). v3: Extract drm_connector_get_encoder too since - we need to always return state->best_encoder when there is a state otherwise we might return stale data if there's a pending async disable (and chase unlocked pointers, too). Same issue with encoder_get_crtc but there it's a bit more tricky to handle. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: NSean Paul <seanpaul@chromium.org> Lightly-Tested-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 25 11月, 2014 1 次提交
-
-
由 Thierry Reding 提交于
The current state of CRTCs, planes and connectors currently leaks during DRM driver ->unload() unless drivers explicitly clean it up. Since there is nothing driver-specific about it, that cleanup can be done within the DRM core. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 11月, 2014 1 次提交
-
-
由 Daniel Vetter 提交于
I guess for hysterical raisins this was meant to be the way to read blob properties. But that's done with the two-stage approach which uses separate blob kms object and the special-purpose get_blob ioctl. Shipping userspace seems to have never relied on this, and the kernel also never put any blob thing onto that property. And nowadays it would blow up, e.g. in drm_property_destroy. Also it makes no sense to return values in an ioctl that only returns metadata about everything. So let's ditch all the internal code for the blob list, rename the list to be unambiguous and sprinkle comments all over the place to explain this peculiar piece of api. v2: Squash in fixup from Rob to remove now unused variables. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-