summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_dvo.c
AgeCommit message (Collapse)AuthorFilesLines
2015-08-14drm/i915: Get rid of dpms handling.Maarten Lankhorst1-45/+1
This is now done completely atomically. Keep connectors_active for now, but make it mirror crtc_state->active. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-14drm/i915: Validate the state after an atomic modeset only, and pass the state.Maarten Lankhorst1-2/+0
First step in removing dpms and validating atomic state. There can still be a mismatch in the connector state because the dpms callbacks are still used, but this can not happen immediately after a modeset. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-27drm: Make the connector dpms callback return a value, v2.Maarten Lankhorst1-3/+5
This is required to properly handle failing dpms calls. When making a wait in i915 interruptible, I've noticed that the dpms sequence could fail with -ERESTARTSYS because it was waiting interruptibly for flips. So from now on allow drivers to fail in their connector dpms callback. Encoder and crtc dpms callbacks are unaffected. Changes since v1: - Update kerneldoc for the drm helper functions. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Resolve conflicts due to different merge order.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-29drm/i915: Silence compiler warning in dvoChris Wilson1-1/+1
drivers/gpu/drm/i915/intel_dvo.c: In function ‘intel_dvo_init’: drivers/gpu/drm/i915/intel_dvo.c:531:8: warning: array subscript is above array bounds [-Warray-bounds] gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix and gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-04-13drm/i915: Allocate connector state together with the connectorsAnder Conselvan de Oliveira1-1/+1
Connector states were being allocated in intel_setup_outputs() in loop over all connectors. That meant hot-added connectors would have a NULL state. Since the change to use a struct drm_atomic_state for the legacy modeset, connector states are necessary for the i915 driver to function properly, so that would lead to oopses. v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reported-and-tested-by: Nicolas Kalkhof <nkalkhof@web.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-01drm/i915: base gmbus pin validity check on the gmbus pin map arrayJani Nikula1-1/+1
This will be helpful for adding future platforms. It is better to keep the information in the single point of truth (the table) instead of duplicating it into the validity function. While at it, add dev_priv parameter to the function, also to prepare for adding future platform support. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-01drm/i915: refer to pin instead of port in the intel_i2c.c interfacesJani Nikula1-1/+1
Rename intel_gmbus_is_port_valid to intel_gmbus_is_valid_pin, and rename port parameters to pin as well. This matches usage all around, as usually a pin is passed to the validity check function. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-01drm/i915: rename GMBUS_PORT_* macros as GMBUS_PIN_*Jani Nikula1-4/+4
The specs refer to pin pairs. Start moving towards using pin rather than port all around to avoid confusion. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-31drm/i915: Enable DVO 2x clock around DVO encoder initVille Syrjälä1-0/+17
ns2501 requires the DVO 2x clock before it will respond to i2c access, so make sure the clock is enabled when we try to initialize the encoder. Fixes the display getting lost on module reload on my Fujitsu/Siemens Lifebook S6010. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-26drm/i915: Implement connector state duplicationAnder Conselvan de Oliveira1-0/+1
So that we can add connector states to the drm_atomic_state used in the legacy modeset. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Add atomic_get_property entrypoint for connectors (v2)Matt Roper1-0/+1
Even though we only support atomic plane updates at the moment, we still need to add an .atomic_get_property() entrypoint for connectors before we allow the driver to flip on the DRIVER_ATOMIC bit. As soon as that bit gets set, the DRM core will start adding atomic connector properties (in addition to the plane properties we care about at the moment), so we need to be able to handle the new way the DRM core will interact with us. For simplicity, we just lookup driver-specific connector properties in the usual shadow array maintained by the core. Once we get real atomic modeset support for crtc's and planes, this code should be re-written to pull the data out of crtc/connector state structures. v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Setup dummy atomic state for connectors (v3)Matt Roper1-0/+2
We want to enable/test plane updates via the atomic interface, but as soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic codepaths to lookup properties during drmModeGetConnector() and some of those codepaths unconditionally dereference connector->state (specifically when looking up the CRTC ID property in drm_atomic_connector_get_property()). Create a dummy connector state for each connector at init time to ensure the DRM core doesn't try to dereference a NULL connector->state. The actual connector properties will never be updated or contain useful information, but since we're doing this specifically for testing/debug of the plane operations (and only when a specific kernel module option is given), that shouldn't really matter. Once we start creating connector states, the DRM core will want to be able to clean them up for us. We also need to hook up the destruction entrypoint to the core's helper. v2: Squash in the patch to set the state destruction hook (Ander & Bob) v3: Only create dummy connector states when we're actually faking atomic support. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Make intel_crtc->config a pointerAnder Conselvan de Oliveira1-4/+4
To match the semantics of drm_crtc->state, which this will eventually become. The allocation of the memory for config will be fixed in a followup patch. By adding the extra _config field to intel_crtc it was possible to generate this entire patch with the cocci script below. @@ @@ struct intel_crtc { ... -struct intel_crtc_state config; +struct intel_crtc_state _config; +struct intel_crtc_state *config; ... } @@ struct intel_crtc *crtc; @@ -memset(&crtc->config, 0, sizeof(crtc->config)); +memset(crtc->config, 0, sizeof(*crtc->config)); @@ @@ __intel_set_mode(...) { <... -to_intel_crtc(crtc)->config = *pipe_config; +(*(to_intel_crtc(crtc)->config)) = *pipe_config; ...> } @@ @@ intel_crtc_init(...) { ... WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe); +intel_crtc->config = &intel_crtc->_config; return; ... } @@ struct intel_crtc *crtc; @@ -&crtc->config +crtc->config @@ struct intel_crtc *crtc; identifier member; @@ -crtc->config.member +crtc->config->member @@ expression E; @@ -&(to_intel_crtc(E)->config) +to_intel_crtc(E)->config @@ expression E; identifier member; @@ -to_intel_crtc(E)->config.member +to_intel_crtc(E)->config->member v2: Clarify manual changes by splitting them into another patch. (Matt) Improve cocci script to generate even more of the changes. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Embedded struct drm_crtc_state in intel_crtc_stateAnder Conselvan de Oliveira1-6/+6
And get rid of the duplicate mode structures. This patch was generated with the following semantic patch: @@ @@ struct intel_crtc_state { +struct drm_crtc_state base; + ... -struct drm_display_mode requested_mode; -struct drm_display_mode adjusted_mode; ... } @@ struct intel_crtc_state *state; @@ -state->adjusted_mode +state->base.adjusted_mode @@ struct intel_crtc_state *state; @@ -state->requested_mode +state->base.mode @@ struct intel_crtc_state state; @@ -state.adjusted_mode +state.base.adjusted_mode @@ struct intel_crtc_state state; @@ -state.requested_mode +state.base.mode @@ struct drm_crtc *crtc; @@ -to_intel_crtc(crtc)->config.adjusted_mode +to_intel_crtc(crtc)->config.base.adjusted_mode @@ identifier member; expression E; @@ -PIPE_CONF_CHECK_FLAGS(adjusted_mode.member, E); +PIPE_CONF_CHECK_FLAGS(base.adjusted_mode.member, E); @@ identifier member; @@ -PIPE_CONF_CHECK_I(adjusted_mode.member); +PIPE_CONF_CHECK_I(base.adjusted_mode.member); @@ identifier member; @@ -PIPE_CONF_CHECK_CLOCK_FUZZY(adjusted_mode.member); +PIPE_CONF_CHECK_CLOCK_FUZZY(base.adjusted_mode.member); v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Rename struct intel_crtc_config to intel_crtc_stateAnder Conselvan de Oliveira1-3/+3
The objective is to make this structure usable with the atomic helpers, so let's start with the rename. Patch generated with coccinelle: @@ @@ -struct intel_crtc_config { +struct intel_crtc_state { ... } @@ @@ -struct intel_crtc_config +struct intel_crtc_state v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-03drm/i915: Don't call DVO mode_set hook on DPMS changesVille Syrjälä1-4/+0
Calling the mode_set hook on DPMS changes doesn't seem to be necessary for ns2501. Just drop it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-03drm/i915: Enable DVO between mode_set and dpms hooksVille Syrjälä1-2/+3
To more closely match the IEGD ns2501 driver behaviour, call the mode_set hook while the DVO port is still disabled, then enable the DVO port, and finally call the dpms hook. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-03drm/i915: ns2501 is on DVOBVille Syrjälä1-1/+1
On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead of DVOC. FIXME: Maybe need to dig out the correct DVO port from VBT Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-09Merge tag 'drm-intel-next-2014-06-20' of ↵Dave Airlie1-0/+8
git://anongit.freedesktop.org/drm-intel into drm-next - Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and flip events. This is prep work for proper PSR support and should also be useful for DRRS&fbc. - Runtime suspend hardware on system suspend to support the new SOix sleep states, from Jesse. - PSR updates for broadwell (Rodrigo) - Universal plane support for cursors (Matt Roper), including core drm patches. - Prefault gtt mappings (Chris) - baytrail write-enable pte bit support (Akash Goel) - mmio based flips (Sourab Gupta) instead of blitter ring flips - interrupt handling race fixes (Oscar Mateo) And old, not yet merged features from the previous round: - rps/turbo support for chv (Deepak) - some other straggling chv patches (Ville) - proper universal plane conversion for the primary plane (Matt Roper) - ppgtt on vlv from Jesse - pile of cleanups, little fixes for insane corner cases and improved debug support all over * tag 'drm-intel-next-2014-06-20' of git://anongit.freedesktop.org/drm-intel: (99 commits) drm/i915: Update DRIVER_DATE to 20140620 drivers/i915: Fix unnoticed failure of init_ring_common() drm/i915: Track frontbuffer invalidation/flushing drm/i915: Use new frontbuffer bits to increase pll clock drm/i915: don't take runtime PM reference around freeze/thaw drm/i915: use runtime irq suspend/resume in freeze/thaw drm/i915: Properly track domain of the fbcon fb drm/i915: Print obj->frontbuffer_bits in debugfs output drm/i915: Introduce accurate frontbuffer tracking drm/i915: Drop schedule_back from psr_exit drm/i915: Ditch intel_edp_psr_update drm/i915: Drop unecessary complexity from psr_inactivate drm/i915: Remove ctx->last_ring drm/i915/chv: Ack interrupts before handling them (CHV) drm/i915/bdw: Ack interrupts before handling them (GEN8) drm/i915/vlv: Ack interrupts before handling them (VLV) drm/i915: Ack interrupts before handling them (GEN5 - GEN7) drm/i915: Don't BUG_ON in i915_gem_obj_offset drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info drm/i915: Add some L3 registers to the parser whitelist ... Conflicts: drivers/gpu/drm/i915/i915_drv.c
2014-06-19drm: add register and unregister functions for connectorsThomas Wood1-1/+1
Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13drm/i915: Don't get hw state from DVO chip unless DVO is enabledVille Syrjälä1-0/+8
Certain DVO chips (ns2501 for example) don't like to be accessed unless the PLL is running. Simply skip the DVO get_hw_state if the DVO port is disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-04drm/i915: replace drm_get_connector_name() with direct name field useJani Nikula1-1/+1
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>
2014-05-05drm/i915/dvo: Remove ->mode_set callbackDaniel Vetter1-2/+2
Currently for the i9xx crtc hooks there's nothing between the call to encoder->mode_set and encoder->pre_enable which touches the hardware. Therefore, since dvo is only used on gen2, we can just move the hook. Yay for easy cases! The only other important thing to check is that the new ->pre_enable hook is idempotent wrt the sw state since now it can be called multiple times (due to DPMS). It only reads crtc->config but otherwise leaves it as-is, so we're good. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-11drm/i915: Make encoder cloning more flexibleVille Syrjälä1-2/+3
Currently we allow encoders to indicate whether they can be part of a cloned set with just one flag. That's not flexible enough to describe the actual hardware capabilities. Instead make it a bitmask of encoder types with which the current encoder can be cloned. For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should match what the old boolean flag allowed. We will add some more cloning options in the future. Note that this patch also removes the encoder.possible_clones setting from encoder setup code - we compute this dynamically. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add Ville's explanation why removing the encoder possible_clones is save.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-02-14drm/i915: add unregister callback to connectorImre Deak1-0/+1
Since commit d9255d57147e1dbcebdf6670409c2fa0ac3609e6 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date:   Thu Sep 26 20:05:59 2013 -0300 it became clear that we need to separate the unload sequence into two parts: 1. remove all interfaces through which new operations on some object (crtc, encoder, connector) can be started and make sure all pending operations are completed 2. do the actual tear down of the internal representation of the above objects The above commit achieved this separation for connectors by splitting out the sysfs removal part from the connector's destroy callback and doing this removal before calling drm_mode_config_cleanup() which does the actual tear-down of all the drm objects. Since we'll have to customize the interface removal part for different types of connectors in the upcoming patches, add a new unregister callback and move the interface removal part to it. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Return a drm_mode_status enum in the mode_valid vfuncsDamien Lespiau1-2/+3
We had some mode_valid() vfuncs returning an int, others the enum. Let's use the latter everywhere. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-04drm/i915/dvo: call ->mode_set callback only when the port is runningDaniel Vetter1-4/+12
The ns2501 controller seems to need the dpll and dvo port to accept the timing update commands. Quick testing on my x30 here seems to indicate that other dvo controllers don't mind. So let's move the ->mode_set callback to a place where we have the port up and running already. Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thomas Richter <thor@math.tu-berlin.de> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: destroy connector sysfs files earlierPaulo Zanoni1-1/+0
For some reason, every single time I try to run module_reload something tries to read the connector sysfs files. This happens after we destroy the encoders and before we destroy the connectors, so when the sysfs read triggers the connector detect() function, intel_conector->encoder points to memory that was already freed. The bad backtrace is just: [<ffffffff8163ca9a>] dump_stack+0x54/0x74 [<ffffffffa00c2c8e>] intel_dp_detect+0x1e/0x4b0 [i915] [<ffffffffa001913d>] status_show+0x3d/0x80 [drm] [<ffffffff813d5340>] dev_attr_show+0x20/0x60 [<ffffffff81221f50>] ? sysfs_read_file+0x80/0x1b0 [<ffffffff81221f79>] sysfs_read_file+0xa9/0x1b0 [<ffffffff811aaf1e>] vfs_read+0x9e/0x170 [<ffffffff811aba4c>] SyS_read+0x4c/0xa0 [<ffffffff8164e392>] system_call_fastpath+0x16/0x1b But if you add tons of memory checking debug options to your Kernel you'll also see: - general protection fault: 0000 - BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten - INFO: Allocated in intel_ddi_init+0x65/0x270 [i915] - INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915] Among a bunch of other error messages. So this commit just destroys the sysfs files before both the encoder and connectors are freed. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: Use crtc_clock with the adjusted modeDamien Lespiau1-1/+1
struct drm_mode_display now has a separate crtc_ version of the clock to be used when we're talking about the timings given to the harwadre (was far as the mode is concerned). This commit is really the result of a git grep adjusted_mode.*clock and replacing those by adjusted_mode.crtc_clock. No functional change. v2: Rebased on drm-intel-queued-next Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) patternDaniel Vetter1-2/+2
Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-24Merge tag 'v3.12-rc2' into drm-intel-nextDaniel Vetter1-0/+2
Backmerge Linux 3.12-rc2 to prep for a bunch of -next patches: - Header cleanup in intel_drv.h, both changed in -fixes and my current -next pile. - Cursor handling cleanup for -next which depends upon the cursor handling fix merged into -rc2. All just trivial conflicts of the "changed adjacent lines" type: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-17drm/i915: Fix port_clock and adjusted_mode.clock readout all overVille Syrjälä1-0/+2
Now that adjusted_mode.clock no longer contains the pixel_multiplier, we can kill the get_clock() callback and instead do the clock readout in get_pipe_config(). Also i9xx_crtc_clock_get() can now extract the frequency of the PCH DPLL, so use it to populate port_clock accurately for PCH encoders. For DP in port A the encoder is still responsible for filling in port_clock. The FDI adjusted_mode.clock extraction is kept in place for some extra sanity checking, but we no longer need to pretend it's also the port_clock. In the encoder get_config() functions fill out adjusted_mode.clock based on port_clock and other details such as the DP M/N values, HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then do an extra sanity check to make sure the dotclock we derived from the FDI configuratiuon matches the one we derive from port_clock. DVO doesn't exist on PCH platforms, so it doesn't need to anything but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so none of the changes apply there. v2: Use hdmi_reg color format to detect 12bpc HDMI case v3: Set adjusted_mode.clock for LVDS too v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get, eliminate the useless link_freq variable. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-12drm/i915/dvo: set crtc timings again for panel fixed modesDaniel Vetter1-0/+2
Yet another regression due to commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 21 21:37:09 2013 +0200 drm/i915: clean up crtc timings computation I'm starting to wonder whether this was worth it ... v2: Actually make it compile. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-05drm/i915: Remove unused mode_fixup() vfunc of struct intel_dvo_dev_opsDamien Lespiau1-5/+0
It's totally unused, so remove the last mode_fixup appearance in i915. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-04drm/i915/dvo: use native encoder ->mode_set callbackDaniel Vetter1-17/+11
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-04drm/i915/dvo: switch ->mode_fixup to ->compute_configDaniel Vetter1-6/+8
This is the last encoder ->mode_fixup callback we have left, so convert it. Note that we want to only rip out the encoder->mode_fixup callback. But we still have the dvo_slave->mode_fixup callback. dvo is gen2 only, so we won't ever touch this again. Hence why I didn't go through all 6-7 dvo slave drivers and give them the same treatment. I'll add a note to the commit message about this when merging, presuming there's nothing else in the patch that needs to be fixed up. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add note about why we keep the dvo->mode_fixup callback to answer a question from Rodrigo's review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-04drm/i915/dvo: use intel_encoder to the upcast macroDaniel Vetter1-9/+9
More natural and will soon be even better! Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-24drm/i915: Add some debug breadcrumbs to connector detectionChris Wilson1-0/+2
Try to decypher detection failures is a little tricker at the moment as the only indicator of progress is when output_poll_execute() tells us the result after the connector->detect() has run. This patch adds a telltale to the start of each detect function so that we can track progress and associate activity more clearly with each connector. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-09drm/i915: fix dvo DPLL regressionDaniel Vetter1-3/+0
I've missed that intel_dvo_mode_set changes the dpll configuration. Hence when I've reworked the sequence to only enable the dpll in the crtc_enable callback in commit 66e3d5c09940d08d94b03e65b420fadaa7484318 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jun 16 21:24:16 2013 +0200 drm/i915: move i9xx dpll enabling into crtc enable function that special DVO bit was lost. Some BSpec reading confirms that it's only needed for DVO encoders. Section 1.5.4, "DPLL A Control Register" for bit 30: "2X Clock Enable. When driving In non-gang DVO modes such as a connected flat panel or TV, a 2X" version of the clock is needed. When not using the 2X output it should be disabled. This bit cannot be set when driving the integrated LVDS port on devices such as Montara-GM." Fix this regression up. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66516 Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Partially-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-31drm/i915: document why dvo/sdvo/crt need a special dpms functionJani Nikula1-0/+3
In the cloned case, changing just one output but keeping the other, the pipe state won't change and intel_crtc_update_dpms will be a nop, but we still need to update the dpms state of the output being changed. Only dvo, sdvo and crt are cloneable, so only those three have special dpms functions. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-21drm/i915: add encoder get_config function v5Jesse Barnes1-0/+21
We can use this for fetching encoder specific pipe_config state, like mode flags, adjusted clock, etc. Just used for mode flags atm, so we can check the pipe config state at mode set time. v2: get_config when checking hw state too v3: fix DVO and LVDS mode flags (Ville) get SDVO DTD for flag fetch (Ville) v4: use input timings (Ville) correct command used (Ville) remove gen4 check (Ville) v5: get DDI flag config too Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4) Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-21Merge tag 'v3.10-rc2' into drm-intel-next-queuedDaniel Vetter1-1/+12
Backmerge Linux 3.10-rc2 since the various (rather trivial) conflicts grew a bit out of hand. intel_dp.c has the only real functional conflict since the logic changed while dev_priv->edp.bpp was moved around. Also squash in a whitespace fixup from Ben Widawsky for i915_gem_gtt.c, git seems to do something pretty strange in there (which I don't fully understand tbh). Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-21drm/i915: add support for dvo Chrontel 7010Bbraggle@free.fr1-0/+7
This patch add dvo detection for the Chrontel 7010B on some old hardware. References: https://bugzilla.kernel.org/show_bug.cgi?id=55101 Signed-off-by: Braggle <braggle at free.fr> [danvet: Fix up whitespace mangling.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-19drm/i915: Fall back to bit banging mode for DVO transmitter detectionDavid Müller (ELSOFT AG)1-1/+12
As discussed in this thread http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html GMBUS based DVO transmitter detection seems to be unreliable which could result in an unusable DVO port. The attached patch fixes this by falling back to bit banging mode for the time DVO transmitter detection is in progress. Signed-off-by: David Müller <d.mueller@elsoft.ch> Tested-by: David Müller <d.mueller@elsoft.ch> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-14drm/i915: rip out helper->disable noop functionsDaniel Vetter1-1/+0
Now that the driver is in control of whether it needs to disable everything at take-over or not, we can rip this all out. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-04Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds1-19/+96
Pull drm merge (part 1) from Dave Airlie: "So first of all my tree and uapi stuff has a conflict mess, its my fault as the nouveau stuff didn't hit -next as were trying to rebase regressions out of it before we merged. Highlights: - SH mobile modesetting driver and associated helpers - some DRM core documentation - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write combined pte writing, ilk rc6 support, - nouveau: major driver rework into a hw core driver, makes features like SLI a lot saner to implement, - psb: add eDP/DP support for Cedarview - radeon: 2 layer page tables, async VM pte updates, better PLL selection for > 2 screens, better ACPI interactions The rest is general grab bag of fixes. So why part 1? well I have the exynos pull req which came in a bit late but was waiting for me to do something they shouldn't have and it looks fairly safe, and David Howells has some more header cleanups he'd like me to pull, that seem like a good idea, but I'd like to get this merge out of the way so -next dosen't get blocked." Tons of conflicts mostly due to silly include line changes, but mostly mindless. A few other small semantic conflicts too, noted from Dave's pre-merged branch. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits) drm/nv98/crypt: fix fuc build with latest envyas drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering drm/nv41/vm: fix and enable use of "real" pciegart drm/nv44/vm: fix and enable use of "real" pciegart drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie drm/nouveau: store supported dma mask in vmmgr drm/nvc0/ibus: initial implementation of subdev drm/nouveau/therm: add support for fan-control modes drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules drm/nouveau/therm: calculate the pwm divisor on nv50+ drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster drm/nouveau/therm: move thermal-related functions to the therm subdev drm/nouveau/bios: parse the pwm divisor from the perf table drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices drm/nouveau/therm: rework thermal table parsing drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table drm/nouveau: fix pm initialization order drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it drm/nouveau: log channel debug/error messages from client object rather than drm client drm/nouveau: have drm debugging macros build on top of core macros ...
2012-10-02UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells1-3/+3
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
2012-10-02UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.David Howells1-1/+0
Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h). They are now #included via drmP.h and drm_crtc.h via a preceding patch. Without this patch and the patch to make include the UAPI headers from the core headers, after the UAPI split, the DRM C sources cannot find these UAPI headers because the DRM code relies on specific -I flags to make #include "..." work on headers in include/drm/ - but that does not work after the UAPI split without adding more -I flags. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
2012-09-06drm/i915: improve modeset state checking after dpms callsDaniel Vetter1-1/+1
Now that we have solid modeset state tracking and checking code in place, we can do the Full Monty also after dpms calls. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-06drm/i915: s/intel_encoder_disable/intel_encoder_noopDaniel Vetter1-1/+1
Because that's what it is. Unfortunately we can't rip this out because the fb helper has an incetious relationship with the crtc helper - it likes to call disable_unused_functions, among other things. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-28 08:40:31 +0300