Displaying 20 results from an estimated 100 matches similar to: "[PATCH 2/8] drm/nouveau/kms/nv50-: Remove (nv_encoder->crtc) checks in ->disable callbacks"
2020 Nov 14
0
[PATCH 8/8] drm/nouveau/kms/nv50-: Fix locking for audio callbacks
Noticed that I wasn't paying close enough attention the last time I looked
at our audio callbacks, as I completely missed the fact that we were
figuring out which audio-enabled connector goes to each encoder by checking
it's state, but without grabbing any of the appropriate modesetting locks
to do so.
That being said however: trying to grab modesetting locks in our audio
callbacks would
2020 Aug 07
4
[PATCH v2 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:
nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
This is magic nvidia speak for "You need to have the DMA notifier
2014 May 05
1
[PATCH] drm/nouveau/dp: restore DP suspend/resume functionality
On 5 May 2014 01:43, Ben Skeggs <skeggsb at gmail.com> wrote:
> On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote:
>> The following commit from about a year ago removed nouveau_dp_dpms() which
>> did steps required to suspend and resume a monitor connected via DisplayPort.
>>
>> commit 0a0afd282fd715dd63d64b243299a64da14f8e8d
2020 Sep 04
3
[PATCH v5 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:
nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
This is magic nvidia speak for "You need to have the DMA notifier
2014 May 04
0
[PATCH] drm/nouveau/dp: restore DP suspend/resume functionality
On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote:
> The following commit from about a year ago removed nouveau_dp_dpms() which
> did steps required to suspend and resume a monitor connected via DisplayPort.
>
> commit 0a0afd282fd715dd63d64b243299a64da14f8e8d
> Author: Ben Skeggs <bskeggs at redhat.com>
> Date: Mon Feb 18
2018 Feb 16
0
[PATCH] bl: fix backlight regression
fixes d9c0aadc5aa241df26ce8301d34a8418919fb5ae
Signed-off-by: Karol Herbst <kherbst at redhat.com>
---
drm/nouveau/nouveau_backlight.c | 7 +++++++
drm/nouveau/nv50_display.c | 4 ++--
drm/nouveau/nv50_display.h | 4 ++++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 380f3402..057708da
2019 Dec 06
2
[PATCH] drm/dp_mst: add missed nv50_outp_release in nv50_msto_disable
nv50_msto_disable() does not call nv50_outp_release() to match
nv50_outp_acquire() like other disable().
Add the missed call to fix it.
Signed-off-by: Chuhong Yuan <hslester96 at gmail.com>
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index
2019 Dec 12
0
[PATCH v2] drm/nouveau/dispnv50: add missed nv50_outp_release in nv50_msto_disable
nv50_msto_disable() does not call nv50_outp_release() to match
nv50_outp_acquire() like other disable().
Add the missed call to fix it.
Signed-off-by: Chuhong Yuan <hslester96 at gmail.com>
---
Changes in v2:
- Fix the subject prefix.
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
2019 Dec 12
0
[PATCH] drm/dp_mst: add missed nv50_outp_release in nv50_msto_disable
On Fri, 06 Dec 2019, Chuhong Yuan <hslester96 at gmail.com> wrote:
> nv50_msto_disable() does not call nv50_outp_release() to match
> nv50_outp_acquire() like other disable().
> Add the missed call to fix it.
The subject prefix "drm/dp_mst" implies drm core change, but this is
about nouveau. Please fix.
BR,
Jani.
>
> Signed-off-by: Chuhong Yuan <hslester96 at
2020 Sep 01
0
[PATCH v4] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:
nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
This is magic nvidia speak for "You need to have the DMA notifier
2020 Aug 06
3
[PATCH] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:
nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
This is magic nvidia speak for "You need to have the DMA notifier
2014 May 04
2
[PATCH] drm/nouveau/dp: restore DP suspend/resume functionality
The following commit from about a year ago removed nouveau_dp_dpms() which
did steps required to suspend and resume a monitor connected via DisplayPort.
commit 0a0afd282fd715dd63d64b243299a64da14f8e8d
Author: Ben Skeggs <bskeggs at redhat.com>
Date: Mon Feb 18 23:17:53 2013 -0500
drm/nv50-/disp: move DP link training to core and train from supervisor
My computer with
2020 Sep 01
3
[PATCH v3] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:
nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
This is magic nvidia speak for "You need to have the DMA notifier
2020 Nov 14
0
[PATCH 6/8] drm/nouveau/kms/nv50-: Lookup current encoder/crtc from atomic state
Despite being an atomic driver, nouveau has a lot of leftover code that
relies on retrieving information regarding the new atomic state from
members of drm_encoder and drm_crtc. The first field being used,
drm_encoder.crtc, is deprecated for atomic drivers. The second field being
used is drm_crtc.state, which is only really sensible to use outside of an
atomic modeset.
So, add some helpers to
2020 Aug 20
0
[RFC v2 06/20] drm/nouveau/kms: Search for encoders' connectors properly
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and
nv50_outp_get_new_connector().
v2:
* Don't
2020 Jan 13
0
[PATCH RESEND] drm/nouveau: Add HD-audio component notifier support
This patch adds the support for the notification of HD-audio hotplug
via the already existing drm_audio_component framework. This allows
us more reliable hotplug notification and ELD transfer without
accessing HD-audio bus; it's more efficient, and more importantly, it
works without waking up the runtime PM.
The implementation is rather simplistic: nouveau driver provides the
get_eld ops for
2017 Jan 17
0
[PATCH 2/6] drm/nouveau: Pass mode-dependent AVI and Vendor HDMI InfoFrames to NVKM
Now that we have mechanism by which to pass mode-dependent HDMI
InfoFrames to the low-level hardware driver, it is incumbent upon
us to do so.
Experimentation on a gt215 device suggests that the Audio InfoFrame
is not required here, possibly being provided by the HDA device
when necessary (because where else would it come from?).
Signed-off-by: Alastair Bridgewater <alastair.bridgewater at
2020 Apr 16
1
[PATCH] drm/nouveau: Fix regression by audio component transition
Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component
notifier support"), the nouveau driver notifies and pokes the HD-audio
HPD and ELD via audio component, but this seems broken. The culprit
is the naive assumption that crtc->index corresponds to the HDA pin.
Actually this rather corresponds to the MST dev_id (alias "pipe" in
the audio component framework)
2020 Aug 25
22
[RFC v4 00/20] drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915
Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's HPD related code has been collecting dust for a while.
Other then the occasional runtime PM related and MST related fixes,
we're missing a lot of nice things that have been added to DRM since
this was originally written. Additionally, the code
2020 Aug 20
22
[RFC v2 00/20] drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915
To start off: this patch series is less work to review then it looks -
most (but not all) of the nouveau related work has already been reviewed
elsewhere. Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's HPD related code has been collecting dust for a while.
Other then the occasional runtime PM