| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Instead of manually iterating over the dss devices in the pipeline to
find the first one that implements the .get_modes() operation, add a new
operation flag for .get_modes() and use the omap_connector_find_device()
helper function to locate the right dss device.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Now that the .get_modes() operations takes a drm_connector and fills it
with modes, it becomes easy to fill display information in the same
operation without requiring a separate .get_size() opearation.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omap_dss_device operations expose fixed video timings through a
.get_timings() operation that return a single timing for the device. To
prepare for the move to drm_bridge, modify the API to instead add DRM
modes directly to the connector.
As this puts more burden on display devices, we also create a helper
function for panels to add a single DRM mode from the panel video
timings.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omapdrm and omapdss drivers are architectured based on display
pipelines made of multiple components handled from sink (display) to
source (DSS output). This is incompatible with the DRM bridge and panel
APIs that handle components from source to sink.
Reconcile the omapdrm and omapdss drivers with the DRM bridge and panel
model by reversing the direction of the DSS device .enable() and
.disable() operations. This completes the move to the DRM bridge model,
with the notable exception of the DSI pipelines that will require more
work.
We also adapt the omapdss shutdown handler dss_shutdown() to shut down
all active pipelines starting from the pipeline output device instead of
the display device.
As a consequence the for_each_dss_display() macro isn't used and can be
removed, and the omapdss_device_get_next() function underlying the macro
can be simplified to search for output devices only.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The displays (connectors, panels and encoders) bail out from their
.enable() and .disable() handlers if the dss device is already enabled
or disabled. Those safety checks are not needed when the functions are
called through the omapdss_device_ops, as the .enable() and .disable()
handlers are called from the DRM atomic helpers that already guarantee
that no double enabling or disabling can occur.
However, the handlers are also called directly from the .remove()
handler. While this shouldn't be needed either as the modules can't be
removed as long as the device is in use, it's still a good practice to
disable the device explicitly. There is currently a safety check in
.remove() in some drivers but not all of them.
Remove the safety checks from the .enable() and .disable() handlers, and
add missing ones in the .remove() handler.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The displays (connectors, panels and encoders) return an error from
their .enable() handler when the dss device is not connected. They also
disconnect the dss device explicitly from their .remove() handler if it
is still connected.
Those safety checks are not needed:
- The .enable() handler is called from code paths that access the dss
devices chain from the display device, which is set to NULL when the
device isn't connected.
- The .remove() handler can only be called when unloading the module as
the driver has the suppress_bind_attrs attribute set, and a reference
to the module is taken when constructing the dss devices chain, so the
module can only be unloaded when the dss device is disconnected.
Remove the safety checks.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
All .enable() and .disable() handlers for panels and connectors share
common code that validates and updates the device's state. Move it to
common locations in the omap_encoder_enable() and omap_encoder_disable()
handlers.
The enabled check in the .disable() handler is left untouched, it will
be addressed separately.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
panel-dpi used to convey the bus-flags via the videomode, but recent
changes changed the use of videomode to DRM's drm_display_mode which
does not contain bus-flags. This broke panel-dpi, which didn't
explicitly store the bus-flags into dssdev->bus_flags.
Fix this by setting dssdev->bus_flags. Also change the bus_flags type to
u32, as that is the type used in the DRM framework, and we would get a
warning with drm_bus_flags_from_videomode() otherwise.
Fixes: 3fbda31e814868d8477ddf52d74b7b8f596578e8 ("drm/omap: Split mode fixup and mode set from encoder enable")
Signed-off-by: Tomi Valkeinen <[email protected]>
Reported-by: H. Nikolaus Schaller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
Instead of calling the .set_timings() operation recursively from the
display device backwards, iterate over the devices manually in the DRM
encoder code. This moves the complexity to a single central location and
simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Panels drivers store their timings in a device data structure field that
is initialized at probe time, either from hardcoded values or from
firmware-supplied values. Those timings are then reported through the
.get_timings() operation to construct the panel display mode.
The panel timings are further modified by the .set_timings() operation,
which is called with the timings retrieved by .get_timings(), and
mangled by .check_timings(). The latter potentially adjusts the pixel
clock only.
Conceptually, modifying the panel timings is wrong, as the timings are
an intrinsic property of the panel and should thus be fixed.
Furthermore, modifying them this way at runtime can result in display
modes reported to userspace varying between calls, which is also wrong.
There's no actual need to store the mangled pixel clock value in the
timings. Don't modify the panel timings in the .set_timings() operation,
just forward it to the previous device in the display pipeline.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The analog TV, DVI and HDMI connectors all report timing information
through the .get_timings() information.
For analog TV outputs the information is queried from the encoder, so
the operation is unused. Remove it.
For HDMI outputs the display pipeline provides EDID capability, so the
operation is unused as well. Remove it.
For DVI outputs the operation is also unused if the pipeline provides
EDID capability. Otherwise (when the DDC bus is not connected) we
shouldn't hardcode a single mode, but instead report no mode and let the
KMS core add default modes. This is achieved by removing the operation.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The .check_timings() operation is called recursively from the display
device back to the output device. Most components just forward the
operation to the previous component in the chain, resulting in lots of
duplicated pass-through functions. To avoid that, iterate over the
components manually.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Source components in the display pipeline need to configure their output
signals polarities and clock driving edge based on the requirements of
the sink component.
Those requirements are currently shared across the whole pipeline in the
flags of a videomode structure, instead of being local to each bus. This
both prevents multiple buses from having different configurations (when
the hardware supports it), and makes it difficult to move from videomode
to drm_display_mode as the latter doesn't contain bus polarities and
clock edge flags.
Add a bus_flags field to the omap_dss_device structure and move the
DISPLAY_FLAGS_DE_(LOW|HIGH), DISPLAY_FLAGS_PIXDATA_(POS|NEG)EDGE and
DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE videomode flags to bus_flags in all
external encoders, connectors and panels. The videomode flags are still
used internally for internal encoders, this will be addressed in a
second step.
The related videomode flags in the default mode of the DVI connector can
simply be dropped, as they are always overridden by the TFP410 driver.
Note that this results in both the DISPLAY_FLAGS_SYNC_POSEDGE and
DISPLAY_FLAGS_SYNC_NEGEDGE flags being set, which is invalid, but only
the former is tested for when programming the DISPC, so the DVI
connector flags are effectively overridden by the TFP410 flags.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device .set_timings() operation for external encoders
stores the video mode in the device data structure. That mode is then
never used again. Drop it.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device .set_timings() operations are called directly from
omap_encoder_update(), and indirectly from the omap_dss_device .enable()
operation. The latter is called from omap_encoder_enable(), right after
calling omap_encoder_update(). The .set_timings() operation it thus
called twice in a row. Fix it by removing the indirect call.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The .set_timings() operations of the omap_dss_device instances don't
need to modify the passed timings. Make the pointer const.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Both the .check_timings() and .set_timings() handlers call
tfp410_fix_timings() to fix the timing's flags. As .check_timings() is
always called before .set_timings(), there's no need to fix the flags
twice. Remove the tfp410_fix_timings() call from .set_timings().
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe())
operations are called recursively from the display device back to the
HDMI encoder. This isn't required, as all components other than the HDMI
encoder just forward the operation to the previous component in the
chain. Call the operations directly on the HDMI encoder.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Instead of calling the EDID read operation (.read_edid()) recursively
from the display device back to the first device that provides EDID read
support, iterate over the devices manually in the DRM connector code.
This moves the complexity to a single central location and simplifies
the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
On HDMI outputs, CEC support requires notification of HPD signal
deassertion. The HPD signal can be handled by various omap_dss_device
instances in the pipeline, and all of them forward HPD events to the
OMAP4 internal HDMI encoder.
Knowledge of the DSS internals need to be removed from the
omap_dss_device instances in order to migrate to drm_bridge. To do so,
move HPD handling for CEC to the omap_connector.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable
and disable hot-plug detection at omapdrm probe and remove time. This is
required to avoid reporting hot-plug detection events before the DRM
infrastructure is ready to accept them, as that could result in crashes
or other malfunction.
Hot-plug event reporting is conditioned by both HPD being enabled
through the .enable_hpd() operation and by the HPD callback being
registered though the .register_hpd_cb() operation. We thus don't need a
separate enable operation if we can guarantee that callbacks won't be
registered too early.
HPD callbacks are registered at connector initialization time, which is
too early to start reporting HPD events. There's however nothing
blocking a move of callback registration to a later time when the
omapdrm driver calls the HPD enable operations. Do so, and remove the
HPD enable operation completely from omap_dss_device drivers.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The HPD-related omap_dss_device operations are now only called when the
device supports HPD. There's no need to duplicate that check in the
omap_dss_device drivers. The .register_hpd_cb() operation can as a
result be turned into a void operation.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Instead of calling the hot-plug detection callback registration
operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively
from the display device back to the first device that provides hot plug
detection support, iterate over the devices manually in the DRM
connector code. This moves the complexity to a single central location
and simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Instead of calling the .detect() operation recursively from the display
device back to the first device that provides hot plug detection
support, iterate over the devices manually in the DRM connector
.detect() implementation. This moves the complexity to a single central
location and simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omap_dss_device instances have two ops structures, omap_dss_driver and
omap_dss_device_ops. The former is used for devices at the end of the
pipeline (a.k.a. display devices), and the latter for intermediate
devices.
Having two sets of operations isn't convenient as code that iterates
over omap_dss_device instances need to take them both into account.
There's currently a reasonably small amount of such code, but more will
be introduced to move the driver away from recursive operations. To
simplify current and future code, move all operations that are not
specific to the display device to the omap_dss_device_ops.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
As the descriptor API handles the active-low flag internally we need to
invert the polarity of all GPIO operations in the driver. Rename the
nreset_gpio field to reset_gpio to reflect that.
The reset GPIO is mandatory, so drop conditional tests through the
driver.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The driver doesn't use GPIOs and thus doesn't need to include the
linux/gpio.h header.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
The reset GPIO is mandatory, so drop conditional tests through the
driver. The qvga GPIO is unused, so drop it completely.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
As the descriptor API handles the active-low flag internally we need to
invert the polarity of all GPIO operations in the driver.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The .get_mirror() and .set_mirror() omap_dss_driver operations are
implemented by the panel-tpo-td043mtea1 driver but are never used.
Remove them.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omapdrm and omapdss drivers are architectured based on display
pipelines made of multiple components handled from sink (display) to
source (DSS output). This is incompatible with the DRM bridge and panel
APIs that handle components from source to sink.
To reconcile the omapdrm and omapdss drivers with the DRM bridge and
panel model, we need to reverse the direction of the DSS device
operations. Start with the connect and disconnect operations.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Look up the next dssdev at probe time based on device tree links for all
DSS outputs and encoders. This will be used to reverse the order of the
dssdev connect and disconnect call chains.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The connect handle of the analog TV and HDMI connectors casts the dssdev
to panel data only to then access fields of the panel data that are also
present in the dssdev. Remove the cast and use dssdev directly.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omapdss_of_find_source_for_first_ep() function locates the source
corresponding to the first endpoint of the first port of a device node.
We can easily extend it to locate sinks as well by passing the port
number as a parameter. This will be useful to find sinks in encoders
drivers.
Extend the function and rename it to omapdss_of_find_connected_device()
to reflect its new extended purpose.
Additionally, it is useful to differentiate between failures to return
the connected device because no link exists in the device tree for the
requested port, or because the connected device as described in the
device tree is invalid or not probed yet. Return NULL in the first case
and an error code in the second case, and update the callers
accordingly.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device port_num field stores the DT port number associated
with the device. The field is used in different ways depending on the
device type:
- For DPI outputs, the port number is used as an identifier of the DPI
instance
- For sources, the port number is used to look up the omap_dss_device by
DT port node
As omap_dss_device instances are only looked up as sources by sinks,
setting the field to the number of the source port works for both use
cases.
However, to enable looking up sinks, we need to record all the ports
associated with an omap_dss_device. Do so by turning the port_num field
into an of_ports bitmask. For DPI outputs the port number is
additionally stored in the dpi_data structure as the output ID.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Storing the dss_device pointer in the omap_dss_device structure will
allow accessing the dss_device from the dss_mgr API functions.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The functions operate on any omap_dss_device, move them from display.c
to base.c. While at it rename them to match the naming of the other
functions operating on struct omap_dss_device.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The panel devices list isn't used anymore, all panel devices are
accessed through the global devices list. Remove it.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Split the function into omapdss_display_init() to perform
display-specific initialization of the omap_dss_device, and
omapdss_register_display() to register the device. The latter will then
be replaced by more generic registration.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The output devices list isn't used anymore, all output devices are
accessed through the global devices list. Remove it.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
All connectors, encoders and panels store a pointer to their input
omap_dss_device in the panel driver data structure. This duplicates the
src field in the omap_dss_device structure. Remove the private copy and
use the src field.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The encoders duplicate the same omap_dss_device src and dst fields set
and checks in their connect and disconnect handlers. Move the code to
the connect and disconnect wrappers.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
In preparation for the move of checks from the disconnect handlers to
the omapdss_device_disconnect() function, replace direct calls to the
disconnect handlers at remove time with calls to
omapdss_device_disconnect().
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The connectors, encoders and display duplicate the same debug messages
and connection checks in their omap_dss_device connect and disconnect
handlers. Move the code to the connect and disconnect wrappers.
To simplify the code the connect function returns -EBUSY unconditionally
if the device is already connected. This doesn't cause any change in
practice: the connect handler of displays is never called on a connected
device as it is only invoked during omapdrm initialization.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device objects model display components and are connected
at runtime to create display pipelines. The connect and disconnect
operations implemented by each component contain lots of duplicate code.
As a first step towards fixing this, create new functions to wrap the
direct calls to those operations and use them.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The various types of omapdss_*_ops structures define multiple operations
that are not specific to a bus type. To simplify the code and remove
dependencies on specific bus types move those operations to a common
structure. Operations that are specific to a bus type are kept in the
specialized ops structures.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device panel.dsi_pix_fmt and panel.dsi_mode fields are
unused. Remove them.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device structure stores a videomode. All the connector and
panel drivers that use omap_dss_device also store the videomode in their
own panel_drv_data structures. There's no need to duplicate, remove the
videomode field from omap_dss_device.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|