1. 16 Dec, 2021 22 commits
  2. 15 Dec, 2021 1 commit
    • Maxime Ripard's avatar
      drm/vc4: kms: Wait for the commit before increasing our clock rate · 244a36e5
      Maxime Ripard authored
      Several DRM/KMS atomic commits can run in parallel if they affect
      different CRTC. These commits share the global HVS state, so we have
      some code to make sure we run commits in sequence. This synchronization
      code is one of the first thing that runs in vc4_atomic_commit_tail().
      
      Another constraints we have is that we need to make sure the HVS clock
      gets a boost during the commit. That code relies on clk_set_min_rate and
      will remove the old minimum and set a new one. We also need another,
      temporary, minimum for the duration of the commit.
      
      The algorithm is thus to set a temporary minimum, drop the previous
      one, do the commit, and finally set the minimum for the current mode.
      
      However, the part that sets the temporary minimum and drops the older
      one runs before the commit synchronization code.
      
      Thus, under the proper conditions, we can end up mixing up the minimums
      and ending up with the wrong one for our current step.
      
      To avoid it, let's move the clock setup in the protected section.
      
      Fixes: d7d96c00 ("drm/vc4: hvs: Boost the core clock during modeset")
      Signed-off-by: default avatarMaxime Ripard <maxime@cerno.tech>
      Reviewed-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.com>
      Tested-by: default avatarJian-Hong Pan <jhp@endlessos.org>
      [danvet: re-apply this from 0c980a00 ("drm/vc4: kms: Wait for the
      commit before increasing our clock rate") because I lost that part in
      my merge resolution in 99b03ca6 ("Merge v5.16-rc5 into drm-next")]
      Fixes: 99b03ca6 ("Merge v5.16-rc5 into drm-next")
      Acked-by: default avatarMaxime Ripard <maxime@cerno.tech>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: https://lore.kernel.org/r/20211117094527.146275-2-maxime@cerno.tech
      244a36e5
  3. 14 Dec, 2021 2 commits
  4. 12 Dec, 2021 14 commits
  5. 11 Dec, 2021 1 commit
    • Linus Torvalds's avatar
      Merge tag 'perf-tools-fixes-for-v5.16-2021-12-11' of... · bbdff6d5
      Linus Torvalds authored
      Merge tag 'perf-tools-fixes-for-v5.16-2021-12-11' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
      
      Pull perf tools fixes from Arnaldo Carvalho de Melo:
      
       - Prevent out-of-bounds access to per sample registers.
      
       - Fix NULL vs IS_ERR_OR_NULL() checking on the python binding.
      
       - Intel PT fixes, half of those are one-liners:
            - Fix some PGE (packet generation enable/control flow packets) usage.
            - Fix sync state when a PSB (synchronization) packet is found.
            - Fix intel_pt_fup_event() assumptions about setting state type.
            - Fix state setting when receiving overflow (OVF) packet.
            - Fix next 'err' value, walking trace.
            - Fix missing 'instruction' events with 'q' option.
            - Fix error timestamp setting on the decoder error path.
      
      * tag 'perf-tools-fixes-for-v5.16-2021-12-11' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
        perf python: Fix NULL vs IS_ERR_OR_NULL() checking
        perf intel-pt: Fix error timestamp setting on the decoder error path
        perf intel-pt: Fix missing 'instruction' events with 'q' option
        perf intel-pt: Fix next 'err' value, walking trace
        perf intel-pt: Fix state setting when receiving overflow (OVF) packet
        perf intel-pt: Fix intel_pt_fup_event() assumptions about setting state type
        perf intel-pt: Fix sync state when a PSB (synchronization) packet is found
        perf intel-pt: Fix some PGE (packet generation enable/control flow packets) usage
        perf tools: Prevent out-of-bounds access to registers
      bbdff6d5