- 12 Oct, 2018 1 commit
-
-
Jyoti Yadav authored
DC5 and DC6 counter register tells about residency of DC5 and DC6. Added the same in debugfs file. v2 : Remove csr_version check. Added generic check regarding DC counters for Gen9 onwards. (Rodrigo) v3 : Simplified gen checks. (Chris) v4 : Simplified "if" ladder for multiple gens. v5 : Removed unnecessary comment. Signed-off-by:Jyoti Yadav <jyoti.r.yadav@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 11 Oct, 2018 10 commits
-
-
Paulo Zanoni authored
This message is currently marked as DRM_DEBUG_ATOMIC. I would like it to be DRM_DEBUG_KMS since it is more KMS than atomic, and this will also make the message appear in the CI logs, which may or may not help us with some FIFO underrun bugs. Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004231600.14101-7-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
We were writing to PLANE_BUF_CFG(pipe, plane_id) twice for every platform, and we were even using different values on the gen10- planar case. The first write is useless since it just gets replaced with the next one, so kill it. There's a lot to improve in the DDB code, but let's start by avoiding the double write. Reviewed-by:
-
Paulo Zanoni authored
The transition watermarks ask for Selected Result Blocks (the real value), not Result Blocks (the integer value). Given how ceilings are applied in both the non-transition and the transition watermarks calculations, we can get away with assuming that Selected Result Blocks is actually Result Blocks minus 1 without any rounding errors. Reviewed-by:
-
Paulo Zanoni authored
On these platforms we're supposed to unconditonally pick the method 2 result instead of the minimum. Reviewed-by:
-
Paulo Zanoni authored
The transition minimum is 14 blocks for gens 9 and 10, and 4 blocks for gen 11. This minimum value is supposed to be added to the configurable trans_amount. This matches both BSpec and additional information provided by our HW engineers. Reviewed-by:
-
Paulo Zanoni authored
Function intel_framebuffer_init() checks for the possibilities during framebuffer creation (addfb ioctl time). It is missing the fact that the indexed format is not supported with Yf tiling. It is worth noticing that skl_plane_format_mod_supported() correctly handles for the C8/Yf combination, but this function runs during modeset time, so we only reject the combination later. Ville recently proposed a new IGT test that only uses addfb to assert supported formats, so that IGT was failing. Add the check so we get green squares right from the start after Ville merges his test. Also drive-by fix the missing /* fall through */ in the chunk we modified by just turning it into a "break;" since IMHO breaks are easier to read than fall-throughs. BSpec: 18565 Testcase: igt/kms_addfb_basic/expected-formats (not merged yet) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We need extra load failure point to better test error path in i915_driver_init_mmio. Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michal Wajdeczko authored
In case of the error we missed to call i915_mmio_cleanup that matches earlier call to i915_mmio_setup. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
This new AML PCI ID uses the same gen graphics as Coffe Lake not a Kaby Lake one like the other AMLs. So to make it more explicit renaming INTEL_AML_GT2_IDS to INTEL_AML_KBL_GT2_IDS and naming this id as INTEL_AML_CFL_GT2_IDS. v2: - missed add new AML macro to INTEL_CFL_IDS() - added derivated platform initials to AML macros Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Chris Wilson authored
For mmap-exhaustion, we deliberately put the system under a large amount of pressure to ensure that we are able to reap mmap-offsets from dead objects. If background activity does that reaping for us, that defeats the purpose of the test and in some cases will fail our sanity checks (because of the fake activity we use to prevent the idle worker). Fixes: 932cac10 ("drm/i915/selftests: Prevent background reaping of acti ve objects") Signed-off-by:
-
- 10 Oct, 2018 7 commits
-
-
Lyude Paul authored
As mentioned in the previous commit, we currently prevent new modesets on recently-removed MST connectors by returning no encoder from our ->best_encoder() callback once the MST port has disappeared. This is wrong however, because it prevents legacy modesetting users from being able to disable CRTCs on MST connectors after the connector's respective topology has disappeared. So, fix this by instead by just always returning a valid encoder. Changes since v2: - Remove usage of atomic MST helper for now, since that got replaced with a much simpler solution Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-3-lyude@redhat.com
-
Lyude Paul authored
It appears when testing my previous fix for some of the legacy modesetting issues with MST, I misattributed some kernel splats that started appearing on my machine after a rebase as being from upstream. But it appears they actually came from my patch series: [ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1] [ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered [ 2.980516] ------------[ cut here ]------------ [ 2.980519] Could not determine valid watermarks for inherited state [ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd [ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1 [ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016 [ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00 [ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282 [ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006 [ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0 [ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065 [ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000 [ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800 [ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000 [ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0 [ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.980645] Call Trace: [ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915] [ 2.980681] ? kernfs_add_one+0xe7/0x130 [ 2.980709] i915_pci_probe+0x46/0x60 [i915] [ 2.980715] pci_device_probe+0xd4/0x150 [ 2.980719] really_probe+0x243/0x3b0 [ 2.980722] driver_probe_device+0xba/0x100 [ 2.980726] __driver_attach+0xe4/0x110 [ 2.980729] ? driver_probe_device+0x100/0x100 [ 2.980733] bus_for_each_dev+0x74/0xb0 [ 2.980736] driver_attach+0x1e/0x20 [ 2.980739] bus_add_driver+0x159/0x230 [ 2.980743] ? 0xffffffffa0393000 [ 2.980746] driver_register+0x70/0xc0 [ 2.980749] ? 0xffffffffa0393000 [ 2.980753] __pci_register_driver+0x57/0x60 [ 2.980780] i915_init+0x55/0x58 [i915] [ 2.980785] do_one_initcall+0x4a/0x1c4 [ 2.980789] ? do_init_module+0x27/0x210 [ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190 [ 2.980797] do_init_module+0x60/0x210 [ 2.980800] load_module+0x2063/0x22e0 [ 2.980804] ? vfs_read+0x116/0x140 [ 2.980807] ? vfs_read+0x116/0x140 [ 2.980811] __do_sys_finit_module+0xbd/0x120 [ 2.980814] ? __do_sys_finit_module+0xbd/0x120 [ 2.980818] __x64_sys_finit_module+0x1a/0x20 [ 2.980821] do_syscall_64+0x5a/0x110 [ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2.980826] RIP: 0033:0x7f4754e32879 [ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48 [ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879 [ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018 [ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000 [ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 [ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000 [ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980884] ---[ end trace 5eb47a76277d4731 ]--- The cause of this appears to be due to the fact that if there's pre-existing display state that was set by the BIOS when i915 loads, it will attempt to perform a modeset before the driver is registered with userspace. Since this happens before the driver's registered with userspace, it's connectors are also unregistered and thus-states which would turn on DPMS on a connector end up getting rejected since the connector isn't registered. These bugs managed to get past Intel's CI partially due to the fact it never ran a full test on my patches for some reason, but also because all of the tests unload the GPU once before running. Since this bug is only really triggered when the drivers tries to perform a modeset before it's been fully registered with userspace when coming from whatever display configuration the firmware left us with, it likely would never have been picked up by CI in the first place. After some discussion with vsyrjala, we decided the best course of action would be to just move the unregistered connector checks out of update_connector_routing() and into drm_atomic_set_crtc_for_connector(). The reason for this being that legacy modesetting isn't going to be expecting failures anywhere (at least this is the case with X), so ideally we want to ensure that any DPMS changes will still work even on unregistered connectors. Instead, we now only reject new modesets which would change the current CRTC assigned to an unregistered connector unless no new CRTC is being assigned to replace the connector's previous one. Signed-off-by:
-
Chris Wilson authored
Check we can handle a late display load failure where the final act of registering the connector fails. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181010123833.16797-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Now that we have intel_connector.c, move the connector specific functions from intel_display.c there. Fix a few checkpatch complaints while at it. No functional changes. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181010075205.7713-2-jani.nikula@intel.com
-
Jani Nikula authored
The common denominator here seems to be connector more than modes. Prepare for moving more connector functions to the same place. No functional changes. Reviewed-by:
-
Jani Nikula authored
For a while we carried lvds connector specific data in the lvds connector, but since commit 05c72e77 ("drm/i915: Nuke the LVDS lid notifier") we haven't needed it. Revert back to plain intel_connector. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
When reporting the DPCD dump through debugfs, show the errors inline where appropriate. If a read at one particular offset fails, report it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106371Signed-off-by:
-
- 09 Oct, 2018 10 commits
-
-
Manasi Navare authored
This patch fixes the original commit c0cfb10d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Tested-by:
Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by:
-
Jani Nikula authored
Almost all of the connector destroy functions do the same thing. The differences are in the edid, detect_edid and panel cleanups, but those are safely NULL when not initialized. Roll out a common connector destroy hook. Inspired by commit bc3213c4 ("drm/i915: Drop the eDP check from intel_dp_connector_destroy()"). Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by:
-
Lyude Paul authored
Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder. So, fix this by always returning a valid encoder regardless of the state of the MST port. Changes since v1: - Remove mst atomic helper, since this got replaced with a much simpler solution Signed-off-by:
-
Lyude Paul authored
Since we need to be able to allow DPMS on->off prop changes after an MST port has disappeared from the system, we need to be able to make sure we can compute a config for the resulting atomic commit. Currently this is impossible when the port has disappeared, since the VCPI slot searching we try to do in intel_dp_mst_compute_config() will fail with -EINVAL. Since the only commits we want to allow on no-longer-present MST ports are ones that shut off display hardware, we already know that no VCPI allocations are needed. So, hardcode the VCPI slot count to 0 when intel_dp_mst_compute_config() is called on an MST port that's gone. Changes since V4: - Don't use mst_port_gone at all, just check whether or not the drm connector is registered - Daniel Vetter Signed-off-by:
-
Lyude Paul authored
Currently we set intel_connector->mst_port to NULL to signify that the MST port has been removed from the system so that we can prevent further action on the port such as connector probes, mode probing, etc. However, we're going to need access to intel_connector->mst_port in order to fixup ->best_encoder() so that it can always return the correct encoder for an MST port to prevent legacy DPMS prop changes from failing. This should be safe, so instead keep intel_connector->mst_port always set and instead just check the status of drm_connector->regustered to signify whether or not the connector has disappeared from the system. Changes since v2: - Add a comment to mst_port_gone (Jani Nikula) - Change mst_port_gone to a u8 instead of a bool, per the kernel bot. Apparently bool is discouraged in structs these days Changes since v4: - Don't use mst_port_gone at all! Just check if the connector is registered or not - Daniel Vetter Signed-off-by:
-
Lyude Paul authored
With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors. Changes since v5: - Fix typo in comment, nothing else Signed-off-by:
-
Ville Syrjälä authored
As long as the connector was zeroed during allocation calling intel_panel_fini() is safe even if we haven't initialized the panel struct explicitly. So let's drop the useless eDP check from dp connector destruction. Signed-off-by:
-
Ville Syrjälä authored
Currently we destroy the backlight during connector unregistration. That means the final modeset performed by drm_atomic_helper_shutdown() will leave the backlight on. We don't want that so let's just move intel_panel_destroy_backlight() into intel_panel_fini() which gets called during connector destuction. We still unregister the user visible backlight device during connector unregistration. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Anuj Phogat authored
Incorrect TDL's SSP address shift in SARB for 16:6 & 18:8 modes. Disable the Sampler state prefetch functionality in the SARB by programming 0xB000[30] to '1'. This is to be done at boot time and the feature must remain disabled permanently. Fixes flaky tex-mip-level-selection* piglit tests with Mesa i965 driver. Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by:
-
Radhakrishna Sripada authored
Shader feature to prefetch binding tables does not support 16:6 18:8 BTP formats. Enabling fault handling could result in hangs with faults. Disabling demand prefetch would disable binding table prefetch. V2: Fix the stepping rivision to B0(Mika) References: HSDES#1406609255, HSDES#1406573985 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
-
- 08 Oct, 2018 12 commits
-
-
Chris Wilson authored
s/crtc/crtc_state/ for the kernel doc as well as the params. Fixes: 65c307fd ("drm/i915: Make shared dpll functions take crtc_state, v3.") Signed-off-by:
-
Ville Syrjälä authored
Let's try to stick a common naming pattern in all the plane init funcs. v2: Rebase due to color_encoding/range props Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-12-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Use a more familiar naming pattern for our variables in the sprite plane init function. v2: Drop the redundant 'plane' from plane_formats and num_planes_formats too v3: Rebase due to ->max_stride() and ->check_plane() changes Signed-off-by: -
Ville Syrjälä authored
There's not much point in following the primary vs. sprite split for the SKL+ universal plane init code. The only difference is of our own doing in the form of the .check_plane(). Let's make a small exception for that little detail and otherwise share the same code to initialize all the universal planes. Eventually we should eliminate the mess around .check_plane() as well, but for now let's be happy with some code reduction. v2: Remember to set up plane->has_fbc Make skl_plane_has_ccs() static v3: Rebase due to NV12, rename some variables v4: Don't leave the color_encoding/range props behind v5: Rebase dur to blend properties, skl_plane_max_stride() and skl_plane_check() v6: Make skl_update_plane() static Signed-off-by: -
Ville Syrjälä authored
Pull the common plane+plane_state allocation into a small helper. Reduces the amount of boilerplate in the plane initialization functions. Signed-off-by:
-
Ville Syrjälä authored
No point in having each caller of intel_create_plane_state() initialize the scaler_id to -1. Instead just do it in intel_create_plane_state(). Previously we left scaler_id at 0 for pre-SKL platforms, but I can't see how initializing it to -1 always would cause any harm. Signed-off-by:
-
Ville Syrjälä authored
All SKL+ universal planes support the same set of formats (with the exception of NV12 which we don't expose yet). Make the format lists for primary and sprites the same. And make the format list const while at it. v2: Deal with the "planar" format list as well Signed-off-by:
-
Ville Syrjälä authored
Plane scaling is not supported with specific pixel formats. Disallow plane scaling when such a format is used. Currently the only such pixel format we expose is C8, but in case we add more in the future let's make it easy to deal with them. v2: Redo due to plane_check() refactoring Signed-off-by:
-
Ville Syrjälä authored
All CNL universal planes support horizontal mirroring. Currently we expose the capability only for the primary plane. Expose it for the overlay planes as well. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
enum i9xx_plane_id namespace is not valid for any sprite plane, so let's not even populate plane->i9xx_plane. Signed-off-by:
-
Ville Syrjälä authored
We're currently not providing the possible_crtcs mask to drm_universal_plane_init() for primary/cursor planes. While that does work on account of drm_crtc_init_with_planes() filling those up for us, it's inconsisten with what we're doing for sprite planes. Let's just always pass the possible_crtcs bitmask to drm_universal_plane_init(). This does assume that crtc->index == pipe. But we're already making that assumption elsewhere so it doesn't seem like a very big sin here. Signed-off-by:
-
Ville Syrjälä authored
plane_funcs can be cosnt. Make them so. v2: Rebase due to per-platforms plane_funcs Signed-off-by:
-
