- Dec 01, 2014
-
-
Jyri Sarha authored
Implements callbacks for OMAP HDMI audio platform driver and registers it in probe function. Unregistering is done in remove function. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Reviewed-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Jyri Sarha authored
Removes the OMAP4 HDMI audio callbacks for the old external DAI driver. Signed-off-by:
-
Jyri Sarha authored
Make hdmi_mode_has_audio() more user friedly by taking hdmi_config as parameter. Signed-off-by:
-
Jyri Sarha authored
The booleans are not used anymore. Just select SND_OMAP_SOC_HDMI_AUDIO to enable OMAP HDMI audio support. Signed-off-by:
-
Jyri Sarha authored
The platform device should only be registered from OMAPDSS HDMI driver. The platform driver registers and unregisters all ASoC components needed for OMAP HDMI audio. The hdmi audio driver implements cpu-dai component using the callbacks provided by OMAPDSS and registers the component under DSS HDMI device. Omap-pcm is registered for platform component also under DSS HDMI device. Dummy codec is used as as codec component. The hdmi audio driver implements also the card and registers it under its own platform device. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by:
-
- Nov 26, 2014
-
-
Jyri Sarha authored
Adds display_enabled flag and audio_abort_cb callback to struct hdmi. Signed-off-by:
-
Jyri Sarha authored
This is used to store omap-hdmi-audio pdev for unregistering it. Signed-off-by:
-
Jyri Sarha authored
Unify the private anonymous struct in hdmi4.c and hdmi5.c, name it as struct omap_hdmi, and make it public in hdmi.h. Signed-off-by:
-
Jyri Sarha authored
The audio dma port is found in the hdmi_wp physical address space. Signed-off-by:
-
Jyri Sarha authored
hdmi4_audio_get_dma_port() is unused and and broken. Signed-off-by:
-
Jyri Sarha authored
It does not waste too many bytes to compile all audio related core functions always in with HDMI support. It should help readability and in keeping the audio code in working shape. Leave the options just for disabling and enabling the functionality in hdmi[45].c. Signed-off-by:
-
Jyri Sarha authored
The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in hdmi_core_audio_layout enum. I found the correct value from ti-linux 3.8 tree. Signed-off-by:
-
Jyri Sarha authored
The hdmi_wp_audio_config_format() expects sample_order of struct hdmi_audio_format to be initialized. The only allowed value is HDMI_AUDIO_SAMPLE_LEFT_FIRST. Signed-off-by:
-
Jyri Sarha authored
Only OMAP4 DSS has non reserved bits above 6th bit in HDMI_WP_AUDIO_CFG. Signed-off-by:
-
- Nov 12, 2014
-
-
Tomi Valkeinen authored
Now that the DSS has the common DSS PLL, we no longer use the DSI PLL feature flags from dss_features.c. Remove all the unused feature flags. Signed-off-by: -
Tomi Valkeinen authored
Now that we have the common DSS PLL support, change HDMI to use it. This results in quite a lot of changes, but almost all of them are trivial name changes. The function to program the PLL settings can be removed from hdmi_pll.c, as the common PLL API contains the same functionality. Signed-off-by: -
Tomi Valkeinen authored
hdmi_pll_enable powers off the PLL as the first thing it does. Right after that, it enables the PLL powers. The initial power-off is pointless, so let's remove it. Signed-off-by: -
Tomi Valkeinen authored
At the moment we have one function, hdmi_pll_enable, which enables the PLL and writes the PLL configuration to registers. To make the HDMI PLL ahere to the DSS PLL API, split the hdmi_pll_enable into two parts: hdmi_pll_enable which enables the PLL HW, and hdmi_pll_set_config which writes the config. Signed-off-by: -
Tomi Valkeinen authored
HDMI PLL code needs the pointer to the WP block so that it can manage its power. Currently this is passed as a function parameter to hdmi_pll_enable and hdmi_pll_disable. To make the PLL function adhere to the DSS PLL API, we need to remove the WP parameter. This patch stores the WP pointer to hdmi_pll_data in hdmi_pll_init, so that it's available when needed. Signed-off-by: -
Tomi Valkeinen authored
The SYSRESET bits in HDMI PLL do not reset the PLL itself, but only affect the power used for the PLL. Afaik there is no reason to use the SYSRESET bits, and we don't use it in the other PLLs, so let's remove the HDMI PLL reset to make the PLL code simpler and similar to other PLLs. Signed-off-by: -
Tomi Valkeinen authored
The code calculating HDMI PLL parameters has always been very confusing. Now that we are implementing a common PLL library for the DSS, it's important that the PLL code is understandable. This patch rewrites the calculation code, and removes a few hacks that were used there. Signed-off-by: -
Tomi Valkeinen authored
We don't support interlace modes properly on OMAP5+ HDMI, so we need to reject interlace timings. Signed-off-by: -
Tomi Valkeinen authored
Only OMAP5+ has REFSEL field, but at the moment it's set also on OMAP4. Fix this by adding a "has_refsel" field, and setting the REFSEL based on that. Signed-off-by: -
Tomi Valkeinen authored
Now that we have the common DSS PLL support, change DSI to use it. This results in quite a lot of changes, but almost all of them are trivial name changes. The functions to calculate and program the PLL settings can be removed from dsi.c, as the common PLL API contains the same functionality. We also need to create struct dss_pll_hw entries for PLL hardware features for different OMAP platforms, instead of using the dss_features.c as the old code does. Signed-off-by: -
Tomi Valkeinen authored
OMAP DSS currently contains two different PLLs: DSI PLL (Type A PLL) and HDMI PLL (Type B PLL). When DRA7 support is added, we will also support Video PLLs (Type A). The driver currently handles all PLLs totally separately. This patch adds common DSS PLL code, which a) lets us have common code for the PLLs b) lets the users of the PLLs use a common API, instead of DSI API or HDMI API. Signed-off-by: -
Tomi Valkeinen authored
When DPI uses the DSI PLL for pixel clock, the DPI code will call dsi_runtime_get/put to keep the DSI block enabled. A much simpler way to handle this is to do dsi_runtime_get/put in DSI's dsi_pll_init() and dsi_pll_uninit(), thus removing the need for DSI to call the runtime PM functions. Signed-off-by: -
Tomi Valkeinen authored
The HSDIV outputs of DSI PLL (and also other PLLs) all have the same bit width for the divider value. Simplify the code by merging HSDIV divider widths into one width. Signed-off-by: -
Tomi Valkeinen authored
We are creating a common DSS PLL code, so having fixed DSI specific hsdiv fields in the clock information is not ok. This patch changes the hsdiv fields to arrays, so that we can use all the 4 possible hsdiv outputs (DSI only usees 2), and we have generic way to access the hsdivs. Signed-off-by: -
Tomi Valkeinen authored
We are creating a common DSS PLL code, so rename 'clkin4ddr' field, which is DSI specific name, to 'clkdco' which is a generic name. Signed-off-by: -
Tomi Valkeinen authored
Now that dsi_clock_info only contains information about the PLL, we can just copy the whole struct when storing the clock information, instead of copying individual fields. Signed-off-by: -
Tomi Valkeinen authored
We have pll_locked field in struct dsi_data, but it doesn't have any meaningful use anymore, and can be removed. Signed-off-by: -
Tomi Valkeinen authored
struct dsi_clock_info contains clkin field, which is the rate of the PLL's input clock. This field is not needed, as it can be easily retrieved by using the clk_get_rate(). This patch removes the clkin field. Signed-off-by: -
Tomi Valkeinen authored
struct dsi_clock_info represents the clocks handled by the DSI, mostly PLL related clocks. In an effort to create common PLL code, we need to remove all the non-PLL items from dsi_clock_info. This patch removes LP clock related fields from dsi_clock_info, and creates a new struct dsi_lp_clock_info for holding clock info for the LP clock. Signed-off-by: -
Tomi Valkeinen authored
The DSS PLL has support to power on the PLL's highspeed clock output and HSDIV output separately. In practice both need to powered on, as in most OMAP's that's the only working configuration. We already do that in dsi_pll_init(), by overriding the passed arguments so that both are always powered. Simplify the code by removing the support for choosing which outputs to power on. Signed-off-by: -
Tomi Valkeinen authored
With the previous patch "OMAPDSS: DSI: wait for hsdiv clocks when enabling PLL", dsi_wait_pll_hsdiv_dispc_active and dsi_wait_pll_hsdiv_dsi_active are no longer needed, so they and the callers can be removed. Signed-off-by: -
Tomi Valkeinen authored
At the moment we have two functions to wait for the HSDIV clocks to get active, dsi_wait_pll_hsdiv_dispc_active and dsi_wait_pll_hsdiv_dsi_active. Instead of such inconvenient functions, let's just make sure that the hsdiv clocks are active after the pll has been enabled. This patch adds code to dsi_pll_set_clock_div() to wait until HSDIV clocks are active. Signed-off-by: -
Archit Taneja authored
Add a 'port' parameter in dpi_select_source. The param tells the port number of the DPI instance that we want to configure. We use this number to select the overlay manager for that DPI instance. Signed-off-by:
Archit Taneja <archit@ti.com> Signed-off-by:
-
Archit Taneja authored
Register DPI outputs, and assign the port_num to them as specified by the 'reg' property in the DPI ports in DT. To support multiple DPI instances, dpi_get_channel needs to take the DPI instance's port number to get the corresponding channel. Make it take this argument. We just pass 0 in the non-DT path, since we don't support multiple instances in the non-DT case. Signed-off-by:
-
Archit Taneja authored
In omapdss_of_find_source_for_first_ep, we retrieve a source endpoint's DT node, and then see what omapdss output has the matching device_node pointer in omap_dss_find_output_by_node. For all DPI and SDI outputs, the device_node pointer is set as the parent's DSS device_node pointer. If the source is one of these outputs, the above method won't work. To get the correct output for ports within DSS(and in other cases in the future, where multiple ports might be under one device), we require additional information which is exclusive to the output port. We create a new field in omap_dss_device called 'port_num', this provides port number of the output port corresponding to this device. When searching for the source endpoint in DT, we extract the 'reg' property from the port corresponding to the endpoint source. From the list of registered outputs, we pick out that output which has both dev->of_node and port_num matching with the device_node pointer and 'reg' of the source endpoint node from DT. For encoder blocks(the ones which have both an input and output port), we need to set the port_num as the 'reg' property for the output port as defined in the DT bindings. We set port_num to 1 in the tfp410 and tpd12s015 encoder drivers. Signed-off-by:
-
Archit Taneja authored
The init/uninit port functions are used to set up the DPI and SDI outputs under the dss platform device. A 'reg' property is used to determine the port number of the output. This tells us whether the port is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, we only have DPI outputs under the dss platform device. For multiple DPI output instances(introduced in DRA7xx DSS), we will use the the port number to specify which DPI output instance is being inited. The current functions work fine if there is only one DPI output instance in DSS. For multiple DPI instances, it would get complicated to figure out whether port number was used to specify whether the output is SDI, or another DPI instance. We create a list of port types supported for each DSS rev, with the index of the port in the list specifying the port number of the output for that DSS revision. This allows us to have a more generic way to init/uninit ports within DSS, and also support multiple DPI ports. We make the uninit_port functions iterative since we will have multiple DPI ports to uninit in the future. Signed-off-by:
-
