This controller provides output signals to interface directly a variety
of LCD and TFT panels. These output signals are: RGB signals
(up to 24bpp), vertical & horizontal synchronisations, data enable and
the pixel clock.
Add function drm_fb_cma_get_gem_addr() which return the physical address
of framebuffer (1st pixel). This function will usually be called by plane
callback (atomic_update).
Eric Anholt [Wed, 12 Apr 2017 19:12:02 +0000 (12:12 -0700)]
drm/vc4: Expose dma-buf fences for V3D rendering.
This is needed for proper synchronization with display on another DRM
device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the
new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2
desktop tests on pl111+vc4.
This doesn't yet introduce waits on another device's fences before
vc4's rendering/display, because I don't have testcases for them.
v2: Reuse dma_fence_free(), retitle commit message to clarify that
it's not a full dma-buf fencing implementation yet.
MAINTAINERS: Update maintainers/reviewers for bridge drivers
Add Laurent as a reviewer and Andrzej as a maintainer for DRM bridge chip
drivers. They actively review and contribute to bridge drivers and the
bridge API.
Sean Paul [Fri, 7 Apr 2017 20:15:30 +0000 (16:15 -0400)]
Revert "drm: Don't allow interruptions when opening debugfs/crc"
This reverts
commit b8dfa821c27046ede9bf8eb14cc8109d379428e9
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Apr 7 12:17:12 2017 +0100
drm: Don't allow interruptions when opening debugfs/crc
It reportedly breaks things, so let's revert now and try again later.
Fixes: b8dfa821c270 ("drm: Don't allow interruptions when opening debugfs/crc") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org>
Daniel Vetter [Fri, 7 Apr 2017 16:48:17 +0000 (18:48 +0200)]
drm: Only take cursor locks when the cursor plane exists
I thought I've fixed this, but maybe not. Anyway, clearly broken, and
easy fix.
Cc: Tony Lindgren <tony@atomide.com> Reported-by: Tony Lindgren <tony@atomide.com> Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc") Cc: Harry Wentland <harry.wentland@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170407164817.28272-1-daniel.vetter@ffwll.ch
drm/atomic-helper: Remove the backoff hack from set_config
Fixing this properly would mean we get to wire the acquire_ctx all the
way through vmwgfx fbdev code, and doing the same was tricky for the
shared fbdev layer. Probably much better to look into refactoring the
entire code to use the helpers, but since that's not a viable
long-term solution fix the issue by open-coding a vmwgfx version of
set_config, that does the legacy backoff dance internally.
Note: Just compile-tested. The idea is to take
drm_mode_set_config_internal(), remove the "is this a legacy driver"
check, and whack the drm_atomic_legacy_backoff trickery at the end.
Since drm_atomic_legacy_backoff is for atomic commits only we need to
open-code it.
drm/rockchip: vop: Enable pm domain before vop_initial
We're trying to access vop registers here, so need to make sure
the pm domain is on.
Normally it should be enabled by the bootloader, but there's no
guarantee of it. And if we wanna do unbind/bind, it would also
cause the device to hang.
And this patch also does these:
1/ move vop_initial to the end of vop_bind for eaiser error handling.
2/ correct the err_put_pm_runtime of vop_enable.
drm: bridge: analogix: Destroy connector & encoder when unbinding
Normally we do this in drm_mode_config_cleanup. But:
1/ analogix dp's connector is allocated in bind, and freed after unbind.
So we need to destroy it in unbind to avoid further access.
2/ the drm bridge is attached in bind, and detached in encoder cleanup.
So we need to destroy encoder in unbind.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100610 Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from open()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170407111712.13962-1-chris@chris-wilson.co.uk
Neil Armstrong [Thu, 6 Apr 2017 09:34:04 +0000 (11:34 +0200)]
drm: bridge: dw-hdmi: fix input format/encoding from plat_data
The plat_data->input_bus_format and plat_data->input_bus_encoding
are unsigned long and are always >=0, but the value 0 was still
considered as RGB888 for input_bus_format and default color space
for input_bus_encoding in the reworked code.
This patch changes the if statement check for a non-zero value to
either use the default input bus_format and/or bus_encoding for a zero
value and the provided bus_format and/or bus_encoding for a
non zero value.
Thanks to Dan Carpenter for his bug report at [1].
Tested on Amlogic P230 (with CSC enabled for YUV444 to RGB) and Rockchip
RK3288 ACT8846 EVB Board (no CSC involved, direct RGB passthrough).
Cc: Dan Carpenter <dan.carpenter@oracle.com> Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Archit Taneja <architt@codeaurora.org>
[narmstrong@baylibre.com: reworded commit message and added Fixes tag] Link: http://patchwork.freedesktop.org/patch/msgid/1491471244-24989-1-git-send-email-narmstrong@baylibre.com
Rob Herring [Wed, 22 Mar 2017 13:26:08 +0000 (08:26 -0500)]
drm: omap: use common OF graph helpers
The OMAP driver has its own OF graph helpers that are similar to the
common helpers. This commit replaces most of the calls with the common
helpers. There's still a couple of custom helpers left, but the driver
needs more extensive changes to get rid of them.
In dss_init_ports, we invert the loop, looping through the known ports
and matching them to DT nodes rather than looping thru DT nodes and
matching them to the ports.
Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sean Paul <seanpaul@chromium.org>
Rob Herring [Wed, 29 Mar 2017 18:55:46 +0000 (13:55 -0500)]
drm: convert drivers to use drm_of_find_panel_or_bridge
Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.
This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.
Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Archit Taneja <architt@codeaurora.org> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[seanpaul dropped rockchip changes since they're now obsolete] Signed-off-by: Sean Paul <seanpaul@chromium.org>
Rob Herring [Wed, 22 Mar 2017 13:26:06 +0000 (08:26 -0500)]
drm: convert drivers to use of_graph_get_remote_node
Convert drivers to use the new of_graph_get_remote_node() helper
instead of parsing the endpoint node and then getting the remote device
node. Now drivers can just specify the device node and which
port/endpoint and get back the connected remote device node. The details
of the graph binding are nicely abstracted into the core OF graph code.
This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Liviu Dudau <liviu.dudau@arm.com> Tested-by: Eric Anholt <eric@anholt.net> Tested-by: Jyri Sarha <jsarha@ti.com>
Tested by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org>
Rob Herring [Wed, 22 Mar 2017 13:26:05 +0000 (08:26 -0500)]
drm: of: introduce drm_of_find_panel_or_bridge
Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated. Create a common function,
drm_of_find_panel_or_bridge, to find the connected node and the
associated DRM panel or bridge device.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
[seanpaul dropped extern from drm_of.h] Signed-off-by: Sean Paul <seanpaul@chromium.org>
drm/atomic: Move enable/connector check up in check_modeset()
Now that handle_conflicting_encoders no longer touches active state,
so there's no need to do the check quite that late any more.
Doing it with all the other checks makes it a lot more clear what the
below block tries to accomplish, and this feels like a better place to
put the check.
drm/atomic: Set all the changed flags in one place.
Now that handle_conflicting_encoders cannot disable crtc's any more
it makes sense to set all the changed flags in 1 place.
This makes the code slightly less magical.
The (now removed) comment is out of date. The only reason the
active_changed was set late was because handle_conflicting_encoders
could disable connectors. This is no longer the case,
and we can put everything in 1 place.
Currently we use a flag to change behavior in atomic commit
whether a conflicting encoder should be enabled or disabled.
This is used for the legacy set_config helper, which disables
connectors that have a conflicting encoder but not part of the
active crtc list.
There's no need for this to be handled in atomic commit, it
could be done in the set_config helper instead. This will
let the atomic check function reject any conflicting encoders,
while set_config can disable conflicting crtc's. This makes it
possible to recalculate the changed flags in 1 loop.
Daniel Vetter [Thu, 6 Apr 2017 19:06:54 +0000 (21:06 +0200)]
drm: Take mode_config.mutex in setcrtc ioctl
Legacy drivers insist that we really take all the locks in this path,
and the harm in doing so is minimal.
v2: Like git add, it exists :(
Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around ->set_config") Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: Alex Deucher <alexdeucher@gmail.com> Reported-by: Alex Deucher <alexdeucher@gmail.com> Acked-and-tested-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170406190654.6733-1-daniel.vetter@ffwll.ch
drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4.
mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.
Some implementations of detect() already lock all state,
so we have to pass an acquire_ctx to them to prevent a deadlock.
This means changing the function signature of detect() slightly,
and passing the acquire_ctx for locking multiple crtc's.
For the callbacks, it will always be non-zero. To allow callers
not to worry about this, drm_helper_probe_detect_ctx is added
which might handle -EDEADLK for you.
Changes since v1:
- Always set ctx parameter.
Changes since v2:
- Always take connection_mutex when probing.
Changes since v3:
- Remove the ctx from intel_dp_long_pulse, and add
WARN_ON(!connection_mutex) (danvet)
- Update docs to clarify the locking situation. (danvet)
Dan Carpenter [Thu, 6 Apr 2017 05:21:32 +0000 (08:21 +0300)]
drm: bridge: dw-hdmi: Add a missing break statement
There was supposed to be a break before the next case statement.
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170406052132.GA26605@mwanda
Daniel Vetter [Mon, 3 Apr 2017 08:33:04 +0000 (10:33 +0200)]
drm/fb-helper: Extract _legacy kms functions
The goal is to push all the kms locking down into these separate
_atomic and _legacy functions, so that we can correctly pass the
acquire ctx into all atomic drivers. Instead of playing games with
hidden ctx in mode_config.acquire_ctx. All the fbdev state will be
protected by a new fbdev private lock that Thierry is working on.
This here is just prep by creating a clean split between atomic and
legacy paths, which also simplifies the control flow a bit.
Daniel Vetter [Mon, 3 Apr 2017 08:33:03 +0000 (10:33 +0200)]
drm: extract legacy framebuffer remove
I got confused every time I audited what that lock_all is doing in
there until realizing it's for legacy kms only. Make that a notch more
obvious by having 2 entirely different paths.
While at it also move the atomic version of this into
drm_framebuffer.c, there's no reason it needs to be in drm_atomic.c.
That way it becomes a simple static function.
Daniel Vetter [Mon, 3 Apr 2017 08:33:01 +0000 (10:33 +0200)]
drm: Add acquire ctx to ->gamma_set hook
Atomic helpers really want this instead of the hacked-up legacy
backoff trick, which unfortunately prevents drivers from using their
own private drm_modeset_locks.
Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which
don't yet use the new atomic color mgmt/gamma table stuff. Would be
nice if they could switch over and just hook up
drm_atomic_helper_legacy_gamma_set() instead.
Cc: Dave Airlie <airlied@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-13-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 3 Apr 2017 08:33:00 +0000 (10:33 +0200)]
drm: Add explicit acquire ctx handling around ->gamma_set
Just the groundwork to prepare for adding the acquire cxt parameter to
the ->gamma_set hook. Again we need a temporary hack to fill out
mode_config.acquire_ctx until the atomic helpers are switched over.
Daniel Vetter [Mon, 3 Apr 2017 08:32:59 +0000 (10:32 +0200)]
drm/fb-helper: Give up on kgdb for atomic drivers
It just doesn't work. It probably stopped working way, way before that
(e.g. i915 grabbed random mutexes all over in modeset code at least
since gen6), but with atomic and all the ww_mutex stuff it's indeed
hopeless.
Remove ->mode_set_base_atomic from the 2 atomic drivers (i915 and
nouveau) that still had one (both had dummy implementations already
anyway), and shunt atomic drivers in the helpers debug_enter/leave
functions.
I'll leave the code in for radeon and amdgpu, but I think as soon as
amdgpu is atomic we should think about just ripping it out. Only
having it around for radeon and pre-nv50 is rather pointless. This
would also allow us to nuke all that code from fbdev.
Funny part is that _all_ kms drivers set this hook, despite that no
one else provides the required ->mode_set_base_atomic implementation.
The reason I'm jumping on this is that I want to wire up a full
acquire ctx for the benefit of atomic drivers, everywhere. And the
debug_enter/leave implementations call ->gamma_set. And there's just
no way ever we can create an acquire_ctx in the nmi context of kgdb.
Daniel Vetter [Mon, 3 Apr 2017 08:32:57 +0000 (10:32 +0200)]
drm/i915: Nuke intel_atomic_legacy_gamma_set
We do set DRIVER_ATOMIC now.
Note that the comment is outdated, the property paths switched over to
checking drm_drv_uses_atomic_modeset() a while ago. Which means this
can't even break if we revert DRIVER_ATOMIC again.
Daniel Vetter [Mon, 3 Apr 2017 08:32:56 +0000 (10:32 +0200)]
drm: Only take crtc lock in get_gamma ioctl
We don't call into drivers at all here, this is enough. Also, we can
reduce the critical section a bit to simplify the code.
crtc->gamma_size is set up once at driver load and then invariant, so
also doesn't need any protection.
Daniel Vetter [Mon, 3 Apr 2017 08:32:55 +0000 (10:32 +0200)]
drm: Drop modeset_lock_all from the getproperty ioctl
Properties, i.e. the struct drm_property specifying the type and value
range of a property, not the instantiation on a given object, are
invariant over the lifetime of a driver.
Hence no locking at all is needed, we can just remove it.
While at it give the function some love and simplify it, to get it
under the 80 char limit:
- Straighten the loops to reduce the nesting.
- use u64_to_user_ptr casting helper
- use put_user for fixed u64 copies.
Note there's a small behavioural change in that we now copy parts of
the values to userspace if the arrays are a bit too small. Since
userspace will immediately retry anyway, this doesn't matter.
Daniel Vetter [Mon, 3 Apr 2017 08:32:54 +0000 (10:32 +0200)]
drm: drop modeset_lock_all from drm_state_info
If we push the locks down we don't have to take them all at the same
time.
Aside: Making dump_info fully safe should be fairly simple, if we
protect the ->state pointers with rcu. Simply putting a
synchronize_rcu() into the drm_atomic_state free function should be
all that's roughly needed. Well except we shouldn't block in there, so
better to put that into a work_struct. But I've not set out to fix
that little issue.
Daniel Vetter [Mon, 3 Apr 2017 08:32:52 +0000 (10:32 +0200)]
drm: Remove drm_modeset_legacy_acquire_ctx and crtc->acquire_ctx
With all the callers of drm_modeset_lock_crtc gone, and all the places
it was formerly used properly wiring the acquire ctx through, we can
remove this.
The only hidden context magic we still have is now the global one.
Daniel Vetter [Mon, 3 Apr 2017 08:32:51 +0000 (10:32 +0200)]
drm: Remove drm_modeset_(un)lock_crtc
The last user, the cursor ioctl, can just open-code this too. We
simply have to move the acquire ctx dance from the universal function
up into the top-level ioctl handler.
With the atomic API, it is possible that a single commit affects
multiple crtcs. If the user requests an event with that commit, one
event will be sent for each CRTC, but it is not possible to distinguish
which crtc an event is for in user space. To solve this, the reserved
field in struct drm_vblank_event is repurposed to include the crtc_id
which the event is for.
The DRM_CAP_CRTC_IN_VBLANK_EVENT is added to allow userspace to query if
the crtc field will be set properly.
Daniel Vetter [Tue, 4 Apr 2017 09:52:57 +0000 (11:52 +0200)]
drm: document drm_ioctl.[hc]
Also unify/merge with the existing stuff.
I was a bit torn where to put this, but in the end I decided to put
all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we
have a bit a split with the other uapi related stuff used internally,
like drm_file.[hc], but I think overall this makes more sense.
If it's too confusing we can always add more cross-links to make it
more discoverable. But the auto-sprinkling of links kernel-doc already
does seems sufficient.
Also for prettier docs and more cross-links, switch the internal
defines over to an enum, as usual.
v2: Update kerneldoc fro drm_compat_ioctl too (caught by 0day), plus a
bit more drive-by polish.
Daniel Vetter [Tue, 4 Apr 2017 09:52:55 +0000 (11:52 +0200)]
drm: Consolidate and document sysfs support
- remove docs for internal func, doesn't add value
- add short overview snippet instead explaining that drivers don't
have to bother themselves with reg/unreg concerns
- drop the ttm comment about drmP.h, drmP.h is disappearing ...
Neil Armstrong [Tue, 4 Apr 2017 12:31:59 +0000 (14:31 +0200)]
drm: bridge: dw-hdmi: Move HPD handling to PHY operations
The HDMI TX controller support HPD and RXSENSE signaling from the PHY
via it's STAT0 PHY interface, but some vendor PHYs can manage these
signals independently from the controller, thus these STAT0 handling
should be moved to PHY specific operations and become optional.
The existing STAT0 HPD and RXSENSE handling code is refactored into
a supplementaty set of default PHY operations that are used automatically
when the platform glue doesn't provide its own operations.
Neil Armstrong [Tue, 4 Apr 2017 12:31:57 +0000 (14:31 +0200)]
drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
Switch code to use the newly introduced V4L bus formats IDs instead of custom
defines. Also use the V4L encoding defines.
Some display pipelines can only provide non-RBG input pixels to the HDMI TX
Controller, this patch takes the pixel format from the plat_data if provided.
Reviewed-by: Jose Abreu <joabreu@synopsys.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function
In preparation for adding PHY operations to handle RX SENSE and HPD,
group all the PHY interrupt setup code in a single location and extract
it to a separate function.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com>
[narmstrong: renamed dw_hdmi_fb_registered to dw_hdmi_setup_i2c] Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Dave Airlie [Mon, 3 Apr 2017 19:45:49 +0000 (05:45 +1000)]
Merge tag 'omapdrm-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
omapdrm changes for 4.12
Main changes include:
* Add support for render nodes.
* Refactor omapdss code to allow multiple DISPC implementations. This is pre-work for DSS6 support.
* Fix replication logic bug, which caused RGB565 fb to be shown too dark on a 24bit display.
* Improve detection of display stack readiness, which should remove the probe order issues.
* Link panel-dpi with its backlight, so that they are turned on/off in sync.
* Fix possibly incorrect setup of sync and data-enable signals.
* Get rid of DRM_OMAP_NUM_CRTCS config option.
* tag 'omapdrm-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (34 commits)
drm/omap: Major omap_modeset_init() cleanup
drm/omap: Remove the obsolete #define omap_plane _omap_plane hack
drm/omap: Fix one ugly indentation style break left by coccinelle
drm/omap: Rename enum omap_plane to enum omap_plane_id
drm/omap: Get rid of DRM_OMAP_NUM_CRTCS config option
drm/omap: fix crash on module unload
drm/omap: use drm_atomic_helper_shutdown()
drm/omap: fix display SYNC/DE flags
drm/omap: dispc: improve debug print of display flags
drm/omap: displays: panel-dpi: Support for handling backlight devices
drm/omap: poll only connectors where the connect/disconnect can be checked
drm/omap: display: Add displays in sorted order to the panel_list
drm/omap: Use omapdss_stack_is_ready() to check that the display stack is up
drm/omap: dss: Support for detecting display stack readiness
drm/omap: dss: Functions to check components in the display/output list
drm/omap: fix replication logic
drm/omap: remove unused dispc_wb_enable & dispc_wb_is_enabled
drm/omap: remove all EXPORT_SYMBOLs from dispc.c
drm/omap: use dispc_ops
drm/omap: fill dispc_ops
...
Neil Armstrong [Mon, 3 Apr 2017 14:42:34 +0000 (16:42 +0200)]
media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller
In order to describe the RGB and YUV bus formats used to feed the
Synopsys DesignWare HDMI TX Controller, add missing formats to the
list of Bus Formats.
Documentation for these formats is added in a separate patch.
Reviewed-by: Archit Taneja <architt@codeaurora.org> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1491230558-10804-3-git-send-email-narmstrong@baylibre.com
Jyri Sarha [Fri, 24 Mar 2017 14:47:55 +0000 (16:47 +0200)]
drm/omap: Major omap_modeset_init() cleanup
Cleanup overly complex omap_modeset_init(). The function is trying to
support many unusual configuration, that have never been tested and
are not supported by other parts of the dirver.
After cleanup the init function creates exactly one connector,
encoder, crtc, and primary plane per each connected dss-device. Each
connector->encoder->crtc chain is expected to be separate and each
crtc is connect to a single dss-channel. If the configuration does not
match the expectations or exceeds the available resources, the
configuration is rejected.
Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Jyri Sarha [Fri, 24 Mar 2017 14:47:52 +0000 (16:47 +0200)]
drm/omap: Rename enum omap_plane to enum omap_plane_id
The enum omap_plane conflicted with the same struct name for omapdrm
plane private data. This rename should solve the conflict.
The rename was implement with this very simple coccinelle patch:
------------------------
@@
@@
enum
-omap_plane
+omap_plane_id
------------------------
The patch was applied like this:
spatch --sp-file <cocci_file> --all-includes --in-place --dir drivers/gpu/drm/omapdrm
The above patch did not rename the actual enum definition. That was
added manually on top of the spatch changes.
Jyri Sarha [Fri, 24 Mar 2017 14:47:51 +0000 (16:47 +0200)]
drm/omap: Get rid of DRM_OMAP_NUM_CRTCS config option
Allocate one CRTC for each connected output and get rid of
DRM_OMAP_NUM_CRTCS config option. We still can not create more CRTCs
than we have DSS display managers. We also reserve one overlay per
CRTC for primary plane so we can not have more CRTCs than we have
overlays either.
We shut down all the crtcs at unload time before calling
omap_drm_irq_uninstall, so the code in omap_drm_irq_uninstall() is
unnecessary and can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tomi Valkeinen [Wed, 23 Nov 2016 11:24:00 +0000 (13:24 +0200)]
drm/omap: fix display SYNC/DE flags
At the moment VSYNC/HSYNC/DE high/low flags set by the panel/encoder
drivers get lost when the videotimings are translated to DRM's
videomode, as DRM's mode does not have corresponding flags.
DRM has bus-flags for this purpose, and while it lacks a few flags at
the moment, it should be used here. However, until we rewrite omapdrm's
device model, using bus-flags is rather difficult.
As a short term fix, this patch makes sure that every time the videomode
is set in omap_crtc_mode_set_nofb(), the driver asks for the SYNC/DE
flags from the panel/encoder drivers, and thus we get the correct flags
into use.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Peter Ujfalusi [Fri, 9 Sep 2016 10:33:06 +0000 (13:33 +0300)]
drm/omap: displays: panel-dpi: Support for handling backlight devices
The associated backlight device can be configured via DT by providing the
phandle to the device.
If the backlight device is configured, the driver can manage the backligt
along with the panel's power state, iow it can turn on the backlight when
the panel is enabled and turn it off when the panel is disabled.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Peter Ujfalusi [Mon, 22 Aug 2016 12:54:30 +0000 (15:54 +0300)]
drm/omap: poll only connectors where the connect/disconnect can be checked
When the connector associated detect callback is not provided, we can not
detect if the display is connected or disconnected. These displays do not
support hot plug, they are always connected. Let DRM know that connectors
w/o detect callback should not be polled.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Peter Ujfalusi [Thu, 11 Aug 2016 07:20:23 +0000 (10:20 +0300)]
drm/omap: display: Add displays in sorted order to the panel_list
Keep the panel_list ordered according to aliases. The DRM connectors will
be created following the panel_list. By keeping the list ordered the DRM
connectors will be created in the same order regardless of the driver
probe order.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Peter Ujfalusi [Tue, 3 May 2016 19:08:01 +0000 (22:08 +0300)]
drm/omap: Use omapdss_stack_is_ready() to check that the display stack is up
Instead of 'guessing' based on aliases of the status of the DSS drivers,
use the new interface to check that all needed drivers are loaded.
In this way we can be sure that all needed drivers are loaded so it is
safe to continue the probing of omapdrm.
This method will allow the omapdrm to be probed 'headless', without
outputs.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Peter Ujfalusi [Tue, 3 May 2016 19:07:10 +0000 (22:07 +0300)]
drm/omap: dss: Support for detecting display stack readiness
When omapdss is loaded (all core components are in place) create a list of
devices used in the display graph. This list later can be used by omapdrm
via the omapdss_stack_is_ready() function to check that these components
are loaded. Based on this information, omapdrm can defer probe in case when
the omapdss stack is not ready yet.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Peter Ujfalusi [Mon, 2 May 2016 11:55:38 +0000 (14:55 +0300)]
drm/omap: dss: Functions to check components in the display/output list
The functions can be used to check a component (by it's of_node) if it is
part of the omapdss display or output list. If the component is found, it
means that the driver is loaded.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi Valkeinen [Mon, 29 Aug 2016 10:15:02 +0000 (13:15 +0300)]
drm/omap: fix replication logic
DSS uses "replication logic" to convert color components from smaller
bit widths to bigger bit widths. Without replication logic, the color
component would be shifted and the least significant bits would be left
at 0, whereas with replication logic, the least significat bits will be
filled with the most significant bit.
For some reason omapdrm leaves replication logic always to off, which,
in the most common case, means that showing 16-bit RGB colors on 24-bit
display gives a bit darker colors than expected.
The reset value of the replication logic bit is enabled, and it should
always be set, as there's no practical reason to disable it. This patch
removes the option to disable it from omapdrm, and always sets it to
enabled in dispc.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
projects / karo-tx-linux.git / log