Skip to content
  1. Jan 26, 2013
  3. Jan 21, 2013
  5. Jan 18, 2013
  7. Jan 07, 2013
  9. Jan 03, 2013
    • Greg Kroah-Hartman's avatar
      ARM: drivers: remove __dev* attributes. · 351a102d
      Greg Kroah-Hartman authored 
      

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      351a102d
  11. Jan 02, 2013
  13. Jan 01, 2013
    • Paul Walmsley's avatar
      ARM: OMAP AM33xx: hwmod data: resolve sparse warnings · 9816aa80
      Paul Walmsley authored 
      

Commit 70384a6a ("ARM: OMAP3+:
hwmod: Add AM33XX HWMOD data for davinci_mdio module") adds two
new sparse warnings:

arch/arm/mach-omap2/omap_hwmod_33xx_data.c:2518:30: warning: symbol 'am33xx_mdio_addr_space' was not declared. Should it be static?
arch/arm/mach-omap2/omap_hwmod_33xx_data.c:2526:26: warning: symbol 'am33xx_cpgmac0__mdio' was not declared. Should it be static?

Fix by marking the two new records as static.

Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Acked-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      9816aa80
  15. Dec 20, 2012
  17. Dec 17, 2012
  19. Dec 16, 2012
  21. Dec 15, 2012
    • Paul Walmsley's avatar
      ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings · 9db316b6
      Paul Walmsley authored 
      

Fix the following sparse warnings in the OMAP3/4 CPUIdle code:

arch/arm/mach-omap2/cpuidle34xx.c:272:1: warning: symbol 'omap3_idle_dev' was not declared. Should it be static?
arch/arm/mach-omap2/cpuidle34xx.c:274:23: warning: symbol 'omap3_idle_driver' was not declared. Should it be static?
arch/arm/mach-omap2/cpuidle44xx.c:164:1: warning: symbol 'omap4_idle_dev' was not declared. Should it be static?
arch/arm/mach-omap2/cpuidle44xx.c:166:23: warning: symbol 'omap4_idle_driver' was not declared. Should it be static?

Also fix the following checkpatch warnings:

WARNING: please, no space before tabs
#44: FILE: arch/arm/mach-omap2/cpuidle34xx.c:105:
+^I.name = ^I"omap3_idle",$

WARNING: please, no space before tabs
#45: FILE: arch/arm/mach-omap2/cpuidle34xx.c:106:
+^I.owner = ^ITHIS_MODULE,$

ERROR: code indent should use tabs where possible
#211: FILE: arch/arm/mach-omap2/cpuidle44xx.c:74:
+                        /* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */$


Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      9db316b6
    • Paul Walmsley's avatar
      ARM: OMAP4: clock data: DPLLs are missing bypass clocks in their parent lists · b8675e2c
      Paul Walmsley authored 
      

Booting OMAP4460 Pandaboard ES with a recent u-boot results in this
warning:

WARNING: at arch/arm/mach-omap2/dpll3xxx.c:427 omap3_noncore_dpll_enable+0xf4/0x110()

The OMAP4 DPLL parent clock names only listed the reference clocks,
not the bypass clocks.  Fix by adding the bypass clocks to the DPLL
parent lists.

Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>
      b8675e2c
    • Paul Walmsley's avatar
      ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider · 628a37d4
      Paul Walmsley authored 
      

The OMAP4 clock divider "div_iva_hs_clk" is listed in the clock data
as an OMAP HSDIVIDER, but it's actually a power-of-two divider.  This
causes a warning during boot on an OMAP4460 Pandaboard-ES with a
recent u-boot:

WARNING: at arch/arm/mach-omap2/clkt_clksel.c:143 omap2_clksel_recalc+0xf4/0x12c()
clock: div_iva_hs_clk: could not find fieldval 0 for parent dpll_core_m5x2_ck

Fix by converting the data for this clock to a power-of-two divider.

Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>
      628a37d4
    • Jon Hunter's avatar
      ARM: OMAP4: Fix EMU clock domain always on · 29f0667f
      Jon Hunter authored 
      

Commit d043d87c (ARM: OMAP2+: clockdomain: bypass clockdomain handling
when disabling unused clks) skips the decrementing of a clock-domains
use count if the clocks use count is zero. However, for OMAP4 devices
this is causing the EMU clock-domain to be stuck ON as the use count is
not getting decremented correctly.

The scenario that leads to this problem is described below ...

omap_hwmod_setup_all
--> _setup
    --> clkdm_hwmod_enable
    	--> EMU clock domain usecount = 1
    --> _enable_clocks
        --> clk_enable
	    --> trace_clk_div_div usecount = 1
            --> clkdm_hwmod_enable
    	        --> EMU clock domain usecount = 2
--> _idle
    --> _disable_clocks
	--> clk_disable
            --> trace_clk_div_div usecount = 0
            --> clkdm_hwmod_disable
                --> skips decrement of EMU clock domain usecount
		    because trace_clk_div_div is 0!
    	        --> EMU clock domain usecount = 2
    --> clkdm_hwmod_disable
    	--> EMU clock domain usecount = 1

Hence, due to the order that a clocks use count is decremented and the
clock domain is disabled, it is possible that the clock domain can have
a non-zero use count when the actual clock has a use count of 0.
Therefore, we should only bypass the clock-domain handling when both the
clock-domain and clock in the clock-domain have a use count of 0 and
warn when the clock-domain has a zero use count and the clock has a
non-zero use count.

Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: fixed checkpatch warning]
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      29f0667f
    • Jon Hunter's avatar
      ARM: OMAP4460: Workaround ABE DPLL failing to turn-on · 8c197ccf
      Jon Hunter authored 
      

With the latest mainline u-boot bootloader (v2012.10), timers (5-8) in
the ABE power domain are failing to turn-on. The timers never come out
of the disabled state when setting the module-mode field to enable.

The problem was exposed when u-boot was updated to NOT configure and
lock the ABE DPLL on start-up. If the ABE DPLL is configured and locked
by u-boot the problem does not occur. However, if the ABE DPLL is in the
idle low-power bypass state and we attempt to enable a timer in the ABE
power domain, it remains stuck in the disabled state. It appears to be a
problem the timer interface clock as this comes from the ABE DPLL.

If we place the ABE DPLL in the MN-bypass state and not the idle
low-power state, then this problem is not seen.

This problem only appears to occur on OMAP4460 and not OMAP4430.

Workaround this problem by locking the ABE DPLL for OMAP4460 in the
kernel on boot. By locking the ABE DPLL, when clocks from the ABE DPLL
are not being requested the DPLL will transition into a low-power stop
mode.

Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      8c197ccf
    • Jon Hunter's avatar
      ARM: OMAP4: Enhance support for DPLLs with 4X multiplier · 3ff51ed8
      Jon Hunter authored 
      

On OMAP4 devices, the ABE DPLL has an internal 4X multiplier that can
be enabled or disabled in addition to the standard configurable
multiplier (M) for OMAP DPLLs. When configuring the ABE DPLL the 4X
multiplier is accounted for by checking to see whether it is enabled or
not. However, when calculating a new rate we only check to see if the
rate can be achieved with the current setting for the 4X multiplier.
Enhance the round_rate() function for such DPLLs to see if the rate
can be achieved with the 4X multiplier if it cannot be achieved without
the 4X multiplier.

This change is necessary, because when using the 32kHz clock as the
source clock for the ABE DPLL, the default DPLL frequency for the ABE
DPLL cannot be achieved without enabling the 4X multiplier.

When using the 32kHz clock as the source clock for the ABE DPLL and
attempting to lock the DPLL to 98.304MHz (default frequency), it was
found that the DPLL would fail to lock if the low-power mode for the DPLL
was not enabled. From reviewing boot-loader settings that configure the
ABE DPLL it was found that the low-power mode is enabled when using the
32kHz clock source, however, the documentation for OMAP does not state
that this is a requirement. Therefore, introduce a new function for
OMAP4 devices to see if low-power mode can be enabled when calculating a
new rate to ensure the DPLL will lock.

New variables for the last calculated 4X multiplier and low-power
setting have been added to the dpll data structure as well as variables
defining the bit mask for enabling these features via the DPLL's
control_reg. It is possible that we could eliminate these bit masks from
the dpll data structure as these bit masks are not unique to OMAP4, if
it is preferred.

The function omap3_noncore_program_dpll() has been updated to avoid
passing the calculated values for the multiplier (M) and divider (N) as
these are stored in the clk structure.

Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      3ff51ed8
    • Jon Hunter's avatar
      ARM: OMAP4: Add function table for non-M4X dplls · 9b4fcc86
      Jon Hunter authored 
      

Currently all OMAP4 non-core DPLLs use the same function table for
configuring DPLLs. For these DPLLs, the function
omap4_dpll_regm4xen_recalc() is used to recalculate the DPLL rate and
the function omap4_dpll_regm4xen_round_rate() is used to calculate the
closest rate to that requested. However, these omap4_dpll_regm4xen_xxx()
functions are only applicable to the ABE DPLL and not the other non-core
DPLLs. Therefore, add a new function table for non-core DPLLs that do
not include the 4X-multiplier (M4X).

Please note that using these omap4_dpll_regm4x_xxx() function works for
the non-M4X DPLLs today because we only check to see if the 4X
multiplier is enabled when calculating the rate. However, it is planned
that the dpll functions will be enhanced to enable the 4X multiplier as
necessary (in order to achieve the requested rate) and so calling these
functions for non-M4X dplls will no longer work.

Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      9b4fcc86
    • Jon Hunter's avatar
      ARM: OMAP4: Update timer clock aliases · ba68c7ef
      Jon Hunter authored 
      

Commit "ARM: dts: OMAP4: Update timer addresses" updated the device-tree
names of the OMAP4 timers 5-7 because the default address for the timers
was changed from the L3 address to the MPU private address. When booting
with device-tree, this introduces a regression when attempting to set
the parent clock of timers 5-7 to the sys_clk_div_ck. Therefore, update
the clock aliases for timer 5-7 to reflect the updated device-tree name
for the timers.

Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply after the CCF conversion]
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      ba68c7ef
  23. Dec 14, 2012