[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75985

--- Comment #55 from Ilia Mirkin  ---
(In reply to Maik Freudenberg from comment #54)
> (In reply to Ilia Mirkin from comment #44)
> > One can check if the DCB table has any outputs, and only do
> > stuff if there are none.
> I don't see how that's feasible since this would require to load the ROM and
> parse it and this is about an early pci quirk or am I wrong there?

Correct.

What's the downside for doing this always btw (except for a fixed list of pci
ids/ranges, for the "older" chips, i.e. pre-fermi)?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75985

--- Comment #54 from Maik Freudenberg  ---
(In reply to Ilia Mirkin from comment #44)
> One can check if the DCB table has any outputs, and only do
> stuff if there are none.
I don't see how that's feasible since this would require to load the ROM and
parse it and this is about an early pci quirk or am I wrong there?
Sidenote: there's also one gtx560ti that's advertising as
PCI_CLASS_MULTIMEDIA_OTHER

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75985

--- Comment #57 from Maik Freudenberg  ---
(In reply to Ilia Mirkin from comment #55)
> What's the downside for doing this always btw 
By 'this', you mean, always turning it on?
This generates the errors from comment #42 since those devices are not
configured resource-wise, all zeros.
I think that's rather ugly, users getting confused, trying to poke sound
through the device, spamming mailing-lists. That's just the non-technical side
of it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75985

--- Comment #56 from Lukas Wunner  ---
(In reply to Ilia Mirkin from comment #53)
> (In reply to Lukas Wunner from comment #52)
> > Ilia, do you have definitive knowledge of GPUs which
> > a) have a different class than PCI_CLASS_DISPLAY_VGA and
> > b) have working DP/HDMI outputs and
> > c) have an integrated HDA controller?
> > 
> > I'm asking because get_bound_vga() in sound/pci/hda/hda_intel.c specifically
> > matches against PCI_CLASS_DISPLAY_VGA only. In other words, if a GPU with
> > the three above-listed properties exists and is built into a hybrid graphics
> > laptop, it is currently not registered with vga_switcheroo, which would be
> > wrong.
> 
> I can say with some certainty that there are laptops running around, esp
> GM107's, whose pci class is 3D, and that have attached DP/HDMI outputs.
> 
> I don't think the users in question ever asked about audio, so I don't know
> about the last bit. However I can't imagine that it wouldn't be there (esp
> once all the proper enablement is done).

In the meantime I've done extensive googling for dmesg output of a laptop that
satisfies all three conditions listed above, but I come back empty-handed. I
did find machines with a PCI_CLASS_DISPLAY_3D Nvidia card and an HDA device on
function 1, but those weren't laptops. So it looks to me like we're good right
now but we'll definitely need to amend hda_intel.c if we expose the HDA device
on all modern cards.

> Is hda_intel only for intel?

No, that file contains the driver for all PCI HDA devices, its name is a
historic artifact.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 99464] openmw - Segfault with the nouveau ddx + DRI3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99464

--- Comment #2 from Greg V  ---
I'm currently also experiencing a crash with OpenMW in update_framebuffer_size
(surface is NULL).

But with RadeonSI on Wayland! (SDL_VIDEODRIVER=wayland)

Radeon RX 480, FreeBSD 12-CURRENT + drm-next-kmod 4.11, Mesa 18.1.0-devel (git
master with my BSD fixes).

Same game works fine on X11. Under Weston, this crash. It *used to* work fine
on Wayland, but broke recently.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 99464] openmw - Segfault with the nouveau ddx + DRI3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99464

--- Comment #3 from Greg V  ---
(In reply to Greg V from comment #2)

UPDATE! The issue was in our DRM port, specifically with ioctl
authentication/permissions.

If nouveau still has this problem, try looking into that…

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=75985

--- Comment #58 from Ilia Mirkin  ---
OK, well, I've seen this both ways -- 3D controllers with outputs as well as
VGA display adapters with the display function actually fused off. The only
reliable thing is the DCB block, but like you said, it's not appropriate for an
early pci quirk.

Finding the specifics is going to be difficult. People come into #nouveau with
a pastebin of their dmesg and some problem, and I note it in my head over the
years. Finding these will be next to impossible, esp as the pastes expire
fairly quickly.

Whatever solution you try to come up with, remember that all these cases are
possible, but some more frequent than others.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Aspirant for GSOC 2018 for Nouveau Vulkan driver

[Anusha Srivastava]

Hi,

I am not been able to contact with mentor of this project.
Can someone else from the community help me with this ?


Regards,
Anusha Srivastava


On 3 March 2018 at 11:16, Anusha Srivastava  wrote:
> Hi Martin,
>
> Any update on this ?
> Regards,
> Anusha Srivastava
>
>
> On 28 February 2018 at 23:37, Anusha Srivastava  
> wrote:
>> Hi,
>>
>> I would like to participate in  GSOC 2018 with Xorg to contribute to
>> project "Initial Nouveau Vulkan driver'
>> I would need some help in how to get started with the same.
>>
>> Regards,
>> Anusha Srivastava
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA

[Daniel Vetter]

On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> Modernize vga_switcheroo by using a device link to enforce a runtime PM
> dependency from an HDA controller to the GPU it's integrated into, v2.
> 
> Changes since v1:
> 
> - Replace patch [1/7] to use pci_save_state() / pci_restore_state()
>   for consistency between runtime PM code path of bound and unbound
>   devices. (Rafael, Bjorn)
> 
> - Patch [5/7]: Drop an unnecessary initialization. (Bjorn)
>   Rephrase error message on failed link addition for clarity.
> 
> Link to v1:
> https://www.spinics.net/lists/dri-devel/msg165889.html
> 
> Testing on more machines would be greatly appreciated, particularly
> Nvidia Optimus or AMD PowerXpress.
> 
> The series is based on 4.16-rc3.  To test it on 4.15, you need to
> cherry-pick 7506dc798993 and 2fa6d6cdaf28.  For your convenience
> I've pushed a 4.15-based branch to:
> https://github.com/l1k/linux/commits/switcheroo_devlink_v2
> 
> Minimal test procedure:
> 
> - Note well: Recent Optimus require that a Mini-DP or HDMI cable is
>   plugged in on boot for the HDA device to be present.
> 
> - Check that HDA, GPU and root port autosuspend when not in use:
>   cat /sys/bus/pci/devices/:01:00.1/power/runtime_status  # HDA
>   cat /sys/bus/pci/devices/:01:00.0/power/runtime_status  # GPU
>   cat /sys/bus/pci/devices/:00:01.0/power/runtime_status  # Root Port
> 
> - Check that all three autoresume when accessing the HDA:
>   hdajacksensetest -c 1
> 
> - Unbind the HDA controller:
>   echo :01:00.1 > /sys/bus/pci/drivers/snd_hda_intel/unbind
>   Wait for GPU to power off, then rebind the HDA controller:
>   echo :01:00.1 > /sys/bus/pci/drivers/snd_hda_intel/bind
>   Check dmesg for errors, try accessing HDA with hdajacksensetest.
> 
> - If your laptop uses the root port's _PR3 to cut power to the GPU:
>   Unbind the GPU:
>   echo :01:00.0 > /sys/bus/pci/drivers/{nouveau,amdgpu,radeon}/unbind
>   Allow runtime PM on the GPU:
>   echo auto > /sys/bus/pci/devices/:01:00.0/power/control
>   Wait for GPU to power off, then rebind it:
>   echo :01:00.0 > /sys/bus/pci/drivers/{nouveau,amdgpu,radeon}/bind
>   Check dmesg for errors.  If you see any then we may need to perform
>   further actions in pci_pm_runtime_resume(), see patch [1/7].

This all looks really reasonable and like a good cleanup, but it's a bit
too much detail so I'll punt review to someone else with more clue.
-Daniel

> 
> Thanks,
> 
> Lukas
> 
> 
> Lukas Wunner (6):
>   PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public
>   vga_switcheroo: Update PCI current_state on power change
>   vga_switcheroo: Deduplicate power state tracking
>   vga_switcheroo: Use device link for HDA controller
>   vga_switcheroo: Let HDA autosuspend on mux change
>   drm/nouveau: Runtime suspend despite HDA being unbound
> 
> Rafael J. Wysocki (1):
>   PCI: Restore config space on runtime resume despite being unbound
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |   2 -
>  drivers/gpu/drm/nouveau/nouveau_drm.c   |  46 --
>  drivers/gpu/drm/nouveau/nouveau_drv.h   |   1 -
>  drivers/gpu/drm/radeon/radeon_drv.c |   2 -
>  drivers/gpu/vga/vga_switcheroo.c| 152 
> 
>  drivers/pci/pci-driver.c|  17 ++--
>  drivers/pci/pci.c   |   8 +-
>  drivers/pci/quirks.c|  39 
>  include/linux/pci.h |   2 +
>  include/linux/pci_ids.h |   1 +
>  include/linux/vga_switcheroo.h  |   6 --
>  include/sound/hdaudio.h |   3 -
>  sound/pci/hda/hda_intel.c   |  36 +---
>  sound/pci/hda/hda_intel.h   |   3 -
>  14 files changed, 117 insertions(+), 201 deletions(-)
> 
> -- 
> 2.15.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/5] drm/ttm: add ttm_sg_tt_init

[Daniel Vetter]

On Tue, Feb 27, 2018 at 01:07:06PM +0100, Christian König wrote:
> Hi guys,
> 
> at least on amdgpu and radeon the page array allocated by ttm_dma_tt_init is
> completely unused in the case of DMA-buf sharing. So I'm trying to get rid
> of that by only allocating the DMA address array.
> 
> Now the only other user of DMA-buf together with ttm_dma_tt_init is Nouveau.
> So my question is are you guys using the page array anywhere in your kernel
> driver in case of a DMA-buf sharing?
> 
> If no then I could just make this the default behavior for all drivers and
> save quite a bit of memory for everybody.

+1 on teaching ttm to no longer look at the struct page * in the dma-buf
sgt, but only the dma_buf address.

If there's still some need for in-kernel cpu or userspace mmap access then
imo ttm needs to be fixed to delegate all that to the right dma-buf
interfaces. The ttm abstraction is already there, it's just not passed
through.

I don't pretend to now enough of the details to review this stuff :-)
-Daniel

> 
> Thanks,
> Christian.
> 
> Am 27.02.2018 um 12:49 schrieb Christian König:
> > This allows drivers to only allocate dma addresses, but not a page
> > array.
> > 
> > Signed-off-by: Christian König 
> > ---
> >   drivers/gpu/drm/ttm/ttm_tt.c | 54 
> > 
> >   include/drm/ttm/ttm_tt.h |  2 ++
> >   2 files changed, 47 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > index 8e0b525cda00..971133106ec2 100644
> > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > @@ -108,6 +108,16 @@ static int ttm_dma_tt_alloc_page_directory(struct 
> > ttm_dma_tt *ttm)
> > return 0;
> >   }
> > +static int ttm_sg_tt_alloc_page_directory(struct ttm_dma_tt *ttm)
> > +{
> > +   ttm->dma_address = kvmalloc_array(ttm->ttm.num_pages,
> > + sizeof(*ttm->dma_address),
> > + GFP_KERNEL | __GFP_ZERO);
> > +   if (!ttm->dma_address)
> > +   return -ENOMEM;
> > +   return 0;
> > +}
> > +
> >   #ifdef CONFIG_X86
> >   static inline int ttm_tt_set_page_caching(struct page *p,
> >   enum ttm_caching_state c_old,
> > @@ -227,8 +237,8 @@ void ttm_tt_destroy(struct ttm_tt *ttm)
> > ttm->func->destroy(ttm);
> >   }
> > -int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
> > -   unsigned long size, uint32_t page_flags)
> > +void ttm_tt_init_fields(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
> > +   unsigned long size, uint32_t page_flags)
> >   {
> > ttm->bdev = bdev;
> > ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> > @@ -236,6 +246,12 @@ int ttm_tt_init(struct ttm_tt *ttm, struct 
> > ttm_bo_device *bdev,
> > ttm->page_flags = page_flags;
> > ttm->state = tt_unpopulated;
> > ttm->swap_storage = NULL;
> > +}
> > +
> > +int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
> > +   unsigned long size, uint32_t page_flags)
> > +{
> > +   ttm_tt_init_fields(ttm, bdev, size, page_flags);
> > if (ttm_tt_alloc_page_directory(ttm)) {
> > ttm_tt_destroy(ttm);
> > @@ -258,12 +274,7 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct 
> > ttm_bo_device *bdev,
> >   {
> > struct ttm_tt *ttm = _dma->ttm;
> > -   ttm->bdev = bdev;
> > -   ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> > -   ttm->caching_state = tt_cached;
> > -   ttm->page_flags = page_flags;
> > -   ttm->state = tt_unpopulated;
> > -   ttm->swap_storage = NULL;
> > +   ttm_tt_init_fields(ttm, bdev, size, page_flags);
> > INIT_LIST_HEAD(_dma->pages_list);
> > if (ttm_dma_tt_alloc_page_directory(ttm_dma)) {
> > @@ -275,11 +286,36 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, 
> > struct ttm_bo_device *bdev,
> >   }
> >   EXPORT_SYMBOL(ttm_dma_tt_init);
> > +int ttm_sg_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device *bdev,
> > +  unsigned long size, uint32_t page_flags)
> > +{
> > +   struct ttm_tt *ttm = _dma->ttm;
> > +   int ret;
> > +
> > +   ttm_tt_init_fields(ttm, bdev, size, page_flags);
> > +
> > +   INIT_LIST_HEAD(_dma->pages_list);
> > +   if (page_flags & TTM_PAGE_FLAG_SG)
> > +   ret = ttm_sg_tt_alloc_page_directory(ttm_dma);
> > +   else
> > +   ret = ttm_dma_tt_alloc_page_directory(ttm_dma);
> > +   if (ret) {
> > +   ttm_tt_destroy(ttm);
> > +   pr_err("Failed allocating page table\n");
> > +   return -ENOMEM;
> > +   }
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(ttm_sg_tt_init);
> > +
> >   void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
> >   {
> > struct ttm_tt *ttm = _dma->ttm;
> > -   kvfree(ttm->pages);
> > +   if (ttm->pages)
> > +   kvfree(ttm->pages);
> > +   else
> > +   kvfree(ttm_dma->dma_address);
> > ttm->pages = NULL;
> > ttm_dma->dma_address = 

[Nouveau] [Bug 105344] Installation bug by video card modules conflict (nvidia GTX 950 M)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105344

--- Comment #7 from Yuri Gelsleichter  ---
Dear all,

thanks for the points.

(In reply to Ilia Mirkin from comment #5)
> (In reply to Emil Velikov from comment #4)
> > Considering that nouveau.modeset=0 helps, I'm flipping this to component
> > nouveau. Feel free to revert.
> 
> Hard to imagine why -- intel is primary, and nvidia chip has no outputs.
> Must be something silly in how the distro has things set up.

The point here is that Nvidia has no drivers in use. With nouveau, system
breaks (impossible to boot), with proprietary system get slow and freeze often
(I am aware that you do not deal with proprietary drivers).

If I boot with "quite splash", the system breaks before boot.
If I boot without any "modeset", the system only get to the terminal.

The only way to get "normal" use is booting with any "nomodeset" (without
proprietary driver for videocard).

I was wondering to understand why the distros (all of them) do not work out of
the box in this machine. As they work great in general in any machine.

I would be glad if one day Linux working smooth out of the box on this
machines.

Thanks for all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 105344] Installation bug by video card modules conflict (nvidia GTX 950 M)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105344

--- Comment #6 from Yuri Gelsleichter  ---
Dear all,

thanks for the points.

(In reply to Emil Velikov from comment #4)
> Considering that nouveau.modeset=0 helps, I'm flipping this to component
> nouveau. Feel free to revert.
> 
Flipping fits good.

> > kernel is: 4.13.0-36-generic
> > mesa: OpenGL version string: 3.0 Mesa 17.2.8
> FWIW these two are EOL. You might want to try something newer.
>
I tried the very fresh through ArchLinux and Manjaro.

> > libdrm: could not find
> > xf86-video-nouveau: could not find.
> > 
> Exact names might differ across distros - please search carefully.
> 
> > -
> > 
> > Follow the "kernel_log.txt" output:
> > 
> Please make sure you _attach_ logs.
> 
> > [1.333868] nouveau :01:00.0: bus: MMIO read of  FAULT at
> > 612004 [ IBUS ]
> > [1.335248] nouveau :01:00.0: bus: MMIO read of  FAULT at
> > 10ac08 [ IBUS ]
> 
> These two look mildly interesting. Not sure how much it matters sunce the
> nvidia device is a 3D controller - there should be no outputs wired/plugged.
>

It is a laptop, so always plugged.
The point here is that Nvidia has no drivers in use. With nouveau, system
breaks (impossible to boot), with proprietary system get slow and freeze often
(I am aware that you do not deal with proprietary drivers).

If I boot with "quite splash", the system breaks before boot.
If I boot without any "modeset", the system only get to the terminal.

The only way to get "normal" use is booting with any "nomodeset" (without
proprietary driver for videocard).

I was wondering to understand why the distros (all of them) do not work out of
the box in this machine. As they work great in general in any machine.

I would be glad if one day Linux working smooth out of the box on this
machines.

> Potential next steps include:
>  - using xserver or wayland - try the former
>  - [it using xserver] - flip between the modesetting and nouveau DDX
>  - attach the respective logs - xserver -> Xorg.*.log, wayland -> no idea
> where kwin puts it
> 
> If the above are cryptic, do read through the wikis/googleit ;-)
> 
> https://nouveau.freedesktop.org/wiki/
> https://nouveau.freedesktop.org/wiki/Optimus/
> https://wiki.archlinux.org/index.php/nouveau

Thanks for the path, I will go for it.
Thanks for all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau