summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)AuthorFilesLines
2020-08-17drm/i915/display: Implement WA 1408330847José Roberto de Souza1-2/+17
From the 3 WAs for PSR2 man track/selective fetch this is only one needed when doing single full frames at every flip. Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200810174144.76761-2-jose.souza@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Initial implementation of PSR2 selective fetchJosé Roberto de Souza5-14/+97
All GEN12 platforms supports PSR2 selective fetch but not all GEN12 platforms supports PSR2 hardware tracking(aka RKL). This feature consists in software programming registers with the damaged area of each plane this way hardware will only fetch from memory those areas and sent the PSR2 selective update blocks to panel, saving even more power. But as initial step it is only enabling the full frame fetch at every flip, the actual selective fetch part will come in a future patch. Also this is only handling the page flip side, it is still completely missing frontbuffer modifications, that is why the enable_psr2_sel_fetch parameter was added. v3: - calling intel_psr2_sel_fetch_update() during the atomic check phase (Ville) BSpec: 55229 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200810174144.76761-1-jose.souza@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/tgl: Add new voltage swing tableJosé Roberto de Souza1-0/+19
This new HBR2 table for TGL-U and TGL-Y is required to pass DisplayPort compliance. BSpec: 49291 Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Khaled Almahallawy<khaled.almahallawy@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200807192629.64134-2-jose.souza@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/tgl: Fix TC-cold block/unblock sequenceImre Deak1-5/+5
The command register is the PCODE MBOX low register not the high one as described by the spec. This left the system with the TC-cold power state being blocked all the time. Fix things by using the correct register. Also to make sure we retry a request for at least 600usec, when the PCODE MBOX command itself succeeded, but the TC-cold block command failed, sleep for 1msec unconditionally after any fail. The change was tested with JTAG register read of the HW/FW's actual TC-cold state, which reported the expected states after this change. Tested-by: Nivedita Swaminathan <nivedita.swaminathan@intel.com> Cc: José Roberto de Souza <jose.souza@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/20200805150056.24248-1-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/tgl: Make sure TC-cold is blocked before enabling TC AUX power wellsImre Deak1-6/+6
The dependency between power wells is determined by the ordering of the power well list: when enabling the power wells for a domain, this happens walking the power well list forward, while disabling them happens in the reverse direction. Accordingly a power well on the list must follow any other power well it depends on. Since the TC AUX power wells depend on TC-cold being blocked, move the TC-cold off power well before all AUX power wells. Fixes: 3c02934b24e3 ("drm/i915/tc/tgl: Implement TC cold sequences") Cc: José Roberto de Souza <jose.souza@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/20200720232952.16228-1-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"Matt Roper1-50/+0
The hardware team has dropped this workaround from the bspec; it is no longer needed. This reverts commit 111822b21be995a3a4a731066db3d820523c57f7. Bspec: 49291 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200804044024.1931170-1-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Fix wrong return value in intel_atomic_check()Tianjia Zhang1-1/+1
In the case of calling check_digital_port_conflicts() failed, a negative error code -EINVAL should be returned. Fixes: bf5da83e4bd80 ("drm/i915: Move check_digital_port_conflicts() earier") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200802111535.5200-1-tianjia.zhang@linux.alibaba.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Update bw_buddy pagemask tableMatt Roper1-1/+1
A recent bspec update removed the LPDDR4 single channel entry from the buddy register table, but added a new four-channel entry. Workaround 1409767108 hasn't been updated with any guidance for four channel configurations, so we leave that alternate table unchanged for now. Bspec 49218 Fixes: 3fa01d642fa7 ("drm/i915/tgl: Program BW_BUDDY registers during display init") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612204734.3674650-1-matthew.d.roper@intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Add a couple of missing i915_active_fini()Chris Wilson1-0/+2
We use i915_active_fini() as a debug check on the i915_active state before freeing. If we forget to call it, we may end up angering the debugobjects contained within. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200731085015.32368-1-chris@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/display: Check for an LPSP encoder before dereferencingChris Wilson1-2/+5
Avoid a GPF at <1>[ 20.177320] BUG: kernel NULL pointer dereference, address: 000000000000007c <1>[ 20.177322] #PF: supervisor read access in kernel mode <1>[ 20.177323] #PF: error_code(0x0000) - not-present page <6>[ 20.177324] PGD 0 P4D 0 <4>[ 20.177327] Oops: 0000 [#1] PREEMPT SMP PTI <4>[ 20.177328] CPU: 1 PID: 944 Comm: debugfs_test Not tainted 5.8.0-rc7-CI-CI_DRM_8814+ #1 <4>[ 20.177330] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4>[ 20.177372] RIP: 0010:i915_lpsp_capability_show+0x44/0xc0 [i915] <4>[ 20.177374] Code: 0f b6 81 ca 0d 00 00 3c 0b 74 77 76 19 3c 0c 75 44 83 7e 7c 01 7e 2f 48 c7 c6 d7 b9 47 a0 e8 43 df 06 e1 31 c0 c3 3c 09 72 2b <8b> 46 7c 85 c0 75 e6 8b 82 e4 00 00 00 89 c2 83 e2 fb 83 fa 0a 74 <4>[ 20.177376] RSP: 0018:ffffc90000cebe38 EFLAGS: 00010246 <4>[ 20.177377] RAX: 0000000000000009 RBX: ffff888267fe6a58 RCX: ffff888252d10000 <4>[ 20.177378] RDX: ffff88824a9a4000 RSI: 0000000000000000 RDI: ffff888267fe6a30 <4>[ 20.177379] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 <4>[ 20.177380] R10: 0000000000000001 R11: 0000000000000000 R12: ffffc90000cebf08 <4>[ 20.177381] R13: 00000000ffffffff R14: 0000000000000001 R15: ffff888267fe6a30 <4>[ 20.177383] FS: 00007f6f9c6b5e40(0000) GS:ffff888276480000(0000) knlGS:0000000000000000 <4>[ 20.177384] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 20.177385] CR2: 000000000000007c CR3: 0000000255f04006 CR4: 00000000003606e0 <4>[ 20.177386] Call Trace: <4>[ 20.177390] seq_read+0xcb/0x420 which is presumably from having no encoder attached at that time. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2175 Fixes: 8806211fe7b3 ("drm/i915: Add i915_lpsp_capability debugfs") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200729130912.30093-1-chris@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/display/fbc: Disable fbc by default on TGLUma Shankar1-0/+7
Fbc is causing random underruns in CI execution on TGL platforms. Disabling the same while the problem is being debugged and analyzed. v2: Moved the check below the module param check (Ville) Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716145857.6911-1-uma.shankar@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Implement WA 14011294188José Roberto de Souza1-0/+6
Although the WA description targets the platforms it is a workaround for the affected PCHs, that is why it is being checked. v2: excluding DG1 fake PCH from WA BSpec: 52890 BSpec: 53273 BSpec: 52888 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200727164729.28836-1-jose.souza@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/rkl: Add Wa_14011224835 for PHY B initializationMatt Roper1-0/+50
After doing normal PHY-B initialization on Rocket Lake, we need to manually copy some additional PHY-A register values into PHY-B registers. Note that the bspec's combo phy page doesn't specify that this workaround is restricted to specific platform steppings (and doesn't even do a very good job of specifying that RKL is the only platform this is needed on), but the RKL workaround page lists this as relevant only for A and B steppings, so I'm trusting that information for now. v2: Make rkl_combo_phy_b_init_wa() static v3: - Minimize variables in WA function. (Jose) - Fix timeout duration (usec vs msec). (Jose) - Add verification of workaround. (Jose) - Fix stepping bounds in comment. Bspec: 49291 Bspec: 53273 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-6-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/rkl: Handle HTIMatt Roper3-0/+38
If HTI (also sometimes called HDPORT) is enabled at startup, it may be using some of the PHYs and DPLLs making them unavailable for general usage. Let's read out the HDPORT_STATE register and avoid making use of resources that HTI is already using. v2: - Fix minor checkpatch warnings v3: - Just readout HDPORT_STATE register once during init and then parse it later as needed. - Add a 'has_hti' device info flag to track whether we should readout HDPORT_STATE or not. We can skip the platform/flag tests later since the hti_state in dev_priv will remain 0 for platforms it does not apply to. - Move PLL masking into icl_get_combo_phy_dpll() since at the moment RKL is the only platform that has HTI. (Jose) Bspec: 49189 Bspec: 53707 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-5-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/rkl: Add DPLL4 supportMatt Roper1-5/+36
Rocket Lake has a third DPLL (called 'DPLL4') that must be used to enable a third display. Unlike EHL's variant of DPLL4, the RKL variant behaves the same as DPLL0/1. And despite its name, the DPLL4 registers are offset as if it were DPLL2. v2: - Add new .update_ref_clks() hook. v3: - Renumber TBT PLL to '3' and switch _MMIO_PLL3 to _MMIO_PLL (Lucas) v4: - Don't drop _MMIO_PLL3; although it's now unused, we're going to need it very soon again for upcoming DG1 patches. (Lucas) v5: - Don't re-number TBT PLL and beyond, just use new RKL_DPLL_CFGCR macros to lookup the proper registers instead. Although renumbering the PLLs might be something we want to consider down the road, it opens a big can of worms right now since a bunch of places in the code have an assumption that the PLL table has idx==id and no holes. Renumbering creates a hole for TGL, so we'd either need to allow holes in the table or break the idx==id invariant, both of which are somewhat invasive changes to the design. Bspec: 49202 Bspec: 49443 Bspec: 50288 Bspec: 50289 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-4-matthew.d.roper@intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/rkl: Add initial workaroundsMatt Roper1-2/+3
RKL and TGL share some general gen12 workarounds, but each platform also has its own platform-specific workarounds. v2: - Add Wa_1604555607 for RKL. This makes RKL's ctx WA list identical to TGL's, so we'll have both functions call the tgl_ function for now; this workaround isn't listed for DG1 so we don't want to add it to the general gen12_ function. Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-3-matthew.d.roper@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/rkl: Handle new DPCLKA_CFGCR0 layoutMatt Roper2-6/+27
RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register. v2: - Fix inverted mask application when updating ICL_DPCLKA_CFGCR0 - Checkpatch style fixes Bspec: 50287 Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-2-matthew.d.roper@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/display: Implement HOBLJosé Roberto de Souza3-6/+59
Hours Of Battery Life is a new GEN12+ power-saving feature that allows supported motherboards to use a special voltage swing table for eDP panels that uses less power. So here if supported by HW, OEM will set it in VBT and i915 will try to train link with HOBL vswing table if link training fails it fall back to the original table. intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag instead of do something like is done in intel_ddi_dp_voltage_max() because it is only called after the first entry of the voltage swing table was loaded so the HOBL flag is valid at that point. v3: - removed a few parameters of icl_ddi_combo_vswing_program() that can be taken from encoder v4: - using the HOBL vswing table until training fails completely (Ville) v5: - not reducing lane or link rate when link training fails with HOBL active - duplicated the HOBL voltage swing entry to match DP spec requirement v6: - removed the optional VS 3 & pre-emp 0 from HOBL table - changed from u8:1 to bool to store hobl_failed/active BSpec: 49291 BSpec: 49399 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200715175637.33763-1-jose.souza@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/ddi: Don't rewrite DDI_BUF_CTL reg during DP link trainingImre Deak1-4/+0
The value we program to DDI_BUF_CTL changes at the following places: - At enabling/disabling the output to configure the port width etc, and to enable/disable the DDI BUF function. - At the beginning/end of link re-training to disable/re-enable the DDI BUF function. - On HSW/BDW/SKL to change the voltage swing/pre-emph levels. Except of the above the value we program to the DDI_BUF_CTL register (intel_dp->DP) doesn't change, so no need to reprogram the register when changing the link training patterns (which is programmed via the DP_TP_CTL register on DDI platforms). v2: - Fix the commit message wrt. voltage/pre-emph level values in intel_dp->DP. (Ville) 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/20200714153141.10280-2-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/ddi: Don't frob the DP link scramble disabling flagImre Deak1-7/+1
According to BSpec this flag should not be changed while the DDI function is enabled. On BDW+ the DP_TP_CTL register spec also states it explicitly that the HW takes care of enabling/disabling the scrambling for training patterns (and it must stay enabled for normal pixel output). Assume that this HW automatic handling of scrambling is also true for HSW. BSpec: 8013, 7557, 50484 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/20200714153141.10280-1-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Make i830 .get_cdclk() assignment less confusingVille Syrjälä1-4/+5
Explicitly check for i830 when assigning the .get_cdclk() vfunc, and then deal with the case of not having assigned the vfunc separately. Less confusing, and gets rid of the checkpatch complaint about using {} on one branch but not the others. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Fix some whitespaceVille Syrjälä1-1/+1
Some spaces have snuck in where we want tabs. Fix it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915: Pack struct intel_cdclk_valsVille Syrjälä1-1/+1
There's a pointless hole in struct intel_cdclk_vals, get rid of it. Fortunately we already use named initializers so the order does not matter. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-17drm/i915/fbc: Limit cfb to the first 256MiB of stolen on g4x+Ville Syrjälä1-0/+10
Since g4x the CFB base only takes a 28bit offset into stolen. Not sure if the CFB is allowed to start below that limit but then extend beyond it. Let's assume not and just restrict the allocation to the first 256MiB (in the unlikely case we have more stolen than that). v2: s/BIT/BIT_ULL/ (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714201945.18959-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-08-15Merge tag 'pwm/for-5.9-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "The majority of this batch is conversion of the PWM period and duty cycle to 64-bit unsigned integers, which is required so that some types of hardware can generate the full range of signals that they're capable of. The remainder is mostly minor fixes and cleanups" * tag 'pwm/for-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: bcm-iproc: handle clk_get_rate() return pwm: Replace HTTP links with HTTPS ones pwm: omap-dmtimer: Repair pwm_omap_dmtimer_chip's broken kerneldoc header pwm: mediatek: Provide missing kerneldoc description for 'soc' arg pwm: bcm-kona: Remove impossible comparison when validating duty cycle pwm: bcm-iproc: Remove impossible comparison when validating duty cycle pwm: iqs620a: Use lowercase hexadecimal literals for consistency pwm: Convert period and duty cycle to u64 clk: pwm: Use 64-bit division function backlight: pwm_bl: Use 64-bit division function pwm: sun4i: Use nsecs_to_jiffies to avoid a division pwm: sifive: Use 64-bit division macro pwm: iqs620a: Use 64-bit division pwm: imx27: Use 64-bit division macro pwm: imx-tpm: Use 64-bit division macro pwm: clps711x: Use 64-bit division macro hwmon: pwm-fan: Use 64-bit division macro drm/i915: Use 64-bit division macro
2020-08-12Merge drm/drm-next into drm-misc-nextThomas Zimmermann50-1573/+2532
Backmerging drm-next into drm-misc-next for nouveau and panel updates. Resolves a conflict between ttm and nouveau, where struct ttm_mem_res got renamed to struct ttm_resource. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2020-08-11drm/i915: utilize subconnector property for DPOleg Vasilev1-0/+8
Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: updates to match previous commit changes v3: rebase v4: renamed a function call Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b@intel.com> Signed-off-by: Oleg Vasilev <oleg.vasilev@intel.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> #and acked for merging Tested-by: Oleg Vasilev <oleg.vasilev@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1587732655-17544-2-git-send-email-jeevan.b@intel.com
2020-08-06Merge tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drmLinus Torvalds51-1561/+2545
Pull drm updates from Dave Airlie: "New xilinx displayport driver, AMD support for two new GPUs (more header files), i915 initial support for RocketLake and some work on their DG1 (discrete chip). The core also grew some lockdep annotations to try and constrain what drivers do with dma-fences, and added some documentation on why the idea of indefinite fences doesn't work. The long list is below. I do have some fixes trees outstanding, but I'll follow up with those later. core: - add user def flag to cmd line modes - dma_fence_wait added might_sleep - dma-fence lockdep annotations - indefinite fences are bad documentation - gem CMA functions used in more drivers - struct mutex removal - more drm_ debug macro usage - set/drop master api fixes - fix for drm/mm hole size comparison - drm/mm remove invalid entry optimization - optimise drm/mm hole handling - VRR debugfs added - uncompressed AFBC modifier support - multiple display id blocks in EDID - multiple driver sg handling fixes - __drm_atomic_helper_crtc_reset in all drivers - managed vram helpers ttm: - ttm_mem_reg handling cleanup - remove bo offset field - drop CMA memtype flag - drop mappable flag xilinx: - New Xilinx ZynqMP DisplayPort Subsystem driver nouveau: - add CRC support - start using NVIDIA published class header files - convert all push buffer emission to new macros - Proper push buffer space management for EVO/NVD channels. - firmware loading fixes - 2MiB system memory pages support on Pascal and newer vkms: - larger cursor support i915: - Rocketlake platform enablement - Early DG1 enablement - Numerous GEM refactorings - DP MST fixes - FBC, PSR, Cursor, Color, Gamma fixes - TGL, RKL, EHL workaround updates - TGL 8K display support fixes - SDVO/HDMI/DVI fixes amdgpu: - Initial support for Sienna Cichlid GPU - Initial support for Navy Flounder GPU - SI UVD/VCE support - expose rotation property - Add support for unique id on Arcturus - Enable runtime PM on vega10 boards that support BACO - Skip BAR resizing if the bios already did id - Major swSMU code cleanup - Fixes for DCN bandwidth calculations amdkfd: - Track SDMA usage per process - SMI events interface radeon: - Default to on chip GART for AGP boards on all arches - Runtime PM reference count fixes msm: - headers regenerated causing churn - a650/a640 display and GPU enablement - dpu dither support for 6bpc panels - dpu cursor fix - dsi/mdp5 enablement for sdm630/sdm636/sdm66 tegra: - video capture prep support - reflection support mediatek: - convert mtk_dsi to bridge API meson: - FBC support sun4i: - iommu support rockchip: - register locking fix - per-pixel alpha support PX30 VOP mgag200: - ported to simple and shmem helpers - device init cleanups - use managed pci functions - dropped hw cursor support ast: - use managed pci functions - use managed VRAM helpers - rework cursor support malidp: - dev_groups support hibmc: - refactor hibmc_drv_vdac: vc4: - create TXP CRTC imx: - error path fixes and cleanups etnaviv: - clock handling and error handling cleanups - use pin_user_pages" * tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm: (1747 commits) drm/msm: use kthread_create_worker instead of kthread_run drm/msm/mdp5: Add MDP5 configuration for SDM636/660 drm/msm/dsi: Add DSI configuration for SDM660 drm/msm/mdp5: Add MDP5 configuration for SDM630 drm/msm/dsi: Add phy configuration for SDM630/636/660 drm/msm/a6xx: add A640/A650 hwcg drm/msm/a6xx: hwcg tables in gpulist drm/msm/dpu: add SM8250 to hw catalog drm/msm/dpu: add SM8150 to hw catalog drm/msm/dpu: intf timing path for displayport drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3 drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845 drm/msm/dpu: move some sspp caps to dpu_caps drm/msm/dpu: update UBWC config for sm8150 and sm8250 drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250 drm/msm/a6xx: set ubwc config for A640 and A650 drm/msm/adreno: un-open-code some packets drm/msm: sync generated headers drm/msm/a6xx: add build_bw_table for A640/A650 drm/msm/a6xx: fix crashstate capture for A650 ...
2020-08-04Merge tag 'uninit-macro-v5.9-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull uninitialized_var() macro removal from Kees Cook: "This is long overdue, and has hidden too many bugs over the years. The series has several "by hand" fixes, and then a trivial treewide replacement. - Clean up non-trivial uses of uninitialized_var() - Update documentation and checkpatch for uninitialized_var() removal - Treewide removal of uninitialized_var()" * tag 'uninit-macro-v5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: compiler: Remove uninitialized_var() macro treewide: Remove uninitialized_var() usage checkpatch: Remove awareness of uninitialized_var() macro mm/debug_vm_pgtable: Remove uninitialized_var() usage f2fs: Eliminate usage of uninitialized_var() macro media: sur40: Remove uninitialized_var() usage KVM: PPC: Book3S PR: Remove uninitialized_var() usage clk: spear: Remove uninitialized_var() usage clk: st: Remove uninitialized_var() usage spi: davinci: Remove uninitialized_var() usage ide: Remove uninitialized_var() usage rtlwifi: rtl8192cu: Remove uninitialized_var() usage b43: Remove uninitialized_var() usage drbd: Remove uninitialized_var() usage x86/mm/numa: Remove uninitialized_var() usage docs: deprecated.rst: Add uninitialized_var()
2020-07-31Merge tag 'drm-intel-next-2020-07-15' of ↵Dave Airlie27-746/+944
git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 features for v5.9, batch #2 Highlights: - Very early DG1 enabling (Abdiel, Lucas, Anusha) Gem/GT: - Fix spinlock recursion on signaling a signaled request (Chris) - Perf: Use GTT when saving/restoring engine GPR (Umesh Nerlige Ramappa) - SSEU refactoring, debugfs move under gt/ (Daniele, Venkata Sandeep Dhanalakota) - Various GT refactoring and cleanup, preparation for future changes (Daniele) - Adjust HuC state accordingly after GuC fetch error (Michał Winiarski) - UC debugfs updates (Michał Winiarski) - Only revoke the GGTT mmappings on aperture detiling changes (Chris) - Only revoke mmap handlers if active (Chris) - Split the context's obj:vma lut into its own mutex (Chris) - Various memory, mmap and performance optimisations (Chris) - Improve system stability in case of false CS events (Chris) - Various refactorings and cleanup (Chris) - Always reset the engine on execlist failures (Chris) - Trace placement of timeline HWSP (Chris) - Update dma-attributes for our sg DMA (Chris) Display: - TGL CDCLK workaround tweaks to unbreak 8K display support (Stanislav) - A number of FBC fixes, along with i865 FBC enabling (Ville) - Validate MST modes against PBN limits (Lyude, Shawn Lee) - Do not access non-existing swizzle registers (Lucas) - Revert GEN11+ HBR3 rate fix that caused issues on TGL (Matt Atwood) - Update TGL+ combo phy initialization to match spec update (José) - Fix HDCP Content Protection property state machine (Anshuman) - Fix HDCP revoked keys handling (Ram) - Improve DDI BUF status checks and waits (Manasi) - Various SDVO+HDMI+DVI fixes around colorimetry, clocking, pixel repeat etc. (Ville) - DP voltage swing function refactoring (José) - WARN if max vswing/pre-emphasis violates the DP spec (Ville) Other: - Add new EHL PCI IDs (José) - Unify struct intel_digital_port variable naming (Lucas) - Various taint updates to aid debugging and improve CI (Michał Winiarski) - Straggler conversions to new mmio register accessors (Daniele) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87a70029vz.fsf@intel.com
2020-07-24Merge v5.8-rc6 into drm-nextDave Airlie2-15/+28
I've got a silent conflict + two trees based on fixes to merge. Fixes a silent merge with amdgpu Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-07-20Merge tag 'drm-misc-next-2020-07-16' of ↵Dave Airlie1-10/+16
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.9: UAPI Changes: Cross-subsystem Changes: - Add ckoenig as dma-buf maintainer. - Revert invalid fix for dma-fence-chain, and fix selftest. - Add fixmes to amifb about APUS support. - Use array3_size in fbcon_prepare_logo, and struct_size() in alloc_apertures. - Fix leaks in neofb, fb/savage and omapfb. - Other small fixes to fb code. - Convert some dt bindings to schema for some panels, and fix simple-framebuffer dt example. Core Changes: - Add DRM_FORMAT_MOD_GENERIC_16_16_TILE as alias to DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, as it can be used more generic. - Add support for multiple DispID extension blocks in edid. - Use https instead of http for some of the urls. - Use drm_* macros for logging in mipi-dsi and fb-helper. - Further cleanup ttm_mem_reg handling. - Remove duplicated words in comments. Driver Changes: - Use __drm_atomic_helper_crtc_reset in all atomic drivers. - Add Amlogic Video FBC support to meson and fourcc to core. - Refactor hisilicon's hibmc_drv_vdac. - Create a TXP CRTC for vc4. - Rework cursor support in ast. - Fix runtime PM in STM. - Allow bigger cursors in vkms. - Cleanup sg handling in radeon and amdgpu, and stop creating dummy gtt nodes with ttm fixed. - Rework crtc handling in mgag200. - Miscellaneous small fixes to meson, vgem, bridge/dw-hdmi, panel/auo,b116xw03, panel/LG LB070WV8, lima, bridge/sil_sii8620, virtio, tilcdc. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8b360d65-f228-9286-d247-3004156a5254@linux.intel.com
2020-07-16treewide: Remove uninitialized_var() usageKees Cook1-1/+1
Using uninitialized_var() is dangerous as it papers over real bugs[1] (or can in the future), and suppresses unrelated compiler warnings (e.g. "unused variable"). If the compiler thinks it is uninitialized, either simply initialize the variable or make compiler changes. In preparation for removing[2] the[3] macro[4], remove all remaining needless uses with the following script: git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \ xargs perl -pi -e \ 's/\buninitialized_var\(([^\)]+)\)/\1/g; s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;' drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid pathological white-space. No outstanding warnings were found building allmodconfig with GCC 9.3.0 for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64, alpha, and m68k. [1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/ [2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/ [3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/ [4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/ Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5 Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs Signed-off-by: Kees Cook <keescook@chromium.org>
2020-07-14drm/i915: Recalculate FBC w/a stride when neededVille Syrjälä1-7/+26
Currently we're failing to recalculate the gen9 FBC w/a stride unless something more drastic than just the modifier itself has changed. This often leaves us with FBC enabled with the linear fbdev framebuffer without the w/a stride enabled. That will cause an immediate underrun and FBC will get promptly disabled. Fix the problem by checking if the w/a stride is about to change, and go through the full dance if so. This part of the FBC code is still pretty much a disaster and will need lots more work. But this should at least fix the immediate issue. v2: Deactivate FBC when the modifier changes since that will likely require resetting the w/a CFB stride Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711080336.13423-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 0428ab013fdd39dbfb8f4cd8ad2b60af3776c6b9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-14drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.Maarten Lankhorst1-8/+2
This fixes the following KASAN splash on module reload: [ 145.136327] ================================================================== [ 145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134 [ 145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G U T 5.5.0-rc7-valkyria+ #5783 [ 145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016 [ 145.136546] Workqueue: events drm_connector_free_work_fn [ 145.136551] Call Trace: [ 145.136560] dump_stack+0xa1/0xe0 [ 145.136571] print_address_description.constprop.0+0x1e/0x210 [ 145.136639] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136703] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136710] __kasan_report.cold+0x1b/0x37 [ 145.136790] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136863] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136870] kasan_report+0x27/0x30 [ 145.136881] __asan_report_load8_noabort+0x1c/0x20 [ 145.136946] intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136954] drm_connector_free_work_fn+0xd1/0x100 [ 145.136967] process_one_work+0x86e/0x1610 [ 145.136987] ? pwq_dec_nr_in_flight+0x2f0/0x2f0 [ 145.137004] ? move_linked_works+0x128/0x2c0 [ 145.137021] worker_thread+0x63e/0xc90 [ 145.137048] kthread+0x2f6/0x3f0 [ 145.137054] ? calculate_sigpending+0x81/0xa0 [ 145.137059] ? process_one_work+0x1610/0x1610 [ 145.137064] ? kthread_bind+0x40/0x40 [ 145.137075] ret_from_fork+0x24/0x30 [ 145.137111] Allocated by task 0: [ 145.137119] (stack is not available) [ 145.137137] Freed by task 5053: [ 145.137147] save_stack+0x28/0x90 [ 145.137152] __kasan_slab_free+0x136/0x180 [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137581] __x64_sys_delete_module+0x35b/0x470 [ 145.137586] do_syscall_64+0x99/0x4e0 [ 145.137591] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 145.137606] The buggy address belongs to the object at ffff888216640000 which belongs to the cache kmalloc-8k of size 8192 [ 145.137618] The buggy address is located 6192 bytes inside of 8192-byte region [ffff888216640000, ffff888216642000) [ 145.137630] The buggy address belongs to the page: [ 145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0 [ 145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80 [ 145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000 [ 145.137656] page dumped because: kasan: bad access detected [ 145.137668] Memory state around the buggy address: [ 145.137678] ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137687] ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137706] ^ [ 145.137715] ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137724] ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137733] ================================================================== [ 145.137742] Disabling lock debugging due to kernel taint Changes since v1: - Add fixes tags. - Use early unregister. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi") Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200212135445.1469133-1-maarten.lankhorst@linux.intel.com (cherry picked from commit a581483b1e5466d28fc50ff623fba31cea2cccb6) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-07-14drm/i915: Recalculate FBC w/a stride when neededVille Syrjälä1-7/+26
Currently we're failing to recalculate the gen9 FBC w/a stride unless something more drastic than just the modifier itself has changed. This often leaves us with FBC enabled with the linear fbdev framebuffer without the w/a stride enabled. That will cause an immediate underrun and FBC will get promptly disabled. Fix the problem by checking if the w/a stride is about to change, and go through the full dance if so. This part of the FBC code is still pretty much a disaster and will need lots more work. But this should at least fix the immediate issue. v2: Deactivate FBC when the modifier changes since that will likely require resetting the w/a CFB stride Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711080336.13423-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-07-14drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.Maarten Lankhorst1-8/+2
This fixes the following KASAN splash on module reload: [ 145.136327] ================================================================== [ 145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134 [ 145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G U T 5.5.0-rc7-valkyria+ #5783 [ 145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016 [ 145.136546] Workqueue: events drm_connector_free_work_fn [ 145.136551] Call Trace: [ 145.136560] dump_stack+0xa1/0xe0 [ 145.136571] print_address_description.constprop.0+0x1e/0x210 [ 145.136639] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136703] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136710] __kasan_report.cold+0x1b/0x37 [ 145.136790] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136863] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136870] kasan_report+0x27/0x30 [ 145.136881] __asan_report_load8_noabort+0x1c/0x20 [ 145.136946] intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136954] drm_connector_free_work_fn+0xd1/0x100 [ 145.136967] process_one_work+0x86e/0x1610 [ 145.136987] ? pwq_dec_nr_in_flight+0x2f0/0x2f0 [ 145.137004] ? move_linked_works+0x128/0x2c0 [ 145.137021] worker_thread+0x63e/0xc90 [ 145.137048] kthread+0x2f6/0x3f0 [ 145.137054] ? calculate_sigpending+0x81/0xa0 [ 145.137059] ? process_one_work+0x1610/0x1610 [ 145.137064] ? kthread_bind+0x40/0x40 [ 145.137075] ret_from_fork+0x24/0x30 [ 145.137111] Allocated by task 0: [ 145.137119] (stack is not available) [ 145.137137] Freed by task 5053: [ 145.137147] save_stack+0x28/0x90 [ 145.137152] __kasan_slab_free+0x136/0x180 [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137581] __x64_sys_delete_module+0x35b/0x470 [ 145.137586] do_syscall_64+0x99/0x4e0 [ 145.137591] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 145.137606] The buggy address belongs to the object at ffff888216640000 which belongs to the cache kmalloc-8k of size 8192 [ 145.137618] The buggy address is located 6192 bytes inside of 8192-byte region [ffff888216640000, ffff888216642000) [ 145.137630] The buggy address belongs to the page: [ 145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0 [ 145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80 [ 145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000 [ 145.137656] page dumped because: kasan: bad access detected [ 145.137668] Memory state around the buggy address: [ 145.137678] ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137687] ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137706] ^ [ 145.137715] ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137724] ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137733] ================================================================== [ 145.137742] Disabling lock debugging due to kernel taint Changes since v1: - Add fixes tags. - Use early unregister. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi") Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200212135445.1469133-1-maarten.lankhorst@linux.intel.com
2020-07-14drm/i915: WARN if max vswing/pre-emphasis violates the DP specVille Syrjälä1-0/+9
According to the DP spec a DPTX must support vswing/pre-emphasis up to and including level 2. Level 3 is optional (actually DP 1.4a seems to make even level 3 mandatory for HBR2/3, while leaving it optional for RBR/HBR1). WARN if out encoders' .voltage_max()/.preemph_max() return an illegal value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200709145845.18118-1-ville.syrjala@linux.intel.com
2020-07-13drm/i915/mst: filter out the display mode exceed sink's capabilityLee Shawn C1-17/+38
So far, max dot clock rate for MST mode rely on physcial bandwidth limitation. It would caused compatibility issue if source display resolution exceed MST hub output ability. For example, source DUT had DP 1.2 output capability. And MST docking just support HDMI 1.4 spec. When a HDMI 2.0 monitor connected. Source would retrieve EDID from external and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps because it did not surpass DP physical bandwidth limitation. Do modeset to 4k@60fps, source output display data but MST docking can't output HDMI properly due to this resolution already over HDMI 1.4 spec. Refer to commit <fcf463807596> ("drm/dp_mst: Use full_pbn instead of available_pbn for bandwidth checks"). Source driver should refer to full_pbn to evaluate sink output capability. And filter out the resolution surpass sink output limitation. Changes since v1: * Using mgr->base.lock to protect full_pbn. Changes since v2: * Add ctx lock. Changes since v3: * s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/ intel_dp_mst_mode_clock_exceeds_pbn_bw/ * Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe down the drm_modeset_acquire_ctx that the probe helpers are using, so we can safely grab &mgr->base.lock without deadlocking Changes since v4: * Move drm_dp_calc_pbn_mode(mode->clock, bpp, false) > port->full_pbn check * Fix the bpp we use in drm_dp_calc_pbn_mode() * Drop leftover (!mgr) check * Don't check for if full_pbn is unset. To be clear - it _can_ be unset, but if it is then it's certainly a bug in DRM or a non-compliant sink as full_pbn should always be populated by the time we call ->mode_valid_ctx. We should workaround non-compliant sinks with full_pbn=0, but that should happen in the DP MST helpers so we can estimate the full_pbn value as best we can. Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Co-developed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713170746.254388-3-lyude@redhat.com
2020-07-09drm/i915/bios: Parse HOBL parameterJosé Roberto de Souza2-0/+4
HOBL means hours of battery life, it is a power-saving feature were supported motherboards can use a special voltage swing table that uses less power. So here parsing the VBT to check if this feature is supported. BSpec: 20150 Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708205512.21625-3-jose.souza@intel.com
2020-07-09drm/i915/display: Remove port and phy from voltage swing functionsJosé Roberto de Souza1-19/+14
This information can be get directly from intel_encoder so no need of those parameters. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708205512.21625-2-jose.souza@intel.com
2020-07-09drm/i915/display: Replace drm_i915_private in voltage swing functions by ↵José Roberto de Souza1-69/+95
intel_encoder intel_encoder will be needed inside of vswing functions in a future patch, so here doing this change in all vswing functions since HSW. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708205512.21625-1-jose.souza@intel.com
2020-07-09drm/i915: Move all FBC w/as to .init_clock_gating()Ville Syrjälä1-15/+0
Some platforms apply the FBC w/as in .init_clock_gating(), some in fbc_activate(). Move them all to .init_clock_gating() for consistentce. Also safer since we don't have to worry about the RMWs clashing with any other runtime use of the same registers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708131223.9519-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-07-09drm/i915/dvo: Make .get_modes() return the number of modesVille Syrjälä1-6/+8
.get_modes() is supposed to return the number of modes added to the probed_modes list (not that anyone actually checks for anything except zero vs. not zero). Let's do that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-9-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-09drm/i915/sdvo: Make .get_modes() return the number of modesVille Syrjälä1-23/+33
.get_modes() is supposed to return the number of modes added to the probed_modes list (not that anyone actually checks for anything except zero vs. not zero). Let's do that. Also switch over to using intel_connector_update_modes() instead of hand rolling it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-8-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-09drm/i915/sdvo: Make SDVO deal with HDMI pixel repeatVille Syrjälä1-4/+23
With SDVO the pipe config pixel_multiplier only concerns itself with the data on the SDVO bus. Any HDMI specific pixel repeat must be handled by the SDVO device itself. To do that simply configure the SDVO pixel replication factor appropriately. We already set up the infoframe PRB values correctly via the infoframe helpers. There is no cap we can check for this. The spec says that 1X,2X,4X are mandatory, anything else is optional. 1X and 2X are all we need so we should be able to assume they work. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-7-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-09drm/i915: Reject DRM_MODE_FLAG_DBLCLK with DVI sinksVille Syrjälä1-1/+4
The code assumes that DRM_MODE_FLAG_DBLCLK means that we enable the pixel repeat feature. That only works with HDMI since it requires AVI infoframe to signal the information to the sink. Hence even if the mode dotclock would be valid we cannot currently assume that we can just ignore the DBLCLK flag. Reject it for DVI sinks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-6-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-09drm/i915/sdvo: Implement limited color range for SDVO HDMI properlyVille Syrjälä4-26/+45
The SDVO/HDMI port register limited color range bit can only be used with TMDS encoding and not SDVO encoding, ie. to be used only when using the port as a HDMI port as opposed to a SDVO port. The SDVO spec does have a note that some GMCHs might allow that, but gen4 bspec vehemently disagrees. I suppose on ILK+ it might work since the color range handling is on the CPU side rather than on the PCH side, so there is no clear linkage between the TMDS vs. SDVO encoding and color range. Alas, I have no hardware to test that theory. To implement limited color range support for SDVO->HDMI we need to ask the SDVO device to do the range compression. Do so, but first check if the device even supports the colorimetry selection. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-5-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-09drm/i915/sdvo: Fix SDVO colorimetry bit definesVille Syrjälä1-4/+4
Fix up the SDVO colorimetry bits to match the spec. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-4-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-08drm/i915/dp: Helper to check for DDI BUF status to get activeManasi Navare1-1/+16
Based on the platform, Bspec expects us to wait or poll with timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active after enabling DDI_BUF_CTL. v2: * Based on platform, fixed delay or poll (Ville) * Use a helper to do this (Imre, Ville) v3: * Add a new function _active for DDI BUF CTL to be non idle (Ville) v4: * Use the timeout for GLK (Ville) v5: * Add bspec quote, change timeout to 500us (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701221052.8946-2-manasi.d.navare@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 05:21:31 +0300