drm_format_info table has a field 'is_yuv' to denote if the format
is yuv or not. The driver is expected to use this instead of
having a function for the same purpose.
Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/omapdrm/dss/dispc.c: In function 'dispc_ovl_setup_common':
drivers/gpu/drm/omapdrm/dss/dispc.c:2627:19: warning:
variable 'frame_height' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of call the dispc timings check function dispc_mgr_timings_ok()
from the internal encoders .check_timings() operation, expose it through
the dispc ops (after renaming it to check_timings) and call it directly
from omapdrm. This allows removal of now empty omap_dss_device
.check_timings() operations.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The CRTC connect handler checks whether the DSS output supports the
DISPC channel assigned to it. As the channel is assigned to the output
by the output driver a failure there could only result from a driver
bug. All the output drivers have been verified and they are always
assigned a DISPC channel that is supported on the SoC they run on. The
check can thus be removed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The setup code for color space conversion is a bit messy. This patch
cleans it up.
For some reason the TRM uses values in YCrCb order, which is also used
in the current driver, whereas everywhere else it's YCbCr (which also
matches YUV order). This patch changes the tables to use the common
order to avoid confusion.
The tables are split into separate lines, and comments added for
clarity.
WB color conversion registers are similar but different than non-WB, but
the same function was used to write both. It worked fine because the
coef table was adjusted accordingly, but that was rather confusing. This
patch adds a separate function to write the WB values so that the coef
table can be written in an understandable way.
Recalculation also showed that 'bcb' value in yuv-to-rgb conversion had
been rounded wrongly, and it should be 516 instead of 517.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add writeback specific dispc functions to dispc_ops so that omapdrm can
use them. Also move 'enum dss_writeback_channel' to the public
omapdss.h for omapdrm.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
WB has additional scaling limits when the output color format is one of
the YUV formats. These limits are not handled at the moment, causing
bad scaling and/or NULL dereference crash.
This patchs adds the check so that dispc returns an error for bad
scaling request.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When using WB capture from interlaced source, we need to halve the
picture heights correctly.
Unfortunately the current dispc_ovl_setup_common() doesn't deal with
interlace very neatly, so the end result is a bit messy.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Vertical blanking needs to be halved on interlace modes. WBDELAYCOUNT
was calculated without such halving, resulting in WBUNCOMPLETE errors.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
For HDMI, WBDELAYCOUNT starts counting at the start of vsync, not at the
start of vfp.
This patch adjusts the wbdelay for HDMI accordingly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We need to know the WB channel-in in wb_setup() to be able to configure
WB properly for capture mode. At the moment channel-in is set
separately.
This patch moves channel-in to wb_setup().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In dispc_set_ovl_common() we need to initialize pclk to a valid
value when we use WB in capture mode (i.e. mem_2_mem is false).
Otherwise dispc_ovl_calc_scaling() fails.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When dispc_wb_setup() calls dispc_ovl_setup_common() it does not
check for failure but instead keeps on partially setting up WB.
This causes the WB H/W to be partially initialized and yield
unexpected behavior.
Make sure return code is successful before proceeding.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Fix sparse warning:
drivers/gpu/drm/omapdrm/dss/dispc.c:387:9: warning: context imbalance in 'mgr_fld_write' - different lock contexts for basic block
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The dispc private data structure is currently stored as a global
variable. While no platform with multiple DISPC currently exists
nor is planned, this doesn't comply with the kernel device model and
should thus be fixed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
This removes the need to access the global DISPC private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DISPC private data dynamically).
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
This removes the need to access the global DISPC private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DISPC private data dynamically).
In order to allow the omapdrm side to call the dispc_ops with a DISPC
pointer, we also introduce a new function dss_get_dispc() to retrieve
the DISPC corresponding to the DSS.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
As part of an effort to remove the usage of global variables in the
driver, store the debugfs root directory in the dss_device structure
instead of a global variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
As part of an effort to remove the usage of global variables in the
driver, store the registered plls array in the dss_device structure
instead of a global variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
To simplify implementation of debugfs seq_file show handlers, the driver
passes the pointer to the show function through the debugfs_create_file
data pointer. This prevents using the pointer to pass driver private
data to the show handler, and requires all handlers to use global
variables to access private data.
To prepare for the removal of global private data in the driver, rework
the debugfs infrastructure to allow passing a private data pointer to
show handlers.
The price to pay is explicit removal of debugfs files to free the
internally allocated memory. This is desirable anyway as debugfs entries
should be removed when a component driver is unbound, otherwise crashes
will occur due to access to freed memory when the components will be
dynamically allocated instead of stored in global variables.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
This removes the need to access the global DSS private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DSS device dynamically).
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>