Lucas De Marchi [Tue, 28 Jun 2022 19:10:16 +0000 (12:10 -0700)]
iosys-map: Add per-word write
Like was done for read, provide the equivalent for write. Even if
current users are not in the hot path, this should future-proof it.
v2:
- Remove default from _Generic() - callers wanting to write more
than u64 should use iosys_map_memcpy_to()
- Add WRITE_ONCE() cases dereferencing the pointer when using system
memory
v3:
- Fix precedence issue when casting inside WRITE_ONCE(). By not using ()
around vaddr__ the offset was not part of the cast, but rather added
to it, producing a wrong address
- Remove compiletime_assert() as WRITE_ONCE() already contains it
Lucas De Marchi [Tue, 28 Jun 2022 19:10:15 +0000 (12:10 -0700)]
iosys-map: Add per-word read
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.
Employ a similar trick as __seqprop() by using _Generic() to generate
only the specific call based on a type-compatible variable.
For a pariticular i915 workload producing GPU context switches,
__get_engine_usage_record() is particularly hot since the engine usage
is read from device local memory with dgfx, possibly multiple times
since it's racy. Test execution time for this test shows a ~12.5%
improvement with DG2:
Before:
nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07;
median = 9.52548e+06; var = 526149;
After:
nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06;
median = 8.33955e+06; var = 333113;
Other things attempted that didn't prove very useful:
1) Change the _Generic() on x86 to just dereference the memory address
2) Change __get_engine_usage_record() to do just 1 read per loop,
comparing with the previous value read
3) Change __get_engine_usage_record() to access the fields directly as it
was before the conversion to iosys-map
(3) did gave a small improvement (~3%), but doesn't seem to scale well
to other similar cases in the driver.
Additional test by Chris Wilson using gem_create from igt with some
changes to track object creation time. This happens to accidentally
stress this code path:
Pre iosys_map conversion of engine busyness:
lmem0: Creating 262144 4KiB objects took 59274.2ms
Unpatched:
lmem0: Creating 262144 4KiB objects took 108830.2ms
With readl (this patch):
lmem0: Creating 262144 4KiB objects took 61348.6ms
s/readl/READ_ONCE/
lmem0: Creating 262144 4KiB objects took 61333.2ms
So we do take a little bit more time than before the conversion, but
that is due to other factors: bringing the READ_ONCE back would be as
good as just doing this conversion.
v2:
- Remove default from _Generic() - callers wanting to read more
than u64 should use iosys_map_memcpy_from()
- Add READ_ONCE() cases dereferencing the pointer when using system
memory
v3:
- Fix precedence issue when casting inside READ_ONCE(). By not using ()
around vaddr__ the offset was not part of the cast, but rather added
to it, producing a wrong address
- Remove compiletime_assert() as READ_ONCE() already contains it
Marek Vasut [Tue, 28 Jun 2022 17:41:52 +0000 (19:41 +0200)]
drm: lcdif: Add support for i.MX8MP LCDIF variant
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
completely different from the LCDIFv3 found in i.MX23 in that it has
a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space.
Add a separate driver which is really a fork of MXSFB driver with the
i.MX8MP LCDIF variant handling filled in.
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Tested-by: Martyn Welch <martyn.welch@collabora.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stefan Agner <stefan@agner.ch> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220628174152.167284-2-marex@denx.de
Marek Vasut [Tue, 28 Jun 2022 17:41:51 +0000 (19:41 +0200)]
dt-bindings: lcdif: Add compatible for i.MX8MP
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3
and is completely different from the LCDIFv3 found in i.MX23 in that it
has a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space. However,
except for the complete bit reshuffling, this is still LCDIF and it still
works like one.
Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Peng Fan <peng.fan@nxp.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robby Cai <robby.cai@nxp.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stefan Agner <stefan@agner.ch> Cc: devicetree@vger.kernel.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220628174152.167284-1-marex@denx.de
Marek Vasut [Fri, 24 Jun 2022 18:19:02 +0000 (20:19 +0200)]
drm/bridge: tc358767: Do not cache dsi_lanes twice
The DSI lane count can be accessed via the dsi device pointer,
make use of that. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624181902.151959-1-marex@denx.de
Dave Stevenson [Mon, 13 Jun 2022 14:48:00 +0000 (16:48 +0200)]
drm/vc4: hdmi: Move pixel doubling from Pixelvalve to HDMI block
With the change to 2 pixels/clock, the pixel doubling in the PV
results in doubling each pair of pixels, ie ABABCDCD instead of AABBCCDD.
Move the pixel doubling to the HDMI block, however this means
that DBLCLK modes now fall foul of requiring even values for
all the horizontal timing parameters.
As both 480i and 576i fail this, attempt to fix up DBLCLK modes
that have odd timings values.
Dom Cobley [Mon, 13 Jun 2022 14:47:58 +0000 (16:47 +0200)]
drm/vc4: hdmi: Force modeset when bpc or format changes
Whenever the maximum BPC is changed, vc4_hdmi_encoder_compute_config()
might pick up a different BPC or format depending on the display
capabilities.
That change will have a number of side effects, including the clock
rates and whether the scrambling is enabled.
However, only drm_crtc_state.connectors_changed will be set to true,
since that properly only affects the connector.
This means that while drm_atomic_crtc_needs_modeset() will return true,
and thus drm_atomic_helper_commit_modeset_enables() will call our
encoder atomic_enable() hook, mode_changed will be false.
So crtc_set_mode() will not call our encoder .atomic_mode_set() hook. We
use this hook in vc4 to set the vc4_hdmi_connector_state.output_bpc (and
output_format), and will then reuse the value in .atomic_enable() to select
whether or not scrambling should be enabled.
However, since our clock rate is pre-computed during .atomic_check(), we
end up with the clocks properly configured, but the scrambling disabled,
leading to a blank screen.
Let's set mode_changed to true in our HDMI driver to force the update of
output_bpc, and thus prevent the issue entirely.
Increase the number of post-sync blanking lines on odd fields instead of
decreasing it on even fields. This makes the total number of lines
properly match the modelines.
Additionally fix the value of PV_VCONTROL_ODD_DELAY, which did not take
pixels_per_clock into account, causing some displays to invert the
fields when driven by bcm2711.
Dave Stevenson [Mon, 13 Jun 2022 14:47:55 +0000 (16:47 +0200)]
drm/vc4: hdmi: Add MISC_CONTROL register for vc4
The MISC_CONTROL register allows configuration of pixel repetition
for pixel doubling in the HDMI block instead of PixelValve.
It was already defined for vc5, so add it for vc4.
Dave Stevenson [Mon, 13 Jun 2022 14:47:54 +0000 (16:47 +0200)]
drm/vc4: hdmi: Add HDMI format detection registers to register list
The block can detect what the incoming image timings are for
debug purposes. Add them to the list of registers understood
by the driver to allow easy dumping of the values.
This bit ensures data island packets are never generated when disallowed
by HDCP. As no Pi boards support HDCP this is providing an unnecessary
restriction
Dom Cobley [Mon, 13 Jun 2022 14:47:52 +0000 (16:47 +0200)]
drm/vc4: hdmi: Skip writes to disabled packet RAM
This path actually occurs when audio is started during a hdmi mode set.
As the data will be written by vc4_hdmi_set_infoframes when packet RAM
is enabled again, don't treat as an error
Dom Cobley [Mon, 13 Jun 2022 14:47:51 +0000 (16:47 +0200)]
drm/vc4: hdmi: Stop checking for enabled output in audio
The current HDMI driver, in vc4_hdmi_audio_can_stream() checks whether
the display output is enabled.
This has been there in one form or the other since the introduction of
the audio support in the VC4 HDMI driver in commit b5780ae2a73c
("drm/vc4: Add HDMI audio support"), but no justification for this check
is in the commit message, or in the discussions around the patches.
One can only assume this was done to prevent a user from playing audio
on the ALSA soundcard when the monitor doesn't support it.
However, this is causing some issues. Indeed, Kodi, for example, was
hitting some errors if it was streaming audio during a modeset. With the
theory above, it does make sense, but the display and audio threads are
typically completely different processes with no opportunity to
synchronise which makes it hard to workaround.
Removing that check also doesn't seem to cause any trouble, so let's
just remove it.
Dave Stevenson [Mon, 13 Jun 2022 14:47:50 +0000 (16:47 +0200)]
drm/vc4: hdmi: Move HDMI reset to pm_resume
The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain
attached to the HDMI block, handled in Linux through runtime_pm.
That power domain is shared with the VEC block, so even if we put our
runtime_pm reference in the HDMI driver it would keep being on. If the
VEC is disabled though, the power domain would be disabled and we would
lose any initialization done in our bind implementation.
That initialization involves calling the reset function and initializing
the CEC registers.
Let's move the initialization to our runtime_resume implementation so
that we initialize everything properly if we ever need to.
Dave Stevenson [Mon, 13 Jun 2022 14:47:49 +0000 (16:47 +0200)]
drm/vc4: hdmi: Switch to pm_runtime_status_suspended
If the controller isn't clocked or its domain powered up, the register
accesses will either stall the CPU or return garbage, respectively.
Thus, we had a warning in our register access function to complain when
that kind of risky accesses were performed.
In order to check the runtime_pm power state, we were using
pm_runtime_active(), but it turns out that it will become active only
once the runtime_resume hook has been executed.
This prevents us from doing any WARN-free register access in our
runtime_resume() implementation, while this is valid.
Let's switch to pm_runtime_status_suspended() instead.
Fixes: b9094a1748e4 ("drm/vc4: hdmi: Warn if we access the controller while disabled") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-23-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Mon, 13 Jun 2022 14:47:48 +0000 (16:47 +0200)]
drm/vc4: hdmi: Reset HDMI MISC_CONTROL register
The HDMI block can repeat pixels for double clocked modes,
and the firmware is now configuring the block to do this as
the PV is doing it incorrectly when at 2pixels/clock.
If the kernel doesn't reset it then we end up with strange
modes.
Phil Elwell [Mon, 13 Jun 2022 14:47:44 +0000 (16:47 +0200)]
drm/vc4: hdmi: Disable audio if dmas property is present but empty
The dmas property is used to hold the dmaengine channel used for audio
output.
Older device trees were missing that property, so if it's not there we
disable the audio output entirely.
However, some overlays have set an empty value to that property, mostly
to workaround the fact that overlays cannot remove a property. Let's add
a test for that case and if it's empty, let's disable it as well.
Dave Stevenson [Mon, 13 Jun 2022 14:47:43 +0000 (16:47 +0200)]
drm/vc4: dsi: Add correct stop condition to vc4_dsi_encoder_disable iteration
vc4_dsi_encoder_disable is partially an open coded version of
drm_bridge_chain_disable, but it missed a termination condition
in the loop for ->disable which meant that no post_disable
calls were made.
Dave Stevenson [Mon, 13 Jun 2022 14:47:42 +0000 (16:47 +0200)]
drm/vc4: dsi: Fix dsi0 interrupt support
DSI0 seemingly had very little or no testing as a load of
the register mappings were incorrect/missing, so host
transfers always timed out due to enabling/checking incorrect
bits in the interrupt enable and status registers.
Dave Stevenson [Mon, 13 Jun 2022 14:47:41 +0000 (16:47 +0200)]
drm/vc4: dsi: Register dsi0 as the correct vc4 encoder type
vc4_dsi was registering both dsi0 and dsi1 as VC4_ENCODER_TYPE_DSI1
which seemed to work OK for a single DSI display, but fails
if there are two DSI displays connected.
Dave Stevenson [Mon, 13 Jun 2022 14:47:40 +0000 (16:47 +0200)]
drm/vc4: dsi: Correct pixel order for DSI0
For slightly unknown reasons, dsi0 takes a different pixel format
to dsi1, and that has to be set in the pixel valve.
Amend the setup accordingly.
Fixes: a4929aa7a5a7 ("drm/vc4: Add support for feeding DSI encoders from the pixel valve.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-14-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Mon, 13 Jun 2022 14:47:39 +0000 (16:47 +0200)]
drm/vc4: dsi: Correct DSI divider calculations
The divider calculations tried to find the divider just faster than the
clock requested. However if it required a divider of 7 then the for loop
aborted without handling the "error" case, and could end up with a clock
lower than requested.
The integer divider from parent PLL to DSI clock is also capable of
going up to /255, not just /7 that the driver was trying. This allows
for slower link frequencies on the DSI bus where the resolution permits.
Correct the loop so that we always have a clock greater than requested,
and covering the whole range of dividers.
Fixes: 98772f8ef2f2 ("drm/vc4: Adjust modes in DSI to work around the integer PLL divider.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-13-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Mon, 13 Jun 2022 14:47:32 +0000 (16:47 +0200)]
drm/vc4: plane: Fix margin calculations for the right/bottom edges
The current plane margin calculation code clips the right and bottom
edges of the range based using the left and top margins.
This is obviously wrong, so let's fix it.
Fixes: 188f608deb8f ("drm/vc4: Take margin setup into account when updating planes") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-6-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Mon, 13 Jun 2022 14:47:30 +0000 (16:47 +0200)]
drm/vc4: kms: Use maximum FIFO load for the HVS clock rate
The core clock computation takes into account both the load due to the
input (ie, planes) and its output (ie, encoders).
However, while the input load needs to consider all the planes, and thus
sum all of their associated loads, the output happens mostly in
parallel.
Therefore, we need to consider only the maximum of all the output loads,
and not the sum like we were doing. This resulted in a clock rate way
too high which could be discarded for being too high by the clock
framework.
Since recent changes, the clock framework will even downright reject it,
leading to a core clock being too low for its current needs.
Maxime Ripard [Mon, 13 Jun 2022 14:47:29 +0000 (16:47 +0200)]
drm/vc4: kms: Warn if clk_set_min_rate fails
We currently ignore the clk_set_min_rate return code assuming it would
succeed. However, it can fail if we ask for a rate higher than the
current maximum for example.
Since we can't fail in atomic_commit, at least warn on failure.
Dave Stevenson [Mon, 13 Jun 2022 14:47:28 +0000 (16:47 +0200)]
drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component
vc4_drv isn't necessarily under the /soc node in DT as it is a
virtual device, but it is the one that does the allocations.
The DMA addresses are consumed by primarily the HVS or V3D, and
those require VideoCore cache alias address mapping, and so will be
under /soc.
During probe find the a suitable device node for HVS or V3D,
and adopt the DMA configuration of that node.
Marek Vasut [Tue, 28 Jun 2022 00:34:07 +0000 (02:34 +0200)]
drm/doc: Fix comment typo
Replace apprpriately with appropriately.
Fixes: 66b593b02c1a5 ("drm/doc: Polish plane composition property docs") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Sean Paul <seanpaul@chromium.org> Cc: Simon Ser <contact@emersion.fr> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20220628003407.77765-1-marex@denx.de
Yannick Fertre [Fri, 3 Jun 2022 13:46:54 +0000 (15:46 +0200)]
drm/stm: ltdc: update hardware error management
The latest hardware version (0x40100) supports a hardware threshold
register (aka FUTR) to trigger a fifo underrun interrupt.
A software threshold has been implemented for other hardware versions.
The threshold is set to 128 by default.
José Expósito [Mon, 20 Jun 2022 16:06:40 +0000 (18:06 +0200)]
drm/doc: Add KUnit documentation
Explain how to run the KUnit tests present in the DRM subsystem and
clarify why the UML-only options were not added to the configuration
file present in drivers/gpu/drm/.kunitconfig [1] [2].
José Expósito [Mon, 20 Jun 2022 16:06:39 +0000 (18:06 +0200)]
drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()
Test the conversion from XRGB8888 to RGB332.
What is tested?
- Different values for the X in XRGB8888 to make sure it is ignored
- Different clip values: Single pixel and full and partial buffer
- Well known colors: White, black, red, green, blue, magenta, yellow
and cyan
- Other colors: Randomly picked
- Destination pitch
How to run the tests?
$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests \
--kconfig_add CONFIG_VIRTIO_UML=y \
--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
drm/simple-kms: Use drm_atomic_helper_check_crtc_state()
Simple-KMS helpers guarantee that the CRTC and plane enable
flags are synchronized. Implement this with atomic helpers
drm_atomic_helper_check_crtc_state() on the CRTC side, and
drm_atomic_helper_check_plane_state() on the plane side.
Add drm_atomic_helper_check_crtc_state(), which contains tests common
to many CRTCs. The first added test verifies that an enabled CRTC has
at least one enabled primary plane.
Clip memory range to screen-buffer size to avoid out-of-bounds access
in fbdev deferred I/O's damage handling.
Fbdev's deferred I/O can only track pages. From the range of pages, the
damage handler computes the clipping rectangle for the display update.
If the fbdev screen buffer ends near the beginning of a page, that page
could contain more scanlines. The damage handler would then track these
non-existing scanlines as dirty and provoke an out-of-bounds access
during the screen update. Hence, clip the maximum memory range to the
size of the screen buffer.
While at it, rename the variables min/max to min_off/max_off in
drm_fb_helper_deferred_io(). This avoids confusion with the macros of
the same name.
Reported-by: Nuno Gonçalves <nunojpg@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Nuno Gonçalves <nunojpg@gmail.com> Fixes: 0252090bb2a7 ("drm/fb-helper: Calculate damaged area in separate helper") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: <stable@vger.kernel.org> # v5.18+ Link: https://patchwork.freedesktop.org/patch/msgid/20220621104617.8817-1-tzimmermann@suse.de
Alex Williamson [Wed, 22 Jun 2022 14:01:34 +0000 (16:01 +0200)]
vfio/pci: Remove console drivers
Console drivers can create conflicts with PCI resources resulting in
userspace getting mmap failures to memory BARs. This is especially
evident when trying to re-use the system primary console for userspace
drivers. Use the aperture helpers to remove these conflicts.
Implement DRM's aperture helpers under video/ for sharing with other
sub-systems. Remove DRM-isms from the interface. The helpers track
the ownership of framebuffer apertures and provide hand-over from
firmware, such as EFI and VESA, to native graphics drivers.
Other subsystems, such as fbdev and vfio, also have to maintain ownership
of framebuffer apertures. Moving DRM's aperture helpers to a more public
location allows all subsystems to interact with each other and share a
common implementation.
The aperture helpers are selected by the various firmware drivers within
DRM and fbdev, and the VGA text-console driver.
The original DRM interface is kept in place for use by DRM drivers.
v3:
* prefix all interfaces with aperture_ (Javier)
* rework and simplify documentation (Javier)
* rename struct dev_aperture to struct aperture_range
* rebase onto latest DRM
* update MAINTAINERS entry
There will be more DRM drivers for firmware-provided framebuffers. Use
the existing entry for simpledrm instead of adding a new one for each
driver. Also add DRM's aperture helpers, which are part of the driver's
infrastructure.
Jocelyn Falempe [Wed, 22 Jun 2022 12:48:15 +0000 (14:48 +0200)]
drm/ast: Fix black screen when getting out of suspend
With an AST2600, the screen is garbage when going out of suspend.
This is because color settings are lost, and not restored on resume.
Force the color settings on DPMS_ON, to make sure the settings are correct.
I didn't write this code, it comes from the out-of-tree aspeed driver v1.13
https://www.aspeedtech.com/support_driver/
Miaoqian Lin [Wed, 25 May 2022 11:54:11 +0000 (15:54 +0400)]
drm/mcde: Fix refcount leak in mcde_dsi_bind
Every iteration of for_each_available_child_of_node() decrements
the reference counter of the previous node. There is no decrement
when break out from the loop and results in refcount leak.
Add missing of_node_put() to fix this.
Joel Selvaraj [Wed, 1 Jun 2022 08:24:10 +0000 (13:54 +0530)]
drm/panel: introduce ebbg,ft8719 panel
Add DRM panel driver for EBBG FT8719 6.18" 2246x1080 DSI video mode
panel, which can be found on some Xiaomi Poco F1 phones. The panel's
backlight is managed through QCOM WLED driver.
A helper macro that can be used to simplify sending DCS commands.
It is useful in scenarios like panel initialization which can sometimes
involve sending lot of DCS commands.
Joel Selvaraj [Wed, 1 Jun 2022 08:24:08 +0000 (13:54 +0530)]
dt-bindings: display: Add bindings for EBBG FT8719
Add bindings for the EBBG FT8719 6.18" 2246x1080 DSI video mode panel,
which can be found on some Xiaomi Poco F1 phones. The backlight is
managed through the QCOM WLED driver.
Jiasheng Jiang [Thu, 2 Jun 2022 10:34:01 +0000 (18:34 +0800)]
drm: bridge: adv7511: Add check for mipi_dsi_driver_register
As mipi_dsi_driver_register could return error if fails,
it should be better to check the return value and return error
if fails.
Moreover, if i2c_add_driver fails, mipi_dsi_driver_register
should be reverted.
Stephen Kitt [Tue, 7 Jun 2022 18:10:22 +0000 (20:10 +0200)]
drm/bridge: parade-ps8622: Use backlight helper
backlight_properties.fb_blank is deprecated. The states it represents
are handled by other properties; but instead of accessing those
properties directly, drivers should use the helpers provided by
backlight.h.
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt <steve@sk2.org> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220607181022.1119546-1-steve@sk2.org
Stephen Kitt [Thu, 16 Jun 2022 17:08:21 +0000 (19:08 +0200)]
drm: shmobile: Use backlight helper
This started with work on the removal of backlight_properties'
deprecated fb_blank field, much of which can be taken care of by using
helper functions provided by backlight.h instead of directly accessing
fields in backlight_properties. This patch series doesn't involve
fb_blank, but it still seems useful to use helper functions where
appropriate.
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt <steve@sk2.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220616170821.1348169-1-steve@sk2.org
Stephen Kitt [Thu, 16 Jun 2022 17:23:13 +0000 (19:23 +0200)]
drm/panel: panel-asus-z00t-tm5p5-n35596: Use backlight helper
backlight_properties.fb_blank is deprecated. The states it represents
are handled by other properties; but instead of accessing those
properties directly, drivers should use the helpers provided by
backlight.h.
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt <steve@sk2.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220616172316.1355133-2-steve@sk2.org
Stephen Kitt [Thu, 16 Jun 2022 17:23:14 +0000 (19:23 +0200)]
drm/panel: panel-dsi-cm: Use backlight helpers
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Instead of setting the power state by manually updating fields in
struct backlight_properties, use backlight_enable() and
backlight_disable(). These also call backlight_update_status() so the
separate call is no longer needed.
Signed-off-by: Stephen Kitt <steve@sk2.org> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220616172316.1355133-3-steve@sk2.org
Stephen Kitt [Thu, 16 Jun 2022 17:23:15 +0000 (19:23 +0200)]
drm/panel: sony-acx565akm: Use backlight helpers
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Instead of manually checking the power state in struct
backlight_properties, use backlight_is_blank().
While we're at it, drop .fb_blank from the initialisation function; it
is deprecated, and this helps make progress towards enabling its
removal. This change makes no functional difference since
FB_BLANK_UNBLANK is the default value.
Signed-off-by: Stephen Kitt <steve@sk2.org> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220616172316.1355133-4-steve@sk2.org
Alexander Stein [Tue, 21 Jun 2022 07:21:18 +0000 (09:21 +0200)]
drm/panel: panel-simple: Add dev_err_probe if backlight could not be found
If the backlight node is not enabled, this (silently) returns with
-EPROBE_DEFER. /sys/kernel/debug/devices_deferred also shows nothing
helpful:
$ cat /sys/kernel/debug/devices_deferred
display
With this patch, there is a helpful hint:
$ cat /sys/kernel/debug/devices_deferred
display panel-simple: Could not find backlight
Jiang Jian [Tue, 21 Jun 2022 13:31:07 +0000 (21:31 +0800)]
drm/pl111: drop unexpected word "the" in the comments
there is an unexpected word "the" in the comments that need to be dropped
file: drivers/gpu/drm/pl111/pl111_display.c
line: 251
* Note that the the ARM hardware's format reader takes 'r' from
changed to
* Note that the the ARM hardware's format reader takes 'r' from
Jiang Jian [Tue, 21 Jun 2022 14:01:51 +0000 (22:01 +0800)]
drm/panel: nt35510: Remove duplicate 'the' in two places.
file: ./drivers/gpu/drm/panel/panel-novatek-nt35510.c
line: 193,214,253
* amplification for the the step-up circuit:
changed to
* amplification for the step-up circuit:
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr> Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/alpine.DEB.2.22.394.2206121300120.3447@hadrien
Yang Li [Mon, 13 Jun 2022 01:26:58 +0000 (09:26 +0800)]
drm: Remove unnecessary print function dev_err()
The print function dev_err() is redundant because platform_get_irq()
already prints an error.
Eliminate the follow coccicheck warning:
./drivers/gpu/drm/logicvc/logicvc_drm.c:352:2-9: line 352 is redundant
because platform_get_irq() already prints an error
Dan Carpenter [Tue, 14 Jun 2022 12:08:53 +0000 (15:08 +0300)]
drm: logicvc: fix error code in logicvc_layer_init()
Return -EINVAL if logicvc_layer_formats_lookup() fails. Don't return
success.
Fixes: 03b72aa1419a ("drm: Add support for the LogiCVC display controller") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/Yqh6VdNiDvJYMOQ+@kili
Dan Carpenter [Tue, 14 Jun 2022 12:08:25 +0000 (15:08 +0300)]
drm: logicvc: Fix uninitialized variable in probe
The "regmap" is supposed to be initialized to NULL but it's used
without being initialized.
Fixes: 03b72aa1419a ("drm: Add support for the LogiCVC display controller") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/Yqh6OfSiPFuVrGo4@kili
drm/hyperv-drm: Include framebuffer and EDID headers
Fix a number of compile errors by including the correct header
files. Examples are shown below.
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_blit_to_vram_rect':
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:25:48: error: invalid use of undefined type 'struct drm_framebuffer'
25 | struct hyperv_drm_device *hv = to_hv(fb->dev);
| ^~
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_connector_get_modes':
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:59:17: error: implicit declaration of function 'drm_add_modes_noedid' [-Werror=implicit-function-declaration]
59 | count = drm_add_modes_noedid(connector,
| ^~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:62:9: error: implicit declaration of function 'drm_set_preferred_mode'; did you mean 'drm_mm_reserve_node'? [-Werror=implicit-function-declaration]
62 | drm_set_preferred_mode(connector, hv->preferred_width,
| ^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: aebd89482ab4 ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Fixes: 6f5734c32c2c ("drm: Drop drm_framebuffer.h from drm_crtc.h") Fixes: b6a276d7208a ("drm: Drop drm_edid.h from drm_crtc.h") Cc: Deepak Rawat <drawat.floss@gmail.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: linux-hyperv@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.14+ Acked-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220622083413.12573-1-tzimmermann@suse.de
Jiang Jian [Tue, 21 Jun 2022 13:51:40 +0000 (21:51 +0800)]
GPU: drm: drop unexpected word "the" in the comments
there is an unexpected word "the" in the comments that need to be dropped
file: drivers/gpu/drm/drm_ioctl.c
line: 86
* means the the unique name for the master node just opening is _not_ filled
changed to
* means the unique name for the master node just opening is _not_ filled
Jiang Jian [Tue, 21 Jun 2022 13:44:01 +0000 (21:44 +0800)]
drm: panel-orientation-quirks: drop unexpected word "the" in the comments
there is an unexpected word "the" in the comments that need to be dropped
file: drivers/gpu/drm/drm_panel_orientation_quirks.c
line: 196
* GPD Pocket, note that the the DMI data is less generic then
changed to
* GPD Pocket, note that the DMI data is less generic then
Jiang Jian [Tue, 21 Jun 2022 13:05:50 +0000 (21:05 +0800)]
drm/vc4: drop unexpected word "the" in the comments
there is an unexpected word "the" in the comments that need to be dropped
file: drivers/gpu/drm/vc4/vc4_regs.h
line: 267
/* Set when the the downstream tries to read from the display FIFO
changed to
/* Set when the downstream tries to read from the display FIFO
Jiang Jian [Tue, 21 Jun 2022 13:02:10 +0000 (21:02 +0800)]
drm/prime: drop unexpected word "the" in the comments
there is an unexpected word "the" in the comments that need to be dropped
file: drivers/gpu/drm/drm_prime.c
line: 842
* of the the buffer described by the provided sg_table.
changed to
* of the buffer described by the provided sg_table.
Jiang Jian [Tue, 21 Jun 2022 13:39:20 +0000 (21:39 +0800)]
drm/nouveau/mmu: drop unexpected word "the" in the comments
there is an unexpected word "the" in the comments that need to be dropped
file: drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
line: 1051
* have the the deepest nesting of page tables.
changed to
* have the deepest nesting of page tables.
Lyude Paul [Thu, 2 Jun 2022 20:17:55 +0000 (16:17 -0400)]
drm/display/dp_mst: Don't validate port refs in drm_dp_check_and_send_link_address()
Drive-by cleanup, we don't need to validate the port references here as we
already previously went through the effort of refactoring things such that
we're guaranteed to be able to access ->mstb and ->port safely from
drm_dp_check_and_send_link_address(), since the only two places in the
codebase that drop an MST reference in such a way that it would remove it
from the topology are both protected under probe_lock.
Jiang Jian [Tue, 21 Jun 2022 19:00:55 +0000 (03:00 +0800)]
drm/display: Remove duplicate 'the' in two places.
there is an unexpected word "the" in the comments that need to be dropped
file: drivers/gpu/drm/display/drm_dp_helper.c
line: 1600
* Doesn't account the the "MOT" bit, and instead assumes each
changed to
* Doesn't account the "MOT" bit, and instead assumes eac
Douglas Anderson [Tue, 14 Jun 2022 21:54:18 +0000 (14:54 -0700)]
drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux
This implements the callback added by the patch ("drm/dp: Add
wait_hpd_asserted() callback to struct drm_dp_aux").
With this change and all the two "DP AUX Endpoint" drivers changed to
use wait_hpd_asserted(), we no longer need to have an long delay in
the AUX transfer function. It's up to the panel code to make sure that
the panel is powered now. If someone tried to call the aux transfer
function without making sure the panel is powered we'll just get a
normal transfer failure.
We'll still keep the wait for HPD in the pre_enable() function. Though
it's probably not actually needed there, this driver is used in the
old mode (pre-DP AUX Endpoints) and it may be important for those
cases. If nothing else, it shouldn't cause any big problems.
NOTE: When handling the timeout for HPD we start the timer _after_
we've runtime resumed the device. This is definitely important for the
panel on my homestar which comes up 170 ms after we start timing (the
panel specifies 200 ms max). It's a little unclear how much of this
extra time is due to some internal state machine in the parade
firmware vs. debouncing but it seems to work for the two test cases I
have to do it this way.
Douglas Anderson [Tue, 14 Jun 2022 21:54:17 +0000 (14:54 -0700)]
drm/panel: atna33xc20: Take advantage of wait_hpd_asserted() in struct drm_dp_aux
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will let us take away the
waiting in the AUX transfer functions of the eDP controller drivers.
Douglas Anderson [Tue, 14 Jun 2022 21:54:16 +0000 (14:54 -0700)]
drm/panel-edp: Take advantage of wait_hpd_asserted() in struct drm_dp_aux
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will allow us to get more
accurate delays also lets us take away the waiting in the AUX transfer
functions of the eDP controller drivers.
projects / kernel.git / log