Gabriel Krisman reported these warnings when building the documentation:
./drivers/gpu/drm/drm_dp_helper.c:1165: warning: No description found
for parameter 'crtc'
./drivers/gpu/drm/drm_dp_helper.c:1166: warning: No description found
for parameter 'crtc'
Reported-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170307203511.14258-1-tomeu.vizoso@collabora.com
Call qxl_add_monitors_config_modes() unconditionally. Do all sanity
checks in that function.
Fix sanity checks. monitors_config is the current monitor
configuration, whereas client_monitors_config is the configuration
requested by the spice client. So when filling the mode list, based on
the spice client request, we need to look at
client_monitors_config->count not monitors_config->count.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-5-git-send-email-kraxel@redhat.com
Try to read the client monitors config at driver load time, even without
explicit notification. So in case that info was filled before the driver
loaded and we've missed the notifications because of that the settings
will still be used.
With that place we now have to take care to properly handle a empty client
monitors config, so we don't trip over an uninitialized client monitors
config.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-4-git-send-email-kraxel@redhat.com
When reading the monitor config fails, don't retry forever. If it fails
ten times in a row just give up to avoid the driver hangs. Also add a
small delay after each attempt, so the host has a chance to complete a
partial update.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-3-git-send-email-kraxel@redhat.com
very old qxl hardware revisions (predating qxl ksm support by a few
years) supported a fixed list of video modes only. The list is still
provided by the virtual hardware, for backward compatibility reasons.
The qxl kms driver never ever looks at it, except for dumping it to
the kernel log at load time in case debug logging is enabled. Drop
that pointless code.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-2-git-send-email-kraxel@redhat.com
Fixes the following link error when CONFIG_DRM_ANALOGIX_DP is not defined:
ERROR: "analogix_dp_start_crc" [drivers/gpu/drm/rockchip/rockchipdrm.ko] undefined!
ERROR: "analogix_dp_stop_crc" [drivers/gpu/drm/rockchip/rockchipdrm.ko] undefined!
Fixes: 3190e58daf ("drm/rockchip: Implement CRC debugfs API")
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
v6: Remove superfluous variable
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170303133936.14964-5-tomeu.vizoso@collabora.com
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
v6: Pass to the DP helper the drm_crtc of the current connector (Sean Paul)
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170303133936.14964-4-tomeu.vizoso@collabora.com
Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.
v2: Reuse drm_crtc_wait_one_vblank
Update locking, as drm_crtc_add_crc_entry now takes the lock
v3: Don't call wake_up_interruptible directly, that's now done in
drm_crtc_add_crc_entry.
v4: Style fixes (Sean Paul)
Reworked retry of CRC reads (Sean Paul)
Flush worker after stopping CRC generationa (Sean Paul)
v5: Move back to make the retry explicitly once
v6: Set and use the drm_crtc backpointer (Sean Paul)
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170303133936.14964-3-tomeu.vizoso@collabora.com
There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487256430-7625-6-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This is a straightforward conversion that converts all the users of
get_existing_state in atomic core to use get_old_state or get_new_state
Changes since v1:
- Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state.
Changes since v2:
- Use the correct state in disable_outputs()
Changes since v3:
- Rebase for link status training.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/df91a9f9-005e-bcbd-1f74-03c38e1e21dd@linux.intel.com
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This function becomes a lot simpler when having passed both the old and
new state to it. Looking at all callers, it seems that old_plane_state
is never NULL so the check can be dropped.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487256430-7625-3-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.
Changes since v1:
- Use old/new_*_state for variable names as much as possible. (pinchartl)
- Expand commit message.
Changes since v2:
- Rebase on top of link training patches.
- free -> cleanup (pinchartl)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: http://patchwork.freedesktop.org/patch/msgid/aafa0d4d-474d-441f-3685-fa6c042ef37e@linux.intel.com
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The THC63LVDM83D is a transparent LVDS encoder. Unlike dumb LVDS
encoders it can be controlled through a few pins (power down, LVDS
swing, clock edge selection) and requires power supplies. However, on
several boards where the device is used neither the control pins nor the
power supply are controllable.
To avoid developing a separate device-specific driver add a
"thine,thc63lvdm83d" compatible entry to the lvds-encoder driver. This
will allow supporting many THC63LVDM83D-based boards easily, while
allowing future development of an thc63lvdm83d driver when needed
without breaking backward compatibility.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302104728.7150-5-laurent.pinchart+renesas@ideasonboard.com
The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
controlled through a power save pin, and requires a power supply.
However, on most boards where the device is used neither the power save
signal nor the power supply are controllable.
To avoid developing a separate device-specific driver add an
"adi,adv7123" compatible entry to the dumb-vga-dac driver. This will
allow supporting most ADV7123-based boards easily, while allowing future
development of an adv7123 driver when needed without breaking backward
compatibility.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302104728.7150-4-laurent.pinchart+renesas@ideasonboard.com
The LVDS encoder driver is a DRM bridge driver that supports the
parallel to LVDS encoders that don't require any configuration. The
driver thus doesn't interact with the device, but creates an LVDS
connector for the panel and exposes its size and timing based on
information retrieved from DT.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302104728.7150-3-laurent.pinchart+renesas@ideasonboard.com
The video processing pipeline on the second output on the GE B850v3:
Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
Each bridge has a dedicated flash containing firmware for supporting the
custom design. The result is that in this design neither the STDP4028
nor the STDP2690 behave as the stock bridges would. The compatible
strings include the suffix "-ge-b850v3-fw" to make it clear that the
driver is for the bridges with the firmware which is specific for the GE
B850v3.
The driver is powerless to control the video processing pipeline, as the
two bridges behaves as a single one. The driver is only needed for
telling the host about EDID / HPD, and for giving the host powers to ack
interrupts.
This driver adds one i2c_device for each bridge, but only one
drm_bridge. This design allows the creation of a functional connector
that is capable of reading EDID from the STDP2690 while handling
interrupts on the STDP4028.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Martyn Welch <martyn.welch@collabora.co.uk>
Cc: Martin Donnelly <martin.donnelly@ge.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Enric Balletbo <enric.balletbo@collabora.com>
Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/ad92919f2eaff2623a551aac94cf11ef948ff9ee.1488555615.git.peter.senna@collabora.com
If a CMA allocation failed, the partially constructed BO would be
unreferenced through the normal path, and we might choose to put it in
the BO cache. If we then reused it before it expired from the cache,
the kernel would OOPS.
Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes: c826a6e106 ("drm/vc4: Add a BO cache.")
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301185602.6873-2-eric@anholt.net
The from_cache flag was actually "the BO is invisible to userspace",
so we can repurpose it to just zero out a cached BO and return it to
userspace.
Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by
-1.44989% +/- 0.862891% (n=28, 1 outlier removed from each that
appeared to be other system noise)
Note that there's an intel-gpu-tools test to check for the proper
zeroing behavior here, which we continue to pass.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301185602.6873-1-eric@anholt.net
This reverts commit 233ce881dd.
I assumed it's ok, but really should have double-checked - CI caught
tons of fail :(
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301171749.13053-1-daniel.vetter@ffwll.ch
Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double buffering. It is tested on
the i.MX6.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization") dropped the num_crtc argument. Update the
documentation to reflect that and prevent the kernel-doc warnings below:
./drivers/gpu/drm/drm_fb_cma_helper.c:557: warning: Excess function parameter 'num_crtc' description in 'drm_fbdev_cma_init'
./drivers/gpu/drm/drm_fb_cma_helper.c:558: warning: Excess function parameter 'num_crtc' description in 'drm_fbdev_cma_init'
Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper initialization")
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/87o9xkvn2m.fsf@dilma.collabora.co.uk
The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1487577744-2855-3-git-send-email-zyw@rock-chips.com
In order to fully reset the state of the MIPI controller we must assert
this reset.
This is slightly more complicated than it could be in order to maintain
compatibility with device trees that do not specify the reset property.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-24-john@metanate.com
This ensures that the output resolution is known before fbcon loads.
mipi_dsi_host_register() is moved above dw_mipi_dsi_register() to
simplify error cleanup since the order of these operations does not
matter.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-22-john@metanate.com
When connected to the MIPI DSI output, we need to use N{H,V}SYNC for the
internal connection but these flags are meaningless for DSI panels.
Switch the test so that we do not set the P{H,V}SYNC bits unless the
mode requires it.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
[seanpaul resolved conflict using macros instead of hardcoded values]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-21-john@metanate.com
As the documentation for readx_poll_timeout says, we want to use the
specialized macro for readl rather than using the generic version
directly.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-19-john@metanate.com
The multiplication ratio for the PLL is required to be even due to the
use of a "by 2 pre-scaler". Currently we are likely to end up with an
odd multiplier even though there is an equivalent set of parameters with
an even multiplier.
For example, using the 324MHz bit rate with a reference clock of 24MHz
we end up with M = 27, N = 2 whereas the example in the PHY databook
gives M = 54, N = 4 for this bit rate and reference clock.
By walking down through the available multiplier instead of up we are
more likely to hit an even multiplier. With the above example we do now
get M = 54, N = 4 as given by the databook.
While doing this, change the loop limits to encode the actual limits on
the divisor, which are:
40MHz >= (pllref / N) >= 5MHz
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-18-john@metanate.com
These values are specified as constant time periods but the PHY
configuration is in terms of the current lane byte clock so using
constant values guarantees that the timings will be outside the
specification with some display configurations.
Derive the necessary configuration from the byte clock in order to
ensure that the PHY configuration is correct.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-17-john@metanate.com
Also don't power up the DSI host at this point since this is not
necessary in order to configure the PHY and we do so later when
selecting video or command mode.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-15-john@metanate.com
This clock rate is derived from the PHY PLL, so it should be calculated
dynamically. This calculation is the same as that used by the vendor
kernel and ensures that the escape clock runs at <20MHz as required by
the MIPI specification.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-14-john@metanate.com
Panel drivers may want to sent commands during the disable function, for
example MIPI_DCS_SET_DISPLAY_OFF before the video signal ends. In order
to send commands we need to write to registers, so pclk must be enabled.
While changing this, remove the unnecessary code after the panel
unprepare call which seems to be a workaround for a specific panel and
thus belongs in the panel driver.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-13-john@metanate.com
Some panels need to be configured with commands sent over the MIPI link,
which they will do in the prepare hook. Call this after the PHY has
been initialized so that we are able to send commands to the panel.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-12-john@metanate.com
By dereferencing the MIPI command buffer as a u32* we rely on it being
correctly aligned on ARM, but this may not be the case. Copy it into a
stack variable that will be correctly aligned.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-11-john@metanate.com
Requesting the HS clock from the PHY before we initialize it causes an
invalid signal to be sent out since the input clock is not yet
configured. The PHY databook suggests only asserting this signal when
performing HS transfers, so let's do that.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-10-john@metanate.com
Instead of always sending commands in LP mode, respect the
MIPI_DSI_MSG_USE_LPM flag to decide how to send each message. Also
request acks if MIPI_DSI_MSG_REQ_ACK is set.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-9-john@metanate.com
We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits
are set so we can't just check "val & mask" because that will be true if
either bit is set.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-6-john@metanate.com
In a couple of places here we use "val" for the value that is about to
be written to a register but then reuse the same variable for the value
of a status register before we get around to writing it. Rename the
value to be written to so that we write the value we intend to and not
what we have just read from the status register.
Signed-off-by: John Keeping <john@metanate.com>
Tested-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-5-john@metanate.com
This is not needed since we can access the mode via the CRTC from the
enable hook. Also remove the "mode" field that is no longer used.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224125506.21533-4-john@metanate.com
Tomeu Vizoso