Back in the day, we used to need to list the exact panel in dts for
eDP panels. This led to all sorts of problems including a large number
of cases where people listed a bogus panel in their device tree
because of the needs of second sourcing (and third sourcing, and
fourth sourcing, ...). Back when we needed to add eDP panels to dts
files we used to list them in "panel-simple.yaml".
These days we have the new way of doing things as documented in
"panel-edp.yaml". We can just list the compatible "edp-panel", add
some timing info to the source code, and we're good to go. There's not
really good reasons not to use this new method.
To try to make it obvious that we shouldn't add new compatible strings
for eDP panels, let's move them all out of the old "panel-simple.yaml"
file to their own file: "panel-edp-legacy.yaml". This new file will
have a description that makes it obvious that we shouldn't use it for
new panels.
While we're doing this:
- We can remove eDP-specific properties from panel-simple.yaml since
there are no more panels there.
- We don't need to copy non-eDP properties to the
"panel-edp-legacy.yaml".
- We'll fork off a separate yaml file for "samsung,atna33xc20.yaml".
This is an eDP panel which isn't _quite_ handled by the generic
"edp-panel" compatible since it's not allowed to have an external
backlight (it has one builtin) and it absolutely requires an
"enable" GPIO.
- We'll un-fork the "sharp,ld-d5116z01b.yaml" and put it in
"panel-edp-legacy.yaml" since there doesn't appear to be any reason
for it to be separate.
Kuro Chung [Wed, 22 May 2024 06:55:28 +0000 (14:55 +0800)]
drm/bridge: it6505: fix hibernate to resume no display issue
When the system power resumes, the TTL input of IT6505 may experience
some noise before the video signal stabilizes, necessitating a video
reset. This patch is implemented to prevent a loop of video error
interrupts, which can occur when a video reset in the video FIFO error
interrupt triggers another such interrupt. The patch processes the SCDT
and FIFO error interrupts simultaneously and ignores any video FIFO
error interrupts caused by a video reset.
Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Signed-off-by: Kuro Chung <kuro.chung@ite.com.tw> Signed-off-by: Hermes Wu <hermes.wu@ite.com.tw> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240522065528.1053439-1-kuro.chung@ite.com.tw
Ville Syrjälä [Thu, 16 May 2024 17:33:24 +0000 (20:33 +0300)]
drm/probe-helper: Call drm_mode_validate_ycbcr420() before connector->mode_valid()
Make life easier for drivers by filtering out unwanted YCbCr 4:2:0
only modes prior to calling the connector->mode_valid() hook.
Currently drivers will still see YCbCr 4:2:0 only modes in said
hook, which will likely come as a suprise when the driver has
declared no support for such modes (via setting
connector->ycbcr_420_allowed to false).
Wayne Lin [Thu, 7 Mar 2024 06:29:57 +0000 (14:29 +0800)]
drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2
[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement")
accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2")
which cause regression.
[How]
Recover the original NULL fix and remove the unnecessary input parameter 'state' for
drm_dp_add_payload_part2().
TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC description
says "This bit should be disabled only in video mode transmission where Host
transmits video timing together with video data and where pixel clock source
is from DSI clock." . This driver always sources pixel clock from external xtal,
therefore the FRMSYNC bit must always be enabled, enable it.
This fixes an actual issue with DSI-to-DPI mode, where the display would
randomly show subtle pixel flickering, or wobble, or shimmering. This is
visible on solid gray color, but the degree of the shimmering differs
between boots, which makes it hard to debug.
There is a caveat to the FRMSYNC and this bridge pixel PLL, which can only
generate pixel clock with limited accuracy, it may therefore be necessary
to reduce the HFP to fit into line length of input pixel data, to avoid any
possible overflows, which make the output video look striped horizontally.
Douglas Anderson [Fri, 17 May 2024 21:36:43 +0000 (14:36 -0700)]
drm/panel: himax-hx83102: use wrapped MIPI DCS functions
Take advantage of some of the new wrapped routines introduced by
commit f79d6d28d8fe ("drm/mipi-dsi: wrap more functions for streamline
handling") to simplify the himax-hx83102 driver a bit more. This gets
rid of some extra error prints (since the _multi functions all print
errors for you) and simplifies the code a bit.
One thing here that isn't just refactoring is that in a few places we
now check with errors with "if (err)" instead of "if (err < 0)". All
errors are expected to be negative so this is not expected to have any
impact. The _multi code internally considers anything non-zero to be
an error so this just makes things consistent.
It can also be noted that hx83102_prepare() has a mix of things that
can take advantage of _multi calls and things that can't. The cleanest
seemed to be to use the multi_ctx still but consistently use the
"accum_err" variable for error returns, though that's definitely a
style decision with pros and cons.
Douglas Anderson [Fri, 17 May 2024 21:36:42 +0000 (14:36 -0700)]
drm/panel: himax-hx83102: Check for errors on the NOP in prepare()
The mipi_dsi_dcs_nop() function returns an error but we weren't
checking it in hx83102_prepare(). Add a check. This is highly unlikely
to matter in practice. If the NOP failed then likely later MIPI
commands would fail too.
Douglas Anderson [Fri, 17 May 2024 21:36:41 +0000 (14:36 -0700)]
drm/panel: himax-hx83102: If prepare fails, disable GPIO before regulators
The enable GPIO should clearly be set low before turning off
regulators. That matches both the inverse order that things were
enabled and also the order in unprepare().
Douglas Anderson [Fri, 17 May 2024 21:36:40 +0000 (14:36 -0700)]
drm/panel: ilitek-ili9882t: Check for errors on the NOP in prepare()
The mipi_dsi_dcs_nop() function returns an error but we weren't
checking it in ili9882t_prepare(). Add a check. This is highly
unlikely to matter in practice. If the NOP failed then likely later
MIPI commands would fail too.
Douglas Anderson [Fri, 17 May 2024 21:36:39 +0000 (14:36 -0700)]
drm/panel: ilitek-ili9882t: If prepare fails, disable GPIO before regulators
The enable GPIO should clearly be set low before turning off
regulators. That matches both the inverse order that things were
enabled and also the order in unprepare().
Douglas Anderson [Fri, 17 May 2024 21:36:38 +0000 (14:36 -0700)]
drm/panel: boe-tv101wum-nl6: Check for errors on the NOP in prepare()
The mipi_dsi_dcs_nop() function returns an error but we weren't
checking it in boe_panel_prepare(). Add a check. This is highly
unlikely to matter in practice. If the NOP failed then likely later
MIPI commands would fail too.
Douglas Anderson [Fri, 17 May 2024 21:36:37 +0000 (14:36 -0700)]
drm/panel: boe-tv101wum-nl6: If prepare fails, disable GPIO before regulators
The enable GPIO should clearly be set low before turning off
regulators. That matches both the inverse order that things were
enabled and also the order in unprepare().
Douglas Anderson [Fri, 17 May 2024 21:36:36 +0000 (14:36 -0700)]
drm/panel: himax-hx8394: Handle errors from mipi_dsi_dcs_set_display_on() better
If mipi_dsi_dcs_set_display_on() returned an error then we'd store
that in the "ret" variable and jump to error handling. We'd then
attempt an orderly poweroff. Unfortunately we then blew away the value
stored in "ret". That means that if the orderly poweroff actually
worked then we're return 0 (no error) from hx8394_enable() even though
the panel wasn't enabled.
Jocelyn Falempe [Fri, 17 May 2024 15:09:58 +0000 (17:09 +0200)]
drm/mgag200: Add an option to disable Write-Combine
Unfortunately, the G200 ioburst workaround doesn't work on some
servers like Dell poweredge XR11, XR5610, or HPE XL260. In this case
completely disabling WC is the only option to achieve low-latency.
So this adds a new Kconfig option to disable WC mapping of the G200.
This workaround doesn't work reliably on all servers.
I'll replace it with an option to disable Write-Combine,
which has more impact on performance, but fix the latency
issue on all hardware.
Maíra Canal [Sun, 12 May 2024 22:23:29 +0000 (19:23 -0300)]
drm/v3d: Deprecate the use of the Performance Counters enum
The Performance Counters enum used to identify the index of each
performance counter and provide the total number of performance
counters (V3D_PERFCNT_NUM). But, this enum is only valid for V3D 4.2,
not for V3D 7.1.
As we implemented a new flexible structure to retrieve performance
counters information, we can deprecate this enum.
Maíra Canal [Sun, 12 May 2024 22:23:28 +0000 (19:23 -0300)]
drm/v3d: Use V3D_MAX_COUNTERS instead of V3D_PERFCNT_NUM
V3D_PERFCNT_NUM represents the maximum number of performance counters
for V3D 4.2, but not for V3D 7.1. This means that, if we use
V3D_PERFCNT_NUM, we might go out-of-bounds on V3D 7.1.
Therefore, use the number of performance counters on V3D 7.1 as the
maximum number of counters. This will allow us to create arrays on the
stack with reasonable size. Note that userspace must use the value
provided by DRM_V3D_PARAM_MAX_PERF_COUNTERS.
Maíra Canal [Sun, 12 May 2024 22:23:27 +0000 (19:23 -0300)]
drm/v3d: Create new IOCTL to expose performance counters information
Userspace usually needs some information about the performance counters
available. Although we could replicate this information in the kernel
and user-space, let's use the kernel as the "single source of truth" to
avoid issues in the future (e.g. list of performance counters is updated
in user-space, but not in the kernel, generating invalid requests).
Therefore, create a new IOCTL to expose the performance counters
information, that is name, category, and description.
Maíra Canal [Sun, 12 May 2024 22:23:26 +0000 (19:23 -0300)]
drm/v3d: Create a new V3D parameter for the maximum number of perfcnt
The maximum number of performance counters can change from version to
version and it's important for userspace to know this value, as it needs
to use the counters for performance queries. Therefore, expose the
maximum number of performance counters to userspace as a parameter.
Maíra Canal [Sun, 12 May 2024 22:23:25 +0000 (19:23 -0300)]
drm/v3d: Different V3D versions can have different number of perfcnt
Currently, even though V3D 7.1 has 93 performance counters, it is not
possible to create counters bigger than 87, as
`v3d_perfmon_create_ioctl()` understands that counters bigger than 87
are invalid.
Therefore, create a device variable to expose the maximum
number of counters for a given V3D version and make
`v3d_perfmon_create_ioctl()` check this variable.
This commit fixes CTS failures in the performance queries tests
`dEQP-VK.query_pool.performance_query.*` [1]
Maíra Canal [Sun, 12 May 2024 22:23:24 +0000 (19:23 -0300)]
drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1
Add name, category and description for each one of the 93 performance
counters available on V3D.
Note that V3D 4.2 has 87 performance counters, while V3D 7.1 has 93.
Therefore, there are two performance counters arrays. The index of the
performance counter for each V3D version is represented by its position
on the array.
Dmitry Baryshkov [Sat, 11 May 2024 23:00:23 +0000 (02:00 +0300)]
drm/panel: novatek-nt36672e: use wrapped MIPI DCS functions
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/exit code. This also includes passing context to
the init_sequence() function instead of passing the DSI device.
Dmitry Baryshkov [Sat, 11 May 2024 23:00:19 +0000 (02:00 +0300)]
drm/mipi-dsi: wrap more functions for streamline handling
Follow the pattern of mipi_dsi_dcs_*_multi() and wrap several existing
MIPI DSI functions to use the context for processing. This simplifies
and streamlines driver code to use simpler code pattern.
Note, msleep function is also wrapped in this way as it is frequently
called inbetween other mipi_dsi_dcs_*() functions.
Thomas Zimmermann [Mon, 13 May 2024 12:51:14 +0000 (14:51 +0200)]
drm/mgag200: Acquire I/O-register lock in DDC code
The modeset lock protects the DDC code from concurrent modeset
operations, which use the same registers. Move that code from the
connector helpers into the DDC helpers .pre_xfer() and .post_xfer().
Both, .pre_xfer() and .post_xfer(), enclose the transfer of data blocks
over the I2C channel in the internal I2C function bit_xfer(). Both
calls are executed unconditionally if present. Invoking DDC transfers
from any where within the driver now takes the lock.
Align the names of the algo-bit helpers with mgag200's convention of
using an mgag200 prefix plus the struct's name plus the callback's name
for such function symbols.
Thomas Zimmermann [Mon, 13 May 2024 12:51:11 +0000 (14:51 +0200)]
drm/mgag200: Replace struct mga_i2c_chan with struct mgag200_ddc
Rename struct mga_i2c_chan to struct mgag200_ddc, define it in the
source file mgag200_i2c.c, and reorder its fields. Rename all related
variables from i2c to ddc. Also rename the i2c adapter accordingly.
Using the term 'ddc' documents the purpose of the code clearly. The
old term 'i2c' could refer to any functionality on an i2c bus. No
functional changes.
Thomas Zimmermann [Mon, 13 May 2024 12:51:10 +0000 (14:51 +0200)]
drm/mgag200: Inline mgag200_i2c_init()
The function mgag200_i2c_init() is an internal helper that sets
up the i2c data structure. Inline its code into the only caller.
Rearrange the individual steps to separate among i2c algorithm,
adapter and fields in struct mga_i2c_chan.
Thomas Zimmermann [Mon, 13 May 2024 12:51:09 +0000 (14:51 +0200)]
drm/mgag200: Allocate instance of struct mga_i2c_chan dynamically
Allocate instances of struct mga_i2c_chan in mgag200_ddc_create()
and return a pointer to the contained i2c adapter. The callers of
the function are now independent from struct mga_i2c_chan.
Thomas Zimmermann [Mon, 13 May 2024 12:51:07 +0000 (14:51 +0200)]
drm/mgag200: Bind I2C lifetime to DRM device
Managed cleanup with devm_add_action_or_reset() will release the I2C
adapter when the underlying Linux device goes away. But the connector
still refers to it, so this cleanup leaves behind a stale pointer
in struct drm_connector.ddc.
Bind the lifetime of the I2C adapter to the connector's lifetime by
using DRM's managed release. When the DRM device goes away (after
the Linux device) DRM will first clean up the connector and then
clean up the I2C adapter.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Fixes: b279df242972 ("drm/mgag200: Switch I2C code to managed cleanup") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.0+ Link: https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-3-tzimmermann@suse.de
Thomas Zimmermann [Mon, 13 May 2024 12:51:06 +0000 (14:51 +0200)]
drm/mgag200: Set DDC timeout in milliseconds
Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update mgag200 accordingly.
Cong Yang [Thu, 16 May 2024 07:20:39 +0000 (15:20 +0800)]
drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Cong Yang [Thu, 16 May 2024 07:20:37 +0000 (15:20 +0800)]
drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Cong Yang [Thu, 16 May 2024 07:20:35 +0000 (15:20 +0800)]
drm/panel: himax-hx83102: Break out as separate driver
The Starry HX83102 based mipi panel should never have been part of the boe
tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a
separate driver to enable the hx83102 controller.
In hx83102 driver, add DSI commands as macros. So it can add some panels
with same control model in the future.
In the old boe-tv101wum-nl6 driver inital cmds was invoked at the end of
prepare() function , and call 0x11 and 0x29 at end of inital. For
himax-hx83102 driver, we move 0x11 and 0x29 cmds invoked at prepare()
function.
Note:0x11 is mipi_dsi_dcs_exit_sleep_mode
0x29 is mipi_dsi_dcs_set_display_on
In V1, discussed with Doug and Linus [1], we need break out as separate
driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02"
and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same
controller, they have some common CMDS. So add new documentation for
this panels.
For himax83102-j02 controller, no need 3v3 supply, so remove it.
Wachowski, Karol [Wed, 15 May 2024 11:30:05 +0000 (13:30 +0200)]
accel/ivpu: Split IP and buttress code
The NPU device consists of two parts: NPU buttress and NPU IP.
Buttress is a platform specific part that integrates the NPU IP with
the CPU.
NPU IP is the platform agnostic part that does the inference.
This separation enables support for multiple platforms using
a single NPU IP, so for example NPU IP 37XX could be integrated into
MTL and LNL platforms.
Add support for Microtips Technology USA MF-103HIEB0GA0 10.25"[0],
1920x720, 8-bit TFT LCD with LVDS interface. Its a Dual-LVDS Panel and
does not support touch.
Add support for Microtips Technology USA 13-101HIECAF0-C 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and touch
support (ILITEK 2511).
Aradhya Bhatia [Wed, 15 May 2024 09:51:31 +0000 (15:21 +0530)]
drm/panel: simple: Add Lincoln Tech Sol LCD185-101CT panel
Add support for Lincoln Technology Solutions LCD185-101CT, 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and PCAP
touch support (Goodix GT928).
Douglas Anderson [Tue, 14 May 2024 17:20:59 +0000 (10:20 -0700)]
drm/panel: innolux-p079zca: Don't use a table for initting panels
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. We'll use the
same concepts as the recently introduced
mipi_dsi_generic_write_seq_multi() to make this clean/easy and also
not bloat the driver too much. Measuring before/after this change:
Note that, unlike some other drivers, we actually make this panel
driver _bigger_ by using the new functions. This is because the
innolux-p079zca panel driver didn't have as complex of a table and
thus the old table was more efficient than the code. The bloat is
still not giant (only 412 bytes).
Also note that we can't direclty use
mipi_dsi_generic_write_seq_multi() here because we need to deal with
the crazy "nop" that this driver sends after all commands. This means
that we have to write code that is "inspired" by the new macros.
Since we're touching all the tables, let's also convert hex numbers to
lower case as per kernel conventions.
Douglas Anderson [Tue, 14 May 2024 17:20:58 +0000 (10:20 -0700)]
drm/panel: ili9882t: Don't use a table for initting panels
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:
Douglas Anderson [Tue, 14 May 2024 17:20:57 +0000 (10:20 -0700)]
drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:
Douglas Anderson [Tue, 14 May 2024 17:20:56 +0000 (10:20 -0700)]
drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
This is a mechanical conversion of the novatek-nt36672e driver to use
the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for
clients to understand and using it also causes smaller code to be
generated. Specifically:
$ scripts/bloat-o-meter \
...after/panel-novatek-nt36672e.ko \
...ctx/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988)
Function old new delta
nt36672e_1080x2408_60hz_init 6236 5248 -988
Total: Before=10651, After=9663, chg -9.28%
The current mipi_dsi_*_write_seq() macros are non-intutitive because
they contain a hidden "return" statement that will return out of the
_caller_ of the macro. Let's mark them as deprecated and instead
introduce some new macros that are more intuitive.
These new macros are less optimal when an error occurs but should
behave more optimally when there is no error. Specifically these new
macros cause smaller code to get generated and the code size savings
(less to fetch from RAM, less cache space used, less RAM used) are
important. Since the error case isn't something we need to optimize
for and these new macros are easier to understand and more flexible,
they should be used.
After converting to use these new functions, one example shows some
nice savings while also being easier to understand.
$ scripts/bloat-o-meter \
...after/panel-novatek-nt36672e.ko \
...ctx/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988)
Function old new delta
nt36672e_1080x2408_60hz_init 6236 5248 -988
Total: Before=10651, After=9663, chg -9.28%
Douglas Anderson [Tue, 14 May 2024 17:20:54 +0000 (10:20 -0700)]
drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
Through a cooperative effort between Hsin-Yi Wang and Dmitry
Baryshkov, we have realized the dev_err() in the
mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty"
version of the functions that includes the print. While doing this,
add a bit more comments to these macros making it clear that they
print errors and also that they return out of _the caller's_ function.
Without any changes to clients this gives a nice savings. Specifically
the macro was inlined and thus the error report call was inlined into
every call to mipi_dsi_dcs_write_seq() and
mipi_dsi_generic_write_seq(). By using a call to a "chatty" function,
the usage is reduced to one call in the chatty function and a function
call at the invoking site.
Building with my build system shows one example:
$ scripts/bloat-o-meter \
.../before/panel-novatek-nt36672e.ko \
.../after/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-4404 (-4404)
Function old new delta
nt36672e_1080x2408_60hz_init 10640 6236 -4404
Total: Before=15055, After=10651, chg -29.25%
Note that given the change in location of the print it's harder to
include the "cmd" in the printout for mipi_dsi_dcs_write_seq() since,
theoretically, someone could call the new chatty function with a
zero-size array and it would be illegal to dereference data[0].
There's a printk format to print the whole buffer and this is probably
more useful for debugging anyway. Given that we're doing this for
mipi_dsi_dcs_write_seq(), let's also print the buffer for
mipi_dsi_generic_write_seq() in the error case.
It should be noted that the current consensus of DRM folks is that the
mipi_dsi_*_write_seq() should be deprecated due to the non-intuitive
return behavior. A future patch will formally mark them as deprecated
and provide an alternative.
Douglas Anderson [Tue, 14 May 2024 17:20:52 +0000 (10:20 -0700)]
drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()
The mipi_dsi_generic_write_seq() macro makes a call to
mipi_dsi_generic_write() which returns a type ssize_t. The macro then
stores it in an int and checks to see if it's negative. This could
theoretically be a problem if "ssize_t" is larger than "int".
To see the issue, imagine that "ssize_t" is 32-bits and "int" is
16-bits, you could see a problem if there was some code out there that
looked like:
mipi_dsi_generic_write_seq(dsi, <32768 bytes as arguments>);
...since we'd get back that 32768 bytes were transferred and 32768
stored in a 16-bit int would look negative.
Though there are no callsites where we'd actually hit this (even if
"int" was only 16-bit), it's cleaner to make the types match so let's
fix it.
Douglas Anderson [Tue, 14 May 2024 17:20:51 +0000 (10:20 -0700)]
drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
The mipi_dsi_dcs_write_seq() macro makes a call to
mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro
then stores it in an int and checks to see if it's negative. This
could theoretically be a problem if "ssize_t" is larger than "int".
To see the issue, imagine that "ssize_t" is 32-bits and "int" is
16-bits, you could see a problem if there was some code out there that
looked like:
mipi_dsi_dcs_write_seq(dsi, cmd, <32767 bytes as arguments>);
...since we'd get back that 32768 bytes were transferred and 32768
stored in a 16-bit int would look negative.
Though there are no callsites where we'd actually hit this (even if
"int" was only 16-bit), it's cleaner to make the types match so let's
fix it.
Tomasz Rusinowicz [Mon, 13 May 2024 12:04:31 +0000 (14:04 +0200)]
accel/ivpu: Share NPU busy time in sysfs
The driver tracks the time spent by NPU executing jobs
and shares it through sysfs `npu_busy_time_us` file.
It can be then used by user space applications to monitor device
utilization.
NPU is considered 'busy' starting with a first job submitted
to firmware and ending when there is no more jobs pending/executing.
Jacek Lawrynowicz [Mon, 13 May 2024 12:04:30 +0000 (14:04 +0200)]
accel/ivpu: Increase reset counter when warm boot fails
Failed warm boot causes a cold boot that looses FW state and is
equivalent to a recovery or reset, so reset_counter should be
incremented in order for this failure to be detected by tests.
Wachowski, Karol [Mon, 13 May 2024 12:04:28 +0000 (14:04 +0200)]
accel/ivpu: Add force snoop module parameter
Add module parameter that enforces snooping for all NPU accesses,
both through MMU PTEs mappings and through TCU page table walk
override register bits for MMU page walks / configuration access.
Wachowski, Karol [Mon, 13 May 2024 12:04:26 +0000 (14:04 +0200)]
accel/ivpu: Add resume engine support
Create debugfs interface that triggers sending resume engine IPC
command to VPU. It is used to test engine resume functionality in
driver user space tests.
Wachowski, Karol [Mon, 13 May 2024 12:04:22 +0000 (14:04 +0200)]
accel/ivpu: Create priority based command queues
Create multiple command queues per engine with different priorities.
The cmdqs are created on-demand and they support 4 priority levels.
These priorities will later be used by the HWS (hardware scheduler).
Wachowski, Karol [Mon, 13 May 2024 12:04:21 +0000 (14:04 +0200)]
accel/ivpu: Add sched_mode module param
This param will be used to enable/disable HWS (hardware scheduler).
The HWS is a FW side feature and may not be available on all
HW generations and FW versions.
Sui Jingfeng [Mon, 13 May 2024 15:31:09 +0000 (23:31 +0800)]
drm/bridge: analogix: Remove redundant checks on existence of bridge->encoder
The checks on the existence of bridge->encoder in the implementation of
drm_bridge_funcs::attach() is not necessary, as it has already been checked
in the drm_bridge_attach() function call by previous bridge or KMS driver.
The drm_bridge_attach() will quit with a negative error code returned if
it fails for some reasons, hence, it is guaranteed that the .encoder member
of the drm_bridge instance is not NULL when various bridge attach functions
are called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:08 +0000 (23:31 +0800)]
drm/bridge: imx: Remove redundant checks on existence of bridge->encoder
The checks on the existence of bridge->encoder in the implementation of
drm_bridge_funcs::attach() is not necessary, as it has already been checked
in the drm_bridge_attach() function call by previous bridge or KMS driver.
The drm_bridge_attach() will quit with a negative error code returned if
it fails for some reasons, hence, it is guaranteed that the .encoder member
of the drm_bridge instance is not NULL when various i.MX specific bridge
attach functions are called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:07 +0000 (23:31 +0800)]
drm/bridge: lt9611uxc: Remove a redundant check on existence of bridge->encoder
In the lt9611uxc_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function. And the check on the drm bridge core
happens before check in the implementation. Hence, it is guaranteed that
the .encoder member of the struct drm_bridge is not NULL when
lt9611uxc_connector_init() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:06 +0000 (23:31 +0800)]
drm/bridge: synopsys: dw-mipi-dsi: Remove a redundant check on existence of bridge->encoder
In the dw_mipi_dsi_bridge_attach() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function invocked by previous bridge or KMS driver.
The previous drm_bridge_attach() will quit with a negative error code
returned if it fails for some reasons, hence, it is guaranteed that the
.encoder member of the struct drm_bridge is not NULL when
dw_mipi_dsi_bridge_attach() function gets called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:05 +0000 (23:31 +0800)]
drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: Remove a redundant check on existence of bridge->encoder
In the ge_b850v3_lvds_create_connector function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in the
drm_bridge_attach() function called by upstream bridge or driver. Hence, it
is guaranteed that the .encoder member of the drm_bridge instance is not
NULL when cdns_mhdp_connector_init() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:04 +0000 (23:31 +0800)]
drm/bridge: cdns-mhdp8546: Remove a redundant check on existence of bridge->encoder
In the cdns_mhdp_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been checked in
the drm_bridge_attach() function. As the cdns_mhdp_connector_init() is
only called by cdns_mhdp_attach(), it is guaranteed that the .encoder
member of the struct drm_bridge is not NULL when cdns_mhdp_attach() gets
called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:03 +0000 (23:31 +0800)]
drm/bridge: adv7511: Remove a redundant check on existence of bridge->encoder
In the adv7511_connector_init() function, the check on the existence of
bridge->encoder is not necessary. As it has already been checked in the
drm_bridge_attach() which happens prior to the adv7511_bridge_attach()
get called. Also note that the adv7511_connector_init() is only called by
adv7511_bridge_attach(). Hence, it is guaranteed that the .encoder member
of the drm_bridge instance is not NULL when adv7511_connector_init() get
called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:02 +0000 (23:31 +0800)]
drm/bridge: it6505: Remove a redundant check on existence of bridge->encoder
In it6505_bridge_attach(), the check on the existence of 'bridge->encoder'
is not necessary, as it has already been checked in the drm_bridge_attach()
which happens prior to it6505_bridge_attach() get called. Note that the
it6505_bridge_attach() will only be called by .attach() of the previous
bridge or KMS driver. The previous drm_bridge_attach() will quit with a
negative error code returned if it fails for some reasons. Hence, it is
guaranteed that the .encoder member of the drm_bridge instance is not NULL
when it6505_bridge_attach() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:01 +0000 (23:31 +0800)]
drm/bridge: panel: Remove a redundant check on existence of bridge->encoder
Because the existence of 'bridge->encoder' has already been checked before
the panel_bridge_attach() function get called, and the drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is not NULL when panel_bridge_attach() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:31:00 +0000 (23:31 +0800)]
drm/bridge: nxp-ptn3460: Remove a redundant check on existence of bridge->encoder
Because the existence of 'bridge->encoder' has already been checked before
the ptn3460_bridge_attach() function get called, and drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is not NULL when the ptn3460_bridge_attach() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:30:59 +0000 (23:30 +0800)]
drm/bridge: tfp410: Remove a redundant check on existence of bridge->encoder
Because the existence of bridge->encoder has already been checked before
the simple_bridge_attach() function get called, And drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is not NULL when the tfp410_attach() function get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Sui Jingfeng [Mon, 13 May 2024 15:30:58 +0000 (23:30 +0800)]
drm/bridge: simple-bridge: Remove a redundant check on existence of bridge->encoder
Because the existence of 'bridge->encoder' has already been checked before
the simple_bridge_attach() function get called, and drm_bridge_attach()
will quit with a negative error code returned if it fails for some reasons.
Hence, it is guaranteed that the .encoder member of the drm_bridge instance
is not NULL when the simple_bridge_attach() get called.
Remove the redundant checking codes "if (!bridge->encoder) { ... }".
Thomas Zimmermann [Fri, 10 May 2024 15:47:12 +0000 (17:47 +0200)]
drm/udl: Remove struct udl_connector
Udl's struct udl_connector is an empty wrapper around struct
drm_connector. Remove it. Allocate the connector as part of struct
udl_device and inline the init function into its only caller.
v2:
- fix return value in udl_modeset_init() (Dan)
Thomas Zimmermann [Fri, 10 May 2024 15:47:11 +0000 (17:47 +0200)]
drm/udl: Untangle .get_modes() and .detect_ctx()
Provide separate implementations of .get_modes() and .detect_ctx()
from struct drm_connector. Switch to struct drm_edid.
Udl's .detect() helper used to fetch the EDID from the adapter and the
.get_modes() helper provided display modes from the data. But this
relied on the DRM helpers to call the functions in the correct order.
When no EDID could be retrieved, .detect() regularly printed a warning
to the kernel log.
Switching to the new helpers around struct drm_edid separates both from
each other. The .get_modes() helper now fetches the EDID by itself and
the .detect_ctx() helper only tests for its presence. The patch does a
number of things to implement this.
- Move udl_get_edid_block() to udl_edid.c and rename it to
udl_read_edid_block(). Then use the helper to implement probing in
udl_probe_edid() and reading in udl_edid_read(). The latter helper
is build on top of DRM helpers.
- Replace the existing code in .get_modes() and .detect() with udl's
new EDID helpers. The new code behaves like DRM's similar DDC-based
helpers. Instead of .detect(), udl now implements .detect_ctx().
- Remove the edid data from struct udl_connector. The field cached
the EDID data between calls to .detect() and .get_modes(), but is now
unused.
v3:
- implement udl_probe_edid() with memchr_inv() (Jani)
v2:
- implement udl_probe_edid() within udl
- reword commit description
Thomas Zimmermann [Fri, 10 May 2024 15:47:09 +0000 (17:47 +0200)]
drm/udl: Move drm_dev_{enter, exit}() into udl_get_edid_block()
Protect the code in udl_get_edid_block() with drm_dev_enter() and
drm_dev_exit(), so that all callers automatically invoke it. The
function uses hardware resources, which can be hot-unplugged at
any time. The other code in udl_connector_detect() does not use the
resources of the hardware device and therefore does not require
protection.
This change will allow to use udl_get_edid_block() in various
contexts easily.
projects / users / jedix / linux-maple.git / log