<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/gpu/drm/nouveau/include, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/gpu/drm/nouveau/include?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/gpu/drm/nouveau/include?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-05-04T18:55:49Z</updated>
<entry>
<title>drm/nouveau/subdev/bus: Ratelimit logging for fault errors</title>
<updated>2022-05-04T18:55:49Z</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2022-04-29T19:53:47Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=9887bda0c831df0c044d6de147d002e48024fb4a'/>
<id>urn:sha1:9887bda0c831df0c044d6de147d002e48024fb4a</id>
<content type='text'>
There's plenty of ways to fudge the GPU when developing on nouveau by
mistake, some of which can result in nouveau seriously spamming dmesg with
fault errors. This can be somewhat annoying, as it can quickly overrun the
message buffer (or your terminal emulator's buffer) and get rid of actually
useful feedback from the driver. While working on my new atomic only MST
branch, I ran into this issue a couple of times.

So, let's fix this by adding nvkm_error_ratelimited(), and using it to
ratelimit errors from faults. This should be fine for developers, since
it's nearly always only the first few faults that we care about seeing.
Plus, you can turn off rate limiting in the kernel if you really need to.

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Reviewed-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20220429195350.85620-1-lyude@redhat.com
</content>
</entry>
<entry>
<title>Merge tag 'drm-next-2022-03-24' of git://anongit.freedesktop.org/drm/drm</title>
<updated>2022-03-24T23:19:43Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-03-24T23:19:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=b14ffae378aa1db993e62b01392e70d1e585fb23'/>
<id>urn:sha1:b14ffae378aa1db993e62b01392e70d1e585fb23</id>
<content type='text'>
Pull drm updates from Dave Airlie:
 "Lots of work all over, Intel improving DG2 support, amdkfd CRIU
  support, msm new hw support, and faster fbdev support.

  dma-buf:
   - rename dma-buf-map to iosys-map

  core:
   - move buddy allocator to core
   - add pci/platform init macros
   - improve EDID parser deep color handling
   - EDID timing type 7 support
   - add GPD Win Max quirk
   - add yes/no helpers to string_helpers
   - flatten syncobj chains
   - add nomodeset support to lots of drivers
   - improve fb-helper clipping support
   - add default property value interface

  fbdev:
   - improve fbdev ops speed

  ttm:
   - add a backpointer from ttm bo-&gt;ttm resource

  dp:
   - move displayport headers
   - add a dp helper module

  bridge:
   - anx7625 atomic support, HDCP support

  panel:
   - split out panel-lvds and lvds bindings
   - find panels in OF subnodes

  privacy:
   - add chromeos privacy screen support

  fb:
   - hot unplug fw fb on forced removal

  simpledrm:
   - request region instead of marking ioresource busy
   - add panel oreintation property

  udmabuf:
   - fix oops with 0 pages

  amdgpu:
   - power management code cleanup
   - Enable freesync video mode by default
   - RAS code cleanup
   - Improve VRAM access for debug using SDMA
   - SR-IOV rework special register access and fixes
   - profiling power state request ioctl
   - expose IP discovery via sysfs
   - Cyan skillfish updates
   - GC 10.3.7, SDMA 5.2.7, DCN 3.1.6 updates
   - expose benchmark tests via debugfs
   - add module param to disable XGMI for testing
   - GPU reset debugfs register dumping support

  amdkfd:
   - CRIU support
   - SDMA queue fixes

  radeon:
   - UVD suspend fix
   - iMac backlight fix

  i915:
   - minimal parallel submission for execlists
   - DG2-G12 subplatform added
   - DG2 programming workarounds
   - DG2 accelerated migration support
   - flat CCS and CCS engine support for XeHP
   - initial small BAR support
   - drop fake LMEM support
   - ADL-N PCH support
   - bigjoiner updates
   - introduce VMA resources and async unbinding
   - register definitions cleanups
   - multi-FBC refactoring
   - DG1 OPROM over SPI support
   - ADL-N platform enabling
   - opregion mailbox #5 support
   - DP MST ESI improvements
   - drm device based logging
   - async flip optimisation for DG2
   - CPU arch abstraction fixes
   - improve GuC ADS init to work on aarch64
   - tweak TTM LRU priority hint
   - GuC 69.0.3 support
   - remove short term execbuf pins

  nouveau:
   - higher DP/eDP bitrates
   - backlight fixes

  msm:
   - dpu + dp support for sc8180x
   - dp support for sm8350
   - dpu + dsi support for qcm2290
   - 10nm dsi phy tuning support
   - bridge support for dp encoder
   - gpu support for additional 7c3 SKUs

  ingenic:
   - HDMI support for JZ4780
   - aux channel EDID support

  ast:
   - AST2600 support
   - add wide screen support
   - create DP/DVI connectors

  omapdrm:
   - fix implicit dma_buf fencing

  vc4:
   - add CSC + full range support
   - better display firmware handoff

  panfrost:
   - add initial dual-core GPU support

  stm:
   - new revision support
   - fb handover support

  mediatek:
   - transfer display binding document to yaml format.
   - add mt8195 display device binding.
   - allow commands to be sent during video mode.
   - add wait_for_event for crtc disable by cmdq.

  tegra:
   - YUV format support

  rcar-du:
   - LVDS support for M3-W+ (R8A77961)

  exynos:
   - BGR pixel format for FIMD device"

* tag 'drm-next-2022-03-24' of git://anongit.freedesktop.org/drm/drm: (1529 commits)
  drm/i915/display: Do not re-enable PSR after it was marked as not reliable
  drm/i915/display: Fix HPD short pulse handling for eDP
  drm/amdgpu: Use drm_mode_copy()
  drm/radeon: Use drm_mode_copy()
  drm/amdgpu: Use ternary operator in `vcn_v1_0_start()`
  drm/amdgpu: Remove pointless on stack mode copies
  drm/amd/pm: fix indenting in __smu_cmn_reg_print_error()
  drm/amdgpu/dc: fix typos in comments
  drm/amdgpu: fix typos in comments
  drm/amd/pm: fix typos in comments
  drm/amdgpu: Add stolen reserved memory for MI25 SRIOV.
  drm/amdgpu: Merge get_reserved_allocation to get_vbios_allocations.
  drm/amdkfd: evict svm bo worker handle error
  drm/amdgpu/vcn: fix vcn ring test failure in igt reload test
  drm/amdgpu: only allow secure submission on rings which support that
  drm/amdgpu: fixed the warnings reported by kernel test robot
  drm/amd/display: 3.2.177
  drm/amd/display: [FW Promotion] Release 0.0.108.0
  drm/amd/display: Add save/restore PANEL_PWRSEQ_REF_DIV2
  drm/amd/display: Wait for hubp read line for Pollock
  ...
</content>
</entry>
<entry>
<title>drm/nouveau: Remove the unused header file nvif/list.h</title>
<updated>2022-02-24T21:06:11Z</updated>
<author>
<name>Cai Huoqing</name>
<email>cai.huoqing@linux.dev</email>
</author>
<published>2022-02-09T06:53:19Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d814833f9e0e1fec2286e7d65c386583139c6a74'/>
<id>urn:sha1:d814833f9e0e1fec2286e7d65c386583139c6a74</id>
<content type='text'>
The nouveau driver depends on include/linux/list.h instead of
nvif/list.h, so remove the obstacle-nvif/list.h.

Signed-off-by: Cai Huoqing &lt;cai.huoqing@linux.dev&gt;
Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220209065322.43938-1-cai.huoqing@linux.dev
</content>
</entry>
<entry>
<title>treewide: Replace zero-length arrays with flexible-array members</title>
<updated>2022-02-17T13:00:39Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavoars@kernel.org</email>
</author>
<published>2022-02-15T01:11:44Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=5224f79096170bf7b92cc8fe42a12f44b91e5f62'/>
<id>urn:sha1:5224f79096170bf7b92cc8fe42a12f44b91e5f62</id>
<content type='text'>
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].

This code was transformed with the help of Coccinelle:
(next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file script.cocci --include-headers --dir . &gt; output.patch)

@@
identifier S, member, array;
type T1, T2;
@@

struct S {
  ...
  T1 member;
  T2 array[
- 0
  ];
};

UAPI and wireless changes were intentionally excluded from this patch
and will be sent out separately.

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays

Link: https://github.com/KSPP/linux/issues/78
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Gustavo A. R. Silva &lt;gustavoars@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge drm/drm-next into drm-misc-next</title>
<updated>2021-11-18T08:36:39Z</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2021-11-18T08:36:39Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a713ca234ea9d946235ac7248995c5fddfd9e523'/>
<id>urn:sha1:a713ca234ea9d946235ac7248995c5fddfd9e523</id>
<content type='text'>
Backmerging from drm/drm-next for v5.16-rc1.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/nouveau/kms/nvd9-nv138: Fix CRC calculation for the cursor channel</title>
<updated>2021-11-12T22:46:03Z</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2021-02-23T23:56:47Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=23244f67ed96c76428bfdfc63eef642e4d627825'/>
<id>urn:sha1:23244f67ed96c76428bfdfc63eef642e4d627825</id>
<content type='text'>
Something that didn't get noticed until I started running cursor tests:
we're accidentally disabling an option for CRC calculation that's enabled
by default: WidePipeCrc, which controls whether we use the full width of
the data in the display pipe in order calculate CRCs. Having this disabled
apparently causes frames with the cursor plane enabled to generate
different CRCs than frames without the cursor plane enabled, even if the
frames are pixel-equivalent.

So, let's make sure to enable this and fix a bunch of cursor related tests
in IGT.

v2:
* Nvidia added the specific bit we were using to fix this issues to
  open-gpu-docs, so pull in the actual macro definitions for it

Cc: Martin Peres &lt;martin.peres@free.fr&gt;
Cc: Jeremy Cline &lt;jcline@redhat.com&gt;
Cc: Simon Ser &lt;contact@emersion.fr&gt;
Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Reviewed-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Signed-off-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
</content>
</entry>
<entry>
<title>drm/nouveau/kms/nv140-: Use hard-coded wndws or core channel for CRC channel</title>
<updated>2021-11-12T22:46:03Z</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2021-01-19T01:48:47Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=57cbdbe65e5f9ba9bfd67b66bc3ce24ef1c54643'/>
<id>urn:sha1:57cbdbe65e5f9ba9bfd67b66bc3ce24ef1c54643</id>
<content type='text'>
Originally it was assumed based on Nvidia's open-gpu-docs and testing that
NVDisplay required that at least one wndw which belongs to a given head to
be used as the controlling channel
(NVC37D_HEAD_SET_CRC_CONTROL_CONTROLLING_CHANNEL) in order for CRC capture
to function. While this is the case on Volta, Turing actually adds the
ability to instead use the core channel as the controlling channel. For
Turing this is quite useful, as it means that we can always default to the
core channel as the controlling channel and we don't need to be concerned
about ensuring we have at least one wndw channel owned by a head with CRC
output enabled. While Volta lacks this ability, Volta conveniently also
lacks flexible wndw mapping - meaning that we can always rely on each head
having four wndw channels mapped to it regardless of the atomic state.

So, simply use the hard-coded wndw mappings we're guaranteed to have on
Volta as the controlling channel, and use the core channel as the
controlling channel for Turing+. As a result this also renders the plane
ownership logic in nv50_crc_atomic_check() unnessecary, which gives us one
less thing to implement when we get support for flexible wndw mapping. We
also can entirely drop the wndw parameter from our set_src callbacks, and
the atomic state.

v2 (Karol): put prackets around complex macro definition
            removed spaces before :32 in structs

Cc: Martin Peres &lt;martin.peres@free.fr&gt;
Cc: Jeremy Cline &lt;jcline@redhat.com&gt;
Cc: Simon Ser &lt;contact@emersion.fr&gt;
Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Reviewed-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Signed-off-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
</content>
</entry>
<entry>
<title>drm/nouveau/ga102-: support ttm buffer moves via copy engine</title>
<updated>2021-10-06T09:05:45Z</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2021-09-16T22:04:06Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=49b2dfc081826874705b27f7970631319628ee7f'/>
<id>urn:sha1:49b2dfc081826874705b27f7970631319628ee7f</id>
<content type='text'>
We don't currently have any kind of real acceleration on Ampere GPUs,
but the TTM memcpy() fallback paths aren't really designed to handle
copies between different devices, such as on Optimus systems, and
result in a kernel OOPS.

A few options were investigated to try and fix this, but didn't work
out, and likely would have resulted in a very unpleasant experience
for users anyway.

This commit adds just enough support for setting up a single channel
connected to a copy engine, which the kernel can use to accelerate
the buffer copies between devices.  Userspace has no access to this
incomplete channel support, but it's suitable for TTM's needs.

A more complete implementation of host(fifo) for Ampere GPUs is in
the works, but the required changes are far too invasive that they
would be unsuitable to backport to fix this issue on current kernels.

v2: fix GPFIFO length in RAMFC (reported by Karol)

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Cc: Lyude Paul &lt;lyude@redhat.com&gt;
Cc: Karol Herbst &lt;kherbst@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.12+
Reviewed-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Tested-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Signed-off-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210916220406.666454-1-skeggsb@gmail.com
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/nouveau: rip out nvkm_client.super</title>
<updated>2021-08-18T09:00:15Z</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2021-03-04T09:53:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=59f216cf04d973b4316761cbf3e7cb9556715b7a'/>
<id>urn:sha1:59f216cf04d973b4316761cbf3e7cb9556715b7a</id>
<content type='text'>
No longer required now that userspace can't touch anything that might
need it, and should fix DRM MM operations racing with each other, and
the random hangs/crashes that come with that.

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Reviewed-by: Lyude Paul &lt;lyude@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/nouveau: block a bunch of classes from userspace</title>
<updated>2021-08-18T09:00:13Z</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2021-03-04T09:16:18Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=148a8653789c01f159764ffcc3f370008966b42f'/>
<id>urn:sha1:148a8653789c01f159764ffcc3f370008966b42f</id>
<content type='text'>
Long ago, there had been plans for making use of a bunch of these APIs
from userspace and there's various checks in place to stop misbehaving.

Countless other projects have occurred in the meantime, and the pieces
didn't finish falling into place for that to happen.

They will (hopefully) in the not-too-distant future, but it won't look
quite as insane.  The super checks are causing problems right now, and
are going to be removed.

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Reviewed-by: Lyude Paul &lt;lyude@redhat.com&gt;
</content>
</entry>
</feed>
