- 04 Feb, 2021 2 commits
-
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
- WARN if plane src coords are too big (Ville) - Prevent double YUV range correction on HDR planes (Andres) - DP MST related Fixes (Sean, Imre) - More clean-up around DRAM detection code (Jose) - Actually async flips enable for all ilk+ platforms (Ville) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129225328.GA1041349@intel.com
-
ssh://git.freedesktop.org/git/tegra/linuxDave Airlie authored
drm/tegra: Changes for v5.12-rc1 Adds support for newer firmware image versions of the Video Image Composer (VIC) and adds a comment clarifying the use of the STREAMID registers. Fixes a couple of issues with display and gr2d on older Tegra SoCs such as Tegra114, as well as a runtime PM reference leak. Signed-off-by:
-
- 01 Feb, 2021 1 commit
-
-
git://github.com/skeggsb/linuxDave Airlie authored
Nothing too major here, I actually thought I'd sent most of these right before the new year, but that apparently got lost in the bustle: - Turing MMU fault recovery fixes - Fix mDP connectors being reported as eDP to userspace - Fixes for audio locking, and other bit-rot from DRM changes since atomic support was written - Misc other minor fixes. Signed-off-by:
-
- 29 Jan, 2021 29 commits
-
-
Imre Deak authored
Atm, the driver programs explicitly the default transparent link training mode (0x55) to DP_PHY_REPEATER_MODE even if no LTTPRs are detected. This conforms to the spec (3.6.6.1): "DP upstream devices that do not enable the Non-transparent mode of LTTPRs shall program the PHY_REPEATER_MODE register (DPCD Address F0003h) to 55h (default) prior to link training" however writing the default value to this DPCD register seems to cause occasional link training errors at least for a DELL WD19TB TBT dock, when no LTTPRs are detected. Writing to DP_PHY_REPEATER_MODE will also cause an unnecessary timeout on systems without any LTTPR. To fix the above two issues let's assume that setting the default mode is redundant when no LTTPRs are detected. Keep the existing behavior and program the default mode if more than 8 LTTPRs are detected or in case the read from DP_PHY_REPEATER_CNT returns an invalid value. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2801Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210118183143.1145707-1-imre.deak@intel.com
-
Ville Syrjälä authored
Add support for async flips on vlv/chv. Unlike all the other platforms vlv/chv do not use the async flip bit in DSPCNTR and instead we select between async vs. sync flips based on the surface address register. The normal DSPSURF generates sync flips DSPADDR_VLV generates async flips. And as usual the interrupt bits are different from the other platforms. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-12-ville.syrjala@linux.intel.comReviewed-by:
Karthik B S <karthik.b.s@intel.com>
-
Ville Syrjälä authored
Add support for async flips on ivb/hsw. Again no need for any workarounds and just have to deal with the interrupt bits being shuffled around a bit. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add support for async flips on ivb/hsw. Unlike bdw+ we don't need any workarounds to disable async flips. Apart from that the only real difference from the bdw implementation is the location of the flip_done interrupt bits. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Implement async flip support for BDW. The implementation is similar to the skl+ code. And just like skl/bxt/glk bdw also needs the disable w/a, thus we need to plumb the desired state of the async flip all the way down to i9xx_plane_ctl_crtc(). According to the spec we do need to bump the surface alignment to 256KiB for this. Async flips require an X-tiled buffer so we don't have to worry about linear. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Limit pre-skl plane stride to below 4k or 8k pixels (depending on the platform). We do this in order guarantee that TILEOFF/OFFSET.x does not get too big. Currently this is not a problem as we align SURF to 4k, and so TILEOFF/OFFSET only have to deal with a single tile's worth of pixels. But for async flips we're going to have to bump SURF alignment to 256k, and thus we can no longer guarantee TILEOFF/OFFSET.x will stay within acceptable bounds. We can avoid this by borrowing a trick from the skl+ code and limit the max plane stride to whatever value we can fit into TILEOFF/OFFSET.x. The slight downside is that we may end up doing GTT remapping in a few more cases where previously we did not have to. But since that will only happen with huge buffers I'm not really concerned about it. Signed-off-by:
-
José Roberto de Souza authored
As it now it is always required for GEN12+ the is_16gb_dimm name do not make sense for GEN12+. v2: - Updated comment on top of "dram_info->wm_lv_0_adjust_needed = !IS_GEN9_LP(i915);" Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128164312.91160-3-jose.souza@intel.com
-
José Roberto de Souza authored
Up to now we were reading some DRAM information from MCHBAR register and from pcode what is already not good but some GEN12(TGL-H and ADL-S) platforms have MCHBAR DRAM information in different offsets. This was notified to HW team that decided that the best alternative is always apply the 16gb_dimm watermark adjustment for GEN12+ platforms and read the remaning DRAM information needed to other display programming from pcode. So here moving the DRAM pcode function to intel_dram.c, removing the duplicated fields from intel_qgv_info, setting and using information from dram_info. v2: - bring back num_points to intel_qgv_info as num_qgv_point can be overwritten in icl_get_qgv_points() - add gen12_get_dram_info() and simplify gen11_get_dram_info() Reviewed-by:
-
José Roberto de Souza authored
Valid, ranks and bandwidth_kbps are set into dram_info but are not used anywhere else so nuking it. Reviewed-by:
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
- HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (Anshuman) - Fix DP vswing settings and handling (Imre, Ville) - Various display code clean-up (Jani, Ville) - Various display refactoring, including split out of pps, aux, and fdi (Ja\ ni, Dave) - Add DG1 missing workarounds (Jose) - Fix display color conversion (Chris, Ville) - Try to guess PCH type even without ISA bridge (Zhenyu) - More backlight refactor (Lyude) - Support two CSC module on gen11 and later (Lee) - Async flips for all ilk+ platforms (Ville) - Clear color support for TGL (RK) - Add a helper to read data from a GEM object page (Imre) - VRR/Adaptive Sync Enabling on DP/eDP for TGL+ (Manasi, Ville Aditya) Signed-off-by:
-
Karol Herbst authored
In some cases we have the handle those explicitly as the fallback connector type detection fails and marks those as eDP connectors. Attempting to use such a connector with mutter leads to a crash of mutter as it ends up with two eDP displays. Information is taken from the official DCB documentation. Cc: stable@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Reported-by:
Mark Pearson <markpearson@lenovo.com> Tested-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Frantisek Hrbata authored
Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC ioctl. This was reported by trinity[1] fuzzer. [ 71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17 [ 71.081730] BUG: kernel NULL pointer dereference, address: 00000000000000a0 [ 71.088928] #PF: supervisor read access in kernel mode [ 71.094059] #PF: error_code(0x0000) - not-present page [ 71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0 [ 71.104842] Oops: 0000 [#1] SMP NOPTI [ 71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2 [ 71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014 [ 71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 [nouveau] [ 71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41 [ 71.147074] RSP: 0018:ffffb4a1809cfd38 EFLAGS: 00010246 [ 71.152526] RAX: 0000000000000000 RBX: ffff98cedbaa1d20 RCX: 00000000000003bf [ 71.159651] RDX: 00000000000003be RSI: 0000000000000000 RDI: 0000000000030160 [ 71.166774] RBP: ffff98cee776de00 R08: ffffdc0144198a08 R09: ffff98ceeefd4000 [ 71.173901] R10: ffff98cee7e81780 R11: 0000000000000001 R12: ffffb4a1809cfe08 [ 71.181214] R13: ffff98cee776d000 R14: ffff98cec519e000 R15: ffff98cee776def0 [ 71.188339] FS: 00007fd926250500(0000) GS:ffff98ceeac80000(0000) knlGS:0000000000000000 [ 71.196418] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 71.202155] CR2: 00000000000000a0 CR3: 0000000106622000 CR4: 00000000000406e0 [ 71.209297] Call Trace: [ 71.211777] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] [ 71.218053] drm_ioctl_kernel+0xac/0xf0 [drm] [ 71.222421] drm_ioctl+0x211/0x3c0 [drm] [ 71.226379] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] [ 71.232500] nouveau_drm_ioctl+0x57/0xb0 [nouveau] [ 71.237285] ksys_ioctl+0x86/0xc0 [ 71.240595] __x64_sys_ioctl+0x16/0x20 [ 71.244340] do_syscall_64+0x4c/0x90 [ 71.248110] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 71.253162] RIP: 0033:0x7fd925d4b88b [ 71.256731] Code: Bad RIP value. [ 71.259955] RSP: 002b:00007ffc743592d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [ 71.267514] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd925d4b88b [ 71.274637] RDX: 0000000000601080 RSI: 00000000c0586442 RDI: 0000000000000003 [ 71.281986] RBP: 00007ffc74359340 R08: 00007fd926016ce0 R09: 00007fd926016ce0 [ 71.289111] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000400620 [ 71.296235] R13: 00007ffc74359420 R14: 0000000000000000 R15: 0000000000000000 [ 71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log dm_mod [ 71.365269] CR2: 00000000000000a0 simplified reproducer ---------------------------------8<---------------------------------------- /* * gcc -o crashme crashme.c * ./crashme /dev/dri/renderD128 */ struct drm_nouveau_channel_alloc { uint32_t fb_ctxdma_handle; uint32_t tt_ctxdma_handle; int channel; uint32_t pushbuf_domains; /* Notifier memory */ uint32_t notifier_handle; /* DRM-enforced subchannel assignments */ struct { uint32_t handle; uint32_t grclass; } subchan[8]; uint32_t nr_subchan; }; static struct drm_nouveau_channel_alloc channel; int main(int argc, char *argv[]) { int fd; int rv; if (argc != 2) die("usage: %s <dev>", 0, argv[0]); if ((fd = open(argv[1], O_RDONLY)) == -1) die("open %s", errno, argv[1]); if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, &channel) == -1 && errno == EACCES) die("ioctl %s", errno, argv[1]); close(fd); printf("PASS\n"); return 0; } ---------------------------------8<---------------------------------------- [1] https://github.com/kernelslacker/trinity Fixes: eeaf06ac ("drm/nouveau/svm: initial support for shared virtual memory") Signed-off-by:Frantisek Hrbata <frantisek@hrbata.com> Reviewed-by:
-
Lyude Paul authored
Noticed that I wasn't paying close enough attention the last time I looked at our audio callbacks, as I completely missed the fact that we were figuring out which audio-enabled connector goes to each encoder by checking it's state, but without grabbing any of the appropriate modesetting locks to do so. That being said however: trying to grab modesetting locks in our audio callbacks would be very painful due to the potential for locking inversion between HDA and DRM. So, let's instead just copy what i915 does again - add our own audio lock to protect audio related state, and store each audio enabled connector in each nouveau_encoder struct so that we don't need to check any atomic states. Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Lyude Paul authored
drm_encoder->crtc is deprecated for atomic drivers, but nouveau_encoder->crtc is safe. Signed-off-by:
-
Lyude Paul authored
Despite being an atomic driver, nouveau has a lot of leftover code that relies on retrieving information regarding the new atomic state from members of drm_encoder and drm_crtc. The first field being used, drm_encoder.crtc, is deprecated for atomic drivers. The second field being used is drm_crtc.state, which is only really sensible to use outside of an atomic modeset. So, add some helpers to lookup the current crtc for a given outp from the atomic state. Then, convert most of the code in dispnv50/disp.c to use said new helper, along with the relevant DRM atomic helpers for retrieving the new encoder/crtc combinations for a new atomic state. Note that we don't get rid of the nouveau_encoder.crtc field entirely for three reasons: - Legacy modesetting for pre-nv50 still uses it - It doesn't cause any locking issues - We need it for the HDA callbacks, as grabbing atomic modesetting locks in those would be a mess. Signed-off-by:
-
Lyude Paul authored
Just to be more consistent with the order of args that DRM helpers like drm_atomic_get_new_crtc_state() use. Signed-off-by:
-
Lyude Paul authored
I have a strange dejavu feeling that I tried to submit a patch for this in the past, but that it was rejected. I can't remember though, but I'm further convinced this patch is the right thing to do anyway. We label the to-be-committed head state in nv50_msto_atomic_enable() as armh. Normally armh implies a state which is currently armed in hardware. nv50_msto_atomic_enable() is called _after_ drm_atomic_swap_state() however, but before the commit tail ends, which means that said state is not actually armed on hardware. As well - take note that this is the same convention followed in all of the other atomic_enable() callbacks. So, let's correct this to asyh. Signed-off-by:
-
Lyude Paul authored
No functional changes, just change the function names to match the callbacks they provide. Signed-off-by:
-
Lyude Paul authored
Noticed these in both the disable (which we'll be getting rid of in a moment) and the atomic disable callbacks: both callback types check whether or not there's actually a CRTC assigned to the given encoder. However, as ->atomic_disable and ->disable will never be called without a CRTC assigned to the given encoder there's no point in this check. So just remove it. Signed-off-by:
-
Alistair Popple authored
Previous hardware allowed a MMU fault to be generated by software to trigger a context switch for engine recovery. Turing has the capability to preempt all work from a specific runlist processor and removed the registers currently used for triggering MMU faults. Attempting to access these non-existent registers results in further errors, so use the runlist preemption register instead. Signed-off-by:
Alistair Popple <apopple@nvidia.com> Signed-off-by:
-
Alistair Popple authored
Some of the low level FIFO interrupt status bits have changed for Turing. Update the handling of these to match the hardware. Signed-off-by:
-
Alistair Popple authored
Turing requires some changes to FIFO interrupt handling due to changes in HW register layout. It also requires some changes to implement robust channel (RC) recovery. This preparatory patch moves the functions requiring changes into nvkm/engine/fifo/tu102.c so they can be altered without affecting gk104 and other users. It should not introduce any functional changes. Signed-off-by:
-
Alistair Popple authored
This is no longer needed now that tu102_mc_intr_stat has been updated to look at the correct top-level interrupt bits. Signed-off-by:
-
Alistair Popple authored
Turing reports MMU fault interrupts via new top level interrupt registers. The old PMC MMU interrupt vector is not used by the HW. This means we can remap the new top-level MMU interrupt to the exisiting PMC MMU bit which simplifies the implementation until all interrupts are moved over to using the new top level registers. Signed-off-by:
-
Lyude Paul authored
Since I'm almost certain I didn't get capability checking right for pre-volta chipsets, let's start logging any caps we find to make things like this obvious in the future. Signed-off-by:
-
Lyude Paul authored
This was a mistake that was present before, but never got noticed until we converted over to using nvidia's class headers for display programming. Luckily though it never caused any problems, since we always end up calling crc907d_set_src() after head907d_mode(). So, let's get rid of this. Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
- 28 Jan, 2021 3 commits
-
-
Imre Deak authored
Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit) value for MST streams if the link parameters (link rate or lane count) are limited in a way independent of the sink capabilities (reported by DPCD). One example of such a limitation is when a MUX between the sink and source connects only a limited number of lanes to the display and connects the rest of the lanes to other peripherals (USB). Another issue is that atm MST core calculates the divider based on the backwards compatible DPCD (at address 0x0000) vs. the extended capability info (at address 0x2200). This can result in leaving some part of the MST BW unused (For instance in case of the WD19TB dock). Fix the above two issues by calculating the PBN divider value based on the rate and lane count link parameters that the driver uses for all other computation. Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977 Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Ville Syrjala <ville.syrjala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com
-
Imre Deak authored
This function will be needed by the next patch where the driver calculates the BW based on driver specific parameters, so export it. At the same time sanitize the function params, passing the more natural link rate instead of the encoding of the same rate. v2: - Fix function documentation. (Lyude) Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: <stable@vger.kernel.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Sean Paul authored
The HDCP 1.4 spec does not require the QUERY_STREAM_ENCRYPTION_STATUS check, it was always a nice-to-have. After deploying this across various devices, we've determined that some MST bridge chips do not properly support this call for HDCP 1.4 (namely Synaptics and Realtek). I had considered creating a quirk for this, but I think it's more prudent to just disable the check entirely since I don't have an idea how widespread support is. Changes in v2: -Rebased on -tip Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
- 27 Jan, 2021 3 commits
-
-
Andres Calderon Jaramillo authored
Prevent the ICL HDR plane pipeline from performing YUV color range correction twice when the input is in limited range. This is done by removing the limited-range code from icl_program_input_csc(). Before this patch the following could happen: user space gives us a YUV buffer in limited range; per the pipeline in [1], the plane would first go through a "YUV Range correct" stage that expands the range; the plane would then go through the "Input CSC" stage which would also expand the range because icl_program_input_csc() would use a matrix and an offset that assume limited-range input; this would ultimately cause dark and light colors to appear darker and lighter than they should respectively. This is an issue because if a buffer switches between being scanned out and being composited with the GPU, the user will see a color difference. If this switching happens quickly and frequently, the user will perceive this as a flickering. [1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281 Cc: stable@vger.kernel.org Signed-off-by:
Andres Calderon Jaramillo <andrescj@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Inform us if we're buggy and are about to exceed the size of the bitfields in the plane TILEOFF/OFFSET registers. Signed-off-by:
-
Manasi Navare authored
DSI transcoder does not support VRR and hence skip the HW state readout if its a DSI transcoder. Fixes: c7f0f437 ("drm/i915/display: Add HW state readout for VRR") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
- 26 Jan, 2021 2 commits
-
-
Ville Syrjälä authored
Readout the dbuf related stuff during driver init/resume and stick it into our dbuf state. v2: Keep crtc_state->wm.skl.ddb Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
In order to make the dbuf state computation less fragile let's make it stand on its own feet by not requiring someone to peek into a crystall ball ahead of time to figure out which pipes need to be added to the state under which potential future conditions. Instead we compute each piece of the state as we go along, and if any fallout occurs that affects more than the current set of pipes we add the affected pipes to the state naturally. That requires that we track a few extra thigns in the global dbuf state: dbuf slices for each pipe, and the weight each pipe has when distributing the same set of slice(s) between multiple pipes. Easy enough. We do need to follow a somewhat careful sequence of computations though as there are several steps involved in cooking up the dbuf state. Thoguh we could avoid some of that by computing more things on demand instead of relying on earlier step of the algorithm to have filled it out. I think the end result is still reasonable as the entire sequence is pretty much consolidated into a single function instead of being spread around all over. The rough sequence is this: 1. calculate active_pipes 2. calculate dbuf slices for every pipe 3. calculate total enabled slices 4. calculate new dbuf weights for any crtc in the state 5. calculate new ddb entry for every pipe based on the sets of slices and weights, and add any affected crtc to the state 6. calculate new plane ddb entries for all crtcs in the state, and add any affected plane to the state so that we'll perform the requisite hw reprogramming And as a nice bonus we get to throw dev_priv->wm.distrust_bios_wm out the window. v2: Keep crtc_state->wm.skl.ddb Reviewed-by:
-
