1. 16 Jul, 2020 16 commits
    • Paul Cercueil's avatar
      drm/ingenic: Fix incorrect assumption about plane->index · ca43f274
      Paul Cercueil authored
      plane->index is NOT the index of the color plane in a YUV frame.
      Actually, a YUV frame is represented by a single drm_plane, even though
      it contains three Y, U, V planes.
      
      v2-v3: No change
      
      Cc: stable@vger.kernel.org # v5.3
      Fixes: 90b86fcc ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
      Signed-off-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Reviewed-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200716163846.174790-1-paul@crapouillou.net
      ca43f274
    • Lyude Paul's avatar
      drm/nouveau/kms/nvd9-: Fix disabling CRCs alongside OR reprogramming · 2d786508
      Lyude Paul authored
      While I had thought I'd tested this before, it looks like this one issue
      slipped by my original CRC patches. Basically, there seem to be a few
      rules we need to follow when sending CRC commands to the display
      controller:
      
      * CRCs cannot be both disabled and enabled for a single head in the same
        flush
      * If a head with CRC reporting enabled switches from one OR to another,
        there must be a flush before the OR is re-enabled regardless of the
        final state of CRC reporting.
      
      So, split nv50_crc_atomic_prepare_notifier_contexts() into two
      functions:
      * nv_crc_atomic_release_notifier_contexts() - checks whether the CRC
        notifier contexts were released successfully after the first flush
      * nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier
        contexts for use before enabling reporting
      
      Additionally, in order to force a flush when we re-assign ORs with heads
      that have CRCs enabled we split our atomic check function into two:
      
      * nv50_crc_atomic_check_head() - called from our heads' atomic checks,
        determines whether a state needs to set or clear CRC reporting
      * nv50_crc_atomic_check_outp() - called at the end of the atomic check
        after all ORs have been added to the atomic state, and sets
        nv50_atom->flush_disable if needed
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarBen Skeggs <skeggsb@gmail.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200629223635.103804-1-lyude@redhat.com
      2d786508
    • Lyude Paul's avatar
      drm/nouveau/kms/nvd9-: Add CRC support · 12885ecb
      Lyude Paul authored
      This introduces support for CRC readback on gf119+, using the
      documentation generously provided to us by Nvidia:
      
      https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
      
      We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
      through a single set of "outp" sources: outp-active/auto for a CRC of
      the scanout region, outp-complete for a CRC of both the scanout and
      blanking/sync region combined, and outp-inactive for a CRC of only the
      blanking/sync region. For each source, nouveau selects the appropriate
      tap point based on the output path in use. We also expose an "rg"
      source, which allows for capturing CRCs of the scanout raster before
      it's encoded into a video signal in the output path. This tap point is
      referred to as the raster generator.
      
      Note that while there's some other neat features that can be used with
      CRC capture on nvidia hardware, like capturing from two CRC sources
      simultaneously, I couldn't see any usecase for them and did not
      implement them.
      
      Nvidia only allows for accessing CRCs through a shared DMA region that
      we program through the core EVO/NvDisplay channel which is referred to
      as the notifier context. The notifier context is limited to either 255
      (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and
      unfortunately the hardware simply drops CRCs and reports an overflow
      once all available entries in the notifier context are filled.
      
      Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit
      on how many CRCs can be captured, we work around this in nouveau by
      allocating two separate notifier contexts for each head instead of one.
      We schedule a vblank worker ahead of time so that once we start getting
      close to filling up all of the available entries in the notifier
      context, we can swap the currently used notifier context out with
      another pre-prepared notifier context in a manner similar to page
      flipping.
      
      Unfortunately, the hardware only allows us to this by flushing two
      separate updates on the core channel: one to release the current
      notifier context handle, and one to program the next notifier context's
      handle. When the hardware processes the first update, the CRC for the
      current frame is lost. However, the second update can be flushed
      immediately without waiting for the first to complete so that CRC
      generation resumes on the next frame. According to Nvidia's hardware
      engineers, there isn't any cleaner way of flipping notifier contexts
      that would avoid this.
      
      Since using vblank workers to swap out the notifier context will ensure
      we can usually flush both updates to hardware within the timespan of a
      single frame, we can also ensure that there will only be exactly one
      frame lost between the first and second update being executed by the
      hardware. This gives us the guarantee that we're always correctly
      matching each CRC entry with it's respective frame even after a context
      flip. And since IGT will retrieve the CRC entry for a frame by waiting
      until it receives a CRC for any subsequent frames, this doesn't cause an
      issue with any tests and is much simpler than trying to change the
      current DRM API to accommodate.
      
      In order to facilitate testing of correct handling of this limitation,
      we also expose a debugfs interface to manually control the threshold for
      when we start trying to flip the notifier context. We will use this in
      igt to trigger a context flip for testing purposes without needing to
      wait for the notifier to completely fill up. This threshold is reset
      to the default value set by nouveau after each capture, and is exposed
      in a separate folder within each CRTC's debugfs directory labelled
      "nv_crc".
      
      Changes since v1:
      * Forgot to finish saving crc.h before saving, whoops. This just adds
        some corrections to the empty function declarations that we use if
        CONFIG_DEBUG_FS isn't enabled.
      Changes since v2:
      * Don't check return code from debugfs_create_dir() or
        debugfs_create_file() - Greg K-H
      Changes since v3:
        (no functional changes)
      * Fix SPDX license identifiers (checkpatch)
      * s/uint32_t/u32/ (checkpatch)
      * Fix indenting in switch cases (checkpatch)
      Changes since v4:
      * Remove unneeded param changes with nv50_head_flush_clr/set
      * Rebase
      Changes since v5:
      * Remove set but unused variable (outp) in nv50_crc_atomic_check() -
        Kbuild bot
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
      12885ecb
    • Lyude Paul's avatar
      drm/nouveau/kms/nv50-: Move hard-coded object handles into header · 0bc8ffe0
      Lyude Paul authored
      While most of the functionality on Nvidia GPUs doesn't require using an
      explicit handle instead of the main VRAM handle + offset, there are a
      couple of places that do require explicit handles, such as CRC
      functionality. Since this means we're about to add another
      nouveau-chosen handle, let's just go ahead and move any hard-coded
      handles into a single header. This is just to keep things slightly
      organized, and to make it a little bit easier if we need to add more
      handles in the future.
      
      This patch should contain no functional changes.
      
      Changes since v3:
      * Correct SPDX license identifier (checkpatch)
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-9-lyude@redhat.com
      0bc8ffe0
    • Lyude Paul's avatar
      drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h · ebec8847
      Lyude Paul authored
      In order to make sure that we flush disable updates at the right time
      when disabling CRCs, we'll need to be able to look at the outp state to
      see if we're changing it at the same time that we're disabling CRCs.
      
      So, expose the struct in disp.h.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-8-lyude@redhat.com
      ebec8847
    • Lyude Paul's avatar
      drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom · dbdaf719
      Lyude Paul authored
      While we're not quite ready yet to add support for flexible wndw
      mappings, we are going to need to at least keep track of the static wndw
      mappings we're currently using in each head's atomic state. We'll likely
      use this in the future to implement real flexible window mapping, but
      the primary reason we'll need this is for CRC support.
      
      See: on nvidia hardware, each CRC entry in the CRC notifier dma context
      has a "tag". This tag corresponds to the nth update on a specific
      EVO/NvDisplay channel, which itself is referred to as the "controlling
      channel". For gf119+ this can be the core channel, ovly channel, or base
      channel. Since we don't expose CRC entry tags to userspace, we simply
      ignore this feature and always use the core channel as the controlling
      channel. Simple.
      
      Things get a little bit more complicated on gv100+ though. GV100+ only
      lets us set the controlling channel to a specific wndw channel, and that
      wndw must be owned by the head that we're grabbing CRCs when we enable
      CRC generation. Thus, we always need to make sure that each atomic head
      state has at least one wndw that is mapped to the head, which will be
      used as the controlling channel.
      
      Note that since we don't have flexible wndw mappings yet, we don't
      expect to run into any scenarios yet where we'd have a head with no
      mapped wndws. When we do add support for flexible wndw mappings however,
      we'll need to make sure that we handle reprogramming CRC capture if our
      controlling wndw is moved to another head (and potentially reject the
      new head state entirely if we can't find another available wndw to
      replace it).
      
      With that being said, nouveau currently tracks wndw visibility on heads.
      It does not keep track of the actual ownership mappings, which are
      (currently) statically programmed. To fix this, we introduce another
      bitmask into nv50_head_atom.wndw to keep track of ownership separately
      from visibility. We then introduce a nv50_head callback to handle
      populating the wndw ownership map, and call it during the atomic check
      phase when core->assign_windows is set to true.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-7-lyude@redhat.com
      dbdaf719
    • Lyude Paul's avatar
      drm/nouveau/kms/nv50-: Fix disabling dithering · fb2420b7
      Lyude Paul authored
      While we expose the ability to turn off hardware dithering for nouveau,
      we actually make the mistake of turning it on anyway, due to
      dithering_depth containing a non-zero value if our dithering depth isn't
      also set to 6 bpc.
      
      So, fix it by never enabling dithering when it's disabled.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-6-lyude@redhat.com
      fb2420b7
    • Lyude Paul's avatar
      drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit · 9c8e9b79
      Lyude Paul authored
      Currently, we modify the depth value stored in the atomic state when
      performing a commit in order to workaround the fact we haven't
      implemented support for depths higher then 10 yet. This isn't idempotent
      though, as it will happen every atomic commit where we modify the OR
      state even if the head's depth in the atomic state hasn't been modified.
      
      Normally this wouldn't matter, since we don't modify OR state outside of
      modesets, but since the CRC capture region is implemented as part of the
      OR state in hardware we'll want to make sure all commits modifying OR
      state are idempotent so as to avoid changing the depth unexpectedly.
      
      So, fix this by simply not writing the reduced depth value we come up
      with to the atomic state.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-5-lyude@redhat.com
      9c8e9b79
    • Lyude Paul's avatar
      drm/vblank: Add vblank works · 5e6c2b4f
      Lyude Paul authored
      Add some kind of vblank workers. The interface is similar to regular
      delayed works, and is mostly based off kthread_work. It allows for
      scheduling delayed works that execute once a particular vblank sequence
      has passed. It also allows for accurate flushing of scheduled vblank
      works - in that flushing waits for both the vblank sequence and job
      execution to complete, or for the work to get cancelled - whichever
      comes first.
      
      Whatever hardware programming we do in the work must be fast (must at
      least complete during the vblank or scanout period, sometimes during the
      first few scanlines of the vblank). As such we use a high-priority
      per-CRTC thread to accomplish this.
      
      Changes since v7:
      * Stuff drm_vblank_internal.h and drm_vblank_work_internal.h contents
        into drm_internal.h
      * Get rid of unnecessary spinlock in drm_crtc_vblank_on()
      * Remove !vblank->worker check
      * Grab vbl_lock in drm_vblank_work_schedule()
      * Mention self-rearming work items in drm_vblank_work_schedule() kdocs
      * Return 1 from drm_vblank_work_schedule() if the work was scheduled
        successfully, 0 or error code otherwise
      * Use drm_dbg_core() instead of DRM_DEV_ERROR() in
        drm_vblank_work_schedule()
      * Remove vblank->worker checks in drm_vblank_destroy_worker() and
        drm_vblank_flush_worker()
      Changes since v6:
      * Get rid of ->pending and seqcounts, and implement flushing through
        simpler means - danvet
      * Get rid of work_lock, just use drm_device->event_lock
      * Move drm_vblank_work item cleanup into drm_crtc_vblank_off() so that
        we ensure that all vblank work has finished before disabling vblanks
      * Add checks into drm_crtc_vblank_reset() so we yell if it gets called
        while there's vblank workers active
      * Grab event_lock in both drm_crtc_vblank_on()/drm_crtc_vblank_off(),
        the main reason for this is so that other threads calling
        drm_vblank_work_schedule() are blocked from attempting to schedule
        while we're in the middle of enabling/disabling vblanks.
      * Move drm_handle_vblank_works() call below drm_handle_vblank_events()
      * Simplify drm_vblank_work_cancel_sync()
      * Fix drm_vblank_work_cancel_sync() documentation
      * Move wake_up_all() calls out of spinlock where we can. The only one I
        left was the call to wake_up_all() in drm_vblank_handle_works() as
        this seemed like it made more sense just living in that function
        (which is all technically under lock)
      * Move drm_vblank_work related functions into their own source files
      * Add drm_vblank_internal.h so we can export some functions we don't
        want drivers using, but that we do need to use in drm_vblank_work.c
      * Add a bunch of documentation
      Changes since v4:
      * Get rid of kthread interfaces we tried adding and move all of the
        locking into drm_vblank.c. For implementing drm_vblank_work_flush(),
        we now use a wait_queue and sequence counters in order to
        differentiate between multiple work item executions.
      * Get rid of drm_vblank_work_cancel() - this would have been pretty
        difficult to actually reimplement and it occurred to me that neither
        nouveau or i915 are even planning to use this function. Since there's
        also no async cancel function for most of the work interfaces in the
        kernel, it seems a bit unnecessary anyway.
      * Get rid of to_drm_vblank_work() since we now are also able to just
        pass the struct drm_vblank_work to work item callbacks anyway
      Changes since v3:
      * Use our own spinlocks, don't integrate so tightly with kthread_works
      Changes since v2:
      * Use kthread_workers instead of reinventing the wheel.
      
      Cc: Tejun Heo <tj@kernel.org>
      Cc: dri-devel@lists.freedesktop.org
      Cc: nouveau@lists.freedesktop.org
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Co-developed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-4-lyude@redhat.com
      5e6c2b4f
    • Lyude Paul's avatar
      drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_off() · a7e3ad5f
      Lyude Paul authored
      This got me confused for a bit while looking over this code: I had been
      planning on adding some blocking function calls into this function, but
      seeing the irqsave/irqrestore variants of spin_(un)lock() didn't make it
      very clear whether or not that would actually be safe.
      
      So I went ahead and reviewed every single driver in the kernel that uses
      this function, and they all fall into three categories:
      
      * Driver probe code
      * ->atomic_disable() callbacks
      * Legacy modesetting callbacks
      
      All of these will be guaranteed to have IRQs enabled, which means it's
      perfectly safe to block here. Just to make things a little less
      confusing to others in the future, let's switch over to
      spin_lock_irq()/spin_unlock_irq() to make that fact a little more
      obvious.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-3-lyude@redhat.com
      a7e3ad5f
    • Lyude Paul's avatar
      drm/vblank: Register drmm cleanup action once per drm_vblank_crtc · a7e5e06d
      Lyude Paul authored
      Since we'll be allocating resources for kthread_create_worker() in the
      next commit (which could fail and require us to clean up the mess),
      let's simplify the cleanup process a bit by registering a
      drm_vblank_init_release() action for each drm_vblank_crtc so they're
      still cleaned up if we fail to initialize one of them.
      
      Changes since v3:
      * Use drmm_add_action_or_reset() - Daniel Vetter
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: nouveau@lists.freedesktop.org
      Reviewed-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-2-lyude@redhat.com
      a7e5e06d
    • Alexander A. Klimov's avatar
      drm/tidss: Replace HTTP links with HTTPS ones · 9410113f
      Alexander A. Klimov authored
      Rationale:
      Reduces attack surface on kernel devs opening the links for MITM
      as HTTPS traffic is much harder to manipulate.
      
      Deterministic algorithm:
      For each file:
        If not .svg:
          For each line:
            If doesn't contain `\bxmlns\b`:
              For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
      	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
                  If both the HTTP and HTTPS versions
                  return 200 OK and serve the same content:
                    Replace HTTP with HTTPS.
      Signed-off-by: default avatarAlexander A. Klimov <grandmaster@al2klimov.de>
      Acked-by: default avatarJyri Sarha <jsarha@ti.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200713123913.34205-1-grandmaster@al2klimov.de
      9410113f
    • Alexander A. Klimov's avatar
      drm/vboxvideo: Replace HTTP links with HTTPS ones · d713b771
      Alexander A. Klimov authored
      Rationale:
      Reduces attack surface on kernel devs opening the links for MITM
      as HTTPS traffic is much harder to manipulate.
      
      Deterministic algorithm:
      For each file:
        If not .svg:
          For each line:
            If doesn't contain `\bxmlns\b`:
              For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
      	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
                  If both the HTTP and HTTPS versions
                  return 200 OK and serve the same content:
                    Replace HTTP with HTTPS.
      Signed-off-by: default avatarAlexander A. Klimov <grandmaster@al2klimov.de>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200713124923.34282-1-grandmaster@al2klimov.de
      d713b771
    • Sebastian Reichel's avatar
    • Paul Cercueil's avatar
      drm/panel-simple: Add 50 Hz mode to the Frida FRD350H54004 panel · 795db2af
      Paul Cercueil authored
      By changing the pixel clock and the length of the back porch, it is
      possible to obtain a perfect 50 Hz refresh rate.
      
      v2: Rebase on drm-misc-next
      Signed-off-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200716125647.10964-2-paul@crapouillou.net
      795db2af
    • Paul Cercueil's avatar
      drm/panel-simple: Fix inverted V/H SYNC for Frida FRD350H54004 panel · bad20a2d
      Paul Cercueil authored
      The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC
      signals, which sorts-of worked, but resulted in the picture fading out
      under certain circumstances.
      
      Fix this issue by marking VSYNC and HSYNC signals active-low.
      
      v2: Rebase on drm-misc-next
      
      Fixes: 7b6bd843 ("drm/panel: simple: Add support for the Frida FRD350H54004 panel")
      Cc: stable@vger.kernel.org # v5.5
      Signed-off-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200716125647.10964-1-paul@crapouillou.net
      bad20a2d
  2. 15 Jul, 2020 7 commits
  3. 14 Jul, 2020 9 commits
  4. 13 Jul, 2020 6 commits
  5. 12 Jul, 2020 2 commits