<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu/drm/tegra/drm.c, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-02-26T14:23:00Z</updated>
<entry>
<title>Merge drm/drm-fixes into drm-misc-fixes</title>
<updated>2024-02-26T14:23:00Z</updated>
<author>
<name>Maxime Ripard</name>
<email>mripard@kernel.org</email>
</author>
<published>2024-02-26T14:23:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2f910859724b53f1cd3579246e3d9bebb16d78b8'/>
<id>urn:sha1:2f910859724b53f1cd3579246e3d9bebb16d78b8</id>
<content type='text'>
Sima needs a more recent release to apply a patch.

Signed-off-by: Maxime Ripard &lt;mripard@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/tegra: Remove existing framebuffer only if we support display</title>
<updated>2024-02-26T12:23:46Z</updated>
<author>
<name>Thierry Reding</name>
<email>treding@nvidia.com</email>
</author>
<published>2024-02-23T15:03:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=86bf8cfda6d2a6720fa2e6e676c98f0882c9d3d7'/>
<id>urn:sha1:86bf8cfda6d2a6720fa2e6e676c98f0882c9d3d7</id>
<content type='text'>
Tegra DRM doesn't support display on Tegra234 and later, so make sure
not to remove any existing framebuffers in that case.

v2: - add comments explaining how this situation can come about
    - clear DRIVER_MODESET and DRIVER_ATOMIC feature bits

Fixes: 6848c291a54f ("drm/aperture: Convert drivers to aperture interfaces")
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Reviewed-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Robert Foss &lt;rfoss@kernel.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240223150333.1401582-1-thierry.reding@gmail.com
</content>
</entry>
<entry>
<title>drm/tegra: Do not assume that a NULL domain means no DMA IOMMU</title>
<updated>2024-02-01T12:17:21Z</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgg@nvidia.com</email>
</author>
<published>2024-01-30T16:14:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fae6e669cdc52fdbb843e7fb1b8419642b6b8cba'/>
<id>urn:sha1:fae6e669cdc52fdbb843e7fb1b8419642b6b8cba</id>
<content type='text'>
Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain
could have been left as NULL. The NULL domain is specially recognized by
host1x_client_iommu_attach() as meaning it is not the DMA domain and
should be replaced with the special shared domain.

This happened prior to the below commit because tegra-smmu was using the
NULL domain to mean IDENTITY.

Now that the domain is properly labled the test in DRM doesn't see NULL.
Check for IDENTITY as well to enable the special domains.

Fixes: c8cc2655cc6c ("iommu/tegra-smmu: Implement an IDENTITY domain")
Reported-by: diogo.ivo@tecnico.ulisboa.pt
Closes: https://lore.kernel.org/all/bbmhcoghrprmbdibnjum6lefix2eoquxrde7wyqeulm4xabmlm@b6jy32saugqh/
Tested-by: diogo.ivo@tecnico.ulisboa.pt
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Link: https://lore.kernel.org/r/0-v1-3049f92c4812+16691-host1x_def_dom_fix_jgg@nvidia.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
</content>
</entry>
<entry>
<title>drm: Clear fd/handle callbacks in struct drm_driver</title>
<updated>2023-06-26T09:08:41Z</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2023-06-20T07:59:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=71e801b9b44f86ce8c816b06960c705f901c50e5'/>
<id>urn:sha1:71e801b9b44f86ce8c816b06960c705f901c50e5</id>
<content type='text'>
Clear all assignments of struct drm_driver's fd/handle callbacks to
drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). These
functions are called by default. Add a TODO item to convert vmwgfx
to the defaults as well.

v2:
	* remove TODO item (Zack)
	* also update amdgpu's amdgpu_partition_driver

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Simon Ser &lt;contact@emersion.fr&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Acked-by: Jeffrey Hugo &lt;quic_jhugo@quicinc.com&gt; # qaic
Link: https://patchwork.freedesktop.org/patch/msgid/20230620080252.16368-3-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>Merge drm/drm-next into drm-misc-next</title>
<updated>2023-04-16T18:11:53Z</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2023-04-16T16:50:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7f6f26d7adee150e09d7537acc6d6894c27c0b7a'/>
<id>urn:sha1:7f6f26d7adee150e09d7537acc6d6894c27c0b7a</id>
<content type='text'>
Backmerging drm-next to sync with msm tree. Resolves a conflict
between aperture-helper changes and msm's use of those interfaces.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/aperture: Remove primary argument</title>
<updated>2023-04-16T12:17:41Z</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2023-04-06T13:21:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=62aeaeaa1b267c5149abee6b45967a5df3feed58'/>
<id>urn:sha1:62aeaeaa1b267c5149abee6b45967a5df3feed58</id>
<content type='text'>
Only really pci devices have a business setting this - it's for
figuring out whether the legacy vga stuff should be nuked too. And
with the preceding two patches those are all using the pci version of
this.

Which means for all other callers primary == false and we can remove
it now.

v2:
- Reorder to avoid compile fail (Thomas)
- Include gma500, which retained it's called to the non-pci version.

v4:
- fix Daniel's S-o-b address

v5:
- add back an S-o-b tag with Daniel's Intel address

Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Cc: Maxime Ripard &lt;mripard@kernel.org&gt;
Cc: Deepak Rawat &lt;drawat.floss@gmail.com&gt;
Cc: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Cc: Kevin Hilman &lt;khilman@baylibre.com&gt;
Cc: Jerome Brunet &lt;jbrunet@baylibre.com&gt;
Cc: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Cc: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Cc: Jonathan Hunter &lt;jonathanh@nvidia.com&gt;
Cc: Emma Anholt &lt;emma@anholt.net&gt;
Cc: Helge Deller &lt;deller@gmx.de&gt;
Cc: David Airlie &lt;airlied@gmail.com&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Cc: linux-hyperv@vger.kernel.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-tegra@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Acked-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230406132109.32050-4-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>drm/tegra: Implement fbdev emulation as in-kernel client</title>
<updated>2023-04-06T10:18:56Z</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2023-03-30T08:36:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=71ec16f45ef8d10e20c58e85f7d3644e324d3c13'/>
<id>urn:sha1:71ec16f45ef8d10e20c58e85f7d3644e324d3c13</id>
<content type='text'>
Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old callbacks. The functions instruct the client
to poll for changed output or restore the display. The DRM core
calls both, the old callbacks and the new client helpers, from
the same places. The new functions perform the same operation as
before, so there's no change in functionality.

Replace all code that initializes or releases fbdev emulation
throughout the driver. Instead initialize the fbdev client by a
single call to tegra_fbdev_setup() after tegra has registered
its DRM device. As in most drivers, tegra's fbdev emulation now
acts like a regular DRM client.

The fbdev client setup consists of the initial preparation and the
hot-plugging of the display. The latter creates the fbdev device
and sets up the fbdev framebuffer. The setup performs display
hot-plugging once. If no display can be detected, DRM probe helpers
re-run the detection on each hotplug event.

A call to drm_dev_unregister() releases the client automatically.
No further action is required within tegra. If the fbdev
framebuffer has been fully set up, struct fb_ops.fb_destroy
implements the release. For partially initialized emulation, the
fbdev client reverts the initial setup.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
</content>
</entry>
<entry>
<title>iommu: Add a gfp parameter to iommu_map()</title>
<updated>2023-01-25T10:52:00Z</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgg@nvidia.com</email>
</author>
<published>2023-01-23T20:35:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1369459b2e219a6f4c861404c4f195cd81dcbb40'/>
<id>urn:sha1:1369459b2e219a6f4c861404c4f195cd81dcbb40</id>
<content type='text'>
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()

Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.

Reviewed-by: Kevin Tian &lt;kevin.tian@intel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Reviewed-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Link: https://lore.kernel.org/r/1-v3-76b587fe28df+6e3-iommu_map_gfp_jgg@nvidia.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/tegra: Add Tegra234 support to NVDEC driver</title>
<updated>2022-11-25T15:14:58Z</updated>
<author>
<name>Mikko Perttunen</name>
<email>mperttunen@nvidia.com</email>
</author>
<published>2022-09-20T08:12:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fbc82b9b2400e1ce88dc73471c6d5aaf6053677a'/>
<id>urn:sha1:fbc82b9b2400e1ce88dc73471c6d5aaf6053677a</id>
<content type='text'>
Add support for the Tegra234 version of NVDEC to the NVDEC driver.
This version sports a RISC-V controller and requires a few additional
clocks. After firmware has been loaded, the behavior is, however,
backwards compatible.

Signed-off-by: Mikko Perttunen &lt;mperttunen@nvidia.com&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: host1x: Avoid trying to use GART on Tegra20</title>
<updated>2022-11-18T08:33:20Z</updated>
<author>
<name>Robin Murphy</name>
<email>robin.murphy@arm.com</email>
</author>
<published>2022-10-20T14:23:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c2418f911a31a266af4fbaca998dc73d3676475a'/>
<id>urn:sha1:c2418f911a31a266af4fbaca998dc73d3676475a</id>
<content type='text'>
Since commit c7e3ca515e78 ("iommu/tegra: gart: Do not register with
bus") quite some time ago, the GART driver has effectively disabled
itself to avoid issues with the GPU driver expecting it to work in ways
that it doesn't. As of commit 57365a04c921 ("iommu: Move bus setup to
IOMMU device registration") that bodge no longer works, but really the
GPU driver should be responsible for its own behaviour anyway. Make the
workaround explicit.

Reported-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Suggested-by: Dmitry Osipenko &lt;digetx@gmail.com&gt;
Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
</content>
</entry>
</feed>
