We currently attach an output to a dssdev in the initialization code for
dssdevices in display.c. This works, but doesn't quite make sense: an
output entity represents (surprisingly) an output of DSS, which is
managed by an output driver. The output driver also handles adding new
dssdev's for that particular output.

It makes more sense to make the output-dssdev connection in the output
driver. This is also in line with common display framework.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This reverts commit 14840b9a.

The commit breaks audio, and a new version will be applied later.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Normally the omapdss driver gets the regulators using the regulator
names assigned for omapdss. However, in an effort to get a minimal DSS
support for DT enabled kernel on selected boards, we will add omapdss
devices and platform data the old way even for DT kernel. This causes
the problem that omapdss cannot find the regulators using omapdss's
regulator names.

This patch creates a temporary workaround for DSI and HDMI by trying to
get the regulators also using native OMAP4 regulator names.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This function is now used in the driver init path to handle
probe errors properly. Thus, it may be possible to use this function
outside the exit path.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Reported-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the design of drivers such
as MFD, in which a single entity handles the creation of the accessory
devices. Such devices are then used by domain-specific drivers; audio in
this case.

Also, this is in line with the DT implementation of HDMI, in which we will
have a single node to describe this feature of the OMAP SoC.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The display must be uninitialized in order to free the requested GPIOs.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Do not blindly assume that the panel could be initialized.

While there, group mutex initialization at a single place.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Using devm_request_and_ioremap provides better memory handling and
improves readability.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Minor cleanup to give to the resource variable a more proper name.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.

However, there is no safe way for the output drivers to handle dispc
clock, as it's shared between the outputs. Thus, if, say, the DSI driver
sets up DSI PLL and configures both the dispc and lcd clock sources to
that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.

Thus the output drivers should really only be concerned about the lcd
clock, which is what the output drivers actually use. There's lot to do
to clean up the dss clock handling, but this patch takes one step
forward and removes the use of dss_select_dispc_clk_source() from the
output drivers.

After this patch, the output drivers only configure the lcd source
clock. On omap4+ the dispc src clock is never changed from the default
PRCM source. On omap3, where the dispc and lcd clocks are actually the
same, setting the lcd clock source sets the dispc clock source.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The hdmi driver tries to find the given video timings from its static
list of timings, to find the required ID for the mode. The check tries
to find exact match for the pixel clock, among other checks.

with omapfb driver there can be some amount of error in the give pixel
clock, as the pixel clock is converted between Hz and ps, thus the
hdmi's check fails to find the mode.

This patch makes the check more allowing, by rounding the pixel clocks
to nearest MHz.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>

Add 1920x1200 video mode to hdmi driver's static modelist.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>

This patch makes use of the hdmi_power_[on|off]_core() functions added
in the previous patch. The functions are used when reading EDID or
detecting if a monitor is connected.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>

There's currently just one power-on function for HDMI, which enables the
IP and the video output. When reading EDID or detecting if a monitor is
connected, we don't need the video output.

Enabling the video output for these operations is not a big problem in
itself, but the quick enable/disable cycles caused by the operations
seem to cause sync lost errors from time to time. Also, this makes it
possible to read the EDID before the full video path has been set up.

This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
and hdmi_power_on_full. The "full" version does what hdmi_power_on does
currently, and hdmi_power_on_core only enables the core IP. Similar
changes are made for power_off.

Note that these don't allow the HDMI IP to be first enabled, and later
enable the video output, but the HDMI IP will first need to be powered
off before calling the full version. So this is rather limited
implementation, but it fills the needs for reading EDID.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ricardo Neri <ricardo.neri@ti.com>

Export dss_get_def_display_name() with the name of
omapdss_get_def_display_name() so that omapfb can use it after the next
patch which moves default display handling to omapfb.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add the missing unlock on the error handling path in function
hdmi_dump_regs().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The output drivers get the omapdss hw version from the platform data for
their respective output device. This doesn't work with DT, as there's no
platform data for them.

Add a new function, omapdss_get_version(), which returns the dss version
from the core device, which will have platform data on DT also. The
function is exported so that users of omapdss can also use it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add the missing unlock on the error handling path in function
hdmi_dump_regs().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use omapdss_version in hdmi.c to select the proper hdmi features.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NArchit Taneja <archit@ti.com>

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: NArchit Taneja <archit@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The hdmi interface driver exposes functions to the hdmi panel driver to
configure the interface timings maintained by the hdmi driver.

These timings(stored in hdmi.ip_data.cfg) should be protected by the hdmi lock
to ensure they are called sequentially, this is similar to how hdmi enable and
disable functions need locking.
Signed-off-by: NArchit Taneja <archit@ti.com>

The hdmi driver currently updates only the 'code' member of hdmi_config when
the op omapdss_hdmi_display_set_timing() is called by the hdmi panel driver.
The 'timing' field of hdmi_config is updated only when hdmi_power_on is called.
It makes more sense to configure the whole hdmi_config field in the set_timing
op called by the panel driver. This way, we don't need to call both functions
to ensure that our hdmi_config is configured correctly. Also, we don't need to
calculate hdmi_config during hdmi_power_on, or rely on the omap_video_timings
in the panel's omap_dss_device struct.

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

Small patch to disable the PLL appropriately before runtime_put in case
an error occurs while enabling the PHY.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
will always return 1 and pm_runtime_put_sync() will always return
-ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
print a warning.

One option would be to ignore errors returned by pm_runtime_put_sync()
totally, as they only say that the call was unable to put the hardware
into suspend mode.

However, I chose to ignore the returned -ENOSYS explicitly, and print a
warning for other errors, as I think we should get notified if the HW
failed to go to suspend properly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

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: NArchit Taneja <archit@ti.com>

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: NJassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
will always return 1 and pm_runtime_put_sync() will always return
-ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
print a warning.

One option would be to ignore errors returned by pm_runtime_put_sync()
totally, as they only say that the call was unable to put the hardware
into suspend mode.

However, I chose to ignore the returned -ENOSYS explicitly, and print a
warning for other errors, as I think we should get notified if the HW
failed to go to suspend properly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Grazvydas Ignotas <notasas@gmail.com>

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: NRajendra 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: NTomi Valkeinen <tomi.valkeinen@ti.com>

Implement the DSS device driver audio support interface in the HDMI
panel driver and generic driver. The implementation relies on the
IP-specific functions that are defined at DSS probe time.

A mixed locking strategy is used. The panel's mutex is used when
the state of the panel is queried as required by the audio functions.
The audio state is protected using a spinlock as users of DSS HDMI
audio functionality might start/stop audio while holding a spinlock.
The mutex and the spinlock are held and released as needed by each
individual function to protect the panel state and the audio state.

Although the panel's audio_start functions does not check whether
the panel is active, the audio _ENABLED state can be reached only
from audio_enable, which does check the state of the panel. Also,
if the panel is ever disabled, the audio state will transition
to _DISABLED. Transitions are always protected by the audio lock.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

Add support for more sample rates when calculating N and CTS. This
covers all the audio sample rates that an HDMI source is allowed
to transmit according to the HDMI 1.4a specification.

Also, reorganize the logic for the calculation when using deep color.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

The N and CTS parameters are relevant to all HDMI implementations and
not specific to a given IP. Hence, the calculation is relocated
into the generic HDMI driver.

Also, deep color is not queried but it is still considered in the
calculation of N. This is to be changed when deep color functionality is
implemented in the driver.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>