- 26 10月, 2012 1 次提交
-
-
由 Wei Yongjun 提交于
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>
-
- 26 9月, 2012 2 次提交
-
-
由 Archit Taneja 提交于
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>
-
由 Archit Taneja 提交于
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>
-
- 18 9月, 2012 4 次提交
-
-
由 Tomi Valkeinen 提交于
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>
-
由 Tomi Valkeinen 提交于
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>
-
由 Tomi Valkeinen 提交于
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>
-
由 Tomi Valkeinen 提交于
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>
-
- 08 9月, 2012 4 次提交
-
-
由 Tomi Valkeinen 提交于
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>
-
由 Tomi Valkeinen 提交于
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>
-
由 Tomi Valkeinen 提交于
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>
-
由 Tomi Valkeinen 提交于
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>
-
- 15 8月, 2012 2 次提交
-
-
由 Archit Taneja 提交于
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>
-
由 Archit Taneja 提交于
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>
-
- 10 8月, 2012 1 次提交
-
-
由 Ricardo Neri 提交于
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>
-
- 08 7月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
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>
-
- 29 6月, 2012 4 次提交
-
-
由 Archit Taneja 提交于
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>
-
由 Jassi Brar 提交于
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>
-
由 Tomi Valkeinen 提交于
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>
-
由 Rajendra Nayak 提交于
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>
-
- 11 5月, 2012 15 次提交
-
-
由 Ricardo Neri 提交于
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>
-
由 Ricardo Neri 提交于
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>
-
由 Ricardo Neri 提交于
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>
-
由 Ricardo Neri 提交于
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: NRicardo Neri <ricardo.neri@ti.com>
-
由 Ricardo Neri 提交于
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: NRicardo Neri <ricardo.neri@ti.com>
-
由 Ricardo Neri 提交于
To improve readability, split the audio_enable HDMI IP operation into two separate functions for enabling and disabling audio. The audio_enable function is also modified to return an error value. While there, update these operations for the OMAP4 IP accordingly. Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
-
由 Tomi Valkeinen 提交于
Move the platform-data based display device initialization into a separate function, so that we may later add of-based initialization. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Now that each output driver creates their own display devices, the output drivers can also initialize those devices. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Currently the higher level omapdss platform driver gets the list of displays in its platform data, and uses that list to create the omap_dss_device for each display. With DT, the logical way to do the above is to list the displays under each individual output, i.e. we'd have "dpi" node, under which we would have the display that uses DPI. In other words, each output driver handles the displays that use that particular output. To make the current code ready for DT, this patch modifies the output drivers so that each of them creates the display devices which use that output. However, instead of changing the platform data to suit this method, each output driver is passed the full list of displays, and the drivers pick the displays that are meant for them. This allows us to keep the old platform data, and thus we avoid the need to change the board files. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Now that the core.c doesn't fail if output driver's init fails, we can change the uses of platform_driver_register to platform_driver_probe. This will allow us to use __init in the following patches. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Instead of having an ugly #ifdef mess in the core.c for creating debugfs files, add a dss_debugfs_create_file() function that the dss drivers can use to create the debugfs files. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Now that the omapdss_core device is the parent for all other dss devices, we don't need to use the dss_runtime_get/put anymore. Instead, enabling omapdss_core will happen automatically when a child device is enabled. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
For unknown reasons we seem to have a return in each of the omapdss's uninit functions, which is a void function. Remove the returns. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
The omapdss pdata handling is a mess. This is more evident when trying to use device tree for DSS, as we don't have platform data anymore in that case. This patch cleans the pdata handling by: - Remove struct omap_display_platform_data. It was used just as a wrapper for struct omap_dss_board_info. - Pass the platform data only to omapdss device. The drivers for omap dss hwmods do not need the platform data. This should also work better for DT, as we can create omapdss device programmatically in generic omap boot code, and thus we can pass the pdata to it. - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads that the dss hwmod drivers can call. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 09 5月, 2012 2 次提交
-
-
由 Archit Taneja 提交于
The DPI and HDMI interfaces use their 'set_timing' functions to take in a new set of timings. If the panel is disabled, they do not disable and re-enable the interface. Currently, the manager timings are applied in hdmi_power_on() and dpi_set_mode() respectively, these are not called by set_timings if the panel is disabled. When checking overlay and manager data, the DSS driver uses the last applied manager timings, and not the timings held by omap_dss_device struct. Hence, there is a need to apply the new manager timings even if the panel is disabled. Apply the manager timings if the panel is disabled. Eventually, there should be one common place where the timings are applied independent of the state of the panel. Signed-off-by: NArchit Taneja <archit@ti.com>
-
由 Archit Taneja 提交于
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the interface drivers. The latter function ensures that the timing related DISPC registers are configured according to the shadow register programming model. Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit is set by dss_mgr_set_timings(). Signed-off-by: NArchit Taneja <archit@ti.com>
-
- 23 4月, 2012 1 次提交
-
-
由 Archit Taneja 提交于
Currently, a LCD manager's timings is set by dispc_mgr_set_lcd_timings() and TV manager's timings is set by dispc_set_digit_size(). Use a common function called dispc_mgr_set_timings() which sets timings for both type of managers. We finally want the interface drivers to use an overlay manager function to configure it's timings, having a common DISPC function would make things cleaner. For LCD managers, dispc_mgr_set_timings() sets LCD size and blanking values, for TV manager, it sets only the TV size since blanking values don't exist for TV. Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 06 3月, 2012 1 次提交
-
-
由 Mythri P K 提交于
While calculating regm and regmf value add using M2 divider in the equation. Formula for calculating: Output clock on digital core domain: CLKOUT = (M / (N+1))*CLKINP*(1/M2) Internal oscillator output clock on internal LDO domain: CLKDCOLDO = (M / (N+1))*CLKINP The current code when allows variable M2 values as input ignores using M2 divider values in calculation of regm and regmf. so fix it by using M2 in calculation although the default value for M2 is 1. Signed-off-by: NMythri P K <mythripk@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 23 2月, 2012 1 次提交
-
-
由 Archit Taneja 提交于
For DSS clock domain to transition from idle to active state. It's necessary to enable the optional clock DSS_FCLK before we enable the module using the MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register. This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led to DSS clock domain not getting out of idle when pm_runtime_get_sync() was called for hdmi's platform device. Since the clock domain failed to change it's state to active, the hwmod code disables any clocks it had enabled before for this hwmod. This led to the clock 'dss_48mhz_clk' gettind disabled. When hdmi's runtime_resume() op is called, the call to dss_runtime_get() correctly enables the DSS clock domain this time. However, the clock 'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was disabled previously, the driver fails when it tries to enable HDMI's PHY. Fix this for now by ensuring that dss_runtime_get() is called before we call pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would be to modify the DSS related hwmod's mainclks, and also some changes in how opt clocks are handled in the DSS driver. This fixes the issue of HDMI not working when it's the default display. The issue is not seen if any other display is already enabled as the first display would have correctly enabled the DSS clockdomain. Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 21 2月, 2012 1 次提交
-
-
由 Ricardo Neri 提交于
The MCLK mode defines a factor to divide the clock that is used to generate the Audio Clock Regeneration packets, MCLK. The divisor is not used when the CTS value is calculated by HW. When the value is calculated by SW, it depends on the silicon revision. Signed-off-by: NRicardo Neri <ricardo.neri@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-