- 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:
Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7yLfhuVbYa-4g0vxVt93OaC7Sodiz2R-TDHu-MoofEdw@mail.gmail.com
-
- 29 Jan, 2021 20 commits
-
-
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:
-
- 27 Jan, 2021 1 commit
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210126185224.32340-1-manasi.d.navare@intel.com
-
- 26 Jan, 2021 8 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:
-
Ville Syrjälä authored
Extract the code to calculate the weights used to chunk up the dbuf between pipes. There's still extra stuff in there that shouldn't be there and must be moved out, but that requires a bit more state to be tracked in the dbuf state. v2: Keep crtc_state->wm.skl.ddb Reviewed-by:
-
Ville Syrjälä authored
The dbuf state will be where we collect all the inter-pipe dbuf allocation stuff. Start by adding the actual per-pipe ddb entries there. Originally the plan was to move them there outright, but that no longer works as we're no longer guaranteed to have a dbuf state when it comes time to sanity check the ddb overlaps in skl_commit_modeset_enables(). I think when I wrote this originally we did the watermark/ddb calculation last, and so we couldn't have any crtcs in the state w/o also having the dbuf state. But that has since changed and we do the watermark/ddb calculation much earlier, and thus it is now possible to commit crtcs w/o a dbuf state. So we keep another copy of the information in the crtc state. v2: Rebase v3: Duplicate the entries instead of moving Reviewed-by:
-
Ville Syrjälä authored
Generalize icl_get_first_dbuf_slice_offset() into something that just gives us the start+end of the dbuf chunk covered by the specified slices as a standard ddb entry. Initial idea was to use it during readout as well, but we shall see. Reviewed-by:
-
Ville Syrjälä authored
Put the code into a function with a descriptive name. Also relocate the code a bit help future work. Reviewed-by:
-
Ville Syrjälä authored
skl_compute_dbuf_slices() has no use for the crtc state, so just pass the crtc itself. Reviewed-by:
-
Ville Syrjälä authored
skl_ddb_get_pipe_allocation_limits() doesn't care how the weights for distributing the ddb are caclculated for each pipe. Put that calculation into a separate function so that such mundane details are hidden from view. v2: s/adjusted_mode/pipe_mode/ Reviewed-by:
-
- 25 Jan, 2021 10 commits
-
-
Ville Syrjälä authored
With vrr enabled the hardware no longer latches the registers automagically at vblank start. The point at which it will do the latching even when no push has been sent is the vmax decision boundary. That is the thing we need to evade to avoid our register latching to get split between two frames. Signed-off-by:
-
Ville Syrjälä authored
To get sensible vblank timestamping behaviour we need to feed the vmax based timings to the vblank code, otherwise it'll chop off the scanline counter when it exceeds the minumum vtotal. Additionally with VRR we have three cases to consider when we generate the vblank timestamp: 1) we are in vertical active -> nothing special needs to be done, just return the current scanout position and the core will calculate the timestamp corresponding to the past time when the current vertical active started 2) we are in vertical blank and no push has been sent -> the hardware will keep extending the vblank presumably to its maximum length, so we make the timestmap match the expected time when the max length vblank will end. Since the timings used for this are now based on vmax nothing special actually needs to be done 3) we are in vblank and a push has been sent so the vblank is about to terminate -> presumably we want the timestmap to accurately reflect when the vblank will terminate, so we use the sampled frame timestamp vs. current timestamp to guesstimate how far along the vblank exit we are, and then we adjust the reported scanout position accordingly so that the core will see that the vblank is close to ending. v2: * Fix the else if (use_scanline_Counter) (Manasi) Signed-off-by: -
Ville Syrjälä authored
Dump vrr state alongside everything else. Signed-off-by:
-
Ville Syrjälä authored
With VRR the earliest the registers can get latched are at flipline decision boundary, calculate that as vrr_vmin_vblank_start() and the latest the regsiters can get latched are vmax decision boundary calculate that as vrr_vmax_vblank_start() v2: * Remove TODO and adjust extra scanline const (Manasi) Signed-off-by:
-
Manasi Navare authored
This functions gets the VRR config from the VRR registers to match the crtc state variables for VRR. v2: * Rebase (Manasi) * Use HAS_VRR (Jani N) v3: * Get pipeline_full, flipline (Ville) Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Manasi Navare authored
If VRR is enabled, the sink should ignore MSA parameters and regenerate incoming video stream without depending on these parameters. Hence set the MSA_TIMING_PAR_IGNORE_EN bit if VRR is enabled. Reset this bit on VRR disable. v2: * ACtually set the dpcd msa ignore bit (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Manasi Navare authored
This patch disables the VRR enable and VRR PUSH bits in the HW during commit modeset disable sequence. Thsi disable will happen when the port is disabled or when the userspace sets VRR prop to false and requests to disable VRR. v2: * Use intel_de_rmw (Jani N) v3: * Remove rmw (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Manasi Navare authored
VRR achieves vblank stretching using the HW PUSH functionality. So once the VRR is enabled during modeset then for each flip request from userspace, in the atomic tail pipe_update_end() we need to set the VRR push bit in HW for it to terminate the vblank at configured flipline or anytime after flipline or latest at the Vmax. The HW clears the PUSH bit after the double buffer updates are completed. v2: * Move send push to after irq en (Manasi) * Call send push unconditionally (Jani N) v3: * Stall w.r.t Vrr vmax (Manasi, Gary Smith) v4: * Remove the rmw (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gary Smith <gary.k.smith@intel.com> Signed-off-by:
-
Manasi Navare authored
This patch computes the VRR parameters from VRR crtc states and configures them in VRR registers during CRTC enable in the modeset enable sequence. v2: * Remove initialization to 0 (Jani N) * Use correct pipe %c (Jani N) v3: * Remove debug prints (Ville) * Use cpu_trans instead of pipe for TRANS_VRR regs (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Give the pipeline full line count bits more descriptive names Signed-off-by:
-
