- 05 11月, 2012 3 次提交
-
-
由 Tomi Valkeinen 提交于
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>
-
由 Tomi Valkeinen 提交于
We don't currently set the dss fck when starting up. This is not a problem, as we setup the fck later when configuring the pixel clocks. Or this is how it was for omap2, for the rest of the omaps this may not be so. For DSI, HDMI and also for DPI when using DSI PLL, we don't need to change the dss fck, and thus it may be left unconfigured. Usually the dss fck is already setup fine by default, but we can't trust this. This patch sets the dss fck to maximum at probe time. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
dss_calc_clock_rates() was removed earlier as it was not used, but it is needed for DSI PLL calculations, so this patch adds it back. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 29 10月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
dss_generic_clk_source_names is missing the names for clocks from DSI2 PLL. Add them. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 24 10月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
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>
-
- 17 10月, 2012 2 次提交
-
-
由 Tomi Valkeinen 提交于
When compiling on x86, we get compilation errors for dss.c and dispc.c: drivers/video/omap2/dss/dispc.c:126:11: error: ‘SZ_4K’ undeclared here (not in a function) include <linux/sizes.h> to fix compilation. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
cpu_is_* calls are no longer used in omapdss, so the includes for <plat/cpu.h> can be removed. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 16 10月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
Use omapdss_version in dss.c to select the proper dss features. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 12 10月, 2012 1 次提交
-
-
由 Chandrabhanu Mahapatra 提交于
The config option CONFIG_OMAP2_DSS_DEBUG_SUPPORT has been removed and replaced with CONFIG_OMAP2_DSS_DEBUG and CONFIG_OMAP2_DSS_DEBUGFS. CONFIG_OMAP2_DSS_DEBUG enables DEBUG flag and CONFIG_OMAP2_DSS_DEBUGFS enables creation of debugfs for OMAPDSS. Both the config options are disabled by default and can be enabled independently of one another as per convenience. Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com> Reviewed-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 24 9月, 2012 3 次提交
-
-
由 Tomi Valkeinen 提交于
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: NTomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Anders <x0132446@ti.com>
-
由 Tomi Valkeinen 提交于
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: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Archit Taneja 提交于
Add basic omap5 features for dss and dispc. Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 08 9月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
Remove unnecessary includes from omapdss. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 22 8月, 2012 2 次提交
-
-
由 Chandrabhanu Mahapatra 提交于
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: NChandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Chandrabhanu Mahapatra 提交于
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: NChandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 16 8月, 2012 1 次提交
-
-
由 Archit Taneja 提交于
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: NArchit Taneja <archit@ti.com>
-
- 10 8月, 2012 1 次提交
-
-
由 Ricardo Neri 提交于
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: 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 3 次提交
-
-
由 Archit Taneja 提交于
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: NArchit Taneja <archit@ti.com>
-
由 Chandrabhanu Mahapatra 提交于
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: NChandrabhanu Mahapatra <cmahapatra@ti.com> 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>
-
- 04 6月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
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: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 22 5月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
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: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 11 5月, 2012 6 次提交
-
-
由 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 提交于
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 提交于
We currently have separate device/driver for each DSS HW module. The DPI and SDI outputs are more or less parts of the DSS or DISPC hardware modules, but in SW it makes sense to represent them as device/driver pairs similarly to all the other outputs. This also makes sense for device tree, as each node under dss will be a platform device, and handling DPI & SDI somehow differently than the rest would just make the code more complex. This patch modifies the dpi.c and sdi.c to create drivers for the platform devices. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
The platform devices for omapdss, dss and dispc drivers are always present, so we can use platform_driver_probe instead of platform_driver_register. 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>
-
- 09 5月, 2012 1 次提交
-
-
由 Archit Taneja 提交于
The wrong bit field was being updated in DSS_CTRL when trying to configure the clock source of DSI2 functional clock. Use the correct bit field based on the dsi module number. Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 23 4月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
Most of the DSS clocks have restrictions on their frequency based on the OPP in use. For example, maximum frequency for a clock may be 180MHz in OPP100, but 90MHz in OPP50. This means that when a high enough pixel clock or function clock is required, we need to use OPP100. However, there's currently no way in the PM framework to make that kind of request. The closest we get is to ask for very high bus throughput from the PM framework, which should effectively force OPP100. This patch is a simple version for handling the problem. Instead of asking for OPP100 only when needed, this patch asks for OPP100 whenever DSS is active. This obviously is not an optimal solution for cases with small displays where OPP50 would work just fine. However, a proper solution is a complex one, and this patch is a short term solution for the problem. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Acked-by: NKevin Hilman <khilman@ti.com>
-
- 25 2月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
This is needed to minimize io.h so the SoC specific io.h for ARMs can removed. Note that minimal driver changes for DSS and RNG are needed to include cpu.h for SoC detection macros. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 21 2月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
Now that dss is using devm_ functions for allocation in probe functions, small reordering of the allocations allows us to clean up the probe functions more. This patch moves "unmanaged" allocations after the managed ones, and uses plain returns instead of gotos where possible. This lets us remove a bunch of goto labels, simplifying the probe's error handling. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 26 1月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
omapdss doesn't work properly on system suspend. The problem seems to be the fact that omapdss uses pm_runtime_put() functions when turning off the hardware, and when system suspend is in process only sync versions are allowed. Using non-sync versions normally and sync versions when suspending would need rather ugly hacks to convey the information of suspending/not-suspending to different functions. Optimally the driver wouldn't even need to care about this, and the PM layer would handle syncing when suspend is in process. This patch changes all omapdss's pm_runtime_put calls to pm_runtime_put_sync. This fixes the suspend problem, and probably the performance penalty of always using sync versions is negligible. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NKevin Hilman <khilman@ti.com>
-
- 25 1月, 2012 1 次提交
-
-
由 Julia Lawall 提交于
The various devm_ functions allocate memory that is released when a driver detaches. This patch uses these functions for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 01 11月, 2011 1 次提交
-
-
由 Paul Gortmaker 提交于
With module.h being implicitly everywhere via device.h, the absence of explicitly including something for EXPORT_SYMBOL went unnoticed. Since we are heading to fix things up and clean module.h from the device.h file, we need to explicitly include these files now. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 30 9月, 2011 1 次提交
-
-
由 Tomi Valkeinen 提交于
Add dss_get_hdmi_venc_clk_source(), which can be used to get the value programmed with dss_select_hdmi_venc_clk_source(). This can be used to find out if the digit output is going to VENC or HDMI. For OMAP2/3 dss_get_hdmi_venc_clk_source() always returns DSS_VENC_TV_CLK. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 20 9月, 2011 2 次提交
-
-
由 Tomi Valkeinen 提交于
Now that the HWMOD fmwk handles the fcks of DSS modules properly, the DSS driver no longer needs to explicitely enable/disable the fck. This patch removes the enables/disables of fck from dispc, dsi and dss. The clk_get(fck) is still needed there, as the modules need to know the frequency of the clock. For hdmi and venc this patch also removes the clk_get(fck), as they don't need the clock at all. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
This reverts commit 9ede365a. The hack is no longer needed, as the HWMOD data has been fixed. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 01 8月, 2011 1 次提交
-
-
由 Tomi Valkeinen 提交于
The HWMOD data for OMAP2 and 3 are currently not up to date regarding DSS (OMAP4 HWMOD data is fine). This patch makes the DSS driver to get the opt clocks needed for OMAP2/3 with the old clock names, thus allowing DSS driver to use runtime PM. The HWMOD databases should be fixes ASAP, and this patch can be reverted after that. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-