Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 01 2月, 2010 3 次提交
  3. 25 1月, 2010 13 次提交
  5. 24 1月, 2010 5 次提交
  7. 21 1月, 2010 14 次提交
  9. 18 1月, 2010 5 次提交
    • B
      drm/nv50: prevent accidently turning off encoders we're actually using · 58d65b84
      由 Ben Skeggs 提交于 
      On most cards the DisplayPort connector is created with 2 encoders sharing
a single SOR (for native DP, and for DVI-over-DP).  The previous logic
for turning off unused encoders didn't take into account that we could
have multiple drm_encoders on a single hw encoder and ended up turning off
encoders that were actually being used still.

This patch fixes that issue.  We probably want to look at something a bit
better later on, and only expose one drm_encoder per hw encoder block.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      58d65b84
    • B
      drm/nv50: fix alignment of per-channel fifo cache · 134f248b
      由 Ben Skeggs 提交于 
      GPU pointer to the structure is shifted right by 10 bits, so we need to
align to 1024 bytes, not 256.
Reported-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      134f248b
    • L
      drm/nouveau: Evict buffers in VRAM before freeing sgdma · 71666475
      由 Luca Barbieri 提交于 
      Currently, we take down the sgdma engine without evicting all buffers
from VRAM.

The TTM device release will try to evict anything in VRAM to GART
memory, but this will fail since sgdma has already been taken down.

This causes an infinite loop in kernel mode on module unload.
It usually doesn't happen because there aren't any buffer on close.
However, if the GPU is locked up, this condition is easily triggered.

This patch fixes it in the simplest way possible by cleaning VRAM
right before cleaning SGDMA memory.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      71666475
    • L
      drm/nouveau: Acknowledge DMA_VTX_PROTECTION PGRAPH interrupts · d051bbb2
      由 Luca Barbieri 提交于 
      Currently Nouveau is unable to dismiss DMA_VTX_PROTECTION errors,
which results in an infinite loop in the interrupt handler.

These errors are caused both by bugs in the Gallium driver and by
user-specified index buffers with out of bounds indices.

By mmio-tracing the nVidia drivers, I found out how this is done.
On DMA_VTX_PROTECTION, The nVidia driver reads the register 0x402000,
always getting the value 4, and then writes 4 back to 0x402000.

This patch adds that logic by reading 0x402000 and writing the same
value back.
It's unclear what should happen if the value read is not 4, and
the current approach might not be the correct one.

To test this, modify mesa/progs/trivial/vbo-drawrange.c, defining
ELTOBJ to 1 and replacing indices with huge out of bounds integers.

Without this patch, the GPU and/or kernel should lock up.
With this patch, it should misrender as expected but not lock up.

The errors are still logged since they are useful for development.

This has been tested on NV49 and may not work on other cards.

To find out how things work on other cards, run the aforementioned
test using the blob with mmiotrace and grep for a read of the PGRAPH
source register.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d051bbb2
    • B
      drm/nouveau: fix thinko in nv04_instmem.c · 0d92971d
      由 Ben Skeggs 提交于 
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      0d92971d