similar to: [PATCH] drm/nouveau: tegra: Call nouveau_drm_device_init()

On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline <jcline at redhat.com> wrote: > > Make use of the devm_drm_dev_alloc() API to bind the lifetime of > nouveau_drm structure to the drm_device. This is important because a > reference to nouveau_drm is accessible from drm_device, which is > provided to a number of DRM layer callbacks that can run after the > deallocation of

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the

Make use of the devm_drm_dev_alloc() API to bind the lifetime of nouveau_drm structure to the drm_device. This is important because a reference to nouveau_drm is accessible from drm_device, which is provided to a number of DRM layer callbacks that can run after the deallocation of nouveau_drm currently occurs. Signed-off-by: Jeremy Cline <jcline at redhat.com> ---

Please find below an automated bisection report for a kernel Oops seen during the initialisation of the nouveau GPU driver on jetson-tk1. All the LAVA test jobs for this bisection can be found here: http://lava.baylibre.com:10080/scheduler/alljobs?length=25&search=lava-bisect-staging-7366#table Here's the beginning of the Oops stack trace: [ 7.485361] [00000064] *pgd=f9e7b835 [

On 08/12/2018 00:08, Lyude Paul wrote: > uhhhhhhhhhhhhh > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > nouveau_drm_device_init()" Yes here's the fix from Thierry: https://patchwork.freedesktop.org/patch/263587/ and I can confirm that it does fix the Oops when applied on top of next-20181206 (what I used for the bisection last week):

On Mon, Dec 10, 2018 at 11:21:47AM +0100, Thierry Reding wrote: > On Sat, Dec 08, 2018 at 02:54:45PM +0000, Marcel Ziswiler wrote: > > Hi Thierry et al. > > > > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on > > Tegra124") graphics on Apalis TK1 is broken. During boot it fails > > loading the vic firmware: > > > > [

uhhhhhhhhhhhhh didn't we fix this weeks ago? with "drm/nouveau: tegra: Call nouveau_drm_device_init()" On Fri, 2018-12-07 at 23:31 +0000, Guillaume Tucker wrote: > Please find below an automated bisection report for a kernel Oops > seen during the initialisation of the nouveau GPU driver on > jetson-tk1. > > > All the LAVA test jobs for this bisection can be

Hello, Commit 2541626cfb79 breaks GM20B probe with the following kernel log: [ 2.153892] ------------[ cut here ]------------ [ 2.153897] WARNING: CPU: 1 PID: 36 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 gf100_vmm_valid+0x2c4/0x390 [ 2.153916] Modules linked in: [ 2.153922] CPU: 1 PID: 36 Comm: kworker/u8:1 Not tainted 6.1.0+ #1 [ 2.153929] Hardware name: Google

Hi there The Release Notes for Samba 3.0.8 from Nov 7, 2004 stated the following: =========================== Change in Winbindd Behavior =========================== All usernames returned by winbindd are now converted to lower case for better consistency. This means any winbind installation relying on the winbind username will need to rename existing directories and/or files based on the

Hi All, I'm having this really weird issue with broken hotplug on a Dell Latitude E6430 with hybrid gfx, with a gf108 as discrete GPU. The LCD panel and VGA are connected through a mux to the iGPU, but the HDMI is only connected to the nvidia dGPU. Plugging in a HDMI monitor when the dGPU is suspend works fine, the ACPI event fires and everything works as it should. Unplugging the HDMI

This series is intended to add support for shutting down the GPU on kernel shutdown/reboot using the ->shutdown() hook, similar to what amdgpu does. This is mainly intended to workaround a bios issue on the P50 that was preventing nouveau from initializing the dedicated GM107 GPU on that system properly. You can find more details on this issue in the patch labeled "Shut down GPU on kernel

Hi Thierry et al. I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on Tegra124") graphics on Apalis TK1 is broken. During boot it fails loading the vic firmware: [ 1.595824] tegra-vic 54340000.vic: Direct firmware load for nvidia/tegra124/vic03_ucode.bin failed with error -2 [ 1.606140] tegra-vic: probe of 54340000.vic failed with error -2 Subsequently Tegra HDMI

From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> Currently drm_gem_handle_create_tail exposes the handle to userspace before the buffer object constructions is complete. This allowing of working against a partially constructed object, which may also be in the process of having its creation fail, can have a range of negative outcomes. A lot of those will depend on what the individual

From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> Currently drm_gem_handle_create_tail exposes the handle to userspace before the buffer object constructions is complete. This allowing of working against a partially constructed object, which may also be in the process of having its creation fail, can have a range of negative outcomes. A lot of those will depend on what the individual

Hi, On 14/02/2023 13:59, Christian K?nig wrote: > Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin: >> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> >> >> Currently drm_gem_handle_create_tail exposes the handle to userspace >> before the buffer object constructions is complete. This allowing >> of working against a partially constructed object, which may

Hi, On 14/02/2023 13:59, Christian K?nig wrote: > Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin: >> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> >> >> Currently drm_gem_handle_create_tail exposes the handle to userspace >> before the buffer object constructions is complete. This allowing >> of working against a partially constructed object, which may

Hi there First a big thank you to all nut developers. I tried the 2.0.4 as well as the 2.0.5-pre1 versions with my CyberPower OP1000E connected to a serial to USB converter. All I got was the following: # /usr/local/ups/bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.0.5-pre1 Network UPS Tools - CyberPower text protocol UPS driver .05 (2.0.5-pre1) Warning: This is an

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

Hello, 5.1.0-next-20190517 I'm looking at quite a lot of kmemleak reports coming from drm/nouveau/core/memory, all of which are: unreferenced object 0xffff8deec27c4ac0 (size 16): comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:

On 20/02/2023 10:01, Christian K?nig wrote: > Am 20.02.23 um 10:55 schrieb Tvrtko Ursulin: >> >> Hi, >> >> On 14/02/2023 13:59, Christian K?nig wrote: >>> Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin: >>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> >>>> >>>> Currently drm_gem_handle_create_tail exposes the handle