These are never modified, so make them const to allow the compiler to
put them in read-only memory. WHile at it, make the description const
char* since it is never modified.
Zhenyu Wang [Mon, 11 Oct 2021 04:33:29 +0000 (12:33 +0800)]
drm/i915/gvt: Fix cmd parser error for Passmark9
This is to add one new register required for windows guest driver
update when running Passmark9, otherwise cmd parser would complain
and fail guest workload.
Mark Brown [Mon, 13 Dec 2021 17:07:53 +0000 (17:07 +0000)]
drm/i915: Fix implicit use of struct pci_dev
intel_device_info.h references struct pci_dev but does not ensure that
the struct has been declared, causing build failures if something in
other headers changes so that the implicit dependency it is relying on
is no longer satisfied:
In file included from drivers/gpu/drm/i915/intel_device_info.h:32,
from drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:11,
from drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:11:
drivers/gpu/drm/i915/display/intel_display.h:643:39: error: 'struct pci_dev' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
643 | bool intel_modeset_probe_defer(struct pci_dev *pdev);
| ^~~~~~~
cc1: all warnings being treated as errors
Ville Syrjälä [Fri, 10 Dec 2021 12:27:26 +0000 (14:27 +0200)]
drm/i915: Move pipe/transcoder/abox masks under intel_device_info.display
Collect the dipslay related mask under the display sub-structure
in intel_device_info.
Note that there is a slight change in behaviour in that we zero
out .display entirely when !HAS_DISPLAY (aka. pipe_mask==0), so
now we also zero out the other masks (although cpu_transocder_mask
should already be zero of pipe_mask is zero). abox_mask is
only used by the display core init when HAS_DISPLAY is true, so
the actual behaviour of the system shouldn't change despite the
zeroing of these masks.
There is a lot more display stuff directly in device info that
could be moved over. Maybe someone else will be inspired to do it...
Hans de Goede [Tue, 5 Oct 2021 20:23:22 +0000 (22:23 +0200)]
drm/i915: Add privacy-screen support (v3)
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
Changes in v3:
- Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector()
Changes in v2:
- Call drm_connector_update_privacy_screen() from
intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
- Move the probe-deferral check to the intel_modeset_probe_defer() helper
Hans de Goede [Tue, 5 Oct 2021 20:23:21 +0000 (22:23 +0200)]
drm/i915: Add intel_modeset_probe_defer() helper
The upcoming privacy-screen support adds another check for
deferring probe till some other drivers have bound first.
Factor out the current vga_switcheroo_client_probe_defer() check
into an intel_modeset_probe_defer() helper, so that further
probe-deferral checks can be added there.
Jani Nikula [Wed, 8 Dec 2021 11:05:17 +0000 (13:05 +0200)]
drm/i915/trace: split out display trace to a separate file
Add display/intel_display_trace.[ch] for defining display
tracepoints. The main goal is to reduce cross-includes between gem and
display. It would be possible split up tracing even further, but that
would lead to more boilerplate.
We end up having to include intel_crtc.h in a few places because it was
pulled in implicitly via intel_de.h -> i915_trace.h -> intel_crtc.h, and
that's no longer the case.
Changes since v2.12:
- Release notes for v2.13:
1. Fix for simple flip queue with DC6v
- Release notes for v2.14:
1. Fix for flip queue roll over cases with DC6v
2. Enhancement for residency
3. Workaround for 3Dlut restore issue
Siva Mullati [Wed, 8 Dec 2021 04:12:15 +0000 (09:42 +0530)]
drm/i915: Skip remap_io_mapping() for non-x86 platforms
Only hw that supports mappable aperture would hit this path
vm_fault_gtt/vm_fault_tmm, So we never hit this function
remap_io_mapping() in discrete, So skip this code for non-x86
architectures.
v2: use IS_ENABLED () instead of #if defined
v3: move function prototypes from i915_drv.h to i915_mm.h
Mika Kahola [Fri, 19 Nov 2021 13:13:47 +0000 (15:13 +0200)]
drm/i915/display/dg2: Read CD clock from squasher table
To calculate CD clock with squasher unit, we set CD clock ratio to fixed value of 34.
The CD clock value is read from CD clock squasher table.
BSpec: 54034
v2: Read ratio from register (Ville)
Drop unnecessary local variable (Ville)
Get CD clock from the given table
v3: Calculate CD clock frequency based on waveform bit pattern (Ville)
[v4: vsyrjala: Actually do a proper blind readout from the hardware]
[v5: vsyrjala: Use has_cdclk_squasher()]
Mika Kahola [Fri, 19 Nov 2021 13:13:46 +0000 (15:13 +0200)]
drm/i915/display/dg2: Set CD clock squashing registers
Set CD clock squashing registers based on selected CD clock.
v2: use slk_cdclk_decimal() to compute decimal values instead of a
specific table (Ville)
Set waveform based on CD clock table (Ville)
Drop unnecessary local variable (Ville)
v3: Correct function naming (Ville)
Correct if-else structure (Ville)
[v4: vsyrjala: Fix spaces vs. tabs]
[v5: vsyrjala: Fix cd2x divider calculation (Uma),
Add warn to waveform lookup (Uma),
Handle bypass freq in waveform lookup,
Generalize waveform handling in bxt_set_cdclk()]
Mika Kahola [Fri, 19 Nov 2021 13:13:44 +0000 (15:13 +0200)]
drm/i915/display/dg2: Introduce CD clock squashing table
For CD clock squashing method, we need to define corresponding CD clock table for
reference clocks, dividers and ratios for all CD clock options.
BSpec: 54034
v2: Add CD squashing waveforms as part of CD clock table (Ville)
v3: Waveform is 16 bits wide (Ville)
[v4: vsyrjala: Nuke the non-squasher based table,
Set .divider=2 for consistency,
Pack intel_cdclk_vals a bit nicer]
v5: Fix error in waveform value (Swati)
v6 (Lucas): Rebase on upstream
v7 (MattR): Drop 40.8, 81.6, and 122.4 MHz frequencies to reflect new
bspec update.
Uma Shankar [Tue, 7 Dec 2021 07:11:35 +0000 (12:41 +0530)]
drm/i915/xelpd: Add Pipe Color Lut caps to platform config
XE_LPD has 128 Lut entries for Degamma, with additional 3 entries for
extended range. It has 511 entries for gamma with additional 2 entries
for extended range.
v2: Updated lut size for 10bit gamma, added lut_tests (Ville)
Uma Shankar [Tue, 7 Dec 2021 07:11:33 +0000 (12:41 +0530)]
drm/i915/xelpd: Enable Pipe color support for D13 platform
Enable pipe color support for Display 13 platforms. Currently
limit to just 10bit gamma and later extend it for logarithmic
gamma, once the new UAPI is agreed by community and implemented
by a userspace consumer.
Remove force probe protection from ADL_P platform. Did not obsevre
warnings, errors, flickering or any visual defects while doing ordinary
tasks like browsing and editing documents in a two monitor setup.
For more info drm-tip idle run results :
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?
Tejas Upadhyay [Fri, 3 Dec 2021 07:37:20 +0000 (13:07 +0530)]
drm/i915/adl_p: Add ddc pin mapping
From VBT, ddc pin info suggests the following mapping:
VBT DRIVER
DDI TC1->ddc_pin=3 should translate to PORT_TC1->0x9
DDI TC2->ddc_pin=4 should translate to PORT_TC2->0xa
DDI TC3->ddc_pin=5 should translate to PORT_TC3->0xb
DDI TC4->ddc_pin=6 should translate to PORT_TC4->0xc
Adding pin map to facilitate this translation as we cannot use existing
icl ddc pin map due to conflict with DDI C and DDI TC1 info.
Bspec:20124
v2:
- Changed Author to Tejas Upadhyay
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Raviteja Goud Talla <ravitejax.goud.talla@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211203073720.3823371-1-ravitejax.goud.talla@intel.com
Ville Syrjälä [Wed, 24 Nov 2021 11:36:52 +0000 (13:36 +0200)]
drm/i915/fbc: Pimp the FBC debugfs output
Now that each plane tracks its own no_fbc_reason we can print that
out in debugfs, and we can also show which plane is currently
selected for FBC duty.
Ville Syrjälä [Wed, 24 Nov 2021 11:36:49 +0000 (13:36 +0200)]
drm/i915/fbc: Move plane pointer into intel_fbc_state
Currently we track the FBC plane as a pointer under intel_fbc
and also as a i9xx_plane_id under intel_fbc_state. Just store
the pointer once in the fbc state.
Ville Syrjälä [Wed, 24 Nov 2021 11:36:47 +0000 (13:36 +0200)]
drm/i915/fbc: Disable FBC fully on FIFO underrun
Currently a FIFO underrun just causes FBC to be deactivated,
and later checks then prevent it from being reactivated. We
can simpify our lives a bit by logically disabling FBC on
FIFO underruns. This avoids the funny intermediate state where
FBC is logically enabled but can't actually be activated.
Ville Syrjälä [Wed, 24 Nov 2021 11:36:45 +0000 (13:36 +0200)]
drm/i915/fbc: Allocate intel_fbc dynamically
In the future we may have more than one FBC instance on some
platforms. So let's just allocate it dynamically. This also
lets us fully hide the implementation from prying eyes.
Ville Syrjälä [Wed, 24 Nov 2021 11:36:42 +0000 (13:36 +0200)]
drm/i915/fbc: Pass i915 instead of FBC instance to FBC underrun stuff
The underrun code doesn't need to know any details about FBC, so
just pass in the whole device rather than a specific FBC instance.
We could make this a bit more fine grained by also passing in the
pipe to intel_fbc_handle_fifo_underrun_irq() and letting the FBC
code figure which FBC instance (if any) is active on said pipe.
But that seems a bit overkill for this so don't bother.
Ville Syrjälä [Wed, 24 Nov 2021 11:36:40 +0000 (13:36 +0200)]
drm/i915/fbc: Track FBC usage per-plane
In the future we may have multiple planes on the same pipe
capable of using FBC. Prepare for that by tracking FBC usage
per-plane rather than per-crtc.
Ville Syrjälä [Wed, 24 Nov 2021 11:36:39 +0000 (13:36 +0200)]
drm/i915/fbc: Pass around FBC instance instead of crtc
Pass the FBC instance instead of the crtc to a bunch of places.
We also adjust intel_fbc_post_update() to do the
intel_fbc_get_reg_params() things instead of doing it from the lower
level function (which also gets called for front buffer tracking).
Nothing in there will change during front buffer updates.
Ville Syrjälä [Wed, 24 Nov 2021 11:36:37 +0000 (13:36 +0200)]
drm/i915/fbc: Nuke more FBC state
There isn't a good reason why we'd have to cache all this
plane state stuff in the FBC state. Instead we can just
pre-calculate what FBC will really need.
Ville Syrjälä [Wed, 24 Nov 2021 11:36:35 +0000 (13:36 +0200)]
drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cache
There's no need to store all this stuff in intel_fbc_state_cache.
Just check it all against the plane/crtc states and store only
what we need. Probably more should get nuked still, but this
is a start.
So what we'll do is:
- each plane will check its own state and update its local
no_fbc_reason
- the per-plane no_fbc_reason (if any) then gets propagated
to the cache->no_fbc_reason while doing the actual update
- fbc->no_fbc_reason gets updated in the end with either
the value from the cache or directly from frontbuffer
tracking
It's still a bit messy, but should hopefuly get cleaned up
more in the future. At least now we can observe each plane's
reasons for rejecting FBC now more consistently, and we don't
have so mcuh redundant state store all over the place.
v2: store no_fbc_reason per-plane instead of per-pipe
Ville Syrjälä [Wed, 24 Nov 2021 11:36:34 +0000 (13:36 +0200)]
drm/i915/fbc: Pass whole plane state to intel_fbc_min_limit()
No reason to burden the caller with the details on how the minimum
compression limit is calculated, so just pass in the whole plane
state instead of just the cpp value.
The ilk fbc watermark computation uses intel_fbc_is_active() which
is racy since we don't know whether FBC will be enabled or not at
some point. So let's just assume it will be if both HAS_FBC()
and the modparam agree.
Ville Syrjälä [Wed, 1 Dec 2021 15:25:39 +0000 (17:25 +0200)]
drm/i915: Get rid of the 64bit PLANE_CC_VAL mmio
Let's just stick to 32bit mmio accesses so we can get rid
of the bare "uncore" reg access in display code. The register
are defined as 32bit in the spec anyway.
We could define a 64bit "de" variant I suppose, but doesn't
really make much sense just for this one case, and when we
start to use the DSB for this stuff we'd also need another
64bit variant for that. Just easier to do 32bit always.
While at it we can reorder stuff a bit so that we write the
registers in order of increasing offset (more or less).
Jani Nikula [Wed, 1 Dec 2021 13:57:11 +0000 (15:57 +0200)]
drm/i915/display: convert dp_to_i915() to a macro
Avoid looking into the guts of struct drm_i915_private in
headers. Again, converting an inline function to a macro is less than
ideal, but avoids having to pull in i915_drv.h just for the to_i915()
part.
Anshuman Gupta [Tue, 30 Nov 2021 13:20:05 +0000 (18:50 +0530)]
drm/i915/selftest: Disable IRQ for timestamp calculation
gt_pm selftest calculates engine ticks cycles and wall time
cycles by delta of respective engine elapsed TIMESTAMP and ktime
for period of 1000us.
It compares the engine ticks cycles with wall time cycles.
Disable local cpu interrupt so that interrupt handler does not
switch out the thread during measure_clocks() and prevent
miscalculation of engine tick cycles.
v2:
- nuke preempt_{disable,enable}, as disable_local_irq()
disable the preemption. (Chris)
Matt Roper [Tue, 16 Nov 2021 17:48:15 +0000 (09:48 -0800)]
drm/i915/dg2: Add Wa_14010547955
This workaround is documented a bit strangely in the bspec; it's listed
as an A0 workaround, but the description clarifies that the workaround
is implicitly handled by the hardware and what the driver really needs
to do is program a chicken bit to reenable some internal behavior.
Matt Roper [Tue, 16 Nov 2021 17:48:14 +0000 (09:48 -0800)]
drm/i915/dg2: s/DISP_STEPPING/DISPLAY_STEPPING/
Commit cd0fcf5af791 ("drm/i915: rename DISP_STEPPING->DISPLAY_STEP and
GT_STEPPING->GT_STEP") renamed all platforms' display stepping tests,
but the DG2 patches were still in-flight at that time and did not
incorporate the new naming scheme. Rename DG2's macro now for
consistency with other platforms.
Vidya Srinivas [Thu, 2 Dec 2021 11:08:36 +0000 (16:38 +0530)]
drm/i915: Add PLANE_CUS_CTL restriction in max_width
PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Take care of this restriction in max_width.
Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out.
v2: Addressed review comments from Ville. Added separate
functions for max_width - for HDR and SDR
v3: Addressed review comments from Ville. Changed names of
HDR and SDR max_width functions to icl_hdr_plane_max_width
and icl_sdr_plane_max_width
Jani Nikula [Wed, 1 Dec 2021 13:57:03 +0000 (15:57 +0200)]
drm/i915/display: add intel_crtc_wait_for_next_vblank() and use it
intel_wait_for_vblank() goes through a pipe to crtc lookup, while in
most cases we already have the crtc available. Avoid the extra lookups
by adding an intel_crtc based helper.
Dave Airlie [Thu, 2 Dec 2021 00:28:17 +0000 (10:28 +1000)]
Merge tag 'drm-intel-next-2021-11-30' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
drm/i915 feature pull for v5.17:
Features and functionality:
- Implement per-lane DP drive settings for ICL+ (Ville)
- Enable runtime pm autosuspend by default (Tilak Tangudu)
- ADL-P DSI support (Vandita)
- Add support for pipe C and D DMC firmware (Anusha)
- Implement (near)atomic gamma LUT updates via vblank workers (Ville)
- Split plane updates to noarm+arm phases (Ville)
- Remove the CCS FB stride restrictions on ADL-P (Imre)
- Add PSR selective fetch support for biplanar formats (Jouni)
- Add support for display audio codec keepalive (Kai)
- VRR platform support for display 11 (Manasi)
Refactoring and cleanups:
- FBC refactoring and cleanups preparing for multiple FBC instances (Ville)
- PCH modeset refactoring, move to its own file (Ville)
- Refactor and simplify handling of modifiers (Imre)
- PXP cleanups (Ville)
- Display header and include refactoring (Jani)
- Some register macro cleanups (Ville)
- Refactor DP HDMI DFP limit code (Ville)
Fixes:
- Disable DSB usage for now due to incorrect gamma LUT updates (Ville)
- Check async flip state of every crtc and plane only once (José)
- Fix DPT FB suspend/resume (Imre)
- Fix black screen on reboot due to disabled DP++ TMDS output buffers (Ville)
- Don't request GMBUS to generate irqs when called while irqs are off (Ville)
- Fix type1 DVI DP dual mode adapter heuristics for modern platforms (Ville)
- Fix fix integer overflow in 128b/132b data rate calculation (Jani)
- Fix bigjoiner state readout (Ville)
- Build fix for non-x86 (Siva)
- PSR fixes (José, Jouni, Ville)
- Disable ADL-P underrun recovery (José)
- Fix DP link parameter usage before valid DPCD (Imre)
- VRR vblank and frame counter fixes (Ville)
- Fix fastsets on TypeC ports following a non-blocking modeset (Imre)
- Compiler warning fixes (Nathan Chancellor)
- Fix DSI HS mode commands (William Tseng)
- Error return fixes (Dan Carpenter)
- Update memory bandwidth calculations (Radhakrishna)
- Implement WM0 cursor WA for DG2 (Stan)
- Fix DSI Double pixelclock on read-back for dual-link panels (Hans de Goede)
- HDMI 2.1 PCON FRL configuration fixes (Ankit)
Merges:
- DP link training delay helpers, via topic branch (Jani)
- Backmerge drm-next (Jani)
Lyude Paul [Tue, 30 Nov 2021 21:29:09 +0000 (16:29 -0500)]
drm/i915/dp: Perform 30ms delay after source OUI write
While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.
Following some investigation Ville Syrjälä did through the docs they have
available to them, they discovered that there's actually supposed to be a
30ms wait after writing the source OUI before we begin setting up the rest
of the backlight interface.
This seems to be correct, as adding this 30ms delay seems to have
completely fixed the probing issues I was previously seeing. So - let's
start performing a 30ms wait after writing the OUI, which we do in a manner
similar to how we keep track of PPS delays (e.g. record the timestamp of
the OUI write, and then wait for however many ms are left since that
timestamp right before we interact with the backlight) in order to avoid
waiting any longer then we need to. As well, this also avoids us performing
this delay on systems where we don't end up using the HDR backlight
interface.
V3:
* Move last_oui_write into intel_dp
V2:
* Move panel delays into intel_pps
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211130212912.212044-1-lyude@redhat.com
Imre Deak [Thu, 25 Nov 2021 17:16:03 +0000 (19:16 +0200)]
drm/i915: Fix DPT suspend/resume on !HAS_DISPLAY platforms
The drm.mode_config state is not initialized in case of !HAS_DISPLAY
so taking the fb_lock and iterating the fb list won't work on those
platforms. Skip the suspend/resume with an explicit check for this.
Fixes: 9755f055f512 ("drm/i915: Restore memory mapping for DPT FBs across system suspend/resume") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211125171603.1775179-1-imre.deak@intel.com
drm: Fix build error caused by missing drm_nomodeset.o
The patch for commit 6a2d2ddf2c34 ("drm: Move nomodeset kernel parameter
to the DRM subsystem") was generated with config 'diff.noprefix true'.
But later was applied using 'cat nomodeset.mbox | dim apply-branch' on a
machine with 'diff.noprefix false'. And command 'git am --scissors -3' as
used by the dim tool doesn't handle that case well, since the 3-way merge
wrongly resolves the path for new file drivers/gpu/drm/drm_nomodeset.c as
gpu/drm/drm_nomodeset.c instead.
It led to the following build error as reported by the kernel test robot:
make[4]: *** No rule to make target 'drivers/gpu/drm/drm_nomodeset.o', needed by 'drivers/gpu/drm/built-in.a'.
The message printed when nomodeset is present in the kernel command line
makes it look as if the parameter must never be used and it's a bad idea.
But there are valid reasons to use this parameter and the message should
not imply otherwise. Change the text to be more accurate and restrained.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112133230.1595307-7-javierm@redhat.com
This relationship was only for historical reasons and the nomodeset option
should be available even on platforms that don't enable CONFIG_VGA_CONSOLE.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112133230.1595307-5-javierm@redhat.com
drm: Move nomodeset kernel parameter to the DRM subsystem
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that are making use of it.
Let's move the vgacon_text_force() function and related logic to the DRM
subsystem. While doing that, rename it to drm_firmware_drivers_only() and
make it return true if "nomodeset" was used and false otherwise. This is
a better description of the condition that the drivers are testing for.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211112133230.1595307-4-javierm@redhat.com
drm: Don't print messages if drivers are disabled due nomodeset
The nomodeset kernel parameter handler already prints a message that the
DRM drivers will be disabled, so there's no need for drivers to do that.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112133230.1595307-2-javierm@redhat.com
Martyn Welch [Thu, 25 Nov 2021 10:53:02 +0000 (10:53 +0000)]
drm/bridge: megachips: Ensure both bridges are probed before registration
In the configuration used by the b850v3, the STDP2690 is used to read EDID
data whilst it's the STDP4028 which can detect when monitors are connected.
This can result in problems at boot with monitors connected when the
STDP4028 is probed first, a monitor is detected and an attempt is made to
read the EDID data before the STDP2690 has probed:
Dan Carpenter [Wed, 24 Nov 2021 14:52:19 +0000 (17:52 +0300)]
drm/bridge: anx7625: fix an error code in anx7625_register_audio()
This code accidentally returns IS_ERR(), which is 1, instead of
propagating the negative error code. The caller doesn't check for
errors so it doesn't affect run time at all.
projects / people / jgross / linux.git / log