[PATCH v5 0/7] Overhaul `is_thunderbolt`

Various drivers in the kernel use `is_thunderbolt` or `pci_is_thunderbolt_attached` to designate behaving differently from a device that is internally in the machine. This currently works by an attribute in PCI core "is_thunderbolt" which makes those drivers only apply differences when Intel Thunde

[PATCH v5 2/7] PCI: Move check for old Apple Thunderbolt controllers into a quirk

`pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt controller to indicate that D3 is possible. This is used solely for older Apple systems, due to a variety of factors: * Apple used SW connection manager from the beginning, other manufacturers used a FW connection manager (IC

[PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

The `is_thunderbolt` attribute originally had a well defined list of quirks that it existed for, but it has been overloaded with more meaning. Instead use the driver core removable attribute to indicate the detail a device is attached to a thunderbolt or USB4 chain. Signed-off-by: Mario Limonciel

[PATCH v5 1/7] PCI: Move `is_thunderbolt` check for lack of command completed to a quirk

The `is_thunderbolt` check is currently used to indicate the lack of command completed support for a number of older Thunderbolt devices. This however is heavy handed and should have been done via a quirk. Move the affected devices outlined in commit 493fb50e958c ("PCI: pciehp: Assume NoCompl+ fo

[PATCH v5 6/7] drm/radeon: drop the use of `pci_is_thunderbolt_attached`

Currently `pci_is_thunderbolt_attached` is used to indicate a device is connected externally. The PCI core now marks such devices as removable and downstream drivers can use this instead. Signed-off-by: Mario Limonciello --- drivers/gpu/drm/radeon/radeon_device.c | 4 ++-- drivers/gpu/drm/radeo

[PATCH v5 7/7] PCI: drop `pci_is_thunderbolt_attached`

Currently `pci_is_thunderbolt_attached` is used to indicate a device is connected externally. As all drivers now look at the removable attribute, drop this function. Signed-off-by: Mario Limonciello --- include/linux/pci.h | 22 -- 1 file changed, 22 deletions(-) diff --git

[PATCH v5 5/7] drm/nouveau: drop the use of `pci_is_thunderbolt_attached`

Currently `pci_is_thunderbolt_attached` is used to indicate a device is connected externally. The PCI core now marks such devices as removable and downstream drivers can use this instead. Signed-off-by: Mario Limonciello --- drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++-- 1 file changed, 2 inse

[PATCH v5 4/7] drm/amd: drop the use of `pci_is_thunderbolt_attached`

Currently `pci_is_thunderbolt_attached` is used to indicate a device is connected externally. The PCI core now marks such devices as removable and downstream drivers can use this instead. Reviewed-by: Macpaul Lin Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2

[PATCH] drm/msm: Add MSM_SUBMIT_FENCE_SN_IN

From: Rob Clark Add a way for userspace to specify the sequence number fence used to track completion of the submit. As the seqno fence is simply an incrementing counter which is local to the submitqueue, it is easy for userspace to know the next value. This is useful for native userspace drive

Re: [PATCH v4 01/10] clk: Introduce Kunit Tests for the framework

Quoting Maxime Ripard (2022-02-21 07:12:59) > Hi Stephen, > > Thanks for your review > > On Fri, Feb 18, 2022 at 06:20:46PM -0800, Stephen Boyd wrote: > > It would also be good to add a test that tries to set the clk rate with > > clk_set_rate() after a range has been set that is outside the acce

Re: [PATCH v4 02/10] clk: Always clamp the rounded rate

Quoting Maxime Ripard (2022-02-21 08:18:21) > Hi, > > On Fri, Feb 18, 2022 at 03:15:06PM -0800, Stephen Boyd wrote: > > Quoting Maxime Ripard (2022-01-25 06:15:41) > > > The current core while setting the min and max rate properly in the > > > clk_request structure will not make sure that the requ

Re: [PATCH v4 02/10] clk: Always clamp the rounded rate

Quoting Maxime Ripard (2022-02-21 08:43:23) > Hi again, > > On Mon, Feb 21, 2022 at 05:18:21PM +0100, Maxime Ripard wrote: > > On Fri, Feb 18, 2022 at 03:15:06PM -0800, Stephen Boyd wrote: > > > Quoting Maxime Ripard (2022-01-25 06:15:41) > > > > +/* > > > > + * Test that if our clock has some bou

Re: [PATCH V3 01/12] dt-bindings: display: bridge: tc358867: Document DPI output support

On Thu, 24 Feb 2022 20:58:06 +0100, Marek Vasut wrote: > The TC358767/TC358867/TC9595 are all capable of operating in multiple > modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the > DPI output port, which can now be connected both as input and output. > > Signed-off-by: Marek

Re: [PATCH V3 02/12] dt-bindings: display: bridge: tc358867: Document DSI data-lanes property

On Thu, 24 Feb 2022 20:58:07 +0100, Marek Vasut wrote: > It is necessary to specify the number of connected/used DSI data lanes when > using the DSI input port of this bridge. Document the 'data-lanes' property > of the DSI input port. > > Signed-off-by: Marek Vasut > Cc: Jonas Karlman > Cc: Lau

[PATCH][next] drm/amdgpu: Fix missing assignment to variable r

Currently the call to function amdgpu_benchmark_move should be assigning the return value to variable r as this is checked in the next statement, however, this assignment is missing. Fix this by adding in the missing assignment. Addresses clang scan warning: drivers/gpu/drm/amd/amdgpu/amdgpu_bench

Re: [PATCH v4 03/10] clk: Use clamp instead of open-coding our own

Quoting Maxime Ripard (2022-02-21 08:30:01) > On Fri, Feb 18, 2022 at 02:34:20PM -0800, Stephen Boyd wrote: > > Quoting Maxime Ripard (2022-01-25 06:15:42) > > > The code in clk_set_rate_range() will, if the current rate is outside of > > > the new range, will force it to the minimum or maximum. Th

[PATCH v9 00/11] vgaarb: Rework default VGA device selection

From: Bjorn Helgaas Current default VGA device selection fails in some cases because part of it is done in the vga_arb_device_init() subsys_initcall, and some arches enumerate PCI devices in pcibios_init(), which runs *after* that. The big change from the v8 posting is that this moves vgaarb.c f

[PATCH v9 01/11] PCI/VGA: Move vgaarb to drivers/pci

From: Bjorn Helgaas The VGA arbiter is really PCI-specific and doesn't depend on any GPU things. Move it to the PCI subsystem. Note that misc_init() must be called before vga_arb_device_init(). These are both subsys_initcalls, so this ordering depends on the link order, which is determined by

[PATCH v9 03/11] PCI/VGA: Factor out vga_select_framebuffer_device()

From: Bjorn Helgaas On x86 and ia64, if a VGA device BARs include a framebuffer reported by platform firmware, we select the device as the default VGA device. Factor this code to a separate function. No functional change intended. Signed-off-by: Bjorn Helgaas Cc: Bruno Prémont --- drivers/p

[PATCH v9 06/11] PCI/VGA: Move non-legacy VGA detection to ADD_DEVICE path

From: Huacai Chen a37c0f48950b ("vgaarb: Select a default VGA device even if there's no legacy VGA") extended the vga_arb_device_init() subsys_initcall so it could select a non-legacy VGA device as the default. That failed to consider that PCI devices may be enumerated after vga_arb_device_init(

[PATCH v9 05/11] PCI/VGA: Move firmware default device detection to ADD_DEVICE path

From: Huacai Chen Previously we selected the firmware default device, i.e., one that owns the boot framebuffer, as the default device in vga_arb_select_default_device(). This was only done in the vga_arb_device_init() subsys_initcall, so devices enumerated later, e.g., by pcibios_init(), were not

[PATCH v9 04/11] PCI/VGA: Factor out default VGA device selection

From: Huacai Chen Default VGA device selection fails when PCI devices are enumerated after the vga_arb_device_init() subsys_initcall. vga_arbiter_add_pci_device() selects the first fully enabled device to which legacy VGA resources are routed as the default VGA device. This is an ADD_DEVICE not

[PATCH v9 07/11] PCI/VGA: Move disabled VGA device detection to ADD_DEVICE path

From: Huacai Chen a37c0f48950b ("vgaarb: Select a default VGA device even if there's no legacy VGA") extended the vga_arb_device_init() subsys_initcall so that if there are no other eligible devices, it could select a disabled VGA device as the default. Move this detection from vga_arb_select_de

[PATCH v9 08/11] PCI/VGA: Remove empty vga_arb_device_card_gone()

From: Bjorn Helgaas vga_arb_device_card_gone() has always been empty. Remove it. Signed-off-by: Bjorn Helgaas --- drivers/pci/vgaarb.c | 16 +--- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c index e8d5efd85ba6..582f0054b

[PATCH v9 09/11] PCI/VGA: Log bridge control messages when adding devices

From: Huacai Chen Previously vga_arb_device_init() iterated through all VGA devices and indicated whether legacy VGA routing to each could be controlled by an upstream bridge. But we determine that information in vga_arbiter_add_pci_device(), which we call for every device, so we can log it ther

[PATCH v9 02/11] PCI/VGA: Move vga_arb_integrated_gpu() earlier in file

From: Huacai Chen Move vga_arb_integrated_gpu() earlier in file to prepare for future patch. No functional change intended. [bhelgaas: pull #ifdefs inside function] Link: https://lore.kernel.org/r/20211015061512.2941859-3-chenhua...@loongson.cn Signed-off-by: Huacai Chen --- drivers/pci/vgaarb

[PATCH v9 11/11] PCI/VGA: Replace full MIT license text with SPDX identifier

From: Bjorn Helgaas Per Documentation/process/license-rules.rst, the SPDX MIT identifier is equivalent to including the entire MIT license text from LICENSES/preferred/MIT. Replace the MIT license text with the equivalent SPDX identifier. Signed-off-by: Bjorn Helgaas --- drivers/pci/vgaarb.c

[PATCH v9 10/11] PCI/VGA: Use unsigned format string to print lock counts

From: Bjorn Helgaas In struct vga_device, io_lock_cnt and mem_lock_cnt are unsigned, but we previously printed them with "%d", the signed decimal format. Print them with the unsigned format "%u" instead. Signed-off-by: Bjorn Helgaas --- drivers/pci/vgaarb.c | 2 +- 1 file changed, 1 insertion

[PATCH v5 3/3] MAINTAINERS: Mark VMware mailing list entries as email aliases

From: Srivatsa S. Bhat (VMware) VMware mailing lists in the MAINTAINERS file are private lists meant for VMware-internal review/notification for patches to the respective subsystems. Anyone can post to these addresses, but there is no public read access like open mailing lists, which makes them m

[PATCH v5 0/3] Update VMware maintainer entries

This series updates a few maintainer entries for VMware-maintained subsystems and cleans up references to VMware's private mailing lists to make it clear that they are effectively email-aliases to reach out to reviewers. Changes from v4->v5: - Add Alexey as reviewer for paravirt ops. Changes from

Re: [PATCH v6 05/12] clk: Use clamp instead of open-coding our own

Quoting Maxime Ripard (2022-02-23 02:55:53) > The code in clk_set_rate_range() will, if the current rate is outside of > the new range, will force it to the minimum or maximum. s/will// > > Since it's running under the condition that the rate is either lower > than the minimum, or higher than th

Re: [PATCH v6 02/12] clk: Introduce Kunit Tests for the framework

Quoting Daniel Latypov (2022-02-23 14:50:59) > On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripard wrote: > > > > Let's test various parts of the rate-related clock API with the kunit > > testing framework. > > > > Cc: kunit-...@googlegroups.com > > Suggested-by: Stephen Boyd > > Signed-off-by: Maxime

[git pull] drm fixes for 5.17-rc6

Hey, Regular drm fixes pull, i915, amdgpu and tegra mostly, all pretty small. I'm in quarantine at home for next 7 days, shouldn't interrupt things, but might be erratic if anyone is looking for me. Dave. drm-fixes-2022-02-25: drm fixes for 5.17-rc6 core: - edid: Always set RGB444 tegra: - te

[Bug 201957] amdgpu: ring gfx timeout

https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #66 from Randune (randyk...@gmail.com) --- So I've been running for about 2.5 weeks now using the amdgpu.runpm=0 kernel parameter and I've had no crashes or freezes so far. I'm cautiously optimistic that for me at least this may have s

[PATCH v2 0/8] Prep work for next GuC release

From: John Harrison The next GuC firmware release includes some significant backwards breaking API changes. One such is that there is no longer an LRC descriptor pool. A bunch of prep work for that change can be done in advance - the descriptor pool was being used for things it shouldn't really h

[PATCH v2 4/8] drm/i915/guc: Split guc_lrc_desc_pin apart

From: John Harrison The LRC descriptor pool is going away. Further, the function that was populating it was also doing a bunch of logic about the context registration sequence. So, split that code apart into separate state setup and try to register functions. Note that some of those 'try to regis

[PATCH v2 6/8] drm/i915/guc: Rename desc_idx to ctx_id

From: John Harrison The LRC descriptor pool is going away. So, stop naming context ids as descriptor pool indecies. While at it, add a bunch of missing line feeds to some error messages. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio --- .../gpu/drm/i915/gt/uc/intel_guc_sub

[PATCH v2 7/8] drm/i915/guc: Drop obsolete H2G definitions

From: John Harrison The CTB registration process changed significantly a while back using a single KLV based H2G. So drop the original and now obsolete H2G definitions. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 2 --

[PATCH v2 3/8] drm/i915/guc: Better name for context id limit

From: John Harrison The LRC descriptor pool is going away. So, stop using it as the limit for how many context ids are available. Instead, size the pool according to the number of contexts allowed. Note that this is just a naming change, the actual limit is identical in value. While at it, also

[PATCH v2 2/8] drm/i915/guc: Add an explicit 'submission_initialized' flag

From: John Harrison The LRC descriptor pool is going away. So, stop using it as a check for whether submission has been initialised or not. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++ drivers/gpu/drm/i915/gt/uc

[PATCH v2 8/8] drm/i915/guc: Fix potential invalid pointer dereferences when decoding G2Hs

From: John Harrison Some G2H handlers were reading the context id field from the payload before checking the payload met the minimum length required. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 -- 1 file chang

[PATCH v2 1/8] drm/i915/guc: Do not conflate lrc_desc with GuC id for registration

From: John Harrison The LRC descriptor pool is going away. So, stop using it as a check for context registration, use the GuC id instead (being the thing that actually gets registered with the GuC). Also, rename the set/clear/query helper functions for context id mappings to better reflect their

[PATCH v2 5/8] drm/i915/guc: Move lrc desc setup to where it is needed

From: John Harrison The LRC descriptor was being initialised early on in the context registration sequence. It could then be determined that the actual registration needs to be delayed and the descriptor would be wiped out. This is inefficient, so move the setup to later in the process after the

Re: [PATCH v4 7/9] drm: vkms: Refactor the plane composer to accept new formats

Hi Pekka, On 2/10/22 06:37, Pekka Paalanen wrote: > On Fri, 21 Jan 2022 18:38:29 -0300 > Igor Torrente wrote: > >> Currently the blend function only accepts XRGB_ and ARGB_ >> as a color input. >> >> This patch refactors all the functions related to the plane composition >> to overcome th

Re: [PATCH] drm/msm: Avoid dirtyfb stalls on video mode displays (v2)

On Wed, 23 Feb 2022 at 22:11, Rob Clark wrote: > > From: Rob Clark > > Someone on IRC once asked an innocent enough sounding question: Why > with xf86-video-modesetting is es2gears limited at 120fps. > > So I broke out the perfetto tracing mesa MR and took a look. It turns > out the problem was

Re: [PATCH v4 9/9] drm: vkms: Add support to the RGB565 format

Hi Pekka, On Thu, Feb 10, 2022 at 6:50 AM Pekka Paalanen wrote: > On Fri, 21 Jan 2022 18:38:31 -0300 > Igor Torrente wrote: > > > Adds this common format to vkms. > > > > This commit also adds new helper macros to deal with fixed-point > > arithmetic. > > > > It was done to improve the precisio

Re: [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote: > The `is_thunderbolt` attribute originally had a well defined list of > quirks that it existed for, but it has been overloaded with more > meaning. > > Instead use the driver core removable attribute to indicate the > detail a dev

Re: [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

On Thu, Feb 24, 2022 at 07:23:49PM -0600, Bjorn Helgaas wrote: > On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote: > > The `is_thunderbolt` attribute originally had a well defined list of > > quirks that it existed for, but it has been overloaded with more > > meaning. > > > > Ins

[PATCH v6 1/2] drm/vrr: Set VRR capable prop only if it is attached to connector

VRR capable property is not attached by default to the connector It is attached only if VRR is supported. So if the driver tries to call drm core set prop function without it being attached that causes NULL dereference. Cc: Jani Nikula Cc: Ville Syrjälä Cc: dri-devel@lists.freedesktop.org Signed

Re: [git pull] drm fixes for 5.17-rc6

The pull request you sent on Fri, 25 Feb 2022 09:01:30 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-02-25 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5ee3d0015a4cec798b44ceefc34245752104fc08 Thank you! -- Deet-doot-dot, I am a bot. https://k

[GIT PULL] exynos-drm-fixes for rc6

Hi Dave and Daniel, Just fixups series. Ps. my previous git-pull request[1] isn't merged so I'm sending it again after rebasing on top of drm-fixes. Please kindly let me know if there is any problem. Thanks, Inki Dae [1] https://www.spinics.net/lists/dri-devel/msg333237.html T

[PATCH v3] drm/i915/guc: Do not complain about stale reset notifications

From: John Harrison It is possible for reset notifications to arrive for a context that is in the process of being banned. So don't flag these as an error, just report it as informational (because it is still useful to know that resets are happening even if they are being ignored). v2: Better wo

Re: [Freedreno] [RFC PATCH v2 1/5] drm/msm/dp: fix panel bridge attachment

On 2/24/2022 12:41 PM, Dmitry Baryshkov wrote: On Thu, 24 Feb 2022 at 21:25, Abhinav Kumar wrote: On 2/18/2022 6:26 PM, Dmitry Baryshkov wrote: On 19/02/2022 02:56, Stephen Boyd wrote: Quoting Dmitry Baryshkov (2022-02-11 14:40:02) In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mec

Re: [PATCH v5 1/4] drm/i915/guc: Add fetch of hwconfig table

On 2/22/2022 02:36, Jordan Justen wrote: From: John Harrison Implement support for fetching the hardware description table from the GuC. The call is made twice - once without a destination buffer to query the size and then a second time to fill in the buffer. Note that the table is only availa

[PATCH] drm/i915/guc: Add fetch of hwconfig table

From: John Harrison Implement support for fetching the hardware description table from the GuC. The call is made twice - once without a destination buffer to query the size and then a second time to fill in the buffer. The table is stored in the GT structure so that it can be fetched once at dri

Re: [PATCH] drm/imx: dw_hdmi-imx: Fix bailout in error cases of probe

Hi Philipp, On Fri, 2022-01-28 at 17:19 +0800, Liu Ying wrote: > In dw_hdmi_imx_probe(), if error happens after dw_hdmi_probe() returns > successfully, dw_hdmi_remove() should be called where necessary as > bailout. > > Fixes: c805ec7eb210 ("drm/imx: dw_hdmi-imx: move initialization into probe")

Re: [RFC v4 02/11] drm/amdgpu: Move scheduler init to after XGMI is ready

Hi Andrey, Sorry for the misleading, I mean the whole patch series. We are depending on this patch series to fix the concurrency issue within SRIOV TDR sequence. On 2/25/22 1:26 AM, Andrey Grodzovsky wrote: > No problem if so but before I do, > > > JingWen - why you think this patch is needed

[PATCH v12 2/6] drm/i915/gt: Re-work intel_write_status_page

Re-work intel_write_status_page to use drm_clflush_virt_range. This will prevent compiler errors when building for non-x86 architectures. Signed-off-by: Michael Cheng Reviewed-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_engine.h | 13 - 1 file changed, 4 insertions(+), 9 deleti

[PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou performs a flush by first performing a clean, follow by an invalidation operation. v2 (Michael Cheng): Use correct macro for cleaning and invalidation the dcache. Thanks Tvrtko for the suggestion. v3 (Michael

[PATCH v12 3/6] drm/i915/gt: Drop invalidate_csb_entries

Drop invalidate_csb_entries and directly call drm_clflush_virt_range. This allows for one less function call, and prevent complier errors when building for non-x86 architectures. v2(Michael Cheng): Drop invalidate_csb_entries function and directly invoke drm_clflush_virt_range.

[PATCH v12 0/6] Use drm_clflush* instead of clflush

This patch series re-work a few i915 functions to use drm_clflush_virt_range instead of calling clflush or clflushopt directly. This will prevent errors when building for non-x86 architectures. v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added more patches to convert addi

[PATCH v12 4/6] drm/i915/gt: Re-work reset_csb

Use drm_clflush_virt_range instead of directly invoking clflush. This will prevent compiler errors when building for non-x86 architectures. v2(Michael Cheng): Remove extra clflush v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range takes care of it. v4(Michae

[PATCH v12 5/6] drm/i915/: Re-work clflush_write32

Use drm_clflush_virt_range instead of clflushopt and remove the memory barrier, since drm_clflush_virt_range takes care of that. v2(Michael Cheng): Use sizeof(*addr) instead of sizeof(addr) to get the actual size of the page. Thanks to Matt Roper for pointing

[PATCH v12 6/6] drm/i915/gt: replace cache_clflush_range

Replace all occurrence of cache_clflush_range with drm_clflush_virt_range. This will prevent compile errors on non-x86 platforms. Signed-off-by: Michael Cheng Reviewed-by: Matt Roper --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++-- drivers/gpu/drm/i915/gt/intel_execli

[PATCH] drm/mediatek: Fix DPI component detection for MT8192

When support for MT8192 was added, the DPI device was not added to the list of components to look for. This causes the secondary display pipeline to not be able to fully bind, and the DRM driver subsequently defers probing. Add the DPI device compatible to list of DPI components to fix this. Fixe

Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5

Hi Martin, 22. 2. 25. 08:27에 Martin Jücker 이(가) 쓴 글: > Hello Inki, > > On Thu, Feb 24, 2022 at 10:41:04AM +0900, Inki Dae wrote: >> Hi Martin. >> >> I found that exynos4 and 5 data sheet include documented same register. >> RGB_ORDER_E field of VIDCONx registers will do same thing. > > If I read

[PATCH v3 2/2] drm/dp: Fix OOB read when handling Post Cursor2 register

The link_status array was not large enough to read the Adjust Request Post Cursor2 register, so remove the common helper function to avoid an OOB read, found with a -Warray-bounds build: drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_h

[PATCH v3 1/2] drm/dp: Fix off-by-one in register cache size

The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the math to calculate the max size. Found from a -Warray-bounds build: drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr': drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside array b

[PATCH v3 0/2] drm/dp: Fix out-of-bounds reads

Hi, I'm sending these again, as they still need fixing. They have been rebased due to the drm_dp_helper code being moved into a subdirectory. Can someone please apply these? :) Thanks! -Kees v1: https://patchwork.freedesktop.org/patch/465200/ https://patchwork.freedesktop.org/patch/465201/

Re: [Freedreno] [RFC PATCH v2 1/5] drm/msm/dp: fix panel bridge attachment

On Fri, 25 Feb 2022 at 05:01, Abhinav Kumar wrote: > > > > On 2/24/2022 12:41 PM, Dmitry Baryshkov wrote: > > On Thu, 24 Feb 2022 at 21:25, Abhinav Kumar > > wrote: > >> > >> > >> > >> On 2/18/2022 6:26 PM, Dmitry Baryshkov wrote: > >>> On 19/02/2022 02:56, Stephen Boyd wrote: > Quoting Dmi

Re: [Freedreno] [RFC PATCH v2 1/5] drm/msm/dp: fix panel bridge attachment

On 2/24/2022 8:22 PM, Dmitry Baryshkov wrote: On Fri, 25 Feb 2022 at 05:01, Abhinav Kumar wrote: On 2/24/2022 12:41 PM, Dmitry Baryshkov wrote: On Thu, 24 Feb 2022 at 21:25, Abhinav Kumar wrote: On 2/18/2022 6:26 PM, Dmitry Baryshkov wrote: On 19/02/2022 02:56, Stephen Boyd wrote:

Re: [PATCH v5 1/4] drm/i915/guc: Add fetch of hwconfig table

John Harrison writes: > On 2/22/2022 02:36, Jordan Justen wrote: >> From: John Harrison >> >> Implement support for fetching the hardware description table from the >> GuC. The call is made twice - once without a destination buffer to >> query the size and then a second time to fill in the buffe

[PATCH] dma-fance: Add dma_fence_assert_in_signalling_section

Useful for checking for dma-fence signalling annotations since they don't quite nest as freely as we'd like to. Cc: Matthew Brost Signed-off-by: Daniel Vetter Cc: Sumit Semwal Cc: Gustavo Padovan Cc: "Christian König" Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org --- dri

[PATCH v7 15/24] drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz

From: Nickey Yang add 594Mhz configuration parameters in rockchip_phy_config Signed-off-by: Nickey Yang Signed-off-by: Sascha Hauer --- Notes: Changes since v3: - new patch drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/dr

[PATCH v7 05/24] arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'

The reference clock for the HDMI controller has been renamed to 'ref', the previous 'vpll' name is only left for compatibility in the driver. Rename the clock to the new name. Signed-off-by: Sascha Hauer --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 delet

[PATCH v7 14/24] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

From: Douglas Anderson Jitter was improved by lowering the MPLL bandwidth to account for high frequency noise in the rk3288 PLL. In each case MPLL bandwidth was lowered only enough to get us a comfortable margin. We believe that lowering the bandwidth like this is safe given sufficient testing.

[PATCH v7 00/24] drm/rockchip: RK356x VOP2 support

Here is v7 of adding RK356x VOP2 support. The one big notable change this time is that I moved the of_graph parsing from runtime code into initialization, see patch 2/24. Other than that there are some smaller changes due to the review feedback to v6. Sascha Changes since v6: - Move of_graph pars

[PATCH v7 02/24] drm/rockchip: Add crtc_endpoint_id to rockchip_encoder

The VOP2 has an interface mux which decides to which encoder(s) a CRTC is routed to. The encoders and CRTCs are connected via of_graphs in the device tree. When given an encoder the VOP2 driver needs to know to which internal register setting this encoder matches. For this the VOP2 binding offers d

[PATCH v7 13/24] drm/rockchip: dw_hdmi: drop mode_valid hook

The driver checks if the pixel clock of the given mode matches an entry in the mpll config table. The frequencies in the mpll table are meant as a frequency range up to which the entry works, not as a frequency that must match the pixel clock. The downstream Kernel also does not have this check, so

[PATCH v7 03/24] drm/rockchip: dw_hdmi: rename vpll clock to reference clock

"vpll" is a misnomer. A clock input to a device should be named after the usage in the device, not after the clock that drives it. On the rk3568 the same clock is driven by the HPLL. To fix that, this patch renames the vpll clock to ref clock. The clock name "vpll" is left for compatibility to old

[PATCH v7 18/24] arm64: dts: rockchip: rk356x: Add HDMI nodes

Add support for the HDMI port found on RK3568. Signed-off-by: Sascha Hauer --- Notes: Changes since v5: - Drop unnecessary #size-cells/#address-cells from nodes with only single endpoint arch/arm64/boot/dts/rockchip/rk356x.dtsi | 32 1 file changed, 32 inserti

[PATCH v7 12/24] drm/rockchip: dw_hdmi: Use auto-generated tables

From: Douglas Anderson The previous tables for mpll_cfg and curr_ctrl were created using the 20-pages of example settings provided by the PHY vendor. Those example settings weren't particularly dense, so there were places where we were guessing what the settings would be for 10-bit and 12-bit (n

[PATCH v7 10/24] drm/rockchip: dw_hdmi: Add support for hclk

The rk3568 HDMI has an additional clock that needs to be enabled for the HDMI controller to work. The purpose of that clock is not clear. It is named "hclk" in the downstream driver, so use the same name. Signed-off-by: Sascha Hauer --- Notes: Changes since v5: - Use devm_clk_get_optiona

[PATCH v7 19/24] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi

This enabled the VOP2 display controller along with hdmi and the required port routes which is enough to get a picture out of the hdmi port of the board. Signed-off-by: Sascha Hauer --- Notes: Changes since v5: - Drop reg property from single endpoint node Changes since v4:

[PATCH v7 07/24] dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMI

From: Benjamin Gaignard Define a new compatible for rk3568 HDMI. This version of HDMI hardware block needs two new clocks hclk_vio and hclk to provide phy reference clocks. Signed-off-by: Benjamin Gaignard Reviewed-by: Rob Herring Signed-off-by: Sascha Hauer --- .../devicetree/bindings/displ

[PATCH v7 06/24] drm/rockchip: dw_hdmi: add rk3568 support

Add a new dw_hdmi_plat_data struct and new compatible for rk3568. Signed-off-by: Benjamin Gaignard Signed-off-by: Sascha Hauer --- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 + 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c

[PATCH v7 22/24] drm: rockchip: Add VOP2 driver

From: Andy Yan The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. It replaces the VOP unit found in the older Rockchip SoCs. This driver has been derived from the downstream Rockchip Kernel and heavily modified: - All nonstandard DRM properties have been removed - dropped str

[PATCH v7 08/24] drm/rockchip: dw_hdmi: add regulator support

The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed for the HDMI port. add support for these to the driver for boards which have them supplied by switchable regulators. Signed-off-by: Sascha Hauer Reviewed-by: Dmitry Osipenko --- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c

[PATCH v7 24/24] dt-bindings: display: rockchip: dw-hdmi: fix ports description

Current port description doesn't cover all possible cases. It currently expects one single port with two endpoints. When the HDMI connector is described in the device tree there can be two ports, first one going to the VOP and the second one going to the connector. Also on SoCs which only have a

[PATCH v7 23/24] dt-bindings: display: rockchip: Add binding for VOP2

The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566. The binding differs slightly from the existing VOP binding, so add a new binding file for it. Signed-off-by: Sascha Hauer Reviewed-by: Rob Herring --- Notes: Changes since v5: - Add Robs Reviewed-by: Change

[PATCH v7 11/24] dt-bindings: display: rockchip: dw-hdmi: Add additional clock

The rk3568 HDMI has an additional clock that needs to be enabled for the HDMI controller to work. The purpose of that clock is not clear. It is named "hclk" in the downstream driver, so use the same name. Signed-off-by: Sascha Hauer Acked-by: Rob Herring --- Notes: Changes since v4: - A

[PATCH v7 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a

From: Michael Riesch Enable the RK356x Video Output Processor (VOP) 2 on the Pine64 Quartz64 Model A. Signed-off-by: Michael Riesch Signed-off-by: Sascha Hauer --- Notes: Changes since v5: - Drop reg property from single endpoint node Changes since v4: - Sort nodes alphab

[PATCH v7 01/24] drm/rockchip: Embed drm_encoder into rockchip_decoder

The VOP2 driver needs rockchip specific information for a drm_encoder. This patch creates a struct rockchip_encoder with a struct drm_encoder embedded in it. This is used throughout the rockchip driver instead of struct drm_encoder directly. The information the VOP2 drivers needs is the of_graph

[PATCH v7 17/24] arm64: dts: rockchip: rk356x: Add VOP2 nodes

The VOP2 is the display output controller on the RK3568. Add the node for it to the dtsi file along with the required display-subsystem node and the iommu node. Signed-off-by: Sascha Hauer Acked-by: Rob Herring --- Notes: Changes since v4: - Add Robs Ack Changes since v3: -

[PATCH v7 16/24] dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional

None of the upstream device tree files has a "unwedge" pinctrl specified. Make it optional. Signed-off-by: Sascha Hauer Acked-by: Rob Herring --- Notes: Changes since v4: - Add Robs Ack .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 + 1 file changed, 1 insertion

[PATCH v7 09/24] dt-bindings: display: rockchip: dw-hdmi: Add regulator support

The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed for the HDMI port. Add the binding for these supplies. Signed-off-by: Sascha Hauer Acked-by: Rob Herring --- Notes: Changes since v4: - Add Robs Ack .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11

[PATCH v7 04/24] dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name

"vpll" is a misnomer. A clock input to a device should be named after the usage in the device, not after the clock that drives it. On the rk3568 the same clock is driven by the HPLL. This patch adds "ref" as a new alternative clock name for "vpll" Signed-off-by: Sascha Hauer Acked-by: Rob Herring

[PATCH v7 21/24] drm/rockchip: Make VOP driver optional

With upcoming VOP2 support VOP won't be the only choice anymore, so make the VOP driver optional. Signed-off-by: Sascha Hauer --- drivers/gpu/drm/rockchip/Kconfig| 8 drivers/gpu/drm/rockchip/Makefile | 3 ++- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- 3 f

<    1   2