Re: [Nouveau] [Intel-gfx] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > > > Hi all,
> > > > >
> > > > > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst")
> > > > > was to
> > > > > "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's
> > > > > what this
> > > > > patch series is about.
> > > > >
> > > > > You will find two types of changes here:
> > > > >
> > > > > - Replacing "drm_modeset_lock_all_ctx()" (and surrounding
> > > > > boilerplate) with
> > > > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as
> > > > > it has
> > > > > already been done in previous commits such as b7ea04d2)
> > > > >
> > > > > - Replacing "drm_modeset_lock_all()" with
> > > > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> > > > > in the remaining places (as it has already been done in previous
> > > > > commits
> > > > > such as 57037094)
> > > > >
> > > > > Most of the changes are straight forward, except for a few cases in
> > > > > the "amd"
> > > > > and "i915" drivers where some extra dancing was needed to overcome the
> > > > > limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can
> > > > > only be used
> > > > > once inside the same function (the reason being that the macro
> > > > > expansion
> > > > > includes *labels*, and you can not have two labels named the same
> > > > > inside one
> > > > > function)
> > > > >
> > > > > Notice that, even after this patch series, some places remain where
> > > > > "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still
> > > > > present,
> > > > > all inside drm core (which makes sense), except for two (in "amd" and
> > > > > "i915")
> > > > > which cannot be replaced due to the way they are being used.
> > > > >
> > > > > Changes in v2:
> > > > >
> > > > > - Fix commit message typo
> > > > > - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
> > > > > - Split drm/i915 patch into two simpler ones
> > > > > - Remove drm_modeset_(un)lock_all()
> > > > > - Fix build problems in non-x86 platforms
> > > > >
> > > > > Fernando Ramos (17):
> > > > > drm: cleanup: drm_modeset_lock_all_ctx() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/i915: cleanup: drm_modeset_lock_all_ctx() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/msm: cleanup: drm_modeset_lock_all_ctx() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN() drm/vmwgfx: cleanup:
> > > > > drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/tegra: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/shmobile: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/radeon: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/nouveau: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/msm: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > > > > drm/gma500: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm/amd: cleanup: drm_modeset_lock_all() -->
> > > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > > drm: cleanup: remove drm_modeset_(un)lock_all()
> > > > > doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
> > > > >
> > > >
> > > > Thank you for revising, Fernando! I've pushed the set to drm-misc-next
> > > > (along
> > > > with the necessary drm-tip conflict resolutions).
> > >
> > > Ugh. Did anyone actually review the locking changes this does?
> > > I shot the previous i915 stuff down because the commit messages
> > > did not address any of it.
> >
> > I reviewed the set on 9/17, I didn't see your feedback on that thread.
>
> It was much earlir than that.
> https://lists.freedesktop.org/archives/dri-devel/2021-June/313193.html
>
> And I think I might have also shot down a similar thing earlier.
>
> I was actually half considering sending a patch to nuke that
> misleading TODO item. I don't think anything which changes
> which locks are taken should be considred a starter level task.
> And the commit messages here don't seem to address any of it.
And i915 is now broken :(
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10680/fi-bwr-2160/boot.html
--
Ville
[Nouveau] [PATCH] drm/nouveau:Fix gcc '-Wunused-but-set-variable' warnings:
drivers/gpu/drm/nouveau/nouveau_bo.c: In function 'nouveau_ttm_tt_populate':
drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable 'dev' set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c: In function 'nouveau_ttm_tt_unpopulate':
drivers/gpu/drm/nouveau/nouveau_bo.c:1274:17: warning: variable 'dev' set but
not used [-Wunused-but-set-variable]
Signed-off-by: Kai Song
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index d3b21d318b42..7f5a3a8eec9e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1249,7 +1249,6 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
{
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (ttm_tt_is_populated(ttm))
@@ -1262,7 +1261,6 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
}
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_alloc(&drm->ttm.bdev.pool, ttm, ctx);
}
@@ -1272,7 +1270,6 @@ nouveau_ttm_tt_unpopulate(struct ttm_device *bdev,
struct ttm_tt *ttm)
{
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (slave)
@@ -1281,7 +1278,6 @@ nouveau_ttm_tt_unpopulate(struct ttm_device *bdev,
nouveau_ttm_tt_unbind(bdev, ttm);
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_free(&drm->ttm.bdev.pool, ttm);
}
--
2.27.0
[Nouveau] Understanding BAR1 Offset to imem/VRAM PA Mapping
Hello, I'm trying to understand how VRAM PAs are mapped to BAR1 offsets on Fermi+, but I'm having difficulty digging through the abstractions in nouveau. I spent the better part of yesterday digging through the nv50_instobj_*() functions, but I lost track of which page tables are being modified and where they're coming from somewhere around level 7 of indirection/aliasing from the nvkm_kmap() call (aka nv50_instobj_acquire()) to the actual nvkm_vmm_iter() logic which I think does the mapping. If page tables are used to map BAR1 offsets to VRAM PAs on Fermi+, I'd like to understand their relation to the normal GPU VA to PA page tables, and how we tell the hardware which page tables to use for the BAR1 mappings. Best regards, Joshua Bakita PhD Student UNC Chapel Hill | Real-Time Systems Group
[Nouveau] Nvidia GeForce 8200M - Image flicker
Hi, I installed lubuntu 20.04 amd64 in my old laptop (Compaq CQ60-210 US), but the screen flicker when i open some program like firefox, i tried nvidia drivers to GeForce 8200M GPU, but no work to this hardware, i want to use nouveau drivers but need to fix the flicker problems. Can you help me with this? Thank you for any help you can provide. -- Oswaldo Graterol
[Nouveau] kmemleak report: 5.15.0-rc3: nouveau_fence_new
Hello, With 5.15.0-rc3 on my ppc64 (PowerMac G5) I am seeing kmemleak reports. They are always 96 bytes and with the same stacktrace. unreferenced object 0xc00011d2a7e0 (size 96): comm "X", pid 1743, jiffies 4295010075 (age 5457.040s) hex dump (first 32 bytes): c0 00 00 00 0b 9f f0 00 c0 00 3d 00 00 b0 85 90 ..=. 00 00 00 a9 77 41 30 23 c0 00 00 00 08 db b7 c8 wA0# backtrace: [<6f102108>] .nouveau_fence_new+0x4c/0x120 [nouveau] [<395e0a83>] .nouveau_bo_move+0x4f0/0x870 [nouveau] [] .ttm_bo_handle_move_mem+0xb4/0x1e0 [ttm] [ ] .ttm_bo_validate+0x144/0x230 [ttm] [ ] .nouveau_bo_validate+0x70/0xc0 [nouveau] [ ] .nouveau_gem_ioctl_pushbuf+0x6e0/0x1a90 [nouveau] [<7b7c5c38>] .drm_ioctl_kernel+0x104/0x180 [drm] [<0af76e30>] .drm_ioctl+0x244/0x490 [drm] [ ] .nouveau_drm_ioctl+0x78/0x140 [nouveau] [<263274a7>] .__se_sys_ioctl+0xfc/0x160 [<88c39f3d>] .system_call_exception+0x178/0x2a0 [<0cfdf34f>] system_call_common+0xec/0x250 If I decode this stacktrace using decode_stacktrace.sh so that the line numbers can be seen, I get the following: .nouveau_fence_new+0x4c/0x120 [nouveau] linux-5.15-rc3/include/linux/slab.h:591 linux-5.15-rc3/include/linux/slab.h:721 linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_fence.c:424 .nouveau_bo_move+0x4f0/0x870 [nouveau] linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_bo.c:821 linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_bo.c:1032 .ttm_bo_handle_move_mem+0xb4/0x1e0 [ttm] linux-5.15-rc3/drivers/gpu/drm/ttm/ttm_bo.c:197 .ttm_bo_validate+0x144/0x230 [ttm] linux-5.15-rc3/drivers/gpu/drm/ttm/ttm_bo.c:904 linux-5.15-rc3/drivers/gpu/drm/ttm/ttm_bo.c:981 .nouveau_bo_validate+0x70/0xc0 [nouveau] linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_bo.c:647 .nouveau_gem_ioctl_pushbuf+0x6e0/0x1a90 [nouveau] linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_gem.c:548 linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_gem.c:605 linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_gem.c:799 .drm_ioctl_kernel+0x104/0x180 [drm] linux-5.15-rc3/drivers/gpu/drm/drm_ioctl.c:795 .drm_ioctl+0x244/0x490 [drm] linux-5.15-rc3/include/linux/thread_info.h:185 linux-5.15-rc3/include/linux/thread_info.h:218 linux-5.15-rc3/include/linux/uaccess.h:199 linux-5.15-rc3/drivers/gpu/drm/drm_ioctl.c:899 .nouveau_drm_ioctl+0x78/0x140 [nouveau] linux-5.15-rc3/drivers/gpu/drm/nouveau/nouveau_drm.c:1163 .__se_sys_ioctl+0xfc/0x160 linux-5.15-rc3/fs/ioctl.c:51 linux-5.15-rc3/fs/ioctl.c:874 linux-5.15-rc3/fs/ioctl.c:860 .system_call_exception+0x178/0x2a0 .system_call_exception linux-5.15-rc3/arch/powerpc/kernel/interrupt.c:233 system_call_common+0xec/0x250 linux-5.15-rc3/arch/powerpc/kernel/interrupt_64.S:314 Here are all enabled DRM and NOUVEAU configs in my kernel: CONFIG_DRM=m CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_FBDEV_EMULATION=y CONFIG_DRM_FBDEV_OVERALLOC=100 CONFIG_DRM_TTM=m CONFIG_DRM_TTM_HELPER=m CONFIG_DRM_NOUVEAU=m CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3 CONFIG_DRM_NOUVEAU_BACKLIGHT=y CONFIG_DRM_PANEL=y CONFIG_DRM_BRIDGE=y CONFIG_DRM_PANEL_BRIDGE=y CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=m And lspci output: :f0:10.0 VGA compatible controller: NVIDIA Corporation NV34 [GeForce FX 5200 Ultra] (rev a1) I have been running 5.12 on my machine without these reports. So it might be something that showed up in 5.13 or 5.14 as well. I do not know if this is a good channel for reporting this, so please let me know if I should report it somewhere else. Also let me know if you need any additional information from me. John Ogness
Re: [Nouveau] [PATCH 2/3] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control
Hi,
On Mon, Sep 27, 2021 at 1:12 PM Lyude Paul wrote:
>
> @@ -3305,11 +3313,10 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
> * @bl: Backlight capability info from drm_edp_backlight_init()
> *
> * This function handles disabling DPCD backlight controls on a panel over
> AUX. Note that some
> - * panels have backlights that are enabled/disabled by other means, despite
> having their brightness
> - * values controlled through DPCD. On such panels
> &drm_edp_backlight_info.aux_enable will be set to
> - * %false, this function will become a no-op (and we will skip updating
> - * %DP_EDP_DISPLAY_CONTROL_REGISTER), and the driver must take care to
> perform it's own
> - * implementation specific step for disabling the backlight.
> + * panels have backlights that are enabled/disabled via PWM. On such panels
> + * &drm_edp_backlight_info.aux_enable will be set to %false, this function
> will become a no-op (and
> + * we will skip updating %DP_EDP_DISPLAY_CONTROL_REGISTER), and the driver
> must handle disabling the
> + * backlight via PWM.
I'm not sure I understand the comment above. You say "enabled/disabled
via PWM" and that doesn't make sense w/ my mental model. Normally I
think of a PWM allowing you to adjust the brightness and there being a
separate GPIO that's in charge of enable/disable. To some extent you
could think of a PWM as being "disabled" when its duty cycle is 0%,
but usually there's separate "enable" logic that really has nothing to
do with the PWM itself.
In general, it seems like the options are:
1. DPCD controls PWM and the "enable" logic.
2. DPCD controls PWM but requires an external "enable" GPIO.
3. We require an external PWM but DPCD controls the "enable" logic.
Maybe you need a second "capability" to describe whether the client of
your code knows how to control an enable GPIO? ...or perhaps better
you don't need a capability and you can just assume that if the client
needs to set an "enable" GPIO that it will do so. That would match how
things work today. AKA:
a) Client calls the AUX backlight code to "enable"
b) AUX backlight code will set the "enable" bit if supported.
c) Client will set the "enable" GPIO if it knows about one.
Presumably only one of b) or c) will actually do something. If neither
does something then this panel simply isn't compatible with this
board.
> +/**
> + * drm_edp_backlight_supported() - Check an eDP DPCD for VESA backlight
> support
> + * @aux: The AUX channel, only used for debug logging
> + * @edp_dpcd: The DPCD to check
> + * @caps: The backlight capabilities this driver supports
> + *
> + * Returns: %True if @edp_dpcd indicates that VESA backlight controls are
> supported, %false
> + * otherwise
> + */
> +bool drm_edp_backlight_supported(struct drm_dp_aux *aux,
> +const u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE],
> +enum drm_edp_backlight_driver_caps caps)
> +{
> + if (!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP))
> + return false;
> +
> + if (!(caps & DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM) &&
> + (!(edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) ||
> +!(edp_dpcd[2] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))) {
Elsewhere you match DP_EDP_BACKLIGHT_AUX_ENABLE_CAP against
edp_dpcd[1]. Here you match against [2]. Are you sure that's correct?
> /*
> * DisplayPort AUX channel
> */
> @@ -2200,7 +2182,11 @@ drm_dp_has_quirk(const struct drm_dp_desc *desc, enum
> drm_dp_quirk quirk)
> * @pwm_freq_pre_divider: The PWM frequency pre-divider value being used for
> this backlight, if any
> * @max: The maximum backlight level that may be set
> * @lsb_reg_used: Do we also write values to the
> DP_EDP_BACKLIGHT_BRIGHTNESS_LSB register?
> - * @aux_enable: Does the panel support the AUX enable cap?
> + * @aux_enable: Does the panel support the AUX enable cap? Always %false
> when the driver doesn't
> + * support %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM
Why is aux_enable always false if it doesn't support
DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM? It doesn't seem like the code
enforces this and I'm not sure why it would. Am I confused?
Re: [Nouveau] EVoC Proposal: REclock - Reverse-engineer and implement NVA3/5/8 Voltage- and Frequency Scaling in Nouveau
[Nouveau] [PATCH v2 3/4] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control
Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.
Note however that we still don't enable using this by default on i915 when
it's not needed, primarily because I haven't yet had a chance to confirm if
it's safe to do this on the one machine in Intel's CI that had an issue
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.
v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps
Signed-off-by: Lyude Paul
Cc: Rajeev Nandan
Cc: Doug Anderson
Cc: Satadru Pramanik
---
drivers/gpu/drm/drm_dp_helper.c | 75 +--
.../drm/i915/display/intel_dp_aux_backlight.c | 48 +---
include/drm/drm_dp_helper.h | 7 +-
3 files changed, 93 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4d0d1e8e51fa..f350e17a80e7 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3173,6 +3173,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux,
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
+ /* The panel uses the PWM for controlling brightness levels */
+ if (!bl->aux_set)
+ return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3199,7 +3203,7 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
int ret;
u8 buf;
- /* The panel uses something other then DPCD for enabling its backlight
*/
+ /* This panel uses the EDP_BL_PWR GPIO for enablement */
if (!bl->aux_enable)
return 0;
@@ -3234,11 +3238,11 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
* restoring any important backlight state such as the given backlight level,
the brightness byte
* count, backlight frequency, etc.
*
- * Note that certain panels, while supporting brightness level controls over
DPCD, may not support
- * having their backlights enabled via the standard
%DP_EDP_DISPLAY_CONTROL_REGISTER. On such panels
- * &drm_edp_backlight_info.aux_enable will be set to %false, this function
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must
perform the required
- * implementation specific step for enabling the backlight after calling this
function.
+ * Note that certain panels do not support being enabled or disabled via DPCD,
but instead require
+ * that the driver handle enabling/disabling the panel through
implementation-specific means using
+ * the EDP_BL_PWR GPIO. For such panels, &drm_edp_backlight_info.aux_enable
will be set to %false,
+ * this function becomes a no-op, and the driver is expected to handle
powering the panel on using
+ * the EDP_BL_PWR GPIO.
*
* Returns: %0 on success, negative error code on failure.
*/
@@ -3246,7 +3250,7 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
const u16 level)
{
int ret;
- u8 dpcd_buf, new_dpcd_buf;
+ u8 dpcd_buf, new_dpcd_buf, new_mode;
ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
&dpcd_buf);
if (ret != 1) {
@@ -3256,10 +3260,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
}
new_dpcd_buf = dpcd_buf;
+ if (bl->aux_set)
+ new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+ else
+ new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
- if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+ if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != new_mode) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
- new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+ new_dpcd_buf |= new_mode;
if (bl->pwmgen_bit_count) {
ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT,
bl->pwmgen_bit_count);
@@ -3304,12 +3312,13 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
* @aux: The DP AUX channel to use
* @bl: Backlight capability info from drm_edp_backlight_init()
*
- * This function handles disabling DPCD backlight controls on a panel over
AUX. Note that some
- * panels have backlights that are enabled/disabled by other means, despite
having their brightness
- * values controlled through DPCD. On such panels
&drm_edp_backlight_info.aux_enable will be set to
- * %false, th
[Nouveau] [PATCH v2 4/4] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.
So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 91daf9ab50e8..04a52d6a74ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -455,11 +455,17 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
}
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will
always use the VESA
+* interface. This means that there's quite a number of panels out
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise
support for both
+* interfaces, the VESA backlight interface will stop working once
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to
detect Intel's
+* backlight interface at all. This means that the only sensible way
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
*/
if (try_intel_interface &&
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight
controls\n");
--
2.31.1
[Nouveau] [PATCH v2 1/4] drm/i915: Add support for panels with VESA backlights with PWM enable/disable
This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.
For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.
Signed-off-by: Lyude Paul
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
enable/disable")
Cc: # v5.12+
---
.../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 569d17b4d00f..594fdc7453ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
+ if (!panel->backlight.edp.vesa.info.aux_enable)
+ panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
+
panel->backlight.pwm_level_max);
+
drm_edp_backlight_enable(&intel_dp->aux,
&panel->backlight.edp.vesa.info, level);
}
@@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
drm_edp_backlight_disable(&intel_dp->aux,
&panel->backlight.edp.vesa.info);
+
+ if (!panel->backlight.edp.vesa.info.aux_enable)
+ panel->backlight.pwm_funcs->disable(old_conn_state,
+
intel_backlight_invert_pwm_level(connector, 0));
}
static int intel_dp_aux_vesa_setup_backlight(struct intel_connector
*connector, enum pipe pipe)
@@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct
intel_connector *connector,
if (ret < 0)
return ret;
+ if (!panel->backlight.edp.vesa.info.aux_enable) {
+ ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+ if (ret < 0) {
+ drm_err(&i915->drm,
+ "Failed to setup PWM backlight controls for eDP
backlight: %d\n",
+ ret);
+ return ret;
+ }
+ }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- /* TODO: We currently only support AUX only backlight configurations,
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time,
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
- if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
- drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+ if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(&i915->drm, "AUX Backlight Control Supported!\n");
return true;
}
--
2.31.1
[Nouveau] [PATCH v2 2/4] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 1cbd71abc80a..ae2f2abc8f5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -308,7 +308,10 @@ nv50_backlight_init(struct nouveau_backlight *bl,
if (ret < 0)
return ret;
- if (drm_edp_backlight_supported(edp_dpcd)) {
+ /* TODO: Add support for hybrid PWM/DPCD panels */
+ if (drm_edp_backlight_supported(edp_dpcd) &&
+ (edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+ (edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
NV_DEBUG(drm, "DPCD backlight controls supported on
%s\n",
nv_conn->base.name);
--
2.31.1
[Nouveau] [PATCH v2 0/4] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
When I originally moved all of the VESA backlight code in i915 into DRM helpers, one of the things I didn't have the hardware or time for testing was machines that used a combination of PWM and DPCD in order to control their backlights. This has since then caused some breakages and resulted in us disabling DPCD backlight support on such machines. This works fine, unless you have a machine that actually needs this functionality for backlight controls to work at all. Additionally, we will need to support PWM for when we start adding support for VESA's product (as in the product of multiplication) control mode for better brightness ranges. So - let's finally finish up implementing basic support for these types of backlights to solve these problems in our DP helpers, along with implementing support for this in i915. And since digging into this issue solved the last questions we really had about probing backlights in i915 for the most part, let's update some of the comments around that as well! Changes: * Fixup docs * Add patch to stop us from breaking nouveau Lyude Paul (4): drm/i915: Add support for panels with VESA backlights with PWM enable/disable drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs() drivers/gpu/drm/drm_dp_helper.c | 75 +++-- .../drm/i915/display/intel_dp_aux_backlight.c | 80 ++- drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +- include/drm/drm_dp_helper.h | 7 +- 4 files changed, 122 insertions(+), 45 deletions(-) -- 2.31.1
Re: [Nouveau] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > > Hi all,
> > > >
> > > > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst")
> > > > was to
> > > > "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's
> > > > what this
> > > > patch series is about.
> > > >
> > > > You will find two types of changes here:
> > > >
> > > > - Replacing "drm_modeset_lock_all_ctx()" (and surrounding
> > > > boilerplate) with
> > > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it
> > > > has
> > > > already been done in previous commits such as b7ea04d2)
> > > >
> > > > - Replacing "drm_modeset_lock_all()" with
> > > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> > > > in the remaining places (as it has already been done in previous
> > > > commits
> > > > such as 57037094)
> > > >
> > > > Most of the changes are straight forward, except for a few cases in the
> > > > "amd"
> > > > and "i915" drivers where some extra dancing was needed to overcome the
> > > > limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only
> > > > be used
> > > > once inside the same function (the reason being that the macro expansion
> > > > includes *labels*, and you can not have two labels named the same
> > > > inside one
> > > > function)
> > > >
> > > > Notice that, even after this patch series, some places remain where
> > > > "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still
> > > > present,
> > > > all inside drm core (which makes sense), except for two (in "amd" and
> > > > "i915")
> > > > which cannot be replaced due to the way they are being used.
> > > >
> > > > Changes in v2:
> > > >
> > > > - Fix commit message typo
> > > > - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
> > > > - Split drm/i915 patch into two simpler ones
> > > > - Remove drm_modeset_(un)lock_all()
> > > > - Fix build problems in non-x86 platforms
> > > >
> > > > Fernando Ramos (17):
> > > > drm: cleanup: drm_modeset_lock_all_ctx() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/i915: cleanup: drm_modeset_lock_all_ctx() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/msm: cleanup: drm_modeset_lock_all_ctx() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/vmwgfx: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/tegra: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/shmobile: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/radeon: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/nouveau: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/msm: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > > > drm/gma500: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm/amd: cleanup: drm_modeset_lock_all() -->
> > > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > > drm: cleanup: remove drm_modeset_(un)lock_all()
> > > > doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
> > > >
> > >
> > > Thank you for revising, Fernando! I've pushed the set to drm-misc-next
> > > (along
> > > with the necessary drm-tip conflict resolutions).
> >
> > Ugh. Did anyone actually review the locking changes this does?
> > I shot the previous i915 stuff down because the commit messages
> > did not address any of it.
>
> I reviewed the set on 9/17, I didn't see your feedback on that thread.
It was much earlir than that.
https://lists.freedesktop.org/archives/dri-devel/2021-June/313193.html
And I think I might have also shot down a similar thing earlier.
I was actually half considering sending a patch to nuke that
misleading TODO item. I don't think anything which changes
which locks are taken should be considred a starter level task.
And the commit messages here don't seem to address any of it.
--
Ville Syrjälä
Intel
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 4:56 PM Jerry Geis wrote: > > > > On Fri, Oct 1, 2021 at 4:48 PM Jerry Geis wrote: >> >> >> >> On Fri, Oct 1, 2021 at 4:41 PM Ilia Mirkin wrote: >>> >>> On Fri, Oct 1, 2021 at 4:29 PM Jerry Geis wrote: >>> > yes very weird on the sound. Using analog speakers at the moment >>> > I got no test sound - and no video sound after getting nouveau to run >>> > correctly >>> > I was playing analog audio before ? >>> > Does nouveau only do HDMI audio ? >>> >>> nouveau only does HDMI(/DP) audio. A different driver will handle a >>> built-in sound card (e.g. snd_hda_intel). You might want to reach out >>> to your distro's support channels to better diagnose what's going on. >>> Unlikely to have anything to do with nouveau. More likely that you had >>> added "acpi=off" to hack around this. Or perhaps pci=nomsi for a >>> broken audio adapter? Don't know. dmesg (not to mention google) will >>> have the answers. >>> >>> -ilia >> >> >> Thanks - I switched monitors - using a 4K monitor with buildin sound. >> Sound works now- great. but the screen is not in 4K . >> Does Nouveau not do 4K - 3840x2160? >> >> Thanks! >> >> Jerry > > > HA! I just dawned on my the OLD GT218 does not do 4K... The 4K display looks > like a strched for some reason - I thought it would jus tbe the normal 1080p. > Anyway - got it working - thanks to all the suggestions! We enforce a max of 165mhz on those boards for HDMI (this is what the HW is rated for). If you feel like forcing it, you can boot with nouveau.hdmimhz=300 to allow the 4k resolution. Note that it's a weaker GPU, and 4k will not be great on it anyways. -ilia
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 4:48 PM Jerry Geis wrote: > > > On Fri, Oct 1, 2021 at 4:41 PM Ilia Mirkin wrote: > >> On Fri, Oct 1, 2021 at 4:29 PM Jerry Geis wrote: >> > yes very weird on the sound. Using analog speakers at the moment >> > I got no test sound - and no video sound after getting nouveau to run >> correctly >> > I was playing analog audio before ? >> > Does nouveau only do HDMI audio ? >> >> nouveau only does HDMI(/DP) audio. A different driver will handle a >> built-in sound card (e.g. snd_hda_intel). You might want to reach out >> to your distro's support channels to better diagnose what's going on. >> Unlikely to have anything to do with nouveau. More likely that you had >> added "acpi=off" to hack around this. Or perhaps pci=nomsi for a >> broken audio adapter? Don't know. dmesg (not to mention google) will >> have the answers. >> >> -ilia >> > > Thanks - I switched monitors - using a 4K monitor with buildin sound. > Sound works now- great. but the screen is not in 4K . > Does Nouveau not do 4K - 3840x2160? > > Thanks! > > Jerry > HA! I just dawned on my the OLD GT218 does not do 4K... The 4K display looks like a strched for some reason - I thought it would jus tbe the normal 1080p. Anyway - got it working - thanks to all the suggestions! Jerry
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 4:41 PM Ilia Mirkin wrote: > On Fri, Oct 1, 2021 at 4:29 PM Jerry Geis wrote: > > yes very weird on the sound. Using analog speakers at the moment > > I got no test sound - and no video sound after getting nouveau to run > correctly > > I was playing analog audio before ? > > Does nouveau only do HDMI audio ? > > nouveau only does HDMI(/DP) audio. A different driver will handle a > built-in sound card (e.g. snd_hda_intel). You might want to reach out > to your distro's support channels to better diagnose what's going on. > Unlikely to have anything to do with nouveau. More likely that you had > added "acpi=off" to hack around this. Or perhaps pci=nomsi for a > broken audio adapter? Don't know. dmesg (not to mention google) will > have the answers. > > -ilia > Thanks - I switched monitors - using a 4K monitor with buildin sound. Sound works now- great. but the screen is not in 4K . Does Nouveau not do 4K - 3840x2160? Thanks! Jerry
Re: [Nouveau] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > Hi all,
> > >
> > > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was
> > > to
> > > "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what
> > > this
> > > patch series is about.
> > >
> > > You will find two types of changes here:
> > >
> > > - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate)
> > > with
> > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it
> > > has
> > > already been done in previous commits such as b7ea04d2)
> > >
> > > - Replacing "drm_modeset_lock_all()" with
> > > "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> > > in the remaining places (as it has already been done in previous
> > > commits
> > > such as 57037094)
> > >
> > > Most of the changes are straight forward, except for a few cases in the
> > > "amd"
> > > and "i915" drivers where some extra dancing was needed to overcome the
> > > limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be
> > > used
> > > once inside the same function (the reason being that the macro expansion
> > > includes *labels*, and you can not have two labels named the same inside
> > > one
> > > function)
> > >
> > > Notice that, even after this patch series, some places remain where
> > > "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still
> > > present,
> > > all inside drm core (which makes sense), except for two (in "amd" and
> > > "i915")
> > > which cannot be replaced due to the way they are being used.
> > >
> > > Changes in v2:
> > >
> > > - Fix commit message typo
> > > - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
> > > - Split drm/i915 patch into two simpler ones
> > > - Remove drm_modeset_(un)lock_all()
> > > - Fix build problems in non-x86 platforms
> > >
> > > Fernando Ramos (17):
> > > drm: cleanup: drm_modeset_lock_all_ctx() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/i915: cleanup: drm_modeset_lock_all_ctx() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/msm: cleanup: drm_modeset_lock_all_ctx() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/vmwgfx: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/tegra: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/shmobile: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/radeon: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/nouveau: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/msm: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/i915: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > > drm/gma500: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm/amd: cleanup: drm_modeset_lock_all() -->
> > > DRM_MODESET_LOCK_ALL_BEGIN()
> > > drm: cleanup: remove drm_modeset_(un)lock_all()
> > > doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
> > >
> >
> > Thank you for revising, Fernando! I've pushed the set to drm-misc-next
> > (along
> > with the necessary drm-tip conflict resolutions).
>
> Ugh. Did anyone actually review the locking changes this does?
> I shot the previous i915 stuff down because the commit messages
> did not address any of it.
I reviewed the set on 9/17, I didn't see your feedback on that thread.
Sean
>
> --
> Ville Syrjälä
> Intel
--
Sean Paul, Software Engineer, Google / Chromium OS
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 4:29 PM Jerry Geis wrote: > yes very weird on the sound. Using analog speakers at the moment > I got no test sound - and no video sound after getting nouveau to run > correctly > I was playing analog audio before ? > Does nouveau only do HDMI audio ? nouveau only does HDMI(/DP) audio. A different driver will handle a built-in sound card (e.g. snd_hda_intel). You might want to reach out to your distro's support channels to better diagnose what's going on. Unlikely to have anything to do with nouveau. More likely that you had added "acpi=off" to hack around this. Or perhaps pci=nomsi for a broken audio adapter? Don't know. dmesg (not to mention google) will have the answers. -ilia
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 4:15 PM Ilia Mirkin wrote: > On Fri, Oct 1, 2021 at 3:58 PM Jerry Geis wrote: > > > > > > > > On Fri, Oct 1, 2021 at 3:40 PM Ilia Mirkin wrote: > >> > >> On Fri, Oct 1, 2021 at 3:36 PM Jerry Geis wrote: > >> > > >> > > >> > > >> > On Fri, Oct 1, 2021 at 3:27 PM Jerry Geis > wrote: > >> >> > >> >> > >> >> > >> >> On Fri, Oct 1, 2021 at 3:20 PM Ilia Mirkin > wrote: > >> >>> > >> >>> On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis > wrote: > >> >>> > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin > wrote: > >> >>> >> > >> >>> >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis > wrote: > >> >>> >> > lsmod | grep nouveau > >> >>> >> > > >> >>> >> > What dont I have ? > >> >>> >> > >> >>> >> nouveau :) > >> >>> >> > >> >>> >> Other than that, you got everything... > >> >>> >> > >> >>> >> Check dmesg for errors. > >> >>> >> > >> >>> >> Cheers, > >> >>> >> > >> >>> >> -ilia > >> >>> > > >> >>> > > >> >>> > I see this: > >> >>> > Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: > (==) Matched nouveau as autoconfigured driver 0 > >> >>> > >> >>> This is not dmesg. This is some log file. Please look in dmesg. > >> >>> > >> >>> > Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: > (**) VESA(0): Using "Shadow Framebuffer" > >> >>> > >> >>> X is using the VESA driver because nouveau (nor any other DRM > driver) is loaded. > >> >>> > >> >>> > > >> >>> > So it seems like its loading but perhaps its not happy > >> >>> > > >> >>> > What do I do ? > >> >>> > >> >>> Check dmesg for why nouveau didn't load. > >> >>> > >> >>> -ilia > >> >> > >> >> > >> >> grep -i nouveau /var/log/dmesg > >> >> [ 19.934733] kernel: fb0: switching to nouveaufb from VESA VGA > >> >> [ 20.013197] kernel: nouveau :03:00.0: vgaarb: deactivate vga > console > >> >> [ 20.013415] kernel: nouveau :03:00.0: NVIDIA GT218 (0a8200b1) > >> >> [ 20.159472] kernel: nouveau :03:00.0: bios: version > 70.18.45.00.00 > >> >> [ 20.162603] kernel: nouveau :03:00.0: fb: 512 MiB DDR3 > >> >> [ 21.552858] kernel: nouveau :03:00.0: DRM: VRAM: 512 MiB > >> >> [ 21.552873] kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB > >> >> [ 21.552888] kernel: nouveau :03:00.0: DRM: TMDS table version > 2.0 > >> >> [ 21.552900] kernel: nouveau :03:00.0: DRM: DCB version 4.0 > >> >> [ 21.552911] kernel: nouveau :03:00.0: DRM: DCB outp 00: > 01000302 0030 > >> >> [ 21.552924] kernel: nouveau :03:00.0: DRM: DCB outp 01: > 02000300 > >> >> [ 21.552937] kernel: nouveau :03:00.0: DRM: DCB outp 02: > 02011362 00020010 > >> >> [ 21.552950] kernel: nouveau :03:00.0: DRM: DCB conn 00: > 1030 > >> >> [ 21.552961] kernel: nouveau :03:00.0: DRM: DCB conn 01: > 2161 > >> >> [ 21.568834] kernel: nouveau :03:00.0: DRM: MM: using COPY for > buffer copies > >> >> [ 21.645206] kernel: nouveau :03:00.0: DRM: allocated > 1920x1080 fb: 0x7, bo (ptrval) > >> >> [ 21.648681] kernel: fbcon: nouveaudrmfb (fb0) is primary device > >> >> [ 21.837701] kernel: nouveau :03:00.0: [drm] fb0: nouveaudrmfb > frame buffer device > >> >> [ 21.873290] kernel: [drm] Initialized nouveau 1.3.1 20120801 for > :03:00.0 on minor 0 > >> > >> I was looking for you to just run "dmesg", BTW, not read a log file. > >> > >> >> > >> >> lsmod | grep nouveau > >> >> nouveau 1986560 30 > >> >> mxm_wmi16384 1 nouveau > >> >> i2c_algo_bit 16384 1 nouveau > >> >> drm_ttm_helper 16384 1 nouveau > >> >> ttm73728 2 drm_ttm_helper,nouveau > >> >> drm_kms_helper237568 1 nouveau > >> >> drm 548864 25 > drm_kms_helper,drm_ttm_helper,ttm,nouveau > >> >> video 53248 1 nouveau > >> >> wmi32768 2 mxm_wmi,nouveau > >> >> > >> >> I took off ALL extra kernel command paramters - nothing specific to > nouveau - and I got better results. however - video is still dropping > frames. > >> > >> Perhaps you had a "nomodeset" in there? That would prevent nouveau > >> from doing anything useful, although I think it'd still load in that > >> case. > >> > >> >> > >> >> So progress. but still no good. > >> > >> Check xorg log to make sure you see NOUVEAU lines, not modeset lines. > >> If you see modeset lines, make sure you force the nouveau DDX driver > >> to load. (Some distros think it's funny to prevent it from loading by > >> default...) > >> > >> >> > >> >> Jerry > >> > > >> > > >> > I see this error: > >> > nouveau :03:00.0: Direct firmware load for nouveau/nva8_fuc084 > failed > >> > > >> > I did apt-file search nva8_fuc084 > >> > and it did not return anything. > >> > >> This is for video decoding acceleration (vdpau / va-api). You can set > >> this up by following the instructions at > >> https://nouveau.freedesktop.org/VideoAcceleration.html . Note that > >> it's hardly perfect. > >> > >> Cheers, > >> > >> -ilia > > >
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 3:58 PM Jerry Geis wrote: > > > > On Fri, Oct 1, 2021 at 3:40 PM Ilia Mirkin wrote: >> >> On Fri, Oct 1, 2021 at 3:36 PM Jerry Geis wrote: >> > >> > >> > >> > On Fri, Oct 1, 2021 at 3:27 PM Jerry Geis wrote: >> >> >> >> >> >> >> >> On Fri, Oct 1, 2021 at 3:20 PM Ilia Mirkin wrote: >> >>> >> >>> On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis wrote: >> >>> > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin >> >>> > wrote: >> >>> >> >> >>> >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis >> >>> >> wrote: >> >>> >> > lsmod | grep nouveau >> >>> >> > >> >>> >> > What dont I have ? >> >>> >> >> >>> >> nouveau :) >> >>> >> >> >>> >> Other than that, you got everything... >> >>> >> >> >>> >> Check dmesg for errors. >> >>> >> >> >>> >> Cheers, >> >>> >> >> >>> >> -ilia >> >>> > >> >>> > >> >>> > I see this: >> >>> > Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) >> >>> > Matched nouveau as autoconfigured driver 0 >> >>> >> >>> This is not dmesg. This is some log file. Please look in dmesg. >> >>> >> >>> > Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) >> >>> > VESA(0): Using "Shadow Framebuffer" >> >>> >> >>> X is using the VESA driver because nouveau (nor any other DRM driver) is >> >>> loaded. >> >>> >> >>> > >> >>> > So it seems like its loading but perhaps its not happy >> >>> > >> >>> > What do I do ? >> >>> >> >>> Check dmesg for why nouveau didn't load. >> >>> >> >>> -ilia >> >> >> >> >> >> grep -i nouveau /var/log/dmesg >> >> [ 19.934733] kernel: fb0: switching to nouveaufb from VESA VGA >> >> [ 20.013197] kernel: nouveau :03:00.0: vgaarb: deactivate vga >> >> console >> >> [ 20.013415] kernel: nouveau :03:00.0: NVIDIA GT218 (0a8200b1) >> >> [ 20.159472] kernel: nouveau :03:00.0: bios: version 70.18.45.00.00 >> >> [ 20.162603] kernel: nouveau :03:00.0: fb: 512 MiB DDR3 >> >> [ 21.552858] kernel: nouveau :03:00.0: DRM: VRAM: 512 MiB >> >> [ 21.552873] kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB >> >> [ 21.552888] kernel: nouveau :03:00.0: DRM: TMDS table version 2.0 >> >> [ 21.552900] kernel: nouveau :03:00.0: DRM: DCB version 4.0 >> >> [ 21.552911] kernel: nouveau :03:00.0: DRM: DCB outp 00: 01000302 >> >> 0030 >> >> [ 21.552924] kernel: nouveau :03:00.0: DRM: DCB outp 01: 02000300 >> >> >> >> [ 21.552937] kernel: nouveau :03:00.0: DRM: DCB outp 02: 02011362 >> >> 00020010 >> >> [ 21.552950] kernel: nouveau :03:00.0: DRM: DCB conn 00: 1030 >> >> [ 21.552961] kernel: nouveau :03:00.0: DRM: DCB conn 01: 2161 >> >> [ 21.568834] kernel: nouveau :03:00.0: DRM: MM: using COPY for >> >> buffer copies >> >> [ 21.645206] kernel: nouveau :03:00.0: DRM: allocated 1920x1080 fb: >> >> 0x7, bo (ptrval) >> >> [ 21.648681] kernel: fbcon: nouveaudrmfb (fb0) is primary device >> >> [ 21.837701] kernel: nouveau :03:00.0: [drm] fb0: nouveaudrmfb >> >> frame buffer device >> >> [ 21.873290] kernel: [drm] Initialized nouveau 1.3.1 20120801 for >> >> :03:00.0 on minor 0 >> >> I was looking for you to just run "dmesg", BTW, not read a log file. >> >> >> >> >> lsmod | grep nouveau >> >> nouveau 1986560 30 >> >> mxm_wmi16384 1 nouveau >> >> i2c_algo_bit 16384 1 nouveau >> >> drm_ttm_helper 16384 1 nouveau >> >> ttm73728 2 drm_ttm_helper,nouveau >> >> drm_kms_helper237568 1 nouveau >> >> drm 548864 25 drm_kms_helper,drm_ttm_helper,ttm,nouveau >> >> video 53248 1 nouveau >> >> wmi32768 2 mxm_wmi,nouveau >> >> >> >> I took off ALL extra kernel command paramters - nothing specific to >> >> nouveau - and I got better results. however - video is still dropping >> >> frames. >> >> Perhaps you had a "nomodeset" in there? That would prevent nouveau >> from doing anything useful, although I think it'd still load in that >> case. >> >> >> >> >> So progress. but still no good. >> >> Check xorg log to make sure you see NOUVEAU lines, not modeset lines. >> If you see modeset lines, make sure you force the nouveau DDX driver >> to load. (Some distros think it's funny to prevent it from loading by >> default...) >> >> >> >> >> Jerry >> > >> > >> > I see this error: >> > nouveau :03:00.0: Direct firmware load for nouveau/nva8_fuc084 failed >> > >> > I did apt-file search nva8_fuc084 >> > and it did not return anything. >> >> This is for video decoding acceleration (vdpau / va-api). You can set >> this up by following the instructions at >> https://nouveau.freedesktop.org/VideoAcceleration.html . Note that >> it's hardly perfect. >> >> Cheers, >> >> -ilia > > > These were the kernel command line items I removed. > acpi=off pci=nomsi Oh dear. Esp acpi=off is very bad for any post-2010 machine. (The cut-off is probably earlier, but def by 2010, ACPI is basically required for thing
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 3:40 PM Ilia Mirkin wrote: > On Fri, Oct 1, 2021 at 3:36 PM Jerry Geis wrote: > > > > > > > > On Fri, Oct 1, 2021 at 3:27 PM Jerry Geis wrote: > >> > >> > >> > >> On Fri, Oct 1, 2021 at 3:20 PM Ilia Mirkin > wrote: > >>> > >>> On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis > wrote: > >>> > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin > wrote: > >>> >> > >>> >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis > wrote: > >>> >> > lsmod | grep nouveau > >>> >> > > >>> >> > What dont I have ? > >>> >> > >>> >> nouveau :) > >>> >> > >>> >> Other than that, you got everything... > >>> >> > >>> >> Check dmesg for errors. > >>> >> > >>> >> Cheers, > >>> >> > >>> >> -ilia > >>> > > >>> > > >>> > I see this: > >>> > Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) > Matched nouveau as autoconfigured driver 0 > >>> > >>> This is not dmesg. This is some log file. Please look in dmesg. > >>> > >>> > Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) > VESA(0): Using "Shadow Framebuffer" > >>> > >>> X is using the VESA driver because nouveau (nor any other DRM driver) > is loaded. > >>> > >>> > > >>> > So it seems like its loading but perhaps its not happy > >>> > > >>> > What do I do ? > >>> > >>> Check dmesg for why nouveau didn't load. > >>> > >>> -ilia > >> > >> > >> grep -i nouveau /var/log/dmesg > >> [ 19.934733] kernel: fb0: switching to nouveaufb from VESA VGA > >> [ 20.013197] kernel: nouveau :03:00.0: vgaarb: deactivate vga > console > >> [ 20.013415] kernel: nouveau :03:00.0: NVIDIA GT218 (0a8200b1) > >> [ 20.159472] kernel: nouveau :03:00.0: bios: version > 70.18.45.00.00 > >> [ 20.162603] kernel: nouveau :03:00.0: fb: 512 MiB DDR3 > >> [ 21.552858] kernel: nouveau :03:00.0: DRM: VRAM: 512 MiB > >> [ 21.552873] kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB > >> [ 21.552888] kernel: nouveau :03:00.0: DRM: TMDS table version 2.0 > >> [ 21.552900] kernel: nouveau :03:00.0: DRM: DCB version 4.0 > >> [ 21.552911] kernel: nouveau :03:00.0: DRM: DCB outp 00: 01000302 > 0030 > >> [ 21.552924] kernel: nouveau :03:00.0: DRM: DCB outp 01: 02000300 > > >> [ 21.552937] kernel: nouveau :03:00.0: DRM: DCB outp 02: 02011362 > 00020010 > >> [ 21.552950] kernel: nouveau :03:00.0: DRM: DCB conn 00: 1030 > >> [ 21.552961] kernel: nouveau :03:00.0: DRM: DCB conn 01: 2161 > >> [ 21.568834] kernel: nouveau :03:00.0: DRM: MM: using COPY for > buffer copies > >> [ 21.645206] kernel: nouveau :03:00.0: DRM: allocated 1920x1080 > fb: 0x7, bo (ptrval) > >> [ 21.648681] kernel: fbcon: nouveaudrmfb (fb0) is primary device > >> [ 21.837701] kernel: nouveau :03:00.0: [drm] fb0: nouveaudrmfb > frame buffer device > >> [ 21.873290] kernel: [drm] Initialized nouveau 1.3.1 20120801 for > :03:00.0 on minor 0 > > I was looking for you to just run "dmesg", BTW, not read a log file. > > >> > >> lsmod | grep nouveau > >> nouveau 1986560 30 > >> mxm_wmi16384 1 nouveau > >> i2c_algo_bit 16384 1 nouveau > >> drm_ttm_helper 16384 1 nouveau > >> ttm73728 2 drm_ttm_helper,nouveau > >> drm_kms_helper237568 1 nouveau > >> drm 548864 25 > drm_kms_helper,drm_ttm_helper,ttm,nouveau > >> video 53248 1 nouveau > >> wmi32768 2 mxm_wmi,nouveau > >> > >> I took off ALL extra kernel command paramters - nothing specific to > nouveau - and I got better results. however - video is still dropping > frames. > > Perhaps you had a "nomodeset" in there? That would prevent nouveau > from doing anything useful, although I think it'd still load in that > case. > > >> > >> So progress. but still no good. > > Check xorg log to make sure you see NOUVEAU lines, not modeset lines. > If you see modeset lines, make sure you force the nouveau DDX driver > to load. (Some distros think it's funny to prevent it from loading by > default...) > > >> > >> Jerry > > > > > > I see this error: > > nouveau :03:00.0: Direct firmware load for nouveau/nva8_fuc084 failed > > > > I did apt-file search nva8_fuc084 > > and it did not return anything. > > This is for video decoding acceleration (vdpau / va-api). You can set > this up by following the instructions at > https://nouveau.freedesktop.org/VideoAcceleration.html . Note that > it's hardly perfect. > > Cheers, > > -ilia > These were the kernel command line items I removed. acpi=off pci=nomsi The machine seems happier - now - althought I no longer have sound for some reason - but after installing the firmware - CPU % is way down. Thanks Jerry
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 3:36 PM Jerry Geis wrote: > > > > On Fri, Oct 1, 2021 at 3:27 PM Jerry Geis wrote: >> >> >> >> On Fri, Oct 1, 2021 at 3:20 PM Ilia Mirkin wrote: >>> >>> On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis wrote: >>> > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin wrote: >>> >> >>> >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis wrote: >>> >> > lsmod | grep nouveau >>> >> > >>> >> > What dont I have ? >>> >> >>> >> nouveau :) >>> >> >>> >> Other than that, you got everything... >>> >> >>> >> Check dmesg for errors. >>> >> >>> >> Cheers, >>> >> >>> >> -ilia >>> > >>> > >>> > I see this: >>> > Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) >>> > Matched nouveau as autoconfigured driver 0 >>> >>> This is not dmesg. This is some log file. Please look in dmesg. >>> >>> > Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) >>> > VESA(0): Using "Shadow Framebuffer" >>> >>> X is using the VESA driver because nouveau (nor any other DRM driver) is >>> loaded. >>> >>> > >>> > So it seems like its loading but perhaps its not happy >>> > >>> > What do I do ? >>> >>> Check dmesg for why nouveau didn't load. >>> >>> -ilia >> >> >> grep -i nouveau /var/log/dmesg >> [ 19.934733] kernel: fb0: switching to nouveaufb from VESA VGA >> [ 20.013197] kernel: nouveau :03:00.0: vgaarb: deactivate vga console >> [ 20.013415] kernel: nouveau :03:00.0: NVIDIA GT218 (0a8200b1) >> [ 20.159472] kernel: nouveau :03:00.0: bios: version 70.18.45.00.00 >> [ 20.162603] kernel: nouveau :03:00.0: fb: 512 MiB DDR3 >> [ 21.552858] kernel: nouveau :03:00.0: DRM: VRAM: 512 MiB >> [ 21.552873] kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB >> [ 21.552888] kernel: nouveau :03:00.0: DRM: TMDS table version 2.0 >> [ 21.552900] kernel: nouveau :03:00.0: DRM: DCB version 4.0 >> [ 21.552911] kernel: nouveau :03:00.0: DRM: DCB outp 00: 01000302 >> 0030 >> [ 21.552924] kernel: nouveau :03:00.0: DRM: DCB outp 01: 02000300 >> >> [ 21.552937] kernel: nouveau :03:00.0: DRM: DCB outp 02: 02011362 >> 00020010 >> [ 21.552950] kernel: nouveau :03:00.0: DRM: DCB conn 00: 1030 >> [ 21.552961] kernel: nouveau :03:00.0: DRM: DCB conn 01: 2161 >> [ 21.568834] kernel: nouveau :03:00.0: DRM: MM: using COPY for buffer >> copies >> [ 21.645206] kernel: nouveau :03:00.0: DRM: allocated 1920x1080 fb: >> 0x7, bo (ptrval) >> [ 21.648681] kernel: fbcon: nouveaudrmfb (fb0) is primary device >> [ 21.837701] kernel: nouveau :03:00.0: [drm] fb0: nouveaudrmfb frame >> buffer device >> [ 21.873290] kernel: [drm] Initialized nouveau 1.3.1 20120801 for >> :03:00.0 on minor 0 I was looking for you to just run "dmesg", BTW, not read a log file. >> >> lsmod | grep nouveau >> nouveau 1986560 30 >> mxm_wmi16384 1 nouveau >> i2c_algo_bit 16384 1 nouveau >> drm_ttm_helper 16384 1 nouveau >> ttm73728 2 drm_ttm_helper,nouveau >> drm_kms_helper237568 1 nouveau >> drm 548864 25 drm_kms_helper,drm_ttm_helper,ttm,nouveau >> video 53248 1 nouveau >> wmi32768 2 mxm_wmi,nouveau >> >> I took off ALL extra kernel command paramters - nothing specific to nouveau >> - and I got better results. however - video is still dropping frames. Perhaps you had a "nomodeset" in there? That would prevent nouveau from doing anything useful, although I think it'd still load in that case. >> >> So progress. but still no good. Check xorg log to make sure you see NOUVEAU lines, not modeset lines. If you see modeset lines, make sure you force the nouveau DDX driver to load. (Some distros think it's funny to prevent it from loading by default...) >> >> Jerry > > > I see this error: > nouveau :03:00.0: Direct firmware load for nouveau/nva8_fuc084 failed > > I did apt-file search nva8_fuc084 > and it did not return anything. This is for video decoding acceleration (vdpau / va-api). You can set this up by following the instructions at https://nouveau.freedesktop.org/VideoAcceleration.html . Note that it's hardly perfect. Cheers, -ilia
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 3:27 PM Jerry Geis wrote: > > > On Fri, Oct 1, 2021 at 3:20 PM Ilia Mirkin wrote: > >> On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis wrote: >> > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin >> wrote: >> >> >> >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis >> wrote: >> >> > lsmod | grep nouveau >> >> > >> >> > What dont I have ? >> >> >> >> nouveau :) >> >> >> >> Other than that, you got everything... >> >> >> >> Check dmesg for errors. >> >> >> >> Cheers, >> >> >> >> -ilia >> > >> > >> > I see this: >> > Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) >> Matched nouveau as autoconfigured driver 0 >> >> This is not dmesg. This is some log file. Please look in dmesg. >> >> > Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) >> VESA(0): Using "Shadow Framebuffer" >> >> X is using the VESA driver because nouveau (nor any other DRM driver) is >> loaded. >> >> > >> > So it seems like its loading but perhaps its not happy >> > >> > What do I do ? >> >> Check dmesg for why nouveau didn't load. >> >> -ilia >> > > grep -i nouveau /var/log/dmesg > [ 19.934733] kernel: fb0: switching to nouveaufb from VESA VGA > [ 20.013197] kernel: nouveau :03:00.0: vgaarb: deactivate vga console > [ 20.013415] kernel: nouveau :03:00.0: NVIDIA GT218 (0a8200b1) > [ 20.159472] kernel: nouveau :03:00.0: bios: version 70.18.45.00.00 > [ 20.162603] kernel: nouveau :03:00.0: fb: 512 MiB DDR3 > [ 21.552858] kernel: nouveau :03:00.0: DRM: VRAM: 512 MiB > [ 21.552873] kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB > [ 21.552888] kernel: nouveau :03:00.0: DRM: TMDS table version 2.0 > [ 21.552900] kernel: nouveau :03:00.0: DRM: DCB version 4.0 > [ 21.552911] kernel: nouveau :03:00.0: DRM: DCB outp 00: 01000302 > 0030 > [ 21.552924] kernel: nouveau :03:00.0: DRM: DCB outp 01: 02000300 > > [ 21.552937] kernel: nouveau :03:00.0: DRM: DCB outp 02: 02011362 > 00020010 > [ 21.552950] kernel: nouveau :03:00.0: DRM: DCB conn 00: 1030 > [ 21.552961] kernel: nouveau :03:00.0: DRM: DCB conn 01: 2161 > [ 21.568834] kernel: nouveau :03:00.0: DRM: MM: using COPY for > buffer copies > [ 21.645206] kernel: nouveau :03:00.0: DRM: allocated 1920x1080 fb: > 0x7, bo (ptrval) > [ 21.648681] kernel: fbcon: nouveaudrmfb (fb0) is primary device > [ 21.837701] kernel: nouveau :03:00.0: [drm] fb0: nouveaudrmfb frame > buffer device > [ 21.873290] kernel: [drm] Initialized nouveau 1.3.1 20120801 for > :03:00.0 on minor 0 > > lsmod | grep nouveau > nouveau 1986560 30 > mxm_wmi16384 1 nouveau > i2c_algo_bit 16384 1 nouveau > drm_ttm_helper 16384 1 nouveau > ttm73728 2 drm_ttm_helper,nouveau > drm_kms_helper237568 1 nouveau > drm 548864 25 drm_kms_helper,drm_ttm_helper,ttm,nouveau > video 53248 1 nouveau > wmi32768 2 mxm_wmi,nouveau > > I took off ALL extra kernel command paramters - nothing specific to > nouveau - and I got better results. however - video is still dropping > frames. > > So progress. but still no good. > > Jerry > I see this error: nouveau :03:00.0: Direct firmware load for nouveau/nva8_fuc084 failed I did apt-file search nva8_fuc084 and it did not return anything. jerry
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 3:20 PM Ilia Mirkin wrote: > On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis wrote: > > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin wrote: > >> > >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis wrote: > >> > lsmod | grep nouveau > >> > > >> > What dont I have ? > >> > >> nouveau :) > >> > >> Other than that, you got everything... > >> > >> Check dmesg for errors. > >> > >> Cheers, > >> > >> -ilia > > > > > > I see this: > > Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) > Matched nouveau as autoconfigured driver 0 > > This is not dmesg. This is some log file. Please look in dmesg. > > > Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) > VESA(0): Using "Shadow Framebuffer" > > X is using the VESA driver because nouveau (nor any other DRM driver) is > loaded. > > > > > So it seems like its loading but perhaps its not happy > > > > What do I do ? > > Check dmesg for why nouveau didn't load. > > -ilia > grep -i nouveau /var/log/dmesg [ 19.934733] kernel: fb0: switching to nouveaufb from VESA VGA [ 20.013197] kernel: nouveau :03:00.0: vgaarb: deactivate vga console [ 20.013415] kernel: nouveau :03:00.0: NVIDIA GT218 (0a8200b1) [ 20.159472] kernel: nouveau :03:00.0: bios: version 70.18.45.00.00 [ 20.162603] kernel: nouveau :03:00.0: fb: 512 MiB DDR3 [ 21.552858] kernel: nouveau :03:00.0: DRM: VRAM: 512 MiB [ 21.552873] kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB [ 21.552888] kernel: nouveau :03:00.0: DRM: TMDS table version 2.0 [ 21.552900] kernel: nouveau :03:00.0: DRM: DCB version 4.0 [ 21.552911] kernel: nouveau :03:00.0: DRM: DCB outp 00: 01000302 0030 [ 21.552924] kernel: nouveau :03:00.0: DRM: DCB outp 01: 02000300 [ 21.552937] kernel: nouveau :03:00.0: DRM: DCB outp 02: 02011362 00020010 [ 21.552950] kernel: nouveau :03:00.0: DRM: DCB conn 00: 1030 [ 21.552961] kernel: nouveau :03:00.0: DRM: DCB conn 01: 2161 [ 21.568834] kernel: nouveau :03:00.0: DRM: MM: using COPY for buffer copies [ 21.645206] kernel: nouveau :03:00.0: DRM: allocated 1920x1080 fb: 0x7, bo (ptrval) [ 21.648681] kernel: fbcon: nouveaudrmfb (fb0) is primary device [ 21.837701] kernel: nouveau :03:00.0: [drm] fb0: nouveaudrmfb frame buffer device [ 21.873290] kernel: [drm] Initialized nouveau 1.3.1 20120801 for :03:00.0 on minor 0 lsmod | grep nouveau nouveau 1986560 30 mxm_wmi16384 1 nouveau i2c_algo_bit 16384 1 nouveau drm_ttm_helper 16384 1 nouveau ttm73728 2 drm_ttm_helper,nouveau drm_kms_helper237568 1 nouveau drm 548864 25 drm_kms_helper,drm_ttm_helper,ttm,nouveau video 53248 1 nouveau wmi32768 2 mxm_wmi,nouveau I took off ALL extra kernel command paramters - nothing specific to nouveau - and I got better results. however - video is still dropping frames. So progress. but still no good. Jerry
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis wrote: > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin wrote: >> >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis wrote: >> > lsmod | grep nouveau >> > >> > What dont I have ? >> >> nouveau :) >> >> Other than that, you got everything... >> >> Check dmesg for errors. >> >> Cheers, >> >> -ilia > > > I see this: > Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) Matched > nouveau as autoconfigured driver 0 This is not dmesg. This is some log file. Please look in dmesg. > Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) VESA(0): > Using "Shadow Framebuffer" X is using the VESA driver because nouveau (nor any other DRM driver) is loaded. > > So it seems like its loading but perhaps its not happy > > What do I do ? Check dmesg for why nouveau didn't load. -ilia
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin wrote: > On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis wrote: > > lsmod | grep nouveau > > > > What dont I have ? > > nouveau :) > > Other than that, you got everything... > > Check dmesg for errors. > > Cheers, > > -ilia > I see this: Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) Matched nouveau as autoconfigured driver 0 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) Matched modesetting as autoconfigured driver 1 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) Matched fbdev as autoconfigured driver 2 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) Matched vesa as autoconfigured driver 3 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) Assigned the driver to the xf86ConfigLayout Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) LoadModule: "nouveau" Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so Oct 1 15:11:21 mediaport57 systemd[1484]: Stopped Tracker file system data miner. Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) Module nouveau: vendor="X.Org Foundation" Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011compiled for 1.20.3, module version = 1.0.16 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011Module class: X.Org Video Driver Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011ABI class: X.Org Video Driver, version 24.0 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) LoadModule: "modesetting" Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) Module modesetting: vendor="X.Org Foundation" Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011compiled for 1.20.11, module version = 1.20.11 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011Module class: X.Org Video Driver Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011ABI class: X.Org Video Driver, version 24.1 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) LoadModule: "fbdev" Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (WW) Warning, couldn't open module fbdev Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (EE) Failed to load module "fbdev" (module does not exist, 0) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) LoadModule: "vesa" Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) NOUVEAU driver Date: Mon Jan 28 23:25:58 2019 -0500 Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) NOUVEAU driver for NVIDIA chipset families : Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011RIVA TNT (NV04) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011RIVA TNT2 (NV05) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 256 (NV10) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 2 (NV11, NV15) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 4MX (NV17, NV18) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 3 (NV20) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 4Ti (NV25, NV28) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce FX (NV3x) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 6 (NV4x) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 7 (G7x) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 8 (G8x) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce 9 (G9x) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce GTX 2xx/3xx (GT2xx) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce GTX 4xx/5xx (GFxxx) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce GTX 6xx/7xx (GKxxx) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce GTX 9xx (GMxxx) Oct 1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: #011GeForce GTX 10xx(GPxxx) Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) VESA(0): : Using default hsync range of 31.50-48.00 kHz Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) VESA(0): : Using default vrefresh range of 50.00-70.00 Hz Oct 1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (II) VESA(0): : Using default maximum pixel clock of 65.00 MHz Oct 1 15:11:23 mediapor
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis wrote: > lsmod | grep nouveau > > What dont I have ? nouveau :) Other than that, you got everything... Check dmesg for errors. Cheers, -ilia
Re: [Nouveau] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > Hi all,
> >
> > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> > "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what
> > this
> > patch series is about.
> >
> > You will find two types of changes here:
> >
> > - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate)
> > with
> > "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has
> > already been done in previous commits such as b7ea04d2)
> >
> > - Replacing "drm_modeset_lock_all()" with
> > "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> > in the remaining places (as it has already been done in previous commits
> > such as 57037094)
> >
> > Most of the changes are straight forward, except for a few cases in the
> > "amd"
> > and "i915" drivers where some extra dancing was needed to overcome the
> > limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be
> > used
> > once inside the same function (the reason being that the macro expansion
> > includes *labels*, and you can not have two labels named the same inside one
> > function)
> >
> > Notice that, even after this patch series, some places remain where
> > "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present,
> > all inside drm core (which makes sense), except for two (in "amd" and
> > "i915")
> > which cannot be replaced due to the way they are being used.
> >
> > Changes in v2:
> >
> > - Fix commit message typo
> > - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
> > - Split drm/i915 patch into two simpler ones
> > - Remove drm_modeset_(un)lock_all()
> > - Fix build problems in non-x86 platforms
> >
> > Fernando Ramos (17):
> > drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all_ctx() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/msm: cleanup: drm_modeset_lock_all_ctx() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/tegra: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/shmobile: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/radeon: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/nouveau: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > drm/gma500: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm: cleanup: remove drm_modeset_(un)lock_all()
> > doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
> >
>
> Thank you for revising, Fernando! I've pushed the set to drm-misc-next (along
> with the necessary drm-tip conflict resolutions).
Ugh. Did anyone actually review the locking changes this does?
I shot the previous i915 stuff down because the commit messages
did not address any of it.
--
Ville Syrjälä
Intel
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 2:44 PM Ilia Mirkin wrote: > On Fri, Oct 1, 2021 at 2:29 PM Jerry Geis wrote: > > Thanks perhaps this is part of the problem: > > ls -l /sys/kernel/debug/dri/ > > total 0 > > This indicates that nouveau is not loaded. (Or loaded and failed > part-way through the load.) > > Cheers, > > -ilia > Thanks I have this: grep nouveau /var/log/syslog Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (==) Matched nouveau as autoconfigured driver 0 Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) LoadModule: "nouveau" Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Module nouveau: vendor="X.Org Foundation" Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (==) Matched nouveau as autoconfigured driver 0 Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) LoadModule: "nouveau" Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Module nouveau: vendor="X.Org Foundation" Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) UnloadModule: "nouveau" Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Unloading nouveau Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Failed to load module "nouveau" (already loaded, 0) grep Loading /var/log/syslog Oct 1 09:47:47 mediaport57 kernel: [ 12.300994] Loading compiled-in X.509 certificates Oct 1 09:47:47 mediaport57 kernel: [ 12.772319] blacklist: Loading compiled-in revocation X.509 certificates Oct 1 09:47:47 mediaport57 kernel: [ 37.869170] cfg80211: Loading compiled-in X.509 certificates for regulatory database Oct 1 09:47:57 mediaport57 lxd.activate[846]: ==> Loading snap configuration Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/extensions/libglx.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading sub module "vbe" Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/libvbe.so Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading sub module "int10" Oct 1 09:48:41 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/libint10.so Oct 1 09:48:42 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading sub module "ddc" Oct 1 09:48:43 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading sub module "shadow" Oct 1 09:48:43 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/libshadow.so Oct 1 09:48:43 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading sub module "fb" Oct 1 09:48:43 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/libfb.so Oct 1 09:48:43 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading sub module "int10" Oct 1 09:48:43 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/libint10.so Oct 1 09:48:44 mediaport57 /usr/lib/gdm3/gdm-x-session[1423]: (II) Loading /usr/lib/xorg/modules/input/libinput_drv.so lsmod | grep nouveau What dont I have ? Jerry
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 2:29 PM Jerry Geis wrote: > Thanks perhaps this is part of the problem: > ls -l /sys/kernel/debug/dri/ > total 0 This indicates that nouveau is not loaded. (Or loaded and failed part-way through the load.) Cheers, -ilia
Re: [Nouveau] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> Hi all,
>
> One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
> patch series is about.
>
> You will find two types of changes here:
>
> - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate) with
> "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has
> already been done in previous commits such as b7ea04d2)
>
> - Replacing "drm_modeset_lock_all()" with
> "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
> in the remaining places (as it has already been done in previous commits
> such as 57037094)
>
> Most of the changes are straight forward, except for a few cases in the "amd"
> and "i915" drivers where some extra dancing was needed to overcome the
> limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be used
> once inside the same function (the reason being that the macro expansion
> includes *labels*, and you can not have two labels named the same inside one
> function)
>
> Notice that, even after this patch series, some places remain where
> "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present,
> all inside drm core (which makes sense), except for two (in "amd" and "i915")
> which cannot be replaced due to the way they are being used.
>
> Changes in v2:
>
> - Fix commit message typo
> - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
> - Split drm/i915 patch into two simpler ones
> - Remove drm_modeset_(un)lock_all()
> - Fix build problems in non-x86 platforms
>
> Fernando Ramos (17):
> drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/i915: cleanup: drm_modeset_lock_all_ctx() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/msm: cleanup: drm_modeset_lock_all_ctx() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/shmobile: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/omapdrm: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/nouveau: cleanup: drm_modeset_lock_all() -->
> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> part 2
> drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> drm: cleanup: remove drm_modeset_(un)lock_all()
> doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
>
Thank you for revising, Fernando! I've pushed the set to drm-misc-next (along
with the necessary drm-tip conflict resolutions).
Sean
> Documentation/gpu/todo.rst| 17
> Documentation/locking/ww-mutex-design.rst | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 21 +++--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 25 ++---
> drivers/gpu/drm/drm_client_modeset.c | 14 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 18 ++--
> drivers/gpu/drm/drm_fb_helper.c | 10 +-
> drivers/gpu/drm/drm_framebuffer.c | 6 +-
> drivers/gpu/drm/drm_modeset_lock.c| 94 +--
> drivers/gpu/drm/gma500/psb_device.c | 18 ++--
> drivers/gpu/drm/i915/display/intel_audio.c| 16 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 23 ++---
> .../drm/i915/display/intel_display_debugfs.c | 46 +
> drivers/gpu/drm/i915/display/intel_overlay.c | 46 -
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 7 +-
> drivers/gpu/drm/i915/i915_drv.c | 13 ++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 10 +-
> .../gpu/drm/msm/disp/msm_disp_snapshot_util.c | 12 +--
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++-
> drivers/gpu/drm/omapdrm/omap_fb.c | 9 +-
> drivers/gpu/drm/radeon/radeon_device.c| 21 +++--
> drivers/gpu/drm/radeon/radeon_dp_mst.c| 10 +-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 +-
> drivers/gpu/drm/tegra/dsi.c | 6 +-
> drivers/gpu/drm/tegra/hdmi.c | 6 +-
> drivers/gpu/drm/tegra/sor.c | 11 ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 ++-
> include/drm/drm_modeset_lock.h| 2 -
> 30 files changed, 265 ins
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
On Fri, Oct 1, 2021 at 11:05 AM Ilia Mirkin wrote: > You can check the perf level your GPU is at, and potentially adjust it. > > cat /sys/kernel/debug/dri/0/pstate > > This should give a list of levels like "xx: stuff", with the "AC" > level being the current settings. Echo'ing any one of the xx's into > that file will attempt to switch to a different performance level. > Sometimes it works, other times it kills the GPU until you reboot. Use > with care. > > Cheers, > > -ilia > > On Fri, Oct 1, 2021 at 11:01 AM Jerry Geis wrote: > > > > I am trying to get Nouveau running and also playing video. > > lspci | grep VGA shows > > 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev > a2) > > > > syslog shows nouveau loaded > > > > But video performance is SLOW - dropping frames. > > > > have I missed something ? > > > > How do I get better video performance ? > > > > Thanks, > > > > Jerry > Thanks perhaps this is part of the problem: ls -l /sys/kernel/debug/dri/ total 0 Do I not have a package installed ? apt list --installed | grep dri WARNING: apt does not have a stable CLI interface. Use with caution in scripts. i965-va-driver/focal,now 2.4.0-0ubuntu1 amd64 [installed,automatic] intel-media-va-driver/focal,now 20.1.1+dfsg1-1 amd64 [installed,automatic] libgl1-mesa-dri/now 21.0.3-0ubuntu0.3~20.04.1 amd64 [installed,upgradable to: 21.0.3-0ubuntu0.3~20.04.2] libreoffice-base-drivers/focal-updates,now 1:6.4.7-0ubuntu0.20.04.1 amd64 [installed,automatic] libxcb-dri2-0/focal,now 1.14-2 amd64 [installed,automatic] libxcb-dri3-0/focal,now 1.14-2 amd64 [installed,automatic] mesa-va-drivers/now 21.0.3-0ubuntu0.3~20.04.1 amd64 [installed,upgradable to: 21.0.3-0ubuntu0.3~20.04.2] mesa-vdpau-drivers/now 21.0.3-0ubuntu0.3~20.04.1 amd64 [installed,upgradable to: 21.0.3-0ubuntu0.3~20.04.2] mesa-vulkan-drivers/now 21.0.3-0ubuntu0.3~20.04.1 amd64 [installed,upgradable to: 21.0.3-0ubuntu0.3~20.04.2] printer-driver-pnm2ppa/focal,now 1.13+nondbs-0ubuntu6 amd64 [installed,automatic] ubuntu-drivers-common/focal-updates,now 1:0.9.0~0.20.04.1 amd64 [installed,automatic] va-driver-all/focal,now 2.7.0-2 amd64 [installed,automatic] vdpau-driver-all/focal,now 1.3-1ubuntu2 amd64 [installed,automatic] vdpau-va-driver/now 0.7.4-7 amd64 [installed,local] Jerry
Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS
You can check the perf level your GPU is at, and potentially adjust it. cat /sys/kernel/debug/dri/0/pstate This should give a list of levels like "xx: stuff", with the "AC" level being the current settings. Echo'ing any one of the xx's into that file will attempt to switch to a different performance level. Sometimes it works, other times it kills the GPU until you reboot. Use with care. Cheers, -ilia On Fri, Oct 1, 2021 at 11:01 AM Jerry Geis wrote: > > I am trying to get Nouveau running and also playing video. > lspci | grep VGA shows > 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2) > > syslog shows nouveau loaded > > But video performance is SLOW - dropping frames. > > have I missed something ? > > How do I get better video performance ? > > Thanks, > > Jerry
[Nouveau] Nouveau on Ubuntu 20.04 LTS
I am trying to get Nouveau running and also playing video. lspci | grep VGA shows 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2) syslog shows nouveau loaded But video performance is SLOW - dropping frames. have I missed something ? How do I get better video performance ? Thanks, Jerry
