On Thu, Jul 22, 2021 at 9:48 AM Sean Paul <sean@xxxxxxxxxx> wrote: > > On Thu, Jul 22, 2021 at 3:49 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > > > On Wed, 21 Jul 2021 13:55:07 -0400 > > Sean Paul <sean@xxxxxxxxxx> wrote: > > > > > From: Sean Paul <seanpaul@xxxxxxxxxxxx> > > > > > > Hi all, > > > I just had the pleasure of rebasing this set on our CrOS downstream > > > kernel and wanted to resend it for consideration once again. There > > > hasn't been any resistence to the set AFAIK, just perhaps not enough > > > motivation for anyone to hit the go bit. There was some interest from > > > the msm folks about a month ago, and it has been an invaluable tool > > > on CrOS for the past ~year. Hopefully someone can dig into this and > > > provide some feedback so we can move this forward. > > > > > > Thanks! > > > > > > Sean > > > > > > Changes since last v6: > > > -Rebased on drm-tip > > > > > > Original v6 of the set available here: > > > https://patchwork.freedesktop.org/series/78133/ > > > https://lore.kernel.org/dri-devel/20200818210510.49730-1-sean@xxxxxxxxxx/ > > > > > > > Woo! Yes! > > > > Do you have a link to your userspace? > > > > Hi Pekka, > Probably less interesting that you're hoping for, but here are the > CrOS patches to enable and collect tracing: > > https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2354674 > https://chromium-review.googlesource.com/c/chromiumos/platform/crosutils/+/2354392 > > > > You wouldn't happen to have already written a privileged userspace > > service that would deliver on request the logs to non-privileged actors > > like a compositor to be dumped in an error report? > > Our feedback report generation (log_tool.cc above) collects the logs > (depending on user log preferences) from across the system and > packages them up for submission when requested by the user. For > drm_trace, we grab them from debugfs since we don't have tracefs > mounted. > One more note: If you have a chromebook with a 5.4+ kernel, you can check out the output yourself by navigating to chrome://system and expanding the "drm_trace" field. Sean > You could adapt this code to change the delivery method, but I'm not > sure how much value it would add beyond writing your own purpose-built > service. > > Sean > > > > > > > Thanks, > > pq > > > > > Sean Paul (14): > > > drm/mipi_dbi: Convert pr_debug calls to DRM_DEBUG_DRIVER > > > drm/sil164: Convert dev_printk to drm_dev_dbg > > > drm/i915/utils: Replace dev_printk with drm helpers > > > drm/msm/dpu: Replace definitions for dpu debug macros > > > drm/print: rename drm_debug* to be more syslog-centric > > > drm/amd: Gate i2c transaction logs on drm_debug_syslog > > > drm/etnaviv: Change buffer dump checks to target syslog > > > drm/nouveau: Change debug checks to specifically target syslog > > > drm/i915: Change infoframe debug checks to specify syslog > > > drm/print: Add drm_debug_category_printer > > > drm/mst: Convert debug printers to debug category printers > > > drm/i915: Use debug category printer for welcome message > > > drm/atomic: Use debug category printer for atomic state printer > > > drm/print: Add tracefs support to the drm logging helpers > > > > > > Documentation/gpu/drm-uapi.rst | 6 + > > > drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 +- > > > drivers/gpu/drm/drm_atomic_uapi.c | 2 +- > > > drivers/gpu/drm/drm_dp_mst_topology.c | 9 +- > > > drivers/gpu/drm/drm_drv.c | 3 + > > > drivers/gpu/drm/drm_mipi_dbi.c | 8 +- > > > drivers/gpu/drm/drm_print.c | 242 ++++++++++++++++--- > > > drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8 +- > > > drivers/gpu/drm/i2c/sil164_drv.c | 12 +- > > > drivers/gpu/drm/i915/display/intel_display.c | 4 +- > > > drivers/gpu/drm/i915/i915_drv.c | 3 +- > > > drivers/gpu/drm/i915/i915_utils.c | 5 +- > > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 20 +- > > > drivers/gpu/drm/nouveau/nouveau_drv.h | 4 +- > > > include/drm/drm_print.h | 96 +++++++- > > > 15 files changed, 331 insertions(+), 95 deletions(-) > > > > >
