Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option
On Thu, Aug 25, 2022 at 02:41:27PM +0200, Noralf Trønnes wrote: > Den 24.08.2022 17.45, skrev Maxime Ripard: > > Hi Noralf, > > > > On Sat, Aug 20, 2022 at 10:18:47PM +0200, Noralf Trønnes wrote: > >> Den 29.07.2022 18.35, skrev Maxime Ripard: > >>> Our new tv mode option allows to specify the TV mode from a property. > >>> However, it can still be useful, for example to avoid any boot time > >>> artifact, to set that property directly from the kernel command line. > >>> > >>> Let's add some code to allow it, and some unit tests to exercise that > >>> code. > >>> > >>> Signed-off-by: Maxime Ripard > >>> > >> > >> In the subject it says "tv_mode property", but the property is called > >> "tv norm", so the option should be tv_norm? > > > > Yeah... I don't know. mode is taken but it's obviously the best name. So > > I went with norm to avoid the (internal) conflict but I left mode for > > the user facing property. > > > > I'm not sure what's best here, or maybe we can pick another name entirely? > > > > Why not just call it "tv mode" or even better "TV Mode". The state > member can be called tv_mode, but the mode_config member will need a > temporary name until the "mode" property is removed. tv_tv_mode or maybe > connector_tv_mode? Yeah, that seems like a good idea. Would legacy_tv_mode work for you? > But IMO, if there are no users of this property, adding it should have a > drm maintainers ack. Yep, of course :) Maxime signature.asc Description: PGP signature
Re: [PATCH 2/2] drm/i915: Add DSC support to MST path
On Thu, Aug 25, 2022 at 07:04:33PM +0300, Govindapillai, Vinod wrote:
> On Thu, 2022-08-25 at 18:17 +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> > > Hi Stan,
> > >
> > > Some comments inline..
> > >
> > > On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > > > Whenever we are not able to get enough timeslots
> > > > for required PBN, let's try to allocate those
> > > > using DSC, just same way as we do for SST.
> > > >
> > > > v2: Removed intel_dp_mst_dsc_compute_config and refactored
> > > > intel_dp_dsc_compute_config to support timeslots as a
> > > > parameter(Ville Syrjälä)
> > > >
> > > > v3: - Rebased
> > > > - Added a debug to see that we at least try reserving
> > > > VCPI slots using DSC, because currently its not visible
> > > > from the logs, thus making debugging more tricky.
> > > > - Moved timeslots to numerator, where it should be.
> > > >
> > > > v4: - Call drm_dp_mst_atomic_check already during link
> > > > config computation, because we need to know already
> > > > by this moment if uncompressed amount of VCPI slots
> > > > needed can fit, otherwise we need to use DSC.
> > > > (thanks to Vinod Govindapillai for pointing this out)
> > > >
> > > > v5: - Put pipe_config->bigjoiner_pipes back to original
> > > > condition in intel_dp_dsc_compute_config
> > > > (don't remember when I lost it)
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 73 -
> > > > drivers/gpu/drm/i915/display/intel_dp.h | 17 +++
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 157
> > > > 3 files changed, 205 insertions(+), 42 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 32292c0be2bd..519b436fc530 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -116,7 +116,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > > > }
> > > >
> > > > static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> > > > -static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> > > > dsc_max_bpc);
> > > >
> > > > /* Is link rate UHBR and thus 128b/132b? */
> > > > bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
> > > > @@ -687,11 +686,12 @@ small_joiner_ram_size_bits(struct
> > > > drm_i915_private *i915)
> > > > return 6144 * 8;
> > > > }
> > > >
> > > > -static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > > > - u32 link_clock, u32 lane_count,
> > > > - u32 mode_clock, u32
> > > > mode_hdisplay,
> > > > - bool bigjoiner,
> > > > - u32 pipe_bpp)
> > > > +u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > > > + u32 link_clock, u32 lane_count,
> > > > + u32 mode_clock, u32 mode_hdisplay,
> > > > + bool bigjoiner,
> > > > + u32 pipe_bpp,
> > > > + u32 timeslots)
> > > > {
> > > > u32 bits_per_pixel, max_bpp_small_joiner_ram;
> > > > int i;
> > > > @@ -702,8 +702,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > > > drm_i915_private *i915,
> > > > * for SST -> TimeSlotsPerMTP is 1,
> > > > * for MST -> TimeSlotsPerMTP has to be calculated
> > > > */
> > > > - bits_per_pixel = (link_clock * lane_count * 8) /
> > > > + bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> > > > intel_dp_mode_to_fec_clock(mode_clock);
> > > > + drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
> > > >
> > > > /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz.
> > > > width */
> > > > max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
> > > > @@ -752,9 +753,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > > > drm_i915_private *i915,
> > > > return bits_per_pixel << 4;
> > > > }
> > > >
> > > > -static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > > > - int mode_clock, int
> > > > mode_hdisplay,
> > > > - bool bigjoiner)
> > > > +u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > > > + int mode_clock, int mode_hdisplay,
> > > > + bool bigjoiner)
> > > > {
> > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > u8 min_slice_count, i;
> > > > @@ -961,8 +962,8 @@ intel_dp_mode_valid_
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
Quoting John Harrison (2022-08-25 19:31:39) > On 8/25/2022 00:15, Joonas Lahtinen wrote: > > Quoting John Harrison (2022-08-24 21:45:09) > >> On 8/24/2022 02:01, Joonas Lahtinen wrote: > >>> NACK on this one. Let's get this reverted or fixed to eliminate > >>> new module parameters. > >>> > >>> What prevents us just from using the maximum sizes? Or alternatively > >>> we could check the already existing drm.debug variable or anything else > >>> but addding 3 new module parameters. > >> We don't want to waste 24MB of memory for all users when 99.999% of them > >> don't care about GuC logs. > > It is not exactly wasting memory if it is what is needed to capture > > the error logs to properly debug a system. And it's definitely not much > > on any modern system where you will have a GPU. You can always leave > > the Kconfig options in place for the cases where it matters. > > > > On the other hand, if 99.999% don't need this, then it could just stay > > as a kernel config time option as well? > No. The point is that we need to able to ask customers to increase the > log size, repro an issue and send us the results. Or we could just ask them to provide the logs for each bug report and save one round trip time. > All on a pre-installed > system where they do not have the option to build a custom kernel. If you argue that way, they don't always have an easy way to change the kernel cmdline options either. Accounting for initrd, update-grub etc. > Either we always allocate the maximum and waste the memory for all end > users or we have a runtime configuration option. Doesn't have to be maximum (as there seems to be limitations in log readback speeds also), just something that is useful for most of the debug scenarios. > Compile time is not > acceptable for some important customers/situations. Yet spending the time discussing how to make the debug logs useful with the issue reporter wouldn't be an issue in such urgency? One can argue what is most convenient way, but there's no way to beat sane default. If somebody has problem with that extra memory usage, then we have the config options to reduce/disable. > >> We also don't want to tie the GuC logging buffer size to the DRM > >> debugging output. Enabling kernel debug output can change timings and > >> prevent the issue that one is trying to capture in the GuC log. And it > >> seems unlikely we could add an entire new top level DRM debug flag just > >> for an internal i915 only log buffer size. Plus drm.debug is explicitly > >> stated as being dynamically changeable via sysfs at any time. The GuC > >> log buffer size cannot be changed without reloading the i915 driver. Or > >> at least, not without reloading the GuC, but we definitely don't want to > >> create a UAPI for arbitrarily reloading the GuC. > >> > >> We can make these parameters 'unsafe' so that they taint the kernel if > >> used. But this is exactly what module parameters are for - configuration > >> that we don't want to hardcode as CONFIG options but which must be set > >> at module load time. > > It's better to have sane defaults. And if somebody wants something > > strange, they can have a Kconfig behind EXPERT option. But even then > > there should really be need for it. > Define sane. I was hoping you would be the expert on that as you've suggested the patch to begin with. Try to aim to cover >90% of the debug scenarios (that are only 0.001%) and we're already only needing to recompile kernel in 1 per million cases. We can live with that. I will push a fixup to remove the module parameters, please figure the rest out in a timely manner. Regards, Joonas > > Sane for most users is to not allocate 24MB of memory for an internal > debug only buffer they will never use. And which completely swamps any > error capture log with the ASCII encoding of said buffer. > > But as above, we need a way to (very occasionally) get larger GuC logs > from customers without rebuilding the kernel. > > John. > > > > > So for now, let's get the module parameters reverted and go with > > reasonable default buffer sizes when GuC is enabled. The compile time > > options can be left in place. > > > > Thank you in advance. > > > > Regards, Joonas > > > >> John. > >> > >>> For future reference, please do Cc maintainers when adding new uAPI > >>> like module parameters. > >>> > >>> Regards, Joonas > >>> > >>> Quoting john.c.harri...@intel.com (2022-07-28 05:20:27) > From: John Harrison > > The GuC log buffer sizes had to be configured statically at compile > time. This can be quite troublesome when needing to get larger logs > out of a released driver. So re-organise the code to allow a boot time > module parameter override. > > Signed-off-by: John Harrison > --- > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 53 ++ > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 14 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 176
[git pull] drm fixes for 6.0-rc3
Hi Linus, Weekly fixes, lots of amdgpu fixes mostly for IP blocks introduced in 6.0-rc1, otherwise vc4, nouveau fixes. There is a backmerge in here to resync our misc-fixes tree with fixes after rc1, but it should be harmless. Regards, Dave. drm-fixes-2022-08-26-1: drm fixes for 6.0-rc3 gem: - Fixes handle release leak nouveau: - fix fencing when moving BO vc4: - HDMI fixes amdgpu: - GFX 11.0 fixes - PSP XGMI handling fixes - GFX9 fix for compute-only IPs - Drop duplicated function call - Fix warning due to missing header - NBIO 7.7 fixes - DCN 3.1.4 fixes - SDMA 6.0 fixes - SMU 13.0 fixes - Arcturus GPUVM page table fix - MMHUB 1.0 fix amdkfd: - GC 10.3.7 fix radeon: - Delayed work flush fix The following changes since commit 1c23f9e627a7b412978b4e852793c5e3c3efc555: Linux 6.0-rc2 (2022-08-21 17:32:54 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-08-26-1 for you to fetch changes up to 100d0ae82b5c240a4dc17486698e67bf116bd598: Merge tag 'amd-drm-fixes-6.0-2022-08-25' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2022-08-26 09:56:53 +1000) drm fixes for 6.0-rc3 gem: - Fixes handle release leak nouveau: - fix fencing when moving BO vc4: - HDMI fixes amdgpu: - GFX 11.0 fixes - PSP XGMI handling fixes - GFX9 fix for compute-only IPs - Drop duplicated function call - Fix warning due to missing header - NBIO 7.7 fixes - DCN 3.1.4 fixes - SDMA 6.0 fixes - SMU 13.0 fixes - Arcturus GPUVM page table fix - MMHUB 1.0 fix amdkfd: - GC 10.3.7 fix radeon: - Delayed work flush fix Candice Li (1): drm/amdgpu: Check num_gfx_rings for gfx v9_0 rb setup. Dave Airlie (2): Merge tag 'drm-misc-fixes-2022-08-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-6.0-2022-08-25' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Evan Quan (1): drm/amd/pm: update SMU 13.0.0 driver_if header Jeffy Chen (1): drm/gem: Fix GEM handle release errors Karol Herbst (1): nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf Likun Gao (1): drm/amdgpu: add MGCG perfmon setting for gfx11 Maxime Ripard (2): drm/vc4: hdmi: Depends on CONFIG_PM drm/vc4: hdmi: Rework power up Maíra Canal (1): drm/amd/display: Include missing header Mukul Joshi (1): drm/amdgpu: Fix page table setup on Arcturus Prike Liang (1): drm/amdkfd: Fix isa version for the GC 10.3.7 Qu Huang (1): drm/amdgpu: mmVM_L2_CNTL3 register not initialized correctly Roman Li (1): drm/amd/display: enable PCON support for dcn314 Thomas Zimmermann (1): Merge drm/drm-fixes into drm-misc-fixes Tim Huang (5): drm/amdgpu: enable GFXOFF allow control for GC IP v11.0.1 drm/amdgpu: add TX_POWER_CTRL_1 macro definitions for NBIO IP v7.7.0 drm/amdgpu: add NBIO IP v7.7.0 Clock Gating support drm/amdgpu: enable NBIO IP v7.7.0 Clock Gating drm/amdgpu: add sdma instance check for gfx11 CGCG YiPeng Chai (2): drm/amdgpu: Move psp_xgmi_terminate call from amdgpu_xgmi_remove_device to psp_hw_fini drm/amdgpu: fix hive reference leak when adding xgmi device Zhenneng Li (1): drm/radeon: add a force flush to delay work when radeon shaoyunl (1): drm/amdgpu: Remove the additional kfd pre reset call for sriov drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 24 --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 +- drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c| 1 + drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c| 12 +++- drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c | 78 ++ drivers/gpu/drm/amd/amdgpu/soc21.c | 22 -- drivers/gpu/drm/amd/amdkfd/kfd_device.c| 6 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c| 5 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h| 8 --- .../drm/amd/display/dc/dcn314/dcn314_resource.c| 1 + .../amd/include/asic_reg/nbio/nbio_7_7_0_offset.h | 2 + .../amd/include/asic_reg/nbio/nbio_7_7_0_sh_mask.h | 13 .../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 31 + drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +- drivers/gpu/drm/drm_gem.c | 17 + drivers/gpu/drm/drm_internal.h | 4 +- drivers/gpu/drm/drm_prime.c| 20 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++ drivers/gpu/drm/radeon/radeon_device.c | 3 + drivers/gpu/drm/vc4/Kconfig| 1 + drivers/gpu/drm/vc4/vc4_hdmi.c | 17 +++-- 24 fi
Re: [PATCH v1 00/35] drm: Analog TV Improvements
Hi Maxime, Noralf and everyone,
Just as a quick update. I isolated the issue to the power management subsystem.
Unfortunately I know very little about the power management subsystem so
I don't think I can help.
There are two alternative dirty ad-hoc hacks that get things working.
- Commenting out the pm_runtime_put() / pm_runtime_get_sync() calls in vc4_vec.c
- Reverting this PR by Dom Cobley a.k.a. popcornmix:
https://github.com/raspberrypi/linux/pull/4639
Either of these approaches makes VEC mode switching work again. Obviously
neither is appropriate for a permanent solution.
I tried some random code permutations that came to my mind, like using the
vc4_encoder callbacks (e.g. post_crtc_powerdown) instead of the standard
enable/disable encoder callbacks, but to no avail.
Since the clocks and power management seem to be delegated to the firmware now,
my guess is that this might be a firmware issue, but I can't really check all
the firmware versions. It certainly crashes on the version currently available
in Raspberry Pi OS repos, and on this one:
https://github.com/raspberrypi/rpi-firmware/commit/4dde751. My Pi4 doesn't boot
using any newer firmware, at least not from USB - I might try some SD card
after the weekend.
Best regards,
Mateusz Kwiatkowski
W dniu 25.08.2022 o 18:17, Mateusz Kwiatkowski pisze:
Hi Maxime,
W dniu 25.08.2022 o 17:55, Maxime Ripard pisze:
Hi Mateusz,
On Mon, Aug 22, 2022 at 10:57:26AM +0200, Mateusz Kwiatkowski wrote:
Hi Maxime,
I tried testing and reviewing your changes properly over the last weekend, but
ultimately ran into this ("flip_done timed out" etc.) issue and was unable to
mitigate it, at least so far. This seems to pop up every time I try to change
modes in any way (either change the TV norm, or just try doing
"xrandr --output Composite-1 --off" followed by bringing it back on; it also
means that the Pi goes unusable when the DE's screen saving routine kicks in).
I'm using a Pi 4, and it works with the rpi-5.13.y branch
https://github.com/raspberrypi/linux, but seemingly nothing newer.
I specifically tried rpi-5.14.y, rpi-5.15.y and rpi-5.19.y - rpi-5.15.y,
which is the current main branch in Raspberry Pi OS, seems to be broken since
forever; at least since my patches (originally written for 5.10) landed there.
I'll try identifying the issue further, possibly later today, and maybe check
the rpi-6.0.y branch as well.
I've tried it this, and I can't reproduce it here. But I'm curious, how
did you apply this series? rpi-5.13.y is probably full of conflicts
everywhere?
I applied your patches onto rpi-5.15.y. There were conflicts, but they seemed
relatively minor. I'm not sure if I did a good job at resolving them - I ran
into various problems trying to test your changes, but I chose not to criticize
you before making sure that it's really due to your changes, or without some
remarks more constructive than "doesn't work" ;-)
I can push my rebase onto some Github fork if you're interested.
I was able to work around some of those problems, and also saw that some
of them were already mentioned by other reviewers (such as the generic modes
not matching due to the aspect ratio setting).
Ultimately I got stuck on this bug, so I put testing this series on hold
in favor of debugging the bigger issue. So far unfortunately no luck with it.
I did not try rebasing your changes onto 5.13 or older.
Maxime
Best regards,
Mateusz Kwiatkowski
RE: vm binding interfaces and parallel with mmap
Sorry for the outlook reply, so in XE that works the opposite of AMDGPU. Mappings keep a reference to the BO and the mapping exist until they are explicitly destroyed or the VM is destroyed, so if a mapping exists the BO exists. Quickly implemented a prototype extension to the VM bind IOCTL that blows away all mappings on a BO per Jason’s suggestion, for XE it was really straight forward. I’d have to double check the i915 reference counting wrt to BO and mappings but I suspect it works like XE. IMO this paradigm is the way to go as it does match open / mmap / close semantics. Matt From: Christian König Sent: Thursday, August 25, 2022 6:37 AM To: Jason Ekstrand Cc: Bas Nieuwenhuizen ; Dave Airlie ; dri-devel ; Daniel Vetter ; Brost, Matthew ; Ben Skeggs Subject: Re: vm binding interfaces and parallel with mmap Am 24.08.22 um 18:14 schrieb Jason Ekstrand: On Mon, Aug 22, 2022 at 8:27 AM Christian König mailto:christian.koe...@amd.com>> wrote: [SNIP] >> I suppose it also asks the question around paralleling >> >> fd = open() >> ptr = mmap(fd,) >> close(fd) >> the mapping is still valid. >> >> I suppose our equiv is >> handle = bo_alloc() >> gpu_addr = vm_bind(handle,) >> gem_close(handle) >> is the gpu_addr still valid does the VM hold a reference on the kernel >> bo internally. > For Vulkan it looks like this is undefined and the above is not necessary: > > "It is important to note that freeing a VkDeviceMemory object with > vkFreeMemory will not cause resources (or resource regions) bound to > the memory object to become unbound. Applications must not access > resources bound to memory that has been freed." > (32.7.6) I'm not sure about this particular question. We need to be sure that maps get cleaned up eventually. On the one hand, I think it's probably a valid API implementation to have each mapped page hold a reference similar to mmap and have vkDestroyImage or vkDestroyBuffer do an unmap to clean up the range. However, clients may be surprised when they destroy a large memory object and can't reap the memory because of extra BO references they don't know about. If BOs unmap themselves on close or if we had a way to take a VM+BO and say "unmap this BO from everywhere, please", we can clean up the memory pretty easily. Without that, it's a giant PITA to do entirely inside the userspace driver because it requires us to globally track every mapping and that means data structures and locks. Yes, such an ioctl would require the kernel to track things but the kernel is already tracking everything that's bound, so hopefully it doesn't add much. For both amdgpu as well as the older radeon mapping a BO does *not* grab a reference to it. Whenever a BO is released all it's mappings just disappear. We need to keep track of the mappings anyway to recreate page tables after (for example) suspend and resume, so that isn't any overhead. Regards, Christian. --Jason Additional to what was discussed here so far we need an array on in and out drm_syncobj for both map as well as unmap. E.g. when the mapping/unmapping should happen and when it is completed etc... Christian. > > >> Dave. >>> Dave.
[PATCH v2 0/3] Drop version numbers from firmware files
From: John Harrison Upstream direction is to include the bare minimum of version numbers in firmware files and to replace them in the repo rather than accumulating them. For HuC, that means going completely versionless. For GuC, the major version needs to be kept as that indicates a break in backwards compatibility with the KMD. v2: Fix a bunch of issues and add better documentation (some found in code review by Daniele, other through more thorough testing). Signed-off-by: John Harrison CC: Daniele Ceraolo Spurio John Harrison (3): drm/i915/uc: Support for version reduced and multiple firmware files drm/i915/uc: Add patch level version number support drm/i915/uc: Enable version reduced firmware files for newest platforms .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 468 -- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 39 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 8 +- drivers/gpu/drm/i915/i915_gpu_error.c | 16 +- 6 files changed, 358 insertions(+), 191 deletions(-) -- 2.37.2
[PATCH v2 2/3] drm/i915/uc: Add patch level version number support
From: John Harrison
With the move to un-versioned filenames, it becomes more difficult to
know exactly what version of a given firmware is being used. So add
the patch level version number to the debugfs output.
Also, support matching by patch level when selecting code paths for
firmware compatibility. While a patch level change cannot be backwards
breaking, it is potentially possible that a new feature only works
from a given patch level onwards (even though it was theoretically
added in an earlier version that bumped the major or minor version).
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 36 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 6
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 8 +++--
5 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 04393932623c7..64c4e83153f47 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.file_selected.major_ver < 70) {
+ if (GET_UC_VER(guc) < MAKE_UC_VER(70, 0, 0)) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct intel_context *ce,
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.file_selected.major_ver >= 70)
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct intel_context *ce,
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- if (guc->fw.file_selected.major_ver >= 70)
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0))
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void __guc_context_set_preemption_timeout(struct
intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.file_selected.major_ver >= 70) {
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.file_selected.major_ver >= 70) {
+ if (GET_UC_VER(guc) >= MAKE_UC_VER(70, 0, 0)) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index d965ac4832d60..abf4e142596d0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -435,9 +435,11 @@ static void print_fw_ver(struct intel_uc *uc, struct
intel_uc_fw *fw)
{
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
- drm_info(&i915->drm, "%s firmware %s version %u.%u\n",
+ drm_info(&i915->drm, "%s firmware %s version %u.%u.%u\n",
intel_uc_fw_type_repr(fw->type), fw->file_selected.path,
-fw->file_selected.major_ver, fw->file_selected.minor_ver);
+fw->file_selected.major_ver,
+fw->file_selected.minor_ver,
+fw->file_selected.patch_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 94cf2d4a46e6f..7c45c097d6845 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -447,10 +447,12 @@ static int check_gsc_manifest(const struct firmware *fw,
struct intel_uc_fw *uc_fw)
{
u32 *dw = (u32 *)fw->data;
- u32 version = dw[HUC_GSC_VERSION_DW];
+ u32 version_hi = dw[HUC_GSC_VERSION_HI_DW];
+ u32 version_lo = dw[HUC_GSC_VERSION_LO_DW];
- uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_MASK,
version);
- uc_fw->file_selected.minor_ver = FIELD_GET(HUC_GSC_MINOR_VER_MASK,
version);
+ uc_fw->file_selected.major_ver = FIELD_GET(HUC_GSC_MAJOR_VER_HI_MASK,
version_hi);
+ uc_fw->file_selected.minor_ver = FI
[PATCH v2 3/3] drm/i915/uc: Enable version reduced firmware files for newest platforms
From: John Harrison Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for DG1/2 and ADL-P/S. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 7c45c097d6845..d6e6fe10c5aca 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -72,11 +72,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ - fw_def(DG2, 0, guc_mmp(dg2, 70, 4, 1)) \ + fw_def(DG2, 0, guc_maj(dg2, 70, 4)) \ + fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \ + fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \ + fw_def(DG1, 0, guc_maj(dg1, 70, 1)) \ fw_def(DG1, 0, guc_mmp(dg1, 70, 1, 1)) \ fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \ fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \ @@ -92,8 +95,11 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp) \ + fw_def(ALDERLAKE_P, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(ALDERLAKE_S, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_S, 0, huc_mmp(tgl, 7, 9, 3)) \ + fw_def(DG1, 0, huc_raw(dg1)) \ fw_def(DG1, 0, huc_mmp(dg1, 7, 9, 3)) \ fw_def(ROCKETLAKE, 0, huc_mmp(tgl, 7, 9, 3)) \ fw_def(TIGERLAKE,0, huc_mmp(tgl, 7, 9, 3)) \ -- 2.37.2
[PATCH v2 1/3] drm/i915/uc: Support for version reduced and multiple firmware files
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware releases forever
new minor firmware releases should replace prior versions
only backwards compatibility breaking releases should be a new file
This patch cleans up the single fallback file support that was added
as a quick fix emergency effort. That is now removed in preference to
supporting arbitrary numbers of firmware files per platform.
The patch also adds support for having GuC firmware files that are
named by major version only (because the major version indicates
backwards breaking changes that affect the KMD) and for having HuC
firmware files with no version number at all (because the KMD has no
interface requirements with the HuC).
For GuC, the driver will report via dmesg if the found file is older than
expected. For HuC, the KMD will no longer require updating for any new
HuC release so will not be able to report what the latest expected
version is.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 442 --
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 33 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +-
5 files changed, 319 insertions(+), 186 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0d56b615bf78e..04393932623c7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.major_ver_found < 70) {
+ if (guc->fw.file_selected.major_ver < 70) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct intel_context *ce,
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_selected.major_ver >= 70)
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct intel_context *ce,
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_selected.major_ver >= 70)
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void __guc_context_set_preemption_timeout(struct
intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_selected.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_selected.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f2e7c82985efd..d965ac4832d60 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -436,8 +436,8 @@ static void print_fw_ver(struct intel_uc *uc, struct
intel_uc_fw *fw)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
drm_info(&i915->drm, "%s firmware %s version %u.%u\n",
-intel_uc_fw_type_repr(fw->type), fw->path,
-fw->major_ver_found, fw->minor_ver_found);
+intel_uc_fw_type_repr(fw->type), fw->file_selected.path,
+fw->file_selected.major_ver, fw->file_selected.minor_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 58547292efa0a..94cf2d4a46e6f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -41,7 +41,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
"%s firmware -> %s\n",
intel_uc_fw_type_repr(uc_fw->type),
status == INTEL_UC_FIRMWARE_SELECTED ?
- uc_fw->path : intel_uc_fw_status_r
linux-next: build failure after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/gt/uc/intel_guc.c: In function 'intel_guc_dump_time_info':
drivers/gpu/drm/i915/gt/uc/intel_guc.c:399:9: error: implicit declaration of
function 'intel_device_info_print_runtime'; did you mean
'intel_device_info_print'? [-Werror=implicit-function-declaration]
399 | intel_device_info_print_runtime(RUNTIME_INFO(gt->i915), p);
| ^~~
| intel_device_info_print
Caused by commit
c7d3c8447b26 ("drm/i915: combine device info printing into one")
interacting with commit
368d179adbac ("drm/i915/guc: Add GuC <-> kernel time stamp translation
information")
from the drm tree.
I have applied the following merge fix patch for today:
From: Stephen Rothwell
Date: Fri, 26 Aug 2022 12:30:19 +1000
Subject: [PATCH] fix up for "drm/i915/guc: Add GuC <-> kernel time stamp
translation information"
interacting with "drm/i915: combine device info printing into one".
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index ab4aacc516aa..977278d71182 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -396,7 +396,7 @@ void intel_guc_dump_time_info(struct intel_guc *guc, struct
drm_printer *p)
u32 stamp = 0;
u64 ktime;
- intel_device_info_print_runtime(RUNTIME_INFO(gt->i915), p);
+ intel_device_info_print(INTEL_INFO(gt->i915), RUNTIME_INFO(gt->i915),
p);
with_intel_runtime_pm(>->i915->runtime_pm, wakeref)
stamp = intel_uncore_read(gt->uncore, GUCPMTIMESTAMP);
--
2.35.1
--
Cheers,
Stephen Rothwell
pgpNixShiSLT8.pgp
Description: OpenPGP digital signature
[PATCH] drm/ast: add dmabuf/prime buffer sharing support
This patch adds ast specific codes for DRM prime feature, this is to
allow for offloading of rending in one direction and outputs in other.
This patch is designed to solve the problem that the AST is not displayed
when the server plug in a discrete graphics graphics card at the same time.
We call the dirty callback function to copy the rendering results of the
discrete graphics card to the ast side by dma-buf.
v1->v2:
- Fix the comment.
v2->v3:
- we remove the attach function, add the drm_gem_pin() before dma_buf_vmap(),
and add the drm_gem_unpin() after the dma_buf_vunmap().
Signed-off-by: oushixiong
---
drivers/gpu/drm/ast/ast_drv.c | 27 +++
drivers/gpu/drm/ast/ast_mode.c | 134 -
drivers/gpu/drm/drm_gem.c | 2 +
include/drm/drm_gem.h | 3 +
4 files changed, 165 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 7465c4f0156a..107383a56ca7 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -50,6 +51,29 @@ module_param_named(modeset, ast_modeset, int, 0400);
DEFINE_DRM_GEM_FOPS(ast_fops);
+struct drm_gem_object *ast_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ struct drm_gem_vram_object *gbo;
+
+ gbo = drm_gem_vram_of_gem(dma_buf->priv);
+ if (gbo->bo.base.dev == dev) {
+ /*
+ * Importing dmabuf exported from out own gem increases
+ * refcount on gem itself instead of f_count of dmabuf.
+ */
+ drm_gem_object_get(&gbo->bo.base);
+ return &gbo->bo.base;
+ }
+
+ gbo = drm_gem_vram_create(dev, dma_buf->size, 0);
+ if (IS_ERR(gbo))
+ return NULL;
+
+ get_dma_buf(dma_buf);
+ return &gbo->bo.base;
+}
+
static const struct drm_driver ast_driver = {
.driver_features = DRIVER_ATOMIC |
DRIVER_GEM |
@@ -63,6 +87,9 @@ static const struct drm_driver ast_driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_import = ast_gem_prime_import,
+
DRM_GEM_VRAM_DRIVER
};
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 45b56b39ad47..c81a6148b6df 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -48,6 +48,8 @@
#include "ast_drv.h"
#include "ast_tables.h"
+MODULE_IMPORT_NS(DMA_BUF);
+
static inline void ast_load_palette_index(struct ast_private *ast,
u8 index, u8 red, u8 green,
u8 blue)
@@ -1535,8 +1537,138 @@ static const struct drm_mode_config_helper_funcs
ast_mode_config_helper_funcs =
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
+static int ast_handle_damage(struct drm_framebuffer *fb, int x, int y,
+ int width, int height)
+{
+ struct drm_gem_vram_object *dst_bo = NULL;
+ void *dst = NULL;
+ int ret = 0, i;
+ unsigned long offset = 0;
+ bool unmap = false;
+ unsigned int bytesPerPixel;
+ struct iosys_map map;
+ struct iosys_map dmabuf_map;
+
+ bytesPerPixel = fb->format->cpp[0];
+
+ if (!fb->obj[0]->dma_buf)
+ return -EINVAL;
+
+ if (!fb->obj[0]->dma_buf->vmap_ptr.vaddr) {
+ ret = drm_gem_pin(fb->obj[0]->dma_buf->priv);
+ if (ret)
+ return ret;
+ ret = dma_buf_vmap(fb->obj[0]->dma_buf, &dmabuf_map);
+ if (ret)
+ goto err_vmap_dmabuf;
+ } else
+ dmabuf_map.vaddr = fb->obj[0]->dma_buf->vmap_ptr.vaddr;
+
+ dst_bo = drm_gem_vram_of_gem(fb->obj[0]);
+
+ ret = drm_gem_vram_pin(dst_bo, 0);
+ if (ret) {
+ DRM_ERROR("ast_bo_pin failed\n");
+ goto err_ast_pin;
+ }
+
+ if (!dst_bo->map.vaddr) {
+ ret = drm_gem_vram_vmap(dst_bo, &map);
+ if (ret) {
+ DRM_ERROR("failed to vmap fbcon\n");
+ goto err_vmap_ast_bo;
+ }
+ unmap = true;
+ }
+ dst = dst_bo->map.vaddr;
+
+ for (i = y; i < y + height; i++) {
+ offset = i * fb->pitches[0] + (x * bytesPerPixel);
+ memcpy_toio(dst + offset, dmabuf_map.vaddr + offset,
+ width * bytesPerPixel);
+ }
+
+ if (unmap)
+ drm_gem_vram_vunmap(dst_bo, &map);
+
+ drm_gem_vram_unpin(dst_bo);
+ return 0;
+
+err_vmap_ast_bo:
+ drm_gem_vram_unpin(dst_bo);
+err_ast_pin:
+err_vmap_dmabuf:
+ drm_gem_unpin(fb->obj[0]->dma_buf->priv);
+
Re: [Intel-gfx] [PATCH 1/2] drm/i915/uc: Support for version reduced and multiple firmware files
On 8/24/2022 21:49, Ceraolo Spurio, Daniele wrote:
On 8/16/2022 1:28 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware releases forever
new minor firmware releases should replace prior versions
only backwards compatibility breaking releases should be a new file
Hence this patch cleans up the single fallback file support that was
added as a quick fix emergency effort. That is now removed in
preference to supporting arbitrary numbers of firmware files per
platform as normal.
The patch also adds support for having GuC firmwrae files that are
named by major version only (because the major version indicates
backwards breaking changes that affect the KMD) and for having HuC
firmware files with no version number at all (because the KMD has no
interface requirements with the HuC).
For GuC, the driver will report via dmesg if the found file is older
than
expected. For HuC, the KMD will no longer require updating for any new
HuC release so will not be able to report what the latest expected
version is.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 396 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 33 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +-
5 files changed, 275 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0d17da77e7872..d1715971fdd79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc
*guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.major_ver_found < 70) {
+ if (guc->fw.file_found.major_ver < 70) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct
intel_context *ce, bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_found.major_ver >= 70)
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct
intel_context *ce, bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_found.major_ver >= 70)
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void
__guc_context_set_preemption_timeout(struct intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_found.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct
intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_found.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f2e7c82985efd..0697128cc3362 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -436,8 +436,8 @@ static void print_fw_ver(struct intel_uc *uc,
struct intel_uc_fw *fw)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
drm_info(&i915->drm, "%s firmware %s version %u.%u\n",
- intel_uc_fw_type_repr(fw->type), fw->path,
- fw->major_ver_found, fw->minor_ver_found);
+ intel_uc_fw_type_repr(fw->type), fw->file_found.path,
+ fw->file_found.major_ver, fw->file_found.minor_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 58547292efa0a..eb3a15f0fa479 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -41,7 +41,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw
*uc_fw,
"%s firmware -> %s\n",
intel_uc_fw_type_repr(uc_fw->type),
status == INTEL_UC_FIRMWARE_SELECTED ?
- uc_fw->path : intel_uc_fw_status_repr(status));
+ uc_fw->file_found.path : intel_uc_fw_status_repr(status));
}
#endif
@@ -52,83 +52,113 @@ v
Re: [PATCH linux-next v2] drm/mediatek: Remove the unneeded result
Hi, cgel:
於 2022年8月25日 週四 下午3:24寫道：
>
> From: ye xingchen
>
> Return the value drm_mode_config_helper_suspend() directly instead of
> storing it in another redundant variable.
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Reported-by: Zeal Robot
> Signed-off-by: ye xingchen
> ---
> v1 -> v2
> Add all the mailinglists that get_maintainers.pl give.
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 5f02f8d0e4fc..91f58db5915f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -833,11 +833,8 @@ static int mtk_drm_sys_prepare(struct device *dev)
> {
> struct mtk_drm_private *private = dev_get_drvdata(dev);
> struct drm_device *drm = private->drm;
> - int ret;
> -
> - ret = drm_mode_config_helper_suspend(drm);
>
> - return ret;
> + return drm_mode_config_helper_suspend(drm);
> }
>
> static void mtk_drm_sys_complete(struct device *dev)
> --
> 2.25.1
Re: [PATCH 2/5] drm/mediatek: Drop of_gpio header
Hi, Maira: Maíra Canal 於 2022年8月13日 週六 凌晨4:58寫道： > > These drivers include the deprecated OF GPIO header > yet fail to use symbols from it, so drop the include. Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Cc: Chun-Kuang Hu > Cc: Philipp Zabel > Cc: Matthias Brugger > Cc: linux-media...@lists.infradead.org > Signed-off-by: Maíra Canal > --- > drivers/gpu/drm/mediatek/mtk_dpi.c | 1 - > drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c > b/drivers/gpu/drm/mediatek/mtk_dpi.c > index 630a4e301ef6..508a6d994e83 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c > @@ -11,7 +11,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c > b/drivers/gpu/drm/mediatek/mtk_hdmi.c > index 3196189429bc..4c80b6896dc3 100644 > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c > @@ -16,7 +16,6 @@ > #include > #include > #include > -#include > #include > #include > #include > -- > 2.37.1 >
Re: [PATCH 2/5] dt-bindings: ata: drop minItems equal to maxItems
On 8/25/22 20:33, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Damien Le Moal > --- > Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml | 1 - > .../devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml | 2 -- > Documentation/devicetree/bindings/ata/sata_highbank.yaml| 1 - > 3 files changed, 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > index 235a93ac86b0..3766cc80cb17 100644 > --- a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > +++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > @@ -30,7 +30,6 @@ properties: >- const: brcm,bcm-nsp-ahci > >reg: > -minItems: 2 > maxItems: 2 > >reg-names: > diff --git > a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > index 21a90975593b..529093666508 100644 > --- a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > +++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > @@ -22,7 +22,6 @@ properties: > maxItems: 1 > >resets: > -minItems: 2 > maxItems: 2 > description: phandles to the reset lines for both SATA bridges > > @@ -32,7 +31,6 @@ properties: >- const: sata1 > >clocks: > -minItems: 2 > maxItems: 2 > description: phandles to the compulsory peripheral clocks > > diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.yaml > b/Documentation/devicetree/bindings/ata/sata_highbank.yaml > index 49679b58041c..f23f26a8f21c 100644 > --- a/Documentation/devicetree/bindings/ata/sata_highbank.yaml > +++ b/Documentation/devicetree/bindings/ata/sata_highbank.yaml > @@ -52,7 +52,6 @@ properties: > minItems: 1 > maxItems: 8 > items: > - minItems: 2 >maxItems: 2 > >calxeda,tx-atten: -- Damien Le Moal Western Digital Research
Re: mainline build failure for x86_64 allmodconfig with clang
Hi AMD folks, Top posting because it might not have been obvious but I was looking for your feedback on this message (which can be viewed on lore.kernel.org if you do not have the original [1]) so that we can try to get this fixed in some way for 6.0/6.1. If my approach is not welcome, please consider suggesting another one or looking to see if this is something you all could look into. [1]: https://lore.kernel.org/Yv5h0rb3AgTZLVJv@dev-arch.thelio-3990X/ Cheers, Nathan On Thu, Aug 18, 2022 at 08:59:14AM -0700, Nathan Chancellor wrote: > Hi Arnd, > > Doubling back around to this now since I think this is the only thing > breaking x86_64 allmodconfig with clang 11 through 15. > > On Fri, Aug 05, 2022 at 09:32:13PM +0200, Arnd Bergmann wrote: > > On Fri, Aug 5, 2022 at 8:02 PM Nathan Chancellor wrote: > > > On Fri, Aug 05, 2022 at 06:16:45PM +0200, Arnd Bergmann wrote: > > > > On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland > > > > wrote: > > > > While splitting out sub-functions can help reduce the maximum stack > > > > usage, it seems that in this case it makes the actual problem worse: > > > > I see 2168 bytes for the combined > > > > dml32_ModeSupportAndSystemConfigurationFull(), but marking > > > > mode_support_configuration() as noinline gives me 1992 bytes > > > > for the outer function plus 384 bytes for the inner one. So it does > > > > avoid the warning (barely), but not the problem that the warning tries > > > > to point out. > > > > > > I haven't had a chance to take a look at splitting things up yet, would > > > you recommend a different approach? > > > > Splitting up large functions can help when you have large local variables > > that are used in different parts of the function, and the split gets the > > compiler to reuse stack locations. > > > > I think in this particular function, the problem isn't actually local > > variables > > but either pushing variables on the stack for argument passing, > > or something that causes the compiler to run out of registers so it > > has to spill registers to the stack. > > > > In either case, one has to actually look at the generated output > > and then try to rearrange the codes so this does not happen. > > > > One thing to try would be to condense a function call like > > > > dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport( > > > > &v->dummy_vars.dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport, > > mode_lib->vba.USRRetrainingRequiredFinal, > > mode_lib->vba.UsesMALLForPStateChange, > > > > mode_lib->vba.PrefetchModePerState[mode_lib->vba.VoltageLevel][mode_lib->vba.maxMpcComb], > > mode_lib->vba.NumberOfActiveSurfaces, > > mode_lib->vba.MaxLineBufferLines, > > mode_lib->vba.LineBufferSizeFinal, > > mode_lib->vba.WritebackInterfaceBufferSize, > > mode_lib->vba.DCFCLK, > > mode_lib->vba.ReturnBW, > > mode_lib->vba.SynchronizeTimingsFinal, > > > > mode_lib->vba.SynchronizeDRRDisplaysForUCLKPStateChangeFinal, > > mode_lib->vba.DRRDisplay, > > v->dpte_group_bytes, > > v->meta_row_height, > > v->meta_row_height_chroma, > > > > v->dummy_vars.DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation.mmSOCParameters, > > mode_lib->vba.WritebackChunkSize, > > mode_lib->vba.SOCCLK, > > v->DCFCLKDeepSleep, > > mode_lib->vba.DETBufferSizeY, > > mode_lib->vba.DETBufferSizeC, > > mode_lib->vba.SwathHeightY, > > mode_lib->vba.SwathHeightC, > > mode_lib->vba.LBBitPerPixel, > > v->SwathWidthY, > > v->SwathWidthC, > > mode_lib->vba.HRatio, > > mode_lib->vba.HRatioChroma, > > mode_lib->vba.vtaps, > > mode_lib->vba.VTAPsChroma, > > mode_lib->vba.VRatio, > > mode_lib->vba.VRatioChroma, > > mode_lib->vba.HTotal, > > mode_lib->vba.VTotal, > > mode_lib->vba.VActive, > > mode_lib->vba.PixelClock, > > mode_lib->vba.BlendingAndTiming, > > /* more arguments */); > > > > into calling conventions that take a pointer to 'mode_lib->vba' and another > > one to 'v', so these are no longer passed on the stack individually. > > So I took a whack at reducing this function's number of parameters and > ended up with the attached patch. I basically just removed any > parameters that were
Re: [PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)
On 8/25/22 9:37 AM, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.
Changes in v2:
- Use the new shared nvidia-wmi-ec-backlight.h header for the
WMI firmware API definitions
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Changes in v3:
- Use WMI_BRIGHTNESS_GUID define
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/Kconfig | 1 +
drivers/acpi/video_detect.c| 37 ++
drivers/gpu/drm/gma500/Kconfig | 2 ++
drivers/gpu/drm/i915/Kconfig | 2 ++
include/acpi/video.h | 1 +
5 files changed, 43 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7802d8846a8d..44ad4b6bd234 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -212,6 +212,7 @@ config ACPI_VIDEO
tristate "Video"
depends on BACKLIGHT_CLASS_DEVICE
depends on INPUT
+ depends on ACPI_WMI || !X86
select THERMAL
help
This driver implements the ACPI Extensions For Display Adapters
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index cc9d0d91e268..4dc7fb865083 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -75,6 +76,36 @@ find_video(acpi_handle handle, u32 lvl, void *context, void
**rv)
return AE_OK;
}
+/* This depends on ACPI_WMI which is X86 only */
+#ifdef CONFIG_X86
This could probably also provide the { return false; } stub which you
have for non-x86 if the kernel is built without nvidia-wmi-ec-backight,
e.g.:
#if defined(CONFIG_X86) && (defined(CONFIG_NVIDIA_WMI_EC_BACKLIGHT) ||
defined(CONFIG_NVIDIA_WMI_EC_BACKLIGHT_MODULE))
Although I suppose that would break things if somebody has a kernel that
originally had NVIDIA_WMI_EC_BACKLIGHT=n in Kconfig, and then builds the
nvidia-wmi-ec-backlight driver out-of-tree later. I don't know whether
that's intended to be a supported use case, so I guess it is fine either
way.
+static bool nvidia_wmi_ec_supported(void)
+{
+ struct wmi_brightness_args args = {
+ .mode = WMI_BRIGHTNESS_MODE_GET,
+ .val = 0,
+ .ret = 0,
+ };
+ struct acpi_buffer buf = { (acpi_size)sizeof(args), &args };
+ acpi_status status;
+
+ status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0,
+WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ /*
+* If brightness is handled by the EC then nvidia-wmi-ec-backlight
+* should be used, else the GPU driver(s) should be used.
+*/
+ return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
+}
+#else
+static bool nvidia_wmi_ec_supported(void)
+{
+ return false;
+}
+#endif
+
/* Force to use vendor driver when the ACPI device is known to be
* buggy */
static int video_detect_force_vendor(const struct dmi_system_id *d)
@@ -541,6 +572,7 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool nvidia_wmi_ec_present;
static bool native_available;
static bool init_done;
static long video_caps;
@@ -553,6 +585,7 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
+ nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
init_done = true;
}
if (native)
@@ -570,6 +603,10 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
+ /* Special cases such as nvidia_wmi_ec and apple gmux. */
+ if (nvidia_wmi_ec_present)
+ return acpi_backlight_nvidia_wmi_ec;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0cff20265f97..807b989e3c77 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -7,6 +7,8 @@ config DRM_GMA500
select ACPI_VIDEO if ACPI
select BAC
Re: [PATCH v5 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2)
Thanks, Hans.
Reviewed-by: Daniel Dadap
On 8/25/22 9:37 AM, Hans de Goede wrote:
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Changes in v2:
- Add missing Nvidia copyright header
- Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
MAINTAINERS | 1 +
.../platform/x86/nvidia-wmi-ec-backlight.c| 68 +
.../x86/nvidia-wmi-ec-backlight.h | 76 +++
3 files changed, 78 insertions(+), 67 deletions(-)
create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d7f64dc0efe..d6f6b96f51f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14527,6 +14527,7 @@ M: Daniel Dadap
L:platform-driver-...@vger.kernel.org
S:Supported
F:drivers/platform/x86/nvidia-wmi-ec-backlight.c
+F: include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
NVM EXPRESS DRIVER
M:Keith Busch
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index 61e37194df70..be803e47eac0 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -7,74 +7,10 @@
#include
#include
#include
+#include
#include
#include
-/**
- * enum wmi_brightness_method - WMI method IDs
- * @WMI_BRIGHTNESS_METHOD_LEVEL: Get/Set EC brightness level status
- * @WMI_BRIGHTNESS_METHOD_SOURCE: Get/Set EC Brightness Source
- */
-enum wmi_brightness_method {
- WMI_BRIGHTNESS_METHOD_LEVEL = 1,
- WMI_BRIGHTNESS_METHOD_SOURCE = 2,
- WMI_BRIGHTNESS_METHOD_MAX
-};
-
-/**
- * enum wmi_brightness_mode - Operation mode for WMI-wrapped method
- * @WMI_BRIGHTNESS_MODE_GET:Get the current brightness
level/source.
- * @WMI_BRIGHTNESS_MODE_SET:Set the brightness level.
- * @WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL: Get the maximum brightness level. This
- * is only valid when the WMI method is
- * %WMI_BRIGHTNESS_METHOD_LEVEL.
- */
-enum wmi_brightness_mode {
- WMI_BRIGHTNESS_MODE_GET = 0,
- WMI_BRIGHTNESS_MODE_SET = 1,
- WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL = 2,
- WMI_BRIGHTNESS_MODE_MAX
-};
-
-/**
- * enum wmi_brightness_source - Backlight brightness control source selection
- * @WMI_BRIGHTNESS_SOURCE_GPU: Backlight brightness is controlled by the GPU.
- * @WMI_BRIGHTNESS_SOURCE_EC: Backlight brightness is controlled by the
- * system's Embedded Controller (EC).
- * @WMI_BRIGHTNESS_SOURCE_AUX: Backlight brightness is controlled over the
- * DisplayPort AUX channel.
- */
-enum wmi_brightness_source {
- WMI_BRIGHTNESS_SOURCE_GPU = 1,
- WMI_BRIGHTNESS_SOURCE_EC = 2,
- WMI_BRIGHTNESS_SOURCE_AUX = 3,
- WMI_BRIGHTNESS_SOURCE_MAX
-};
-
-/**
- * struct wmi_brightness_args - arguments for the WMI-wrapped ACPI method
- * @mode:Pass in an &enum wmi_brightness_mode value to select between
- * getting or setting a value.
- * @val: In parameter for value to set when using %WMI_BRIGHTNESS_MODE_SET
- * mode. Not used in conjunction with %WMI_BRIGHTNESS_MODE_GET or
- * %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL mode.
- * @ret: Out parameter returning retrieved value when operating in
- * %WMI_BRIGHTNESS_MODE_GET or %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL
- * mode. Not used in %WMI_BRIGHTNESS_MODE_SET mode.
- * @ignored: Padding; not used. The ACPI method expects a 24 byte params
struct.
- *
- * This is the parameters structure for the WmiBrightnessNotify ACPI method as
- * wrapped by WMI. The value passed in to @val or returned by @ret will be a
- * brightness value when the WMI method ID is %WMI_BRIGHTNESS_METHOD_LEVEL, or
- * an &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
- */
-struct wmi_brightness_args {
- u32 mode;
- u32 val;
- u32 ret;
- u32 ignored[3];
-};
-
/**
* wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI
method
* @w:Pointer to the struct wmi_device identified by %WMI_BRIGHTNESS_GUID
@@ -191,8 +127,6 @@ static int nvidia_wmi_ec_backlight_probe(struct wmi_device
*wdev, const void *ct
return PTR_ERR_OR_ZERO(bdev);
}
-#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
-
static const struct wmi_device_id nvidia_wmi_ec_backlight_id_table[] = {
{ .guid_string = WMI_BRIGHTNESS_GUID },
{ }
diff --git a/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
new file mode 100644
index ..23d60130272c
--- /dev/null
+++ b/include/linux/platform_data/x86/nvidia-wmi-ec-backlig
Re: [PATCH] gpu: move from strlcpy with unused retval to strscpy
Dne četrtek, 18. avgust 2022 ob 23:00:07 CEST je Wolfram Sang napisal(a): > Follow the advice of the below link and prefer 'strscpy' in this > subsystem. Conversion is 1:1 because the return value is not used. > Generated by a coccinelle script. > > Link: > https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmk > n...@mail.gmail.com/ Signed-off-by: Wolfram Sang > Acked-by: Jernej Skrabec Best regards, Jernej > --- > drivers/gpu/drm/amd/amdgpu/atom.c | 2 +- > drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 +++--- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/display/drm_dp_helper.c | 2 +- > drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_mipi_dsi.c | 2 +- > drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_perf.c | 2 +- > drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 2 +- > drivers/gpu/drm/radeon/radeon_atombios.c| 4 ++-- > drivers/gpu/drm/radeon/radeon_combios.c | 4 ++-- > drivers/gpu/drm/rockchip/inno_hdmi.c| 2 +- > drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 +- > drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 2 +- > 15 files changed, 19 insertions(+), 19 deletions(-)
Re: [PATCH v4 00/10] dt-bindings: display/msm: rework MDSS and DPU bindings
On Thu, 25 Aug 2022 at 23:11, Rob Herring wrote: > > On Thu, Aug 25, 2022 at 12:50:53PM +0300, Dmitry Baryshkov wrote: > > Create separate YAML schema for MDSS devicesd$ (both for MDP5 and DPU > > devices). Cleanup DPU schema files, so that they do not contain schema > > for both MDSS and DPU nodes. Apply misc small fixes to the DPU schema > > afterwards. > > > > Changes since v3: > > - Changed mdss->(dpu, dsi, etc.) relationship into the tight binding > >dependin on the mdss compatible string. > > - Added sm8250 dpu schema and added qcom,sm8250-mdss to mdss.yaml > > My scripts tell me I reviewed these, but I don't really follow what's > changed. Previously I used the $ref for the mdss child nodes (which resulted in errors for disabled DSI PHY nodes). These were replaced with binding dpu/dsi/hdmi/phy nodes using the compatible properties rather than using $ref. -- With best wishes Dmitry
Re: [PATCH v4 00/10] dt-bindings: display/msm: rework MDSS and DPU bindings
On Thu, Aug 25, 2022 at 12:50:53PM +0300, Dmitry Baryshkov wrote: > Create separate YAML schema for MDSS devicesd$ (both for MDP5 and DPU > devices). Cleanup DPU schema files, so that they do not contain schema > for both MDSS and DPU nodes. Apply misc small fixes to the DPU schema > afterwards. > > Changes since v3: > - Changed mdss->(dpu, dsi, etc.) relationship into the tight binding >dependin on the mdss compatible string. > - Added sm8250 dpu schema and added qcom,sm8250-mdss to mdss.yaml My scripts tell me I reviewed these, but I don't really follow what's changed. Rob
Re: [PATCH] dt-bindings: display: adi,adv75xx: Add missing graph schema references
On Tue, 23 Aug 2022 09:56:43 -0500, Rob Herring wrote: > DT bindings using the graph binding must have references to the graph > binding schema. These are missing from the adi,adv7511 and adi,adv7533 > bindings, so add them. > > Signed-off-by: Rob Herring > --- > .../bindings/display/bridge/adi,adv7511.yaml | 14 ++ > .../bindings/display/bridge/adi,adv7533.yaml | 14 ++ > 2 files changed, 12 insertions(+), 16 deletions(-) > Applied, thanks!
Re: [PATCH v1 00/35] drm: Analog TV Improvements
Den 25.08.2022 18.21, skrev Maxime Ripard: > On Mon, Aug 22, 2022 at 03:21:29PM +0200, Noralf Trønnes wrote: >> >> >> Den 22.08.2022 09.48, skrev Maxime Ripard: >>> Hi, >>> >>> On Sun, Aug 21, 2022 at 06:33:12PM +0200, Noralf Trønnes wrote: Den 29.07.2022 18.34, skrev Maxime Ripard: > Hi, > > Here's a series aiming at improving the command line named modes support, > and more importantly how we deal with all the analog TV variants. > > The named modes support were initially introduced to allow to specify the > analog TV mode to be used. > > However, this was causing multiple issues: > > * The mode name parsed on the command line was passed directly to the > driver, which had to figure out which mode it was suppose to match; > > * Figuring that out wasn't really easy, since the video= argument or > what > the userspace might not even have a name in the first place, but > instead could have passed a mode with the same timings; > > * The fallback to matching on the timings was mostly working as long as > we were supporting one 525 lines (most likely NSTC) and one 625 lines > (PAL), but couldn't differentiate between two modes with the same > timings (NTSC vs PAL-M vs NSTC-J for example); > > * There was also some overlap with the tv mode property registered by > drm_mode_create_tv_properties(), but named modes weren't interacting > with that property at all. > > * Even though that property was generic, its possible values were > specific to each drivers, which made some generic support difficult. > > Thus, I chose to tackle in multiple steps: > > * A new TV norm property was introduced, with generic values, each > driver > reporting through a bitmask what standard it supports to the > userspace; > > * This option was added to the command line parsing code to be able to > specify it on the kernel command line, and new atomic_check and reset > helpers were created to integrate properly into atomic KMS; > > * The named mode parsing code is now creating a proper display mode for > the given named mode, and the TV standard will thus be part of the > connector state; > > * Two drivers were converted and tested for now (vc4 and sun4i), with > some backward compatibility code to translate the old TV mode to the > new TV mode; > > Unit tests were created along the way. Nouveau, ch7006 and gud are > currently broken for now since I expect that work to be reworked fairly > significantly. I'm also not entirely sure about how to migrate GUD to the > new property. > > Let me know what you think, > Maxime > I don't know if it's related to this patchset or not, but I do get this: pi@pi4t:~ $ sudo dmesg -C && sudo modprobe -r vc4 && sudo modprobe vc4 && dmesg [ 430.066211] Console: switching to colour dummy device 80x30 [ 431.294788] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) [ 431.295115] vc4-drm gpu: bound fec13000.vec (ops vc4_vec_ops [vc4]) [ 431.295467] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4]) [ 431.295804] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 431.298895] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 [ 441.444250] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done timed out [ 441.446529] Console: switching to colour frame buffer device 90x30 [ 451.684321] vc4-drm gpu: [drm] *ERROR* flip_done timed out [ 451.684347] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] commit wait timed out [ 461.924255] vc4-drm gpu: [drm] *ERROR* flip_done timed out [ 461.924281] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:45:Composite-1] commit wait timed out [ 472.164006] vc4-drm gpu: [drm] *ERROR* flip_done timed out [ 472.164031] vc4-drm gpu: [drm] *ERROR* [PLANE:61:plane-1] commit wait timed out [ 482.403877] vc4-drm gpu: [drm] *ERROR* flip_done timed out [ 482.403903] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit [ 492.643799] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done timed out [ 492.647073] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device >>> >>> Module unloading/reloading has been janky for a while. >>> >>> I've fixed it up recently but it doesn't surprise me that there's still >>> some situation that won't work. Is it on a Pi3? >>> >> >> It's a Pi4. > > With which kernel? I just tested it on last next and it seems to work ok > there. I've fixed it recently though, so it's only in drm-misc-next and > linux-next at the moment. > I'm on a week old drm-misc-next. What's your setup so I can try that. This is mine: https://gist.github.com/notro/41c59d77c3022dc6d931d4f9547c4e
[PATCH] drm: panel-orientation-quirks: Add quirk for Aya Neo Air
From: Maya Matuszczyk
Yet another x86 gaming handheld.
This one has many SKUs with quite a few of DMI strings,
so let's just use a catchall, just as with Aya Neo Next.
Signed-off-by: Maya Matuszczyk
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index fc1728d46ac2..0b011b615495 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -103,6 +103,12 @@ static const struct drm_dmi_panel_orientation_data
lcd800x1280_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data lcd1080x1920_leftside_up = {
+ .width = 1080,
+ .height = 1920,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
static const struct drm_dmi_panel_orientation_data lcd1200x1920_rightside_up =
{
.width = 1200,
.height = 1920,
@@ -152,6 +158,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "AYA NEO 2021"),
},
.driver_data = (void *)&lcd800x1280_rightside_up,
+ }, {/* AYA NEO AIR */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "AYANEO"),
+ DMI_MATCH(DMI_BOARD_NAME, "AIR"),
+ },
+ .driver_data = (void *)&lcd1080x1920_leftside_up,
}, {/* AYA NEO NEXT */
.matches = {
DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AYANEO"),
--
2.37.2
Re: [PATCH 4/4] amd/display: indicate support for atomic async page-flips on DCN
On Wed, Aug 24, 2022 at 11:09 AM Simon Ser wrote: > > amdgpu_dm_commit_planes already sets the flip_immediate flag for > async page-flips. This flag is used to set the UNP_FLIP_CONTROL > register. Thus, no additional change is required to handle async > page-flips with the atomic uAPI. > > Note, async page-flips are still unsupported on DCE with the atomic > uAPI. The mode_set_base callbacks unconditionally set the > GRPH_SURFACE_UPDATE_H_RETRACE_EN field of the GRPH_FLIP_CONTROL > register to 0, which disables async page-flips. Can you elaborate a bit on this? We don't use hsync flips at all, even in non-atomic, as far as I recall. The hardware can also do immediate flips which take effect as soon as you update the base address register which is what we use for async updates today IIRC. Alex > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Joshua Ashton > Cc: Melissa Wen > Cc: Alex Deucher > Cc: Harry Wentland > Cc: Nicholas Kazlauskas > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index ef816bf295eb..9ab01c58bedb 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -3804,7 +3804,6 @@ static int amdgpu_dm_mode_config_init(struct > amdgpu_device *adev) > adev_to_drm(adev)->mode_config.prefer_shadow = 0; > /* indicates support for immediate flip */ > adev_to_drm(adev)->mode_config.async_page_flip = true; > - adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = > true; > > adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base; > > -- > 2.37.2 > >
[pull] amdgpu, amdkfd, radeon drm-fixes-6.0
Hi Dave, Daniel, Fixes for 6.0. Mainly fixes for new IPs added in 6.0. The following changes since commit b1fb6b87ed55ced458b322ea10cf0d0ab151e01b: Merge tag 'amd-drm-fixes-6.0-2022-08-17' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2022-08-19 09:45:22 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.0-2022-08-25 for you to fetch changes up to b8983d42524f10ac6bf35bbce6a7cc8e45f61e04: drm/amdgpu: mmVM_L2_CNTL3 register not initialized correctly (2022-08-25 13:54:35 -0400) amd-drm-fixes-6.0-2022-08-25: amdgpu: - GFX 11.0 fixes - PSP XGMI handling fixes - GFX9 fix for compute-only IPs - Drop duplicated function call - Fix warning due to missing header - NBIO 7.7 fixes - DCN 3.1.4 fixes - SDMA 6.0 fixes - SMU 13.0 fixes - Arcturus GPUVM page table fix - MMHUB 1.0 fix amdkfd: - GC 10.3.7 fix radeon: - Delayed work flush fix Candice Li (1): drm/amdgpu: Check num_gfx_rings for gfx v9_0 rb setup. Evan Quan (1): drm/amd/pm: update SMU 13.0.0 driver_if header Likun Gao (1): drm/amdgpu: add MGCG perfmon setting for gfx11 Maíra Canal (1): drm/amd/display: Include missing header Mukul Joshi (1): drm/amdgpu: Fix page table setup on Arcturus Prike Liang (1): drm/amdkfd: Fix isa version for the GC 10.3.7 Qu Huang (1): drm/amdgpu: mmVM_L2_CNTL3 register not initialized correctly Roman Li (1): drm/amd/display: enable PCON support for dcn314 Tim Huang (5): drm/amdgpu: enable GFXOFF allow control for GC IP v11.0.1 drm/amdgpu: add TX_POWER_CTRL_1 macro definitions for NBIO IP v7.7.0 drm/amdgpu: add NBIO IP v7.7.0 Clock Gating support drm/amdgpu: enable NBIO IP v7.7.0 Clock Gating drm/amdgpu: add sdma instance check for gfx11 CGCG YiPeng Chai (2): drm/amdgpu: Move psp_xgmi_terminate call from amdgpu_xgmi_remove_device to psp_hw_fini drm/amdgpu: fix hive reference leak when adding xgmi device Zhenneng Li (1): drm/radeon: add a force flush to delay work when radeon shaoyunl (1): drm/amdgpu: Remove the additional kfd pre reset call for sriov drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 24 --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 +- drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c| 1 + drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c| 12 +++- drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c | 78 ++ drivers/gpu/drm/amd/amdgpu/soc21.c | 22 -- drivers/gpu/drm/amd/amdkfd/kfd_device.c| 6 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c| 5 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h| 8 --- .../drm/amd/display/dc/dcn314/dcn314_resource.c| 1 + .../amd/include/asic_reg/nbio/nbio_7_7_0_offset.h | 2 + .../amd/include/asic_reg/nbio/nbio_7_7_0_sh_mask.h | 13 .../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 31 + drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 3 + 18 files changed, 173 insertions(+), 47 deletions(-)
Re: [PATCH 5/5] drm/msm: Skip tlbinv on unmap from non-current pgtables
On 8/25/2022 12:32 AM, Rob Clark wrote: On Wed, Aug 24, 2022 at 10:46 AM Akhil P Oommen wrote: On 8/21/2022 11:49 PM, Rob Clark wrote: From: Rob Clark We can rely on the tlbinv done by CP_SMMU_TABLE_UPDATE in this case. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 ++ drivers/gpu/drm/msm/msm_iommu.c | 29 +++ 2 files changed, 35 insertions(+) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index c8ad8aeca777..1ba0ed629549 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -1180,6 +1180,12 @@ static int hw_init(struct msm_gpu *gpu) /* Always come up on rb 0 */ a6xx_gpu->cur_ring = gpu->rb[0]; + /* + * Note, we cannot assume anything about the state of the SMMU when + * coming back from power collapse, so force a CP_SMMU_TABLE_UPDATE + * on the first submit. Also, msm_iommu_pagetable_unmap() relies on + * this behavior. + */ gpu->cur_ctx_seqno = 0; /* Enable the SQE_to start the CP engine */ diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c index 94c8c09980d1..218074a58081 100644 --- a/drivers/gpu/drm/msm/msm_iommu.c +++ b/drivers/gpu/drm/msm/msm_iommu.c @@ -45,8 +45,37 @@ static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu, u64 iova, size -= 4096; } + /* + * A CP_SMMU_TABLE_UPDATE is always sent for the first + * submit after resume, and that does a TLB invalidate. + * So we can skip that if the device is not currently + * powered. + */ + if (!pm_runtime_get_if_in_use(pagetable->parent->dev)) + goto out; + + /* + * If we are not the current pgtables, we can rely on the + * TLB invalidate done by CP_SMMU_TABLE_UPDATE. + * + * We'll always be racing with the GPU updating ttbr0, + * but there are only two cases: + * + * + either we are not the the current pgtables and there + *will be a tlbinv done by the GPU before we are again + * + * + or we are.. there might have already been a tblinv + *if we raced with the GPU, but we have to assume the + *worse and do the tlbinv + */ + if (adreno_smmu->get_ttbr0(adreno_smmu->cookie) != pagetable->ttbr) + goto out_put; + adreno_smmu->tlb_inv_by_id(adreno_smmu->cookie, pagetable->asid); +out_put: + pm_runtime_put(pagetable->parent->dev); +out: return (unmapped == size) ? 0 : -EINVAL; } Asking because it is a *security issue* if we get this wrong: 1. Is there any measure benefit with this patch? I believe tlb invalidation doesn't contribute much to the unmap latency. It turned out to not make a huge difference.. although I expect the part about skipping the inv when runtime suspended is still useful from a power standpoint (but don't have a great setup to measure that) Agree. Perhaps use the recently added 'suspended' flag instead of pm_runtime_get_if_in_use(). -Akhil. BR, -R 2. We at least should insert a full memory barrier before reading the ttbr0 register to ensure that everything we did prior to that is visible to smmu. But then I guess the cost of the full barrier would be similar to the tlb invalidation. Because it could lead to security issues or other very hard to debug issues, I would prefer this optimization only if there is a significant measurable gain. -Akhil.
Re: [PATCH] Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time"
Hi, On Thu, Aug 25, 2022 at 10:37 AM Doug Anderson wrote: > Reviewed-by: Douglas Anderson Thanks :) > Given that this is _not_ an area that I'm an expert in nor is it an > area where the consequences are super easy to analyze, I'm a little > hesitant to apply this to drm-misc-next myself. Ideally someone more > familiar with the driver would do it. However, if nobody steps up > after a few weeks and nobody has yelled about this patch, I'll apply > it. I'll take this opportunity to correct Andrzej's email address (my bad; I need to use the up-to-date MAINTAINERS / .mailmap when generating CC lists), in case he's one such expert. Brian
Re: [PATCH] Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time"
Hi,
On Mon, Aug 22, 2022 at 6:08 PM Brian Norris wrote:
>
> This reverts commit 211f276ed3d96e964d2d1106a198c7f4a4b3f4c0.
>
> For quite some time, core DRM helpers already ensure that any relevant
> connectors/CRTCs/etc. are disabled, as well as their associated
> components (e.g., bridges) when suspending the system. Thus,
> analogix_dp_bridge_{enable,disable}() already get called, which in turn
> call drm_panel_{prepare,unprepare}(). This makes these drm_panel_*()
> calls redundant.
>
> Besides redundancy, there are a few problems with this handling:
>
> (1) drm_panel_{prepare,unprepare}() are *not* reference-counted APIs and
> are not in general designed to be handled by multiple callers --
> although some panel drivers have a coarse 'prepared' flag that mitigates
> some damage, at least. So at a minimum this is redundant and confusing,
> but in some cases, this could be actively harmful.
>
> (2) The error-handling is a bit non-standard. We ignored errors in
> suspend(), but handled errors in resume(). And recently, people noticed
> that the clk handling is unbalanced in error paths, and getting *that*
> right is not actually trivial, given the current way errors are mostly
> ignored.
>
> (3) In the particular way analogix_dp_{suspend,resume}() get used (e.g.,
> in rockchip_dp_*(), as a late/early callback), we don't necessarily have
> a proper PM relationship between the DP/bridge device and the panel
> device. So while the DP bridge gets resumed, the panel's parent device
> (e.g., platform_device) may still be suspended, and so any prepare()
> calls may fail.
>
> So remove the superfluous, possibly-harmful suspend()/resume() handling
> of panel state.
>
> Fixes: 211f276ed3d9 ("drm: bridge: analogix/dp: add panel prepare/unprepare
> in suspend/resume time")
> Link: https://lore.kernel.org/all/yv2cpbd3picg%2f...@google.com/
> Signed-off-by: Brian Norris
> ---
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 -
> 1 file changed, 13 deletions(-)
I thought it was strange that the patch being reverted had my
Tested-by, so I tracked that down at least. Looks like that's from:
https://lore.kernel.org/lkml/CAD=FV=xxesza6n6mnegh1kbh7cel8xwx8cifflvf91+0jyf...@mail.gmail.com/
...where I tested the whole stack of 17 patches together. That means
that my Tested-by was legit but it wasn't as if I tested that one
patch and confirmed that it was useful / needed.
Your argument here sounds right to me. The panel should get prepared
through the normal means (analogix_dp_bridge_pre_enable()) and
unprepared through normal means (analogix_dp_bridge_disable()). ...and
whenever the Analogix gets moved to "panel bridge" then that will move
to just being part of the bridge chain. Having these calls directly in
the suspend/resume seems weird/wrong.
So while I'm not an expert enough in the quirks of the Analogix DP
driver to say for certain that your revert won't cause any problems at
all, if problems come up they should probably be fixed in a way that
doesn't involve re-adding these direct calls to the suspend/resume
callbacks. Thus:
Reviewed-by: Douglas Anderson
Given that this is _not_ an area that I'm an expert in nor is it an
area where the consequences are super easy to analyze, I'm a little
hesitant to apply this to drm-misc-next myself. Ideally someone more
familiar with the driver would do it. However, if nobody steps up
after a few weeks and nobody has yelled about this patch, I'll apply
it.
[PATCH v2] drm: Move radeon and amdgpu Kconfig options into their directories
Most Kconfig options to enable a driver are in the Kconfig file inside the relevant directory, move these two to the same. Signed-off-by: Andrew Davis Reviewed-by: Christian König --- Changes from v1: - Fix whitespace issue pointed out by Randy drivers/gpu/drm/Kconfig| 42 -- drivers/gpu/drm/amd/amdgpu/Kconfig | 22 drivers/gpu/drm/radeon/Kconfig | 22 3 files changed, 44 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 6c2256e8474be..24fa9ccd92a4e 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -234,50 +234,8 @@ source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" -config DRM_RADEON - tristate "ATI Radeon" - depends on DRM && PCI && MMU - depends on AGP || !AGP - select FW_LOADER - select DRM_DISPLAY_DP_HELPER - select DRM_DISPLAY_HELPER -select DRM_KMS_HELPER -select DRM_TTM - select DRM_TTM_HELPER - select POWER_SUPPLY - select HWMON - select BACKLIGHT_CLASS_DEVICE - select INTERVAL_TREE - help - Choose this option if you have an ATI Radeon graphics card. There - are both PCI and AGP versions. You don't need to choose this to - run the Radeon in plain VGA mode. - - If M is selected, the module will be called radeon. - source "drivers/gpu/drm/radeon/Kconfig" -config DRM_AMDGPU - tristate "AMD GPU" - depends on DRM && PCI && MMU - select FW_LOADER - select DRM_DISPLAY_DP_HELPER - select DRM_DISPLAY_HDMI_HELPER - select DRM_DISPLAY_HELPER - select DRM_KMS_HELPER - select DRM_SCHED - select DRM_TTM - select DRM_TTM_HELPER - select POWER_SUPPLY - select HWMON - select BACKLIGHT_CLASS_DEVICE - select INTERVAL_TREE - select DRM_BUDDY - help - Choose this option if you have a recent AMD Radeon graphics card. - - If M is selected, the module will be called amdgpu. - source "drivers/gpu/drm/amd/amdgpu/Kconfig" source "drivers/gpu/drm/nouveau/Kconfig" diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index d55275de8..36b1206124cff 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -1,4 +1,26 @@ # SPDX-License-Identifier: MIT + +config DRM_AMDGPU + tristate "AMD GPU" + depends on DRM && PCI && MMU + select FW_LOADER + select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_HDMI_HELPER + select DRM_DISPLAY_HELPER + select DRM_KMS_HELPER + select DRM_SCHED + select DRM_TTM + select DRM_TTM_HELPER + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select INTERVAL_TREE + select DRM_BUDDY + help + Choose this option if you have a recent AMD Radeon graphics card. + + If M is selected, the module will be called amdgpu. + config DRM_AMDGPU_SI bool "Enable amdgpu support for SI parts" depends on DRM_AMDGPU diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig index 52819e7f1fca1..5b0201cbf6b32 100644 --- a/drivers/gpu/drm/radeon/Kconfig +++ b/drivers/gpu/drm/radeon/Kconfig @@ -1,4 +1,26 @@ # SPDX-License-Identifier: MIT + +config DRM_RADEON + tristate "ATI Radeon" + depends on DRM && PCI && MMU + depends on AGP || !AGP + select FW_LOADER + select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_HELPER + select DRM_KMS_HELPER + select DRM_TTM + select DRM_TTM_HELPER + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select INTERVAL_TREE + help + Choose this option if you have an ATI Radeon graphics card. There + are both PCI and AGP versions. You don't need to choose this to + run the Radeon in plain VGA mode. + + If M is selected, the module will be called radeon. + config DRM_RADEON_USERPTR bool "Always enable userptr support" depends on DRM_RADEON -- 2.36.1
Re: [PATCH v9 2/8] util_macros: Add exact_type macro to catch type mis-match while compiling
On Wed, Aug 24, 2022 at 05:45:08PM +0900, Gwan-gyeong Mun wrote:
> It adds exact_type and exactly_pgoff_t macro to catch type mis-match while
> compiling. The existing typecheck() macro outputs build warnings, but the
> newly added exact_type() macro uses the BUILD_BUG_ON() macro to generate
> a build break when the types are different and can be used to detect
> explicit build errors.
>
> v6: Move macro addition location so that it can be used by other than drm
> subsystem (Jani, Mauro, Andi)
>
> Signed-off-by: Gwan-gyeong Mun
> Cc: Thomas Hellström
> Cc: Matthew Auld
> Cc: Nirmoy Das
> Cc: Jani Nikula
> Cc: Andi Shyti
> Cc: Mauro Carvalho Chehab
> ---
> include/linux/util_macros.h | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/include/linux/util_macros.h b/include/linux/util_macros.h
> index 72299f261b25..b6624b275257 100644
> --- a/include/linux/util_macros.h
> +++ b/include/linux/util_macros.h
> @@ -2,6 +2,9 @@
> #ifndef _LINUX_HELPER_MACROS_H_
> #define _LINUX_HELPER_MACROS_H_
>
> +#include
> +#include
> +
> #define __find_closest(x, a, as, op) \
> ({ \
> typeof(as) __fc_i, __fc_as = (as) - 1; \
> @@ -38,4 +41,26 @@
> */
> #define find_closest_descending(x, a, as) __find_closest(x, a, as, >=)
>
> +/**
> + * exact_type - break compile if source type and destination value's type are
> + * not the same
> + * @T: Source type
> + * @n: Destination value
> + *
> + * It is a helper macro for a poor man's -Wconversion: only allow variables
> of
> + * an exact type. It determines whether the source type and destination
> value's
> + * type are the same while compiling, and it breaks compile if two types are
> + * not the same
> + */
> +#define exact_type(T, n) \
> + BUILD_BUG_ON(!__builtin_constant_p(n) &&
> !__builtin_types_compatible_p(T, typeof(n)))
Maybe use __same_type() here instead of open-coded
__builtin_types_compatible_p()? Also, IIUC, currently coding style
advise is to use _Static_assert when possible over BUILD_BUG_ON for
error message readability.
This macro has a trap-door for literals, yes?
i.e. exact_type(pgoff_t, 5) will pass?
I also note that this is very close to the really common (and open-coded)
test scattered around the kernel already (BUILD_BUG_ON(__same_type(a,
b))), so I think it's good to get a macro defined for it, though I'm not
sure about the trap door test. Regardless, I'd like to bikeshed the name
a bit; I think this should be named something a bit more clear about
what happens on failure. Perhaps: assert_type()? Or to capture the
trapdoor idea, assert_typable()?
#define assert_type(t1, t2) _Static_assert(__same_type(t1, t2))
#define assert_typable(t, n)_Static_assert(__builtin_constant_p(n) ||
__same_type(t, typeof(n))
> +
> +/**
> + * exactly_pgoff_t - helper to check if the type of a value is pgoff_t
> + * @n: value to compare pgoff_t type
> + *
> + * It breaks compile if the argument value's type is not pgoff_t type.
> + */
> +#define exactly_pgoff_t(n) exact_type(pgoff_t, n)
Why specialize this? Just use assert_typable(pgoff_t, n) in the other
patches? It's almost the same amount to write. :)
--
Kees Cook
RE: [PATCH 4/5] dt-bindings: crypto: drop minItems equal to maxItems
Hi Krzysztof >-Original Message- >From: Krzysztof Kozlowski [mailto:krzysztof.kozlow...@linaro.org] >Sent: Thursday, August 25, 2022 5:04 PM >To: Rob Herring ; Krzysztof Kozlowski >; Kunihiko Hayashi >; Masami Hiramatsu >; Damien Le Moal >; Michael Turquette >; Stephen Boyd ; Geert >Uytterhoeven ; Sylwester Nawrocki >; Tomasz Figa ; >Chanwoo Choi ; Alim Akhtar >; Vladimir Zapolskiy ; Herbert >Xu ; David S. Miller >; Andrzej Hajda ; Neil >Armstrong ; Robert Foss >; Laurent Pinchart >; Jonas Karlman ; >Jernej Skrabec ; David Airlie ; >Daniel Vetter ; Rob Clark ; Abhinav >Kumar ; Dmitry Baryshkov >; Sean Paul ; Inki Dae >; Seung-Woo Kim ; >Kyungmin Park ; Thierry Reding >; Jonathan Hunter ; >Masahiro Yamada ; Florian Fainelli >; Linus Walleij ; Andre >Przywara ; Kuninori Morimoto >; Yoshihiro Shimoda >; Marek Vasut ; >Krishna Manikandan ; >devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- >ker...@vger.kernel.org; linux-...@vger.kernel.org; linux- >c...@vger.kernel.org; linux-renesas-...@vger.kernel.org; linux-samsung- >s...@vger.kernel.org; linux-cry...@vger.kernel.org; dri- >de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; >freedr...@lists.freedesktop.org; linux-te...@vger.kernel.org >Cc: Krzysztof Kozlowski >Subject: [PATCH 4/5] dt-bindings: crypto: drop minItems equal to maxItems > >minItems, if missing, are implicitly equal to maxItems, so drop redundant >piece to reduce size of code. > >Signed-off-by: Krzysztof Kozlowski >--- Reviewed-by: Alim Akhtar > Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml | 1 - > 1 file changed, 1 deletion(-) > >diff --git a/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml >b/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml >index 676950bb7b37..5b31891c97fe 100644 >--- a/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml >+++ b/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml >@@ -24,7 +24,6 @@ properties: > maxItems: 1 > > clocks: >-minItems: 2 > maxItems: 2 > > clock-names: >-- >2.34.1
RE: [PATCH 5/5] dt-bindings: display: drop minItems equal to maxItems
Hi Krzysztof I got below messages when replied to all " Your mail to 'linux-arm-kernel' with the subject RE: [PATCH 4/5] dt-bindings: crypto: drop minItems equal to maxItems and for [PATCH 3/5] as well Is being held until the list moderator can review it for approval. The reason it is being held: Too many recipients to the message " Are these many "To" addresses are really needed? >-Original Message- >From: Krzysztof Kozlowski [mailto:krzysztof.kozlow...@linaro.org] >Sent: Thursday, August 25, 2022 5:04 PM >To: Rob Herring ; Krzysztof Kozlowski >; Kunihiko Hayashi >; Masami Hiramatsu >; Damien Le Moal >; Michael Turquette >; Stephen Boyd ; Geert >Uytterhoeven ; Sylwester Nawrocki >; Tomasz Figa ; >Chanwoo Choi ; Alim Akhtar >; Vladimir Zapolskiy ; Herbert >Xu ; David S. Miller >; Andrzej Hajda ; Neil >Armstrong ; Robert Foss >; Laurent Pinchart >; Jonas Karlman ; >Jernej Skrabec ; David Airlie ; >Daniel Vetter ; Rob Clark ; Abhinav >Kumar ; Dmitry Baryshkov >; Sean Paul ; Inki Dae >; Seung-Woo Kim ; >Kyungmin Park ; Thierry Reding >; Jonathan Hunter ; >Masahiro Yamada ; Florian Fainelli >; Linus Walleij ; Andre >Przywara ; Kuninori Morimoto >; Yoshihiro Shimoda >; Marek Vasut ; >Krishna Manikandan ; >devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- >ker...@vger.kernel.org; linux-...@vger.kernel.org; linux- >c...@vger.kernel.org; linux-renesas-...@vger.kernel.org; linux-samsung- >s...@vger.kernel.org; linux-cry...@vger.kernel.org; dri- >de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; >freedr...@lists.freedesktop.org; linux-te...@vger.kernel.org >Cc: Krzysztof Kozlowski >Subject: [PATCH 5/5] dt-bindings: display: drop minItems equal to maxItems > >minItems, if missing, are implicitly equal to maxItems, so drop redundant >piece to reduce size of code. > >Signed-off-by: Krzysztof Kozlowski >--- Feel free to add Reviewed-by: Alim Akhtar > Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml | 1 - > .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 -- > Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 2 -- > .../bindings/display/samsung/samsung,exynos5433-decon.yaml | 2 -- > .../bindings/display/samsung/samsung,exynos5433-mic.yaml| 1 - > .../bindings/display/samsung/samsung,exynos7-decon.yaml | 1 - > .../devicetree/bindings/display/samsung/samsung,fimd.yaml | 1 - > .../devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml | 1 - > .../devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml | 2 -- > 9 files changed, 13 deletions(-) > >diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml >b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml >index 2ebaa43eb62e..b19be0804abe 100644 >--- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml >+++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml >@@ -25,7 +25,6 @@ properties: > const: ldb > > reg: >-minItems: 2 > maxItems: 2 > > reg-names: >diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller- >main.yaml b/Documentation/devicetree/bindings/display/msm/dsi- >controller-main.yaml >index 880bfe930830..3b609c19e0bc 100644 >--- a/Documentation/devicetree/bindings/display/msm/dsi-controller- >main.yaml >+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main. >+++ yaml >@@ -66,13 +66,11 @@ properties: > 2 DSI links. > > assigned-clocks: >-minItems: 2 > maxItems: 2 > description: | > Parents of "byte" and "pixel" for the given platform. > > assigned-clock-parents: >-minItems: 2 > maxItems: 2 > description: | > The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block. >diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy- >10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy- >10nm.yaml >index 716f921e3532..d9ad8b659f58 100644 >--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml >+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml >@@ -37,7 +37,6 @@ properties: > > qcom,phy-rescode-offset-top: > $ref: /schemas/types.yaml#/definitions/int8-array >-minItems: 5 > maxItems: 5 > description: > Integer array of offset for pull-up legs rescode for all five lanes. >@@ -49,7 +48,6 @@ properties: > > qcom,phy-rescode-offset-bot: > $ref: /schemas/types.yaml#/definitions/int8-array >-minItems: 5 > maxItems: 5 > description: > Integer array of offset for pull-down legs rescode for all five lanes. >diff --git >a/Documentation/devicetree/bindings/display/samsung/samsung,exynos543 >3-decon.yaml >b/Documentation/devicetree/bindings/display/samsung/samsung,exynos543 >3-decon.yaml >index 921bfe925cd6..6380eeebb073 100644 >--- >a/Documentation/devicetree/bindings/display/samsung/samsung,exynos543 >3-decon.yaml >+++ >b/Documentation/devicetree/bindings/display/samsung/samsu
RE: [PATCH 3/5] dt-bindings: clock: drop minItems equal to maxItems
>-Original Message- >From: Krzysztof Kozlowski [mailto:krzysztof.kozlow...@linaro.org] >Sent: Thursday, August 25, 2022 5:04 PM >To: Rob Herring ; Krzysztof Kozlowski >; Kunihiko Hayashi >; Masami Hiramatsu >; Damien Le Moal >; Michael Turquette >; Stephen Boyd ; Geert >Uytterhoeven ; Sylwester Nawrocki >; Tomasz Figa ; >Chanwoo Choi ; Alim Akhtar >; Vladimir Zapolskiy ; Herbert >Xu ; David S. Miller >; Andrzej Hajda ; Neil >Armstrong ; Robert Foss >; Laurent Pinchart >; Jonas Karlman ; >Jernej Skrabec ; David Airlie ; >Daniel Vetter ; Rob Clark ; Abhinav >Kumar ; Dmitry Baryshkov >; Sean Paul ; Inki Dae >; Seung-Woo Kim ; >Kyungmin Park ; Thierry Reding >; Jonathan Hunter ; >Masahiro Yamada ; Florian Fainelli >; Linus Walleij ; Andre >Przywara ; Kuninori Morimoto >; Yoshihiro Shimoda >; Marek Vasut ; >Krishna Manikandan ; >devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- >ker...@vger.kernel.org; linux-...@vger.kernel.org; linux- >c...@vger.kernel.org; linux-renesas-...@vger.kernel.org; linux-samsung- >s...@vger.kernel.org; linux-cry...@vger.kernel.org; dri- >de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; >freedr...@lists.freedesktop.org; linux-te...@vger.kernel.org >Cc: Krzysztof Kozlowski >Subject: [PATCH 3/5] dt-bindings: clock: drop minItems equal to maxItems > >minItems, if missing, are implicitly equal to maxItems, so drop redundant >piece to reduce size of code. > >Signed-off-by: Krzysztof Kozlowski >--- Reviewed-by: Alim Akhtar > Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 1 - > .../devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml | 2 -- > Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml| 1 - > 3 files changed, 4 deletions(-) > >diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml >b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml >index 0abd6ba82dfd..82836086cac1 100644 >--- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml >+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml >@@ -23,7 +23,6 @@ properties: > clocks: > description: > Common clock binding for CLK_IN, XTI/REF_CLK >-minItems: 2 > maxItems: 2 > > clock-names: >diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2- >clock-sel.yaml b/Documentation/devicetree/bindings/clock/renesas,rcar- >usb2-clock-sel.yaml >index 6eaabb4d82ec..81f09df7147e 100644 >--- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock- >sel.yaml >+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-se >+++ l.yaml >@@ -47,7 +47,6 @@ properties: > maxItems: 1 > > clocks: >-minItems: 4 > maxItems: 4 > > clock-names: >@@ -64,7 +63,6 @@ properties: > maxItems: 1 > > resets: >-minItems: 2 > maxItems: 2 > > reset-names: >diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml >b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml >index 9248bfc16d48..d5296e6053a1 100644 >--- a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml >+++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml >@@ -34,7 +34,6 @@ properties: > const: 1 > > clock-output-names: >-minItems: 3 > maxItems: 3 > description: Names for AP, CP and BT clocks. > >-- >2.34.1
Re: [PATCH 5/5] dt-bindings: display: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:34PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml | 1 - > .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 -- > Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 2 -- > .../bindings/display/samsung/samsung,exynos5433-decon.yaml | 2 -- > .../bindings/display/samsung/samsung,exynos5433-mic.yaml| 1 - > .../bindings/display/samsung/samsung,exynos7-decon.yaml | 1 - > .../devicetree/bindings/display/samsung/samsung,fimd.yaml | 1 - > .../devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml | 1 - > .../devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml | 2 -- > 9 files changed, 13 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml > b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml > index 2ebaa43eb62e..b19be0804abe 100644 > --- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml > @@ -25,7 +25,6 @@ properties: > const: ldb > >reg: > -minItems: 2 > maxItems: 2 > >reg-names: > diff --git > a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > index 880bfe930830..3b609c19e0bc 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > @@ -66,13 +66,11 @@ properties: >2 DSI links. > >assigned-clocks: > -minItems: 2 > maxItems: 2 > description: | >Parents of "byte" and "pixel" for the given platform. > >assigned-clock-parents: > -minItems: 2 > maxItems: 2 > description: | >The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block. > diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > index 716f921e3532..d9ad8b659f58 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > @@ -37,7 +37,6 @@ properties: > >qcom,phy-rescode-offset-top: > $ref: /schemas/types.yaml#/definitions/int8-array > -minItems: 5 > maxItems: 5 > description: >Integer array of offset for pull-up legs rescode for all five lanes. > @@ -49,7 +48,6 @@ properties: > >qcom,phy-rescode-offset-bot: > $ref: /schemas/types.yaml#/definitions/int8-array > -minItems: 5 > maxItems: 5 > description: >Integer array of offset for pull-down legs rescode for all five lanes. > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml > > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml > index 921bfe925cd6..6380eeebb073 100644 > --- > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml > +++ > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml > @@ -24,7 +24,6 @@ properties: >- samsung,exynos5433-decon-tv > >clocks: > -minItems: 11 > maxItems: 11 > >clock-names: > @@ -59,7 +58,6 @@ properties: >- const: te > >iommus: > -minItems: 2 > maxItems: 2 > >iommu-names: > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml > > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml > index 7d405f2febcd..26e5017737a3 100644 > --- > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml > +++ > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml > @@ -24,7 +24,6 @@ properties: > const: samsung,exynos5433-mic > >clocks: > -minItems: 2 > maxItems: 2 > >clock-names: > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > index 969bd8c563a5..c06f306e8d14 100644 > --- > a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > +++ > b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml > @@ -22,7 +22,6 @@ properties: > const: samsung,exynos7-decon > >clocks: > -minItems: 4 > maxItems: 4 > >clock-names: > diff --git > a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml > b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml > index
Re: [PATCH 4/5] dt-bindings: crypto: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:33PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml > b/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml > index 676950bb7b37..5b31891c97fe 100644 > --- a/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml > +++ b/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml > @@ -24,7 +24,6 @@ properties: > maxItems: 1 > >clocks: > -minItems: 2 > maxItems: 2 > >clock-names: -- Regards, Laurent Pinchart
Re: [PATCH 3/5] dt-bindings: clock: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:32PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 1 - > .../devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml | 2 -- > Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml| 1 - > 3 files changed, 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml > b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml > index 0abd6ba82dfd..82836086cac1 100644 > --- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml > +++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml > @@ -23,7 +23,6 @@ properties: >clocks: > description: >Common clock binding for CLK_IN, XTI/REF_CLK > -minItems: 2 > maxItems: 2 > >clock-names: > diff --git > a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml > b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml > index 6eaabb4d82ec..81f09df7147e 100644 > --- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml > +++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml > @@ -47,7 +47,6 @@ properties: > maxItems: 1 > >clocks: > -minItems: 4 > maxItems: 4 > >clock-names: > @@ -64,7 +63,6 @@ properties: > maxItems: 1 > >resets: > -minItems: 2 > maxItems: 2 > >reset-names: > diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml > b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml > index 9248bfc16d48..d5296e6053a1 100644 > --- a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml > +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml > @@ -34,7 +34,6 @@ properties: > const: 1 > >clock-output-names: > -minItems: 3 > maxItems: 3 > description: Names for AP, CP and BT clocks. > -- Regards, Laurent Pinchart
Re: [PATCH 2/5] dt-bindings: ata: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:31PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml | 1 - > .../devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml | 2 -- > Documentation/devicetree/bindings/ata/sata_highbank.yaml| 1 - > 3 files changed, 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > index 235a93ac86b0..3766cc80cb17 100644 > --- a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > +++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml > @@ -30,7 +30,6 @@ properties: >- const: brcm,bcm-nsp-ahci > >reg: > -minItems: 2 > maxItems: 2 > >reg-names: > diff --git > a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > index 21a90975593b..529093666508 100644 > --- a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > +++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml > @@ -22,7 +22,6 @@ properties: > maxItems: 1 > >resets: > -minItems: 2 > maxItems: 2 > description: phandles to the reset lines for both SATA bridges > > @@ -32,7 +31,6 @@ properties: >- const: sata1 > >clocks: > -minItems: 2 > maxItems: 2 > description: phandles to the compulsory peripheral clocks > > diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.yaml > b/Documentation/devicetree/bindings/ata/sata_highbank.yaml > index 49679b58041c..f23f26a8f21c 100644 > --- a/Documentation/devicetree/bindings/ata/sata_highbank.yaml > +++ b/Documentation/devicetree/bindings/ata/sata_highbank.yaml > @@ -52,7 +52,6 @@ properties: > minItems: 1 > maxItems: 8 > items: > - minItems: 2 >maxItems: 2 > >calxeda,tx-atten: -- Regards, Laurent Pinchart
Re: [PATCH v9 1/8] overflow: Move and add few utility macros into overflow
On Wed, Aug 24, 2022 at 05:45:07PM +0900, Gwan-gyeong Mun wrote:
> It moves overflows_type utility macro into overflow header from i915_utils
> header. The overflows_type can be used to catch the truncaion (overflow)
> between different data types. And it adds check_assign() macro which
> performs an assigning source value into destination ptr along with an
> overflow check. overflow_type macro has been improved to handle the signbit
> by gcc's built-in overflow check function. And it adds overflows_ptr()
> helper macro for checking the overflows between a value and a pointer
> type/value.
>
> v3: Add is_type_unsigned() macro (Mauro)
> Modify overflows_type() macro to consider signed data types (Mauro)
> Fix the problem that safe_conversion() macro always returns true
> v4: Fix kernel-doc markups
> v6: Move macro addition location so that it can be used by other than drm
> subsystem (Jani, Mauro, Andi)
> Change is_type_unsigned to is_unsigned_type to have the same name form
> as is_signed_type macro
> v8: Add check_assign() and remove safe_conversion() (Kees)
> Fix overflows_type() to use gcc's built-in overflow function (Andrzej)
> Add overflows_ptr() to allow overflow checking when assigning a value
> into a pointer variable (G.G.)
> v9: Fix overflows_type() to use __builtin_add_overflow() instead of
> __builtin_add_overflow_p() (Andrzej)
> Fix overflows_ptr() to use overflows_type() with the unsigned long type
> (Andrzej)
>
> Signed-off-by: Gwan-gyeong Mun
> Cc: Thomas Hellström
> Cc: Matthew Auld
> Cc: Nirmoy Das
> Cc: Jani Nikula
> Cc: Andi Shyti
> Cc: Andrzej Hajda
> Cc: Mauro Carvalho Chehab
> Cc: Kees Cook
> Reviewed-by: Mauro Carvalho Chehab (v5)
> ---
> drivers/gpu/drm/i915/i915_user_extensions.c | 3 +-
> drivers/gpu/drm/i915/i915_utils.h | 5 +-
> include/linux/overflow.h| 62 +
> 3 files changed, 64 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
> b/drivers/gpu/drm/i915/i915_user_extensions.c
> index c822d0aafd2d..6f6b5b910968 100644
> --- a/drivers/gpu/drm/i915/i915_user_extensions.c
> +++ b/drivers/gpu/drm/i915/i915_user_extensions.c
> @@ -50,8 +50,7 @@ int i915_user_extensions(struct i915_user_extension __user
> *ext,
> if (err)
> return err;
>
> - if (get_user(next, &ext->next_extension) ||
> - overflows_type(next, ext))
> + if (get_user(next, &ext->next_extension) || overflows_ptr(next))
> return -EFAULT;
>
> ext = u64_to_user_ptr(next);
I continue to dislike the layers of macros and specialization here.
This is just a fancy version of check_assign():
if (get_user(next, &ext->next_extension) || check_assign(next, &ext))
return -EFAULT;
However, the __builtin_*_overflow() family only wants to work on
integral types, so this needs to be slightly expanded:
uintptr_t kptr;
...
if (get_user(next, &ext->next_extension) || check_assign(next, &kptr))
return -EFAULT;
ext = (void * __user)kptr;
But, it does seem like the actual problem here is that u64_to_user_ptr()
is not performing the checking? It's used heavily in the drm code.
Is a check_assign_user_ptr() needed?
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index c10d68cdc3ca..eb0ded23fa9c 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_X86
> #include
> @@ -111,10 +112,6 @@ bool i915_error_injected(void);
> #define range_overflows_end_t(type, start, size, max) \
> range_overflows_end((type)(start), (type)(size), (type)(max))
>
> -/* Note we don't consider signbits :| */
> -#define overflows_type(x, T) \
> - (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
> -
> #define ptr_mask_bits(ptr, n) ({ \
> unsigned long __v = (unsigned long)(ptr); \
> (typeof(ptr))(__v & -BIT(n)); \
> diff --git a/include/linux/overflow.h b/include/linux/overflow.h
> index f1221d11f8e5..6af9df1d67a1 100644
> --- a/include/linux/overflow.h
> +++ b/include/linux/overflow.h
> @@ -52,6 +52,68 @@ static inline bool __must_check __must_check_overflow(bool
> overflow)
> return unlikely(overflow);
> }
>
> +/**
> + * overflows_type - helper for checking the overflows between data types or
> + * values
> + *
> + * @x: Source value or data type for overflow check
> + * @T: Destination value or data type for overflow check
> + *
> + * It compares the values or data type between the first and second argument
> to
> + * check whether overflow can occur when assigning the first argument to the
> + * variable of th
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
On 8/25/2022 00:15, Joonas Lahtinen wrote:
Quoting John Harrison (2022-08-24 21:45:09)
On 8/24/2022 02:01, Joonas Lahtinen wrote:
NACK on this one. Let's get this reverted or fixed to eliminate
new module parameters.
What prevents us just from using the maximum sizes? Or alternatively
we could check the already existing drm.debug variable or anything else
but addding 3 new module parameters.
We don't want to waste 24MB of memory for all users when 99.999% of them
don't care about GuC logs.
It is not exactly wasting memory if it is what is needed to capture
the error logs to properly debug a system. And it's definitely not much
on any modern system where you will have a GPU. You can always leave
the Kconfig options in place for the cases where it matters.
On the other hand, if 99.999% don't need this, then it could just stay
as a kernel config time option as well?
No. The point is that we need to able to ask customers to increase the
log size, repro an issue and send us the results. All on a pre-installed
system where they do not have the option to build a custom kernel.
Either we always allocate the maximum and waste the memory for all end
users or we have a runtime configuration option. Compile time is not
acceptable for some important customers/situations.
We also don't want to tie the GuC logging buffer size to the DRM
debugging output. Enabling kernel debug output can change timings and
prevent the issue that one is trying to capture in the GuC log. And it
seems unlikely we could add an entire new top level DRM debug flag just
for an internal i915 only log buffer size. Plus drm.debug is explicitly
stated as being dynamically changeable via sysfs at any time. The GuC
log buffer size cannot be changed without reloading the i915 driver. Or
at least, not without reloading the GuC, but we definitely don't want to
create a UAPI for arbitrarily reloading the GuC.
We can make these parameters 'unsafe' so that they taint the kernel if
used. But this is exactly what module parameters are for - configuration
that we don't want to hardcode as CONFIG options but which must be set
at module load time.
It's better to have sane defaults. And if somebody wants something
strange, they can have a Kconfig behind EXPERT option. But even then
there should really be need for it.
Define sane.
Sane for most users is to not allocate 24MB of memory for an internal
debug only buffer they will never use. And which completely swamps any
error capture log with the ASCII encoding of said buffer.
But as above, we need a way to (very occasionally) get larger GuC logs
from customers without rebuilding the kernel.
John.
So for now, let's get the module parameters reverted and go with
reasonable default buffer sizes when GuC is enabled. The compile time
options can be left in place.
Thank you in advance.
Regards, Joonas
John.
For future reference, please do Cc maintainers when adding new uAPI
like module parameters.
Regards, Joonas
Quoting john.c.harri...@intel.com (2022-07-28 05:20:27)
From: John Harrison
The GuC log buffer sizes had to be configured statically at compile
time. This can be quite troublesome when needing to get larger logs
out of a released driver. So re-organise the code to allow a boot time
module parameter override.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 53 ++
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 14 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 176 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 42 +++--
drivers/gpu/drm/i915/i915_params.c| 12 ++
drivers/gpu/drm/i915/i915_params.h| 3 +
6 files changed, 226 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index ab4aacc516aa4..01f2705cb94a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -224,53 +224,22 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
- u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
- u32 flags;
-
- #if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)
- #define LOG_UNIT SZ_1M
- #define LOG_FLAG GUC_LOG_LOG_ALLOC_UNITS
- #else
- #define LOG_UNIT SZ_4K
- #define LOG_FLAG 0
- #endif
-
- #if (((CAPTURE_BUFFER_SIZE) % SZ_1M) == 0)
- #define CAPTURE_UNIT SZ_1M
- #define CAPTURE_FLAG GUC_LOG_CAPTURE_ALLOC_UNITS
- #else
- #define CAPTURE_UNIT SZ_4K
- #define CAPTURE_FLAG 0
- #endif
-
- BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, LOG_UNIT));
- BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, LOG_UNIT));
- BUILD_BUG_ON(!CAPTURE_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(CAPTURE_BUF
Re: [PATCH 1/5] dt-bindings: socionext,uniphier-system-cache: drop minItems equal to maxItems
Hi Krzysztof, Thank you for the patch. On Thu, Aug 25, 2022 at 02:33:30PM +0300, Krzysztof Kozlowski wrote: > minItems, if missing, are implicitly equal to maxItems, so drop > redundant piece to reduce size of code. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart > --- > .../bindings/arm/socionext/socionext,uniphier-system-cache.yaml | 1 - > 1 file changed, 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml > > b/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml > index 7ca5375f278f..6096c082d56d 100644 > --- > a/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml > +++ > b/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml > @@ -22,7 +22,6 @@ properties: > description: | >should contain 3 regions: control register, revision register, >operation register, in this order. > -minItems: 3 > maxItems: 3 > >interrupts: -- Regards, Laurent Pinchart
[PATCH v2] drm: omapdrm: Improve check for contiguous buffers
While a scatter-gather table having only 1 entry does imply it is
contiguous, it is a logic error to assume the inverse. Tables can have
more than 1 entry and still be contiguous. Use a proper check here.
Signed-off-by: Andrew Davis
---
Changes from v1:
- Sent correct version of patch :)
drivers/gpu/drm/omapdrm/omap_gem.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index cf571796fd26e..c10f3d2dd61ce 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -48,7 +48,7 @@ struct omap_gem_object {
* OMAP_BO_MEM_DMA_API flag set)
*
* - buffers imported from dmabuf (with the OMAP_BO_MEM_DMABUF flag set)
-* if they are physically contiguous (when sgt->orig_nents == 1)
+* if they are physically contiguous
*
* - buffers mapped through the TILER when pin_cnt is not zero, in which
* case the DMA address points to the TILER aperture
@@ -148,12 +148,18 @@ u64 omap_gem_mmap_offset(struct drm_gem_object *obj)
return drm_vma_node_offset_addr(&obj->vma_node);
}
+static bool omap_gem_sgt_is_contiguous(struct sg_table *sgt, size_t size)
+{
+ return !(drm_prime_get_contiguous_size(sgt) < size);
+}
+
static bool omap_gem_is_contiguous(struct omap_gem_object *omap_obj)
{
if (omap_obj->flags & OMAP_BO_MEM_DMA_API)
return true;
- if ((omap_obj->flags & OMAP_BO_MEM_DMABUF) && omap_obj->sgt->nents == 1)
+ if ((omap_obj->flags & OMAP_BO_MEM_DMABUF) &&
+ omap_gem_sgt_is_contiguous(omap_obj->sgt, omap_obj->base.size))
return true;
return false;
@@ -1398,7 +1404,7 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct
drm_device *dev, size_t size,
union omap_gem_size gsize;
/* Without a DMM only physically contiguous buffers can be supported. */
- if (sgt->orig_nents != 1 && !priv->has_dmm)
+ if (!omap_gem_sgt_is_contiguous(sgt, size) && !priv->has_dmm)
return ERR_PTR(-EINVAL);
gsize.bytes = PAGE_ALIGN(size);
@@ -1412,7 +1418,7 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct
drm_device *dev, size_t size,
omap_obj->sgt = sgt;
- if (sgt->orig_nents == 1) {
+ if (omap_gem_sgt_is_contiguous(sgt, size)) {
omap_obj->dma_addr = sg_dma_address(sgt->sgl);
} else {
/* Create pages list from sgt */
--
2.36.1
Re: [PATCH v1 00/35] drm: Analog TV Improvements
On Mon, Aug 22, 2022 at 03:21:29PM +0200, Noralf Trønnes wrote: > > > Den 22.08.2022 09.48, skrev Maxime Ripard: > > Hi, > > > > On Sun, Aug 21, 2022 at 06:33:12PM +0200, Noralf Trønnes wrote: > >> Den 29.07.2022 18.34, skrev Maxime Ripard: > >>> Hi, > >>> > >>> Here's a series aiming at improving the command line named modes support, > >>> and more importantly how we deal with all the analog TV variants. > >>> > >>> The named modes support were initially introduced to allow to specify the > >>> analog TV mode to be used. > >>> > >>> However, this was causing multiple issues: > >>> > >>> * The mode name parsed on the command line was passed directly to the > >>> driver, which had to figure out which mode it was suppose to match; > >>> > >>> * Figuring that out wasn't really easy, since the video= argument or > >>> what > >>> the userspace might not even have a name in the first place, but > >>> instead could have passed a mode with the same timings; > >>> > >>> * The fallback to matching on the timings was mostly working as long as > >>> we were supporting one 525 lines (most likely NSTC) and one 625 lines > >>> (PAL), but couldn't differentiate between two modes with the same > >>> timings (NTSC vs PAL-M vs NSTC-J for example); > >>> > >>> * There was also some overlap with the tv mode property registered by > >>> drm_mode_create_tv_properties(), but named modes weren't interacting > >>> with that property at all. > >>> > >>> * Even though that property was generic, its possible values were > >>> specific to each drivers, which made some generic support difficult. > >>> > >>> Thus, I chose to tackle in multiple steps: > >>> > >>> * A new TV norm property was introduced, with generic values, each > >>> driver > >>> reporting through a bitmask what standard it supports to the > >>> userspace; > >>> > >>> * This option was added to the command line parsing code to be able to > >>> specify it on the kernel command line, and new atomic_check and reset > >>> helpers were created to integrate properly into atomic KMS; > >>> > >>> * The named mode parsing code is now creating a proper display mode for > >>> the given named mode, and the TV standard will thus be part of the > >>> connector state; > >>> > >>> * Two drivers were converted and tested for now (vc4 and sun4i), with > >>> some backward compatibility code to translate the old TV mode to the > >>> new TV mode; > >>> > >>> Unit tests were created along the way. Nouveau, ch7006 and gud are > >>> currently broken for now since I expect that work to be reworked fairly > >>> significantly. I'm also not entirely sure about how to migrate GUD to the > >>> new property. > >>> > >>> Let me know what you think, > >>> Maxime > >>> > >> > >> I don't know if it's related to this patchset or not, but I do get this: > >> > >> pi@pi4t:~ $ sudo dmesg -C && sudo modprobe -r vc4 && sudo modprobe vc4 > >> && dmesg > >> [ 430.066211] Console: switching to colour dummy device 80x30 > >> [ 431.294788] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) > >> [ 431.295115] vc4-drm gpu: bound fec13000.vec (ops vc4_vec_ops [vc4]) > >> [ 431.295467] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4]) > >> [ 431.295804] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops > >> [vc4]) > >> [ 431.298895] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > >> [ 441.444250] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done > >> timed out > >> [ 441.446529] Console: switching to colour frame buffer device 90x30 > >> [ 451.684321] vc4-drm gpu: [drm] *ERROR* flip_done timed out > >> [ 451.684347] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] commit wait > >> timed out > >> [ 461.924255] vc4-drm gpu: [drm] *ERROR* flip_done timed out > >> [ 461.924281] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:45:Composite-1] > >> commit wait timed out > >> [ 472.164006] vc4-drm gpu: [drm] *ERROR* flip_done timed out > >> [ 472.164031] vc4-drm gpu: [drm] *ERROR* [PLANE:61:plane-1] commit wait > >> timed out > >> [ 482.403877] vc4-drm gpu: [drm] *ERROR* flip_done timed out > >> [ 482.403903] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit > >> [ 492.643799] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done > >> timed out > >> [ 492.647073] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device > > > > Module unloading/reloading has been janky for a while. > > > > I've fixed it up recently but it doesn't surprise me that there's still > > some situation that won't work. Is it on a Pi3? > > > > It's a Pi4. With which kernel? I just tested it on last next and it seems to work ok there. I've fixed it recently though, so it's only in drm-misc-next and linux-next at the moment. Maxime signature.asc Description: PGP signature
Re: [PATCH v1 00/35] drm: Analog TV Improvements
Hi Maxime,
W dniu 25.08.2022 o 17:55, Maxime Ripard pisze:
> Hi Mateusz,
>
> On Mon, Aug 22, 2022 at 10:57:26AM +0200, Mateusz Kwiatkowski wrote:
>> Hi Maxime,
>>
>> I tried testing and reviewing your changes properly over the last weekend,
>> but
>> ultimately ran into this ("flip_done timed out" etc.) issue and was unable to
>> mitigate it, at least so far. This seems to pop up every time I try to change
>> modes in any way (either change the TV norm, or just try doing
>> "xrandr --output Composite-1 --off" followed by bringing it back on; it also
>> means that the Pi goes unusable when the DE's screen saving routine kicks
>> in).
>>
>> I'm using a Pi 4, and it works with the rpi-5.13.y branch
>> https://github.com/raspberrypi/linux, but seemingly nothing newer.
>> I specifically tried rpi-5.14.y, rpi-5.15.y and rpi-5.19.y - rpi-5.15.y,
>> which is the current main branch in Raspberry Pi OS, seems to be broken since
>> forever; at least since my patches (originally written for 5.10) landed
>> there.
>>
>> I'll try identifying the issue further, possibly later today, and maybe check
>> the rpi-6.0.y branch as well.
>
> I've tried it this, and I can't reproduce it here. But I'm curious, how
> did you apply this series? rpi-5.13.y is probably full of conflicts
> everywhere?
I applied your patches onto rpi-5.15.y. There were conflicts, but they seemed
relatively minor. I'm not sure if I did a good job at resolving them - I ran
into various problems trying to test your changes, but I chose not to criticize
you before making sure that it's really due to your changes, or without some
remarks more constructive than "doesn't work" ;-)
I can push my rebase onto some Github fork if you're interested.
I was able to work around some of those problems, and also saw that some
of them were already mentioned by other reviewers (such as the generic modes
not matching due to the aspect ratio setting).
Ultimately I got stuck on this bug, so I put testing this series on hold
in favor of debugging the bigger issue. So far unfortunately no luck with it.
I did not try rebasing your changes onto 5.13 or older.
> Maxime
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH 1/2] drm: Add missing DP DSC extended capability definitions.
Reviewed-by: Vinod Govindapillai On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote: > Adding DP DSC register definitions, we might need for further > DSC implementation, supporting MST and DP branch pass-through mode. > > v2: - Fixed checkpatch comment warning > v3: - Removed function which is not yet used(Jani Nikula) > > Signed-off-by: Stanislav Lisovskiy > --- > include/drm/display/drm_dp.h | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index 9e3aff7e68bb..0d05e3172f96 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -239,6 +239,9 @@ > > #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ > # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP (1 << 2) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) > > #define DP_DSC_REV 0x061 > # define DP_DSC_MAJOR_MASK (0xf << 0) > @@ -277,12 +280,15 @@ > > #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 > # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) > > #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ > > #define DP_DSC_MAX_BITS_PER_PIXEL_HI 0x068 /* eDP 1.4 */ > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 > +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 > +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 > > #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 > # define DP_DSC_RGB (1 << 0) > @@ -344,11 +350,13 @@ > # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) > > #define DP_DSC_BITS_PER_PIXEL_INC 0x06F > +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f > +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 > # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 > # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 > # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 > # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 > -# define DP_DSC_BITS_PER_PIXEL_1 0x4 > +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > # define DP_PSR_IS_SUPPORTED 1
Re: [PATCH] drm/amd: fix potential memory leak
On Tue, Aug 23, 2022 at 3:29 AM Bernard Zhao wrote: > > This patch fix potential memory leak (clk_src) when function run > into last return NULL. > > Signed-off-by: Bernard Zhao > --- > drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > index 85f32206a766..76f263846c6b 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > @@ -1715,6 +1715,7 @@ static struct clock_source *dcn30_clock_source_create( > } > > BREAK_TO_DEBUGGER(); > + free(clk_src); This should be kfree(). Fixed up locally. Alex > return NULL; > } > > -- > 2.33.1 >
Re: [PATCH 2/2] drm/i915: Add DSC support to MST path
On Thu, 2022-08-25 at 18:17 +0300, Lisovskiy, Stanislav wrote:
> On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> > Hi Stan,
> >
> > Some comments inline..
> >
> > On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > > Whenever we are not able to get enough timeslots
> > > for required PBN, let's try to allocate those
> > > using DSC, just same way as we do for SST.
> > >
> > > v2: Removed intel_dp_mst_dsc_compute_config and refactored
> > > intel_dp_dsc_compute_config to support timeslots as a
> > > parameter(Ville Syrjälä)
> > >
> > > v3: - Rebased
> > > - Added a debug to see that we at least try reserving
> > > VCPI slots using DSC, because currently its not visible
> > > from the logs, thus making debugging more tricky.
> > > - Moved timeslots to numerator, where it should be.
> > >
> > > v4: - Call drm_dp_mst_atomic_check already during link
> > > config computation, because we need to know already
> > > by this moment if uncompressed amount of VCPI slots
> > > needed can fit, otherwise we need to use DSC.
> > > (thanks to Vinod Govindapillai for pointing this out)
> > >
> > > v5: - Put pipe_config->bigjoiner_pipes back to original
> > > condition in intel_dp_dsc_compute_config
> > > (don't remember when I lost it)
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 73 -
> > > drivers/gpu/drm/i915/display/intel_dp.h | 17 +++
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 157
> > > 3 files changed, 205 insertions(+), 42 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 32292c0be2bd..519b436fc530 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -116,7 +116,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > > }
> > >
> > > static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> > > -static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> > > dsc_max_bpc);
> > >
> > > /* Is link rate UHBR and thus 128b/132b? */
> > > bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
> > > @@ -687,11 +686,12 @@ small_joiner_ram_size_bits(struct drm_i915_private
> > > *i915)
> > > return 6144 * 8;
> > > }
> > >
> > > -static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > > - u32 link_clock, u32 lane_count,
> > > - u32 mode_clock, u32 mode_hdisplay,
> > > - bool bigjoiner,
> > > - u32 pipe_bpp)
> > > +u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > > + u32 link_clock, u32 lane_count,
> > > + u32 mode_clock, u32 mode_hdisplay,
> > > + bool bigjoiner,
> > > + u32 pipe_bpp,
> > > + u32 timeslots)
> > > {
> > > u32 bits_per_pixel, max_bpp_small_joiner_ram;
> > > int i;
> > > @@ -702,8 +702,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > > drm_i915_private *i915,
> > > * for SST -> TimeSlotsPerMTP is 1,
> > > * for MST -> TimeSlotsPerMTP has to be calculated
> > > */
> > > - bits_per_pixel = (link_clock * lane_count * 8) /
> > > + bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> > > intel_dp_mode_to_fec_clock(mode_clock);
> > > + drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
> > >
> > > /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz.
> > > width */
> > > max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
> > > @@ -752,9 +753,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > > drm_i915_private *i915,
> > > return bits_per_pixel << 4;
> > > }
> > >
> > > -static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > > - int mode_clock, int mode_hdisplay,
> > > - bool bigjoiner)
> > > +u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > > + int mode_clock, int mode_hdisplay,
> > > + bool bigjoiner)
> > > {
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > u8 min_slice_count, i;
> > > @@ -961,8 +962,8 @@ intel_dp_mode_valid_downstream(struct intel_connector
> > > *connector,
> > > return MODE_OK;
> > > }
> > >
> > > -static bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > > - int hdisplay, int clock)
> > > +bool intel_dp_need_bigjoiner(struct intel_
Re: [PATCH] drm/amd: remove possible condition with no effect (if == else)
Applied. Thanks! On Tue, Aug 23, 2022 at 3:30 AM Bernard Zhao wrote: > > This patch fix cocci warning: > drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c:1816:6-8: > WARNING: possible condition with no effect (if == else). > > Signed-off-by: Bernard Zhao > --- > drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > index 85f32206a766..dccc9794e6a2 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > @@ -1813,8 +1813,6 @@ static bool dcn314_resource_construct( > > if (dc->ctx->dce_environment == DCE_ENV_PRODUCTION_DRV) > dc->debug = debug_defaults_drv; > - else if (dc->ctx->dce_environment == DCE_ENV_FPGA_MAXIMUS) > - dc->debug = debug_defaults_diags; > else > dc->debug = debug_defaults_diags; > // Init the vm_helper > -- > 2.33.1 >
Re: [PATCH] drm/amd: remove possible condition with no effect (if == else)
Applied. Thanks!
Alex
On Tue, Aug 23, 2022 at 3:01 AM Bernard Zhao wrote:
>
> This patch fix cocci warning:
> drivers/gpu/drm/amd/display/dc/core/dc.c:3335:2-4: WARNING:
> possible condition with no effect (if == else).
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index aeecca68dea7..2d4c44083d79 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -3332,13 +3332,8 @@ static void commit_planes_for_stream(struct dc *dc,
> /* Since phantom pipe programming is moved to
> post_unlock_program_front_end,
> * move the SubVP lock to after the phantom pipes have been
> setup
> */
> - if (should_lock_all_pipes &&
> dc->hwss.interdependent_update_lock) {
> - if (dc->hwss.subvp_pipe_control_lock)
> - dc->hwss.subvp_pipe_control_lock(dc, context,
> false, should_lock_all_pipes, NULL, subvp_prev_use);
> - } else {
> - if (dc->hwss.subvp_pipe_control_lock)
> - dc->hwss.subvp_pipe_control_lock(dc, context,
> false, should_lock_all_pipes, NULL, subvp_prev_use);
> - }
> + if (dc->hwss.subvp_pipe_control_lock)
> + dc->hwss.subvp_pipe_control_lock(dc, context, false,
> should_lock_all_pipes, NULL, subvp_prev_use);
> return;
> }
>
> --
> 2.33.1
>
Re: [PATCH] drm/amd: fix potential memory leak
Applied. Thanks! Alex On Tue, Aug 23, 2022 at 2:36 AM Bernard Zhao wrote: > > This patch fix potential memory leak (clk_src) when function run > into last return NULL. > Signed-off-by: Bernard Zhao > --- > drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > index 85f32206a766..c7bb76a2a8c2 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > @@ -1643,6 +1643,7 @@ static struct clock_source *dcn31_clock_source_create( > } > > BREAK_TO_DEBUGGER(); > + kfree(clk_src); > return NULL; > } > > -- > 2.33.1 >
Re: [PATCH] drm/amd: fix potential memory leak
Applied. Thanks! On Tue, Aug 23, 2022 at 3:29 AM Bernard Zhao wrote: > > This patch fix potential memory leak (clk_src) when function run > into last return NULL. > > Signed-off-by: Bernard Zhao > --- > drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > index 85f32206a766..76f263846c6b 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c > @@ -1715,6 +1715,7 @@ static struct clock_source *dcn30_clock_source_create( > } > > BREAK_TO_DEBUGGER(); > + free(clk_src); > return NULL; > } > > -- > 2.33.1 >
Re: [PATCH] drm/amdgpu: mmVM_L2_CNTL3 register not initialized correctly
Applied. Thanks!
Alex
On Tue, Aug 23, 2022 at 3:15 AM wrote:
>
> From: Qu Huang
>
> The mmVM_L2_CNTL3 register is not assigned an initial value
>
> Signed-off-by: Qu Huang
> ---
> drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
> b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
> index 1da2ec692057e..b8a987a032a8e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
> @@ -176,6 +176,7 @@ static void mmhub_v1_0_init_cache_regs(struct
> amdgpu_device *adev)
> tmp = REG_SET_FIELD(tmp, VM_L2_CNTL2, INVALIDATE_L2_CACHE, 1);
> WREG32_SOC15(MMHUB, 0, mmVM_L2_CNTL2, tmp);
>
> + tmp = mmVM_L2_CNTL3_DEFAULT;
> if (adev->gmc.translate_further) {
> tmp = REG_SET_FIELD(tmp, VM_L2_CNTL3, BANK_SELECT, 12);
> tmp = REG_SET_FIELD(tmp, VM_L2_CNTL3,
> --
> 2.31.1
>
Re: [PATCH v1 00/35] drm: Analog TV Improvements
Hi Mateusz,
On Mon, Aug 22, 2022 at 10:57:26AM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime,
>
> I tried testing and reviewing your changes properly over the last weekend, but
> ultimately ran into this ("flip_done timed out" etc.) issue and was unable to
> mitigate it, at least so far. This seems to pop up every time I try to change
> modes in any way (either change the TV norm, or just try doing
> "xrandr --output Composite-1 --off" followed by bringing it back on; it also
> means that the Pi goes unusable when the DE's screen saving routine kicks in).
>
> I'm using a Pi 4, and it works with the rpi-5.13.y branch
> https://github.com/raspberrypi/linux, but seemingly nothing newer.
> I specifically tried rpi-5.14.y, rpi-5.15.y and rpi-5.19.y - rpi-5.15.y,
> which is the current main branch in Raspberry Pi OS, seems to be broken since
> forever; at least since my patches (originally written for 5.10) landed there.
>
> I'll try identifying the issue further, possibly later today, and maybe check
> the rpi-6.0.y branch as well.
I've tried it this, and I can't reproduce it here. But I'm curious, how
did you apply this series? rpi-5.13.y is probably full of conflicts
everywhere?
Maxime
signature.asc
Description: PGP signature
Re: [PATCH] drm: amd: amdgpu: ACPI: Add comment about ACPI_FADT_LOW_POWER_S0
Applied. Thanks!
Alex
On Thu, Aug 25, 2022 at 3:58 AM Limonciello, Mario
wrote:
>
> On 8/24/2022 12:32, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > According to the ACPI specification [1], the ACPI_FADT_LOW_POWER_S0
> > flag merely means that it is better to use low-power S0 idle on the
> > given platform than S3 (provided that the latter is supported) and it
> > doesn't preclude using either of them (which of them will be used
> > depends on the choices made by user space).
> >
> > However, on some systems that flag is used to indicate whether or not
> > to enable special firmware mechanics allowing the system to save more
> > energy when suspended to idle. If that flag is unset, doing so is
> > generally risky.
> >
> > Accordingly, add a comment to explain the ACPI_FADT_LOW_POWER_S0 check
> > in amdgpu_acpi_is_s0ix_active(), the purpose of which is otherwise
> > somewhat unclear.
> >
> > Link:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuefi.org%2Fspecs%2FACPI%2F6.4%2F05_ACPI_Software_Programming_Model%2FACPI_Software_Programming_Model.html%23fixed-acpi-description-table-fadt&data=05%7C01%7Cmario.limonciello%40amd.com%7Cf43320dda5114deeb16908da85f69d3b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637969591512297179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xp8pNzsXCkLcIJOJFY77yaLkMrvz5he3S%2Bi%2FwaxTwwg%3D&reserved=0
> > # [1]
> > Signed-off-by: Rafael J. Wysocki
>
> Reviewed-by: Mario Limonciello
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |6 ++
> > 1 file changed, 6 insertions(+)
> >
> > Index: linux-pm/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > ===
> > --- linux-pm.orig/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > +++ linux-pm/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > @@ -1066,6 +1066,12 @@ bool amdgpu_acpi_is_s0ix_active(struct a
> > (pm_suspend_target_state != PM_SUSPEND_TO_IDLE))
> > return false;
> >
> > + /*
> > + * If ACPI_FADT_LOW_POWER_S0 is not set in the FADT, it is generally
> > + * risky to do any special firmware-related preparations for entering
> > + * S0ix even though the system is suspending to idle, so return false
> > + * in that case.
> > + */
> > if (!(acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)) {
> > dev_warn_once(adev->dev,
> > "Power consumption will be higher as BIOS has
> > not been configured for suspend-to-idle.\n"
> >
> >
> >
>
Re: [PATCH] drm/radeon: use time_after(a,b) to replace "a>b"
Applied. Thanks!
Alex
On Wed, Aug 24, 2022 at 10:40 PM Yu Zhe wrote:
>
> time_after() deals with timer wrapping correctly.
>
> Signed-off-by: Yu Zhe
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index e765abcb3b01..04c693ca419a 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -1899,7 +1899,7 @@ static void radeon_dynpm_idle_work_handler(struct
> work_struct *work)
> * to false since we want to wait for vbl to avoid flicker.
> */
> if (rdev->pm.dynpm_planned_action != DYNPM_ACTION_NONE &&
> - jiffies > rdev->pm.dynpm_action_timeout) {
> + time_after(jiffies, rdev->pm.dynpm_action_timeout)) {
> radeon_pm_get_dynpm_state(rdev);
> radeon_pm_set_clocks(rdev);
> }
> --
> 2.11.0
>
Re: [PATCH v2 1/3] PCI: Move PCI_VENDOR_ID_MICROSOFT/PCI_DEVICE_ID_HYPERV_VIDEO definitions to pci_ids.h
On Thu, Aug 25, 2022 at 11:00:22AM +0200, Vitaly Kuznetsov wrote:
> There are already three places in kernel which define PCI_VENDOR_ID_MICROSOFT
> and two for PCI_DEVICE_ID_HYPERV_VIDEO and there's a need to use these
> from core Vmbus code. Move the defines where they belong.
>
> No functional change.
>
> Signed-off-by: Vitaly Kuznetsov
Acked-by: Bjorn Helgaas# pci_ids.h
> ---
> drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 3 ---
> drivers/net/ethernet/microsoft/mana/gdma_main.c | 4
> drivers/video/fbdev/hyperv_fb.c | 4
> include/linux/pci_ids.h | 3 +++
> 4 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> index 6d11e7938c83..40888e36f91a 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> @@ -23,9 +23,6 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -#define PCI_VENDOR_ID_MICROSOFT 0x1414
> -#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> -
> DEFINE_DRM_GEM_FOPS(hv_fops);
>
> static struct drm_driver hyperv_driver = {
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> index 5f9240182351..00d8198072ae 100644
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -1465,10 +1465,6 @@ static void mana_gd_shutdown(struct pci_dev *pdev)
> pci_disable_device(pdev);
> }
>
> -#ifndef PCI_VENDOR_ID_MICROSOFT
> -#define PCI_VENDOR_ID_MICROSOFT 0x1414
> -#endif
> -
> static const struct pci_device_id mana_id_table[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_PF_DEVICE_ID) },
> { PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_VF_DEVICE_ID) },
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index 886c564787f1..b58b445bb529 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -74,10 +74,6 @@
> #define SYNTHVID_DEPTH_WIN8 32
> #define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
>
> -#define PCI_VENDOR_ID_MICROSOFT 0x1414
> -#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> -
> -
> enum pipe_msg_type {
> PIPE_MSG_INVALID,
> PIPE_MSG_DATA,
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 6feade66efdb..15b49e655ce3 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2079,6 +2079,9 @@
> #define PCI_DEVICE_ID_ICE_1712 0x1712
> #define PCI_DEVICE_ID_VT1724 0x1724
>
> +#define PCI_VENDOR_ID_MICROSOFT 0x1414
> +#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> +
> #define PCI_VENDOR_ID_OXSEMI 0x1415
> #define PCI_DEVICE_ID_OXSEMI_12PCI8400x8403
> #define PCI_DEVICE_ID_OXSEMI_PCIe840 0xC000
> --
> 2.37.1
>
Re: [Intel-gfx] [PATCH v1] drm/i915: fix null pointer dereference
On Thu, Aug 25, 2022 at 10:37:14AM +0300, Jani Nikula wrote:
> On Tue, 23 Aug 2022, Łukasz Bartosik wrote:
> >>
> >> Hi all,
> >>
> >> Apologies in advance if you see this twice. I did not see the original
> >> make it to either lore.kernel.org or the freedesktop.org archives so I
> >> figured it might have been sent into the void.
> >>
> >> On Tue, Feb 01, 2022 at 04:33:54PM +0100, Lukasz Bartosik wrote:
> >> > From: Łukasz Bartosik
> >> >
> >> > Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
> >> > The root cause is null pointer defeference of bi_next
> >> > in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.
> >> >
> >> > BUG: kernel NULL pointer dereference, address: 002e
> >> > PGD 0 P4D 0
> >> > Oops: 0002 [#1] PREEMPT SMP NOPTI
> >> > CPU: 0 PID: 1 Comm: swapper/0 Tainted: G U5.17.0-rc1
> >> > Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3
> >> > 05/14/2021
> >> > RIP: 0010:tgl_get_bw_info+0x2de/0x510
> >> > ...
> >> > [2.554467] Call Trace:
> >> > [2.554467]
> >> > [2.554467] intel_bw_init_hw+0x14a/0x434
> >> > [2.554467] ? _printk+0x59/0x73
> >> > [2.554467] ? _dev_err+0x77/0x91
> >> > [2.554467] i915_driver_hw_probe+0x329/0x33e
> >> > [2.554467] i915_driver_probe+0x4c8/0x638
> >> > [2.554467] i915_pci_probe+0xf8/0x14e
> >> > [2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c
> >> > [2.554467] pci_device_probe+0xaa/0x142
> >> > [2.554467] really_probe+0x13f/0x2f4
> >> > [2.554467] __driver_probe_device+0x9e/0xd3
> >> > [2.554467] driver_probe_device+0x24/0x7c
> >> > [2.554467] __driver_attach+0xba/0xcf
> >> > [2.554467] ? driver_attach+0x1f/0x1f
> >> > [2.554467] bus_for_each_dev+0x8c/0xc0
> >> > [2.554467] bus_add_driver+0x11b/0x1f7
> >> > [2.554467] driver_register+0x60/0xea
> >> > [2.554467] ? mipi_dsi_bus_init+0x16/0x16
> >> > [2.554467] i915_init+0x2c/0xb9
> >> > [2.554467] ? mipi_dsi_bus_init+0x16/0x16
> >> > [2.554467] do_one_initcall+0x12e/0x2b3
> >> > [2.554467] do_initcall_level+0xd6/0xf3
> >> > [2.554467] do_initcalls+0x4e/0x79
> >> > [2.554467] kernel_init_freeable+0xed/0x14d
> >> > [2.554467] ? rest_init+0xc1/0xc1
> >> > [2.554467] kernel_init+0x1a/0x120
> >> > [2.554467] ret_from_fork+0x1f/0x30
> >> > [2.554467]
> >> > ...
> >> > Kernel panic - not syncing: Fatal exception
> >> >
> >> > Fixes: c64a9a7c05be ("drm/i915: Update memory bandwidth formulae")
> >> > Signed-off-by: Łukasz Bartosik
> >> > ---
> >> > drivers/gpu/drm/i915/display/intel_bw.c | 16 +---
> >> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> >> > b/drivers/gpu/drm/i915/display/intel_bw.c
> >> > index 2da4aacc956b..bd0ed68b7faa 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> >> > @@ -404,15 +404,17 @@ static int tgl_get_bw_info(struct drm_i915_private
> >> > *dev_priv, const struct intel
> >> > int clpchgroup;
> >> > int j;
> >> >
> >> > - if (i < num_groups - 1)
> >> > - bi_next = &dev_priv->max_bw[i + 1];
> >> > -
> >> > clpchgroup = (sa->deburst * qi.deinterleave /
> >> > num_channels) << i;
> >> >
> >> > - if (i < num_groups - 1 && clpchgroup < clperchgroup)
> >> > - bi_next->num_planes = (ipqdepth - clpchgroup) /
> >> > clpchgroup + 1;
> >> > - else
> >> > - bi_next->num_planes = 0;
> >> > + if (i < num_groups - 1) {
> >> > + bi_next = &dev_priv->max_bw[i + 1];
> >> > +
> >> > + if (clpchgroup < clperchgroup)
> >> > + bi_next->num_planes = (ipqdepth -
> >> > clpchgroup) /
> >> > +clpchgroup + 1;
> >> > + else
> >> > + bi_next->num_planes = 0;
> >> > + }
> >> >
> >> > bi->num_qgv_points = qi.num_points;
> >> > bi->num_psf_gv_points = qi.num_psf_points;
> >> > --
> >> > 2.35.0.rc2.247.g8bbb082509-goog
> >> >
> >> >
> >>
> >> Was this patch ever applied or was the issue fixed in a different way?
> >> If CONFIG_INIT_STACK_ALL_ZERO is enabled (it is on by default when the
> >> compiler supports it), bi_next will be deterministically initialized to
> >> NULL, which means 'bi_next->num_planes = 0' will crash when the first if
> >> statement is not taken (i.e. 'i > num_groups - 1'). This was reported to
> >> us at [1] so it impacts real users (and I have been applying this change
> >> locally for six months). I see some discussion in this thread, was it
> >> ever resolved?
> >>
> >> [1]: https://github.com/ClangBuiltLinux/linux/issues/1626
> >>
> >> Cheers,
> >> Nathan
> >
> > The patch was n
RE: [PATCH v2 3/3] Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region
From: Vitaly Kuznetsov Sent: Thursday, August 25, 2022
2:00 AM
>
> Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
> DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
>
> $ cat /proc/iomem
> ...
> f800-fffb : PCI Bus :00
> f800-fbff : :00:08.0
> f800-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
> ...
> fe000-f : PCI Bus :00
> fe000-fe07f : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
> fe000-fe07f : 2ba2:00:02.0
> fe000-fe07f : mlx4_core
>
> the interesting part is the 'f800' region as it is actually the
> VM's framebuffer:
>
> $ lspci -v
> ...
> :00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
> VGA
> (prog-if 00 [VGA controller])
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f800 (32-bit, non-prefetchable) [size=64M]
> ...
>
> hv_vmbus: registering driver hyperv_drm
> hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Synthvid Version
> major 3, minor 5
> hyperv_drm :00:08.0: vgaarb: deactivate vga console
> hyperv_drm :00:08.0: BAR 0: can't reserve [mem 0xf800-0xfbff]
> hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Cannot request
> framebuffer, boot fb still active?
>
> Note: "Cannot request framebuffer" is not a fatal error in
> hyperv_setup_gen1() as the code assumes there's some other framebuffer
> device there but we actually have some other PCI device (mlx4 in this
> case) config space there!
My apologies for not getting around to commenting on the previous
version of this patch. The function hyperv_setup_gen1() and the
"Cannot request framebuffer" message have gone away as of
commit a0ab5abced55.
>
> The problem appears to be that vmbus_allocate_mmio() can allocate from
> the reserved framebuffer region (fb_overlap_ok), however, if the
> request to allocate MMIO comes from some other device before
> framebuffer region is taken, it can happily use framebuffer region for
> it.
Interesting. I had never looked at the details of vmbus_allocate_mmio().
The semantics one might assume of a parameter named "fb_overlap_ok"
aren't implemented because !fb_overlap_ok essentially has no effect. The
existing semantics are really "prefer_fb_overlap". This patch implements
the expected and needed semantics, which is to not allocate from the frame
buffer space when !fb_overlap_ok.
If that's an accurate high level summary, maybe this commit message
could describe it that way? The other details you provide about what can
go wrong should still be included as well.
> Note, Gen2 VMs are usually unaffected by the issue because
> framebuffer region is already taken by EFI fb (in case kernel supports
> it) but Gen1 VMs may have this region unclaimed by the time Hyper-V PCI
> pass-through driver tries allocating MMIO space if Hyper-V DRM/FB drivers
> load after it. Devices can be brought up in any sequence so let's
> resolve the issue by always ignoring 'fb_mmio' region for non-FB
> requests, even if the region is unclaimed.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/hv/vmbus_drv.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 536f68e563c6..3c833ea60db6 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -2331,7 +2331,7 @@ int vmbus_allocate_mmio(struct resource **new, struct
> hv_device *device_obj,
> bool fb_overlap_ok)
> {
> struct resource *iter, *shadow;
> - resource_size_t range_min, range_max, start;
> + resource_size_t range_min, range_max, start, end;
> const char *dev_n = dev_name(&device_obj->device);
> int retval;
>
> @@ -2366,6 +2366,14 @@ int vmbus_allocate_mmio(struct resource **new, struct
> hv_device *device_obj,
> range_max = iter->end;
> start = (range_min + align - 1) & ~(align - 1);
> for (; start + size - 1 <= range_max; start += align) {
> + end = start + size - 1;
> +
> + /* Skip the whole fb_mmio region if not fb_overlap_ok */
> + if (!fb_overlap_ok && fb_mmio &&
> + (((start >= fb_mmio->start) && (start <=
> fb_mmio->end)) ||
> + ((end >= fb_mmio->start) && (end <=
> fb_mmio->end
> + continue;
> +
> shadow = __request_region(iter, start, size, NULL,
> IORESOURCE_BUSY);
> if (!shadow)
> --
> 2.37.1
Other than my musings on the commit message,
Reviewed-by: Michael Kelley
Re: [PATCH 2/2] drm/i915: Add DSC support to MST path
On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> Hi Stan,
>
> Some comments inline..
>
> On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > Whenever we are not able to get enough timeslots
> > for required PBN, let's try to allocate those
> > using DSC, just same way as we do for SST.
> >
> > v2: Removed intel_dp_mst_dsc_compute_config and refactored
> > intel_dp_dsc_compute_config to support timeslots as a
> > parameter(Ville Syrjälä)
> >
> > v3: - Rebased
> > - Added a debug to see that we at least try reserving
> > VCPI slots using DSC, because currently its not visible
> > from the logs, thus making debugging more tricky.
> > - Moved timeslots to numerator, where it should be.
> >
> > v4: - Call drm_dp_mst_atomic_check already during link
> > config computation, because we need to know already
> > by this moment if uncompressed amount of VCPI slots
> > needed can fit, otherwise we need to use DSC.
> > (thanks to Vinod Govindapillai for pointing this out)
> >
> > v5: - Put pipe_config->bigjoiner_pipes back to original
> > condition in intel_dp_dsc_compute_config
> > (don't remember when I lost it)
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 73 -
> > drivers/gpu/drm/i915/display/intel_dp.h | 17 +++
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 157
> > 3 files changed, 205 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 32292c0be2bd..519b436fc530 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -116,7 +116,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > }
> >
> > static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> > -static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> > dsc_max_bpc);
> >
> > /* Is link rate UHBR and thus 128b/132b? */
> > bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
> > @@ -687,11 +686,12 @@ small_joiner_ram_size_bits(struct drm_i915_private
> > *i915)
> > return 6144 * 8;
> > }
> >
> > -static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > - u32 link_clock, u32 lane_count,
> > - u32 mode_clock, u32 mode_hdisplay,
> > - bool bigjoiner,
> > - u32 pipe_bpp)
> > +u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > + u32 link_clock, u32 lane_count,
> > + u32 mode_clock, u32 mode_hdisplay,
> > + bool bigjoiner,
> > + u32 pipe_bpp,
> > + u32 timeslots)
> > {
> > u32 bits_per_pixel, max_bpp_small_joiner_ram;
> > int i;
> > @@ -702,8 +702,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > drm_i915_private *i915,
> > * for SST -> TimeSlotsPerMTP is 1,
> > * for MST -> TimeSlotsPerMTP has to be calculated
> > */
> > - bits_per_pixel = (link_clock * lane_count * 8) /
> > + bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> > intel_dp_mode_to_fec_clock(mode_clock);
> > + drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
> >
> > /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz.
> > width */
> > max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
> > @@ -752,9 +753,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > drm_i915_private *i915,
> > return bits_per_pixel << 4;
> > }
> >
> > -static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > - int mode_clock, int mode_hdisplay,
> > - bool bigjoiner)
> > +u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > + int mode_clock, int mode_hdisplay,
> > + bool bigjoiner)
> > {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 min_slice_count, i;
> > @@ -961,8 +962,8 @@ intel_dp_mode_valid_downstream(struct intel_connector
> > *connector,
> > return MODE_OK;
> > }
> >
> > -static bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > - int hdisplay, int clock)
> > +bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > + int hdisplay, int clock)
> > {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >
> > @@ -1049,7 +1050,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> >
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Den 25.08.2022 15.44, skrev Maxime Ripard:
> Hi,
>
> On Sat, Aug 20, 2022 at 10:12:46PM +0200, Noralf Trønnes wrote:
>>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>>> index 1e9996b33cc8..78275e68ff66 100644
>>> --- a/include/drm/drm_connector.h
>>> +++ b/include/drm/drm_connector.h
>>> @@ -143,6 +143,32 @@ enum subpixel_order {
>>>
>>> };
>>>
>>> +#define DRM_MODE_TV_NORM_NTSC_443 (1 << 0)
>>> +#define DRM_MODE_TV_NORM_NTSC_J(1 << 1)
>>> +#define DRM_MODE_TV_NORM_NTSC_M(1 << 2)
>>> +#define DRM_MODE_TV_NORM_PAL_60(1 << 3)
>>> +#define DRM_MODE_TV_NORM_PAL_B (1 << 4)
>>> +#define DRM_MODE_TV_NORM_PAL_D (1 << 5)
>>> +#define DRM_MODE_TV_NORM_PAL_G (1 << 6)
>>> +#define DRM_MODE_TV_NORM_PAL_H (1 << 7)
>>> +#define DRM_MODE_TV_NORM_PAL_I (1 << 8)
>>> +#define DRM_MODE_TV_NORM_PAL_M (1 << 9)
>>> +#define DRM_MODE_TV_NORM_PAL_N (1 << 10)
>>> +#define DRM_MODE_TV_NORM_PAL_NC(1 << 11)
>>> +#define DRM_MODE_TV_NORM_SECAM_60 (1 << 12)
>>> +#define DRM_MODE_TV_NORM_SECAM_B (1 << 13)
>>> +#define DRM_MODE_TV_NORM_SECAM_D (1 << 14)
>>> +#define DRM_MODE_TV_NORM_SECAM_G (1 << 15)
>>> +#define DRM_MODE_TV_NORM_SECAM_K (1 << 16)
>>> +#define DRM_MODE_TV_NORM_SECAM_K1 (1 << 17)
>>> +#define DRM_MODE_TV_NORM_SECAM_L (1 << 18)
>>> +#define DRM_MODE_TV_NORM_HD480I(1 << 19)
>>> +#define DRM_MODE_TV_NORM_HD480P(1 << 20)
>>> +#define DRM_MODE_TV_NORM_HD576I(1 << 21)
>>> +#define DRM_MODE_TV_NORM_HD576P(1 << 22)
>>> +#define DRM_MODE_TV_NORM_HD720P(1 << 23)
>>> +#define DRM_MODE_TV_NORM_HD1080I (1 << 24)
>>> +
>>
>> This is an area where DRM overlaps with v4l2, see:
>> - include/dt-bindings/display/sdtv-standards.h
>> - v4l2_norm_to_name()
>>
>> Maybe we should follow suit, but if we do our own thing please mention
>> why in the commit message.
>
> Are you suggesting that we'd share that definition with v4l2?
>
If possible, yes.
> I've tried to share some code in the past between v4l2 and DRM, and it
> got completely shut down so it's not something I'd like to try again, if
> possible.
>
But that is a good enough reason not to do so. I just got the impression
from some of Laurent's emails a while back that there was some
cooperativ atmosphere, but I might be mistaken in my reading/understanding.
It is ofc possible to just copy the values from sdtv-standards.h, but I
see that hd* is missing from that list, so not sure if there's much
point if it has to be extended without changing the source.
We can at least use the names from v4l2_norm_to_name(), but from a quick
look it seems you already do so.
Noralf.
Re: [PATCH v3,1/2] soc: mediatek: Add mmsys func to adapt to dpi output for MT8186
On 23/08/2022 22:17, Nícolas F. R. A. Prado wrote: On Tue, Aug 23, 2022 at 02:38:22PM +0800, xinlei@mediatek.com wrote: From: Xinlei Lee Add mmsys function to manipulate dpi output format configuration for MT8186. Co-developed-by: Jitao Shi Signed-off-by: Jitao Shi Signed-off-by: Xinlei Lee Reviewed-by: Nícolas F. R. A. Prado Patch looks fine, I'll wait for v4 as there is still some discussion on the DRM part. Please try to fix the threading problem you had in sending this series. Thanks, Matthias
Re: [PATCH] drm/mediatek: dsi: Add atomic {destroy, duplicate}_state, reset callbacks
Chen-Yu Tsai 於 2022年8月19日 週五 晚上9:29寫道：
>
> On Fri, Jul 22, 2022 at 1:27 AM AngeloGioacchino Del Regno
> wrote:
> >
> > Add callbacks for atomic_destroy_state, atomic_duplicate_state and
> > atomic_reset to restore functionality of the DSI driver: this solves
> > vblank timeouts when another bridge is present in the chain.
> >
> > Tested bridge chain: DSI <=> ANX7625 => aux-bus panel
> >
Applied to mediatek-drm-fixes [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes
Regards,
Chun-Kuang.
> > Fixes: 7f6335c6a258 ("drm/mediatek: Modify dsi funcs to atomic operations")
> > Signed-off-by: AngeloGioacchino Del Regno
> >
>
> This patch is now needed on top of v6.0-rc1, otherwise booting will
> stall for a while waiting for display vblank, which never happens
> because the DSI pipeline is not configured correctly.
>
> ChenYu
>
> > ---
> >
> > Note: The commit that has been mentioned in the Fixes tag should
> > *not* have my Reviewed-by tag, as the author changed it but
> > erroneously retained the tag that I had released for an
> > earlier version of that commit (which was fine, but the new
> > version broke mtk_dsi!).
> >
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 9cc406e1eee1..5b624e0f5b0a 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -808,10 +808,13 @@ static void mtk_dsi_bridge_atomic_post_disable(struct
> > drm_bridge *bridge,
> >
> > static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
> > .attach = mtk_dsi_bridge_attach,
> > + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> > .atomic_disable = mtk_dsi_bridge_atomic_disable,
> > + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> > .atomic_enable = mtk_dsi_bridge_atomic_enable,
> > .atomic_pre_enable = mtk_dsi_bridge_atomic_pre_enable,
> > .atomic_post_disable = mtk_dsi_bridge_atomic_post_disable,
> > + .atomic_reset = drm_atomic_helper_bridge_reset,
> > .mode_set = mtk_dsi_bridge_mode_set,
> > };
> >
> > --
> > 2.35.1
> >
Re: [PATCH 2/2] drm/i915: Add DSC support to MST path
Hi Stan,
Some comments inline..
On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> Whenever we are not able to get enough timeslots
> for required PBN, let's try to allocate those
> using DSC, just same way as we do for SST.
>
> v2: Removed intel_dp_mst_dsc_compute_config and refactored
> intel_dp_dsc_compute_config to support timeslots as a
> parameter(Ville Syrjälä)
>
> v3: - Rebased
> - Added a debug to see that we at least try reserving
> VCPI slots using DSC, because currently its not visible
> from the logs, thus making debugging more tricky.
> - Moved timeslots to numerator, where it should be.
>
> v4: - Call drm_dp_mst_atomic_check already during link
> config computation, because we need to know already
> by this moment if uncompressed amount of VCPI slots
> needed can fit, otherwise we need to use DSC.
> (thanks to Vinod Govindapillai for pointing this out)
>
> v5: - Put pipe_config->bigjoiner_pipes back to original
> condition in intel_dp_dsc_compute_config
> (don't remember when I lost it)
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 73 -
> drivers/gpu/drm/i915/display/intel_dp.h | 17 +++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 157
> 3 files changed, 205 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 32292c0be2bd..519b436fc530 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -116,7 +116,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
> }
>
> static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> -static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> dsc_max_bpc);
>
> /* Is link rate UHBR and thus 128b/132b? */
> bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
> @@ -687,11 +686,12 @@ small_joiner_ram_size_bits(struct drm_i915_private
> *i915)
> return 6144 * 8;
> }
>
> -static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> - u32 link_clock, u32 lane_count,
> - u32 mode_clock, u32 mode_hdisplay,
> - bool bigjoiner,
> - u32 pipe_bpp)
> +u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> + u32 link_clock, u32 lane_count,
> + u32 mode_clock, u32 mode_hdisplay,
> + bool bigjoiner,
> + u32 pipe_bpp,
> + u32 timeslots)
> {
> u32 bits_per_pixel, max_bpp_small_joiner_ram;
> int i;
> @@ -702,8 +702,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> drm_i915_private *i915,
> * for SST -> TimeSlotsPerMTP is 1,
> * for MST -> TimeSlotsPerMTP has to be calculated
> */
> - bits_per_pixel = (link_clock * lane_count * 8) /
> + bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> intel_dp_mode_to_fec_clock(mode_clock);
> + drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
>
> /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width
> */
> max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
> @@ -752,9 +753,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> drm_i915_private *i915,
> return bits_per_pixel << 4;
> }
>
> -static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> - int mode_clock, int mode_hdisplay,
> - bool bigjoiner)
> +u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> + int mode_clock, int mode_hdisplay,
> + bool bigjoiner)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 min_slice_count, i;
> @@ -961,8 +962,8 @@ intel_dp_mode_valid_downstream(struct intel_connector
> *connector,
> return MODE_OK;
> }
>
> -static bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> - int hdisplay, int clock)
> +bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> + int hdisplay, int clock)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>
> @@ -1049,7 +1050,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> target_clock,
> mode->hdisplay,
> bigjoiner,
> - pipe_bpp) >> 4;
> +
Re: [Intel-gfx] [PATCH v6 3/4] drm/i915/display: add hotplug.suspended flag
On Thu, Aug 25, 2022 at 01:24:04PM +0200, Andrzej Hajda wrote: > On 24.08.2022 13:22, Imre Deak wrote: > > On Tue, Aug 23, 2022 at 11:48:01PM +0200, Andrzej Hajda wrote: > > > > > > > > > On 22.08.2022 19:27, Imre Deak wrote: > > > > On Fri, Jul 22, 2022 at 02:51:42PM +0200, Andrzej Hajda wrote: > > > > > HPD events during driver removal can be generated by hardware and > > > > > software frameworks - drm_dp_mst, the former we can avoid by disabling > > > > > interrupts, the latter can be triggered by any drm_dp_mst transaction, > > > > > and this is too late. Introducing suspended flag allows to solve this > > > > > chicken-egg problem. > > > > intel_hpd_cancel_work() is always called after suspending MST and > > > > disabling IRQs (with the order I suggested in patch 1). If both of these > > > > have disabled the corresponding functionality (MST, IRQs) properly with > > > > all their MST/IRQ scheduled works guaranteed to not get rescheduled, > > > > then it's not clear how could either intel_hpd_trigger_irq() or an IRQ > > > > work run. So the problematic sequence would need a better explanation. > > > > > > I am not familiar with MST but as I understand from earlier discussion MST > > > framework can be called during driver removal code even after > > > intel_dp_mst_suspend. > > > > Not sure how that happens, but it looks wrong. One way I can imagine is > > that connector detection re-enables MST, which should be prevented then. > > I am not MST expert and atm I have no access to the machine on which I could > look for real prove. > As I understand intel_dp_mst_suspend prevents only downstream devices to > initiate transactions, it does not prevent transactions initiated from i915 > driver. > My guesses for such transactions are: > - any ioctl/sysfs/drm_property access initiated by user which can involve > MST tranaction (set brightness, read EDID, reading capabilities, statuses, > ), unless they are already blocked, how? In theory all these should be blocked already, after i915_driver_unregister() has returned; for the above cases in particular via drm_connector_unregister_all(). > - maybe some mode_config disabling code (for example intel_mst_disable_dp) - This should be called already via i915_driver_unregister() -> intel_display_driver_unregister() -> drm_atomic_helper_shutdown(). > intel_mode_config_cleanup is called after intel_dp_mst_suspend. This should only free the allocated objects etc, but not do any transactions. > And since MST transfer can timeout it can trigger > drm_dp_mst_wait_tx_reply --> mgr->cbs->poll_hpd_irq(mgr) --> > intel_dp_mst_poll_hpd_irq --> intel_hpd_trigger_irq. > > If such situation happens after intel_dp_mst_suspend > i915->hotplug.dig_port_work will be queued, and we have risk of > use-after-free. > > If this analysis looks incorrect I can send patches 1, 2, 4 with your > comments addressed. CI probably will verify this anyway. Ok. I suppose blocking detection based on a new flag would mean avoiding scheduling and flushing hotplug.hotplug_work already as the first step in intel_display_driver_unregister() and somewhere early during system suspend. > Regards > Andrzej > > > > > > > And since MST transfer can timeout it can trigger > > > drm_dp_mst_wait_tx_reply --> mgr->cbs->poll_hpd_irq(mgr) --> > > > intel_dp_mst_poll_hpd_irq --> intel_hpd_trigger_irq. > > > > > > So actually this patch supersedes the 1st patch. > > > > > > > > > > > There's also already > > > > dev_priv->runtime_pm.irqs_enabled > > > > showing if hotplug interrupts are disabled (along with all other IRQs). > > > > > > So it is slightly different, this patch introduces flag indicating if HPD > > > is > > > enabled, we can have IRQs not related to HPD, and HPD events not related > > > to > > > IRQs. > > > > In its current form I can't see a difference. What would make sense is > > to add a flag that prevents connector detection (which would > > incorrectly enable MST for instace), but leave the handling of other > > interrupts enabled. That flag would be set already before suspending > > MST. > > > > > Regards > > > Andrzej > > > > > > > > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950 > > > > > Signed-off-by: Andrzej Hajda > > > > > Reviewed-by: Arun R Murthy > > > > > --- > > > > >drivers/gpu/drm/i915/display/intel_display.c | 2 +- > > > > >drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++- > > > > >drivers/gpu/drm/i915/display/intel_hotplug.h | 2 +- > > > > >drivers/gpu/drm/i915/i915_driver.c | 4 ++-- > > > > >drivers/gpu/drm/i915/i915_drv.h | 2 ++ > > > > >5 files changed, 16 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > > > > b/drivers/gpu/drm/i915/display/intel_display.c > > > > > index f1c765ac7ab8aa..cd6139bb36151b 100644 > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > > > > +++ b/drivers/gpu/d
RE: [PATCH v2 2/3] Drivers: hv: Always reserve framebuffer region for Gen1 VMs
From: Vitaly Kuznetsov Sent: Thursday, August 25, 2022
2:00 AM
>
> vmbus_reserve_fb() tries reserving framebuffer region iff
> 'screen_info.lfb_base' is set. Gen2 VMs seem to have it set by EFI fb
Just so I'm clear, by "EFI fb" you mean the EFI layer code that sets
up the frame buffer before the Linux kernel ever boots, right?
You are not referring to the Linux kernel EFI framebuffer
driver, which may or may not be configured in the kernel.
> (or, in some edge cases like kexec, the address where the buffer was
> moved, see
> https://lore.kernel.org/all/20201014092429.1415040-1-kas...@redhat.com/
> but on Gen1 VM it depends on bootloader behavior. With grub, it depends
> on 'gfxpayload=' setting but in some cases it is observed to be zero.
> Relying on 'screen_info.lfb_base' to reserve framebuffer region is
> risky. Instead, it is possible to get the address from the dedicated
> PCI device which is always present.
>
> Check for legacy PCI video device presence and reserve the whole
> region for framebuffer on Gen1 VMs.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/hv/vmbus_drv.c | 46 +-
> 1 file changed, 32 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 23c680d1a0f5..536f68e563c6 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "hyperv_vmbus.h"
>
> @@ -2262,26 +2263,43 @@ static int vmbus_acpi_remove(struct acpi_device
> *device)
>
> static void vmbus_reserve_fb(void)
> {
> - int size;
> + resource_size_t start = 0, size;
> + struct pci_dev *pdev;
> +
> + if (efi_enabled(EFI_BOOT)) {
> + /* Gen2 VM: get FB base from EFI framebuffer */
> + start = screen_info.lfb_base;
> + size = max_t(__u32, screen_info.lfb_size, 0x80);
> + } else {
> + /* Gen1 VM: get FB base from PCI */
> + pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
> + PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
> + if (!pdev)
> + return;
> +
> + if (pdev->resource[0].flags & IORESOURCE_MEM) {
> + start = pci_resource_start(pdev, 0);
> + size = pci_resource_len(pdev, 0);
> + }
> +
> + /*
> + * Release the PCI device so hyperv_drm or hyperv_fb driver can
> + * grab it later.
> + */
> + pci_dev_put(pdev);
> + }
> +
> + if (!start)
> + return;
> +
> /*
>* Make a claim for the frame buffer in the resource tree under the
>* first node, which will be the one below 4GB. The length seems to
>* be underreported, particularly in a Generation 1 VM. So start out
>* reserving a larger area and make it smaller until it succeeds.
>*/
> -
> - if (screen_info.lfb_base) {
> - if (efi_enabled(EFI_BOOT))
> - size = max_t(__u32, screen_info.lfb_size, 0x80);
> - else
> - size = max_t(__u32, screen_info.lfb_size, 0x400);
> -
> - for (; !fb_mmio && (size >= 0x10); size >>= 1) {
> - fb_mmio = __request_region(hyperv_mmio,
> -screen_info.lfb_base, size,
> -fb_mmio_name, 0);
> - }
> - }
> + for (; !fb_mmio && (size >= 0x10); size >>= 1)
> + fb_mmio = __request_region(hyperv_mmio, start, size,
> fb_mmio_name, 0);
> }
>
> /**
> --
> 2.37.1
Reviewed-by: Michael Kelley
[PATCH v5 28/31] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.
So this is no longer an issue an the quirk is no longer needed.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 67a0211c07b4..af2833b57b8b 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -132,21 +132,6 @@ static int video_detect_force_none(const struct
dmi_system_id *d)
}
static const struct dmi_system_id video_detect_dmi_table[] = {
- /* On Samsung X360, the BIOS will set a flag (VDRV) if generic
-* ACPI backlight device is used. This flag will definitively break
-* the backlight interface (even the vendor interface) until next
-* reboot. It's why we should prevent video.ko from being used here
-* and we can't rely on a later call to acpi_video_unregister().
-*/
- {
-.callback = video_detect_force_vendor,
-/* X360 */
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "X360"),
- DMI_MATCH(DMI_BOARD_NAME, "X360"),
- },
- },
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
.callback = video_detect_force_vendor,
--
2.37.2
[PATCH v5 27/31] ACPI: video: Remove acpi_video_set_dmi_backlight_type()
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.
All callers have been fixed to no longer call it, so remove
acpi_video_set_dmi_backlight_type() now.
This means we now also no longer need acpi_video_unregister_backlight()
for the remove acpi_video backlight after it was wrongly registered hack,
so remove that too.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 10 --
drivers/acpi/video_detect.c | 16
include/acpi/video.h| 4
3 files changed, 30 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index d1e41f30c004..a7c3d11e0dac 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2296,16 +2296,6 @@ void acpi_video_register_backlight(void)
}
EXPORT_SYMBOL(acpi_video_register_backlight);
-void acpi_video_unregister_backlight(void)
-{
- struct acpi_video_bus *video;
-
- mutex_lock(&video_list_lock);
- list_for_each_entry(video, &video_bus_head, entry)
- acpi_video_bus_unregister_backlight(video);
- mutex_unlock(&video_list_lock);
-}
-
bool acpi_video_handles_brightness_key_presses(void)
{
return may_report_brightness_keys &&
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 3861d4121172..67a0211c07b4 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -38,8 +38,6 @@
#include
#include
-void acpi_video_unregister_backlight(void);
-
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
@@ -817,17 +815,3 @@ bool acpi_video_backlight_use_native(void)
return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
}
EXPORT_SYMBOL(acpi_video_backlight_use_native);
-
-/*
- * Set the preferred backlight interface type based on DMI info.
- * This function allows DMI blacklists to be implemented by external
- * platform drivers instead of putting a big blacklist in video_detect.c
- */
-void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
-{
- acpi_backlight_dmi = type;
- /* Remove acpi-video backlight interface if it is no longer desired */
- if (acpi_video_get_backlight_type() != acpi_backlight_video)
- acpi_video_unregister_backlight();
-}
-EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
diff --git a/include/acpi/video.h b/include/acpi/video.h
index dbd48cb8bd23..a275c35e5249 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -60,7 +60,6 @@ extern int acpi_video_get_edid(struct acpi_device *device,
int type,
int device_id, void **edid);
extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
extern bool acpi_video_backlight_use_native(void);
-extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
/*
* Note: The value returned by acpi_video_handles_brightness_key_presses()
* may change over time and should not be cached.
@@ -86,9 +85,6 @@ static inline bool acpi_video_backlight_use_native(void)
{
return true;
}
-static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type
type)
-{
-}
static inline bool acpi_video_handles_brightness_key_presses(void)
{
return false;
--
2.37.2
[PATCH v5 31/31] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel
Add an entry summarizing the discussion about dealing with brightness control on devices with more then 1 internal panel. The original discussion can be found here: https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/ Reviewed-by: Lyude Paul Signed-off-by: Hans de Goede --- Documentation/gpu/todo.rst | 68 ++ 1 file changed, 68 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7634c27ac562..393d218e4a0c 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -679,6 +679,74 @@ Contact: Sam Ravnborg Level: Advanced +Brightness handling on devices with multiple internal panels + + +On x86/ACPI devices there can be multiple backlight firmware interfaces: +(ACPI) video, vendor specific and others. As well as direct/native (PWM) +register programming by the KMS driver. + +To deal with this backlight drivers used on x86/ACPI call +acpi_video_get_backlight_type() which has heuristics (+quirks) to select +which backlight interface to use; and backlight drivers which do not match +the returned type will not register themselves, so that only one backlight +device gets registered (in a single GPU setup, see below). + +At the moment this more or less assumes that there will only +be 1 (internal) panel on a system. + +On systems with 2 panels this may be a problem, depending on +what interface acpi_video_get_backlight_type() selects: + +1. native: in this case the KMS driver is expected to know which backlight + device belongs to which output so everything should just work. +2. video: this does support controlling multiple backlights, but some work + will need to be done to get the output <-> backlight device mapping + +The above assumes both panels will require the same backlight interface type. +Things will break on systems with multiple panels where the 2 panels need +a different type of control. E.g. one panel needs ACPI video backlight control, +where as the other is using native backlight control. Currently in this case +only one of the 2 required backlight devices will get registered, based on +the acpi_video_get_backlight_type() return value. + +If this (theoretical) case ever shows up, then supporting this will need some +work. A possible solution here would be to pass a device and connector-name +to acpi_video_get_backlight_type() so that it can deal with this. + +Note in a way we already have a case where userspace sees 2 panels, +in dual GPU laptop setups with a mux. On those systems we may see +either 2 native backlight devices; or 2 native backlight devices. + +Userspace already has code to deal with this by detecting if the related +panel is active (iow which way the mux between the GPU and the panels +points) and then uses that backlight device. Userspace here very much +assumes a single panel though. It picks only 1 of the 2 backlight devices +and then only uses that one. + +Note that all userspace code (that I know off) is currently hardcoded +to assume a single panel. + +Before the recent changes to not register multiple (e.g. video + native) +/sys/class/backlight devices for a single panel (on a single GPU laptop), +userspace would see multiple backlight devices all controlling the same +backlight. + +To deal with this userspace had to always picks one preferred device under +/sys/class/backlight and will ignore the others. So to support brightness +control on multiple panels userspace will need to be updated too. + +There are plans to allow brightness control through the KMS API by adding +a "display brightness" property to drm_connector objects for panels. This +solves a number of issues with the /sys/class/backlight API, including not +being able to map a sysfs backlight device to a specific connector. Any +userspace changes to add support for brightness control on devices with +multiple panels really should build on top of this new KMS property. + +Contact: Hans de Goede + +Level: Advanced + Outside DRM === -- 2.37.2
[PATCH v5 29/31] ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.
So this is no longer an issue an the quirks are no longer needed.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683
Tested-by: Werner Sembach
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 92 +
1 file changed, 1 insertion(+), 91 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index af2833b57b8b..789d5913c178 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -609,97 +609,7 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_BOARD_NAME, "N250P"),
},
},
- /*
-* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
-* working native and video interface. However the default detection
-* mechanism first registers the video interface before unregistering
-* it again and switching to the native interface during boot. This
-* results in a dangling SBIOS request for backlight change for some
-* reason, causing the backlight to switch to ~2% once per boot on the
-* first power cord connect or disconnect event. Setting the native
-* interface explicitly circumvents this buggy behaviour, by avoiding
-* the unregistering process.
-*/
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xRU",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xRU",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xRU",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xNU",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
- },
- },
- /*
-* The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15
Gen10,
-* Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the
Clevo
-* NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description
-* above.
-*/
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF5PU1G",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "PF5PU1G"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF4NU1F",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "PF4NU1F"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF4NU1F",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "PULSE1401"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF5NU1G",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "PF5NU1G"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF5NU1G",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "PULSE1501"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF5LUXG",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"),
- },
- },
+
/*
* Desktops which falsely report a backlight and which our heuristics
* for this do not catch.
--
2.37.2
[PATCH v5 30/31] ACPI: video: Fix indentation of video_detect_dmi_table[] entries
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.
Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.
But over time some entries did not event have the single space
indent in front of the ".name = ..." lines.
Make things consistent by using a single space indent for these
lines everywhere.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 48 ++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 789d5913c178..db2474fe58ac 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -142,17 +142,17 @@ static const struct dmi_system_id
video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_vendor,
- /* Asus UL30VT */
- .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30VT */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"),
},
},
{
- .callback = video_detect_force_vendor,
- /* Asus UL30A */
- .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30A */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
@@ -198,9 +198,9 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
},
},
{
- .callback = video_detect_force_vendor,
- /* GIGABYTE GB-BXBT-2807 */
- .matches = {
+.callback = video_detect_force_vendor,
+/* GIGABYTE GB-BXBT-2807 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
@@ -233,17 +233,17 @@ static const struct dmi_system_id
video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_vendor,
- /* Sony VPCEH3U1E */
- .matches = {
+.callback = video_detect_force_vendor,
+/* Sony VPCEH3U1E */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "VPCEH3U1E"),
},
},
{
- .callback = video_detect_force_vendor,
- /* Xiaomi Mi Pad 2 */
- .matches = {
+.callback = video_detect_force_vendor,
+/* Xiaomi Mi Pad 2 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Xiaomi Inc"),
DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"),
},
@@ -551,25 +551,25 @@ static const struct dmi_system_id
video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_native,
- /* ASUSTeK COMPUTER INC. GA401 */
- .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA401 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA401"),
},
},
{
- .callback = video_detect_force_native,
- /* ASUSTeK COMPUTER INC. GA502 */
- .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA502 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA502"),
},
},
{
- .callback = video_detect_force_native,
- /* ASUSTeK COMPUTER INC. GA503 */
- .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA503 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
--
2.37.2
[PATCH v5 26/31] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Move all the acpi_backlight=[vendor|native] quirks from samsung-laptop to
drivers/acpi/video_detect.c .
Note the X360 -> acpi_backlight=native quirk is not moved because that
already was present in drivers/acpi/video_detect.c .
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 54 +
drivers/platform/x86/samsung-laptop.c | 87 ---
2 files changed, 54 insertions(+), 87 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index a09089e7fada..3861d4121172 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -222,6 +222,33 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
},
+ {
+.callback = video_detect_force_vendor,
+/* Samsung N150/N210/N220 */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N150/N210/N220"),
+ DMI_MATCH(DMI_BOARD_NAME, "N150/N210/N220"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Samsung NF110/NF210/NF310 */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "NF110/NF210/NF310"),
+ DMI_MATCH(DMI_BOARD_NAME, "NF110/NF210/NF310"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Samsung NC210 */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "NC210/NC110"),
+ DMI_MATCH(DMI_BOARD_NAME, "NC210/NC110"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* Sony VPCEH3U1E */
@@ -572,6 +599,33 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
},
},
+ {
+.callback = video_detect_force_native,
+/* Samsung N150P */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N150P"),
+ },
+ },
+ {
+.callback = video_detect_force_native,
+/* Samsung N145P/N250P/N260P */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N145P/N250P/N260P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N145P/N250P/N260P"),
+ },
+ },
+ {
+.callback = video_detect_force_native,
+/* Samsung N250P */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N250P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N250P"),
+ },
+ },
/*
* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
* working native and video interface. However the default detection
diff --git a/drivers/platform/x86/samsung-laptop.c
b/drivers/platform/x86/samsung-laptop.c
index c187dcdf82f0..cc30cf08f32d 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -356,23 +356,13 @@ struct samsung_laptop {
};
struct samsung_quirks {
- bool broken_acpi_video;
bool four_kbd_backlight_levels;
bool enable_kbd_backlight;
- bool use_native_backlight;
bool lid_handling;
};
static struct samsung_quirks samsung_unknown = {};
-static struct samsung_quirks samsung_broken_acpi_video = {
- .broken_acpi_video = true,
-};
-
-static struct samsung_quirks samsung_use_native_backlight = {
- .use_native_backlight = true,
-};
-
static struct samsung_quirks samsung_np740u3e = {
.four_kbd_backlight_levels = true,
.enable_kbd_backlight = true,
@@ -1540,76 +1530,6 @@ static const struct dmi_system_id samsung_dmi_table[]
__initconst = {
},
},
/* Specific DMI ids for laptop with quirks */
- {
-.callback = samsung_dmi_matched,
-.ident = "N150P",
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
- DMI_MATCH(DMI_BOARD_NAME, "N150P"),
- },
-.driver_data = &samsung_use_native_backlight,
- },
- {
-.callback = samsung
[PATCH v5 24/31] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Note no entries are dropped from the dmi_system_id table in asus-nb-wmi.c.
This is because the entries using the removed wmi_backlight_power flag
also use other model specific quirks from the asus-wmi quirk_entry struct.
So the quirk_asus_x55u struct and the entries pointing to it cannot be
dropped.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c| 40 ++
drivers/platform/x86/asus-nb-wmi.c | 7 --
drivers/platform/x86/asus-wmi.c| 3 ---
drivers/platform/x86/asus-wmi.h| 1 -
drivers/platform/x86/eeepc-wmi.c | 25 +--
5 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 6a2523bc02ba..d893313fe1a0 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -174,6 +174,46 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
},
+ {
+.callback = video_detect_force_vendor,
+/* Asus X55U */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X55U"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Asus X101CH */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Asus X401U */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X401U"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Asus X501U */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X501U"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Asus 1015CX */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* GIGABYTE GB-BXBT-2807 */
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index 478dd300b9c9..810a94557a85 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -79,12 +79,10 @@ static struct quirk_entry quirk_asus_q500a = {
/*
* For those machines that need software to control bt/wifi status
- * and can't adjust brightness through ACPI interface
* and have duplicate events(ACPI and WMI) for display toggle
*/
static struct quirk_entry quirk_asus_x55u = {
.wapf = 4,
- .wmi_backlight_power = true,
.wmi_backlight_set_devstate = true,
.no_display_toggle = true,
};
@@ -147,11 +145,6 @@ static const struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "U32U"),
},
- /*
-* Note this machine has a Brazos APU, and most Brazos Asus
-* machines need quirk_asus_x55u / wmi_backlight_power but
-* here acpi-video seems to work fine for backlight control.
-*/
.driver_data = &quirk_asus_wapf4,
},
{
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 301166a5697d..5cf9d9aff164 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
- if (asus->driver->quirks->wmi_backlight_power)
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (asus->driver->quirks->wmi_backlight_native)
acpi_video_set_dmi_backlight_type(acpi_backlight_native);
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index b302415bf1d9..30770e411301 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct
[PATCH v5 25/31] platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c| 8
drivers/platform/x86/asus-nb-wmi.c | 14 --
drivers/platform/x86/asus-wmi.c| 3 ---
drivers/platform/x86/asus-wmi.h| 1 -
4 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index d893313fe1a0..a09089e7fada 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -564,6 +564,14 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
},
+ {
+.callback = video_detect_force_native,
+/* Asus UX303UB */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
+ },
+ },
/*
* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
* working native and video interface. However the default detection
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index 810a94557a85..bbfed85051ee 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -97,11 +97,6 @@ static struct quirk_entry quirk_asus_x200ca = {
.wmi_backlight_set_devstate = true,
};
-static struct quirk_entry quirk_asus_ux303ub = {
- .wmi_backlight_native = true,
- .wmi_backlight_set_devstate = true,
-};
-
static struct quirk_entry quirk_asus_x550lb = {
.wmi_backlight_set_devstate = true,
.xusb2pr = 0x01D9,
@@ -372,15 +367,6 @@ static const struct dmi_system_id asus_quirks[] = {
},
.driver_data = &quirk_asus_x200ca,
},
- {
- .callback = dmi_matched,
- .ident = "ASUSTeK COMPUTER INC. UX303UB",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
- DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
- },
- .driver_data = &quirk_asus_ux303ub,
- },
{
.callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. UX330UAK",
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 5cf9d9aff164..434249ac47a5 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
- if (asus->driver->quirks->wmi_backlight_native)
- acpi_video_set_dmi_backlight_type(acpi_backlight_native);
-
if (asus->driver->quirks->xusb2pr)
asus_wmi_set_xusb2pr(asus);
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 30770e411301..f30252efe1db 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct quirk_entry {
bool hotplug_wireless;
bool scalar_panel_brightness;
bool store_backlight_power;
- bool wmi_backlight_native;
bool wmi_backlight_set_devstate;
bool wmi_force_als_set;
bool use_kbd_dock_devid;
--
2.37.2
[PATCH v5 23/31] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling
Remove this check from the asus-wmi backlight handling: /* Some Asus desktop boards export an acpi-video backlight interface, stop this from showing up */ chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE); if (chassis_type && !strcmp(chassis_type, "3")) acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); This acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) call must be removed because other changes in this series change the native backlight drivers to no longer unconditionally register their backlight. Instead these drivers now do this check: if (acpi_video_get_backlight_type(false) != acpi_backlight_native) return 0; /* bail */ So leaving this in place can break things on laptops with a broken DMI chassis-type, which would have GPU native brightness control before the addition of the acpi_video_get_backlight_type() != native check. Removing this should be ok now, since the ACPI video code has improved heuristics for this itself now (which includes a chassis-type check). Signed-off-by: Hans de Goede --- drivers/platform/x86/asus-wmi.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index 89b604e04d7f..301166a5697d 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -3553,7 +3553,6 @@ static int asus_wmi_add(struct platform_device *pdev) struct platform_driver *pdrv = to_platform_driver(pdev->dev.driver); struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv); struct asus_wmi *asus; - const char *chassis_type; acpi_status status; int err; u32 result; @@ -3635,12 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev) if (asus->driver->quirks->wmi_force_als_set) asus_wmi_set_als(); - /* Some Asus desktop boards export an acpi-video backlight interface, - stop this from showing up */ - chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE); - if (chassis_type && !strcmp(chassis_type, "3")) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (asus->driver->quirks->wmi_backlight_power) acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); -- 2.37.2
[PATCH v5 18/31] ACPI: video: Add Apple GMUX brightness control detection
On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.
Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.
This will allow removig the (ab)use of:
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
Inside the apple-gmux driver.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 4
include/acpi/video.h| 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 4dc7fb865083..be2fc43418af 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
#include
@@ -607,6 +608,9 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
if (nvidia_wmi_ec_present)
return acpi_backlight_nvidia_wmi_ec;
+ if (apple_gmux_present())
+ return acpi_backlight_apple_gmux;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 91578e77ac4e..dbd48cb8bd23 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -49,6 +49,7 @@ enum acpi_backlight_type {
acpi_backlight_vendor,
acpi_backlight_native,
acpi_backlight_nvidia_wmi_ec,
+ acpi_backlight_apple_gmux,
};
#if IS_ENABLED(CONFIG_ACPI_VIDEO)
--
2.37.2
[PATCH v5 19/31] platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()
Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec
check. This will make nvidia-wmi-ec-backlight properly honor the user
selecting a different backlight driver through the acpi_backlight=...
kernel commandline option.
Since the auto-detect code check for nvidia-wmi-ec-backlight in
drivers/acpi/video_detect.c already checks that the WMI advertised
brightness-source is the embedded controller, this new check makes it
unnecessary for nvidia_wmi_ec_backlight_probe() to check this itself.
Suggested-by: Daniel Dadap
Reviewed-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/nvidia-wmi-ec-backlight.c | 14 +++---
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index f2f98e942cf2..0cc5ac35fc57 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -93,6 +93,7 @@ config PEAQ_WMI
config NVIDIA_WMI_EC_BACKLIGHT
tristate "EC Backlight Driver for Hybrid Graphics Notebook Systems"
+ depends on ACPI_VIDEO
depends on ACPI_WMI
depends on BACKLIGHT_CLASS_DEVICE
help
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index be803e47eac0..baccdf658538 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/**
* wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI
method
@@ -87,19 +88,10 @@ static int nvidia_wmi_ec_backlight_probe(struct wmi_device
*wdev, const void *ct
{
struct backlight_properties props = {};
struct backlight_device *bdev;
- u32 source;
int ret;
- ret = wmi_brightness_notify(wdev, WMI_BRIGHTNESS_METHOD_SOURCE,
- WMI_BRIGHTNESS_MODE_GET, &source);
- if (ret)
- return ret;
-
- /*
-* This driver is only to be used when brightness control is handled
-* by the EC; otherwise, the GPU driver(s) should control brightness.
-*/
- if (source != WMI_BRIGHTNESS_SOURCE_EC)
+ /* drivers/acpi/video_detect.c also checks that SOURCE == EC */
+ if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
return -ENODEV;
/*
--
2.37.2
[PATCH v5 22/31] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c
Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Note that even though the DMI quirk table name was video_vendor_dmi_table,
5/6 quirks were actually quirks to use the GPU native backlight.
These 5 quirks also had a callback in their dmi_system_id entry which
disabled the acer-wmi vendor driver; and any DMI match resulted in:
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
which disabled the acpi_video driver, so only the native driver was left.
The new entries for these 5/6 devices correctly marks these as needing
the native backlight driver.
Also note that other changes in this series change the native backlight
drivers to no longer unconditionally register their backlight. Instead
these drivers now do this check:
if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
return 0; /* bail */
which without this patch would have broken these 5/6 "special" quirks.
Since I had to look at all the commits adding the quirks anyways, to make
sure that I understood the code correctly, I've also added links to
the various original bugzillas for these quirks to the new entries.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 53 ++
drivers/platform/x86/acer-wmi.c | 66 -
2 files changed, 53 insertions(+), 66 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 74e2087c8ff0..6a2523bc02ba 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -149,6 +149,15 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_BOARD_NAME, "X360"),
},
},
+ {
+/* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
+.callback = video_detect_force_vendor,
+/* Acer KAV80 */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* Asus UL30VT */
@@ -437,6 +446,41 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_BOARD_NAME, "JV50"),
},
},
+ {
+/* https://bugzilla.redhat.com/show_bug.cgi?id=1012674 */
+.callback = video_detect_force_native,
+/* Acer Aspire 5741 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
+ },
+ },
+ {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42993 */
+.callback = video_detect_force_native,
+/* Acer Aspire 5750 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
+ },
+ },
+ {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42833 */
+.callback = video_detect_force_native,
+/* Acer Extensa 5235 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
+ },
+ },
+ {
+.callback = video_detect_force_native,
+/* Acer TravelMate 4750 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
+ },
+ },
{
/* https://bugzilla.kernel.org/show_bug.cgi?id=207835 */
.callback = video_detect_force_native,
@@ -447,6 +491,15 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_BOARD_NAME, "BA51_MV"),
},
},
+ {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=36322 */
+.callback = video_detect_force_native,
+/* Acer TravelMate 5760 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
+ },
+ },
{
.callback = video_detect_force_native,
/* ASUSTeK COMPUTER INC. GA401 */
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index e0230ea0cb7e..b933a5165edb 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -643,69 +643,6 @@ static const struct dmi_system_id non_acer_quirks[]
__initconst = {
{}
};
-static int __init
-video_set_backlight_video_vendor(const struct dmi_system_id *d)
-{
- interface->cap
[PATCH v5 21/31] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type()
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.
In case of toshiba_acpi there are no DMI quirks to move to
acpi/video_detect.c, but it also (ab)uses it for transflective
displays. Adding transflective display support to video_detect.c would
be quite involved. But luckily there are only 2 known models with
a transflective display, so we can just add DMI quirks for those.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 19 +++
drivers/platform/x86/toshiba_acpi.c | 16
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index be2fc43418af..74e2087c8ff0 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -190,6 +190,25 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
},
},
+ /*
+* Toshiba models with Transflective display, these need to use
+* the toshiba_acpi vendor driver for proper Transflective handling.
+*/
+ {
+.callback = video_detect_force_vendor,
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R500"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R600"),
+ },
+ },
+
/*
* These models have a working acpi_video backlight control, and using
* native backlight causes a regression where backlight does not work
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 0fc9e8b8827b..030dc37d50b8 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -271,14 +271,6 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
{ KE_END, 0 },
};
-/*
- * List of models which have a broken acpi-video backlight interface and thus
- * need to use the toshiba (vendor) interface instead.
- */
-static const struct dmi_system_id toshiba_vendor_backlight_dmi[] = {
- {}
-};
-
/*
* Utility
*/
@@ -2881,14 +2873,6 @@ static int toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
return 0;
}
- /*
-* Tell acpi-video-detect code to prefer vendor backlight on all
-* systems with transflective backlight and on dmi matched systems.
-*/
- if (dev->tr_backlight_supported ||
- dmi_check_system(toshiba_vendor_backlight_dmi))
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return 0;
--
2.37.2
[PATCH v5 20/31] platform/x86: apple-gmux: Stop calling acpi/video.h functions
Now that acpi_video_get_backlight_type() has apple-gmux detection (using apple_gmux_present()), it is no longer necessary for the apple-gmux code to manually remove possibly conflicting drivers. So remove the handling for this from the apple-gmux driver. Signed-off-by: Hans de Goede --- drivers/platform/x86/apple-gmux.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c index ffe98a18440b..ca33df7ea550 100644 --- a/drivers/platform/x86/apple-gmux.c +++ b/drivers/platform/x86/apple-gmux.c @@ -21,7 +21,6 @@ #include #include #include -#include #include /** @@ -694,7 +693,6 @@ static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id) * backlight control and supports more levels than other options. * Disable the other backlight choices. */ - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); apple_bl_unregister(); gmux_data->power_state = VGA_SWITCHEROO_ON; @@ -804,7 +802,6 @@ static void gmux_remove(struct pnp_dev *pnp) apple_gmux_data = NULL; kfree(gmux_data); - acpi_video_register(); apple_bl_register(); } -- 2.37.2
[PATCH v5 16/31] ACPI: video: Refactor acpi_video_get_backlight_type() a bit
Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.
Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 39 ++---
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index fb49b8f4523a..cc9d0d91e268 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -537,16 +537,6 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
- *
- * The autodetect order is:
- * 1) Is the acpi-video backlight interface supported ->
- * no, use a vendor interface
- * 2) Is this a win8 "ready" BIOS and do we have a native interface ->
- * yes, use a native interface
- * 3) Else use the acpi-video interface
- *
- * Arguably the native on win8 check should be done first, but that would
- * be a behavior change, which may causes issues.
*/
static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
@@ -569,19 +559,36 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
native_available = true;
mutex_unlock(&init_mutex);
+ /*
+* The below heuristics / detection steps are in order of descending
+* presedence. The commandline takes presedence over anything else.
+*/
if (acpi_backlight_cmdline != acpi_backlight_undef)
return acpi_backlight_cmdline;
+ /* DMI quirks override any autodetection. */
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
- if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
- return acpi_backlight_vendor;
-
- if (acpi_osi_is_win8() && native_available)
- return acpi_backlight_native;
+ /* On systems with ACPI video use either native or ACPI video. */
+ if (video_caps & ACPI_VIDEO_BACKLIGHT) {
+ /*
+* Windows 8 and newer no longer use the ACPI video interface,
+* so it often does not work. If the ACPI tables are written
+* for win8 and native brightness ctl is available, use that.
+*
+* The native check deliberately is inside the if acpi-video
+* block on older devices without acpi-video support native
+* is usually not the best choice.
+*/
+ if (acpi_osi_is_win8() && native_available)
+ return acpi_backlight_native;
+ else
+ return acpi_backlight_video;
+ }
- return acpi_backlight_video;
+ /* No ACPI video (old hw), use vendor specific fw methods. */
+ return acpi_backlight_vendor;
}
enum acpi_backlight_type acpi_video_get_backlight_type(void)
--
2.37.2
[PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.
Changes in v2:
- Use the new shared nvidia-wmi-ec-backlight.h header for the
WMI firmware API definitions
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Changes in v3:
- Use WMI_BRIGHTNESS_GUID define
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/Kconfig | 1 +
drivers/acpi/video_detect.c| 37 ++
drivers/gpu/drm/gma500/Kconfig | 2 ++
drivers/gpu/drm/i915/Kconfig | 2 ++
include/acpi/video.h | 1 +
5 files changed, 43 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7802d8846a8d..44ad4b6bd234 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -212,6 +212,7 @@ config ACPI_VIDEO
tristate "Video"
depends on BACKLIGHT_CLASS_DEVICE
depends on INPUT
+ depends on ACPI_WMI || !X86
select THERMAL
help
This driver implements the ACPI Extensions For Display Adapters
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index cc9d0d91e268..4dc7fb865083 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -75,6 +76,36 @@ find_video(acpi_handle handle, u32 lvl, void *context, void
**rv)
return AE_OK;
}
+/* This depends on ACPI_WMI which is X86 only */
+#ifdef CONFIG_X86
+static bool nvidia_wmi_ec_supported(void)
+{
+ struct wmi_brightness_args args = {
+ .mode = WMI_BRIGHTNESS_MODE_GET,
+ .val = 0,
+ .ret = 0,
+ };
+ struct acpi_buffer buf = { (acpi_size)sizeof(args), &args };
+ acpi_status status;
+
+ status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0,
+WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ /*
+* If brightness is handled by the EC then nvidia-wmi-ec-backlight
+* should be used, else the GPU driver(s) should be used.
+*/
+ return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
+}
+#else
+static bool nvidia_wmi_ec_supported(void)
+{
+ return false;
+}
+#endif
+
/* Force to use vendor driver when the ACPI device is known to be
* buggy */
static int video_detect_force_vendor(const struct dmi_system_id *d)
@@ -541,6 +572,7 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool nvidia_wmi_ec_present;
static bool native_available;
static bool init_done;
static long video_caps;
@@ -553,6 +585,7 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
+ nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
init_done = true;
}
if (native)
@@ -570,6 +603,10 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
+ /* Special cases such as nvidia_wmi_ec and apple gmux. */
+ if (nvidia_wmi_ec_present)
+ return acpi_backlight_nvidia_wmi_ec;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0cff20265f97..807b989e3c77 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -7,6 +7,8 @@ config DRM_GMA500
select ACPI_VIDEO if ACPI
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
+ select X86_PLATFORM_DEVICES if ACPI
+ select ACPI_WMI if ACPI
help
Say yes for an experimental 2D KMS framebuffer driver for the
Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7ae3b7d67fcf..3efce05d7b57 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,8 @@ config DRM_I915
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_CLASS_DEVICE if ACPI
[PATCH v5 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2)
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Changes in v2:
- Add missing Nvidia copyright header
- Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
MAINTAINERS | 1 +
.../platform/x86/nvidia-wmi-ec-backlight.c| 68 +
.../x86/nvidia-wmi-ec-backlight.h | 76 +++
3 files changed, 78 insertions(+), 67 deletions(-)
create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d7f64dc0efe..d6f6b96f51f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14527,6 +14527,7 @@ M: Daniel Dadap
L: platform-driver-...@vger.kernel.org
S: Supported
F: drivers/platform/x86/nvidia-wmi-ec-backlight.c
+F: include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
NVM EXPRESS DRIVER
M: Keith Busch
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index 61e37194df70..be803e47eac0 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -7,74 +7,10 @@
#include
#include
#include
+#include
#include
#include
-/**
- * enum wmi_brightness_method - WMI method IDs
- * @WMI_BRIGHTNESS_METHOD_LEVEL: Get/Set EC brightness level status
- * @WMI_BRIGHTNESS_METHOD_SOURCE: Get/Set EC Brightness Source
- */
-enum wmi_brightness_method {
- WMI_BRIGHTNESS_METHOD_LEVEL = 1,
- WMI_BRIGHTNESS_METHOD_SOURCE = 2,
- WMI_BRIGHTNESS_METHOD_MAX
-};
-
-/**
- * enum wmi_brightness_mode - Operation mode for WMI-wrapped method
- * @WMI_BRIGHTNESS_MODE_GET:Get the current brightness
level/source.
- * @WMI_BRIGHTNESS_MODE_SET:Set the brightness level.
- * @WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL: Get the maximum brightness level. This
- * is only valid when the WMI method is
- * %WMI_BRIGHTNESS_METHOD_LEVEL.
- */
-enum wmi_brightness_mode {
- WMI_BRIGHTNESS_MODE_GET = 0,
- WMI_BRIGHTNESS_MODE_SET = 1,
- WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL = 2,
- WMI_BRIGHTNESS_MODE_MAX
-};
-
-/**
- * enum wmi_brightness_source - Backlight brightness control source selection
- * @WMI_BRIGHTNESS_SOURCE_GPU: Backlight brightness is controlled by the GPU.
- * @WMI_BRIGHTNESS_SOURCE_EC: Backlight brightness is controlled by the
- * system's Embedded Controller (EC).
- * @WMI_BRIGHTNESS_SOURCE_AUX: Backlight brightness is controlled over the
- * DisplayPort AUX channel.
- */
-enum wmi_brightness_source {
- WMI_BRIGHTNESS_SOURCE_GPU = 1,
- WMI_BRIGHTNESS_SOURCE_EC = 2,
- WMI_BRIGHTNESS_SOURCE_AUX = 3,
- WMI_BRIGHTNESS_SOURCE_MAX
-};
-
-/**
- * struct wmi_brightness_args - arguments for the WMI-wrapped ACPI method
- * @mode:Pass in an &enum wmi_brightness_mode value to select between
- * getting or setting a value.
- * @val: In parameter for value to set when using %WMI_BRIGHTNESS_MODE_SET
- * mode. Not used in conjunction with %WMI_BRIGHTNESS_MODE_GET or
- * %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL mode.
- * @ret: Out parameter returning retrieved value when operating in
- * %WMI_BRIGHTNESS_MODE_GET or %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL
- * mode. Not used in %WMI_BRIGHTNESS_MODE_SET mode.
- * @ignored: Padding; not used. The ACPI method expects a 24 byte params
struct.
- *
- * This is the parameters structure for the WmiBrightnessNotify ACPI method as
- * wrapped by WMI. The value passed in to @val or returned by @ret will be a
- * brightness value when the WMI method ID is %WMI_BRIGHTNESS_METHOD_LEVEL, or
- * an &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
- */
-struct wmi_brightness_args {
- u32 mode;
- u32 val;
- u32 ret;
- u32 ignored[3];
-};
-
/**
* wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI
method
* @w:Pointer to the struct wmi_device identified by %WMI_BRIGHTNESS_GUID
@@ -191,8 +127,6 @@ static int nvidia_wmi_ec_backlight_probe(struct wmi_device
*wdev, const void *ct
return PTR_ERR_OR_ZERO(bdev);
}
-#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
-
static const struct wmi_device_id nvidia_wmi_ec_backlight_id_table[] = {
{ .guid_string = WMI_BRIGHTNESS_GUID },
{ }
diff --git a/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
new file mode 100644
index ..23d60130272c
--- /dev/null
+++ b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020, NVIDIA CORPOR
[PATCH v5 14/31] drm/radeon: Register ACPI video backlight when skipping radeon backlight registration
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when radeon skips
registering its own backlight device because of e.g. the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the radeon drm_device gets registered with userspace.
Acked-by: Alex Deucher
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 35c535e48b8d..fbc0a2182318 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -30,6 +30,8 @@
#include
#include
+#include
+
#include "radeon.h"
#include "radeon_atombios.h"
#include "radeon_legacy_encoders.h"
@@ -167,7 +169,7 @@ static void radeon_encoder_add_backlight(struct
radeon_encoder *radeon_encoder,
return;
if (radeon_backlight == 0) {
- return;
+ use_bl = false;
} else if (radeon_backlight == 1) {
use_bl = true;
} else if (radeon_backlight == -1) {
@@ -193,6 +195,13 @@ static void radeon_encoder_add_backlight(struct
radeon_encoder *radeon_encoder,
else
radeon_legacy_backlight_init(radeon_encoder, connector);
}
+
+ /*
+* If there is no native backlight device (which may happen even when
+* use_bl==true) try registering an ACPI video backlight device instead.
+*/
+ if (!rdev->mode_info.bl_encoder)
+ acpi_video_register_backlight();
}
void
--
2.37.2
[PATCH v5 12/31] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2)
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when native backlight
device registration has failed / was skipped to ensure that there is a
backlight device available before the drm_device gets registered with
userspace.
Changes in v2:
- Add nouveau_acpi_video_register_backlight() wrapper to avoid unresolved
symbol errors on non X86
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 5 +
drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 ++
drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 1592c9cd7750..8cf096f841a9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -391,3 +391,8 @@ bool nouveau_acpi_video_backlight_use_native(void)
{
return acpi_video_backlight_use_native();
}
+
+void nouveau_acpi_video_register_backlight(void)
+{
+ acpi_video_register_backlight();
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index 3c666c30dfca..e39dd8b94b8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -12,6 +12,7 @@ void nouveau_unregister_dsm_handler(void);
void nouveau_switcheroo_optimus_dsm(void);
void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
bool nouveau_acpi_video_backlight_use_native(void);
+void nouveau_acpi_video_register_backlight(void);
#else
static inline bool nouveau_is_optimus(void) { return false; };
static inline bool nouveau_is_v1_dsm(void) { return false; };
@@ -20,6 +21,7 @@ static inline void nouveau_unregister_dsm_handler(void) {}
static inline void nouveau_switcheroo_optimus_dsm(void) {}
static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector) { return NULL; }
static inline bool nouveau_acpi_video_backlight_use_native(void) { return
true; }
+static inline void nouveau_acpi_video_register_backlight(void) {}
#endif
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index d2b8f8c13db4..a614582779ca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -436,6 +436,13 @@ nouveau_backlight_init(struct drm_connector *connector)
fail_alloc:
kfree(bl);
+ /*
+* If we get here we have an internal panel, but no nv_backlight,
+* try registering an ACPI video backlight device instead.
+*/
+ if (ret == 0)
+ nouveau_acpi_video_register_backlight();
+
return ret;
}
--
2.37.2
[PATCH v5 13/31] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when amdgpu skips
registering its own backlight device because of either the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the amdgpu drm_device gets registered with userspace.
Acked-by: Alex Deucher
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 9 +++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index b4e3cedceaf8..6be9ac2b9c5b 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -184,11 +184,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
return;
if (!(adev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
- return;
+ goto register_acpi_backlight;
if (!acpi_video_backlight_use_native()) {
drm_info(dev, "Skipping amdgpu atom DIG backlight
registration\n");
- return;
+ goto register_acpi_backlight;
}
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
@@ -225,6 +225,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
error:
kfree(pdata);
return;
+
+register_acpi_backlight:
+ /* Try registering an ACPI video backlight device instead. */
+ acpi_video_register_backlight();
+ return;
}
void
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 706c67f4bda8..c450964f84d4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4037,6 +4037,8 @@ amdgpu_dm_register_backlight_device(struct
amdgpu_display_manager *dm)
if (!acpi_video_backlight_use_native()) {
drm_info(adev_to_drm(dm->adev), "Skipping amdgpu DM backlight
registration\n");
+ /* Try registering an ACPI video backlight device instead. */
+ acpi_video_register_backlight();
return;
}
--
2.37.2
[PATCH v5 11/31] drm/i915: Call acpi_video_register_backlight() (v3)
On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the drivers/acpi/video_detect.c code
unregistered the acpi_video0 device to avoid there being 2 backlight
devices (when acpi_video_get_backlight_type()==native).
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() after the i915 calls
acpi_video_register() (after setting up the i915 opregion) so that the
acpi_video backlight devices get registered on systems where the i915
native backlight device is not registered.
Changes in v2:
-Only call acpi_video_register_backlight() when a panel is detected
Changes in v3:
-Add a new intel_acpi_video_register() helper which checks if a panel
is present and then calls acpi_video_register_backlight()
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_acpi.c| 27
drivers/gpu/drm/i915/display/intel_acpi.h| 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f07..9df78e7caa2b 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include "i915_drv.h"
#include "intel_acpi.h"
@@ -331,3 +332,29 @@ void intel_acpi_assign_connector_fwnodes(struct
drm_i915_private *i915)
*/
fwnode_handle_put(fwnode);
}
+
+void intel_acpi_video_register(struct drm_i915_private *i915)
+{
+ struct drm_connector_list_iter conn_iter;
+ struct drm_connector *connector;
+
+ acpi_video_register();
+
+ /*
+* If i915 is driving an internal panel without registering its native
+* backlight handler try to register the acpi_video backlight.
+* For panels not driven by i915 another GPU driver may still register
+* a native backlight later and acpi_video_register_backlight() should
+* only be called after any native backlights have been registered.
+*/
+ drm_connector_list_iter_begin(&i915->drm, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
+ struct intel_panel *panel =
&to_intel_connector(connector)->panel;
+
+ if (panel->backlight.funcs && !panel->backlight.device) {
+ acpi_video_register_backlight();
+ break;
+ }
+ }
+ drm_connector_list_iter_end(&conn_iter);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
b/drivers/gpu/drm/i915/display/intel_acpi.h
index 4a760a2baed9..6a0007452f95 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -14,6 +14,7 @@ void intel_unregister_dsm_handler(void);
void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
void intel_acpi_device_id_update(struct drm_i915_private *i915);
void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915);
+void intel_acpi_video_register(struct drm_i915_private *i915);
#else
static inline void intel_register_dsm_handler(void) { return; }
static inline void intel_unregister_dsm_handler(void) { return; }
@@ -23,6 +24,8 @@ static inline
void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
static inline
void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) {
return; }
+static inline
+void intel_acpi_video_register(struct drm_i915_private *i915) { return; }
#endif /* CONFIG_ACPI */
#endif /* __INTEL_ACPI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6103b02c081f..129a13375101 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9087,7 +9087,7 @@ void intel_display_driver_register(struct
drm_i915_private *i915)
/* Must be done after probing outputs */
intel_opregion_register(i915);
- acpi_video_register();
+ intel_acpi_video_register(i915);
intel_audio_init(i915);
--
2.37.2
[PATCH v5 09/31] ACPI: video: Make backlight class device registration a separate step (v2)
On x86/ACPI boards the acpi_video driver will usually initialize before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the acpi_video0 device (when acpi_video_get_backlight_type()==native).
This means that userspace briefly sees 2 devices and the disappearing of
acpi_video0 after a brief time confuses the systemd backlight level
save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this make backlight class device registration a separate step
done by a new acpi_video_register_backlight() function. The intend is for
this to be called by the drm/kms driver *after* it is done setting up its
own native backlight device. So that acpi_video_get_backlight_type() knows
if a native backlight will be available or not at acpi_video backlight
registration time, avoiding the add + remove dance.
Note the new acpi_video_register_backlight() function is also called from
a delayed work to ensure that the acpi_video backlight devices does get
registered if necessary even if there is no drm/kms driver or when it is
disabled.
Changes in v2:
- Make register_backlight_delay a module parameter, mainly so that it can
be disabled by Nvidia binary driver users
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 50 ---
include/acpi/video.h | 2 ++
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 8545bf94866f..09dd86f86cf3 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -73,6 +73,16 @@ module_param(device_id_scheme, bool, 0444);
static int only_lcd = -1;
module_param(only_lcd, int, 0444);
+/*
+ * Display probing is known to take up to 5 seconds, so delay the fallback
+ * backlight registration by 5 seconds + 3 seconds for some extra margin.
+ */
+static int register_backlight_delay = 8;
+module_param(register_backlight_delay, int, 0444);
+MODULE_PARM_DESC(register_backlight_delay,
+ "Delay in seconds before doing fallback (non GPU driver triggered) "
+ "backlight registration, set to 0 to disable.");
+
static bool may_report_brightness_keys;
static int register_count;
static DEFINE_MUTEX(register_count_mutex);
@@ -81,6 +91,9 @@ static LIST_HEAD(video_bus_head);
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+static void acpi_video_bus_register_backlight_work(struct work_struct
*ignored);
+static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
+ acpi_video_bus_register_backlight_work);
void acpi_video_detect_exit(void);
/*
@@ -1859,8 +1872,6 @@ static int acpi_video_bus_register_backlight(struct
acpi_video_bus *video)
if (video->backlight_registered)
return 0;
- acpi_video_run_bcl_for_osi(video);
-
if (acpi_video_get_backlight_type() != acpi_backlight_video)
return 0;
@@ -2086,7 +2097,11 @@ static int acpi_video_bus_add(struct acpi_device *device)
list_add_tail(&video->entry, &video_bus_head);
mutex_unlock(&video_list_lock);
- acpi_video_bus_register_backlight(video);
+ /*
+* The userspace visible backlight_device gets registered separately
+* from acpi_video_register_backlight().
+*/
+ acpi_video_run_bcl_for_osi(video);
acpi_video_bus_add_notify_handler(video);
return 0;
@@ -2125,6 +2140,11 @@ static int acpi_video_bus_remove(struct acpi_device
*device)
return 0;
}
+static void acpi_video_bus_register_backlight_work(struct work_struct *ignored)
+{
+ acpi_video_register_backlight();
+}
+
static int __init is_i740(struct pci_dev *dev)
{
if (dev->device == 0x00D1)
@@ -2235,6 +2255,18 @@ int acpi_video_register(void)
*/
register_count = 1;
+ /*
+* acpi_video_bus_add() skips registering the userspace visible
+* backlight_device. The intend is for this to be registered by the
+* drm/kms driver calling acpi_video_register_backlight() *after* it is
+* done setting up its own native backlight device. The delayed work
+* ensures that acpi_video_register_backlight() always gets called
+* eventually, in case there is no drm/kms driver or it is disabled.
+*/
+ if (register_backlight_delay)
+ schedule_delayed_work(&video_bus_register_backlight_work,
+ register_backlight_delay * HZ);
+
leave:
mutex_unlock(®ister_count_mutex);
return ret;
@@ -2245,6 +2277,7 @@ void acpi_video_unregister(void)
{
mutex_lock(®ister_count_mutex);
if (reg
[PATCH v5 10/31] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer necessary to monitor for a
native (BACKLIGHT_RAW) device showing up later and to then unregister
the acpi_video backlight device(s).
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 2 --
drivers/acpi/video_detect.c | 36
2 files changed, 38 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 09dd86f86cf3..d1e41f30c004 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -94,7 +94,6 @@ static void acpi_video_bus_notify(struct acpi_device *device,
u32 event);
static void acpi_video_bus_register_backlight_work(struct work_struct
*ignored);
static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
acpi_video_bus_register_backlight_work);
-void acpi_video_detect_exit(void);
/*
* Indices in the _BCL method response: the first two items are special,
@@ -2342,7 +2341,6 @@ static int __init acpi_video_init(void)
static void __exit acpi_video_exit(void)
{
- acpi_video_detect_exit();
acpi_video_unregister();
}
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 385eb49c763f..fb49b8f4523a 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -38,10 +38,6 @@
void acpi_video_unregister_backlight(void);
-static bool backlight_notifier_registered;
-static struct notifier_block backlight_nb;
-static struct work_struct backlight_notify_work;
-
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
@@ -538,26 +534,6 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
{ },
};
-/* This uses a workqueue to avoid various locking ordering issues */
-static void acpi_video_backlight_notify_work(struct work_struct *work)
-{
- if (acpi_video_get_backlight_type() != acpi_backlight_video)
- acpi_video_unregister_backlight();
-}
-
-static int acpi_video_backlight_notify(struct notifier_block *nb,
- unsigned long val, void *bd)
-{
- struct backlight_device *backlight = bd;
-
- /* A raw bl registering may change video -> native */
- if (backlight->props.type == BACKLIGHT_RAW &&
- val == BACKLIGHT_REGISTERED)
- schedule_work(&backlight_notify_work);
-
- return NOTIFY_OK;
-}
-
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
@@ -587,12 +563,6 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
- INIT_WORK(&backlight_notify_work,
- acpi_video_backlight_notify_work);
- backlight_nb.notifier_call = acpi_video_backlight_notify;
- backlight_nb.priority = 0;
- if (backlight_register_notifier(&backlight_nb) == 0)
- backlight_notifier_registered = true;
init_done = true;
}
if (native)
@@ -639,9 +609,3 @@ void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type)
acpi_video_unregister_backlight();
}
EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
-
-void __exit acpi_video_detect_exit(void)
-{
- if (backlight_notifier_registered)
- backlight_unregister_notifier(&backlight_nb);
-}
--
2.37.2
[PATCH v5 08/31] ACPI: video: Simplify acpi_video_unregister_backlight()
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index cde8ffa9f0b8..8545bf94866f 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2257,14 +2257,10 @@ void acpi_video_unregister_backlight(void)
{
struct acpi_video_bus *video;
- mutex_lock(®ister_count_mutex);
- if (register_count) {
- mutex_lock(&video_list_lock);
- list_for_each_entry(video, &video_bus_head, entry)
- acpi_video_bus_unregister_backlight(video);
- mutex_unlock(&video_list_lock);
- }
- mutex_unlock(®ister_count_mutex);
+ mutex_lock(&video_list_lock);
+ list_for_each_entry(video, &video_bus_head, entry)
+ acpi_video_bus_unregister_backlight(video);
+ mutex_unlock(&video_list_lock);
}
bool acpi_video_handles_brightness_key_presses(void)
--
2.37.2
[PATCH v5 07/31] ACPI: video: Remove acpi_video_bus from list before tearing it down
Move the list_del removing an acpi_video_bus from video_bus_head on teardown to before the teardown is done, to avoid code iterating over the video_bus_head list seeing acpi_video_bus objects on there which are (partly) torn down already. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/acpi_video.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index 5cbe2196176d..cde8ffa9f0b8 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -2111,14 +2111,14 @@ static int acpi_video_bus_remove(struct acpi_device *device) video = acpi_driver_data(device); - acpi_video_bus_remove_notify_handler(video); - acpi_video_bus_unregister_backlight(video); - acpi_video_bus_put_devices(video); - mutex_lock(&video_list_lock); list_del(&video->entry); mutex_unlock(&video_list_lock); + acpi_video_bus_remove_notify_handler(video); + acpi_video_bus_unregister_backlight(video); + acpi_video_bus_put_devices(video); + kfree(video->attached_array); kfree(video); -- 2.37.2
[PATCH v5 06/31] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type()
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type backlight devices call acpi_video_backlight_use_native() now. This sets __acpi_video_get_backlight_type()'s internal static native_available flag. This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check unnecessary. Relying on the cached native_available value not only is simpler, it will also work correctly in cases where then native backlight registration was skipped because of acpi_video_backlight_use_native() returning false. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 5f105eaa7d30..385eb49c763f 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -608,8 +608,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) if (!(video_caps & ACPI_VIDEO_BACKLIGHT)) return acpi_backlight_vendor; - if (acpi_osi_is_win8() && - (native_available || backlight_device_get_by_type(BACKLIGHT_RAW))) + if (acpi_osi_is_win8() && native_available) return acpi_backlight_native; return acpi_backlight_video; -- 2.37.2
[PATCH v5 01/31] ACPI: video: Add acpi_video_backlight_use_native() helper
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2 backlight devices for a single display really is undesirable.
On x86 laptops where the native GPU backlight device should be used,
the registering of other backlight devices is avoided by their drivers
using acpi_video_get_backlight_type() and only registering their backlight
if the return value matches their type.
acpi_video_get_backlight_type() uses
backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
driver is available and will never return native if this returns
false. This means that the GPU's native backlight registering code
cannot just call acpi_video_get_backlight_type() to determine if it
should register its backlight, since acpi_video_get_backlight_type() will
never return native until the native backlight has already registered.
To fix this add a new internal native function parameter to
acpi_video_get_backlight_type(), which when set to true will make
acpi_video_get_backlight_type() behave as if a native backlight has
already been registered.
And add a new acpi_video_backlight_use_native() helper, which sets this
to true, for use in native GPU backlight code.
Changes in v2:
- Replace adding a native parameter to acpi_video_get_backlight_type() with
adding a new acpi_video_backlight_use_native() helper.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 24
include/acpi/video.h| 5 +
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 5d7f38016a24..5f105eaa7d30 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -17,8 +17,9 @@
* Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
* sony_acpi,... can take care about backlight brightness.
*
- * Backlight drivers can use acpi_video_get_backlight_type() to determine
- * which driver should handle the backlight.
+ * Backlight drivers can use acpi_video_get_backlight_type() to determine which
+ * driver should handle the backlight. RAW/GPU-driver backlight drivers must
+ * use the acpi_video_backlight_use_native() helper for this.
*
* If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a module (m)
* this file will not be compiled and acpi_video_get_backlight_type() will
@@ -571,9 +572,10 @@ static int acpi_video_backlight_notify(struct
notifier_block *nb,
* Arguably the native on win8 check should be done first, but that would
* be a behavior change, which may causes issues.
*/
-enum acpi_backlight_type acpi_video_get_backlight_type(void)
+static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool native_available;
static bool init_done;
static long video_caps;
@@ -593,6 +595,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
backlight_notifier_registered = true;
init_done = true;
}
+ if (native)
+ native_available = true;
mutex_unlock(&init_mutex);
if (acpi_backlight_cmdline != acpi_backlight_undef)
@@ -604,13 +608,25 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
return acpi_backlight_vendor;
- if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
+ if (acpi_osi_is_win8() &&
+ (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
return acpi_backlight_native;
return acpi_backlight_video;
}
+
+enum acpi_backlight_type acpi_video_get_backlight_type(void)
+{
+ return __acpi_video_get_backlight_type(false);
+}
EXPORT_SYMBOL(acpi_video_get_backlight_type);
+bool acpi_video_backlight_use_native(void)
+{
+ return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
+}
+EXPORT_SYMBOL(acpi_video_backlight_use_native);
+
/*
* Set the preferred backlight interface type based on DMI info.
* This function allows DMI blacklists to be implemented by external
diff --git a/include/acpi/video.h b/include/acpi/video.h
index db8548ff03ce..4705e339c252 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
extern int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid);
extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
+extern bool acpi_video_backlight_use_native(void);
extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
/*
* Note: The value returned by acpi_v
[PATCH v5 05/31] drm/nouveau: Don't register backlight when another backlight should be used (v2)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Changes in v2:
- Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved
symbol errors on non X86
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 5 +
drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 ++
drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 6140db756d06..1592c9cd7750 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -386,3 +386,8 @@ nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector)
return kmemdup(edid, EDID_LENGTH, GFP_KERNEL);
}
+
+bool nouveau_acpi_video_backlight_use_native(void)
+{
+ return acpi_video_backlight_use_native();
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index 330f9b837066..3c666c30dfca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -11,6 +11,7 @@ void nouveau_register_dsm_handler(void);
void nouveau_unregister_dsm_handler(void);
void nouveau_switcheroo_optimus_dsm(void);
void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
+bool nouveau_acpi_video_backlight_use_native(void);
#else
static inline bool nouveau_is_optimus(void) { return false; };
static inline bool nouveau_is_v1_dsm(void) { return false; };
@@ -18,6 +19,7 @@ static inline void nouveau_register_dsm_handler(void) {}
static inline void nouveau_unregister_dsm_handler(void) {}
static inline void nouveau_switcheroo_optimus_dsm(void) {}
static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector) { return NULL; }
+static inline bool nouveau_acpi_video_backlight_use_native(void) { return
true; }
#endif
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index a2141d3d9b1d..d2b8f8c13db4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -38,6 +38,7 @@
#include "nouveau_reg.h"
#include "nouveau_encoder.h"
#include "nouveau_connector.h"
+#include "nouveau_acpi.h"
static struct ida bl_ida;
#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
@@ -405,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
goto fail_alloc;
}
+ if (!nouveau_acpi_video_backlight_use_native()) {
+ NV_INFO(drm, "Skipping nv_backlight registration\n");
+ goto fail_alloc;
+ }
+
if (!nouveau_get_backlight_name(backlight_name, bl)) {
NV_ERROR(drm, "Failed to retrieve a unique name for the
backlight interface\n");
goto fail_alloc;
--
2.37.2
[PATCH v5 03/31] drm/amdgpu: Don't register backlight when another backlight should be used (v3)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Changes in v2:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
a module, select ACPI_VIDEO and its deps if ACPI is enabled.
When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
the stubs from acpi/video.h will be used.
Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Acked-by: Alex Deucher
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7 +++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0b2ad7212ee6..95ca33938b4a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -259,6 +259,13 @@ config DRM_AMDGPU
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
select DRM_BUDDY
+ # amdgpu depends on ACPI_VIDEO when ACPI is enabled, for select to work
+ # ACPI_VIDEO's dependencies must also be selected.
+ select INPUT if ACPI
+ select ACPI_VIDEO if ACPI
+ # On x86 ACPI_VIDEO also needs ACPI_WMI
+ select X86_PLATFORM_DEVICES if ACPI && X86
+ select ACPI_WMI if ACPI && X86
help
Choose this option if you have a recent AMD Radeon graphics card.
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index fa7421afb9a6..b4e3cedceaf8 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -26,6 +26,8 @@
#include
+#include
+
#include
#include
#include "amdgpu.h"
@@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
if (!(adev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(dev, "Skipping amdgpu atom DIG backlight
registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e702f0d72d53..706c67f4bda8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -90,6 +90,8 @@
#include
#include
+#include
+
#include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
#include "dcn/dcn_1_0_offset.h"
@@ -4033,6 +4035,11 @@ amdgpu_dm_register_backlight_device(struct
amdgpu_display_manager *dm)
amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(adev_to_drm(dm->adev), "Skipping amdgpu DM backlight
registration\n");
+ return;
+ }
+
props.max_brightness = AMDGPU_MAX_BL_LEVEL;
props.brightness = AMDGPU_MAX_BL_LEVEL;
props.type = BACKLIGHT_RAW;
--
2.37.2
[PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Changes in v2:
- Use drm_info(drm_dev, ...) for log messages
Reviewed-by: Jani Nikula
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 681ebcda97ad..03c7966f68d6 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -8,6 +8,8 @@
#include
#include
+#include
+
#include "intel_backlight.h"
#include "intel_backlight_regs.h"
#include "intel_connector.h"
@@ -952,6 +954,11 @@ int intel_backlight_device_register(struct intel_connector
*connector)
WARN_ON(panel->backlight.max == 0);
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(&i915->drm, "Skipping intel_backlight registration\n");
+ return 0;
+ }
+
memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
--
2.37.2
Re: [PATCH v4 03/10] dt-bindings: display/msm: move qcom, sc7180-mdss schema to mdss.yaml
On 25/08/2022 15:40, Dmitry Baryshkov wrote: >>> clock-names: >>> items: >>> + - const: bus >>> - const: iface >>> - - const: ahb >>> + - const: rot >>> + - const: lut >>> - const: core >>> + - const: vsync >> >> All these changes point that device schemas are simply different and >> trying to unify them is not correct approach. > > I'm not going the argue the mdss-common + platform specifics, but please > note that these changes are coming from me removing one extra level of > depth in dpu-smth.yaml. Currently these files have both mdss and dpu > devices, I'm stripping the mdss out of them. True, it's second time I got myself looking at wrong part of diff hunk. Still your allOf:if:then grows with different cases. I guess the biggest differences came with sdm845 and later only children and clocks differ. Best regards, Krzysztof
[PATCH v5 04/31] drm/radeon: Don't register backlight when another backlight should be used (v3)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Changes in v2:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
a module, select ACPI_VIDEO and its deps if ACPI is enabled.
When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
the stubs from acpi/video.h will be used.
Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Acked-by: Alex Deucher
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/radeon/atombios_encoders.c | 7 +++
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 7 +++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95ca33938b4a..0471505e951d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -234,6 +234,13 @@ config DRM_RADEON
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+ # radeon depends on ACPI_VIDEO when ACPI is enabled, for select to work
+ # ACPI_VIDEO's dependencies must also be selected.
+ select INPUT if ACPI
+ select ACPI_VIDEO if ACPI
+ # On x86 ACPI_VIDEO also needs ACPI_WMI
+ select X86_PLATFORM_DEVICES if ACPI && X86
+ select ACPI_WMI if ACPI && X86
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 0eae05dfb385..c841c273222e 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -32,6 +32,8 @@
#include
#include
+#include
+
#include "atom.h"
#include "radeon_atombios.h"
#include "radeon.h"
@@ -209,6 +211,11 @@ void radeon_atom_backlight_init(struct radeon_encoder
*radeon_encoder,
if (!(rdev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(dev, "Skipping radeon atom DIG backlight
registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 1a66fb969ee7..0cd32c65456c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -33,6 +33,8 @@
#include
#include
+#include
+
#include "radeon.h"
#include "radeon_asic.h"
#include "radeon_legacy_encoders.h"
@@ -387,6 +389,11 @@ void radeon_legacy_backlight_init(struct radeon_encoder
*radeon_encoder,
return;
#endif
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(dev, "Skipping radeon legacy LVDS backlight
registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
--
2.37.2
[PATCH v5 00/31] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
Hi All, As mentioned in my RFC titled "drm/kms: control display brightness through drm_connector properties": https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/ The first step towards this is to deal with some existing technical debt in backlight handling on x86/ACPI boards, specifically we need to stop registering multiple /sys/class/backlight devs for a single display. This series implements my RFC describing my plan for these cleanups: https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ Changes in version 5: - Use drm_info(drm_dev, ...) in patch 2/31 - Modify "drm/i915: Call acpi_video_register_backlight()", dropping the global has_panel flag, replacing it with a new intel_acpi_video_register() helper Changes in version 4: - Minor tweaks to nvidia-wmi-ec-backlight changes - Add nouveau_acpi_* wrappers around used include/acpi/video.h functions to fix unresolved symbol errors on non X86 Changes in version 3: - ACPI_VIDEO can now be enabled on non X86 too, adjust various Kconfig changes - Make the delay before doing fallback acpi_video backlight registration a module option (patch 9) - Move the nvidia-wmi-ec-backlight fw API definitions to a shared header - Add a "acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec" check to the nvidia-wmi-ec-backlight driver (patch 19) Changes in version 2: - Introduce acpi_video_backlight_use_native() helper - Finishes the refactoring, addressing all the bits from the "Other issues" section of the refactor RFC This series as submitted is based on drm-tip for CI purposes. Assuming the last i915 patch also pass review now, I hope to push out an immutable branch with this series on top of v6.0-rc1 and send out a pull-request to all involved subsystems based on this branch soon. Regards, Hans Hans de Goede (31): ACPI: video: Add acpi_video_backlight_use_native() helper drm/i915: Don't register backlight when another backlight should be used (v2) drm/amdgpu: Don't register backlight when another backlight should be used (v3) drm/radeon: Don't register backlight when another backlight should be used (v3) drm/nouveau: Don't register backlight when another backlight should be used (v2) ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() ACPI: video: Remove acpi_video_bus from list before tearing it down ACPI: video: Simplify acpi_video_unregister_backlight() ACPI: video: Make backlight class device registration a separate step (v2) ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers drm/i915: Call acpi_video_register_backlight() (v3) drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2) drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration drm/radeon: Register ACPI video backlight when skipping radeon backlight registration platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2) ACPI: video: Refactor acpi_video_get_backlight_type() a bit ACPI: video: Add Nvidia WMI EC brightness control detection (v3) ACPI: video: Add Apple GMUX brightness control detection platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type() platform/x86: apple-gmux: Stop calling acpi/video.h functions platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type() platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c ACPI: video: Remove acpi_video_set_dmi_backlight_type() ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks ACPI: video: Fix indentation of video_detect_dmi_table[] entries drm/todo: Add entry about dealing with brightness control on devices with > 1 panel Documentation/gpu/todo.rst| 68 +++ MAINTAINERS | 1 + drivers/acpi/Kconfig | 1 + drivers/acpi/acpi_video.c | 64 ++- drivers/acpi/video_detect.c | 428 +++--- drivers/gpu/drm/Kconfig | 14 + .../gpu/drm/amd/amdgpu/atombios_encoders.c| 14 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 + drivers/gpu/drm/gma500/Kconfig| 2 + drivers/gpu/drm/i915/Kconfig | 2 + drivers/gpu/drm/i915/display/intel_acpi.c | 27 ++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 +
RE: [PATCH v2 1/3] PCI: Move PCI_VENDOR_ID_MICROSOFT/PCI_DEVICE_ID_HYPERV_VIDEO definitions to pci_ids.h
From: Vitaly Kuznetsov Sent: Thursday, August 25, 2022
2:00 AM
>
> There are already three places in kernel which define PCI_VENDOR_ID_MICROSOFT
> and two for PCI_DEVICE_ID_HYPERV_VIDEO and there's a need to use these
> from core Vmbus code. Move the defines where they belong.
>
> No functional change.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 3 ---
> drivers/net/ethernet/microsoft/mana/gdma_main.c | 4
> drivers/video/fbdev/hyperv_fb.c | 4
> include/linux/pci_ids.h | 3 +++
> 4 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> index 6d11e7938c83..40888e36f91a 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> @@ -23,9 +23,6 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -#define PCI_VENDOR_ID_MICROSOFT 0x1414
> -#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> -
> DEFINE_DRM_GEM_FOPS(hv_fops);
>
> static struct drm_driver hyperv_driver = {
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> index 5f9240182351..00d8198072ae 100644
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -1465,10 +1465,6 @@ static void mana_gd_shutdown(struct pci_dev *pdev)
> pci_disable_device(pdev);
> }
>
> -#ifndef PCI_VENDOR_ID_MICROSOFT
> -#define PCI_VENDOR_ID_MICROSOFT 0x1414
> -#endif
> -
> static const struct pci_device_id mana_id_table[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_PF_DEVICE_ID) },
> { PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_VF_DEVICE_ID) },
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index 886c564787f1..b58b445bb529 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -74,10 +74,6 @@
> #define SYNTHVID_DEPTH_WIN8 32
> #define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
>
> -#define PCI_VENDOR_ID_MICROSOFT 0x1414
> -#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> -
> -
> enum pipe_msg_type {
> PIPE_MSG_INVALID,
> PIPE_MSG_DATA,
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 6feade66efdb..15b49e655ce3 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2079,6 +2079,9 @@
> #define PCI_DEVICE_ID_ICE_1712 0x1712
> #define PCI_DEVICE_ID_VT1724 0x1724
>
> +#define PCI_VENDOR_ID_MICROSOFT 0x1414
> +#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
> +
> #define PCI_VENDOR_ID_OXSEMI 0x1415
> #define PCI_DEVICE_ID_OXSEMI_12PCI8400x8403
> #define PCI_DEVICE_ID_OXSEMI_PCIe840 0xC000
> --
> 2.37.1
Reviewed-by: Michael Kelley
