drm/atomic: Set current atomic state in drm_private_state
drm_private_state has a back pointer to the drm_atomic_state,
however that was not initialized in drm_atomic_get_private_obj_state
after duplication, as it is the case for other drm atomic getters
Ville Syrjälä [Mon, 11 Jun 2018 19:34:01 +0000 (22:34 +0300)]
drm/atomic: Improve debug messages
Print the id/name of the object we're dealing with. Makes it easier to
figure out what's going on. Also toss in a few extra debug prints that
might be useful.
Inki Dae [Thu, 24 May 2018 09:32:59 +0000 (18:32 +0900)]
drm/bridge: sil_sii8620: do not have a dependency of RC_CORE
This patch makes RC_CORE to be selected with this driver.
sil_sii8620 driver calls remote controller interfaces directly
so RC_CORE should be enabled mandatorily.
And some boards not using remote controller device don't really
need to know that RC_CORE config should be enabled to use sil_sii8620
driver only for HDMI.
Changelog v2:
- select INPUT because compiling will fail without INPUT.
Ville Syrjälä [Fri, 25 May 2018 18:50:45 +0000 (21:50 +0300)]
drm: Stop updating plane->crtc/fb/old_fb on atomic drivers
Stop playing around with plane->crtc/fb/old_fb with atomic
drivers. Make life a lot simpler when we don't have to do the
magic old_fb vs. fb dance around plane updates. That way we
can't risk plane->fb getting out of sync with plane->state->fb
and we're less likely to leak any refcounts as well.
Ville Syrjälä [Fri, 25 May 2018 18:50:37 +0000 (21:50 +0300)]
drm/vmwgfx: Stop using plane->fb in atomic_enable()
Instead of looking at the (soon to be deprecated) plane->fb we'll
examing plane->state->fb instead. We can do this because
vmw_du_crtc_atomic_check() prevents us from enabling a crtc
without the primary plane also being enabled.
Due to that same reason, I'm actually not sure what the checks here are
for NULL fb. If we can't enable the crtc without an enabled plane
we should always have an fb. But I'll leave that for someone else
to figure out.
Ville Syrjälä [Fri, 25 May 2018 18:50:35 +0000 (21:50 +0300)]
drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()
The only caller of vmw_kms_update_implicit_fb() is the page_flip
hook which itself gets called with the plane mutex already held.
Hence we can look at plane->state safely.
Ville Syrjälä [Fri, 25 May 2018 18:50:34 +0000 (21:50 +0300)]
drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_update()
all pass in the crtc which means we'll never end up in this branch
of the function. All other callers use drm_modeset_lock_all() somewhere
higher up, which means accessing plane->state is safe.
v2: Drop the comment and make the code do what it did before (Thomas)
v3: Drop the bogus lockdep assert
Cc: Deepak Rawat <drawat@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-3-ville.syrjala@linux.intel.com Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Ville Syrjälä [Fri, 25 May 2018 18:50:33 +0000 (21:50 +0300)]
drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()
Instead of looking at plane->fb let's look at the proper new
plane state.
Not that the code makes a ton of sense. It's only going through the
crtcs in the atomic state, so assuming not all of them are included
we're not even calculating the total bandwidth here. Also we're
not considering whether each crtc is actually enabled or not.
Cc: Deepak Rawat <drawat@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-2-ville.syrjala@linux.intel.com Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Dave Stevenson [Fri, 16 Mar 2018 22:04:35 +0000 (15:04 -0700)]
drm/vc4: Add support for SAND modifier.
This is the format generated by VC4's H.264 engine, and preferred by
the ISP as well. By displaying SAND buffers directly, we can avoid
needing to use the ISP to rewrite the SAND H.264 output to linear
before display.
This is a joint effort by Dave Stevenson (who wrote the initial patch
and DRM demo) and Eric Anholt (drm_fourcc.h generalization, safety
checks, RGBA support).
v2: Make the parameter macro give all of the middle 48 bits (suggested
by Daniels). Fix fourcc_mod_broadcom_mod()'s bits/shift being
swapped. Mark NV12/21 as supported, not YUV420.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by: Eric Anholt <eric@anholt.net> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> (v1) Cc: Boris Brezillon <boris.brezillon@bootlin.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-3-eric@anholt.net
Eric Anholt [Fri, 16 Mar 2018 22:04:34 +0000 (15:04 -0700)]
drm/vc4: Add missing formats to vc4_format_mod_supported().
Daniel's format_mod_supported() patch predated Dave's for NV21/61, and
I didn't catch that when rebasing. This is a problem since the
formats are now getting validated before being passed to the driver's
atomic hooks.
Eric Anholt [Fri, 16 Mar 2018 22:04:33 +0000 (15:04 -0700)]
drm: Trust format_mod_supported() when it OKs a plane modifier.
For parameterized modifiers (Broadcom's SAND and UIF), we need to
allow the parameter fields to be filled in, while exposing only the
variant of the modifier with the parameter unfilled in the internal
arrays and the format blob.
Ville Syrjälä [Fri, 18 May 2018 16:21:59 +0000 (19:21 +0300)]
drm/i915: Promote .format_mod_supported() to the lead role
Up to now we've used the plane's modifier list as the primary
source of information for which modifiers are supported by a
given plane. In order to allow auxiliary metadata to be embedded
within the bits of the modifier we need to stop doing that.
Thus we have to make .format_mod_supported() aware of the plane's
capabilities and gracefully deal with any modifier being passed
in directly from userspace.
Souptick Joarder [Thu, 10 May 2018 13:42:04 +0000 (19:12 +0530)]
gpu: drm: drm_vm: Adding new typedef vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Arnd Bergmann [Fri, 25 May 2018 15:50:08 +0000 (17:50 +0200)]
drm/sun4i: mark PM functions as __maybe_unused
Disabling CONFIG_PM produces a compile time warning when these
functions are not referenced:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function]
static int sun6i_dsi_runtime_suspend(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1043:12: error: 'sun6i_dsi_runtime_resume' defined but not used [-Werror=unused-function]
static int sun6i_dsi_runtime_resume(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~
Ville Syrjälä [Thu, 5 Apr 2018 15:13:57 +0000 (18:13 +0300)]
drm/atmel-hlcdc: Stop using plane->fb
We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Daniel pointed out that the drm_framebuffer_put() in the plane cleanup
indicates that the driver doesn't shut things down cleanly. To do
that we should be able to just call drm_atomic_helper_shutdown(). Not
really sure the current cleanup sequence is actually sane, but whatever.
v2: Replace the drm_framebuffer_put() with
drm_atomic_helper_shutdown() (Daniel)
omap_framebuffer_get_next_connector() uses plane->fb which we want to
deprecate for atomic drivers. As omap_framebuffer_get_next_connector()
is unused just nuke the entire function.
Ville Syrjälä [Thu, 5 Apr 2018 19:50:29 +0000 (22:50 +0300)]
drm/arc: Stop consulting plane->fb
We want to stop using plane->fb with atomic driver, so stop looking at
it.
I have no idea what this code is trying to achieve. There is no
corresponding check in the enable path. Also since
arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going
to assuming that I can just remove the check entirely. There seems
to be a general shortage of .atomic_check() in this driver...
Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t first.
Chris Wilson [Mon, 21 May 2018 08:21:31 +0000 (09:21 +0100)]
drm/i915: Pin the ring high
If we can use an unmappable ring, try to pin it out of the mappable
aperture. This simple layout preference is to try and keep the mappable
aperture reserved and available to handle GGTT mmapping requests from
userspace without causing evictions and GPU stalls.
Chris Wilson [Mon, 21 May 2018 08:21:30 +0000 (09:21 +0100)]
drm/i915: Limit searching for PIN_HIGH
To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
times), doing a search by address over a pathologically fragmented
address space is exceeding slow. To protect ourselves from nearly
unbounded latency (think searching a million holes while under
struct_mutex), limit the search for the highest available hole and
fallback to best-fit if it fails.
In the pathologically fragmented case, such as igt/gem_ctx_thrash, the
effect is dramatic, bringing the runtime down from hours to seconds
(depending on how many other slow searches you hit, e.g. alloc_iova()
and alloc_vmap_area() both degrade to a slow rbtree walk after their
small cache is exhausted). For the real world, the number of search
steps is unlikely to be significant as we should only need to search
once per new context.
Chris Wilson [Mon, 21 May 2018 08:21:29 +0000 (09:21 +0100)]
drm/mm: Add a search-by-address variant to only inspect a single hole
Searching for an available hole by address is slow, as there no
guarantee that a hole will be available and so we must walk over all
nodes in the rbtree before we determine the search was futile. In many
cases, the caller doesn't strictly care for the highest available hole
and was just opportunistically laying out the address space in a
preferred order. In such cases, the caller can accept any address and
would rather do so then do a slow walk.
To be able to mix search strategies, the caller wants to tell the drm_mm
how long to spend on the search. Without a good guide for what should be
the best split, start with a request to try once at most. That is return
the top-most (or lowest) hole if it fulfils the alignment and size
requirements.
v2: Documentation, by why of example (selftests) and kerneldoc.
Chris Wilson [Mon, 21 May 2018 08:21:28 +0000 (09:21 +0100)]
drm/mm: Reject over-sized allocation requests early
As we keep an rbtree of available holes sorted by their size, we can
very easily determine if there is any hole large enough that might
satisfy the allocation request. This helps when dealing with a highly
fragmented address space and a request for a search by address.
To cache the largest size, we convert into the cached rbtree variant
which tracks the leftmost node for us. However, currently we sorted into
ascending size order so the leftmost node is the smallest, and so to
make it the largest hole we need to invert our sorting.
Use new return type vm_fault_t for fault and huge_fault
handler. For now, this is just documenting that the
function returns a VM_FAULT value rather than an errno.
Once all instances are converted, vm_fault_t will become
a distinct type.
Commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_page() returns err which driver
mapped into VM_FAULT_* type. The new function vmf_
insert_page() will replace this inefficiency by
returning VM_FAULT_* type.
Laura Abbott [Wed, 11 Apr 2018 01:03:30 +0000 (18:03 -0700)]
drm/i2c: tda998x: Remove VLA usage
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to this upper bound.
Laura Abbott [Mon, 9 Apr 2018 21:06:47 +0000 (14:06 -0700)]
drm/gma500: Remove VLA
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a reasonable upper bound for the VLAs in
the gma500 driver.
Daniel Stone [Mon, 21 May 2018 14:24:49 +0000 (15:24 +0100)]
drm/gma500: Fix Medfield for drm_framebuffer move
Commit bc61c97502e2 ("drm/gma500: Move GEM BO to drm_framebuffer") moved
the gtt_range structure, from being in psb_framebuffer and embedding the
GEM object, to being placed in the drm_framebuffer with the gtt_range
being derived from the GEM object.
The conversion missed out the Medfield subdriver, which was not being
built in the default drm-misc config. Do the trivial fixup here.
Signed-off-by: Daniel Stone <daniels@collabora.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Fixes: bc61c97502e2 ("drm/gma500: Move GEM BO to drm_framebuffer") Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521142449.20800-1-daniels@collabora.com
Daniel Stone [Fri, 30 Mar 2018 14:11:21 +0000 (15:11 +0100)]
drm/omap: Move buffer pitch/offset to drm_framebuffer
drm_framebuffer already holds per-plane pitch and offsets, which is
filled out for us when we create the framebuffer. Nuke our local copy in
the plane struct.
Daniel Stone [Fri, 30 Mar 2018 14:11:20 +0000 (15:11 +0100)]
drm/omap: Move GEM BO to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Daniel Stone [Fri, 30 Mar 2018 14:11:18 +0000 (15:11 +0100)]
drm/rockchip: Place GEM BOs in drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Heiko Stübner <heiko@sntech.de> Tested-by: Heiko Stübner <heiko@sntech.de> Cc: Sandy Huang <hjc@rock-chips.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-4-daniels@collabora.com
Daniel Stone [Fri, 18 May 2018 13:47:04 +0000 (14:47 +0100)]
drm/mtk: Move GEM BO to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Daniel Stone [Fri, 30 Mar 2018 14:11:35 +0000 (15:11 +0100)]
drm/msm: Move GEM BOs to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.
Daniel Stone [Fri, 30 Mar 2018 14:11:34 +0000 (15:11 +0100)]
drm/gma500: Move GEM BO to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Daniel Stone [Fri, 30 Mar 2018 14:11:33 +0000 (15:11 +0100)]
drm/armada: Move GEM BO to drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Daniel Stone [Fri, 30 Mar 2018 14:11:17 +0000 (15:11 +0100)]
drm/virtio: Place GEM BOs in drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Daniel Stone [Fri, 30 Mar 2018 14:11:15 +0000 (15:11 +0100)]
drm/cirrus: Place GEM BOs in drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Stefan Agner [Thu, 19 Apr 2018 21:20:03 +0000 (23:20 +0200)]
drm/panel: simple: Fix data type in KEO TX31D200VM0BAA timings
All values in a struct struct timing_entry (every entry in
struct display_timing) require an integer. Choose the closest
safe integer of 32.
This avoids a warning seen with clang:
drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit
conversion from 'double' to 'u32' (aka 'unsigned int')
changes value from 33.5 to 33 [-Wliteral-conversion]
.vfront_porch = { 6, 21, 33.5 },
~ ^~~~
drivers/gpu/drm/panel/panel-simple.c:1251:26: warning: implicit
conversion from 'double' to 'u32' (aka 'unsigned int')
changes value from 33.5 to 33 [-Wliteral-conversion]
.vback_porch = { 6, 21, 33.5 },
~ ^~~~
Lucas Stach [Wed, 11 Apr 2018 15:27:41 +0000 (17:27 +0200)]
drm/panel: simple: AUO P320HVN03 uses SPWG data ordering
The patch adding support for the AUO P320HVN03 panel was written against a
preliminary datasheet, which specified JEIDA data ordering. Testing with
real hardware has shown that the actually used data ordering is SPWG.
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as done by other existing panel support changes.
Changes in v2:
- Separate driver change from dt-binding documentation (Rob Herring).
- Add the properties from simple-panel binding that are applicable to
this panel (Rob Herring).
drm/bridge: cdns: Mark runtime PM operations as maybe unused
Building the driver in a configuration with !PM currently causes a
warning about these operations being unused. Mark them as such to shut
up the compiler.
Philippe CORNU [Mon, 23 Apr 2018 14:10:51 +0000 (16:10 +0200)]
drm/panel: otm8009a: Fix glitches by moving backlight enable to otm8009a_enable()
The backlight 1st update was in the otm8009a_prepare() function for a
bad reason: backlight was not working in video mode and the
otm8009a_prepare() is in command mode for the init sequence. As the
backlight is now fixed (no low-power mode), it is good to put it back
in the otm8009a_enable() function, avoiding also image glitches visible
on some "slow" devices.
Philippe CORNU [Mon, 23 Apr 2018 14:10:50 +0000 (16:10 +0200)]
drm/panel: otm8009a: Fix backlight updates
Backlight updates was not working anymore since the good implementation
of the DSI low-power mode in the DSI host driver. After a longer
analysis, the backlight updates in DSI video mode require the DSI high-
speed mode.
Note: it is important to keep the DSI low-power mode for the rest of the
driver as init sequence, sleep in/out... DSI commands work in low-power
mode.
drm/panel: Add device_link from panel device to DRM device
Add device_link from panel device (supplier) to DRM device (consumer)
when drm_panel_attach() is called. This patch should protect the master
DRM driver if an attached panel driver unbinds while it is in use. The
device_link should make sure the DRM device is unbound before the panel
driver becomes unavailable.
The device_link is removed when drm_panel_detach() is called. The
drm_panel_detach() should be called by the consumer DRM driver, not the
panel driver, otherwise both drivers are racing to delete the same link.
drm/panel: Remove drm_panel_detach() calls from all panel drivers
Remove all drm_panel_detach() calls from all panel drivers and update
the kerneldoc for drm_panel_detach().
Setting the connector and drm to NULL when the DRM panel device is going
away hardly serves any purpose. Usually the whole memory structure is
freed right after the remove call. However, calling the detach function
from the master DRM device, and setting the connector pointer to NULL,
has the logic of marking the panel again as available for another DRM
master to attach. The usual situation would be the same DRM master
device binding again.
Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.
This requires also manipulationg ITC bit, as stated in
HDMI spec.
v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.
v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.
v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.
v5:
* Moved patch revision's description to commit messages.
v6:
* Minor naming fix for the content type enumeration string.
v7:
* Fix parameter name for documentation and parameter alignment
in order not to get warning. Added Content Type description to
new HDMI connector properties section.
v8:
* Thrown away unneeded numbers from HDMI content-type property
description. Switch to strings desription instead of plain
definitions.
v9:
* Moved away hdmi specific content-type enum from
drm_connector_state. Content type property should probably not
be bound to any specific connector interface in
drm_connector_state.
Same probably should be done to hdmi_picture_aspect_ration enum
which is also contained in drm_connector_state. Added special
helper function to get derive hdmi specific relevant infoframe
fields.
v10:
* Added usage description to HDMI properties kernel doc.
v11:
* Created centralized function for filling HDMI AVI infoframe, based
on correspondent DRM property value.
Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.
v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.
v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.
v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.
v5:
* Moved patch revision's description to commit messages.
v6:
* Minor naming fix for the content type enumeration string.
v7:
* Fix parameter name for documentation and parameter alignment
in order not to get warning. Added Content Type description to
new HDMI connector properties section.
v8:
* Thrown away unneeded numbers from HDMI content-type property
description. Switch to strings desription instead of plain
definitions.
v9:
* Moved away hdmi specific content-type enum from
drm_connector_state. Content type property should probably not
be bound to any specific connector interface in
drm_connector_state.
Same probably should be done to hdmi_picture_aspect_ration enum
which is also contained in drm_connector_state. Added special
helper function to get derive hdmi specific relevant infoframe
fields.
v10:
* Added usage description to HDMI properties kernel doc.
v11:
* Created centralized function for filling HDMI AVI infoframe, based
on correspondent DRM property value.
Maxime Ripard [Thu, 17 May 2018 13:37:59 +0000 (15:37 +0200)]
drm/vc4: plane: Expand the lower bits by repeating the higher bits
The vc4 HVS uses an internal RGB888 representation of the frames, and will
by default expand formats using a lower depth using zeros.
This causes an issue when we try to use other compositing software such as
pixman that fill the missing bits by repeating the higher significant bits.
As such, we can't check the display output in a reliable way by doing a
software composition and an hardware one and compare both.
To prevent this, force the same behaviour so that we can do such things.
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Reference id -> 1c8f422059ae ("mm: change return type to
vm_fault_t")
Eric Anholt [Wed, 9 May 2018 00:14:25 +0000 (17:14 -0700)]
drm: Fix render node numbering regression from control node removal.
drm_minor_alloc() does multiplication on this enum, so the removal
ended up moving render nodes down from 128 base to 64. This caused
Mesa's surfaceless backend to be unable to open the render nodes,
since it was still looking up at 128.
Shashank Sharma [Tue, 8 May 2018 11:09:45 +0000 (16:39 +0530)]
drm: Add and handle new aspect ratios in DRM layer
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.
The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V2) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
Shashank Sharma [Tue, 8 May 2018 11:09:44 +0000 (16:39 +0530)]
drm: Add aspect ratio parsing in DRM layer
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).
Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Lin, Jia <lin.a.jia@intel.com> Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
drm_fb_helper, while trying to find a common mode among connectors
for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
Ankit Nautiyal [Tue, 8 May 2018 11:09:43 +0000 (16:39 +0530)]
drm: Expose modes with aspect ratio, only if requested
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.
This patch:
-prunes the modes with aspect-ratio information, from the
drm_mode_get_connector modelist supplied to the user, if the
user-space has not set the aspect ratio DRM client cap. However if
such a mode is unique in the list, it is kept in the list, with
aspect-ratio flags reset.
-prepares a list of exposed modes, which is used to find unique modes
if aspect-ratio is not allowed.
-adds a new list_head 'exposed_head' in drm_mode_display, to traverse
the list of exposed modes.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: As suggested by Ville, modified the mechanism of pruning of modes
with aspect-ratio, if the aspect-ratio is not supported. Instead
of straight away pruning such a mode, the mode is retained with
aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
-used a pointer to store last valid mode.
-avoided, modifying of picture_aspect_ratio in kernel mode,
instead only flags bits of user mode are reset (if aspect-ratio
is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
logic to correctly identify and prune modes with aspect-ratio,
if aspect-ratio cap is not set.
V12: As suggested by Ville, added another list_head in
drm_mode_display to traverse the list of exposed modes and
avoided duplication of modes.
V13: Minor modifications, as suggested by Ville.
v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the
pruning logic to avoid any dependency in the order of mode with
aspect-ratio. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Tue, 8 May 2018 11:09:42 +0000 (16:39 +0530)]
drm: Handle aspect ratio info in legacy modeset path
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.
This patch:
1. rejects the modes with aspect-ratio info, during modeset, if the
user does not support aspect ratio.
2. does not load the aspect-ratio info in user-mode structure, if
aspect ratio is not supported.
3. adds helper functions for determining if aspect-ratio is expected
in user-mode and for allowing/disallowing the aspect-ratio, if its
not expected.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: Addressed review comments from Ville:
Do not corrupt the current crtc state by updating aspect-ratio on
the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
aspect ratio, if the user does not set aspect-ratio cap.
V6: Used the helper functions for determining if aspect-ratio is
expected in the user-mode.
V7: rebase
V8: rebase
V9: rebase
V10: Modified the commit-message
V11: rebase
V12: Merged the patch for adding aspect-ratio helper functions
with this patch.
V13: Minor modifications as suggested by Ville.
V14: Removed helper functions, as they were used only once in legacy
modeset path, as suggested by Daniel Vetter.
Ankit Nautiyal [Tue, 8 May 2018 11:09:41 +0000 (16:39 +0530)]
drm: Add DRM client cap for aspect-ratio
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.
To avoid this, a new drm client cap is required to enable a non-atomic
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.
This patch adds the client cap for aspect-ratio.
Since no atomic-userspaces blow up on receiving aspect-ratio
information, the client cap for aspect-ratio is always enabled
for atomic clients.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio. Also,
tweaked the comment lines in the code for better understanding and
clarity, as recommended by Shashank Sharma.
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: As suggested by Daniel Vetter and Ville Syrjala,
always enable aspect-ratio client cap for atomic userspaces,
if no atomic userspace breaks on aspect-ratio bits.
V13: rebase
V14: rebase
Ville Syrjälä [Tue, 8 May 2018 11:09:39 +0000 (16:39 +0530)]
drm/edid: Don't send bogus aspect ratios in AVI infoframes
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.
Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-5-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:38 +0000 (16:39 +0530)]
drm/edid: Fix cea mode aspect ratio handling
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.
Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.
Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: "Lin, Jia" <lin.a.jia@intel.com> Cc: Akashdeep Sharma <akashdeep.sharma@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-4-git-send-email-ankit.k.nautiyal@intel.com
Ville Syrjälä [Tue, 8 May 2018 11:09:37 +0000 (16:39 +0530)]
drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.
Matt Atwood [Fri, 4 May 2018 22:18:00 +0000 (15:18 -0700)]
drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address 0000eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
V8: Style
V9: Strip out DPCD_REV_XX into seperate patch
v10: DPCD_REV_XX to DP_DPCD_REV_XX
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180508092739.GB661@mwanda
Ezequiel Garcia [Fri, 4 May 2018 18:00:37 +0000 (15:00 -0300)]
dma-buf: Remove unneeded stubs around sync_debug interfaces
The sync_debug.h header is internal, and only used by
sw_sync.c. Therefore, SW_SYNC is always defined and there
is no need for the stubs. Remove them and make the code
simpler.
projects / mirror_ubuntu-eoan-kernel.git / log