- 25 2月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
There's no need to have these defines in plat/io.h. Note that we now need to ifdef omap_read/write calls as they will be available for omap1 only. While at it, clean up the includes to group them like they typically are grouped. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 26 1月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
"hdmi_hpd" pin is muxed to INPUT and PULLUP, but the pin is not currently used, and in the future when it is used, the pin is used as a GPIO and is board specific, not an OMAP4 wide thing. So remove the muxing for now. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
- 05 1月, 2012 2 次提交
-
-
由 Mythri P K 提交于
Disables the internal pull resistor for SDA and SCL which are enabled by default, as there are external pull up's in 4460 and 4430 ES2.3 SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure. Signed-off-by: NRicardo Salveti de Araujo <ricardo.salveti@linaro.org> Signed-off-by: NMythri P K <mythripk@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Mythri P K 提交于
Move duplicate HDMI mux_init code from omap4 and panda board file to display file. Signed-off-by: NMythri P K <mythripk@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 07 12月, 2011 1 次提交
-
-
由 Tony Lindgren 提交于
ARM restart changes needed changes to common.h to make it local. This conflicted with v3.2-rc4 DSS related hwmod changes that git mergetool was not able to handle. Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 08 11月, 2011 2 次提交
-
-
由 Archit Taneja 提交于
Resetting DISPC when a DISPC output is enabled causes the DSS to go into an inconsistent state. Thus if the bootloader has enabled a display, the hwmod code cannot reset the DISPC module just like that, but the outputs need to be disabled first. Add function dispc_disable_outputs() which disables all active overlay manager and ensure all frame transfers are completed. Modify omap_dss_reset() to call this function and clear DSS_CONTROL, DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the DSS2 driver starts. This resolves the hang issue(caused by a L3 error during boot) seen on the beagle board C3, which has a factory bootloader that enables display. The issue is resolved with this patch. Thanks to Tomi and Sricharan for some additional testing. Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: NR, Sricharan <r.sricharan@ti.com> Signed-off-by: NArchit Taneja <archit@ti.com> [paul@pwsan.com: restructured code, removed omap_{read,write}l(), removed cpu_is_omap*() calls and converted to dev_attr] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Tomi Valkeinen 提交于
This patch adds a custom DSS reset function used on OMAPs from OMAP2 forward. The function doesn't actually do a reset, it only waits for the reset to complete. The reason for this is that on OMAP4 there is no possibility to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets all the other DSS modules also, thus breaking the HWMOD model where every DSS module is handled independently. This fixes the problem with DSS reset on OMAP4, caused by the fact that because there's no SW reset for dss_core on OMAP4, the HWMOD framework doesn't try to reset dss_core and thus the DSS clocks were never enabled at the same time. This causes causes the HWMOD reset to fail for dss_dispc and dss_rfbi. The common reset function will also allow us to fix another problem in the future: before doing a reset we need to disable DSS outputs, which are in some cases enabled by the bootloader, as otherwise DSS HW seems to get more or less stuck, requiring a power reset to recover. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> [paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o unconditionally to avoid an error when !CONFIG_OMAP2_DSS] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 01 11月, 2011 1 次提交
-
-
由 Paul Gortmaker 提交于
To fix things like this: arch/arm/mach-omap2/usb-tusb6010.c:58: error: implicit declaration of function 'memset' arch/arm/kernel/leds.c:40: error: implicit declaration of function 'strcspn' arch/arm/kernel/leds.c:40: warning: incompatible implicit declaration of built-in function 'strcspn' arch/arm/kernel/leds.c:45: error: implicit declaration of function 'strncmp' arch/arm/kernel/leds.c:55: error: implicit declaration of function 'strlen' arch/arm/kernel/leds.c:55: warning: incompatible implicit declaration of built-in function 'strlen' arch/arm/mach-omap2/clockdomain.c:52: error: implicit declaration of function 'strcmp' Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 05 10月, 2011 1 次提交
-
-
由 Benoit Cousson 提交于
Remove all these duplicated structures since a default one is now available. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 30 9月, 2011 3 次提交
-
-
由 Tomi Valkeinen 提交于
Implement dsi_mux_pads for OMAP4. On enable the function enables the DSI pins and disables pull down. On disable the function disables the pins and enables pull down. It is unclear from the TRM whether the pull down is active if the pins are disabled, so this implementation may leave the pins floating when the DSI device is disabled. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
dsi_mux_pads() needs to know about the DSI HW module and the DSI lanes used. Split the function into two, enable and disable, which take necessary arguments, and add empty implementations for both. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Currently, there are 2 differently named platform devices generated for the 2 DSS DSI modules. In order to use the same driver, the dsi devices should be 2 instances of the same platform device. Change the platform device names from "omapdss_dsi1" and "omapdss_dsi2" to omapdss_dsi", and set the device indices to 0 and 1. Signed-off-by: NArchit Taneja <archit@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 16 9月, 2011 1 次提交
-
-
由 Kevin Hilman 提交于
All of the device init and device driver interaction with omap_device is done using platform_device pointers. To make this more explicit, have omap_device return a platform_device pointer instead of an omap_device pointer. All current users of the omap_device pointer were only using it to get at the platform_device pointer or struct device pointer, so fixing all of the users was trivial. This also makes it more difficult for device init code to directly access members of struct omap_device, and allows for easier changing of omap_device internals. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 25 7月, 2011 4 次提交
-
-
由 Tomi Valkeinen 提交于
oh_core variable is no longer used, so it and its initialization can be removed. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
opt_clock_available() is no longer needed, so remove it. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Initialize get_context_loss_count in the DSS board data to omap_pm_get_dev_context_loss_count, so that omapdss driver can use it. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
The function to get device's context loss count has changed from omap_pm_get_last_off_on_transaction_id() to omap_pm_get_dev_context_loss_count() Change name of the function pointer in omapdss.h accordingly, and use the term "context loss count" instead of "context id" in the code. Restructure the context loss count functions to handle errors properly, and ensure that context is always considered lost if an error happens. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 11 5月, 2011 2 次提交
-
-
由 Archit Taneja 提交于
Currently, omap_display_init() maintains arrays for hwmod name(oh_name) and the correspnding platform_device name(dev_name) needed by omap_device_build(). A variable oh_count keeps a track of the number of devices to build from oh_name based on what omap revision it is. Clean this up by maintaining an array of omap_dss_hwmod_data struct which is defined for each omap revision as suggested by Tomi Valkeinen. Assign the corresponding omap_dss_hwmod_data array struct to the pointer curr_dss_hwmod in omap_display_init(). Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
arch/arm/plat-omap/include/plat/display.h is an include for the OMAP DSS driver. A more logical place for it is in include/video. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 11 3月, 2011 3 次提交
-
-
由 Semwal, Sumit 提交于
Provide a function in pdata to allow dss submodules to check if a given clock is available on a platform as an optional clock. Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com> (based on implementation from Senthil) Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Mayuresh Janorkar 提交于
Add hwmod device names for OMAP4; this enables device build for omap4 dss hwmod IPs. Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NMayuresh Janorkar <mayur@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Senthilvadivu Guruswamy 提交于
Looks up the hwmod database for each of the given DSS HW IP and builds omap_device which inturn does the platform device register for each of DSS HW IP Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 23 2月, 2011 1 次提交
-
-
由 Sumit Semwal 提交于
A new file display.c is introduced for display driver init, which adds a function omap_display_init to do the DSS driver registration. This is the first step in moving away registration of DSS from board files into a common place. Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-