aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video/fbdev/omap2/dss
Commit message (Collapse)AuthorAge
...
* | | OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameterJyri Sarha2014-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format()Jyri Sarha2014-11-26
| | | | | | | | | | | | | | | | | | | | | Only OMAP4 DSS has non reserved bits above 6th bit in HDMI_WP_AUDIO_CFG. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: features: remove unused DSI PLL featuresTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: HDMI: use common DSS PLL supportTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: HDMI: remove extra poweroffTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: HDMI: split PLL enable & configTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: HDMI: store WP pointer to hdmi_pll_dataTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: HDMI: Remove HDMI PLL resetTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: HDMI: rewrite HDMI PLL calculation codeTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: HDMI5: disable interlace modesTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | We don't support interlace modes properly on OMAP5+ HDMI, so we need to reject interlace timings. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: HDMI: fix setting REFSELTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: use common DSS PLL supportTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: Add common PLL codeTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: dsi_runtime_get/put in pll_initTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: features: combine dsi & dispc hsdivsTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: turn hsdivs fields to arraysTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: rename clkin4ddr to clkdcoTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: use struct copy instead of individual field copyTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: remove pll_locked fieldTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: remove clkin from dsi_clock_infoTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: separate LP clock info from dsi_clock_infoTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: always power on hsclk & hsdivTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: remove unused hsdiv wait funcsTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSI: wait for hsdiv clocks when enabling PLLTomi Valkeinen2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSS: add a param to dpi_select_source which specifies it's port numberArchit Taneja2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: DPI: Add support for multiple instancesArchit Taneja2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: DT: Get source endpoint by matching reg-idArchit Taneja2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: DSS: init dss ports cleanlyArchit Taneja2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: DPI: Store dpi_data pointer in the DT port's dataArchit Taneja2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DPI and SDI ports are backed by only one parent DSS device. We don't have a corresponding platform_device for ports under DSS. In order to support multiple instances of DPI, we need to pass the driver data pointer through the DPI port's private data ('data' member in device_node struct). dpi_init_output/dpi_uninit_output are untouched and only used for non-DT case, these are called when the DPI platform device probed/removed. These funcs will be removed when non-DT mode is removed. dpi_init_output_port/dpi_uninit_output_port are created and used for the DT path, called when DSS inits/uninits it's ports. These new functions retrieve the dpi_data pointer from 'port->data', and not from the platform device's data(pdev->dev) like in the non-DT path. We add some code in dss_uninit_ports() to pass a pointer to the DPI port in dpi_uninit_port(). Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: DPI: Allocate driver dataArchit Taneja2014-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allocate driver data(dpi_data) for each DPI instance. It's allocated in omap_dpi_probe() when DT isn't used, and in dpi_init_port() when DT is used. The dpi_data struct instance is no longer global. In the case of DPI ops, it's retrieved from dpi_get_data_from_dssdev(). 'dssdev' passed by the connected encoder/panel driver is a pointer to the 'output' member in dpi_data, and thus can be used to get the DPI instance's driver data. In the case of probe/ini_port functions, it's set as DPI/DSS device's private data embedded in the platform_device struct. Having dpi_data as private data of the platform device will not work for multiple DPI instances in the DT case. This is because there is no corresponding platform_device for DPI or SDI, they exist only as ports under the parent DSS platform_device in the DT case. The DPI port's private data('data' member in device_node struct) will later be used to store dpi_data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | OMAPDSS: DPI: Use DPI driver dataArchit Taneja2014-11-12
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | DPI related data is currently a static global struct parameter. It is accessed directly by functions in the driver. This method won't work if we want the driver to support multiple DPI instances. Create struct dpi_data, and pass its pointer to functions which need to use it. We still have a static instance defined for dpi_data, which is accessed by top level DPI ops. This will be removed when the driver dynamically allocates dpi_data for each DPI instance. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DSI: Fix PLL_SELFEQDCO field widthTomi Valkeinen2014-10-22
| | | | | | | | | | | | | | | | PLL_SELFREQDCO bitfield is from bit 3 to 1, but the driver writes bits from 4 to 1. The bit 4 is 'reserved', so this probably should not cause any issues, but it's better to fix it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: fix dispc register dump for preload & mflagTomi Valkeinen2014-10-22
| | | | | | | | | | | | | | | | | | Preload register is dumped twice for video overlays and mflag register is not dumped for GFX. Fix the register dump. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DISPC: fix mflag offsetTomi Valkeinen2014-10-22
| | | | | | | | | | | | The register offset for DISPC_OVL_MFLAG_THRESHOLD is wrong, fix it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: fix regsd writeTomi Valkeinen2014-10-22
| | | | | | | | | | | | | | | | HDMI PLL's REGSD field is only set by the driver if the PLL's output clock is over 1GHz. This is clearly an error, as REGSD should be set always. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: fix PLL GO bit handlingTomi Valkeinen2014-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PLL settings are committed by setting GO bit, which is then cleared by the HW when the settings have been taken into use. The current PLL code handles this wrong: instead of waiting for the bit to be cleared, it waits for the bit to be set. Usually, the bit is always set, as the CPU has just set it before. However, if the CPU takes enough time between setting the GO bit and checking it, the HW may already have cleared the bit and this leads to timeout error. Fix the wait to check the bit properly. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: apply: wait pending updates on manager disableTomi Valkeinen2014-10-22
| | | | | | | | | | | | | | | | We should wait for any pending updates when an overlay manager is about to be disabled, because the updates will never be finished if the manager is disabled too early. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: set suppress_bind_attrsTomi Valkeinen2014-10-22
|/ | | | | | | | | | | omapdss drivers cannot handle devices being unbound while the devices are part of a connected display pipeline. Module refcounts are used to prevent unloading the modules, but one can still manually unbind the devices via sysfs, causing crash. Set suppress_bind_attrs to disable the bind/unbind support via sysfs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* arm, fbdev, omap2, LLVMLinux: Remove nested function from omap2 dssBehan Webster2014-09-30
| | | | | | | | | | | | | | | | Replace the use of nested functions where a normal function will suffice. Nested functions are not liked by upstream kernel developers in general. Their use breaks the use of clang as a compiler, and doesn't make the code any better. This code now works for both gcc and clang. Signed-off-by: Behan Webster <behanw@converseincode.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> Cc: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: use c99 initializers in structuresJulia Lawall2014-08-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use c99 initializers for structures. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @decl@ identifier i1,fld; type T; field list[n] fs; @@ struct i1 { fs T fld; ...}; @bad@ identifier decl.i1,i2; expression e; initializer list[decl.n] is; @@ struct i1 i2 = { is, + .fld = e - e ,...}; // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge tag 'fbdev-3.17' of ↵Linus Torvalds2014-08-08
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux Pull fbdev updates from Tomi Valkeinen: - much better HDMI infoframe support for OMAP - Cirrus Logic CLPS711X framebuffer driver - DT support for PL11x CLCD driver - various small fixes * tag 'fbdev-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (35 commits) OMAPDSS: DSI: fix depopulating dsi peripherals video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic video: ARM CLCD: Fix DT-related build problems drivers: video: fbdev: atmel_lcdfb.c: Add ability to inverted backlight PWM. video: ARM CLCD: Add DT support drm/omap: Add infoframe & dvi/hdmi mode support OMAPDSS: HDMI: remove the unused code OMAPDSS: HDMI5: add support to set infoframe & HDMI mode OMAPDSS: HDMI4: add support to set infoframe & HDMI mode OMAPDSS: HDMI: add infoframe and hdmi_dvi_mode fields OMAPDSS: add hdmi ops to hdmi-connector and tpd12s015 OMAPDSS: add hdmi ops to hdmi_ops and omap_dss_driver OMAPDSS: HDMI: remove custom avi infoframe OMAPDSS: HDMI5: use common AVI infoframe support OMAPDSS: HDMI4: use common AVI infoframe support OMAPDSS: Kconfig: select HDMI OMAPDSS: HDMI: fix name conflict OMAPDSS: DISPC: clean up dispc_mgr_timings_ok OMAPDSS: DISPC: reject interlace for lcd out OMAPDSS: DISPC: fix debugfs reg dump ...
| * OMAPDSS: DSI: fix depopulating dsi peripheralsTomi Valkeinen2014-08-08
| | | | | | | | | | | | | | | | | | | | After v3.16-rc1, devices populated with of_platform_populate() should be depopulated using of_platform_depopulate(). Failure to do so prevents the devices from being populated again (e.g. when loading a module). This patch fixes the problem for the OMAP DSI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI: remove the unused codeTomi Valkeinen2014-07-04
| | | | | | | | | | | | | | | | We no longer need the horrible driver internal videmode tables, which were used to decide if a given videomode is a HDMI or DVI mode. So remove all related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI5: add support to set infoframe & HDMI modeTomi Valkeinen2014-07-04
| | | | | | | | | | | | | | | | Instead of using hardcoded AVI infoframe, and a custom HDMI/DVI mode selection based in internal videomode tables, add support to set the infoframe and HDMI/DVI mode. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI4: add support to set infoframe & HDMI modeTomi Valkeinen2014-07-04
| | | | | | | | | | | | | | | | Instead of using hardcoded AVI infoframe, and a custom HDMI/DVI mode selection based in internal videomode tables, add support to set the infoframe and HDMI/DVI mode. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI: add infoframe and hdmi_dvi_mode fieldsTomi Valkeinen2014-07-04
| | | | | | | | | | | | | | Add infoframe and hdmi_dvi_mode fields to 'struct hdmi_config' which will be used in the following patches for OMAP4 and OMAP5 HDMI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI: remove custom avi infoframeTomi Valkeinen2014-07-04
| | | | | | | | | | | | | | We now use the common AVI infoframe support, so the OMAP specific AVI infoframe code can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI5: use common AVI infoframe supportTomi Valkeinen2014-07-04
| | | | | | | | | | | | | | Instead of using OMAP specific AVI infoframe structs, use the common one from include/linux/hdmi.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI4: use common AVI infoframe supportTomi Valkeinen2014-07-04
| | | | | | | | | | | | | | Instead of using OMAP specific AVI infoframe structs, use the common one from include/linux/hdmi.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: Kconfig: select HDMITomi Valkeinen2014-07-04
| | | | | | | | | | | | Select HDMI support to be able to use HDMI infoframe helpers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-04-15 17:56:44 -0400