/*
* tc358743 - Toshiba HDMI to CSI-2 bridge
*
* Copyright 2015 Cisco Systems, Inc. and/or its affiliates. All rights
* reserved.
*
* This program is free software; you may redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
*/
/*
* References (c = chapter, p = page):
* REF_01 - Toshiba, TC358743XBG (H2C), Functional Specification, Rev 0.60
* REF_02 - Toshiba, TC358743XBG_HDMI-CSI_Tv11p_nm.xls
*/
#ifndef _TC358743_
#define _TC358743_
enum tc358743_ddc5v_delays {
DDC5V_DELAY_0_MS,
DDC5V_DELAY_50_MS,
DDC5V_DELAY_100_MS,
DDC5V_DELAY_200_MS,
};
enum tc358743_hdmi_detection_delay {
HDMI_MODE_DELAY_0_MS,
HDMI_MODE_DELAY_25_MS,
HDMI_MODE_DELAY_50_MS,
HDMI_MODE_DELAY_100_MS,
};
struct tc358743_platform_data {
/* System clock connected to REFCLK (pin H5) */
u32 refclk_hz; /* 26 MHz, 27 MHz or 42 MHz */
/* DDC +5V debounce delay to avoid spurious interrupts when the cable
* is connected.
* Sets DDC5V_MODE in register DDC_CTL.
* Default: DDC5V_DELAY_0_MS
*/
enum tc358743_ddc5v_delays ddc5v_delay;
bool enable_hdcp;
/*
* The FIFO size is 512x32, so Toshiba recommend to set the default FIFO
* level to somewhere in the middle (e.g. 300), so it can cover speed
* mismatches in input and output ports.
*/
u16 fifo_level;
/* Bps pr lane is (refclk_hz / pll_prd) * pll_fbd */
u16 pll_prd;
u16 pll_fbd;
/* CSI
* Calculate CSI parameters with REF_02 for the highest resolution your
* CSI interface can handle. The driver will adjust the number of CSI
* lanes in use according to the pixel clock.
*
* The values in brackets are calculated with REF_02 when the number of
* bps pr lane is 823.5 MHz, and can serve as a starting point.
*/
u32 lineinitcnt; /* (0x00001770) */
u32 lptxtimecnt; /* (0x00000005) */
u32 tclk_headercnt; /* (0x00001d04) */
u32 tclk_trailcnt; /* (0x00000000) */
u32 ths_headercnt; /* (0x00000505) */
u32 twakeup; /* (0x00004650) */
u32 tclk_postcnt; /* (0x00000000) */
u32 ths_trailcnt; /* (0x00000004) */
u32 hstxvregcnt; /* (0x00000005) */
/* DVI->HDMI detection delay to avoid unnecessary switching between DVI
* and HDMI mode.
* Sets HDMI_DET_V in register HDMI_DET.
* Default: HDMI_MODE_DELAY_0_MS
*/
enum tc358743_hdmi_detection_delay hdmi_detection_delay;
/* Reset PHY automatically when TMDS clock goes from DC to AC.
* Sets PHY_AUTO_RST2 in register PHY_CTL2.
* Default: false
*/
bool hdmi_phy_auto_reset_tmds_detected;
/* Reset PHY automatically when TMDS clock passes 21 MHz.
* Sets PHY_AUTO_RST3 in register PHY_CTL2.
* Default: false
*/
bool hdmi_phy_auto_reset_tmds_in_range;
/* Reset PHY automatically when TMDS clock is detected.
* Sets PHY_AUTO_RST4 in register PHY_CTL2.
* Default: false
*/
bool hdmi_phy_auto_reset_tmds_valid;
/* Reset HDMI PHY automatically when hsync period is out of range.
* Sets H_PI_RST in register HV_RST.
* Default: false
*/
bool hdmi_phy_auto_reset_hsync_out_of_range;
/* Reset HDMI PHY automatically when vsync period is out of range.
* Sets V_PI_RST in register HV_RST.
* Default: false
*/
bool hdmi_phy_auto_reset_vsync_out_of_range;
};
/* custom controls */
/* Audio sample rate in Hz */
#define TC358743_CID_AUDIO_SAMPLING_RATE (V4L2_CID_USER_TC358743_BASE + 0)
/* Audio present status */
#define TC358743_CID_AUDIO_PRESENT (V4L2_CID_USER_TC358743_BASE + 1)
#endif
'30'>30
drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj()
I've seen this trigger twice now, where the i915_gem_object_to_ggtt()
call in intel_unpin_fb_obj() returns NULL, resulting in an oops
immediately afterwards as the (inlined) call to i915_vma_unpin_fence()
tries to dereference it.
It seems to be some race condition where the object is going away at
shutdown time, since both times happened when shutting down the X
server. The call chains were different:
- VT ioctl(KDSETMODE, KD_TEXT):
intel_cleanup_plane_fb+0x5b/0xa0 [i915]
drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper]
intel_atomic_commit_tail+0x749/0xfe0 [i915]
intel_atomic_commit+0x3cb/0x4f0 [i915]
drm_atomic_commit+0x4b/0x50 [drm]
restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper]
drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
intel_fbdev_set_par+0x18/0x70 [i915]
fb_set_var+0x236/0x460
fbcon_blank+0x30f/0x350
do_unblank_screen+0xd2/0x1a0
vt_ioctl+0x507/0x12a0
tty_ioctl+0x355/0xc30
do_vfs_ioctl+0xa3/0x5e0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x13/0x94
- i915 unpin_work workqueue:
intel_unpin_work_fn+0x58/0x140 [i915]
process_one_work+0x1f1/0x480
worker_thread+0x48/0x4d0
kthread+0x101/0x140
and this patch purely papers over the issue by adding a NULL pointer
check and a WARN_ON_ONCE() to avoid the oops that would then generally
make the machine unresponsive.
Other callers of i915_gem_object_to_ggtt() seem to also check for the
returned pointer being NULL and warn about it, so this clearly has
happened before in other places.
[ Reported it originally to the i915 developers on Jan 8, applying the
ugly workaround on my own now after triggering the problem for the
second time with no feedback.
This is likely to be the same bug reported as
https://bugs.freedesktop.org/show_bug.cgi?id=98829
https://bugs.freedesktop.org/show_bug.cgi?id=99134
which has a patch for the underlying problem, but it hasn't gotten to
me, so I'm applying the workaround. ]
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>