| Age | Commit message (Collapse) | Author |
|---|
|
To prepare the introduction of tiled mode support, pass the framebuffer
format modifier to the helpers dealing with format support.
Since only linear mode is supported for now, add corresponding checks in
each helper.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-33-paul.kocialkowski@bootlin.com
|
|
This introduces support for the BGRX8888 output format for the frontend,
with its associated output format value definition.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-23-paul.kocialkowski@bootlin.com
|
|
Our hardware requires the pitch to be an even number when using YUV
formats with the frontend. Implement a driver-specific callback for GEM
dumb allocation that sets the pitch accordingly.
Since only the bpp is passed (and not the format), we cannot really
distinguish if this alignment is really required. Since it doesn't hurt
to align the pitch anyway, always do it.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-30-paul.kocialkowski@bootlin.com
|
|
The frontend comes with two "channels", that can be configured
independently. When used in YUV mode, the first channel (CH0) represents
the luminance component while the second channel (CH1) represents the
chrominance. In RGB mode, both have to be configured the same way.
Use variables (with the YUV terminology) for each channel's
dimensions, calculating the chroma dimensions from the luma dimensions
and the sub-sampling factors from the format description.
Since the configured size only has pixel precision, the fractional
fixed-point part of the source size is dropped for both components to
ensure that the scaling factors are accurate.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-26-paul.kocialkowski@bootlin.com
|
|
The values in the BT601 YUV to RGB colorspace translation are not
simply coded as multiples, but rather as fixed-point signed fractional
values on a given number of bits. Add an explanation about that.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-24-paul.kocialkowski@bootlin.com
|
|
This introduces support for the BGRX8888 input format for the frontend,
with its associated pixel sequence value definition. Other fields are
already configured correctly as they no longer depend on the format's
fourcc directly.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-22-paul.kocialkowski@bootlin.com
|
|
Use the number of planes associated with the DRM format to determine the
input mode configuration instead of the format iteself. This way, the
helper can be used for all packed formats without future changes.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-20-paul.kocialkowski@bootlin.com
|
|
This introduces proper definitions for the input and output format
configuration registers instead of a macro and raw values in the code,
with the intent to increase code readability and reduce indirections.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-19-paul.kocialkowski@bootlin.com
|
|
This introduces new helpers for retrieving the input data mode and pixel
sequence register field values based on the DRM format instead of
hardcoding these. This makes it easier to add support for more formats.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-18-paul.kocialkowski@bootlin.com
|
|
In order to support YUV to RGB conversion with the frontend (which is
generally used for connecting with the backend), the CSC block must not
be bypassed.
As a result, the bit to enable CSC bypass is moved from the runtime
resume routine to the format update routine, so that it can disabled
when introducing support for YUV formats later.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-17-paul.kocialkowski@bootlin.com
|
|
Since more formats can be supported by the frontend, rename the
variable listing the layer formats to avoid suggesting that the backend
itself supports all the listed formats.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-16-paul.kocialkowski@bootlin.com
|
|
Our hardware has a limited number of YUV planes (usually 1) that can be
supported using the backend only. However, YUV planes can also be
supported by the frontend and must then not be counted when checking for
that limitation.
Only count the YUV plane when the frontend is not used.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-15-paul.kocialkowski@bootlin.com
|
|
Before this patch, it is assumed that a plane is supported either
through the frontend or through the backend alone. However, the DRM
interface does not allow finely reporting our hardware capabilities
and there are cases where neither are support.
In particular, some plane formats are supported by the backend and not
the frontend, so they can only be supported without scaling.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-8-paul.kocialkowski@bootlin.com
|
|
Checking that scaling is in use is not sufficient as a condition to
decide to use the frontend.
Since not all layer formats are supported by the frontend, we need to
check for that support first. Then, the frontend must only be enabled
if the backend doesn't support the format or that scaling is required.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-7-paul.kocialkowski@bootlin.com
|
|
In order to check whether the frontend supports a specific format, an
explicit list and a related helper are introduced.
Just like in the backend, the prototype of the helper is added to the
frontend header so that it can be used later on. The helper is also
exported because it will be used outside of the frontend module.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-6-paul.kocialkowski@bootlin.com
|
|
In order to check whether the backend supports a specific format, an
explicit list and a related helper are introduced.
The prototype of this helper is added to the header so that it can be
called from sun4i_layer later (when introducing tiled mode support).
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-5-paul.kocialkowski@bootlin.com
|
|
The backend allows integer-only scaling but can handle alpha components,
unlike the frontend. It could be useful to add support for this
eventually, so add a short TODO comment describing the situation.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-4-paul.kocialkowski@bootlin.com
|
|
The frontend documentation (for the A33) mentions that ARGB is supported
as output, but with the alpha component always set to 0xff. In practice,
this means that the alpha component cannot be preserved when going
through the frontend. Since the information is lost, ARGB is not
properly supported.
As a result, expose the matching format supported by the frontend (both
for input and output) as XRGB instead of ARGB.
Since ARGB was the selected format for connecting the frontend to the
backend, change it to XRGB to reflect this as well.
The A31 and A80 SoCs apparently have a bit to enable proper alpha,
but this is not supported at this point (see the comment already in the
code).
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-3-paul.kocialkowski@bootlin.com
|
|
This adds a dedicated function for cleaning the video and YUV source
channel layer enable bits. This function is called first on layer atomic
update to make sure that there are no leftover bits from previous
plane configuration that were not cleaned until now.
It fixes issues when alternating between video and YUV planes, where
both bits would be set eventually, leading to broken plane display.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123092515.2511-2-paul.kocialkowski@bootlin.com
|
|
This essential mode for PAL users is missing, so add it.
Fixes: 335e3713afb87 ("drm/meson: Add support for HDMI venc modes and settings")
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1542793169-13008-1-git-send-email-christianshewitt@gmail.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:
[ 117.904528] ==================================================================
[ 117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
[ 117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
[ 117.904601]
[ 118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
[ 118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 118.099768] Call trace:
[ 118.102181] dump_backtrace+0x0/0x3e8
[ 118.105796] show_stack+0x14/0x20
[ 118.109083] dump_stack+0x130/0x1c4
[ 118.112539] print_address_description+0x60/0x25c
[ 118.117214] kasan_report+0x1b4/0x368
[ 118.120851] __asan_report_load4_noabort+0x18/0x20
[ 118.125566] meson_viu_set_osd_lut+0x7a0/0x890
[ 118.129953] meson_viu_init+0x10c/0x290
[ 118.133741] meson_drv_bind_master+0x474/0x748
[ 118.138141] meson_drv_bind+0x10/0x18
[ 118.141760] try_to_bring_up_master+0x3d8/0x768
[ 118.146249] component_add+0x214/0x570
[ 118.149978] meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
[ 118.155404] platform_drv_probe+0x98/0x138
[ 118.159455] really_probe+0x2a0/0xa70
[ 118.163070] driver_probe_device+0x1b4/0x2d8
[ 118.167299] __driver_attach+0x200/0x280
[ 118.171189] bus_for_each_dev+0x10c/0x1a8
[ 118.175144] driver_attach+0x38/0x50
[ 118.178681] bus_add_driver+0x330/0x608
[ 118.182471] driver_register+0x140/0x388
[ 118.186361] __platform_driver_register+0xc8/0x108
[ 118.191117] meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
[ 118.198022] do_one_initcall+0x12c/0x3bc
[ 118.201883] do_init_module+0x1fc/0x638
[ 118.205673] load_module+0x4b4c/0x6808
[ 118.209387] __se_sys_init_module+0x2e8/0x3c0
[ 118.213699] __arm64_sys_init_module+0x68/0x98
[ 118.218100] el0_svc_common+0x104/0x210
[ 118.221893] el0_svc_handler+0x48/0xb8
[ 118.225594] el0_svc+0x8/0xc
[ 118.228429]
[ 118.229887] The buggy address belongs to the variable:
[ 118.235007] eotf_33_linear_mapping+0x84/0xc0
[ 118.239301]
[ 118.240752] Memory state around the buggy address:
[ 118.245522] ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 118.252695] ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 118.259850] >ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
[ 118.267000] ^
[ 118.271222] ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[ 118.278393] ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
[ 118.285542] ==================================================================
[ 118.292699] Disabling lock debugging due to kernel taint
It seems that when looping through the OSD EOTF LUT maps, we use the
same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
which means that we'll stop out of bounds on the EOTF maps.
But, this whole thing is already confusing enough to read through as-is,
so let's just replace all of the hardcoded sizes with
OSD_(OETF/EOTF)_LUT_SIZE / 2.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.10+
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Seeing as we use this registermap in the context of our IRQ handlers, we
need to be using spinlocks for reading/writing registers so that we can
still read them from IRQ handlers without having to grab any mutexes and
accidentally sleep. We don't currently do this, as pointed out by
lockdep:
[ 18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
[ 18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0
[ 18.413864] INFO: lockdep is turned off.
[ 18.417675] irq event stamp: 12
[ 18.420778] hardirqs last enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
[ 18.429510] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
[ 18.437345] softirqs last enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
[ 18.446684] softirqs last disabled at (0): [<0000000000000000>] (null)
[ 18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G W O 4.20.0-rc3Lyude-Test+ #9
[ 18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 18.480037] Workqueue: hci0 hci_power_on [bluetooth]
[ 18.487138] Call trace:
[ 18.494192] dump_backtrace+0x0/0x1b8
[ 18.501280] show_stack+0x14/0x20
[ 18.508361] dump_stack+0xbc/0xf4
[ 18.515427] ___might_sleep+0x140/0x1d8
[ 18.522515] __might_sleep+0x50/0x88
[ 18.529582] __mutex_lock+0x60/0x870
[ 18.536621] mutex_lock_nested+0x1c/0x28
[ 18.543660] regmap_lock_mutex+0x10/0x18
[ 18.550696] regmap_read+0x38/0x70
[ 18.557727] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[ 18.564804] __handle_irq_event_percpu+0xac/0x410
[ 18.571891] handle_irq_event_percpu+0x34/0x88
[ 18.578982] handle_irq_event+0x48/0x78
[ 18.586051] handle_fasteoi_irq+0xac/0x160
[ 18.593061] generic_handle_irq+0x24/0x38
[ 18.599989] __handle_domain_irq+0x60/0xb8
[ 18.606857] gic_handle_irq+0x50/0xa0
[ 18.613659] el1_irq+0xb4/0x130
[ 18.620394] debug_lockdep_rcu_enabled+0x2c/0x30
[ 18.627111] schedule+0x38/0xa0
[ 18.633781] schedule_timeout+0x3a8/0x510
[ 18.640389] wait_for_common+0x15c/0x180
[ 18.646905] wait_for_completion+0x14/0x20
[ 18.653319] mmc_wait_for_req_done+0x28/0x168
[ 18.659693] mmc_wait_for_req+0xa8/0xe8
[ 18.665978] mmc_wait_for_cmd+0x64/0x98
[ 18.672180] mmc_io_rw_direct_host+0x94/0x130
[ 18.678385] mmc_io_rw_direct+0x10/0x18
[ 18.684516] sdio_enable_func+0xe8/0x1d0
[ 18.690627] btsdio_open+0x24/0xc0 [btsdio]
[ 18.696821] hci_dev_do_open+0x64/0x598 [bluetooth]
[ 18.703025] hci_power_on+0x50/0x270 [bluetooth]
[ 18.709163] process_one_work+0x2a0/0x6e0
[ 18.715252] worker_thread+0x40/0x448
[ 18.721310] kthread+0x12c/0x130
[ 18.727326] ret_from_fork+0x10/0x1c
[ 18.735555] ------------[ cut here ]------------
[ 18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<000000006265ec59>] wait_for_common+0x140/0x180
[ 18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88
[ 18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic
brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O)
dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec
leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas
meson_gxbb_wdt pwm_meson efivarfs ipv6
[ 18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G W O 4.20.0-rc3Lyude-Test+ #9
[ 18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 18.818045] Workqueue: hci0 hci_power_on [bluetooth]
[ 18.824088] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[ 18.829891] pc : __might_sleep+0x7c/0x88
[ 18.835722] lr : __might_sleep+0x7c/0x88
[ 18.841256] sp : ffff000008003cb0
[ 18.846751] x29: ffff000008003cb0 x28: 0000000000000000
[ 18.852269] x27: ffff00000938e000 x26: ffff800010283000
[ 18.857726] x25: ffff800010353280 x24: ffff00000868ef50
[ 18.863166] x23: 0000000000000000 x22: 0000000000000000
[ 18.868551] x21: 0000000000000000 x20: 000000000000038c
[ 18.873850] x19: ffff000008cd08c0 x18: 0000000000000010
[ 18.879081] x17: ffff000008a68cb0 x16: 0000000000000000
[ 18.884197] x15: 0000000000aaaaaa x14: 0e200e200e200e20
[ 18.889239] x13: 0000000000000001 x12: 00000000ffffffff
[ 18.894261] x11: ffff000008adfa48 x10: 0000000000000001
[ 18.899517] x9 : ffff0000092a0158 x8 : 0000000000000000
[ 18.904674] x7 : ffff00000812136c x6 : 0000000000000000
[ 18.909895] x5 : 0000000000000000 x4 : 0000000000000001
[ 18.915080] x3 : 0000000000000007 x2 : 0000000000000007
[ 18.920269] x1 : 99ab8e9ebb6c8500 x0 : 0000000000000000
[ 18.925443] Call trace:
[ 18.929904] __might_sleep+0x7c/0x88
[ 18.934311] __mutex_lock+0x60/0x870
[ 18.938687] mutex_lock_nested+0x1c/0x28
[ 18.943076] regmap_lock_mutex+0x10/0x18
[ 18.947453] regmap_read+0x38/0x70
[ 18.951842] dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[ 18.956269] __handle_irq_event_percpu+0xac/0x410
[ 18.960712] handle_irq_event_percpu+0x34/0x88
[ 18.965176] handle_irq_event+0x48/0x78
[ 18.969612] handle_fasteoi_irq+0xac/0x160
[ 18.974058] generic_handle_irq+0x24/0x38
[ 18.978501] __handle_domain_irq+0x60/0xb8
[ 18.982938] gic_handle_irq+0x50/0xa0
[ 18.987351] el1_irq+0xb4/0x130
[ 18.991734] debug_lockdep_rcu_enabled+0x2c/0x30
[ 18.996180] schedule+0x38/0xa0
[ 19.000609] schedule_timeout+0x3a8/0x510
[ 19.005064] wait_for_common+0x15c/0x180
[ 19.009513] wait_for_completion+0x14/0x20
[ 19.013951] mmc_wait_for_req_done+0x28/0x168
[ 19.018402] mmc_wait_for_req+0xa8/0xe8
[ 19.022809] mmc_wait_for_cmd+0x64/0x98
[ 19.027177] mmc_io_rw_direct_host+0x94/0x130
[ 19.031563] mmc_io_rw_direct+0x10/0x18
[ 19.035922] sdio_enable_func+0xe8/0x1d0
[ 19.040294] btsdio_open+0x24/0xc0 [btsdio]
[ 19.044742] hci_dev_do_open+0x64/0x598 [bluetooth]
[ 19.049228] hci_power_on+0x50/0x270 [bluetooth]
[ 19.053687] process_one_work+0x2a0/0x6e0
[ 19.058143] worker_thread+0x40/0x448
[ 19.062608] kthread+0x12c/0x130
[ 19.067064] ret_from_fork+0x10/0x1c
[ 19.071513] irq event stamp: 12
[ 19.075937] hardirqs last enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
[ 19.083560] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
[ 19.091401] softirqs last enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
[ 19.100801] softirqs last disabled at (0): [<0000000000000000>] (null)
[ 19.108135] ---[ end trace 38c4920787b88c75 ]---
So, fix this by enabling the fast_io option in our regmap config so that
regmap uses spinlocks for locking instead of mutexes.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 3f68be7d8e96 ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.12+
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181124191238.28276-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Since Linux 4.17, calls to drm_crtc_vblank_on/off are mandatory, and we get
a warning when ctrc is disabled :
" driver forgot to call drm_crtc_vblank_off()"
But, the vsync IRQ was not totally disabled due the transient hardware
state and specific interrupt line, thus adding proper IRQ masking from
the HHI system control registers.
The last change fixes a race condition introduced by calling the added
drm_crtc_vblank_on/off when an HPD event occurs from the HDMI connector,
triggering a WARN_ON() in the _atomic_begin() callback when the CRTC
is disabled, thus also triggering a WARN_ON() in drm_vblank_put() :
WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/meson/meson_crtc.c:157 meson_crtc_atomic_begin+0x78/0x80
[...]
Call trace:
meson_crtc_atomic_begin+0x78/0x80
drm_atomic_helper_commit_planes+0x140/0x218
drm_atomic_helper_commit_tail+0x38/0x80
commit_tail+0x7c/0x80
drm_atomic_helper_commit+0xdc/0x150
drm_atomic_commit+0x54/0x60
restore_fbdev_mode_atomic+0x198/0x238
restore_fbdev_mode+0x6c/0x1c0
drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xf0
drm_fb_helper_set_par+0x34/0x60
drm_fb_helper_hotplug_event.part.28+0xb8/0xc8
drm_fbdev_client_hotplug+0xa4/0xe0
drm_client_dev_hotplug+0x90/0xe0
drm_kms_helper_hotplug_event+0x3c/0x48
drm_helper_hpd_irq_event+0x134/0x168
dw_hdmi_top_thread_irq+0x3c/0x50
[...]
WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/drm_vblank.c:1026 drm_vblank_put+0xb4/0xc8
[...]
Call trace:
drm_vblank_put+0xb4/0xc8
drm_crtc_vblank_put+0x24/0x30
drm_atomic_helper_wait_for_vblanks.part.9+0x130/0x2b8
drm_atomic_helper_commit_tail+0x68/0x80
[...]
The issue is that vblank need to be enabled in any occurrence of :
- atomic_enable()
- atomic_begin() and state->enable == true, which was not the case
Moving the CRTC enable code to a common function and calling in one of
these occurrence solves this race condition and makes sure vblank is
enabled in each call to _atomic_begin() from the HPD event leading to
drm_atomic_helper_commit_planes().
To Summarize :
- Make sure that the CRTC code will call the drm_crtc_vblank_on()/off()
- *Really* mask the Vsync IRQ
- Initialize and enable vblank at the first
atomic_begin()/_atomic_enable()
Cc: stable@vger.kernel.org # 4.17+
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
[fixed typos+added cc for stable]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181122160103.10993-1-narmstrong@baylibre.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
When drm_new_set_master() fails, set is_master to 0, to prevent a
possible NULL pointer deref.
Here is a problematic flow: we check is_master in drm_is_current_master(),
then proceed to call drm_lease_owner() passing master. If we do not restore
is_master status when drm_new_set_master() fails, we may have a situation
in which is_master will be 1 and master itself, NULL, leading to the deref
of a NULL pointer in drm_lease_owner().
This fixes the following OOPS, observed on an ArchLinux running a 4.19.2
kernel:
[ 97.804282] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
[ 97.807224] PGD 0 P4D 0
[ 97.807224] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 97.807224] CPU: 0 PID: 1348 Comm: xfwm4 Tainted: P OE 4.19.2-arch1-1-ARCH #1
[ 97.807224] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./AB350 Pro4, BIOS P5.10 10/16/2018
[ 97.807224] RIP: 0010:drm_lease_owner+0xd/0x20 [drm]
[ 97.807224] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44
[ 97.807224] RSP: 0018:ffffb8cf08e07bb0 EFLAGS: 00010202
[ 97.807224] RAX: 0000000000000000 RBX: ffff9cf0f2586c00 RCX: ffff9cf0f2586c88
[ 97.807224] RDX: ffff9cf0ddbd8000 RSI: 0000000000000000 RDI: 0000000000000000
[ 97.807224] RBP: ffff9cf1040e9800 R08: 0000000000000000 R09: 0000000000000000
[ 97.807224] R10: ffffdeb30fd5d680 R11: ffffdeb30f5d6808 R12: ffff9cf1040e9888
[ 97.807224] R13: 0000000000000000 R14: dead000000000200 R15: ffff9cf0f2586cc8
[ 97.807224] FS: 00007f4145513180(0000) GS:ffff9cf10ea00000(0000) knlGS:0000000000000000
[ 97.807224] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 97.807224] CR2: 0000000000000080 CR3: 00000003d7548000 CR4: 00000000003406f0
[ 97.807224] Call Trace:
[ 97.807224] drm_is_current_master+0x1a/0x30 [drm]
[ 97.807224] drm_master_release+0x3e/0x130 [drm]
[ 97.807224] drm_file_free.part.0+0x2be/0x2d0 [drm]
[ 97.807224] drm_open+0x1ba/0x1e0 [drm]
[ 97.807224] drm_stub_open+0xaf/0xe0 [drm]
[ 97.807224] chrdev_open+0xa3/0x1b0
[ 97.807224] ? cdev_put.part.0+0x20/0x20
[ 97.807224] do_dentry_open+0x132/0x340
[ 97.807224] path_openat+0x2d1/0x14e0
[ 97.807224] ? mem_cgroup_commit_charge+0x7a/0x520
[ 97.807224] do_filp_open+0x93/0x100
[ 97.807224] ? __check_object_size+0x102/0x189
[ 97.807224] ? _raw_spin_unlock+0x16/0x30
[ 97.807224] do_sys_open+0x186/0x210
[ 97.807224] do_syscall_64+0x5b/0x170
[ 97.807224] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 97.807224] RIP: 0033:0x7f4147b07976
[ 97.807224] Code: 89 54 24 08 e8 7b f4 ff ff 8b 74 24 0c 48 8b 3c 24 41 89 c0 44 8b 54 24 08 b8 01 01 00 00 89 f2 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 77 30 44 89 c7 89 44 24 08 e8 a6 f4 ff ff 8b 44
[ 97.807224] RSP: 002b:00007ffcced96ca0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
[ 97.807224] RAX: ffffffffffffffda RBX: 00005619d5037f80 RCX: 00007f4147b07976
[ 97.807224] RDX: 0000000000000002 RSI: 00005619d46b969c RDI: 00000000ffffff9c
[ 98.040039] RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000000
[ 98.040039] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000024
[ 98.040039] R13: 0000000000000012 R14: 00005619d5035950 R15: 0000000000000012
[ 98.040039] Modules linked in: nct6775 hwmon_vid algif_skcipher af_alg nls_iso8859_1 nls_cp437 vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common arc4 videodev media snd_usb_audio snd_hda_codec_hdmi snd_usbmidi_lib snd_rawmidi snd_seq_device mousedev input_leds iwlmvm mac80211 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec edac_mce_amd kvm_amd snd_hda_core kvm iwlwifi snd_hwdep r8169 wmi_bmof cfg80211 snd_pcm irqbypass snd_timer snd libphy soundcore pinctrl_amd rfkill pcspkr sp5100_tco evdev gpio_amdpt k10temp mac_hid i2c_piix4 wmi pcc_cpufreq acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv(OE) msr sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto uas usb_storage dm_crypt hid_generic usbhid hid
[ 98.040039] dm_mod raid1 md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel aes_x86_64 libata crypto_simd cryptd glue_helper ccp xhci_pci rng_core scsi_mod xhci_hcd nvidia_drm(POE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart nvidia_uvm(POE) nvidia_modeset(POE) nvidia(POE) ipmi_devintf ipmi_msghandler
[ 98.040039] CR2: 0000000000000080
[ 98.040039] ---[ end trace 3b65093b6fe62b2f ]---
[ 98.040039] RIP: 0010:drm_lease_owner+0xd/0x20 [drm]
[ 98.040039] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44
[ 98.040039] RSP: 0018:ffffb8cf08e07bb0 EFLAGS: 00010202
[ 98.040039] RAX: 0000000000000000 RBX: ffff9cf0f2586c00 RCX: ffff9cf0f2586c88
[ 98.040039] RDX: ffff9cf0ddbd8000 RSI: 0000000000000000 RDI: 0000000000000000
[ 98.040039] RBP: ffff9cf1040e9800 R08: 0000000000000000 R09: 0000000000000000
[ 98.040039] R10: ffffdeb30fd5d680 R11: ffffdeb30f5d6808 R12: ffff9cf1040e9888
[ 98.040039] R13: 0000000000000000 R14: dead000000000200 R15: ffff9cf0f2586cc8
[ 98.040039] FS: 00007f4145513180(0000) GS:ffff9cf10ea00000(0000) knlGS:0000000000000000
[ 98.040039] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 98.040039] CR2: 0000000000000080 CR3: 00000003d7548000 CR4: 00000000003406f0
Signed-off-by: Sergio Correia <sergio@correia.cc>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181122053329.2692-1-sergio@correia.cc
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I
accidentally introduced into DRM two years ago.
Pretend we have a topology like this:
|- DP-1: mst_primary
|- DP-4: active display
|- DP-5: disconnected
|- DP-6: active hub
|- DP-7: active display
|- DP-8: disconnected
|- DP-9: disconnected
If we unplug DP-6, the topology starting at DP-7 will be destroyed but
it's payloads will live on in DP-1's VCPI allocations and thus require
removal. However, this removal currently fails because
drm_dp_update_payload_part1() will (rightly so) try to validate the port
before accessing it, fail then abort. If we keep going, eventually we
run the MST hub out of bandwidth and all new allocations will start to
fail (or in my case; all new displays just start flickering a ton).
We could just teach drm_dp_update_payload_part1() not to drop the port
ref in this case, but then we also need to teach
drm_dp_destroy_payload_step1() to do the same thing, then hope no one
ever adds anything to the that requires a validated port reference in
drm_dp_destroy_connector_work(). Kind of sketchy.
So let's go with a more clever solution: any port that
drm_dp_destroy_connector_work() interacts with is guaranteed to still
exist in memory until we say so. While said port might not be valid we
don't really care: that's the whole reason we're destroying it in the
first place! So, teach drm_dp_get_validated_port_ref() to use the all
mighty current_work() function to avoid attempting to validate ports
from the context of mgr->destroy_connector_work. I can't see any
situation where this wouldn't be safe, and this avoids having to play
whack-a-mole in the future of trying to work around port validation.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 263efde31f97 ("drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()")
Reported-by: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: <stable@vger.kernel.org> # v4.6+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181113224613.28809-1-lyude@redhat.com
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
There is a spelling mistake in the module description text and
a comment too, fix them. Also line break overly long comment.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Remove dce/dce_mem_input.h which is included more than once
Signed-off-by: Brajeswar Ghosh <brajeswar.linux@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Remove gca/gfx_8_0_enum.h which is included more than once
Signed-off-by: Brajeswar Ghosh <brajeswar.linux@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Remove drm/drm_fb_helper.h which is included more than once
Signed-off-by: Brajeswar Ghosh <brajeswar.linux@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
ACPI ATIF has a function called query
backlight transfer characteristics. Among the
information returned by this function is
the minimum and maximum input signals for the
backlight
Call that function on ACPI init. When DM
backlight device is updated, copy over the
backlight caps into DM, but only once. Use
the backlight caps in the backlight-to-dc
calculation
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The ACPI interface in AMD was a few years out of date
and contained some unused and deprecated functions
Remove functions: Select Active Displays, Get Lid State,
Get TV Standard, Set TV Standard, Get Panel Expansion Mode,
Set Panel Expansion Mode, Get Graphics Device Types
Add functions: Query Backlight Transfer Characteristics,
Ready To Undock Notification
Changed functions: Get System Parameters,
Get System BIOS Requests
All changes are right from the standard
ATI ACPI Control Methods V0.44
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Adaptive Backlight Management (ABM) is a feature
that reduces backlight level to save power, while
increasing pixel contrast and pixel luminance
to maintain readability and image quality.
ABM will adjust in response to the
pixel luminance of the displayed content.
ABM is made available as a drm property on eDP
monitors called "abm level", which ranges from 0 to 4.
When this property is set to 0, ABM is off. Levels 1
to 4 represent different ranges of backlight reduction.
At higher levels both the backlight reduction and pixel
adjustment will be greater.
ABM requires DMCU firmware, which is currently available for
Raven ASICs only. If the feature does not work, please
ensure your firmware is up to date.
v2:
Fix commit message, only attach property if DMCU loaded
v3:
Store ABM level in crtc state to accommodate dc
v4:
Fix ABM saving on dpms cycle
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
DMCU IRAM must be loaded by the driver before DMCU
can function.
Move the IRAM code out of the shadows and into a new file
modules/power/power_helpers.c
The IRAM table contains the backlight curve and ABM parameters
Add this new file to the Makefiles
Call dmcu_load_iram in late init of DM
Move struct dmcu_version from dc.h to dmcu.h to allow
dmcu to be included on its own
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c:49 amdgpu_allocate_static_csa()
error: uninitialized symbol 'ptr'.
the test if (!bo) doesn't work, as the bo is a pointer to a pointer.
if bo create failed, the *bo will be set to NULL.
so change to test *bo.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We observe black lines (underflow) on display when playing a
4K video with UVD. On Disabling Low memory P state this issue is
not seen.
In this patch ,disabling low memory P state only when video
size >= 4k.
Multiple runs of power measurement shows no impact
Signed-off-by: suresh guttula <suresh.guttula@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add hwmgr callback "update_nbdpm_pstate".This will use to access
"cz_nbdpm_pstate_enable_disable" function to enable/disable low
memory pstate.
Signed-off-by: suresh guttula <suresh.guttula@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.
Reason for revert:
This patch sends msg PPSMC_MSG_DisableLowMemoryPstate(0x002e)
in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON (0x0008).
This leads to SMU failing to service the request as it is
dependent on UVD to be powered ON, since it accesses UVD
registers.
This msg should ideally be sent only when the UVD is about to decode
a 4k video.
Signed-off-by: Shirish S <shirish.s@amd.com>
Signed-off-by: suresh guttula <suresh.guttula@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Before:
We use drm_match_cea_mode() to get the vic for any mode we
want to set, most of the time vic will be different for the new mode.
DC uses memcmp to check if timing changed, in this case DC will
say timing changed and we endup doing a full modeset.
Current:
Now we check if !RMX_OFF and old_refresh == new_refresh if so
we copy the vic from old timing. In a case where we are currently on
a lower timing and want to change to higher mode, stream->dst will be
different and cause us to do a full modeset, which is what we want.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Setting this allows for display scaling by default
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We may be simply restarting too fast for the culmudgeonly gen3/gen4 as
we still see missing interrupts following a reset. So let's try
restarting a little slower, first wake up the ring empty and then tell
it about the work it has to perform.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181126122821.4537-1-chris@chris-wilson.co.uk
|
|
drm-intel-fixes
gvt-fixes-2018-11-26
- Fix engine check for correct MOCS regs load (Xinyun)
- Fix rpm locking for vGPU ggtt init (Henry)
- Fix use-after-free when destroy partial ggtt entries (Chris)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181126021820.GL12743@zhen-hp.sh.intel.com
|
|
Group start/stop is controlled by the DRES and DEN bits of DSYSR0 for
the first group and DSYSR2 for the second group. On most DU instances,
this maps to the first CRTC of the group. On M3-N, however, DU2 doesn't
exist, but DSYSR2 does. There is no CRTC object there that maps to the
correct DSYSR register.
Commit 9144adc5e5a9 ("drm: rcar-du: Cache DSYSR value to ensure known
initial value") switched group start/stop from using group read/write
access to DSYSR to a CRTC-based API to cache the DSYSR value. While
doing so, it introduced a regression on M3-N by accessing DSYSR3 instead
of DSYSR2 to start/stop the second group.
To fix this, access the DSYSR register directly through group read/write
if the SoC is missing the first DU channel of the group. Keep using the
rcar_du_crtc_dsysr_clr_set() function otherwise, to retain the DSYSR
caching feature.
Fixes: 9144adc5e5a9 ("drm: rcar-du: Cache DSYSR value to ensure known initial value")
Reported-by: Hoan Nguyen An <na-hoan@jinso.co.jp>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
|
|
This patch unifies the naming of DRM functions for reference counting as
requested on Documentation/gpu/todo.rst
Signed-off-by: Fernando Ramos <greenfoo@gluegarage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-6-greenfoo@gluegarage.com
|
|
There are no more places where this (deprecated) function is being used
from, thus it can now be removed.
Signed-off-by: Fernando Ramos <greenfoo@gluegarage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-5-greenfoo@gluegarage.com
|
|
This patch unifies the naming of DRM functions for reference counting as
requested on Documentation/gpu/todo.rst
Signed-off-by: Fernando Ramos <greenfoo@gluegarage.com>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-4-greenfoo@gluegarage.com
|
|
Currently, we convert the error state into a string every time we read
from sysfs (and sysfs reads in page size (4KiB) chunks). We do try to
window the string and only capture the portion that is being read, but
that means that we must always convert up to the window to find the
start. For a very large error state bordering on EXEC_OBJECT_CAPTURE
abuse, this is noticeable as it degrades to O(N^2)!
As we do not have a convenient hook for sysfs open(), and we would like
to keep the lazy conversion into a string, do the conversion of the
whole string on the first read and keep the string until the error state
is freed.
v2: Don't double advance simple_read_from_buffer
v3: Due to extreme pain of lack of vrealloc, use a scatterlist
v4: Keep the forward iterator loosely cached
v5: Stylistic improvements to reduce patch size
Reported-by: Jason Ekstrand <jason@jlekstrand.net>
Testcase: igt/gem_exec_capture/many*
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123132325.26541-1-chris@chris-wilson.co.uk
|
|
For real commits we WARN if ->hw_done hasn't been completed by the time
drm_atomic_helper_commit_cleanup_done() is called. Let's do the same for
the fake commit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181122143412.11655-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Consider the following scenario:
1. nonblocking enable crtc
2. wait for the event
3. nonblocking disable crtc
On i915 this can lead to a spurious -EBUSY from step 3 on
account of non-enabled planes getting the fake_commit in step 1
and we don't complete the fake_commit-> flip_done until
drm_atomic_helper_commit_hw_done() which can happen a long
time after the flip event was sent out.
This will become somewhat easy to hit on SKL+ once we start
to add all the planes for the crtc to every modeset commit
for the purposes of forcing a watermark register programming
[1].
To make the race a little less pronounced let's complete
fake_commit->flip_done after drm_atomic_helper_wait_for_flip_done().
For the single crtc case this should make the race quite
theoretical, assuming drm_atomic_helper_wait_for_flip_done()
actually has to wait for the real commit flip_done. In case
the real commit flip_done gets completed singificantly before
drm_atomic_helper_wait_for_flip_done(), or we are dealing with
multiple crtcs whose vblanks don't line up nicely the race still
exists.
[1] https://patchwork.freedesktop.org/patch/262670/
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 080de2e5be2d ("drm/atomic: Check for busy planes/connectors before setting the commit")
Testcase: igt/kms_cursor_legacy/*nonblocking-modeset-vs-cursor-atomic
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181122143412.11655-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
The hardware requires the HDSR and VDSR registers to be set to 1 or
higher. This translates to a minimum combined horizontal sync and back
porch of 20 pixels and a minimum vertical back porch of 3 lines. Reject
modes that fail those requirements.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
|
|
The rcar-du driver supports probe deferral for external clocks, but
implements it badly by checking the wrong pointer due to a bad copy and
paste. Fix it.
While at it, reject invalid clocks outright for DU channels that have a
display PLL, as the external clock is mandatory in that case. This
avoids a WARN_ON() at runtime.
Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel clock")
Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
|
