| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add binding for the idk-2121wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1583869169-1006-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
We actually expect this to return a 0 on success, or negative error code
on failure. In order to do that, we check whether or not we managed to
write the whole GUID and then return 0 if so, otherwise return a
negative error code. Also, let's add an error message here so it's a
little more obvious when this fails in the middle of a link address
probe.
This should fix issues with certain MST hubs seemingly stopping for no
reason in the middle of the link address probe process.
Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings")
Cc: Benjamin Gaignard <benjamin.gaignard@st.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-3-lyude@redhat.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Noticed this while having some problems with hubs sometimes not being
detected on the first plug. Every single dpcd read or write function
returns the number of bytes transferred on success or a negative error
code, except apparently for drm_dp_mst_dpcd_write() - which returns 0 on
success.
There's not really any good reason for this difference that I can tell,
and having the two functions give differing behavior means that
drm_dp_dpcd_write() will end up returning 0 on success for MST devices,
but the number of bytes transferred for everything else.
So, fix that and update the kernel doc.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 2f221a5efed4 ("drm/dp_mst: Add MST support to DP DPCD R/W functions")
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mikita Lipski <mikita.lipski@amd.com>
Cc: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-2-lyude@redhat.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
There are two variants of the COM37H3M panel.
The older one's COM37H3M05DTC data sheet specifies:
MIN TYP MAX
CLK frequency fCLK -- 22.4 26.3 MHz (in VGA mode)
VSYNC Frequency fVSYNC 54 60 66 Hz
VSYNC cycle time tv -- 650 -- H
HSYNC frequency fHSYNC -- 39.3 -- kHz
HSYNC cycle time th -- 570 -- CLK
The newer one's COM37H3M99DTC data sheet says:
MIN TYP MAX
CLK frequency fCLK 18 19.8 27 MHz
VSYNC Frequency fVSYNC 54 60 66 Hz
VSYNC cycle time tv 646 650 700 H
HSYNC frequency fHSYNC -- 39.0 50.0 kHz
HSYNC cycle time th 504 508 630 CLK
So we choose a parameter set that lies within the specs
of both variants. We start at .vrefresh = 60,
choose .htotal = 570 and .vtotal = 650 and end up
in a clock of 22.230 MHz.
Reported-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/e63a0533ad5b5142373437ef758aedbdb716152d.1583826198.git.hns@goldelico.com
|
|
The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309184210.10042-1-laurent.pinchart@ideasonboard.com
|
|
Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system. This reduce the amount of time
we spend waiting on the semaphore used to synchronise the start of the
bonded payload.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306133852.3420322-3-chris@chris-wilson.co.uk
|
|
In Pete Goodliffe words, "You can improve a system by adding new code. You
can also improve a system by removing code" - In this case, commit
"202b52b7fbf70" added new code to initialize end of the node. So, there
is no need for duplicated initialization, and this patch simply removes it.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309151156.25040-1-akeem.g.abodunrin@intel.com
|
|
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
In addition if pixel stream down-sampling, the Y Cb Cr components must
also be mapped differently to align with the HDMI2.0 specifications.
This mode needs a different clock generation scheme since the TMDS PHY
clock must match the 10x ratio with the YUV420 pixel clock, but
the video encoder must run at 2x the pixel clock.
This patch enables the bridge bus format negociation, and handles
the YUV420 case if selected by the negociation.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-12-narmstrong@baylibre.com
|
|
This patch adds clocking support for the YUV420 output from the
Amlogic Meson SoCs Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
This mode needs a different clock generation scheme since the TMDS PHY
clock must match the 10x ratio with the YUV420 pixel clock, but
the video encoder must run at 2x the pixel clock.
This patch adds the TMDS PHY clock value in all the video clock setup
in order to better support these specific uses cases and switch
to the Common Clock framework for clocks handling in the future.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-11-narmstrong@baylibre.com
|
|
This patch adds encoding support for the YUV420 output from the
Amlogic Meson SoCs Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
In addition if pixel stream down-sampling, the Y Cb Cr components must
also be mapped differently to align with the HDMI2.0 specifications.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-10-narmstrong@baylibre.com
|
|
To allow using formats from negotiation, stop enforcing input_bus_format
in the private dw-plat-data struct.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-9-narmstrong@baylibre.com
|
|
Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local
bridge, connecting it to the dw-hdmi bridge, then implement the
atomic_get_input_bus_fmts/atomic_get_output_bus_fmts.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-8-narmstrong@baylibre.com
|
|
Before switching to bridge funcs, make sure drm_display_mode is passed
as const to the venc functions.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-7-narmstrong@baylibre.com
|
|
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-6-narmstrong@baylibre.com
|
|
Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate
the possible output and input formats for the current mode and monitor,
and use the negotiated formats in a basic atomic_check callback.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-5-narmstrong@baylibre.com
|
|
Add atomic_duplicate_state/atomic_destroy_state/atomic_reset bridge
funcs to allow setup of atomic bridge state.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-4-narmstrong@baylibre.com
|
|
Add the max_bpc property to the dw-hdmi connector to prepare support
for 10, 12 & 16bit output support.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-3-narmstrong@baylibre.com
|
|
Configure the correct mtmdsclock for deep colors to prepare support
for 10, 12 & 16bit output.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-2-narmstrong@baylibre.com
|
|
[ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
[ 206.875654]
[ 206.875666] race at unknown origin, with read to 0xffff8881f7644480 of 8 bytes by task 703 on cpu 3:
[ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
[ 206.876130] __bump_priority+0x63/0x80 [i915]
[ 206.876361] __i915_sched_node_add_dependency+0x258/0x300 [i915]
[ 206.876593] i915_sched_node_add_dependency+0x50/0xa0 [i915]
[ 206.876824] i915_request_await_dma_fence+0x1da/0x530 [i915]
[ 206.877057] i915_request_await_object+0x2fe/0x470 [i915]
[ 206.877287] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[ 206.877517] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 206.877535] drm_ioctl_kernel+0xe4/0x120
[ 206.877549] drm_ioctl+0x297/0x4c7
[ 206.877563] ksys_ioctl+0x89/0xb0
[ 206.877577] __x64_sys_ioctl+0x42/0x60
[ 206.877591] do_syscall_64+0x6e/0x2c0
[ 206.877606] entry_SYSCALL_64_after_hwframe+0x44/0xa9
v2: Be safe and include mb
References: https://gitlab.freedesktop.org/drm/intel/issues/1318
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309170540.10332-1-chris@chris-wilson.co.uk
|
|
gmbus/aux may be clocked by cdclk, thus we should make sure no
transfers are ongoing while the cdclk frequency is being changed.
We do that by simply grabbing all the gmbus/aux mutexes. No one
else should be holding any more than one of those at a time so
the lock ordering here shouldn't matter.
v2: Use mutex_lock_nest_lock() (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302174442.5803-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The low level read_lut() functions don't need the entire crtc state
as they know exactly what they're reading. Just need to pass in the
crtc to get at the pipe. This now neatly mirrors the load_lut()
direction.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-10-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
PIPEGCMAX is a 11.6 (or 1.16 if you will) value. Ie. it can
represent a value of 1.0 when the maximum we can store in the
software LUT is 0.ffff. Clamp the value so that it gets
saturated to the max the uapi supports.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-9-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
Extract all the 'hw value -> LUT entry' stuff into small helpers
to make the main 'read out the entire LUT' loop less bogged down
by such mundane details.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-8-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
A variable called 'i' having an unsigned type is just looking for
trouble, and using a sized type generally makes no sense either.
Change all of them to just plain old int. And do the same for some
'lut_size' variables which generally provide the loop end codition
for 'i'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-7-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
let's rename it to reflect that fact. This also mirrors
the other direction's chv_load_cgm_gamma().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-6-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
We're talking about LUT contents here so let's call the thing
'lut' rather than 'blob_data'. This is the name the load_lut()
code used before already.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-5-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
To mirror the load_luts path let's clone an ilk+ version
from i9xx_read_lut_8(). I guess the extra branch isn't a huge
issue but feels better to make a clean split.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-4-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
Split i9xx_load_luts_internal() into neat gmch vs. ilk+ chunks.
Avoids at least one branch in the inner loop, and makes life
a bit less confusing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-3-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
Only load the CGM CSC based on the cgm_mode bit like we
do with the gamma/degamma LUTs. And make the function
naming and arguments consistent as well.
TODO: the code to convert the coefficients look totally
bogus. IIRC CHV uses two's complement format but the code
certainly doesn't generate that, so probably negative
coefficients are totally busted.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-2-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
|
|
We read the current state of intel_rps.active outside of the lock, so
mark up the racy access.
[ 525.037073] BUG: KCSAN: data-race in intel_rps_boost [i915] / intel_rps_park [i915]
[ 525.037091]
[ 525.037103] write to 0xffff8881f145efa1 of 1 bytes by task 192 on cpu 2:
[ 525.037331] intel_rps_park+0x72/0x230 [i915]
[ 525.037552] __gt_park+0x61/0xa0 [i915]
[ 525.037771] ____intel_wakeref_put_last+0x42/0x90 [i915]
[ 525.037991] __intel_wakeref_put_work+0xd3/0xf0 [i915]
[ 525.038008] process_one_work+0x3b1/0x690
[ 525.038022] worker_thread+0x80/0x670
[ 525.038037] kthread+0x19a/0x1e0
[ 525.038051] ret_from_fork+0x1f/0x30
[ 525.038062]
[ 525.038074] read to 0xffff8881f145efa1 of 1 bytes by task 733 on cpu 3:
[ 525.038304] intel_rps_boost+0x67/0x1f0 [i915]
[ 525.038535] i915_request_wait+0x562/0x5d0 [i915]
[ 525.038764] i915_gem_object_wait_fence+0x81/0xa0 [i915]
[ 525.038994] i915_gem_object_wait_reservation+0x489/0x520 [i915]
[ 525.039224] i915_gem_wait_ioctl+0x167/0x2b0 [i915]
[ 525.039241] drm_ioctl_kernel+0xe4/0x120
[ 525.039255] drm_ioctl+0x297/0x4c7
[ 525.039269] ksys_ioctl+0x89/0xb0
[ 525.039282] __x64_sys_ioctl+0x42/0x60
[ 525.039296] do_syscall_64+0x6e/0x2c0
[ 525.039311] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309113623.24208-1-chris@chris-wilson.co.uk
|
|
[ 120.176548] BUG: KCSAN: data-race in __i915_schedule [i915] / effective_prio [i915]
[ 120.176566]
[ 120.176577] write to 0xffff8881e35e6540 of 4 bytes by task 730 on cpu 3:
[ 120.176792] __i915_schedule+0x63e/0x920 [i915]
[ 120.177007] __bump_priority+0x63/0x80 [i915]
[ 120.177220] __i915_sched_node_add_dependency+0x258/0x300 [i915]
[ 120.177438] i915_sched_node_add_dependency+0x50/0xa0 [i915]
[ 120.177654] i915_request_await_dma_fence+0x1da/0x530 [i915]
[ 120.177867] i915_request_await_object+0x2fe/0x470 [i915]
[ 120.178081] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[ 120.178292] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 120.178309] drm_ioctl_kernel+0xe4/0x120
[ 120.178322] drm_ioctl+0x297/0x4c7
[ 120.178335] ksys_ioctl+0x89/0xb0
[ 120.178348] __x64_sys_ioctl+0x42/0x60
[ 120.178361] do_syscall_64+0x6e/0x2c0
[ 120.178375] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 120.178387]
[ 120.178397] read to 0xffff8881e35e6540 of 4 bytes by interrupt on cpu 2:
[ 120.178606] effective_prio+0x25/0xc0 [i915]
[ 120.178812] process_csb+0xe8b/0x10a0 [i915]
[ 120.179021] execlists_submission_tasklet+0x30/0x170 [i915]
[ 120.179038] tasklet_action_common.isra.0+0x42/0xa0
[ 120.179053] __do_softirq+0xd7/0x2cd
[ 120.179066] irq_exit+0xbe/0xe0
[ 120.179078] do_IRQ+0x51/0x100
[ 120.179090] ret_from_intr+0x0/0x1c
[ 120.179104] cpuidle_enter_state+0x1b8/0x5d0
[ 120.179117] cpuidle_enter+0x50/0x90
[ 120.179131] do_idle+0x1a1/0x1f0
[ 120.179145] cpu_startup_entry+0x14/0x16
[ 120.179158] start_secondary+0x120/0x180
[ 120.179172] secondary_startup_64+0xa4/0xb0
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309110934.868-5-chris@chris-wilson.co.uk
|
|
[ 145.927961] BUG: KCSAN: data-race in can_merge_rq [i915] / signal_irq_work [i915]
[ 145.927980]
[ 145.927992] write (marked) to 0xffff8881e513fab0 of 8 bytes by interrupt on cpu 2:
[ 145.928250] signal_irq_work+0x134/0x640 [i915]
[ 145.928268] irq_work_run_list+0xd7/0x120
[ 145.928283] irq_work_run+0x1d/0x50
[ 145.928300] smp_irq_work_interrupt+0x21/0x30
[ 145.928328] irq_work_interrupt+0xf/0x20
[ 145.928356] _raw_spin_unlock_irqrestore+0x34/0x40
[ 145.928596] execlists_submission_tasklet+0xde/0x170 [i915]
[ 145.928616] tasklet_action_common.isra.0+0x42/0xa0
[ 145.928632] __do_softirq+0xd7/0x2cd
[ 145.928646] irq_exit+0xbe/0xe0
[ 145.928665] do_IRQ+0x51/0x100
[ 145.928684] ret_from_intr+0x0/0x1c
[ 145.928699] schedule+0x0/0xb0
[ 145.928719] worker_thread+0x194/0x670
[ 145.928743] kthread+0x19a/0x1e0
[ 145.928765] ret_from_fork+0x1f/0x30
[ 145.928784]
[ 145.928796] read to 0xffff8881e513fab0 of 8 bytes by task 738 on cpu 1:
[ 145.929046] can_merge_rq+0xb1/0x100 [i915]
[ 145.929282] __execlists_submission_tasklet+0x866/0x25a0 [i915]
[ 145.929518] execlists_submit_request+0x2a4/0x2b0 [i915]
[ 145.929758] submit_notify+0x8f/0xc0 [i915]
[ 145.929989] __i915_sw_fence_complete+0x5d/0x3e0 [i915]
[ 145.930221] i915_sw_fence_complete+0x58/0x80 [i915]
[ 145.930453] i915_sw_fence_commit+0x16/0x20 [i915]
[ 145.930698] __i915_request_queue+0x60/0x70 [i915]
[ 145.930935] i915_gem_do_execbuffer+0x3997/0x4c20 [i915]
[ 145.931175] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 145.931194] drm_ioctl_kernel+0xe4/0x120
[ 145.931208] drm_ioctl+0x297/0x4c7
[ 145.931222] ksys_ioctl+0x89/0xb0
[ 145.931238] __x64_sys_ioctl+0x42/0x60
[ 145.931260] do_syscall_64+0x6e/0x2c0
[ 145.931275] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309110934.868-4-chris@chris-wilson.co.uk
|
|
[ 25.025543] BUG: KCSAN: data-race in __i915_request_create [i915] / process_csb [i915]
[ 25.025561]
[ 25.025573] write (marked) to 0xffff8881e85c1620 of 8 bytes by task 696 on cpu 1:
[ 25.025789] __i915_request_create+0x54b/0x5d0 [i915]
[ 25.026001] i915_request_create+0xcc/0x150 [i915]
[ 25.026218] i915_gem_do_execbuffer+0x2f70/0x4c20 [i915]
[ 25.026428] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 25.026445] drm_ioctl_kernel+0xe4/0x120
[ 25.026459] drm_ioctl+0x297/0x4c7
[ 25.026472] ksys_ioctl+0x89/0xb0
[ 25.026484] __x64_sys_ioctl+0x42/0x60
[ 25.026497] do_syscall_64+0x6e/0x2c0
[ 25.026510] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 25.026522]
[ 25.026532] read to 0xffff8881e85c1620 of 8 bytes by interrupt on cpu 2:
[ 25.026742] process_csb+0x8d6/0x1070 [i915]
[ 25.026949] execlists_submission_tasklet+0x30/0x170 [i915]
[ 25.026969] tasklet_action_common.isra.0+0x42/0xa0
[ 25.026984] __do_softirq+0xd7/0x2cd
[ 25.026997] irq_exit+0xbe/0xe0
[ 25.027009] do_IRQ+0x51/0x100
[ 25.027021] ret_from_intr+0x0/0x1c
[ 25.027033] poll_idle+0x3e/0x13b
[ 25.027047] cpuidle_enter_state+0x189/0x5d0
[ 25.027060] cpuidle_enter+0x50/0x90
[ 25.027074] do_idle+0x1a1/0x1f0
[ 25.027086] cpu_startup_entry+0x14/0x16
[ 25.027100] start_secondary+0x120/0x180
[ 25.027116] secondary_startup_64+0xa4/0xb0
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309110934.868-2-chris@chris-wilson.co.uk
|
|
During i915_request_retire() we decouple the i915_request.hwsp_seqno
from the intel_timeline so that it may be freed before the request is
released. However, we need to warn the compiler that the pointer may
update under its nose.
[ 171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fence [i915] / i915_request_retire [i915]
[ 171.438920]
[ 171.438932] write to 0xffff8881e7e28ce0 of 8 bytes by task 148 on cpu 2:
[ 171.439174] i915_request_retire+0x1ea/0x660 [i915]
[ 171.439408] retire_requests+0x7a/0xd0 [i915]
[ 171.439640] engine_retire+0xa1/0xe0 [i915]
[ 171.439657] process_one_work+0x3b1/0x690
[ 171.439671] worker_thread+0x80/0x670
[ 171.439685] kthread+0x19a/0x1e0
[ 171.439701] ret_from_fork+0x1f/0x30
[ 171.439721]
[ 171.439739] read to 0xffff8881e7e28ce0 of 8 bytes by task 696 on cpu 1:
[ 171.439990] i915_request_await_dma_fence+0x162/0x520 [i915]
[ 171.440230] i915_request_await_object+0x2fe/0x470 [i915]
[ 171.440467] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[ 171.440704] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 171.440722] drm_ioctl_kernel+0xe4/0x120
[ 171.440736] drm_ioctl+0x297/0x4c7
[ 171.440750] ksys_ioctl+0x89/0xb0
[ 171.440766] __x64_sys_ioctl+0x42/0x60
[ 171.440788] do_syscall_64+0x6e/0x2c0
[ 171.440802] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309110934.868-1-chris@chris-wilson.co.uk
|
|
AMDGPU statically sets priority for compute queues
at initialization so remove all the functions
responsible for changing compute queue priority dynamically.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Switch to appropriate sched list for an entity on priority override.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Implement drm_sched_entity_modify_sched() which modifies existing
sched_list with a different one. This is going to be helpful when
userspace changes priority of a ctx/entity then the driver can switch
to the corresponding HW scheduler list for that priority.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We were changing compute ring priority while rings were being used
before every job submission which is not recommended. This patch
sets compute queue priority at mqd initialization for gfx8, gfx9 and
gfx10.
Policy: make queue 0 of each pipe as high priority compute queue
High/normal priority compute sched lists are generated from set of high/normal
priority compute queues. At context creation, entity of compute queue
get a sched list from high or normal priority depending on ctx->priority
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fix version for navi12.
Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Problem Description:
Currently we are checking internal fused rev id with pci rev id. However, fused
internal rev id is the same on all raven2 parts (in which Dali and Pollock were
based on too), thus Pollock detection fails
Fix:
use the pci rev to preform the detection for bandwidth calculations.
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Aly-Tawfik <altawfik@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use the pci revision id rather than the asic silicon revision id.
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Aly-Tawfik <altawfik@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
CRTC in DPMS state off calls for low power state entry.
Support both atomic mode setting and pre-atomic mode setting.
v2: move comment
Acked-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The dpp2_get_optimal_number_of_taps function is never used. Removing
just for code cleaning up.
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
FEC capability query should not be affected by debugging decision on
whether to disable FEC. We should not determine if display supports FEC
by checking debug option.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
on some displays that prefer swapped polarity we were seeing L/R images
swapped because OTG_STEREO_SYNC_OUTPUT_POLARITY would always be mapped
to 0
[how]
fix initial dal3 implementation to properly update the polarity field
according to the crtc_stereo_flags (same as
OTG_STEREO_EYE_FLAG_POLARITY)
Signed-off-by: Martin Leung <martin.leung@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Raven provides retimer feature support that requires i2c interaction in
order to make it work well, all settings required for this configuration
are loaded from the Atom bios which include the i2c address. If the
retimer feature is not available, we should abort the attempt to set
this feature, otherwise, it makes the following line return
I2C_CHANNEL_OPERATION_NO_RESPONSE:
i2c_success = i2c_write(pipe_ctx, slave_address, buffer, sizeof(buffer));
...
if (!i2c_success)
ASSERT(i2c_success);
This ends up causing problems with hotplugging HDMI displays on Raven,
and causes retimer settings to warn like so:
WARNING: CPU: 1 PID: 429 at
drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link.c:1998
write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Modules linked in:
edac_mce_amd ccp kvm irqbypass binfmt_misc crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic
ledtrig_audio snd_hda_codec_hdmi snd_hda_intel amdgpu(+) snd_hda_codec
snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
snd_rawmidi aesni_intel snd_seq amd_iommu_v2 gpu_sched aes_x86_64
crypto_simd cryptd glue_helper snd_seq_device ttm drm_kms_helper
snd_timer eeepc_wmi wmi_bmof asus_wmi sparse_keymap drm mxm_wmi snd
k10temp fb_sys_fops syscopyarea sysfillrect sysimgblt soundcore joydev
input_leds mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables
x_tables autofs4 igb i2c_algo_bit hid_generic usbhid i2c_piix4 dca ahci
hid libahci video wmi gpio_amdpt gpio_generic CPU: 1 PID: 429 Comm:
systemd-udevd Tainted: G W 5.2.0-rc1sept162019+ #1
Hardware name: System manufacturer System Product Name/ROG STRIX B450-F
GAMING, BIOS 2605 08/06/2019
RIP: 0010:write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu]
Code: ff 0f b6 4d ce 44 0f b6 45 cf 44 0f b6 c8 45 89 cf 44 89 e2 48 c7
c6 f0 34 bc c0 bf 04 00 00 00 e8 63 b0 90 ff 45 84 ff 75 02 <0f> 0b 42
0f b6 04 73 8d 50 f6 80 fa 02 77 8c 3c 0a 0f 85 c8 00 00 RSP:
0018:ffffa99d02726fd0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa99d02727035 RCX: 0000000000000006
RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff976acc857440
RBP: ffffa99d02727018 R08: 0000000000000002 R09: 000000000002a600
R10: ffffe90610193680 R11: 00000000000005e3 R12: 000000000000005d
R13: ffff976ac4b201b8 R14: 0000000000000001 R15: 0000000000000000
FS: 00007f14f99e1680(0000) GS:ffff976acc840000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fdf212843b8 CR3: 0000000408906000 CR4: 00000000003406e0
Call Trace:
core_link_enable_stream+0x626/0x680 [amdgpu]
dce110_apply_ctx_to_hw+0x414/0x4e0 [amdgpu]
dc_commit_state+0x331/0x5e0 [amdgpu]
? drm_calc_timestamping_constants+0xf9/0x150 [drm]
amdgpu_dm_atomic_commit_tail+0x395/0x1e00 [amdgpu]
? dm_plane_helper_prepare_fb+0x20c/0x280 [amdgpu]
commit_tail+0x42/0x70 [drm_kms_helper]
drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper]
amdgpu_dm_atomic_commit+0x95/0xa0 [amdgpu]
drm_atomic_commit+0x4a/0x50 [drm]
restore_fbdev_mode_atomic+0x1c0/0x1e0 [drm_kms_helper]
restore_fbdev_mode+0x4c/0x160 [drm_kms_helper]
? _cond_resched+0x19/0x40
drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0 [drm_kms_helper]
drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
fbcon_init+0x471/0x630
visual_init+0xd5/0x130
do_bind_con_driver+0x20a/0x430
do_take_over_console+0x7d/0x1b0
do_fbcon_takeover+0x5c/0xb0
fbcon_event_notify+0x6cd/0x8a0
notifier_call_chain+0x4c/0x70
blocking_notifier_call_chain+0x43/0x60
fb_notifier_call_chain+0x1b/0x20
register_framebuffer+0x254/0x360
__drm_fb_helper_initial_config_and_unlock+0x2c5/0x510 [drm_kms_helper]
drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper]
amdgpu_fbdev_init+0xcd/0x100 [amdgpu]
amdgpu_device_init+0x1156/0x1930 [amdgpu]
amdgpu_driver_load_kms+0x8d/0x2e0 [amdgpu]
drm_dev_register+0x12b/0x1c0 [drm]
amdgpu_pci_probe+0xd3/0x160 [amdgpu]
local_pci_probe+0x47/0xa0
pci_device_probe+0x142/0x1b0
really_probe+0xf5/0x3d0
driver_probe_device+0x11b/0x130
device_driver_attach+0x58/0x60
__driver_attach+0xa3/0x140
? device_driver_attach+0x60/0x60
? device_driver_attach+0x60/0x60
bus_for_each_dev+0x74/0xb0
? kmem_cache_alloc_trace+0x1a3/0x1c0
driver_attach+0x1e/0x20
bus_add_driver+0x147/0x220
? 0xffffffffc0cb9000
driver_register+0x60/0x100
? 0xffffffffc0cb9000
__pci_register_driver+0x5a/0x60
amdgpu_init+0x74/0x83 [amdgpu]
do_one_initcall+0x4a/0x1fa
? _cond_resched+0x19/0x40
? kmem_cache_alloc_trace+0x3f/0x1c0
? __vunmap+0x1cc/0x200
do_init_module+0x5f/0x227
load_module+0x2330/0x2b40
__do_sys_finit_module+0xfc/0x120
? __do_sys_finit_module+0xfc/0x120
__x64_sys_finit_module+0x1a/0x20
do_syscall_64+0x5a/0x130
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f14f9500839
Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
RSP: 002b:00007fff9bc4f5a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 000055afb5abce30 RCX: 00007f14f9500839
RDX: 0000000000000000 RSI: 000055afb5ace0f0 RDI: 0000000000000017
RBP: 000055afb5ace0f0 R08: 0000000000000000 R09: 000000000000000a
R10: 0000000000000017 R11: 0000000000000246 R12: 0000000000000000
R13: 000055afb5aad800 R14: 0000000000020000 R15: 0000000000000000
---[ end trace c286e96563966f08 ]---
This commit reworks the way that we handle i2c write for retimer in the
way that we abort this configuration if the feature is not available in
the device. For debug sake, we kept a simple log message in case the
retimer is not available.
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
In HDCP Uninitialzed State, a CPIRQ event would cause log output
internal policy error because the CPIRQ event is not recognized as
unexpected event.
[how]
CPIRQ is issued in HDCP uninitialized state is unexpected. We should
set unexpected event flag in event ctx.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
Some RX doesn't like us to read rx id list upto max rx id list size. As
discussed, we decided to read rx id list based on device count.
[how]
According to HDCP specs the actual size of rx id list is calculated as
rx id list size = 2+3+16+5*device_count. We will read 16 bytes at a
time until it reached or exceeded rx id list size.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
Link or DIG BE can't be exposed to a higher stream bandwidth than they
can handle. When DSC is required to fit the stream into the link
bandwidth, DSC has to be programmed during timing programming to ensure
this. Without it, intermittent issues such as black screen after S3 or a
hot-plug can be seen.
[how]
Move DSC programming from enabling stream on link to timing setup.
Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
