| Age | Commit message (Collapse) | Author | Files | Lines |
|
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]>
|
|
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]
|
|
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]
|
|
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]
|
|
./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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|
|
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]
|