- 10 7月, 2011 10 次提交
-
-
由 Avinash.H.M 提交于
The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a special sequence to reset the module. The sequence is - Disable the I2C. - Write to SOFTRESET bit. - Enable the I2C. - Poll on the RESETDONE bit. The sequence is implemented as a function and the i2c_class is updated with the correct 'reset' pointer. omap_hwmod_softreset function is implemented which triggers the softreset by writing into sysconfig register. On following this sequence, i2c module resets properly and timeouts are not seen. Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: NAvinash.H.M <avinashhm@ti.com> [paul@pwsan.com: combined this patch with a patch to remove HWMOD_INIT_NO_RESET from the 44xx hwmod flags; change register offset conditional code to use the IP block revision; minor code cleanup] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Andy Green 提交于
This adds the new functionality flags for omap i2c unit to all OMAP2 hwmod definitions Cc: patches@linaro.org Cc: Ben Dooks <ben-linux@fluff.org> Reported-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NAndy Green <andy.green@linaro.org> Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Andy Green 提交于
Since we cannot trust (or even reliably find) the OMAP I2C peripheral unit's own revision register, we must inform the OMAP i2c driver of which IP version it is running on. We do this by tagging the omap_hwmod_class for i2c on all the OMAP2+ platform / cpu specific hwmod init and passing it up to the driver (next patches). Cc: patches@linaro.org Cc: Ben Dooks <ben-linux@fluff.org> Reported-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NAndy Green <andy.green@linaro.org> Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
To reduce kernel source file data duplication, share struct omap_hwmod_class and omap_hwmod_class_sysconfig arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
To reduce kernel source file data duplication, share struct omap_hwmod_dma_info arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
Previously, struct omap_hwmod_dma_info arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_dma_info arrays and uses a sentinel value (irq == -1) as the array terminator instead. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
To reduce kernel source file data duplication, share struct omap_hwmod_mpu_irqs arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
Previously, struct omap_hwmod_mpu_irqs arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_mpu_irqs arrays and uses a sentinel value (irq == -1) as the array terminator instead. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
To reduce kernel source file data duplication, share struct omap_hwmod_addr_space arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
Previously, struct omap_hwmod_addr_space arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_addr_space arrays and uses a null structure member as the array terminator instead. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 21 4月, 2011 1 次提交
-
-
由 Avinash.H.M 提交于
GPIO module expects the debounce clocks to be enabled during reset. It doesn't reset properly and timeouts are seen, if this clock isn't enabled during reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with which the debounce clocks are enabled during reset. Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: NAvinash.H.M <avinashhm@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 20 4月, 2011 1 次提交
-
-
由 Benoit Cousson 提交于
OMAP2420, 2430 and 3xxx were using the OMAP4 end address that unfortunately is not located at the same base address. Moreover the OMAP4 size was set to 256 instead of 4096. Change all .pa_end to set them to .pa_start + 0xfff Cc: "G, Manjunath Kondaiah" <manjugk@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Reported-by: NMichael Fillinger <m-fillinger@ti.com> Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 11 3月, 2011 1 次提交
-
-
由 archit taneja 提交于
Currently, the core DSS platform device requests for an irq line for OMAP2 and OMAP3. Make DISPC and DSI platform devices request for a shared IRQ line. On OMAP3, the logical OR of DSI and DISPC interrupt lines goes to the MPU. There is a register DSS_IRQSTATUS which tells if the interrupt came from DISPC or DSI. On OMAP2, there is no DSI, only DISPC interrupts goto the MPU. There is no DSS_IRQSTATUS register. Hence, it makes more sense to have separate irq handlers corresponding to the DSS sub modules instead of having a common handler. Since on OMAP3 the logical OR of the lines goes to MPU, the irq line is shared among the IRQ handlers. The hwmod irq info has been removed for DSS to DISPC and DSI for OMAP2 and OMAP3 hwmod databases. The Probes of DISPC and DSI now request for irq handlers. Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 10 3月, 2011 2 次提交
-
-
由 Avinash.H.M 提交于
Some of the omap2, omap3 peripherals support software reset. This can be done through the softreset bit in sysconfig register. The reset status can be checked through resetdone bit of sysstatus register. syss_has_reset_status is added to the hwmod database of peripherals which have resetdone bit in sysstatus register. Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Reviewed-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NAvinash.H.M <avinashhm@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
According to the hwmod interface data, the DSS submodule "VENC" uses a clock, "dss_54m_fck"/"dss_tv_fck", which the PRCM cannot autoidle. By default, the hwmod code assumes that interface clocks can be autoidled by the PRCM. When the interface clock can't be autoidled by the PRCM, those interfaces must be marked with the OCPIF_SWSUP_IDLE flag. Otherwise, the "interface clock" will always have a non-zero use count, and the device won't enter idle. This problem was observed on N8x0. Fix the immediate problem by marking the VENC interface with the OCPIF_SWSUP_IDLE flag. But it's not clear that "dss_54m_fck"/"dss_tv_fck" is really the correct interface clock for VENC. It may be that the VENC interface should use a hardware-autoidling interface clock. This is the situation on OMAP4, which uses "l3_div_ck" as the VENC interface clock, which can be autoidled by the PRCM. Clarification from TI is needed. Problem found and patch tested on N8x0 by Tony Lindgren <tony@atomide.com>. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Senthilvadivu Guruswamy <svadivu@ti.com> Cc: Sumit Semwal <sumit.semwal@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 01 3月, 2011 1 次提交
-
-
由 Paul Walmsley 提交于
Rename omap_hwmod_init() to omap_hwmod_register(). Rename omap_hwmod_late_init() to omap_hwmod_setup_all(). Also change all of the callers to reflect the new names. While here, update some copyrights. Suggested by Tony Lindgren <tony@atomide.com>. N.B. The comment in mach-omap2/serial.c may no longer be correct, given recent changes in init order. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
- 28 2月, 2011 1 次提交
-
-
由 Thara Gopinath 提交于
Add dmtimer data. Signed-off-by: NThara Gopinath <thara@ti.com> Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: NBenoit Cousson <b-cousson@ti.com>
-
- 25 2月, 2011 2 次提交
-
-
由 Charulatha V 提交于
Add McBSP hwmod data for OMAP2420. Also add macros in prcm-common.h for idlest bit of OMAP24XX McBSP devices Signed-off-by: NCharulatha V <charu@ti.com> Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Omar Ramirez Luna 提交于
Mailbox hwmod data for omap2430 and 2420. Signed-off-by: NOmar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 23 2月, 2011 1 次提交
-
-
由 Senthilvadivu Guruswamy 提交于
Hwmod needs database of all IPs in a system. This patch generates the hwmod database for OMAP2420 Display Sub System,. Since DSS is also considered as an IP as DISPC, RFBI, name it as dss_core. Acked-by: NBenoit Cousson <b-cousson@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 18 2月, 2011 1 次提交
-
-
由 Charulatha V 提交于
Update the omap2420 hwmod data with the McSPI info. Add a device attribute structure which will be used for passing number of chipselects from hwmod data. Add revision macros to be passed from rev field from hwmod. Signed-off-by: NCharulatha V <charu@ti.com> Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: NGrant Likely <grant.likely@secretlab.ca> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 22 12月, 2010 1 次提交
-
-
由 Paul Walmsley 提交于
The OMAP watchdog timer IP blocks require a specific set of register writes to occur before they will be disabled[1], even if the device clocks appear to be disabled in the CM_*CLKEN registers. In the MPU watchdog case, failure to execute this reset sequence will eventually cause the watchdog to reset the OMAP unexpectedly. Previously, the code to disable this watchdog was manually called from mach-omap2/devices.c during device initialization. This causes the watchdog to be unconditionally disabled for a portion of kernel initialization. This should be controllable by the board-*.c files, since some system integrators will want full watchdog coverage of kernel initialization. Also, the watchdog disable code was not connected to the hwmod shutdown code. This means that calling omap_hwmod_shutdown() will not, in fact, disable the watchdog, and the goal of omap_hwmod_shutdown() is to be able to shutdown any on-chip OMAP device. To resolve the latter problem, populate the pre_shutdown pointer in the watchdog timer hwmod classes with a function that executes the watchdog shutdown sequence. This allows the hwmod code to fully disable the watchdog. Then, to allow some board files to support watchdog coverage throughout kernel initialization, add common code to mach-omap2/io.c to cause the MPU watchdog to be disabled on boot unless a board file specifically requests it to remain enabled. Board files can do this by changing the watchdog timer hwmod's postsetup state between the omap2_init_common_infrastructure() and omap2_init_common_devices() function calls. 1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. ZH [SWPU222H], Section 16.4.3.6, "Start/Stop Sequence for WDTs (Using WDTi.WSPR Register)" Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Charulatha Varadarajan <charu@ti.com>
-
- 21 12月, 2010 1 次提交
-
-
由 G, Manjunath Kondaiah 提交于
Add OMAP2420 DMA hwmod data and also add required DMA device attributes. Signed-off-by: NG, Manjunath Kondaiah <manjugk@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 08 12月, 2010 1 次提交
-
-
由 Varadarajan, Charulatha 提交于
Add GPIO hwmod data for OMAP2420 and add the required GPIO device attributes in the gpio header file Also remove "omap24xx.h" header file as it is not required anymore. Signed-off-by: NCharulatha V <charu@ti.com> Acked-by: NBenoit Cousson <b-cousson@ti.com> Acked-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 10 11月, 2010 1 次提交
-
-
由 Paul Walmsley 提交于
Add hwmod structures for I2C controllers on OMAP2420/2430. NOTE: I2C module on OMAP2420 has 16bit registers and causes imprecise aborts if 32bits are read/written to it. Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this hard requirement so that __raw_writew/readw is used to read /write the mdoule registers. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
- 30 9月, 2010 2 次提交
-
-
由 Kevin Hilman 提交于
This patch adds omap_hwmod data for UARTs on OMAP2 and OMAP3 platforms. UART4 support for 3630 and OMAP2 hwmod data added by Govindraj R. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Varadarajan, Charulatha 提交于
Add watchdog timer hwmod data for OMAP2420 chip Signed-off-by: NCharulatha V <charu@ti.com> Acked-by: NCousson, Benoit <b-cousson@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
- 27 7月, 2010 4 次提交
-
-
由 Paul Walmsley 提交于
Add IVA1 hwmod data for OMAP2420 and IVA2 hwmod data for 2430. The data is based on Benoît Cousson's hwmod data for the OMAP3 IVA blocks. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Kevin Hilman 提交于
Replace all the struct that contain l3 with l3_main in order to be consistent with the OMAP4 naming convention. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Benoit Cousson 提交于
In the lastest OMAP4 hwmod data file, the _hwmod was removed in order to save some memory space and because it does not bring a lot. Align OMAP2420, 2430 and 3430 data files with the same convention. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Acked-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Kevin Hilman 提交于
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag, otherwise _enable() will fail due to failing _wait_target_ready(). Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 21 5月, 2010 1 次提交
-
-
由 Benoit Cousson 提交于
In the lastest OMAP4 hwmod data file, the _hwmod was removed in order to save some memory space and because it does not bring a lot. The same cleanup will be have to done for other hwmods in OMAP2 & 3 data files. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
-
- 25 2月, 2010 3 次提交
-
-
由 Paul Walmsley 提交于
Add support for categorizing and iterating over hardware IP blocks by the "class" of the IP block. The class is the type of the IP block: e.g., "timer", "timer1ms", etc. Move the OCP_SYSCONFIG/SYSSTATUS data from the struct omap_hwmod into the struct omap_hwmod_class, since it's expected to stay consistent for each class. While here, fix some comments. The hwmod_class structures in this patch were designed and proposed by Benoît Cousson <b-cousson@ti.com> and were refined in a discussion between Thara Gopinath <thara@ti.com>, Kevin Hilman <khilman@deeprootsystems.com>, and myself. This patch uses WARN() lines that are longer than 80 characters, as Kevin noted a broader lkml consensus to increase greppability by keeping the messages all on one line. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NBenoît Cousson <b-cousson@ti.com> Cc: Thara Gopinath <thara@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Paul Walmsley 提交于
Code should be able to #include any header file without the fear that the header file will go allocating memory. This is a coding style issue, similar to commit 82e9bd58. Move the existing hwmod data from .h files to .c files. While here, convert "omap34xx" to "omap3xxx" in the hwmod files, since most of these structures should be reusable across all OMAP3 chips. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Paul Walmsley 提交于
The OMAP hwmod core code is intended to use SoC IP block description structures that are autogenerated from TI's OMAP hardware database. Currently the hwmod code uses clkdev device + connection addressing to identify clocks. This causes problems in the hwmod autogeneration process, since the TI hardware database doesn't use platform_device or clkdev addressing; it uses a single clock signal name string, which tends to bear some resemblance to what is used in the OMAP TRMs. This patch converts the hwmod code and existing data to use omap_clk_get_by_name(), introduced in the previous patch. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
- 21 10月, 2009 1 次提交
-
-
由 Tony Lindgren 提交于
Move the remaining headers under plat-omap/include/mach to plat-omap/include/plat. Also search and replace the files using these headers to include using the right path. This was done with: #!/bin/bash mach_dir_old="arch/arm/plat-omap/include/mach" plat_dir_new="arch/arm/plat-omap/include/plat" headers=$(cd $mach_dir_old && ls *.h) omap_dirs="arch/arm/*omap*/ \ drivers/video/omap \ sound/soc/omap" other_files="drivers/leds/leds-ams-delta.c \ drivers/mfd/menelaus.c \ drivers/mfd/twl4030-core.c \ drivers/mtd/nand/ams-delta.c" for header in $headers; do old="#include <mach\/$header" new="#include <plat\/$header" for dir in $omap_dirs; do find $dir -type f -name \*.[chS] | \ xargs sed -i "s/$old/$new/" done find drivers/ -type f -name \*omap*.[chS] | \ xargs sed -i "s/$old/$new/" for file in $other_files; do sed -i "s/$old/$new/" $file done done for header in $(ls $mach_dir_old/*.h); do git mv $header $plat_dir_new/ done Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 04 9月, 2009 1 次提交
-
-
由 Paul Walmsley 提交于
Connect the omap_hwmod code to the kernel boot. Create some basic interconnect and device structures for OMAP2/3 chips. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-