aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-11-23drm/imagination: Add skeleton PowerVR driverSarah Walker7-0/+711
This adds the basic skeleton of the driver. The driver registers itself with DRM on probe. Ioctl handlers are currently implemented as stubs. Changes since v8: - Corrected license identifiers Changes since v5: - Update compatible string & description to match marketing name - Checkpatch fixes in to/from_pvr_device/file macros Changes since v3: - Clarify supported GPU generations in driver description - Use drm_dev_unplug() when removing device - Change from_* and to_* functions to macros - Fix IS_PTR/PTR_ERR confusion in pvr_probe() - Remove err_out labels in favour of direct returning - Remove specific am62 compatible match string - Drop MODULE_FIRMWARE() Co-developed-by: Frank Binns <[email protected]> Signed-off-by: Frank Binns <[email protected]> Co-developed-by: Matt Coster <[email protected]> Signed-off-by: Matt Coster <[email protected]> Signed-off-by: Sarah Walker <[email protected]> Signed-off-by: Donald Robson <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/fed8a77e29620a61aed2684f802339759082cf1b.1700668843.git.donald.robson@imgtec.com Signed-off-by: Maxime Ripard <[email protected]>
2023-11-23drm/i915/display: Do not check psr2 if psr/panel replay is not supportedJouni Högander1-0/+3
Do not continue to psr2 checks if psr or panel replay is not supported. Cc: Animesh Manna <[email protected]> Fixes: b8cf5b5d266e ("drm/i915/panelreplay: Initializaton and compute config for panel replay") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9670 Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-23drm/i915/display: Use int type for entry_setup_framesMika Kahola1-1/+1
entry_setup_frames variable is defined as u8. However, the function call intel_psr_entry_setup_frames() can return negative error code. There is a type mismatch here, so let's switch to use int here as well. Fixes: 2b981d57e480 ("drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier") Signed-off-by: Mika Kahola <[email protected]> Reviewed-by: Vinod Govindapillai <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-23drm/rockchip: rk3066_hdmi: include drm/drm_atomic.hArnd Bergmann1-0/+1
Without this header, the newly added code fails to build: drivers/gpu/drm/rockchip/rk3066_hdmi.c: In function 'rk3066_hdmi_encoder_enable': drivers/gpu/drm/rockchip/rk3066_hdmi.c:397:22: error: implicit declaration of function 'drm_atomic_get_new_connector_state'; did you mean 'drm_atomic_helper_connector_reset'? [-Werror=implicit-function-declaration] 397 | conn_state = drm_atomic_get_new_connector_state(state, &hdmi->connector); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | drm_atomic_helper_connector_reset drivers/gpu/drm/rockchip/rk3066_hdmi.c:397:20: error: assignment to 'struct drm_connector_state *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] 397 | conn_state = drm_atomic_get_new_connector_state(state, &hdmi->connector); | ^ drivers/gpu/drm/rockchip/rk3066_hdmi.c:401:22: error: implicit declaration of function 'drm_atomic_get_new_crtc_state'; did you mean 'drm_atomic_helper_swap_state'? [-Werror=implicit-function-declaration] 401 | crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | drm_atomic_helper_swap_state drivers/gpu/drm/rockchip/rk3066_hdmi.c:401:20: error: assignment to 'struct drm_crtc_state *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] 401 | crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc); | ^ Fixes: ae3436a5e7c2 ("drm/rockchip: rk3066_hdmi: Switch encoder hooks to atomic") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> # build-tested Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/nouveau/fifo: Remove duplicated include in chan.cYang Li1-1/+0
./drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c: chid.h is included more than once. Reported-by: Abaci Robot <[email protected]> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7603 Signed-off-by: Yang Li <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/iosf: Drop unused APIsAndy Shevchenko2-20/+0
Drop unused vlv_iosf_sb_read() and vlv_iosf_sb_write(). Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Combine checks in mipi_exec_gpio()Andy Shevchenko1-3/+1
For a couple of cases the branches call the same bxt_gpio_set_value(). As Ville suggested they can be combined by dropping the DISPLAY_VER() check from Gen 11 to Gen 9. Do it that way. Suggested-by: Ville Syrjälä <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's backAndy Shevchenko1-37/+10
It's a dirty hack in the driver that pokes GPIO registers behind the driver's back. Moreoever it might be problematic as simultaneous I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl: cherryview: prevent concurrent access to GPIO controllers") for the details. Taking all this into consideration replace the hack with proper GPIO APIs being used. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Prepare soc_gpio_set_value() to distinguish GPIO communitiesAndy Shevchenko1-10/+10
Currently soc_gpio_set_value() supports only a single indexing for GPIO pin. For CHV case, for example, we will need to distinguish community based index from the one that VBT is using. Introduce an additional parameter to soc_gpio_set_value() and its callers. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's backAndy Shevchenko1-70/+28
It's a dirty hack in the driver that pokes GPIO registers behind the driver's back. Moreoever it might be problematic as simultaneous I/O may hang the system, see the commit 40ecab551232 ("pinctrl: baytrail: Really serialize all register accesses") for the details. Taking all this into consideration replace the hack with proper GPIO APIs being used. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Extract common soc_gpio_set_value() helperAndy Shevchenko1-20/+26
Extract a common soc_gpio_set_value() helper that may be used by a few SoCs. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Fix wrong initial value for GPIOs in bxt_gpio_set_value()Hans de Goede1-3/+1
Fix wrong initial value for GPIOs in bxt_gpio_set_value(). Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Remove GPIO lookup table at the end of intel_dsi_vbt_gpio_init()Hans de Goede1-16/+9
To properly deal with GPIOs used in MIPI panel sequences a temporary GPIO lookup will be used. Since there can only be 1 GPIO lookup table for the "0000:00:02.0" device this will not work if the GPIO lookup table used by intel_dsi_vbt_gpio_init() is still registered. After getting the "backlight" and "panel" GPIOs the lookup table registered by intel_dsi_vbt_gpio_init() is no longer necessary, remove it so that another temporary lookup-table for the "0000:00:02.0" device can be added. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Replace check with a (missing) MIPI sequence nameAndy Shevchenko1-1/+2
Names of the MIPI sequence steps are sequential and defined, no need to check for the gaps. However in seq_name the MIPI_SEQ_END is missing. Add it there, and drop unneeded NULL check in sequence_name(). Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Get rid of redundant 'else'Andy Shevchenko1-29/+27
In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: Replace while(1) with one with clear exit conditionAndy Shevchenko1-4/+1
Move existing condition to while(), so it will be clear on what circumstances the loop is successfully finishing. Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jani Nikula <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: bxt/icl GPIO set value do not need gpio sourceJani Nikula1-3/+3
Drop the unused parameter. Cc: Andy Shevchenko <[email protected]> Cc: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: rename platform specific *_exec_gpio() to *_gpio_set_value()Jani Nikula1-10/+10
The lowest level functions are about setting GPIO values, not about executing any sequences anymore. Cc: Andy Shevchenko <[email protected]> Cc: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: clarify GPIO exec sequenceJani Nikula1-14/+17
With the various sequence versions and pointer increments interleaved, it's a bit hard to decipher what's going on. Add separate paths for different sequence versions. Cc: Andy Shevchenko <[email protected]> Cc: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: switch mipi_exec_gpio() from dev_priv to i915Jani Nikula1-7/+7
Follow the contemporary conventions. Cc: Andy Shevchenko <[email protected]> Cc: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-22drm/i915/dsi: assume BXT gpio works for non-native GPIOJani Nikula1-9/+1
Purely a guess. Drop the nop function. Cc: Andy Shevchenko <[email protected]> Cc: Hans de Goede <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21nouveau/gsp: allocate enough space for all channel ids.Dave Airlie1-1/+1
This probably isn't the ideal fix, but we ended up using chids sparsely, and lots of things rely on indexing into the full range, so just allocate the full range up front. The GSP code fixes 8 channels into a userd page, but we end up using a single userd page per channel so end up sparsely using the range. Fixes a few crashes seen with multiple channels. Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/277 Signed-off-by: Dave Airlie <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02 panel HFP and HBPCong Yang1-4/+4
The refresh reported by modetest is 60.46Hz, and the actual measurement is 60.01Hz, which is outside the expected tolerance. Adjust hporch and pixel clock to fix it. After repair, modetest and actual measurement were all 60.01Hz. Modetest refresh = Pixel CLK/ htotal* vtotal, but measurement frame rate is HS->LP cycle time(Vblanking). Measured frame rate is not only affecte by Htotal/Vtotal/pixel clock, also affected by Lane-num/PixelBit/LineTime /DSI CLK. Assume that the DSI controller could not make the mode that we requested(presumably it's PLL couldn't generate the exact pixel clock?). If you use a different DSI controller, you may need to readjust these parameters. Now this panel looks like it's only used by me on the MTK platform, so let's change this set of parameters. Fixes: 1bc2ef065f13 ("drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel") Signed-off-by: Cong Yang <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20231120020109.3216343-1-yangcong5@huaqin.corp-partner.google.com
2023-11-21drm/i915/dp: Reuse intel_dp_{max,effective}_data_rate in ↵Imre Deak1-22/+3
intel_link_compute_m_n() Reuse intel_dp_max_data_rate() and intel_dp_effective_data_rate() in intel_link_compute_m_n(), instead of open-coding the equivalent. Note the kbit/sec -> kByte/sec unit change in the M/N values, but this not reducing the precision, as the link rate value is based anyway on a less precise 10 kbit/sec value. Suggested-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/i915/dp: Simplify intel_dp_max_data_rate()Imre Deak1-14/+12
Simplify intel_dp_max_data_rate() using drm_dp_bw_channel_coding_efficiency() to calculate the max data rate for both DP1.4 and UHBR link rates. This trades a redundant multiply/divide for readability. Cc: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/i915/dp: Report a rounded-down value as the maximum data rateImre Deak1-2/+2
Callers of intel_dp_max_data_rate() use the return value as an upper bound for the BW a given mode requires. As such the rounding shouldn't result in a bigger value than the actual upper bound. Use round-down instead of -closest accordingly. Cc: Jani Nikula <[email protected]> Reviewed-by: Stanislav Lisovskiy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/i915/dp_mst: Fix PBN / MTP_TU size calculation for UHBR ratesImre Deak3-10/+44
Atm the allocated MST PBN value is calculated from the TU size (number of allocated MTP slots) as PBN = TU * pbn_div pbn_div being the link BW for each MTP slot. For DP 1.4 link rates this worked, as pbn_div there is guraranteed to be an integer number, however on UHBR this isn't the case. To get a PBN, TU pair where TU is a properly rounded-up value covering all the BW corresponding to PBN, calculate first PBN and from PBN the TU value. Calculate PBN directly from the effective pixel data rate, instead of calculating it indirectly from the corresponding TU and pbn_div values (which are in turn derived from the pixel data rate and BW overhead). Add a helper function to calculate the effective data rate, also adding a note that callers of intel_dp_link_required() may also need to check the effective data rate (vs. the data rate w/o the BW overhead). While at it add a note to check if WA#14013163432 is applicable. v2: - Fix PBN calculation, deriving it from the effective data rate directly instead of using the indirect TU and pbn_div values for this. - Add a note about WA#14013163432. (Arun) v3: - Fix rounding up quotient while calculating remote_tu. (Ville) Cc: Ville Syrjälä <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> (v1) Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/i915/dp_mst: Calculate the BW overhead in ↵Imre Deak1-9/+18
intel_dp_mst_find_vcpi_slots_for_bpp() The next patch will calculate the PBN value directly from the pixel data rate and the BW allocation overhead, not requiring the data, link M/N and TU values for this. To prepare for that move the calculation of BW overheads from intel_dp_mst_compute_m_n() to intel_dp_mst_find_vcpi_slots_for_bpp(). While at it store link_bpp in a .4 fixed point format. Reviewed-by: Arun R Murthy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/i915/dp: Fix UHBR link M/N valuesImre Deak3-6/+36
The link M/N ratio is the data rate / link symbol clock rate, fix things up accordingly. On DP 1.4 this ratio was correct as the link symbol clock rate in that case matched the link data rate (in bytes/sec units, the symbol size being 8 bits), however it wasn't correct for UHBR rates where the symbol size is 32 bits. Kudos to Arun noticing in Bspec the incorrect use of link data rate in the ratio's N value. Reviewed-by: Arun R Murthy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/i915/dp: Account for channel coding efficiency on UHBR linksImre Deak1-10/+0
Apply the correct BW allocation overhead and channel coding efficiency on UHBR link rates, similarly to DP1.4 link rates. Reviewed-by: Arun R Murthy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/i915/dp: Replace intel_dp_is_uhbr_rate() with drm_dp_is_uhbr_rate()Imre Deak3-8/+2
Replace intel_dp_is_uhbr_rate() with the recently added drm_dp_is_uhbr_rate(). Reviewed-by: Arun R Murthy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/dp_mst: Add kunit tests for drm_dp_get_vc_payload_bw()Imre Deak1-0/+160
Add kunit test cases for drm_dp_get_vc_payload_bw() with all the DP1.4 and UHBR link configurations. v2: - List test cases in decreasing rate,lane count order matching the corresponding DP Standard tables. (Ville) - Add references to the DP Standard tables. v3: - Sort the testcases properly. v4: - Avoid 'stack frame size x exceeds limit y in drm_test_dp_mst_calc_pbn_div()' compiler warn. (LKP) Cc: Ville Syrjälä <[email protected]> Cc: Lyude Paul <[email protected]> Cc: [email protected] Cc: kernel test robot <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> (v3) Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/dp_mst: Fix PBN divider calculation for UHBR ratesImre Deak1-3/+7
The current way of calculating the pbn_div value, the link BW per each MTP slot, worked only for DP 1.4 link rates. Fix things up for UHBR rates calculating with the correct channel coding efficiency based on the link rate. v2: - Return the fractional pbn_div value from drm_dp_get_vc_payload_bw(). v3: - Fix rounding up quotient while calculating req_slots. (Ville) Cc: Ville Syrjälä <[email protected]> Cc: Lyude Paul <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/dp_mst: Store the MST PBN divider value in fixed point formatImre Deak6-15/+30
On UHBR links the PBN divider is a fractional number, accordingly store it in fixed point format. For now drm_dp_get_vc_payload_bw() always returns a whole number and all callers will use only the integer part of it which should preserve the current behavior. The next patch will fix drm_dp_get_vc_payload_bw() for UHBR rates returning a fractional number for those (also accounting for the channel coding efficiency correctly). Cc: Lyude Paul <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Wayne Lin <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> [Rebased changes in dm_helpers_construct_old_payload() on drm-intel-next] Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/edid/firmware: drop drm_kms_helper.edid_firmware backward compatJani Nikula2-48/+0
Since the edid_firmware module parameter was moved from drm_kms_helper.ko to drm.ko in v4.15, we've had a backwards compatibility helper in place, with a DRM_NOTE() suggesting to migrate to drm.edid_firmware. This was added in commit ac6c35a4d8c7 ("drm: add backwards compatibility support for drm_kms_helper.edid_firmware"). More than five years and 30+ kernel releases later, drop the backward compatibility. v2: Drop the warnings too Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/tilcdc: Fix irq free on unloadTomi Valkeinen1-1/+1
The driver only frees the reserved irq if priv->irq_enabled is set to true. However, the driver mistakenly sets priv->irq_enabled to false, instead of true, in tilcdc_irq_install(), and thus the driver never frees the irq, causing issues on loading the driver a second time. Fixes: b6366814fa77 ("drm/tilcdc: Convert to Linux IRQ interfaces") Cc: Thomas Zimmermann <[email protected]> Reviewed-by: Aradhya Bhatia <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/ast: Disconnect BMC if physical connector is connectedThomas Zimmermann2-8/+67
Many user-space compositors fail with mode setting if a CRTC has more than one connected connector. This is the case with the BMC on Aspeed systems. Work around this problem by setting the BMC's connector status to disconnected when the physical connector has a display attached. This way compositors will only see one connected connector at a time; either the physical one or the BMC. Suggested-by: Jocelyn Falempe <[email protected]> Fixes: e329cb53b45d ("drm/ast: Add BMC virtual connector") Signed-off-by: Thomas Zimmermann <[email protected]> Cc: <[email protected]> # v6.6+ Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/sprd: Convert to platform remove callback returning voidUwe Kleine-König3-11/+6
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert the sprd drm drivers from always returning zero in the remove callback to the void returning variant. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/nouveau: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/meson: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/mediatek: Convert to platform remove callback returning voidUwe Kleine-König2-6/+4
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/kmb: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/imx: lcdc: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/imx/dcss: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/etnaviv: Convert to platform remove callback returning voidUwe Kleine-König2-7/+4
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert the etnaviv drm driver from always returning zero in the remove callback to the void returning variant. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/bridge: tpd12s015: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/bridge: cdns-mhdp8546: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/bridge: cdns-mhdp8546: Improve error reporting in remove callbackUwe Kleine-König1-9/+9
Replace the generic error message issued by the driver core when the remove callback returns non-zero ("remove callback returned a non-zero value. This will be ignored.") by a message that tells the actual problem. Also simplify a bit by checking the return value of wait_event_timeout a bit later. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/armada: Convert to platform remove callback returning voidUwe Kleine-König2-6/+4
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert the armada drm drivers from always returning zero in the remove callback to the void returning variant. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-11-21drm/arcpgu: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]