#
c0ef3df8 |
|
30-Jan-2024 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
PM: runtime: Simplify pm_runtime_get_if_active() usage There are two ways to opportunistically increment a device's runtime PM usage count, calling either pm_runtime_get_if_active() or pm_runtime_get_if_in_use(). The former has an argument to tell whether to ignore the usage count or not, and the latter simply calls the former with ign_usage_count set to false. The other users that want to ignore the usage_count will have to explicitly set that argument to true which is a bit cumbersome. To make this function more practical to use, remove the ign_usage_count argument from the function. The main implementation is in a static function called pm_runtime_get_conditional() and implementations of pm_runtime_get_if_active() and pm_runtime_get_if_in_use() are moved to runtime.c. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Alex Elder <elder@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Takashi Iwai <tiwai@suse.de> # sound/ Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> # drivers/accel/ivpu/ Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> # drivers/gpu/drm/i915/ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci/ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
261200eb |
|
05-Dec-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/rpm: add rpm_to_i915() helper around container_of() Reduce the duplication. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205121545.2338665-1-jani.nikula@intel.com
|
#
b49e894c |
|
30-Oct-2023 |
Andrzej Hajda <andrzej.hajda@intel.com> |
drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library Beside reusing existing code, the main advantage of ref_tracker is tracking per instance of wakeref. It allows also to catch double put. On the other side we lose information about the first acquire and the last release, but the advantages outweigh it. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030-ref_tracker_i915-v1-1-006fe6b96421@intel.com
|
#
8874288c |
|
13-Sep-2023 |
Jouni Högander <jouni.hogander@intel.com> |
drm/i915: Remove runtime suspended boolean from intel_runtime_pm struct It's not necessary to carry separate suspended status information in intel_runtime_pm struct as this information is already in underlying device structure. Remove it and use pm_runtime_suspended() to obtain suspended status information when needed. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913100430.3433969-1-jouni.hogander@intel.com
|
#
8d208a5e |
|
08-Jun-2023 |
Luca Coelho <luciano.coelho@intel.com> |
drm/i915: use pointer to i915 instead of rpm in wakeref Currently a pointer to an intel_runtime_pm structure is stored in the wake reference structures so the runtime data can be accessed. We can save the entire device information (drm_i915_private) instead, since we'll need to reference the new workqueue we'll add in subsequent patches. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ec0eb5149120d04f3d9870d7671ef10103e6fc29.1686231190.git.jani.nikula@intel.com
|
#
d3708182 |
|
01-Mar-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/pm: drop intel_pm_setup() All the init in intel_pm_setup() is related to runtime pm. Move them to intel_runtime_pm_init_early(), and remove intel_pm_setup(). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b01f9bf0afa9abaece5d0f76aecde69e2679f662.1677678803.git.jani.nikula@intel.com
|
#
1cacd689 |
|
27-Oct-2022 |
Anshuman Gupta <anshuman.gupta@intel.com> |
drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual We had already grabbed the rpm wakeref at obj destruction path, but it also required to grab the wakeref when object moves. When i915_gem_object_release_mmap_offset() gets called by i915_ttm_move_notify(), it will release the mmap offset without grabbing the wakeref. We want to avoid that therefore, grab the wakeref at i915_ttm_unmap_virtual() accordingly. While doing that also changed the lmem_userfault_lock from mutex to spinlock, as spinlock widely used for list. Also changed if (obj->userfault_count) to GEM_BUG_ON(!obj->userfault_count). v2: - Removed lmem_userfault_{list,lock} from intel_gt. [Matt Auld] Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend") Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221027092242.1476080-3-anshuman.gupta@intel.com
|
#
e66c8dcf |
|
27-Oct-2022 |
Anshuman Gupta <anshuman.gupta@intel.com> |
drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm Runtime pm is not really per GT, therefore it make sense to move lmem_userfault_list, lmem_userfault_lock and userfault_wakeref from intel_gt to intel_runtime_pm structure, which is embedded to i915. No functional change. v2: - Fixes the code comment nit. [Matt Auld] Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221027092242.1476080-2-anshuman.gupta@intel.com
|
#
66eb93e7 |
|
14-Oct-2022 |
Anshuman Gupta <anshuman.gupta@intel.com> |
drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPU DGFX platforms has lmem and cpu can access the lmem objects via mmap and i915 internal i915_gem_object_pin_map() for i915 own usages. Both of these methods has pre-requisite requirement to keep GFX PCI endpoint in D0 for a supported iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1) Both DG1/DG2 have a known hardware bug that violates the PCIe specs and support the iomem read write transaction over PCIe bus despite endpoint is D3 state. Due to above H/W bug, we had never observed any issue with i915 runtime PM versus lmem access. But this issue becomes visible when PCIe gfx endpoint's upstream bridge enters to D3, at this point any lmem read/write access will be returned as unsupported request. But again this issue is not observed on every platform because it has been observed on few host machines DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver. which really disables the PCIe power savings and leaves the bridge at D0 state. We need a unique interface to read/write from lmem with runtime PM wakeref protection something similar to intel_uncore_{read, write}, keep autosuspend control to 'on' on all discrete platforms, until we have a unique interface to read/write from lmem. This just change the default autosuspend setting of i915 on dGPU, user can still change it to 'auto'. v2: - Modified the commit message and subject with more information. - Changed the Fixes tag to LMEM support commit. [Joonas] - Changed !HAS_LMEM() Cond to !IS_DGFX(). [Rodrigo] Fixes: b908be543e44 ("drm/i915: support creating LMEM objects") Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014113258.1284226-1-anshuman.gupta@intel.com
|
#
62c52eac |
|
14-Oct-2022 |
Anshuman Gupta <anshuman.gupta@intel.com> |
drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPU DGFX platforms has lmem and cpu can access the lmem objects via mmap and i915 internal i915_gem_object_pin_map() for i915 own usages. Both of these methods has pre-requisite requirement to keep GFX PCI endpoint in D0 for a supported iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1) Both DG1/DG2 have a known hardware bug that violates the PCIe specs and support the iomem read write transaction over PCIe bus despite endpoint is D3 state. Due to above H/W bug, we had never observed any issue with i915 runtime PM versus lmem access. But this issue becomes visible when PCIe gfx endpoint's upstream bridge enters to D3, at this point any lmem read/write access will be returned as unsupported request. But again this issue is not observed on every platform because it has been observed on few host machines DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver. which really disables the PCIe power savings and leaves the bridge at D0 state. We need a unique interface to read/write from lmem with runtime PM wakeref protection something similar to intel_uncore_{read, write}, keep autosuspend control to 'on' on all discrete platforms, until we have a unique interface to read/write from lmem. This just change the default autosuspend setting of i915 on dGPU, user can still change it to 'auto'. v2: - Modified the commit message and subject with more information. - Changed the Fixes tag to LMEM support commit. [Joonas] - Changed !HAS_LMEM() Cond to !IS_DGFX(). [Rodrigo] Fixes: b908be543e44 ("drm/i915: support creating LMEM objects") Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014113258.1284226-1-anshuman.gupta@intel.com (cherry picked from commit 66eb93e71a7a6695b7c5eb682e3ca1c980cf9d58) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
985a0256 |
|
04-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/selftests: Disable runtime pm wakeref tracking for the mock device commit c50df701d49e ("drm/i915: Enable rpm wakeref tracking whether runtime pm is enabled or not") enabled wakeref tracking even for the mock device. Turns out that has somewhat significant overhead, and on the glacial Core m3's we have in CI the vma selftests are now exceeding the allotted time budget. So let's disable the wakeref tracking once again for the mock device in order to avoid blowing up the selftest runtime. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204171053.18409-1-ville.syrjala@linux.intel.com
|
#
c50df701 |
|
26-Jan-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable rpm wakeref tracking whether runtime pm is enabled or not Don't see why we should skip the wakeref tracking when the platform doesn't support runtime pm. We still want all the code to be 100% leak free so let's track this unconditionally. Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com> # stackdepot Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220126081539.23227-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
751a9d69 |
|
26-Jan-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix oops due to missing stack depot We call __save_depot_stack() unconditionally so the stack depot must always be initialized or else we'll oops on platforms without runtime pm support. Presumably we've not seen this in CI due to stack_depot_init() already getting called via drm_mm_init()+CONFIG_DRM_DEBUG_MM. Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com> # stackdepot Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Fixes: 2dba5eb1c73b ("lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220126081539.23227-1-ville.syrjala@linux.intel.com Acked-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
eb48d421 |
|
26-Jan-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix oops due to missing stack depot We call __save_depot_stack() unconditionally so the stack depot must always be initialized or else we'll oops on platforms without runtime pm support. Presumably we've not seen this in CI due to stack_depot_init() already getting called via drm_mm_init()+CONFIG_DRM_DEBUG_MM. Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com> # stackdepot Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Fixes: 2dba5eb1c73b ("lib/stackdepot: allow optional init and stack_table allocation by kvmalloc()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220126081539.23227-1-ville.syrjala@linux.intel.com Acked-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit 751a9d69b19702af35b0fedfb8ff362027c1cf0c) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
2dba5eb1 |
|
21-Jan-2022 |
Vlastimil Babka <vbabka@suse.cz> |
lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() Currently, enabling CONFIG_STACKDEPOT means its stack_table will be allocated from memblock, even if stack depot ends up not actually used. The default size of stack_table is 4MB on 32-bit, 8MB on 64-bit. This is fine for use-cases such as KASAN which is also a config option and has overhead on its own. But it's an issue for functionality that has to be actually enabled on boot (page_owner) or depends on hardware (GPU drivers) and thus the memory might be wasted. This was raised as an issue [1] when attempting to add stackdepot support for SLUB's debug object tracking functionality. It's common to build kernels with CONFIG_SLUB_DEBUG and enable slub_debug on boot only when needed, or create only specific kmem caches with debugging for testing purposes. It would thus be more efficient if stackdepot's table was allocated only when actually going to be used. This patch thus makes the allocation (and whole stack_depot_init() call) optional: - Add a CONFIG_STACKDEPOT_ALWAYS_INIT flag to keep using the current well-defined point of allocation as part of mem_init(). Make CONFIG_KASAN select this flag. - Other users have to call stack_depot_init() as part of their own init when it's determined that stack depot will actually be used. This may depend on both config and runtime conditions. Convert current users which are page_owner and several in the DRM subsystem. Same will be done for SLUB later. - Because the init might now be called after the boot-time memblock allocation has given all memory to the buddy allocator, change stack_depot_init() to allocate stack_table with kvmalloc() when memblock is no longer available. Also handle allocation failure by disabling stackdepot (could have theoretically happened even with memblock allocation previously), and don't unnecessarily align the memblock allocation to its own size anymore. [1] https://lore.kernel.org/all/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com/ Link: https://lkml.kernel.org/r/20211013073005.11351-1-vbabka@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Marco Elver <elver@google.com> # stackdepot Cc: Marco Elver <elver@google.com> Cc: Vijayanand Jitta <vjitta@codeaurora.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Oliver Glitta <glittao@gmail.com> Cc: Imran Khan <imran.f.khan@oracle.com> From: Colin Ian King <colin.king@canonical.com> Subject: lib/stackdepot: fix spelling mistake and grammar in pr_err message There is a spelling mistake of the work allocation so fix this and re-phrase the message to make it easier to read. Link: https://lkml.kernel.org/r/20211015104159.11282-1-colin.king@canonical.com Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: Vlastimil Babka <vbabka@suse.cz> From: Vlastimil Babka <vbabka@suse.cz> Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup On FLATMEM, we call page_ext_init_flatmem_late() just before kmem_cache_init() which means stack_depot_init() (called by page owner init) will not recognize properly it should use kvmalloc() and not memblock_alloc(). memblock_alloc() will also not issue a warning and return a block memory that can be invalid and cause kernel page fault when saving stacks, as reported by the kernel test robot [1]. Fix this by moving page_ext_init_flatmem_late() below kmem_cache_init() so that slab_is_available() is true during stack_depot_init(). SPARSEMEM doesn't have this issue, as it doesn't do page_ext_init_flatmem_late(), but a different page_ext_init() even later in the boot process. Thanks to Mike Rapoport for pointing out the FLATMEM init ordering issue. While at it, also actually resolve a checkpatch warning in stack_depot_init() from DRM CI, which was supposed to be in the original patch already. [1] https://lore.kernel.org/all/20211014085450.GC18719@xsang-OptiPlex-9020/ Link: https://lkml.kernel.org/r/6abd9213-19a9-6d58-cedc-2414386d2d81@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: kernel test robot <oliver.sang@intel.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> From: Vlastimil Babka <vbabka@suse.cz> Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup3 Due to cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks without backoff") landing recently to -next adding a new stack depot user in drivers/gpu/drm/drm_modeset_lock.c we need to add an appropriate call to stack_depot_init() there as well. Link: https://lkml.kernel.org/r/2a692365-cfa1-64f2-34e0-8aa5674dce5e@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Cc: Marco Elver <elver@google.com> Cc: Vijayanand Jitta <vjitta@codeaurora.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Oliver Glitta <glittao@gmail.com> Cc: Imran Khan <imran.f.khan@oracle.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> From: Vlastimil Babka <vbabka@suse.cz> Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup4 Due to 4e66934eaadc ("lib: add reference counting tracking infrastructure") landing recently to net-next adding a new stack depot user in lib/ref_tracker.c we need to add an appropriate call to stack_depot_init() there as well. Link: https://lkml.kernel.org/r/45c1b738-1a2f-5b5f-2f6d-86fab206d01c@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Eric Dumazet <edumazet@google.com> Cc: Jiri Slab <jirislaby@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
527bab04 |
|
16-Nov-2021 |
Tilak Tangudu <tilak.tangudu@intel.com> |
drm/i915/rpm: Enable runtime pm autosuspend by default Let's enable runtime pm autosuspend by default everywhere. So, we can allow D3hot and bigger power savings on idle scenarios. But at this time let's not touch the autosuspend_delay time, what caused some regression on our previous attempt. Also, the latest identified issue on GuC PM has been fixed by commit 1a52faed3131 ("drm/i915/guc: Take GT PM ref when deregistering context") v1: Enable runtime pm autosuspend by default for Gen12 and later versions. v2: Enable runtime pm autosuspend by default for all platforms(Syrjala Ville) v3: Change commit message(Nikula Jani) Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116155238.3226516-1-tilak.tangudu@intel.com
|
#
0f68d45e |
|
08-Nov-2021 |
Imran Khan <imran.f.khan@oracle.com> |
lib, stackdepot: add helper to print stack entries into buffer To print stack entries into a buffer, users of stackdepot, first get a list of stack entries using stack_depot_fetch and then print this list into a buffer using stack_trace_snprint. Provide a helper in stackdepot for this purpose. Also change above mentioned users to use this helper. [imran.f.khan@oracle.com: fix build error] Link: https://lkml.kernel.org/r/20210915175321.3472770-4-imran.f.khan@oracle.com [imran.f.khan@oracle.com: export stack_depot_snprint() to modules] Link: https://lkml.kernel.org/r/20210916133535.3592491-4-imran.f.khan@oracle.com Link: https://lkml.kernel.org/r/20210915014806.3206938-4-imran.f.khan@oracle.com Signed-off-by: Imran Khan <imran.f.khan@oracle.com> Suggested-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Jani Nikula <jani.nikula@intel.com> [i915] Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
81f1f8f1 |
|
30-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Fix docbook header for __intel_runtime_pm_get_if_active() Fix the Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-string. warning from the htmldocs build. Fixes: 9d58aa46291d ("drm/i915: Fix the GT fence revocation runtime PM logic") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210330150118.1105079-1-imre.deak@intel.com
|
#
9d58aa46 |
|
22-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Fix the GT fence revocation runtime PM logic To optimize some task deferring it until runtime resume unless someone holds a runtime PM reference (because in this case the task can be done w/o the overhead of runtime resume), we have to use the runtime PM get-if-active logic: If the runtime PM usage count is 0 (and so get-if-in-use would return false) the runtime suspend handler is not necessarily called yet (it could be just pending), so the device is not necessarily powered down, and so the runtime resume handler is not guaranteed to be called. The fence revocation depends on the above deferral, so add a get-if-active helper and use it during fence revocation. v2: - Add code comment explaining the fence reg programming deferral logic to i915_vma_revoke_fence(). (Chris) - Add Cc: stable and Fixes: tags. (Chris) - Fix the function docbook comment. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v4.12+ Fixes: 181df2d458f3 ("drm/i915: Take rpm wakelock for releasing the fence on unbind") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210322204223.919936-1-imre.deak@intel.com
|
#
8ff5446a |
|
28-Jan-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Remove references to struct drm_device.pdev Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. v6: * also remove assignment in selftests/ in a later patch (Chris) v5: * remove assignment in later patch (Chris) v3: * rebased v2: * move gt/ and gvt/ changes into separate patches Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-2-tzimmermann@suse.de
|
#
8840e3bd |
|
22-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Fix the GT fence revocation runtime PM logic To optimize some task deferring it until runtime resume unless someone holds a runtime PM reference (because in this case the task can be done w/o the overhead of runtime resume), we have to use the runtime PM get-if-active logic: If the runtime PM usage count is 0 (and so get-if-in-use would return false) the runtime suspend handler is not necessarily called yet (it could be just pending), so the device is not necessarily powered down, and so the runtime resume handler is not guaranteed to be called. The fence revocation depends on the above deferral, so add a get-if-active helper and use it during fence revocation. v2: - Add code comment explaining the fence reg programming deferral logic to i915_vma_revoke_fence(). (Chris) - Add Cc: stable and Fixes: tags. (Chris) - Fix the function docbook comment. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v4.12+ Fixes: 181df2d458f3 ("drm/i915: Take rpm wakelock for releasing the fence on unbind") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210322204223.919936-1-imre.deak@intel.com (cherry picked from commit 9d58aa46291d4d696bb1eac3436d3118f7bf2573) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
649c10ff |
|
04-May-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915/runtime_pm: Prefer drm_WARN* over WARN* struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN* over WARN*. Conversion is done with below semantic patch: @@ identifier func, T; @@ func(struct intel_runtime_pm *T,...) { + struct drm_i915_private *i915 = container_of(T, struct drm_i915_private, runtime_pm); <+... ( -WARN( +drm_WARN(&i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&i915->drm, ...) ) ...+> } Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-10-pankaj.laxminarayan.bharadiya@intel.com
|
#
e0751556 |
|
18-Apr-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which matches its purpose more closely. No functional impact. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # for PCI parts Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
#
4fb87831 |
|
01-Oct-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: abstract all vgaarb access to intel_vga.[ch] Split out the code related to vga client and vgaarb all over the place into new intel_vga.[ch]. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> 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: https://patchwork.freedesktop.org/patch/msgid/20191001152506.7854-1-jani.nikula@intel.com
|
#
a09d9a80 |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: avoid including intel_drv.h via i915_drv.h->i915_trace.h Disentangle i915_drv.h from intel_drv.h, which gets included via i915_trace.h. This necessitates including i915_trace.h wherever it's needed. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ed82bf259d3b725a1a1a3c3e9d6fb5c08bc4d489.1565085691.git.jani.nikula@intel.com
|
#
fdcc789a |
|
01-Jul-2019 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Fix memleak in runtime wakeref tracking If we untrack wakerefs, the actual count may reach zero. However the krealloced owners array is still there and needs to be taken care of. Free the owners unconditionally to fix the leak. Fixes: bd780f37a361 ("drm/i915: Track all held rpm wakerefs") Reported-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190701104442.9319-1-mika.kuoppala@linux.intel.com (cherry picked from commit c5f846eed2a1856b78e988eeef08215c70598ecd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
3b58a945 |
|
12-Jul-2019 |
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> |
drm/i915: Propagate "_release" function name suffix down Replace mixed "_fini"/"_cleanup"/"_cleanup_hw" suffixes found in names of functions called from i915_driver_release() with "_release" suffix consistently. This provides better code readability, especially helpful when trying to work out which phase the code is in. Functions names starting with "i915_driver_", i.e., those defined in drivers/gpu/dri/i915/i915_drv.c, just have their "cleanup" or "fini" parts of their names replaced with the "_release" suffix, while names of functions coming from other source files have been suffixed with "_driver_release" to avoid ambiguity with other possible .release entry points. v2: early_probe pairs better with late_release (Chris) v3: fix typo in commit message (Joonas) Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190712112429.740-5-janusz.krzysztofik@linux.intel.com
|
#
c5f846ee |
|
01-Jul-2019 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Fix memleak in runtime wakeref tracking If we untrack wakerefs, the actual count may reach zero. However the krealloced owners array is still there and needs to be taken care of. Free the owners unconditionally to fix the leak. Fixes: bd780f37a361 ("drm/i915: Track all held rpm wakerefs") Reported-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190701104442.9319-1-mika.kuoppala@linux.intel.com
|
#
d858d569 |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: update rpm_get/put to use the rpm structure The functions where internally already only using the structure, so we need to just flip the interface. v2: rebase Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-7-daniele.ceraolospurio@intel.com
|
#
69c66355 |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: move a few more functions to accept the rpm structure Focusing on the functions called in few places. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-6-daniele.ceraolospurio@intel.com
|
#
1bf676cc |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: move and rename i915_runtime_pm Asserts aside, all the code working on this structure is in intel_runtime_pm.c and uses the intel_ prefix, so move the structure to intel_runtime_pm.h and adopt the same prefix. Since all the asserts are now working on the runtime_pm structure, bring them across as well. v2: drop unneeded include (Chris), don't rename debugfs, rebase Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-5-daniele.ceraolospurio@intel.com
|
#
87b391b9 |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: Remove rpm asserts that use i915 Quite a few of the call points have already switched to the version working directly on the runtime_pm structure, so let's switch over the rest and kill the i915-based asserts. v2: rebase Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-3-daniele.ceraolospurio@intel.com
|
#
d5b6c275 |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: prefer i915_runtime_pm in intel_runtime function As a first step towards updating the code to work on the runtime_pm structure instead of i915, rework all the internals to use and pass around that. v2: add comment for kdev (Jani), move rpm init after pdev init for mock_device Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-2-daniele.ceraolospurio@intel.com
|
#
affa22b5 |
|
04-Jun-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: fix documentation build warnings Just a straightforward bag of fixes for a clean htmldocs build. Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190605095657.23601-2-jani.nikula@intel.com
|
#
7645b19d |
|
31-May-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: extract intel_display_power.h/c from intel_runtime_pm.h/c Keep all the device-level PM management in intel_runtime_pm.h/c and move all the display specific bits into their own file. Also add the new header to Makefile.header-test. Apart from the giant code move, the only difference is with the intel_runtime_<get/put>_raw() functions, which are now exposed in the header. The _put() version is also not conditionally compiled anymore since it is ok to always pass the wakeref taken from the _get() to __intel_runtime_pm_put (it is -1 if tracking is disabled). Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190531222409.9177-2-daniele.ceraolospurio@intel.com
|
#
08d8e170 |
|
09-May-2019 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Replace use of PLLS power domain with DISPLAY_CORE domain There isn't a separate power domain specific to PLLs. When programming them we require the same power domain to be enabled which is needed when accessing other display core parts (not specific to any pipe/port/transcoder). This corresponds to the DISPLAY_CORE domain added previously in this patchset, so use that instead to save bits in the power domain mask. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190509173446.31095-10-imre.deak@intel.com
|
#
6cfe7ec0 |
|
09-May-2019 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Remove the unneeded AUX power ref from intel_dp_detect() We don't need the AUX power for the whole duration of the detect, only when we're doing AUX transfers. The AUX transfer function takes its own reference on the AUX power domain already. The two places during detect which access display core registers (not specific to a pipe/port/transcoder) only need the power domain that is required for that access. That power domain is equivalent to the device global power domain on most platforms (enabled whenever we hold a runtime PM reference) except on CHV/VLV where it's equivalent to the display power well. Add a new power domain that reflects the above, and use this at the two spots accessing registers. With that we can avoid taking the AUX reference for the whole duration of the detect function. Put the domains asynchronously to avoid the unneeded on-off-on toggling. Also adapt the idea from with_intel_runtime_pm et al. for making it easy to write short sequences where a display power ref is needed. v2: (Ville) - Add with_intel_display_power() helper to simplify things. - s/bool res/bool is_connected/ Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190509173446.31095-8-imre.deak@intel.com
|
#
e0da2d63 |
|
13-May-2019 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add support for asynchronous display power disabling By disabling a power domain asynchronously we can restrict holding a reference on that power domain to the actual code sequence that requires the power to be on for the HW access it's doing, by also avoiding unneeded on-off-on togglings of the power domain (since the disabling happens with a delay). One benefit is potential power saving due to the following two reasons: 1. The fact that we will now be holding the reference only for the necessary duration by the end of the patchset. While simply not delaying the disabling has the same benefit, it has the problem that frequent on-off-on power switching has its own power cost (see the 2. point below) and the debug trace for power well on/off events will cause a lot of dmesg spam (see details about this further below). 2. Avoiding the power cost of freuqent on-off-on power switching. This requires us to find the optimal disabling delay based on the measured power cost of on->off and off->on switching of each power well vs. the power of keeping the given power well on. In this patchset I'm not providing this optimal delay for two reasons: a) I don't have the means yet to perform the measurement (with high enough signal-to-noise ratio, or with the help of an energy counter that takes switching into account). I'm currently looking for a way to measure this. b) Before reducing the disabling delay we need an alternative way for debug tracing powerwell on/off events. Simply avoiding/throttling the debug messages is not a solution, see further below. Note that even in the case where we can't measure any considerable power cost of frequent on-off switching of powerwells, it still would make sense to do the disabling asynchronously (with 0 delay) to avoid blocking on the disabling. On VLV I measured this disabling time overhead to be 1ms on average with a worst case of 4ms. In the case of the AUX power domains on ICL we would also need to keep the sequence where we hold the power reference short, the way it would be by the end of this patchset where we hold it only for the actual AUX transfer. Anything else would make the locking we need for ICL TypeC ports (whenever we hold a reference on any AUX power domain) rather problematic, adding for instance unnecessary lockdep dependencies to the required TypeC port lock. I chose the disabling delay to be 100msec for now to avoid the unneeded toggling (and so not to introduce dmesg spamming) in the DP MST sideband signaling code. We could optimize this delay later, once we have the means to measure the switching power cost (see above). Note that simply removing/throttling the debug tracing for power well on/off events is not a solution. We need to know the exact spots of these events and cannot rely only on incorrect register accesses caught (due to not holding a wakeref at the time of access). Incorrect powerwell enabling/disabling could lead to other problems, for instance we need to keep certain powerwells enabled for the duration of modesets and AUX transfers. v2: - Clarify the commit log parts about power cost measurement and the problem of simply removing/throttling debug tracing. (Chris) - Optimize out local wakeref vars at intel_runtime_pm_put_raw() and intel_display_power_put_async() call sites if CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n. (Chris) - Rebased on v2 of the wakeref w/o power-on guarantee patch. - Add missing docbook headers. v3: - Checkpatch spelling/missing-empty-line fix. v4: - Fix unintended local wakeref var optimization when using call-arguments with side-effects, by using inline funcs instead of macros. In this patch in particular this will fix the intel_display_power_grab_async_put_ref()->intel_runtime_pm_put_raw() call). No size change in practice (would be the same disregarding the corresponding change in intel_display_power_grab_async_put_ref()): $ size i915-macro.ko text data bss dec hex filename 2455190 105890 10272 2571352 273c58 i915-macro.ko $ size i915-inline.ko text data bss dec hex filename 2455195 105890 10272 2571357 273c5d i915-inline.ko Kudos to Stan for reporting the raw-wakeref WARNs this issue caused. His config has CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n, which I didn't retest after v1, and we are also not testing this config in CI. Now tested both with CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y/n on ICL, connecting both Chamelium and regular DP, HDMI sinks. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190513192533.12586-1-imre.deak@intel.com
|
#
ee70080a |
|
09-May-2019 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Verify power domains state during suspend in all cases There is no reason why we couldn't verify the power domains state during suspend in all cases, so do that. I overlooked this when originally adding the check. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190509173446.31095-4-imre.deak@intel.com
|
#
dbf99c1f |
|
09-May-2019 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Force printing wakeref tacking during pm_cleanup Make sure we print and drop the wakeref tracking info during pm_cleanup even if there are wakeref holders (either raw-wakeref or wakelock holders). Dropping the wakeref tracking means that a late put on the ref will WARN since the wakeref will be unknown, but that is rightly so, since the put is late and we want to catch that case. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190509173446.31095-3-imre.deak@intel.com
|
#
4547c255 |
|
09-May-2019 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add support for tracking wakerefs w/o power-on guarantee It's useful to track runtime PM refs that don't guarantee a device power-on state to the rest of the driver. One such case is holding a reference that will be put asynchronously, during which normal users without their own reference shouldn't access the HW. A follow-up patch will add support for disabling display power domains asynchronously which needs this. For this we can split wakeref_count into a low half-word tracking all references (raw-wakerefs) and a high half-word tracking references guaranteeing a power-on state (wakelocks). Follow-up patches will make use of the API added here. While at it add the missing docbook header for the unchecked display-power and runtime_pm put functions. No functional changes, except for printing leaked raw-wakerefs and wakelocks separately in intel_runtime_pm_cleanup(). v2: - Track raw wakerefs/wakelocks in the low/high half-word of wakeref_count, instead of adding a new counter. (Chris) v3: - Add a struct_member(T, m) helper instead of open-coding it. (Chris) - Checkpatch indentation formatting fix. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190509173446.31095-2-imre.deak@intel.com
|
#
46034d2b |
|
03-May-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move the hsw/bdw pc8 code to intel_runtime_pm.c hsw_enable_pc8()/hsw_disable_pc8() are more less equivalent to the display core init/unit functions of later platforms. Relocate the hsw/bdw code into intel_runtime_pm.c so that it sits next to its cousins. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503193143.28240-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
8f91cfd2 |
|
03-May-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Replace intel_ddi_pll_init() intel_ddi_pll_init() is an anachronism. Rename it to hsw_assert_cdclk() and move it to the power domain init code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503193143.28240-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
b1ad4c39 |
|
02-May-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_dpio_phy.h from i915_drv.h It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/876a1671a84c6839bcafdf276cf9c4e1da6c631c.1556809195.git.jani.nikula@intel.com
|
#
c9fd9166 |
|
02-May-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: add single combo phy init/unit functions Work on the principle that files should prefer not to expose platform specific functions. v2, v3: Rebase Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502145234.7002-1-jani.nikula@intel.com
|
#
d5f9db2c |
|
29-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_combo_phy.h from i915_drv.h It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6aea17072684dec0b04b6831c0c0e5a134edf87e.1556540890.git.jani.nikula@intel.com
|
#
dbeb38d9 |
|
29-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_hotplug.h from intel_drv.h and i915_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: fix sparse warnings on undeclared global functions Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190429125011.10876-1-jani.nikula@intel.com
|
#
440e2b3d |
|
29-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract i915_irq.h from intel_drv.h and i915_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/64e46278dc8dccc9c548ef453cb2ceece5367bb2.1556540890.git.jani.nikula@intel.com
|
#
fcfec1fc |
|
04-Apr-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/icl: fix step numbers in icl_display_core_init() At some point the spec was changed and we never updated the numbers to match it. Let's try once more to keep them in sync. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190404230426.15837-2-lucas.demarchi@intel.com
|
#
487f3c7f |
|
25-Apr-2019 |
Thomas Gleixner <tglx@linutronix.de> |
drm: Simplify stacktrace handling Replace the indirection through struct stack_trace by using the storage array based interfaces. The original code in all printing functions is really wrong. It allocates a storage array on stack which is unused because depot_fetch_stack() does not store anything in it. It overwrites the entries pointer in the stack_trace struct so it points to the depot storage. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Cc: Andy Lutomirski <luto@kernel.org> Cc: intel-gfx@lists.freedesktop.org Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: linux-mm@kvack.org Cc: David Rientjes <rientjes@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: kasan-dev@googlegroups.com Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Cc: iommu@lists.linux-foundation.org Cc: Robin Murphy <robin.murphy@arm.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: David Sterba <dsterba@suse.com> Cc: Chris Mason <clm@fb.com> Cc: Josef Bacik <josef@toxicpanda.com> Cc: linux-btrfs@vger.kernel.org Cc: dm-devel@redhat.com Cc: Mike Snitzer <snitzer@redhat.com> Cc: Alasdair Kergon <agk@redhat.com> Cc: Tom Zanussi <tom.zanussi@linux.intel.com> Cc: Miroslav Benes <mbenes@suse.cz> Cc: linux-arch@vger.kernel.org Link: https://lkml.kernel.org/r/20190425094802.622094226@linutronix.de
|
#
56c5098f |
|
26-Apr-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Separate sideband declarations to intel_sideband.h Split the sideback declarations out of the ginormous i915_drv.h Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426081725.31217-5-chris@chris-wilson.co.uk
|
#
ebb5eb7d |
|
26-Apr-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Replace pcu_lock with sb_lock We now have two locks for sideband access. The general one covering sideband access across all generation, sb_lock, and a specific one covering sideband access via the punit on vlv/chv. After lifting the sb_lock around the punit into the callers, the pcu_lock is now redudant and can be separated from its other use to regulate RPS (essentially giving RPS a lock all of its own). v2: Extract a couple of minor bug fixes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426081725.31217-4-chris@chris-wilson.co.uk
|
#
337fa6e0 |
|
26-Apr-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Lift sideband locking for vlv_punit_(read|write) Lift the sideband acquisition for vlv_punit_read and vlv_punit_write into their callers, so that we can lock the sideband once for a sequence of operations, rather than perform the heavyweight acquisition on each request. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426081725.31217-3-chris@chris-wilson.co.uk
|
#
221c7862 |
|
26-Apr-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Lift acquiring the vlv punit magic to a common sb-get As we now employ a very heavy pm_qos around the punit access, we want to minimise the number of synchronous requests by performing one for the whole punit sequence rather than around individual accesses. The sideband lock is used for this, so push the pm_qos into the sideband lock acquisition and release, moving it from the lowlevel punit rw routine to the callers. In the first step, we move the punit magic into the common sideband lock so that we can acquire a bunch of ports simultaneously, and if need be extend the workaround protection later. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426081725.31217-2-chris@chris-wilson.co.uk
|
#
fa49e2ea |
|
09-Apr-2019 |
Thomas Gleixner <tglx@linutronix.de> |
drm: Remove the ULONG_MAX stack trace hackery No architecture terminates the stack trace with ULONG_MAX anymore. Remove the cruft. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: intel-gfx@lists.freedesktop.org Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lkml.kernel.org/r/20190410103644.945059666@linutronix.de
|
#
39564ae8 |
|
12-Apr-2019 |
Bob Paauwe <bob.j.paauwe@intel.com> |
drm/i915/ehl: Inherit Ice Lake conditional code Most of the conditional code for ICELAKE also applies to ELKHARTLAKE so use IS_GEN(dev_priv, 11) even for PM and Workarounds for now. v2: - Rename commit (Jose) - Include a wm workaround (Jose and Lucas) - Include display core init (Jose and Lucas) v3: Add a missing case of gen greater-than 11 (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190412180920.22347-1-rodrigo.vivi@intel.com
|
#
2e1e5c55 |
|
09-Apr-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid reclaim taints from runtime-pm debug As intel_runtime_pm_get/_put may be called from any blockable context, we need to avoid allowing reclaim from our mallocs, as we need to avoid tainting any mutexes held by the callers (as they may themselves not allow for allocations as they are taken in the shrinker). <4> [435.339331] WARNING: possible circular locking dependency detected <4> [435.339364] 5.1.0-rc4-CI-Trybot_4116+ #1 Tainted: G U <4> [435.339395] ------------------------------------------------------ <4> [435.339426] gem_caching/1334 is trying to acquire lock: <4> [435.339456] 000000004505c39b (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915] <4> [435.339788] but task is already holding lock: <4> [435.339819] 00000000ee77b4ed (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.24+0x0/0x30 <4> [435.339879] which lock already depends on the new lock. <4> [435.339918] the existing dependency chain (in reverse order) is: <4> [435.339952] -> #1 (fs_reclaim){+.+.}: <4> [435.339998] fs_reclaim_acquire.part.24+0x24/0x30 <4> [435.340035] kmem_cache_alloc_trace+0x2a/0x290 <4> [435.340311] __print_intel_runtime_pm_wakeref+0x24/0x160 [i915] <4> [435.340590] untrack_intel_runtime_pm_wakeref+0x16e/0x1d0 [i915] <4> [435.340869] intel_runtime_pm_put_unchecked+0xd/0x30 [i915] <4> [435.341147] __intel_wakeref_put_once+0x22/0x40 [i915] <4> [435.341508] i915_request_retire+0x477/0xaf0 [i915] <4> [435.341871] ring_retire_requests+0x86/0x160 [i915] <4> [435.342226] i915_retire_requests+0x58/0xc0 [i915] <4> [435.342576] retire_work_handler+0x5b/0x70 [i915] <4> [435.342615] process_one_work+0x245/0x610 <4> [435.342646] worker_thread+0x37/0x380 <4> [435.342679] kthread+0x119/0x130 <4> [435.342714] ret_from_fork+0x3a/0x50 <4> [435.342739] -> #0 (wakeref#3){+.+.}: <4> [435.342788] lock_acquire+0xa6/0x1c0 <4> [435.342822] __mutex_lock+0x8c/0x960 <4> [435.342853] atomic_dec_and_mutex_lock+0x33/0x50 <4> [435.343151] intel_engine_pm_put+0x1b/0x40 [i915] <4> [435.343501] i915_request_retire+0x477/0xaf0 [i915] <4> [435.343851] ring_retire_requests+0x86/0x160 [i915] <4> [435.344202] i915_retire_requests+0x58/0xc0 [i915] <4> [435.344543] i915_gem_shrink+0xd8/0x5b0 [i915] <4> [435.344835] i915_drop_caches_set+0x17b/0x250 [i915] <4> [435.344877] simple_attr_write+0xb0/0xd0 <4> [435.344911] full_proxy_write+0x51/0x80 <4> [435.344943] vfs_write+0xbd/0x1b0 <4> [435.344972] ksys_write+0x55/0xe0 <4> [435.345002] do_syscall_64+0x55/0x190 <4> [435.345040] entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190409174108.19396-1-chris@chris-wilson.co.uk
|
#
93a643f2 |
|
05-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/cdclk: have only one init/uninit function While transitioning to having better clarity between the modules, it's desirable to have the function name prefixes reflect the module. Functions in intel_foo.c should be prefixed intel_foo_. Expose only one CDCLK init/uninit function from intel_cdclk.c instead of one per platform. Obviously this adds one "unnecessary" if ladder within the entry points. However it should be considered more of a CDCLK implementation detail how this is done per platform, instead of exposing the fact. In other words, abstract the CDCLK module better. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f63ed6e129098a32c63735be6cffa4756e7947af.1554461791.git.jani.nikula@intel.com
|
#
e7674ef6 |
|
05-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_cdclk.h from intel_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c128d7be3f621391e571e86b03f302f3ffd0ed2b.1554461791.git.jani.nikula@intel.com
|
#
27fec1f9 |
|
05-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_dp.h from intel_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f86f9beed730eaad0bdcc18b18817b3d221e16e2.1554461791.git.jani.nikula@intel.com
|
#
174594db |
|
05-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_csr.h from intel_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: Add function argument names to fix checkpatch warning Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/44ceebca0206de9c40dc6794b660d84b8994f700.1554461791.git.jani.nikula@intel.com
|
#
d2ee2e8a |
|
05-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_crt.h from intel_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/19c39bfcfb82f50c77382e8dea4fe1ad6cd043ed.1554461791.git.jani.nikula@intel.com
|
#
97a04e0d |
|
25-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: switch intel_wait_for_register to uncore The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-9-daniele.ceraolospurio@intel.com
|
#
209d7353 |
|
06-Mar-2019 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl: Prevent incorrect DBuf enabling Pretend that we have only 1 DBuf slice and that 1 slice is always enabled, until we have a proper way for on-demand toggling of the second slice. Currently we'll try to incorrectly enable DBuf even when all pipes are disabled and we are already runtime suspended (as the computed number of DBuf slices will be 1 in that case). This also means we'll leave the second slice enabled redundantly (except when suspended), but that's an acceptable tradeoff until we have a proper solution. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108756 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190307103235.23538-1-imre.deak@intel.com
|
#
5e0b6697 |
|
29-Nov-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Assert that VED and ISP are power gated As there are no upstream drivers for VED or ISP let's just assert that they are power gated. Otherwise they would prevent s0ix entry. For ISP this is only relevant when it is not exposed as a PCI device and instead is a subordinate of the gunit. When exposed as a PCI device it will be handled by the atomisp2_pm driver. On my VLV FFRD8 board the firmware power gates both of these by default. Let's assume that is always the case and just WARN if we ever encounter something different. Cc: Hans de Goede <hdegoede@redhat.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181129175504.3630-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
c11b813f |
|
29-Nov-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/PUNIT_REG_DSPFREQ/PUNIT_REG_DSPSSPM/ Rename the punit display power register to match the spec. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181129175504.3630-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
739f3abd |
|
16-Jan-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: small isolated c99 types to kernel types switch Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Minor checkpatch fixes sprinkled on top of the changed lines. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/14ed72e7f04c9340a057855c5950b54811f8a477.1547629303.git.jani.nikula@intel.com
|
#
25c896bd |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Track the wakeref used to initialise display power domains On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and transfer them to the runtime-pm code. We can use our wakeref tracking to verify that the wakeref is indeed passed from init to enable, and disable to fini; and across suspend. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-17-chris@chris-wilson.co.uk
|
#
0e6e0be4 |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Markup paired operations on display power domains The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-16-chris@chris-wilson.co.uk
|
#
16e4dd03 |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Markup paired operations on wakerefs The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). For regular builds, the compiler should be able to eliminate the unused local variables and the program growth should be minimal. Fwiw, it came out as a net improvement as gcc was able to refactor rpm_get and rpm_get_if_in_use together, v2: Just s/rpm_put/rpm_put_unchecked/ everywhere, leaving the manual mark up for smaller more targeted patches. v3: Mention the cookie in Returns Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-2-chris@chris-wilson.co.uk
|
#
bd780f37 |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Track all held rpm wakerefs Everytime we take a wakeref, record the stack trace of where it was taken; clearing the set if we ever drop back to no owners. For debugging a rpm leak, we can look at all the current wakerefs and check if they have a matching rpm_put. v2: Use skip=0 for unwinding the stack as it appears our noinline function doesn't appear on the stack (nor does save_stack_trace itself!) v3: Allow rpm->debug_count to disappear between inspections and so avoid calling krealloc(0) as that may return a ZERO_PTR not NULL! (Mika) v4: Show who last acquire/released the runtime pm Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Tested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-1-chris@chris-wilson.co.uk
|
#
cf819eff |
|
12-Dec-2018 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: replace IS_GEN<N> with IS_GEN(..., N) Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
|
#
91ba2c8b |
|
28-Nov-2018 |
Manasi Navare <manasi.d.navare@intel.com> |
drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI On Icelake, a separate power well PG2 is created for VDSC engine used for eDP/MIPI DSI. This patch adds a new display power domain for Power well 2. v3: * Call it POWER_DOMAIN_TRANSCODER_EDP_VDSC (Ville) * Move it around TRANSCODER power domain defs (Ville) v2: * Fix the power well mismatch CI error (Ville) * Rename as VDSC_PIPE_A (Imre) * Fix a whitespace (Anusha) * Fix Comments (Imre) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-7-manasi.d.navare@intel.com
|
#
56d4eac0 |
|
13-Nov-2018 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i195: spell out reverse on for_each macros Do like it's done for list.h macros, and use "reverse" suffix rather than "rev". Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114011509.3667-3-lucas.demarchi@intel.com
|
#
fa96ed1f |
|
09-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Remove special case for power well 1/MISC_IO state verification Even though PW#1 and the MISC_IO power wells are managed by the DMC firmware (toggled dynamically if conditions allow it) from the driver's POV they are always on if the display core is initialized (always restored by DMC to the enabled state after exiting from DC5/6 for instance b/c of MMIO access). Accordingly we can just mark them as always-on and remove the special casing for them during state verification (thus enabling verification for these power wells too). Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-3-imre.deak@intel.com
|
#
285cf66d |
|
09-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Use proper bool bitfield initializer in power well descs We can just use a proper true/false initializer even for bitfields, which is more descriptive. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-2-imre.deak@intel.com
|
#
cb8ef723 |
|
09-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9_bc: Work around DMC bug zeroing power well requests A DMC bug on GEN9 big core machines fails to restore the driver's request bits for the PW1 and MISC_IO power wells after a DC5/6 entry->exit sequence. As a consequence the driver's subsequent check for the enabled status of these power wells will fail, as the check considers the power wells being enabled only if both the status and request bits are set. To work around this borrow the request bits from BIOS's own request register in which DMC forces on the request bits when exiting from DC5/6. This fixes a problem reported by Ramalingam, where HDCP init failed, since PW1 reported itself as being disabled, while in reality it was enabled. Reported-by: Ramalingam C <ramalingam.c@intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-1-imre.deak@intel.com
|
#
a2261230 |
|
09-Nov-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/icl: Drop spurious register read from icl_dbuf_slices_update Register DBUF_CTL_S2 is read and it's value is not used. As there is no explanation why we should prime the hardware with read, remove it as spurious. Fixes: aa9664ffe863 ("drm/i915/icl: Enable 2nd DBuf slice only when needed") Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109140924.2663-1-mika.kuoppala@linux.intel.com (cherry picked from commit 8577c319b6511fbc391f3775225fecd8b979bc26) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
8577c319 |
|
09-Nov-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/icl: Drop spurious register read from icl_dbuf_slices_update Register DBUF_CTL_S2 is read and it's value is not used. As there is no explanation why we should prime the hardware with read, remove it as spurious. Fixes: aa9664ffe863 ("drm/i915/icl: Enable 2nd DBuf slice only when needed") Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109140924.2663-1-mika.kuoppala@linux.intel.com
|
#
c4f22407 |
|
02-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl: Fix power well 2 wrt. DC-off toggling order To enable DC5/6 power well 2 has to be disabled as for previous platforms, so fix things up. Bspec: 4234 Fixes: 67ca07e7ac10 ("drm/i915/icl: Add power well support") Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181102182200.17219-1-imre.deak@intel.com (cherry picked from commit a33e1ece777996ddddb1f23a30f8c66422ed0b68) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
602438ea |
|
06-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl: Fix port B combo PHY context loss after DC transitions On ICL DMC/PCODE retains the HW context only for port A across DC transitions, for the other port B combo PHY, it doesn't. So we need to do this manually after exiting from DC6. Do the reinit even after exiting from DC5, it won't hurt since we only reinit the PHY in case it's needed (in case it was disabled to begin with). As can be guessed from the bugzilla report leaving the PHY uninited will lead to a later timeout during the port B specific AUX and DDI_IO power well enabling. v2: - Apply the fix on all GEN>=11 platforms. (Rodrigo) Bspec: 21257 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-6-imre.deak@intel.com
|
#
c45198b1 |
|
06-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/cnl+: Move the combo PHY init/uninit code to a new file Similarly to the GEN9_LP DPIO PHY code keep the CNL+ combo PHY code in a separate file. No functional change. v2: - Use SPDX license tag instead of boilerplate. (Rodrigo) v3: - Use MIT instead of GPL-2.0 license. (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-3-imre.deak@intel.com
|
#
1e0e9c8a |
|
06-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl: Fix combo PHY uninit BSpec says to clear the comp init HW flag too during combo PHY uninit, so do that. The lack of this could badly interact with the PHY reinit after a DC6/9 transition at least, where (after a follow-up patch fixing the init code) we'd skip the initialization incorrectly due to this flag being set. BSpec: 21257 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-2-imre.deak@intel.com
|
#
a33e1ece |
|
02-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl: Fix power well 2 wrt. DC-off toggling order To enable DC5/6 power well 2 has to be disabled as for previous platforms, so fix things up. Bspec: 4234 Fixes: 67ca07e7ac10 ("drm/i915/icl: Add power well support") Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181102182200.17219-1-imre.deak@intel.com
|
#
c7375d95 |
|
01-Nov-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain Most of the AUX_CH_CTL flags are concerned with DP AUX transfer parameters. As opposed to this the flag specifying the thunderbolt vs. non-thunderbolt mode of the port is not related to AUX transfers at all (rather it's repurposed to enable either TBT or non-TBT PHY HW blocks). The programming has to be done before enabling the corresponding AUX power well, so make it part of the power well code. v3: - Use existing enable/disable helpers instead of opencoding. (Jose) - Fix type of is_tc_tbt to remain a bitfield. (Lucas) - Add comment describing the is_tc_tbt power well flag. (Lucas) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108548 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-8-imre.deak@intel.com
|
#
3e68928b |
|
29-Oct-2018 |
Animesh Manna <animesh.manna@intel.com> |
drm/i915/icl: Enable DC9 as lowest possible state during screen-off ICL supports DC5, DC6, and DC9. Enable DC9 during screen-off, and enable DC5/6 when appropriate. v2: (James Ausmus) - Also handle ICL as GEN9_LP in i915_drm_suspend_late and i915_drm_suspend_early - Add DC9 to gen9_dc_mask for ICL - Re-order GEN checks for newest platform first - Use INTEL_GEN instead of INTEL_INFO->gen - Use INTEL_GEN >= 11 instead of IS_ICELAKE - Consolidate GEN checks v3: (James Ausmus) - Also allow DC6 for ICL (Imre, Art) - Simplify !(GEN >= 11) to GEN < 11 (Imre) v4: (James Ausmus) - Don't call intel_power_sequencer_reset after DC9 for Gen11+, as the PPS regs are Always On - Rebase against upstream changes v5: (Anusha Srivatsa) - rebased against the latest upstream changes. v6: (Anusha Srivatsa) - rebased.Use INTEL_GEN consistently. - Simplify the code (Rodrigo) v7: rebased. Change order according to platforms(Jyoti) v8: rebased. Change the check from platform specific to HAS_PCH_SPLIT(). Add comment in code to be more clear.(Rodrigo) Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Tested-by: Jyoti Yadav <jyoti.r.yadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181029221410.4423-1-anusha.srivatsa@intel.com
|
#
fb72deae |
|
22-Oct-2018 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: power_domains_init sort platforms newer-to-older No functional change. Just sorting this "if" block from newer to older platform. v2: Fix few positions (Ville) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181022171526.15641-4-rodrigo.vivi@intel.com
|
#
ffd7e32d |
|
12-Oct-2018 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/icl: apply Display WA #1178 to fix type C dongles Display WA #1178 is meant to fix Aux channel voltage swing too low with some type C dongles. It applies to external ports on combo phy. On Icelake this is port A and B when those are not eDP. v2: follow the spec to the letter: include Aux A and just check if it's not eDP instead of checking only for Aux B. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181012215758.25342-1-lucas.demarchi@intel.com
|
#
6edafc4e |
|
18-Sep-2018 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915: Unset reset pch handshake when PCH is not present in one place Right now RESET_PCH_HANDSHAKE_ENABLE is enabled all the times inside of intel_power_domains_init_hw() and if PCH is NOP it is unsed in i915_gem_init_hw(). So making skl_pch_reset_handshake() handle both cases and calling it for the missing gens in intel_power_domains_init_hw(). Ivybridge have a different register and bits but with the same objective so moving it too. v2(Rodrigo): - handling IVYBRIDGE case inside intel_pch_reset_handshake() v4(Rodrigo and Ville): - moving the enable/disable decision to callers Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-2-jose.souza@intel.com
|
#
7c86828d |
|
18-Sep-2018 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/runtime_pm: Share code to enable/disable PCH reset handshake Instead of have the same code spread into 4 platforms lets share it. BXT do not have a PCH so here also handling this case by unseting RESET_PCH_HANDSHAKE_ENABLE. v2(Rodrigo): - renamed to intel_pch_reset_handshake() - added comment about why BXT need the bit to be unset v3(Rodrigo and Ville): - added bool have_pch to intel_pch_reset_handshake() - added back BXT comment Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-1-jose.souza@intel.com
|
#
9e3b5ce9 |
|
13-Sep-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/psr: Enable AUX-A IO power well on ICL for PSR PSR requires AUX IO power well to be enabled. This was already in place for CNL, extend this for ICL too. Not enabling the power well results in the aux error interrupts when the hardware exits PSR. Reported-by: Casey G Bowman <casey.g.bowman@intel.com> Reported-by: Jyoti R Yadav <jyoti.r.yadav@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Jyoti R Yadav <jyoti.r.yadav@intel.com> Cc: Casey G Bowman <casey.g.bowman@intel.com> Tested-by: Casey G Bowman <casey.g.bowman@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180914001822.2503-1-dhinakaran.pandiyan@intel.com
|
#
4445930f |
|
27-Aug-2018 |
Anusha Srivatsa <anusha.srivatsa@intel.com> |
firmware/dmc/icl: load v1.07 on icelake. Add Support to load DMC on Icelake. While at it, also add support to load the firmware during system resume. v2: load firmware during system resume.(Imre) v3: enable has_csr for icelake.(Jyoti) v4: Only load the firmware in this patch Cc: Jyoti Yadav <jyoti.r.yadav@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180828003844.4682-2-anusha.srivatsa@intel.com
|
#
d8c5d29f |
|
28-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Don't check power domains state in intel_power_domains_init_hw() During power domains initialization we acquire power well references for power wells in the INIT power domain. The rest of power wells - which BIOS could have left enabled - we can only acquire references as needed during display HW readout and so must defer sanitization until then (also implying that we must always do HW readout to cleanup unused power wells). Thus during initialization these latter power wells can have a refcount of 0 while still being enabled. To avoid the false-positive state mismatch error this causes remove the check from intel_power_domains_init_hw() and rely on the state check in intel_power_domains_enable() which follows the HW readout. v2: - Add comment to log and code clarifying how unused power wells get disabled. (Chris) Fixes: 6dfc4a8f134f ("drm/i915: Verify power domains after enabling them") Cc: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=107411 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180828122231.14336-1-imre.deak@intel.com
|
#
f7480b2f |
|
20-Aug-2018 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: move lookup_power_well() up There's no need for that forward declaration. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-4-paulo.r.zanoni@intel.com
|
#
0229bfd4 |
|
20-Aug-2018 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: use for_each_power_well in lookup_power_well() Use the nice helper function to make the implementation simpler. v2: Rebase. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-3-paulo.r.zanoni@intel.com
|
#
99da0b35 |
|
20-Aug-2018 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: WARN() if we can't lookup_power_well() None of the current lookup_power_well() callers are actually checking for NULL return values, they all just use the pointer right away. The first idea was to replace these theoretical segfaults with a BUG() since this would at least make our code a little more explicit to the reader. It was suggested that just converting the BUG() to a WARN() and returning any power well would probably be better since it would still keep the system running while at the same time exposing the driver bug. We can only hit this NULL/BUG()/WARN() condition if we try to lookup a power well that isn't defined on a given platform. If that ever happens, we have to fix our code, making it lookup the correct power well. Because of this, I don't think it's worth trying to implement error checking in every caller. Improving our CI system will be a better use of our time once a bug is found in the wild. v2: Avoid the BUG() with a WARN() return a random PW (Michal). Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-2-paulo.r.zanoni@intel.com
|
#
a61d904f |
|
22-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Simplify condition to keep DMC active during S0ix For S0ix we want to deinit power domains (and so deactivate the DMC firmware) exactly when the platform supports the DC9 state. To reach S0ix we need DC9 on these platforms (for which the DMC FW needs to be deactivated) while to reach S0ix on the rest of the DMC platforms we need DC6 (which needs the DMC FW to stay active). Simplify the condition accordingly so it will be automatically correct for upcoming DC9 platforms like ICL. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822112602.27543-1-imre.deak@intel.com
|
#
6dfc4a8f |
|
16-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Verify power domains after enabling them After commit 2cd9a689e97b ("drm/i915: Refactor intel_display_set_init_power() logic") it makes more sense to check the power domain/well refcounts after enabling the power domains functionality. Before that it's guaranteed that most power wells (in the INIT domain) will have a reference held, so not an interesting state. While at it also add the check after the init_hw/fini_hw, disable and suspend/resume steps. Make the test optional on a Kconfig option since it may add substantial overhead: on VLV/CHV the corresponding PUNIT reg access for each power well may take up to 20ms. v2: - Add the state check to more spots. (Chris) v3: - During suspend check the state before deiniting display core. Afterwards DC states are disabled (and so the dc_off power well is enabled) even though we don't hold a reference on it. - Do the test conditionally based on a new Kconfig option. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [Add DRM_I915_DEBUG_RUNTIME_PM to welcome messages] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180817145837.26592-1-imre.deak@intel.com
|
#
2cd9a689 |
|
16-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Refactor intel_display_set_init_power() logic The device global init_power_on flag is somewhat arbitrary and makes debugging power refcounting problems difficult. Instead arrange things so that all display power domain get has a corresponding put call. After this change we have the following sequences: driver loading: intel_power_domains_init_hw(); <other init steps> intel_power_domains_enable(); driver unloading: intel_power_domains_disable(); <other uninit steps> intel_power_domains_fini_hw(); system suspend: intel_power_domains_disable(); <other suspend steps> intel_power_domains_suspend(); system resume: intel_power_domains_resume(); <other resume steps> intel_power_domains_enable(); at other times while the driver is loaded: intel_display_power_get(); ... intel_display_power_put(); Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180816123757.3286-2-imre.deak@intel.com
|
#
07d80572 |
|
16-Aug-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable Currently, we cancel the extra wakeref we have for !runtime-pm devices inside power_wells_fini_hw. However, this is not strictly paired with the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may be called on errors paths before we even call runtime_pm_enable). Make the symmetry more explicit and include a check that we do release all of our rpm wakerefs. v2: Fixup transfer of ownership back to core whilst keeping our wakeref count balanced. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180816123757.3286-1-imre.deak@intel.com
|
#
d9fcdc8d |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Use existing power well IDs where possible There is no need for separate IDs for power wells on a new platform with the same functionality as an other power well on a previous platform, we can just reuse the ID from the previous platform. This is only possible after the previous patches where we removed dependence on the actual enum values. This also fixes a problem on ICL where in assert_can_enable_dc5/9() we would've failed to look up the PW#2 power well. v2: - Keep an ID assigned for the ICL PW#2 power well too. (Paulo) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> [Added comment about the ICL PW#2 fix to the commit log] Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-10-imre.deak@intel.com
|
#
2183b499 |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Make power well ID names more uniform The format for the ID names is <platform>_DISP_PW_* so rename the IDs not following this accordingly. Leave BXT_DPIO_CMN_BC as-is since we'll change that to use another existing ID in the next patch. v2: - Fix line over 80 chars checkpatch warning. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-9-imre.deak@intel.com
|
#
4739a9d2 |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Remove redundant power well IDs Now that we removed dependence on the power well IDs to determine the control register and request/status flag offsets the only purpose of power well IDs is to look up power wells directly bypassing the power domains framework. However this direct lookup isn't needed for most of the exisiting power wells and hopefully won't be needed for any new power wells in the future. To make maintenance of the power well ID enum easier, don't require a unique ID for each power well, only if it's necessary. Remove the IDs becoming redundant this way and assign to all the corresponding power wells a new DISP_PW_ID_NONE ID. After the previous two patches the IDs don't need to have a fixed value, so remove the explicit initializers and adjust the enum's code comment accordingly. v2: - Keep required ID assignments for HSW_DISP_PW_GLOBAL and ICL_DISP_PW_2. (Paulo) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-8-imre.deak@intel.com
|
#
75e39688 |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/ddi: Use power well CTL IDX instead of ID Similarly to the previous patch use a separate request/status HW flag index defined right after the corresponding control registers instead of depending for this on the power well IDs. Since the set of control/status registers varies among the different power wells (on a single platform), also add a new i915_power_well_registers struct that we populate and assign to each DDI power well as needed. Also clarify a bit the code comment describing the function and layout of the control registers. This also fixes a problem on ICL, where we incorrectly read the KVMR control register in hsw_power_well_requesters() even for DDI and AUX power wells. v2: - Clarify platform range tags in code comments. (Paulo) - Fix line over 80 chars checkpatch warning. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com
|
#
d13dd05a |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/vlv: Use power well CTL IDX instead of ID Atm, we determine the control/status flag offsets within the PUNIT control/status registers based on the power well's ID. Since the power well ID enum is global across all platforms, the associated macros to get the flag offsets involves some magic. This makes checking the register/bit definitions against the specification more difficult than necessary. Also the values in the power well ID enum must stay fixed, making code maintenance of the enum cumbersome. To solve the above define the control/status flag indices right after the corresponding registers and use these to derive the control/status flag values by storing the indices in the i915_power_well_desc struct. Initializing anonymous union fields require the preceding field in the struct to be explicitly initialized - even when using named initializers - and the initialization to be done right before the union initialization, hence the reordering of the .id fields. v2: - Clarify commit log message about anonymous union initializers. (Paulo) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-6-imre.deak@intel.com
|
#
f28ec6f4 |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Constify power well descriptors It makes sense to keep unchanging data const. Extract such fields from the i915_power_well struct into a new i915_power_well_desc struct that we initialize during compile time. For the rest of the dynamic fields allocate an array of i915_power_well objects in i915 dev_priv, and link to each of these objects their corresponding i915_power_well_desc object. v2: - Fix checkpatch warnings about missing param name in fn declaration and lines over 80 chars. (Paulo) - Move check for unique IDs to __set_power_wells(). Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> [Fixed checkpatch warn in __set_power_wells()] Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-5-imre.deak@intel.com
|
#
3ae27f7e |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/vlv: Remove redundant power well ID asserts The callbacks these asserts are called from are used from a single power well, so not much point in checking that. The check also requires a unique power well ID that we would need to keep around only for this purpose. (A follow-up patch removes power well IDs not needed for direct power well access). Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-4-imre.deak@intel.com
|
#
48a287ed |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Rename intel_power_domains_fini() to intel_power_domains_fini_hw() intel_power_domains_fini() rolls back what was done in intel_power_domains_init_hw(), so rename and move it accordingly. This allows us adding a cleanup function later for intel_power_domains_init() in a cleaner way. No functional change. v2: - Fix checkpatch error adding missing param name to function declaration. (Paulo) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-3-imre.deak@intel.com
|
#
ae9b06ca |
|
05-Aug-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl: Fix power well anonymous union initializers Similarly to commit 0a445945be6d ("drm/i915: Work around GCC anonymous union initialization bug") we need to initialize anonymous unions inside extra braces to work around a GCC4.4 build error. v2: - Fix checkpatch errors in commit log. (Paulo) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-2-imre.deak@intel.com
|
#
c50dfe79 |
|
25-Jul-2018 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/icl: don't set CNL_DDI_CLOCK_REG_ACCESS_ON anymore The new recommendation from the spec is to simply not set this bit anymore. Not setting the bit would prevent some hangs that our driver manages to avoid since commit c8af5274c3cb ("drm/i915: enable the pipe/transcoder/planes later on HSW+"), and the theoretical downside of not setting the bit doesn't seem realistic according to the HW team. Let's follow their recommendation. BSpec: 20233 References: commit c8af5274c3cb ("drm/i915: enable the pipe/transcoder/planes later on HSW+") Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180726001229.13791-1-paulo.r.zanoni@intel.com
|
#
f0d759f0 |
|
28-Jun-2018 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
drm/i915: Mark expected switch fall-throughs In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 141432 Addresses-Coverity-ID: 141433 Addresses-Coverity-ID: 141434 Addresses-Coverity-ID: 141435 Addresses-Coverity-ID: 141436 Addresses-Coverity-ID: 1357360 Addresses-Coverity-ID: 1357403 Addresses-Coverity-ID: 1357433 Addresses-Coverity-ID: 1392622 Addresses-Coverity-ID: 1415273 Addresses-Coverity-ID: 1435752 Addresses-Coverity-ID: 1441500 Addresses-Coverity-ID: 1454596 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628223541.GA17665@embeddedor.com
|
#
67ca07e7 |
|
26-Jun-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl: Add power well support Add the definition for ICL power wells and their mapping to power domains. On ICL there are 3 power well control registers, we'll select the correct one based on higher bits of the power well ID. The offset for the control and status flags within this register is based on the lower bits of the ID as on older platforms. As the DC state programming is also the same as on old platforms we can reuse the corresponding helpers. For this we mark here the DC-off power well as shared among multiple platforms. Other than the above the delta between old platforms and ICL: - Pipe C has its own power well, so we can save some additional power in the pipe A+B and (non-eDP) pipe A configurations. - Power wells for port E/F DDI/AUX IO and Thunderbolt 1-4 AUX IO v2: - Rebase on drm-tip after prep patch for this was merged there as requested by Paulo. - Actually add the new AUX and DDI power well control regs (Rakshmi) v3: - Fix power well register names in code comments - Add TBT AUX->power well 3 dependency v4: - Rebase v5: - Detach AUX power wells from the INIT power domain. These power wells can only be enabled in a TC/TBT connected state and otherwise not needed during driver initialization. v6: - Use _MMIO_PORT(...) instead _MMIO(_PICK(...)) (Paulo) Fix checkpatch warnings. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> (v1) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180626142232.22361-1-imre.deak@intel.com
|
#
52528055 |
|
21-Jun-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915/ddi: Get AUX power domain for DP main link too So far we got an AUX power domain reference only for the duration of DP AUX transfers. However, the following suggests that we also need these for main link functionality: - The specification doesn't state whether it's needed or not for main link functionality, but suggests that these power wells need to be enabled already during display core initialization (Sequences to Initialize Display). - For PSR we need to keep the AUX power well enabled. - On ICL combo PHY ports (non-TC) the AUX power well is needed for link training too: while the port is enabled with a DP link training test pattern trying to toggle the AUX power well will time out. - On ICL MG PHY ports (TC) the AUX power well is needed also for main link functionality (both in DP and HDMI modes). - Windows enables these power wells both for main and AUX lane functionality. Based on the above take an AUX power reference for main link functionality too. This makes a difference only on GEN10+ (GLK+) platforms, where we have separate port specific AUX power wells. For PSR we still need to distinguish between port A and the other ports, since on port A DC states must stay enabled for main link functionality, but DC states must be disabled for driver initiated AUX transfers. So re-use the corresponding helper from intel_psr.c. Since we take now a reference for main link functionality on all DP ports we can forgo taking the separate power ref for PSR functionality. v2: - Make sure DC states stay enabled when taking the ref on port A. (Ville) v3: (Ville) - Fix comment about logic for encoders without a crtc state and add FIXME note for a simplification to avoid calling get_power_domains in such cases. - Use intel_crtc_has_dp_encoder() instead !intel_crtc_has_type(HDMI). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> [Clarified code comments in intel_ddi_main_link_aux_domain() and intel_ddi_get_power_domains() (Imre)] Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180621184449.26634-1-imre.deak@intel.com
|
#
bb187e93 |
|
11-Jun-2018 |
James Ausmus <james.ausmus@intel.com> |
drm/i915/icl: DP_AUX_E is valid on ICL+ Add support for DP_AUX_E. Here we also introduce the bits for the AUX power well E, however ICL power well support is still not enabled yet, so the power well is not used. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180612002512.29783-2-paulo.r.zanoni@intel.com
|
#
13e1592f |
|
17-Apr-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add documentation to gen9_set_dc_state() Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180417113147.25120-1-imre.deak@intel.com
|
#
aa9664ff |
|
26-Apr-2018 |
Mahesh Kumar <mahesh1.kumar@intel.com> |
drm/i915/icl: Enable 2nd DBuf slice only when needed ICL has two slices of DBuf, each slice of size 1024 blocks. We should not always enable slice-2. It should be enabled only if display total required BW is > 12GBps OR more than 1 pipes are enabled. Changes since V1: - typecast total_data_rate to u64 before multiplication to solve any possible overflow (Rodrigo) - fix where skl_wm_get_hw_state was memsetting ddb, resulting enabled_slices to become zero - Fix the logic of calculating ddb_size Changes since V2: - If no-crtc is part of commit required_slices will have value "0", don't try to disable DBuf slice. Changes since V3: - Create a generic helper to enable/disable slice - don't return early if total_data_rate is 0, it may be cursor only commit, or atomic modeset without any plane. Changes since V4: - Solve checkpatch warnings - use kernel types u8/u64 instead of uint8_t/uint64_t Changes since V5: - Rebase Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-3-mahesh1.kumar@intel.com
|
#
74bd8004 |
|
26-Apr-2018 |
Mahesh Kumar <mahesh1.kumar@intel.com> |
drm/i915/icl: track dbuf slice-2 status This patch adds support to start tracking status of DBUF slices. This is foundation to introduce support for enabling/disabling second DBUF slice dynamically for ICL. Changes Since V1: - use kernel type u8 over uint8_t Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-2-mahesh1.kumar@intel.com
|
#
ac315c62 |
|
19-Apr-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Enable display WA#1183 from its correct spot The DMC FW specific part of display WA#1183 is supposed to be enabled whenever enabling DC5 or DC6, so move it to the DC6 enable function from the DC6 disable function. I noticed this after Daniel's patch to remove the unused skl_disable_dc6() function. Fixes: 53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com (cherry picked from commit b49be6622f08187129561cff0409f7b06b33de57) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
c4c25259 |
|
16-Apr-2018 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Remove skl dc6 enable/disable functions One is outright unused, other can be made static. Drive-by cleanup while accidentally reading dc code. Cc: Imre Deak <imre.deak@intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180417100225.12286-1-daniel.vetter@ffwll.ch
|
#
b49be662 |
|
19-Apr-2018 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Enable display WA#1183 from its correct spot The DMC FW specific part of display WA#1183 is supposed to be enabled whenever enabling DC5 or DC6, so move it to the DC6 enable function from the DC6 disable function. I noticed this after Daniel's patch to remove the unused skl_disable_dc6() function. Fixes: 53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com
|
#
b891d5e4 |
|
23-Feb-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/psr: New power domain for AUX IO. PSR on CNL requires AUX IO wells to be kept on and the existing AUX domain for AUX-A enables DC_OFF well too. This is not required, so add a new AUX_IO_A domain for AUX-A to allow DC states to remain enabled. Other AUX channels re-use the existing AUX domains. v4: Reword comment (Rodrigo and Ville) Rename _get and _put functions to include aux_io substring(Rodrigo) Remove unnecessary diff that got included. v3: Extract aux domain selection into a function (Ville) v2: Add AUX IO domain only for AUX-A Rebased on top of Ville's AUX series. Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180223221520.18464-1-dhinakaran.pandiyan@intel.com
|
#
acb79148 |
|
18-Feb-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_use As the driver is called to handle circumstances beyond it's control, we cannot assume that the pm_runtime core is happy to see us. For example, if we are called from shrink_slab to free up our pages during suspend, rpm may be disabled and pm_runtime_if_in_use() decides to fail with -EINVAL rather than simply say no. This is expected to happen, so don't warn. For example, [ 217.429228] Suspending console(s) (use no_console_suspend to debug) [ 217.557179] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 217.559399] sd 0:0:0:0: [sda] Stopping disk [ 218.661567] i915 0000:00:02.0: Resetting chip after gpu hang [ 219.523879] ------------[ cut here ]------------ [ 219.524474] pm_runtime_get_if_in_use() failed: -22 [ 219.524817] WARNING: CPU: 1 PID: 14 at drivers/gpu/drm/i915/intel_runtime_pm.c:3351 intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915] [ 219.524836] Modules linked in: vgem i915 snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec r8169 lpc_ich snd_hwdep mii snd_hda_core snd_pcm prime_numbers [ 219.525054] CPU: 1 PID: 14 Comm: cpuhp/1 Tainted: G U 4.16.0-rc1-g740f57c54ecf-kasan_6+ #1 [ 219.525070] Hardware name: /D510MO, BIOS MOPNV10J.86A.0311.2010.0802.2346 08/02/2010 [ 219.525294] RIP: 0010:intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915] [ 219.525313] RSP: 0018:ffff880018f5edf8 EFLAGS: 00010286 [ 219.525344] RAX: dffffc0000000008 RBX: ffff880007fc0000 RCX: 0000000000000000 [ 219.525361] RDX: 0000000000000001 RSI: ffffffff850609c0 RDI: ffffffff872992a0 [ 219.525377] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 219.525394] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880007fc0000 [ 219.525411] R13: ffff880018f5f0f8 R14: ffff880007fc8de8 R15: ffff880018f5f0f0 [ 219.525429] FS: 0000000000000000(0000) GS:ffff880019c80000(0000) knlGS:0000000000000000 [ 219.525446] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 219.525463] CR2: 0000564df7897e86 CR3: 0000000000d7c000 CR4: 00000000000006e0 [ 219.525478] Call Trace: [ 219.525734] i915_gem_shrink+0x841/0xb50 [i915] [ 219.525802] ? debug_check_no_locks_freed+0x2a0/0x2a0 [ 219.525842] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 219.526083] ? i915_gem_shrinker_count+0x2f0/0x2f0 [i915] [ 219.526131] ? lock_acquire+0x138/0x3c0 [ 219.526157] ? lock_acquire+0x138/0x3c0 [ 219.526391] ? shrinker_lock+0x49/0x210 [i915] [ 219.526465] ? mutex_trylock+0x15c/0x1a0 [ 219.526694] ? shrinker_lock+0x49/0x210 [i915] [ 219.526969] ? i915_gem_shrinker_scan+0xc4/0x320 [i915] [ 219.527200] i915_gem_shrinker_scan+0xc4/0x320 [i915] [ 219.527448] ? i915_gem_shrinker_vmap+0x3a0/0x3a0 [i915] [ 219.527533] shrink_slab.part.18+0x2d0/0x8d0 [ 219.527613] ? unregister_shrinker+0x1f0/0x1f0 [ 219.527668] ? mem_cgroup_iter+0x37d/0xc50 [ 219.527728] shrink_node+0x882/0xbe0 [ 219.527847] ? shrink_node_memcg+0x11c0/0x11c0 [ 219.527882] ? mark_held_locks+0xa8/0xf0 [ 219.527931] ? trace_hardirqs_on_caller+0x33f/0x590 [ 219.527961] ? ktime_get+0xad/0x140 [ 219.528015] do_try_to_free_pages+0x2d3/0xd70 [ 219.528099] ? allow_direct_reclaim.part.23+0x1d0/0x1d0 [ 219.528132] ? shrink_node+0xbe0/0xbe0 [ 219.528213] try_to_free_pages+0x1cd/0x570 [ 219.528257] ? do_try_to_free_pages+0xd70/0xd70 [ 219.528355] __alloc_pages_nodemask+0xadf/0x2110 [ 219.528423] ? unwind_next_frame+0x870/0x1970 [ 219.528465] ? deref_stack_reg+0x97/0xc0 [ 219.528503] ? gfp_pfmemalloc_allowed+0x150/0x150 [ 219.528539] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.528588] ? unwind_next_frame+0x138/0x1970 [ 219.528619] ? kthread+0x30a/0x3d0 [ 219.528677] ? __read_once_size_nocheck.constprop.4+0x10/0x10 [ 219.528698] ? deref_stack_reg+0xc0/0xc0 [ 219.528762] ? __save_stack_trace+0x6e/0xd0 [ 219.528822] depot_save_stack+0x3bc/0x430 [ 219.528870] kasan_kmalloc+0x142/0x170 [ 219.528912] ? __kmalloc+0xf7/0x340 [ 219.528935] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.528957] ? partition_sched_domains+0x4d4/0x840 [ 219.528978] ? sched_cpu_deactivate+0x11b/0x150 [ 219.529001] ? cpuhp_invoke_callback+0x160/0x15f0 [ 219.529023] ? cpuhp_thread_fun+0x35e/0x710 [ 219.529044] ? smpboot_thread_fn+0x50a/0x7f0 [ 219.529065] ? kthread+0x30a/0x3d0 [ 219.529086] ? ret_from_fork+0x24/0x50 [ 219.529141] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529169] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529198] ? set_track+0x87/0x100 [ 219.529225] ? init_object+0x6e/0x80 [ 219.529275] ? ___slab_alloc.constprop.36+0x232/0x3e0 [ 219.529303] ? ___slab_alloc.constprop.36+0x232/0x3e0 [ 219.529325] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529410] ? mark_held_locks+0xa8/0xf0 [ 219.529453] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529479] ? trace_hardirqs_on_caller+0x33f/0x590 [ 219.529532] __kmalloc+0xf7/0x340 [ 219.529557] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529604] register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529684] ? sched_debug_show+0x20/0x20 [ 219.529713] ? debug_object_activate+0x530/0x530 [ 219.529771] ? rcu_lockdep_current_cpu_online+0xdc/0x130 [ 219.529802] ? partition_sched_domains+0x4ae/0x840 [ 219.529825] ? rcu_read_lock_sched_held+0x10f/0x130 [ 219.529875] partition_sched_domains+0x4d4/0x840 [ 219.529955] ? sched_init_domains+0x110/0x110 [ 219.529981] ? __wait_rcu_gp+0x24f/0x390 [ 219.530054] sched_cpu_deactivate+0x11b/0x150 [ 219.530086] ? sched_cpu_activate+0x1e0/0x1e0 [ 219.530112] ? __call_rcu.constprop.53+0x680/0x680 [ 219.530132] ? call_rcu_bh+0x10/0x10 [ 219.530166] ? debug_check_no_locks_freed+0x2a0/0x2a0 [ 219.530201] ? trace_raw_output_rcu_utilization+0xa0/0xa0 [ 219.530267] ? trace_raw_output_rcu_utilization+0xa0/0xa0 [ 219.530337] ? rcu_lockdep_current_cpu_online+0xdc/0x130 [ 219.530370] ? sched_cpu_activate+0x1e0/0x1e0 [ 219.530397] cpuhp_invoke_callback+0x160/0x15f0 [ 219.530424] ? lock_acquire+0x138/0x3c0 [ 219.530445] ? lock_acquire+0x138/0x3c0 [ 219.530471] ? cpuhp_thread_fun+0xaf/0x710 [ 219.530507] ? pci_mmcfg_check_reserved+0x100/0x100 [ 219.530565] cpuhp_thread_fun+0x35e/0x710 [ 219.530618] ? cpuhp_complete_idle_dead+0x10/0x10 [ 219.530639] smpboot_thread_fn+0x50a/0x7f0 [ 219.530678] ? sort_range+0x20/0x20 [ 219.530709] ? __kthread_parkme+0xba/0x1f0 [ 219.530739] ? schedule+0x84/0x1a0 [ 219.530768] ? __kthread_parkme+0xbf/0x1f0 [ 219.530805] ? sort_range+0x20/0x20 [ 219.530831] kthread+0x30a/0x3d0 [ 219.530859] ? _kthread_create_on_node+0xb0/0xb0 [ 219.530900] ret_from_fork+0x24/0x50 [ 219.530999] Code: 01 00 00 00 85 c0 74 4a 89 e8 5b 5d c3 80 3d 48 37 4e 00 00 75 f2 89 c6 48 c7 c7 40 f0 61 c0 c6 05 36 37 4e 00 01 e8 ed 2a e1 c2 <0f> ff eb d9 80 3d 3f 37 4e 00 00 75 94 48 c7 c7 60 e8 61 c0 c6 [ 219.531880] ---[ end trace 18ec0139488ea0c8 ]--- [ 219.607967] IRQ 16: no longer affine to CPU1 [ 219.670291] IRQ 24: no longer affine to CPU2 [ 219.701489] IRQ 8: no longer affine to CPU3 [ 219.701529] IRQ 9: no longer affine to CPU3 [ 219.701582] IRQ 18: no longer affine to CPU3 [ 219.701640] IRQ 25: no longer affine to CPU3 [ 219.743857] cache: parent cpu1 should not be sleeping [ 219.784549] cache: parent cpu2 should not be sleeping [ 219.816041] cache: parent cpu3 should not be sleeping v2: Add Returns: information to intel_runtime_pm_get_if_in_use() kerneldoc. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219125046.19363-1-chris@chris-wilson.co.uk
|
#
4cb4585e |
|
05-Feb-2018 |
Mahesh Kumar <mahesh1.kumar@intel.com> |
drm/i915/icl: initialize MBus during display init This patch initializes MBus during display initialization. Changes since V2 (from Paulo): - Don't forget to remove the WARN_ON(1) call. Changes since V1: - Rebase to use function like Macros Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-6-paulo.r.zanoni@intel.com
|
#
746edf8f |
|
05-Feb-2018 |
Mahesh Kumar <mahesh1.kumar@intel.com> |
drm/i915/icl: Enable both DBuf slices during init ICL has 2 slices of DBuf, enable both the slices during display init. Ideally we should only enable the second slice when needed in order to save power, but while we're not there yet, adopt the simpler solution to keep us bug-free. v2 (from Paulo): - Add the TODO comment. - Reorganize where things are defined. - Fix indentation. - Remove unnecessary POSTING_READ() calls. - Improve the commit message. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-5-paulo.r.zanoni@intel.com
|
#
ad186f3f |
|
05-Feb-2018 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/icl: implement the display init/uninit sequences This code is similar enough to the CNL code that I considered just adding ICL support to the CNL function, but I think it's still different enough, and having a function specific to ICL allows us to more easily adapt code in case the spec changes more later. We're still missing the power wells and the mbus code, so leave those pieces with a FIXME comment while they're not here yet. v2: Don't use _PICK, don't WARN_ON(1), don't forget the chicken bits. v3: Use _MMIO_PORT() (Ville). Reviewed-by: James Ausmus <james.ausmus@intel.com> (v2) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-4-paulo.r.zanoni@intel.com
|
#
62d4a5e1 |
|
05-Feb-2018 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/icl: add ICL support to cnl_set_procmon_ref_values On ICL we have two sets of registers: one for port A and another for port B. The set of port A registers is the same as the CNL registers. Since the procmon table on ICL is the same we want to reuse the CNL function. To do that we add a port argument and make CNL always call the function passing port A. This way, we'll be able to easily reuse the function on ICL when we add icl_display_core_init(). v2: Don't use _PICK() when you can use a ternary operator. v3: Don't use a ternary operation when you can use _MMIO_PORT (Ville). Add an extra comment about why we're passing PORT_A (James). Reviewed-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-2-paulo.r.zanoni@intel.com
|
#
9787e835 |
|
29-Jan-2018 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Enable DDI-F on Cannonlake. Now let's finish the Port-F support by adding the proper port F detection, irq and power well support. v2: Rebase v3: Use BIT_ULL v4: Cover missed case on ddi init. v5: Update commit message. v6: Rebase on top of display headers rework. v7: Squash power-well handling related to DDI F to this patch to avoid warns as pointed out by DK. v8: Introduce DDI_F_LANES to PG2. (DK) v9: Squash in the PORT_F case for enabling DP MST encoder. (DK) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-9-rodrigo.vivi@intel.com
|
#
b1ae6a8b |
|
29-Jan-2018 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Extend Wa 1178 to Aux F. We also need to extend this WA to Aux F. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-3-rodrigo.vivi@intel.com
|
#
a324fcac |
|
29-Jan-2018 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Add AUX-F support On some Cannonlake SKUs we have a dedicated Aux for port F, that is only the full split between port A and port E. There is still no Aux E for Port E, as in previous platforms, because port_E still means shared lanes with port A. v2: Rebase. v3: Add couple missed PORT_F cases on intel_dp. v4: Rebase and fix commit message. v5: Squash Imre's "drm/i915: Add missing AUX_F power well string" v6: Rebase on top of display headers rework. v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK) v8: Fix Aux bits for Port F (DK) v9: Fix VBT definition of Port F (DK). v10: Squash power well addition to this patch to avoid warns as pointed by DK. v11: Clean up squashed commit message. (David) v12: Remove unnecessary handling for older platforms (DK) Adding AUX_F to PG2 following other existent ones. (DK) Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-2-rodrigo.vivi@intel.com
|
#
ddd39e4b |
|
28-Nov-2017 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/cnl: apply Display WA #1178 to fix type C dongles Display WA #1178 is meant to fix Aux channel voltage swing too low with some type C dongles. Although it is for type C, HW engineers reported that it can be applied to all external ports even if they are not going to type C. For CNL we apply the workaround every time Aux B, C and D are powering up since they will lose the configuration when powered down. v2: Use common tag for WA Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171128220553.22435-1-lucas.demarchi@intel.com
|
#
6e7a3f52 |
|
11-Jan-2018 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Apply headless DMC workaround for CNL With firmware 1.07 having fixed the state corruption issue, we can enable the headless GT performance workaround for CNL as well. (Equivalent to b68763741aa2 ("drm/i915: Restore GT performance in headless mode with DMC loaded") on other affected platforms.) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572 Testcase: igt/gem_exec_nop/headless Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180111082417.795-1-tvrtko.ursulin@linux.intel.com
|
#
30414f30 |
|
02-Jan-2018 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Apply Display WA #1183 on skl, kbl, and cfl Display WA #1183 was recently added to workaround "Failures when enabling DPLL0 with eDP link rate 2.16 or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz (CDCLK_CTL CD Frequency Select 10b or 11b) used in this enabling or in previous enabling." This workaround was designed to minimize the impact only to save the bad case with that link rates. But HW engineers indicated that it should be safe to apply broadly, although they were expecting the DPLL0 link rate to be unchanged on runtime. We need to cover 2 cases: when we are in fact enabling DPLL0 and when we are just changing the frequency with small differences. This is based on previous patch by Rodrigo Vivi with suggestions from Ville Syrjälä. Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com (cherry picked from commit 53421c2fe99ce16838639ad89d772d914a119a49) [ Lucas: Backport to 4.15 adding back variable that has been removed on commits not meant to be backported ] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180102201837.6812-1-lucas.demarchi@intel.com
|
#
3488d023 |
|
08-Dec-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disable DC states around GMBUS on GLK Prevent the DMC from destroying GMBUS transfers on GLK. GMBUS lives in PG1 so DC off is all we need. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> (cherry picked from commit 156961ae7bdf6feb72778e8da83d321b273343fd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
53421c2f |
|
04-Dec-2017 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Apply Display WA #1183 on skl, kbl, and cfl Display WA #1183 was recently added to workaround "Failures when enabling DPLL0 with eDP link rate 2.16 or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz (CDCLK_CTL CD Frequency Select 10b or 11b) used in this enabling or in previous enabling." This workaround was designed to minimize the impact only to save the bad case with that link rates. But HW engineers indicated that it should be safe to apply broadly, although they were expecting the DPLL0 link rate to be unchanged on runtime. We need to cover 2 cases: when we are in fact enabling DPLL0 and when we are just changing the frequency with small differences. This is based on previous patch by Rodrigo Vivi with suggestions from Ville Syrjälä. Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com
|
#
54c105d6 |
|
08-Dec-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: No need to power up PG2 for GMBUS on BXT GMBUS lives in PG1, so no need to power up PG2. We do want to prevent the DMC from making a mess of things though, so add GMBUS to the DC off power well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-2-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
|
#
156961ae |
|
08-Dec-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disable DC states around GMBUS on GLK Prevent the DMC from destroying GMBUS transfers on GLK. GMBUS lives in PG1 so DC off is all we need. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171208213739.16388-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
|
#
b6876374 |
|
05-Dec-2017 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Restore GT performance in headless mode with DMC loaded It seems that the DMC likes to transition between the DC states a lot when there are no connected displays (no active power domains) during command submission. This activity on DC states has a negative impact on the performance of the chip with huge latencies observed in the interrupt handlers and elsewhere. Simple tests like igt/gem_latency -n 0 are slowed down by a factor of eight. Work around it by introducing a new power domain named, POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is held for the duration of command submission activity. CNL has the same problem which will be addressed as a follow-up. Doing that requires a fix for a DC6 context corruption problem in the CNL DMC firmware which is yet to be released. v2: * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson) * Protect macro body with braces. (Jani Nikula) v3: * Add dedicated power domain for clarity. (Chris, Imre) * Commit message and comment text updates. * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC firmware release. v4: * Power domain should be inner to device runtime pm. (Chris) * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris) * Handle async DMC loading by moving the GT_IRQ power domain logic into intel_runtime_pm. (Daniel, Chris) * Include small core GEN9 as well. (Imre) v5 * Special handling for async DMC load is not needed since on failure the power domain reference is kept permanently taken. (Imre) v6: * Drop the NEEDS_CSR_GT_PERF_WA macro since all firmwares have now been deployed. (Imre, Chris) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572 Testcase: igt/gem_exec_nop/headless Cc: Imre Deak <imre.deak@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v5) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [Imre: Add note about applying the WA on CNL as a follow-up] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205132854.26380-1-tvrtko.ursulin@linux.intel.com
|
#
64600bd5 |
|
23-Oct-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Start tracking voltage level in the cdclk state For CNL we'll need to start considering the port clocks when we select the voltage level for the system agent. To that end start tracking the voltage in the cdclk state (since that already has to adjust it). v2: s/voltage/voltage_level/ (Rodrigo) Cc: Mika Kahola <mika.kahola@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-3-ville.syrjala@linux.intel.com
|
#
9f817501 |
|
10-Oct-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Move rps.hw_lock to dev_priv and s/hw_lock/pcu_lock In order to separate GT PM related functionality into new structure we are updating rps structure. hw_lock in it is used for display related PCU communication too hence move it to dev_priv. Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-8-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-7-chris@chris-wilson.co.uk
|
#
ad1443f0 |
|
10-Oct-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Name i915_runtime_pm structure in dev_priv as "runtime_pm" We were using dev_priv->pm for runtime power management related state. This patch renames it to "runtime_pm" which looks more apt. v2: s/rpm/runtime_pm (Chris) Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> #1 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-7-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-6-chris@chris-wilson.co.uk
|
#
de3ded0a |
|
02-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Silence compiler warning for hsw_power_well_enable() Not all compilers are able to determine that pg is guarded by wait_fuses and so may think that pg is used uninitialized. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: b2891eb2531e ("drm/i915/hsw+: Add has_fuses power well attribute") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171002100416.25865-1-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit 320671f94ada80ff036cc9d5dcd730ba4f3e0f1a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
320671f9 |
|
02-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Silence compiler warning for hsw_power_well_enable() Not all compilers are able to determine that pg is guarded by wait_fuses and so may think that pg is used uninitialized. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: b2891eb2531e ("drm/i915/hsw+: Add has_fuses power well attribute") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171002100416.25865-1-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
2a8408e5 |
|
02-Oct-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume The DMC firmware program memory is lost after S3/S4 system suspend, so we need to reprogram it during resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103070 Fixes: cebfcead63de ("drm/i915/DMC/CNL: Load DMC on CNL") Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171003095159.711-1-imre.deak@intel.com (cherry picked from commit 57522c4c87de20d8f7ad4e142a3a4334066d55ff) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
57522c4c |
|
02-Oct-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume The DMC firmware program memory is lost after S3/S4 system suspend, so we need to reprogram it during resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103070 Fixes: cebfcead63de ("drm/i915/DMC/CNL: Load DMC on CNL") Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171003095159.711-1-imre.deak@intel.com
|
#
4f044a88 |
|
19-Sep-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Rename global i915 to i915_modparams Our global struct with params is named exactly the same way as new preferred name for the drm_i915_private function parameter. To avoid such name reuse lets use different name for the global. v5: pure rename v6: fix Credits-to: Coccinelle @@ identifier n; @@ ( - i915.n + i915_modparams.n ) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170919193846.38060-1-michal.wajdeczko@intel.com
|
#
ade5ee7e |
|
21-Aug-2017 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/cnl: extract cnl_set_procmon_ref_values Move the part that reads the table and sets registers based on the table to its own function. v2: Rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170822000356.17330-2-rodrigo.vivi@intel.com
|
#
e0b8acf3 |
|
21-Aug-2017 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/cnl: simplify cnl_procmon_values handling Make it a little less magical and a little simpler and more hardcoded so we don't end up with an array that's composed mostly of empty entries. v2: Add an enum for the voltage+register values (Ville). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170822000356.17330-1-rodrigo.vivi@intel.com
|
#
9c3a16c8 |
|
14-Aug-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw+: Add support for multiple power well regs Future platforms increase the number of power wells which require additional control registers. A convenient way to select the correct register is to use the high bits of the power well ID as index. This patch only prepares for this, while upcoming platform enabling patches will add the actual new power well IDs and corresponding power well control registers. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-2-imre.deak@intel.com
|
#
0a445945 |
|
14-Aug-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Work around GCC anonymous union initialization bug GCC 4.4 can't cope with anonymous union initializers which seems to be a bug in that version (see the Reference) and is fixed since GCC version 4.6. A workaround which is also used elsewhere in the kernel for the same purpose is to wrap the initialization in curly braces, so do the same here. Fixes: b5565a2efc12 ("drm/i915/bxt, glk: Give a proper name to the power well struct phy field") Reference: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676 Reported-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-1-imre.deak@intel.com
|
#
ea46708f |
|
08-Aug-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Removing missing DDI_E bits from CNL. DDI_E is not supported on CNL-U and CNL-Y When adding the initial support we noticed DDI_E wasn't supported and removed it on v4 and v5 of that patch. However for some reason I missed or put back these 2 chunks. Time to clean it up to avoid later confusion. Fixes: 8bcd3dd41766 ("drm/i915/cnl: Add power wells for CNL") Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808193237.17410-1-rodrigo.vivi@intel.com
|
#
746a5173 |
|
14-Jul-2017 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions * Don't define it twice. * Define MSBs first, like the rest of i915_reg.h. * Add CNL_ prefix to the bit that arrived in CNL. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170714175228.27019-1-paulo.r.zanoni@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
965a79ad |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Gather all the power well->domain mappings to one place Shuffle the power well->domain mapping macros around so they are at one place in old->new GEN order. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-19-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d42539ba |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Move hsw_power_well_enable() next to the rest of HSW helpers Move the helper next to the rest of HSW specific code. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-18-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4196b918 |
|
11-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9+: Unify the HSW/BDW and GEN9+ power well helpers After the previous refactorings the HSW/BDW and GEN9+ power well helpers are practically identical, so use the HSW power well helpers for GEN9+ too. This means using the HSW power well ops instead of the SKL one and setting the irq_pipe_mask, has_vga and has_fuses attributes as needed. v2: - Rebased on v2 of patch 15. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-7-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b2891eb2 |
|
11-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw+: Add has_fuses power well attribute The pattern of a power well backing a set of fuses whose initialization we need to wait for during power well enabling is common to all GEN9+ platforms. Adding support for this to the HSW power well enable helper allows us to use the HSW/BDW power well code for GEN9+ as well in a follow-up patch. v2: - Use an enum for power gates instead of raw numbers. (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-6-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
76347c04 |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw, bdw: Wait for the power well disabled state Similarly to GEN9+ waiting for the power well disabled state is a safer option and also provides diagnostic info if the disabling didn't succeed or the power well was forced on by an external requester. While at it also use the existing GEN9+ helper to wait for the enabled state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-15-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
001bd2cb |
|
12-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw, bdw: Add irq_pipe_mask, has_vga power well attributes The pattern of a power well backing a set of pipe IRQ or VGA functionality applies to all HSW+ platforms. Using power well attributes instead of platform checks to decide whether to init/reset pipe IRQs and VGA correspondingly is cleaner and it allows us to unify the HSW/BDW and GEN9+ power well code in follow-up patches. Also use u8 for pipe_mask in related helpers to match the type in the power well struct. v2: - Use u8 instead of u32 for irq_pipe_mask. (Ville) v3: - Use u8 for pipe_mask in related helpers too for clarity. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170712155413.29839-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1af474fe |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw+: Unify the hsw/bdw and gen9+ power well req/state macros Although on HSW/BDW there is only a single display global power well, it's programmed the same way as other GEN9+ power wells. This also means we can get at the HSW/BDW request and status flags the same way it's done on GEN9+ by assigning the corresponding HSW/BDW power well ID. This ID was assigned in a recent patch, so we can now switch to using the same macros everywhere on HSW+. Updating the HSW power well control register with RMW is not strictly necessary, but this will allow us to use the same code for GEN9+. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-13-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ec46d483 |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw, bdw: Split power well set to enable/disable helpers We can reduce the code indentation by splitting the set helper to separate enable/disable helpers. This also allows us to unify the HSW/BDW and GEN9+ power well ops in follow-up patches, which introduces some differences between the enable and disable helpers. While at it also remove the redundant enable/disable debug messages, the same info is printed already elsewhere. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-12-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
00742cab |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw, bdw: Remove redundant state check during power well toggling Similarly to the GEN9 power well toggling, saving an occasional extra MMIO write is not worth the code complexity, let's simplify things. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-11-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9137726a |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9+: Remove redundant state check during power well toggling Atm we enable/disable a power well only if it wasn't already enabled/disabled respectively. The only reason for this I can think of is to save the extra MMIO writes. Since the HW state matches the power well's usage counter most of the time the overhead due to these MMIOs is insignificant. Let's simplify the code by making the writes unconditional. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-10-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2efbda72 |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9+: Remove redundant power well state assert during enabling We check already for power wells that are unexpectedly on (or forced on) during power well disabling. Those checks also account for other power well requesters like KVMR or DEBUG. As such this check is redundant, let's remove it to simplify things. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-9-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b5565a2e |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt, glk: Give a proper name to the power well struct phy field Follow-up patches will add new fields to the i915_power_well struct that are specific to the hsw_power_well_ops helpers. Prepare for this by changing the generic 'data' field to a union of platform specific structs. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-8-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
21792c60 |
|
11-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Check for duplicated power well IDs Check that all the power well IDs are unique on the given platform. v2: - Fix using BIT_ULL() instead of BIT() for 64 bit mask. v3: - Move the check to a separate function. (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-4-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fb9248e2 |
|
11-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw, bdw: Add an ID for the global display power well Add an ID for the HSW/BDW global display power well for consistency. The ID is selected so that it can be used to get at the HW request and status flags with the corresponding GEN9+ macros. Unifying the HSW/BDW and GEN9+ versions of these macros and the power well ops using them will be done in follow-up patches. v2: - Rebased on v2 of patch 2. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-3-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
120b56a2 |
|
11-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen2: Add an ID for the display pipes power well Make the I830 power well ID assignment explicit for consistency. v2: - s/GEN2/I830/ in the comment, since other GEN2s don't have the power well. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-2-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
029d80d0 |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Assign everywhere the always-on power well ID Power well IDs are used for lookup so they must be unique. To ensure this assign the always-on power well ID everywhere where it's missing. This didn't cause a problem so far, since we didn't need to look up power wells that happened to share their IDs. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-4-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
438b8dc4 |
|
11-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Unify power well ID enums Atm, the power well IDs are defined in separate platform specific enums, which isn't ideal for the following reasons: - the IDs are used by helpers like lookup_power_well() in a platform independent way - the always-on power well is used by multiple platforms and so needs now separate IDs, although these IDs refer to the same thing To make things more consistent use a single enum instead of the two separate ones, listing the IDs per platform (or set of very similar platforms like all GEN9/10). Replace the separate always-on power well IDs with a single ID. While at it also add a note clarifying the distinction between regular power wells that follow a common programming pattern and custom ones that are programmed in some other way. The IDs for regular power wells need to stay fixed, since they also define the request and state HW flag positions in their corresponding power well control register(s). v2: - Add comment about id to req,status bit mapping to the enum. (Rodrigo) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f49193cd |
|
06-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/chv: Add unique power well ID for the pipe A power well The power well IDs are used for lookup, so they must be unique on a given platform; ensure this on CHV. This didn't cause an actual problem since we didn't need to look up power wells which happened to share an ID. Mark this new power well as custom, since its programming pattern doesn't follow that of the rest of VLV/CHV power wells. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-2-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6d6a8970 |
|
06-Jul-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Add max allowed Cannonlake DC. This is a follow-up after enabling DC states with commit: "drm/i915/DMC/CNL: Load DMC on CNL". Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499373908-26761-1-git-send-email-rodrigo.vivi@intel.com
|
#
b38131fb |
|
29-Jun-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/cnl: Fix comment about AUX IO power well enable/disable The comments match an earlier version of the patch, fix them to match the current state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-6-git-send-email-imre.deak@intel.com
|
#
42d9366d |
|
29-Jun-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9+: Don't remove secondary power well requests So far in an attempt to make sure all power wells get disabled during display uninitialization the driver removed any secondary request bits (BIOS, KVMR, DEBUG) that were set for a given power well. The known source for these requests was DMC's request on power well 1 and the misc IO power well. Since DMC is inactive (DC states are disabled) at the point we disable these power wells, there shouldn't be any reason to leave them on. However there are two problems with the above assumption: Bspec requires that the misc IO power well stays enabled (without providing a reason) and there can be KVMR requests that we can't remove anyway (the KVMR request register is R/O). Atm, a KVMR request can trigger a timeout WARN when trying to disable power wells. To make the code aligned to Bspec and to get rid of the KVMR WARN, don't try to remove the secondary requests, only detect them and stop polling for the power well disabled state when any one is set. Also add a comment about the timeout values required by Bspec when enabling power wells and the fact that waiting for them to get disabled is not required by Bspec. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98564 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-5-git-send-email-imre.deak@intel.com
|
#
e8a3a2a3 |
|
29-Jun-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt, glk: Fix assert on conditions for DC9 enabling What we want to assert based on the conditions required by Bspec is that power well 2 is disabled, so no need to check for other power wells. In addition we can only check if the driver's request is removed, the actual state depends on whether the other request bits are set or not (BIOS, KVMR, DEBUG). So check only the driver's request bit. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-4-git-send-email-imre.deak@intel.com
|
#
edfda8e3 |
|
29-Jun-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: Don't disable misc IO power well during display uninit Bspec requires leaving the misc IO power well enabled during display uninit, so align the code accordingly. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-3-git-send-email-imre.deak@intel.com
|
#
846c6b26 |
|
29-Jun-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9+: Add 10 us delay after power well 1/AUX IO pw disabling Bspec requires a 10 us delay after disabling power well 1 and - if not toggled on-demand - the AUX IO power wells during display uninit. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-2-git-send-email-imre.deak@intel.com
|
#
2ee0da16 |
|
01-Jun-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add i830 "pipes power well" 830 more or less requires both pipes and DPLLs to remain on as long as either pipe is needed. However, when neither pipe is actually needed, we can save a bit of power by turning everything off. To do that we add a new "power well" that turns both pipes and DPLLs on and off in the right order. Seems to save ~50mW on my Fujitsu-Siemens Lifebook S6010. This also avoids having to abuse the load detection to force pipe A on at init time. That was never very robust, and it only worked for one pipe, whereas 830 really needs both pipes enabled. As a bonus the 830 pipe quirk is now a bit more isolated from the rest of the mode setting infrastructure, which should mean that it's much less likely someone will accidentally break it in the future. The extra cost is of course slight code duplication, but that seems like a worthwile tradeoff here. v2; s/BIT/BIT_ULL/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-5-ville.syrjala@linux.intel.com Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
d8d4a512 |
|
09-Jun-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/cnl: Implement CNL display init/unit sequence Implement the CNL display init/uninit sequence as outlined in Bspec. Quite similar to SKL/BXT. The main complicaiton is probably the extra procmon setup we must do based on the process/voltage information we can read out from some register. v2: s/skl_dbuf/gen9_dbuf/ to follow upstream bxt needed a cdclk sanitize step, so let's add it for cnl too v3: s/CHICKEN_MISC_1/CHICKEN_MISC_2/ (Ander) v4: Rebased by Rodrigo after Ville's cdclk rework v5: Removed unecessary Aux IO forced enable/disable, Fix DW10 setup Fix procpon Mask. (Credits-to Paulo and Clint) Remove A0 workaround. v6: Rebased on top of recent code (Rodrigo). v7: Respect the order of sanitize_ after set_ (Done by Rodrigo, Requested by Ville) v8: Commit message updated to matvh v5 changes besides Remove unused DW8 and an extra blank line. (all noticed by Imre). v9: Remove __attribute__((unused)) added on latest version of drm/i915/cnl: Implement .set_cdclk() for CNL. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-3-git-send-email-rodrigo.vivi@intel.com
|
#
bf9a496a |
|
06-Jun-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Also need power well sanitize. The workaround added in commit c6782b76d31a ("drm/i915/gen9: Reset secondary power well equests left on by DMC/KVMR") needs to be applied on Cannonlake as well. So let's assume any platform using this power well setup will also need and let's just go ahead and remove if condition. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1496781040-20888-11-git-send-email-rodrigo.vivi@intel.com
|
#
8bcd3dd4 |
|
06-Jun-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/cnl: Add power wells for CNL CNL power wells are very similar to SKL, with the exception that the misc IO well has been split into separate AUX IO wells. Not sure if DMC is supposed to manage the AUX wells for us or not. Let's assume so for now. v2: DDI A power well wants DDI A domains, not DDI B domains v3: s/BIT/BIT_ULL and add proper Aux IO domains. (Rodrigo) v4: Remove PW_DDI_E. Not supported on Current CNL SKUs. (Rodrigo). v5: Removed DDI_E_IO_DOMAINS and moved PORT_DDI_E_IO to DDI_A_IO for the same reasons as v4 when we found out that current CNL SKUs don't have the full port E split. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1496781040-20888-10-git-send-email-rodrigo.vivi@intel.com
|
#
f5073824 |
|
27-Mar-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: WARN if the core runtime PM get helpers fail We don't expect the core runtime PM get helpers to return any error, so add a WARN for this. Also print the return value for all the callsites to help debugging. v2: - Don't call pm_runtime_get_sync() as part of initing locals. (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1490693935-12638-1-git-send-email-imre.deak@intel.com
|
#
62b69566 |
|
24-Feb-2017 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Only enable DDI IO power domains after enabling DPLL According to bspec, the DDI IO power domains should be enabled after enabling the DPLL and mapping it to the DDI. The current order doesn't seem to create problems with Skylake and Kabylake, but causes enable timeouts in Geminilake. v2: Rebase. - Take power domain references before sanitizing encoders. (Imre) - Add comment to get_encoder_power_domains() defition. (Ander) v3: Don't put the domain if called with HSW/BDW's analog encoder. (CI) v4: Put IO power domain before unmapping DPLL. (Imre) - Change return type of intel_ddi_get_power_domains() to u64. (Imre) Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> # v1 Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170224141959.5955-1-ander.conselvan.de.oliveira@intel.com
|
#
71cc22e5 |
|
21-Feb-2017 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915/glk: Don't enable DDI IO power domains during init In Geminilake, the DDI IO power domains can't be enabled before a DPLL is running and mapped to the appropriate DDI. At least on Geminilake, attempting to enable those during init will lead to a timeout. The failure to enable the power domain also causes issues with the state verifier during resume from suspend. After all the init power domains are enabled, the call to intel_power_domains_sync_hw() from the resume path will cause the hw_enabled field on the respective power wells to be false while the usage count remains above zero. Further attempts to enable the power domain caused by a modeset will simply update the usage count without doing anything else. When the state verifier attempts to read the state of a DDI encoder, intel_display_power_get_if_enabled() returns false, leading to the following WARN: WARNING: CPU: 3 PID: 1743 at drivers/gpu/drm/i915/intel_display.c:7001 verify_connector_state.isra.80+0x26c/0x2b0 [i915] attached crtc is active, but connector isn't Modules linked in: i915(E) tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge stp llc ebtable_nat ip6table_mangle ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw iptable_mangle iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables x86_pkg_temp_thermal coretemp kvm_intel kvm i2c_algo_bit drm_kms_helper irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drm shpchp tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc crc32c_intel serio_raw [last unloaded: i915] CPU: 3 PID: 1743 Comm: kworker/u8:22 Tainted: G W E 4.10.0-rc3ander+ #300 Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0023.B40.1611302145 11/30/2016 Workqueue: events_unbound async_run_entry_fn Call Trace: dump_stack+0x86/0xc3 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 verify_connector_state.isra.80+0x26c/0x2b0 [i915] intel_atomic_commit_tail+0x520/0x1000 [i915] ? remove_wait_queue+0x70/0x70 intel_atomic_commit+0x3f8/0x520 [i915] ? intel_runtime_pm_put+0x6e/0xa0 [i915] drm_atomic_commit+0x4b/0x50 [drm] __intel_display_resume+0x72/0xc0 [i915] intel_display_resume+0x107/0x150 [i915] i915_drm_resume+0xe0/0x180 [i915] i915_pm_restore+0x1e/0x30 [i915] i915_pm_resume+0xe/0x10 [i915] pci_pm_resume+0x64/0xa0 dpm_run_callback+0xa1/0x2a0 ? pci_pm_thaw+0x90/0x90 device_resume+0xe3/0x200 async_resume+0x1d/0x50 async_run_entry_fn+0x39/0x170 process_one_work+0x212/0x670 ? process_one_work+0x197/0x670 worker_thread+0x4e/0x490 kthread+0x101/0x140 ? process_one_work+0x670/0x670 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x2a/0x40 Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-6-ander.conselvan.de.oliveira@intel.com
|
#
8d8c386c |
|
17-Feb-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add power well SW/HW state verification Verify that the refcount of all power wells match their HW enabled state at the end of modeset HW state readout. Also add documentation on how the reference count for each power well is supposed to be acquired during initialization and HW state readout. Suggested by Ander. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487345986-26511-6-git-send-email-imre.deak@intel.com
|
#
16e84914 |
|
17-Feb-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Preserve the state of power wells not explicitly enabled Atm, power wells that BIOS has enabled, but which we don't explicitly enable during power domain initialization would get disabled as we clear the BIOS request bit in the given power well sync_hw hook. To prevent this copy over any set request bits in the BIOS request register to the driver request register and clear the BIOS request bit only afterwards. This doesn't make a difference now, since we enable all power wells during power domain initialization. A follow-up patchset will add power wells for which this isn't true, so fix up the inconsistency. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487345986-26511-5-git-send-email-imre.deak@intel.com
|
#
14544e13 |
|
17-Feb-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Fix clearing of the BIOS power well request register Atm, in the power well sync_hw hook we are clearing all BIOS request bits, not just the one corresponding to the given power well. This could turn off an unrelated power well inadvertently if it didn't have a request bit set in the driver request register. This didn't cause a problem so far, since we enabled all power wells explicitly before clearing the BIOS request register. A follow-up patchset will add power wells that won't get enabled this way, so fix up the inconsistency. Note that this patch only makes the clearing of the BIOS req register more logical. Power wells without a reference would still get disabled by the end of power domain initialization, that is fixed by the next patch. v2: - Clarify in the commit log that this patch doesn't address the case of power wells without a reference. (Ander) Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487345986-26511-4-git-send-email-imre.deak@intel.com
|
#
75ccb2ec |
|
17-Feb-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Call the sync_hw hook for power wells without a domain So far the sync_hw hook wasn't called for power wells not belonging to any power domain, that is the GEN9 PW1 and MISC_IO power wells. This wasn't a problem so far since the goal of the sync_hw hook - to clear the corresponding BIOS request bit - was guaranteed by clearing the whole BIOS request register elsewhere. This will change with the next patch, so fix up the inconsistency. While at it clean up the power well iterator helpers and move them to the rest of iterators. v2: - Clean up the power well iterator helpers. (Ander) - Move the helpers to i915_drv.h. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487345986-26511-3-git-send-email-imre.deak@intel.com
|
#
3c1b38e6 |
|
17-Feb-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Remove redundant toggling from the power well sync_hw hooks Doing an explicit enable/disable in the power well sync_hw hook based on the power well's reference count is redundant, since by the time these hooks are called all the power wells are enabled and have a reference. So remove the redundant toggling. This is needed by a follow-up patchset that adds power wells which we can't enable/disable during power domain initialization and so want to preserve their state until modeset init time. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487345986-26511-2-git-send-email-imre.deak@intel.com
|
#
d8fc70b7 |
|
09-Feb-2017 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Make power domain masks 64 bit long There are currently 30 power domains, which puts us pretty close to the limit with 32 bit masks. Prepare for the future and increase the limit to 64 bit. v2: Rebase v3: s/unsigned long long/u64/ (Joonas) Allow the 64th bit of the mask to be used. (Joonas) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170209093121.24410-1-ander.conselvan.de.oliveira@intel.com
|
#
49cd97a3 |
|
07-Feb-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Start moving the cdclk stuff into a distinct state structure Introduce intel_cdclk state which for now will track the cdclk frequency, the vco frequency and the reference frequency (not sure we want the last one, but I put it there anyway). We'll also make the .get_cdclk() function fill out this state structure rather than just returning the current cdclk frequency. One immediate benefit is that calling .get_cdclk() will no longer clobber state stored under dev_priv unless ex[plicitly told to do so. Previously it clobbered the vco and reference clocks stored there on some platforms. We'll expand the use of this structure to actually precomputing the state and whatnot later. v2: Constify intel_cdclk_state_compare() v3: Document intel_cdclk_state_compare() v4: Deal with i945gm_get_cdclk() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207183345.19763-1-ville.syrjala@linux.intel.com
|
#
c49a0d05 |
|
07-Feb-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/get_display_clock_speed/get_cdclk/ Rename the .get_display_clock_speed() hook to .get_cdclk(). .get_cdclk() is more specific (which clock) and it's much shorter. v2: Deal with IS_GEN9_BC() v3: Deal with i945gm_get_display_clock_speed() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207183146.19420-1-ville.syrjala@linux.intel.com
|
#
3c779a49 |
|
08-Feb-2017 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
drm/i915: Avoid BIT(max) - 1 and use GENMASK(max - 1, 0) "BIT(max) - 1" will overflow when max = 32, and GCC will complain. We already have GENMASK for generating the mask, use it! v2: Majestic off by one spotted (Chris) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b976dc53 |
|
23-Jan-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Introduce IS_GEN9_BC for Skylake and Kabylake. Along with GLK it was introduced the .is_lp and IS_GEN9_LP. So, following the same simplification standard we can put Skylake and Kabylake under the same bucket for most of the things. So let's add the IS_GEN9_BC for "Big Core" (non Atom based platforms). The i915_drv.c was let out of this patch on purpose because that is really a decision per platform, just like other cases where IS_KABYLAKE is different from IS_SKYLAKE. v2: fix conflict with IS_LP and 3 new cases for this big core bucket: - intel_ddi.c: intel_ddi_get_link_dpll - intel_fbc.c: find_compression_threshold - i915_gem_gtt.c: gtt_write_workarounds Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485196357-30599-2-git-send-email-rodrigo.vivi@intel.com
|
#
bb98e72a |
|
02-Dec-2016 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by vlv_init_display_clock_gating() clearing the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled driving the DSI LCD by the BIOS. Clearing this bit while DSI is in use is a known issue and intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it as appropriate. This commit modifies vlv_init_display_clock_gating() to leave the DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck. Changes in v2: -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
721d4845 |
|
02-Dec-2016 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by vlv_init_display_clock_gating() clearing the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled driving the DSI LCD by the BIOS. Clearing this bit while DSI is in use is a known issue and intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it as appropriate. This commit modifies vlv_init_display_clock_gating() to leave the DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck. Changes in v2: -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
b817c440 |
|
02-Dec-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915/glk: Implement core display init/uninit sequence for geminilake The sequence is pretty much the same as broxton, except that bspec requires the AUX domains to be enabled. But since those can't be enabled before the phys are initialized, we just use the same sequence as broxton. v2: Don't manually enable AUX domains. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-9-git-send-email-ander.conselvan.de.oliveira@intel.com
|
#
0a116ce8 |
|
02-Dec-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915/glk: Implement Geminilake DDI init sequence Implement the DDI initsequence and add information about the different phys in GLK. v2: Rebase on the move of phys to be power wells. v3: Rebase on addition of struct bxt_ddi_phy_info. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-4-git-send-email-ander.conselvan.de.oliveira@intel.com
|
#
0d03926d |
|
02-Dec-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915/glk: Add power wells for Geminilake Geminilake has power wells are similar to SKL, but with the misc IO well being split into separate AUX IO wells. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-3-git-send-email-ander.conselvan.de.oliveira@intel.com
|
#
cc3f90f0 |
|
02-Dec-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915/glk: Reuse broxton code for geminilake Geminilake is mostly backwards compatible with broxton, so change most of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the platforms will be implemented in follow-up patches. v2: Don't reuse broxton's path in intel_update_max_cdclk(). Don't set plane count as in broxton. v3: Rebase v4: Include the check intel_bios_is_port_hpd_inverted(). Commit message. v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo) v6: Rebase. v7: Convert a few mode IS_BROXTON() occurances in pps, ddi, dsi and pll code. (Rodrigo) v8: Squash a couple of DDI patches with more conversions. (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-2-git-send-email-ander.conselvan.de.oliveira@intel.com
|
#
801388cb |
|
16-Nov-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Fix for_each_pipe argument in vlv_display_power_well_init Macro takes dev_priv and not dev. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
29b74b7f |
|
16-Nov-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: dev_priv cleanup in i915_suspend.c And a little bit of function prototype changes. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
cdffe3e2 |
|
25-Oct-2016 |
Lyude <lyude@redhat.com> |
drm/i915/vlv: Prevent enabling hpd polling in late suspend One of the CI machines began to run into issues with the hpd poller suddenly waking up in the midst of the late suspend phase. It looks like this is getting caused by the fact we now deinitialize power wells in late suspend, which means that intel_hpd_poll_init() gets called in late suspend causing polling to get re-enabled. So, when deinitializing power wells on valleyview we now refrain from enabling polling in the midst of suspend. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040 Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd") Signed-off-by: Lyude <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Petry Latvala <petri.latvala@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/1477499769-1966-1-git-send-email-lyude@redhat.com (cherry picked from commit b64b540931483cca3200d98756bed6ad0e01d75c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
1353c4fb |
|
31-Oct-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass dev_priv to .get_display_clock_speed() Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477946245-14134-15-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b64b5409 |
|
25-Oct-2016 |
Lyude <lyude@redhat.com> |
drm/i915/vlv: Prevent enabling hpd polling in late suspend One of the CI machines began to run into issues with the hpd poller suddenly waking up in the midst of the late suspend phase. It looks like this is getting caused by the fact we now deinitialize power wells in late suspend, which means that intel_hpd_poll_init() gets called in late suspend causing polling to get re-enabled. So, when deinitializing power wells on valleyview we now refrain from enabling polling in the midst of suspend. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040 Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd") Signed-off-by: Lyude <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Petry Latvala <petri.latvala@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/1477499769-1966-1-git-send-email-lyude@redhat.com
|
#
e7583f7b |
|
06-Oct-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Add location of the Rcomp resistor to bxt_ddi_phy_info Use struct bxt_ddi_phy_info to hold information of where the Rcomp resistor is located, instead of hard coding it in the init sequence. Note that this moves the enabling of the phy with the Rcomp resistor out of the power well enable code. That should be safe since bxt_ddi_phy_init() is called while the power domains lock is held, and that is the only way that function gets called, so there is no possibility of a concurrent phy enable caused by a power domain get call. v2: Replace comment about lock with lockdep_assert_held() (Imre) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/62d209950ad48484564f3e793cf247cf62572a39.1475770848.git-series.ander.conselvan.de.oliveira@intel.com
|
#
362624c9 |
|
06-Oct-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Explicitly map broxton DPIO power wells to phys The mapping from the BXT_DPIO_CMN_* power wells to their respective phys required a detour implemented in the bxt_power_well_to_phy() function. Instead, embed that information directly into the power_well struct, by resurrecting the data field. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/7fe97582fa08c7340ce6a3b6b0ea3e72a73182d7.1475770848.git-series.ander.conselvan.de.oliveira@intel.com
|
#
01c3faa7 |
|
06-Oct-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Rename struct i915_power_well field data to id Calling it data seems to imply arbitrary data can be associated with the power well. However, that field is used for look ups and expected to be unique, so rename it. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/f3916c3c5bfa793b0fc870fd44007a3ff425194d.1475770848.git-series.ander.conselvan.de.oliveira@intel.com
|
#
2eedfc7d |
|
24-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove RPM sequence checking We only used the RPM sequence checking inside the lowlevel GTT accessors, when we had to rely on callers taking the wakeref on our behalf. Now that we take the RPM wakeref inside the GTT management routines themselves, we can forgo the sanitycheck of the callers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161024124218.18252-4-chris@chris-wilson.co.uk
|
#
11a914c2 |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_VALLEYVIEW only take dev_priv Saves 944 bytes of .rodata strings and 128 bytes of .text. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
920a14b2 |
|
14-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_CHERRYVIEW only take dev_priv Saves 864 bytes of .rodata strings and ~100 of .text. v2: Add parantheses around dev_priv. (Ville Syrjala) v3: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
e2d214ae |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_BROXTON only take dev_priv Saves 1392 bytes of .rodata strings. Also change a few function/macro prototypes in i915_gem_gtt.c from dev to dev_priv where it made more sense to do so. v2: Add parantheses around dev_priv. (Ville Syrjala) v3: Mention function prototype changes. (David Weinehall) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
|
#
0853723b |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_KABYLAKE only take dev_priv Saves 1320 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
8652744b |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_BROADWELL only take dev_priv Saves 1808 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
6772ffe0 |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make HAS_RUNTIME_PM only take dev_priv Saves 960 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
52a05c30 |
|
22-Aug-2016 |
David Weinehall <david.weinehall@linux.intel.com> |
drm/i915: pdev cleanup In an effort to simplify things for a future push of dev_priv instead of dev wherever possible, always take pdev via dev_priv where feasible, eliminating the direct access from dev. Right now this only eliminates a few cases of dev, but it also obviates that we pass dev into a lot of functions where dev_priv would be the more obvious choice. v2: Fixed one more place missing in the previous patch set Signed-off-by: David Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160822103245.24069-5-david.weinehall@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
c49d13ee |
|
22-Aug-2016 |
David Weinehall <david.weinehall@linux.intel.com> |
drm/i915: consistent struct device naming We currently have a mix of struct device *device, struct device *kdev, and struct device *dev (the latter forcing us to refer to struct drm_device as something else than the normal dev). To simplify things, always use kdev when referring to struct device. v2: Replace the dev_to_drm_minor() macro with the inline function kdev_to_drm_minor(). Signed-off-by: David Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160822103245.24069-3-david.weinehall@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
ca99d878 |
|
15-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Silence GCC warning for cmn_a_well Just make the logic simple enough for even GCC to understand (and foolproof against random changes): drivers/gpu/drm/i915/intel_runtime_pm.c: warning: 'cmn_a_well' may be used uninitialized in this function [-Wuninitialized]: => 871:23 Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1471284383-22324-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
8090ba8c |
|
10-Aug-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Apply the PPS register unlock workaround more consistently Atm, we apply this workaround somewhat inconsistently at the following points: driver loading, LVDS init, eDP PPS init, system resume. As this workaround also affects registers other than PPS (timing, PLL) a more consistent way is to apply it early after the PPS HW context is known to be lost: driver loading, system resume and on VLV/CHV/BXT when turning on power domains. This is needed by the next patch that removes saving/restoring of the PP_CONTROL register. This also removes the incorrect programming of the workaround on HSW+ PCH platforms which don't have the register locking mechanism. v2: (Ville) - Don't apply the workaround on BXT. - Simplify platform checks using HAS_DDI(). v3: - Move the call of intel_pps_unlock_regs_wa() to the more logical vlv_display_power_well_init() (also fixing CHV) (Ville). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470827254-21954-5-git-send-email-imre.deak@intel.com
|
#
84c8e096 |
|
21-Jun-2016 |
Lyude <cpaul@redhat.com> |
drm/i915: Enable polling when we don't have hpd Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get their display to turn on. For instance; if we boot a Valleyview system without any monitors connected, it won't need any of it's power wells and thus shut them off. Since this causes us to lose HPD, this means that unless the user knows how to ssh into their machine and do a manual reprobe for monitors, none of the monitors they connect after booting will actually work. Eventually we should come up with a better fix then having to enable polling for this, since this makes rpm a lot less useful, but for now the infrastructure in i915 just isn't there yet to get hpd in these situations. Changes since v1: - Add comment explaining the addition of the if (!mode_config->poll_running) in intel_hpd_init() - Remove unneeded if (!dev->mode_config.poll_enabled) in i915_hpd_poll_init_work() - Call to drm_helper_hpd_irq_event() after we disable polling - Add cancel_work_sync() call to intel_hpd_cancel_work() Changes since v2: - Apparently dev->mode_config.poll_running doesn't actually reflect whether or not a poll is currently in progress, and is actually used for dynamic module paramter enabling/disabling. So now we instead keep track of our own poll_running variable in dev_priv->hotplug - Clean i915_hpd_poll_init_work() a little bit Changes since v3: - Remove the now-redundant connector loop in intel_hpd_init(), just rely on intel_hpd_poll_enable() for setting connector->polled correctly on each connector - Get rid of poll_running - Don't assign enabled in i915_hpd_poll_init_work before we actually lock dev->mode_config.mutex - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE() for doc purposes - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in intel_hpd_poll_enable() - Add some comments about racing not mattering in intel_hpd_poll_enable Changes since v4: - Rename intel_hpd_poll_enable() to intel_hpd_poll_init() - Drop the bool argument from intel_hpd_poll_init() - Remove redundant calls to intel_hpd_poll_init() - Rename poll_enable_work to poll_init_work - Add some kerneldoc for intel_hpd_poll_init() - Cross-reference intel_hpd_poll_init() in intel_hpd_init() - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init() Changes since v5: - Minor kerneldoc nitpicks Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 19625e85c6ec56038368aa72c44f5f55b221f0fc)
|
#
4c732e6e |
|
21-Jun-2016 |
Lyude <cpaul@redhat.com> |
drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init() While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA get cleared and consequently VGA hotplugging gets disabled. This causes bugs such as one we found on an Intel NUC, where doing the following sequence of hotplugs: - Disconnect all monitors - Connect VGA - Disconnect VGA - Connect HDMI Would result in VGA hotplugging becoming disabled, due to the powerwells getting toggled in the process of connecting HDMI. Changes since v3: - Expose intel_crt_reset() through intel_drv.h and call that in vlv_display_power_well_init() instead of encoder->base.funcs->reset(&encoder->base); Changes since v2: - Use intel_encoder structs instead of drm_encoder structs Changes since v1: - Instead of handling the register writes ourself, we just reuse intel_crt_detect() - Instead of resetting the ADPA during display IRQ installation, we now reset them in vlv_display_power_well_init() Cc: stable@vger.kernel.org Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude <cpaul@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Rebase over dev_priv/drm_device embedding.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 9504a89247595b6c066c68aea0c34af1fc78d021)
|
#
19625e85 |
|
21-Jun-2016 |
Lyude <cpaul@redhat.com> |
drm/i915: Enable polling when we don't have hpd Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get their display to turn on. For instance; if we boot a Valleyview system without any monitors connected, it won't need any of it's power wells and thus shut them off. Since this causes us to lose HPD, this means that unless the user knows how to ssh into their machine and do a manual reprobe for monitors, none of the monitors they connect after booting will actually work. Eventually we should come up with a better fix then having to enable polling for this, since this makes rpm a lot less useful, but for now the infrastructure in i915 just isn't there yet to get hpd in these situations. Changes since v1: - Add comment explaining the addition of the if (!mode_config->poll_running) in intel_hpd_init() - Remove unneeded if (!dev->mode_config.poll_enabled) in i915_hpd_poll_init_work() - Call to drm_helper_hpd_irq_event() after we disable polling - Add cancel_work_sync() call to intel_hpd_cancel_work() Changes since v2: - Apparently dev->mode_config.poll_running doesn't actually reflect whether or not a poll is currently in progress, and is actually used for dynamic module paramter enabling/disabling. So now we instead keep track of our own poll_running variable in dev_priv->hotplug - Clean i915_hpd_poll_init_work() a little bit Changes since v3: - Remove the now-redundant connector loop in intel_hpd_init(), just rely on intel_hpd_poll_enable() for setting connector->polled correctly on each connector - Get rid of poll_running - Don't assign enabled in i915_hpd_poll_init_work before we actually lock dev->mode_config.mutex - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE() for doc purposes - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in intel_hpd_poll_enable() - Add some comments about racing not mattering in intel_hpd_poll_enable Changes since v4: - Rename intel_hpd_poll_enable() to intel_hpd_poll_init() - Drop the bool argument from intel_hpd_poll_init() - Remove redundant calls to intel_hpd_poll_init() - Rename poll_enable_work to poll_init_work - Add some kerneldoc for intel_hpd_poll_init() - Cross-reference intel_hpd_poll_init() in intel_hpd_init() - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init() Changes since v5: - Minor kerneldoc nitpicks Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9504a892 |
|
21-Jun-2016 |
Lyude <cpaul@redhat.com> |
drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init() While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA get cleared and consequently VGA hotplugging gets disabled. This causes bugs such as one we found on an Intel NUC, where doing the following sequence of hotplugs: - Disconnect all monitors - Connect VGA - Disconnect VGA - Connect HDMI Would result in VGA hotplugging becoming disabled, due to the powerwells getting toggled in the process of connecting HDMI. Changes since v3: - Expose intel_crt_reset() through intel_drv.h and call that in vlv_display_power_well_init() instead of encoder->base.funcs->reset(&encoder->base); Changes since v2: - Use intel_encoder structs instead of drm_encoder structs Changes since v1: - Instead of handling the register writes ourself, we just reuse intel_crt_detect() - Instead of resetting the ADPA during display IRQ installation, we now reset them in vlv_display_power_well_init() Cc: stable@vger.kernel.org Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude <cpaul@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Rebase over dev_priv/drm_device embedding.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
91c8a326 |
|
05-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm 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
|
#
ffebb83b |
|
30-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register() By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-53-git-send-email-chris@chris-wilson.co.uk
|
#
919fcd51 |
|
30-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register() By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-52-git-send-email-chris@chris-wilson.co.uk
|
#
8b00f55a |
|
30-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register() By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-51-git-send-email-chris@chris-wilson.co.uk
|
#
117c1148 |
|
30-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register() By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-50-git-send-email-chris@chris-wilson.co.uk
|
#
2c2ccc3a |
|
30-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register() By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-49-git-send-email-chris@chris-wilson.co.uk
|
#
78597996 |
|
16-Jun-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: Fix PPS lost state after suspend breaking eDP link training The PPS registers are backed by power well #0 and as such may be reset after system or runtime suspend (both implying a possible DC9 transition). Fix this by reusing the VLV/CHV PPS pipe-reassignment logic. The difference on BXT is that the PPS instances are not pipe but port (or more accurately pin) specific, so we only need to care about the lost HW state. As opposed to VLV/CHV the SW state is fixed and initialized during connector init. This also paves the way towards using the actual port->PPS instance mapping based on VBT. This fixes eDP link training errors on BXT after suspend, where we started the link training too early due to an incorrect T3 (panel power on) register value. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96436 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466084243-5388-2-git-send-email-imre.deak@intel.com
|
#
324513c0 |
|
13-Jun-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: Rename broxton to bxt in PHY/CDCLK function prefixes Rename these remaining function prefixes to better align with the corresponding SKL functions. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
9c8d0b8e |
|
13-Jun-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: Move DDI PHY enabling/disabling to the power well code So far we depended on the HW to dynamically power down unused PHYs and so we enabled them manually once during driver loading/resuming. There are indications however that we can achieve better power savings by manual powering toggling. So make the PHY enabling/disabling to happen on-demand whenever we need either the corresponding AUX or port functionality. CHV does this already by enabling the PHY along the corresponding PHY common lane power wells there, do the same on BXT by adding virtual power wells for the same purpose. Also sanity check the common lane power down ack signal from the PHY. Do this only when the PHY is enabled, since it's not clear at what point the HW power/clock gates things. While at it rename broxton_ prefix to bxt_ in related function names to better align with the SKL code. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
b409ca95 |
|
13-Jun-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Factor out intel_power_well_get/put These helpers will be needed by the next patch, so factor them out. No functional change. v2: - Move the refcount==0 WARN to the new put helper. (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
14bb2c11 |
|
03-Jun-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Fix a buch of kerneldoc warnings Just a bunch of stale kerneldocs generating warnings when building the docs. Mostly function parameters so not very useful but still. v2: Tidy. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464958937-23344-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
18a8067c |
|
16-May-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Assert the dbuf is enabled when disabling DC5/6 Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling. Let's make sure it has correctly restored the dbuf state to enabled when we disable the DC states. v2: s/skl/gen9/ in function name (Imre) Cc: Imre Deak <imre.deak@intel.com> Suggested-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463407180-28993-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
342be926 |
|
13-May-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk check Rather than having a BXT specific function to make sure the DE PLL is enabled after disabling DC6, let's just make sure the current cdclk is the same as what we last programmed. Having another check in bxt_display_core_init() almost immediately after the cdclk init seems redundant, so let's just kill that one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-21-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
70c2c184 |
|
13-May-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit SKL and BXT have the same snippets of code for enabling disabling the DBUF. Extract those into helpers and move the calls from init/unit_cdclk() to the display core init/init since this stuff isn't really about cdclk. Also doing the enable twice shouldn't hurt since you're just setting the request bit again when it was already set. We can also toss in a few WARNs about the register values into skl_get_dpll0_vco() now that we know that things should always be sane there. Flatten skl_init_cdclk() while at it. v2: s/skl/gen9/ in function names (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
9f7eb31a |
|
13-May-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Unify SKL cdclk init paths Currently we initialize cdclk on SKL from two different places, depending on whether it's during driver init or resume. Let's unify it to happen from the same place always, and that place will be the display core init function. To do this we first run through the cdclk sanitation code, which will first verify that the PLL is programmed correctly, after which we can read out the current cdclk frequency, and once the cdclk is known we verify that the cdclk "decimal" frequency is programmed correctly. If any of these fail we will force a cdclk change, and to be safe we also force the PLL to be turned off and on again. If the sanitation step didn't notice anything amiss, we'll skip the cdclk programming which will prevent cdclk reprogramming when the displays might be active. We can also toss in a few WARNs about the register values into skl_update_dpll0() since we now know that the PLL state should always be sane when that function is called. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
19ab4ed3 |
|
27-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Update RAWCLK_FREQ register on VLV/CHV I just noticed that VLV/CHV have a RAWCLK_FREQ register just like PCH platforms. It lives in the display power well, so we should update it when enabling the power well. Interestingly the BIOS seems to leave it at the reset value (125) which doesn't match the rawclk frequency on VLV/CHV (200 MHz). As always with these register, the spec is extremely vague what the register does. All it says is: "This is used to generate a divided down clock for miscellaneous timers in display." Based on a quick test, at least AUX and PWM appear to be unaffected by this. But since the register is there, let's configure it in accordance with the spec. Note that we have to move intel_update_rawclk() to occur before we touch the power wells, so that the dev_priv->rawclk_freq is already populated when the disp2 enable hook gets called for the first time. I think this should be safe to do on other platforms as well. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461768202-17544-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
f62c79b3 |
|
20-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: Enable DC5 during runtime resume Right after runtime resume we know that we can re-enable DC5, since we just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly instead of delaying this until the next time we disable power well 2. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-5-git-send-email-imre.deak@intel.com
|
#
da2f41d1 |
|
20-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: Sanitize DC state tracking during system resume After suspend-to-ram or -disk we don't know what power state the display HW will be, DC0 or DC9 are both possible states, so reset the software DC state tracking in these cases. This gets rid of 'DC state mismatch' error messages during resuming from ram or disk where we expected to be in DC9 (as set by the suspend handler) but we are in DC0. v2: - Remove extra WS in gen9_sanitize_dc_state() (Bob) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-4-git-send-email-imre.deak@intel.com
|
#
80dbe997 |
|
19-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/kbl: Don't WARN for expected secondary MISC IO power well request In commit 5f304c873634 ("drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMR") I forgot about the fact that SKL==KBL most of the time and that a secondary MISC IO power well request left on by the DMC is "expected". Tune down the corresponding WARN to be a debug message. This was caught by CI suspend tests. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461060036-19043-1-git-send-email-imre.deak@intel.com
|
#
9d0996b5 |
|
18-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Define HSW/BDW display power domains the right way up Currently we're trying to define HSW/BDW power wells by what's not included. Let's do it the other way around, so that you can actually tell when the power well would get enabled. This will also allow us to add new power domains without accidentally adding it to the HSW/BDW display power domains. The current set of domains looks rather buggy even: - POWER_DOMAIN_MODESET is included in the display power well needlessly - DDI-B to DDI-E were not part of the display power well when they should be So let's fix that up while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
465ac0c6 |
|
18-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Define VLV/CHV display power well domains properly Currently we're using POWER_DOMAIN_MASK as the power domains for the display power well on VLV/CHV. That includes all power domains even though the disp2d/pipe-a power well is not needed for a lot of things. Let's reduce these to what we actually need. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
998bd66a |
|
18-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Set .domains=POWER_DOMAIN_MASK for the always-on well The always-on well is the same as runtime PM, so we should just "enable" it for any power domain. Throw out the usless FOO_ALWAYS_ON_DOMAINS defines and just use POWER_DOMAIN_MASK. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460977348-32260-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
f74ed08d |
|
18-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Fix runtime PM refcounting in case DMC firmware isn't loaded While we disable runtime PM and with that display power well support if the DMC firmware isn't loaded, we still want to disable power wells during system suspend and driver unload. So drop/reacquire the corresponding power refcount during suspend/resume and driver unloading. This also means we have to check if DMC is not loaded and skip enabling DC states in the power well code. v2: - Reuse intel_csr_ucode_suspend() in intel_csr_ucode_fini() instead of opencoding the former. (Chris) - Add docbook comment to the public resume and suspend functions. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460980101-14713-1-git-send-email-imre.deak@intel.com
|
#
5f304c87 |
|
15-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMR The workaround added in commit c6782b76d31a ("drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR") needs to be applied on Kabylake too as shown by the corresponding timeout errors about power well 1 and MISC IO power well disabling in the latest CI run. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460748778-4484-1-git-send-email-imre.deak@intel.com
|
#
f11f4e95 |
|
01-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
Revert "drm/i915/bxt: Disable power well support" With the preceding fixes power well support should be functional on Broxton, I could enter/exit DC5 without problems. This reverts commit 18024199579882265653bfe9e2b1a3dcb5697cd9. CC: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-16-git-send-email-imre.deak@intel.com
|
#
adc7f04b |
|
04-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: Add HW state verification for DDI PHY and CDCLK I caught a few errors in our current PHY/CDCLK programming by sanity checking the actual programmed state, so I thought it would be also useful for the future. In addition to verifying the state after programming it also verify it after exiting DC5, to make sure DMC restored/kept intact everything related. v2: - Inlining __phy_reg_verify_state() doesn't make sense and also incorrect, so don't do it (PW/CI gcc) v3: - Rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459780030-15781-1-git-send-email-imre.deak@intel.com
|
#
d7d7c9ee |
|
01-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: Don't toggle power well 1 on-demand Power well 1 is managed by the DMC firmware so don't toggle it on-demand from the driver. This means we need to follow the BSpec display initialization sequence during driver loading and resuming (both system and runtime) and enable power well 1 only once there. Afterwards DMC will toggle power well 1 whenever entering/exiting DC5. For this to work we also need to do away getting the PLL power domain, since that just kept runtime PM disabled for good. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-12-git-send-email-imre.deak@intel.com
|
#
443a93ac |
|
04-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: Unexport skl_pw1_misc_io_init On Broxton we need to enable/disable power well 1 during the init/unit display sequence similarly to Skylake/Kabylake. The code for this will be added in a follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's a simple function called only from a single place and having it inlined in the Skylake display core init/unit functions will make it easier to compare it with its Broxton counterpart. This also flips the order of Misc IO and power well 1 disabling which matches the enabling order. The specification doesn't prescribe the disabling order, so this should be fine. v2: - Fix incorrect enable vs. disable power well call in skl_display_core_uninit() (Patrik) - Add commit comment about chaning the order of PW1 and Misc IO power well disabling (Patrik) CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459773777-10701-1-git-send-email-imre.deak@intel.com
|
#
bfcdabe8 |
|
01-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Fix DMC/DC state asserts The display power well support and DC state management doesn't depend on runtime PM support, so remove the incorrect asserts about this. Also Broxton does support DC5, so the related assert in assert_can_enable_dc5() is incorrect. There is a more generic and correct assert for this already in gen9_set_dc_state(), so we can remove all the other ones. At the same time convert WARNs to WARN_ONCE for consistency with the other DC state asserts. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-7-git-send-email-imre.deak@intel.com
|
#
1d963afa |
|
01-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Make power well disabling synchronous So far we only power well enabling was synchronous not disabling. Since we don't exactly know how the firmware (both DMC and PCU) synchronizes against the actual power well state during DC transitions, make the disabling also synchronous. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-6-git-send-email-imre.deak@intel.com
|
#
c6782b76 |
|
05-Apr-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR DMC forces on power well 1 and the misc IO power well by setting the corresponding request bits both in the BIOS and the DEBUG power well request registers. This is somewhat unexpected since the firmware should really just save and restore state but not alter it. We also depend on being able to disable power well 1, and the misc IO power well before entering S3/S4 on BXT and SKL or entering DC9 on BXT. To fix this make sure these request bits are cleared whenever we want to disable the given power wells. On SKL there is another twist where the firmware also clears the power well 1 request bit in HSW_POWER_WELL_DRIVER (but not that of the misc IO power well). This happens to not cause a problem due to the forced-on request bits in the other request registers. I've filed a bug about all this, but fixing that may take a while and having this sanity check in place makes sense even for future firmware versions. At the same time also check the KVMR request bits. I haven't seen this being altered, but we don't expect any request bits in here either, so sanitize this register as well. v2: - Apply the workaround on SKL as well. I noticed the related failure from the CI report, later Patrik also reported seeing it on his machine. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459851965-6137-1-git-send-email-imre.deak@intel.com
|
#
766078df |
|
11-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move vlv_init_display_clock_gating() to the display power well The registers frobbed by vlv_init_display_clock_gating() libve inside the disp2d power well, so frobbing them while the power well is down results in unclaimed register access warning (and of course the values won't stick). Let's do this setup after we know the power well is enabled. It's also worth noting that DSPCLK_GATE_D and CBR1_VLV lose their state when the power well goes down, but fortunately the values we've been writing are actually the reset defaults. MI_ARB_VLV actually retains its value even if the power well was turned off, we just can't access it while the power well is down. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
2d1fe073 |
|
07-Apr-2016 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
drm/i915: Do not use {HAS_*, IS_*, INTEL_INFO}(dev_priv->dev) dev_priv is what the macro works hard to extract, pass it directly. > sed 's/\([A-Z].*(dev_priv\)->dev)/\1)/g' v2: - Include all wrapper macros too (Chris) v3: - Include sed cmdline (Chris) v4: - Break long line - Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460016485-8089-1-git-send-email-joonas.lahtinen@linux.intel.com
|
#
4d1de975 |
|
18-Mar-2016 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/bxt: add dsi transcoders The BXT display connections have DSI transcoders A and C that can be muxed to any pipe, not unlike the eDP transcoder. Add the notion of DSI transcoders. The "normal" transcoders A, B and C are not used with BXT DSI, so care must be taken to avoid accessing those registers with DSI transcoders in the hardware state readout, modeset, and generally everywhere. v2: addressing comments by Ville: - rename the dsi get config function to hsw_get_dsi_transcoder_state - rebase onto the higher level split of pipe/transcoder functions - use more has_dsi_encoder as we can now because of the above, with no need to look at the transcoder so much - rename IS_DSI_TRANSCODER to transcoder_is_dsi - use the above a bit more instead of comparing to < TRANSCODER_EDP 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/299740536b7941e31b2744f3ce34f7afe936a771.1458313400.git.jani.nikula@intel.com
|
#
acad889f |
|
08-Mar-2016 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/bxt: add missing DSI power domain to power well 1 The DSI power domain was missing from BXT power well 1 definitions, failing to get the power well for DSI transcoders. As pipe A is in the same power well as DSI transcoders, the problem should only occur with pipes B and C. According to Ville, this is basically a nop since pw1 is under dmc control. But given that we still have this stuff defined here, it's clearly correct to include DSI here. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: 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/1457463656-29357-1-git-send-email-jani.nikula@intel.com
|
#
2abc525b |
|
04-Mar-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Fix DMC firmware initialization In commit 1e657ad7 we moved the last step of firmware initialization to skl_display_core_init(), where it will be run only during system resume, but not during driver loading. Since this init step needs to be done whenever we program the firmware fix this by moving the initialization to the end of intel_csr_load_program(). While at it simplify a bit csr_load_work_fn(). This issue prevented DC5/6 transitions, this change will re-enable those. v2: - remove debugging left-over and redundant comment in csr_load_work_fn() Fixes: 1e657ad7a48f ("drm/i915/gen9: Write dc state debugmask bits only once") CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457121461-16729-1-git-send-email-imre.deak@intel.com
|
#
eda90896 |
|
25-Feb-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM) commit 09731280028ce03e6a27e1998137f1775a2839f3 Author: Imre Deak <imre.deak@intel.com> Date: Wed Feb 17 14:17:42 2016 +0200 drm/i915: Add helper to get a display power ref if it was already enabled left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as intel_runtime_pm_get_if_in_use() would return true without incrementing the local bookkeeping required for the assertions. Fixes: 09731280028c ("drm/i915: Add helper to get a display power ref if it was already enabled") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456434628-22574-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit 135dc79efbc119ea5fb34475996983159e6ca31c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
bd90123c |
|
29-Feb-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: Fix power domain suspend sequence During system suspend we need to first disable power wells then unitialize the display core. In case power well support is disabled we did this in the wrong order, so fix this up. Fixes: d314cd43 ("drm/i915: fix handling of the disable_power_well module option") CC: stable@vger.kernel.org CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456778945-5411-1-git-send-email-imre.deak@intel.com (cherry picked from commit 2622d79bd9d18fd04b650234e6a218c5f95cf308) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
5b773eb4 |
|
29-Feb-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Remove state asserts when disabling DC states Disabling the DC states when it's already disabled is a valid scenario, for example during HW state sanitization during driver loading and resuming or when DC states are disabled via the i915.enable_dc or disable_power_well option. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456778945-5411-4-git-send-email-imre.deak@intel.com
|
#
66e2c4c3 |
|
29-Feb-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Disable DC states if power well support is disabled If power well support is disabled via the i915.disable_power_well module option we should never enable DC states. Currently we would enable DC states even in this case during system suspend, where we need to disable all power wells regardless of the disable_power_well option. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456778945-5411-3-git-send-email-imre.deak@intel.com
|
#
a37baf3b |
|
29-Feb-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: Sanitize handling of allowed DC states We can simplify the conditions selecting the target DC state during runtime by calculating the allowed DC states in advance during driver loading. This also makes it easier to disable DC states depending on the i915.disable_power_well module option, added in the next patch. v2: - Print a debug message if the requested max DC value was adjusted due to a platform limit. Also debug print the calculated mask value. (Patrik) CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456778945-5411-2-git-send-email-imre.deak@intel.com
|
#
2622d79b |
|
29-Feb-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: Fix power domain suspend sequence During system suspend we need to first disable power wells then unitialize the display core. In case power well support is disabled we did this in the wrong order, so fix this up. Fixes: d314cd43 ("drm/i915: fix handling of the disable_power_well module option") CC: stable@vger.kernel.org CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456778945-5411-1-git-send-email-imre.deak@intel.com
|
#
ead8f34c |
|
25-Feb-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM) commit 09731280028ce03e6a27e1998137f1775a2839f3 Author: Imre Deak <imre.deak@intel.com> Date: Wed Feb 17 14:17:42 2016 +0200 drm/i915: Add helper to get a display power ref if it was already enabled left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as intel_runtime_pm_get_if_in_use() would return true without incrementing the local bookkeeping required for the assertions. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
135dc79e |
|
25-Feb-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM) commit 09731280028ce03e6a27e1998137f1775a2839f3 Author: Imre Deak <imre.deak@intel.com> Date: Wed Feb 17 14:17:42 2016 +0200 drm/i915: Add helper to get a display power ref if it was already enabled left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as intel_runtime_pm_get_if_in_use() would return true without incrementing the local bookkeeping required for the assertions. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456434628-22574-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
aae8ba84 |
|
19-Feb-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make sure pipe interrupts are processed before turning off power well on BDW+ Starting from BDW the DE_PIPE interrupts for pipe B and C belong to the relevant display power well. So we should make sure we've finished processing them before turning off the power well. The pipe interrupts shouldn't really happen at this point anymore since we've already shut down the planes/pipes/whatnot, but being a bit paranoid shouldn't hurt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
2230fde8 |
|
19-Feb-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: synchronize_irq() before turning off disp2d power well on VLV/CHV After we've told the irq code we don't want to handle display irqs anymore, we must make sure any display irq handling already kicked off has finished before we actually turn off the power well. I wouldn't expect PIPESTAT based interrupts to occur anymore since vblanks/page flips/gmbus/etc should all be quiescent at this point. But at least hotplug interrupts could still occur. Hotplug interrupts may also kick off the workqueue based hotplug processing, but that code should take the required power domain references itself, so there shouldn't be any need to synchronize with the hotplug processing from the power well code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455900112-15387-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
9b18572e |
|
18-Feb-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/gen9: Verify and enforce dc6 state writes It has been observed that sometimes disabling the dc6 fails and dc6 state pops back up, brief moment after disabling. This has to be dmc save/restore timing issue or other bug in the way dc states are handled. Try to work around this issue as we don't have firmware fix yet available. Verify that the value we wrote for the dmc sticks, and also enforce it by rewriting it, if it didn't. v2: Zero rereads on rewrite for extra paranoia (Imre) Testcase: kms_flip/basic-flip-vs-dpms References: https://bugs.freedesktop.org/show_bug.cgi?id=93768 Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 779cb5d3ddd72950ec726f86e38f7575c7fbdd4c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
9b6f2098 |
|
18-Feb-2016 |
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> |
drm/i915/gen9: Check for DC state mismatch The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 832dba889e27487c3087149f1039acc3feb89003) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
5af9a454 |
|
17-Feb-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add helper to get a display power ref if it was already enabled We have many places in the code where we check if a given display power domain is enabled and if so access registers backed by this power domain. We assumed that some modeset lock will prevent the power reference from vanishing in the middle of the HW access, but this assumption doesn't always hold. In such cases we get either the wakeref not held, or an unclaimed register access error message. To fix this in a future-proof way that's independent of other locks wrap any such access with a get_ref_if_enabled()/put_ref() pair. Kudos to Ville and Joonas for the ideas of this new interface. v2: - init the power_domains ptr when declaring it everywhere (Joonas) v3: - don't report the device to be powered if runtime PM is disabled CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com (cherry picked from commit 09731280028ce03e6a27e1998137f1775a2839f3) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
1e657ad7 |
|
18-Feb-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/gen9: Write dc state debugmask bits only once DMC debugmask bits should stick so no need to write them everytime dc state is changed. v2: Write after firmware has been successfully loaded (Ville) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-5-git-send-email-mika.kuoppala@intel.com
|
#
5b076889 |
|
18-Feb-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/gen9: Extend dmc debug mask to include cores Cores need to be included into the debug mask. We don't exactly know what it does but the spec says it must be enabled. So obey. v2: Cores should be only set for BXT (Imre, Art) Cc: Imre Deak <imre.deak@intel.com> Cc: Runyan, Arthur J <arthur.j.runyan@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455877564-5128-1-git-send-email-mika.kuoppala@intel.com
|
#
779cb5d3 |
|
18-Feb-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/gen9: Verify and enforce dc6 state writes It has been observed that sometimes disabling the dc6 fails and dc6 state pops back up, brief moment after disabling. This has to be dmc save/restore timing issue or other bug in the way dc states are handled. Try to work around this issue as we don't have firmware fix yet available. Verify that the value we wrote for the dmc sticks, and also enforce it by rewriting it, if it didn't. v2: Zero rereads on rewrite for extra paranoia (Imre) Testcase: kms_flip/basic-flip-vs-dpms References: https://bugs.freedesktop.org/show_bug.cgi?id=93768 Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com
|
#
832dba88 |
|
18-Feb-2016 |
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> |
drm/i915/gen9: Check for DC state mismatch The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com
|
#
09731280 |
|
17-Feb-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add helper to get a display power ref if it was already enabled We have many places in the code where we check if a given display power domain is enabled and if so access registers backed by this power domain. We assumed that some modeset lock will prevent the power reference from vanishing in the middle of the HW access, but this assumption doesn't always hold. In such cases we get either the wakeref not held, or an unclaimed register access error message. To fix this in a future-proof way that's independent of other locks wrap any such access with a get_ref_if_enabled()/put_ref() pair. Kudos to Ville and Joonas for the ideas of this new interface. v2: - init the power_domains ptr when declaring it everywhere (Joonas) v3: - don't report the device to be powered if runtime PM is disabled CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com
|
#
6a7e4f99 |
|
08-Dec-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Kill intel_prepare_ddi() Move the ddi buffer translation programming to occur from the encoder .pre_enable() hook, for just the ddi port we are enabling. Previously we used to reprogram the translations for all ddi ports during init and during power well enabling. v2: s/intel_prepare_ddi_buffers/intel_prepare_ddi_buffer/ (Daniel) Resolve conflicts due to dev_priv->atomic_cdclk_freq Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8d7a1c4a |
|
07-Jan-2016 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/kbl: Adding missing IS_KABYLAKE checks. When adding IS_KABYLAKE definition I didn't included the DC states related because I was planing to include them with the patch that fixes DMC firmware loading, but I forgot them. Meanwhile this runtime pm code changed a lot for Skylake. Well, I didn't expect that this would crash the machine and I just noticed now that Sarah warned me our driver wasn't working. Thanks Sarah. Michel had found the main error first and his fix had better details on the history and got merged already: commit 16fbc291cb87c7defcd13ad715d3e4af0d523e43 Author: Michel Thierry <michel.thierry@intel.com> Date: Wed Jan 6 12:08:36 2016 +0000 drm/i915/kbl: Enable PW1 and Misc I/O power wells This one is a follow-up adding the other remaining missing pieces. v2: Rebased on top of Michel's patch as explained above. Cc: Sarah Sharp <sarah.a.sharp@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452214179-22361-1-git-send-email-rodrigo.vivi@intel.com
|
#
16fbc291 |
|
05-Jan-2016 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915/kbl: Enable PW1 and Misc I/O power wells My kbl stopped working because of this. Fixes regression from commit 2f693e28b8df69f67beced5e18bb2b91c2bfcec2 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Wed Nov 4 19:24:12 2015 +0200 drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452082116-16770-1-git-send-email-michel.thierry@intel.com Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cbc68dc9 |
|
17-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: don't enable autosuspend on platforms without RPM support pm_runtime_{use,dont_use}_autosuspend() controls whether the device's sysfs power/autosuspend_delay_ms file is writeable or returns -EIO on access to user space. Since commit 25b181b46e4340f69793a886f2cd46608487783b Author: Imre Deak <imre.deak@intel.com> Date: Thu Dec 17 13:44:56 2015 +0200 drm/i915: get a permanent RPM reference on platforms w/o RPM support this sysfs file is writeable also on platforms without RPM support, but userspace (at least IGT) depends on this file being unchangable to determine whether the device supports runtime PM at all. So restore the old behavior. This gets rid of igt/pm_rpm failures on old platforms without RPM support, where the test should be skipped. Testcase: igt/pm_rpm/basic-rte Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450371873-878-1-git-send-email-imre.deak@intel.com
|
#
2b19efeb |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: add support for checking RPM atomic sections In some cases we want to check whether we hold an RPM wakelock reference for the whole duration of a sequence. To achieve this add a new RPM atomic sequence counter that we increment any time the wakelock refcount drops to zero. Check whether the sequence number stays the same during the atomic section and that we hold the wakelock at the beginning of the section. Motivated by Chris. v2-v3: - unchanged v4: - swap the order of atomic_read() and assert_rpm_wakelock_held() in assert_rpm_atomic_begin() to avoid race Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-10-git-send-email-imre.deak@intel.com
|
#
542db3cd |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: check that we hold an RPM wakelock ref before we put it With this change we have the corresponding wake lock checks in both the rpm get and put functions. v2-v3: - unchanged v4: - keep the corresponding check in the get helper (Chris) v5: - add a note to the commit message that with this change we have the checks both in the rpm get and put functions (Joonas) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-9-git-send-email-imre.deak@intel.com
|
#
1f814dac |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: add support for checking if we hold an RPM reference Atm, we assert that the device is not suspended until the point when the device is truly put to a suspended state. This is fine, but we can catch more problems if we check that RPM refcount is non-zero. After that one drops to zero we shouldn't access the device any more, even if the actual device suspend may be delayed. Change assert_rpm_wakelock_held() accordingly to check for a non-zero RPM refcount in addition to the current device-not-suspended check. For the new asserts to work we need to annotate every place explicitly in the code where we expect that the device is powered. The places where we only assume this, but may not hold an RPM reference: - driver load We assume the device to be powered until we enable RPM. Make this explicit by taking an RPM reference around the load function. - system and runtime sudpend/resume handlers These handlers are called when the RPM reference becomes 0 and know the exact point after which the device can get powered off. Disable the RPM-reference-held check for their duration. - the IRQ, hangcheck and RPS work handlers These handlers are flushed in the system/runtime suspend handler before the device is powered off, so it's guaranteed that they won't run while the device is powered off even though they don't hold any RPM reference. Disable the RPM-reference-held check for their duration. In all these cases we still check that the device is not suspended. These explicit annotations also have the positive side effect of documenting our assumptions better. This caught additional WARNs from the atomic modeset path, those should be fixed separately. v2: - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville) v3: - use a new dedicated RPM wakelock refcount to also catch cases where our own RPM get/put functions were not called (Chris) - assert also that the new RPM wakelock refcount is 0 in the RPM suspend handler (Chris) - change the assert error message to be more meaningful (Chris) - prevent false assert errors and check that the RPM wakelock is 0 in the RPM resume handler too - prevent false assert errors in the hangcheck work too - add a device not suspended assert check to the hangcheck work v4: - rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts and wakelock_count to wakeref_count - disable the wakeref asserts in the IRQ handlers and RPS work too - update/clarify commit message v5: - mark places we plan to change to use proper RPM refcounting with separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450227139-13471-1-git-send-email-imre.deak@intel.com
|
#
c9b8846a |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: use assert_rpm_wakelock_held instead of opencoding it Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-7-git-send-email-imre.deak@intel.com
|
#
7f233235 |
|
17-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers We don't really need to check this flag in the get/put/assert helpers, as on platforms without RPM support we won't ever enable RPM. That means pm.suspend will be always false and the assert will be always true. Do this to simplify the code and to let us extend the RPM asserts to all platforms for a better coverage. Motivated by Ville. v2-v3: - unchanged v4: - remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too made possible by the previous two patches v5: - rebased on the previous new patch in the series that keeps HAS_RUNTIME_PM() in intel_runtime_pm_enable() with a permanent reference taken there Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450352931-16498-1-git-send-email-imre.deak@intel.com
|
#
25b181b4 |
|
17-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: get a permanent RPM reference on platforms w/o RPM support Currently we disable RPM functionality on platforms that doesn't support this by not putting/getting the RPM reference we receive from the RPM core during driver loading/unloading respectively. This is somewhat obscure, so make it more explicit by keeping a reference dedicated for this particular purpose whenever the driver is loaded. This makes it possible to remove the HAS_RUNTIME_PM() special casing from every other places in the next patch. v2: - fix intel_runtime_pm_get vs. intel_runtime_pm_put in intel_power_domains_fini() v3: - take only a low level RPM reference so the ref tracking asserts continue to work (Ville) - update the commit message - move the patch earlier for bisectability Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450352696-16135-1-git-send-email-imre.deak@intel.com
|
#
b268c699 |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: refactor RPM disabling due to RC6 being disabled We can make the RPM dependency on RC6 explcit in the code by taking an actual RPM reference, instead of avoiding to drop the initial one. This will also enable us to remove the HAS_RUNTIME_PM special casing from more places in the next patch. v2: - fixed typo in commit message (Joonas) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-4-git-send-email-imre.deak@intel.com
|
#
aabee1bb |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: clarify comment about mandatory RPM put/get during driver load/unload Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-2-git-send-email-imre.deak@intel.com
|
#
ac9b8236 |
|
27-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce a gmbus power domain Currently the gmbus code uses intel_aux_display_runtime_get/put in an effort to make sure the hardware is powered up sufficiently for gmbus. That function only takes the runtime PM reference which on VLV/CHV/BXT is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well 2 on BXT. So add a new power domnain for gmbus and kill off the now unused intel_aux_display_runtime_get/put. And change intel_hdmi_set_edid() to use the gmbus power domain too since that's all we need there. Also toss in a BUILD_BUG_ON() to catch problems if we run out of bits for power domains. We're already really close to the limit... [Patrik: Add gmbus string to debugfs output] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> [Cherry-picked from drm-intel-next-queued f0ab43e6 (Imre)] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-3-git-send-email-imre.deak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
18024199 |
|
01-Dec-2015 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/bxt: Disable power well support BXT power well support is not yet stable. Starting with patch commit 9f836f9016ad5320e0c9230419d2102cf15a28aa Author: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Date: Mon Nov 16 16:20:01 2015 +0100 drm/i915/gen9: Turn DC handling into a power well DPMS off operations may actually cause the entire system to powerdown or reboot. Disable power well support for now until Broxton gets fixes similar to what we have for SKL. Cc: Imre Deak <imre.deak@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> References: http://lists.freedesktop.org/archives/intel-gfx/2015-November/081037.html Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448990818-11005-1-git-send-email-matthew.d.roper@intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
95150bdf |
|
24-Nov-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: fix potential dangling else problems in for_each_ macros We have serious dangling else bugs waiting to happen in our for_each_ style macros with ifs. Consider, for example, #define for_each_power_domain(domain, mask) \ for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \ if ((1 << (domain)) & (mask)) If this is used in context: if (condition) for_each_power_domain(domain, mask); else foo(); foo() will be called for each domain *not* in mask, if condition holds, and not at all if condition doesn't hold. Fix this by reversing the conditions in the macros, and adding an else branch for the "for each" block, so that other if/else blocks can't interfere. Provide a "for_each_if" helper macro to make it easier to get this right. v2: move for_each_if to drmP.h in a separate patch. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448392916-2281-2-git-send-email-jani.nikula@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
11c86db8 |
|
20-Nov-2015 |
Daniel Stone <daniels@collabora.com> |
drm/i915/pm: Print offending domain in refcount failure If we experience a refcounting failure in a power domain/well (unref'ing at least one too many times), log the name of the offending domain or well. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448034934-11926-2-git-send-email-daniels@collabora.com
|
#
9895ad03 |
|
20-Nov-2015 |
Daniel Stone <daniels@collabora.com> |
drm/i915/pm: Unstatic power_domain_str Let us print human-parseable values from the power domain code; upcoming display code also wants to use it. This requires moving it out of i915_debugfs.c, as that is only conditionally compiled. v2: Move it out of the header. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448034934-11926-1-git-send-email-daniels@collabora.com
|
#
a7de5506 |
|
18-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: re-enable power well support Now that the known DMC/DC issues are fixed, let's try again and re-enable the power well support. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447869230-21416-1-git-send-email-imre.deak@intel.com
|
#
443646c7 |
|
16-Nov-2015 |
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> |
drm/i915/gen9: Add boot parameter for disabling DC6 v2: Use _unsafe (Jani) v3: Allow specifying specific DC-states instead of just DC6 (Imre) Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447682467-6237-3-git-send-email-patrik.jakobsson@linux.intel.com
|
#
9f836f90 |
|
16-Nov-2015 |
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> |
drm/i915/gen9: Turn DC handling into a power well Handle DC off as a power well where enabling the power well will prevent the DMC to enter selected DC states (required around modesets and Aux A). Disabling the power well will allow DC states again. For now the highest DC state is DC6 for Skylake and DC5 for Broxton but will be configurable for Skylake in a later patch. v2: Check both DC5 and DC6 bits in power well enabled function (Ville) v3: - Remove unneeded DC_OFF case in skl_set_power_well() (Imre) - Add PW2 dependency to DC_OFF (Imre) v4: Put DC_OFF before PW2 in BXT power well array Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [fixed line over 80 and parenthesis alignment checkpatch warns (imre)] Link: http://patchwork.freedesktop.org/patch/msgid/1447687201-24759-1-git-send-email-patrik.jakobsson@linux.intel.com
|
#
b450e177 |
|
09-Nov-2015 |
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> |
drm/i915: Do not warn on PG2 enabled in gen9_disable_dc5() PG2 enabled is not a requirement for disabling DC5. It's just one of the reasons why the DMC wouldn't enter DC5. During modeset we don't care about PG2 from a DC perspective, only the fact that DC5/DC6 is not allowed. Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-9-git-send-email-patrik.jakobsson@linux.intel.com
|
#
6331a704 |
|
09-Nov-2015 |
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> |
drm/i915: Remove distinction between DDI 2 vs 4 lanes We never make use of the distinction between 2 vs 4 lanes so combine them into a per port domain instead. This saves us a few bits in the power domain mask. Change suggested by Ville. Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-7-git-send-email-patrik.jakobsson@linux.intel.com
|
#
edd993fd |
|
09-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove DDI power domain exclusion SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS All the DDI power domains are already excluded from SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS on account of excluding SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS and SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS, no need to spell them out again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-6-git-send-email-patrik.jakobsson@linux.intel.com
|
#
f0ab43e6 |
|
09-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce a gmbus power domain Currently the gmbus code uses intel_aux_display_runtime_get/put in an effort to make sure the hardware is powered up sufficiently for gmbus. That function only takes the runtime PM reference which on VLV/CHV/BXT is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well 2 on BXT. So add a new power domnain for gmbus and kill off the now unused intel_aux_display_runtime_get/put. And change intel_hdmi_set_edid() to use the gmbus power domain too since that's all we need there. Also toss in a BUILD_BUG_ON() to catch problems if we run out of bits for power domains. We're already really close to the limit... [Patrik: Add gmbus string to debugfs output] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-5-git-send-email-patrik.jakobsson@linux.intel.com
|
#
4deccbb2 |
|
09-Nov-2015 |
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> |
drm/i915/gen9: Always set mask memory up when enabling DC5 or DC6 Move call to gen9_set_dc_state_debugmask_memory_up() into gen9_set_dc_state() to prevent us missing it somewhere. Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-3-git-send-email-patrik.jakobsson@linux.intel.com
|
#
d314cd43 |
|
17-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix handling of the disable_power_well module option When this option is 0 (so the power well support is disabled) we are supposed to enable all power wells once and don't disable them unless we system suspend the device. Currently if the option is 0, we can call the power well enable handlers multiple times, whenever their refcount changes from 0->1. This may not be a problem for the HW, but it's not logical and may trigger some warnings in the power well code which doesn't expect this. So simply keep around a reference while we are not system suspended to solve this. For simplicity mark the module option read only, so we don't need to deal with re-enabling the feature during runtime. If someone really needs that it could be added later in a more proper way. v2: - fix typo in comment in intel_power_domains_suspend() (Patrik) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447775063-24438-1-git-send-email-imre.deak@intel.com
|
#
c2b16152 |
|
04-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: remove redundant DDI/IRQ reinitialization during PW1 enabling We don't need to reinit DDI and IRQs during PW1 enabling any more, since we don't toggle PW1 on-demand any more. We enable PW1 only as part of the display core init sequence and after this we initialize both DDI and IRQs later in the init sequence. So remove these init steps from the power well code. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-11-git-send-email-imre.deak@intel.com
|
#
d26fa1d5 |
|
04-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: disable DC states before display core init/uninit We need to disable the DC states during display core init to sanitize the HW state we inherit from the BIOS. We need to disable it during display core uninit too, since the power well framework will leave it enabled (since we get to the display core uninit step with all power domains disabled already). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-9-git-send-email-imre.deak@intel.com
|
#
13ae3a0d |
|
04-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9: simplify DC toggling code Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> [fix line over 80 chars checkpatch WARN in gen9_set_dc_state() (imre)] Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-8-git-send-email-imre.deak@intel.com
|
#
4a76f295 |
|
04-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: don't toggle PW1 and MISC power wells on-demand With the DMC firmware installed we don't need to handle HW resources that are handled automatically by the firmware. Besides being redundant this can also interfere with the firmware, possibly getting it into a broken/blocked state. The on-demand handling of PW1 was already half-way removed, MISC IO was still handled in this way. After the last patch we init/uninit these HW resources manually as part of the display core init/uninit sequence, so we can now remove the on-demand handling for these completely. We still keep around the power wells (with no domains attached to them) since the manual toggling during display core init/uninit happens via the current API. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> [s/beeing/being/ in commit message (imre)] Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-7-git-send-email-imre.deak@intel.com
|
#
73dfc227 |
|
17-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: init/uninit display core as part of the HW power domain state We need to initialize the display core part early, before initializing the rest of the display power state. This is also described in the bspec termed "Display initialization sequence". Atm we run this sequence during driver loading after power domain HW state initialization which is too late and during runtime suspend/resume which is unneeded and can interere with DMC functionality which handles HW resources toggled by this init/uninit sequence automatically. The init sequence must be run as the first step of HW power state initialization and during system resume. The uninit sequence must be run during system suspend. To address the above move the init sequence to the initial HW power state setup and the uninit sequence to a new power domains suspend function called during system suspend. As part of the init sequence we also have to reprogram the DMC firmware as it's lost across a system suspend/resume cycle. After this change CD clock initialization during driver loading will happen only later after other dependent HW/SW parts are initialized, while during system resume it will get initialized as the last step of the init sequence. This distinction can be removed by some refactoring of platform independent parts. I left this refactoring out from this series since I didn't want to change non-SKL parts. This is a TODO for later. v2: - fix error path in i915_drm_suspend_late() - don't try to re-program the DMC firmware if it failed to load Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447774433-20834-1-git-send-email-imre.deak@intel.com
|
#
30eade12 |
|
04-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: rename intel_power_domains_resume to *_sync_hw Give a more proper name to this function. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-5-git-send-email-imre.deak@intel.com
|
#
2f693e28 |
|
04-Nov-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences Before this patch, we used the intel_display_power_{get,put} functions to make sure the PW1 and Misc I/O power wells were enabled all the time while LCPLL was enabled. We called a get() at intel_ddi_pll_init() when we discovered that LCPLL was enabled, then we would call put/get at skl_{un,}init_cdclk(). The problem is that skl_uninit_cdclk() is indirectly called by intel_runtime_suspend(). So it will only release its power well _after_ we already decided to runtime suspend. But since we only decide to runtime suspend after all power wells and refcounts are released, that basically means we will never decide to runtime suspend. So what this patch does to fix that problem is move the PW1 + Misc I/O power well handling out of the runtime PM mechanism: instead of calling intel_display_power_{get_put} - functions that touch the refcount -, we'll call the low level intel_power_well_{en,dis}able, which don't change the refcount. This way, it is now possible for the refcount to actually reach zero, and we'll now start runtime suspending/resuming. v2 (from Paulo): - Write a commit message since the original patch left it empty. - Rebase after the intel_power_well_{en,dis}able rename. - Use lookup_power_well() instead of hardcoded indexes. Testcase: igt/pm_rpm/rte (and every other rpm test) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92211 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92605 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-4-git-send-email-imre.deak@intel.com
|
#
fc17f227 |
|
04-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix lookup_power_well for power wells without any domain The current lookup code wouldn't find a power well if it's not in any power domain. There wasn't any power wells before but an upcoming patch will detach the power domains from power well#1 and the MISC IO power wells, so fix things up accordingly. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-3-git-send-email-imre.deak@intel.com
|
#
56fcfd63 |
|
04-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix the power well ID for always on wells lookup_power_well() expects uniq power well IDs, but atm we have uninitialized IDs which would clash with those power wells with a 0 ID. This wasn't a problem so far since nothing looked up such a power well, but an upcoming patch will (Misc IO for SKL), so fix this up on platforms where this matters. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-2-git-send-email-imre.deak@intel.com
|
#
ca1283d5 |
|
28-Oct-2015 |
Animesh Manna <animesh.manna@intel.com> |
drm/i915/skl: Removed assert for csr-fw-loading check during disabling dc6 As during disabling dc6 no need to check for csr firmware loading status, so removed the assert call (Requested by Damien). Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-14-git-send-email-imre.deak@intel.com
|
#
414b7999 |
|
12-Nov-2015 |
Daniel Vetter <daniel.vetter@intel.com> |
drm/i915/gen9: Remove csr.state, csr_lock and related code. This removes two anti-patterns: - Locking shouldn't be used to synchronize with async work (of any form, whether callbacks, workers or other threads). This is what the mutex_lock/unlock seems to have been for in intel_csr_load_program. Instead ordering should be ensured with the generic wait_for_completion()/complete(). Or more specific functions provided by the core kernel like e.g. flush_work()/cancel_work_sync() in the case of synchronizing with a work item. - Don't invent own completion like the following code did with the (already removed) wait_for(csr_load_status_get()) pattern - it's really hard to get these right when you want them to be _really_ correct (and be fast) in all cases. Furthermore it's easier to read code using the well-known primitives than new ones using non-standard names. Before enabling/disabling DC6 check if the firmware is loaded successfully. This is guaranteed during runtime s/r, since otherwise we don't enable RPM, but not during system s/r. Note that it's still unclear whether we need to enable/disable DC6 during system s/r, until that's clarified, keep the current behavior and enable/disable DC6. Also after this patch there is a race during system s/r where the firmware may not be loaded yet, that's addressed in an upcoming patch. v2-v3: - unchanged v4: - rebased on latest drm-intel-nightly Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [imre: added code and note about checking if the firmware loaded ok, before enabling/disabling it] Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447341037-2623-1-git-send-email-imre.deak@intel.com
|
#
af5fead2 |
|
28-Oct-2015 |
Daniel Vetter <daniel.vetter@intel.com> |
drm/i915/gen9: move assert_csr_loaded into intel_rpm.c Avoids non-static functions since all the callers are in intel_rpm.c. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [imre: removed note about reg definitions from commit message, since it's not relevant any more] Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL [Jani: make assert_csr_loaded static] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-4-git-send-email-imre.deak@intel.com
|
#
18a04a73 |
|
06-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Kill intel_runtime_pm_disable() intel_runtime_pm_disable() takes an extra rpm reference which combined with the one we leak from intel_display_set_init_power() leaves the usage count at <original>+1 after the driver has been unloaded. The original ref is dropped explicitly in intel_runtime_pm_enable(). So the next time we load the driver we can no longer do runtime PM ever. This used to work, but commit 292b990e86ab ("drm/i915: Update power domains on readout.") broke things by not dropping the init power domain during fbdev teardown. Based on the comment in intel_power_domains_fini(), the way it used to to work wasn't intentional. As in we weren't supposed to drop the init power during driver unload. And since we no longer do, we now leak an extra rpm reference. So fix things by throwing intel_runtime_pm_disable() to the bin, so that the only leaked reference comes from the init power domain. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Fixes: 292b990e86ab ("drm/i915: Update power domains on readout.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
1b0e3a04 |
|
05-Nov-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/skl: disable display side power well support for now The display power well support on this platform is in a somewhat broken state atm, so disable it by default. This in effect will get rid of incorrect assert WARNs about the CSR/DMC firmware not being loaded during power well toggling. It also removes a problem during driver loading where a register is accessed while its backing power well is down, resulting in another WARN. Until we come up with the root cause of the second problem and the proper fix for both issues, keep all display side power wells on. Also clarify a bit the option description. Reported-by: Dave Airlie <airlied@redhat.com> Reference: http://mid.gmane.org/CAPM=9tyjBQjSBTKa49cRr6SYkpNW7Pq-fUFznZZ8Y1snvvk7mA@mail.gmail.com Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446757451-2777-1-git-send-email-imre.deak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
ef11bdb3 |
|
28-Oct-2015 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/kbl: Introduce Kabylake platform defition. Kabylake is a Intel® Processor containing Intel® HD Graphics following Skylake. It is Gen9p5, so it inherits everything from Skylake. Let's start by adding the platform separated from Skylake but reusing most of all features, functions etc. Later we rebase the PCI-ID patch without is_skylake=1 so we don't replace what original Author did there. Few IS_SKYLAKEs if statements are not being covered by this patch on purpose: - Workarounds: Kabylake is derivated from Skylake H0 so no W/As apply here. - GuC: A following patch removes Kabylake support with an explanation: No firmware available yet. - DMC/CSR: Done in a separated patch since we need to be carefull and load the version for revision 7 since Kabylake is Skylake H0. v2: relative cleaner commit message and added the missed IS_KABYLAKE to intel_i2c.c as pointed out by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
0a9d2bed |
|
28-Sep-2015 |
Animesh Manna <animesh.manna@intel.com> |
drm/i915/skl: Making DC6 entry is the last call in suspend flow. Mmio register access after dc6/dc5 entry is not allowed when DC6 power states are enabled according to bspec (bspec-id 0527), so enabling dc6 as the last call in suspend flow. Addtional note from Imre: Currently we keep DC6 enabled during modesets and DPAUX transfers, which is not allowed according to the specification. This can lead at least to PLL locking failures, DPAUX timeouts and prevent deeper package power states (PC9/10). Fix this for now by enabling DC6 only when we know the above events (modeset, DPAUX) can't happen. This a temporary solution as some issues are still unsolved as described in [1] and [2], we'll address those as a follow-up. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077669.html [2] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077787.html v1: Initial version. v2: Based on review comment from Daniel, - created a seperate patch for csr uninitialization set call. v3: Rebased on top of latest code. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3be60de9 |
|
08-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Skip CHV PHY asserts until PHY has been fully reset The BIOS can leave the CHV display PHY in some odd state where some of the LDOs/lanes won't power down fully when unused. This will trigger a host of asserts that were added in: 30142273a3e83936fd7b45aa5339311a9295ca51 drm/i915: Add CHV PHY LDO power sanity checks 6669e39f95b5530ca8cb9137703ceb5e83e5d648 drm/i915: Add some CHV DPIO lane power state asserts To avoid that, skip the asserts until the PHY power well has been disabled at least once. That will fully reset the PHY, and once brought back up, the dynamic power down features will work correctly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
165ed87c |
|
23-Sep-2015 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: fixup runtime PM handling v2 According to the PCI docs and Rafael, we don't need to be doing explicit enables and disables in our init and teardown routines, as they're taken care of by the PCI core. So drop the pm_runtime_disable() at teardown and pm_runtime_set_active() at init. This fixes one failure of the basic-pci-d3-state test on my BYT. v2: drop extra get_noresume() and put_noidle() (Rafael) Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
08aef7ca |
|
25-Aug-2015 |
Animesh Manna <animesh.manna@intel.com> |
drm/i915/skl: Block disable call for pw1 if dmc firmware is present. Another interesting criteria to work dmc as expected is pw1 to be enabled by driver and dmc will shut it off in its execution sequence. If already disabled by driver dmc will get confuse and behave differently than expected found during pc10 entry issue for skl. So berfore we disable power-well 1, added check if dmc firmware is present and driver will not disable power well 1, but for any reason if firmware is not present of failed to load we can shut off the power well 1 which will save some power. As skl is currently fully dependent on dmc to go in lowest possible power state (dc6) but the same is not applicable for bxt. Display engine can enter into dc9 without dmc, hence unblocking disable call. v1: Initial version. v2: Rebased as per current patch series. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bc5f2ab1 |
|
23-Sep-2015 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/skl: Don't call intel_prepare_ddi when encoder list isn't yet initialized. In case something goes wrong with power well initialization we were calling intel_prepare_ddi during boot while encoder list isnt't initilized. [ 9.618747] i915 0000:00:02.0: Invalid ROM contents [ 9.631446] [drm] failed to find VBIOS tables [ 9.720036] BUG: unable to handle kernel NULL pointer dereference at 00000000 00000058 [ 9.721986] IP: [<ffffffffa014eb72>] ddi_get_encoder_port+0x82/0x190 [i915] [ 9.723736] PGD 0 [ 9.724286] Oops: 0000 [#1] PREEMPT SMP [ 9.725386] Modules linked in: intel_powerclamp snd_hda_intel(+) coretemp crc 32c_intel snd_hda_codec snd_hda_core serio_raw snd_pcm snd_timer i915(+) parport _pc parport pinctrl_sunrisepoint pinctrl_intel nfsd nfs_acl [ 9.730635] CPU: 0 PID: 497 Comm: systemd-udevd Not tainted 4.3.0-rc2-eywa-10 967-g72de2cfd-dirty #2 [ 9.732785] Hardware name: Intel Corporation Cannonlake Client platform/Skyla ke DT DDR4 RVP8, BIOS CNLSE2R1.R00.X021.B00.1508040310 08/04/2015 [ 9.735785] task: ffff88008a704700 ti: ffff88016a1ac000 task.ti: ffff88016a1a c000 [ 9.737584] RIP: 0010:[<ffffffffa014eb72>] [<ffffffffa014eb72>] ddi_get_enco der_port+0x82/0x190 [i915] [ 9.739934] RSP: 0000:ffff88016a1af710 EFLAGS: 00010296 [ 9.741184] RAX: 000000000000004e RBX: ffff88008a9edc98 RCX: 0000000000000001 [ 9.742934] RDX: 000000000000004e RSI: ffffffff81fc1e82 RDI: 00000000ffffffff [ 9.744634] RBP: ffff88016a1af730 R08: 0000000000000000 R09: 0000000000000578 [ 9.746333] R10: 0000000000001065 R11: 0000000000000578 R12: fffffffffffffff8 [ 9.748033] R13: ffff88016a1af7a8 R14: ffff88016a1af794 R15: 0000000000000000 [ 9.749733] FS: 00007eff2e1e07c0(0000) GS:ffff88016fc00000(0000) knlGS:00000 00000000000 [ 9.751683] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9.753083] CR2: 0000000000000058 CR3: 000000016922b000 CR4: 00000000003406f0 [ 9.754782] Stack: [ 9.755332] ffff88008a9edc98 ffff88008a9ed800 ffffffffa01d07b0 00000000fffb9 09e [ 9.757232] ffff88016a1af7d8 ffffffffa0154ea7 0000000000000246 ffff88016a370 080 [ 9.759182] ffff88016a370080 ffff88008a9ed800 0000000000000246 ffff88008a9ed c98 [ 9.761132] Call Trace: [ 9.761782] [<ffffffffa0154ea7>] intel_prepare_ddi+0x67/0x860 [i915] [ 9.763332] [<ffffffff81a56996>] ? _raw_spin_unlock_irqrestore+0x26/0x40 [ 9.765031] [<ffffffffa00fad01>] ? gen9_read32+0x141/0x360 [i915] [ 9.766531] [<ffffffffa00b43e1>] skl_set_power_well+0x431/0xa80 [i915] [ 9.768181] [<ffffffffa00b4a63>] skl_power_well_enable+0x13/0x20 [i915] [ 9.769781] [<ffffffffa00b2188>] intel_power_well_enable+0x28/0x50 [i915] [ 9.771481] [<ffffffffa00b4d52>] intel_display_power_get+0x92/0xc0 [i915] [ 9.773180] [<ffffffffa00b4fcb>] intel_display_set_init_power+0x3b/0x40 [i91 5] [ 9.774980] [<ffffffffa00b5170>] intel_power_domains_init_hw+0x120/0x520 [i9 15] [ 9.776780] [<ffffffffa0194c61>] i915_driver_load+0xb21/0xf40 [i915] So let's protect this case. My first attempt was to remove the intel_prepare_ddi, but Daniel had pointed out this is really needed to restore those registers values. And Imre pointed out that this case was without the flag protection and this was actually where things were going bad. So I've just checked and this indeed solves my issue. The regressing intel_prepare_ddi call was added in commit 1d2b9526a790d55b7ae870934a74937081f62de2 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Fri Mar 6 18:50:53 2015 +0000 drm/i915/skl: Restore the DDI translation tables when enabling PW1 Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [Jani: regression reference] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
6ff8ab0d |
|
10-Sep-2015 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: make CSR firmware messages less verbose Use WARN_ONCE in a bunch of places and demote a message that would continually spam us. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
30142273 |
|
08-Jul-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add CHV PHY LDO power sanity checks At various points when changing the DPIO lane/phy power states, construct an expected value of the DISPLAY_PHY_STATUS register and compare it with the real thing. To construct the expected value we look at our shadow PHY_CONTROL register value (which should match what we've just written to the hardware), and we also need to look at the actual state of the cmn power wells as a disabled power well causes the relevant LDO status to be reported as 'on' in DISPLAY_PHY_STATUS. When initially powering up the PHY it performs various internal calibrations for which it fully powers up. That means that if we check for the expetected power state immediately upon releasing cmnreset we would get the occasional false positive. But we can of course poll until the expected value appears. It shouldn't be too long so this shouldn't make modesets substantially longer. One extra complication is introduced when we cross the streams, ie. drive port B with pipe B. In this case we trick CL2 (where the DPLL lives) into life by temporaily powering up the lanes in the second channel, and once the pipe is up and runnign we release the lane power override. At that point the power state of CL2 has somehow gotten entangled with the power state of the first channel. That means that constructing the expected DISPLAY_PHY_STATUS value is a bit tricky since based on the lane power states in the second channel, CL2 should also be powered down. But we can use the DPLL enable bit to determine when CL2 should be alive even if the lanes are powered down. However the power state of CL2 isn't actually tied in with the DPLL state, but to the state of the lanes in first channel, so we have to avoid checking the expected state between shutting down the DPLL and powering down the lanes in the first channel. So no calling assert_chv_phy_status() before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(), but after the write is a safe time to check. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6669e39f |
|
08-Jul-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add some CHV DPIO lane power state asserts Add some checks that the state of the DPIO lanes is more or less what we expect based on the overrides. The hardware only provides two bits per channel indicating whether all or some of the lanes are powered down, so we can't do an exact check. Additionally, CL2 powering down before we can check it adds another twist. To work around this we simply check for the 0 value of the CL2 register (which is what we get when it's powered down) and adjust our expectations. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d8e19f99 |
|
13-Aug-2015 |
Xiong Zhang <xiong.y.zhang@intel.com> |
drm/i915/skl: Adding DDI_E power well domain From B spec, DDI_E port belong to PowerWell 2, but DDI_E share the powerwell_req/staus register bit with DDI_A which belong to DDI_A_E_POWER_WELL. In order to communicate with the connector on DDI-E, both DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled. Currently intel_dp_power_get(DDI_E) only enable DDI_A_E_POWER_WELL, this patch will not only enable DDI_a_E_POWER_WELL but also enable POWER_WELL_2. This patch also fix the DDI-E hotplug function. Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
3e288786 |
|
08-Jul-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Force CL2 off in CHV x1 PHY We can choose to leave the display PHY CL2 powerdown up to some hardware signals, or we can force it. The BXT code forces the nonexistent CL2 in the x1 PHY to power down. Follow suit on CHV. Maybe it can still save some extra power by disabling some extra logic in CL1, or something. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ee279218 |
|
08-Jul-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable DPIO SUS clock gating on CHV CHV has supports some form of automagic clock gating for the DPIO SUS clock. We can simply enable the magic bits and the hardware should take care of the rest. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b0b33846 |
|
08-Jul-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Trick CL2 into life on CHV when using pipe B with port B Normmally the common lane in a PHY channel gets powered up when some of the data lanes get powered up. But when we're driving port B with pipe B we don't want to enabled any of the data lanes, and just want the DPLL in the common lane to be active. To make that happens we have to temporarily enable some data lanes after which we can access the DPLL registers in the common lane. Once the pipe is up and running we can drop the power override on the data lanes allowing them to shut down. From this point forward the common lane will in fact stay powered on until the data lanes in the other channel get powered down. Ville's extended explanation from the review thread: On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote: > One Q, why only for port B? Port C is also in same common lane right? Port B is in the first PHY channel which also houses CL1. CL1 always powers up whenever any lanes in either PHY channel are powered up. CL2 only powers up if lanes in the second channel (ie. the one with port C) powers up. So in this scenario (pipe B->port B) we want the DPLL from CL2, but ideally we only want to power up the lanes for port B. Powering up port B lanes will only power up CL1, but as we need CL2 instead we need to, temporarily, power up some lanes in port C as well. Crossing the streams the other way (pipe A->port C) is not a problem since CL1 powers up whenever anything else powers up. So powering up some port C lanes is enough on its own to make the CL1 DPLL operational, even though CL1 and the lanes live in separate channels. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> [danvet: Amend commit message with extended explanation.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e0fce78f |
|
08-Jul-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement PHY lane power gating for CHV Powergate the PHY lanes when they're not needed. For HDMI all four lanes are needed always, but for DP we can enable only the needed lanes. To power down the unused lanes we use some power down override bits in the DISPLAY_PHY_CONTROL register. Without the overrides it appears that the hardware always powers on all the lanes. When the port is disabled the power down override is not needed and the lanes will shut off on their own. That also means the override is critical to actually be able to access the DPIO registers before the port is actually enabled. Additionally the common lanes will power down when not needed. CL1 remains on as long as anything else is on, CL2 will shut down when all the lanes in the same channel will shut down. There is one exception for CL2 that will be dealt in a separate patch for clarity. With potentially some lanes powered down, the DP code now has to check the number of active lanes before accessing PCS/TX registers. All registers in powered down blocks will reads as 0xffffffff, and soe we would drown in warnings from vlv_dpio_read() if we allowed the code to access all those registers. Another important detail in the DP code is the "TX latency optimal" setting. Normally the second TX lane acts as some kind of reset master, with the other lanes as slaves. But when only a single lane is enabled, that single lane obviously has to be the master. A bit of extra care is needed to reconstruct the initial state of the DISPLAY_PHY_CONTROL register since it can't be read safely. So instead read the actual lane status from the DPLL/PHY_STATUS registers and use that to determine which lanes ought to be powergated initially. We also need to switch the PHY power modes to "deep PSR" to avoid a hard system hang when powering down the single channel PHY. Also sprinkle a few debug prints around so that we can monitor the DISPLAY_PHY_STATUS changes without having to read it and risk corrupting it. v2: Add locking to chv_powergate_phy_lanes() v3: Actually enable dynamic powerdown in the PHY and deal with the fallout Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5a8fbb7d |
|
29-Jun-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move DPLL ref/cri/VGA mode frobbing to the disp2d well enable Bunch of stuff needs the DPLL ref/cri clocks on both VLV and CHV, and having VGA mode enabled causes some problems for CHV. So let's just pull the code to configure those bits into the disp2d well enable hook. With the DPLL disable code also fixed to leave those bits alone we should now have a consistent DPLL state all the time even if the DPLL is disabled. This also neatly removes some duplicated code between the VLV and CHV codepaths. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
770effb1 |
|
08-Jul-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add locking around chv_phy_control_init() dev_priv->chv_phy_control is protected by the power_domains->lock elsewhere, so also grab it when initializing chv_phy_control. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
dcddab3a |
|
30-Jul-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Extract a intel_power_well_disable() function Similar to the ->enable vfunc in patch "drm/i915: Extract a intel_power_well_enable() function". v2 (from Paulo): - Same s/i915_/intel_/ bikeshed as the previous patch. - Update the commit hash. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e8ca9320 |
|
30-Jul-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Extract a intel_power_well_enable() function We need a bit book keeping around power wells' ops->enable(), namely a nice debug message and updating hw_enabled. Let's introduce a intel_power_well_enable() function to make sure all the callers do the same things. v2 (from Paulo): - s/i915_power_well_enable/intel_power_well_enable/ since everything else on this file uses intel_ instead of i915_. - Fix typo in commit message. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2be7d540 |
|
29-Jun-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Refactor VLV display power well init/deinit We do the exact same steps around the disp2d/pipe A power well enable/disable on VLV and CHV. Refactor the shared code into some helpers. Note that this means we now call vlv_power_sequencer_reset() before turning off the power well, whereas before we did it after. That doesn't matter though since vlv_power_sequencer_reset() just resets the power sequencer software tracking and doesn't touch the hardware at all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8fcd5cd8 |
|
29-Jun-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Simplify CHV pipe A power well code The pipe A power well is the "disp2d" well on CHV and pipe B and C wells don't even exist. Thereforce we can remove the checks for pipe A vs. others and just assume it's always pipe A. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
60bfe44f |
|
29-Jun-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Apply OCD to VLV/CHV DPLL defines Drop the spurious 'A' from the VLV/CHV ref clock enable define, and add the "REF" to the VLV ref clock selection bit. Also s/CLOCK/CLK/ for extra consistency. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b8afb911 |
|
29-Jun-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Keep GMCH DPLL VGA mode always disabled We disable the DPLL VGA mode when enabling the DPLL, but we enaable it again when disabling the DPLL. Having VGA mode enabled even in unused DPLLs can cause problems for CHV, so it seems wiser to always keep it disabled. And let's just do that on all GMCH platforms to keep things as similar as possible between them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fde61e4b |
|
26-May-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Throw out WIP CHV power well definitions Expecting CHV power wells to be just an extended versions of the VLV power wells, a bunch of commented out power wells were added in anticipation when Punit folks would implement it all. Turns out they never did, and instead CHV has fewer power wells than VLV. Rip out all the #if 0'ed junk that's not needed. v2: Rename the "pipe-a" well to "display" to match VLV Clarify the pipe A power well relationship to pipes B and C (Deepak) Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bc284542 |
|
26-May-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use the default 600ns LDO programming sequence delay Not sure which LDO programming sequence delay should be used for the CHV PHY, but the spec says that 600ns is "Used by default for initial bringup", and the BIOS seems to use that, so let's do the same. Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7e35ab88 |
|
09-May-2015 |
Masanari Iida <standby24x7@gmail.com> |
drm/i915: Fix typo in intel_runtime_pm.c This patch fix spelling typo in intel_runtime_pm.c Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
71849b67 |
|
10-Apr-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
Revert "drm/i915: Hack to tie both common lanes together on chv" With recent hardware/firmware there don't appear to be any glitches on the other PHY when we toggle the cmnreset for the other PHY. So detangle the cmnlane power wells from one another and let them be controlled independently. This reverts commit 3dd7b97458e8aa2d8985b46622d226fa635071e7. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
70722468 |
|
10-Apr-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Work around DISPLAY_PHY_CONTROL register corruption on CHV Sometimes (exactly when is a bit unclear) DISPLAY_PHY_CONTROL appears to get corrupted. The values I've managed to read from it seem to have some pattern but vary quite a lot. The corruption doesn't seem to just happen when the register is accessed, but can also happen spontaneosly during modeset. When this happens during a modeset things go south and the display doesn't light up. I've managed to hit the problemn when toggling HDMI on port D on and off. When things get corrupted the display doesn't light up, but as soon as I manually write the correct value to the register the display comes up. First I was suspicious that we ourselves accidentally overwrite it with garbage, but didn't catch anything with the reg_rw tracepoint. Also I sprinkled check all over the modeset path to see exactly when the corruption happens, and eg. the read back value was fine just before intel_dp_set_m(), and corrupted immediately after it. I also made my check function repair the register value whenever it was wrong, and with this approach the corruption repeated several times during the modeset operation, always seeming to trigger in the same exact calls to the check function, while other calls to the function never caught anything. So far I've not seen this problem occurring when carefully avoiding all read accesses to DISPLAY_PHY_CONTROL. Not sure if that's just pure luck or an actual workaround, but we can hope it works. So let's avoid reading the register and instead track the desired value of the register in dev_priv. v2: Read out the power well state to determine initial register value v3: Use DPIO_CHx names instead of raw numbers Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6222709d |
|
30-Apr-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Make the Misc I/O power well part of the PLLS domain The specs tell us to ungate PG1 and Misc I/O at display init. We'll use the PLLS power domain to ensure those two power wells are up. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
aeaa2122 |
|
30-Apr-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Add the INIT power domain to the MISC I/O power well Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
93c7cb6c |
|
16-Apr-2015 |
Suketu Shah <suketu.j.shah@intel.com> |
drm/i915/skl: Assert the requirements to enter or exit DC6. Warn if the conditions to enter or exit DC6 are not satisfied such as support for runtime PM, state of power well, CSR loading etc. v2: Removed camelcase in functions and variables. v3: Do some minimal check to assert if CSR program is not loaded. v4: 1] Correct the check for backlight-disabling in assert_can_enable_dc6(). 2] Check csr.loaded = false before disabling DC6 and simplify other checks. v5: 1] Remove checks for DC5 state from assert_can_enable_dc6 function as DC5 is no longer enabled before enabling DC6. 2] Correct the check for CSR-loading in assert_can_disable_dc6 function as CSR must be loaded for context restore to happen on DC6 disabling. v6: 1] It's okay to explicitly disable DC6 during driver-load/resume even though it might already be disabled and so don't warn about it. v7: Rebase to latest. v8: Sqashed the patch from Imre - [PATCH] drm/i915/skl: avoid false CSR fw not loaded WARN during driver load/resume v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v10: During initialization added a early return before disabling DC5. (Animesh) Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Suketu Shah <suketu.j.shah@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
74b4f371 |
|
16-Apr-2015 |
A.Sunil Kamath <sunil.kamath@intel.com> |
Implement enable/disable for Display C6 state This patch just implements the basic enable and disable functions of DC6 state which is needed for SKL platform. Its important to load SKL CSR program before calling enable. DC6 is a deeper power saving state where hardware dynamically disables power well 0 and saves the associated registers. DC6 can be entered when software allows it, the conditions for DC5 are met, and the PCU allows DC6. DC6 cannot be used if the backlight is being driven from the display utility pin. Its better to configure display engine to have power well 2 disabled before getting into DC6 enable function. Hence rpm framework will ensure to check status of power well 2 and DC5 before calling skl_enable_dc6. v2: Replace HAS_ with IS_ check as per Daniel's review comments v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register before setting them as per Satheesh's review comments. v4: No need to call gen9_disable_dc5 inside enable sequence of DC6, as its already take care above. v5: call POSTING_READ for every write to a register to ensure that its written immediately. Call intel_prepare_ddi during DC6 exit as it's required on low-power exit. v6: Protect DC6-enabling-disabling functionality with locks to synchronize with CSR-loading code. v7: Remove grabbing CSR-related mutex in skl_enable/disable_dc6 functions as deferred DC5-enabling functionality is now removed. v8: Remove 'Disabling DC5' from the debug comment during DC6 enabling as when DC6 is allowed, DC5 is not programmed at all. v9: - Rebase to latest. - Move all DC6-related functions from intel_display.c to intel_runtime_pm.c. v10: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f75a1985 |
|
16-Apr-2015 |
Suketu Shah <suketu.j.shah@intel.com> |
drm/i915/skl: Add DC6 Trigger sequence. Add triggers for DC6 as per details provided in skl_enable_dc6 and skl_disable_dc6 implementations. Also Call POSTING_READ for every write to a register to ensure it is written to immediately v1: Remove POSTING_READ and intel_prepare_ddi calls as they've been added in previous patches. v2: 1] Remove check for backlight disabled as it should be the case by that time. 2] Mark DC5 as disabled when enabling DC6. 3] Return from DC5-disabling function early if DC5 is already be disabled which can happen due to DC6-enabling earlier. 3] Ensure CSR firmware is loaded after resume from DC6 as corresponding memory contents won't be retained after runtime-suspend. 4] Ensure that CSR isn't identified as loaded before CSR-loading program is called during runtime-resume. v3: Rebase to latest Modified as per review comments from Imre and after discussion with Art: 1] DC6 should be preferably enabled when PG2 is disabled by SW as the check for PG1 being disabled is taken of by HW to enter DC6, and disabled when PG2 is enabled respectively. This helps save more power, especially in the case when display is disabled but GT is enabled. Accordingly, replacing DC5 trigger sequence with DC6 for SKL. 2] DC6 could be enabled from intel_runtime_suspend() function, if DC5 is already enabled. 3] Move CSR-load-status setting code from intel_runtime_suspend function to a new function. v4: 1] Enable/disable DC6 only when toggling the power-well using a newly defined macro ENABLE_DC6. v5: 1] Load CSR on system resume too as firmware may be lost on system suspend preventing enabling DC5, DC6. 2] DDI buffers shouldn't be programmed during driver-load/resume as it's already done during modeset initialization then and also that the encoder list is still uninitialized by then. Therefore, call intel_prepare_ddi function right after disabling DC6 but outside skl_disable_dc6 function and not during driver-load/resume. v6: 1] Rebase to latest. 2] Move SKL_ENABLE_DC6 macro definition from intel_display.c to intel_runtime_pm.c. v7: 1) Refactored the code for removing the warning got from checkpatch. 2) After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v8: - Reverted the changes done in v7. - Removed the condition check in skl_prepare_resune(). (Animesh) Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Suketu Shah <suketu.j.shah@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5aefb239 |
|
16-Apr-2015 |
Suketu Shah <suketu.j.shah@intel.com> |
drm/i915/skl: Assert the requirements to enter or exit DC5. Warn if the conditions to enter or exit DC5 are not satisfied such as support for runtime PM, state of power well, CSR loading etc. v2: Removed camelcase in functions and variables. v3: Do some minimal check to assert if CSR program is not loaded. v4: 1] Used an appropriate function lookup_power_well() to identify power well, instead of using a magic number which can change in future. 2] Split the conditions further in assert_can_enable_DC5() and added more checks. 3] Removed all WARNs from assert_can_disable_DC5 as they were unnecessary and added two new ones. 4] Changed variable names as updated in earlier patches. v5: 1] Change lookup_power_well function to take an int power well id. 2] Define a new intel_display_power_well_is_enabled helper function to check whether a particular power well is enabled. 3] Use CSR-related mutex in assert_csr_loaded function. v6: Remove use of dc5_enabled variable as it's no longer needed. v7: 1] Rebase to latest. 2] Move all DC5-related functions from intel_display.c to intel_runtime_pm.c. v8: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v9: Modified below changes based on review comments from Imre. - Moved intel_display_power_well_is_enabled() to intel_runtime_pm.c. - Removed mutex lock from assert_csr_loaded(). (Animesh) Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Suketu Shah <suketu.j.shah@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6b457d31 |
|
16-Apr-2015 |
A.Sunil Kamath <sunil.kamath@intel.com> |
drm/i915/skl: Implement enable/disable for Display C5 state. This patch just implements the basic enable and disable functions of DC5 state which is needed for both SKL and BXT. Its important to load respective CSR program before calling enable, which anyways will happen as CSR program is executed during boot. DC5 is a power saving state where hardware dynamically disables power well 1 and the CDCLK PLL and saves the associated registers. DC5 can be entered when software allows it, power well 2 is disabled, and hardware detects that all pipes are disabled or pipe A is enabled with PSR active. Its better to configure display engine to have power well 2 disabled before getting into DC5 enable function. Hence rpm framework will have to ensure to check status of power well 2 before calling gen9_enable_dc5. Rather dc5 entry criteria should be decided based on power well 2 status. If disabled, then call gen9_enable_dc5. v2: Replace HAS_ with IS_ check as per Daniel's review comments v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register before setting them as per Satheesh's review comments. v4: call POSTING_READ for every write to a register to ensure that its written immediately. v5: Modified as per review comments from Imre. - Squashed register definitions into this patch. - Finetuned comments and functions. v6: Avoid redundant writes in gen9_set_dc_state_debugmask_memory_up function. v7: - Rebase to latest. - Move all runtime PM functions defined in intel_display.c to intel_runtime_pm.c. v8: Rebased to drm-intel-nightly. (Animesh) Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
dc174300 |
|
17-Apr-2015 |
Suketu Shah <suketu.j.shah@intel.com> |
drm/i915/skl: Add DC5 Trigger Sequence Add triggers as per expectations mentioned in gen9_enable_dc5 and gen9_disable_dc5 patch. Also call POSTING_READ for every write to a register to ensure that its written immediately. v1: Remove POSTING_READ calls as they've already been added in previous patches. v2: Rebase to move all runtime pm specific changes to intel_runtime_pm.c file. Modified as per review comments from Imre: 1] Change variable name 'dc5_allowed' to 'dc5_enabled' to correspond to relevant functions. 2] Move the check dc5_enabled in skl_set_power_well() to disable DC5 into gen9_disable_DC5 which is a more appropriate place. 3] Convert checks for 'pm.dc5_enabled' and 'pm.suspended' in skl_set_power_well() to warnings. However, removing them for now as they'll be included in a future patch asserting DC-state entry/exit criteria. 4] Enable DC5, only when CSR firmware is verified to be loaded. Create new structure to track 'enabled' and 'deferred' status of DC5. 5] Ensure runtime PM reference is obtained, if CSR is not loaded, to avoid entering runtime-suspend and release it when it's loaded. 6] Protect necessary CSR-related code with locks. 7] Move CSR-loading call to runtime PM initialization, as power domains needed to be accessed during deferred DC5-enabling, are not initialized earlier. v3: Rebase to latest. Modified as per review comments from Imre: 1] Use blocking wait for CSR-loading to finish to enable DC5 for simplicity, instead of deferring enabling DC5 until CSR is loaded. 2] Obtain runtime PM reference during CSR-loading initialization itself as deferred DC5- enabling is removed and release it at the end of CSR-loading functionality. 3] Revert calling CSR-loading functionality to the beginning of i915 driver-load functionality to avoid any delay in loading. 4] Define another variable to track whether CSR-loading failed and use it to avoid enabling DC5 if it's true. 5] Define CSR-load-status accessor functions for use later. v4: 1] Disable DC5 before enabling PG2 instead of after it. 2] DC5 was being mistaken enabled even when CSR-loading timed-out. Fix that. 3] Enable DC5-related functionality using a macro. 4] Remove dc5_enabled tracking variable and its use as it's not needed now. v5: 1] Mark CSR failed to load where necessary in finish_csr_load function. 2] Use mutex-protected accessor function to check if CSR loaded instead of directly accessing the variable. 3] Prefix csr_load_status_get/set function names with intel_. v6: rebase to latest. v7: Rebase on top of nightly (Damien) v8: Squashed the patch from Imre - added csr helper pointers to simplify the code. (Imre) v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v10: Added a enum for different csr states, suggested by Imre. (Animesh) v11: Based on review comments from Imre, Damien and Daniel following changes done - enum name chnaged to csr_state (singular form). - FW_UNINITIALIZED used as zeroth element in enum csr_state. - Prototype changed for helper function(set/get csr status), using enum csr_state instead of bool. v12: Based on review comment from Imre, introduced bool fw_loaded local to finish_csr_load() which helps calling once to set the csr status. The same flag used to fail RPM if find any issue during firmware loading. Issue: VIZ-2819 Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by: Suketu Shah <suketu.j.shah@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
664326f8 |
|
24-Nov-2014 |
A.Sunil Kamath <sunil.kamath@intel.com> |
drm/i915/bxt: Implement enable/disable for Display C9 state v2: Modified as per review comments from Imre - Mention enabling instead of allowing in the debug trace and remove unnecessary comments. v3: - Rebase to latest. - Move DC9-related functions from intel_display.c to intel_runtime_pm.c. v4: (imre) - remove DC5 disabling, it's a nop at this point - squashed in Suketu's "Assert the requirements to enter or exit DC9" patch - remove check for RUNTIME_PM from assert_can_enable_dc9, it's not a dependency Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> (v3) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0b4a2a36 |
|
11-Jul-2014 |
Satheeshakrishna M <satheeshakrishna.m@intel.com> |
drm/i915/bxt: Define BXT power domains Add BXT power domains v2: Use DOMAIN_PLLS instead of a new CDCLK one, whitespace fixes (Damien) v3: add VGA, TRANSCODER_A power domains (imre) Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ca2b1403 |
|
09-Mar-2015 |
Geert Uytterhoeven <geert+renesas@glider.be> |
drm/i915: Spelling s/auxilliary/auxiliary/ Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1d2b9526 |
|
06-Mar-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Restore the DDI translation tables when enabling PW1 I was dumping the DDI translation tables to make sure my patch updating the HDMI entry was doing the right thing when I noticed that the table was showing reset values after DPMS. And indeed, the DDI translation registers are in power well 1 on SKL, and so we're losing their values when shutting down eDP. Calling intel_prepare_ddi() on PW1 enabling re-programs the table. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
25400392 |
|
06-Mar-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Remove unused condition in hsw_power_well_post_enable() We don't use this function on gen9, no need for that test here. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d14c0343 |
|
06-Mar-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Restore pipe interrupt registers after power well enabling The pipe interrupt registers are in the actual pipe power well, so we need to restore them when re-enable the corresponding power well. I've also copied what we do on HSW/BDW for VGA, even if the we haven't enabled unclaimed registers just yet. v2: Don't run skl_power_well_post_enable() if the power well is already enabled (Paulo) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
510e6fdd |
|
06-Mar-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Mirror what we do on HSW for the power well enable log message Just to be more consistent with what we do on HSW. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2a51835f |
|
06-Mar-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Introduce enable_requested and is_enabled in the power well code Just like what we do for HSW/BDW, having those variables makes it a bit easier to parse the code. Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4c6c03be |
|
06-Mar-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Make gen8_irq_power_well_post_enable() take a pipe mask While we only need to restore pipe B/C interrupt registers on BDW when enabling the power well, skylake a bit more flexible and we'll also need to restore the pipe A registers as it has its own power well that can be toggled. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
94dd5138 |
|
04-Feb-2015 |
Satheeshakrishna M <satheeshakrishna.m@intel.com> |
drm/i915/skl: Implementation of SKL display power well support This patch implements core logic of SKL display power well. v2: Addressed Imre's comments - Added respective DDIs under power well #1 and #2 - Simplified repetitive code in power well programming v3: Implemented Imre's comments - Further simplified power well programming - Made sure that PW 1 is enabled prior to PW 2 v4: Fix minor conflict with the the cherryview support (Damien) v5: Add the PLL power domain to the always on power well (Damien) v6: Disable BIOS power well (Imre) Use power well data for comparison (Imre) Put the PLL power domain into PW1 as its needed for CDCLK (Satheesh, Damien) v7: Addressed Imre's comments - Lowered the time out to 1ms - Added parantheses in macro - Moved debug message and fixed wait_for interval v8: - Add a WARN() when swiching on an unknown power well (Imre, done by Damien) - Whitespace fixes (spaces instead of tabs) (Damien) v9: (Imre, done by Damien) - Merge the register definitions with this patch - Merge the MISC IO power well in this patch v10: (Imre, done by Damien) - Define the Misc I/O power domains to be the power well 1 ones as Misc I/O needs to be enabled with PW1 - Added Transcoder A and VGA domains to PW 2 - Remove the MISC_IO power domains as well in the the always on domains definition - Move Misc I/O power well at the top of the power well list so it's turned on right after PW1. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v3,v6,v7) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1407121a |
|
16-Jan-2015 |
Satheeshakrishna M <satheeshakrishna.m@intel.com> |
drm/i915/skl: Adding power domains for AUX controllers Adding new power doamins for AUX controllers v2: Added new power domains in power_domain_str per Imre's comment v3: Added AUX power domains to older platforms v4: Rebase on top of POWER_DOMAIN_PLLS. v5: Modified to address review comments from Imre Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v3) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fcf3aac5 |
|
08-Jan-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: remove unused power_well/get_cdclk_freq api After switching to using the component interface this API isn't needed any more. v2-3: unchanged v4: - move the removal of i915_powerwell.h to this patch (Takashi) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7f1241ed |
|
18-Dec-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Kill check_power_well() calls pps_{lock,unlock}() call intel_display_power_{get,put}() outside pps_mutes to avoid deadlocks with the power_domain mutex. In theory during aux transfers we should usually have the relevant power domain references already held by some higher level code, so this should not result in much overhead (exception being userspace i2c-dev access). However thanks to the check_power_well() calls in intel_display_power_{get/put}() we end up doing a few Punit reads for each aux transfer. Obviously doing this for each byte transferred via i2c-over-aux is not a good idea. I can't think of a good way to keep check_power_well() while eliminating the overhead, so let's just remove check_power_well() entirely. Fixes a driver init time regression introduced by: commit 773538e86081d146e0020435d614f4b96996c1f9 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:56 2014 +0300 drm/i915: Reset power sequencer pipe tracking when disp2d is off Credit goes to Jani for figuring this out. v2: Add the regression note in the commit message. Cc: stable@vger.kernel.org (v3.18+) Cc: Egbert Eich <eich@suse.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201 Tested-by: Wendy Wang <wendy.wang@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
e2c719b7 |
|
15-Dec-2014 |
Rob Clark <robdclark@gmail.com> |
drm/i915: tame the chattermouth (v2) Many distro's have mechanism in place to collect and automatically file bugs for failed WARN()s. And since i915 has a lot of hw state sanity checks which result in WARN(), it generates quite a lot of noise which is somewhat disconcerting to the end user. Separate out the internal hw-is-in-the-state-I-expected checks into I915_STATE_WARN()s and allow configuration via i915.verbose_checks module param about whether this will generate a full blown stacktrace or just DRM_ERROR(). The new moduleparam defaults to true, so by default there is no change in behavior. And even when disabled, you will still get an error message logged. v2: paint the macro names blue, clarify that the default behavior remains the same as before Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f61ccae3 |
|
25-Nov-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Fix short description of intel_display_power_is_enabled() That's the version actually taking the dev_priv->power_domains lock. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
afd6275d |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reinit display irqs and hpd from chv pipe-a power well On chv the pipe-a power well is the new disp2d well, and it kills pretty much everything in the display block. So we need to do the the same dance that vlv does wrt. display irqs and hpd when the power well goes up or down. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
baa4e575 |
|
27-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable pipe-a power well on chv It seems that the pipe-a power well has replaced the disp2d power well on chv. At least that's the case with the current punit firmware. So enable the pipe-a power and expand its domains to cover everything the disp2d well ought to cover. The other power wells (apart from the cmnlane wells) still seem awol in the current punit firmware. So leave them disabled in the code. This fixes a hilarious oops during resume on bsw where intel_hdmi_get_config() would read the port register and get back 0xffffffff and thus think the port is enabled on pipe D. It would then go and index the pipe_to_crtc_mapping[] array with PIPE_D and blow up when intel_hdmi_get_config() tries to write to crtc->config. Someone really ought to replace all naked pipe_to_crtc_mapping[] uses with the appropriate function call so we could add a warning there if the pipe doesn't actually exist... We must also call the power seqeuencer state reset function from the pipe-a well disable just like we do from disp2d on vlv. Otherwise the eDP panel won't recover at resume time since the PPS has lost its hold on the port. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84903 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5d93a6e5 |
|
16-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Do vlv cmnlane toggle w/a in more cases In case the cmnlane power well is down but cmnreset isn't asserted we would currently skip the off+on toggle for the power well. That could leave cmnreset deasserted while cmnlane is powered down which might lead to problems with the PHY. To avoid such issues skip the cmnlane toggle only if both cmnlane and disp2d wells are up and cmnreset is already deasserted. In all other cases power down the cmnlane well which will also make sure cmnreset gets asserted correctly while cmnlane is powered down. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6d729bff |
|
07-Oct-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: only run hsw_power_well_post_enable when really needed Only run it after we actually enable the power well. When we're booting the machine there are cases where we run hsw_power_well_post_enable without really needing, and even though this is not causing any real bugs, it is unneeded and causes confusion to people debugging interrupts. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b963291c |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Use dev_priv instead of dev in irq setup functions It's the new world order! Not going full monty on these here and rolling this out throughout the subsequent call chains since this is just for the kerneldoc. Later on we can go more crazy, especially once we've embedded drm_device correctly. v2: Also frob the runtime_pm functions ... Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e4e7684f |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Kerneldoc for intel_runtime_pm.c I've decided not to document the functions exported to the audio driver since really, they shouldn't exist ... v2: Improvements from Imre's review plus a few more spelling fixes I've spotted. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
41373cd5 |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Call runtime_pm_disable directly Allows us to mark it static and so forgoe the kerneldoc for it. Note that intel_power_domains_fini is also called from failure paths in the driver load sequence. But the call to runtime_pm_disable for that is harmless since by default runtime pm is already disabled. v2: Augment the commit message as discussed with Imre on irc. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d9bc89d9 |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Move intel_display_set_init_power to intel_runtime_pm.c I've decided to not move intel_display_port_power_domain because that's just a hack in our design ... Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f458ebbc |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Bikeshed rpm functions name a bit. - fini goes with init, so call it intel_power_domains_fini. While at it shovel some of the fini code that leaked out of it back in. - give power_enabled functions the verb _is_ to make the meaning clearer. Also use a __ prefix instead of _unlocked to really discourage users. - rename runtime_pm_init/fini to enable/disable since that's what they do. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9c065a7d |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Extract intel_runtime_pm.c Geez is the audio hack ugly. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Rebased on top of the skl patches.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|