- 10 Sep, 2015 3 commits
-
-
Maarten Lankhorst authored
Legacy state might not be updated any more. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
Signed-off-by:
-
Shashank Sharma authored
This patch adds the intel_connector initialized to intel_hdmi display, during the init phase, just like the other encoders do. This attachment is very useful when we need to extract the connector pointer during the hotplug handler function Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 07 Sep, 2015 4 commits
-
-
Jani Nikula authored
Fall back to VBT based backlight modulation frequency if it's not set. Do not hard code. This could be a problem if there is no VBT. Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Reviewed-by:
-
Jani Nikula authored
Normally we determine the backlight PWM modulation frequency (which we also use as backlight max value) from the backlight registers at module load time, expecting the registers have been initialized by the BIOS. If this is not the case, we fail. The VBT contains the backlight modulation frequency in Hz. Add platform specific functions to convert the frequency in Hz to backlight PWM modulation frequency, and use them to initialize the backlight when the registers are not initialized by the BIOS. v2: Fix SPT and VLV. Thanks to Clint for the VLV code. Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Jani Nikula authored
Currently the difference between backlight control on HSW vs. BDW/SKL is that on HSW we modify the duty cycle on the CPU register, and have the hardware pass the changes on to the PCH registers. We still drive the PCH PWM on both. While HSW and BDW use the same LPT PCH, BDW does not pass these messages on to the PCH. Therefore on BDW we need to enable the PCH override bit, and program the PCH directly. (On SPT PCH, this mode is the default.) We could as well do this on HSW too, and in fact I've been told this is what a certain other operating system does. So use PCH backlight override on HSW too. This simplifies some follow-up code, but it does have the danger of breaking backlight on HSW machines. It should work, but mysterious are the ways of backlight. While at it, name the related backlight hooks according to the PCH rather than the CPU for clarity. Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Nick Hoath authored
Add stepping check for A0 workarounds, and remove the associated FIXME tags. Split out unrelated WAs for later condition checking. v2: Fixed format (PeterL) v3: Corrected stepping check for WaDisableSDEUnitClockGating - Ignoring comment, following hardware spec instead. (ChrisH) Added description for TILECTL setting (JonB) Cc: Peter Lawthers <peter.lawthers@intel.com> Cc: Chris Harris <chris.harris@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by:Nick Hoath <nicholas.hoath@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
- 04 Sep, 2015 14 commits
-
-
Chris Wilson authored
Fixes regression from commit f1afe24f Author: Arun Siluvery <arun.siluvery@linux.intel.com> Date: Tue Aug 4 16:22:20 2015 +0100 drm/i915: Change SRM, LRM instructions to use correct length which forgot to account for the length bias when declaring the fixed length. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91844Reported-by:
Andreas Reis <andreas.reis@gmail.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
The pfit state is stored as register values, so dump them as hex instead of decimal to make some sense of the error messages. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
These registers exist only before GEN5, so currently we may access undefined registers on VLV/CHV and BXT. Apply the workaround only pre GEN5. Since the workaround is relevant only when LVDS is present, for clarity apply it only if this is the case. This triggered an unclaimed register access warning on BXT. v2: (Ville) - move the workaround to the LVDS init code - print a debug note about the workaround Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
This register exists only pre GEN5, but atm we also access it on VLV/BXT/CHV. Prevent accessing it on these latter platforms. Signed-off-by:
-
Chris Wilson authored
A small, very small, step to sharing the duplicate code between execlists and legacy submission engines, starting with the ringbuffer allocation code. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Jani Nikula authored
Reviewed-by:
-
Jani Nikula authored
TPS3 is mandatory for downstream devices that support HBR2, and Intel platforms that support HBR2 also support TPS3. Whenever TPS3 is supported by both the source and sink, it should be used. In other words, whenever the source and sink are capable of 5.4 Gbps link, we should anyway go for TPS3, regardless of the link rate being selected. Log an error if the sink has advertized HBR2 capability without TPS3 capability. Reviewed-by:
-
Jani Nikula authored
There is no need to have a separate flag for tps3 as the information is only used at one location. Move the logic there to make it easier to follow. Reviewed-by:
-
Rodrigo Vivi authored
This is another case where we can consider the default is the newest available and not actually a missed case. No functional change. Signed-off-by:
-
Rodrigo Vivi authored
Unless future specs tells otherwise we can assume future gens inherit some stuff from the previous so let's handle missed cases when we know tehy should't be there and assume default equals newest one. No functional changes. v2: Remove useless case as pointed out by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
These functions are already being called for gen >= 9, so let's be sure when this happens we use whatever is there already for the latest platform. No functional change. Signed-off-by:
-
Michał Winiarski authored
On each call to gen8_alloc_va_range_3lvl we're allocating temporary bitmaps needed for error handling. Unfortunately, when we increase address space size (48b ppgtt) we do additional (512 - 4) calls to kcalloc, increasing latency between exec and actual start of execution on the GPU. Let's just do a single kcalloc, we can also drop the size from free_gen8_temp_bitmaps since it's no longer used. v2: Use GFP_TEMPORARY to make the allocations reclaimable. v3: Drop the 2D array, just allocate a single block. v4: Rebase to handle gen8_preallocate_top_level_pdps. v5: Align misaligned bracket. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Kumar, Mahesh authored
GEN >= 9 supports YUV format for all planes, but it's not exported in Capability list of primary plane. Add YUV formats in skl_primary_formats list. Testcase: igt/kms_universal_plane.c Signed-off-by:
Kumar, Mahesh <mahesh1.kumar@intel.com> Cc: Konduru, Chandra <chandra.konduru@intel.com> Reviewed-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
-
Kumar, Mahesh authored
Don't rely on fb->bits_per_pixel as intel_framebuffer_init is not filling bits_per_pixel field of fb-struct for YUV pixel format. This leads to divide by zero error during watermark calculation. Signed-off-by:
-
- 02 Sep, 2015 19 commits
-
-
Ville Syrjälä authored
On GMCH plaforms we are now getting the following spew on aux interrupts: [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 Prevent it by not calling intel_get_hpd_pins() unless one of the HPD interrupt bits are actually set. I already fixed similar annoyance once with 4bca26d0 drm/i915: Use HOTPLUG_INT_STATUS_G4X on VLV/CHV but another source for it got added in fd63e2a9 drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins due to pch_get_hpd_pins() being chosen over i9xx_get_hpd_pins() to serve as the new unified piece of code. pch_get_hpd_pins() had the debug print, and i9xx_get_hpd_pins() didn't. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Rewrite the BXT hpd setup to match the way we do it on other platforms: - Throw out BXT_HOTPLUG_CTL since it's the same as PCH_PORT_HOTPLUG - Enable the HPD bits in the DE port IER in gen8_de_irq_postinstall() - Update DE port IMR using bdw_update_port_irq() Also throw out port D from bxt_port_hotplug_long_detect() since BXT only goes up to C. Signed-off-by:
-
Ville Syrjälä authored
A lot of the hpd irq handling is duplicated code, so refactor it a bit by observing that in several places the only difference is the hpd[] array. So pull the code to a few functions and pass in the hpd[] array from the caller. Another option would be to determine the correct array to use within the functions themselves, but somehow passing it in felt nicer. Further code reduction could be achieved by passing in the hotplug register offset, and the long pulse detection function pointer. But that didn't feel as good for some reason, so I left it at the middle ground. Signed-off-by:
-
Ville Syrjälä authored
bxt_hpd_handler() looks different to everyone else for no good reason. Rewrite it to use the standard variable namees etc. Signed-off-by:
-
Ville Syrjälä authored
Runtime suspends disabled all interrupts, so in order to get them back fully we need to also do the HPD irq setup on runtime resume. Except on VLV/CHV where the display interrupt initialization is part of the display power well powerup. Reviewed-by:
-
Ville Syrjälä authored
On SKL the port A HPD has moved to the PCH. Hook it up. Reviewed-by:
-
Ville Syrjälä authored
Wire up the port A HPD for BDW. Compared to earlier platforms the interrupt setup is a bit different, but basically everything else looks the same. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Check for BDW before processing the HPD to not break BXT Set found=true when processing port A HPD Sort out the mess I made of the irq setup in v1 Warn about bad irq mask vs. enable bits in bdw_update_port_irq() (Paulo) Signed-off-by: -
Ville Syrjälä authored
If the CPU and PCH are on the same package we must enabled the port A HPD also in the south hotplug register. To identify the package type we simply look at the PCH type: LPT-H means separate package, and LPT-LP means multi chip package (MCP). v2: Add comment and pimp commit message Reviewed-by:
-
Ville Syrjälä authored
As with ILK/SNB wire up the port A HPD on IVB/HSW. This might be more important on HSW with PSR. BSpec tells us that if the automagic link training performed by the hardware fails for some reason, we're going to get a short HPD and are supposed to re-train the link manyally. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Add a comment about the pulse duration bits being reserved on HSW+ like we have for LPT+ in ibx_hpd_irq_setup() Reviewed-by: -
Ville Syrjälä authored
ILK/SNB support port A HPD. While HPD is optional on eDP let's at least try to wite it up so that we might notice if the link has issues. The eDP spec suggests that if HPD is not wired up, one should poll the link status instead. We don't even do that currently. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Reviewed-by:
-
Ville Syrjälä authored
Starting from SPT the only interrupts living in the south are GMBUS and HPD. What's worse some of the SPT specific new bits conflict with some other bits on earlier PCH generations. So better not use the cpt_irq_handler() for SPT+ anymore. Also kill the hand rolled port E handling with something more standardish. This also avoids accidentally confusing port B and port E long pulses since the bits occupy the same positions, just in different registers. Also add a comment noting that the short pulse duration bits are reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the MBZ in the spec. v2: Call intel_hpd_irq_handler() only once (Paulo) Signed-off-by:
-
Ville Syrjälä authored
Move the 0 initialization of pin_mask and long_mask from intel_get_hpd_pins() into each caller. This we we can call intel_get_hpd_pins() multiple times to accumulate more pins from several sources. v2: Add a comment explaining the dangers of intel_get_hpd_pins() (Paulo) Reviewed-by:
-
Ville Syrjälä authored
The PORTA HPD defines are not BXT specific. They also exist on SPT, and partially already on LPT:LP. Reviewed-by:
-
Ville Syrjälä authored
Make LPT:LP checks look neater by wrapping the details in a new HAS_PCH_LPT_LP() macro. Reviewed-by:
-
Ville Syrjälä authored
Extract the core of ironlake_{enable,disable}_display_irq() into a new function. We'll have further use for it later. v2: Warn about invalid mask vs. enable bits (Paulo) Reviewed-by: -
Ville Syrjälä authored
Eliminate a bunch of duplicated code that calculates the currently enabled HPD interrupt bits. v2: s/;/:/ in patch subject (Paulo) Reviewed-by:
-
Ville Syrjälä authored
Indent the PORTx_HOTPLUG_... defines appropriately, and fix some space vs. tab issues. v2: Document pre-HSW/LPT bits, and order another tab (Paulo) Reviewed-by:
-
Daniel Vetter authored
Forgot to do that in commit d328c9d7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 10 16:22:37 2015 +0200 drm/i915: Select starting pipe bpp irrespective or the primary plane and it's confusing. Fix it. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Backmerge -fixes since there's more DDI-E related cleanups on top of the pile of -fixes for skl that just landed for 4.3. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i914/intel_dp.c drivers/gpu/drm/i915/intel_lrc.c Conflicts are all fairly harmless adjacent line stuff. Signed-off-by:
-
