#
937e8722 |
|
31-May-2023 |
Franziska Naepelt <franziska.naepelt@googlemail.com> |
ARM: omap2: Fix checkpatch issues The following checkpatch issues have been resolved: arch/arm/mach-omap2/omap-wakeupgen.c WARNING: Missing a blank line after declarations arch/arm/mach-omap2/omap_hwmod_3xxx_data.c ERROR: space prohibited before that ',' (ctx:WxE) WARNING: Use lore.kernel.org archive links when possible arch/arm/mach-omap2/omap_phy_internal.c WARNING: Block comments should align the * on each line arch/arm/mach-omap2/sdrc2xxx.c WARNING: It's generally not useful to have the filename in the file arch/arm/mach-omap2/ti81xx-restart.c ERROR: trailing statements should be on next line Signed-off-by: Franziska Naepelt <franziska.naepelt@gmail.com> Message-ID: <20230531170427.42199-1-franziska.naepelt@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
3af8e972 |
|
28-Sep-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: omap2: remove unused headers The serial.h and clock3xxx.h headers have no contents that anything else uses, so these can be removed after the other files stop including them. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
#
42a79edd |
|
22-Nov-2022 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Drop legacy hwmod data for omap3 otg With complete devicetree data available to probe with ti-sysc interconnect target module driver, we can now drop the related SoC data. Cc: H. Nikolaus Schaller <hns@goldelico.com> Tested-by: Sicelo A. Mhlongo <absicsz@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
c312f066 |
|
17-Jun-2020 |
Adam Ford <aford173@gmail.com> |
ARM: dts: omap3: Migrate AES from hwmods to sysc-omap2 Various OMAP3 boards have two AES blocks, but only one is currently available, because the hwmods are only configured for one. This patch migrates the hwmods for the AES engine to sysc-omap2 which allows the second AES crypto engine to become available. omap-aes 480a6000.aes1: OMAP AES hw accel rev: 2.6 omap-aes 480a6000.aes1: will run requests pump with realtime priority omap-aes 480c5000.aes2: OMAP AES hw accel rev: 2.6 omap-aes 480c5000.aes2: will run requests pump with realtime priority Signed-off-by: Adam Ford <aford173@gmail.com> [tony@atomide.com: updated to disable both aes_targets on hs boards] Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
e428e250 |
|
07-May-2020 |
Tony Lindgren <tony@atomide.com> |
ARM: dts: Configure system timers for omap3 We can now init system timers using the dmtimer and 32k counter based on only devicetree data and drivers/clocksource timers. Let's configure the clocksource and clockevent, and drop the old unused platform data. As we're just dropping platform data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Since the dmtimer can use both 32k clock and system clock as the source, let's also configure the SoC specific default values. The board specific dts files can reconfigure these with assigned-clocks and assigned-clock-parents as needed. Let's also update the dts file to use #include while at it. Cc: devicetree@vger.kernel.org Cc: Adam Ford <aford173@gmail.com> Cc: Andreas Kemnade <andreas@kemnade.info> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: "H. Nikolaus Schaller" <hns@goldelico.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Rob Herring <robh@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
37b156ec |
|
10-Dec-2019 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Drop legacy platform data for sdma We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Vinod Koul <vkoul@kernel.org> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
c6797bcd |
|
16-Dec-2019 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Configure dma_plat_info directly and drop dma_dev_attr Let's prepare things for passing dma_plat_info to the dmaengine driver in device tree auxdata. To do that, we want to configure dma_plat_info directly. And we can also drop the related dma_dev_attr data. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Vinod Koul <vkoul@kernel.org> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
d2912cb1 |
|
04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
70451127 |
|
21-Mar-2019 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Remove hwmod .rev data and use local SoC checks instead We can just check for omap2 and 3 for i2c and smartreflex locally. The rest of the .rev data is already unused. Cc: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
79fc540f |
|
19-Apr-2018 |
Wolfram Sang <wsa@kernel.org> |
i2c: omap: move header to platform_data This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Tony Lindgren <tony@atomide.com>
|
#
103fd8e7 |
|
16-Apr-2018 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Use signed value for sysc register offsets We currently don't know if a revision register exists or not. Zero is often a valid offset for the revision register. As we are still checking device tree data against platform data, we will get bogus warnings with correct device tree data because of incomplete platform data. Let's fix the issue by using signed offsets and tag the revision registers that don't exist with -ENODEV, and init the missing ones with the correct revision register offset. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
0693036c |
|
12-Feb-2018 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: Cleanup omap_mcbsp_dev_attr and other legacy data The omap_mcbsp_dev_attr data was used to supply instance-specific data for legacy non-DT devices. The legacy McBSP device support including the usage of the hwmod class revision data has been dropped in commit 48f6693790aa ("ARM: OMAP2+: Remove unused legacy code for McBSP") and this data is therefore no longer needed. So, cleanup the structure and all the associated data in various hwmod data files. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
1cddc364 |
|
12-Feb-2018 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: Cleanup omap2_spi_dev_attr and other legacy data The omap2_spi_dev_attr data was used to supply instance-specific data for legacy non-DT devices. The SPI legacy device support including the usage of the hwmod class revision data has been dropped in commit 6f3ab009a178 ("ARM: OMAP2+: Remove unused legacy code for device init") and this data is therefore no longer needed. So, cleanup the structure and all the associated data in various hwmod data files. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
cc7e3fb6 |
|
12-Feb-2018 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: Cleanup omap_timer_capability_dev_attr usage The omap_timer_capability_dev_attr data was used to supply instance specific capabilities (like always-on, PWM functionality or ability to interrupt DSP cores) for legacy non-DT devices. These capabilities are now provided through device-tree properties. The legacy device support has been cleaned up in commit 8d39ff3d1696 ("ARM: OMAP2+: Remove unused legacy code for timer") and this data is therefore no longer needed. So, cleanup the structure and all the associated data in various hwmod data files. While at this, remove the stale header in hwmod data files that already do not have any timer capability data. Cc: Keerthy <j-keerthy@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
5297e1d7 |
|
12-Feb-2018 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: Cleanup omap_i2c_dev_attr usage The omap_i2c_dev_attr data was used to supply instance-specific data for legacy non-DT devices. The I2C legacy device support has been cleaned up in commit 65fa3e719f36 ("ARM: OMAP2+: Remove legacy i2c.c platform init code") and this data is therefore no longer needed. So, cleanup the structure and all the associated data in various hwmod data files. The i2c-omap.h header is still needed because of the need for various OMAP_I2C_IP_VERSION_x macros. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
a0e37da2 |
|
12-Feb-2018 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: Cleanup omap_gpio_dev_attr usage The omap_gpio_dev_attr data was used to supply instance-specific data for legacy non-DT devices. The GPIO legacy device support has been cleaned up in commit 14944934f8ac ("ARM: OMAP2+: Remove legacy gpio code") a while ago and this data is therefore no longer needed. So, cleanup the structure and all the associated data in various hwmod data files. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
bf807052 |
|
15-Dec-2017 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Move all omap_hwmod_sysc_fields to omap_hwmod_common_data.c We want to be able to eventually allocate these dynamically with the data for omap_hwmod_class_sysconfig coming from dts. Note that omap_hwmod_sysc_type_smartreflex is the same as the older omap36xx_sr_sysc_fields, so let's use the earlier omap36xx_sr_sysc_fields instead. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
a7cb4671 |
|
14-Dec-2017 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Drop unused legacy data for prcm_reg_id and module_bit We are now using clock drivers in driver/clk/ti for enabling and disabling modules and these are all unused. Let's also remove the related unused defines in cm-regbits-24xx.h and cm-regbits-34xx.h. Reported-by: H. Nikolaus Schaller <hns@goldelico.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
3c4d296e |
|
30-Oct-2017 |
Tero Kristo <t-kristo@ti.com> |
ARM: OMAP3: hwmod_data: add missing module_offs for MMC3 MMC3 hwmod data is missing the module_offs definition. MMC3 belongs under core, so add CORE_MOD for it. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
d9ecbef3 |
|
20-Oct-2017 |
Markus Elfring <elfring@users.sourceforge.net> |
ARM: OMAP3: Delete an unnecessary variable initialisation in omap3xxx_hwmod_init() The local variable "bus" will eventually be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
f33aadd2 |
|
20-Oct-2017 |
Markus Elfring <elfring@users.sourceforge.net> |
ARM: OMAP3: Use common error handling code in omap3xxx_hwmod_init() Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
9cffb1a0 |
|
10-Oct-2017 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Drop legacy struct omap_hwmod_addr_space With all of mach-omap2 booting now in device tree only mode, we can get the module IO range from device tree and just drop the legacy hwmod struct omap_hwmod_addr_space. Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
c2b84a9b |
|
10-Oct-2017 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Drop omap_hwmod_dma_info We have all of mach-omap2 booting in device tree only mode now, and this data is populated from device tree. Note that once we have removed support for the omap legacy DMA, we can also drop struct omap_dma_dev_attr. Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
fe97874a |
|
10-Oct-2017 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Drop omap_hwmod_irq_info With the previous patches removing the need for legacy IRQs now that all of mach-omap2 is booting in device tree only mode, we can drop struct omap_hwmod_irq_info. Note that we can now also finally drop omap4_xlate_irq. Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
1aa8f0cb |
|
31-May-2017 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Remove unused legacy code for interconnects We are now booting all mach-omap2 in device tree only mode. Any code that is only called in legacy boot mode where of_have_populated_dt() is not set is safe to remove now. Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
ca5339b1 |
|
14-Mar-2017 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Remove unused CLOCKACT_TEST_ICLK This is not used so let's remove it. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
b92675d9 |
|
04-Mar-2017 |
Guenter Roeck <linux@roeck-us.net> |
ARM: OMAP2+: Release device node after it is no longer needed. The device node returned by of_find_node_by_name() needs to be released after it is no longer needed to avoid a device node leak. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
10e5778f |
|
04-Mar-2017 |
Guenter Roeck <linux@roeck-us.net> |
ARM: OMAP2+: Fix device node reference counts After commit 0549bde0fcb1 ("of: fix of_node leak caused in of_find_node_opts_by_path"), the following error may be reported when running omap images. OF: ERROR: Bad of_node_put() on /ocp@68000000 CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc7-next-20170210 #1 Hardware name: Generic OMAP3-GP (Flattened Device Tree) [<c0310604>] (unwind_backtrace) from [<c030bbf4>] (show_stack+0x10/0x14) [<c030bbf4>] (show_stack) from [<c05add8c>] (dump_stack+0x98/0xac) [<c05add8c>] (dump_stack) from [<c05af1b0>] (kobject_release+0x48/0x7c) [<c05af1b0>] (kobject_release) from [<c0ad1aa4>] (of_find_node_by_name+0x74/0x94) [<c0ad1aa4>] (of_find_node_by_name) from [<c1215bd4>] (omap3xxx_hwmod_is_hs_ip_block_usable+0x24/0x2c) [<c1215bd4>] (omap3xxx_hwmod_is_hs_ip_block_usable) from [<c1215d5c>] (omap3xxx_hwmod_init+0x180/0x274) [<c1215d5c>] (omap3xxx_hwmod_init) from [<c120faa8>] (omap3_init_early+0xa0/0x11c) [<c120faa8>] (omap3_init_early) from [<c120fb2c>] (omap3430_init_early+0x8/0x30) [<c120fb2c>] (omap3430_init_early) from [<c1204710>] (setup_arch+0xc04/0xc34) [<c1204710>] (setup_arch) from [<c1200948>] (start_kernel+0x68/0x38c) [<c1200948>] (start_kernel) from [<8020807c>] (0x8020807c) of_find_node_by_name() drops the reference to the passed device node. The commit referenced above exposes this problem. To fix the problem, use of_get_child_by_name() instead of of_find_node_by_name(); of_get_child_by_name() does not drop the reference count of passed device nodes. While semantically different, we only look for immediate children of the passed device node, so of_get_child_by_name() is a more appropriate function to use anyway. Release the reference to the device node obtained with of_get_child_by_name() after it is no longer needed to avoid another device node leak. While at it, clean up the code and change the return type of omap3xxx_hwmod_is_hs_ip_block_usable() to bool to match its use and the return type of of_device_is_available(). Cc: Qi Hou <qi.hou@windriver.com> Cc: Peter Rosin <peda@axentia.se> Cc: Rob Herring <robh@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
17912508 |
|
14-Feb-2017 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP3: Fix smartreflex platform data regression Commit d9d9cec02835 ("ARM: OMAP2+: Remove legacy data from hwmod for omap3") dropped platform data that should no longer be used as we're booting with device tree. It turns out that smartreflex is still using platform data and produces the following errors during probe: smartreflex smartreflex.0: invalid resource smartreflex smartreflex.0: omap_sr_probe: ioremap fail smartreflex: probe of smartreflex.0 failed with error -22 smartreflex smartreflex.1: invalid resource smartreflex smartreflex.1: omap_sr_probe: ioremap fail smartreflex: probe of smartreflex.1 failed with error -22 Let's fix the regression by adding back the smartreflex hwmod data. The long term is to update the smartreflex driver to use device tree based probing. Fixes: d9d9cec02835 ("ARM: OMAP2+: Remove legacy data from hwmod for omap3") Reported-by: Adam Ford <aford173@gmail.com> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
d9d9cec0 |
|
21-Oct-2016 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Remove legacy data from hwmod for omap3 This data is now coming from device tree so we can remove the duplicate data. Let's keep the DSS and DMA related things for now until those have been converted to device tree completely. While at it, let's also add the trailing commas to data structures so further processing with scripts will be a bit easier. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
b46211d6 |
|
23-Jun-2016 |
Sebastian Reichel <sre@kernel.org> |
ARM: OMAP3: hwmod data: Add sysc information for DSI Add missing sysconfig/sysstatus information to OMAP3 hwmod. The information has been checked against OMAP34xx and OMAP36xx TRM. Without this change DSI block is not reset during boot, which is required for working Nokia N950 display. Signed-off-by: Sebastian Reichel <sre@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
3b80c9be |
|
30-May-2016 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the sidetone only receives the ICLK from the main McBSP module. Since the McBSP and sidetone is using the very same clock from PRCM level the sidetone must not have the prcm section to check the clock status since the sidetone is only used when McBSP is already configured. If two separate hwmods looking at the same bit and they would use pm_runtime in nested way (as it must happen with McBSP and it's ST module) the hwmod would warn, because the idlest will not match what it is expected after enable/disable of the clocks. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
77112076 |
|
17-Jan-2016 |
Sebastian Reichel <sre@kernel.org> |
ARM: OMAP2+: hwmod data: Add SSI data for omap36xx This patch enables Synchronous Serial Interface (SSI) hwmod support for OMAP36xx SoCs (used by Nokia N950/N9). Signed-off-by: Sebastian Reichel <sre@kernel.org> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
621062f4 |
|
16-Sep-2015 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP3: hwmod data: Remove legacy IOMMU data The legacy-mode device creation logic for IOMMU devices has been cleaned up, so the device attribute data, irq information and address data are no longer required. Remove all of these data for the ISP & IVA IOMMU devices. Signed-off-by: Suman Anna <s-anna@ti.com> [tony@atomide.com: updated to apply for the include] Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
c4384a97 |
|
14-Sep-2015 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs Remove the mailbox attribute data, irq info and hwmod addr space data that are used for creating the legacy-style mailbox devices, there is no need for these as the support for legacy-mode for this IP is being dropped. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
a55a7445 |
|
26-Feb-2015 |
Pali Rohár <pali@kernel.org> |
ARM: OMAP3: Fix crypto support for HS devices Register crypto hwmod links only if they are not disabled in DT. If DT information is missing, enable them only for GP devices. Before this patch crypto hwmod links were always disabled for all HS devices and it was not possible to use omap-aes and omap-sham linux drivers. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> [paul@pwsan.com: move the complex IP-block presence heuristics into their own function to simplify the code; fix some checkpatch warnings] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
63aa945b |
|
01-Jun-2015 |
Tony Lindgren <tony@atomide.com> |
memory: omap-gpmc: Add Kconfig option for debug We support decoding the bootloader values if DEBUG is defined. But we also need to change the struct omap_hwmod flags to have HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the boot. Otherwise just the default timings will be displayed instead of the bootloader configured timings. This also allows us to clean up the various GPMC related hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET, and HWMOD_INIT_NO_IDLE is not needed. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
13eeb0f3 |
|
13-Jan-2015 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP3: Remove legacy support for am35xx-emac This is no longer needed now that 3517 is booting in device tree only mode. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
55143438 |
|
08-Nov-2014 |
Andreas Fenkart <afenkart@gmail.com> |
ARM: OMAP1/2+: MMC: separate platform data for mmc and mmc hs driver - omap mmc driver supports multiplexing, omap_mmc_hs doesn't this leads to one of the major confusions in the omap_hsmmc driver - platform data should be read-only for the driver most callbacks are not set by the omap3 platform init code while still required. So they are set from the driver probe function, which is against the paradigm that platform-data should not be modified by the driver typical examples are card_detect, read_only callbacks un-bundling by searching for driver name \"omap_hsmmc in the arch/arm folder. omap_hsmmc_platform_data is not initialized directly, but from omap2_hsmmc_info, which is defined in a separate header file not touched by this patch hwmod includes platform headers to declare features of the platform. All the declared features are prefixed OMAP_HSMMC. There is no need to include platform header from hwmod other except for feature defines Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
826c71a0 |
|
08-Nov-2014 |
Andreas Fenkart <afenkart@gmail.com> |
ARM: OMAP2: MMC: include mmc-omap platform header directly Only a few files really need that platform header. When later splitting omap_mmc_platform_data into omap_mmc and omap_mmc_hs, those files declaring an hs mmc platform data will have to change the platform include, which is a good sanity check. Also removing omap242x_init_mmc, which is not used anywhere, checked with grep. Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
a2fc3661 |
|
18-Sep-2014 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP3: Use manual idle for UARTs because of DMA errata In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge idle requests in smartidle mode when configured for DMA operations. This prevents L4 from going idle. So let's use manual idle mode instead. Otherwise systems using Sebastian's 8250 patches with DMA will never enter deeper idle states because of the errata above. Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
6a08b11a |
|
18-Sep-2014 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Add hwmod flag for HWMOD_RECONFIG_IO_CHAIN Commit cc824534d4fe ("ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled") fixed issues with hung UART wake-up events by calling _reconfigure_io_chain() when MUSB is connected or disconnected. As pointed out by Paul Walmsley, we may need to also call _reconfigure_io_chain() in other cases, so it should be a separate flag. Let's add HWMOD_RECONFIG_IO_CHAIN as suggested by Paul. Reviewed-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
4aa5dd7e |
|
17-Jul-2014 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
ARM: omap: Don't set iommu pdata da_start and da_end fields The fields are not used by the driver and will be removed from platform data. Don't set them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
dc94fabf |
|
21-May-2014 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Fix ssi hwmod entry to allow idling The current entry prevents system from idling if the hwmod is defined in the .dts file so let's change the idlemodes. Note that we probably don't have SYSC_HAS_EMUFREE or SYSS_HAS_RESET_STATUS either. If we do, those can be added later on. Acked-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
c6c56697 |
|
10-Apr-2014 |
Roger Quadros <rogerq@ti.com> |
ARM: OMAP3: hwmod data: Correct clock domains for USB modules OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the proper clock domains for USB Host and USB TLL modules. Gets rid of the following warnings during boot omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm Reported-by: Nishanth Menon <nm@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Fixes: de231388cb80a8ef3e779bbfa0564ba0157b7377 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3") Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: Partha Basak <parthab@india.ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
775bb078 |
|
27-Feb-2014 |
Roger Quadros <rogerq@ti.com> |
mfd: omap-usb-host: Use proper clock name instead of alias Use the proper clock name 'usbhost_120m_fck' instead of the alias 'ehci_logic_fck' Get rid of the 'ehci_logic_fck' alias from the OMAP3 hwmod data as well. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
#
200a274f |
|
05-Mar-2014 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP3: fix iva mmu programming issues The IVA MMU is not functional when used through the hwmod and omap_device layers. Add fixes to clockdomain and hwmod data to have it functional. The hwmod changes are needed to enable the clock, and the SWSUP change is needed to wakeup the domain because the power domain is programmed to be in RET, and there is no automatic power domain switching to ON. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
895a9613 |
|
05-Mar-2014 |
Florian Vaussard <florian.vaussard@epfl.ch> |
ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2 CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting usage by tidspbridge and other iommu users. The same can be achieved by marking the DT node disabled, so remove this obsolete flag and the corresponding hwmod data can be enabled. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> [s-anna@ti.com: revise commit log] Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
6d4c8830 |
|
23-Dec-2013 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: hwmod_data: fix missing OMAP_INTC_START in irq data Commit 7d7e1eb (ARM: OMAP2+: Prepare for irqs.h removal) and commit ec2c082 (ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ) updated the way interrupts for OMAP2/3 devices are defined in the HWMOD data structures to being an index plus a fixed offset (defined by OMAP_INTC_START). Couple of irqs in the OMAP2/3 hwmod data were misconfigured completely as they were missing this OMAP_INTC_START relative offset. Add this offset back to fix the incorrect irq data for the following modules: OMAP2 - GPMC, RNG OMAP3 - GPMC, ISP MMU & IVA MMU Signed-off-by: Suman Anna <s-anna@ti.com> Fixes: 7d7e1eba7e92 ("ARM: OMAP2+: Prepare for irqs.h removal") Fixes: ec2c0825ca31 ("ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ") Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
7f4d3641 |
|
08-Dec-2013 |
Roger Quadros <rogerq@ti.com> |
ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module Unlike what the comment states, errata i660 does not state that we can't RESET the USB host module. Instead it states that RESET is the only way to recover from a deadlock situation. RESET ensures that the module is in a known good state irrespective of what bootloader does with the module, so it must be done at boot. Signed-off-by: Roger Quadros <rogerq@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM Fixes: de231388cb80 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3") Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
398917ce |
|
08-Oct-2013 |
Sebastian Reichel <sre@kernel.org> |
ARM: OMAP2+: hwmod data: Add SSI information This patch adds Synchronous Serial Interface (SSI) hwmod support for OMAP34xx SoCs. Signed-off-by: Sebastian Reichel <sre@debian.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
7dedd346 |
|
28-Jul-2013 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL With commit '82702ea11ddfe0e43382e1fa5b66d807d8114916' "ARM: OMAP2+: Fix serial init for device tree based booting" stubbing out omap_serial_early_init() for Device tree based booting, there was a crash observed on AM335x based devices when hwmod does a _setup_reset() early at boot. This was rootcaused to hwmod trying to reset console uart while earlycon was using it. The way to tell hwmod not to do this is to specify the HWMOD_INIT_NO_RESET flag, which were infact set by the omap_serial_early_init() function by parsing the cmdline to identify the console device. Parsing the cmdline to identify the uart used by earlycon itself seems broken as there is nothing preventing earlycon to use a different one. This patch, instead, attempts to populate the requiste flags for hwmod based on the CONFIG_DEBUG_OMAPxUARTy FLAGS. This gets rid of the need for cmdline parsing in the DT as well as non-DT cases to identify the uart used by earlycon. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Reported-by: Mark Jackson <mpfj-list@newflow.co.uk> Reported-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Tested-by: Mark Jackson <mpfj-list@newflow.co.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
da4f9d28 |
|
15-Jun-2013 |
Jarkko Nikula <jarkko.nikula@bitmer.com> |
ARM: OMAP2+: Remove dma.h All definitions in arch/arm/mach-omap2/dma.h are removed so it can be removed now. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
0fd8824f |
|
15-Jun-2013 |
Jarkko Nikula <jarkko.nikula@bitmer.com> |
ARM: OMAP2+: hwmod: Remove remaining DMA channel definitions Last remaining DMA channel definitions in arch/arm/mach-omap2/dma.h are used only by omap_hwmod_2xxx_3xxx_ipblock_data.c and omap_hwmod_3xxx_data.c. Remove them by using directly DMA channel number in hwmod data and drop definitions with a following script: egrep '#define [OMAP|AM35XX].*DMA' arch/arm/mach-omap2/dma.h | cut -f 1,3 \ | while read i; do \ DEF=`echo $i |cut -d ' ' -f 2`; \ CH=`echo $i |cut -d ' ' -f 3`; \ echo "removing" $DEF; \ sed -i "s/${DEF}/${CH}/" arch/arm/mach-omap2/omap_hwmod_*.c; \ sed -i "/${DEF}/d" arch/arm/mach-omap2/dma.h; \ done Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
fe32c1f6 |
|
07-May-2013 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: add user and fifo info to mailbox platform data The different generations of OMAP2+ SoCs have almost the same mailbox IP, but the IP has configurable parameters for number of users (interrupts it can generate out towards processors) and number of fifos (the base unidirectional h/w communication channel). This data cannot be read from any registers, and so has been added to the platform data. This data together with the interrupt-type configuration can be used in properly figuring out the number of registers to save and restore in the OMAP mailbox driver code. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Suman Anna <s-anna@ti.com>
|
#
b8a7cf8e |
|
28-Jan-2013 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: mbox: remove dependencies with soc.h The OMAP mailbox platform driver code has been cleaned up to remove the dependencies with soc.h in preparation for moving the mailbox code to drivers folder. The code relied on cpu_is_xxx/soc_is_xxx macros previously to pick the the right set of mailbox devices and register with the mailbox driver. This data is now represented in a concise format and moved to the respective omap_hwmod data files and published to the driver through the platform data. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Suman Anna <s-anna@ti.com>
|
#
66dde54e |
|
15-May-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: OMAP2+: hwmod-data: UART IP needs software control to manage sidle modes OMAP UART IP needs software control for slave idle modes based on functional state of the IP. i.e The IP slave idle settings should be set to 'noidle' when being used and then put back to 'smart_idle' when unused. Currently this is handled by the driver with function pointers implemented in platform code. This however breaks in case of device tree because of missing idle handling APIs. Previous patches in this series added a flag HWMOD_SWSUP_SIDLE_ACTIVE which takes care of the mentioned requirement. Hence add the flag for all UART IPs to take advantage of feature supported by framework. Subsequent patches removes the slave idle handling from driver code. Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Tested-by: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP4/Panda Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
14ae5564 |
|
21-Dec-2012 |
Mark A. Greer <mgreer@animalcreek.com> |
ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod Convert the device data for the OMAP3 AES crypto IP from explicit platform_data to hwmod. CC: Paul Walmsley <paul@pwsan.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> [paul@pwsan.com: fixed lines causing sparse warnings] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
26f88e6e |
|
18-Mar-2013 |
Mark A. Greer <mgreer@animalcreek.com> |
ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP from explicit platform_data to hwmod. CC: Paul Walmsley <paul@pwsan.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> [paul@pwsan.com: updated to use per-SoC registration lists for GP-only hwmods; fixed lines causing sparse warnings] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
092bc089 |
|
11-Mar-2013 |
Grazvydas Ignotas <notasas@gmail.com> |
ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb For some unknown reason, allowing hwmod to control MIDLEMODE causes core_pwrdm to not hit idle states for musb in DM3730 at least. I've verified that setting any MIDLEMODE value other than "force standby" before enabling the device causes subsequent suspend attempts to fail with core_pwrdm not entering idle states, even if the driver is unloaded and "force standby" is restored before suspend attempt. To recover from this, soft reset can be used, but that's not suitable solution for suspend. Keeping the register set at force standby (reset value) makes it work and device still functions properly, as musb has driver-controlled OTG_FORCESTDBY register that controls MSTANDBY signal. Note that TI PSP kernels also have similar workarounds. This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the actual flag name. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
814a18a5 |
|
06-Feb-2013 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable to wake the ARM up from WFI: http://www.spinics.net/lists/arm-kernel/msg174734.html Further troubleshooting was unable to narrow the problem down. So we don't have much choice other than to block WFI when the EMAC is active with the HWMOD_BLOCK_WFI flag. Based on Mark's original patch. We're removing the omap_device-based pm_lats code, so a different approach was needed. This third version contains some corrections thanks to Mark's review. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Mark A. Greer <mgreer@animalcreek.com> Acked-by: Mark A. Greer <mgreer@animalcreek.com>
|
#
45c3eb7d |
|
30-Nov-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Move plat-omap/dma-omap.h to include/linux/omap-dma.h Based on earlier discussions[1] we attempted to find a suitable location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion to dmaengine is complete. Unfortunately that was before I was able to try to test compile of the ARM multiplatform builds for omap2+, and the end result was not very good. So I'm creating yet another all over the place patch to cut the last dependency for building omap2+ for ARM multiplatform. After this, we have finally removed the driver dependencies to the arch/arm code, except for few drivers that are being worked on. The other option was to make the <plat-omap/dma-omap.h> path to work, but we'd have to add some new header directory to for multiplatform builds. Or we would have to manually include arch/arm/plat-omap/include again from arch/arm/Makefile for omap2+. Neither of these alternatives sound appealing as they will likely lead addition of various other headers exposed to the drivers, which we want to avoid for the multiplatform kernels. Since we already have a minimal include/linux/omap-dma.h, let's just use that instead and add a note to it to not use the custom omap DMA functions any longer where possible. Note that converting omap DMA to dmaengine depends on dmaengine supporting automatically incrementing the FIFO address at the device end, and converting all the remaining legacy drivers. So it's going to be few more merge windows. [1] https://patchwork.kernel.org/patch/1519591/# cc: Russell King <linux@arm.linux.org.uk> cc: Kevin Hilman <khilman@ti.com> cc: "Benoît Cousson" <b-cousson@ti.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: "David S. Miller" <davem@davemloft.net> cc: Vinod Koul <vinod.koul@intel.com> cc: Dan Williams <djbw@fb.com> cc: Mauro Carvalho Chehab <mchehab@infradead.org> cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> cc: David Woodhouse <dwmw2@infradead.org> cc: Kyungmin Park <kyungmin.park@samsung.com> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Tomi Valkeinen <tomi.valkeinen@ti.com> cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> cc: Hans Verkuil <hans.verkuil@cisco.com> cc: Vaibhav Hiremath <hvaibhav@ti.com> cc: Lokesh Vutla <lokeshvutla@ti.com> cc: Rusty Russell <rusty@rustcorp.com.au> cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> cc: Afzal Mohammed <afzal@ti.com> cc: linux-crypto@vger.kernel.org cc: linux-media@vger.kernel.org cc: linux-mtd@lists.infradead.org cc: linux-usb@vger.kernel.org cc: linux-fbdev@vger.kernel.org Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
972deb4f |
|
26-Nov-2012 |
Shubhrajyoti D <shubhrajyoti@ti.com> |
i2c: omap: Remove the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE flag The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore in the i2c driver. Remove the flag. Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
#
2ab7c848 |
|
02-Nov-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Move iommu/iovmm headers to platform_data Move iommu/iovmm headers from plat/ to platform_data/ as part of the single zImage work. Partially based on an earlier version by Ido Yariv <ido@wizery.com>. Cc: Ido Yariv <ido@wizery.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Joerg Roedel <joro@8bytes.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
2c88ab8c |
|
05-Nov-2012 |
Shubhrajyoti D <shubhrajyoti@ti.com> |
ARM: i2c: omap: Remove the i207 errata flag The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207] uses the revision id instead of the flag. So the flag can be safely removed. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
#
10759e82 |
|
11-Jul-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP2+: Don't use __omap_dm_timer_reset() Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to configure the clock-activity, idle, wakeup-enable and auto-idle fields in the timer OCP_CFG register. The name of the function is mis-leading because this function does not actually perform a reset of the timer. For OMAP2+ devices, HWMOD is responsible for reseting and configuring the timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not have the fields clock-activity, wakeup-enable and auto-idle and so this function could configure the OCP_CFG register incorrectly. Currently HWMOD is not configuring the clock-activity field in the OCP_CFG register for timers that have this field. Commit 0f0d080 (ARM: OMAP: DMTimer: Use posted mode) configures the clock-activity field to keep the f-clk enabled so that the wake-up capability is enabled. Therefore, add the appropriate flags to the timer HWMOD structures to configure this field in the same way. For OMAP2/3 devices all dmtimers have the clock-activity field, where as for OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field. Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is configuring the dmtimer OCP_CFG register as expected for clock-events timer. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
#
f3a13e72 |
|
27-Aug-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs For OMAP2/3 devices, the HWMOD data does not define a software reset status field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices, the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER TISTAT register (referred to as the SYSS register in HWMOD). Add the appropriate HWMOD definitions so that HWMOD will check the software reset status when performing a software reset of the DMTIMER. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
#
725a8fe3 |
|
27-Aug-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures (referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10 use one of the defintions and the other timers use the other definition. For OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for all 12 instances of the DMTIMER. Please note that this is a difference between OMAP3 and OMAP4 and could be the source of the confusion. For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields, clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all 12 timers. Therefore, remove one of the SYSC register definitions for the DMTIMERs and ensure the appropriate register fields are defined for all DMTIMERs. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
#
3d82cbbb |
|
15-Oct-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Split plat/serial.h for omap1 and omap2+ For omap1, we'll keep mach/serial.h around for 8250.c hardware workarounds. For omap2+, we no longer need mach/serial.h and can make it local to mach-omap2. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
2a296c8f |
|
02-Oct-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Make plat/omap_hwmod.h local to mach-omap2 Let's make omap_hwmod local to mach-omap2 for ARM common zImage support. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
3a8761c0 |
|
08-Oct-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Split plat-omap/i2c.c into mach-omap1 and mach-omap2 There's no need to keep the device related things in the common i2c.c as omap2+ is using hwmod. Split the code to mach-omap1 and mach-omap2 parts and only leave common code to plat-omap/i2c.c. Note that as omap1 only has one i2c controller, we can now remove the old device related macros. Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
1bef60cc |
|
04-Oct-2012 |
Jean Pihet <j-pihet@ti.com> |
ARM: OMAP: hwmod: align the SmartReflex fck names Rename the smartreflex fck names for consistency and better readability; rename the clock aliases so that they match the hwmod main_clk names. Signed-off-by: Jean Pihet <j-pihet@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
|
#
2b6c4e73 |
|
15-Oct-2012 |
Lokesh Vutla <lokeshvutla@ti.com> |
ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h Move plat/dma.h to plat-omap/dma-omap.h as part of single zImage work Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
d5e7c864 |
|
15-Oct-2012 |
Lokesh Vutla <lokeshvutla@ti.com> |
ARM: OMAP2+: DMA: Moving OMAP2+ DMA channel definitions to mach-omap2 Similar to omap1, some of the omap2+ dma channel definitions are used by some drivers. For moving omap2+ dma channel definitions to mach-omap2/, the used ones should be defined locally to driver. Drivers can eliminate it using DT, platform data, or IORESOURCE_DMA And moving omap2+ DMA channel definitions to mach-omap2 Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
68f39e74 |
|
15-Oct-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Split plat/mmc.h into local headers and platform_data We need to remove this from plat for ARM common zImage support. Also remove includes not needed by the omap_hsmmc.c driver. Cc: linux-mmc@vger.kernel.org Acked-by: Chris Ball <cjb@laptop.org> Acked-by: Venkatraman S <svenkatr@ti.com> [tony@atomide.com: fold in removal of unused driver includes] Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
c09fcc43 |
|
18-Sep-2012 |
Peter Senna Tschudin <peter.senna@gmail.com> |
arch/arm/mach-omap2: Remove unecessary semicolon Found by http://coccinelle.lip6.fr/ Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
b1a923d0 |
|
17-Sep-2012 |
Raphael Assenat <raph@8d.com> |
AM35xx: Add missing hwmod entry for the HDQ/1-Wire present in AM3505/3517 CPUs. This patch adds a missing hwmod entry for the HDQ/1-Wire module present in the AM3505/17 CPUs. This restores 1-Wire support to our AM3505 boards. We think it probably stopped working with commit 96b1b29d37b0ca3ecd424a1fe301406cf525fc04 ARM: OMAP2+: HDQ1W: use omap_device Signed-off-by: Raphael Assenat <raph@8d.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
3dc3401c |
|
07-Oct-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP2+: hwmod data: Fix PMU interrupt definitions Commit 7d7e1eb (ARM: OMAP2+: Prepare for irqs.h removal) and commit ec2c082 (ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ) updated the way interrupts for OMAP2/3 devices are defined in the HWMOD data structures to being an index plus a fixed offset (defined by OMAP_INTC_START). The definition of the PMU interrupts on OMAP2/3 devices is missing the OMAP_INTC_START offset and so this is causing the allocation of PMU interrupts to fail on OMAP2/3 devices. So add the offset to fix this. This is patch is based upon Tony's master branch for OMAP. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
76a5d9bf |
|
23-Sep-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70 OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these interrupts to the MPU HWMOD so we can use these for PMU events on these devices. The PMU interrupts need to be the first interrupts in the array of interrupts as the ARM PMU driver assumes this. By using these dedicated interrupts we only need to enable the MPU and DEBUG sub-systems for PMU to work. This is different to OMAP4430 that did not have dedicated interrupts and required other power domains in addition to the DEBUG sub-system to be enabled so we could route the PMU events to the CTI interrupts. Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create the PMU device that is using by OMAP3. Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: updated to apply] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
ee75d95c |
|
23-Sep-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD Convert OMAP2/3 devices to use HWMOD for creating a PMU device. To support PMU on OMAP2 devices we only need to use MPU sub-system and so we can simply use the MPU HWMOD to create the PMU device. To support PMU on OMAP3 devices, we need to use the MPU and DEBUG sub-systems and so use these HWMODs to create the PMU device for OMAP3. The MPU HWMOD for OMAP2/3 devices is currently missing the PMU interrupt and so add the PMU interrupt to the MPU HWMOD for these devices. This change also moves the PMU code out of the mach-omap2/devices.c files into its own pmu.c file as suggested by Kevin Hilman to de-clutter devices.c. Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: fixed checkpatch messages; updated to apply; dropped old-style initial filename line in header comments] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
c7dad45f |
|
23-Sep-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP3: hwmod data: Add debugss HWMOD data To enable PMU with runtime PM support on OMAP3 devices we need to be able to dynamically enable and disable the debug sub-system at runtime. By adding HWMOD data for the debug sub-system for OMAP3, we can build the PMU device using the debug sub-system HWMOD and control this power domain using runtime PM. Reviewed-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: updated to apply; added L4-EMU address space] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
5c3e4ec4 |
|
23-Sep-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP Some instances of the DMTIMER peripheral on OMAP devices have the ability to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER attribute to indicate which timers can interrupt the DSP. By using the omap_dm_timer_request_by_cap() API, driver will now be able to allocate a DMTIMER that can interrupt the DSP based upon this attribute and not require the driver to know which instance has this capability. DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as follows ... - OMAP1 (OMAP5912/16xx/17xx) devices - All 8 DMTIMERs - OMAP2/3/4 devices - DMTIMERs 5-8 Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and generate a PWM output. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
49484a60 |
|
23-Sep-2012 |
Afzal Mohammed <afzal@ti.com> |
ARM: OMAP2/3: hwmod data: add gpmc Add gpmc hwmod and associated interconnect data Signed-off-by: Afzal Mohammed <afzal@ti.com> [paul@pwsan.com: added comments to the use of HWMOD_INIT_NO_RESET] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
5486474c |
|
23-Sep-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod data: add mmu data for iva and isp Add mmu hwmod data for iva and isp. Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be propagated (previously on iommu resource info) to hwmod data in OMAP3, so users of iommu and tidspbridge can avoid issues of two modules managing mmu data/irqs/resets; this until tidspbridge can be migrated to iommu framework. Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> [paul@pwsan.com: fixed some kerneldoc and whitespace; ISP MMUs not present on AM35xx so restricted these hwmods to 34xx/36xx] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
8f993a01 |
|
23-Sep-2012 |
Tero Kristo <t-kristo@ti.com> |
ARM: OMAP3: hwmod data: add sad2d hwmod SAD2D stands for the die to die interface, and is used for communicating with the optional stacked modem. This hwmod is added in preparation for the d2d_idle move from pm34xx.c to hwmod data. Signed-off-by: Tero Kristo <t-kristo@ti.com> [paul@pwsan.com: SAD2D presumably doesn't exist on non-OMAP34xx/OMAP36xx, so only add it to the OMAP34xx/OMAP36xx lists] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
957988c7 |
|
20-Sep-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Make l4_3xxx.h local This can be local to mach-omap2. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
79e3cb22 |
|
20-Sep-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Make l3_3xxx.h local This can be local to mach-omap2. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
4f9ed545 |
|
20-Sep-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Make am35xx.h local This can be local to mach-omap2. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
2203747c |
|
24-Aug-2012 |
Arnd Bergmann <arnd@arndb.de> |
ARM: omap: move platform_data definitions Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: "Benoît Cousson" <b-cousson@ti.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: Jean Pihet <j-pihet@ti.com> Cc: J Keerthy <j-keerthy@ti.com> Cc: linux-omap@vger.kernel.org
|
#
dbc04161 |
|
31-Aug-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Acked-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
7d7e1eba |
|
27-Aug-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Prepare for irqs.h removal As the interrupts should only be defined in the platform_data, and eventually coming from device tree, there's no need to define them in header files. Let's remove the hardcoded references to irqs.h and fix up the includes so we don't rely on headers included in irqs.h. Note that we're defining OMAP_INTC_START as 0 to the interrupts. This will be needed when we enable SPARSE_IRQ. For some drivers we need to add #include <plat/cpu.h> for now until these drivers are fixed to remove cpu_is_omapxxxx() usage. While at it, sort som of the includes the standard way, and add the trailing commas where they are missing in the related data structures. Note that for drivers/staging/tidspbridge we just define things locally. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
4b25408f |
|
30-Aug-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Move gpio.h to include/linux/platform_data This way we can remove includes of plat/gpio.h which won't work with the single zImage support. Note that we also remove the cpu_class_is_omap2() check in gpio-omap.c as the drivers should not call it as we need to make it local to arch/arm/mach-omap2 for single zImage support. While at it, arrange the related includes in the standard way. Cc: Grant Likely <grant.likely@secretlab.ca> Cc: linux-mtd@lists.infradead.org Cc: alsa-devel@alsa-project.org Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
ed733619 |
|
03-Sep-2012 |
Tero Kristo <t-kristo@ti.com> |
ARM: OMAP3: hwmod data: fix iva2 reset info IVA2 hwmod resets were missing the status bit offsets. Also, as the hwmod itself didn't have prcm info at all, resetting iva hwmod was accessing some bogus memory addresses. Added both infos to fix this. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
31ba8808 |
|
27-Jun-2012 |
Mark A. Greer <mgreer@animalcreek.com> |
ARM: OMAP AM35x: EMAC/MDIO integration: Add Davinci EMAC/MDIO hwmod support Add hwmod support for the EMAC (and MDIO) ethernet controller that's on the am35x family of SoC's. Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> [paul@pwsan.com: updated subject line; updated to apply on v3.5-rc4; added comments to hwmod data regarding IPSS] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
82ee620d |
|
27-Jun-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP: AM35xx: fix UART4 softreset During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset: omap_hwmod: uart4: softreset failed (waited 10000 usec) This also results in another warning later in the boot process: omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or disabled state From empirical observation, the AM35xx UART4 IP block requires either uart1_fck or uart2_fck to be enabled while UART4 resets. Otherwise the reset will never complete. So this patch adds uart1_fck as an optional clock for UART4 and adds the appropriate hwmod flag to cause uart1_fck to be enabled during the reset process. (The choice of uart1_fck over uart2_fck was arbitrary.) Unfortunately this observation raises many questions. Is it necessary for uart1_fck or uart2_fck to be controlled with uart4_fck for the UART4 to work correctly? What exactly do the AM35xx UART4 clock tree and the related PRCM idle management FSMs look like? If anyone has the ability to answer these questions through empirical functional testing, or hardware information from the AM35xx designers, it would be greatly appreciated. Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kyle Manna <kyle.manna@fuel7.com> Cc: Mark A. Greer <mgreer@animalcreek.com> Cc: Ranjith Lohithakshan <ranjithl@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Mark A. Greer <mgreer@animalcreek.com>
|
#
bf765237 |
|
27-Jun-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP AM35xx: clock and hwmod data: fix UART4 data Add missing terminators to the arrays of IRQ, DMA, and address space structure records in the AM35xx UART4 hwmod data. Without these terminators, the following warnings appear on boot: omap_uart.3: failed to claim resource 58 omap_device: omap_uart: build failed (-16) WARNING: at /home/paul/linux/arch/arm/mach-omap2/serial.c:375 omap_serial_init_port+0x198/0x284() Could not build omap_device for omap_uart: uart4. Also, AM35xx uart4_fck has an incorrect parent clock pointer. Fix it and clean up a whitespace issue. Fix some incorrectly-named macros related to AM35xx UART4. Cc: Kyle Manna <kyle.manna@fuel7.com> Cc: Mark A. Greer <mgreer@animalcreek.com> Cc: Ranjith Lohithakshan <ranjithl@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Mark A. Greer <mgreer@animalcreek.com>
|
#
89ea2583 |
|
27-Jun-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP AM35xx: clock and hwmod data: fix AM35xx HSOTGUSB hwmod Partially fix the hwmod data for the AM35xx USB OTG hwmod. This should resolve the following boot warning on AM35xx platforms: omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3) While here, also fix the clkdev records, to avoid warnings about duplicate clock aliases. The hwmod is also connected to the wrong interconnect. It should be connected to the IPSS, not the L4 CORE. But that is left for a future fix, since it probably has a dependency on some hwmod core changes. Cc: Felipe Balbi <balbi@ti.com> Cc: Hema HK <hemahk@ti.com> Cc: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Mark A. Greer <mgreer@animalcreek.com>
|
#
7039154b |
|
18-Jun-2012 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
ARM: OMAP3: Move McBSP fck clock alias to hwmod data Remove the existing alias for pad_fck, prcm_fck from the clock data and add them as opt_clks to the hwmod data. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
9ebfd285 |
|
18-Jun-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module The enable/disable module functions are specific to SoCs with OMAP4-class PRCM. Rather than use cpu_is* checks at runtime inside the enable/disable module functions, use cpu_is at init time to initialize function pointers only for SoCs that need them. NOTE: the cpu_is* check for _enable_module was different than the one for _disable_module, and this patch uses cpu_is_omap44xx() for both. Signed-off-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: moved soc_ops function pointers to be per-kernel rather than per-hwmod since they do not vary by hwmod; added kerneldoc] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
67d2e760 |
|
04-Jun-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP2+: Fix external clock support for dmtimers Currently, the dmtimer determines whether an timer can support an external clock source (sys_altclk) for driving the timer by the IP version. Only OMAP24xx devices can support an external clock source, but the IP version between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates that OMAP3 devices can use an external clock source. Rather than use the IP version, just let the clock framework handle this. If the "alt_ck" does not exist for a timer then the clock framework will fail to find the clock and hence will return an error. By doing this we can eliminate the "timer_ip_version" variable passed as part of the platform data and simplify the code. We can also remove the timer IP version from the HWMOD data because the dmtimer driver uses the TIDR register to determine the IP version. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
139486fa |
|
04-Jun-2012 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP2+: HWMOD: Correct timer device attributes Fix the following issues with the timer device attributes for OMAP2+ devices: 1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating that these timers are in an ALWAYS-ON power domain. This is not the case only timer1 is in an ALWAYS-ON power domain. 2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating that these timers are in an ALWAYS-ON power domain. This is not the case only timer1 and timer12 are in an ALWAYS-ON power domain. 3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but is in an always-on power domain. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
1fcd3069 |
|
23-Apr-2012 |
Jean Pihet <j-pihet@ti.com> |
ARM: OMAP3: hwmod: rename the smartreflex entries Change the name field value to better reflect the smartreflex integration in the system. Signed-off-by: Jean Pihet <j-pihet@ti.com> Signed-off-by: J Keerthy <j-keerthy@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
|
#
b86aeafc |
|
25-Apr-2012 |
Jean Pihet <j-pihet@ti.com> |
ARM: OMAP2+: SmartReflex: move the smartreflex header to include/linux/power Move the smartreflex header file (arch/arm/mach-omap2/smartreflex.h) in a new header file include/linux/power/smartreflex.h. This change makes the SmartReflex implementation ready for the move to drivers/. Signed-off-by: Jean Pihet <j-pihet@ti.com> Signed-off-by: J Keerthy <j-keerthy@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
|
#
68a88b98 |
|
30-Apr-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP: AM35xx: convert 3517 detection/flags to AM35xx Currently cpu_is_omap3517() actually detects any device in the AM35x family (3517 and no-SGX version 3505.) To make it more clear what is being detected, convert the names from 3517 to AM35xx. This adds a new soc_is_am35xx() which duplicates the cpu_is_omap3517(). In order to avoid cross-tree dependencies with clock-tree changes, cpu_is_omap3517() is left until the clock changes are merged, at which point cpu_is_omap3517() will be completely removed. Acked-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Kevin Hilman <khilman@ti.com> [tony@atomide.com: change to use soc_is_omap instead] Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
414e4128 |
|
08-May-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP2+: WDTIMER integration: fix !PM boot crash, disarm timer after hwmod reset Without runtime PM enabled, hwmod needs to leave all IP blocks in an enabled state by default so any driver access to the HW will succeed. This is accomplished by seting the postsetup_state to enabled for all hwmods during init when runtime PM is disabled. Currently, we have a special case for WDT in that its postsetup_state is always set to disabled. This is done so that the WDT is disabled and the timer is disarmed at boot in case there is no WDT driver. This also means that when runtime PM is disabled, if a WDT driver *is* built in the kernel, the kernel will crash on the first access to the WDT hardware. We can't simply leave the WDT module enabled, because the timer is armed by default after reset. That means that if there is no WDT driver initialzed or loaded before the timer expires, the kernel will reboot. To fix this, a custom reset method is added to the watchdog class of omap_hwmod. This method will *always* disarm the timer after hwmod reset. The WDT timer then will only be rearmed when/if the driver is loaded for the WDT. With the timer disarmed by default, we no longer need a special-case for the postsetup_state of WDT during init, so it is removed. Any platforms wishing to ensure the watchdog remains armed across the entire boot boot can simply disable the reset-on-init feature of the watchdog hwmod using omap_hwmod_no_setup_reset(). Tested on 3530/Overo, 4430/Panda. NOTE: on 4430, the hwmod OCP reset does not seem to rearm the timer as documented in the TRM (and what happens on OMAP3.) I noticed this because testing the HWMOD_INIT_NO_RESET feature with no driver loaded, I expected a reboot part way through the boot, but did not see a reboot. Adding some debug to read the counter, I verified that right after OCP softreset, the counter is not firing. After writing the magic start sequence, the timer starts counting. This means that the timer disarm sequence added here does not seem to be needed for 4430, but is technically the correct way to ensure the timer is disarmed, so it is left in for OMAP4. Special thanks to Paul Walmsley for helping brainstorm ideas to fix this problem. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [paul@pwsan.com: updated the omap2_wd_timer_reset() function in the wake of commit 3c55c1baffa5f719eb2ae9729088bc867f972f53 ("ARM: OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status""); added kerneldoc; rolled in warning fix from Kevin] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
c8d82ff6 |
|
08-May-2012 |
Vaibhav Hiremath <hvaibhav@ti.com> |
ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database Add 32k-sync timer hwmod-data and add ocp_if details to omap2 & 3 hwmod table. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
1c2badc1 |
|
08-May-2012 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
ARM: OMAP3: hwmod_data: Rename the common irq for McBSP ports Use 'common' as name for the common irq number in hwmod data for the McBSP ports. The same name already in use for OMAP2430, and the OMAP4 hwmod data will be using the same name. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
45a4bb06 |
|
08-May-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod data: add HDQ/1-wire hwmod Add the HDQ1W hwmod for OMAP34xx, OMAP36xx, and AM3505/3517 devices. According to the respective TRMs, it doesn't appear to be available for the 816x/814x or the AM335x. The OCPIF_SWSUP_IDLE flag is added to work around an apparent hardware bug: the hardware is not taking the CM_FCLKEN*_CORE.EN_HDQ bit into account when considering whether to go idle: http://www.spinics.net/lists/linux-omap/msg63576.html This causes HDQ transfers to fail or become corrupt. Thanks to NeilBrown for his help diagnosing and testing fixes for this problem. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: NeilBrown <neilb@suse.de> Tested-by: NeilBrown <neilb@suse.de>
|
#
f42c5496 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomain The IVA hwmod data is missing some fields that cause the following warning on boot: [ 0.118011] omap_hwmod: iva: cannot be enabled for reset (3) Fix by encoding the IP block's main functional clock, reset lines, and clockdomain. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
064931ab |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod data: fix IVA interface clock The OMAP3 hwmod data listed iva2_ck as an interface clock between the IVA and L3. This is incorrect. iva2_ck is not an interface clock. Since it cannot auto-idle, specifying it here prevents the IVA and at least one of the CORE clockdomains from going idle, which causes PM problems such as these upon system suspend: [ 70.626129] Powerdomain (iva2_pwrdm) didn't enter target state 1 [ 70.626190] Powerdomain (core_pwrdm) didn't enter target state 1 Fix by specifying the actual interface clock in the hwmod data. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
844a3b63 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod data: remove forward declarations, reorganize Reorganize the hwmod data to declare the IP blocks first and the interconnects second. This allows us to remove the forward declarations, which this patch also does. Saves some lines of source data. While here, take the opportunity to synchronize the order of the OMAP44xx hwmod data with the autogenerator output -- it's slightly different due to past mismerges -- and fix a few minor typos and whitespace problems in the files. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
#
0a78c5c5 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod data: convert to link registration Register interconnect links between IP blocks, rather than the IP blocks themselves. (The IP blocks will be registered as a side-effect of registering the links.) The objective is to reduce the number of lines of static data and facilitate the sharing of IP block data between different SoCs. These objectives come at the penalty of increased boot time due to increased computation. While here, fix a few whitespace problems and inaccurate variable names. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
#
43085705 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod data: GPTIMER12 is attached to a separate interconnect GPTIMER12 is attached to the L4 SEC interconnect, not directly to L4 WKUP. Add the L4 SEC interconnect and attach GPTIMER12 to it. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
d69dc648 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod data: add DSS->L3 interconnect for 3430ES1 The OMAP3 hwmod data was missing a DSS->L3 interconnect link for the OMAP3430 ES1 DSS hwmod. Since the hwmod code and data is being modified to register interfaces rather than hwmods, this would result in the DSS hwmod not being registered correctly on OMAP3430ES1. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
4a9efb62 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod data: fix interfaces for the MMC hwmods Commit a52e2ab66d4a9305e1ba64d9b9d25754b6c70895 ("ARM: OMAP3: hwmod data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1") didn't link the MMC hwmods to the interconnects correctly. Future patches will register hwmods by interface, so if this is not fixed, the MMC IP blocks won't be registered. Update the interface data records to point to the correct IP blocks. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
bec93811 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2/3: hwmod data: update old names Some of the 2xxx and 3xxx hwmod data files use the old naming style for hwmods, ending in a "_hwmod". These names are used by the OMAP integration code to map hwmods to platform_devices, so they need to be consistent, or the platform_devices won't be created. Remove the _hwmod suffix to conform with the rest of the OMAP SoC data. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
1f5e6247 |
|
13-Apr-2012 |
Archit Taneja <archit@ti.com> |
ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from VENC slave interface The clocks for all DSS slave interfaces were recently changed to "dss_ick" on OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface previously had "dss_54m_fck" as it's clock which couldn't be autoidled, and hence the OCPIF_SWSUP_IDLE flag was needed. Remove the OCPIF_SWSUP_IDLE flag from VENC interfaces as it's clock is now "dss_ick". This allows the PRCM hardware to autoidle the VENC interface clocks when they are not active, rather than relying on the software to do it, which can keep the interface clocks active unnecessarily. Signed-off-by: Archit Taneja <archit@ti.com> [paul@pwsan.com: add a short description of the fix to the commit log] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
d62bc78a |
|
29-Feb-2012 |
Nishanth Menon <nm@ti.com> |
ARM: OMAP3+: hwmod: add SmartReflex IRQs Add OMAP3 SmartReflex IRQs in hwmod structures. Without these IRQs being registered the SmartReflex driver will be unable to get the IRQ numbers to handle notifications. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
|
#
cea6b942 |
|
29-Feb-2012 |
Shweta Gulati <shweta.gulati@ti.com> |
ARM: OMAP3+: SmartReflex: use voltage domain name in device attributes To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. The value of the field must match the voltage domain names for the binding to be effective. Tested on OMAP3630 SDP, OMAP3530 Beagleboard and OMAP4430 SDP Board. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Shweta Gulati <shweta.gulati@ti.com> Acked by: Nishanth Menon <nm@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
|
#
1d2f56c8 |
|
27-Dec-2011 |
Ilya Yanok <yanok@emcraft.com> |
ARM: OMAP3: hwmod data: register dss hwmods after dss_core dss_core has to be initialized before any other DSS hwmod. Currently this is broken as dss_core is listed in chip/revision specific hwmod lists while other DSS hwmods are listed in common list which is registered first. This patch moves DSS hwmods (except for dss_core) to the separate list which is registered last to ensure that dss_core is already registered. This solves the problem with BUG() in L3 interrupt handler on boards with DSS enabled in bootloader. The long-term fix to this is to ensure modules are set up in dependency order in the hwmod core code. CC: Tomi Valkeinen <tomi.valkeinen@ti.com> CC: Archit Taneja <archit@ti.com> CC: Paul Walmsley <paul@pwsan.com> Signed-off-by: Ilya Yanok <yanok@emcraft.com> [paul@pwsan.com: add notes that this is just a temporary workaround until hwmod dependencies are added] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
b0a85faf |
|
23-Jan-2012 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
ARM: OMAP3: hwmod data: add SYSC_HAS_ENAWAKEUP for dispc dispc's sysc_flags is missing SYSC_HAS_ENAWAKEUP flag. This seems to cause SYNC_LOST errors from the DSS when the power management is enabled. This patch adds the missing SYSC_HAS_ENAWAKEUP flag. Note that there are other flags missing also (clock activity, DSI's sysc flags), but as they are not critical, they will be fixed in the next merge window. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
1ac6d46e |
|
23-Jan-2012 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
ARM: OMAP2+: hwmod data: split omap2/3 dispc hwmod class Currently OMAP2 and 3 share the same omap_hwmod_class and omap_hwmod_class_sysconfig for dispc. However, OMAP3 has sysconfig bits that OMAP2 doesn't have, so we need to split those structs into OMAP2 and OMAP3 specific versions. This patch only splits the structs, without changing the contents. This is a prerequisite for a subsequent fix. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> [paul@pwsan.com: added commit note] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
3e47dc6a |
|
13-Dec-2011 |
Shubhrajyoti D <shubhrajyoti@ti.com> |
ARM: OMAP3+: hwmod data: Add the default clockactivity for I2C For I2C clockactivity field is added for OMAP3 and OMAP4 that defines how the interface (OCP) and functional (system) clocks behave when the I2C module is idle. The configuration of the clock activity bit field (per TRM) is as follows: 0x0: Both clocks can be cut off 0x1: Only OCP clock must be kept active; system clock can be cut off 0x3: Both clocks must be kept active 0x2: Only system clock must be kept active; OCP clock can be cut off The patch makes 0x2(CLOCKACT_TEST_ICLK) the default for OMAP3 and OMAP4. Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
a52e2ab6 |
|
15-Dec-2011 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1 The HSMMC1/HSMMC2 host controllers on OMAP34xx and OMAP3503/3515/3525/3530 chips at ES levels prior to 3.0 can't do multiple block reads[1]. Mark the hwmod data appropriately. Reported by Dave Hylands <dhylands@gmail.com> and Steve Sakoman <sakoman@gmail.com>. Thanks to Steve Sakoman for further help testing this patch. 1. See for example Advisory 2.1.1.128 "MMC: Multiple Block Read Operation Issue" in _OMAP3530/3525/3515/3503 Silicon Errata_ Revision F (October 2010) (SPRZ278F), available from http://focus.ti.com/lit/er/sprz278f/sprz278f.pdf Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Dave Hylands <dhylands@gmail.com> Cc: Steve Sakoman <sakoman@gmail.com>
|
#
de231388 |
|
15-Dec-2011 |
Keshava Munegowda <keshava_mgowda@ti.com> |
ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3 Following 2 hwmod structures are added 1. usb_host_hs The hwmod of usbhs with uhh, ehci and ohci base addresses functional clock and ehci, ohci irqs 2. usb_tll_hs hwmod of usbhs with the TLL base address and irq. Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Reviewed-by: Partha Basak <parthab@india.ti.com> [paul@pwsan.com: fixed whitespace; removed nonexistent TLL->L3 interface; added master & slave for L4 CORE->TLL interface; skip registration on 3430ES1; fixed multiline comment style; updated to apply on Tony's cleanup branch; rebased] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
4bf90f65 |
|
18-Oct-2011 |
Kyle Manna <kyle.manna@fuel7.com> |
ARM: OMAP: hwmod data: Add support for AM35xx UART4/ttyO3 Add hwmod support to enable access to UART4 of the AM35xx series of chips. The UART4 device referenced from the TRM will show up as ttyO3. This was tested on an AM3505. Signed-off-by: Kyle Manna <kyle.manna@fuel7.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
91a36bdb |
|
15-Dec-2011 |
Aaro Koskinen <aaro.koskinen@nokia.com> |
ARM: OMAP: hwmod data: fix the panic on Nokia RM-680 during boot Booting the Linux kernel on Nokia RM-680 board has been broken since 2.6.39 due to the following: [ 0.217193] omap_hwmod: timer12: enabling [ 0.221435] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa304010 [ 0.229431] Internal error: : 1028 [#1] SMP [ 0.233825] Modules linked in: [ 0.237060] CPU: 0 Not tainted (3.2.0-rc4-dirty #46) [ 0.242645] PC is at _update_sysc_cache+0x2c/0x7c [ 0.247589] LR is at _enable+0x1b0/0x2d8 [ 0.251708] pc : [<c0026108>] lr : [<c0026df4>] psr: 40000013 [ 0.251708] sp : ef831f40 ip : ef82f380 fp : c06ac0c0 [ 0.263702] r10: 00000000 r9 : c05dfb2c r8 : ef830000 [ 0.269165] r7 : c0027494 r6 : 00000000 r5 : 00000000 r4 : c06608b0 [ 0.276000] r3 : fa304000 r2 : 00000010 r1 : c0661e28 r0 : c06608b0 [ 0.282806] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.290405] Control: 10c5387d Table: 80004019 DAC: 00000017 [ 0.296417] Process swapper (pid: 1, stack limit = 0xef8302f8) [ 0.302520] Stack: (0xef831f40 to 0xef832000) [ 0.307098] 1f40: c06608b0 c0026df4 c06ad094 c0035120 00000001 c06608b0 00000000 c0027530 [ 0.315612] 1f60: c0027604 ef830000 c05dfb2c c06608b0 c0642ac0 c0025bf0 c0621234 c062120c [ 0.324127] 1f80: c0621738 00000013 ef830000 c05dfb6c c0621234 c0008688 c062c880 c009eadc [ 0.332641] 1fa0: 0000005f 00000000 c0621738 35390013 00000000 00000000 00000000 0000019a [ 0.341156] 1fc0: c0681cf4 c0621234 c062120c c0621738 00000013 00000000 00000000 00000000 [ 0.349670] 1fe0: 00000000 c05d5298 00000000 c05d5200 c0014fa8 c0014fa8 ffff0000 ffff0000 [ 0.358184] [<c0026108>] (_update_sysc_cache+0x2c/0x7c) from [<c0026df4>] (_enable+0x1b0/0x2d8) [ 0.367248] [<c0026df4>] (_enable+0x1b0/0x2d8) from [<c0027530>] (_setup+0x9c/0x170) [ 0.375335] [<c0027530>] (_setup+0x9c/0x170) from [<c0025bf0>] (omap_hwmod_for_each+0x38/0x58) [ 0.384307] [<c0025bf0>] (omap_hwmod_for_each+0x38/0x58) from [<c05dfb6c>] (omap_hwmod_setup_all+0x40/0xa0) [ 0.394409] [<c05dfb6c>] (omap_hwmod_setup_all+0x40/0xa0) from [<c0008688>] (do_one_initcall+0x34/0x180) [ 0.404296] [<c0008688>] (do_one_initcall+0x34/0x180) from [<c05d5298>] (kernel_init+0x98/0x144) [ 0.413452] [<c05d5298>] (kernel_init+0x98/0x144) from [<c0014fa8>] (kernel_thread_exit+0x0/0x8) [ 0.422576] Code: e3130c01 1590304c 0590304c 119320b2 (07932002) [ 0.429046] ---[ end trace 1b75b31a2719ed1c ]--- [ 0.433959] Kernel panic - not syncing: Attempted to kill init! Timer 12 is not necessarily available on non-GP devices (see e.g. http://marc.info/?l=linux-omap&m=129433066521102&w=2), so it should be registered only on GP OMAPs. With this change it's again possible to boot RM-680 into the shell. Tested with 3.2-rc4. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> [paul@pwsan.com: changed subject line] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
7c17c770 |
|
15-Dec-2011 |
Felipe Contreras <felipe.contreras@gmail.com> |
ARM: OMAP: hwmod data: fix iva and mailbox hwmods for OMAP 3 Seems the commit 7e89098 was overly aggressive in adding iva and mailbox hwmods so now they are registered twice. ------------[ cut here ]------------ WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959 omap_hwmod_register+0x104/0x12c() omap_hwmod: iva: _register returned -22 Modules linked in: [<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f970>] (warn_slowpath_common+0x4c/0x64) [<c002f970>] (warn_slowpath_common+0x4c/0x64) from [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) from [<c02fbb44>] (omap3_init_early+0x1c/0x28) [<c02fbb44>] (omap3_init_early+0x1c/0x28) from [<c02f9580>] (setup_arch+0x6b8/0x7a4) [<c02f9580>] (setup_arch+0x6b8/0x7a4) from [<c02f754c>] (start_kernel+0x6c/0x264) [<c02f754c>] (start_kernel+0x6c/0x264) from [<80008040>] (0x80008040) ---[ end trace 1b75b31a2719ed1c ]--- ------------[ cut here ]------------ WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959 omap_hwmod_register+0x104/0x12c() omap_hwmod: mailbox: _register returned -22 Modules linked in: [<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f970>] (warn_slowpath_common+0x4c/0x64) [<c002f970>] (warn_slowpath_common+0x4c/0x64) from [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) [<c002fa08>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) [<c02fdb4c>] (omap_hwmod_register+0x104/0x12c) from [<c02fbb44>] (omap3_init_early+0x1c/0x28) [<c02fbb44>] (omap3_init_early+0x1c/0x28) from [<c02f9580>] (setup_arch+0x6b8/0x7a4) [<c02f9580>] (setup_arch+0x6b8/0x7a4) from [<c02f754c>] (start_kernel+0x6c/0x264) [<c02f754c>] (start_kernel+0x6c/0x264) from [<80008040>] (0x80008040) ---[ end trace 1b75b31a2719ed1d ]--- Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
b923d40d |
|
06-Oct-2011 |
Archit Taneja <archit@ti.com> |
ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader 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: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: R, Sricharan <r.sricharan@ti.com> Signed-off-by: Archit 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: Paul Walmsley <paul@pwsan.com>
|
#
6c3d7e34 |
|
08-Nov-2011 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
ARM: OMAP3: HWMOD: fix DSS clock data The OMAP3 HWMOD data currently contains these errors with DSS clocks: - dss_rfbi is missing ick opt-clock, which is needed for RFBI to calculate timings - dss_dsi is missing ick and sys_clk - dss_venc is missing dss_96m_fck opt-clock, which is required on OMAP3430 - dss_venc's interface and main clocks are wrong, causing VENC to fail to start These problems were temporarily fixed with a DSS patch 9ede365aa6f74428a1f69c21ca1cf21213167576 ("HACK: OMAP: DSS2: clk hack for OMAP2/3"), which can be reverted after this patch (and the similar patches for other OMAPs). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
8c3105ca |
|
08-Nov-2011 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
ARM: OMAP3: HWMOD: Fix DSS reset DSS needs all DSS clocks to be enabled to be able to finish reset properly. Before v3.1-rc1 the omapdss driver was managing clocks and resets correctly. However, when omapdss started using runtime PM at v3.1-rc1, the responsibility for the reset moved to HWMOD framework. HWMOD framework does not currently enable all the DSS clocks when resetting the DSS hardware. This hasn't caused any problems so far, but we may just have been lucky. dss_core's opt-clocks is also missing dss_96m_fck, which is a DSS clock present only on OMAP3430, and thus required on OMAP3430 to finish the reset. This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET and adds the dss_96m_fck opt-clock for dss_core in OMAP3 HWMOD data, fixing the issue. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> [paul@pwsan.com: merged duplicate .flags fields] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
ace90216 |
|
06-Oct-2011 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Commit d6504acd2125984c61dce24727dd3842d0144015 ("OMAP2+: hwmod: remove OMAP_CHIP*") tests the inverse condition of what it should be testing for the return value from omap_hwmod_register(). This causes several IP blocks to not be registered on several OMAP3 family devices. Fixing that bug also unmasked another bug, originally reported by Chase Maupin <chase.maupin@ti.com> and then subsequently by Abhilash K V <abhilash.kv@ti.com>, which caused SmartReflex IP blocks to be registered on SoCs that don't support them. Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for comments on a previous version of the patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Chase Maupin <chase.maupin@ti.com> Cc: Abhilash K V <abhilash.kv@ti.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
7e89098c |
|
07-Oct-2011 |
Abhilash K V <abhilash.kv@ti.com> |
ARM: OMAP: AM35x: remove hwmods that aren't generic Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from the base omap3xxx_hwmods list, so that they can be excluded for am35x. This removes quite a few warnings on boot for AM35x. Signed-off-by: Abhilash K V <abhilash.kv@ti.com> [paul@pwsan.com: dropped 'mailbox class' comments; updated changelog] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
c345c8b0 |
|
20-Sep-2011 |
Tarun Kanti DebBarma <tarun.kanti@ti.com> |
ARM: OMAP2+: dmtimer: convert to platform devices Add routines to converts dmtimers to platform devices. The device data is obtained from hwmod database of respective platform and is registered to device model after successful binding to driver. In addition, capability attribute of each of the timers is added in hwmod database. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Thara Gopinath <thara@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
280a7275 |
|
23-Mar-2011 |
Kevin Hilman <khilman@ti.com> |
OMAP3: voltage: rename "mpu" voltagedomain to "mpu_iva" This voltage domain (a.k.a. VDD1) contains both the MPU and the IVA, so rename appropriately. Also fixup any users of the "mpu" name to use "mpu_iva" Signed-off-by: Kevin Hilman <khilman@ti.com>
|
#
d6504acd |
|
14-Sep-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: remove OMAP_CHIP* At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and replace it instead with chip family, variant, and ES level-specific lists of hwmods to register. Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the AM3517/3505 support, and for other review comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Gražvydas Ignotas <notasas@gmail.com>
|
#
6d3c55fd |
|
10-Jul-2011 |
Avinash.H.M <avinashhm@ti.com> |
OMAP: hwmod: fix the i2c-reset timeout during bootup 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: Avinash.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: Paul Walmsley <paul@pwsan.com>
|
#
4d4441a6 |
|
10-Jul-2011 |
Andy Green <andy@warmcat.com> |
I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr 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: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andy Green <andy.green@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
db791a75 |
|
10-Jul-2011 |
Andy Green <andy@warmcat.com> |
I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision 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: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andy Green <andy.green@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
3e600522 |
|
10-Jul-2011 |
Andy Green <andy@warmcat.com> |
I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c Peter Maydell noticed when running under QEMU he was getting errors reporting 32-bit access to I2C peripheral unit registers that are documented to be 8 or 16-bit only[1][2] The I2C driver is blameless as it wraps its accesses in a function using __raw_writew and __raw_readw, it turned out it is the hwmod stuff. However the hwmod code already has a flag to force a perhipheral unit to only be accessed using 16-bit operations. This patch applies the 16-bit only flag to the 2430, OMAP3xxx and OMAP44xx hwmod structs. 2420 was already correctly marked up as 16-bit. The 2430 change will need testing by TI as arranged in the comments to the previous patch version. When the 16-bit flag is or-ed with other flags, it is placed first as requested in comments. [1] OMAP4430 Technical reference manual section 23.1.6.2 [2] OMAP3530 Techincal reference manual section 18.6 Cc: patches@linaro.org Cc: Ben Dooks <ben-linux@fluff.org> Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andy Green <andy.green@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
273b9465 |
|
09-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: share identical omap_hwmod_class, omap_hwmod_class_sysconfig arrays 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: Paul Walmsley <paul@pwsan.com>
|
#
d826ebfa |
|
09-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: share identical omap_hwmod_dma_info arrays To reduce kernel source file data duplication, share struct omap_hwmod_dma_info arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
bc614958 |
|
09-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays 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: Paul Walmsley <paul@pwsan.com>
|
#
0d619a89 |
|
09-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: share identical omap_hwmod_mpu_irqs arrays To reduce kernel source file data duplication, share struct omap_hwmod_mpu_irqs arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
212738a4 |
|
09-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays 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: Paul Walmsley <paul@pwsan.com>
|
#
ded11383 |
|
09-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: share identical omap_hwmod_addr_space arrays To reduce kernel source file data duplication, share struct omap_hwmod_addr_space arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
78183f3f |
|
09-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays 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: Paul Walmsley <paul@pwsan.com>
|
#
f95440ca |
|
05-Apr-2011 |
Avinash.H.M <avinashhm@ti.com> |
OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup. 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: Avinash.H.M <avinashhm@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
1286eeb2 |
|
19-Apr-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod data: Fix wrong dma_system end address 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: Michael Fillinger <m-fillinger@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
affe360d |
|
23-Feb-2011 |
Archit Taneja <archit@ti.com> |
OMAP: DSS2: Have separate irq handlers for DISPC and DSI 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: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
#
872462cd |
|
31-Jan-2011 |
Sumit Semwal <sumit.semwal@ti.com> |
OMAP2PLUS: clocks: Align DSS clock names and roles Currently, clock database has <dev, clock-name> tuples for DSS2. Because of this, the clock names are different across different OMAP platforms. This patch aligns the DSS2 clock names and roles across OMAP 2420, 2430, 3xxx, 44xx platforms in the clock databases, hwmod databases for opt-clocks, and DSS clock handling. This ensures that clk_get/put/enable/disable APIs in DSS can use uniform role names. Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
#
2f4dd595 |
|
10-Mar-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP3: wdtimer: Fix CORE idle transition The HW superwised smart idle for wdtimer in OMAP3 prevents CORE power domain idle transitions. Disable it by swithing to SW supervised transitions. This could be a hardware bug in the OMAP3 wdtimer2 block. Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@ti.com>
|
#
d73d65fa |
|
03-Mar-2011 |
Avinash.H.M <avinashhm@ti.com> |
omap: hwmod: add syss reset done flags to omap2, omap3 hwmods 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: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Avinash.H.M <avinashhm@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
478f478b |
|
25-Feb-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP3: hwmod data: Remove masters port links for interconnects. Master ports from interconnect are generating some annoying circular references that become tricky to handle if we have to dynamically remove some IP on some variant platforms. Since they are not used for the moment, and since we can still build that relation using the reverse relation (slave port from the IP toward master port of the interconnect), let remove them for the moment like it is done on OMAP4. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com>
|
#
b9ccf8af |
|
10-Mar-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP3: hwmod data: Fix incorrect SmartReflex -> L4 CORE interconnect links Commit d34427267186827dfd62bd8cf726601fffb22534 ("OMAP3: PM: Adding smartreflex hwmod data") added data that claims that the L4 CORE has two slave interfaces that originate from the SmartReflex modules, omap3_l4_core__sr1 and omap3_l4_core__sr2. But as those two data structure records show, it's L4 CORE that has a master port towards SR1 and SR2. Move the incorrect data from slaves list to master list. Based on a path by Paul Walmsley <paul@pwsan.com> https://patchwork.kernel.org/patch/623171/ That is based on a patch by Benoît Cousson <b-cousson@ti.com>: https://patchwork.kernel.org/patch/590561/ Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Cc: Sanjeev Premi <premi@ti.com> Cc: Thara Gopinath <thara@ti.com>
|
#
c39bee8a |
|
03-Mar-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2/3: VENC hwmod: add OCPIF_SWSUP_IDLE flag to interface 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: Paul 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: Tony Lindgren <tony@atomide.com>
|
#
4bb194dc |
|
08-Feb-2011 |
sricharan <r.sricharan@ti.com> |
OMAP3: hwmod_data: Add address space and irq in L3 hwmod. Add the address spaces, irqs of the l3 interconnect to the hwmod data. The hwmod changes are aligned with Benoit Cousson. Signed-off-by: sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
|
#
7328ff4d |
|
25-Feb-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP: smartreflex: move plat/smartreflex.h to mach-omap2/smartreflex.h There's no reason for this header file to be in plat-omap/include/plat/smartreflex.h. The hardware devices are in OMAP2+ SoCs only. Leaving this header file in plat-omap causes problems due to cross-dependencies with other header files that should live in mach-omap2/. Thanks to Benoît Cousson <b-cousson@ti.com> for suggesting the removal of the smartreflex.h include from the OMAP3xxx hwmod data. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
#
6ab8946f |
|
01-Mar-2011 |
Kishore Kadiyala <kishore.kadiyala@ti.com> |
OMAP: hwmod data: Add dev_attr and use in the host driver Add a device attribute to hwmod data of omap2430, omap3, omap4. Currently the device attribute holds information regarding dual volt MMC card support by the controller which will be later passed to the host driver via platform data. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Acked-by: Benoit Cousson<b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
b163605e |
|
01-Mar-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP3: hwmod data: Add HSMMC Update the omap3 hwmod data with the HSMMC info. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
550c8092 |
|
28-Feb-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: rename some init functions 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: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com>
|
#
ce722d26 |
|
23-Feb-2011 |
Thara Gopinath <thara@ti.com> |
OMAP3: hwmod data: add dmtimer Add dmtimer data. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
|
#
8b1906f1 |
|
24-Feb-2011 |
Kishon Vijay Abraham I <kishon@ti.com> |
OMAP3: hwmod: add dev_attr for McBSP sidetone Since the sidetone block is tightly coupled to the mcbsp, sidetone information is directly added to mcbsp2 & 3 hwmod dev_attr. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
dc48e5fc |
|
24-Feb-2011 |
Charulatha V <charu@ti.com> |
OMAP3: hwmod data: Add McBSP Add McBSP hwmod data for OMAP3. Added a revision member inorder to facilitate the driver to differentiate between mcbsp in different omap. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
0f9dfdd3 |
|
24-Feb-2011 |
Felipe Contreras <felipe.contreras@gmail.com> |
OMAP3: hwmod data: add mailbox data Mailbox hwmod data for omap3. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
e04d9e1e |
|
23-Jan-2011 |
Senthilvadivu Guruswamy <svadivu@ti.com> |
OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC Hwmod needs database of all IPs in a system. This patch generates the hwmod database for Display Sub System applicable for OMAP3430 and OMAP36xx. DSS is also considered as an IP as DISPC, RFBI and named as dss_core. For all the IP modules in DSS, same clock is needed for enabling. Hwmod sees DSS IPs as independent IPs, so same clock has to be repeated for .main_clk in each IP. This patch defines separate hwmod databases for OMAP3430ES1 and (OMAP3430ES2 and OMAP36xx) as OMAP3430ES1 does not have IDLEST bit to poll on for dss IP, and also the firewall regions are different between 3430es1 and later. Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
#
0f616a4e |
|
17-Feb-2011 |
Charulatha V <charu@ti.com> |
OMAP3: hwmod data: Add McSPI Update omap3 hwmod data file with McSPI info. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
273ff8c3 |
|
16-Feb-2011 |
Hema HK <hemahk@ti.com> |
AM35xx: hwmod data: Add USBOTG AM35xx hwmod data structures are populated for USBOTG with base address, L3 and L4 interface clocks and IRQ. Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
|
#
870ea2b8 |
|
16-Feb-2011 |
Hema HK <hemahk@ti.com> |
OMAP3xxx: hwmod data: Add USBOTG OMAP3 hwmod data structures are populated for USBOTG with base address, L3 and L4 interface clocks, IRQs and sysconfig register details. This is applicable for OMAP3430 amd OMAP3630. As per OMAP USBOTG specification, need to configure the USBOTG to smart idle/standby or no idle/standby during data transfer and force idle/standby when not in use to support retention and offmode. By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework will take care of configuring to no idle/standby when module is enabled and force idle/standby when idled. Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
|
#
d3442726 |
|
29-May-2010 |
Thara Gopinath <thara@ti.com> |
OMAP3: PM: Adding smartreflex hwmod data This patch adds the smartreflex hwmod data for OMAP3430 and OMAP3630. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
#
ff2516fb |
|
21-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism 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: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Charulatha Varadarajan <charu@ti.com>
|
#
01438ab6 |
|
20-Dec-2010 |
G, Manjunath Kondaiah <manjugk@ti.com> |
OMAP3: hwmod data: add system DMA Add OMAP3 DMA hwmod data Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
70034d38 |
|
07-Dec-2010 |
Varadarajan, Charulatha <charu@ti.com> |
OMAP3: hwmod data: Add GPIO Add GPIO hwmod data for OMAP3 Also remove "omap34xx.h" header file as it is not required anymore. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
#
4fe20e97 |
|
21-Sep-2010 |
Rajendra Nayak <rnayak@ti.com> |
OMAP3: hwmod: add I2C hwmods for OMAP3430 Add hwmod structures for I2C controllers on OMAP3430. This patch was developed in collaboration with Paul Walmsley <paul@pwsan.com>. OMAP3 fixes for correct IDLEST bit monitoring from G, Manjunath Kondaiah <manjugk@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: G, Manjunath Kondaiah <manjugk@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
#
046465b7 |
|
27-Sep-2010 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP2/3: UART: add omap_hwmod data for UARTs 1-4 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: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
#
6b667f88 |
|
23-Sep-2010 |
Varadarajan, Charulatha <charu@ti.com> |
OMAP3: hwmod data: Add watchdog timer Add watchdog timer hwmod data for OMAP3 chip Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
#
540064bf |
|
26-Jul-2010 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP3: hwmod data: add data for OMAP3 IVA2 Add hwmod data for IVA2 module on OMAP3. Naming of "iva" instead of "iva2" to be aligned with OMAP4 naming done by Benoit Cousson. Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
4a7cf90a |
|
26-Jul-2010 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP2&3: hwmod: Replace l3 -> l3_main Replace all the struct that contain l3 with l3_main in order to be consistent with the OMAP4 naming convention. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
fa98347e |
|
26-Jul-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2&3: hwmod: Remove _hwmod prefix in name string 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: Benoit Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
2eb1875d |
|
26-Jul-2010 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST 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: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
#
5c2c0296 |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Rename hwmod name for the MPU 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: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
|
#
43b40992 |
|
22-Feb-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP hwmod: add hwmod class support 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: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Cc: Thara Gopinath <thara@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
#
7359154e |
|
22-Feb-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP hwmod: convert header files with static allocations into C files 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 82e9bd588563c4e22ebb55b684ebec7e310cc715. 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: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|