Re: [Nouveau] nvs280 / nv34 card only does 1680x1050, not 1920x1080 ?

On 04.09.2015 16:56, Ilia Mirkin wrote: > Tmds is limited to 135mhz on nv3x. If you use analog, you can get full > resolution. > On Sep 4, 2015 9:00 AM, "Hans de Goede" wrote: > >> Hi All, >> >> I've recently acquired a nvs280 card, which is a nv34 >> gpu based card with a pci-e bridge on the car

Re: [Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x

On Fri, Sep 4, 2015 at 9:10 AM, Hans de Goede wrote: > Hi, > > On 03-09-15 19:32, Ilia Mirkin wrote: >> >> On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote: >>> >>> On nv3x we will likely end up using the cpu to do color resolving for >>> msaa >>> blits. Disable msaa on these cards so that we

Re: [Nouveau] nvs280 / nv34 card only does 1680x1050, not 1920x1080 ?

Tmds is limited to 135mhz on nv3x. If you use analog, you can get full resolution. On Sep 4, 2015 9:00 AM, "Hans de Goede" wrote: > Hi All, > > I've recently acquired a nvs280 card, which is a nv34 > gpu based card with a pci-e bridge on the card, this > way I can test nv3x problems without needi

Re: [Nouveau] [PATCH mesa 4/4] nv30: Disable msaa on nv4x because it causes gpu lockups

Hi, On 03-09-15 19:33, Ilia Mirkin wrote: On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote: On nv4x with a msaa visual after a while the gpu locks up, attach gdb to impress shows it is hanging waiting for a fence which never comes. Killing ooimpress at this point works exactly once, trying

Re: [Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x

Hi, On 03-09-15 19:32, Ilia Mirkin wrote: On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote: On nv3x we will likely end up using the cpu to do color resolving for msaa blits. Disable msaa on these cards so that we do not end up using the cpu. Actually the CPU fallback won't do scaled, so i

[Nouveau] nvs280 / nv34 card only does 1680x1050, not 1920x1080 ?

Hi All, I've recently acquired a nvs280 card, which is a nv34 gpu based card with a pci-e bridge on the card, this way I can test nv3x problems without needing an agp motherboard. One thing which stands out with this card is that it drivers my dvi lcd monitor at 1680x1050 instead of its native 1

[Nouveau] [Bug 90626] HP ZBook 15 nouveau driver hangup for kernel >= 4.1

https://bugs.freedesktop.org/show_bug.cgi?id=90626 --- Comment #14 from vdanj...@free.fr --- Any progress on this bug? Any missing information? I still get the same thing on a HP ZBook 15, too: août 30 23:33:05 eyak kernel: nouveau :01:00.0: enabling device (0004 -> 0007) août 30 23:33:05 e

Re: [Nouveau] [PATCH mesa 0/4] nv30: Various fixes

Hi, On 03-09-15 19:14, Ilia Mirkin wrote: On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote: Hi All, Here is a bunch of fixes for nv30 cards, the first patch is a resend of a patch I send a while back. AFAICT that one is ready for merging, but it is not entirely clear to me what the process

Re: [Nouveau] nv3x libreoffice impress opengl animations not working

Hi, On 03-09-15 19:36, Ilia Mirkin wrote: On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede wrote: Hi, On 02-09-15 16:44, Ilia Mirkin wrote: On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede wrote: Hi Ilia Of course I don't really see how MS can work at all with nv30 since it doesn't suppo

[Nouveau] [PATCH 3/4] ttm: convert to DMA API

The pci_dma_* functions are now superseeded in the kernel by the DMA API. Make the conversion to this more generic API. Signed-off-by: Alexandre Courbot --- drm/nouveau/nouveau_ttm.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drm/nouveau/nouveau_ttm.c b/drm/

[Nouveau] [PATCH 4/4] ttm: set the DMA mask for platform devices

So far the DMA mask was not set for platform devices, which limited them to a 32-bit physical space. Allow dma_set_mask() to be called for non-PCI devices, and also take the IOMMU bit into account since it could restrict the physically addressable space. Signed-off-by: Alexandre Courbot --- drm/

[Nouveau] [PATCH 0/4] tegra: DMA mask and IOMMU bit fixes

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,

[Nouveau] [PATCH 2/4] instmem/gk20a: make use of the IOMMU bit

Use the IOMMU bit specified in platform data instead of hardcoding it to the bit used by current Tegra GPUs. Signed-off-by: Alexandre Courbot --- drm/nouveau/nvkm/subdev/instmem/gk20a.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/instmem

[Nouveau] [PATCH 1/4] platform: allow to specify the IOMMU bit

Current Tegra code taking advantage of the IOMMU assumes a hardcoded value for the IOMMU bit. Make it a platform property instead for flexibility. Signed-off-by: Alexandre Courbot --- drm/nouveau/include/nvkm/core/tegra.h | 3 +++ drm/nouveau/nouveau_platform.c | 14 -- drm

[Nouveau] [PATCH v3] instmem/gk20a: use direct CPU access

The Great Nouveau Refactoring Take II brought us a lot of goodness, including acquire/release methods that are called before and after an instobj is modified. These functions can be used as synchronization points to manage CPU/GPU coherency if we modify an instobj using the CPU. This patch replace