search for: outps

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c index 6094805fbd63..06b19883a06b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c +++

Now that we're supporting things like Ada and the GSP, there's situations where we really need to actually know the display state that we're starting with when loading the driver in order to prevent breaking GSP expectations. The first step in doing this is making it so that we can read the current state of IORs from nvkm in DRM, so that we can fill in said into into the atomic state.

Hi Ben, still _assuming_ it's an issue of the card I thought about why it works with the NVIDIA binary driver. And I can image they're just trying to do an identity-mapping first and if that doesn't work (e.g. the particular SOR is already in use by another macro link) they just pick the next suitable one. So the case would be that the NVIDIA binary driver always assignes the only

With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar routing should be possible, such that any SOR sublink can drive any macro link. Unfortunately, there's at least one card where some SOR sublinks being connected to a particular macro link are causing failures. To work around this issue, supply a quirk for such cards which prevents a dynamic mapping of SOR sublink and macro link

With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar routing should be possible, such that any SOR sublink can drive any macro link. Unfortunately, there's at least one card where some SOR sublinks being connected to a particular macro link are causing failures. To work around this issue, supply a quirk for such cards which prevents a dynamic mapping of SOR sublink and macro link

Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of nouveau in order to read the DPCD of a DP connector, which makes sure we do the right thing and also check for extended DPCD caps. However, it turns out we're not currently doing this on the nvkm side since we don't have access to the drm_dp_aux structure there - which means that the DRM side of the driver and the NVKM

I have the signed firmware (I think) and I'm running a fresh 4.6 kernel. I got an image to show up briefly, rendering the Fedora sign-in screen at something like one frame per ten seconds. But then I got all kinds of garbage, and I see: [ 719.300820] nouveau 0000:09:00.0: disp: outp 04:0006:0f44: link training failed dmesg |grep nouveau says: [ 10.053162] fb: switching to nouveaufb

Taken from NVIDIA binary driver (Linux 64-bit, revision 390.25) from README.txt. Signed-off-by: Danilo Krummrich <danilokrummrich at dk-develop.de> --- drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 41 ++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c index

Both Coverity and GCC with -Wstringop-overflow noticed that nvif_outp_acquire_dp() accidentally defined its second argument with 1 additional element: drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_pior_atomic_enable': drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: error: 'nvif_outp_acquire_dp' accessing 16 bytes in a region of size 15 [-Werror=stringop-overflow=]

Sorry! I've been pretty busy until now, this is: Reviewed-by: Lyude Paul <lyude at redhat.com> Let me know if you've pushed it already or if you want me to push it to drm- misc On Wed, 2023-01-25 at 12:15 -0800, Kees Cook wrote: > Ping. I'll take this via my tree unless someone else wants to take it... > > On Sun, Nov 27, 2022 at 10:30:41AM -0800, Kees Cook wrote:

Taken from NVIDIA binary driver (Linux 64-bit, revision 390.25) from README.txt. Signed-off-by: Danilo Krummrich <danilokrummrich at dk-develop.de> --- drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 41 ++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c index

If init doesn't run then disp->outp might not be initialized, resulting in an oops. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c b/drivers/gpu/drm/nouveau/core/engine/disp/base.c index c41f656abe64..9c38c5e40500 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/base.c +++

More arrays (and arguments) for dcpd were set to 16, when it looks like DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen with GCC 13: ../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp': ../include/linux/fortify-string.h:57:33: warning: array subscript 'unsigned char[16][0]' is partly outside array bounds of 'u8[15]' {aka

While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max symbol rate supported by the encoder, so limiting clock to ds_clock using max() doesn't make sense. Additionally, we want to check against 6bpc for the time being since that's the

This is another bit that we never implemented for nouveau: dongle detection. When a "dongle", e.g. an active display adaptor, is hooked up to the system and causes an HPD to be fired, we don't actually know whether or not there's anything plugged into the dongle without checking the sink count. As a result, plugging in a dongle without anything plugged into it currently results

The commit commit 476e84e126171d809f9c0b5d97137f5055f95ca8 Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Feb 11 09:24:23 2013 +1000 drm/nv50-/disp: initial supervisor support for off-chip encoders changed the write mask in one of the interrupt functions for on-chip encoders, causing a regression in certain VGA dual-head setups. This commit reintroduces the mask

Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2. Cheers, -ilia On Sat, May 28, 2016 at 4:51 PM, Andy Lutomirski <luto at kernel.org> wrote: > I have the signed firmware (I think) and I'm running a fresh 4.6 > kernel. I got an image to show up briefly, rendering the Fedora > sign-in screen at something like one frame per ten seconds. But then >

From: Chen Haonan <chen.haonan2 at zte.com.cn> Use kmemdup() helper instead of open-coding to simplify the code. Signed-off-by: Chen Haonan <chen.haonan2 at zte.com.cn> Reviewed-by: Yang Guang <yang.guang5 at zte.com.cn> --- drivers/gpu/drm/nouveau/nvif/outp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvif/outp.c

Hi, I want to run t.test() for several variables among two groups, and I would like to skip the tedious process of collecting information to assemble a table, but I am not sure if the function I want already exists. Any suggestion would be appreciated. I have a working example, as required by the posting guide: my_swiss = swiss[-1,] my_swiss$facto = rep(1:2,nrow(my_swiss)/2)

From: Yang Guang <yang.guang5 at zte.com.cn> Use kmemdup() helper instead of open-coding to simplify the code. Signed-off-by: Chen Haonan <chen.haonan2 at zte.com.cn> --- drivers/gpu/drm/nouveau/nvif/outp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvif/outp.c b/drivers/gpu/drm/nouveau/nvif/outp.c index 5d3190c05250..6daeb7f0b09b