Commit Graph

1051 Commits

Author SHA1 Message Date
Archit Taneja 8bbe09ee4d OMAPDSS: DISPC: Configure writeback FIFOs
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.

The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:51 +03:00
Archit Taneja 9e4a0fc765 OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup()
Configure some of the writeback specific parameters in dispc_wb_setup(). The
writeback parameters configured are:

truncation: This needs to be set if the color depth input to writeback is more
than the color depth of the color mode we want to store in memory.

writeback mode: This configures whether we want to use writeback in mem to mem
or capture mode. This information will be directly passed by APPLY later.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:51 +03:00
Archit Taneja 749feffa6b OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
Create struct omap_dss_writeback_info, this is similar to omap_overlay_info,
the major difference is that there is no parameter which describes the input
size to writeback, this is because this is always fixed, and decided by the
connected overlay or overlay manager. One more difference is that screen_width
is renamed to buf_width, to give the value of stride the writeback buffer has.

Call dispc_ovl_setup_common() through dispc_wb_setup() to configure overlay-like
parameters. The parameters in dispc_ovl_setup_common() which do not hold for
writeback are filled passed as zeroes or false, the code takes care of not
configuring them as they won't possess the needed overlay caps.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:50 +03:00
Archit Taneja d9ac773cd0 OMAPDSS: DISPC: Add function to set channel in for writeback
Writeback can take input from either one of the overlays, or one of the overlay
managers. Add an enum which represents the channel_in for writeback, and maps
to the register field programming.

Add a function to configure channel in for writeback. This will be used later in
APPLY.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:50 +03:00
Archit Taneja 2a5561b1f7 OMAPDSS: DISPC: Don't set chroma resampling bit for writeback
The bit YUVCHROMARESAMPLING isn't there for writeback in DISPC_WB_ATTRIBUTES2.
It isn't there because we don't upsample chroma like for video pipelines, we
downsample chroma in writeback to get YUV422 or NV12 formats from the YUV444
input.

Ignore this bit in dispc_ovl_set_scaling_uv() if the plane is OMAP_DSS_WB.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:50 +03:00
Archit Taneja f92afae2af OMAPDSS: DISPC: Downscale chroma if plane is writeback
When converting YUYV444 content to YUV422 or NV12 formats through writeback
pipeline, the scaler needs to downscale the chroma plane. Ensure that chroma
is downscaled when the pipeline is writeback.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:50 +03:00
Archit Taneja 36d87d9558 OMAPDSS: DISPC: Configure input and output sizes for writeback
Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scaler. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scaler. This naming is different
as compared to overlays.

Add checks for writeback in dispc_ovl_set_input_size() and
dispc_ovl_set_output_size() to write to the correct registers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:50 +03:00
Archit Taneja 7a155be39e OMAPDSS: DISPC: Add writeback register offsets and dss features structs
Since writeback has many overlay like properties, and most of it's registers are
similar to that of overlays, it's possible to reuse most of the overlay related
DISPC code for writeback when considering it as a plane. Writeback was added as
a plane in the omap_plane field as OMAP_DSS_WB.

Add the writeback register offsets in dispc.h, add minimal WB plane related info
needed in dss_features. Add a function which returns the number of writeback
pipelines an OMAP version has.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:50 +03:00
Archit Taneja 20fbb50be4 OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma
In the function dispc_plane_set_scaling_uv(), create a parameter which tells if
we want to upscale or downscale the chroma plane.

Downscaling of chroma is required by writeback pipeline for converting the input
YUV444 color format to YUV422 or NV12.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:49 +03:00
Archit Taneja 8ba85306ba OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory mode
The scalers of overlays and writeback do not have any constraints on downscale
ratio when operating in memory to memory mode.

This is because in memory to memory mode, we aren't connected to a display which
needs data output at the rate of pixel clock. The scalers can perform as much
downscaling as needed, the rate at which the scaler outputs is adjusted
accordingly.

Relax constraints related to downscaling based on whether the input overlays are
connected to writeback in memory to memory mode. We pass a mem_to_mem boolean
parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this
will later be configured to the correct value based on whether the overlay is
connected to writeback or not. Do the same later for writeback when writeback is
configured.

In the scaling calculation code, we calculate the minimum amount of core clock we
need to achieve the required downscaling. If we are in memory to memory mode, we
set this to a very small value(1 in this case), this value would always be
lesser than the actual DISPC core clock value, and hence the scaling checks
would succeed.

We take care that pixel clock isn't calculated for writeback and the overlays
connected to it when in memory to memory mode. A pixel clock in such cases
doesn't make sense.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:49 +03:00
Archit Taneja 3e8a6ff248 OMAPDSS: DISPC: Don't pass channel out when configuring overlays
dispc_ovl_setup_common() is to be used by both overlays and writeback. We pass
channel out to figure out what manager the overlay is connected to, to determine
the pixel clock rate. This is used to decide the scaling limitations for that
overlay.

writeback doesn't have a channel out, it has a channel in field which tells
where writeback gets its input from. These are 2 different fields, and this
prevents us reusing the overlay configuration code for writeback.

To overcome this, we now pass omap_plane to overlay related functions rather
than passing channel out. We create helper functions which can derive pclk/lclk
from the omap_plane id.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:49 +03:00
Archit Taneja 84a880fd51 OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_common
Add a new static function called dispc_ovl_setup_common(). This function is used by
dispc_ovl_setup() to configure the overlay registers. This split is done so that
dispc_wb_setup() can reuse overlay register configuration related code.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:49 +03:00
Archit Taneja d79db85300 OMAPDSS: OVERLAY: Add position and replication as overlay caps
Add position and replication as overlay caps, and pass overlay caps as an
argument to the corresponding functions. Adding position and replication to
overlay caps seems a bit unnecessary, but it allows us to use the
corresponding functions for writeback too.

These caps will be set for all overlays, but not for writeback. This is done
so writeback can reuse dispc_ovl_setup() to the maximum.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:49 +03:00
Archit Taneja 5b54ed3ec3 OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane functions
Currently, the functions below take the omap_plane parameter and derive the
overlay caps within them. Pass the overlay caps as a parameter to the function
to allow these to be used by writeback too.

- dispc_ovl_set_zorder()
- dispc_ovl_set_pre_mult_alpha()
- dispc_ovl_setup_global_alpha()
- dispc_ovl_calc_scaling()
- dispc_ovl_setup()

These functions will be used for writeback later, and the caps will help in
deciding if they are to be used for writeback or not. This allows reuse of
overlay caps for writeback.

Using omap_overlay_caps for writeback seems a bit incorrect, but caps is
something already in use by users of OMAPDSS(omapfb/omap_vout), so we use
overlay caps for overlay like features of writeback too.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:49 +03:00
Archit Taneja 78b687fc4f OMAPDSS: DISPC: Simplify function names for setting pipeline input and output sizes
The DISPC pipeline register names in the TRM for setting the buffer size and
the output size are a bit misleading, for example, there are different register
names for setting the buffer size for VID and GFX pipes. Things get more
confusing when considering writeback pipeline.

Rename the functions so that they tell whether they are configuring the input
to the scalar or the output. These will be extended later to support writeback
registers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:49 +03:00
Archit Taneja 8eeb7019a4 OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()
The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure
DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field
was being changed in dispc_ovl_setup in the case of interlaced displays. Fix
this and const qualifier to the omap_overlay_info argument.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:48 +03:00
Archit Taneja 3c2995ac34 OMAPDSS: Remove old way of setting manager and device links
Now that an omap_dss_output can be used to link between managers and devices, we
can remove the old way of setting manager and device links. This involves
removing the device and manager pointers from omap_overlay_manager and
omap_dss_device respectively, and removing the set_device/unset_device ops from
omap_overlay_manager.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:38 +03:00
Archit Taneja 0f0e4e3cd8 OMAPDSS: APPLY: Remove omap_dss_device references from dss_ovl_enable/disable
An overlay isn't allowed to be enabled/disabled if it isn't connected to an
omap_dss_device. This requirement isn't needed any more. An overlay can be
enabled/disabled as long as it has an output connected to it. The output may
not be connected to a device, but we can be assured that the connected
manager's output is in use by an output interface.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:38 +03:00
Archit Taneja 80d81d64d6 OMAPDSS: OVERLAY/MANAGER: Get device via output
A manager is not connected to a device directly any more. It first connects
to an output, and then to the display. Update overlay and manager get_device ops
to return the device via the connected output.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:37 +03:00
Archit Taneja 947b225424 OMAPDSS: MANAGER: Update display sysfs store
The display sysfs attribute's store function needs to be changed with the
introduction of outputs.

The DSS driver ensures that there is one display per output, and that a
registered omap_dss_device will have an output connected to it. The display
sysfs store function unsets the current output connected to the manager, and
sets it with the output connected to the new display. If the new display doesn't
have an output for some reason, we just bail out. The function doesn't set/unset
output->device links. These remain the same as when the omap_dss_device was
registered.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:37 +03:00
Archit Taneja 952cbaaa9b OMAPFB: Change dssdev->manager references
To retrieve the manager pointer via a device, we need to now access it via the
output to which the device is connected. Make this change in omapfb_ioctl()
where the WAITFORVSYNC ioctl tries to access the manager's device.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:37 +03:00
Archit Taneja cea87b92da OMAPDSS: HDMI: Replace dssdev->manager with dssdev->output->manager references
With addition of output entities, a device connects to an output, and an output
connects to overlay manager. Replace the dssdev->manager references with
dssdev->output->manager to access the manager correctly.

When enabling the HDMI output, check whether the output entity connected to
display is not NULL.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:36 +03:00
Archit Taneja 8f1f736c45 OMAPDSS: VENC: Replace dssdev->manager with dssdev->output->manager references
With addition of output entities, a device connects to an output, and an output
connects to overlay manager. Replace the dssdev->manager references with
dssdev->output->manager to access the manager correctly.

When enabling the VENC output, check whether the output entity connected to
display is not NULL.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:36 +03:00
Archit Taneja 1db39c0a28 OMAPDSS: RFBI: Replace dssdev->manager with dssdev->output->manager references
With addition of output entities, a device connects to an output, and an output
connects to overlay manager. Replace the dssdev->manager references with
dssdev->output->manager to access the manager correctly.

When enabling the RFBI output, check whether the output entity connected to
display is not NULL.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:35 +03:00
Archit Taneja 7d6069e571 OMAPDSS: SDI: Replace dssdev->manager with dssdev->output->manager references
With addition of output entities, a device connects to an output, and an output
connects to overlay manager. Replace the dssdev->manager references with
dssdev->output->manager to access the manager correctly.

When enabling the SDI output, check whether the output entity connected to
display is not NULL.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:35 +03:00
Archit Taneja eea8340a1d OMAPDSS: DSI: Replace dssdev->manager with dssdev->output->manager references
With addition of output entities, a device connects to an output, and an output
connects to overlay manager. Replace the dssdev->manager references with
dssdev->output->manager to access the manager correctly.

When enabling the DSI output, check whether the output entity connected to
display is not NULL.

In dsi_init_display(), the display won't be connected to the DSI output yet,
that happens later in dss_recheck_connections() in the panel driver's probe. Get
the dsidev platform device pointer using the DSI moudle number provided in the
omap_dss_device struct.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:34 +03:00
Archit Taneja 400e65d1c9 OMAPDSS: DSI: Remove dsi_pdev_map global struct
dsi_pdev_map is a struct visible globally in the DSI driver to get the platform
device pointer of the DSI device corresponding to it's module ID. This was
required because there was no clean way to derive the platform device from
the DSI module instance number or from the connected panel.

With the new output entity, it is possible to retrieve the platform device
pointer if the omap_dss_output pointer is available. Modify the functions
dsi_get_dsidev_from_dssdev() dsi_get_dsidev_from_id() so that they use output
instead of dsi_pdev_map to retrieve the dsi platform device pointer.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:34 +03:00
Archit Taneja 5d512fcdf6 OMAPDSS: DPI: Replace dssdev->manager with dssdev->output->manager references
With addition of output entities, a device connects to an output, and an output
connects to overlay manager. Replace the dssdev->manager references with
dssdev->output->manager to access the manager correctly.

When enabling the DPI output, check whether the output entity connected to
display is not NULL.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:33 +03:00
Archit Taneja 3224827630 OMAPDSS: Create links between managers, outputs and devices
Links between DSS entities are made in dss_init_connections() when a panel
device is registered, and are removed in dss_uninit_connections() when the
device is unregistered. Modify these functions to incorporate the addition of
outputs.

The fields in omap_dss_device struct gives information on which output and
manager to connect to. The desired manager and output pointers are retrieved and
prepared to form the desired links. The output is linked to the device, and then
the manager to the output.

A helper function omapdss_get_output_from_device() is created to retrieve the
output from the display by checking it's type, and the module id in case of DSI.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:33 +03:00
Archit Taneja 4249e61e04 OMAPFB: remove manager->device references
With the introduction of output entities, managers will now connect to outputs.
Use the helper op for overlays named get_device. This will abstract away the
information on how to get the device from an overlay.

Using the helper function will reduce the number of pointer dereferences a user
of OMAPDSS needs to do and reduce risk of a NULL dereference.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:32 +03:00
Archit Taneja 794bc4eefa OMAPDSS: Remove manager->device references
With the introduction of output entities, managers will now connect to outputs.
Create helper ops for overlays and managers named get_device. This will abstract
away the information on how to get the device from an overlay or an overlay
manager. The get_device ops currently retrieve the output via a
ovl->manager->device reference. This will be later replaced by
ovl->manager->output->device references.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:31 +03:00
Archit Taneja 97f01b3a2e OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager
Add set_output/unset_output ops for overlay managers, these form links between
managers and outputs. Create a function in dss features which tell all the
output instances that connect to a manager, use it when a manager tries to set
an output. Add a constraint of not unsetting an output when the manager is
enabled.

Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for
now to not break things. Keep the dss feature function get_supported_displays
as it's used in some places. These will be removed later.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 14:58:31 +03:00
Archit Taneja 6d71b923e5 OMAPDSS: output: Add set/unset device ops for omap_dss_output
An output entity represented by the struct omap_dss_output connects to a
omap_dss_device entity. Add functions to set or unset an output's device. This
is similar to how managers and devices were connected previously. An output can
connect to a device without being connected to a manager. However, the output
needs to eventually connect to a manager so that the connected panel can be
enabled.

Keep the omap_overlay_manager pointer in omap_dss_device for now to prevent
breaking things. This will be removed later when outputs are supported
completely.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 16:31:46 +05:30
Archit Taneja 81b87f515f OMAPDSS: outputs: Create and register output instances
Add output structs to output driver's private data. Register output instances by
having an init function in the probes of the platform device drivers for
different outputs. The *_init_output for each output registers the output and
fill up the output's plaform device, type and id fields. The *_uninit_output
functions unregister the output.

In the probe of each interface driver, the output entities are initialized
before the *_probe_pdata() functions intentionally. This is done to ensure that
the output entity is prepared before the panels connected to the output are
registered. We need the output entities to be ready because OMAPDSS will try
to make connections between overlays, managers, outputs and devices during the
panel's probe.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 16:30:49 +05:30
Archit Taneja 484dc404d2 OMAPDSS: outputs: Create a new entity called outputs
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.

The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.

Adding outputs as a new software entity gives us the following benefits:

- Have exact information on the possible connections between managers and
  outputs: A manager can't connect to each and every output, there only limited
  hardware links between a manager's video port and some of the outputs.

- Remove hacks related to connecting managers and devices: Currently, default
  links between managers and devices are set in a not so clean way. Matching is
  done via comparing the device type, and the display types supported by the
  manager. This isn't sufficient to establish all the possible links between
  managers, outputs and devices in hardware.

- Make panel drivers more generic: The DSS panel drivers currently call
  interface/output specific functions to configure the hardware IP. When making
  these calls, the driver isn't actually aware of the underlying output. The
  output driver extracts information from the panel's omap_dss_device pointer
  to figure out which interface it is connected to, and then configures the
  corresponding output block. An example of this is when a DSI panel calls
  dsi functions, the dsi driver figures out whether the panel is connected
  to DSI1 or DSI2. This isn't correct, and having output as entities will
  give the panel driver the exact information on which output to configure.
  Having outputs also gives the opportunity to make panel drivers generic
  across different platforms/SoCs, this is achieved as omap specific output
  calls can be replaced by ops of a particular output type.

- Have more complex connections between managers, outputs and devices: OMAPDSS
  currently doesn't support use cases like 2 outputs connect to a single
  device. This can be achieved by extending properties of outputs to connect to
  more managers or devices.

- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
  as compared to overlays, managers or devices.

Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 16:29:10 +05:30
Archit Taneja fc22a84339 OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions
The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if there
is an enabled display connected to the manager before trying to see the state of
the GO bit.

The checks related to the display can be replaced by checking the state of the
manager, i.e, whether the manager is enabled or not. This makes more sense than
checking with the connected display as the GO bit behaviour is more connected
with the manager state rather than the display state. A GO bit can only be set
if the manager is enabled. If a manager isn't enabled, we can safely assume that
the GO bit is not set.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 16:29:09 +05:30
Archit Taneja 9e7e937222 OMAPDSS: DSI: Pass dsi platform device wherever possible
Many of the DSI functions receive the connected panel's omap_dss_device pointer
as an argument. The platform device pointer is then derived via omap_dss_device
pointers.

Most of these functions don't really require omap_dss_device pointer anymore
since we now keep copies of parameters in the driver data which were previously
available only via omap_dss_device. Replace the arguments with platform device
pointers for such functions.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-26 16:29:07 +05:30
Tomi Valkeinen e84dc1cc15 OMAPDSS: DSI: fix tlpx_half reg field length
tlpx_half bit field in DSI_DSIPHY_CFG1 is [20,16], not [22,16] as
accessed in the code currently. Fix this.

The bug should not have caused any problems on OMAP3/4, as the bits
21,22 are unused. They are used on OMAP5, though.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-26 12:57:51 +03:00
Chandrabhanu Mahapatra d557a9cf2f OMAPDSS: DISPC: Add predecimation limit for TILER based rotations
In OMAP4 and OMAP5 when TILER 2D burst mode is used, a maximum of one line can
be skipped as per the respective TRMs. The MBlockStride OCP signal, which is
sum of ROWINC and image width in memory, is only 17 bits wide. In 2D mode TILER
supports 8192, 16384, 32768 and 65536 values of MBlockStride. In case when 2 or
more lines are skipped the ROWINC value exceeds 65536 resulting in OCP errors.
So, maximum vertical predecimation achievable is 2.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-25 16:41:11 +03:00
Tomi Valkeinen 406f7b8baa Merge OMAP5 DSS changes to omapdss
This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI
and DSI.

* omap5-dss:
  OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5
  OMAPDSS: DSI: Add code to disable PHY DCC
  OMAPDSS: DSI: Add new linebuffer size for OMAP5
  OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL
  OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO
  OMAPDSS: Add support for DPI source selection
  OMAPDSS: move dss feats to the end of dss.c
  OMAPDSS: Add basic omap5 features to dss and dispc
  OMAPDSS: DSI: improve DSI clock calcs for DISPC
2012-09-25 11:26:28 +03:00
Tomi Valkeinen c0ca7c38c5 Merge omapdss single-dssdev series
This series contains patches that change how omapdss's panel devices
(omap_dss_device) are initialized and registered. There are two patches that
change behaviour, the rest are just cleanups:

The patch "omap_dss_register_device() doesn't take display index" affects the
number for the "displayX" sysfs files. This hopefully doesn't affect the
userspace, as the number has never been a clear indication of what the
particular display is.

The patch "register only one display device per output" affects how panel
devices are created. Currently we support multiple panels per output, i.e. you
could have DVI and an LCD displays using the same DPI output, as long as the
DVI and LCD are not used at the same time.

This patch changes the omapdss driver to only register one display device per
output. If there are multiple displays for the output, either the first one is
picked or, if def_display has been defined in kernel parameters and the
def_display is one of the displays for this output, the def_display is picked.
See the patch for more information.

  OMAPDSS: alloc dssdevs dynamically
  OMAPDSS: cleanup dss_recheck_connections further
  OMAPDSS: cleanup dss_recheck_connections
  OMAPDSS: handle errors in dss_init_device
  OMAPDSS: explicitely initialize dssdev->channel for new displays
  OMAPDSS: register only one display device per output
  OMAPDSS: Add dss_get_default_display_name()
  OMAPDSS: omap_dss_register_device() doesn't take display index
2012-09-25 11:23:14 +03:00
Raphaël Assénat 524d9f48a6 OMAPDSS: Do not require a VDDS_DSI regulator on AM35xx
On our AM3505 based board, dpi.c complains that there is no VDDS_DSI
regulator and the framebuffer cannot be enabled. However, this check
does not seem to apply to AM3505/17 chips.

This patch adds new features list for AM35xxx, which is the same as for
OMAP3 except the VDDS_DSI is removed.

Signed-off-by: Raphael Assenat <raph@8d.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-25 11:20:37 +03:00
Tomi Valkeinen 995885897f OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5
Change omapdss Kconfig file to make OMAP2_DSS_DSI depend on ARCH_OMAP5.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 16:50:10 +03:00
Tomi Valkeinen 77ccbfbb07 OMAPDSS: DSI: Add code to disable PHY DCC
OMAP5 DSI PHY has DCC (Duty Cycle Corrector) block, and by default DCC
is enabled and thus the PLL clock is divided by 2 to get the DSI DDR
clk. This divider has been 4 for all previous OMAPs, and changing it
needs some reorganization of the code. The DCC can be disabled, and in
that case the divider is back to the old 4.

This patch adds dss feature for the DCC, and adds code to always disable
the DCC.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 16:50:10 +03:00
Tomi Valkeinen 2ac80fbea1 OMAPDSS: DSI: Add new linebuffer size for OMAP5
OMAP5's DSI has a larger line buffer than earlier OMAPs. This patch adds
support for this to the DSI driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 16:50:10 +03:00
Tomi Valkeinen 6d44610f83 OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL
Add FEAT_DSI_PLL_REFSEL. OMAP5's DSI PLL needs configuration to select
the reference clock to be used. We always use SYSCLK.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 16:50:09 +03:00
Tomi Valkeinen f8ef3d6966 OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO
Add FEAT_DSI_PLL_SELFREQDCO. OMAP5's DSI PLL has a new configuration
option that needs to be programmed depending on the PLL's output clock
frequency.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 16:50:09 +03:00
Tomi Valkeinen de09e45555 OMAPDSS: Add support for DPI source selection
We can select the video source for DPI output as follows:

OMAP2/3: always LCD1
OMAP4: LCD2 or DIGIT
OMAP5: LCD1/LCD2/LCD3/DIGIT

This patch adds support to select the source, and makes dpi.c call the
function to set the source.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Anders <x0132446@ti.com>
2012-09-24 16:50:08 +03:00
Tomi Valkeinen 84273a9593 OMAPDSS: move dss feats to the end of dss.c
Move dss_features to the end of dss.c the same way they are in dispc.c,
so that we don't have to declare prototypes for static feat-related
functions.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 16:50:08 +03:00
Archit Taneja 2336283280 OMAPDSS: Add basic omap5 features to dss and dispc
Add basic omap5 features for dss and dispc.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 16:50:07 +03:00
Tomi Valkeinen d66b15818c OMAPDSS: DSI: improve DSI clock calcs for DISPC
Commit ee144e645a added
dsi_pll_calc_ddrfreq() which calculates PLL dividers based on given DSI
bus clock speed. The function works ok, but it can be improved for the
DISPC clock calc.

The current version calculates the clock going from the PLL to the DISPC
simply by setting the clock as close to DISPC maximum as possible, and
the pixel clock is calculated based on that.

This patch changes the function to calculate DISPC clock more
dynamically, iterating through different DISPC clocks and pixel clock
values, and thus we'll get more suitable pixel clocks.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-24 16:50:07 +03:00
Tomi Valkeinen 5274484b82 OMAPDSS: alloc dssdevs dynamically
We currently create omap_dss_devices statically in board files, and use
those devices directly in the omapdss driver. This model prevents us
from having the platform data (which the dssdevs in board files
practically are) as read-only, and it's also different than what we will
use with device tree.

This patch changes the model to be in line with DT model: we allocate
the dssdevs dynamically, and initialize them according to the data in
the board file's dssdev (basically we memcopy the dssdev fields).

The allocation and registration is done in the following steps in the
output drivers:

- Use dss_alloc_and_init_device to allocate and initialize the device.
  The function uses kalloc and device_initialize to accomplish this.
- Call dss_copy_device_pdata to copy the data from the board file's
  dssdev
- Use dss_add_device to register the device.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-18 16:15:05 +03:00
Tomi Valkeinen 5eeb55f870 OMAPDSS: cleanup dss_recheck_connections further
Cleanup dss_recheck_connections, move and rename it to a static
dss_init_connections function inside display.c. Improve the function to
return errors, and implement a matching dss_uninit_connections that can
be used to free the mgr->dssdev link.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-18 16:15:04 +03:00
Tomi Valkeinen 6b41785836 OMAPDSS: cleanup dss_recheck_connections
dss_recheck_connections is quite a mess. With the previous commit that
initializes the channel field for HDMI and VENC displays, we can greatly
simplify the dss_recheck_connections.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-18 16:15:04 +03:00
Tomi Valkeinen 47eb6763ff OMAPDSS: handle errors in dss_init_device
Add error handling to dss_init_device(), which has, for some reason,
been missing.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-18 16:15:03 +03:00
Tomi Valkeinen bcb226a925 OMAPDSS: explicitely initialize dssdev->channel for new displays
HDMI and VENC outputs always use the DIGIT output from DISPC. The dssdev
struct contains "channel" field which is used to specify the DISPC
output for the display, but this was not used for HDMI and VENC.

This patch fills the channel field explicitely for HDMI and VENC
displays so that we can always rely on the channel field.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-18 16:15:03 +03:00
Tomi Valkeinen 1521653c72 OMAPDSS: register only one display device per output
We have boards with multiple panel devices connected to the same
physical output, of which only one panel can be enabled at one time.
Examples of these are Overo, where you can use different daughter boards
that have different LCDs, and 3430SDP which has an LCD and a DVI output
and a physical switch to select the active display.

These are supported by omapdss so that we add all the possible display
devices at probe, but the displays are inactive until somebody enables
one. At this point the panel driver starts using the DSS, thus reserving
the physcal resource and excluding the other panels.

This is problematic:
- Panel drivers can't allocate their resources properly at probe(),
  because the resources can be shared with other panels. Thus they can
  be only reserved at enable time.
- Managing this in omapdss is confusing. It's not natural to have
  child devices, which may not even exist (for example, a daughterboard
  that is not connected).

Only some boards have multiple displays per output, and of those, only
very few have possibility of switching the display during runtime.
Because of the above points:
- We don't want to make omapdss and all the panel drivers more complex
  just because some boards have complex setups.
- Only few boards support runtime switching, and afaik even then it's
  not required. So we don't need to support runtime switching.

Thus we'll change to a model where we will have only one display device
per output and this cannot be (currently) changed at runtime. We'll
still have the possibility to select the display from multiple options
during boot with the default display option.

This patch accomplishes the above by changing how the output drivers
register the display device. Instead of registering all the devices
given from the board file, we'll only register one. If the default
display option is set, the output driver selects that display from its
displays. If the default display is not set, or the default display is
not one of the output's displays, the output driver selects the first
display.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-18 16:15:02 +03:00
Tomi Valkeinen 6a03fca96e OMAPDSS: Add dss_get_default_display_name()
Add function dss_get_default_display_name() which returns the name of
the default display, given from the board file or via module parameters.
The default display name can be used by output drivers to decide which
display is the wanted one.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-18 16:15:02 +03:00
Tomi Valkeinen 8768a52f8f OMAPDSS: omap_dss_register_device() doesn't take display index
We used to have all the displays of the board in one list, and we made a
"displayX" directory in the sysfs, where X was the index of the display
in the list.

This doesn't work anymore with device tree, as there's no single list to
get the number from, and it doesn't work very well even with non-DT as
we need to do some tricks to get the index nowadays.

This patch changes omap_dss_register_device() so that it doesn't take
disp_num as a parameter anymore, but uses a private increasing counter
for the display number.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-18 16:10:32 +03:00
Tony Lindgren 7d7e1eba7e ARM: OMAP2+: Prepare for irqs.h removal
As the interrupts should only be defined in the platform_data, and
eventually coming from device tree, there's no need to define them
in header files.

Let's remove the hardcoded references to irqs.h and fix up the includes
so we don't rely on headers included in irqs.h. Note that we're
defining OMAP_INTC_START as 0 to the interrupts. This will be needed
when we enable SPARSE_IRQ. For some drivers we need to add
#include <plat/cpu.h> for now until these drivers are fixed to
remove cpu_is_omapxxxx() usage.

While at it, sort som of the includes the standard way, and add
the trailing commas where they are missing in the related data
structures.

Note that for drivers/staging/tidspbridge we just define things
locally.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-09-12 18:06:30 -07:00
Archit Taneja fda7c362f9 OMAPFB: Clear framebuffers before they are registered
The framebuffers are cleared with the function omapfb_clear_fb(), which
internally calls cfb_fillrect(). The boot logo is copied on to the
framebuffer when the fb device is registered with fb framework.

omapfb_clear_fb() is called after the framebuffer is registered, leading to
the boot logo getting cleared. Clear the framebuffers using omapfb_clear_fb()
before registering the framebuffer devices.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-11 13:51:28 +03:00
Tomi Valkeinen 6659145746 Merge branch 'fbdev-for-linus' of git://github.com/schandinat/linux-2.6
Merge omapfb and OMAP SDI fixes:

* OMAPFB: fix framebuffer console colors
* OMAPDSS: Fix SDI PLL locking

Conflicts:
	drivers/video/omap2/dss/sdi.c
2012-09-11 11:28:59 +03:00
Tomi Valkeinen b2f5976c10 OMAPDSS: fix dss_ovl_unset_manager
When we removed fifomerge support, we also changed dss_ovl_disable so
that it doesn't wait for the hardware to be finished with the overlay.
This may cause a problem when changing the overlay's manager, as
changing the manager is an immediate change. Thus if the overlay is
still being used by the HW when the manager is changed, there may be
glitches on the screen.

This patch adds a wait into dss_ovl_unset_manager, which ensures the
overlays are disabled in the HW.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:14 +03:00
Tomi Valkeinen b82fe7f025 OMAPDSS: fix set_timings
set_timings function of DSS's output drivers are not consistent. Some of
them disable the output, set the timings, and re-enable the output. Some
set the timings on the fly, while the output is enabled. And some just
store the given timings, so that they will be taken into use next time
the output is enabled.

We require the DISPC output to be disabled when changing the timings,
and so we can change all the output drivers' set_timings to just store
the given timings.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:13 +03:00
Tomi Valkeinen 66a0f9e4ac OMAPDSS: Use WB fifo for GFX overlay
OMAP4's GFX overlay has smaller fifo than the rest of the overlays
(including writeback "overlay"). This seems to be the reason for
underflows in some more demanding scenarios.

We can avoid the problems by using the WB fifo for GFX overlay, and vice
versa. WB usage is not supported yet, but when it will, it should
perform just fine with smaller fifo as there are no hard realtime
constraints with WB.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:13 +03:00
Tomi Valkeinen 42a6961cf6 OMAPDSS: Improve fifo management code
OMAP4+ allows assigning the overlay FIFOs freely, but that is not
supported by omapdss yet. This patch takes a step forward by improving
the fifo management to be more flexible.

dispc.c is changed to keep track of the sizes of each fifo, and also the
overlay using each fifo.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:13 +03:00
Tomi Valkeinen 85099f11bd Revert "OMAPDSS: APPLY: add fifo merge support funcs"
This reverts commit fb01197422.

Adding fifo merge feature as an omapdss internal configuration was a
mistake. We cannot hide from the users of omapdss the complexities of
fifo merge.

The previous commit removed fifo merge itself, and this removes the
remaining fifo merge support functions.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:12 +03:00
Tomi Valkeinen b3e93cbddd Revert "OMAPDSS: APPLY: add fifo-merge support"
This reverts commit 1d71f42b35.

Adding fifo merge feature as an omapdss internal configuration was a
mistake. We cannot hide from the users of omapdss the complexities of
fifo merge.

This commit removes the fifo merge support, which luckily is easily done
as it was handled totally inside apply.c. Note that this is not a 1:1
revert, but some resolving was needed for the dss_ovl_setup_fifo.

The plan is to try fifo merge again later when it is more clear how the
hardware acts in various situations, and how the omapdrm wants to use
fifo merge.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:12 +03:00
Tomi Valkeinen fed62e54ae OMAPDSS: clean up dss_mgr_set_timings
dss_mgr_set_timings() can only be called when the output is not active.
This means that most of the code in the function is extra, as there's no
need to write the values to registers, etc, because that will be handled
when the output will be enabled.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:11 +03:00
Tomi Valkeinen aba965707c OMAPDSS: clean up dss_mgr_set_lcd_config
dss_mgr_set_lcd_config() can only be called when the output is not
active. This means that most of the code in the function is extra, as
there's no need to write the values to registers, etc, because that will
be handled when the output will be enabled.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:11 +03:00
Tomi Valkeinen f6a0492ee0 OMAPDSS: split manager sysfs code
Separate sysfs code for managers to a separate file. This is a bit
cleaner, and will allow us later to easily switch off the sysfs support
via Kconfig option.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:10 +03:00
Tomi Valkeinen 916915161d OMAPDSS: split overlay sysfs code
Separate sysfs code for overlays to a separate file. This is a bit
cleaner, and will allow us later to easily switch off the sysfs support
via Kconfig option.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:10 +03:00
Tomi Valkeinen a6df3fd963 OMAPDSS: TFP410: use devm_gpio_request_one
Use devm_ version instead of the regular gpio_request_one to simplify
the error handling.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:09 +03:00
Tomi Valkeinen f075a594d7 OMAPDSS: Taal: Reogranize for device tree
Reorganize taal driver to make it easier to integrate device tree code.
Instead of storing the panel's platform data, we'll "parse" the platform
data and store the required information in driver's own data. This way
adding device tree data parsing is simple.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:09 +03:00
Tomi Valkeinen 5ae1f3723f OMAPDSS: VRAM: Remove clearing with sDMA
Currently vram.c clears the allocated memory automatically using OMAP
system DMA. In an effort to reduce OMAP dependencies, we'll do the
memory clear with CPU from now on.

The previous patch implemented memory clear in the omapfb driver, and
this patch removes the now obsolete clear functionality from vram.c.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
2012-09-07 20:02:09 +03:00
Tomi Valkeinen ca44415872 OMAPFB: clear framebuffers with CPU
Currently vram.c clears the allocated memory automatically using OMAP
system DMA. In an effort to reduce OMAP dependencies, we'll do the
memory clear with CPU from now on.

This patch implements clearing of the framebuffer in omapfb, using
cfb_fillrect() to do the actual clear.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:08 +03:00
Tomi Valkeinen fe6a466283 OMAPDSS: remove unnecessary includes
Remove unnecessary includes from omapdss.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:08 +03:00
Tomi Valkeinen 5e56ad44b4 OMAPDSS: Taal: use devm_* functions
Use devm_ functions in panel-taal.c's probe when possible. Also reorder
the initialization sequence so that devm_ allocations are done before
things that require explicit freeing. This simplifies the probe and
remove functions.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:06 +03:00
Tomi Valkeinen ab585254ba OMAPDSS: fix use of dssdev->caps
Recent commit dca2b1522c (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev->caps are initialized, and
the result was that every DSI display is initialized with manual-update
and tear-elim caps.

The code that sets dssdev->caps is not very good, even when fixed.
omapdss driver shouldn't be writing dssdev->caps at all.

This patch fixes the problem with video mode displays by moving the
initialization of dssdev->caps to the panel driver. The same change is
done for RFBI.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:06 +03:00
Tomi Valkeinen ee144e645a OMAPDSS: DSI: calculate dsi clock
Currently the way to configure clocks related to DSI (both DSI and DISPC
clocks) happens via omapdss platform data. The reason for this is that
configuring the DSS clocks is a very complex problem, and it's
impossible for the SW to know requirements about things like
interference.

However, for general cases it should be fine to calculate the dividers
for clocks in the SW. The calculated clocks are probably not perfect,
but should work.

This patch adds support to calculate the dividers when using DSI command
mode panels. The panel gives the required DDR clock rate and LP clock
rate, and the DSI driver configures itself and DISPC accordingly.

This patch is somewhat ugly, though. The code does its job by modifying
the platform data where the clock dividers would be if the board file
gave them. This is not how it's going to be in the future, but allows us
to have quite simple patch and keep the backward compatibility.

It also allows the developer to still give the exact dividers from the
board file when there's need for that, as long as the panel driver does
not override them.

There are also other areas for improvement. For example, it would be
better if the panel driver could ask for a DSI clock in a certain range,
as, at least command mode panels, the panel can work fine with many
different clock speeds.

While the patch is not perfect, it allows us to remove the hardcoded
clock dividers from the board file, making it easier to bring up a new
panel and to use device tree from omapdss.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:05 +03:00
Tomi Valkeinen bc63f30441 OMAPDSS: Add DSI fclk maximum to dss_features
Add max value of DSI functional clock to dss_features, so that DSI
driver can use it.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:05 +03:00
Tomi Valkeinen 174869435e OMAPDSS: HDMI: use vdda_hdmi_dac
The HDMI driver requires vdda_hdmi_dac power for operation, but does not
enable it. This has worked because the regulator has been always
enabled.

But this may not always be the case, as I encountered when implementing
HDMI device tree support.

This patch changes the HDMI driver to use the vdda_hdmi_dac.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:04 +03:00
Tomi Valkeinen a84b20654b OMAPDSS: HDMI: Add delay to wait for 5V power
TPD12S015A spec says to wait 300us after setting CT_CP_HPD gpio for the
5V power output to reach 90% of the voltage. This patch adds the delay
to the driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:03 +03:00
Tomi Valkeinen cca35017ca OMAPDSS: HDMI: Move GPIO handling to HDMI driver
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.

This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the common hdmi.c file, and this probably needs to
be revisited when adding OMAP5 HDMI support to see if the GPIO handling
needs to be moved to IP specific files.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2012-09-07 20:01:49 +03:00
Tomi Valkeinen c50e86ce7c Linux 3.6-rc4
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (GNU/Linux)
 
 iQEcBAABAgAGBQJQQkiRAAoJEHm+PkMAQRiGk64H/Rp67mBWom2xMmU8gul3gr7d
 MFq7dQOShoHZVyuCtKFNF+RTFkHDT2mw0ZkdszHdMkPEznIVRNklieN6GayOwj7C
 XcRb50z/C0CTvEskLOzWsaC+Rok6doOi5VCgkkZ+6N4CvWQNEqWLfWW5H6wZ7juo
 ME1xx/59GDm/4TYMUXzPI9UygptGGXvH/18n/z47FQpvL5EbAECTVt1nPX1uvn/S
 ZzdSLG8MrbK+IX+62JZqRG5M6TUC2b8ggog2cFfP20JNK0TwU9dMQPtbk2Y+LZRg
 JiUqyRUOuQJFbCgE+b1JuleJHAlsAgqIs7tkY9VfdFYfh+NQcaccWjDjdeB7Hjo=
 =Ooia
 -----END PGP SIGNATURE-----

Merge tag 'v3.6-rc4'

Merge 3.6-rc4 to get latest OMAP and device tree fixes.
2012-09-03 09:26:33 +03:00
Grazvydas Ignotas c1c52848ce OMAPFB: fix framebuffer console colors
omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
  echo -e '\e[0;31mRED' > /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Cc: stable@vger.kernel.org # v3.x
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2012-08-23 12:37:22 +00:00
Tomi Valkeinen 35d6786648 OMAPDSS: Fix SDI PLL locking
Commit f476ae9dab (OMAPDSS: APPLY: Remove
DISPC writes to manager's lcd parameters in interface) broke the SDI
output, as it causes the SDI PLL locking to fail.

LCLK and PCLK divisors are located in shadow registers, and we normally
write them to DISPC registers when enabling the output.  However, SDI
uses pck-free as source clock for its PLL, and pck-free is affected by
the divisors. And as we need the PLL before enabling the output, we need
to write the divisors early.

It seems just writing to the DISPC register is enough, and we don't need
to care about the shadow register mechanism for pck-free. The exact
reason for this is unknown.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2012-08-23 12:37:21 +00:00
Chandrabhanu Mahapatra 195e672a76 OMAPDSS: DPI: Remove cpu_is_xxxx checks
The OMAP3 checks have been removed and replaced by a dss feature
FEAT_DPI_USES_VDDS_DSI for cleaner implementation. The patches
"OMAP: DSS2: enable VDDS_DSI when using DPI" (8a2cfea8cc) by Tomi Valkeinen
<tomi.valkeinen@nokia.com> and "ARM: omap: fix oops in
drivers/video/omap2/dss/dpi.c" (4041071571) by Russell King
<rmk+kernel@arm.linux.org.uk> had introduced these checks. As it is evident
from these patches a dependency exists for some DSS pins on VDDS_DSI which is
better shown by dss feature FEAT_DPI_USES_VDDS_DSI.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-22 11:43:05 +03:00
Chandrabhanu Mahapatra ee223b7030 OMAPDSS: VENC: Remove cpu_is_xxxx checks
OMAP4 checks are removed from VENC to provide it a cleaner interface. These
checks were introduced by patches "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4
to prevent crash" (ba02fa37de) by Tomi Valkeinen <tomi.valkeinen@ti.com> and
"OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on
OMAP4" (cc1d3e032d)  by Danny Kukawka <danny.kukawka@bisect.de> to prevent VENC
from crashing OMAP4 kernel.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-22 11:43:04 +03:00
Chandrabhanu Mahapatra 185bae1095 OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
All the cpu_is checks have been moved to dss_init_features function providing a
much more generic and cleaner interface. The OMAP version and revision specific
initializations in various functions are cleaned and the necessary data are
moved to dss_features structure which is local to dss.c.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-22 11:43:03 +03:00
Chandrabhanu Mahapatra ba1bc5bb1d OMAPDSS: DSS: Remove redundant functions
Functions dss_calc_clock_rates() and dss_get_clock_div() are removed as these
functions have become redundant and no longer used.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-22 11:43:03 +03:00
Chandrabhanu Mahapatra dcbe765b4f OMAPDSS: DISPC: Cleanup cpu_is_xxxx checks
All the cpu_is checks have been moved to dispc_init_features function providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions and data are initialized by dispc_features structure which is
local to dispc.c.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-22 11:43:03 +03:00
Tomi Valkeinen 0b3d9cfe7d OMAPDSS: HDMI: fix initial HDMI enable
Commit 7849398fa2 introduced a bug,
causing the following error to be reported:

[  370.827819] cannot lock PLL
[  370.830749] CFG1 0x1e
[  370.833160] CFG2 0x602004
[  370.835876] CFG4 0x40000
[  370.838562] omapdss HDMI: Failed to lock PLL

However, HDMI output is still enabled.

The problem is that we enable the HDMI video output temporarily when
reading EDID or detecting if a HDMI cable is connected (ugh), and the
commit above changes the behavior of the driver so that the video
timings are not yet configured at the point when EDID is read.

This patch fixes the problem by configuring the initial VGA timings at
HDMI probe.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-22 11:33:32 +03:00
Tejun Heo 136b5721d7 workqueue: deprecate __cancel_delayed_work()
Now that cancel_delayed_work() can be safely called from IRQ handlers,
there's no reason to use __cancel_delayed_work().  Use
cancel_delayed_work() instead of __cancel_delayed_work() and mark the
latter deprecated.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Roland Dreier <roland@kernel.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-21 13:18:24 -07:00
Tejun Heo 203b42f731 workqueue: make deferrable delayed_work initializer names consistent
Initalizers for deferrable delayed_work are confused.

* __DEFERRED_WORK_INITIALIZER()
* DECLARE_DEFERRED_WORK()
* INIT_DELAYED_WORK_DEFERRABLE()

Rename them to

* __DEFERRABLE_WORK_INITIALIZER()
* DECLARE_DEFERRABLE_WORK()
* INIT_DEFERRABLE_WORK()

This patch doesn't cause any functional changes.

Signed-off-by: Tejun Heo <tj@kernel.org>
2012-08-21 13:18:23 -07:00
Archit Taneja 89e7195634 OMAPDSS: VENC: Maintian copy of video output polarity info in private data
The VENC driver currently relies on the omap_dss_device struct to configure the
video output polarity. This makes the VENC interface driver dependent on the
omap_dss_device struct.

Make the VENC driver data maintain it's own polarity field. A panel driver
is expected to call omapdss_venc_invert_vid_out_polarity() before enabling the
interface.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:47:52 +05:30
Archit Taneja febe2905d0 OMAPDSS: VENC: Maintain copy of venc type in driver data
The VENC driver currently relies on the omap_dss_device struct to configure the
venc type. This makes the VENC interface driver dependent on the omap_dss_device
struct.

Make the VENC driver data maintain it's own 'venc type' field. A panel driver
is expected to call omapdss_venc_set_type() before enabling the interface or
changing the type via display sysfs attributes.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:10:17 +05:30
Archit Taneja 6e883324b2 OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data
The RFBI driver currently relies on the omap_dss_device struct to receive the
rfbi specific timings requested by the panel driver. This makes the RFBI
interface driver dependent on the omap_dss_device struct.

Make the RFBI driver data maintain it's own rfbi specific timings field. The
panel driver is expected to call omapdss_rfbi_set_interface_timings() to
configure the rfbi timings before the interface is enabled.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:09:41 +05:30
Archit Taneja 0b3ffe397a OMAPDSS: DSI: Maintain copy of video mode timings in driver data
The DSI driver currently relies on the omap_dss_device struct to receive the
video mode timings requested by the panel driver. This makes the DSI interface
driver dependent on the omap_dss_device struct.

Make the DSI driver data maintain it's own video mode timings field. The panel
driver is expected to call omapdss_dsi_set_videomode_timings() to configure the
video mode timings before the interface is enabled.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:05:56 +05:30
Archit Taneja 6b84937577 OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings
The struct omap_dss_dsi_videomode_data holds fields which need to be configured
for DSI to operate in video mode. Rename the struct to dsi_videomode_timings.

One reason to do this is because most of the fields in the struct are timings
related. The other reason is to create a generic op for output specific
timings. This generic op can be considered as a way to set custom or private
timings for the output.

In the case of OMAP, DSI and RFBI require some more timings apart from the
relgular DISPC timings. The structs omap_dss_videomode_timings and rfbi_timings
can be considered as these output specific timings respectively.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:02:11 +05:30
Archit Taneja dca2b1522c OMAPDSS: DSI: Maintain copy of operation mode in driver data
The DSI driver currently relies on the omap_dss_device struct to know the mode
of operation of the DSI protocol(command or video mode). This makes the DSI
interface driver dependent on the omap_dss_device struct.

Make the DSI driver data maintain it's own operation mode field. The panel
driver is expected to call omapdss_dsi_set_operation_mode() before the interface
is enabled.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:02:00 +05:30
Archit Taneja 889b4fd7ee OMAPDSS: SDI: Maintain copy of data pairs in driver data
The SDI driver currently relies on the omap_dss_device struct to configure the
number of data pairs as specified by the panel. This makes the SDI interface
driver dependent on the omap_dss_device struct.

Make the SDI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_sdi_set_datapairs() before enabling the interface.
Even though we configure the number of data pairs here, this function would be
finally mapped to a generic interface op called set_data_lines. The datapairs
argument type has been changed from u8 to int at some places to be in sync with
the 'set_data_lines' ops of other interfaces.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:00:55 +05:30
Archit Taneja c6b393d4bc OMAPDSS: DPI: Maintain copy of number of data lines in driver data
The DPI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the DPI interface
driver dependent on the omap_dss_device struct.

Make the DPI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_dpi_set_data_lines() before enabling the interface.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:00:55 +05:30
Archit Taneja 475989b763 OMAPDSS: RFBI: Maintain copy of number of data lines in driver data
The RFBI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the RFBI interface
driver dependent on the omap_dss_device struct.

Make the RFBI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_rfbi_set_data_lines() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:00:54 +05:30
Archit Taneja b02875be08 OMAPDSS: RFBI: Maintain copy of pixel size in driver data
The RFBI driver currently relies on the omap_dss_device struct to receive the
desired pixel size of the panel. This makes the RFBI interface driver dependent
on the omap_dss_device struct.

Make the RFBI driver data maintain it's own pixel format field. A panel driver
is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:00:54 +05:30
Archit Taneja 02c3960b1e OMAPDSS: DSI: Maintain copy of pixel format in driver data
The DSI driver currently relies on the omap_dss_device struct to receive the
desired pixel format of the panel. This makes the DSI interface driver dependent
on the omap_dss_device struct.

Make the DSI driver data maintain it's own pixel format field. The panel driver
is expected to call omapdss_dsi_set_pixel_format() to configure the pixel format
before the interface is enabled.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:00:47 +05:30
Archit Taneja 6ff9dd5a6f OMAPDSS: RFBI: Add function to set panel size
RFBI drivers requires configuration of the update area. Since we don't support
partial updates, the size to be configures is the panel size itself.

Add a timings field in RFBI's driver data. Apart from x_res and y_res, all the
other fields are configured to an initial value when RFBI is enabled. A panel
driver is expected to call omapdss_rfbi_set_size() configure the size of the
panel.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-15 15:53:09 +05:30
Archit Taneja 43eab86167 OMAPDSS: RFBI: Remove partial update support
Partial update suppport was removed from DISPC and DSI sometime back. The RFBI
driver still tries to support partial update without the underlying support in
DISPC.

Remove partial update support from RFBI, only support updates which span acros
the whole panel size. This also helps in DSI and RFBI having similar update
ops.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-15 15:53:08 +05:30
Archit Taneja a5abf4721b OMAPDSS: VENC: Maintain our own timings field in driver data
The VENC driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and VENC blocks accordingly. This makes the VENC interface
driver dependent on the omap_dss_device struct.

Make the VENC driver data maintain it's own timings field. The panel driver is
expected to call omapdss_venc_set_timings() to set these timings before the
panel is enabled. Call omapdss_venc_set_timings() before enabling
venc output, this is done to atleast have the venc output configured to the
panel's default timings if the DSS user didn't explicitly call the venc panel
driver's set_timings op.

Make the VENC panel driver configure the new timings is the omap_dss_device
struct(dssdev->panel.timings). The VENC driver is responsible for maintaining
only it's own copy of timings.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-15 15:50:50 +05:30
Archit Taneja 156fd99e92 OMAPDSS: VENC: Split VENC into interface and panel driver
The current venc.c driver contains both the interface and panel driver code.
This makes the driver hard to read, and difficult to understand the work split
between the interface and panel driver and the how the locking works.

This also makes it easier to clearly define the VENC interface ops called by the
panel driver.

Split venc.c into venc.c and venc_panel.c representing the interface and panel
driver respectively. This split is done along the lines of the HDMI interface
and panel drivers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-15 15:49:23 +05:30
Archit Taneja 9b4a5716ef OMAPDSS: SDI: Maintain our own timings field in driver data
The SDI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the SDI interface driver dependent
on the omap_dss_device struct.

Make the SDI driver data maintain it's own timings field. The panel driver is
expected to call omapdss_sdi_set_timings() to set these timings before the panel
is enabled.

Make the SDI panel driver configure the new timings is the omap_dss_device
struct(dssdev->panel.timings). The SDI driver is responsible for maintaining
only it's own copy of timings.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-15 15:48:45 +05:30
Archit Taneja c7833f7bc0 OMAPDSS: SDI: Create a function to set timings
Create function omapdss_sdi_set_timings(). Configuring new timings is done the
same way as before, SDI is disabled, and re-enabled with the new timings in
dssdev. This just moves the code from the panel drivers to the SDI driver.

The panel drivers shouldn't be aware of how SDI manages to configure a new set
of timings. This should be taken care of by the SDI driver itself.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-15 15:48:45 +05:30
Archit Taneja ed1aa9003b OMAPDSS: HDMI: Add locking for hdmi interface set timing functions
The hdmi interface driver exposes functions to the hdmi panel driver to
configure the interface timings maintained by the hdmi driver.

These timings(stored in hdmi.ip_data.cfg) should be protected by the hdmi lock
to ensure they are called sequentially, this is similar to how hdmi enable and
disable functions need locking.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-15 15:48:23 +05:30
Archit Taneja 7849398fa2 OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings
The hdmi driver currently updates only the 'code' member of hdmi_config when
the op omapdss_hdmi_display_set_timing() is called by the hdmi panel driver.
The 'timing' field of hdmi_config is updated only when hdmi_power_on is called.
It makes more sense to configure the whole hdmi_config field in the set_timing
op called by the panel driver. This way, we don't need to call both functions
to ensure that our hdmi_config is configured correctly. Also, we don't need to
calculate hdmi_config during hdmi_power_on, or rely on the omap_video_timings
in the panel's omap_dss_device struct.

The default timings of the hdmi panel are represented in a cleaner form. Since
the hdmi output is now configured by it's own copy of timings (in
hdmi.ip_data.cfg), the panel driver needs to set it to a valid value before
enabling hdmi output. We now call omapdss_hdmi_set_timing() before enabling
hdmi output, this is done to atleast have the hdmi output configured to the
panel's default timings if the DSS user didn't call panel driver's set_timings()
op explicitly.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-15 15:42:43 +05:30
Archit Taneja 55cd63acf6 OMAPDSS: DSI: Update manager timings on a manual update
During a command mode update using DISPC video port, we may need to swap the
connected overlay manager's width and height when 90 or 270 degree rotation is
done via the panel by changing it's address mode.

Call dss_mgr_set_timings() in update_screen_dispc() before starting the manager
update. The new manager size is updated in the 'timings' field of DSI driver's
private data via omapdss_dsi_set_size(). A panel driver is expected to call this
when performing rotation.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:40 +05:30
Archit Taneja e352574db5 OMAPDSS: DSI: Add function to set panel size for command mode panels
DSI command mode panels don't need to configure a full set of timings to
configure DSI, they only require the width and the height of the panel in
pixels.

Use omapdss_dsi_set_size for command mode panels, omapdss_dsi_set_timings is
meant for video mode panels. When performing rotation via chaning the address
mode of the panel, we would need to swap width and height when doing 90 or 270
rotation. Make sure that omapdss_dsi_set_size() makes the new width and height
visible to DSI.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Archit Taneja e67458a831 OMAPDSS: DSI: Maintain own copy of timings in driver data
The DSI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and DSI blocks accordingly. This makes the DSI interface
driver dependent on the omap_dss_device struct.

Make the DSI driver data maintain it's own timings field. A DSI video mode panel
driver is expected to call omapdss_dsi_set_timings() to set these timings before
the panel is enabled.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Archit Taneja bdcae3cc39 OMAPDSS: DPI displays: Take care of panel timings in the driver itself
The timings maintained in omap_dss_device(dssdev->panel.timings) should be
maintained by the panel driver itself. It's the panel drivers responsibility
to update it if a new set of timings is to be configured. The DPI interface
driver shouldn't be responsible of updating the panel timings, it's responsible
of maintianing it's own copy of timings.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Archit Taneja c499144c3b OMAPDSS: DPI: Maintain our own timings field in driver data
The DPI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the DPI interface driver dependent
on the omap_dss_device struct.

Make the DPI driver data maintain it's own timings field. The panel driver is
expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set
these timings before the panel is enabled.

In the set_timings() op, we still ensure that the omap_dss_device timings
(dssdev->panel.timings) are configured. This will later be configured only by
the DPI panel drivers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Archit Taneja e19d659bbf OMAPDSS: Displays: Add locking in generic DPI panel driver
The generic DPI panel driver doesn't currently have locking to ensure that
the display states and the driver data is maintained correctly. Add mutex
locking to take care of this. Add a new get_timings driver op to override the
default get_timings op. The new driver op contains locking to ensure the correct
panel timings are seen when a DSS2 user calls device->driver->get_timings.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Archit Taneja c8a5e4e86d OMAPDSS: DPI: Add locking for DPI interface
The DPI interface driver currently relies on the panel driver to ensure calls
like omapdss_dpi_display_enable() and omapdss_dpi_display_disable() are executed
sequentially. Also, currently, there is no way to protect the DPI driver data.

All DPI panel drivers don't ensure this, and in general, a DPI panel driver
should use it's lock to that ensure it's own driver data and omap_dss_device
states are taken care of, and not worry about the DPI interface.

Add mutex locking in the DPI enable/disable/set_timings ops.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Archit Taneja 27dfddc7fe OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings
The function dss_mgr_set_timings is supposed to apply timings passed by an
interface driver. It is not supposed to change the timings. Add const qualifier
to the omap_video_timings pointer argument in dss_mgr_set_timings().

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Grazvydas Ignotas a2496dc942 OMAPFB: fix framebuffer console colors
omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
  echo -e '\e[0;31mRED' > /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-10 15:48:40 +03:00
Ricardo Neri 8aa2eed134 OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
DSS code wrongly assumes that VENC is always available as source for the external
sync signal for the display controller DIGIT channel. One cannot blindly write/read
the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5) this operation
may not be valid. If the the sync source is not read correctly, the callers of
dss_get_hdmi_venc_clk_source might make wrong assumptions about, for instance,
video timings.

Logic is added to correctly get the sync signal based on the available displays
in the DIGIT channel. The source is set only if both VENC and HDMI are supported.

Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-10 15:48:35 +03:00
Jassi Brar d7ad718d35 OMAPDSS: DISPC: Use msleep instead of blocking mdelay
We have no reason to block in the error handler workqueue, so use msleep.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-10 15:48:28 +03:00
Ricardo Neri d3b4aa519c OMAPDSS: HDMI: Disable PLL properly in case of error at power_on
Small patch to disable the PLL appropriately before runtime_put in case
an error occurs while enabling the PHY.

Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-08-10 15:48:24 +03:00
Florian Tobias Schandinat d9053b4879 Merge branch 'for-florian' of git://gitorious.org/linux-omap-dss2/linux into fbdev-next
Conflicts:
	drivers/video/omap2/dss/core.c
	drivers/video/omap2/dss/dispc.c
2012-07-25 08:55:46 +00:00
Florian Tobias Schandinat d65c8f312c Merge branch 'fbdev-for-linus' into fbdev-next 2012-07-08 14:00:47 +00:00
Tomi Valkeinen 373b436521 OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n
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>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2012-07-08 14:00:27 +00:00
Tomi Valkeinen 736f29cd6b OMAPDSS: Use PM notifiers for system suspend
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>
Tested-by: Joe Woodward <jw@terrafix.co.uk>
Signed-off-by: Archit Taneja <archit@ti.com>
[fts: fixed 2 brace coding style issues]
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2012-07-08 14:00:26 +00:00
Archit Taneja 6c6f510afb OMAPDSS: OVERLAY: Clean up replication checking
Replication logic for an overlay depends on the color mode in which it is
configured and the video port width of the manager it is connected to.

video port width now held in dss_lcd_mgr_config in the manager's private
data in APPLY. Use this instead of referring to the omap_dss_device connected to
the manager.

Replication is enabled in the case of TV manager, the video_port_width is set to
a default value of 24 for TV manager.

Make the replication checking an overlay function since it's more of an overlay
characteristic than a display characteristic.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 16:27:59 +05:30
Archit Taneja c47cdb3088 OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay manager
The RFBI driver uses a direct DISPC register write to enable the overlay
manager. Replace this with dss_mgr_enable() which checks if the connected
overlay and managers are correctly configured, and configure DSS for
fifomerge.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 16:27:59 +05:30
Archit Taneja dd88b7a677 OMAPDSS: DISPC: Remove a redundant function
dss_mgr_is_lcd() available in dss.h does the same thing as dispc_mgr_is_lcd()
in dispc.c. Remove the function from dispc.c and replace it with the one in
dss.h.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 16:27:58 +05:30
Archit Taneja 75bac5d1a2 OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checks
APPLY needs to know at certain places whether an overlay manager is in manual
or auto update mode. The caps of the connected omap_dss_device were used to
check that.

A LCD manager is in manual update if stallmode is enabled for that manager. TV
managers for now always auto update.

Return the value of stallmode parameter in the private data 'lcd_confg' in
mgr_manual_update() and ovl_manual_update(), for TV managers stallmode field
will be false by default.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 16:27:58 +05:30
Archit Taneja 6e5435958c OMAPDSS: MANAGER: Check LCD related overlay manager parameters
The LCD related manager configurations are a part of the manager's private data
in APPLY. Pass this to dss_lcd_mgr_config to dss_mgr_check and create a function
to check the validity of some of the configurations.

To check some of the configurations, we require information of interface to
which the manager output is connected. These can be added once interfaces are
represented as an entity.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 16:27:57 +05:30
Archit Taneja f476ae9dab OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drivers
Replace the DISPC fuctions used to configure LCD channel related manager
parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that
the DISPC registers are written at the right time by using the shadow register
programming model.

The LCD manager configurations is stored as a private data of manager in APPLY.
It is treated as an extra info as it's the panel drivers which trigger this
apply via interface drivers, and not a DSS2 user like omapfb or omapdrm.

Storing LCD manager related properties in APPLY also prevents the need to refer
to the panel connected to the manager for information. This helps in making the
DSS driver less dependent on panel.

A helper function is added to check whether the manager is LCD or TV. The direct
DISPC register writes are removed from the interface drivers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 16:27:42 +05:30
Archit Taneja 37a579903e OMAPDSS: SDI: Configure dss_lcd_mgr_config struct with lcd manager parameters
Create a dss_lcd_mgr_config struct instance in SDI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by SDI.

Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.

Create function sdi_config_lcd_manager() which fills the mgr_config parameters
and writes to the DISPC registers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 16:02:41 +05:30
Archit Taneja 7d2572f8b3 OMAPDSS: DSI: Configure dss_lcd_mgr_config struct with lcd manager parameters
Create a dss_lcd_mgr_config struct instance in DSI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by DSI.

Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.

The function dsi_configure_dispc_clocks() is now called in
dsi_display_init_dispc(), this lets all the lcd manager related configurations
happen in the same place. The DISPC_DIVISORo register was written in
dsi_configure_dispc_clock(), now it just fills up the dispc_clock_info parameter
in mgr_config. The clock_info is written later in dsi_display_init_dispc().

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 16:02:26 +05:30
Archit Taneja bc2e60a69f OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parameters
Create a dss_lcd_mgr_config struct instance in RFBI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by RFBI.

Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.

Create function rfbi_config_lcd_manager() which fills up the mgr_config
parameters and writes to the DISPC regs.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 14:46:49 +05:30
Archit Taneja 5cf9a26411 OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parameters
Create a dss_lcd_mgr_config struct instance in DPI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by DPI.

Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.

The DISPC_DIVISORo registers were written in the functions dpi_set_dispc_clk()
and dpi_set_dsi_clk(), now they just fill up the dispc_clock_info parameter in
mgr_config. They are written later in dpi_config_lcd_manager.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 14:46:43 +05:30
Archit Taneja c56fb3ef05 OMAPDSS: Add struct to hold LCD overlay manager configuration
Create a struct dss_lcd_mgr_config which holds LCD overlay manager related
parameters. These are currently partially contained in the omap_dss_device
connected to the manager, and the rest are in the interface driver.

The parameters are directly written to the DISPC registers in the interface
drivers. These should eventually be applied at the correct time using the
shadow register programming model. This struct would help in grouping these
parameters so that they can be applied together.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 14:03:48 +05:30
Archit Taneja f0d08f89ff OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div()
dipsc_mgr_set_clock div has an int return type to report errors or success.
The function doesn't really check for errors and always returns 0. Change
the return type to void.

Checking for the correct DISPC clock divider ranges will be done when a DSS2
user does a manager apply. This support will be added later.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 14:00:54 +05:30
Archit Taneja bd5a7b11a0 OMAPDSS: DSI: Fix HSYNC, VSYNC and DE polarities between DISPC and DSI
For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC
and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and
VP_DE_POL in DSI_CTRL registers.

This information is completely internal to DSS as logic levels for the above
signals hold no meaning on the DSI bus. Hence a DSI panel driver should be
totally oblivious of these fields.

Fix the logic levels/polarities in the DISPC and DSI registers to a default
value. This is done by overriding these fields in omap_video_timings struct
filled by the panel driver for DISPC, and use the equivalent default values
when programming DSI_CTRL registers. Also, remove the redundant polarity related
fields in omap_dss_dsi_videomode_data.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:54 +03:00
Archit Taneja cc937e5e4b OMAPDSS: HDMI: Remove custom hdmi_video_timings struct
The hdmi CEA and VESA timings were represented by the struct hdmi_video_timings,
omap_video_timings couldn't be used as it didn't contain the fields hsync/vsync
polarities and interlaced/progressive information.

Remove hdmi_video_timings, and use omap_video_timings instead.

Cc: Mythri P K <mythripk@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:53 +03:00
Archit Taneja 23bae3adbf OMAPFB: Map interlace field in omap_video_timings with fb vmode flags
Use the interlace field in omap_video_timings to configure/retrieve
corresponding fb mode flags in fb_var_screeninfo and fb_videomode.

The interlace field maps with the fb mode flags FB_VMODE_INTERLACED and
FB_VMODE_NONINTERLACED.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:53 +03:00
Archit Taneja 8050cbe4cd OMAPDSS: DISPC/APPLY: Use interlace info in manager timings for dispc_ovl_setup()
Currently the interlace parameter passed to dispc_ovl_setup() is configured by
checking the display type, and set to true if the display type is VENC.

This isn't correct as other panels can take interlaced content too. The
omap_video_timings struct in manager's private data contains the info whether
the panel is in interlaced mode or not.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:52 +03:00
Archit Taneja 23c8f88e8a OMAPDSS: Add interlace parameter to omap_video_timings
Add a parameter called interlace which tells whether the timings are in
interlaced or progressive mode. This aligns the omap_video_timings struct with
the Xorg modeline configuration.

It also removes the hack needed to write to divide the manager height by 2 if
the connected interface is VENC.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:52 +03:00
Archit Taneja 07fb51c6bd OMAPDSS: Remove omap_panel_config enum from omap_dss_device
omap_panel_config contains fields which are finally written to DISPC_POL_FREQo
registers. These are now held by omap_video_timings and are set when the manager
timings are applied.

Remove the omap_panel_config enum, and remove all it's references from panel or
interface drivers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:51 +03:00
Archit Taneja 783babf33f OMAPFB: Map the newly added omap_video_timings fields with fb sync flags
Use the newly added fields in omap_video_timings(hsync, vsync and data_enable
logic levels and data, hsync and vsync latching related info) to
configure/retrieve corresponding sync flags in fb_var_screeninfo and
fb_videomode.

Out of the new fields, hsync_level and vsync_level can be mapped to the fb sync
flags FB_SYNC_HOR_HIGH_ACT and FB_SYNC_VERT_HIGH_ACT.

When converting fb mode to omap_video_timings, the fields which don't have an
equivalent parameter in fb are kept as the original values if the panel driver
has a get_timings op, else they are set to default values.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:51 +03:00
Archit Taneja 0e065c79e6 OMAPDSS: DISPC: Remove dispc_mgr_set_pol_freq()
dispc_mgr_set_pol_freq() configures the fields in the register DISPC_POL_FREQo.
All these fields have been moved to omap_video_timings struct, and are now
programmed in dispc_mgr_set_lcd_timings(). These will be configured when timings
are applied via dss_mgr_set_timings().

Remove dispc_mgr_set_pol_freq() and it's calls from the interface drivers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:50 +03:00
Archit Taneja 655e294116 OMAPDSS: DISPC: Configure newly added omap_video_timing fields
Hsync, Vsync, Data enable enable logic levels and latching info of Data lanes,
Hsync and Vsync signals(with respect to pixel clock) are newly added parameters
in omap_video_timings.

Program these in dispc_mgr_set_lcd_timings. These will be configured when the
manager's timings are set via dss_mgr_set_timings().

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:50 +03:00
Archit Taneja a14909eac8 OMAPDSS: DISPLAY: Ignore newly added omap_video_timings fields for display timings sysfs file
The display sysfs file for viewing/storing display timings is something which
will be deprecated. The new omap_video_timings fields (hsync_level, vsync_level
and others) are not configurable or viewable via this sysfs file.

This prevents the need to make the input more configurable to take the new
fields and at the same time work without these fields for backward
compatibility.

In display_timings_store, the omap_video_timings struct used to set the timings
is initialized to the existing panel timings so that the new fields are taken in
correctly. The other fields are taken from the user as before.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:49 +03:00
Archit Taneja a8d5e41cef OMAPDSS: Add some new fields to omap_video_timings
Some panel timing related fields are contained in omap_panel_config in the form
of flags. The fields are:

- Hsync logic level
- Vsync logic level
- Data driven on rising/falling edge of pixel clock
- Output enable/Data enable logic level
- HSYNC/VSYNC driven on rising/falling edge of pixel clock

Out of these parameters, Hsync and Vsync logic levels are a part of the timings
in the Xorg modeline configuration. So it makes sense to move the to
omap_video_timings. The rest aren't a part of modeline, but it still makes
sense to move these since they are related to panel timings.

These fields stored in omap_panel_config in dssdev are configured for LCD
panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers.

Add the above fields in omap_video_timings. Represent their state via new enums.

Add these parameters to the omap_video_timings instances in the panel drivers.
Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in
omap_panel_config for now. The struct will be removed later.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:49 +03:00
Archit Taneja a9105cb5c2 OMAPDSS: Remove passive matrix LCD support (part 4)
Remove configuration of Ac-bias pins

Ac-bias pins need to be configured only for passive matrix displays. Remove
acbi and acb fields in omap_dss_device and their configuration in panel
drivers. Don't program these fields in DISP_POL_FREQo register any more.

The panel driver for sharp-ls037v7dw01, and the panel config for
Innolux AT070TN8 in generic dpi panel driver set acb to a non zero value. This
is most likely carried over from the old omapfb driver which supported passive
matrix displays.

Cc: Thomas Weber <weber@corscience.de>
Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:48 +03:00
Archit Taneja d21f43bc39 OMAPDSS: Remove passive matrix LCD support (part 3)
Remove omap_lcd_display_type enum

The enum omap_lcd_display_type is used to configure the lcd display type in
DISPC. Remove this enum and always set display type to TFT by creating function
dss_mgr_set_lcd_type_tft().

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:46 +03:00
Archit Taneja 5ae9eaa6db OMAPDSS: Remove passive matrix LCD support (part 2)
Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.

We don't support passive matrix displays any more. Remove this flag from all the
panel drivers.

Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:10:03 +03:00
Archit Taneja 6d523e7b0e OMAPDSS: Remove passive matrix LCD support (part 1)
Remove clock constraints related to passive matrix displays.

There is a constraint (pcd_min should be 3) for passive matrix displays. Remove
this constraint in clock divider calculations as we won't support passive
matrix displays any more.

This cleans up the functions which calculate the clock dividers with DSI's PLL
or DSS_FCLK as the clock source.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:10:03 +03:00
Jassi Brar 3a5383a237 OMAPDSS: HDMI: Replace spinlock with mutex in hdmi_check_hpd_state
State change of HDMI PHY could potentially take many millisecs, we can do
better by protecting things in hdmi_set_phy_pwr() with a mutex rather than
a spin_lock_irqsave.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-06-29 09:42:42 +03:00
Jassi Brar ece2f1539e OMAPDSS: HDMI: Discard phy_tx_enabled member
It is simpler to read the current status from a register as compared
to maintaining a state variable to hold the information.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-06-29 09:41:33 +03:00
Chandrabhanu Mahapatra 6f1891fc70 OMAPDSS: Add dump and debug support for LCD3
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>
2012-06-29 09:41:29 +03:00
Chandrabhanu Mahapatra e86d456a23 OMAPDSS: Add LCD3 overlay manager and Clock and IRQ support
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>
2012-06-29 09:41:24 +03:00
Chandrabhanu Mahapatra ff6331e25e OMAPDSS: Add support for LCD3 channel
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>
2012-06-29 09:41:20 +03:00
Chandrabhanu Mahapatra efa70b3b7d OMAPDSS: Cleanup implementation of LCD channels
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>
2012-06-29 09:41:15 +03:00
Tomi Valkeinen 5be3aebd09 OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n
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>
2012-06-29 09:09:49 +03:00
Tomi Valkeinen 2b8501d777 OMAPDSS: Use PM notifiers for system suspend
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>
2012-06-29 09:09:40 +03:00
Rajendra Nayak f11766d1c2 OMAPDSS: add clk_prepare_enable and clk_disable_unprepare
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>
2012-06-29 09:09:17 +03:00
Peter Meerwald 7df913b352 OMAPDSS: fix specification spelling in Kconfig
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-06-28 09:11:45 +03:00
Tomi Valkeinen 0df8ad71a2 OMAPDSS: remove enum omap_dss_overlay_managers
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>
2012-06-28 09:11:28 +03:00
Linus Torvalds 7794f709c5 Small fixes for omapdss driver. Most importantly, fixes a build problem when
debugfs or omapdss debug support is turned off, and fixes a suspend related
 crash.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJPzhSwAAoJEPo9qoy8lh71dsoP/jaG+94RexLOAAr4uzqV7t3c
 PB/CTp1SwALNhGYflZMtQF6tx6hVWbqEQqY0KmyseJeC2hp5pNluKuMkxspyPyfx
 aoYER3XNb0ncsjQzhrFWa4HgBUt3nAeS0e2mDLQDEkhuh5bsgtyu3OsPIHELbZGL
 4kW3xO3ujEJLVQlHP58EWGgE8051dU608uEAte95lxeNhLaF27WNFJBDYIwriGjl
 a6vglYkoMAW+nV3k1KjOq2WNpVSh/uvCPZJd+aPa36z16IGR7EfQPTdh0yVtdbjc
 ABdaOnoUKkb8AfQtMQaCLzVWMnIao6klbAJv/RIue3VCjdj4Rhjd4Ds0rTh9sIqM
 VrKyg1j+VKJyuuIPSo4SlNETMi2kMLnaKjKd+hXcft5eVkdWlpPOGcEg1OtdosMA
 pPOLdg+VmAKTey3Sjn8oBRZIJbfG6uKPDB/EWFHNgii+8H3WMU7LBuGj9JlB8ERY
 Tnl17cxS5YnVFkpjvzIAYk7vgY5v3rh9y6VwlfTaU0FMJ4z0VMwkUN6nCvGezvM0
 A1cJ9Yvm8tMkBjurEkdBIyysjBVa8D4oEnsMBUMXzz8besGkPaFRBhPBu9buKwdz
 mbwkla7STxQ5/jWQjsabvzwMuZ+oHuo5GdVZd65w0+VU+fSZ3jVN8chikDHyISEu
 6W9OV0PeZp0miTlhynKW
 =yO72
 -----END PGP SIGNATURE-----

Merge tag 'omapdss-for-3.5-rc2' of git://gitorious.org/linux-omap-dss2/linux

Pull omapdss build problem fix from Tomi Valkeinen:
 "Small fixes for omapdss driver.  Most importantly, fixes a build
  problem when debugfs or omapdss debug support is turned off, and fixes
  a suspend related crash."

This has apparently been annoying rmk for a while..

* tag 'omapdss-for-3.5-rc2' of git://gitorious.org/linux-omap-dss2/linux:
  OMAPDSS: fix registration of DPI and SDI devices
  OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters
  OMAPDSS: fix bogus WARN_ON in dss_runtime_put()
  OMAPDSS: Taal: fix compilation warning
  OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled
2012-06-13 17:57:30 +03:00
Tomi Valkeinen 289733ed45 Linux 3.5-rc2
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQEcBAABAgAGBQJP0qm4AAoJEHm+PkMAQRiG62QIAJRNJFyVB0ZrsMPgdwLnlX4O
 5I86H7GaYXoOK/KMb2s5h4KiFggIODnyEkZi+/39tJOgGo0KrMcDlsh0owB1Iggw
 LE6iyze9I1z9wQze0+SXe7VAcvUYvsx2vgpOKvoNi97Qgn3B6onL+SAi5U+NAqJl
 0NdKmveEd42UIm7JfChHlxl8bm8YB+WcU38OkMGpRpJ/Moz9EbSjYVQg3oHrzJjy
 duiX6SD/OV4m5yCcXXmu+f41pN+SG7xENJ5r4enyi2ZF8mAyVz2goIyL2bA0AJX2
 +GbpD1sxUHkZ6yPg4tf2bmJOj0PkfZNAi8YpFxZDlP4y1pKuCTEDTBp8O2id43w=
 =Jyn8
 -----END PGP SIGNATURE-----

Merge tag 'v3.5-rc2'

Merge v3.5-rc2 to get latest device tree and dynamic debug changes.
2012-06-13 11:24:38 +03:00
Archit Taneja 2e063c305a OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters
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>
2012-06-04 13:07:51 +03:00
Tomi Valkeinen 5025ce070e OMAPDSS: fix bogus WARN_ON in dss_runtime_put()
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>
2012-06-04 11:04:41 +03:00
Tomi Valkeinen d1700f9258 OMAPDSS: Taal: fix compilation warning
This patch fixes a warning:

drivers/video/omap2/displays/panel-taal.c: In function
‘taal_num_errors_show’:
drivers/video/omap2/displays/panel-taal.c:529: warning: ‘errors’ may be
used uninitialized in this function

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-06-04 11:04:40 +03:00
Tomi Valkeinen 0e9a126e95 OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled
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>
2012-06-04 11:04:40 +03:00
Linus Torvalds 804ce9866d fbdev updates for 3.5
It includes:
 - driver for AUO-K1900 and AUO-K1901 epaper controller
 - large updates for OMAP (e.g. decouple HDMI audio and video)
 - some updates for Exynos and SH Mobile
 - various other small fixes and cleanups
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJPyAhmAAoJECSVL5KnPj1PBcoQAIWftuoXo3sk94f5jKcV4Ucx
 MthEc5iEpMVs8xaEruHHNHXWv8ic0x/PfdC2xrpKOEbNXQcNPlb/QE2xWmBRxmT1
 ucDyu10HJ36jKcwcK4ra5IQwOW+GtbTBEoBZT+WNAjxHZtJmxzjQGM4C12zVQpdJ
 +qV2RP93JmsJoVBL9aKVAg1Ko135LLfD8TcKd+z8TmgFnLfSwKhfl7Jtd2xXwyvz
 /hmW3kJUEnD8E5wuj+/g8sKJhQkGalEiITTqG2j2vJyFgxHSqyLSw8BBixrFW1uT
 B9VnZsHF35ccCo+96UZRH4QsGJTx08+rea/qsv8IMSGczyRp5ey1ufjL+CzKiiIN
 FWfex6fY0HHqZGAopQhjag54e914SIbSxdBwWS/iRrtVt3e9d03BzkhYs4rXl4Ey
 CTC5obzWNTbQ6hLEjgWfVKkKcrF56BnRn3zGPgCTKGp2NK3vODdBkt/EmzUFvCWR
 CcyQhh+PvZzEWp3XsdOGossYs/0aP4bO+7XPGJxZaa3+WVcRaZwAG/uZvJXXBfnp
 DGRFy4wPsTTwKYIx4+t/KrsLtNVKioSMS5GEtuM1YEb8pA7mkUIkqwJv1I261h58
 heTr6vWUsviUqHlKALJ+1CdwWGr3CtktCZssGsSUri61nm8CvlSRn2Nr2aJ/L3RN
 AkemC/33RE5X/+lfkdMx
 =tmIU
 -----END PGP SIGNATURE-----

Merge tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6

Pull fbdev updates from Florian Tobias Schandinat:
 - driver for AUO-K1900 and AUO-K1901 epaper controller
 - large updates for OMAP (e.g. decouple HDMI audio and video)
 - some updates for Exynos and SH Mobile
 - various other small fixes and cleanups

* tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6: (130 commits)
  video: bfin_adv7393fb: Fix cleanup code
  video: exynos_dp: reduce delay time when configuring video setting
  video: exynos_dp: move sw reset prioir to enabling sw defined function
  video: exynos_dp: use devm_ functions
  fb: handle NULL pointers in framebuffer release
  OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
  OMAPDSS: Apply VENC timings even if panel is disabled
  OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
  OMAPDSS: DISPC: Support rotation through TILER
  OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
  OMAPFB: remove compiler warnings when CONFIG_BUG=n
  OMAPDSS: remove compiler warnings when CONFIG_BUG=n
  OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
  OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
  OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
  OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
  drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
  video: exynos mipi dsi: support reverse panel type
  video: exynos mipi dsi: Properly interpret the interrupt source flags
  video: exynos mipi dsi: Avoid races in probe()
  ...
2012-06-01 16:57:51 -07:00
Corentin Chary f5f4fd4516 backlight: initialize struct backlight_properties properly
In all these files, the .power field was never correctly initialized.

Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-29 16:22:30 -07:00
Ricardo Neri e92a5b28f7 OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
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>
2012-05-22 11:00:09 +03:00
Archit Taneja c808ab9c82 OMAPDSS: Apply VENC timings even if panel is disabled
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>
2012-05-22 11:00:08 +03:00
Archit Taneja 2aefad49d8 OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
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>
2012-05-22 11:00:01 +03:00
Chandrabhanu Mahapatra 65e006ff4b OMAPDSS: DISPC: Support rotation through TILER
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>
2012-05-22 10:59:15 +03:00
Tomi Valkeinen 3cb6a1b967 OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
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>
2012-05-22 10:59:15 +03:00
Tomi Valkeinen 4a75cb857d OMAPFB: remove compiler warnings when CONFIG_BUG=n
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>
2012-05-22 10:59:15 +03:00
Tomi Valkeinen c6eee968d4 OMAPDSS: remove compiler warnings when CONFIG_BUG=n
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>
2012-05-22 10:59:14 +03:00
Tomi Valkeinen 36377357db OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
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>
2012-05-22 10:59:14 +03:00
Tomi Valkeinen 3568f2a46f OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
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>
2012-05-22 10:59:13 +03:00
Archit Taneja 6f28c2964b OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
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>
2012-05-21 12:21:18 +03:00
Chandrabhanu Mahapatra 05dd0f5308 OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
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>
2012-05-15 13:51:56 +03:00
Ricardo Neri f3a97491f2 OMAPDSS: HDMI: Implement DSS driver interface for audio
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>
2012-05-11 15:17:10 +03:00
Ricardo Neri b7dea05aec OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutex
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>
2012-05-11 15:17:09 +03:00
Ricardo Neri 24ccfc5541 OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order
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>
2012-05-11 15:17:09 +03:00
Ricardo Neri 6ec355d6c7 OMAPDSS: HDMI: Add an audio configuration function
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>
2012-05-11 15:17:08 +03:00
Ricardo Neri 25a653597e OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation
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>
2012-05-11 15:17:08 +03:00
Ricardo Neri 35547626f3 OMAPDSS: HDMI: Relocate N/CTS calculation
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>
2012-05-11 15:17:06 +03:00
Ricardo Neri c1164ed87e OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio
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>
2012-05-11 15:15:23 +03:00
Ricardo Neri 7e151f7f6a OMAPDSS: HDMI: Decouple HDMI audio from ASoC
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>
2012-05-11 15:15:22 +03:00
Axel Castaneda Gonzalez 3df9fb5c51 OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop
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>
2012-05-11 15:15:22 +03:00
Ricardo Neri 7c92af1678 OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings
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>
2012-05-11 15:15:21 +03:00
Ricardo Neri 199e7fd621 OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums
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>
2012-05-11 15:15:21 +03:00
Ricardo Neri 7c3291f06b OMAPDSS: HDMI: Remove ASoC codec
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>
2012-05-11 15:15:18 +03:00
Ricardo Neri c0456be38f OMAPDSS: HDMI: Split video_enable into video_enable/disable
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>
2012-05-11 15:13:51 +03:00