- 25 Jan, 2019 28 commits
-
-
Ville Syrjälä authored
To make vblank timestamps work better with the TV encoder let's scale the pipe timings such that the relationship between the TV active and TV blanking periods is mirrored in the corresponding pipe timings. Note that in reality the pipe runs at a faster speed during the TV vblank, and correspondigly there are periods when the pipe is enitrely stopped. We pretend that this isn't the case and as such we incur some error in the vblank timestamps during the TV vblank. Further explanation of the issues in a big comment in the code. This makes the vblank timestamps good enough to make i965gm (which doesn't have a working frame counter with the TV encoder) report correct frame numbers. Previously you could get all kinds of nonsense which resulted in eg. glxgears reporting that it's running at twice the actual framerate in most cases. v2: s/IS_GEN4(dev_priv)/IS_GEN(dev_priv, 4)/ in the comment for consistency Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-15-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Add the missing 1080p TV modes. On gen4 all of them work just fine, whereas on gen3 only the 30Hz mode actually works correctly. v2: s/IS_GEN3(dev_priv)/IS_GEN(dev_priv, 3)/ Signed-off-by:
-
Ville Syrjälä authored
Remove the silly reported_modes[] array. I suppse once upon a time this actually had something to do with modes we reported to userspace. Now it is just the placeholder for the mode we use for load detection. We don't need it even for that, and instead we can just rely on the fallback mode in intel_get_load_detect_pipe(). Signed-off-by:
-
Ville Syrjälä authored
The current code insists on picking a new TV mode when switching between component and non-component cables. That's super annoying. Let's just keep the current TV mode unless the new cable type actually disagrees with it. Signed-off-by:
-
Ville Syrjälä authored
No point in storing the mode names in the array. drm_mode_set_name() will give us the same names without wasting space for these string constants. Signed-off-by:
-
Ville Syrjälä authored
Rewrite the preferred mode selection to just check whether the TV modes is HD or SD. For SD TV modes we favor 480 line modes, for 720p we prefer 720 line modes, and for 1080i/p we prefer 1080 line modes. Signed-off-by:
-
Ville Syrjälä authored
Just assign the margin values directly to xpos/ypos instead of first initializing to zero and then adding the values. Signed-off-by:
-
Ville Syrjälä authored
'component_only' is a bool. Initialize it like a bool. Signed-off-by:
-
Ville Syrjälä authored
Store the oversampling factor as a number in the TV modes. We shall want to arithmetic with this which is easier if it's a number we can use directly. Signed-off-by:
-
Ville Syrjälä authored
The oversample clock is always supposed to be either 108 MHz or 148.5 MHz. Make it so. Signed-off-by:
-
Ville Syrjälä authored
Fix the calculation of the vertical active period for interlaced TV modes. Signed-off-by:
-
Ville Syrjälä authored
On i965gm the hardware frame counter does not work when the TV encoder is active. So let's not try to consult the hardware frame counter in that case. Instead we'll fall back to the timestamp based guesstimation method used on gen2. Note that the pipe timings generated by the TV encoder are also rather peculiar. Apparently the pipe wants to run at a much higher speed (related to the oversample clock somehow it seems) but during the vertical active period the TV encoder stalls the pipe every few lines to keep its speed in check. But once the vertical blanking period is reached the pipe gets to run at full speed. This means our vblank timestamp estimates are suspect. Fixing all that would require quite a bit more work. This simple fix at least avoids the nasty vblank timeouts that are happening currently. Curiously the frame counter works just fine on i945gm and gm45. I don't really understand what kind of mishap occurred with the hardware design on i965gm. Sadly I wasn't able to find any chicken bits etc. that would fix the frame counter :( v2: Move the zero vs. non-zero hw counter value handling into i915_get_vblank_counter() (Daniel) Use the per-crtc maximum exclusively, leaving the per-device maximum at zero v3: max_vblank_count not populated yet in intel_enable_pipe() use intel_crtc_max_vblank_count() instead Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Fixes: 51e31d49 ("drm/i915: Use generic vblank wait") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93782Signed-off-by: -
Chris Wilson authored
Always perform the requested reset, even if we believe the engine is idle. Presumably there was a reason the caller wanted the reset, and in the near future we lose the easy tracking for whether the engine is idle. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged() as a reminder that it must be callable without struct_mutex held. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Now that the submission backends are controlled via their own spinlocks, with a wave of a magic wand we can lift the struct_mutex requirement around GPU reset. That is we allow the submission frontend (userspace) to keep on submitting while we process the GPU reset as we can suspend the backend independently. The major change is around the backoff/handoff strategy for performing the reset. With no mutex deadlock, we no longer have to coordinate with any waiter, and just perform the reset immediately. Testcase: igt/gem_mmap_gtt/hang # regresses Signed-off-by:
-
Chris Wilson authored
The guc (and huc) currently inexcruitably depend on struct_mutex for device reinitialisation from inside the reset, and indeed taking any mutex here is verboten (as we must be able to reset from underneath any of our mutexes). That makes recovering the guc unviable without, for example, reserving contiguous vma space and pages for it to use. The plan to re-enable global reset for the GuC centres around reusing the WOPM reserved space at the top of the aperture (that we know we can populate a contiguous range large enough to dma xfer the fw image). In the meantime, hopefully no one even notices as the device-reset is only used as a backup to the per-engine resets for handling GPU hangs. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Chris Wilson authored
In preparation for the next few commits, make resetting the GPU atomic. Currently, we have prepared gen6+ for atomic resetting of individual engines, but now there is a requirement to perform the whole device level reset (just the register poking) from inside an atomic context. Signed-off-by:
-
Chris Wilson authored
Simplify by using sizeof(u32) to convert from the index inside the HWSP to the byte offset. This has the advantage of not only being shorter (and so not upsetting checkpatch!) but that it matches use where we are writing to byte addresses using other commands than MI_STORE_DWORD_IMM. v2: Drop the now superfluous MI_STORE_DWORD_INDEX_SHIFT, it appears to be a local invention so keeping it after the final use does not help to clarify the GPU instruction. Signed-off-by:
-
Chris Wilson authored
Now that we know we measure the size of the engine->emit_breadcrumb() correctly, we can remove the previous manual counting. Signed-off-by:
-
Chris Wilson authored
Instead of tediously and fragilely counting up the number of dwords required to emit the breadcrumb to seal a request, fake a request and measure it automatically once during engine setup. The downside is that this requires a fair amount of mocking to create a proper breadcrumb. Still, should be less error prone in future as the breadcrumb size fluctuates! Signed-off-by:
-
Tvrtko Ursulin authored
Configuring RPCS in context image just before pin is sufficient and will come extra handy in one of the following patches. v2: * Split image setup a bit differently. (Chris Wilson) v3: * Update context image after reset as well - otherwise the application of pinned default state clears the RPCS. v4: * Use local variable throughout the function. (Chris Wilson) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125023005.1007-1-chris@chris-wilson.co.uk
-
Tomasz Lis authored
The table has been unified across OSes to minimize virtualization overhead. The MOCS table is now published as part of bspec, and versioned. Entries are supposed to never be modified, but new ones can be added. Adding entries increases table version. The patch includes version 1 entries. Meaning of each entry is now explained in bspec, and user mode clients are expected to know what each entry means. The 3 entries used for previous platforms are still compatible with their legacy definitions, but that is not guaranteed to be true for future platforms. v2: Fixed SCC values, improved commit comment (Daniele) v3: Improved MOCS table comment (Daniele) v4: Moved new entries below gen9 ones. Put common entries into definition to be used in multiple arrays. (Lucas) v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas) v6: Removed definitions of reserved entries. (Michal) Increased limit of entries sent to the hardware on gen11+. v7: Simplify table as done for previou gens (Lucas) v8: Rebase on cached number of entries per-platform and use new MOCS_ENTRY() macro (Lucas) v9: Update comment (from Tomasz) BSpec: 34007 BSpec: 560 Signed-off-by:Tomasz Lis <tomasz.lis@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-8-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Instead of checking the gen number every time we need to know the max number of entries, just save it into the table struct so we don't need extra branches throughout the code. This will be useful for Ice Lake that has 64 rather than 62 defined entries. Ice Lake changes will be added in a follow up. v2: make size and n_entries `unsigned int` and introduce changes as a pre-work for the Ice Lake changes (Tvrtko) Suggested-by: -
Lucas De Marchi authored
Instead of considering we have defined entries for any index in the table, let's keep track of the ones we explicitly defined. This will allow Gen 11 to have it's new table defined in which we have holes of undefined entries. Repeated comments about the meaning of undefined entries were removed since they are overly verbose and copy-pasted in several functions: now the definition is in the top only. v2: add helper function to get the index (from Chris) Signed-off-by:
-
Lucas De Marchi authored
Let's use a macro to make tables smaller and at the same time allow us to add fields that apply to all entries in future. v2: rewrap lines to respect 80 chars limit and make it more readable (from Chris) Signed-off-by: -
Tomasz Lis authored
The MOCS tables are going to be very similar across platforms. To reduce the amount of copied code, this patch rips the common part and puts it into a definition valid for all gen9 platforms. v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE to MOCS_ENTRIES. (Joonas) v3 (Lucas): - Fix indentation - Rebase on rework done by additional patch - Remove define for or-ing flags as it made the table more complex by requiring zeroed values to be passed - Do not embed comma in the macro, so to treat that just as another item and please source code formatting tools Signed-off-by: -
Lucas De Marchi authored
Make the defines for LE and L3 caching options to contain the shifts and remove the zeros from the tables as shifting zeros always result in zero. Starting from Ice Lake the MOCS table is defined in the spec and contains all entries. So to simplify checking the table with the values set in code, the value is now part of the macro name. This allows to still give the most used option and sensible name, but also to easily cross check the table from the spec for gen >= 11. By removing the zeros we avoid maintaining a huge table since the one from spec contains many more entries. The new table for Ice Lake will be added by other patches, this only reformats the table. While at it also fix the indentation. Signed-off-by:
-
Lucas De Marchi authored
Instead of initializing them to uncached, let's set them to PTE for kernel tracking. While at it do some minor adjustments to comments and coding style. From Chris: "What it does mean is that the buffer contents are consistent with our cache tracking; and for userspace the results were always undefined. So we should at least be able to guarantee that the data written by userspace from the CPU is visible. After that, your caches are on your own". Signed-off-by:
-
- 24 Jan, 2019 12 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <vivijim@rdvivi-cozumel.jf.intel.com>
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2019-01-24 - split kvmgt as seperate module (Zhenyu) - Coffeelake GVT support (Fred) - const treatment and change for kernel type (Jani) Signed-off-by:
-
Maarten Lankhorst authored
This way we don't accidentally double allocate it. Noticed this when I wrote a patch to sanity check all of the scaler state. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108160842.13396-4-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
Now that our state comparison functions are pretty complete, we should enable fastset by default when a modeset can be avoided. Even if we're not completely certain about the inherited state, we can be certain after the first modeset that our sw state matches the hw state. There is one testcase explicitly testing fastset, kms_panel_fitting.atomic-fastset but other testcases do so indirectly because most tests don't clean up the display during exit, or otherwise indirectly preserve mode by doing igt_display_reset or inheriting during init. Signed-off-by:
-
Maarten Lankhorst authored
On lynxpoint the bios sometimes sets up the backlight using the CPU display, but the driver expects using the PWM PCH override register. Read the value from the CPU register, then convert it to the other units by converting from the old duty cycle, to freq, to the new units. This value is then programmed in the override register, after which we set the override and disable the CPU display control. This allows us to switch the source without flickering, and make the backlight controls work in the driver. Changes since v1: - Read BLC_PWM_CPU_CTL2 to cpu_ctl2. - Clean up cpu_mode if slightly. - Always disable BLM_PWM_ENABLE in cpu_ctl2. Changes since v2: - Simplify cpu_mode handling (Jani) Signed-off-by:
Tolga Cakir <cevelnet@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108160842.13396-2-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
Restore our saved values for backlight. This way even with fastset on S4 resume we will correctly restore the backlight to the active values. Changes since v1: - Call enable_backlight() when backlight.level is set. On suspend backlight.enabled is always cleared, this makes it not a good indicator. Also check for crtc->state->active. Changes since v2: - Use the new update_pipe() callback to run this on resume as well. Signed-off-by:
-
Chris Wilson authored
Nip some inline spaghetti in the bud before the problem gets too bad. Signed-off-by:
-
Jani Nikula authored
The VBT int_crt_support can't be trusted on earlier platforms, and is always set to true in intel_bios.c for pre-DDI and pre-VLV platforms. We can simplify the output setup by unconditionally calling intel_crt_init() for these platforms. Suggested-by:
-
Jani Nikula authored
Gen 2 mobile and not I830 is, in fact, I85X. Simplify. Suggested-by:
-
Jani Nikula authored
Clarify that the name is specific to ILK+ PCH platforms. v2: prefix the name with ilk rather than pch (Ville) Reviewed-by:
-
Jani Nikula authored
With most platforms not having TV support, only call intel_tv_init() on platforms that might actually have TV, specifically gens 3 and 4. This puts intel_tv_init() more in line with the rest of the outputs, and makes it slightly easier for the uninitiated to figure out which platforms actually have what. Reviewed-by:
-
Jani Nikula authored
Now that intel_lvds_init() is only called for platforms that might have LVDS, move the remaining checks to intel_setup_outputs(), again similar to other outputs, and remove the overlapping checks. Reviewed-by:
-
