summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'omap-cleanup-hwmod-for-v3.5' of ↵Olof Johansson2012-05-0910-7815/+5661
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup Clean up of hwmod to shrink down the IP block interconnections By Paul Walmsley via Paul Walmsley (1) and Tony Lindgren (1) * tag 'omap-cleanup-hwmod-for-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (29 commits) ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomain ARM: OMAP3: hwmod data: fix IVA interface clock ARM: OMAP2xxx: hwmod data: share common interface data ARM: OMAP2xxx: hwmod data: share common hwmods between OMAP2420 and OMAP2430 ARM: OMAP2+: hwmod data: remove forward declarations, reorganize ARM: OMAP: hwmod: remove code support for direct hwmod registration ARM: OMAP2+: hwmod data: convert to link registration ARM: OMAP2+: hwmod: add support for link registration ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing it ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_if ARM: OMAP2+: hwmod: add _find_mpu_rt_port() ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bits ARM: OMAP4: hwmod data: uncomment some "excluded" hwmods ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriately ARM: OMAP4: hwmod data: remove bandgap hwmod ARM: OMAP3: hwmod data: GPTIMER12 is attached to a separate interconnect ARM: OMAP3: hwmod data: add DSS->L3 interconnect for 3430ES1 ARM: OMAP3: hwmod data: fix interfaces for the MMC hwmods ARM: OMAP2/3: hwmod data: update old names ... Signed-off-by: Olof Johansson <olof@lixom.net>
| * Merge tag 'omap-cleanup-b-for-3.5' of ↵Tony Lindgren2012-04-1910-7821/+5688
| |\ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-hwmod Clean up various aspects of the OMAP hwmod code, which is the IP block control code for OMAP SoCs. In particular, this series results in a considerable diffstat savings by changing the way that IP block interconnections are defined.
| | * ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSPPaul Walmsley2012-04-192-4/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | N800 logs this message on boot: [ 0.182281] omap_hwmod: iva: cannot be enabled for reset (3) Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2 hwmod for OMAP2430. There is still more information to be added, but this should resolve the immediate issue. Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | * ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomainPaul Walmsley2012-04-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP3: hwmod data: fix IVA interface clockPaul Walmsley2012-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP2xxx: hwmod data: share common interface dataPaul Walmsley2012-04-194-518/+324
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several struct omap_hwmod_ocp_if records can be shared between OMAP2420 and OMAP2430. Move these shared records out of the chip-specific files into mach-omap2/omap_hwmod_2xxx_interconnect_data.c. This should save some memory and source lines, at the cost of readability. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2xxx: hwmod data: share common hwmods between OMAP2420 and OMAP2430Paul Walmsley2012-04-194-1211/+740
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the link registration conversion, it's much easier to share some hwmod data between OMAP2420 and 2430. Move the shareable data into a common file. This should save some memory and lines of source, at the cost of readability. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod data: remove forward declarations, reorganizePaul Walmsley2012-04-194-4268/+3963
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP: hwmod: remove code support for direct hwmod registrationPaul Walmsley2012-04-192-98/+33
| | | | | | | | | | | | | | | | | | | | | | | | Now that the data has been converted to use interface registration, we can remove the (now unused) direct hwmod registration code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod data: convert to link registrationPaul Walmsley2012-04-194-2182/+370
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP2+: hwmod: add support for link registrationPaul Walmsley2012-04-192-16/+305
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing itPaul Walmsley2012-04-191-24/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An IP block's MPU interface port only needs to be found once. The result can be cached to speed further lookups. This patch consolidates these two steps into a single function. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_ifPaul Walmsley2012-04-191-48/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To reduce the number of lines of data in the OMAP portion of the Linux code base, subsequent patches will remove the lists of hwmod interconnect links from the static hwmod data. These lists will be built dynamically during boot. To ease this transition, this patch centralizes the way that interconnect links are iterated into a single function, _fetch_next_ocp_if(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: add _find_mpu_rt_port()Paul Walmsley2012-04-191-10/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most IP blocks on the OMAP SoC have an interconnect link that is intended to be used by the MPU to communicate with the IP block. Several parts of the hwmod code need to be able to identify this link. Currently, this is open-coded. However, future patches will change the way that interconnect links are represented and will make identifying the link more complex. So to avoid code duplication, this patch centralizes the MPU port link identification code into a new function, _find_mpu_rt_port(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bitsPaul Walmsley2012-04-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the OCP_* register offsets in the struct omap_hwmod_class_sysconfig to 32 bits. This is required to add the OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16 bits. Another possible solution may be to simply add a single 16 bit offset field in this structure, and to add code to factor that offset into all OCP_* register accesses. This would save some memory, since almost no modules need 32 bit offsets. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP4: hwmod data: uncomment some "excluded" hwmodsPaul Walmsley2012-04-191-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some hwmods were commented out from the OMAP4 data, under the theory that they shouldn't be added until drivers were ready. But part of the utility of the hwmod code is that it can reset and properly initialize IP blocks that have no drivers associated with them. Rather than commenting the links in the future hwmod data conversion patches, discussing this with Benoit, it seems best to simply uncomment them now. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriatelyPaul Walmsley2012-04-192-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the OMAP4 links was missing OCP_USER flags, since it was only used by the DSP initiator, and we did not have an OCP_USER_DSP flag. Future patches will switch the hwmod code and data to register interfaces, rather than hwmods, and it will be mandatory for all interfaces to have at least one user bit set. This patch resolves the issue by adding OCP_USER_DSP and marking the DSP-IVA interface appropriately. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP4: hwmod data: remove bandgap hwmodPaul Walmsley2012-04-191-30/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 407a6888f7362cb3dabe69ea6d9dcf3c750dc56a ("OMAP4: hwmod data: Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU") adds a hwmod for the bandgap die temperature sensor IP block. This IP block has no interconnect port or firewall region, nor does it have an independent register space or OCP control registers. Its registers are embedded in the System Control Module (SCM) IP block. So it appears that the bandgap device should be created by the SCM driver. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP3: hwmod data: GPTIMER12 is attached to a separate interconnectPaul Walmsley2012-04-191-3/+25
| | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP3: hwmod data: add DSS->L3 interconnect for 3430ES1Paul Walmsley2012-04-191-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP3: hwmod data: fix interfaces for the MMC hwmodsPaul Walmsley2012-04-191-8/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP2/3: hwmod data: update old namesPaul Walmsley2012-04-193-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * ARM: OMAP2+: timer: use a proper interface to get hwmod dataPaul Walmsley2012-04-191-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arch/arm/mach-omap2/timer.c pokes around inside the hwmod data structures. Since the hwmod data structures are about to change, this code will break. This patch modifies the timer code to use recently-added hwmod functions instead. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
| | * ARM: OMAP2+: hwmod: add omap_hwmod_get_resource_byname()Paul Walmsley2012-04-192-0/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The timer integration code pokes around in hwmod data structures. Those data structures are about to change. Define a function, omap_hwmod_get_resource_byname(), for the timer integration code to use instead. The original patch has been changed to use struct resource by Tony's request, although the caller of this function should not be a driver._ Platform drivers should get their data through the regular platform_* functions; DT drivers through the appropriate of_* functions. This a function is only for use by OMAP core code in arch/arm/*omap*. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com>
| | * ARM: OMAP2+: hwmod: provide a function to return the address space of the MPU RTPaul Walmsley2012-04-191-24/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A subsequent patch will need to know the struct omap_hwmod_addr_space record corresponding to the module's register target, used by the MPU. So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space(). Then modify its sole current user, _populate_mpu_rt_base(), to extract the MPU RT base address itself from the struct omap_hwmod_addr_space record. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: revise hardreset behaviorPaul Walmsley2012-04-191-56/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the way that hardreset lines are handled by the hwmod code. Hardreset lines are generally associated with initiator IP blocks. Prior to this change, the hwmod code expected to control hardreset lines itself, asserting them on shutdown and deasserting them upon enable. But driver authors inside TI have commented to us that their drivers require direct control over these lines. Unfortunately, these drivers haven't been posted publicly yet, so it's hard to determine exactly what is needed, a priori. This change attempts to set forth some reasonable semantics that should be an improvement over the current code. The semantics implemented by this patch are as follows: - If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all associated hardreset lines during IP block setup. This is intended to place the IP blocks into a known state that will not interfere with other devices during kernel boot. - IP blocks with hardreset lines will not be automatically enabled or idled during setup. Instead, they will be left in the INITIALIZED state. - When the hwmod code is asked to enable, idle, or shutdown an IP block with asserted hardreset lines, the hwmod code will do nothing. The driver integration code must do the remaining work needed to control these IP blocks. Once this driver integration code is posted to the lists, hopefully we can consolidate it and move it inside the hwmod code. Custom reset functions for IP blocks with hardreset lines still should be supported and are strongly endorsed. It is intended that every subsystem with hardreset lines should have a custom reset function that can place their subsystem into quiescent idle with the hardreset lines deasserted. This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42 ("OMAP: hwmod: Add hardreset management support"). Later code reorganizations caused the sequencing of the code from this patch to be changed, anyway. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: reorganize and document the reset and configuration processPaul Walmsley2012-04-191-32/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reorganize the code involved in resetting and configuring an IP block to make it easier to read and maintain. This involves improving documentation, splitting some large functions up into smaller ones to better conform with Documentation/CodingStyle, and removing some unnecessary code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: reorganize and document the initialization processPaul Walmsley2012-04-191-57/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reorganize the code involved in initializing the internal data for each hwmod to make it easier to read and maintain. This involves improving documentation and removing some duplicated and unnecessary code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: revise the IP block reset processPaul Walmsley2012-04-191-23/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revise the IP block reset process. This patch ensures that the OCP_SYSCONFIG registers are reloaded after a custom reset. Since OCP_SYSCONFIG bits are cleared during reset, they should be reprogrammed unless the IP block is being left in reset. (The only IP blocks that are left in reset are IP blocks with hardreset lines and no custom reset function.) If the IP block is left in reset, then it is inaccessible to the MPU, and an access to the OCP_SYSCONFIG register will cause an abort. This version incorporates comments from Omar Ramirez Luna <omar.ramirez@ti.com> to skip the OCP_SYSCONFIG access after asserting hardreset lines. This allows the MMU (IOMMU) IP block, which has both hardreset lines and an OCP_SYSCONFIG register. Also, ignore _ocp_softreset() errors if the IP block doesn't include a softreset bit. This is needed since a subsequent patch will start taking the return value of the _reset() function seriously. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
| | * ARM: OMAP4: hwmod data: remove pseudo-hwmods associated with hardreset linesPaul Walmsley2012-04-181-98/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the pseudo-hwmods associated with hardreset lines from the OMAP4 data file. Future patches will convert this data to register hwmods by interfaces, rather than registering hwmods directly. The pseudo-hwmods aren't associated with any interfaces, so this will create a problem. After this change, the hwmod code will reset processor IPs at the hwmod level, rather than by individual hardreset lines. So, for example, if the IVA device driver code wishes to place one of the sequencer cores into reset, while leaving the other active, it must do so itself by calling the appropriate PRM functions. This patch will cause a change in the initialization behavior of the DSP, IVA, and IPU. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| | * ARM: OMAP2+: hwmod: control all hardreset lines attached to a hwmodPaul Walmsley2012-04-181-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parts of the hwmod code test to see if a module has one and only one hardreset line before taking an action. It seems more appropriate to control all hardreset lines associated with a hwmod, not just one. It so happens that with the current hwmod data, this patch will not change any behavior, since hwmods with hardreset lines have only one hardreset line associated with them, and 'pseudo-hwmods' are used to handle the other hardreset lines. But future hwmod data patches to remove the pseudo-hwmods will change this. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* | | Merge tag 'omap-cleanup-sparse-for-v3.5' of ↵Olof Johansson2012-05-0952-163/+158
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup Sparse and cppcheck warning fixes By Paul Walmsley via Paul Walmsley (1) and Tony Lindgren (1) * tag 'omap-cleanup-sparse-for-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: clean up some cppcheck warnings ARM: OMAP1: board files: deduplicate and clean some NAND-related code ARM: OMAP: USB: remove unnecessary sideways include ARM: OMAP: DMA: use constant array maximum, drop some LCD DMA code ARM: OMAP: OCM RAM: use memset_io() when clearing SRAM ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warnings ARM: OMAP2+: GPMC: resolve type-conversion warning from sparse ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus ARM: OMAP1: OCPI: move to mach-omap1/ ARM: OMAP: add includes for missing prototypes ARM: OMAP2+: declare file-local functions as static Signed-off-by: Olof Johansson <olof@lixom.net>
| * \ \ Merge tag 'omap-cleanup-a2-for-3.5' of ↵Tony Lindgren2012-04-1852-163/+158
| |\ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-sparse Resolve static analysis warnings generated by files in arch/arm/mach-omap1, arch/arm/mach-omap2, and arch/arm/plat-omap. Fixes all but one sparse warning and most of the useful cppcheck warnings (excepting the warnings generated by the dmtimer integration code which is going up via 3.4-rc fixes)
| | * | ARM: OMAP2+: clean up some cppcheck warningsPaul Walmsley2012-04-1716-57/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Resolve some warnings identified by cppcheck in arch/arm/mach-omap2: [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero. [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247 [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57 [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else. [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354 [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used Some of them are pretty good catches, such as gpio.c:56 and usb-tusb6010.c:129. Thanks to Jarkko Nikula for some comments on the sscanf() warnings. It seems that the kernel sscanf() ignores the field width anyway for the %d format, so those changes have been dropped from this second version. Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing out that a variable was unnecessarily marked static in the board-omap3evm.c change. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Charulatha Varadarajan <charu@ti.com> Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c
| | * | ARM: OMAP1: board files: deduplicate and clean some NAND-related codePaul Walmsley2012-04-137-65/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The H2, H3, Perseus2, and FSample board files all contain the same duplicated code to handle NAND commands. That code is missing some casts around conversions from unsigned long to void __iomem *. Consolidate the duplicated code into a new file, arch/arm/mach-omap1/board-nand.c. Resolve the sparse warnings by adding appropriate casts: arch/arm/mach-omap1/board-h2.c:193:9: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/board-h2.c:193:9: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap1/board-h2.c:193:9: got unsigned long arch/arm/mach-omap1/board-perseus2.c:157:9: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/board-perseus2.c:157:9: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap1/board-perseus2.c:157:9: got unsigned long arch/arm/mach-omap1/board-fsample.c:199:9: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/board-fsample.c:199:9: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap1/board-fsample.c:199:9: got unsigned long arch/arm/mach-omap1/board-h3.c:195:9: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/board-h3.c:195:9: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap1/board-h3.c:195:9: got unsigned long Thanks to Arnd Bergmann <arnd@arndb.de> for suggesting a cleaner implementation of omap1_nand_cmd_ctl(), avoiding some casts. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Brian Swetland <swetland@google.com> Cc: Imre Deak <imre.deak@nokia.com> Cc: Greg Lonnon <glonnon@ridgerun.com> Cc: Kevin Hilman <kjh@hilman.org> Cc: Kevin Hilman <khilman@ti.com> Cc: Arnd Bergmann <arnd@arndb.de>
| | * | ARM: OMAP: USB: remove unnecessary sideways includePaul Walmsley2012-04-131-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the include of mach-omap2/common.h from plat-omap/usb.c. It appears to be unneeded. Removing it also resolves the sparse warning: arch/arm/plat-omap/../mach-omap2/common.h:183:12: warning: symbol 'omap_intc_of_init' was not declared. Should it be static? Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | * | ARM: OMAP: DMA: use constant array maximum, drop some LCD DMA codePaul Walmsley2012-04-132-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gcc can apparently handle stack-allocated arrays that use a dynamic variable as the array maximum. Rather than using a mutable quantity, simply use a constant maximum possible size. To me, code clarity is improved; and it also avoids the following sparse warnings: arch/arm/plat-omap/dma.c:886:40: error: bad constant expression arch/arm/plat-omap/dma.c:892:17: error: cannot size expression arch/arm/plat-omap/dma.c:970:40: error: bad constant expression arch/arm/plat-omap/dma.c:972:17: error: cannot size expression Also drop some dead code from the OMAP1 LCD DMA code: arch/arm/mach-omap1/lcd_dma.c:80:6: warning: symbol 'omap_set_lcd_dma_src_port' was not declared. Should it be static? Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | * | ARM: OMAP: OCM RAM: use memset_io() when clearing SRAMPaul Walmsley2012-04-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently treat the OCM RAM memory as memory that hangs off an I/O bus, so use memset_io() to clear it rather than memset(). This also takes care of this sparse warning: arch/arm/plat-omap/sram.c:199:9: warning: cast removes address space of expression There is still one SRAM-related sparse warning, but it appears that fixing it correctly will take some time and thought. N.B., at some point, the OCM RAM IP block interface code should probably be reimplemented as an MTD device or something similar under drivers/. Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | * | ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warningsPaul Walmsley2012-04-134-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sparse warns when 0 is passed to a function expecting a pointer argument. Resolve these warnings by replacing the 0 with NULL. arch/arm/plat-omap/include/plat/dmtimer.h:319:34: warning: Using plain integer as NULL pointer arch/arm/plat-omap/include/plat/dmtimer.h:324:35: warning: Using plain integer as NULL pointer arch/arm/mach-omap2/irq.c:294:22: warning: Using plain integer as NULL pointer arch/arm/mach-omap1/board-palmz71.c:292:50: warning: Using plain integer as NULL pointer arch/arm/mach-omap1/board-palmz71.c:295:73: warning: Using plain integer as NULL pointer arch/arm/mach-omap1/ams-delta-fiq.c:105:63: warning: Using plain integer as NULL pointer Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | * | ARM: OMAP2+: GPMC: resolve type-conversion warning from sparsePaul Walmsley2012-04-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arch/arm/mach-omap2/gpmc.c passes a return value from ioremap() as the fifth argument to request_irq() without casting it. This causes sparse to generate the following warning: arch/arm/mach-omap2/gpmc.c:759:63: warning: incorrect type in argument 5 (different address spaces) arch/arm/mach-omap2/gpmc.c:759:63: expected void *dev arch/arm/mach-omap2/gpmc.c:759:63: got void [noderef] <asn:2>*static [toplevel] [assigned] gpmc_base It turns out that it's not necessary to pass this. gpmc_base is a file-scoped static variable, the ISR is located in the same file ... and the ISR doesn't even touch the passed-in variable. So, just replace it with NULL in request_irq(). Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | * | ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI busPaul Walmsley2012-04-132-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OMAP1 OHCI driver needs to enable the OCPI IP block before it can work. Previously, the driver was simply calling a symbol defined in the OMAP platform code, but this is incorrect: drivers should be fully decoupled from platform and architecture code. So instead, modify the driver to call through a platform_data function pointer instead. We skip any DT aspect, since OMAP1 is not scheduled to be converted to DT in the near future. This resolves the following sparse warning: It also gets rid of a cpu_is_omap16xx() call in a driver. In the long term, it probably makes sense to move the OCPI bus code to somewhere under drivers/. This should avoid the whole platform_data/DT issue with this function. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Anand Gadiyar <gadiyar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com>
| | * | ARM: OMAP1: OCPI: move to mach-omap1/Paul Walmsley2012-04-134-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the OMAP1 OCPI "bus" code to arch/arm/mach-omap1, since it is only used on OMAP1 devices. In the long term, it probably makes sense to move the OCPI bus code to somewhere under drivers/. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
| | * | ARM: OMAP: add includes for missing prototypesPaul Walmsley2012-04-1313-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several C files in arch/arm/mach-omap* and arch/arm/plat-omap declare functions that are used by other files, but don't include the header file where the prototype is declared. This results in the following warnings from sparse: arch/arm/mach-omap2/irq.c:114:5: warning: symbol 'omap_irq_pending' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:186:13: warning: symbol 'omap2_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:191:13: warning: symbol 'omap3_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:196:13: warning: symbol 'ti81xx_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:233:39: warning: symbol 'omap2_intc_handle_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:242:6: warning: symbol 'omap_intc_save_context' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'omap_intc_restore_context' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:291:6: warning: symbol 'omap3_intc_suspend' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:297:6: warning: symbol 'omap3_intc_prepare_idle' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:306:6: warning: symbol 'omap3_intc_resume_idle' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:312:39: warning: symbol 'omap3_intc_handle_irq' was not declared. Should it be static? arch/arm/mach-omap2/omap-secure.c:59:12: warning: symbol 'omap_secure_ram_reserve_memblock' was not declared. Should it be static? arch/arm/mach-omap2/board-zoom-display.c:133:13: warning: symbol 'zoom_display_init' was not declared. Should it be static? arch/arm/plat-omap/common.c:73:13: warning: symbol 'omap_init_consistent_dma_size' was not declared. Should it be static? arch/arm/mach-omap1/irq.c:61:5: warning: symbol 'omap_irq_flags' was not declared. Should it be static? arch/arm/mach-omap1/irq.c:179:13: warning: symbol 'omap1_init_irq' was not declared. Should it be static? arch/arm/mach-omap1/reset.c:11:6: warning: symbol 'omap1_restart' was not declared. Should it be static? Fix by including the appropriate header files. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Senthilvadivu Guruswamy <svadivu@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
| | * | ARM: OMAP2+: declare file-local functions as staticPaul Walmsley2012-04-137-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several function declarations used only in the files in which they're declared should include the static keyword, but don't: arch/arm/mach-omap2/serial.c:248:6: warning: symbol 'cmdline_find_option' was not declared. Should it be static? arch/arm/mach-omap2/omap-wakeupgen.c:259:6: warning: symbol 'irq_sar_clear' was not declared. Should it be static? arch/arm/mach-omap2/board-rx51-peripherals.c:878:27: warning: symbol 'rx51_vibra_data' was not declared. Should it be static? arch/arm/mach-omap2/board-rx51-peripherals.c:882:27: warning: symbol 'rx51_audio_data' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:201:29: warning: symbol 'omap_panda_wlan_data' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:393:24: warning: symbol 'omap4_panda_dvi_device' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:403:12: warning: symbol 'omap4_panda_dvi_init' was not declared. Should it be static? arch/arm/mach-omap2/board-omap4panda.c:464:6: warning: symbol 'omap4_panda_display_init' was not declared. Should it be static? arch/arm/mach-omap2/hsmmc.c:434:6: warning: symbol 'omap_init_hsmmc' was not declared. Should it be static? arch/arm/mach-omap2/hwspinlock.c:31:12: warning: symbol 'hwspinlocks_init' was not declared. Should it be static? arch/arm/mach-omap1/timer.c:58:12: warning: symbol 'omap1_dm_timer_init' was not declared. Should it be static? arch/arm/mach-omap1/fpga.c:90:6: warning: symbol 'innovator_fpga_IRQ_demux' was not declared. Should it be static? Mark all of these as static. Thanks to Arnd Bergmann <arnd@arndb.de> for pointing out a typo in the original patch description. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Govindraj R <govindraj.raja@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: David Anders <x0132446@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
* | | | Merge branch 'ux500-del-u5500-for-arm-soc' of ↵Arnd Bergmann2012-05-0226-2635/+11
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into next/cleanup Linus Walleij <linus.walleij@linaro.org> writes: Delete U5500 after obsoletion of this ASIC, including two patches to the MFD subsystem that have been ACK:ed by Samuel Ortiz. * 'ux500-del-u5500-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson: mfd/ab5500: delete AB5500 support mfd/db5500-prcmu: delete DB5500 PRCMU support ARM: ux500: delete U5500 support Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * | | | ARM: ux500: delete U5500 supportLinus Walleij2012-05-0226-2635/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This platform has been obsoleted and was only available inside of ST-Ericsson, no users of this code are left in the world. This deletes the core U5500 support entirely in the same manner as the obsoleted U8500 silicon was previously deleted. The cpu_is_u5500() macros that can read out the CPU ID is left until the next kernel cycle, this makes it possible to merge deletion of dependent drivers without breakage. This also has the upside of removing the mailbox driver which was our only driver that was outside the drivers/* hiearchy, now the machine directory only handles machines and nothing else. Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Rabin Vincent <rabin.vincent@stericsson.com> Cc: Jonas Aberg <jonas.aberg@stericsson.com> Cc: Per Forlin <per.forlin@stericsson.com> Cc: Ulf Hansson <ulf.hansson@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | | | | Merge tag 'imx-cleanup' of git://git.pengutronix.de/git/imx/linux-2.6 into ↵Arnd Bergmann2012-05-0268-374/+338
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | next/cleanup From: Sascha Hauer <s.hauer@pengutronix.de> ARM: i.MX cleanups for 3.5 * tag 'imx-cleanup' of git://git.pengutronix.de/git/imx/linux-2.6: (5 commits) ARM: mx53: fix pad definitions for MX53_PAD_EIM_D28__I2C1_SDA and MX53_PAD_GPIO_8__CAN1_RXCAN ARM: imx/eukrea_mbimx27-baseboard: fix typo in error message ARM: i.MX51 iomux: add missed definitions for SION-bit and mode for some pads arm: imx: add missing select IMX_HAVE_PLATFORM for MACH_MX35_3DS in Kconfig arm: imx: make various struct sys_timer static Includes an update to 3.4-rc4 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * | | | | ARM: mx53: fix pad definitions for MX53_PAD_EIM_D28__I2C1_SDA and ↵Lothar Waßmann2012-05-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MX53_PAD_GPIO_8__CAN1_RXCAN MX53_PAD_EIM_D28__I2C1_SDA uses an undefined PAD_CTRL_I2C MX53_PAD_GPIO_8__CAN1_RXCAN has an incorrect input_select value Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
| * | | | | ARM: imx/eukrea_mbimx27-baseboard: fix typo in error messageUwe Kleine-König2012-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
| * | | | | ARM: i.MX51 iomux: add missed definitions for SION-bit and mode for some padsAlexander Shiyan2012-05-021-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
OpenPOWER on IntegriCloud