[Bug 212469] plymouth animation freezes during shutdown
https://bugzilla.kernel.org/show_bug.cgi?id=212469 --- Comment #12 from Norbert (asteri...@gmx.de) --- The plymouth git works (Ubuntu 21.10). -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] doc: gpu: Add document describing buffer exchange
Since there's a lot of confusion around this, document both the rules and the best practice around negotiating, allocating, importing, and using buffers when crossing context/process/device/subsystem boundaries. This ties up all of dmabuf, formats and modifiers, and their usage. Signed-off-by: Daniel Stone --- This is just a quick first draft, inspired by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3197#note_1048637 It's not complete or perfect, but I'm off to eat a roast then have a nice walk in the sun, so figured it'd be better to dash it off rather than let it rot on my hard drive. .../gpu/exchanging-pixel-buffers.rst | 285 ++ Documentation/gpu/index.rst | 1 + 2 files changed, 286 insertions(+) create mode 100644 Documentation/gpu/exchanging-pixel-buffers.rst diff --git a/Documentation/gpu/exchanging-pixel-buffers.rst b/Documentation/gpu/exchanging-pixel-buffers.rst new file mode 100644 index ..75c4de13d5c8 --- /dev/null +++ b/Documentation/gpu/exchanging-pixel-buffers.rst @@ -0,0 +1,285 @@ +.. Copyright 2021 Collabora Ltd. + + +Exchanging pixel buffers + + +As originally designed, the Linux graphics subsystem had extremely limited +support for sharing pixel-buffer allocations between processes, devices, and +subsystems. Modern systems require extensive integration between all three +classes; this document details how applications and kernel subsystems should +approach this sharing for two-dimensional image data. + +It is written with reference to the DRM subsystem for GPU and display devices, +V4L2 for media devices, and also to Vulkan, EGL and Wayland, for userspace +support, however any other subsystems should also follow this design and advice. + + +Formats and modifiers += + +Each buffer must have an underlying format. This format describes the data which +can be stored and loaded for each pixel. Although each subsystem has its own +format descriptions (e.g. V4L2 and fbdev), the `DRM_FORMAT_*` tokens should be +reused wherever possible, as they are the standard descriptions used for +interchange. + +Each `DRM_FORMAT_*` token describes the per-pixel data available, in terms of +the translation between one or more pixels in memory, and the color data +contained within that memory. The number and type of color channels are +described: whether they are RGB or YUV, integer or floating-point, the size +of each channel and their locations within the pixel memory, and the +relationship between color planes. + +For example, `DRM_FORMAT_ARGB` describes a format in which each pixel has a +single 32-bit value in memory. Alpha, red, green, and blue, color channels are +available at 8-byte precision per channel, ordered respectively from most to +least significant bits in little-endian storage. As a more complex example, +`DRM_FORMAT_NV12` describes a format in which luma and chroma YUV samples are +stored in separate memory planes, where the chroma plane is stored at half the +resolution in both dimensions (i.e. one U/V chroma sample is stored for each 2x2 +pixel grouping). + +Format modifiers describe a translation mechanism between these per-pixel memory +samples, and the actual memory storage for the buffer. The most straightforward +modifier is `DRM_FORMAT_MOD_LINEAR`, describing a scheme in which each pixel has +contiguous storage beginning at (0,0); each pixel's location in memory will be +`base + (y * stride) + (x * bpp)`. This is considered the baseline interchange +format, and most convenient for CPU access. + +Modern hardware employs much more sophisticated access mechanisms, typically +making use of tiled access and possibly also compression. For example, the +`DRM_FORMAT_MOD_VIVANTE_TILED` modifier describes memory storage where pixels +are stored in 4x4 blocks arranged in row-major ordering, i.e. the first tile in +memory stores pixels (0,0) to (3,3) inclusive, and the second tile in memory +stores pixels (4,0) to (7,3) inclusive. + +Some modifiers may modify the number of memory buffers required to store the +data; for example, the `I915_FORMAT_MOD_Y_TILED_CCS` modifier adds a second +memory buffer to RGB formats in which it stores data about the status of every +tile, notably including whether the tile is fully populated with pixel data, or +can be expanded from a single solid color. + +These extended layouts are highly vendor-specific, and even specific to +particular generations or configurations of devices per-vendor. For this reason, +support of modifiers must be explicitly enumerated and negotiated by all users +in order to ensure a compatible and optimal pipeline, as discussed below. + + +Dimensions and size +=== + +Each pixel buffer must be accompanied by logical pixel dimensions. This refers +to the number of unique samples which can be extracted from, or stored to, the +underlying memory storage. For example,
[PATCH] drm: panel-orientation-quirks: Add quirk for the Chuwi HiBook
The Chuwi HiBook uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 4e965b0f5502..7e0f581a360e 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -140,6 +140,14 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T103HAF"),
},
.driver_data = (void *)&lcd800x1280_rightside_up,
+ }, {/* Chuwi HiBook (CWI514) */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
+ /* Above matches are too generic, add bios-date match */
+ DMI_MATCH(DMI_BIOS_DATE, "05/07/2016"),
+ },
+ .driver_data = (void *)&lcd1200x1920_rightside_up,
}, {/* Chuwi Hi10 Pro (CWI529) */
.matches = {
DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
--
2.31.1
Re: [PATCH] drm/panel: otm8009a: add a 60 fps mode
Hi Raphael, On Thu, Sep 02, 2021 at 03:04:34PM +, Raphael GALLAIS-POU - foss wrote: > This patch adds a 60 fps mode to the Orisetech OTM8009A panel. > The 50 fps mode is left as preferred. > > Signed-off-by: Raphael Gallais-Pou Thanks, applied to drm-misc-next. Sam
[drm-intel:drm-intel-gt-next 1/1] drivers/gpu/drm/i915/i915_query.c:439:2: warning: comparison of integers of different signs: 'int' and 'unsigned int'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next head: d5ef86b38e4c2a65d5c1d64d8d0f3fcf58aa0884 commit: d5ef86b38e4c2a65d5c1d64d8d0f3fcf58aa0884 [1/1] drm/i915: Add pci ids and uapi for DG1 config: i386-randconfig-r002-20210903 (attached as .config) compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 1104e3258b5064e7110cc297e2cec60ac9acfc0a) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git remote add drm-intel git://anongit.freedesktop.org/drm-intel git fetch --no-tags drm-intel drm-intel-gt-next git checkout d5ef86b38e4c2a65d5c1d64d8d0f3fcf58aa0884 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): include/linux/random.h:127:67: warning: unused parameter 'v' [-Wunused-parameter] static inline bool __must_check arch_get_random_int(unsigned int *v) ^ include/linux/random.h:131:74: warning: unused parameter 'v' [-Wunused-parameter] static inline bool __must_check arch_get_random_seed_long(unsigned long *v) ^ include/linux/random.h:135:72: warning: unused parameter 'v' [-Wunused-parameter] static inline bool __must_check arch_get_random_seed_int(unsigned int *v) ^ In file included from drivers/gpu/drm/i915/i915_query.c:9: In file included from drivers/gpu/drm/i915/i915_drv.h:84: In file included from drivers/gpu/drm/i915/gt/intel_engine.h:17: In file included from drivers/gpu/drm/i915/gt/intel_gt_types.h:18: In file included from drivers/gpu/drm/i915/gt/uc/intel_uc.h:9: drivers/gpu/drm/i915/gt/uc/intel_guc.h:180:59: warning: unused parameter 'guc' [-Wunused-parameter] static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc, ^ In file included from drivers/gpu/drm/i915/i915_query.c:9: In file included from drivers/gpu/drm/i915/i915_drv.h:101: drivers/gpu/drm/i915/i915_gpu_error.h:276:43: warning: unused parameter 'gt' [-Wunused-parameter] i915_capture_error_state(struct intel_gt *gt, intel_engine_mask_t engine_mask) ^ drivers/gpu/drm/i915/i915_gpu_error.h:276:67: warning: unused parameter 'engine_mask' [-Wunused-parameter] i915_capture_error_state(struct intel_gt *gt, intel_engine_mask_t engine_mask) ^ drivers/gpu/drm/i915/i915_gpu_error.h:281:50: warning: unused parameter 'i915' [-Wunused-parameter] i915_gpu_coredump_alloc(struct drm_i915_private *i915, gfp_t gfp) ^ drivers/gpu/drm/i915/i915_gpu_error.h:281:62: warning: unused parameter 'gfp' [-Wunused-parameter] i915_gpu_coredump_alloc(struct drm_i915_private *i915, gfp_t gfp) ^ drivers/gpu/drm/i915/i915_gpu_error.h:287:42: warning: unused parameter 'gt' [-Wunused-parameter] intel_gt_coredump_alloc(struct intel_gt *gt, gfp_t gfp) ^ drivers/gpu/drm/i915/i915_gpu_error.h:287:52: warning: unused parameter 'gfp' [-Wunused-parameter] intel_gt_coredump_alloc(struct intel_gt *gt, gfp_t gfp) ^ drivers/gpu/drm/i915/i915_gpu_error.h:293:53: warning: unused parameter 'engine' [-Wunused-parameter] intel_engine_coredump_alloc(struct intel_engine_cs *engine, gfp_t gfp) ^ drivers/gpu/drm/i915/i915_gpu_error.h:293:67: warning: unused parameter 'gfp' [-Wunused-parameter] intel_engine_coredump_alloc(struct intel_engine_cs *engine, gfp_t gfp) ^ drivers/gpu/drm/i915/i915_gpu_error.h:299:65: warning: unused parameter 'ee' [-Wunused-parameter] intel_engine_coredump_add_request(struct intel_engine_coredump *ee, ^ drivers/gpu/drm/i915/i915_gpu_error.h:300:28: warning: unused parameter 'rq' [-Wunused-parameter] struct i915_request *rq, ^ drivers/gpu/drm/i915/i915_gpu_error.h:301:13: warning: unused parameter 'gfp' [-Wunused-parameter] gfp_t gfp) ^ drivers/gpu/drm/i915/i915_gpu_error.h:307:61: wa
Re: [PATCH v3 03/16] drm/edid: Allow the querying/working with the panel ID from the EDID
Hi Douglas, On Wed, Sep 01, 2021 at 01:19:21PM -0700, Douglas Anderson wrote: > EDIDs have 32-bits worth of data which is intended to be used to > uniquely identify the make/model of a panel. This has historically > been used only internally in the EDID processing code to identify > quirks with panels. > > We'd like to use this panel ID in panel-simple to identify which panel > is hooked up and from that information figure out power sequence > timings. Let's expose this information from the EDID code and also > allow it to be accessed early, before a connector has been created. > > To make matching in the panel-simple code easier, we'll return the > panel ID as a 32-bit value. We'll provide some functions for > converting this value back and forth to something more human readable. > > Signed-off-by: Douglas Anderson nit - two patches down this is no longer panel-simple.
Re: [PATCH v3 05/16] drm/panel-simple-edp: Split eDP panels out of panel-simple
Hi Douglas, On Wed, Sep 01, 2021 at 01:19:23PM -0700, Douglas Anderson wrote: > The panel-simple driver handles way too much. Let's start trying to > get a handle on it by splitting out the eDP panels. This patch does > this: > > 1. Start by copying simple-panel verbatim over to a new driver, >simple-panel-edp. > 2. Rename "panel_simple" to "panel_edp" in the new driver. > 3. Keep only panels marked with `DRM_MODE_CONNECTOR_eDP` in the new >driver. Remove those panels from the old driver. > 4. Remove all recent "DP AUX bus" stuff from the old driver. The DP >AUX bus is only possible on DP panels. > 5. Remove all DSI / MIPI related functions from the new driver. > 6. Remove bus_format / bus_flags from eDP driver. These things don't >seem to make any sense for eDP panels so let's stop filling in made >up stuff. > > In the end we end up with a bunch of duplicated code for now. Future > patches will try to address _some_ of this duplicated code though some > of it will be unavoidable. > > NOTE: This may not actually move all eDP panels over to the new driver > since not all panels were properly marked with > `DRM_MODE_CONNECTOR_eDP`. A future patch will attempt to move wayward > panels I could identify but even so there may be some missed. > > Suggested-by: Sam Ravnborg > Signed-off-by: Douglas Anderson > --- > I believe this is what Sam was looking for when he requested that the > eDP panels split out [1]. Please yell if not. I will yell a big thanks! This was exactly what I hoped to see. And very nice to have panel-simple complexity reduced. The code duplication is worth it. To avoid confusion I would prefer the file named panel-edp.c, as this is not "simple" panels and it then matches the compatible. A few nits in the following. Sam > > [1] https://lore.kernel.org/dri-devel/yrtsfntn%2ft8fl...@ravnborg.org/ > > Changes in v3: > - Split eDP panels patch new for v3. > > drivers/gpu/drm/panel/Kconfig| 16 +- > drivers/gpu/drm/panel/Makefile |1 + > drivers/gpu/drm/panel/panel-simple-edp.c | 1298 ++ > drivers/gpu/drm/panel/panel-simple.c | 575 +- > 4 files changed, 1323 insertions(+), 567 deletions(-) > create mode 100644 drivers/gpu/drm/panel/panel-simple-edp.c > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 0b3784941312..4b7ff4ebdc34 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -77,14 +77,26 @@ config DRM_PANEL_LVDS > backlight handling if the panel is attached to a backlight controller. > > config DRM_PANEL_SIMPLE > - tristate "support for simple panels" > + tristate "support for simple panels (other than eDP ones)" > + depends on OF > + depends on BACKLIGHT_CLASS_DEVICE > + depends on PM > + select VIDEOMODE_HELPERS > + help > + DRM panel driver for dumb non-eDP panels that need at most a regulator > + and a GPIO to be powered up. Optionally a backlight can be attached so > + that it can be automatically turned off when the panel goes into a > + low power state. > + > +config DRM_PANEL_SIMPLE_EDP So this should also be named DRM_PANEL_EDP to follow the name of the driver. > + tristate "support for simple Embedded DisplayPort panels" > depends on OF > depends on BACKLIGHT_CLASS_DEVICE > depends on PM > select VIDEOMODE_HELPERS > select DRM_DP_AUX_BUS > help > - DRM panel driver for dumb panels that need at most a regulator and > + DRM panel driver for dumb eDP panels that need at most a regulator and > a GPIO to be powered up. Optionally a backlight can be attached so > that it can be automatically turned off when the panel goes into a > low power state. > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index 60c0149fc54a..640234d4d693 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += > panel-boe-tv101wum-nl6.o > obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o > obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o > obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o > +obj-$(CONFIG_DRM_PANEL_SIMPLE_EDP) += panel-simple-edp.o > obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o > obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o > obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += > panel-feiyang-fy07024di26a30d.o > diff --git a/drivers/gpu/drm/panel/panel-simple-edp.c > b/drivers/gpu/drm/panel/panel-simple-edp.c > new file mode 100644 > index ..5b47ee4bc338 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-simple-edp.c > @@ -0,0 +1,1298 @@ > +/* > + * Copyright (C) 2013, NVIDIA Corporation. All rights reserved. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy
Re: [PATCH v3 10/16] drm/panel-simple: Non-eDP panels don't need "HPD" handling
On Wed, Sep 01, 2021 at 01:19:28PM -0700, Douglas Anderson wrote: > All of the "HPD" handling added to panel-simple recently was for eDP > panels. Remove it from panel-simple now that panel-simple-edp handles > eDP panels. The "prepare_to_enable" delay only makes sense in the > context of HPD, so remove it too. No non-eDP panels used it anyway. > > Signed-off-by: Douglas Anderson Maybe merge this with the patch that moved all the functionality from panel-simple to panel-edp? Sam
Re: [PATCH v7 6/8] drm_print: instrument drm_debug_enabled
On Tue, Aug 31, 2021 at 2:21 PM Jim Cromie wrote:
>
> Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
> ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg"
> branch.
>
> Then convert the "dyndbg" branch's code to a macro, so that its
> pr_debug() get its callsite info from the invoking function, instead
> of from drm_debug_enabled() itself.
>
> This gives us unique callsite info for the 8 remaining users of
> drm_debug_enabled(), and lets us enable them individually to see how
> much logging traffic they generate. The oft-visited callsites can
> then be reviewed for runtime cost and possible optimizations.
>
> Heres what we get:
>
> bash-5.1# modprobe drm
> dyndbg: 384 debug prints in module drm
> bash-5.1# grep todo: /proc/dynamic_debug/control
> drivers/gpu/drm/drm_edid.c:1843 [drm]connector_bad_edid =_ "todo: maybe avoid
> via dyndbg\012"
> drivers/gpu/drm/drm_print.c:309 [drm]___drm_dbg =p "todo: maybe avoid via
> dyndbg\012"
> drivers/gpu/drm/drm_print.c:286 [drm]__drm_dev_dbg =p "todo: maybe avoid via
> dyndbg\012"
> drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe
> avoid via dyndbg\012"
> drivers/gpu/drm/drm_vblank.c:787
> [drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe
> avoid via dyndbg\012"
> drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_
> "todo: maybe avoid via dyndbg\012"
> drivers/gpu/drm/drm_atomic_uapi.c:1457 [drm]drm_mode_atomic_ioctl =_ "todo:
> maybe avoid via dyndbg\012"
> drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via
> dyndbg\012"
>
> At quick glance, edid won't qualify, drm_print might, drm_vblank is
> strongest chance, maybe atomic-ioctl too.
>
> Signed-off-by: Jim Cromie
> ---
heres 120 seconds of enabled todos, from this patch
[jimc@frodo wk-next]$ journalctl -b0 | grep todo | grep 'frodo kernel'
[jimc@frodo wk-next]$ sudo su -c 'echo format ^todo: +pfml >
/proc/dynamic_debug/control; sleep 120; echo format ^todo: -p >
/proc/dynamic_debug/control'
[sudo] password for jimc:
[jimc@frodo wk-next]$ journalctl -b0 | grep todo | grep 'frodo kernel'
> todo-120-log
[jimc@frodo wk-next]$ wc todo-120-log
228 2516 24066 todo-120-log
so overall thats not too much work, not so many bitchecks as to be
worth avoiding.
I think I'll try hitting it with my new igt-tools hammer, see what breaks :-)
[jimc@frodo wk-next]$ hsto todo-120-log
120 : drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal:787:
todo: maybe avoid via dyndbg
40 : i915:process_csb:1904: todo: maybe avoid via dyndbg
20 : drm:drm_vblank_restore:1491: todo: maybe avoid via dyndbg
20 : drm:drm_crtc_accurate_vblank_count:410: todo: maybe avoid via dyndbg
20 : i915:skl_print_wm_changes:6068: todo: maybe avoid via dyndbg
2 : dyndbg: applied: func="" file="" module="" format="^todo:" lineno=0-0
2 : dyndbg: parsed: func="" file="" module="" format="^todo:" lineno=0-0
1 : dyndbg: split into words: "format" "^todo:" "-p"
1 : dyndbg: split into words: "format" "^todo:" "+pfml"
1 : dyndbg: query 0: "format ^todo: -p" mod:*
1 : dyndbg: query 0: "format ^todo: +pfml" mod:*
Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding
Hi Douglas,
On Wed, Sep 01, 2021 at 01:19:18PM -0700, Douglas Anderson wrote:
> The goal of this patch series is to move away from hardcoding exact
> eDP panels in device tree files. As discussed in the various patches
> in this series (I'm not repeating everything here), most eDP panels
> are 99% probable and we can get that last 1% by allowing two "power
> up" delays to be specified in the device tree file and then using the
> panel ID (found in the EDID) to look up additional power sequencing
> delays for the panel.
>
> This patch series is the logical contiunation of a previous patch
> series where I proposed solving this problem by adding a
> board-specific compatible string [1]. In the discussion that followed
> it sounded like people were open to something like the solution
> proposed in this new series.
>
> In version 2 I got rid of the idea that we could have a "fallback"
> compatible string that we'd use if we didn't recognize the ID in the
> EDID. This simplifies the bindings a lot and the implementation
> somewhat. As a result of not having a "fallback", though, I'm not
> confident in transitioning any existing boards over to this since
> we'll have to fallback to very conservative timings if we don't
> recognize the ID from the EDID and I can't guarantee that I've seen
> every panel that might have shipped on an existing product. The plan
> is to use "edp-panel" only on new boards or new revisions of old
> boards where we can guarantee that every EDID that ships out of the
> factory has an ID in the table.
>
> Version 3 of this series now splits out all eDP panels to their own
> driver and adds the generic eDP panel support to this new driver. I
> believe this is what Sam was looking for [2].
>
> [1] https://lore.kernel.org/r/yfkqaxomowyye...@google.com/
> [2] https://lore.kernel.org/r/yrtsfntn%2ft8fl...@ravnborg.org/
>
> Changes in v3:
> - Decode hex product ID w/ same endianness as everyone else.
> - ("Reorder logicpd_type_28...") patch new for v3.
> - Split eDP panels patch new for v3.
> - Move wayward panels patch new for v3.
> - ("Non-eDP panels don't need "HPD" handling") new for v3.
> - Split the delay structure out patch just on eDP now.
> - ("Better describe eDP panel delays") new for v3.
> - Fix "prepare_to_enable" patch new for v3.
> - ("Don't re-read the EDID every time") moved to eDP only patch.
> - Generic "edp-panel" handled by the eDP panel driver now.
> - Change init order to we power at the end.
> - Adjust endianness of product ID.
> - Fallback to conservative delays if panel not recognized.
> - Add Sharp LQ116M1JW10 to table.
> - Add AUO B116XAN06.1 to table.
> - Rename delays more generically so they can be reused.
>
> Changes in v2:
> - No longer allow fallback to panel-simple.
> - Add "-ms" suffix to delays.
> - Don't support a "fallback" panel. Probed panels must be probed.
> - Not based on patch to copy "desc"--just allocate for probed panels.
> - Add "-ms" suffix to delays.
>
> Douglas Anderson (16):
> dt-bindings: drm/panel-simple-edp: Introduce generic eDP panels
> drm/edid: Break out reading block 0 of the EDID
> drm/edid: Allow the querying/working with the panel ID from the EDID
> drm/panel-simple: Reorder logicpd_type_28 / mitsubishi_aa070mc01
> drm/panel-simple-edp: Split eDP panels out of panel-simple
> ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP
> arm64: defconfig: Everyone who had PANEL_SIMPLE now gets
> PANEL_SIMPLE_EDP
> MIPS: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP
> drm/panel-simple-edp: Move some wayward panels to the eDP driver
> drm/panel-simple: Non-eDP panels don't need "HPD" handling
> drm/panel-simple-edp: Split the delay structure out
> drm/panel-simple-edp: Better describe eDP panel delays
> drm/panel-simple-edp: hpd_reliable shouldn't be subtraced from
> hpd_absent
> drm/panel-simple-edp: Fix "prepare_to_enable" if panel doesn't handle
> HPD
> drm/panel-simple-edp: Don't re-read the EDID every time we power off
> the panel
> drm/panel-simple-edp: Implement generic "edp-panel"s probed by EDID
Thanks for looking into this. I really like the outcome.
We have panel-simple that now (mostly) handle simple panels,
and thus all the eDP functionality is in a separate driver.
I have provided a few nits.
My only take on this is the naming - as we do not want to confuse
panel-simple and panel-edp I strongly suggest renaming the driver to
panel-edp.
And then rename the corresponding Kconfig entry.
With these few changes all patches are:
Acked-by: Sam Ravnborg
For bisectability I suggest to move the defconfig patches up before you
introduce the new Kconfig symbol. Or maybe they will be added via
another tree and then this is not possible to control
I assume you will apply the patches yourself.
Thanks again!
Sam
Re: Kernel 5.14.0 - invalid opcode: 0000 [#1] SMP NOPTI
cc'ing lists/people On Sun, Sep 5, 2021 at 11:50 AM Andrew Falcon wrote: > > Hello, > > I am encountering a kernel panic with the error in the subject line using > kernel 5.14.0 (final). Kernel 5.14.0-rc7 works without issue for me so > looking back at the last amdgpu commits for 5.14.0 (final) not sure which one > is at fault and causing the panic - > https://cgit.freedesktop.org/drm/drm/tag/?h=drm-fixes-2021-08-27 > > I filed a kernel bug here - > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942684 with a full log > attached in the report. I am not sure if a separate bug report is needed in > drm kernel? I'm hoping I can get some advice on who needs to be aware of this > bug or how to bring it to the right developer's attention... > > Below is the boot log and the specific error message: > > Sep 04 09:07:39 bluestang-pc kernel: [drm] initializing kernel modesetting > (SIENNA_CICHLID 0x1002:0x73BF 0x1849:0x5201 0xC1). > Sep 04 09:07:39 bluestang-pc kernel: amdgpu :2f:00.0: amdgpu: Trusted > Memory Zone (TMZ) feature not supported > Sep 04 09:07:39 bluestang-pc kernel: [drm] register mmio base: 0xFC90 > Sep 04 09:07:39 bluestang-pc kernel: [drm] register mmio size: 1048576 > Sep 04 09:07:39 bluestang-pc kernel: invalid opcode: [#1] SMP NOPTI > Sep 04 09:07:39 bluestang-pc kernel: CPU: 1 PID: 533 Comm: systemd-udevd Not > tainted 5.14.1-051401-generic #202109030936 > Sep 04 09:07:39 bluestang-pc kernel: Hardware name: Micro-Star International > Co., Ltd. MS-7C84/MAG X570 TOMAHAWK WIFI (MS-7C84), BIOS 1.81 08/05/2021 > Sep 04 09:07:39 bluestang-pc kernel: RIP: > 0010:amdgpu_discovery_reg_base_init+0x225/0x260 [amdgpu] > Sep 04 09:07:39 bluestang-pc kernel: Code: 0f 85 d4 fe ff ff 48 83 45 c0 01 > 48 8b 45 c0 39 45 c8 0f 8f 55 fe ff ff 8b 45 b4 48 8d 65 d8 5b 41 5c 41 5d 41 > 5e 41 5f 5d c3 <0f> 0b 48 c7 c7 e4 5a 61 c1 e8 9d 79 10 ff eb de 41 89 d0 48 > c7 c7 > Sep 04 09:07:39 bluestang-pc kernel: RSP: 0018:b883c1907928 EFLAGS: > 00010202 > Sep 04 09:07:39 bluestang-pc kernel: RAX: 0008 RBX: > 99558b89f128 RCX: 0006 > Sep 04 09:07:39 bluestang-pc kernel: RDX: c1615b69 RSI: > c15c0428 RDI: > Sep 04 09:07:39 bluestang-pc kernel: RBP: b883c1907978 R08: > 0008 R09: 000b > Sep 04 09:07:39 bluestang-pc kernel: R10: 99558b89f120 R11: > R12: 995587c0 > Sep 04 09:07:39 bluestang-pc kernel: R13: 0019 R14: > 0019 R15: 99558b89f120 > Sep 04 09:07:39 bluestang-pc kernel: FS: 7f3d5b7138c0() > GS:995c7ea4() knlGS: > Sep 04 09:07:39 bluestang-pc kernel: CS: 0010 DS: ES: CR0: > 80050033 > Sep 04 09:07:39 bluestang-pc kernel: CR2: 7fc505b6c420 CR3: > 000106d9 CR4: 00750ee0 > Sep 04 09:07:39 bluestang-pc kernel: PKRU: 5554 > Sep 04 09:07:39 bluestang-pc kernel: Call Trace: > Sep 04 09:07:39 bluestang-pc kernel: nv_set_ip_blocks+0x8e/0xab0 [amdgpu] > Sep 04 09:07:39 bluestang-pc kernel: amdgpu_device_ip_early_init+0x2b1/0x47f > [amdgpu] > Sep 04 09:07:39 bluestang-pc kernel: ? > amdgpu_device_get_job_timeout_settings+0x90/0x1cc [amdgpu] > Sep 04 09:07:39 bluestang-pc kernel: amdgpu_device_init.cold+0xc9/0x6d1 > [amdgpu] > Sep 04 09:07:39 bluestang-pc kernel: amdgpu_driver_load_kms+0x6d/0x310 > [amdgpu] > Sep 04 09:07:39 bluestang-pc kernel: amdgpu_pci_probe+0x11b/0x1a0 [amdgpu] > Sep 04 09:07:39 bluestang-pc kernel: local_pci_probe+0x48/0x80 > Sep 04 09:07:39 bluestang-pc kernel: pci_device_probe+0x105/0x1d0 > Sep 04 09:07:39 bluestang-pc kernel: really_probe+0x1fe/0x400 > Sep 04 09:07:39 bluestang-pc kernel: __driver_probe_device+0x109/0x180 > Sep 04 09:07:39 bluestang-pc kernel: driver_probe_device+0x23/0x90 > Sep 04 09:07:39 bluestang-pc kernel: __driver_attach+0xac/0x1b0 > Sep 04 09:07:39 bluestang-pc kernel: ? __device_attach_driver+0xe0/0xe0 > Sep 04 09:07:39 bluestang-pc kernel: bus_for_each_dev+0x7e/0xc0 > Sep 04 09:07:39 bluestang-pc kernel: driver_attach+0x1e/0x20 > Sep 04 09:07:39 bluestang-pc kernel: bus_add_driver+0x135/0x1f0 > Sep 04 09:07:39 bluestang-pc kernel: driver_register+0x95/0xf0 > Sep 04 09:07:39 bluestang-pc kernel: __pci_register_driver+0x68/0x70 > Sep 04 09:07:39 bluestang-pc kernel: amdgpu_init+0x7c/0x1000 [amdgpu] > Sep 04 09:07:39 bluestang-pc kernel: ? 0xc0e95000 > Sep 04 09:07:39 bluestang-pc kernel: do_one_initcall+0x48/0x1d0 > Sep 04 09:07:39 bluestang-pc kernel: ? kmem_cache_alloc_trace+0x159/0x2c0 > Sep 04 09:07:39 bluestang-pc kernel: do_init_module+0x62/0x290 > Sep 04 09:07:39 bluestang-pc kernel: load_module+0xaa8/0xb40 > Sep 04 09:07:39 bluestang-pc kernel: __do_sys_finit_module+0xbf/0x120 > Sep 04 09:07:39 bluestang-pc kernel: __x64_sys_finit_module+0x18/0x20 > Sep 04 09:07:39 bluestang-pc kernel: do_syscall_64+0x5c/0xc0 > Sep 04 09:07:39 bluestang-pc kernel: ? exit_to_user_m
[PATCH v4 0/2] GPD Win Max display fixes
This patch series is for making the GPD Win Max display usable with Linux. The GPD Win Max is a small laptop, and its eDP panel does not send an EDID over DPCD; the EDID is instead available in the intel opregion, in mailbox #5 [1] The second patch is just to fix the orientation of the panel. Changes since v1: - rebased on drm-tip - squashed patch 1 & 2 - picked up Reviewed-by from Hans de Goede (thanks for the review) Changes since v2: - rebased on drm-tip - updated commit message When v2 was initially sent [3] Ville Syrjälä suggested that it might be a good idea to use the ACPI _DDC method instead to get the EDID, to cover a wider range of hardware. Unfortunately, it doesn't seem available on GPD Win Max, so I think this work should be done independently, and this patch series considered separately. Change since v3: - edits following Jani's review: - The EDID from the opregion is now only used as a fallback: if we cannot get any edid from the edp connector, then we attempt to get it from the opregion. This works for the GPD Win Max. - all other remarks should have been taken into account - rebased on drm-tip - added Co-developed-by - reordered signed-off-by and reviewed-by in second patch (thanks Maarten!) [1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454 [2]: https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/ [3]: https://patchwork.kernel.org/project/intel-gfx/patch/20210531204642.4907-2-ani...@astier.eu/ Anisse Astier (2): drm/i915/opregion: add support for mailbox #5 EDID drm: Add orientation quirk for GPD Win Max .../gpu/drm/drm_panel_orientation_quirks.c| 6 ++ drivers/gpu/drm/i915/display/intel_dp.c | 7 +++ drivers/gpu/drm/i915/display/intel_opregion.c | 55 ++- drivers/gpu/drm/i915/display/intel_opregion.h | 10 4 files changed, 77 insertions(+), 1 deletion(-) -- 2.31.1
[PATCH v4 2/2] drm: Add orientation quirk for GPD Win Max
Panel is 800x1280, but mounted on a laptop form factor, sideways.
Signed-off-by: Anisse Astier
Reviewed-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 4e965b0f5502..643b55f9a9d1 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -160,6 +160,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "MicroPC"),
},
.driver_data = (void *)&lcd720x1280_rightside_up,
+ }, {/* GPD Win Max */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1619-01"),
+ },
+ .driver_data = (void *)&lcd800x1280_rightside_up,
}, {/*
* GPD Pocket, note that the the DMI data is less generic then
* it seems, devices with a board-vendor of "AMI Corporation"
--
2.31.1
[PATCH v4 1/2] drm/i915/opregion: add support for mailbox #5 EDID
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.
If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.
Fixes the GPD Win Max display.
Based on original patch series by: Jani Nikula
https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/
Changes:
- EDID is copied and validated with drm_edid_is_valid
- EDID is now only used as a fallback.
- squashed the two patches
Cc: Jani Nikula
Cc: Uma Shankar
Cc: Ville Syrjälä
Co-developed-by: Jani Nikula
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/i915/display/intel_dp.c | 8 +++
drivers/gpu/drm/i915/display/intel_opregion.c | 55 ++-
drivers/gpu/drm/i915/display/intel_opregion.h | 10
3 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d28bd8c4a8a5..836a98d9e5c3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4820,6 +4820,14 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
mutex_lock(&dev->mode_config.mutex);
edid = drm_get_edid(connector, &intel_dp->aux.ddc);
+ if (!edid) {
+ /* Fallback to EDID from ACPI OpRegion, if any */
+ edid = intel_opregion_get_edid(intel_connector);
+ if (edid)
+ drm_dbg_kms(&dev_priv->drm,
+ "[CONNECTOR:%d:%s] Using OpRegion EDID\n",
+ connector->base.id, connector->name);
+ }
if (edid) {
if (drm_add_edid_modes(connector, edid)) {
drm_connector_update_edid_property(connector, edid);
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drivers/gpu/drm/i915/display/intel_opregion.c
index 0065111593a6..985790a66a4d 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -195,6 +195,8 @@ struct opregion_asle_ext {
#define ASLE_IUER_WINDOWS_BTN (1 << 1)
#define ASLE_IUER_POWER_BTN(1 << 0)
+#define ASLE_PHED_EDID_VALID_MASK 0x3
+
/* Software System Control Interrupt (SWSCI) */
#define SWSCI_SCIC_INDICATOR (1 << 0)
#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
@@ -908,8 +910,10 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
opregion->asle->ardy = ASLE_ARDY_NOT_READY;
}
- if (mboxes & MBOX_ASLE_EXT)
+ if (mboxes & MBOX_ASLE_EXT) {
drm_dbg(&dev_priv->drm, "ASLE extension supported\n");
+ opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
+ }
if (intel_load_vbt_firmware(dev_priv) == 0)
goto out;
@@ -1036,6 +1040,54 @@ intel_opregion_get_panel_type(struct drm_i915_private
*dev_priv)
return ret - 1;
}
+/**
+ * intel_opregion_get_edid - Fetch EDID from ACPI OpRegion mailbox #5
+ * @intel_connector: eDP connector
+ *
+ * This reads the ACPI Opregion mailbox #5 to extract the EDID that is passed
+ * to it.
+ *
+ * Returns:
+ * The EDID in the OpRegion, or NULL if there is none or it's invalid.
+ *
+ */
+struct edid *intel_opregion_get_edid(struct intel_connector *intel_connector)
+{
+ struct drm_connector *connector = &intel_connector->base;
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+ struct intel_opregion *opregion = &i915->opregion;
+ const void *in_edid;
+ const struct edid *edid;
+ struct edid *new_edid;
+ int len;
+
+ if (!opregion->asle_ext)
+ return NULL;
+
+ in_edid = opregion->asle_ext->bddc;
+
+ /* Validity corresponds to number of 128-byte blocks */
+ len = (opregion->asle_ext->phed & ASLE_PHED_EDID_VALID_MASK) * 128;
+ if (!len || !memchr_inv(in_edid, 0, len))
+ return NULL;
+
+ edid = in_edid;
+
+ if (len < EDID_LENGTH * (1 + edid->extensions)) {
+ drm_dbg_kms(&i915->drm, "Invalid EDID in ACPI OpRegion (Mailbox
#5): too short\n");
+ return NULL;
+ }
+ new_edid = drm_edid_duplicate(edid);
+ if (!new_edid)
+ return NULL;
+ if (!drm_edid_is_valid(new_edid)) {
+ kfree(new_edid);
+ drm_dbg_kms(&i915->drm, "Invalid EDID in ACPI OpRegion (Mailbox
#5)\n");
+ return NULL;
+ }
+ return new_edid;
+}
+
void intel_opregion_register(struct drm_i915_private *i915)
{
struct intel_opregion *opregion = &i915->opregion;
@@ -1129,6 +1181,7 @@ void intel_opregion_unregister(struct drm_i915_private
*i915)
opregion->acpi = NULL;
opregion->swsci = NULL;
Re: linux-next: build failure after merge of the drm tree
Hi all,
On Thu, 2 Sep 2021 07:50:38 +1000 Stephen Rothwell
wrote:
>
> On Fri, 20 Aug 2021 15:23:34 +0900 Masahiro Yamada
> wrote:
> >
> > On Fri, Aug 20, 2021 at 11:33 AM Stephen Rothwell
> > wrote:
> > >
> > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > In file included from drivers/gpu/drm/i915/i915_debugfs.c:39:
> > > drivers/gpu/drm/i915/gt/intel_gt_requests.h:9:10: fatal error: stddef.h:
> > > No such file or directory
> > > 9 | #include
> > > | ^~
> > >
> > > Caused by commit
> > >
> > > 564f963eabd1 ("isystem: delete global -isystem compile option")
> > >
> > > from the kbuild tree interacting with commit
> > >
> > > b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with
> > > GuC")
> > >
> > > I have applied the following patch for today.
> >
> >
> > Thanks.
> >
> > This fix-up does not depend on my kbuild tree in any way.
> >
> > So, the drm maintainer can apply it to his tree.
> >
> > Perhaps with
> >
> > Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to
> > work with GuC")
>
> OK, so that didn't happen so I will now apply the merge fix up to the
> merge of the kbuild tree.
>
> > > From: Stephen Rothwell
> > > Date: Fri, 20 Aug 2021 12:24:19 +1000
> > > Subject: [PATCH] drm/i915: use linux/stddef.h due to "isystem: trim/fixup
> > > stdarg.h and other headers"
> > >
> > > Signed-off-by: Stephen Rothwell
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_gt_requests.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > > b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > > index 51dbe0e3294e..d2969f68dd64 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > > @@ -6,7 +6,7 @@
> > > #ifndef INTEL_GT_REQUESTS_H
> > > #define INTEL_GT_REQUESTS_H
> > >
> > > -#include
> > > +#include
> > >
> > > struct intel_engine_cs;
> > > struct intel_gt;
> > > --
> > > 2.32.0
Ping? I am still applying this ...
--
Cheers,
Stephen Rothwell
pgpiagh6AIEzd.pgp
Description: OpenPGP digital signature
[PATCH 1/2] drm/nouveau/ga102-: support ttm buffer moves via copy engine
From: Ben Skeggs
We don't currently have any kind of real acceleration on Ampere GPUs,
but the TTM memcpy() fallback paths aren't really designed to handle
copies between different devices, such as on Optimus systems, and
result in a kernel OOPS.
A few options were investigated to try and fix this, but didn't work
out, and likely would have resulted in a very unpleasant experience
for users anyway.
This commit adds just enough support for setting up a single channel
connected to a copy engine, which the kernel can use to accelerate
the buffer copies between devices. Userspace has no access to this
incomplete channel support, but it's suitable for TTM's needs.
A more complete implementation of host(fifo) for Ampere GPUs is in
the works, but the required changes are far too invasive that they
would be unsuitable to backport to fix this issue on current kernels.
Signed-off-by: Ben Skeggs
Cc: Lyude Paul
Cc: Karol Herbst
Cc: # v5.12+
---
drivers/gpu/drm/nouveau/include/nvif/class.h | 2 +
.../drm/nouveau/include/nvkm/engine/fifo.h| 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
drivers/gpu/drm/nouveau/nouveau_chan.c| 6 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +
drivers/gpu/drm/nouveau/nv84_fence.c | 2 +-
.../gpu/drm/nouveau/nvkm/engine/device/base.c | 3 +
.../gpu/drm/nouveau/nvkm/engine/fifo/Kbuild | 1 +
.../gpu/drm/nouveau/nvkm/engine/fifo/ga102.c | 308 ++
.../gpu/drm/nouveau/nvkm/subdev/top/ga100.c | 7 +-
10 files changed, 329 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c
diff --git a/drivers/gpu/drm/nouveau/include/nvif/class.h
b/drivers/gpu/drm/nouveau/include/nvif/class.h
index c68cc957248e..a582c0cb0cb0 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/class.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/class.h
@@ -71,6 +71,7 @@
#define PASCAL_CHANNEL_GPFIFO_A /* cla06f.h */ 0xc06f
#define VOLTA_CHANNEL_GPFIFO_A/* clc36f.h */ 0xc36f
#define TURING_CHANNEL_GPFIFO_A /* clc36f.h */ 0xc46f
+#define AMPERE_CHANNEL_GPFIFO_B /* clc36f.h */ 0xc76f
#define NV50_DISP /* cl5070.h */ 0x5070
#define G82_DISP /* cl5070.h */ 0x8270
@@ -200,6 +201,7 @@
#define PASCAL_DMA_COPY_B0xc1b5
#define VOLTA_DMA_COPY_A 0xc3b5
#define TURING_DMA_COPY_A0xc5b5
+#define AMPERE_DMA_COPY_B0xc7b5
#define FERMI_DECOMPRESS 0x90b8
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
index 54fab7cc36c1..64ee82c7c1be 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
@@ -77,4 +77,5 @@ int gp100_fifo_new(struct nvkm_device *, enum
nvkm_subdev_type, int inst, struct
int gp10b_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst,
struct nvkm_fifo **);
int gv100_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst,
struct nvkm_fifo **);
int tu102_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst,
struct nvkm_fifo **);
+int ga102_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst,
struct nvkm_fifo **);
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4a7cebac8060..b3e4f555fa05 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -844,6 +844,7 @@ nouveau_bo_move_init(struct nouveau_drm *drm)
struct ttm_resource *, struct ttm_resource *);
int (*init)(struct nouveau_channel *, u32 handle);
} _methods[] = {
+ { "COPY", 4, 0xc7b5, nve0_bo_move_copy, nve0_bo_move_init },
{ "COPY", 4, 0xc5b5, nve0_bo_move_copy, nve0_bo_move_init },
{ "GRCE", 0, 0xc5b5, nve0_bo_move_copy, nvc0_bo_move_init },
{ "COPY", 4, 0xc3b5, nve0_bo_move_copy, nve0_bo_move_init },
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 80099ef75702..ea7769135b0d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -250,7 +250,8 @@ static int
nouveau_channel_ind(struct nouveau_drm *drm, struct nvif_device *device,
u64 runlist, bool priv, struct nouveau_channel **pchan)
{
- static const u16 oclasses[] = { TURING_CHANNEL_GPFIFO_A,
+ static const u16 oclasses[] = { AMPERE_CHANNEL_GPFIFO_B,
+ TURING_CHANNEL_GPFIFO_A,
[PATCH 2/2] drm/nouveau/kms/tu102-: delay enabling cursor until after assign_windows
From: Ben Skeggs
Prevent NVD core channel error code 67 occuring and hanging display,
managed to reproduce on GA102 while testing suspend/resume scenarios.
Required extension of earlier commit to fix interactions with EFI.
Fixes: e78b1b545c6c ("drm/nouveau/kms/nv50: workaround EFI GOP window channel
format differences").
Signed-off-by: Ben Skeggs
Cc: Lyude Paul
Cc: Karol Herbst
Cc: # v5.12+
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index f8438a886b64..c3c57be54e1c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -52,6 +52,7 @@ nv50_head_flush_clr(struct nv50_head *head,
void
nv50_head_flush_set_wndw(struct nv50_head *head, struct nv50_head_atom *asyh)
{
+ if (asyh->set.curs ) head->func->curs_set(head, asyh);
if (asyh->set.olut ) {
asyh->olut.offset = nv50_lut_load(&head->olut,
asyh->olut.buffer,
@@ -67,7 +68,6 @@ nv50_head_flush_set(struct nv50_head *head, struct
nv50_head_atom *asyh)
if (asyh->set.view ) head->func->view(head, asyh);
if (asyh->set.mode ) head->func->mode(head, asyh);
if (asyh->set.core ) head->func->core_set(head, asyh);
- if (asyh->set.curs ) head->func->curs_set(head, asyh);
if (asyh->set.base ) head->func->base(head, asyh);
if (asyh->set.ovly ) head->func->ovly(head, asyh);
if (asyh->set.dither ) head->func->dither (head, asyh);
--
2.31.1
Subject: [PATCH v2 0/2] Fix a hung during memory pressure test
[AMD Official Use Only]
A long time ago, someone reports system got hung during memory test.
In recent days, I am trying to look for or understand the potential
deadlock in ttm/amdgpu code.
This patchset aims to fix the deadlock during ttm populate.
TTM has a parameter called pages_limit, when allocated GTT memory
reaches this limit, swapout would be triggered. As ttm_bo_swapout does
not return the correct retval, populate might get hung.
UVD ib test uses GTT which might be insufficient. So a gpu recovery
would hung if populate hung.
I have made one drm test which alloc two GTT BOs, submit gfx copy
commands and free these BOs without waiting fence. What's more, these
gfx copy commands will cause gfx ring hang. So gpu recovery would be
triggered.
Now here is one possible deadlock case.
gpu_recovery
-> stop drm scheduler
-> asic reset
-> ib test
-> tt populate (uvd ib test)
-> ttm_bo_swapout (BO A) // this always fails as the fence of
BO A would not be signaled by schedluer or HW. Hit deadlock.
I paste the drm test patch below.
#modprobe ttm pages_limit=65536
#amdgpu_test -s 1 -t 4
---
tests/amdgpu/basic_tests.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index dbf02fee..f85ed340 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -65,13 +65,16 @@ static void amdgpu_direct_gma_test(void);
static void amdgpu_command_submission_write_linear_helper(unsigned ip_type);
static void amdgpu_command_submission_const_fill_helper(unsigned ip_type);
static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type);
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+static void _amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
unsigned ip_type,
int instance, int pm4_dw, uint32_t
*pm4_src,
int res_cnt, amdgpu_bo_handle *resources,
struct amdgpu_cs_ib_info *ib_info,
- struct amdgpu_cs_request *ibs_request);
+ struct amdgpu_cs_request *ibs_request,
int sync, int repeat);
+#define amdgpu_test_exec_cs_helper(...) \
+ _amdgpu_test_exec_cs_helper(__VA_ARGS__, 1, 1)
+
CU_TestInfo basic_tests[] = {
{ "Query Info Test", amdgpu_query_info_test },
{ "Userptr Test", amdgpu_userptr_test },
@@ -1341,12 +1344,12 @@ static void amdgpu_command_submission_compute(void)
* pm4_src, resources, ib_info, and ibs_request
* submit command stream described in ibs_request and wait for this IB
accomplished
*/
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+static void _amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
unsigned ip_type,
int instance, int pm4_dw, uint32_t
*pm4_src,
int res_cnt, amdgpu_bo_handle *resources,
struct amdgpu_cs_ib_info *ib_info,
- struct amdgpu_cs_request *ibs_request)
+ struct amdgpu_cs_request *ibs_request,
int sync, int repeat)
{
int r;
uint32_t expired;
@@ -1395,12 +1398,15 @@ static void
amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
CU_ASSERT_NOT_EQUAL(ibs_request, NULL);
/* submit CS */
- r = amdgpu_cs_submit(context_handle, 0, ibs_request, 1);
+ while (repeat--)
+ r = amdgpu_cs_submit(context_handle, 0, ibs_request, 1);
CU_ASSERT_EQUAL(r, 0);
r = amdgpu_bo_list_destroy(ibs_request->resources);
CU_ASSERT_EQUAL(r, 0);
+ if (!sync)
+ return;
fence_status.ip_type = ip_type;
fence_status.ip_instance = 0;
fence_status.ring = ibs_request->ring;
@@ -1667,7 +1673,7 @@ static void
amdgpu_command_submission_sdma_const_fill(void)
static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
{
- const int sdma_write_length = 1024;
+ const int sdma_write_length = (255) << 20;
const int pm4_dw = 256;
amdgpu_context_handle context_handle;
amdgpu_bo_handle bo1, bo2;
@@ -1715,8 +1721,6 @@ static void
amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
&bo1_va_handle);
CU_ASSERT_EQUAL(r, 0);
- /* set bo1 */
- memset((void*)bo1_cpu, 0xaa, sdma_write_length);
/* allocate UC bo2 for sDMA use */
r = amdgpu_bo_alloc_and_map(device_handle,
@@ -1727,8 +1731,
[PATCH v2 1/2] drm/ttm: Fix a deadlock if the target BO is not idle during swap
[AMD Official Use Only]
The ret value might be -EBUSY, caller will think lru lock is still
locked but actually NOT. So return -ENOSPC instead. Otherwise we hit
list corruption.
ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0,
caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will
be stuck as we actually did not free any BO memory. This usually happens
when the fence is not signaled for a long time.
Signed-off-by: xinhui pan
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1fedd0eb67ba..f1367107925b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1159,9 +1159,9 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx,
}
if (bo->deleted) {
- ttm_bo_cleanup_refs(bo, false, false, locked);
+ ret = ttm_bo_cleanup_refs(bo, false, false, locked);
ttm_bo_put(bo);
- return 0;
+ return ret == -EBUSY ? -ENOSPC : ret;
}
ttm_bo_move_to_pinned(bo);
@@ -1215,7 +1215,7 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx,
if (locked)
dma_resv_unlock(bo->base.resv);
ttm_bo_put(bo);
- return ret;
+ return ret == -EBUSY ? -ENOSPC : ret;
}
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
--
2.25.1
[PATCH v2 2/2] drm/amdpgu: Use VRAM domain in UVD IB test
[AMD Official Use Only]
Like vce/vcn does, visible VRAM is OK for ib test.
While commit a11d9ff3ebe0 ("drm/amdgpu: use GTT for
uvd_get_create/destory_msg") says VRAM is not mapped correctly in his
platform which is likely an arm64.
So lets change back to use VRAM on x86_64 platform.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index d451c359606a..e4b75f33ccc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -1178,7 +1178,11 @@ int amdgpu_uvd_get_create_msg(struct amdgpu_ring *ring,
uint32_t handle,
int r, i;
r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
+#ifdef CONFIG_X86_64
+ AMDGPU_GEM_DOMAIN_VRAM,
+#else
AMDGPU_GEM_DOMAIN_GTT,
+#endif
&bo, NULL, (void **)&msg);
if (r)
return r;
@@ -1210,7 +1214,11 @@ int amdgpu_uvd_get_destroy_msg(struct amdgpu_ring *ring,
uint32_t handle,
int r, i;
r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
+#ifdef CONFIG_X86_64
+ AMDGPU_GEM_DOMAIN_VRAM,
+#else
AMDGPU_GEM_DOMAIN_GTT,
+#endif
&bo, NULL, (void **)&msg);
if (r)
return r;
--
2.25.1
[PATCH v2 0/2] Fix a hung during memory pressure test
A long time ago, someone reports system got hung during memory test.
In recent days, I am trying to look for or understand the potential
deadlock in ttm/amdgpu code.
This patchset aims to fix the deadlock during ttm populate.
TTM has a parameter called pages_limit, when allocated GTT memory
reaches this limit, swapout would be triggered. As ttm_bo_swapout does
not return the correct retval, populate might get hung.
UVD ib test uses GTT which might be insufficient. So a gpu recovery
would hung if populate hung.
I have made one drm test which alloc two GTT BOs, submit gfx copy
commands and free these BOs without waiting fence. What's more, these
gfx copy commands will cause gfx ring hang. So gpu recovery would be
triggered.
Now here is one possible deadlock case.
gpu_recovery
-> stop drm scheduler
-> asic reset
-> ib test
-> tt populate (uvd ib test)
-> ttm_bo_swapout (BO A) // this always fails as the fence of
BO A would not be signaled by schedluer or HW. Hit deadlock.
I paste the drm test patch below.
#modprobe ttm pages_limit=65536
#amdgpu_test -s 1 -t 4
---
tests/amdgpu/basic_tests.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index dbf02fee..f85ed340 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -65,13 +65,16 @@ static void amdgpu_direct_gma_test(void);
static void amdgpu_command_submission_write_linear_helper(unsigned ip_type);
static void amdgpu_command_submission_const_fill_helper(unsigned ip_type);
static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type);
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+static void _amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
unsigned ip_type,
int instance, int pm4_dw, uint32_t
*pm4_src,
int res_cnt, amdgpu_bo_handle *resources,
struct amdgpu_cs_ib_info *ib_info,
- struct amdgpu_cs_request *ibs_request);
+ struct amdgpu_cs_request *ibs_request,
int sync, int repeat);
+#define amdgpu_test_exec_cs_helper(...) \
+ _amdgpu_test_exec_cs_helper(__VA_ARGS__, 1, 1)
+
CU_TestInfo basic_tests[] = {
{ "Query Info Test", amdgpu_query_info_test },
{ "Userptr Test", amdgpu_userptr_test },
@@ -1341,12 +1344,12 @@ static void amdgpu_command_submission_compute(void)
* pm4_src, resources, ib_info, and ibs_request
* submit command stream described in ibs_request and wait for this IB
accomplished
*/
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+static void _amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
unsigned ip_type,
int instance, int pm4_dw, uint32_t
*pm4_src,
int res_cnt, amdgpu_bo_handle *resources,
struct amdgpu_cs_ib_info *ib_info,
- struct amdgpu_cs_request *ibs_request)
+ struct amdgpu_cs_request *ibs_request,
int sync, int repeat)
{
int r;
uint32_t expired;
@@ -1395,12 +1398,15 @@ static void
amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
CU_ASSERT_NOT_EQUAL(ibs_request, NULL);
/* submit CS */
- r = amdgpu_cs_submit(context_handle, 0, ibs_request, 1);
+ while (repeat--)
+ r = amdgpu_cs_submit(context_handle, 0, ibs_request, 1);
CU_ASSERT_EQUAL(r, 0);
r = amdgpu_bo_list_destroy(ibs_request->resources);
CU_ASSERT_EQUAL(r, 0);
+ if (!sync)
+ return;
fence_status.ip_type = ip_type;
fence_status.ip_instance = 0;
fence_status.ring = ibs_request->ring;
@@ -1667,7 +1673,7 @@ static void
amdgpu_command_submission_sdma_const_fill(void)
static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
{
- const int sdma_write_length = 1024;
+ const int sdma_write_length = (255) << 20;
const int pm4_dw = 256;
amdgpu_context_handle context_handle;
amdgpu_bo_handle bo1, bo2;
@@ -1715,8 +1721,6 @@ static void
amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
&bo1_va_handle);
CU_ASSERT_EQUAL(r, 0);
- /* set bo1 */
- memset((void*)bo1_cpu, 0xaa, sdma_write_length);
/* allocate UC bo2 for sDMA use */
r = amdgpu_bo_alloc_and_map(device_handle,
@@ -1727,8 +1731,6 @@ static void
[PATCH v2 2/2] drm/amdpgu: Use VRAM domain in UVD IB test
Like vce/vcn does, visible VRAM is OK for ib test.
While commit a11d9ff3ebe0 ("drm/amdgpu: use GTT for
uvd_get_create/destory_msg") says VRAM is not mapped correctly in his
platform which is likely an arm64.
So lets change back to use VRAM on x86_64 platform.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index d451c359606a..e4b75f33ccc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -1178,7 +1178,11 @@ int amdgpu_uvd_get_create_msg(struct amdgpu_ring *ring,
uint32_t handle,
int r, i;
r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
+#ifdef CONFIG_X86_64
+ AMDGPU_GEM_DOMAIN_VRAM,
+#else
AMDGPU_GEM_DOMAIN_GTT,
+#endif
&bo, NULL, (void **)&msg);
if (r)
return r;
@@ -1210,7 +1214,11 @@ int amdgpu_uvd_get_destroy_msg(struct amdgpu_ring *ring,
uint32_t handle,
int r, i;
r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
+#ifdef CONFIG_X86_64
+ AMDGPU_GEM_DOMAIN_VRAM,
+#else
AMDGPU_GEM_DOMAIN_GTT,
+#endif
&bo, NULL, (void **)&msg);
if (r)
return r;
--
2.25.1
[PATCH v2 1/2] drm/ttm: Fix a deadlock if the target BO is not idle during swap
The ret value might be -EBUSY, caller will think lru lock is still
locked but actually NOT. So return -ENOSPC instead. Otherwise we hit
list corruption.
ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0,
caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will
be stuck as we actually did not free any BO memory. This usually happens
when the fence is not signaled for a long time.
Signed-off-by: xinhui pan
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1fedd0eb67ba..f1367107925b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1159,9 +1159,9 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx,
}
if (bo->deleted) {
- ttm_bo_cleanup_refs(bo, false, false, locked);
+ ret = ttm_bo_cleanup_refs(bo, false, false, locked);
ttm_bo_put(bo);
- return 0;
+ return ret == -EBUSY ? -ENOSPC : ret;
}
ttm_bo_move_to_pinned(bo);
@@ -1215,7 +1215,7 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx,
if (locked)
dma_resv_unlock(bo->base.resv);
ttm_bo_put(bo);
- return ret;
+ return ret == -EBUSY ? -ENOSPC : ret;
}
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
--
2.25.1
Re: [PATCH v4 10/17] soc: mediatek: mmsys: Add reset controller support for MT8195 vdosys1
Hi Philipp, Thanks for the review. I will base on Enric's patchset in my next revision. Regards, Nancy On Wed, 2021-08-25 at 12:46 +0200, Philipp Zabel wrote: > Hi, > > On Wed, 2021-08-25 at 18:05 +0800, Nancy.Lin wrote: > > Among other features the mmsys driver should implement a reset > > controller to be able to reset different bits from their space. > > > > For MT8195 vdosys1, many async modules need to reset after > > the display pipe stops and restart. > > > > Signed-off-by: Nancy.Lin > > --- > > drivers/soc/mediatek/mt8195-mmsys.h | 1 + > > drivers/soc/mediatek/mtk-mmsys.c| 76 > > + > > Cc: Enric - this patch clashes with [1], please coordinate. > > [1] > https://urldefense.com/v3/__https://lore.kernel.org/linux-arm-kernel/20210825122613.v3.6.I15e2419141a69b2e5c7e700c34d92a69df47e04d@changeid/__;!!CTRNKA9wMg0ARbw!yhYDk3anhefxrYOCQBcUgiosJbqdIRCV2IfO2toZ3FZi4t-AcCNOcE5xeK-IV0MC$ > > > regards > Philipp
Re: [PATCH v2 2/2] drm/amdpgu: Use VRAM domain in UVD IB test
[AMD Official Use Only]
From: dri-devel on behalf of Pan,
Xinhui
Sent: Monday, September 6, 2021 9:10 AM
To: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian ; Deucher, Alexander
; che...@uniontech.com
Subject: [PATCH v2 2/2] drm/amdpgu: Use VRAM domain in UVD IB test
[AMD Official Use Only]
[AMD Official Use Only]
Like vce/vcn does, visible VRAM is OK for ib test.
While commit a11d9ff3ebe0 ("drm/amdgpu: use GTT for
uvd_get_create/destory_msg") says VRAM is not mapped correctly in his
platform which is likely an arm64.
So lets change back to use VRAM on x86_64 platform.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index d451c359606a..e4b75f33ccc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -1178,7 +1178,11 @@ int amdgpu_uvd_get_create_msg(struct amdgpu_ring *ring,
uint32_t handle,
int r, i;
r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
+#ifdef CONFIG_X86_64
[kevin]:
It's better to replace this with macro of CONFIG_64BIT to cover more cases,
do you think it is ok ?
Best Regards,
Kevin
+ AMDGPU_GEM_DOMAIN_VRAM,
+#else
AMDGPU_GEM_DOMAIN_GTT,
+#endif
&bo, NULL, (void **)&msg);
if (r)
return r;
@@ -1210,7 +1214,11 @@ int amdgpu_uvd_get_destroy_msg(struct amdgpu_ring *ring,
uint32_t handle,
int r, i;
r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
+#ifdef CONFIG_X86_64
+ AMDGPU_GEM_DOMAIN_VRAM,
+#else
AMDGPU_GEM_DOMAIN_GTT,
+#endif
&bo, NULL, (void **)&msg);
if (r)
return r;
--
2.25.1
[PATCH] drm/i915: Free the returned object of acpi_evaluate_dsm()
As per the comment on top of acpi_evaluate_dsm():
| * Evaluate device's _DSM method with specified GUID, revision id and
| * function number. Caller needs to free the returned object.
We should free the returned object of acpi_evaluate_dsm() to avoid memory
leakage. Otherwise the kmemleak splat will be triggered at boot time (if we
compile kernel with CONFIG_DEBUG_TEST_DRIVER_REMOVE=y).
Fixes: 8e55f99c510f ("drm/i915: Invoke another _DSM to enable MUX on HP
Workstation laptops")
Cc: Kai-Heng Feng
Signed-off-by: Zenghui Yu
---
drivers/gpu/drm/i915/display/intel_acpi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
b/drivers/gpu/drm/i915/display/intel_acpi.c
index 7cfe91fc05f2..68abeaf2d7d4 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -186,13 +186,16 @@ void intel_dsm_get_bios_data_funcs_supported(struct
drm_i915_private *i915)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
acpi_handle dhandle;
+ union acpi_object *obj;
dhandle = ACPI_HANDLE(&pdev->dev);
if (!dhandle)
return;
- acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
- INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
+ obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2,
INTEL_DSM_REVISION_ID,
+ INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED,
NULL);
+ if (obj)
+ ACPI_FREE(obj);
}
/*
--
2.19.1
[PATCH] drm/i915/audio: Use BIOS provided value for RKL HDA link
Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in
driver") makes HDMI audio on Lenovo P350 disappear.
So in addition to TGL, extend the logic to RKL to use BIOS provided
value to fix the regression.
Fixes: 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver")
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/i915/display/intel_audio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index 532237588511..4e0f96bf6158 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -1308,8 +1308,9 @@ static void i915_audio_component_init(struct
drm_i915_private *dev_priv)
else
aud_freq = aud_freq_init;
- /* use BIOS provided value for TGL unless it is a known bad
value */
- if (IS_TIGERLAKE(dev_priv) && aud_freq_init !=
AUD_FREQ_TGL_BROKEN)
+ /* use BIOS provided value for TGL and RKL unless it is a known
bad value */
+ if ((IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv)) &&
+ aud_freq_init != AUD_FREQ_TGL_BROKEN)
aud_freq = aud_freq_init;
drm_dbg_kms(&dev_priv->drm, "use AUD_FREQ_CNTRL of 0x%x (init
value 0x%x)\n",
--
2.32.0
intel display struct refactor
I posted an intro set of patches to intel-gfx earlier, but I got a bit OCD and kept going here. https://cgit.freedesktop.org/~airlied/linux/log/?h=i915-display-struct-refactor Mainly looking to see if this is interesting enough refactor to get it landed, I realise it would be quite disruptive. I'd also like to see if I missed anything really obvious, I wasn't sure whether vbt/opregion were suitable and I may have left some stuff behind. Dave.
RE: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread
[AMD Official Use Only] > I'm fearing that just repeating what Alex said, but to make it clear > once more: That is *not* necessary! > > The shared repository is owned by upstream maintainers and they are > usually free to do restructuring work without getting acknowledge from > every single driver maintainer. Hi Daniel Anyway thanks for officially confirm to me of working model & policy in community, I don't want to put my opinion here due to that's not my call to change no matter how. I only want to let this diagnostic TDR scheme going to a good end for AMD or even for all DRM vendor. How about this way, we still have a final patch not landed in DRM scheduler and I would like jingwen to present it to you and AlexD/Christian/Andrey, I believe you will have concerns or objections regarding this patch, but that's fine, let us figure it out together, how to make it acceptable by you and other vendors that working with DRM scheduler. P.S.: I had to repeat myself again, we are not popping up new idea suddenly, it is disconnection issue, we didn't have changes (or plan to have changes) in DRM scheduler before, but eventually we found we must make job_timeout and sched_main to work in a serialized otherwise it won't work based on current scheduler's code structure. Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: Daniel Vetter Sent: Friday, September 3, 2021 12:11 AM To: Koenig, Christian Cc: Liu, Monk ; Dave Airlie ; Alex Deucher ; Grodzovsky, Andrey ; Chen, JingWen ; DRI Development ; amd-...@lists.freedesktop.org Subject: Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread On Thu, Sep 2, 2021 at 1:00 PM Christian König wrote: > > Hi Monk, > > Am 02.09.21 um 07:52 schrieb Liu, Monk: > > [AMD Official Use Only] > > > > I'm not sure I can add much to help this along, I'm sure Alex has > > some internal training, Once your driver is upstream, it belongs to > > upstream, you can maintain it, but you no longer control it 100%, it's a > > tradeoff, it's not one companies always understand. > > Usually people are fine developing away internally, but once interaction > > with other parts of the kernel/subsystem is required they have the > > realisation that they needed to work upstream 6 months earlier. > > The best time to interact with upstream was 6 months ago, the second best > > time is now. > > <<< > > > > Daniel/AlexD > > > > I didn't mean your changes on AMD driver need my personal approval > > or review ... and I'm totally already get used that our driver is not 100% > > under control by AMDers, but supposedly any one from community (including > > you) who tend to change AMD's driver need at least to get approvement from > > someone in AMD, e.g.: AlexD or Christian, doesn't that reasonable? > > I'm fearing that just repeating what Alex said, but to make it clear > once more: That is *not* necessary! > > The shared repository is owned by upstream maintainers and they are > usually free to do restructuring work without getting acknowledge from > every single driver maintainer. > > Anybody can of course technically object to upstream design decisions, > but that means that you need to pay attention to the mailing lists in > the first place. > > > just like we need your approve if we try to modify DRM-sched, or need > > panfrost's approval if we need to change panfrost code ... > > > > by only CC AMD's engineers looks not quite properly, how do you know if > > your changes (on AMD code part) are conflicting with AMD's on-going > > internal features/refactoring or not ? > > Well because AMD is supposed to work in public as much as possible and > ask upstream before doing changes to the code base. > > Additional to that design decisions are supposed to be discussed on > the mailing list and *not* internally. Yeah I'm honestly really surprised about the course of this discussion here. With Alex, Christian and others amd has a lot of folks with years/decades of experience in how to collaborate in upstream, when to pull in others proactively and when that's not needed, and in general how to plan upstream work with the lest amount of risk and surprises. I think step zero here needs to be some training at amd and then re-planning this effort, before we get back to technical stuff. Otherwise we'll just get bogged down in pain because expectations about the process don't pan out. -Daniel > > Regards, > Christian. > > > > > Thanks > > > > -- > > Monk Liu | Cloud-GPU Core team > > -- > > > > -Original Message- > > From: Dave Airlie > > Sent: Thursday, September 2, 2021 2:51 AM > > To: Alex Deucher > > Cc: Liu, Monk ; Daniel Vetter ; > > Koenig, Christian ; Grodzovsky, Andrey > > ; Chen, JingWen ; > > DRI Development ; > > amd-.
[Bug 107381] radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics
https://bugzilla.kernel.org/show_bug.cgi?id=107381 GeorgeQQHu (huqiq...@uniontech.com) changed: What|Removed |Added CC||huqiq...@uniontech.com --- Comment #23 from GeorgeQQHu (huqiq...@uniontech.com) --- this card didn't seem to have VCE at all pls refer to https://en.wikipedia.org/wiki/Video_Coding_Engine it is same as Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197327 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
