[PATCH 0/2] drm bridge: drop drm_bridge_chain_mode_fixup.
I had a few bridge related patches in an old branch. They were last posted here almost one year ago: https://lore.kernel.org/dri-devel/20220717174454.46616-1-...@ravnborg.org/ The following two patches gets rid of drm_bridge_chain_mode_fixup. The patches was already rb / ab - but due to the age a repost is due before applying the patches. Sam --- Sam Ravnborg (2): drm/mediatek: Drop chain_mode_fixup call in mode_valid() drm/bridge: Drop drm_bridge_chain_mode_fixup drivers/gpu/drm/drm_bridge.c| 37 - drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 --- include/drm/drm_bridge.h| 3 --- 3 files changed, 51 deletions(-) --- base-commit: c9402efe492bb46ccbf94fedc4783eb8f8747567 change-id: 20240531-bridge_chain_mode-9ed8528e92cd Best regards, -- Sam Ravnborg
[PATCH 0/2] Fix alignment in comment blocks
Hi! This patchset fixes two alignment issues in comment blocks throughout the codebase. These changes fix codestyle warnings reported from checkpatch and are intended to improve code readability. Thanks, Bruno Rocha Levi (2): drm/vkms: Fix misalignment in comment block drivers/gpu: Fix misalignment in comment block drivers/gpu/drm/amd/acp/include/acp_gfx_if.h | 2 +- drivers/gpu/drm/vkms/vkms_drv.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) -- 2.45.1
Re: [PATCH 0/2] Add WL-355608-A8 panel
Tested on my RG35XX-H, no issues Tested-by: Philippe Simons
Re: [PATCH 0/2] Add WL-355608-A8 panel
Tested on my RG35XX-H, no issues Tested-by: Philippe Simons
[PATCH 0/2] Support more panels used by MT8173 Chromebooks in edp-panel
This series contains 2 patches.
The first patch adds more panel entries with the delays from the
datasheets.
The second patch adds 3 panel entries whose datasheets are not available.
For more backgrounds of the rationale behind these conservative timings,
please refer to the commit message of commit 7c8690d8fc80 ("drm/panel-edp:
Add some panels with conservative timings") and the related mailing list
discussion[1].
[1]:
https://lore.kernel.org/all/CAD=FV=V=K9L=bjinvfj+k_dhutpxa4wtukxa+e_vw6uihe8...@mail.gmail.com/
Pin-yen Lin (2):
drm/panel-edp: Add support for several panels
drm/panel-edp: Add more panels with conservative timings
drivers/gpu/drm/panel/panel-edp.c | 6 ++
1 file changed, 6 insertions(+)
--
2.45.1.288.g0e0cd299f1-goog
[PATCH 0/2] drm/panfrost: Add MT8188 support
This series adds support for MT8188's Mali-G57 MC3. AngeloGioacchino Del Regno (2): dt-bindings: gpu: mali-bifrost: Add compatible for MT8188 SoC drm/panfrost: Add support for Mali on the MT8188 SoC .../devicetree/bindings/gpu/arm,mali-bifrost.yaml| 1 + drivers/gpu/drm/panfrost/panfrost_drv.c | 9 + 2 files changed, 10 insertions(+) -- 2.45.1
[PATCH 0/2] Add WL-355608-A8 panel
Hello, The WL_355608_A8 panel is a VGA LCD display with an NV3052C-compatible driver IC, used in a number of Anbernic handheld gaming devices. This patch adds a device tree binding, and support for the display timings and init sequence to the NV3052C SPI/RGB driver. Regards, Ryan Ryan Walklin (2): dt-bindings: display: panel: Add WL-355608-A8 panel drm: panel: nv3052c: Add WL-355608-A8 panel .../bindings/display/panel/wl-355608-a8.yaml | 68 ++ .../gpu/drm/panel/panel-newvision-nv3052c.c | 225 ++ 2 files changed, 293 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/wl-355608-a8.yaml -- 2.45.1
[PATCH 0/2] Add DRM-managed drm_mm_init()
Add drmm_mm_init(), a helper that provides managed allocator cleanup, and start using it in the Xe driver. Michal Wajdeczko (2): drm: Add DRM-managed drm_mm_init() drm/xe: Use drm_device managed mutex/mm init helpers in GGTT drivers/gpu/drm/drm_managed.c | 27 +++ drivers/gpu/drm/xe/xe_ggtt.c | 23 +++ include/drm/drm_managed.h | 3 +++ 3 files changed, 41 insertions(+), 12 deletions(-) -- 2.43.0
Re: [PATCH 0/2] Add support for Panel Power Savings property
On 2024-05-21 13:32, Mario Limonciello wrote: On 5/21/2024 12:27, Leo Li wrote: On 2024-05-21 12:21, Mario Limonciello wrote: On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "color fidelity" = "preferred" maybe? (I don't know, just throwing ideas around.) In that vein, how about: "power saving policy" --> "power saving" --> "color fidelity" It's not just about colors though, is it? The compositor might want to disable it to increase the backlight brightness in bright environments, so "color fidelity" doesn't really sound right Either of these better? "power saving policy" --> "power saving" --> "accuracy" "power saving policy" --> "allowed" --> "forbidden" Or any other idea? Another consideration in addition to accuracy is latency. I suppose a compositor may want to disable features such as PSR for use-cases requiring low latency. Touch and stylus input are some examples. I wonder if flags would work better than enums? A compositor can set something like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example. I thought we had said the PSR latency issue discussed at the hackfest was likely just a bug and that nominally it won't matter? Ah, either my memory failed, or I failed to clarify. Let me fix that below. If it really will matter enough then yeah I think you're right that flags would be better. More drivers would probably want to opt into the property for the purpose of turning off PSR/PSR2/panel replay as well then. Latency technically shouldn't be a problem for Panel Replay, but is a problem for PSR/PSR2 due to their design. At least it is a problem for amdgpu, not sure about other drivers. FWIU, in short, when a panel (DPRX) goes into self-refresh, it's clock can drift from the gpu (DPTX). Since there's no resync mechanism in PSR/PSR2, it is possible for the panel to lag behind by 1-frame-time(ms) for a noticeable period of time. Panel replay has a resync mechanism, so it theoretically can resync within 1 frame. Since, fwict, replay panels are still rare, I think it'll be nice for compositors that care about latency to have the option to temporarily disable PSR/PSR2. - Leo - Leo Would be nice to add documentation for the property in the "standard connector properties" section. Ack.
Re: [PATCH 0/2] Add support for Panel Power Savings property
On Tuesday, May 21st, 2024 at 19:27, Leo Li wrote: > I wonder if flags would work better than enums? A compositor can set something > like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example. (FWIW, the KMS uAPI has first-class support for bitfields.)
Re: [PATCH 0/2] Add support for Panel Power Savings property
Am Di., 21. Mai 2024 um 19:28 Uhr schrieb Leo Li : > > > > On 2024-05-21 12:21, Mario Limonciello wrote: > > On 5/21/2024 11:14, Xaver Hugl wrote: > >> Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello > >> : > >>> > >>> On 5/21/2024 08:43, Simon Ser wrote: > This makes sense to me in general. I like the fact that it's simple and > vendor-neutral. > > Do we want to hardcode "panel" in the name? Are we sure that this will > ever only apply to panels? > > Do we want to use a name which reflects the intent, rather than the > mechanism? In other words, something like "color fidelity" = "preferred" > maybe? (I don't know, just throwing ideas around.) > >>> > >>> In that vein, how about: > >>> > >>> "power saving policy" > >>> --> "power saving" > >>> --> "color fidelity" > >> > >> It's not just about colors though, is it? The compositor might want to > >> disable it to increase the backlight brightness in bright > >> environments, so "color fidelity" doesn't really sound right > > > > Either of these better? > > > > "power saving policy" > > --> "power saving" > > --> "accuracy" > > > > "power saving policy" > > --> "allowed" > > --> "forbidden" > > > > Or any other idea? > > Another consideration in addition to accuracy is latency. > > I suppose a compositor may want to disable features such as PSR for use-cases > requiring low latency. Touch and stylus input are some examples. > > I wonder if flags would work better than enums? A compositor can set something > like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example. I think that's a good idea. With a flag for color accuracy and one for brightness, the compositor's intent would be communicated well. > - Leo > > > > >> > > Would be nice to add documentation for the property in the "standard > connector properties" section. > >>> > >>> Ack. > >>> > >
Re: [PATCH 0/2] Add support for Panel Power Savings property
On 5/21/2024 12:27, Leo Li wrote: On 2024-05-21 12:21, Mario Limonciello wrote: On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "color fidelity" = "preferred" maybe? (I don't know, just throwing ideas around.) In that vein, how about: "power saving policy" --> "power saving" --> "color fidelity" It's not just about colors though, is it? The compositor might want to disable it to increase the backlight brightness in bright environments, so "color fidelity" doesn't really sound right Either of these better? "power saving policy" --> "power saving" --> "accuracy" "power saving policy" --> "allowed" --> "forbidden" Or any other idea? Another consideration in addition to accuracy is latency. I suppose a compositor may want to disable features such as PSR for use-cases requiring low latency. Touch and stylus input are some examples. I wonder if flags would work better than enums? A compositor can set something like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example. I thought we had said the PSR latency issue discussed at the hackfest was likely just a bug and that nominally it won't matter? If it really will matter enough then yeah I think you're right that flags would be better. More drivers would probably want to opt into the property for the purpose of turning off PSR/PSR2/panel replay as well then. - Leo Would be nice to add documentation for the property in the "standard connector properties" section. Ack.
Re: [PATCH 0/2] Add support for Panel Power Savings property
On 2024-05-21 12:21, Mario Limonciello wrote: On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "color fidelity" = "preferred" maybe? (I don't know, just throwing ideas around.) In that vein, how about: "power saving policy" --> "power saving" --> "color fidelity" It's not just about colors though, is it? The compositor might want to disable it to increase the backlight brightness in bright environments, so "color fidelity" doesn't really sound right Either of these better? "power saving policy" --> "power saving" --> "accuracy" "power saving policy" --> "allowed" --> "forbidden" Or any other idea? Another consideration in addition to accuracy is latency. I suppose a compositor may want to disable features such as PSR for use-cases requiring low latency. Touch and stylus input are some examples. I wonder if flags would work better than enums? A compositor can set something like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example. - Leo Would be nice to add documentation for the property in the "standard connector properties" section. Ack.
Re: [PATCH 0/2] Add support for Panel Power Savings property
On 5/21/2024 11:14, Xaver Hugl wrote: Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "color fidelity" = "preferred" maybe? (I don't know, just throwing ideas around.) In that vein, how about: "power saving policy" --> "power saving" --> "color fidelity" It's not just about colors though, is it? The compositor might want to disable it to increase the backlight brightness in bright environments, so "color fidelity" doesn't really sound right Either of these better? "power saving policy" --> "power saving" --> "accuracy" "power saving policy" --> "allowed" --> "forbidden" Or any other idea? Would be nice to add documentation for the property in the "standard connector properties" section. Ack.
Re: [PATCH 0/2] Add support for Panel Power Savings property
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello : > > On 5/21/2024 08:43, Simon Ser wrote: > > This makes sense to me in general. I like the fact that it's simple and > > vendor-neutral. > > > > Do we want to hardcode "panel" in the name? Are we sure that this will > > ever only apply to panels? > > > > Do we want to use a name which reflects the intent, rather than the > > mechanism? In other words, something like "color fidelity" = "preferred" > > maybe? (I don't know, just throwing ideas around.) > > In that vein, how about: > > "power saving policy" > --> "power saving" > --> "color fidelity" It's not just about colors though, is it? The compositor might want to disable it to increase the backlight brightness in bright environments, so "color fidelity" doesn't really sound right > > > > Would be nice to add documentation for the property in the "standard > > connector properties" section. > > Ack. >
Re: [PATCH 0/2] Add support for Panel Power Savings property
On 5/21/2024 08:43, Simon Ser wrote: This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "color fidelity" = "preferred" maybe? (I don't know, just throwing ideas around.) In that vein, how about: "power saving policy" --> "power saving" --> "color fidelity" Would be nice to add documentation for the property in the "standard connector properties" section. Ack.
Re: [PATCH 0/2] Add support for Panel Power Savings property
This makes sense to me in general. I like the fact that it's simple and vendor-neutral. Do we want to hardcode "panel" in the name? Are we sure that this will ever only apply to panels? Do we want to use a name which reflects the intent, rather than the mechanism? In other words, something like "color fidelity" = "preferred" maybe? (I don't know, just throwing ideas around.) Would be nice to add documentation for the property in the "standard connector properties" section.
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
On Thu, May 16, 2024 at 08:04:59PM GMT, Sui Jingfeng wrote: > > > On 5/16/24 18:40, Sui Jingfeng wrote: > > use 'to_i2c_client(bridge->dev)' to retrieve the pointer > > to_i2c_client(bridge->kdev). > > Besides, this also means that we don't need to add the fwnode > pointer into struct drm_bridge as member. Relief the conflicts > with other reviewers if the work of switching to fwnode is still > needed. As for majorities cases (1 to 1), of_node and fwnode can > be retrieved with 'struct device *' easily. The aux-bridge.c and > aux-hdp-bridge.c can also be converted too easily. So that's what you're going for. > of_node, fwnode, swnode and device properties are all belong to > the backing device structure itself. It can be more natural to use > device_proterty_read_xxx() APIs after init time, Which in turn > avoid the need to acquire and duplicate all properties another > time in the driver private structure. > > We could do the programming around the 'struct device *.', remove > a batch of boilerplate. Please make that happen once the device_property_read_* API is there, and we can get rid of of_node, swnode, and fwnode then. Maxime signature.asc Description: PGP signature
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
On Thu, May 16, 2024 at 06:40:45PM GMT, Sui Jingfeng wrote: > Hi, > > On 5/16/24 16:25, Maxime Ripard wrote: > > On Wed, May 15, 2024 at 11:19:58PM +0800, Sui Jingfeng wrote: > > > Hi, > > > > > > > > > On 5/15/24 22:58, Maxime Ripard wrote: > > > > On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote: > > > > > On 5/15/24 22:30, Maxime Ripard wrote: > > > > > > On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote: > > > > > > > On 2024/5/15 00:22, Maxime Ripard wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: > > > > > > > > > Because a lot of implementations has already added it into > > > > > > > > > their drived > > > > > > > > > class, promote it into drm_bridge core may benifits a lot. > > > > > > > > > drm bridge is > > > > > > > > > a driver, it should know the underlying hardware entity. > > > > > > > > Is there some actual benefits, or is it theoretical at this > > > > > > > > point? > > > > > > > > > > > > > > > > > > > > > I think, DRM bridge drivers could remove the 'struct device *dev' > > > > > > > member from their derived structure. Rely on the drm bridge core > > > > > > > when they need the 'struct device *' pointer. > > > > > > > > > > > > Sure, but why do we need to do so? > > > > > > > > > > > > The other thread you had with Jani points out that it turns out that > > > > > > things are more complicated than "every bridge driver has a struct > > > > > > device anyway", it creates inconsistency in the API (bridges would > > > > > > have > > > > > > a struct device, but not other entities), and it looks like there's > > > > > > no > > > > > > use for it anyway. > > > > > > > > > > > > None of these things are deal-breaker by themselves, but if there's > > > > > > only > > > > > > downsides and no upside, it's not clear to me why we should do it > > > > > > at all. > > > > > > > > > > It can reduce boilerplate. > > > > > > > > You're still using a conditional here. > > > > > > It's for safety reason, prevent NULL pointer dereference. > > > drm bridge can be seen as either a software entity or a device driver. > > > > > > It's fine to pass NULL if specific KMS drivers intend to see > > > drm bridge as a pure software entity, and for internal use only. > > > Both use cases are valid. > > > > Sorry, I don't follow you. We can't NULL dereference a pointer that > > doesn't exist. > > > > Please state why we should merge this series: what does it fix or > > improve, aside from the potential gain of making bridges declare one > > less pointer in their private structure. > > We could reduce more. But *why*? What benefit does it bring that outweights the downsides I listed earlier? > Bridge driver instances also don't have to embed 'struct i2c_client *'. We > could use 'to_i2c_client(bridge->dev)' to retrieve the pointer, > where needed. Sure, we could use a function instead of another one. But again, what benefit does that bring exactly? signature.asc Description: PGP signature
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
On Thu, May 16, 2024 at 08:04:59PM +0800, Sui Jingfeng wrote: > > > On 5/16/24 18:40, Sui Jingfeng wrote: > > use 'to_i2c_client(bridge->dev)' to retrieve the pointer > > to_i2c_client(bridge->kdev). > > Besides, this also means that we don't need to add the fwnode > pointer into struct drm_bridge as member. Relief the conflicts > with other reviewers if the work of switching to fwnode is still > needed. As for majorities cases (1 to 1), of_node and fwnode can > be retrieved with 'struct device *' easily. The aux-bridge.c and > aux-hdp-bridge.c can also be converted too easily. > > of_node, fwnode, swnode and device properties are all belong to > the backing device structure itself. It can be more natural to use > device_proterty_read_xxx() APIs after init time, Which in turn > avoid the need to acquire and duplicate all properties another > time in the driver private structure. This doesn't sound 100% correct. This is going to drop the possibile case when bridge driver uses child DT or FW node under the main device node. For example of such usecase see drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c > > We could do the programming around the 'struct device *.', remove > a batch of boilerplate. -- With best wishes Dmitry
[PATCH 0/2] Add support for testing panel power saving DRM property
During the Display Next hackfest 2024 one of the topics discussed was the need for compositor to be able to relay intention to drivers that color fidelity is preferred over power savings. To accomplish this a new optional DRM property is being introduced called "panel power saving". This property is an enum that can be configured by the compositor to "Allowed" or "Forbidden". When a driver advertises support for this property and the compositor sets it to "Forbidden" then the driver will disable any power saving features that can compromise color fidelity. This set of IGT changes introduces a new subtest that will cover the expected kernel behavior when switching between Allowed and Forbidden. Mario Limonciello (2): tests/amdgpu/amd_abm: Make set_abm_level return type int tests/amdgpu/amd_abm: Add support for panel_power_saving property tests/amdgpu/amd_abm.c | 98 +- 1 file changed, 88 insertions(+), 10 deletions(-) -- 2.45.0
[PATCH 0/2] Add support for Panel Power Savings property
During the Display Next hackfest 2024 one of the topics discussed was the need for compositor to be able to relay intention to drivers that color fidelity is preferred over power savings. To accomplish this a new optional DRM property is being introduced called "panel power saving". This property is an enum that can be configured by the compositor to "Allowed" or "Forbidden". When a driver advertises support for this property and the compositor sets it to "Forbidden" then the driver will disable any power saving features that can compromise color fidelity. In practice the main feature this currently applies to is the "Adaptive Backlight Modulation" feature within AMD DCN on eDP panels. When the compositor has marked the property "Forbidden" then this feature will be disabled and any userspace that tries to turn it on will get an -EBUSY return code. When the compositor has restored the value back to "Allowed" then the previous value that would have been programmed will be restored. Mario Limonciello (2): drm: Introduce panel_power_saving drm property drm/amd: Add panel_power_saving drm property to eDP connectors drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 ++--- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 + drivers/gpu/drm/drm_connector.c | 37 +++ include/drm/drm_connector.h | 1 + include/drm/drm_mode_config.h | 6 +++ include/uapi/drm/drm_mode.h | 4 ++ 7 files changed, 81 insertions(+), 5 deletions(-) -- 2.45.0
[PATCH 0/2] Don't be alarmed at FLR timeouts
Hi, often, on new platforms or firmware updates, we receive reports of FLR timeout expiration and we shift the timeout we wait for the reset to complete. Let's not be alarmed if we reach a timeout while waiting for FLR resets and print debugs rather than errors. The function is anyway a void fucntions without any effect. While at it, increase the timeout. Thanks, Andi Andi Shyti (2): drm/i915: Increase FLR timeout from 3s to 9s drm/i915: Don't treat FLR resets as errors drivers/gpu/drm/i915/intel_uncore.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- 2.43.0
[PATCH 0/2] drm/mgag200: Add an option to disable Write-Combine
Unfortunately, the G200 ioburst workaround doesn't work on some servers like Dell poweredge XR11, XR5610, or HPE XL260 In this case completely disabling WC is the only option to achieve low-latency. It's probably useless to maintain two workarounds for this, so I reverted commit bfa4437fd3938 drm/mgag200: Add a workaround for low-latency and added a new and simpler option, to just disable Write-Combine. Jocelyn Falempe (2): Revert "drm/mgag200: Add a workaround for low-latency" drm/mgag200: Add an option to disable Write-Combine drivers/gpu/drm/mgag200/Kconfig| 18 -- drivers/gpu/drm/mgag200/mgag200_drv.c | 24 +++- drivers/gpu/drm/mgag200/mgag200_mode.c | 8 3 files changed, 15 insertions(+), 35 deletions(-) base-commit: 2c3d1bd284c5141a85188f48e7f42112e81ffcd8 -- 2.45.0
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
On 5/16/24 18:40, Sui Jingfeng wrote: use 'to_i2c_client(bridge->dev)' to retrieve the pointer to_i2c_client(bridge->kdev). Besides, this also means that we don't need to add the fwnode pointer into struct drm_bridge as member. Relief the conflicts with other reviewers if the work of switching to fwnode is still needed. As for majorities cases (1 to 1), of_node and fwnode can be retrieved with 'struct device *' easily. The aux-bridge.c and aux-hdp-bridge.c can also be converted too easily. of_node, fwnode, swnode and device properties are all belong to the backing device structure itself. It can be more natural to use device_proterty_read_xxx() APIs after init time, Which in turn avoid the need to acquire and duplicate all properties another time in the driver private structure. We could do the programming around the 'struct device *.', remove a batch of boilerplate.
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
Hi, On 5/16/24 16:25, Maxime Ripard wrote: On Wed, May 15, 2024 at 11:19:58PM +0800, Sui Jingfeng wrote: Hi, On 5/15/24 22:58, Maxime Ripard wrote: On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote: On 5/15/24 22:30, Maxime Ripard wrote: On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote: On 2024/5/15 00:22, Maxime Ripard wrote: Hi, On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: Because a lot of implementations has already added it into their drived class, promote it into drm_bridge core may benifits a lot. drm bridge is a driver, it should know the underlying hardware entity. Is there some actual benefits, or is it theoretical at this point? I think, DRM bridge drivers could remove the 'struct device *dev' member from their derived structure. Rely on the drm bridge core when they need the 'struct device *' pointer. Sure, but why do we need to do so? The other thread you had with Jani points out that it turns out that things are more complicated than "every bridge driver has a struct device anyway", it creates inconsistency in the API (bridges would have a struct device, but not other entities), and it looks like there's no use for it anyway. None of these things are deal-breaker by themselves, but if there's only downsides and no upside, it's not clear to me why we should do it at all. It can reduce boilerplate. You're still using a conditional here. It's for safety reason, prevent NULL pointer dereference. drm bridge can be seen as either a software entity or a device driver. It's fine to pass NULL if specific KMS drivers intend to see drm bridge as a pure software entity, and for internal use only. Both use cases are valid. Sorry, I don't follow you. We can't NULL dereference a pointer that doesn't exist. Please state why we should merge this series: what does it fix or improve, aside from the potential gain of making bridges declare one less pointer in their private structure. We could reduce more. Bridge driver instances also don't have to embed 'struct i2c_client *'. We could use 'to_i2c_client(bridge->dev)' to retrieve the pointer, where needed. Maxime -- Best regards Sui
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
On Wed, May 15, 2024 at 11:19:58PM +0800, Sui Jingfeng wrote: > Hi, > > > On 5/15/24 22:58, Maxime Ripard wrote: > > On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote: > > > On 5/15/24 22:30, Maxime Ripard wrote: > > > > On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote: > > > > > On 2024/5/15 00:22, Maxime Ripard wrote: > > > > > > Hi, > > > > > > > > > > > > On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: > > > > > > > Because a lot of implementations has already added it into their > > > > > > > drived > > > > > > > class, promote it into drm_bridge core may benifits a lot. drm > > > > > > > bridge is > > > > > > > a driver, it should know the underlying hardware entity. > > > > > > Is there some actual benefits, or is it theoretical at this point? > > > > > > > > > > > > > > > I think, DRM bridge drivers could remove the 'struct device *dev' > > > > > member from their derived structure. Rely on the drm bridge core > > > > > when they need the 'struct device *' pointer. > > > > > > > > Sure, but why do we need to do so? > > > > > > > > The other thread you had with Jani points out that it turns out that > > > > things are more complicated than "every bridge driver has a struct > > > > device anyway", it creates inconsistency in the API (bridges would have > > > > a struct device, but not other entities), and it looks like there's no > > > > use for it anyway. > > > > > > > > None of these things are deal-breaker by themselves, but if there's only > > > > downsides and no upside, it's not clear to me why we should do it at > > > > all. > > > > > > It can reduce boilerplate. > > > > You're still using a conditional here. > > It's for safety reason, prevent NULL pointer dereference. > drm bridge can be seen as either a software entity or a device driver. > > It's fine to pass NULL if specific KMS drivers intend to see > drm bridge as a pure software entity, and for internal use only. > Both use cases are valid. Sorry, I don't follow you. We can't NULL dereference a pointer that doesn't exist. Please state why we should merge this series: what does it fix or improve, aside from the potential gain of making bridges declare one less pointer in their private structure. Maxime signature.asc Description: PGP signature
[PATCH 0/2] Update on habanalabs, Xe maintainer status
Hi Dave, Sima. A few weeks ago I left Habana and Intel. Therefore, I'm stepping down from the maintainer role of both habanalabs and Xe drivers. Ofir Bitton from Habana will replace me in the role of habanalabs driver maintainer and as for the Xe driver, Thomas and Lucas will probably suggest someone in the near future. Although I'm not going to do full-time kernel development in my next role, I will remain as the accel maintainer and will probably continue to participate in discussions from time to time. Thanks, Oded Oded Gabbay (2): MAINTAINERS: Change habanalabs maintainer and git repo path MAINTAINERS: update Xe driver maintainers MAINTAINERS | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.34.1
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
Hi, On 5/15/24 22:58, Maxime Ripard wrote: On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote: On 5/15/24 22:30, Maxime Ripard wrote: On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote: On 2024/5/15 00:22, Maxime Ripard wrote: Hi, On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: Because a lot of implementations has already added it into their drived class, promote it into drm_bridge core may benifits a lot. drm bridge is a driver, it should know the underlying hardware entity. Is there some actual benefits, or is it theoretical at this point? I think, DRM bridge drivers could remove the 'struct device *dev' member from their derived structure. Rely on the drm bridge core when they need the 'struct device *' pointer. Sure, but why do we need to do so? The other thread you had with Jani points out that it turns out that things are more complicated than "every bridge driver has a struct device anyway", it creates inconsistency in the API (bridges would have a struct device, but not other entities), and it looks like there's no use for it anyway. None of these things are deal-breaker by themselves, but if there's only downsides and no upside, it's not clear to me why we should do it at all. It can reduce boilerplate. You're still using a conditional here. It's for safety reason, prevent NULL pointer dereference. drm bridge can be seen as either a software entity or a device driver. It's fine to pass NULL if specific KMS drivers intend to see drm bridge as a pure software entity, and for internal use only. Both use cases are valid. Maxime -- Best regards Sui
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote: > On 5/15/24 22:30, Maxime Ripard wrote: > > On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote: > > > On 2024/5/15 00:22, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: > > > > > Because a lot of implementations has already added it into their > > > > > drived > > > > > class, promote it into drm_bridge core may benifits a lot. drm bridge > > > > > is > > > > > a driver, it should know the underlying hardware entity. > > > > Is there some actual benefits, or is it theoretical at this point? > > > > > > > > > I think, DRM bridge drivers could remove the 'struct device *dev' > > > member from their derived structure. Rely on the drm bridge core > > > when they need the 'struct device *' pointer. > > > > Sure, but why do we need to do so? > > > > The other thread you had with Jani points out that it turns out that > > things are more complicated than "every bridge driver has a struct > > device anyway", it creates inconsistency in the API (bridges would have > > a struct device, but not other entities), and it looks like there's no > > use for it anyway. > > > > None of these things are deal-breaker by themselves, but if there's only > > downsides and no upside, it's not clear to me why we should do it at all. > > It can reduce boilerplate. You're still using a conditional here. Maxime signature.asc Description: PGP signature
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
Hi, On 5/15/24 22:30, Maxime Ripard wrote: On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote: Hi, On 2024/5/15 00:22, Maxime Ripard wrote: Hi, On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: Because a lot of implementations has already added it into their drived class, promote it into drm_bridge core may benifits a lot. drm bridge is a driver, it should know the underlying hardware entity. Is there some actual benefits, or is it theoretical at this point? I think, DRM bridge drivers could remove the 'struct device *dev' member from their derived structure. Rely on the drm bridge core when they need the 'struct device *' pointer. Sure, but why do we need to do so? The other thread you had with Jani points out that it turns out that things are more complicated than "every bridge driver has a struct device anyway", it creates inconsistency in the API (bridges would have a struct device, but not other entities), and it looks like there's no use for it anyway. None of these things are deal-breaker by themselves, but if there's only downsides and no upside, it's not clear to me why we should do it at all. It can reduce boilerplate. Maxime -- Best regards Sui
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote: > Hi, > > On 2024/5/15 00:22, Maxime Ripard wrote: > > Hi, > > > > On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: > > > Because a lot of implementations has already added it into their drived > > > class, promote it into drm_bridge core may benifits a lot. drm bridge is > > > a driver, it should know the underlying hardware entity. > > Is there some actual benefits, or is it theoretical at this point? > > > I think, DRM bridge drivers could remove the 'struct device *dev' > member from their derived structure. Rely on the drm bridge core > when they need the 'struct device *' pointer. Sure, but why do we need to do so? The other thread you had with Jani points out that it turns out that things are more complicated than "every bridge driver has a struct device anyway", it creates inconsistency in the API (bridges would have a struct device, but not other entities), and it looks like there's no use for it anyway. None of these things are deal-breaker by themselves, but if there's only downsides and no upside, it's not clear to me why we should do it at all. Maxime signature.asc Description: PGP signature
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
Hi, On 2024/5/15 00:22, Maxime Ripard wrote: Hi, On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: Because a lot of implementations has already added it into their drived class, promote it into drm_bridge core may benifits a lot. drm bridge is a driver, it should know the underlying hardware entity. Is there some actual benefits, or is it theoretical at this point? I think, DRM bridge drivers could remove the 'struct device *dev' member from their derived structure. Rely on the drm bridge core when they need the 'struct device *' pointer. Maxime -- Best regards, Sui
Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
Hi, On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote: > Because a lot of implementations has already added it into their drived > class, promote it into drm_bridge core may benifits a lot. drm bridge is > a driver, it should know the underlying hardware entity. Is there some actual benefits, or is it theoretical at this point? Maxime signature.asc Description: PGP signature
[PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
Because a lot of implementations has already added it into their drived class, promote it into drm_bridge core may benifits a lot. drm bridge is a driver, it should know the underlying hardware entity. Sui Jingfeng (2): drm/bridge: Support finding bridge with struct device drm/bridge: Switch to use drm_bridge_add_with_dev() drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 +- .../drm/bridge/analogix/analogix-anx6345.c| 4 +- .../drm/bridge/analogix/analogix-anx78xx.c| 4 +- drivers/gpu/drm/bridge/analogix/anx7625.c | 3 +- .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 3 +- .../drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +- drivers/gpu/drm/bridge/chipone-icn6211.c | 5 +-- drivers/gpu/drm/bridge/chrontel-ch7033.c | 3 +- drivers/gpu/drm/bridge/cros-ec-anx7688.c | 4 +- drivers/gpu/drm/bridge/display-connector.c| 3 +- drivers/gpu/drm/bridge/fsl-ldb.c | 3 +- drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 3 +- .../gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 3 +- drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 3 +- drivers/gpu/drm/bridge/ite-it6505.c | 3 +- drivers/gpu/drm/bridge/ite-it66121.c | 3 +- drivers/gpu/drm/bridge/lontium-lt8912b.c | 3 +- drivers/gpu/drm/bridge/lontium-lt9211.c | 3 +- drivers/gpu/drm/bridge/lontium-lt9611.c | 3 +- drivers/gpu/drm/bridge/lontium-lt9611uxc.c| 3 +- drivers/gpu/drm/bridge/lvds-codec.c | 3 +- .../bridge/megachips-stdp-ge-b850v3-fw.c | 3 +- drivers/gpu/drm/bridge/microchip-lvds.c | 3 +- drivers/gpu/drm/bridge/nwl-dsi.c | 3 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 3 +- drivers/gpu/drm/bridge/panel.c| 3 +- drivers/gpu/drm/bridge/parade-ps8622.c| 3 +- drivers/gpu/drm/bridge/parade-ps8640.c| 1 - drivers/gpu/drm/bridge/samsung-dsim.c | 3 +- drivers/gpu/drm/bridge/sii902x.c | 3 +- drivers/gpu/drm/bridge/sii9234.c | 3 +- drivers/gpu/drm/bridge/sil-sii8620.c | 3 +- drivers/gpu/drm/bridge/simple-bridge.c| 3 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 +- drivers/gpu/drm/bridge/tc358762.c | 3 +- drivers/gpu/drm/bridge/tc358764.c | 3 +- drivers/gpu/drm/bridge/tc358767.c | 3 +- drivers/gpu/drm/bridge/tc358768.c | 3 +- drivers/gpu/drm/bridge/tc358775.c | 3 +- drivers/gpu/drm/bridge/thc63lvd1024.c | 3 +- drivers/gpu/drm/bridge/ti-dlpc3433.c | 3 +- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 3 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +- drivers/gpu/drm/bridge/ti-tfp410.c| 3 +- drivers/gpu/drm/bridge/ti-tpd12s015.c | 3 +- drivers/gpu/drm/drm_bridge.c | 39 +++ drivers/gpu/drm/i2c/tda998x_drv.c | 5 +-- include/drm/drm_bridge.h | 5 +++ 49 files changed, 91 insertions(+), 99 deletions(-) -- 2.43.0
Re: [PATCH 0/2] drm/fourcc.h: Add libcamera to Open Source Waiver
On Thu, 14 Mar 2024 at 10:12, Jacopo Mondi wrote: > gentle nudge for > > *) libcamera: are we ok being listed here ? > *) DRM/KMS: is it ok splitting the list of projects in the way I've >done ? My bikeshed would be to change the list to 1) OpenGL / OpenGL ES / EGL and its extensions, 2) Vulkan and its extensions, 3) libcamera. But it doesn't really make much difference; people are going to get the point. With whatever reasonable wording, series is: Reviewed-by: Daniel Stone Thanks Jacopo! -d
Re: [PATCH 0/2] drm/meson: fix hdmi auxiliary system operation without display
Hi, On Fri, 26 Apr 2024 18:02:52 +0200, Jerome Brunet wrote: > CEC and ARC should work even when HDMI is not actively used for the > display but it is not the case with Amlogic HDMI. > > This is important for devices such as sound bars which may use DSI > to display a UI and HDMI for CEC/ARC. A display is not required for these > functions > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-fixes) [1/2] drm/meson: dw-hdmi: power up phy on device init https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/04703bfd7f99c016a823c74712b97f8b5590ce87 [2/2] drm/meson: dw-hdmi: add bandgap setting for g12 https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/08001033121dd92b8297a5b7333636b466c30f13 -- Neil
Re: [PATCH 0/2] Add TDM setting support
On Thu, May 2, 2024 at 5:03 PM Hsin-Te Yuan wrote: > > The anx7625 supports two different TDM settings, which determine whether > or not the first audio data bit should be shifted. This series adds the > support for configuring TDM setting through a property in the device > tree. As mentioned offline, this shouldn't need a DT property. Instead the machine driver dictates which format is used to the DAIs, and the DAIs set their respective settings accordingly. It would seem that one of the drivers is misbehaving. ChenYu > Signed-off-by: Hsin-Te Yuan > --- > Hsin-Te Yuan (2): > dt-bindings: drm/bridge: anx7625: Add a perporty to change TDM setting > drm/bridge: anx7625: Change TDM setting accroding to dt property > > .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4 > drivers/gpu/drm/bridge/analogix/anx7625.c | 8 > > drivers/gpu/drm/bridge/analogix/anx7625.h | 1 + > 3 files changed, 13 insertions(+) > --- > base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72 > change-id: 20240430-anx-tdm-7ce41a0a901d > > Best regards, > -- > Hsin-Te Yuan >
[PATCH 0/2] Add TDM setting support
The anx7625 supports two different TDM settings, which determine whether or not the first audio data bit should be shifted. This series adds the support for configuring TDM setting through a property in the device tree. Signed-off-by: Hsin-Te Yuan --- Hsin-Te Yuan (2): dt-bindings: drm/bridge: anx7625: Add a perporty to change TDM setting drm/bridge: anx7625: Change TDM setting accroding to dt property .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4 drivers/gpu/drm/bridge/analogix/anx7625.c | 8 drivers/gpu/drm/bridge/analogix/anx7625.h | 1 + 3 files changed, 13 insertions(+) --- base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72 change-id: 20240430-anx-tdm-7ce41a0a901d Best regards, -- Hsin-Te Yuan
[PATCH 0/2] drm/meson: fix hdmi auxiliary system operation without display
CEC and ARC should work even when HDMI is not actively used for the display but it is not the case with Amlogic HDMI. This is important for devices such as sound bars which may use DSI to display a UI and HDMI for CEC/ARC. A display is not required for these functions This patchset fixes the problem. Jerome Brunet (2): drm/meson: dw-hdmi: power up phy on device init drm/meson: dw-hdmi: add bandgap setting for g12 drivers/gpu/drm/meson/meson_dw_hdmi.c | 70 --- 1 file changed, 31 insertions(+), 39 deletions(-) -- 2.43.0
[PATCH 0/2] drm/rockchip: vop2: two fixes from working on DSI enablement
While working on enabling DSI support on rk3588 I stumbled across the issue of the display staying black while both the vop2 and dsi drivers were claiming to be running just fine. After a bit of checking I found that I got DSI output on VP3 when HDMI on VP0 was at least associated in the DTS, but not without. Andy's patch [0] helped and is definitly necessary, but did not fix the problem completely. The missing thing was that VP3 is rk3588-specific (rk3568 only has 3 video-ports, not 4 like rk3588) and the layers of VP3 never got configured. Patch2 fixes this. [0] https://lore.kernel.org/dri-devel/20240422101905.32703-2-andys...@163.com/ Heiko Stuebner (2): drm/rockchip: vop2: fix rk3588 dp+dsi maxclk verification drm/rockchip: vop2: configure layers for vp3 on rk3588 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 16 ++-- drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 + 2 files changed, 15 insertions(+), 2 deletions(-) -- 2.39.2
[PATCH 0/2] drm/amd/display: Use frame_warn_flag consistently in dml2 Makefile
Hi all, This series resolves a couple instances of -Wframe-larger-than from the new display code that appear with newer versions of clang along without another inconsistency I noticed while fixing this, which have been accounted for with the $(frame_warn_flag) variable. --- Nathan Chancellor (2): drm/amd/display: Add frame_warn_flag to dml2_core_shared.o drm/amd/display: Fix CFLAGS for dml2_core_dcn4_calcs.o drivers/gpu/drm/amd/display/dc/dml2/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- base-commit: d60dc4dd72412d5d9566fdf391e4202b05f88912 change-id: 20240424-amdgpu-dml2-fix-frame-larger-than-dcn401-48ff7e1f51ea Best regards, -- Nathan Chancellor
[PATCH 0/2] Remove more useless wrappers
Shaving off some cruft obj files seem to be identical pre and post cleanup which is always a good sign Signed-off-by: Konrad Dybcio --- Konrad Dybcio (2): drm/msm/dsi: Remove dsi_phy_read/write() drm/msm/dsi: Remove dsi_phy_write_[un]delay() drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 5 - drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 273 +--- drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 218 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 109 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 305 +++--- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 205 +++ drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 320 7 files changed, 699 insertions(+), 736 deletions(-) --- base-commit: 33edc5592466996fe9610efc712da0a3539027ae change-id: 20240423-topic-msm_cleanup-b3e47bc8411d Best regards, -- Konrad Dybcio
[PATCH 0/2] drm/panic: Allows to run with fbcon
fbcon and drm_panic cannot be built together because they both write to the screen when a panic occurs, leading to a corrupted panic image. With this 2 patches, drm_panic will disable the fbdev output before writing the panic screen, so only drm_panic screen will be shown. Jocelyn Falempe (2): drm/fb-helper: Add drm_fb_helper_emergency_disable drm/panic: Allows to run with fbcon drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/drm_fb_helper.c | 17 + drivers/gpu/drm/drm_panic.c | 4 include/drm/drm_fb_helper.h | 5 + 4 files changed, 27 insertions(+), 1 deletion(-) base-commit: 105aa4c65b76c3a344ca89a2d2dc96c84cca557f -- 2.44.0
[PATCH 0/2] drm/panel: two fixes for lg-sw43408
Fix two issues with the panel-lg-sw43408 driver reported by the kernel test robot. Signed-off-by: Dmitry Baryshkov --- Dmitry Baryshkov (2): drm/panel/lg-sw43408: depends on CONFIG_DRM_DISPLAY_DP_HELPER drm/panel/lg-sw43408: mark sw43408_backlight_ops as static drivers/gpu/drm/panel/Kconfig| 1 + drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) --- base-commit: a35e92ef04c07bd473404b9b73d489aea19a60a8 change-id: 20240420-panel-sw43408-fix-ff6549c121be Best regards, -- Dmitry Baryshkov
[PATCH 0/2] Add generic panel-dsi to panel-simple
Adds a generic panel-dsi panel similar to panel-dpi to panel-simple. Allows override of timings, flags and lanes using devicetree. Signed-off-by: Johan Adolfsson --- Johan Adolfsson (2): drm/panel: panel-simple: Add generic panel-dsi driver dt-bindings: panel-simple-dsi: Add generic panel-dsi .../bindings/display/panel/panel-simple-dsi.yaml | 2 + drivers/gpu/drm/panel/panel-simple.c | 76 +- 2 files changed, 75 insertions(+), 3 deletions(-) --- base-commit: e8f897f4afef0031fe618a8e94127a0934896aba change-id: 20240308-foo-fix-5ea945a14e2b Best regards, -- Johan Adolfsson
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-16 10:10, Harry Wentland wrote: On 2024-04-16 04:01, Pekka Paalanen wrote: On Mon, 15 Apr 2024 18:33:39 -0400 Leo Li wrote: On 2024-04-15 04:19, Pekka Paalanen wrote: On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be nailed down and what can left to independent implementation. I guess things like which plane should be enabled first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed) can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way for vendors to communicate overlay, underlay, or mixed-arrangement support. I don't think allowing OVERLAYs to be placed under the PRIMARY is currently documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. libliftoff for example, assumes that the PRIMARY has the lowest zpos. So underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. The assignment restriction is just technical design debt. It is limiting. There is no other good reason for it, than when lighting up a CRTC for the first time, Weston should do it with the renderer FB only, on the plane that is most likely to succeed i.e. PRIMARY. After the CRTC is lit, there should be no built-in limitations in what can go where. The reason for this is that if a CRTC can be activated, it must always be able to show the renderer FB without incurring a modeset. This is important for ensuring that the fallback compositing (renderer) is always possible. So we start with that configuration, and everything else is optional bonus. Genuinely curious - What exactly is limiting with keeping the renderer FB on PRIMARY? IOW, what is the additional benefit of placing the renderer FB on something other than PRIMARY? The limitations come from a combination of hardware limitations. Perhaps zpos is not mutable, or maybe other planes cannot arbitrarily move between above and below the primary. This reduces the number of possible configurations, which might cause off-loading to fail. I think older hardware has more of these arbitrary restrictions. I see. I was thinking that drivers can do under-the-hood stuff to present a mutable zpos to clients, even if their hardware planes cannot be arbitrarily rearranged, by mapping the PRIMARY to a different hardware plane. But not all planes have the same function, so this sounds more complicated than helpful. For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. If zpos exists, I don't think such limitation is a good idea. It will just limit the possible configurations for no reason. With zpos, the KMS plane type should be irrelevant for their z-ordering. Underlay vs. overlay completely loses its meaning at the KMS level. Right, the plane types loose their meanings. But at least with the way libliftoff builds the plane arrangement, where we first allocate the renderer fb matters. libliftoff incrementally builds the atomic state by adding a single plane to the atomic state, then testing it. It essentially does a depth-first-search of all possible arrangements, pruning the search on atomic test
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-16 04:01, Pekka Paalanen wrote: > On Mon, 15 Apr 2024 18:33:39 -0400 > Leo Li wrote: > >> On 2024-04-15 04:19, Pekka Paalanen wrote: >>> On Fri, 12 Apr 2024 16:14:28 -0400 >>> Leo Li wrote: >>> On 2024-04-12 11:31, Alex Deucher wrote: > On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen > wrote: >> >> On Fri, 12 Apr 2024 10:28:52 -0400 >> Leo Li wrote: >> >>> On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: >> >> ... >> > That begs the question of what can be nailed down and what can left to > independent implementation. I guess things like which plane should be > enabled > first (PRIMARY), and how zpos should be interpreted (overlay, > underlay, mixed) > can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. >>> >>> The zpos value of the PRIMARY plane relative to OVERLAYS, for example, >>> as a way >>> for vendors to communicate overlay, underlay, or mixed-arrangement >>> support. I >>> don't think allowing OVERLAYs to be placed under the PRIMARY is >>> currently >>> documented as a way to support underlay. >> >> I always thought it's obvious that the zpos numbers dictate the plane >> order without any other rules. After all, we have the universal planes >> concept, where the plane type is only informational to aid heuristics >> rather than defining anything. >> >> Only if the zpos property does not exist, the plane types would come >> into play. >> >> Of course, if there actually exists userspace that fails if zpos allows >> an overlay type plane to be placed below primary, or fails if primary >> zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. >> >>> libliftoff for example, assumes that the PRIMARY has the lowest zpos. So >>> underlay arrangements will use an OVERLAY for the scanout plane, and >>> the PRIMARY >>> for the underlay view. >> >> That's totally ok. It works, right? Plane type does not matter if the >> KMS driver accepts the configuration. >> >> What is a "scanout plane"? Aren't all KMS planes by definition scanout >> planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. >>> >>> The assignment restriction is just technical design debt. It is >>> limiting. There is no other good reason for it, than when lighting >>> up a CRTC for the first time, Weston should do it with the renderer FB >>> only, on the plane that is most likely to succeed i.e. PRIMARY. After >>> the CRTC is lit, there should be no built-in limitations in what can go >>> where. >>> >>> The reason for this is that if a CRTC can be activated, it must always >>> be able to show the renderer FB without incurring a modeset. This is >>> important for ensuring that the fallback compositing (renderer) is >>> always possible. So we start with that configuration, and everything >>> else is optional bonus. >> >> Genuinely curious - What exactly is limiting with keeping the renderer FB on >> PRIMARY? IOW, what is the additional benefit of placing the renderer FB on >> something other than PRIMARY? > > The limitations come from a combination of hardware limitations. > Perhaps zpos is not mutable, or maybe other planes cannot arbitrarily > move between above and below the primary. This reduces the number of > possible configurations, which might cause off-loading to fail. > > I think older hardware has more of these arbitrary restrictions. > For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. >>> >>> If zpos exists, I don't think such limitation is a good idea. It will >>> just limit the possible configurations for no reason. >>> >>> With zpos, the KMS plane type should be irrelevant for their >>> z-ordering. Underlay vs. overlay completely loses its meaning at the >>> KMS level. >> >> Right, the plane types loose their meanings. But at least with the way >>
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Mon, 15 Apr 2024 18:33:39 -0400 Leo Li wrote: > On 2024-04-15 04:19, Pekka Paalanen wrote: > > On Fri, 12 Apr 2024 16:14:28 -0400 > > Leo Li wrote: > > > >> On 2024-04-12 11:31, Alex Deucher wrote: > >>> On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen > >>> wrote: > > On Fri, 12 Apr 2024 10:28:52 -0400 > Leo Li wrote: > > > On 2024-04-12 04:03, Pekka Paalanen wrote: > >> On Thu, 11 Apr 2024 16:33:57 -0400 > >> Leo Li wrote: > >> > > ... > > >>> That begs the question of what can be nailed down and what can left to > >>> independent implementation. I guess things like which plane should be > >>> enabled > >>> first (PRIMARY), and how zpos should be interpreted (overlay, > >>> underlay, mixed) > >>> can be defined. How to handle atomic test failures could be as well. > >> > >> What room is there for the interpretation of zpos values? > >> > >> I thought they are unambiguous already: only the relative numerical > >> order matters, and that uniquely defines the KMS plane ordering. > > > > The zpos value of the PRIMARY plane relative to OVERLAYS, for example, > > as a way > > for vendors to communicate overlay, underlay, or mixed-arrangement > > support. I > > don't think allowing OVERLAYs to be placed under the PRIMARY is > > currently > > documented as a way to support underlay. > > I always thought it's obvious that the zpos numbers dictate the plane > order without any other rules. After all, we have the universal planes > concept, where the plane type is only informational to aid heuristics > rather than defining anything. > > Only if the zpos property does not exist, the plane types would come > into play. > > Of course, if there actually exists userspace that fails if zpos allows > an overlay type plane to be placed below primary, or fails if primary > zpos is not zero, then DRM needs a new client cap. > >> > >> Right, it wasn't immediately clear to me that the API allowed placement of > >> things beneath the PRIMARY. But reading the docs for > >> drm_plane_create_zpos*, > >> there's nothing that forbids it. > >> > > > libliftoff for example, assumes that the PRIMARY has the lowest zpos. So > > underlay arrangements will use an OVERLAY for the scanout plane, and > > the PRIMARY > > for the underlay view. > > That's totally ok. It works, right? Plane type does not matter if the > KMS driver accepts the configuration. > > What is a "scanout plane"? Aren't all KMS planes by definition scanout > planes? > >> > >> Pardon my terminology, I thought the scanout plane was where weston > >> rendered > >> non-offloadable surfaces to. I guess it's more correct to call it the > >> "render > >> plane". On weston, it seems to be always assigned to the PRIMARY. > >> > > > > The assignment restriction is just technical design debt. It is > > limiting. There is no other good reason for it, than when lighting > > up a CRTC for the first time, Weston should do it with the renderer FB > > only, on the plane that is most likely to succeed i.e. PRIMARY. After > > the CRTC is lit, there should be no built-in limitations in what can go > > where. > > > > The reason for this is that if a CRTC can be activated, it must always > > be able to show the renderer FB without incurring a modeset. This is > > important for ensuring that the fallback compositing (renderer) is > > always possible. So we start with that configuration, and everything > > else is optional bonus. > > Genuinely curious - What exactly is limiting with keeping the renderer FB on > PRIMARY? IOW, what is the additional benefit of placing the renderer FB on > something other than PRIMARY? The limitations come from a combination of hardware limitations. Perhaps zpos is not mutable, or maybe other planes cannot arbitrarily move between above and below the primary. This reduces the number of possible configurations, which might cause off-loading to fail. I think older hardware has more of these arbitrary restrictions. > >> > >> For libliftoff, using OVERLAYs as the render plane and PRIMARY as the > >> underlay > >> plane would work. But I think keeping the render plane on PRIMARY (a la > >> weston) > >> makes underlay arrangements easier to allocate, and would be nice to > >> incorporate > >> into a shared algorithm. > > > > If zpos exists, I don't think such limitation is a good idea. It will > > just limit the possible configurations for no reason. > > > > With zpos, the KMS plane type should be irrelevant for their > > z-ordering. Underlay vs. overlay completely loses its meaning at the > > KMS level. > > Right, the plane types loose their meanings. But at least with the way > libliftoff builds the plane arrangement, where we first allocate the renderer
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-15 04:19, Pekka Paalanen wrote: On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be nailed down and what can left to independent implementation. I guess things like which plane should be enabled first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed) can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way for vendors to communicate overlay, underlay, or mixed-arrangement support. I don't think allowing OVERLAYs to be placed under the PRIMARY is currently documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. libliftoff for example, assumes that the PRIMARY has the lowest zpos. So underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. The assignment restriction is just technical design debt. It is limiting. There is no other good reason for it, than when lighting up a CRTC for the first time, Weston should do it with the renderer FB only, on the plane that is most likely to succeed i.e. PRIMARY. After the CRTC is lit, there should be no built-in limitations in what can go where. The reason for this is that if a CRTC can be activated, it must always be able to show the renderer FB without incurring a modeset. This is important for ensuring that the fallback compositing (renderer) is always possible. So we start with that configuration, and everything else is optional bonus. Genuinely curious - What exactly is limiting with keeping the renderer FB on PRIMARY? IOW, what is the additional benefit of placing the renderer FB on something other than PRIMARY? For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. If zpos exists, I don't think such limitation is a good idea. It will just limit the possible configurations for no reason. With zpos, the KMS plane type should be irrelevant for their z-ordering. Underlay vs. overlay completely loses its meaning at the KMS level. Right, the plane types loose their meanings. But at least with the way libliftoff builds the plane arrangement, where we first allocate the renderer fb matters. libliftoff incrementally builds the atomic state by adding a single plane to the atomic state, then testing it. It essentially does a depth-first-search of all possible arrangements, pruning the search on atomic test fail. The state that offloads the most number of FBs will be the arrangement used. Of course, it's unlikely that the entire DFS tree will traversed in time for a frame. So the key is to search the most probable and high-benefit branches first, while minimizing the # of atomic tests needed, before a hard-coded deadline is hit. Following this algorithm, the PRIMARY needs to be enabled first, followed by all the secondary planes. After a plane is enabled, it's not preferred to change it's assigned FB, since that can cause the state to be rejected (in actuality, not just the FB, but also any color and transformation stuffs associated with the surface). It is preferable to build on the state by enabling another fb->plane. This is where changing a plane's zpos to be above/below the PRIMARY is
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: > On 2024-04-12 11:31, Alex Deucher wrote: > > On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen > > wrote: > >> > >> On Fri, 12 Apr 2024 10:28:52 -0400 > >> Leo Li wrote: > >> > >>> On 2024-04-12 04:03, Pekka Paalanen wrote: > On Thu, 11 Apr 2024 16:33:57 -0400 > Leo Li wrote: > > >> > >> ... > >> > > That begs the question of what can be nailed down and what can left to > > independent implementation. I guess things like which plane should be > > enabled > > first (PRIMARY), and how zpos should be interpreted (overlay, underlay, > > mixed) > > can be defined. How to handle atomic test failures could be as well. > > What room is there for the interpretation of zpos values? > > I thought they are unambiguous already: only the relative numerical > order matters, and that uniquely defines the KMS plane ordering. > >>> > >>> The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as > >>> a way > >>> for vendors to communicate overlay, underlay, or mixed-arrangement > >>> support. I > >>> don't think allowing OVERLAYs to be placed under the PRIMARY is currently > >>> documented as a way to support underlay. > >> > >> I always thought it's obvious that the zpos numbers dictate the plane > >> order without any other rules. After all, we have the universal planes > >> concept, where the plane type is only informational to aid heuristics > >> rather than defining anything. > >> > >> Only if the zpos property does not exist, the plane types would come > >> into play. > >> > >> Of course, if there actually exists userspace that fails if zpos allows > >> an overlay type plane to be placed below primary, or fails if primary > >> zpos is not zero, then DRM needs a new client cap. > > Right, it wasn't immediately clear to me that the API allowed placement of > things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, > there's nothing that forbids it. > > >> > >>> libliftoff for example, assumes that the PRIMARY has the lowest zpos. So > >>> underlay arrangements will use an OVERLAY for the scanout plane, and the > >>> PRIMARY > >>> for the underlay view. > >> > >> That's totally ok. It works, right? Plane type does not matter if the > >> KMS driver accepts the configuration. > >> > >> What is a "scanout plane"? Aren't all KMS planes by definition scanout > >> planes? > > Pardon my terminology, I thought the scanout plane was where weston rendered > non-offloadable surfaces to. I guess it's more correct to call it the "render > plane". On weston, it seems to be always assigned to the PRIMARY. > The assignment restriction is just technical design debt. It is limiting. There is no other good reason for it, than when lighting up a CRTC for the first time, Weston should do it with the renderer FB only, on the plane that is most likely to succeed i.e. PRIMARY. After the CRTC is lit, there should be no built-in limitations in what can go where. The reason for this is that if a CRTC can be activated, it must always be able to show the renderer FB without incurring a modeset. This is important for ensuring that the fallback compositing (renderer) is always possible. So we start with that configuration, and everything else is optional bonus. > > For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay > plane would work. But I think keeping the render plane on PRIMARY (a la > weston) > makes underlay arrangements easier to allocate, and would be nice to > incorporate > into a shared algorithm. If zpos exists, I don't think such limitation is a good idea. It will just limit the possible configurations for no reason. With zpos, the KMS plane type should be irrelevant for their z-ordering. Underlay vs. overlay completely loses its meaning at the KMS level. > In an underlay arrangement, pushing down an OVERLAY's zpos below the PRIMARY's > zpos is simpler than swapping their surfaces. If such an arrangement fails > atomic_test, we won't have to worry about swapping the surfaces back. Of > course, > it's not that we can't keep track of that in the algorithm, but I think it > does > make things easier. There is no "swapping" or "swapping back". The tentative configuration is created as a new object that contains the complete CRTC+connector state, and if it doesn't work, it's simply destroyed. In Weston at least, I don't know of libliftoff. One surface could also be assigned to multiple KMS planes for different CRTCs, so there should be no 1:1 association in the first place. > It may help with reducing the amount of atomic tests. Assuming that the same > DRM > plane provides the same format/color management/transformation support > regardless of it's zpos, I would definitely expect so. > we should be able to reasonably expect that changing > it's z-ordering will not cause atomic_test failures (or at least, expect
Re: [PATCH 0/2] drm/lima: two driver cleanups
applied to drm-misc-next On Thu, Apr 4, 2024 at 8:51 PM Qiang Yu wrote: > > Serial is Reviewed-by: Qiang Yu > > On Tue, Apr 2, 2024 at 6:43 AM Erico Nunes wrote: > > > > Patch 1 is a fix for a crash which triggers on removing the module on > > kernels with CONFIG_DEBUG_SHIRQ enabled, such as the Fedora kernel. > > > > Patch 2 is a fix to this warning: > > drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer > > type 'enum lima_gpu_id' from 'const void *' > > [-Werror,-Wvoid-pointer-to-enum-cast] > > which we have received as a repeated report from the kernel test bot to > > the lima mailing list. > > The warning only reproduces with recent clang on aarch64, but the patch > > does get rid of it and there seem to be no more warnings for W=1. > > > > Erico Nunes (2): > > drm/lima: fix shared irq handling on driver remove > > drm/lima: fix void pointer to enum lima_gpu_id cast warning > > > > drivers/gpu/drm/lima/lima_drv.c | 21 ++--- > > drivers/gpu/drm/lima/lima_drv.h | 5 + > > drivers/gpu/drm/lima/lima_gp.c | 2 ++ > > drivers/gpu/drm/lima/lima_mmu.c | 5 + > > drivers/gpu/drm/lima/lima_pp.c | 4 > > 5 files changed, 34 insertions(+), 3 deletions(-) > > > > -- > > 2.44.0 > >
[PATCH 0/2] Add driver for Raydium RM69380-based DSI panels
This patch adds support the 2560x1600@90Hz dual DSI command mode panel by EDO in combination with a Raydium RM69380 driver IC. This driver IC can be found in the following devices: * Lenovo Xiaoxin Pad Pro 2021 (TB-J716F) with EDO panel * Lenovo Tab P11 Pro (TB-J706F) with EDO panel * Robo & Kala 2-in-1 Laptop with Sharp panel Signed-off-by: David Wronek --- David Wronek (2): dt-bindings: display: panel: Add Raydium RM69380 drm/panel: Add driver for EDO RM69380 OLED panel .../bindings/display/panel/raydium,rm69380.yaml| 94 + drivers/gpu/drm/panel/Kconfig | 14 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-raydium-rm69380.c | 378 + 4 files changed, 487 insertions(+) --- base-commit: 9ed46da14b9b9b2ad4edb3b0c545b6dbe5c00d39 change-id: 20240414-raydium-rm69380-driver-47f22b6f24fe Best regards, -- David Wronek
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be nailed down and what can left to independent implementation. I guess things like which plane should be enabled first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed) can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way for vendors to communicate overlay, underlay, or mixed-arrangement support. I don't think allowing OVERLAYs to be placed under the PRIMARY is currently documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. libliftoff for example, assumes that the PRIMARY has the lowest zpos. So underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. In an underlay arrangement, pushing down an OVERLAY's zpos below the PRIMARY's zpos is simpler than swapping their surfaces. If such an arrangement fails atomic_test, we won't have to worry about swapping the surfaces back. Of course, it's not that we can't keep track of that in the algorithm, but I think it does make things easier. It may help with reducing the amount of atomic tests. Assuming that the same DRM plane provides the same format/color management/transformation support regardless of it's zpos, we should be able to reasonably expect that changing it's z-ordering will not cause atomic_test failures (or at least, expect less causes for failure). In other words, swapping the render plane from the PRIMARY to an OVERLAY might have more causes for an atomic_test fail, versus changing their z-ordering. The driver might have to do more things under-the-hood to provide this consistent behavior, but I think that's the right place for it. After all, drivers should know more about their hardware's behavior. The assumption that the PRIMARY has the lowest zpos isn't always true. I was made aware that the imx8mq platform places all of their OVERLAYS beneath the PRIMARY. Granted, the KMS code for enabling OVERLAYS is not upstream yet, but it is available from this thread: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258#note_2319898 . I guess this is more of a bad assumption that should be fixed in libliftoff. IOW, if the KMS client understands zpos and can do a proper KMS configuration search, and all planes have zpos property, then there is no need to look at the plane type at all. That is the goal of the universal planes feature. The optimal configuration with DCN hardware is using underlays. E.g., the desktop plane would be at the top and would have holes cut out of it for videos or windows that want their own plane. If you do it the other way around, there are lots of limitations. Alex Right, patch 1/2 tries to work around one of these limitations (cursor-on-yuv). Others have mentioned we can do the same for scaling. Thanks, Leo Thanks, pq
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: > > On Fri, 12 Apr 2024 10:28:52 -0400 > Leo Li wrote: > > > On 2024-04-12 04:03, Pekka Paalanen wrote: > > > On Thu, 11 Apr 2024 16:33:57 -0400 > > > Leo Li wrote: > > > > > ... > > > >> That begs the question of what can be nailed down and what can left to > > >> independent implementation. I guess things like which plane should be > > >> enabled > > >> first (PRIMARY), and how zpos should be interpreted (overlay, underlay, > > >> mixed) > > >> can be defined. How to handle atomic test failures could be as well. > > > > > > What room is there for the interpretation of zpos values? > > > > > > I thought they are unambiguous already: only the relative numerical > > > order matters, and that uniquely defines the KMS plane ordering. > > > > The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a > > way > > for vendors to communicate overlay, underlay, or mixed-arrangement support. > > I > > don't think allowing OVERLAYs to be placed under the PRIMARY is currently > > documented as a way to support underlay. > > I always thought it's obvious that the zpos numbers dictate the plane > order without any other rules. After all, we have the universal planes > concept, where the plane type is only informational to aid heuristics > rather than defining anything. > > Only if the zpos property does not exist, the plane types would come > into play. > > Of course, if there actually exists userspace that fails if zpos allows > an overlay type plane to be placed below primary, or fails if primary > zpos is not zero, then DRM needs a new client cap. > > > libliftoff for example, assumes that the PRIMARY has the lowest zpos. So > > underlay arrangements will use an OVERLAY for the scanout plane, and the > > PRIMARY > > for the underlay view. > > That's totally ok. It works, right? Plane type does not matter if the > KMS driver accepts the configuration. > > What is a "scanout plane"? Aren't all KMS planes by definition scanout > planes? > > IOW, if the KMS client understands zpos and can do a proper KMS > configuration search, and all planes have zpos property, then there is > no need to look at the plane type at all. That is the goal of the > universal planes feature. The optimal configuration with DCN hardware is using underlays. E.g., the desktop plane would be at the top and would have holes cut out of it for videos or windows that want their own plane. If you do it the other way around, there are lots of limitations. Alex > > > Thanks, > pq
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: > On 2024-04-12 04:03, Pekka Paalanen wrote: > > On Thu, 11 Apr 2024 16:33:57 -0400 > > Leo Li wrote: > > ... > >> That begs the question of what can be nailed down and what can left to > >> independent implementation. I guess things like which plane should be > >> enabled > >> first (PRIMARY), and how zpos should be interpreted (overlay, underlay, > >> mixed) > >> can be defined. How to handle atomic test failures could be as well. > > > > What room is there for the interpretation of zpos values? > > > > I thought they are unambiguous already: only the relative numerical > > order matters, and that uniquely defines the KMS plane ordering. > > The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a > way > for vendors to communicate overlay, underlay, or mixed-arrangement support. I > don't think allowing OVERLAYs to be placed under the PRIMARY is currently > documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. > libliftoff for example, assumes that the PRIMARY has the lowest zpos. So > underlay arrangements will use an OVERLAY for the scanout plane, and the > PRIMARY > for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? IOW, if the KMS client understands zpos and can do a proper KMS configuration search, and all planes have zpos property, then there is no need to look at the plane type at all. That is the goal of the universal planes feature. Thanks, pq pgpyAAfXdjPXO.pgp Description: OpenPGP digital signature
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: On 2024-04-04 10:22, Marius Vlad wrote: On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: Hi all, On 2024-04-04 06:24, Pekka Paalanen wrote: On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: On 2024-03-28 10:33, Pekka Paalanen wrote: On Fri, 15 Mar 2024 13:09:56 -0400 wrote: From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. You already quoted me on the Weston link, so I don't think I have anything to add. Sounds fine to me, and we don't have a standard plane arrangement algorithm that the kernel could optimize zpos ranges against, yet. Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. I think there probably should be a standardised plane arrangement algorithm in userspace, because the search space suffers from permutational explosion. Either there needs to be very few planes (max 4 or 5 at-all-possible per CRTC, including shareable ones) for an exhaustive search to be feasible, or all planes should be more or less equal in capabilities and userspace employs some simplified or heuristic search. If the search algorithm is fixed, then drivers could optimize zpos ranges to have the algorithm find a solution faster. My worry is that userspace already has heuristic search algorithms that may start failing if drivers later change their zpos ranges to be more optimal for another algorithm. OTOH, as long as exhaustive search is feasible, then it does not matter how DRM drivers set up the zpos ranges. In any case, the zpos ranges should try to allow all possible plane arrangements while minimizing the number of arrangements that won't work. The absolute values of zpos are pretty much irrelevant, so I think setting one plane to have an immutable zpos is a good idea, even if it's not necessary by the driver. That is one less moving part, and only the relative ordering between the planes matters. Thanks, pq Right, thanks for your thoughts! I agree that there should be a common plane arrangement algorithm. I think libliftoff is the most obvious candidate here. It only handles overlay arrangements currently, but mixed-mode arrangements is something I've been trying to look at. Taking the driver's reported zpos into account could narrow down the search space for mixed arrangements. We could tell whether underlay, or overlay, or both, is supported by looking at the allowed zpos ranges. I also wonder if it'll make underlay assignments easier. libliftoff has an assumption that the PRIMARY plane has the lowest zpos (which now I realize, is not always true). Therefore, the underlay buffer has to be placed on the PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between planes when testing mixed-arrangements is kind of awkward, and simply setting the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. Currently only gamescope makes use of libliftoff, but I'm curious if patches hooking it up to Weston would be welcomed? If there are other ways to have a common arrangement algorithm, I'd be happy to hear that as well. A natural thing would be to document such an algorithm with the KMS
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: > On 2024-04-04 10:22, Marius Vlad wrote: > > On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: > >> > > Hi all, > >> > >> On 2024-04-04 06:24, Pekka Paalanen wrote: > >>> On Wed, 3 Apr 2024 17:32:46 -0400 > >>> Leo Li wrote: > >>> > On 2024-03-28 10:33, Pekka Paalanen wrote: > > On Fri, 15 Mar 2024 13:09:56 -0400 > > wrote: > > > >> From: Leo Li > >> > >> These patches aim to make the amdgpgu KMS driver play nicer with > >> compositors > >> when building multi-plane scanout configurations. They do so by: > >> > >> 1. Making cursor behavior more sensible. > >> 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY > >> plane for > >> 'underlay' configurations (perhaps more of a RFC, see below). > >> > >> Please see the commit messages for details. > >> > >> > >> For #2, the simplest way to accomplish this was to increase the value > >> of the > >> immutable zpos property for the PRIMARY plane. This allowed OVERLAY > >> planes with > >> a mutable zpos range of (0-254) to be positioned underneath the > >> PRIMARY for an > >> underlay scanout configuration. > >> > >> Technically speaking, DCN hardware does not have a concept of primary > >> or overlay > >> planes - there are simply 4 general purpose hardware pipes that can be > >> maped in > >> any configuration. So the immutable zpos restriction on the PRIMARY > >> plane is > >> kind of arbitrary; it can have a mutable range of (0-254) just like the > >> OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also > >> somewhat > >> arbitrary. We can interpret PRIMARY as the first plane that should be > >> enabled on > >> a CRTC, but beyond that, it doesn't mean much for amdgpu. > >> > >> Therefore, I'm curious about how compositors devs understand KMS > >> planes and > >> their zpos properties, and how we would like to use them. It isn't > >> clear to me > >> how compositors wish to interpret and use the DRM zpos property, or > >> differentiate between OVERLAY and PRIMARY planes, when it comes to > >> setting up > >> multi-plane scanout. > > > > You already quoted me on the Weston link, so I don't think I have > > anything to add. Sounds fine to me, and we don't have a standard plane > > arrangement algorithm that the kernel could optimize zpos ranges > > against, yet. > > > >> Ultimately, what I'd like to answer is "What can we do on the KMS > >> driver and DRM > >> plane API side, that can make building multi-plane scanout > >> configurations easier > >> for compositors?" I'm hoping we can converge on something, whether > >> that be > >> updating the existing documentation to better define the usage, or > >> update the > >> API to provide support for something that is lacking. > > > > I think there probably should be a standardised plane arrangement > > algorithm in userspace, because the search space suffers from > > permutational explosion. Either there needs to be very few planes (max > > 4 or 5 at-all-possible per CRTC, including shareable ones) for an > > exhaustive search to be feasible, or all planes should be more or less > > equal in capabilities and userspace employs some simplified or > > heuristic search. > > > > If the search algorithm is fixed, then drivers could optimize zpos > > ranges to have the algorithm find a solution faster. > > > > My worry is that userspace already has heuristic search algorithms that > > may start failing if drivers later change their zpos ranges to be more > > optimal for another algorithm. > > > > OTOH, as long as exhaustive search is feasible, then it does not matter > > how DRM drivers set up the zpos ranges. > > > > In any case, the zpos ranges should try to allow all possible plane > > arrangements while minimizing the number of arrangements that won't > > work. The absolute values of zpos are pretty much irrelevant, so I > > think setting one plane to have an immutable zpos is a good idea, even > > if it's not necessary by the driver. That is one less moving part, and > > only the relative ordering between the planes matters. > > > > > > Thanks, > > pq > > Right, thanks for your thoughts! I agree that there should be a common > plane > arrangement algorithm. I think libliftoff is the most obvious candidate > here. It > only handles overlay arrangements currently, but mixed-mode arrangements > is > something I've been trying to look at. > > Taking the driver's reported zpos into account could narrow down the > search > space for mixed arrangements.
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-04 10:22, Marius Vlad wrote: On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: Hi all, On 2024-04-04 06:24, Pekka Paalanen wrote: On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: On 2024-03-28 10:33, Pekka Paalanen wrote: On Fri, 15 Mar 2024 13:09:56 -0400 wrote: From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. You already quoted me on the Weston link, so I don't think I have anything to add. Sounds fine to me, and we don't have a standard plane arrangement algorithm that the kernel could optimize zpos ranges against, yet. Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. I think there probably should be a standardised plane arrangement algorithm in userspace, because the search space suffers from permutational explosion. Either there needs to be very few planes (max 4 or 5 at-all-possible per CRTC, including shareable ones) for an exhaustive search to be feasible, or all planes should be more or less equal in capabilities and userspace employs some simplified or heuristic search. If the search algorithm is fixed, then drivers could optimize zpos ranges to have the algorithm find a solution faster. My worry is that userspace already has heuristic search algorithms that may start failing if drivers later change their zpos ranges to be more optimal for another algorithm. OTOH, as long as exhaustive search is feasible, then it does not matter how DRM drivers set up the zpos ranges. In any case, the zpos ranges should try to allow all possible plane arrangements while minimizing the number of arrangements that won't work. The absolute values of zpos are pretty much irrelevant, so I think setting one plane to have an immutable zpos is a good idea, even if it's not necessary by the driver. That is one less moving part, and only the relative ordering between the planes matters. Thanks, pq Right, thanks for your thoughts! I agree that there should be a common plane arrangement algorithm. I think libliftoff is the most obvious candidate here. It only handles overlay arrangements currently, but mixed-mode arrangements is something I've been trying to look at. Taking the driver's reported zpos into account could narrow down the search space for mixed arrangements. We could tell whether underlay, or overlay, or both, is supported by looking at the allowed zpos ranges. I also wonder if it'll make underlay assignments easier. libliftoff has an assumption that the PRIMARY plane has the lowest zpos (which now I realize, is not always true). Therefore, the underlay buffer has to be placed on the PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between planes when testing mixed-arrangements is kind of awkward, and simply setting the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. Currently only gamescope makes use of libliftoff, but I'm curious if patches hooking it up to Weston would be welcomed? If there are other ways to have a common arrangement algorithm, I'd be happy to hear that as well. A natural thing would be to document such an algorithm with the KMS UAPI. I don't know libliftoff well enough to say how welcome it would be in Weston. I have no fundamental
Re: [PATCH 0/2] drm/msm/dp: fix runtime PM leaks on hotplug
On Wed, 13 Mar 2024 17:43:04 +0100, Johan Hovold wrote: > As I've reported elsewhere, I've been hitting runtime PM usage count > leaks when investigated a DisplayPort hotplug regression on the Lenovo > ThinkPad X13s. [1] > > This series addresses two obvious leaks on disconnect and on connect > failures, respectively. > > [...] Applied, thanks! [1/2] drm/msm/dp: fix runtime PM leak on disconnect https://gitlab.freedesktop.org/drm/msm/-/commit/0640f47b7426 [2/2] drm/msm/dp: fix runtime PM leak on connect failure https://gitlab.freedesktop.org/drm/msm/-/commit/e86750b01a15 Best regards, -- Abhinav Kumar
[PATCH 0/2] nouveau: GSP DP aux fixes
Fixes for a few issues I've been seeing around regarding DP aux transactions with nouveau and GSP support - mainly stemming from the fact that GSP returns an error for aux transactions that are attempted on disconnected ports. Some of these issues somehow manage to make runtime PM fail on my Slimbook Executive 16! Lyude Paul (2): drm/nouveau/kms/nv50-: Disable AUX bus for disconnected DP ports drm/nouveau/dp: Don't probe eDP ports twice harder drivers/gpu/drm/nouveau/nouveau_dp.c | 24 +++- 1 file changed, 19 insertions(+), 5 deletions(-) -- 2.44.0
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: > Hi all, > > On 2024-04-04 06:24, Pekka Paalanen wrote: > > On Wed, 3 Apr 2024 17:32:46 -0400 > > Leo Li wrote: > > > >> On 2024-03-28 10:33, Pekka Paalanen wrote: > >>> On Fri, 15 Mar 2024 13:09:56 -0400 > >>> wrote: > >>> > From: Leo Li > > These patches aim to make the amdgpgu KMS driver play nicer with > compositors > when building multi-plane scanout configurations. They do so by: > > 1. Making cursor behavior more sensible. > 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane > for > 'underlay' configurations (perhaps more of a RFC, see below). > > Please see the commit messages for details. > > > For #2, the simplest way to accomplish this was to increase the value of > the > immutable zpos property for the PRIMARY plane. This allowed OVERLAY > planes with > a mutable zpos range of (0-254) to be positioned underneath the PRIMARY > for an > underlay scanout configuration. > > Technically speaking, DCN hardware does not have a concept of primary or > overlay > planes - there are simply 4 general purpose hardware pipes that can be > maped in > any configuration. So the immutable zpos restriction on the PRIMARY > plane is > kind of arbitrary; it can have a mutable range of (0-254) just like the > OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also > somewhat > arbitrary. We can interpret PRIMARY as the first plane that should be > enabled on > a CRTC, but beyond that, it doesn't mean much for amdgpu. > > Therefore, I'm curious about how compositors devs understand KMS planes > and > their zpos properties, and how we would like to use them. It isn't clear > to me > how compositors wish to interpret and use the DRM zpos property, or > differentiate between OVERLAY and PRIMARY planes, when it comes to > setting up > multi-plane scanout. > >>> > >>> You already quoted me on the Weston link, so I don't think I have > >>> anything to add. Sounds fine to me, and we don't have a standard plane > >>> arrangement algorithm that the kernel could optimize zpos ranges > >>> against, yet. > >>> > Ultimately, what I'd like to answer is "What can we do on the KMS driver > and DRM > plane API side, that can make building multi-plane scanout > configurations easier > for compositors?" I'm hoping we can converge on something, whether that > be > updating the existing documentation to better define the usage, or > update the > API to provide support for something that is lacking. > >>> > >>> I think there probably should be a standardised plane arrangement > >>> algorithm in userspace, because the search space suffers from > >>> permutational explosion. Either there needs to be very few planes (max > >>> 4 or 5 at-all-possible per CRTC, including shareable ones) for an > >>> exhaustive search to be feasible, or all planes should be more or less > >>> equal in capabilities and userspace employs some simplified or > >>> heuristic search. > >>> > >>> If the search algorithm is fixed, then drivers could optimize zpos > >>> ranges to have the algorithm find a solution faster. > >>> > >>> My worry is that userspace already has heuristic search algorithms that > >>> may start failing if drivers later change their zpos ranges to be more > >>> optimal for another algorithm. > >>> > >>> OTOH, as long as exhaustive search is feasible, then it does not matter > >>> how DRM drivers set up the zpos ranges. > >>> > >>> In any case, the zpos ranges should try to allow all possible plane > >>> arrangements while minimizing the number of arrangements that won't > >>> work. The absolute values of zpos are pretty much irrelevant, so I > >>> think setting one plane to have an immutable zpos is a good idea, even > >>> if it's not necessary by the driver. That is one less moving part, and > >>> only the relative ordering between the planes matters. > >>> > >>> > >>> Thanks, > >>> pq > >> > >> Right, thanks for your thoughts! I agree that there should be a common > >> plane > >> arrangement algorithm. I think libliftoff is the most obvious candidate > >> here. It > >> only handles overlay arrangements currently, but mixed-mode arrangements is > >> something I've been trying to look at. > >> > >> Taking the driver's reported zpos into account could narrow down the search > >> space for mixed arrangements. We could tell whether underlay, or overlay, > >> or > >> both, is supported by looking at the allowed zpos ranges. > >> > >> I also wonder if it'll make underlay assignments easier. libliftoff has an > >> assumption that the PRIMARY plane has the lowest zpos (which now I > >> realize, is > >> not always true). Therefore, the underlay buffer has
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-04 06:24, Pekka Paalanen wrote: > On Wed, 3 Apr 2024 17:32:46 -0400 > Leo Li wrote: > >> On 2024-03-28 10:33, Pekka Paalanen wrote: >>> On Fri, 15 Mar 2024 13:09:56 -0400 >>> wrote: >>> From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. >>> >>> You already quoted me on the Weston link, so I don't think I have >>> anything to add. Sounds fine to me, and we don't have a standard plane >>> arrangement algorithm that the kernel could optimize zpos ranges >>> against, yet. >>> Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. >>> >>> I think there probably should be a standardised plane arrangement >>> algorithm in userspace, because the search space suffers from >>> permutational explosion. Either there needs to be very few planes (max >>> 4 or 5 at-all-possible per CRTC, including shareable ones) for an >>> exhaustive search to be feasible, or all planes should be more or less >>> equal in capabilities and userspace employs some simplified or >>> heuristic search. >>> >>> If the search algorithm is fixed, then drivers could optimize zpos >>> ranges to have the algorithm find a solution faster. >>> >>> My worry is that userspace already has heuristic search algorithms that >>> may start failing if drivers later change their zpos ranges to be more >>> optimal for another algorithm. >>> >>> OTOH, as long as exhaustive search is feasible, then it does not matter >>> how DRM drivers set up the zpos ranges. >>> >>> In any case, the zpos ranges should try to allow all possible plane >>> arrangements while minimizing the number of arrangements that won't >>> work. The absolute values of zpos are pretty much irrelevant, so I >>> think setting one plane to have an immutable zpos is a good idea, even >>> if it's not necessary by the driver. That is one less moving part, and >>> only the relative ordering between the planes matters. >>> >>> >>> Thanks, >>> pq >> >> Right, thanks for your thoughts! I agree that there should be a common plane >> arrangement algorithm. I think libliftoff is the most obvious candidate >> here. It >> only handles overlay arrangements currently, but mixed-mode arrangements is >> something I've been trying to look at. >> >> Taking the driver's reported zpos into account could narrow down the search >> space for mixed arrangements. We could tell whether underlay, or overlay, or >> both, is supported by looking at the allowed zpos ranges. >> >> I also wonder if it'll make underlay assignments easier. libliftoff has an >> assumption that the PRIMARY plane has the lowest zpos (which now I realize, >> is >> not always true). Therefore, the underlay buffer has to be placed on the >> PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between >> planes when testing mixed-arrangements is kind of awkward, and simply setting >> the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. >> >> Currently only gamescope makes use of libliftoff, but
Re: [PATCH 0/2] drm/lima: two driver cleanups
Serial is Reviewed-by: Qiang Yu On Tue, Apr 2, 2024 at 6:43 AM Erico Nunes wrote: > > Patch 1 is a fix for a crash which triggers on removing the module on > kernels with CONFIG_DEBUG_SHIRQ enabled, such as the Fedora kernel. > > Patch 2 is a fix to this warning: > drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer > type 'enum lima_gpu_id' from 'const void *' > [-Werror,-Wvoid-pointer-to-enum-cast] > which we have received as a repeated report from the kernel test bot to > the lima mailing list. > The warning only reproduces with recent clang on aarch64, but the patch > does get rid of it and there seem to be no more warnings for W=1. > > Erico Nunes (2): > drm/lima: fix shared irq handling on driver remove > drm/lima: fix void pointer to enum lima_gpu_id cast warning > > drivers/gpu/drm/lima/lima_drv.c | 21 ++--- > drivers/gpu/drm/lima/lima_drv.h | 5 + > drivers/gpu/drm/lima/lima_gp.c | 2 ++ > drivers/gpu/drm/lima/lima_mmu.c | 5 + > drivers/gpu/drm/lima/lima_pp.c | 4 > 5 files changed, 34 insertions(+), 3 deletions(-) > > -- > 2.44.0 >
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: > On 2024-03-28 10:33, Pekka Paalanen wrote: > > On Fri, 15 Mar 2024 13:09:56 -0400 > > wrote: > > > >> From: Leo Li > >> > >> These patches aim to make the amdgpgu KMS driver play nicer with > >> compositors > >> when building multi-plane scanout configurations. They do so by: > >> > >> 1. Making cursor behavior more sensible. > >> 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane > >> for > >> 'underlay' configurations (perhaps more of a RFC, see below). > >> > >> Please see the commit messages for details. > >> > >> > >> For #2, the simplest way to accomplish this was to increase the value of > >> the > >> immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes > >> with > >> a mutable zpos range of (0-254) to be positioned underneath the PRIMARY > >> for an > >> underlay scanout configuration. > >> > >> Technically speaking, DCN hardware does not have a concept of primary or > >> overlay > >> planes - there are simply 4 general purpose hardware pipes that can be > >> maped in > >> any configuration. So the immutable zpos restriction on the PRIMARY plane > >> is > >> kind of arbitrary; it can have a mutable range of (0-254) just like the > >> OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also > >> somewhat > >> arbitrary. We can interpret PRIMARY as the first plane that should be > >> enabled on > >> a CRTC, but beyond that, it doesn't mean much for amdgpu. > >> > >> Therefore, I'm curious about how compositors devs understand KMS planes and > >> their zpos properties, and how we would like to use them. It isn't clear > >> to me > >> how compositors wish to interpret and use the DRM zpos property, or > >> differentiate between OVERLAY and PRIMARY planes, when it comes to setting > >> up > >> multi-plane scanout. > > > > You already quoted me on the Weston link, so I don't think I have > > anything to add. Sounds fine to me, and we don't have a standard plane > > arrangement algorithm that the kernel could optimize zpos ranges > > against, yet. > > > >> Ultimately, what I'd like to answer is "What can we do on the KMS driver > >> and DRM > >> plane API side, that can make building multi-plane scanout configurations > >> easier > >> for compositors?" I'm hoping we can converge on something, whether that be > >> updating the existing documentation to better define the usage, or update > >> the > >> API to provide support for something that is lacking. > > > > I think there probably should be a standardised plane arrangement > > algorithm in userspace, because the search space suffers from > > permutational explosion. Either there needs to be very few planes (max > > 4 or 5 at-all-possible per CRTC, including shareable ones) for an > > exhaustive search to be feasible, or all planes should be more or less > > equal in capabilities and userspace employs some simplified or > > heuristic search. > > > > If the search algorithm is fixed, then drivers could optimize zpos > > ranges to have the algorithm find a solution faster. > > > > My worry is that userspace already has heuristic search algorithms that > > may start failing if drivers later change their zpos ranges to be more > > optimal for another algorithm. > > > > OTOH, as long as exhaustive search is feasible, then it does not matter > > how DRM drivers set up the zpos ranges. > > > > In any case, the zpos ranges should try to allow all possible plane > > arrangements while minimizing the number of arrangements that won't > > work. The absolute values of zpos are pretty much irrelevant, so I > > think setting one plane to have an immutable zpos is a good idea, even > > if it's not necessary by the driver. That is one less moving part, and > > only the relative ordering between the planes matters. > > > > > > Thanks, > > pq > > Right, thanks for your thoughts! I agree that there should be a common plane > arrangement algorithm. I think libliftoff is the most obvious candidate here. > It > only handles overlay arrangements currently, but mixed-mode arrangements is > something I've been trying to look at. > > Taking the driver's reported zpos into account could narrow down the search > space for mixed arrangements. We could tell whether underlay, or overlay, or > both, is supported by looking at the allowed zpos ranges. > > I also wonder if it'll make underlay assignments easier. libliftoff has an > assumption that the PRIMARY plane has the lowest zpos (which now I realize, is > not always true). Therefore, the underlay buffer has to be placed on the > PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between > planes when testing mixed-arrangements is kind of awkward, and simply setting > the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. > > Currently only gamescope makes use of libliftoff, but I'm curious if patches > hooking it up to Weston would be
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-03-28 10:33, Pekka Paalanen wrote: On Fri, 15 Mar 2024 13:09:56 -0400 wrote: From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. You already quoted me on the Weston link, so I don't think I have anything to add. Sounds fine to me, and we don't have a standard plane arrangement algorithm that the kernel could optimize zpos ranges against, yet. Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. I think there probably should be a standardised plane arrangement algorithm in userspace, because the search space suffers from permutational explosion. Either there needs to be very few planes (max 4 or 5 at-all-possible per CRTC, including shareable ones) for an exhaustive search to be feasible, or all planes should be more or less equal in capabilities and userspace employs some simplified or heuristic search. If the search algorithm is fixed, then drivers could optimize zpos ranges to have the algorithm find a solution faster. My worry is that userspace already has heuristic search algorithms that may start failing if drivers later change their zpos ranges to be more optimal for another algorithm. OTOH, as long as exhaustive search is feasible, then it does not matter how DRM drivers set up the zpos ranges. In any case, the zpos ranges should try to allow all possible plane arrangements while minimizing the number of arrangements that won't work. The absolute values of zpos are pretty much irrelevant, so I think setting one plane to have an immutable zpos is a good idea, even if it's not necessary by the driver. That is one less moving part, and only the relative ordering between the planes matters. Thanks, pq Right, thanks for your thoughts! I agree that there should be a common plane arrangement algorithm. I think libliftoff is the most obvious candidate here. It only handles overlay arrangements currently, but mixed-mode arrangements is something I've been trying to look at. Taking the driver's reported zpos into account could narrow down the search space for mixed arrangements. We could tell whether underlay, or overlay, or both, is supported by looking at the allowed zpos ranges. I also wonder if it'll make underlay assignments easier. libliftoff has an assumption that the PRIMARY plane has the lowest zpos (which now I realize, is not always true). Therefore, the underlay buffer has to be placed on the PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between planes when testing mixed-arrangements is kind of awkward, and simply setting the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. Currently only gamescope makes use of libliftoff, but I'm curious if patches hooking it up to Weston would be welcomed? If there are other ways to have a common arrangement algorithm, I'd be happy to hear that as well. Note that libliftoff's algorithm is more complex than weston, since it searches harder, and suffers from that permutational explosion. But it solves that by trying high benefit arrangements first (offloading surfaces that update frequently), and bailing out once the search reaches a hard-coded deadline. Since it's currently overlay-only, the goal could be to "simply" have no regressions.
[PATCH 0/2] drm/lima: two driver cleanups
Patch 1 is a fix for a crash which triggers on removing the module on kernels with CONFIG_DEBUG_SHIRQ enabled, such as the Fedora kernel. Patch 2 is a fix to this warning: drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer type 'enum lima_gpu_id' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] which we have received as a repeated report from the kernel test bot to the lima mailing list. The warning only reproduces with recent clang on aarch64, but the patch does get rid of it and there seem to be no more warnings for W=1. Erico Nunes (2): drm/lima: fix shared irq handling on driver remove drm/lima: fix void pointer to enum lima_gpu_id cast warning drivers/gpu/drm/lima/lima_drv.c | 21 ++--- drivers/gpu/drm/lima/lima_drv.h | 5 + drivers/gpu/drm/lima/lima_gp.c | 2 ++ drivers/gpu/drm/lima/lima_mmu.c | 5 + drivers/gpu/drm/lima/lima_pp.c | 4 5 files changed, 34 insertions(+), 3 deletions(-) -- 2.44.0
[PATCH 0/2] drm/lima: fix devfreq refcount imbalance for job timeouts
This is a followup to https://patchwork.freedesktop.org/series/128856/ Patch 1 rev1 from that series https://patchwork.freedesktop.org/patch/574745/?series=128856=1 was dropped because it needed a better solution for a race condition between the irq and the timeout handler. The proposed solution in that discussion is to solve the race condition by masking the irqs during the timeout handler execution, which is what is done here. This bug is very hard to reproduce with regular applications, but I found it to be reliable to reproduce with a program that triggers many jobs right in the boundary between timeouting, so that jobs still manage to complete while the timeout handler runs. With this series, I was unable to further reproduce the bug. At first I had only the pp and gp irqs masked and the problem never reproduced again on Mali-400, but I still managed to reproduce it on Mali-450 after hours of test time. After masking the pp bcast irq as well I was not able to reproduce it anymore even on Mali-450, so I think that was the missing bit for it. Erico Nunes (2): drm/lima: add mask irq callback to gp and pp drm/lima: mask irqs in timeout path before hard reset drivers/gpu/drm/lima/lima_bcast.c | 12 drivers/gpu/drm/lima/lima_bcast.h | 3 +++ drivers/gpu/drm/lima/lima_gp.c| 8 drivers/gpu/drm/lima/lima_pp.c| 18 ++ drivers/gpu/drm/lima/lima_sched.c | 9 + drivers/gpu/drm/lima/lima_sched.h | 1 + 6 files changed, 51 insertions(+) -- 2.44.0
Re: [PATCH 0/2] video: backlight: constify struct class usage
On 28 Mar 17:49, Greg Kroah-Hartman wrote: > On Thu, Mar 28, 2024 at 09:46:01AM -0300, Ricardo B. Marliere wrote: > > On 28 Mar 13:01, Greg Kroah-Hartman wrote: > > > On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote: > > > > On Tue, 05 Mar 2024, Ricardo B. Marliere wrote: > > > > > > > > > This is a simple and straight forward cleanup series that aims to > > > > > make the > > > > > class structures in backlight constant. This has been possible since > > > > > 2023 > > > > > [1]. > > > > > > > > > > [1]: > > > > > https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/ > > > > > > > > > > Signed-off-by: Ricardo B. Marliere > > > > > --- > > > > > Ricardo B. Marliere (2): > > > > > video: backlight: make backlight_class constant > > > > > video: backlight: lcd: make lcd_class constant > > > > > > > > > > drivers/video/backlight/backlight.c | 29 > > > > > - > > > > > drivers/video/backlight/lcd.c | 23 +-- > > > > > 2 files changed, 29 insertions(+), 23 deletions(-) > > > > > > > > No longer apply. > > > > > > > > Please rebase on top of v6.9-rc1 or for-backlight-next. > > > > > > As I already had this in my local tree, I've sent out a v2 at: > > > https://lore.kernel.org/lkml/2024032805-putdown-mushy-a0f9@gregkh/ > > > > Thank you Greg. I will see what is left to be made const for -next. > > Many of your patches were not picked up for -rc1, I'll be taking a bunch > of them into my tree "soon" as that usually means the subsystem isn't as > active. Yup, I was keeping them in my inbox so as to resend but if you could pick them that would be great! Cheers, > > thanks, > > greg k-h
Re: [PATCH 0/2] video: backlight: constify struct class usage
On Thu, Mar 28, 2024 at 09:46:01AM -0300, Ricardo B. Marliere wrote: > On 28 Mar 13:01, Greg Kroah-Hartman wrote: > > On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote: > > > On Tue, 05 Mar 2024, Ricardo B. Marliere wrote: > > > > > > > This is a simple and straight forward cleanup series that aims to make > > > > the > > > > class structures in backlight constant. This has been possible since > > > > 2023 > > > > [1]. > > > > > > > > [1]: > > > > https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/ > > > > > > > > Signed-off-by: Ricardo B. Marliere > > > > --- > > > > Ricardo B. Marliere (2): > > > > video: backlight: make backlight_class constant > > > > video: backlight: lcd: make lcd_class constant > > > > > > > > drivers/video/backlight/backlight.c | 29 - > > > > drivers/video/backlight/lcd.c | 23 +-- > > > > 2 files changed, 29 insertions(+), 23 deletions(-) > > > > > > No longer apply. > > > > > > Please rebase on top of v6.9-rc1 or for-backlight-next. > > > > As I already had this in my local tree, I've sent out a v2 at: > > https://lore.kernel.org/lkml/2024032805-putdown-mushy-a0f9@gregkh/ > > Thank you Greg. I will see what is left to be made const for -next. Many of your patches were not picked up for -rc1, I'll be taking a bunch of them into my tree "soon" as that usually means the subsystem isn't as active. thanks, greg k-h
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Fri, 15 Mar 2024 13:09:56 -0400 wrote: > From: Leo Li > > These patches aim to make the amdgpgu KMS driver play nicer with compositors > when building multi-plane scanout configurations. They do so by: > > 1. Making cursor behavior more sensible. > 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for >'underlay' configurations (perhaps more of a RFC, see below). > > Please see the commit messages for details. > > > For #2, the simplest way to accomplish this was to increase the value of the > immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes > with > a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an > underlay scanout configuration. > > Technically speaking, DCN hardware does not have a concept of primary or > overlay > planes - there are simply 4 general purpose hardware pipes that can be maped > in > any configuration. So the immutable zpos restriction on the PRIMARY plane is > kind of arbitrary; it can have a mutable range of (0-254) just like the > OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat > arbitrary. We can interpret PRIMARY as the first plane that should be enabled > on > a CRTC, but beyond that, it doesn't mean much for amdgpu. > > Therefore, I'm curious about how compositors devs understand KMS planes and > their zpos properties, and how we would like to use them. It isn't clear to me > how compositors wish to interpret and use the DRM zpos property, or > differentiate between OVERLAY and PRIMARY planes, when it comes to setting up > multi-plane scanout. You already quoted me on the Weston link, so I don't think I have anything to add. Sounds fine to me, and we don't have a standard plane arrangement algorithm that the kernel could optimize zpos ranges against, yet. > Ultimately, what I'd like to answer is "What can we do on the KMS driver and > DRM > plane API side, that can make building multi-plane scanout configurations > easier > for compositors?" I'm hoping we can converge on something, whether that be > updating the existing documentation to better define the usage, or update the > API to provide support for something that is lacking. I think there probably should be a standardised plane arrangement algorithm in userspace, because the search space suffers from permutational explosion. Either there needs to be very few planes (max 4 or 5 at-all-possible per CRTC, including shareable ones) for an exhaustive search to be feasible, or all planes should be more or less equal in capabilities and userspace employs some simplified or heuristic search. If the search algorithm is fixed, then drivers could optimize zpos ranges to have the algorithm find a solution faster. My worry is that userspace already has heuristic search algorithms that may start failing if drivers later change their zpos ranges to be more optimal for another algorithm. OTOH, as long as exhaustive search is feasible, then it does not matter how DRM drivers set up the zpos ranges. In any case, the zpos ranges should try to allow all possible plane arrangements while minimizing the number of arrangements that won't work. The absolute values of zpos are pretty much irrelevant, so I think setting one plane to have an immutable zpos is a good idea, even if it's not necessary by the driver. That is one less moving part, and only the relative ordering between the planes matters. Thanks, pq > Some links to provide context and details: > * What is underlay?: > https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/76 > * Discussion on how to implement underlay on Weston: > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258#note_2325164 > > Cc: Joshua Ashton > Cc: Michel Dänzer > Cc: Chao Guo > Cc: Xaver Hugl > Cc: Vikas Korjani > Cc: Robert Mader > Cc: Pekka Paalanen > Cc: Sean Paul > Cc: Simon Ser > Cc: Shashank Sharma > Cc: Harry Wentland > Cc: Sebastian Wick > > Leo Li (2): > drm/amd/display: Introduce overlay cursor mode > drm/amd/display: Move PRIMARY plane zpos higher > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 405 -- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 + > .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 28 +- > 4 files changed, 391 insertions(+), 50 deletions(-) > pgpvrSkzh7lgc.pgp Description: OpenPGP digital signature
Re: [PATCH 0/2] video: backlight: constify struct class usage
On 28 Mar 13:01, Greg Kroah-Hartman wrote: > On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote: > > On Tue, 05 Mar 2024, Ricardo B. Marliere wrote: > > > > > This is a simple and straight forward cleanup series that aims to make the > > > class structures in backlight constant. This has been possible since 2023 > > > [1]. > > > > > > [1]: https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/ > > > > > > Signed-off-by: Ricardo B. Marliere > > > --- > > > Ricardo B. Marliere (2): > > > video: backlight: make backlight_class constant > > > video: backlight: lcd: make lcd_class constant > > > > > > drivers/video/backlight/backlight.c | 29 - > > > drivers/video/backlight/lcd.c | 23 +-- > > > 2 files changed, 29 insertions(+), 23 deletions(-) > > > > No longer apply. > > > > Please rebase on top of v6.9-rc1 or for-backlight-next. > > As I already had this in my local tree, I've sent out a v2 at: > https://lore.kernel.org/lkml/2024032805-putdown-mushy-a0f9@gregkh/ Thank you Greg. I will see what is left to be made const for -next. > > thanks, > > greg k-h
Re: [PATCH 0/2] video: backlight: constify struct class usage
On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote: > On Tue, 05 Mar 2024, Ricardo B. Marliere wrote: > > > This is a simple and straight forward cleanup series that aims to make the > > class structures in backlight constant. This has been possible since 2023 > > [1]. > > > > [1]: https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/ > > > > Signed-off-by: Ricardo B. Marliere > > --- > > Ricardo B. Marliere (2): > > video: backlight: make backlight_class constant > > video: backlight: lcd: make lcd_class constant > > > > drivers/video/backlight/backlight.c | 29 - > > drivers/video/backlight/lcd.c | 23 +-- > > 2 files changed, 29 insertions(+), 23 deletions(-) > > No longer apply. > > Please rebase on top of v6.9-rc1 or for-backlight-next. As I already had this in my local tree, I've sent out a v2 at: https://lore.kernel.org/lkml/2024032805-putdown-mushy-a0f9@gregkh/ thanks, greg k-h
Re: [PATCH 0/2] video: backlight: constify struct class usage
On Tue, 05 Mar 2024, Ricardo B. Marliere wrote: > This is a simple and straight forward cleanup series that aims to make the > class structures in backlight constant. This has been possible since 2023 > [1]. > > [1]: https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/ > > Signed-off-by: Ricardo B. Marliere > --- > Ricardo B. Marliere (2): > video: backlight: make backlight_class constant > video: backlight: lcd: make lcd_class constant > > drivers/video/backlight/backlight.c | 29 - > drivers/video/backlight/lcd.c | 23 +-- > 2 files changed, 29 insertions(+), 23 deletions(-) No longer apply. Please rebase on top of v6.9-rc1 or for-backlight-next. -- Lee Jones [李琼斯]
Re: [PATCH 0/2] drm/fourcc.h: Add libcamera to Open Source Waiver
Quoting Jacopo Mondi (2024-03-14 10:12:47) > Hello > > gentle nudge for > > *) libcamera: are we ok being listed here ? I think it's fine ... Acked-by: Kieran Bingham > *) DRM/KMS: is it ok splitting the list of projects in the way I've >done ? > > Thanks >j > > On Wed, Feb 28, 2024 at 11:22:42AM +0100, Jacopo Mondi wrote: > > As suggested by Sima, add libcamera to the list of projects to which the > > Open Source Waiver notice applies. > > > > To maintain the paragraph readable, make a list out of the projects to which > > such notice applies. > > > > Jacopo Mondi (2): > > drm/fourcc.h: List of Open Source Waiver projects > > drm/fourcc.h: Add libcamera to Open Source Waiver > > > > include/uapi/drm/drm_fourcc.h | 12 +--- > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > -- > > 2.43.2 > >
[PATCH 0/2] of: replace of_graph_get_next_endpoint()
Hi Rob, Helge This is resend of remain of replace of_graph_get_next_endpoint() (In previous patch-set, media maintainer accepted some of them). This patches are for GPU/Video, I'm not sure who should handle it. GPU/Video maintainer as Video, or Rom as OF ? We should get rid of or minimize of_graph_get_next_endpoint() in its current form. In general, drivers should be asking for a specific port number because their function is fixed in the binding. https://lore.kernel.org/r/20240131184347.ga1906672-r...@kernel.org This patch-set replace of_graph_get_next_endpoint() by of_graph_get_endpoint_by_regs(). There are still next_endpoint() after this patch-set, but it will be replaced by for_each_endpoint_of_node() in next patch-set (A) [*] this patch-set [o] done [o] tidyup of_graph_get_endpoint_count() [*] replace endpoint func - use endpoint_by_regs() (A) [ ] replace endpoint func - use for_each() [ ] rename endpoint func to device_endpoint [ ] add new port function [ ] add new endpont function [ ] remove of_graph_get_next_device_endpoint() v1 -> v2 - add Reviewed-by from Launrent - use by_regs(xx, -1, -1) for some devices - add extra explain for drm_of_get_dsi_bus() - add FIXME and Link on adv7604.c - based on latest of branch Kuninori Morimoto (2): gpu: drm: replace of_graph_get_next_endpoint() video: fbdev: replace of_graph_get_next_endpoint() drivers/gpu/drm/drm_of.c | 4 +++- .../drm/panel/panel-raspberrypi-touchscreen.c | 2 +- drivers/gpu/drm/tiny/arcpgu.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/dsi.c| 3 ++- drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 20 +-- drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 ++- drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 ++- drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 ++- drivers/video/fbdev/pxafb.c | 2 +- include/video/omapfb_dss.h| 3 --- 10 files changed, 15 insertions(+), 30 deletions(-) -- 2.25.1
Re: [PATCH 0/2] Add POWERTIP PH128800T006-ZHC01 panel
Hi, On Mon, 18 Mar 2024 09:17:06 -0700, Nathan Morrisson wrote: > Add the device tree bindings, timings, and compatible string for the > POWERTIP PH128800T006-ZHC01 panel. > > Nathan Morrisson (2): > dt-bindings: display: simple: Add POWERTIP PH128800T-006-ZHC01 panel > drm/panel: simple: Add POWERTIP PH128800T006-ZHC01 panel entry > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/2] dt-bindings: display: simple: Add POWERTIP PH128800T-006-ZHC01 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3b2304cfeddd141523cb50cc1a3ba7624b865011 [2/2] drm/panel: simple: Add POWERTIP PH128800T006-ZHC01 panel entry https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/fd6aa8f2dcb7236e511c1a58d82c2a178170e6ff -- Neil
[PATCH 0/2] Add POWERTIP PH128800T006-ZHC01 panel
Add the device tree bindings, timings, and compatible string for the POWERTIP PH128800T006-ZHC01 panel. Nathan Morrisson (2): dt-bindings: display: simple: Add POWERTIP PH128800T-006-ZHC01 panel drm/panel: simple: Add POWERTIP PH128800T006-ZHC01 panel entry .../bindings/display/panel/panel-simple.yaml | 2 ++ drivers/gpu/drm/panel/panel-simple.c | 29 +++ 2 files changed, 31 insertions(+) -- 2.25.1
Re: [PATCH 0/2] drm/panel: Add Startek KD050HDFIA020-C020A support
Hi, On Sun, 17 Mar 2024 17:57:44 +0200, Laurent Pinchart wrote: > This small series adds support for the Startek KD050HDFIA020-C020A panel > to the ilitek-ili9881c driver. There's not much special here, patch 1/2 > addresses the DT binding and patch 2/2 the driver. Please see individual > patches for details. > > The series has been tested witha Compulab SB-UCM-iMX8MPLUS carrier > board. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/2] dt-bindings: ili9881c: Add Startek KD050HDFIA020-C020A support https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/77880bd4512e261372dfc3f49a5ed44fde9d3fa5 [2/2] drm/panel: ilitek-ili9881c: Add Startek KD050HDFIA020-C020A support https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/9fb8aaff8eef56c1822e5267e52d4ab8ebb5b523 -- Neil
[PATCH 0/2] drm/panel: Add Startek KD050HDFIA020-C020A support
Hello, This small series adds support for the Startek KD050HDFIA020-C020A panel to the ilitek-ili9881c driver. There's not much special here, patch 1/2 addresses the DT binding and patch 2/2 the driver. Please see individual patches for details. The series has been tested witha Compulab SB-UCM-iMX8MPLUS carrier board. Laurent Pinchart (2): dt-bindings: ili9881c: Add Startek KD050HDFIA020-C020A support drm/panel: ilitek-ili9881c: Add Startek KD050HDFIA020-C020A support .../display/panel/ilitek,ili9881c.yaml| 1 + drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 222 ++ 2 files changed, 223 insertions(+) -- Regards, Laurent Pinchart
[PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. Thanks, Leo Some links to provide context and details: * What is underlay?: https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/76 * Discussion on how to implement underlay on Weston: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258#note_2325164 Cc: Joshua Ashton Cc: Michel Dänzer Cc: Chao Guo Cc: Xaver Hugl Cc: Vikas Korjani Cc: Robert Mader Cc: Pekka Paalanen Cc: Sean Paul Cc: Simon Ser Cc: Shashank Sharma Cc: Harry Wentland Cc: Sebastian Wick Leo Li (2): drm/amd/display: Introduce overlay cursor mode drm/amd/display: Move PRIMARY plane zpos higher .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 405 -- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 + .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 1 + .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 28 +- 4 files changed, 391 insertions(+), 50 deletions(-) -- 2.44.0
[PATCH 0/2] drm: Add DRM managed workqueues
Based on work at https://lore.kernel.org/dri-devel/20230118032413.6496-1-jiash...@iscas.ac.cn/ The API in the origional work seemed to have two issues: 1. The output parameter was not correctly defined 2. The allocating functions did not return the allocated object like the other drmm functions I tweaked the implementation to address both of these. >From what I can tell, the i915 change no longer applies to the code base, likely due to refactoring from merging xe. I dropped it. Jeffrey Hugo (1): accel/qaic: Use drmm_alloc_workqueue() Jiasheng Jiang (1): drm: Add DRM-managed alloc_workqueue() and alloc_ordered_workqueue() drivers/accel/qaic/qaic_drv.c | 30 ++--- drivers/gpu/drm/drm_managed.c | 82 +++ include/drm/drm_managed.h | 8 3 files changed, 94 insertions(+), 26 deletions(-) -- 2.34.1
Re: [PATCH 0/2] drm/fourcc.h: Add libcamera to Open Source Waiver
Hello gentle nudge for *) libcamera: are we ok being listed here ? *) DRM/KMS: is it ok splitting the list of projects in the way I've done ? Thanks j On Wed, Feb 28, 2024 at 11:22:42AM +0100, Jacopo Mondi wrote: > As suggested by Sima, add libcamera to the list of projects to which the > Open Source Waiver notice applies. > > To maintain the paragraph readable, make a list out of the projects to which > such notice applies. > > Jacopo Mondi (2): > drm/fourcc.h: List of Open Source Waiver projects > drm/fourcc.h: Add libcamera to Open Source Waiver > > include/uapi/drm/drm_fourcc.h | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > -- > 2.43.2 >
[PATCH 0/2] drm/msm/dp: fix runtime PM leaks on hotplug
As I've reported elsewhere, I've been hitting runtime PM usage count leaks when investigated a DisplayPort hotplug regression on the Lenovo ThinkPad X13s. [1] This series addresses two obvious leaks on disconnect and on connect failures, respectively. Johan [1] https://lore.kernel.org/lkml/ze8ke_m2xhypy...@hovoldconsulting.com/ Johan Hovold (2): drm/msm/dp: fix runtime PM leak on disconnect drm/msm/dp: fix runtime PM leak on connect failure drivers/gpu/drm/msm/dp/dp_display.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.43.2
[PATCH 0/2] Add pagefault support for devcoredump
Add support of devcoredump from global object of amdgpu_device Sunil Khatri (2): drm/amdgpu: add recent pagefault info in vm_manager drm/amdgpu: add vm fault information to devcoredump drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 8 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 2 ++ 3 files changed, 23 insertions(+), 1 deletion(-) -- 2.34.1
[PATCH 0/2] Support fdinfo runtime and memory stats on Panthor
This patch series enables userspace utilities like gputop and nvtop to query a render context's fdinfo file and figure out rates of engine and memory utilisation. Adrián Larumbe (2): drm/panthor: Enable fdinfo for cycle and time measurements drm/panthor: Enable fdinfo for memory stats drivers/gpu/drm/panthor/panthor_devfreq.c | 10 + drivers/gpu/drm/panthor/panthor_device.h | 11 ++ drivers/gpu/drm/panthor/panthor_drv.c | 32 drivers/gpu/drm/panthor/panthor_gem.c | 12 ++ drivers/gpu/drm/panthor/panthor_sched.c | 217 +++--- 5 files changed, 254 insertions(+), 28 deletions(-) base-commit: e635b7eb7062b464bbd9795308b1a80eac0b01f5 -- 2.43.0
[PATCH 0/2] video: backlight: constify struct class usage
This is a simple and straight forward cleanup series that aims to make the class structures in backlight constant. This has been possible since 2023 [1]. [1]: https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/ Signed-off-by: Ricardo B. Marliere --- Ricardo B. Marliere (2): video: backlight: make backlight_class constant video: backlight: lcd: make lcd_class constant drivers/video/backlight/backlight.c | 29 - drivers/video/backlight/lcd.c | 23 +-- 2 files changed, 29 insertions(+), 23 deletions(-) --- base-commit: cd1995b6ac7384149ad755b74e3c3eb25195ab81 change-id: 20240305-class_cleanup-backlight-62b91c38005e Best regards, -- Ricardo B. Marliere
[PATCH 0/2] drm/fourcc.h: Add libcamera to Open Source Waiver
As suggested by Sima, add libcamera to the list of projects to which the Open Source Waiver notice applies. To maintain the paragraph readable, make a list out of the projects to which such notice applies. Jacopo Mondi (2): drm/fourcc.h: List of Open Source Waiver projects drm/fourcc.h: Add libcamera to Open Source Waiver include/uapi/drm/drm_fourcc.h | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) -- 2.43.2
Re: [PATCH 0/2] Match panel hash for overridden mode
On Tue, 27 Feb 2024 at 03:10, Hsin-Yi Wang wrote:
>
> On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
> wrote:
> >
> > On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> > >
> > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> > > product id. One of them requires an overridden mode, while the other
> > > should
> > > use the mode directly from edid.
> > >
> > > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is
> > > extended
> > > to check the crc hash of the entire edid base block.
> >
> > Do you have these EDIDs posted somewhere? Can we use something less
> > cryptic than hash for matching the panel, e.g. strings from Monitor
> > Descriptors?
> >
>
> Panel 1:
>
> 00 ff ff ff ff ff ff 00 06 af 5c 40 00 00 00 00
> 00 1a 01 04 95 1a 0e 78 02 99 85 95 55 56 92 28
> 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 12 1b 56 5a 50 00 19 30 30 20
> 46 00 00 90 10 00 00 18 00 00 00 0f 00 00 00 00
> 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41
> 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe
> 00 42 31 31 36 58 41 4b 30 31 2e 30 20 0a 00 cc
>
>
>
> Block 0, Base EDID:
> EDID Structure Version & Revision: 1.4
> Vendor & Product Identification:
> Manufacturer: AUO
> Model: 16476
> Made in: 2016
> Basic Display Parameters & Features:
> Digital display
> Bits per primary color channel: 6
> DisplayPort interface
> Maximum image size: 26 cm x 14 cm
> Gamma: 2.20
> Supported color formats: RGB 4:4:4
> First detailed timing includes the native pixel format and
> preferred refresh rate
> Color Characteristics:
> Red : 0.5839, 0.3330
> Green: 0.3378, 0.5712
> Blue : 0.1582, 0.1328
> White: 0.3134, 0.3291
> Established Timings I & II: none
> Standard Timings: none
> Detailed Timing Descriptors:
> DTD 1: 1366x76860.020 Hz 683:384 47.596 kHz 69.300 MHz
> (256 mm x 144 mm)
> Hfront 48 Hsync 32 Hback 10 Hpol N
> Vfront4 Vsync 6 Vback 15 Vpol N
> Manufacturer-Specified Display Descriptor (0x0f): 00 0f 00 00 00
> 00 00 00 00 00 00 00 00 00 00 20 '... '
> Alphanumeric Data String: 'AUO'
> Alphanumeric Data String: 'B116XAK01.0 '
> Checksum: 0xcc
>
>
> Panel 2:
>
> 00 ff ff ff ff ff ff 00 06 af 5c 40 00 00 00 00
> 00 19 01 04 95 1a 0e 78 02 99 85 95 55 56 92 28
> 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 ce 1d 56 ea 50 00 1a 30 30 20
> 46 00 00 90 10 00 00 18 d4 17 56 ea 50 00 1a 30
> 30 20 46 00 00 90 10 00 00 18 00 00 00 fe 00 41
> 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe
> 00 42 31 31 36 58 41 4e 30 34 2e 30 20 0a 00 94
>
>
>
> Block 0, Base EDID:
> EDID Structure Version & Revision: 1.4
> Vendor & Product Identification:
> Manufacturer: AUO
> Model: 16476
> Made in: 2015
> Basic Display Parameters & Features:
> Digital display
> Bits per primary color channel: 6
> DisplayPort interface
> Maximum image size: 26 cm x 14 cm
> Gamma: 2.20
> Supported color formats: RGB 4:4:4
> First detailed timing includes the native pixel format and
> preferred refresh rate
> Color Characteristics:
> Red : 0.5839, 0.3330
> Green: 0.3378, 0.5712
> Blue : 0.1582, 0.1328
> White: 0.3134, 0.3291
> Established Timings I & II: none
> Standard Timings: none
> Detailed Timing Descriptors:
> DTD 1: 1366x76860.059824 Hz 683:384 47.688 kHz
> 76.30 MHz (256 mm x 144 mm)
> Hfront 48 Hsync 32 Hback 154 Hpol N
> Vfront4 Vsync 6 Vback 16 Vpol N
> DTD 2: 1366x76848.016373 Hz 683:384 38.125 kHz
> 61.00 MHz (256 mm x 144 mm)
> Hfront 48 Hsync 32 Hback 154 Hpol N
> Vfront4 Vsync 6 Vback 16 Vpol N
> Alphanumeric Data String: 'AUO'
> Alphanumeric Data String: 'B116XAN04.0 '
> Checksum: 0x94
>
> In this example, Descriptors can also be used to distinguish. But it's
> possible that the name field is also reused by mistake, for the same
> reason as model id is reused.
Thank you! Let's settle the discussion at the cover letter.
>
>
> > >
> > > Hsin-Yi Wang (2):
> > > drm_edid: Add a function to get EDID base block
> > > drm/panel: panel-edp: Match with panel hash for overridden modes
> > >
> > > drivers/gpu/drm/drm_edid.c| 55 +++-
> > > drivers/gpu/drm/panel/panel-edp.c | 60 ++-
> > > include/drm/drm_edid.h| 3 +-
> > > 3 files changed, 84 insertions(+), 34 deletions(-)
> > >
> > > --
> > > 2.44.0.rc0.258.g7320e95886-goog
> > >
> >
> >
> > --
> > With best wishes
> > Dmitry
--
With best wishes
Dmitry
Re: [PATCH 0/2] Match panel hash for overridden mode
On Tue, 27 Feb 2024 at 03:00, Doug Anderson wrote:
>
> Hi,
>
> On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
> wrote:
> >
> > On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> > >
> > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> > > product id. One of them requires an overridden mode, while the other
> > > should
> > > use the mode directly from edid.
> > >
> > > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is
> > > extended
> > > to check the crc hash of the entire edid base block.
> >
> > Do you have these EDIDs posted somewhere? Can we use something less
> > cryptic than hash for matching the panel, e.g. strings from Monitor
> > Descriptors?
>
> We could try it if need be. I guess I'm worried that if panel vendors
> ended up re-using the panel ID for two different panels that they
> might also re-use the name field too. Hashing the majority of the
> descriptor's base block makes us more likely not to mix two panels up.
> In general it feels like the goal is that if there is any doubt that
> we shouldn't override the mode and including more fields in the hash
> works towards that goal.
My main concern is that hash (or crc) is a non-obvious thing: even if
we have EDID in the commit message, it takes some effort to calculate
the value. If for any reason we decide to change the hashed bytes
(e.g. by dropping any of the fields) it will be an error-prone process
to update existing hash values. On the contrary, the 'strings' are
easy to check / compare without any additional tools.
>
> I guess one thing that might help would be to make it a policy that
> any time a panel is added to this list that a full EDID is included in
> the commit message. That would mean that if we ever needed to change
> things we could. What do you think?
Definitely, that sounds like a good idea.
> That being said, if everyone thinks that the "name" field is enough,
> we could do it. I think that in the one case that we ran into it would
> have been enough...
Yes, I'd suggest using the string unless at some point we see two
panels sharing both panel_id and names.
--
With best wishes
Dmitry
Re: [PATCH 0/2] Match panel hash for overridden mode
On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
wrote:
>
> On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> >
> > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> > product id. One of them requires an overridden mode, while the other should
> > use the mode directly from edid.
> >
> > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended
> > to check the crc hash of the entire edid base block.
>
> Do you have these EDIDs posted somewhere? Can we use something less
> cryptic than hash for matching the panel, e.g. strings from Monitor
> Descriptors?
>
Panel 1:
00 ff ff ff ff ff ff 00 06 af 5c 40 00 00 00 00
00 1a 01 04 95 1a 0e 78 02 99 85 95 55 56 92 28
22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 12 1b 56 5a 50 00 19 30 30 20
46 00 00 90 10 00 00 18 00 00 00 0f 00 00 00 00
00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41
55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe
00 42 31 31 36 58 41 4b 30 31 2e 30 20 0a 00 cc
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: AUO
Model: 16476
Made in: 2016
Basic Display Parameters & Features:
Digital display
Bits per primary color channel: 6
DisplayPort interface
Maximum image size: 26 cm x 14 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
First detailed timing includes the native pixel format and
preferred refresh rate
Color Characteristics:
Red : 0.5839, 0.3330
Green: 0.3378, 0.5712
Blue : 0.1582, 0.1328
White: 0.3134, 0.3291
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 1366x76860.020 Hz 683:384 47.596 kHz 69.300 MHz
(256 mm x 144 mm)
Hfront 48 Hsync 32 Hback 10 Hpol N
Vfront4 Vsync 6 Vback 15 Vpol N
Manufacturer-Specified Display Descriptor (0x0f): 00 0f 00 00 00
00 00 00 00 00 00 00 00 00 00 20 '... '
Alphanumeric Data String: 'AUO'
Alphanumeric Data String: 'B116XAK01.0 '
Checksum: 0xcc
Panel 2:
00 ff ff ff ff ff ff 00 06 af 5c 40 00 00 00 00
00 19 01 04 95 1a 0e 78 02 99 85 95 55 56 92 28
22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 ce 1d 56 ea 50 00 1a 30 30 20
46 00 00 90 10 00 00 18 d4 17 56 ea 50 00 1a 30
30 20 46 00 00 90 10 00 00 18 00 00 00 fe 00 41
55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe
00 42 31 31 36 58 41 4e 30 34 2e 30 20 0a 00 94
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: AUO
Model: 16476
Made in: 2015
Basic Display Parameters & Features:
Digital display
Bits per primary color channel: 6
DisplayPort interface
Maximum image size: 26 cm x 14 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
First detailed timing includes the native pixel format and
preferred refresh rate
Color Characteristics:
Red : 0.5839, 0.3330
Green: 0.3378, 0.5712
Blue : 0.1582, 0.1328
White: 0.3134, 0.3291
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 1366x76860.059824 Hz 683:384 47.688 kHz
76.30 MHz (256 mm x 144 mm)
Hfront 48 Hsync 32 Hback 154 Hpol N
Vfront4 Vsync 6 Vback 16 Vpol N
DTD 2: 1366x76848.016373 Hz 683:384 38.125 kHz
61.00 MHz (256 mm x 144 mm)
Hfront 48 Hsync 32 Hback 154 Hpol N
Vfront4 Vsync 6 Vback 16 Vpol N
Alphanumeric Data String: 'AUO'
Alphanumeric Data String: 'B116XAN04.0 '
Checksum: 0x94
In this example, Descriptors can also be used to distinguish. But it's
possible that the name field is also reused by mistake, for the same
reason as model id is reused.
> >
> > Hsin-Yi Wang (2):
> > drm_edid: Add a function to get EDID base block
> > drm/panel: panel-edp: Match with panel hash for overridden modes
> >
> > drivers/gpu/drm/drm_edid.c| 55 +++-
> > drivers/gpu/drm/panel/panel-edp.c | 60 ++-
> > include/drm/drm_edid.h| 3 +-
> > 3 files changed, 84 insertions(+), 34 deletions(-)
> >
> > --
> > 2.44.0.rc0.258.g7320e95886-goog
> >
>
>
> --
> With best wishes
> Dmitry
Re: [PATCH 0/2] Match panel hash for overridden mode
Hi,
On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
wrote:
>
> On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> >
> > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> > product id. One of them requires an overridden mode, while the other should
> > use the mode directly from edid.
> >
> > Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended
> > to check the crc hash of the entire edid base block.
>
> Do you have these EDIDs posted somewhere? Can we use something less
> cryptic than hash for matching the panel, e.g. strings from Monitor
> Descriptors?
We could try it if need be. I guess I'm worried that if panel vendors
ended up re-using the panel ID for two different panels that they
might also re-use the name field too. Hashing the majority of the
descriptor's base block makes us more likely not to mix two panels up.
In general it feels like the goal is that if there is any doubt that
we shouldn't override the mode and including more fields in the hash
works towards that goal.
I guess one thing that might help would be to make it a policy that
any time a panel is added to this list that a full EDID is included in
the commit message. That would mean that if we ever needed to change
things we could. What do you think?
That being said, if everyone thinks that the "name" field is enough,
we could do it. I think that in the one case that we ran into it would
have been enough...
-Doug
Re: [PATCH 0/2] Match panel hash for overridden mode
On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
>
> This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> product id. One of them requires an overridden mode, while the other should
> use the mode directly from edid.
>
> Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended
> to check the crc hash of the entire edid base block.
Do you have these EDIDs posted somewhere? Can we use something less
cryptic than hash for matching the panel, e.g. strings from Monitor
Descriptors?
>
> Hsin-Yi Wang (2):
> drm_edid: Add a function to get EDID base block
> drm/panel: panel-edp: Match with panel hash for overridden modes
>
> drivers/gpu/drm/drm_edid.c| 55 +++-
> drivers/gpu/drm/panel/panel-edp.c | 60 ++-
> include/drm/drm_edid.h| 3 +-
> 3 files changed, 84 insertions(+), 34 deletions(-)
>
> --
> 2.44.0.rc0.258.g7320e95886-goog
>
--
With best wishes
Dmitry
[PATCH 0/2] Match panel hash for overridden mode
This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
product id. One of them requires an overridden mode, while the other should
use the mode directly from edid.
Since product id match is no longer sufficient, EDP_PANEL_ENTRY2 is extended
to check the crc hash of the entire edid base block.
Hsin-Yi Wang (2):
drm_edid: Add a function to get EDID base block
drm/panel: panel-edp: Match with panel hash for overridden modes
drivers/gpu/drm/drm_edid.c| 55 +++-
drivers/gpu/drm/panel/panel-edp.c | 60 ++-
include/drm/drm_edid.h| 3 +-
3 files changed, 84 insertions(+), 34 deletions(-)
--
2.44.0.rc0.258.g7320e95886-goog
[PATCH 0/2] Disable automatic load CCS load balancing
Hi, this series does basically two things: 1. Disables automatic load balancing as adviced by the hardware workaround. 2. Assigns all the CCS slices to one single user engine. The user will then be able to query only one CCS engine Changelog = - In Patch 1 use the correct workaround number (thanks Matt). - In Patch 2 do not add the extra CCS engines to the exposed UABI engine list and adapt the engine counting accordingly (thanks Tvrtko). - Reword the commit of Patch 2 (thanks John). Andi Shyti (2): drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Enable only one CCS for compute workload drivers/gpu/drm/i915/gt/intel_engine_user.c | 9 + drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ drivers/gpu/drm/i915/i915_query.c | 1 + 5 files changed, 30 insertions(+) -- 2.43.0
Re: [PATCH 0/2] Disable automatic load CCS load balancing
Please, ignore, I sent V1 again. Sorry about the noise! Andi On Tue, Feb 20, 2024 at 03:20:32PM +0100, Andi Shyti wrote: > Hi, > > this series does basically two things: > > 1. Disables automatic load balancing as adviced by the hardware >workaround. > > 2. Forces the sharing of the load submitted to CCS among all the >CCS available (as of now only DG2 has more than one CCS). This >way the user, when sending a query, will see only one CCS >available. > > Andi > > Andi Shyti (2): > drm/i915/gt: Disable HW load balancing for CCS > drm/i915/gt: Set default CCS mode '1' > > drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++ > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ > drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ > drivers/gpu/drm/i915/i915_drv.h | 17 + > drivers/gpu/drm/i915/i915_query.c | 5 +++-- > 5 files changed, 40 insertions(+), 2 deletions(-) > > -- > 2.43.0
Re: [PATCH 0/2] Disable automatic load CCS load balancing
Hi, I'm sorry, I forgot to add the changelog. Here it is: v1 -> v2 - In Patch 1 use the correct workaround number (thanks Matt). - In Patch 2 do not add the extra CCS engines to the exposed UABI engine list and adapt the engine counting accordingly (thanks Tvrtko). - Reword the commit of Patch 2 (thanks John). On Tue, Feb 20, 2024 at 03:20:32PM +0100, Andi Shyti wrote: > Hi, > > this series does basically two things: > > 1. Disables automatic load balancing as adviced by the hardware >workaround. > > 2. Forces the sharing of the load submitted to CCS among all the >CCS available (as of now only DG2 has more than one CCS). This >way the user, when sending a query, will see only one CCS >available. > > Andi > > Andi Shyti (2): > drm/i915/gt: Disable HW load balancing for CCS > drm/i915/gt: Set default CCS mode '1' > > drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++ > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ > drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ > drivers/gpu/drm/i915/i915_drv.h | 17 + > drivers/gpu/drm/i915/i915_query.c | 5 +++-- > 5 files changed, 40 insertions(+), 2 deletions(-) > > -- > 2.43.0
[PATCH 0/2] Disable automatic load CCS load balancing
Hi, this series does basically two things: 1. Disables automatic load balancing as adviced by the hardware workaround. 2. Forces the sharing of the load submitted to CCS among all the CCS available (as of now only DG2 has more than one CCS). This way the user, when sending a query, will see only one CCS available. Andi Andi Shyti (2): drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Set default CCS mode '1' drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ drivers/gpu/drm/i915/i915_drv.h | 17 + drivers/gpu/drm/i915/i915_query.c | 5 +++-- 5 files changed, 40 insertions(+), 2 deletions(-) -- 2.43.0
[PATCH 0/2] Disable automatic load CCS load balancing
Hi, this series does basically two things: 1. Disables automatic load balancing as adviced by the hardware workaround. 2. Forces the sharing of the load submitted to CCS among all the CCS available (as of now only DG2 has more than one CCS). This way the user, when sending a query, will see only one CCS available. Andi Andi Shyti (2): drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Set default CCS mode '1' drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ drivers/gpu/drm/i915/i915_drv.h | 17 + drivers/gpu/drm/i915/i915_query.c | 5 +++-- 5 files changed, 40 insertions(+), 2 deletions(-) -- 2.43.0
[PATCH 0/2] drm/amd/display: clean codestyle errors
jppaulo (2): drm/amd/display: clean inconsistent indenting drm/amd/display: clean else not following close brace drivers/gpu/drm/amd/display/dc/core/dc.c | 6 +++--- drivers/gpu/drm/amd/display/dc/core/dc_link_enc_cfg.c | 3 +-- 2 files changed, 4 insertions(+), 5 deletions(-) -- 2.43.0
