similar to: [PATCH] drm: merge nouveau_platform.ko into nouveau.ko

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. >

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

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 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

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

This patch is needed by initramfs tools to detect the required firmware files for the module. This patch tests for NOUVEAU_PLATFORM_DRIVER and either TEGRA_124_SOC or TEGRA_132_SOC for the firmwares related to the Tegra K1 generation. Signed-off-by: Nicolas Chauvet <kwizart at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff

On Tue, Dec 30, 2014 at 11:18:34AM +0800, Vince Hsu wrote: > Hi Emil, > > On 12/30/2014 10:34 AM, Emil Velikov wrote: > >On 23/12/14 10:40, Vince Hsu wrote: > >>This patch adds some checks in the suspend/resume functions to distinguish > >>the dGPU and mobile GPU and exports some variables/functions so that the > >>nouveau platform device can reuse them.

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

On Thu, Jan 15, 2015 at 3:39 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > 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

This patch is needed by initramfs tools to detect the required firmware files for the module. This patch tests for either TEGRA_124_SOC or TEGRA_132_SOC for the firmwares related to the Tegra K1 generation. v2: move the MODULE_FIRMWARE to the nvidia_platform.c file. This will avoid to test for NOUVEAU_PLATFORM_DRIVER Signed-off-by: Nicolas Chauvet <kwizart at gmail.com> ---

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

Le 26/06/2014 16:58, Alexandre Courbot a ?crit : > On Thu, Jun 26, 2014 at 6:30 PM, Roy Spliet <seven at nimrod-online.com> wrote: >> 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

On 23/12/14 10:40, Vince Hsu wrote: > This patch adds some checks in the suspend/resume functions to distinguish > the dGPU and mobile GPU and exports some variables/functions so that the > nouveau platform device can reuse them. > Hi Vince, Afaiu one needs to export a symbol as it's used by another module or subsystem. With the follow up two patches you are not doing either one,

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:

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

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

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

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

This fixes the auto-magic detection of LEDS_CLASS by fixing the case where nouveau would be built-in and the LEDS_CLASS would be built as as module. Cc: <stable at vger.kernel.org> # 4.9.x- Reported-by: Intel's 0-DAY Signed-off-by: Martin Peres <martin.peres at free.fr> --- drivers/gpu/drm/nouveau/Kbuild | 2 +- drivers/gpu/drm/nouveau/Kconfig | 9 +++++++++ 2 files changed, 10