summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_opregion.c
AgeCommit message (Collapse)Author
2017-02-16drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXTHans de Goede
If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation for a vbt in mailbox #4 for this. This fixes the driver not finding the VBT on a jumper ezpad mini3 cherrytrail tablet and on a ACER SW5_017 machine. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487088758-30050-1-git-send-email-jani.nikula@intel.com (cherry picked from commit dfb65e71ea2c1d97ac373cc0587dc60b3307581a) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-11-17drm/i915/opregion: fill in the CADL from connector list, not DIDLJani Nikula
This is essentially the same thing as duplicating DIDL now that the connector list has the ACPI device IDs. Cc: Peter Wu <peter@lekensteyn.nl> Cc: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Cc: Paolo Stivanin <paolostivanin@fastmail.fm> Tested-by: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com> Tested-by: Paolo Stivanin <paolostivanin@fastmail.fm> Tested-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/ea0a052fa99a4cb56b559a815866434bcfef853d.1479295490.git.jani.nikula@intel.com
2016-11-17drm/i915: make i915 the source of acpi device ids for _DODJani Nikula
The graphics driver is supposed to define the DIDL, which are used for _DOD, not the BIOS. Restore that behaviour. This is basically a revert of commit 3143751ff51a163b77f7efd389043e038f3e008e Author: Zhang Rui <rui.zhang@intel.com> Date: Mon Mar 29 15:12:16 2010 +0800 drm/i915: set DIDL using the ACPI video output device _ADR method return. which went out of its way to cater to a specific BIOS, setting up DIDL based on _ADR method. Perhaps that approach worked on that specific machine, but on the machines I checked the _ADR method invents the device identifiers out of thin air if DIDL has not been set. The source for _ADR is also supposed to be the DIDL set by the driver, not the other way around. With this, we'll also limit the number of outputs to what the driver actually has. A side effect of this change is that the DIDL, and by proxy CADL, will be initialized in the order of the connector list. That, in turn, has internal panels in front, ensuring they're included in the DIDL and CADL lists. Hopefully this ensures the BIOS does not block backlight hotkey events, thinking the internal panel is off. v2: do not set ACPI_DEVICE_ID_SCHEME in the device id (Peter Wu) v3: Rebase Cc: Peter Wu <peter@lekensteyn.nl> Cc: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Cc: Paolo Stivanin <paolostivanin@fastmail.fm> Tested-by: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com> Tested-by: Paolo Stivanin <paolostivanin@fastmail.fm> Tested-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Reviewed-and-tested-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/9660d29cf310c17bbf4d58c0e09d5b047446e2d5.1479295490.git.jani.nikula@intel.com
2016-09-14drm/i915: Ignore OpRegion panel type except on select machinesVille Syrjälä
Turns out commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") has regressed quite a few machines. So it looks like we can't use the panel type from OpRegion on all systems, and yet we absolutely must use it on some specific systems. Despite trying, I was unable to find any automagic way to determine if the OpRegion panel type is respectable or not. The only glimmer of hope I had was bit 8 in the SCIC response, but that turned out to not work either (it was always 0 on both types of systems). So, to fix the regressions without breaking the machine we know to need the OpRegion panel type, let's just add a quirk for this. Only specific machines known to require the OpRegion panel type will therefore use it. Everyone else will fall bck to the VBT panel type. The only known machine so far is a "Conrac GmbH IX45GM2". The PCI subsystem ID on this machine is just a generic 8086:2a42, so of no use. Instead we'll go with a DMI match. I suspect we can now also revert commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL") but let's leave that to a separate patch. v2: Do the DMI match in the opregion code directly, as dev_priv->quirks gets populated too late Cc: Rob Kramer <rob@solution-space.com> Cc: Martin van Es <martin@mrvanes.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Dave Airlie <airlied@linux.ie> Cc: Marco Krüger <krgsch@gmail.com> Cc: Sean Greenslade <sean@seangreenslade.com> Cc: Trudy Tective <bertslany@gmail.com> Cc: Robin Müller <rm1990@gmx.de> Cc: Alexander Kobel <a-kobel@a-kobel.de> Cc: Alexey Shumitsky <alexey.shumitsky@gmail.com> Cc: Emil Andersen Lauridsen <mine809@gmail.com> Cc: oceans112@gmail.com Cc: James Hogan <james@albanarts.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: stable@vger.kernel.org References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363 Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") Tested-by: Marco Krüger <krgsch@gmail.com> Tested-by: Alexey Shumitsky <alexey.shumitsky@gmail.com> Tested-by: Sean Greenslade <sean@seangreenslade.com> Tested-by: Emil Andersen Lauridsen <mine809@gmail.com> Tested-by: Robin Müller <rm1990@gmx.de> Tested-by: oceans112@gmail.com Tested-by: Rob Kramer <rob@solution-space.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2016-07-14drm/i915: Ignore panel type from OpRegion on SKLVille Syrjälä
Dell XPS 13 9350 apparently doesn't like it when we use the panel type from OpRegion. The OpRegion panel type (0) tells us to use use low vswing for eDP, whereas the VBT panel type (2) tells us to use normal vswing. The problem is that low vswing results in some display flickers. Since no one seems to know how this stuff is supposed to be handled, let's just ignore the OpRegion panel type on SKL for now. v2: Print the panel type correctly in the debug output Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: drm-intel-fixes@lists.freedesktop.org References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468324837-29237-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-07-07drm/i915: s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/Ville Syrjälä
INTEL_OUTPUT_DISPLAYPORT hsa been bugging me for a long time. It always looks out of place besides INTEL_OUTPUT_EDP and INTEL_OUTPUT_DP_MST. Let's just rename it to INTEL_OUTPUT_DP. v2: Rebase Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466621833-5054-9-git-send-email-ville.syrjala@linux.intel.com
2016-07-05drm/i915: Convert dev_priv->dev backpointers to dev_priv->drmChris Wilson
Since drm_i915_private is now a subclass of drm_device we do not need to chase the drm_i915_private->dev backpointer and can instead simply access drm_i915_private->drm directly. text data bss dec hex filename 1068757 4565 416 1073738 10624a drivers/gpu/drm/i915/i915.ko 1066949 4565 416 1071930 105b3a drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ struct drm_i915_private *d; identifier i; @@ ( - d->dev->i + d->drm.i | - d->dev + &d->drm ) and for good measure the dev_priv->dev backpointer was removed entirely. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467711623-2905-4-git-send-email-chris@chris-wilson.co.uk
2016-06-29drm/i915/opregion: handle missing connector types for acpi display typesJani Nikula
Most notably eDP, DSI, and TV. Add MISSING_CASE handling so we won't miss this in the future. Reviewed-and-tested-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/5773794027ea0d699052a343491b52343ba30504.1465810007.git.jani.nikula@intel.com
2016-06-29drm/i915/opregion: abstract acpi display type getter for a connectorJani Nikula
No functional changes. Reviewed-and-tested-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/ef19172e5a00d8abd8190a5389283ef6b5f7eaa9.1465810007.git.jani.nikula@intel.com
2016-06-29drm/i915/opregion: add acpi defines from the specJani Nikula
It's easier to read the code when the macro names match the spec. Also add a bunch of missing ones. No functional changes. Reviewed-and-tested-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/7cfdd2733b8cc7abae43cfa8c81aed902b69ecd5.1465810007.git.jani.nikula@intel.com
2016-05-23drm/i915/opregion: Rename init/fini functions to register/unregisterChris Wilson
Current intel_opregion_init is called during the driver registration phase and intel_opregion_fini from the unregistration phase. Rename the functions so that this is clear from their names. The phases tell us what we expect the existing hw state to be, e.g. whether interrupts are still enabled etc. It should be noted that the opregion init/fini routines are asymmetric and this is carried across into their new names. Indeed, their new names make it even clearer that perhaps all is not well in the opregion suspend/resume sequence (as well in the module unload). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464012490-30961-2-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
2016-05-23drm/i915/opregion: Convert to using native drm_i915_privateChris Wilson
Prefer passing struct drm_i915_private to internal interfaces as this saves us having to dance between drm_device and our native struct. The savings hare are small (only 70 bytes of unrequired dancing), but progressive! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464012490-30961-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
2016-05-09drm/i915: Small display interrupt handlers tidyTvrtko Ursulin
I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away with only dev_priv in the huge majority of cases. Tidying that up had a cascading effect on changing functions prototypes, so relatively big churn factor, but I think it is for the better. For example even where changes cascade out of i915_irq.c, for functions prefixed with intel_, genX_ or <plat>_, it makes more sense to take dev_priv directly anyway. This allows us to eliminate local variables and intermixed usage of dev and dev_priv where only one is good enough. End result is shrinkage of both source and the resulting binary. i915.ko: - .text 000b0899 + .text 000b0619 Or if we look at the Gen8 display irq chain: -00000000000006ad t gen8_irq_handler +0000000000000663 t gen8_irq_handler -0000000000000028 T intel_opregion_asle_intr +0000000000000024 T intel_opregion_asle_intr -000000000000008c t ilk_hpd_irq_handler +000000000000007f t ilk_hpd_irq_handler -0000000000000116 T intel_check_page_flip +0000000000000112 T intel_check_page_flip -000000000000011a T intel_prepare_page_flip +0000000000000119 T intel_prepare_page_flip -0000000000000014 T intel_finish_page_flip_plane +0000000000000013 T intel_finish_page_flip_plane -0000000000000053 t hsw_pipe_crc_irq_handler +000000000000004c t hsw_pipe_crc_irq_handler -000000000000022e t cpt_irq_handler +0000000000000213 t cpt_irq_handler So small shrinkage but it is all fast paths so doesn't harm. Situation is similar in other interrupt handlers as well. v2: Tidy intel_queue_rps_boost_for_request as well. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-19drm/i915: Clean up PCI config register handlingJoonas Lahtinen
Do not use magic numbers, do not prefix stuff with "PCI_", do not declare registers in implementation files. Also move the PCI registers under correct comment in i915_reg.h. v2: - Consistently use BSM (not BDSM or other variants from PRM) (Chris) - Also include register address to help identify the register (Chris) v3: - Refer to register value as *_val instead of *_reg (Chris) v4: - Make style checker happy Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2016-04-13drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPIJani Nikula
The whole file is ignored on CONFIG_ACPI=n. Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460127589-8357-1-git-send-email-jani.nikula@intel.com
2016-04-12drm/i915: Get panel_type from OpRegion panel detailsVille Syrjälä
We've had problems on several occasions with using the panel type from the VBT block 40. Usually it seems to be 2, which often doesn't give us the correct timings for the panel. After some more digging I found a way to get a panel type via the OpRegion SWSCI GBDA "Get Panel Details" method. Let's try to use it. The spec has this to say about the output: "Bits [15:8] - Panel Type Bits contain the panel type user setting from CMOS 00h = Not Valid, use default Panel Type & Timings from VBT 01h - 0Fh = Panel Number" Another version of the spec lists the valid range as 1-16, which makes more sense since VBT supports 16 panels. Based on actual results from Rob's G45, 1-16 is what we need to accept. The other bits in the output don't look relevant for the problem at hand. The input is specified as: "Bits [31:4] - Reserved Reserved (must be zero) Bits [3:0] - Panel Number These bits contain the sequential index of Panel, starting at 0 and counting upwards from the first integrated Internal Flat-Panel Display Encoder present, and then from the first external Display Encoder (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels. 0h - 0Fh = Panel number" For now I've just hardcoded the input panel number as 0. That would seem like a decent choise for LVDS. Not so sure about eDP when port != A. v2: Accept values 1-16 Filter out bogus results in opregion code (Jani) Add debug logging for all the different branches (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rob Kramer <rob@solution-space.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460359431-11003-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Rob Kramer <rob@solution-space.com>
2015-12-17drm/i915/opregion: handle VBT sizes bigger than 6 KBJani Nikula
The RVDA and RVDS (raw VBT data address and size) fields of the ASLE mailbox may specify an alternate location for VBT instead of mailbox #4. Use the alternate location if available and valid, falling back to mailbox #4 otherwise. v2: Update debug logging (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178280-28020-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915: prefer for_each_intel_* macros for iterationJani Nikula
Use the for_each_intel_* macros for iterating intel_encoder, intel_connector, and intel_crtc. No functional changes. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450262896-5325-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915/debugfs: add a separate debugfs file for VBTJani Nikula
In the future the VBT might not be in mailbox #4 of the ACPI OpRegion, thus unavailable in i915_opregion, so add a separate file for the VBT. v2: Drop the locking as unneeded (Chris) v3: Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178232-27780-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915/opregion: make VBT pointer a constJani Nikula
Because we can. It's not to be touched so tell the compiler too. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/4b1872b121fb34a193cff9a5cb4e7c858d4a55aa.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915/opregion: make VBT size limit more strictJani Nikula
The VBT in OpRegion should fit in mailbox #4. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/4bdb3f5820e3dbd1cdfa7b65cadfce4f80b880f0.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915: refactor VBT validationJani Nikula
Make the validation function a boolean operating on a buffer of given size, removing the extra pointer dances. Move the OpRegion based VBT validation to intel_opregion_setup(), only initializing opregion->vbt if it's valid. v2: move logging about valid VBT to opregion setup too (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178175-27420-1-git-send-email-jani.nikula@intel.com
2015-12-16drm/i915: move "no VBT in opregion" quirk to intel_opregion_setup()Jani Nikula
Check the quirk in intel_opregion_setup(), and don't initialize opregion->vbt at all if the quirk says it's not present, hiding the quirk from the rest of the driver. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/7cdc86eb441f8b7075142445a800b07ecf8c76cb.1450089383.git.jani.nikula@intel.com
2015-12-16drm/i915: Add Intel opregion mailbox 5 structureDeepak M
Mailbox 5 is BIOS to Driver Notification mailbox is intended to support BIOS to Driver event notification or data storage for BIOS to Driver data synchronization purpose. Mailbox 5 is the extension of mailbox 3. v4 by Jani: - don't add asle_ext to dev_priv as it's unused - use u8 for bddc and rsvd fields in asle ext struct - add BUILD_BUG_ON the asle ext struct size - debug logging for asle ext present Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Deepak M <m.deepak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/c2d4009659fca32280d9859ec34a62f45b86d895.1450089383.git.jani.nikula@intel.com
2015-12-11drm/i915: add VBT address and size fields to ASLE mailbox structDeepak M
To be used on systems where the VBT does not fit into the normal VBT mailbox. v3: rebase Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Deepak M <m.deepak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448923632-16760-3-git-send-email-m.deepak@intel.com [Jani: updated commit message] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-10-31drm/i915: Don't complain about lack of ACPI video biosDaniel Vetter
Another CI fail we have for no reason. Totally unjustified since nothing fails at all. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445590806-23886-1-git-send-email-daniel.vetter@ffwll.ch Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-13i915: switch from acpi_os_ioremap to memremapWilliams, Dan J
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly map it with memremap rather than the implied cache setting of acpi_os_ioremap(). Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-02drm/i915/bxt: DSI encoder support in CRTC modesetShashank Sharma
SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset functions are re-used for modeset sequence. But DDI interface doesn't include support for DSI. This patch adds: 1. cases for DSI encoder, in those modeset functions and allows a CRTC modeset 2. Adds call to pre_pll enabled from CRTC modeset function. Nothing needs to be done as such in CRTC for DSI encoder, as PLL, clock and and transcoder programming will be taken care in encoder's pre_enable and pre_pll_enable function. v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI encoder like DSI for platforms having HAS_DDI as true. v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid encoder. v4: WARN_ON for invalid encoder is refactored as per Jani's suggestion. Fixed the sequence for pre_pll_enable. v5: Protected DDI code paths in case of DSI encoder calls. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15Merge tag 'drm-intel-fixes-2015-07-15' into drm-intel-next-queuedDaniel Vetter
Backmerge fixes since it's getting out of hand again with the massive split due to atomic between -next and 4.2-rc. All the bugfixes in 4.2-rc are addressed already (by converting more towards atomic instead of minimal duct-tape) so just always pick the version in next for the conflicts in modeset code. All the other conflicts are just adjacent lines changed. Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem_gtt.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h drivers/gpu/drm/i915/intel_ringbuffer.h Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-06drm/i915/opregion: start using extended didlJani Nikula
Adding support for did2, or the extended support display devices ID list, increases the total to 15. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-06drm/i915/opregion: abstract didl and did2 getter and setterJani Nikula
Make it easier to handle the extended didl. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-06drm/i915/opregion: prefer DRM logging functions over pr_warn and dev_dbgJani Nikula
Conform to same style as the rest of the driver. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-06drm/i915/opregion: add new opregion stuffJani Nikula
Inluding extended didl and cpdl fields Present since opregion version 3.0. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-06drm/i915/opregion: use BUILD_BUG_ON to verify mailbox struct sizesJani Nikula
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-19drm: i915: Port to new backlight interface selection APIHans de Goede
This results in a nice cleanup, as we can replace the complicated logic from should_ignore_backlight_request() with a simple check for the type being native. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-27drm/i915: Remove DRIVER_MODESET checks from modeset codeDaniel Vetter
Mostly just checks in i915-private modeset ioctls. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-30ACPI / i915: Update the condition to ignore firmware backlight change requestAaron Lu
Some of the Thinkpads' firmware will issue a backlight change request through i915 operation region unconditionally on AC plug/unplug, the backlight level used is arbitrary and thus should be ignored. This is handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change). Then there is a Dell laptop whose vendor backlight interface also makes use of operation region to change backlight level and with the above commit, that interface no long works. The condition used to ignore the backlight change request from firmware is thus changed to: if the vendor backlight interface is not in use and the ACPI backlight interface is broken, we ignore the requests; oterwise, we keep processing them. Fixes: 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change) Link: https://lkml.org/lkml/2014/9/23/854 Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-05Merge tag 'v3.16' into drm-nextDave Airlie
Linux 3.16 backmerge requested by i915, nouveau and radeon authors Conflicts: drivers/gpu/drm/i915/i915_gem_render_state.c drivers/gpu/drm/i915/intel_drv.h
2014-07-29Merge remote-tracking branch 'airlied/drm-next' into drm-intel-nextDaniel Vetter
Pull in drm-next with Dave's DP MST support so that I can merge some conflicting patches which also touch the driver load sequencing around interrupt handling. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-23drm/i915: respect the VBT minimum backlight brightnessJani Nikula
Historically we've exposed the full backlight PWM duty cycle range to the userspace, in the name of "mechanism, not policy". However, it turns out there are both panels and board designs where there is a minimum duty cycle that is required for proper operation. The minimum duty cycle is available in the VBT. The backlight class sysfs interface does not make any promises to the userspace about the physical meaning of the range 0..max_brightness. Specifically there is no guarantee that 0 means off; indeed for acpi_backlight 0 usually is not off, but the minimum acceptable value. Respect the minimum backlight, and expose the range acceptable to the hardware as 0..max_brightness to the userspace via the backlight class device; 0 means the minimum acceptable enabled value. To switch off the backlight, the user must disable the encoder. As a side effect, make the backlight class device max brightness and physical PWM modulation frequency (i.e. max duty cycle) independent. This allows a follow-up patch to virtualize the max value exposed to the userspace. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: s/BUG_ON/WARN_ON/] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-22drm/i915: add DP 1.2 MST support (v0.7)Dave Airlie
This adds DP 1.2 MST support on Haswell systems. Notes: a) this reworks irq handling for DP MST ports, so that we can avoid the mode config locking in the current hpd handlers, as we need to process up/down msgs at a better time. Changes since v0.1: use PORT_PCH_HOTPLUG to detect short vs long pulses add a workqueue to deal with digital events as they can get blocked on the main workqueue beyong mode_config mutex fix a bunch of modeset checker warnings acks irqs in the driver cleanup the MST encoders Changes since v0.2: check irq status again in work handler move around bring up and tear down to fix DPMS on/off use path properties. Changes since v0.3: updates for mst apis more state checker fixes irq handling improvements fbcon handling support improved reference counting of link - fixes redocking. Changes since v0.4: handle gpu reset hpd reinit without oopsing check link status on HPD irqs fix suspend/resume Changes since v0.5: use proper functions to get max link/lane counts fix another checker backtrace - due to connectors disappearing. set output type in more places fro, unknown->displayport don't talk to devices if no HPD asserted check mst on short irqs only check link status properly rebase onto prepping irq changes. drop unsued force_act Changes since v0.6: cleanup unused struct entry. [airlied: fix some sparse warnings]. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-07-07ACPI / i915: ignore firmware requests for backlight changeAaron Lu
Some Thinkpad laptops' firmware will initiate a backlight level change request through operation region on the events of AC plug/unplug, but since we are not using firmware's interface to do the backlight setting on these affected laptops, we do not want the firmware to use some arbitrary value from its ASL variable to set the backlight level on AC plug/unplug either. Link: https://bugzilla.kernel.org/show_bug.cgi?id=76491 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77091 Reported-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com> Reported-and-tested-by: Anton Gubarkov <anton.gubarkov@gmail.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-05drm: convert crtc and connection_mutex to ww_mutex (v5)Rob Clark
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>
2014-06-04drm: Split connection_mutex out of mode_config.mutex (v3)Daniel Vetter
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>
2014-02-11Merge tag 'drm-intel-fixes-2014-02-06' of ↵Dave Airlie
ssh://git.freedesktop.org/git/drm-intel into drm-next Just minor stuff really, on vlv dp fix and two patches to tune down some opregion sanity check. Plus MAINTAINERS update for the new git repo, which is the only reason I've really bothered with this pull request. * tag 'drm-intel-fixes-2014-02-06' of ssh://git.freedesktop.org/git/drm-intel: drm/i915: demote opregion excessive timeout WARN_ONCE to DRM_INFO_ONCE drm: add DRM_INFO_ONCE() to print a one-time DRM_INFO() message MAINTAINERS: Update drm/i915 git repo drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup
2014-02-04drm/i915: demote opregion excessive timeout WARN_ONCE to DRM_INFO_ONCEJani Nikula
The WARN_ONCE is a bit too verbose, make it a DRM_INFO_ONCE. While at it, add a #define for MAX_DSLP and make the message a bit more informative. v2: use DRM_INFO_ONCE, add MAX_DSLP, pimp the message. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-29Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm updates from Dave Airlie: "Been a bit busy, first week of kids school, and waiting on other trees to go in before I could send this, so its a bit later than I'd normally like. Highlights: - core: timestamp fixes, lots of misc cleanups - new drivers: bochs virtual vga - vmwgfx: major overhaul for their nextgen virt gpu. - i915: runtime D3 on HSW, watermark fixes, power well work, fbc fixes, bdw is no longer prelim. - nouveau: gk110/208 acceleration, more pm groundwork, old overlay support - radeon: dpm rework and clockgating for CIK, pci config reset, big endian fixes - tegra: panel support and DSI support, build as module, prime. - armada, omap, gma500, rcar, exynos, mgag200, cirrus, ast: fixes - msm: hdmi support for mdp5" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (595 commits) drm/nouveau: resume display if any later suspend bits fail drm/nouveau: fix lock unbalance in nouveau_crtc_page_flip drm/nouveau: implement hooks for needed for drm vblank timestamping support drm/nouveau/disp: add a method to fetch info needed by drm vblank timestamping drm/nv50: fill in crtc mode struct members from crtc_mode_fixup drm/radeon/dce8: workaround for atom BlankCrtc table drm/radeon/DCE4+: clear bios scratch dpms bit (v2) drm/radeon: set si_notify_smc_display_change properly drm/radeon: fix DAC interrupt handling on DCE5+ drm/radeon: clean up active vram sizing drm/radeon: skip async dma init on r6xx drm/radeon/runpm: don't runtime suspend non-PX cards drm/radeon: add ring to fence trace functions drm/radeon: add missing trace point drm/radeon: fix VMID use tracking drm: ast,cirrus,mgag200: use drm_can_sleep drm/gma500: Lock struct_mutex around cursor updates drm/i915: Fix the offset issue for the stolen GEM objects DRM: armada: fix missing DRM_KMS_FB_HELPER select drm/i915: Decouple GPU error reporting from ring initialisation ...
2014-01-22drm/i915: Eliminate lots of WARNs when there's no backlight presentVille Syrjälä
My 855gm doesn't register the intel backlight but it still ends up calling the backlight code to enable/disable the backlight via the LVDS code. This leads to some WARNs due to backlight.max being 0. Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight() check whether there's a backlight present or not. Also move the backlight.present check from asle_set_backlight() into intel_panel_set_backlight() for some extra symmetry. 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-12-09Merge tag 'v3.13-rc3' into drm-intel-next-queuedDaniel Vetter
Linux 3.13-rc3 I need a backmerge for two reasons: - For merging the ppgtt patches from Ben I need to pull in the bdw support. - We now have duplicated calls to intel_uncore_forcewake_reset in the setup code to due 2 different patches merged into -next and 3.13. The conflict is silen so I need the merge to be able to apply Deepak's fixup patch. Conflicts: drivers/gpu/drm/i915/intel_display.c Trivial conflict, it doesn't even show up in the merge diff. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07ACPI / i915: Fix incorrect <acpi/acpi.h> inclusions via <linux/acpi_io.h>Lv Zheng
To avoid build problems and breaking dependencies between ACPI header files, <acpi/acpi.h> should not be included directly by code outside of the ACPI core subsystem. However, that is possible if <linux/acpi_io.h> is included, because that file contains a direct inclusion of <acpi/acpi.h>. For this reason, remove the direct <acpi/acpi.h> inclusion from <linux/acpi_io.h>, move that file from include/linux/ to include/acpi/ and make <linux/acpi.h> include it for CONFIG_ACPI set along with the other ACPI header files. Accordingly, Remove the inclusions of <linux/acpi_io.h> from everywhere. Of course, that causes the contents of the new <acpi/acpi_io.h> file to be available for CONFIG_ACPI set only, so intel_opregion.o that depends on it should also depend on CONFIG_ACPI (and it really should not be compiled for CONFIG_ACPI unset anyway). References: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit (git 2.34.1) at 2024-06-15 15:41:44 +0000