similar to: [PATCH] drm/nouveau: remove unused variable ret

Having the two modules separated causes various unneeded complications, including having to export symbols accessed between the modules. Make things simpler by compiling platform device support into nouveau.ko. Platform device support remains optional and is only compiled on Tegra. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- Vince, with this you won't have to export

From: Thierry Reding <treding at nvidia.com> Irrespective of whether or not the device has any usable outputs, the modesetting helpers will try to register all the resources such as CRTCs and planes. Unfortunately, the helpers rely on drm_mode_config_init() to properly set up internal data structures. Since the Tegra GPU does not have a display engine, the Nouveau driver doesn't set

Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > This patch adds some missing pieces of the rail gaing/ungating sequence that > can improve the stability in theory. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > drm/nouveau_platform.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > drm/nouveau_platform.h | 3 +++ > 2 files changed, 45

nvkm_mm_fini() was not called when exiting the driver, resulting in a memory leak. Fix this. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nouveau_platform.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c index 3691982452a9..f83aa12ee5c6 100644 --- a/drm/nouveau/nouveau_platform.c +++

op 26-06-14 07:33, Alexandre Courbot schreef: > Add a platform driver for Nouveau devices declared using the device tree > or platform data. This driver currently supports GK20A on Tegra > platforms and is only compiled for these platforms if Nouveau is > enabled. > > Nouveau will probe the chip type itself using the BOOT0 register, so all > this driver really needs to do is

This series adds support for probing platform devices on Nouveau, as well as the DT bindings for GK20A. It doesn't enable the GPU yet on Tegra boards since a few extra things need to be supported before that. This version is mostly identical to v2 but fixes an important issue: the drvdata must be set to the drm_device for sysfs to work, so the platform device structure now includes the

These 4 patches fix two issues that existed on Tegra regarding DMA: 1) The bit indicating whether to use an IOMMU or not was hardcoded ; make this a platform property and use it in instmem 2) The DMA mask was not set for platform devices. Fix this by converting more pci_dma* to the DMA API, and use that more generic code to set the DMA mask properly for all platforms. Tested on both x86

This series adds support for probing platform devices on Nouveau, as well as the DT bindings for GK20A. It doesn't enable the GPU yet on Tegra boards since a few extra things need to be supported before that. Thanks to the input received for v1, this version is more self-contained and shares less stuff between nouveau_drm and nouveau_platform. The major change is that nouveau_platform is now

On Thu, Jan 15, 2015 at 4:29 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Having the two modules separated causes various unneeded complications, > including having to export symbols accessed between the modules. Make > things simpler by compiling platform device support into nouveau.ko. > Platform device support remains optional and is only compiled on Tegra. >

This patch series is the leftovers of a patch series sent in September 2023 [1] in an attempt to get some of the patches landed finally. This patch series originally came about after a _long_ discussion between me and Maxime Ripard in response to a different patch I sent out [2]. As part of that discussion, we realized that it would be good if DRM drivers consistently called

This patch series came about after a _long_ discussion between me and Maxime Ripard in response to a different patch I sent out [1]. As part of that discussion, we realized that it would be good if DRM drivers consistently called drm_atomic_helper_shutdown() properly at shutdown and driver remove time as it's documented that they should do. The eventual goal of this would be to enable removing

This patch series is the final (?) step towards the initial support of GK20A, allowing it to be probed and used (currently at a very slow speed, and for offscreen rendering only) on the Jetson TK1 and Venice 2 boards. The main piece if the first patch which adds platform devices probing support to Nouveau. There are probably lots of things that need to be discussed about it, e.g.: * The way the

actually very glad to see this because I think I've seen one bug in the wild as a result of things not getting shut down :) Reviewed-by: Lyude Paul <lyude at redhat.com> Tested-by: Lyude Paul <lyude at redhat.com> On Thu, 2023-09-21 at 12:26 -0700, Douglas Anderson wrote: > Based on grepping through the source code this driver appears to be > missing a call to

Add a platform driver for Nouveau devices declared using the device tree or platform data. This driver currently supports GK20A on Tegra platforms and is only compiled for these platforms if Nouveau is enabled. Nouveau will probe the chip type itself using the BOOT0 register, so all this driver really needs to do is to make sure the module is powered and its clocks active before calling

This patch adds some missing pieces of the rail gaing/ungating sequence that can improve the stability in theory. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/nouveau_platform.c | 42 ++++++++++++++++++++++++++++++++++++++++++ drm/nouveau_platform.h | 3 +++ 2 files changed, 45 insertions(+) diff --git a/drm/nouveau_platform.c b/drm/nouveau_platform.c index

Hi, This series includes some pieces of fixes to complete the GK20A power on/off sequences and add the suspend/resume support. The patches 1/11 - 4/11 are based on the linux-next-20141219. The patches 5/11 - 11/11 are based on the branch "linux-3.19" of Ben Skeggs's tree (http://cgit.freedesktop.org/~darktama/nouveau). Thanks, Vince Vince Hsu (4): (linux-next-20141219) ARM:

On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > Irrespective of whether or not the device has any usable outputs, the > modesetting helpers will try to register all the resources such as CRTCs > and planes. Unfortunately, the helpers rely on drm_mode_config_init() to > properly set up internal data

Hello, There is a trouble on ARM with DMA allocations made by device drivers, the trouble is that DMA allocations are getting implicitly backed with IOMMU mapping by the driver core if IOMMU presents in a system and IOMMU could handle device. This is an undesired behaviour for drivers that manage IOMMU by themselves, like NVIDIA Tegra GPU driver. On arm32 the implicit backing happens if

On 12/24/2014 09:23 PM, Lucas Stach wrote: > Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >> This patch adds some missing pieces of the rail gaing/ungating sequence that >> can improve the stability in theory. >> >> Signed-off-by: Vince Hsu <vinceh at nvidia.com> >> --- >> drm/nouveau_platform.c | 42

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted