OMAP4 checks are removed from VENC to provide it a cleaner interface. These
checks were introduced by patches "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4
to prevent crash" (ba02fa37de) by Tomi Valkeinen <tomi.valkeinen@ti.com> and
"OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on
OMAP4" (cc1d3e032d) by Danny Kukawka <danny.kukawka@bisect.de> to prevent VENC
from crashing OMAP4 kernel.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
All the cpu_is checks have been moved to dss_init_features function providing a
much more generic and cleaner interface. The OMAP version and revision specific
initializations in various functions are cleaned and the necessary data are
moved to dss_features structure which is local to dss.c.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Functions dss_calc_clock_rates() and dss_get_clock_div() are removed as these
functions have become redundant and no longer used.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
All the cpu_is checks have been moved to dispc_init_features function providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions and data are initialized by dispc_features structure which is
local to dispc.c.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Commit 7849398fa2 introduced a bug,
causing the following error to be reported:
[ 370.827819] cannot lock PLL
[ 370.830749] CFG1 0x1e
[ 370.833160] CFG2 0x602004
[ 370.835876] CFG4 0x40000
[ 370.838562] omapdss HDMI: Failed to lock PLL
However, HDMI output is still enabled.
The problem is that we enable the HDMI video output temporarily when
reading EDID or detecting if a HDMI cable is connected (ugh), and the
commit above changes the behavior of the driver so that the video
timings are not yet configured at the point when EDID is read.
This patch fixes the problem by configuring the initial VGA timings at
HDMI probe.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
So we've had a fair few reports of fbcon handover breakage between
efi/vesafb and i915 surface recently, so I dedicated a couple of
days to finding the problem.
Essentially the last thing we saw was the conflicting framebuffer
message and that was all.
So after much tracing with direct netconsole writes (printks
under console_lock not so useful), I think I found the race.
Thread A (driver load) Thread B (timer thread)
unbind_con_driver -> |
bind_con_driver -> |
vc->vc_sw->con_deinit -> |
fbcon_deinit -> |
console_lock() |
| |
| fbcon_flashcursor timer fires
| console_lock() <- blocked for A
|
|
fbcon_del_cursor_timer ->
del_timer_sync
(BOOM)
Of course because all of this is under the console lock,
we never see anything, also since we also just unbound the active
console guess what we never see anything.
Hopefully this fixes the problem for anyone seeing vesafb->kms
driver handoff.
v1.1: add comment suggestion from Alan.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that cancel_delayed_work() can be safely called from IRQ handlers,
there's no reason to use __cancel_delayed_work(). Use
cancel_delayed_work() instead of __cancel_delayed_work() and mark the
latter deprecated.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Roland Dreier <roland@kernel.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Initalizers for deferrable delayed_work are confused.
* __DEFERRED_WORK_INITIALIZER()
* DECLARE_DEFERRED_WORK()
* INIT_DELAYED_WORK_DEFERRABLE()
Rename them to
* __DEFERRABLE_WORK_INITIALIZER()
* DECLARE_DEFERRABLE_WORK()
* INIT_DEFERRABLE_WORK()
This patch doesn't cause any functional changes.
Signed-off-by: Tejun Heo <tj@kernel.org>
So we've had a fair few reports of fbcon handover breakage between
efi/vesafb and i915 surface recently, so I dedicated a couple of
days to finding the problem.
Essentially the last thing we saw was the conflicting framebuffer
message and that was all.
So after much tracing with direct netconsole writes (printks
under console_lock not so useful), I think I found the race.
Thread A (driver load) Thread B (timer thread)
unbind_con_driver -> |
bind_con_driver -> |
vc->vc_sw->con_deinit -> |
fbcon_deinit -> |
console_lock() |
| |
| fbcon_flashcursor timer fires
| console_lock() <- blocked for A
|
|
fbcon_del_cursor_timer ->
del_timer_sync
(BOOM)
Of course because all of this is under the console lock,
we never see anything, also since we also just unbound the active
console guess what we never see anything.
Hopefully this fixes the problem for anyone seeing vesafb->kms
driver handoff.
Signed-off-by: David Airlie <airlied@redhat.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: stable@vger.kernel.org
Tested-by: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The VENC driver currently relies on the omap_dss_device struct to configure the
video output polarity. This makes the VENC interface driver dependent on the
omap_dss_device struct.
Make the VENC driver data maintain it's own polarity field. A panel driver
is expected to call omapdss_venc_invert_vid_out_polarity() before enabling the
interface.
Signed-off-by: Archit Taneja <archit@ti.com>
The VENC driver currently relies on the omap_dss_device struct to configure the
venc type. This makes the VENC interface driver dependent on the omap_dss_device
struct.
Make the VENC driver data maintain it's own 'venc type' field. A panel driver
is expected to call omapdss_venc_set_type() before enabling the interface or
changing the type via display sysfs attributes.
Signed-off-by: Archit Taneja <archit@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to receive the
rfbi specific timings requested by the panel driver. This makes the RFBI
interface driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own rfbi specific timings field. The
panel driver is expected to call omapdss_rfbi_set_interface_timings() to
configure the rfbi timings before the interface is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The DSI driver currently relies on the omap_dss_device struct to receive the
video mode timings requested by the panel driver. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own video mode timings field. The panel
driver is expected to call omapdss_dsi_set_videomode_timings() to configure the
video mode timings before the interface is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The struct omap_dss_dsi_videomode_data holds fields which need to be configured
for DSI to operate in video mode. Rename the struct to dsi_videomode_timings.
One reason to do this is because most of the fields in the struct are timings
related. The other reason is to create a generic op for output specific
timings. This generic op can be considered as a way to set custom or private
timings for the output.
In the case of OMAP, DSI and RFBI require some more timings apart from the
relgular DISPC timings. The structs omap_dss_videomode_timings and rfbi_timings
can be considered as these output specific timings respectively.
Signed-off-by: Archit Taneja <archit@ti.com>
The DSI driver currently relies on the omap_dss_device struct to know the mode
of operation of the DSI protocol(command or video mode). This makes the DSI
interface driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own operation mode field. The panel
driver is expected to call omapdss_dsi_set_operation_mode() before the interface
is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The SDI driver currently relies on the omap_dss_device struct to configure the
number of data pairs as specified by the panel. This makes the SDI interface
driver dependent on the omap_dss_device struct.
Make the SDI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_sdi_set_datapairs() before enabling the interface.
Even though we configure the number of data pairs here, this function would be
finally mapped to a generic interface op called set_data_lines. The datapairs
argument type has been changed from u8 to int at some places to be in sync with
the 'set_data_lines' ops of other interfaces.
Signed-off-by: Archit Taneja <archit@ti.com>
The DPI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the DPI interface
driver dependent on the omap_dss_device struct.
Make the DPI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_dpi_set_data_lines() before enabling the interface.
Signed-off-by: Archit Taneja <archit@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the RFBI interface
driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_rfbi_set_data_lines() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().
Signed-off-by: Archit Taneja <archit@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to receive the
desired pixel size of the panel. This makes the RFBI interface driver dependent
on the omap_dss_device struct.
Make the RFBI driver data maintain it's own pixel format field. A panel driver
is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().
Signed-off-by: Archit Taneja <archit@ti.com>
The DSI driver currently relies on the omap_dss_device struct to receive the
desired pixel format of the panel. This makes the DSI interface driver dependent
on the omap_dss_device struct.
Make the DSI driver data maintain it's own pixel format field. The panel driver
is expected to call omapdss_dsi_set_pixel_format() to configure the pixel format
before the interface is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
RFBI drivers requires configuration of the update area. Since we don't support
partial updates, the size to be configures is the panel size itself.
Add a timings field in RFBI's driver data. Apart from x_res and y_res, all the
other fields are configured to an initial value when RFBI is enabled. A panel
driver is expected to call omapdss_rfbi_set_size() configure the size of the
panel.
Signed-off-by: Archit Taneja <archit@ti.com>
Partial update suppport was removed from DISPC and DSI sometime back. The RFBI
driver still tries to support partial update without the underlying support in
DISPC.
Remove partial update support from RFBI, only support updates which span acros
the whole panel size. This also helps in DSI and RFBI having similar update
ops.
Signed-off-by: Archit Taneja <archit@ti.com>
The VENC driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and VENC blocks accordingly. This makes the VENC interface
driver dependent on the omap_dss_device struct.
Make the VENC driver data maintain it's own timings field. The panel driver is
expected to call omapdss_venc_set_timings() to set these timings before the
panel is enabled. Call omapdss_venc_set_timings() before enabling
venc output, this is done to atleast have the venc output configured to the
panel's default timings if the DSS user didn't explicitly call the venc panel
driver's set_timings op.
Make the VENC panel driver configure the new timings is the omap_dss_device
struct(dssdev->panel.timings). The VENC driver is responsible for maintaining
only it's own copy of timings.
Signed-off-by: Archit Taneja <archit@ti.com>
The current venc.c driver contains both the interface and panel driver code.
This makes the driver hard to read, and difficult to understand the work split
between the interface and panel driver and the how the locking works.
This also makes it easier to clearly define the VENC interface ops called by the
panel driver.
Split venc.c into venc.c and venc_panel.c representing the interface and panel
driver respectively. This split is done along the lines of the HDMI interface
and panel drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
The SDI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the SDI interface driver dependent
on the omap_dss_device struct.
Make the SDI driver data maintain it's own timings field. The panel driver is
expected to call omapdss_sdi_set_timings() to set these timings before the panel
is enabled.
Make the SDI panel driver configure the new timings is the omap_dss_device
struct(dssdev->panel.timings). The SDI driver is responsible for maintaining
only it's own copy of timings.
Signed-off-by: Archit Taneja <archit@ti.com>
Create function omapdss_sdi_set_timings(). Configuring new timings is done the
same way as before, SDI is disabled, and re-enabled with the new timings in
dssdev. This just moves the code from the panel drivers to the SDI driver.
The panel drivers shouldn't be aware of how SDI manages to configure a new set
of timings. This should be taken care of by the SDI driver itself.
Signed-off-by: Archit Taneja <archit@ti.com>
The hdmi interface driver exposes functions to the hdmi panel driver to
configure the interface timings maintained by the hdmi driver.
These timings(stored in hdmi.ip_data.cfg) should be protected by the hdmi lock
to ensure they are called sequentially, this is similar to how hdmi enable and
disable functions need locking.
Signed-off-by: Archit Taneja <archit@ti.com>
The hdmi driver currently updates only the 'code' member of hdmi_config when
the op omapdss_hdmi_display_set_timing() is called by the hdmi panel driver.
The 'timing' field of hdmi_config is updated only when hdmi_power_on is called.
It makes more sense to configure the whole hdmi_config field in the set_timing
op called by the panel driver. This way, we don't need to call both functions
to ensure that our hdmi_config is configured correctly. Also, we don't need to
calculate hdmi_config during hdmi_power_on, or rely on the omap_video_timings
in the panel's omap_dss_device struct.
The default timings of the hdmi panel are represented in a cleaner form. Since
the hdmi output is now configured by it's own copy of timings (in
hdmi.ip_data.cfg), the panel driver needs to set it to a valid value before
enabling hdmi output. We now call omapdss_hdmi_set_timing() before enabling
hdmi output, this is done to atleast have the hdmi output configured to the
panel's default timings if the DSS user didn't call panel driver's set_timings()
op explicitly.
Signed-off-by: Archit Taneja <archit@ti.com>
During a command mode update using DISPC video port, we may need to swap the
connected overlay manager's width and height when 90 or 270 degree rotation is
done via the panel by changing it's address mode.
Call dss_mgr_set_timings() in update_screen_dispc() before starting the manager
update. The new manager size is updated in the 'timings' field of DSI driver's
private data via omapdss_dsi_set_size(). A panel driver is expected to call this
when performing rotation.
Signed-off-by: Archit Taneja <archit@ti.com>
DSI command mode panels don't need to configure a full set of timings to
configure DSI, they only require the width and the height of the panel in
pixels.
Use omapdss_dsi_set_size for command mode panels, omapdss_dsi_set_timings is
meant for video mode panels. When performing rotation via chaning the address
mode of the panel, we would need to swap width and height when doing 90 or 270
rotation. Make sure that omapdss_dsi_set_size() makes the new width and height
visible to DSI.
Signed-off-by: Archit Taneja <archit@ti.com>
The DSI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and DSI blocks accordingly. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DSI driver data maintain it's own timings field. A DSI video mode panel
driver is expected to call omapdss_dsi_set_timings() to set these timings before
the panel is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The timings maintained in omap_dss_device(dssdev->panel.timings) should be
maintained by the panel driver itself. It's the panel drivers responsibility
to update it if a new set of timings is to be configured. The DPI interface
driver shouldn't be responsible of updating the panel timings, it's responsible
of maintianing it's own copy of timings.
Signed-off-by: Archit Taneja <archit@ti.com>
The DPI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the DPI interface driver dependent
on the omap_dss_device struct.
Make the DPI driver data maintain it's own timings field. The panel driver is
expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set
these timings before the panel is enabled.
In the set_timings() op, we still ensure that the omap_dss_device timings
(dssdev->panel.timings) are configured. This will later be configured only by
the DPI panel drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
The generic DPI panel driver doesn't currently have locking to ensure that
the display states and the driver data is maintained correctly. Add mutex
locking to take care of this. Add a new get_timings driver op to override the
default get_timings op. The new driver op contains locking to ensure the correct
panel timings are seen when a DSS2 user calls device->driver->get_timings.
Signed-off-by: Archit Taneja <archit@ti.com>
The DPI interface driver currently relies on the panel driver to ensure calls
like omapdss_dpi_display_enable() and omapdss_dpi_display_disable() are executed
sequentially. Also, currently, there is no way to protect the DPI driver data.
All DPI panel drivers don't ensure this, and in general, a DPI panel driver
should use it's lock to that ensure it's own driver data and omap_dss_device
states are taken care of, and not worry about the DPI interface.
Add mutex locking in the DPI enable/disable/set_timings ops.
Signed-off-by: Archit Taneja <archit@ti.com>
The function dss_mgr_set_timings is supposed to apply timings passed by an
interface driver. It is not supposed to change the timings. Add const qualifier
to the omap_video_timings pointer argument in dss_mgr_set_timings().
Signed-off-by: Archit Taneja <archit@ti.com>
omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
echo -e '\e[0;31mRED' > /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DSS code wrongly assumes that VENC is always available as source for the external
sync signal for the display controller DIGIT channel. One cannot blindly write/read
the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5) this operation
may not be valid. If the the sync source is not read correctly, the callers of
dss_get_hdmi_venc_clk_source might make wrong assumptions about, for instance,
video timings.
Logic is added to correctly get the sync signal based on the available displays
in the DIGIT channel. The source is set only if both VENC and HDMI are supported.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We have no reason to block in the error handler workqueue, so use msleep.
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Small patch to disable the PLL appropriately before runtime_put in case
an error occurs while enabling the PHY.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This patch moves the contents from regs-fb-v4.h and regs-fb.h to
include/video/samsung_fimd.h. Also updates the header inclusion in
machine files and driver files accordingly.
Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The lp855x header is used only in the platform side, so it can be moved
into platform_data directory
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Bryan Wu <bryan.wu@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ROM boundary definitions do not need to be exported because these are
used only internally in the lp855x driver.
And few code cosmetic changes
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Bryan Wu <bryan.wu@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_gpio_request_one() for these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Alberto Panizzo <alberto@amarulasolutions.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_gpio_request() for these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_gpio_request() for these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_gpio_request() for these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Dmitry Baryshkov <dbaryshkov@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_gpio_request() for these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Dmitry Baryshkov <dbaryshkov@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_gpio_request() for these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The devm_ functions allocate memory that is released when a driver
detaches. This patch uses devm_gpio_request() for these functions.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chandrabhanu Mahapatra