- 05 Jun, 2014 21 commits
-
-
Thierry Reding authored
When disabling the DSI controller, the code wasn't really doing what it was supposed to. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
To prevent the enable or disable operations to potentially be run multiple times, add guards to return early when the output is already in the targetted state. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The packet sequencer needs to be programmed depending on the video mode of the attached peripheral. Add support for non-burst video modes with sync events (as opposed to sync pulses) and select either sequence depending on the video mode. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The DSI controllers are powered by a (typically 1.2V) regulator. Usually this is always on, so there was no need to support enabling or disabling it thus far. But in order not to consume any power when DSI is inactive, give the driver a chance to enable or disable the supply as needed. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
A bunch of registers are initialized to 0 upon during driver probe. It turns out that none of these are actually needed, so they can simply be dropped. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The pixel format enumeration values used by the Tegra DSI controller don't match those defined by the DSI framework. Make sure to convert them to the internal format before writing it to the register. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
For some reason when the PW*_ENABLE and PM*_ENABLE fields are cleared during disable, the HDMI output stops working properly. Resetting and initializing doesn't help. Comment out those accesses for now until it has been determined what to do about them. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Disable LVDS mode according to register documentation. It seems like this has no effect on the operation of HDMI, but it's probably a good idea to do this anyway. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
This reflects the power-up sequence as described in the documentation, but it doesn't seem to be strictly necessary to get HDMI to work. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Clocks are never enabled or disabled in atomic context, so we can use the clk_prepare_enable() and clk_disable_unprepare() helpers instead. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Schematics indicate that the AVDD_HDMI_PLL supply should be enabled prior to the AVDD_HDMI supply. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The generic Tegra output code already sets up the clocks properly, so there's no need to do it again when the HDMI output is enabled. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Revert commit 18ebc0f4 "drm/tegra: hdmi: Enable VDD earlier for hotplug/DDC" and instead add a new supply for the +5V pin on the HDMI connector. The vdd-supply property refers to the regulator that supplies the AVDD_HDMI input on Tegra, rather than the +5V HDMI connector pin. This was never a problem before, because all boards had that pin hooked up to a regulator that was always on. Starting with Dalmore and continuing with Venice2, the +5V pin is controllable via a GPIO. For reasons unknown, the GPIO ended up as the controlling GPIO of the AVDD_HDMI supply in the Dalmore and Venice2 DTS files. But that's not correct. Instead, a separate supply must be introduced so that the +5V pin can be controlled separately from the supplies that feed the HDMI block within Tegra. A new hdmi-supply property is introduced that takes the place of the vdd-supply and vdd-supply is only enabled when HDMI is enabled rather than all the time. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
For HDMI compliance both of these values need to be set to 1. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Setting the bits in this register is dependent on the output type driven by the display controller. All output drivers already set these properly so there is no need to do it here again. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The tegra_dc_format() and tegra_dc_setup_window() functions are only used internally by the display controller driver. Move them upwards in order to make them static and get rid of the function prototypes. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
V_DIRECTION is the name of the field in the documentation, so use that for consistency. Also add the H_DIRECTION field for completeness. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
The SOR allows the computation of a 32 bit CRC of the content that it transmits. This functionality is exposed via debugfs and is useful to verify proper operation of the SOR. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
YUYV is UYVY with swapped bytes. Luckily the Tegra DC hardware can swap bytes during scan-out, so supporting YUYV is simply a matter of writing the correct value to the byteswap register. This patch modifies tegra_dc_format() to return the byte swap parameter via an output parameter in addition to returning the pixel format. Many other formats can potentially be supported in a similar way. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Remove extern keyword from function prototypes since it isn't needed and drop an unnecessary forward declaration. Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Rob Clark authored
All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same locking. Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked(). Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- 04 Jun, 2014 19 commits
-
-
Rob Clark authored
For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
This should avoid races between connector probing and HPD irqs in the future, currently mode_config.mutex blocks this possibility. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Just flushing out my pile of random drm patches for the merge window, nothing big. And it all hung around in drm-intel trees for a while (only just rebased now). * tag 'topic/core-stuff-2014-06-02' of git://anongit.freedesktop.org/drm-intel: imx-drm: imx-tve: remove unused variable drm: Missed clflushopt in drm_clflush_virt_range drm/plane: Fix a couple of checkpatch warnings drm/plane: Fix sparse warnings drm/exynos: Fix double locks at PM resume drm/ast: Fix double lock at PM resume drm/dp-helper: Deprecate old i2c-over-dp_aux heleprs
-
Dave Airlie authored
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Summary: - Resolve probe order and deferred probe issue with component framework support. - Resolve hdmi dt broken issue. . HDMI DT support, which was broken since CCF (common clock framework) support, and considring legacy dt binding. - Consolidate HDMI part. . APB based phy support for Exynos5420 and later, and fixups related to power on/off sequence. - Consolidate IPP part. . Mostly bug fixups and code cleanups. - Trivial fixups and code cleanups. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (64 commits) drm/exynos: consider deferred probe case drm/exynos: remove unnecessary exynos_hdmi.h file drm/exynos/fimd: allow multiplatform configuration drm/exynos: add hdmiphy power on/off sequence drm/exynos: ipp: remove description of non-existing field drm/exynos: ipp: update comment for struct drm_ipp_buf_info drm/exynos: ipp: rearrange c_node->event_lock using routine drm/exynos: ipp: rearrange c_node->mem_lock using routines drm/exynos: ipp: add ipp_remove_id() drm/exynos: ipp: add cmd_lock for cmd_list drm/exynos: ipp: rename cmd_lock to lock drm/exynos: ipp: remove duplicated setting drm/exynos: ipp: remove usless list_empty() functions drm/exynos: Use PTR_ERR_OR_ZERO in exynos_dp_core.c drm/exynos: remove hardware overlays disable from fimd probe drm/exynos: Fix checkpatch warning in exynos_dp_reg.c drm/exynos: add fimd dependency to fimd related encoders drm/exynos: remove redundant mutex_unlock drm/exynos/fimc: simplify and rename fimc_dst_get_buf_seq drm/exynos/fimc: replace mutex by spinlock ...
-
git://people.freedesktop.org/~robclark/linuxDave Airlie authored
Pretty small pull this time around for msm. Adds some useful debugfs I'd been carrying around on a branch for a while, plus few fixes. And Kconfig update for the great ARCH_MSM -> ARCH_QCOM split. * 'msm-next' of git://people.freedesktop.org/~robclark/linux: drm/msm: use correct gfp flag for vram allocation drm/msm/mdp5: fix error return value drm/msm: remove redundant private plane cleanup drm/msm: add perf logging debugfs drm/msm: add rd logging debugfs drm/msm: update for ARCH_MSM -> ARCH_QCOM drm/msm/hdmi: use gpio and HPD polling drm/msm/mdp5: fix crash in error/unload paths
-
Daniel Vetter authored
The drm core shouldn't depend upon any helpers, and we make sure this doesn't accidentally happen by moving them into the helper-only drm_kms_helper.ko module. v2: Don't break the build for vmwgfx, spotted by Matt. v3: Unbreak the depency loop around CONFIG_FB (not actually a loop since it involves select). Reported by Chris. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Daniel Vetter authored
After the split-out of crtc locks from the big mode_config.mutex there's still two major areas it protects: - Various connector probe states, like connector->status, EDID properties, probed mode lists and similar information. - The links from connector->encoder and encoder->crtc and other modeset-relevant connector state (e.g. properties which control the panel fitter). The later is used by modeset operations. But they don't really care about the former since it's allowed to e.g. enable a disconnected VGA output or with a mode not in the probed list. Thus far this hasn't been a problem, but for the atomic modeset conversion Rob Clark needs to convert all modeset relevant locks into w/w locks. This is required because the order of acquisition is determined by how userspace supplies the atomic modeset data. This has run into troubles in the detect path since the i915 load detect code needs _both_ protections offered by the mode_config.mutex: It updates probe state and it needs to change the modeset configuration to enable the temporary load detect pipe. The big deal here is that for the probe/detect users of this lock a plain mutex fits best, but for atomic modesets we really want a w/w mutex. To fix this lets split out a new connection_mutex lock for the modeset relevant parts. For simplicity I've decided to only add one additional lock for all connector/encoder links and modeset configuration states. We have piles of different modeset objects in addition to those (like bridges or panels), so adding per-object locks would be much more effort. Also, we're guaranteed (at least for now) to do a full modeset if we need to acquire this lock. Which means that fine-grained locking is fairly irrelevant compared to the amount of time the full modeset will take. I've done a full audit, and there's just a few things that justify special focus: - Locking in drm_sysfs.c is almost completely absent. We should sprinkle mode_config.connection_mutex over this file a bit, but since it already lacks mode_config.mutex this patch wont make the situation any worse. This is material for a follow-up patch. - omap has a omap_framebuffer_flush function which walks the connector->encoder->crtc links and is called from many contexts. Some look like they don't acquire mode_config.mutex, so this is already racy. Again fixing this is material for a separate patch. - The radeon hot_plug function to retrain DP links looks at connector->dpms. Currently this happens without any locking, so is already racy. I think radeon_hotplug_work_func should gain mutex_lock/unlock calls for the mode_config.connection_mutex. - Same applies to i915's intel_dp_hot_plug. But again, this is already racy. - i915 load_detect code needs to acquire this lock. Which means the w/w dance due to Rob's work will be nicely contained to _just_ this function. I've added fixme comments everywhere where it looks suspicious but in the sysfs code. After a quick irc discussion with Dave Airlie it sounds like the lack of locking in there is due to sysfs cleanup fun at module unload. v1: original (only compile tested) v2: missing mutex_init(), etc (from Rob Clark) v3: i915 needs more care in the conversion: - Protect the edp pp logic with the connection_mutex. - Use connection_mutex in the backlight code due to get_pipe_from_connector. - Use drm_modeset_lock_all in suspend/resume paths. - Update lock checks in the overlay code. Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
I find myself making this change locally whenever debugging FB reference counting. Which seems a bit silly. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
-
Rob Clark authored
Like range, but values are signed. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
-
Rob Clark authored
An object property is an id (idr) for a drm mode object. This will allow a property to be used set/get a framebuffer, CRTC, etc. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rob Clark authored
If we continue to use bitmask for type, we will quickly run out of room to add new types. Split this up so existing part of bitmask range continues to function as before, but reserve a chunk of the remaining space for an integer type-id. Wrap this all up in some type-check helpers to keep the backwards-compat uglyness contained. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rob Clark authored
Add a few more useful helpers to find mode objects. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
No longer used or needed as the structs have a name field. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jani Nikula authored
Generated using semantic patch: @@ expression E; @@ - drm_get_encoder_name(E) + E->name Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jani Nikula authored
Generated using semantic patches: @@ expression E; @@ - drm_get_encoder_name(&E) + E.name @@ expression E; @@ - drm_get_encoder_name(E) + E->name v2: Turn drm_get_encoder_name(&E) into E.name instead of &(E)->name. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jani Nikula authored
Generated using semantic patch: @@ expression E; @@ - drm_get_connector_name(E) + E->name [airlied: regenerated] Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jani Nikula authored
Generated using semantic patch: @@ expression E; @@ - drm_get_connector_name(E) + E->name [airlied: regenerated] Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jani Nikula authored
Generated using semantic patches: @@ expression E; @@ - drm_get_connector_name(&E) + E.name @@ expression E; @@ - drm_get_connector_name(E) + E->name v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jani Nikula authored
Generated using semantic patches: @@ expression E; @@ - drm_get_connector_name(&E) + E.name @@ expression E; @@ - drm_get_connector_name(E) + E->name v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-