similar to: [PATCH v3 1/3] device: rework mmio mapping code to get rid of second map

Fixes warnings on GPUs with smaller a smaller mmio region like vGPUs. Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nvkm/engine/device/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/engine/device/base.c b/drm/nouveau/nvkm/engine/device/base.c index 8ebbe1656..17676c75a 100644 --- a/drm/nouveau/nvkm/engine/device/base.c +++

Fixes warnings on GPUs with smaller a smaller mmio region like vGPUs. Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nvkm/engine/device/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/engine/device/base.c b/drm/nouveau/nvkm/engine/device/base.c index 8ebbe1656..17676c75a 100644 --- a/drm/nouveau/nvkm/engine/device/base.c +++

With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") --- .../gpu/drm/nouveau/nvkm/engine/device/base.c | 39 ++++++++++++------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c

Previously the code relied on device->pri to be NULL and to fail probing later. We really should just return an error inside nvkm_device_ctor for unsupported GPUs. Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio mapping code to get rid of second map") Signed-off-by: Karol Herbst <kherbst at redhat.com> Cc: dann frazier <dann.frazier at canonical.com> ---

v2: relax the checks a little Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nvkm/engine/device/base.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/drm/nouveau/nvkm/engine/device/base.c b/drm/nouveau/nvkm/engine/device/base.c index 37589f365..c732074bf 100644 --- a/drm/nouveau/nvkm/engine/device/base.c +++

Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it only gives VGA resolution on screen. Use the same chipset as nv134 then it shows FullHD. This commit copies fields from nv134_chipset to nv136_chipset for GTX 1060. Signed-off-by: Chris Chiu <chiu at endlessm.com> --- drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29 +++++++++++++++++++++++ 1 file changed, 29

On Mon, Oct 05, 2020 at 03:52:30PM +0200, Karol Herbst wrote: > Previously the code relied on device->pri to be NULL and to fail probing > later. We really should just return an error inside nvkm_device_ctor for > unsupported GPUs. > > Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio mapping code to get rid of second map") > Signed-off-by: Karol Herbst

On Tue, Oct 06, 2020 at 06:46:35PM +0200, Karol Herbst wrote: > On Tue, Oct 6, 2020 at 6:43 PM dann frazier <dann.frazier at canonical.com> wrote: > > > > On Mon, Oct 05, 2020 at 03:52:30PM +0200, Karol Herbst wrote: > > > Previously the code relied on device->pri to be NULL and to fail probing > > > later. We really should just return an error inside

From: Chris Chiu <chiu at endlessm.com> This new graphics card was failing to initialize with nouveau due to an "unknown chipset" error. Copy the GP106 configuration and rename for GP107/NV137. We don't know for certain that this is fully correct, but brief desktop testing suggests this is working fine. Signed-off-by: Chris Chiu <chiu at endlessm.com> Signed-off-by:

https://bugs.freedesktop.org/show_bug.cgi?id=88868 Bug ID: 88868 Summary: PowerPC e5500, kernel crash, GT520, GT610 Product: xorg Version: unspecified Hardware: PowerPC OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

The T124 generation of Tegra GPUs uses the Kepler architecture and can thus be driven by Nouveau. However, they are declared as platform devices using the Device Tree, and Nouveau has a very strong dependency on PCI. This patch makes Nouveau core able to handle platform devices as well as PCI devices. Commonly-used PCI functions include resource range query and page mapping. These functions are

dmesg -t | grep -i nvidia nouveau 0000:02:00.0: NVIDIA G98 (098200a2) input: HDA NVidia Rear Mic as /devices/pci0000:00/0000:00:07.0/sound/card0/input6 input: HDA NVidia Front Mic as /devices/pci0000:00/0000:00:07.0/sound/card0/input7 input: HDA NVidia Line as /devices/pci0000:00/0000:00:07.0/sound/card0/input8 input: HDA NVidia Line Out Front as /devices/pci0000:00/0000:00:07.0/sound/card0/input9

On Mon, 2024-06-17 at 21:54 +0200, Danilo Krummrich wrote: Hi Timur, thanks for the follow-up on this patch series. On Wed, Jun 12, 2024 at 06:52:53PM -0500, Timur Tabi wrote: The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers that have printf-like logs from GSP-RM and PMU encoded in them. LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA addresses are

On Tue, Oct 13, 2020 at 8:01 AM Karol Herbst <kherbst at redhat.com> wrote: > > With this we try to detect if the endianess switch works and assume LE if > not. Suggested by Ben. > > Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") > --- > .../gpu/drm/nouveau/nvkm/engine/device/base.c | 39 ++++++++++++------- > 1 file

Hello poma, The chipset didn't disappear and is still displayed: it is the G98 you get on the "[ 2.483843] nouveau 0000:02:00.0: NVIDIA G98 (098200a2)" line. The "NV98" was the "Nouveau" chipset, but the switch was made to use the same naming as NVIDIA. So rather than displaying both the Nouveau version of the chipset and the NVIDIA one, it make sense to only

This is a highly changed revision of the first patch series that adds secure boot support to Nouveau. This code still depends on NVIDIA releasing official firmware files, but the files released with SHIELD TV and Pixel C can already be used on a Jetson TX1. As you know we are working hard to release the official firmware files, however in the meantime it doesn't hurt to review the code so it

On Tue, Oct 6, 2020 at 6:43 PM dann frazier <dann.frazier at canonical.com> wrote: > > On Mon, Oct 05, 2020 at 03:52:30PM +0200, Karol Herbst wrote: > > Previously the code relied on device->pri to be NULL and to fail probing > > later. We really should just return an error inside nvkm_device_ctor for > > unsupported GPUs. > > > > Fixes: 24d5ff40a732

This patch set adds basic supports for amd next generation iommu (IOMMUv2) hardware. IOMMUv2 supports various new features advertised by iommu extended feature register. It introduces guest level IO translation and supports state-of-the-art ATS/ATC devices with demand paging capability. Please refer to AMD IOMMU Architectural Specification [1] for more details. Thanks, Wei [1]

Hello everyone, Reposting with after having applied the (minor) fixes suggested by Wei and Jan. Allen, if you can tell us what you think about this, or suggest someone else to ask some feedback to, if you''re no longer involved with VT-d, that would be great! :-) -- As already discussed here [1], dealing with IOMMU faults in interrupt context may cause nasty things to happen, up to

On 12/12/2016 09:26 PM, Chris Chiu wrote: > Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it > only gives VGA resolution on screen. Use the same chipset as nv134 > then it shows FullHD. This commit copies fields from nv134_chipset > to nv136_chipset for GTX 1060. I have one of these sitting on my desk, but won't be merging support for it until it's been