DISPC functions have been modified to provide clock and register dumps and debug
support for the LCD3 manager.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The support for LCD3 manager has been added into the manager module. LCD3 panel
has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and
LCD2 panels. These registers control the Display Controller (DISPC) module for
LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame
Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can
be connected through parallel output interface using DISPC and RFBI or DPI. For
serial interface DSS uses DSI.
The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL
register which has been enabled. The clock switch chooses between DSS_CLK and
DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3,
DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have
been added specific to the new manager.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP5 Display Subsystem (DSS) architecture comes with a additional LCD3 channel
with its own dedicated overlay manager. The current patch adds LCD3 channel and
basic register support for LCD3 channel. It adds register addresses for various
Display Controller (DISPC) registers like DISPC_DEFAULT_COLOR, DISPC_TIMING_H,
DISPC_DIVISORo, etc.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The current implementation of LCD channels and managers consists of a number of
if-else construct which has been replaced by a simpler interface. A constant
structure mgr_desc has been created in Display Controller (DISPC) module. The
mgr_desc contains for each channel its name, irqs and is initialized one time
with all registers and their corresponding fields to be written to enable
various features of Display Subsystem. This structure is later used by various
functions of DISPC which simplifies the further implementation of LCD channels
and its corresponding managers.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
will always return 1 and pm_runtime_put_sync() will always return
-ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
print a warning.
One option would be to ignore errors returned by pm_runtime_put_sync()
totally, as they only say that the call was unable to put the hardware
into suspend mode.
However, I chose to ignore the returned -ENOSYS explicitly, and print a
warning for other errors, as I think we should get notified if the HW
failed to go to suspend properly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Grazvydas Ignotas <notasas@gmail.com>
The current way how omapdss handles system suspend and resume is that
omapdss device (a platform device, which is not part of the device
hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses
the suspend and resume callbacks from platform_driver to handle system
suspend. It does this by disabling all enabled panels on suspend, and
resuming the previously disabled panels on resume.
This presents a few problems.
One is that as omapdss device is not related to the panel devices or the
DSS HW devices, there's no ordering in the suspend process. This means
that suspend could be first ran for DSS HW devices and panels, and only
then for omapdss device. Currently this is not a problem, as DSS HW
devices and panels do not handle suspend.
Another, more pressing problem, is that when suspending or resuming, the
runtime PM functions return -EACCES as runtime PM is disabled during
system suspend. This causes the driver to print warnings, and operations
to fail as they think that they failed to bring up the HW.
This patch changes the omapdss suspend handling to use PM notifiers,
which are called before suspend and after resume. This way we have a
normally functioning system when we are suspending and resuming the
panels.
This patch, I believe, creates a problem that somebody could enable or
disable a panel between PM_SUSPEND_PREPARE and the system suspend, and
similarly the other way around in resume. I choose to ignore the problem
for now, as it sounds rather unlikely, and if it happens, it's not
fatal.
In the long run the system suspend handling of omapdss and panels should
be thought out properly. The current approach feels rather hacky.
Perhaps the panel drivers should handle system suspend, or the users of
omapdss (omapfb, omapdrm) should handle system suspend.
Note that after this patch we could probably revert
0eaf9f52e9 (OMAPDSS: use sync versions of
pm_runtime_put). But as I said, this patch may be temporary, so let's
leave the sync version still in place.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Jassi Brar <jaswinder.singh@linaro.org>
Tested-by: Jassi Brar <jaswinder.singh@linaro.org>
In preparation of OMAP moving to Common Clk Framework(CCF) change
clk_enable() and clk_disable() calls to clk_prepare_enable() and
clk_disable_unprepare() in omapdss. This can be safely done, as omapdss
never enables or disables clocks in atomic context.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: <linux-fbdev@vger.kernel.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>
[tomi.valkeinen@ti.com: updated patch description]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We have two almost the same enums: omap_channel and
omap_dss_overlay_managers. omap_channel is used almost everywhere, and
omap_channel assigns explicit values to the enum values which are needed
for proper operation.
omap_dss_overlay_managers is only used in one place, so it's easy to
remove it, which is what this patch does.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In function dsi_compute_interleave_lp(), the escape clock/LP clock time period
is calculated incorrectly. The escape clock/LP clock is calculated as:
LP Clock(Hz) = DSI_FCLK(Hz) / lp_clk_div
Since we are calculating the time period of LP clock, the LP clock divider
should be multiplied with the time period of DSI_FCLK.
Calculating incorrect value of txclkesc results in incorrect calculation of LP
interleaving parameters, it also creates a possibility of a divide by zero
error.
Reported-by: Sureshkumar Manimuthu <mail2msuresh@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
pm_runtime_put_sync() in dss_runtime_put() returns -EBUSY when any child
of dss is still enabled. This happens, for example, when a display
output is enabled and one dumps the clocks via debugfs. This causes
dss_runtime_get & put to be called.
While I couldn't find anything about this in the documentation and it
wasn't immediately clear from runtime_pm code, it looks to me that
pm_runtime_put_sync() returns -EBUSY to inform that things went fine,
but the device could not be turned off as there are still child devices
that are enabled. This is not a problem.
This patch skips the WARN_ON if pm_runtime_put_sync() returns -EBUSY.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If CONFIG_DEBUG_FS or CONFIG_OMAP2_DSS_DEBUG_SUPPORT is disabled, the
build fails:
drivers/video/omap2/dss/core.c:197:50: error: static declaration of
'dss_debugfs_create_file' follows non-static declaration
drivers/video/omap2/dss/dss.h:166:5: note: previous declaration of
'dss_debugfs_create_file' was here
This patch fixes the dummy dss_debugfs_create_file() so that the driver
builds.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
genirq requires that the IRQ requests that do not provided a handler to
use the IRQF_ONESHOT flag. This is to prevent situations in which the irq line
is reenabled while the interrupt is still asserted. While this situation may
not happen in edge type interrupts, genirq still requires to use IRQF_ONESHOT.
Also, remove the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The VENC interfaces uses it's venc_set_timing() function to take in a new set
of timings. If the panel is disabled, it does not disable and re-enable the
interface. Currently, the manager timings are applied in venc_power_on(), these
are not called by set_timings if the panel is disabled. When checking overlay
and manager data, the DSS driver uses the last applied manager timings, and not
the timings held by omap_dss_device struct. Hence, there is a need to apply the
new manager timings even if the panel is disabled.
Apply the manager timings if the VENC panel is disabled.
This is similar to the commit below which fixed the same issue for HDMI/DPI
interfaces:
fcc3661990
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DSS2 driver uses the timings in manager's private data to check the validity of
overlay and manager infos written by the user. For VENC interface, we divide the
Y resolution by half when writing to the DISPC_DIGIT_SIZE register as the
content is interlaced. However, the height of the manager/display with respect
to the content shown through VENC still remains the same.
The VENC driver divides the y_res parameter in omap_video_timings by half, and
then applies the configuration. This leads to manager's private data storing
the wrong Y resolution. Hence, overlay related checks fail.
Ensure that manager's private data stores the original timings, and the Y
resolution is halved only when we write to the DISPC register. This is a hack,
the proper solution would be to pass some sort of interlace parameter which
makes the call whether we should divide y_res or not.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner.
Physical memory can be mapped to a portion of OMAP's system address space called
TILER address space. The TILER address space is split into 8 views. Each view
represents a rotated or mirrored form of the mapped physical memory. When a
DISPC overlay's base address is programmed to one of these views, the TILER
fetches the pixels according to the orientation of the view. A view is further
split into 4 containers, each container holds elements of a particular size.
Rotation can be achieved at the granularity of elements in the container. For
more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM.
Rotation type TILER has been added which is used to exploit the capabilities of
these 8 views for performing various rotations.
When fetching from addresses mapped to TILER space, the DISPC DMA can fetch
pixels in either 1D or 2D bursts. The fetch depends on which TILER container we
are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts,
and page mode sized containers require 1D bursts.
The DSS2 user is expected to provide the Tiler address of the view that it is
interested in. This is passed to the paddr and p_uv_addr parameters in
omap_overlay_info. It is also expected to provide the stride value based on the
view's orientation and container type, this should be passed to the screen_width
parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is
used to calculate the required row_inc for DISPC. x_predecim and y_predecim are
also used to calculate row_inc and pix_inc thereby adding predecimation support
for TILER.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.
This patch fixes the warnings by initializing the variables and
returning properly after BUG() lines. However, the behaviour is still
undefined after the BUG, but this is the choice the user makes when
using CONFIG_BUG=n.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Commit 05dd0f5308 ("OMAPDSS: DISPC: Update
Accumulator configuration for chroma plane") adds
dispc_ovl_set_accu_uv() function that sets the accu, but the function
only handles YUV and NV12 modes, and BUGs otherwise.
The patch also adds a call to the function, but unfortunately the place
of call was such that the mode could be other than YUV or NV12, thus
crashing the driver.
This patchs moves the call to a slightly later spot, at which point only
YUV and NV12 modes are handled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
There is a problem related to DSS FIFO thresholds and power management
on OMAP3. It seems that when the full PM hits in, we get underflows. The
core reason is unknown, but after experiments it looks like only
particular FIFO thresholds work correctly.
This bug is related to an earlier patch, which added special FIFO
threshold configuration for OMAP3, because DSI command mode output
didn't work with the normal threshold configuration.
However, as the above work-around worked fine for other output types
also, we currently always configure thresholds in this special way on
OMAP3. In theory there should be negligible difference with this special
way and the standard way. The first paragraph explains what happens in
practice.
This patch changes the driver to use the special threshold configuration
only when the output is a manual update display on OMAP3. This does
include RFBI displays also, and although it hasn't been tested (no
boards using RFBI) I suspect the similar behaviour is present there
also, as the DISPC side should work similarly for DSI command mode and
RFBI.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Joe Woodward <jw@terrafix.co.uk>
DSI supports interleaving of command mode packets during the HSA, HFP, HBP and
BLLP blanking intervals in a video mode stream. This is useful as a user may
want to read or change the configuration of a panel without stopping the video
stream.
On OMAP DSI, we can queue HS or LP command mode packets in the TX FIFO, and
the DSI HW takes care of interleaving this data during the one of the blanking
intervals. The DSI HW needs to be programmed with the maximum amount of data
that can be interleaved in a particular blanking period. A blanking period
cannot be used to send command mode data for it's complete duration, there is
some amount of time required for the DSI data and clock lanes to transition
to the desired LP or HS state.
Based on the state of the lanes at the beginning and end of the blanking period,
we have different scenarios, with each scenario having a different value of time
required to transition to HS or LP. Refer to the section 'Interleaving Mode' in
OMAP TRM for more info on the scenarios and the equations to calculate the time
required for HS or LP transitions.
We use the scenarios which takes the maximum time for HS or LP transition, this
gives us the minimum amount of time that can be used to interleave command mode
data. The amount of data that can be sent during this minimum time is calculated
for command mode packets both in LP and HS. These are written to the registers
DSI_VM_TIMING4 to DSI_VM_TIMING6.
The calculations don't take into account the time required of transmitting BTA
when doing a DSI read, or verifying if a DSI write went through correctly. Until
these latencies aren't considered, the behaviour of DSI is unpredictable when
a BTA is interleaved during a blanking period. Enhancement of these calculations
is a TODO item.
The calculations are derived from DSI parameter calculation tools written by
Sebastien Fagard <s-fagard@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DISPC has two accumulator registers DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1 each
with horizontal and vertical bit fields. The bit fields can take values in the
range of -1024 to 1023. Based on bit field values DISPC decides on which one out
of 8 phases the filtering starts. DISPC_VIDp_ACCU_0 is used for progressive
output and for interlaced output both DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
are used.
The current accumulator values in DISPC scaling logic for chroma plane takes
default values for all color modes and rotation types. So, the horizontal and
vertical up and downsampling accumulator bit field values have been updated for
better performance.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Implement the DSS device driver audio support interface in the HDMI
panel driver and generic driver. The implementation relies on the
IP-specific functions that are defined at DSS probe time.
A mixed locking strategy is used. The panel's mutex is used when
the state of the panel is queried as required by the audio functions.
The audio state is protected using a spinlock as users of DSS HDMI
audio functionality might start/stop audio while holding a spinlock.
The mutex and the spinlock are held and released as needed by each
individual function to protect the panel state and the audio state.
Although the panel's audio_start functions does not check whether
the panel is active, the audio _ENABLED state can be reached only
from audio_enable, which does check the state of the panel. Also,
if the panel is ever disabled, the audio state will transition
to _DISABLED. Transitions are always protected by the audio lock.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
As the hdmi_lock mutex is inside the hdmi struct, rename to simply
"lock". This is only a change in the name. There are not changes
in functionality.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
As of today, the only know user of the DSS HDMI audio support is
ASoC. Hence, it makes sense to remap the speaker order to match
the ALSA speaker order. In the future, a dynamic mapping mechanism
may be implemented.
Remapping is needed as the HDMI speaker order is FL/FR/LFE/C/RL/RR/
RLC-FLC/RRC-FLC while the ALSA order is FL/FR/RL/RR/C/LFE/SL/SR.
Refer to CEA-861 Section 6.6.2 for further details.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
The generic HDMI driver does not need to know about the specific
settings of a given IP. Hence, it just passes the audio configuration
and the IP library parses such configuration and sets the IP
accordingly. This patch introduces an IP-specific audio configuration
function.
Also, this patch implements the audio config function for OMAP4. The
DMA, format and core config functions are no longer exposed to the
generic HDMI driver as they are IP-specific.
The audio configuration function caters for 16-bit through 24-bit
audio samples with sample rates from 32kHz and up to 192kHz as well
as up to 8 audio channels.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Add support for more sample rates when calculating N and CTS. This
covers all the audio sample rates that an HDMI source is allowed
to transmit according to the HDMI 1.4a specification.
Also, reorganize the logic for the calculation when using deep color.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
The N and CTS parameters are relevant to all HDMI implementations and
not specific to a given IP. Hence, the calculation is relocated
into the generic HDMI driver.
Also, deep color is not queried but it is still considered in the
calculation of N. This is to be changed when deep color functionality is
implemented in the driver.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Utilize a snd_aes_iec958 struct to write the parameters of the IEC-60958
channel status word into the HDMI IP registers. Hence, the user of the
driver has full control of what parameters are written in the word.
Also, some of the parameters of the I2S structure have been removed
as they are actually IEC-60958 parameters.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Instead of having OMAPDSS HDMI audio functionality depending on the
ASoC HDMI audio driver, use a new config option so that
potential users, including ASoC, may select if needed.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Decouple the enable/disable operation of the HDMI audio wrapper from
audio start/stop. Otherwise, an audio FIFO underflow may occur. The
audio wrapper enablement must be done after configuration and
before audio playback is started.
Signed-off-by: Axel Castaneda Gonzalez <x0055901@ti.com>
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
According to the most up-to-date documentation from Texas Instruments,
the configuration of High Bitrate Audio is not possible. Also, it is
not possible to set polarity of the I2S Word Select signal. This patch
removes the invalid settings.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Instead of having its own definitions for CEA-861 and IEC-60958, the HDMI
driver should use those provided by ALSA. This patch removes the definitions
that are already provided by ALSA.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Remove the ASoC OMAP HDMI audio codec. The goal of removing the codec
is to, in subsequent patches, give way to the implementation of the HDMI
audio support using the DSS device driver audio interface. This
approach will expose the HDMI audio functionality to any interested entity.
In a separate patch, ASoC will use this new approach to expose HDMI audio
to ALSA.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
To improve readability, split the video_enable HDMI IP operation
into two separate functions for enabling and disabling video.
The video_enable function is also modified to return an error value.
While there, update these operations for the OMAP4 IP accordingly.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
To improve readability, split the audio_enable HDMI IP operation
into two separate functions for enabling and disabling audio.
The audio_enable function is also modified to return an error value.
While there, update these operations for the OMAP4 IP accordingly.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Move the platform-data based display device initialization into a
separate function, so that we may later add of-based initialization.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We currently use the id of the dsi platform device (dsidev->id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.
Instead of using dsidev->id during operation, this patch stores the
value of dsidev->id to a private field of the dsi driver at probe(). The
future device tree code can thus set the private field with some other
way.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Now that each output driver creates their own display devices, the
output drivers can also initialize those devices.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Currently the higher level omapdss platform driver gets the list of
displays in its platform data, and uses that list to create the
omap_dss_device for each display.
With DT, the logical way to do the above is to list the displays under
each individual output, i.e. we'd have "dpi" node, under which we would
have the display that uses DPI. In other words, each output driver
handles the displays that use that particular output.
To make the current code ready for DT, this patch modifies the output
drivers so that each of them creates the display devices which use that
output. However, instead of changing the platform data to suit this
method, each output driver is passed the full list of displays, and the
drivers pick the displays that are meant for them. This allows us to
keep the old platform data, and thus we avoid the need to change the
board files.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We currently have a two ways to set a "default panel device" for dss, to
which the overlays are connected when the omapdss driver is loaded:
- in textual format (name of the display) as cmdline parameter
- as a pointer to the panel device from board file via pdata
The current code handles this in a bit too complex way by using both of
the above methods during runtime. However, with DT we don't have pdata
anymore, so the code handling the second case won't work anymore. The
current code has also the problem that it modifies the platform_data.
This patch simplifies the code a bit by using the pointer method only
inside the probe function, and stores the name of the panel device. This
way we only need to handle the textual format during operation and also
avoid modifying the platform_data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Now that the core.c doesn't fail if output driver's init fails, we can
change the uses of platform_driver_register to platform_driver_probe.
This will allow us to use __init in the following patches.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of having an ugly #ifdef mess in the core.c for creating debugfs
files, add a dss_debugfs_create_file() function that the dss drivers
can use to create the debugfs files.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Now that the omapdss_core device is the parent for all other dss
devices, we don't need to use the dss_runtime_get/put anymore. Instead,
enabling omapdss_core will happen automatically when a child device is
enabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI & SDI somehow differently than the rest would just make the
code more complex.
This patch modifies the dpi.c and sdi.c to create drivers for the
platform devices.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The platform devices for omapdss, dss and dispc drivers are always
present, so we can use platform_driver_probe instead of
platform_driver_register.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
For unknown reasons we seem to have a return in each of the omapdss's
uninit functions, which is a void function.
Remove the returns.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI
instance. However, there were a few places where dsidev->id was used
instead of the function. Fix those places to use the function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
VENC output type (composite/svideo) doesn't have to be fixed by board
wiring, it is possible to also provide composite signal through svideo
luminance connector (software enabled), which is what pandora does.
Having to recompile the kernel for users who have TV connector types
that don't match default board setting is very inconvenient, especially
for users of a consumer device, so add support for switching VENC output
type at runtime over a new sysfs file output_type.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Conflicts:
drivers/video/omap2/displays/panel-taal.c
Merge OMAP DSS related board file changes. The branch will also be
merged through linux-omap tree to solve conflicts.
The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
function dispc_mgr_get_device() to get the omap_dss_device pointer to which
the manager is connected, the width of the panel is derived from that.
The manager's timing is stored in it's private data in APPLY. This contains
the latest timings applied to the manager. Pass these timings to
dispc_ovl_setup() and use them in the above functions. Remove the function
dispc_mgr_get_device() as it isn't used any more.
Signed-off-by: Archit Taneja <archit@ti.com>
The pixel clock rate for the TV manager is calculated by checking the device
type connected to the manager, and then requesting the VENC/HDMI interface for
the pixel clock rate.
Remove the use of omap_dss_device pointer from here by checking which interface
generates the pixel clock by reading the DSS_CTRL.VENC_HDMI_SWITCH bit.
Signed-off-by: Archit Taneja <archit@ti.com>
The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
the pointer variable declaration and it's assignment.
Signed-off-by: Archit Taneja <archit@ti.com>
The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
set of timings. If the panel is disabled, they do not disable and re-enable
the interface. Currently, the manager timings are applied in hdmi_power_on()
and dpi_set_mode() respectively, these are not called by set_timings if the
panel is disabled.
When checking overlay and manager data, the DSS driver uses the last applied
manager timings, and not the timings held by omap_dss_device struct. Hence,
there is a need to apply the new manager timings even if the panel is disabled.
Apply the manager timings if the panel is disabled. Eventually, there should be
one common place where the timings are applied independent of the state of the
panel.
Signed-off-by: Archit Taneja <archit@ti.com>
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Pass the manager's timings in private data to dss_mgr_check(). Remove the need
to pass omap_dss_device structs in the functions which check for the validity
of overlay and manager parameters.
Signed-off-by: Archit Taneja <archit@ti.com>
If a manager is disabled, there is no guarantee at any point in time that all
it's parameters are configured. There is always a chance that some more
parameters are yet to be configured by a user of DSS, or by DSS itself.
However, when the manager is enabled, we can be certain that all the parameters
have been configured, as we can't enable a manager with an incomplete
configuration. Therefore, if a manager is disabled, don't check for the validity
of it's parameters or the parameters of the overlays connected to it. Only check
once it is enabled. Add a check in dss_check_settings_low() to achieve the same.
Signed-off-by: Archit Taneja <archit@ti.com>
Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.
dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the omap_dss_device struct. This would be later
replaced by the timings stored in the manager's private data.
Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
omap_video_timings pointer since these functions just check the timings.
Signed-off-by: Archit Taneja <archit@ti.com>
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.
Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit
is set by dss_mgr_set_timings().
Signed-off-by: Archit Taneja <archit@ti.com>
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.
To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar to what is done for overlays. This is needed
because timings aren't a part of overlay_manager_info struct configured by a
user of DSS, they are configured internally by the interface or panel drivers.
Add dirty and shadow_dirty extra_info flags for managers, update these flags
at the appropriate places. Rewrite the function extra_info_update_ongoing()
slightly as checking for manager's extra_info flags can simplify the code a bit.
Create function dss_mgr_set_timings() which applies the new manager timings to
extra_info.
Signed-off-by: Archit Taneja <archit@ti.com>
Fake VSYNC support is a hack and has some bugs in it. It isn't used by any user
of DSS. Remove Fake VSYNC support. For DSI command mode and RFBI panels, a user
of DSS should wait for the completion of a frame by using the panel driver's
sync op.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The wrong bit field was being updated in DSS_CTRL when trying to configure the
clock source of DSI2 functional clock. Use the correct bit field based on the
dsi module number.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The HDMI core register offset macros aren't defined in ascending order of their
values, some of the offset macros are also redefined. The same issues occur when
these core registers are dumped.
Clean up the ordering of HDMI core registers and remove repeated registers in
the definition in ti_hdmi_4xxx_ip.h and in ti_hdmi_4xxx_core_dump().
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The function ti_hdmi_4xxx_core_dump has some bugs, the following mention the
bugs and the solutions:
- The macros DUMPCORE and DUMPCOREAV in ti_hdmi_4xxx_core_dump() use
hdmi_pll_base() for the offsets needed to calculate register addresses, use
functions hdmi_core_sys_base() amd hdmi_av_base() to calculate the correct
offsets for CORE_SYS and CORE_AV registers.
- Many of the CORE_AV registers use the DUMPCORE macro, and hence the register
addresses are calculated incorrectly. Rename the current DUMPCOREAV macro as
DUMPCOREAV2 as it takes 2 arguments to dump indexed CORE_AV registers, create
a new macro called DUMPCOREAV which is now used for dumping non-indexed
CORE_AV registers.
Thanks to Ancy Tom <ancytom@gmail.com> for pointing out the issues.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.
This patch moves the configuration data to the panel's platform data,
and the data can easily be given via DT in the future. The configuration
data format is also changed to a generic one which should be suitable
for all platforms.
The new format is an array of pin numbers, where the array items start
from clock + and -, then data1 + and -, and so on. For example:
{
0, // pin num for clock lane +
1, // pin num for clock lane -
2, // pin num for data1 lane +
3, // pin num for data1 lane -
...
}
The pin numbers are translated by the DSI driver and used to configure
the hardware appropriately.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
DISPC_FCLK is incorrectly used as functional clock of DISPC in scaling
calculations. So, DISPC_CORE_CLK replaces as functional clock of DISPC.
DISPC_CORE_CLK is derived from DISPC_FCLK divided by an independent DISPC
divisor LCD.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver rejects
configuration exceeding above limitations.
This code was successfully tested on OMAP3. This code is written based on code
written by Ville Syrjälä <ville.syrjala@nokia.com> in Linux OMAP kernel. Ville
Syrjälä <ville.syrjala@nokia.com> had added checks for video overlay horizontal
timing and DISPC horizontal blanking length limitations.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
up to 2 times in OMAP2. However, with predecimation, the image can be reduced
to 16 times by fetching only the necessary pixels in memory. Then this
predecimated image can be downscaled further by the DISPC scaler.
The pipeline is configured to use a burst of size 8 * 128 bits which consists
of 8 mini bursts of 16 bytes each. So, horizontal predecimation more than 16
can lead to complete discarding of such mini bursts. L3 interconnect may
handover the bus to some other initiator and inturn delay the fetching of
pixels leading to underflows. So, maximum predecimation limit is fixed at 16.
Based on the downscaling required, a prior calculation of predecimation values
for width and height of an image is done. Since, Predecimation reduces quality
of an image higher priorty is given to DISPC Scaler for downscaling.
This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and
vertical predecimation worked fine except for some synclost errors due to
undocumented errata in OMAP3 which are fixed later and skewed images were seen
on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in
the future patches.
This code is based on code written by Lajos Molnar <lajos@ti.com> who had added
predecimation support for NV12/YUV/rotated/SDMA buffers.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Clean up the DISPC manager timings related function by:
- Create a common function to set size for LCD and TV.
- Create a common function to check timings for LCD and TV.
- Add dss params to get the range of manager size.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Currently, a LCD manager's timings is set by dispc_mgr_set_lcd_timings() and TV
manager's timings is set by dispc_set_digit_size(). Use a common function called
dispc_mgr_set_timings() which sets timings for both type of managers.
We finally want the interface drivers to use an overlay manager function to
configure it's timings, having a common DISPC function would make things
cleaner.
For LCD managers, dispc_mgr_set_timings() sets LCD size and blanking values, for
TV manager, it sets only the TV size since blanking values don't exist for TV.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The RFBI driver uses dispc_mgr_set_lcd_size() to set the width and height of
the LCD manager. Replace this to use dispc_mgr_set_lcd_timings(), pass dummy
blanking parameters like done in the DSI driver.
This prevents the need to export dispc_mgr_set_lcd_size(), and use a common
function to set lcd timings.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
For some OMAP versions the TRM says that the pixel clock from DISPC can
be used as an input clock for DSI PLL, instead of the default, which is
sysclk. For some OMAP versions the bits affecting this are marked as
reserved. This feature has never been tested, so it's unknown if the HW
even works, and has never been used.
To clean things up, this patch removes the functionality. This should
not affect any board.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Most of the DSS clocks have restrictions on their frequency based on the
OPP in use. For example, maximum frequency for a clock may be 180MHz in
OPP100, but 90MHz in OPP50. This means that when a high enough pixel
clock or function clock is required, we need to use OPP100.
However, there's currently no way in the PM framework to make that kind
of request. The closest we get is to ask for very high bus throughput
from the PM framework, which should effectively force OPP100.
This patch is a simple version for handling the problem. Instead of
asking for OPP100 only when needed, this patch asks for OPP100 whenever
DSS is active. This obviously is not an optimal solution for cases with
small displays where OPP50 would work just fine. However, a proper
solution is a complex one, and this patch is a short term solution for
the problem.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Quite a bit of code gets removed, and some stuff moved around, mostly
the old samsung s3c24xx stuff. There should be no functional changes
in this series otherwise. Some cleanups have dependencies on other
arm-soc branches and will be sent in the second round.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIVAwUAT2pCjGCrR//JCVInAQLd8RAAqCxhzSc4ewTUP/974gVhujj3TrpiEQcS
FKvYWF76yP38Lbf3CJZBZaONRtrQNOhYpVQ0jb3WCV4F8mEH9PCes2q9RObeBYiY
TNX8VdcuVjX2U9HaH0+RQtBUdujNLHpEOqtO57un7T5UDNssR5JOive1tNAooRv1
pL0Hgx3AVqUbNOPpqQqHzy/MDdd67S6dX80yysANjFGMX87Nvp/ztYAdNnIdta+Z
pDJt+DPlmK8LvjoSL3SEUN0p3Thk75621cCuauGq88PLIB2w62tzF0NFFbvIAgJT
3aMlHM2flOiTJAWkUvA8zJiUzwv/0vYvH3xPoTo84abve3lVfZcY+fHNcfxE/Gge
ri2MmkHyimVP3rNeyM0GbN1RTej1TN1MezeQW3nq2wP6nvS2k0/t32ObLLtWU7XA
6iA0hKVMSnhqj4ln6jPAmyaDkaWHyYz97urhgetHqGadvLTiGPXCSBPalSiFmyMo
11tvuqwUNz9tw4nsvGboFQwS2ZoVquC5inoHp5seqZETkGCB67JyeRGxtAM4gbP/
wIRa3OBLY99yo1on6QovWNnSOMC6X4cOvBI/qHIjSEY/T9JVkslY87gRg3LkxCBR
XpXfZ6iuLHoSRUGcIjE8D6KHjMgWIDPRnLkIliK4H+3Jn08g0R1MxCplevFCRtis
egswZ8C24Xw=
=o5Xl
-----END PGP SIGNATURE-----
Merge tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull "ARM: global cleanups" from Arnd Bergmann:
"Quite a bit of code gets removed, and some stuff moved around, mostly
the old samsung s3c24xx stuff. There should be no functional changes
in this series otherwise. Some cleanups have dependencies on other
arm-soc branches and will be sent in the second round.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>"
Fixed up trivial conflicts mainly due to #include's being changes on
both sides.
* tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (121 commits)
ep93xx: Remove unnecessary includes of ep93xx-regs.h
ep93xx: Move EP93XX_SYSCON defines to SoC private header
ep93xx: Move crunch code to mach-ep93xx directory
ep93xx: Make syscon access functions private to SoC
ep93xx: Configure GPIO ports in core code
ep93xx: Move peripheral defines to local SoC header
ep93xx: Convert the watchdog driver into a platform device.
ep93xx: Use ioremap for backlight driver
ep93xx: Move GPIO defines to gpio-ep93xx.h
ep93xx: Don't use system controller defines in audio drivers
ep93xx: Move PHYS_BASE defines to local SoC header file
ARM: EXYNOS: Add clock register addresses for EXYNOS4X12 bus devfreq driver
ARM: EXYNOS: add clock registers for exynos4x12-cpufreq
PM / devfreq: update the name of EXYNOS clock registers that were omitted
PM / devfreq: update the name of EXYNOS clock register
ARM: EXYNOS: change the prefix S5P_ to EXYNOS4_ for clock
ARM: EXYNOS: use static declaration on regarding clock
ARM: EXYNOS: replace clock.c for other new EXYNOS SoCs
ARM: OMAP2+: Fix build error after merge
ARM: S3C24XX: remove call to s3c24xx_setup_clocks
...
We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.
There doesn't seem to be any reason for that, and additionally the
soon-to-be-merged patch "ARM: OMAP: omap_device: remove
omap_device_parent" will break omapdss initialization with the current
registration model.
This patch changes the registration for all drivers to happen at the
same place, in the init of the module.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* 'next/cleanup-exynos-clock' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Add clock register addresses for EXYNOS4X12 bus devfreq driver
ARM: EXYNOS: add clock registers for exynos4x12-cpufreq
PM / devfreq: update the name of EXYNOS clock registers that were omitted
PM / devfreq: update the name of EXYNOS clock register
ARM: EXYNOS: change the prefix S5P_ to EXYNOS4_ for clock
ARM: EXYNOS: use static declaration on regarding clock
ARM: EXYNOS: replace clock.c for other new EXYNOS SoCs
(includes an update to v3.3-rc6)
Currently the shadow-dirty flags for manual update displays is cleared
in the apply_irq_handler when an update has finished. This is not
correct, as the shadow registers are taken into use (i.e. after that
they are not dirty) when the update is started.
Move the mgr_clear_shadow_dirty() call from apply_irq_handler to
dss_mgr_start_update() to fix this.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
wait_pending_extra_info_updates() currently does a hacky second check
for extra_info_update_ongoing() at the end of the function to show a
warning if extra_info update is still ongoing. The call to
extra_info_update_ongoing() should really be inside spinlock, but that's
a bit heavy just for verification.
Rather than that, check the return value of the
wait_for_completion_timeout() and print an error if it has timeouted or
returned an error.
Even better would be to return the error value and act on it in the
callers of wait_pending_extra_info_updates. However, it's not clear what
the callers should do in case of an error, as the error should only
happen if there's a bug in the driver or the HW. So we'll just print the
warning for now.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If DSS suspends within the functions dss_mgr_wait_for_go(),
dss_mgr_wait_for_go_ovl() or dss_mgr_wait_for_vsync(). It may lose it's clock
and lead to a register access failure.
Request runtime_pm around these functions.
[archit@ti.com: Moved runtime_pm calls to wait_for_go/vsync functions rather
then calling them from omap_dispc_wait_for_irq_interruptible_timeout()]
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
coef3_M8 had an incorrect phase with 50% more intensity. This resulted in
banding on slightly down/upscaled images. Fixed a rounding error in coef5_M9.
Also removed ARRAY_LEN macro as ARRAY_SIZE is the standard linux one.
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add missing but supported color formats for GFX pipeline in dss features:
RGBX16-4444, RGBA16-4444 and XRGB16-1555.
In dispc_ovl_set_color_mode():
- Remove unsupported modes on GFX pipeline: YUV2 and UYVY. Replace these by
missing modes supported by GFX pipelines: RGBX16-4444 and RGBA16-4444.
- Fix swapped modes on VID pipelines: RGBX16-4444 and XRGB16-4444.
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
While calculating regm and regmf value add using M2 divider in
the equation.
Formula for calculating:
Output clock on digital core domain:
CLKOUT = (M / (N+1))*CLKINP*(1/M2)
Internal oscillator output clock on internal LDO domain:
CLKDCOLDO = (M / (N+1))*CLKINP
The current code when allows variable M2 values as input
ignores using M2 divider values in calculation of regm and regmf.
so fix it by using M2 in calculation although the default value for
M2 is 1.
Signed-off-by: Mythri P K <mythripk@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ovl->enable/disable are meant to be synchronous so that they can handle
the configuration of fifo sizes. The current kernel doesn't configure
fifo sizes yet, and so the code doesn't need to block to function (from
omapdss driver's perspective).
However, for the users of omapdss a non-blocking ovl->disable is
confusing, because they don't know when the memory area is not used
any more.
Furthermore, when the fifo size configuration is added in the next merge
window, the change from non-blocking to blocking could cause side
effects to the users of omapdss. So by making the functions block
already will keep them behaving in the same manner.
And, while not the main purpose of this patch, this will also remove the
compile warning:
drivers/video/omap2/dss/apply.c:350: warning:
'wait_pending_extra_info_updates' defined but not used
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes
ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
ARM: OMAP: Remove plat/io.h by splitting it into mach/io.h and mach/hardware.h
ARM: OMAP2+: Move most of plat/io.h into local iomap.h
ARM: OMAP1: Move most of plat/io.h into local iomap.h
ARM: OMAP1: Move 16xx GPIO system clock to platform init code
ARM: OMAP: Move omap_init_consistent_dma_size() to local common.h
ARM: OMAP2+: Move SDRC related functions from io.h into local common.h
ARM: OMAP2+: Drop DISPC L3 firewall code
ARM: OMAP2xxx: PM: remove obsolete timer disable code in the suspend path
ARM: OMAP: McSPI: Remove unused flag from struct omap2_mcspi_device_config
(update to latest rmk/for-arm-soc branch)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This is needed to minimize io.h so the SoC specific io.h
for ARMs can removed.
Note that minimal driver changes for DSS and RNG are needed to
include cpu.h for SoC detection macros.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This is only needed when using SRAM for framebuffer,
and the support for SRAM framebuffer is about to get
removed.
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
The "OMAPDSS: HDMI: PHY burnout fix" commit switched the HDMI driver
over to using a GPIO for plug detect. Unfortunately the ->detect()
method was not also updated, causing HDMI to no longer work for the
omapdrm driver (because it would actually check if a connection was
detected before attempting to enable display).
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
For DSS clock domain to transition from idle to active state. It's necessary
to enable the optional clock DSS_FCLK before we enable the module using the
MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register.
This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
called for hdmi's platform device.
Since the clock domain failed to change it's state to active, the hwmod code
disables any clocks it had enabled before for this hwmod. This led to the clock
'dss_48mhz_clk' gettind disabled.
When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
correctly enables the DSS clock domain this time. However, the clock
'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was
disabled previously, the driver fails when it tries to enable HDMI's PHY.
Fix this for now by ensuring that dss_runtime_get() is called before we call
pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would
be to modify the DSS related hwmod's mainclks, and also some changes in how
opt clocks are handled in the DSS driver.
This fixes the issue of HDMI not working when it's the default display. The
issue is not seen if any other display is already enabled as the first display
would have correctly enabled the DSS clockdomain.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP SRAM can be used as video memory on OMAP1 and 2. However, there
usually is very little SRAM available, thus limiting its use, and no
board supported by the kernel currently uses it.
This patch removes the use of SRAM as video ram for the omapdss driver
to simplify memory handling.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The MCLK mode defines a factor to divide the clock that is used to
generate the Audio Clock Regeneration packets, MCLK.
The divisor is not used when the CTS value is calculated by HW.
When the value is calculated by SW, it depends on the silicon
revision.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When the MCLK is used to drive the Audio Clock Regeneration packets,
the initialization procedure is to set ACR_CTRL[2] to 0 and then
back again to 1. Also, devices that do not support the MCLK, use
the TMDS clock directly by leaving ACR_CTRL[2] set to 0.
The MLCK clock divisor, mclk_mode, is configured only if MLCK
is used. Such configuration is no longer related to the CTS mode
as in some silicon revisions CTS SW-mode is used along with the MCLK.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Certain OMAP4 revisions (i.e., 4430 ES2.3, 4460, and 4470) use
a pseudo clock (generated from the TMDS clock), MCLK, to drive the
generation of Audio Clock Regeneration packets. Other devices
(i.e., 4430 ES2.[0,2]) use the TMDS clock directly.
This patch adds a new DSS feature for MCLK support. It also rearranges
the omap_dss_features structures to reflect the devices supporting it.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the ip_data structure.
Signed-off-by: Mythri P K <mythripk@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The calculation of required DISPC_FCLK for downscaling is done by multplying the
pixel clock with an integer factor. This isn't true for OMAP4 where the required
clock is calculated using the exact ratio of downscaling done.
Fix this calculation for OMAP4. Also, do a minor clean up of calc_fclk().
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The number of dss_feat_id members has increased to a large value, the current
way of assigning a subset of these features (for a particular OMAP) as a mask
is no longer feasible.
Maintain the subset of features supported as lists. Make the function
dss_has_feature() traverse through this list.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Now that dss is using devm_ functions for allocation in probe functions,
small reordering of the allocations allows us to clean up the probe
functions more.
This patch moves "unmanaged" allocations after the managed ones, and
uses plain returns instead of gotos where possible. This lets us remove
a bunch of goto labels, simplifying the probe's error handling.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
It includes:
- a compile fix for fsl-diu-fb
- a fix for a suspend/resume issue in atmel_lcdfb
- a fix for a suspend/resume issue in OMAP
- a workaround for a hardware bug to avoid physical damage in OMAP
- a really trivial dead code removal in intelfb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
iQIcBAABAgAGBQJPMG54AAoJECSVL5KnPj1PR6QQAKOoD4luFRw2F85jdk4GYBiX
WqUWc1OlKYxCGIhk6LpV6fwBLDZCTjOw9NU/9i3JIOHAscGzqVvUce1zYwolEu0B
tTH15/6Bh6uuRJEKYF8H53t1vsbrutssvUsqVcJsHrfie6bVjqjGV18cLT9siVy5
jEZnU958Nb7t8hk7Af1ppQkbB4cpExHX4k3hXTKM+dOkRWMaH1fHv2dnikKuYXDq
G7PC57VqN89DP14M+isUGt5uUgaMSmI09VdTYZ8xgULaZwOxnfOQNnceb/AaKnTY
I2oHDNlNwmiHVgafN7uS0tAhIqnlYOAVLJNLlDfL7xC71AyH6WtzwJuhXnqun7v6
moSwzzGKHohCXyeTjMAthx6HyLq55fBPAI1CmEEtmFLMv1tADLAp9Rm4dsaAjyF8
7aKJO/9iGEpolLYjAGJGGjgCALa+/NWdXnW/zP/2vmcjAaPOZtd0YlD3OaPYr31p
0cImhG57xIAfh60BRq+/FDthEN478Xj8f2jRe/2nsonw8JuFodZZ6nUaFeQS25X/
X/07Wkvmz2CY8FoPeXDHaKO8B1wJphzvY2iJjDwI1jg8u/PT2agILNM24tH3SVky
s6nyBLOEBHZh7mVwll2YifjZ6zzJm4y09LzgZpqXmUXOYPDn5JP9yZE4+R23RaEY
kVz8fkE/FjmjAlx/WjKa
=2uP4
-----END PGP SIGNATURE-----
Merge tag 'fbdev-fixes-for-3.3-1' of git://github.com/schandinat/linux-2.6
fbdev fixes for 3.3
It includes:
- compile fix for fsl-diu-fb
- fix for a suspend/resume issue in atmel_lcdfb
- fix for a suspend/resume issue in OMAP
- workaround for a hardware bug to avoid physical damage in OMAP
- really trivial dead code removal in intelfb
* tag 'fbdev-fixes-for-3.3-1' of git://github.com/schandinat/linux-2.6:
atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume
intelfb: remove some dead code
drivers/video: compile fixes for fsl-diu-fb.c
OMAPDSS: HDMI: PHY burnout fix
OMAP: 4430SDP/Panda: add HDMI HPD gpio
OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
OMAPDSS: remove wrong HDMI HPD muxing
OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
OMAPDSS: use sync versions of pm_runtime_put
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.
The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.
The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
"ticking" and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omapdss doesn't work properly on system suspend. The problem seems to be
the fact that omapdss uses pm_runtime_put() functions when turning off
the hardware, and when system suspend is in process only sync versions
are allowed.
Using non-sync versions normally and sync versions when suspending would
need rather ugly hacks to convey the information of
suspending/not-suspending to different functions. Optimally the driver
wouldn't even need to care about this, and the PM layer would handle
syncing when suspend is in process.
This patch changes all omapdss's pm_runtime_put calls to
pm_runtime_put_sync. This fixes the suspend problem, and probably the
performance penalty of always using sync versions is negligible.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Commit ba02fa37de disabled the
venc driver registration on OMAP4. Since the driver never gets
probed/initialised your get a dereferenceed NULL pointer if you
try to get info from /sys/kernel/debug/omapdss/venc
Return info message about disabled venc if venc_dump_regs() gets called.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Due to changes in struct hdmi_config, the pixel clock has to be obtained
differently.
The pixel clock is needed to calculate the CTS value as defined in the
HDMI specification.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
code and mode parameters are already a part of the ip_data structure
so no need to keep the same parameters again in hdmi global structure.
Signed-off-by: Mythri P K <mythripk@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Change the timing match logic, Instead of the statically mapped method
to get the corresponding timings for a given code and mode, move to a
simpler array indexed method. It will help to scale up to add more
timings when needed.
Signed-off-by: Mythri P K <mythripk@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add the vsync polarity, hsync polarity, interlace to hdmi_video_timings.
Remove the now duplicate structure hdmi_timings.
update the static table structure in HDMI with CEA/VESA code and mode.
Signed-off-by: Mythri P K <mythripk@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
video interface structure is a duplicate structure with parameters which are
already present in ip_data config structure, Thus removing the structure and
modifying corresponding code.
Signed-off-by: Mythri P K <mythripk@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Take fifo merge into use by implementing a rather naive fifo merge
threshold calculation: keep the low threshold always the same, but
increase the high threshold when fifo merge is used.
This should greatly increase the time between pixel data fetches from
SDRAM, as the usable fifo size is much larger. However, it probably
won't help for fifo underflows, as the low threshols is kept the same.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fifo thresholds are calculated using bytes, but the debug print prints
values in buffer units. Change the prints to use bytes to be in line
with the calculations, and also to print in the same units on all OMAPs.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add fifo-merge support. This is done mainly in four functions:
mgr_enable/disable and ovl_enable/disable. These are the functions where
overlays are taken into and out of active use.
The process to enable and disable fifo-merge is not simple. We need to
do it in steps, waiting in between for certain settings to be taken into
use, and continuing after that. The reason for this is that fifo-merge
is a common thing for all managers/overlays, and its use must be
synchronized.
As an example, when we disable an overlay, we first set the overlay as
disabled, then wait until the overlay is actually disabled in the HW,
and only after that we may re-configure the fifos, possibly taking
fifo-merge into use.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add mechanism to set/unset the DISPC fifo-merge:
Add new fields to dss_data, fifo_merge and fifo_merge_dirty. These are
similar to the other info/dirty flags in ovl_priv_data and ovl_mgr_data,
but fifo merge is a common attribute to all managers and thus outside
the ovl_mgr_data.
The fifo-merge field is used in the dss_write_regs_common, which handles
writing the register.
dss_apply_fifo_merge() can be used to set/unset the fifo merge field in
the dss_data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add feature flag for fifo merge. OMAP2 doesn't contain fifo merge, later
OMAPs do.
dispc_enable_fifomerge() checks for the flag when called, and gives a
WARN if fifo merge is being enabled when it is not supported.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* 'fbdev-next' of git://github.com/schandinat/linux-2.6: (175 commits)
module_param: make bool parameters really bool (drivers/video/i810)
Revert "atmel_lcdfb: Adjust HFP calculation so it matches the manual."
OMAPDSS: HDMI: Disable DDC internal pull up
OMAPDSS: HDMI: Move duplicate code from boardfile
OMAPDSS: add OrtusTech COM43H4M10XTC display support
OMAP: DSS2: Support for UMSH-8173MD TFT panel
ASoC: OMAP: HDMI: Move HDMI codec trigger function to generic HDMI driver
OMAPDSS: HDMI: Create function to enable HDMI audio
ASoC: OMAP: HDMI: Correct signature of ASoC functions
ASoC: OMAP: HDMI: Introduce driver data for audio codec
grvga: fix section mismatch warnings
video: s3c-fb: Don't keep device runtime active when open
video: s3c-fb: Hold runtime PM references when touching registers
video: s3c-fb: Take a runtime PM reference when unblanked
video: s3c-fb: Disable runtime PM in error paths from probe
video: s3c-fb: Use s3c_fb_enable() to enable the framebuffer
video: s3c-fb: Make runtime PM functional again
drivers/video: fsl-diu-fb: merge fsl_diu_alloc() into map_video_memory()
drivers/video: fsl-diu-fb: add default platform ops functions
drivers/video: fsl-diu-fb: remove broken reference count enabling the display
...
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The function hdmi_audio_trigger is a callback used by ASoC to stop/start
HDMI audio. Also, it does not perform IP-specific configuration directly.
Hence, it should be placed in the general portion of the HDMI driver,
along with the other ASoC callbacks.
Also, make this function static.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In order to separate clearly IP-specific code from general DSS code,
a function for OMAP4 audio enable is created. This function is
included in the HDMI IP ops to align with the current implementation
of the DSS HDMI driver. This function is to be used by the ASoC
HDMI audio codec.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
These functions require access to IP-secific data. However, it is not possible
to pass such data as a function argument as such functions have a specific
signature specified by ASoC. Instead, they will have access to the IP-specific
data by calling snd_soc_codec_get_drvdata. The codec driver data is set
at probe time.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Under the new DSS architecture for HDMI, there is a clear separation
between general DSS code and HDMI IP-specific data. Functions
that require access to the HDMI driver IP-specific data receive an
hdmi_ip_data structure. The ASoC codec require access to such
IP-specific data. Then, instead of accessing it directly, it will be
passed as codec driver data. This also helps to have a clear separation
between DSS and ASoC portions of the code.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Clock requirements for scaling in OMAP2, OMAP3 and OMAP4 are different. In
OMAP2 and OMAP3 the required clock rate is a function of pixel clock, vertical
downscale ratio and horizontal downscale ratio whereas in OMAP4 it is a
function of pixel clock and horizontal downscale ratio only. Selection of 3-tap
vs 5-tap coefficients depends on clock rate line buffer width in OMAP3 whereas
in OMAP4 it is independent of clock rate and line buffer width. In OMAP2 3-tap
for vertical and 5-tap for horizontal scaling is used. In OMAP4 5-tap is used
both for horizontal and vertical scaling for better performance. Also, the
number and width of line buffers differs in OMAP3 and OMAP4.
So, clock functions have been fined tuned for OMAP3 and support has been added
added for OMAP4. This code has been tested on OMAP2, OMAP3 and OMAP4, and
scaling issues due to clock errors have been resolved.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The FIR coefficients present in kernel are being updated to new coefficients
consisting of 24 coefficient tables, with 12 each for 3 tap and 5 tap scenario,
which are chosen on the basis of DISPC up/downsampling filters M value. M is
the inverse of low pass cut off frequency of the sampling filter. For vertical
scaling 3 tap or 5 tap tables are used based on the clock rate and width of
the line buffer whereas in OMAP2 3 tap is always used. For horizontal scaling
however 5 tap tables are always used.
New coefficients and the corresponding logic have been tested on OMAP2, OMAP3
and OMAP4. Horizontal and vertical scaling worked fine except for some 3 tap
vs 5 tap issue during vertical upscaling and clock failing issues which is
acknowledged in the next patch. Vertical upscaling was found to perform better
under 5 taps. The 24 coefficient tables have been moved to another file
dispc_coefs.c for proper maintainance.
This code is written based on code written by Lajos Molnar <lajos@ti.com> in
Android Kernel for scaling. Lajos Molnar <lajos@ti.com> had fine tuned the FIR
coefficient selection process and reduced outliness and blockiness around
images when upscaling more than 2 times.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
extra_info_update_ongoing() goes through all overlays, but doesn't check
if the overlay is connected to a manager. This leads to a crash whenever
an overlay has been detached.
Add a check to skip the non-connected overlays.
Reported-by: Rob Clark <rob@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The clock names of DSI_PLL_HSDIV_DISPC and DSI_PLL_HSDIV_DSI was made
dynamic based on the current value of DISPC and DSI FCLK sources. This
doesn't need to be done since we are just interested in the clock names,
and not the current clock sources for DISPC and DSI FCLKs.
Use only the generic and omap specific names for the DSI PLL's HSDIV
clocks.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The functions dss_ovl_simple_check() and dss_mgr_simple_check() are not
really part of the apply mechanism, and can be moved to overlay.c and
manager.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The dispc's error handler tries to disable all outputs when OCP_ERR
happens. However, the code doesn't check if there actually is a display
on each particular output, nor if there's a driver for the display. This
may lead to NULL pointer reference.
Signed-off-by: Rob Clark <rob@ti.com>
[tomi.valkeinen@ti.com: added patch description]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The functions dss_ovl_check, dss_mgr_check_zorder, dss_mgr_check in
apply.c are not really part of the apply mechanism, and can be moved to
overlay.c and manager.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Current code will always write fifo threshold values to the register,
even if they are the same as previously. Separate the setting of fifo
fields into a separate function, and only set new values if they are
different than the old ones.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Currently fifo threshold configuration is done per overlay or per
manager. However, when a fifo size configuration is added, we need to
always configure the thresholds for all overlays.
This patch prepares for that by changing the fifo threshold
configuration to always handle all overlays.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When we are enabling an overlay, there's a point in time when the
overlay is not actually enabled yet (nor do we want it to be enabled),
but we do want to check if the configuration for the overlay is valid,
and to calculate correct fifo thresholds for the soon-to-be-enabled
overlay.
Current code handled this in a hacky way, setting op->enabled to true
temporarily when calling functions that need to consider the state when
the overlay is enabled.
This patch makes this a bit cleaner, adding "enabling" field, which is
set when the overlay is not yet enabled but should be considered in the
checks and calculations.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Currently dss_write_regs() implicitely sets the GO bits for all managers
with shadow dirty flags set. This is a bit misleading, as one does not
presume "write registers" function to also set the GO bit.
Thus this patch splits the setting of GO bits into a separate function,
dss_set_go_bits, which is used after writing the registers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In the apply irq handler the code currently clears the shadow dirty
flags whenever the manager in question is not busy (i.e. GO bit is
down). However, this is not quite right, as the GO bit may have never
been set.
While not done in the current code, the above would cause bug in
scenario where the registers are written, and thus shadow_dirty flag is
set, but the GO bit will be set only later. In this case the
shadow_dirty flags would be cleared, even if the HW is not using the new
configurations.
This patch fixes the issue by clearing the shadow flags only when the GO
bit is clear, and the GO bit had been set.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
need_isr() should return true whenever there's work that needs to be
handled in the VSYNC/FRAMEDONE irq handler. However, need_isr() is
missing some cases where we need the irq handler.
This patch adds checks for shadow dirty flags, so that the irq handler
is started/kept running while shadow dirty flags are set.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
extra_info_update_ongoing() skipped checks for overlays that were marked
as disabled. This doesn't work, as the enable status of an overlay is in
the extra_info group, and thus extra_info_update_ongoing() reports false
when we are disabling an overlay. This causes
wait_pending_extra_info_updates() to not wait for the ongoing overlay
disable.
This patch changes extra_info_update_ongoing() to check the state of
overlays marked as disabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Now that dss_mgr_enable returns an error value, check it in all the
places dss_mgr_enable is used, and bail out properly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add checks for overlay and manager settings. The checks are a bit
complex, as we need to observe the bigger picture instead of overlays
and managers independently. Things like the used display and the zorder
of other overlays affect the validity of the settings.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add dss_mgr_simple_check() which is used to check the validity of
certain manager attributes. Only attributes that can be checked
independently, without knowing the display being used, is done here
(thus "simple").
We can use this function in dss_mgr_set_info().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add dss_ovl_simple_check() which is used to check the validity of
certain overlay attributes. Only attributes that can be checked
independently, without knowing the display being used, is done here
(thus "simple").
We can use this function in dss_ovl_set_info().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
apply.c no longer touches any registers if an output is not enabled.
This means that we don't need to do dispc_runtime_get() anymore, and the
calls can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add wait_pending_extra_info_updates() function which can be used to wait
until any extra_info changes have been taken into use by the hardware.
This can be only called when holding the apply mutex, so that other
threads cannot insert new extra_info changes.
This will be used to handle fifo-configurations.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add checks to dss_mgr_enable, dss_mgr_disable, dss_ovl_enable,
dss_ovl_disable that check if the state is already the same as given in
the parameters, and exit if so.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add a helper function dss_apply_ovl_enable(), which is similar to the
main apply() function: dss_apply_ovl_enable() applies the given overlay
enable-status to ovl_priv_data, and sets the dirty flag.
The difference between the helper function and the previous direct use
of the fields is that the helper function will not do anything if the
enable state is already the same as given in the parameter.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omap_overlay_manager contains device_changed field, which no longer has
any use. So remove the field and the few places where it is touched.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Rename ovl_priv_data's and mgr_priv_data's dirty and shadow_dirty fields
to info_dirty and shadow_info_dirty to better reflect what they mean.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Setting overlay's fifo thresholds is currently handled at the same time
as other overlay attributes. This is not right, as the normal attributes
should only affect one overlay and manager, but changing the fifo
thresholds are needed in cases like fifo-merge, where multiple managers
are affected.
This patch moves the channel field into the "extra_info" set, handled
together with channel and enabled-status.
This also lets us to calculate the fifos only when needed, specifically,
when an overlay or a manager is enabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Setting overlay's output channel is currently handled at the same time
as other overlay attributes. This is not right, as the normal attributes
should only affect one overlay and manager, but changing the channel
affects two managers.
This patch moves the channel field into the "extra_info" set, handled
together with enabled-status.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
struct omap_overlayr contains info and info_dirty fields, both of which
should be internal to apply.c.
This patch moves those fields into ovl_priv data, and names them
user_info and user_info_dirty.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
struct omap_overlay_manager contains info and info_dirty fields, both of
which should be internal to apply.c.
This patch moves those fields into mgr_priv data, and names them
user_info and user_info_dirty.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add a helper function mgr_clear_shadow_dirty(), which clears the
shadow_dirty flags for the given manager and for the overlays on that
manager.
This lets us simplify the code in the dss_apply_irq_handler().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add "updating" flag to mgr_priv_data, which is used to track whether the
manager is currently actively working, i.e. updating the screen.
For auto-update displays updating is always true when the display is
enabled, but for manual update displays the flag is true only during
frame transfers.
The flag is used to manage registers properly, for example when updating
is false and a register for a manager is written, there's no need to set
shadow_dirty flag nor set the GO bit, as the settings will be taken into
use by the HW automatically when the output is enabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add dispc_mgr_get_framedone_irq() which returns the irq number for
FRAMEDONE for the given channel.
Note that the function returns always 0 for DIGIT channel, even if OMAP4
does have FRAMEDONE_TV interrupt. The reason for this is that this
function is currently used only to track manual updates, and thus
FRAMEDONE_TV is not needed.
If there's need in the future to also get the FRAMEDONE_TV this needs
revisiting. However, as FRAMEDONE_TV doesn't exist on OMAP2/3, the use
of this function for that purpose needs some extra code to handle the
OMAP2/3 case.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The functions writing to the DISPC registers in apply.c are more complex
than needed. This patch cleans things up.
Two helper functions are added: need_isr(), which returns if an isr for
VSYNC is needed, and need_go(), which tells if there has been a write to
the shadow registers and we need to set the GO bit.
The functions that call the actual dispc write functions will set the
dirty and shadow_dirty flags themselves, instead of that being done on
the caller side. The writing functions also check if the dirty flag is
even set, and return immediately if not.
This allows us to clean up dss_write_regs().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Overlays are currently enabled and disabled with a boolean in the struct
omap_overlay_info. The overlay info is set with ovl->set_overlay_info(),
and made into use with mgr->apply().
This doesn't work properly, as the enable/disable status may affect also
other overlays, for example when using fifo-merge. Thus the enabling and
disabling of the overlay needs to be done outside the normal overlay
configuration.
This patch achieves that by doing the following things:
1) Add function pointers to struct omap_overlay: enable(), disable() and
is_enabled(). These are used to do the obvious. The functions may block.
2) Move the "enabled" field from struct omap_overlay to ovl_priv_data.
3) Add a new route for settings to be applied to the HW, called
"extra_info". The status of the normal info and extra_info are tracked
separately.
The point here is to allow the normal info to be changed and
applied in non-blocking matter, whereas the extra_info can only be
changed when holding the mutex. This makes it possible to, for example,
set the overlay enable flag, apply it, and wait until the HW has taken
the flag into use.
This is not possible if the enable flag would be in the normal info, as
a new value for the flag could be set at any time from the users of
omapdss.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add a new field to mgr_priv data, "busy", which is used to track the
status of GO bit with the manager. As manual update displays never use
the GO bit, the field is always false for managers used for manual
update displays.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
struct omap_overlay_manager contains "enabled"-field, used to track if
the manager is enabled or not. This field should be internal to apply.c.
This patch moves the field to mgr_priv_data, and applies the necessary
locking when accessing the field.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The current code uses dsi_video_mode_enable/disable functions to
enable/disable DISPC output for video mode displays. For command mode
displays we have no notion in the DISPC side of whether the panel is
enabled, except when a dss_mgr_start_update() call is made.
However, to properly maintain the DISPC state in apply.c, we need to
know if a manager used for a manual update display is currently in use.
This patch achieves that by changing dsi_video_mode_enable/disable to
dsi_enable/disable_video_output, which is called by both video and
command mode displays. For video mode displays it starts the actual
pixel stream, as it did before. For command mode displays it doesn't do
anything else than mark that the manager is currently in use.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The functions in apply.c, called mostly via function pointers in overlay
and overlay_manager structs, will be divided into two groups. The other
group will not sleep and can be called from interrupts, and the other
group may sleep.
The idea is that the non-sleeping functions may only change certain
settings in overlays and managers, and those settings may only affect
the particular overlay/manager. For example, set the base address of the
overlay.
The blocking functions, however, will handle more complex configuration
changes. For example, when an overlay is enabled and fifo-merge feature
is used, we need to do the enable in multiple steps, waiting in between,
and the change affects multiple overlays and managers.
apply.c already contains a spinlock, which has been used to protect
(badly) the dss_data. This patch adds locks/unlocks of the spinlock to
the missing places, and the lock should now properly protect dss_data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The functions in apply.c, called mostly via function pointers in overlay
and overlay_manager structs, will be divided into two groups. The first
group will not sleep and can be called from interrupts, and the second
group may sleep.
The idea is that the non-sleeping functions may only change certain
settings in overlays and managers, and those settings may only affect
the particular overlay/manager. For example, set the base address of the
overlay.
The blocking functions, however, will handle more complex configuration
changes. For example, when an overlay is enabled and fifo-merge feature
is used, we need to do the enable in multiple steps, waiting in between,
and the change affects multiple overlays and managers.
This patch adds the mutex which is used in the blocking functions to
have exclusive access to overlays and overlay managers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
DSS currently tries to check that the given overlay and overlay manager
settings are acceptable, but the code does not work quite properly.
Things may change between the check and the actual use of the settings.
Furthermore, the following patches will rewrite how settings are
configured and managed, and trying to keep the (broken) settings
checking working during the rewrite would be very difficult.
This patch removes the checking code, and a working version of checking
will be added back after the settings rewrite has been done.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
apply.c will handle the management of dispc in the future patches. This
patch moves overlay manager related functions to apply.c so that they
will have access to the private data and functions of apply.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
apply.c will handle the management of dispc in the future patches. This
patch moves overlay related functions to apply.c so that they will have
access to the private data and functions of apply.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss_cache struct contains private data used to manage dispc. "cache" is
not a good word for it, so rename it to dss_data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss_cache struct contains a spinlock used to protect the struct. A more
logical place for the spinlock is outside the struct that it is
protecting. So move it there.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
manager_cache_data is not a suitable name for the struct. It is more of
a private data for the manager.
Rename the struct to mgr_priv_data, and add a function,
get_mgr_priv(mgr), to get a pointer to the data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
overlay_cache_data is not a suitable name for the struct. It is more of
a private data for the overlay.
Rename the struct to ovl_priv_data, and add a function,
get_ovl_priv(ovl), to get a pointer to the data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Make configure_overlay() and configure_manager() take overlay/manager
pointer as an argument, instead of the ovl/mgr id. This will be useful
with the future patches.
Also rename the functions to be a bit more informative:
dss_ovl_write_regs, dss_mgr_write_regs, dss_write_regs.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use dispc_mgr_get_vsync_irq() to get the interrupt numbers for vsync,
instead of hardcoding the values depending on the display type.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Current way of handling overlay-manager links is a bit strange: each
manager has a static array, containing pointers to all the overlays
(even those used by other managers). The overlays contain a pointer to
the manager being used.
This patch makes the system a bit saner: each manager has a linked list
of overlays, and only the overlays linked to that manager are in the
list.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Overlay managers are stored in a linked list. There's no need for this
list, as an array would do just as fine.
This patch changes the code to use an array for overlay managers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Overlays are stored in a linked list. There's no need for this list, as
an array would do just as fine.
This patch changes the code to use an array for overlays.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss_mgr_start_update() has a loop, of which sole purpose is to find the
manager used for this update. The whole loop is extra, as we already
know the manager.
Remove the loop.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
There's no need to register the vsync ISR and configure the hardware if
the overlay manager is disabled, so this patch adds a check for disabled
managers to the omap_dss_mgr_apply() function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The mechanism to cache manager and overlay settings and configure them
into the HW registers in VSYNC is meant only for auto-update displays,
as it doesn't make sense (and doesn't work) for manual-update displays.
This patchs adds a check so that we skip the above for manual update
displays.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add "enabled" field to struct omap_overlay_manager, which tells if the
output is enabled or not. This will be used in apply.c in the following
patches.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omap_overlay_manager struct contains enable() and disable() functions.
However, these are only meant to be used from inside omapdss, and thus
it's bad to expose the functions.
This patch adds dss_mgr_enable() and dss_mgr_disable() functions to
apply.c, which handle enabling and disabling the output.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Create a new file, apply.c, and move code about handling the
apply-mechanism and configuration of the managers and overlays from
manager.c to apply.c.
Not all related code is moved in this patch, but only the core
apply/configure functions. The later patches move rest of the code from
overlay.c and manager.c, adding necessary locking at the same time.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omap_dss_mgr_apply currently applies settings to all overlays and
overlay managers. The reason for this was to support cases where
configuration changes affecting multiple managers are made. However, the
current code doesn't support changing such configurations, so the
functionality is not needed.
Change the apply to affect only the manager given as an argument, and
the overlays attached to that manager.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add helper functions ovl_manual_update() and mgr_manual_update() which
return whether the overlay or manager is used with a manual update
display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
There's an unnecessary wrapper function, dss_ovl_wait_for_go(), which
does nothing else than call dss_mgr_wait_for_go_ovl(). The
dss_ovl_wait_for_go() function can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Change manager configuration to be similar to overlay configuration by
creating dispc_mgr_setup() which takes omap_overlay_manager_info as
parameter.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Overlay channel is configured with ovl_setup, with all the other overlay
attriutes. This patch separates overlay channel setup so that we can
later configure the channel only when needed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Overlay FIFO thresholds are configured with ovl_setup, with all the
other overlay attributes. This patch separates FIFO threshold setup so
that we can later configure FIFO thresholds only when needed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Move the configuration of interlace and replication from
omap_dss_mgr_apply() to configure_overlay(). This removes the need to
store the values into the cache data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Overlay out_width/height are set to 0 when scaling is not used by the
users of omapdss. Currently ovl_setup() expects the caller of
ovl_setup() to convert those zero values to width or height.
This patch makes ovl_setup() accept zero values for out_width/height,
making calling ovl_setup() a bit simpler as the overlay_info can be
just passed to this function without modifications.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dss_start_update() takes currently the dss device as a parameter. Change
the parameter to ovl manager, as that is what the dss_start_update()
actually needs. Change the name of the function to
dss_mgr_start_update() to reflect the change.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
