Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 1月, 2013 3 次提交
  3. 08 1月, 2013 1 次提交
  5. 04 1月, 2013 1 次提交
    • G
      ARM: drivers: remove __dev* attributes. · 351a102d
      由 Greg Kroah-Hartman 提交于 
      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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      351a102d
  7. 03 1月, 2013 5 次提交
  9. 02 1月, 2013 1 次提交
    • P
      ARM: OMAP AM33xx: hwmod data: resolve sparse warnings · 9816aa80
      由 Paul Walmsley 提交于 
      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: NPaul 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: NMugunthan V N <mugunthanvnm@ti.com>
      9816aa80
  11. 21 12月, 2012 3 次提交
  13. 18 12月, 2012 7 次提交
  15. 17 12月, 2012 2 次提交
  17. 15 12月, 2012 16 次提交
    • P
      ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings · 9db316b6
      由 Paul Walmsley 提交于 
      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: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      9db316b6
    • P
      ARM: OMAP4: clock data: DPLLs are missing bypass clocks in their parent lists · b8675e2c
      由 Paul Walmsley 提交于 
      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: NPaul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>
      b8675e2c
    • P
      ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider · 628a37d4
      由 Paul Walmsley 提交于 
      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: NPaul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>
      628a37d4
    • J
      ARM: OMAP4: Fix EMU clock domain always on · 29f0667f
      由 Jon Hunter 提交于 
      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: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: fixed checkpatch warning]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      29f0667f
    • J
      ARM: OMAP4460: Workaround ABE DPLL failing to turn-on · 8c197ccf
      由 Jon Hunter 提交于 
      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: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      8c197ccf
    • J
      ARM: OMAP4: Enhance support for DPLLs with 4X multiplier · 3ff51ed8
      由 Jon Hunter 提交于 
      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: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3ff51ed8
    • J
      ARM: OMAP4: Add function table for non-M4X dplls · 9b4fcc86
      由 Jon Hunter 提交于 
      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: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      9b4fcc86
    • J
      ARM: OMAP4: Update timer clock aliases · ba68c7ef
      由 Jon Hunter 提交于 
      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: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply after the CCF conversion]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      ba68c7ef
    • T
      ARM: OMAP: Move plat/omap-serial.h to include/linux/platform_data/serial-omap.h · d9ba5737
      由 Tony Lindgren 提交于 
      We need to move this file to allow ARM multiplatform configurations
to build for omap2+. This can now be done as this file now only
contains platform_data.

cc: Russell King <linux@arm.linux.org.uk>
cc: Alan Cox <alan@linux.intel.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Govindraj.R <govindraj.raja@ti.com>
cc: Kevin Hilman <khilman@ti.com>
cc: linux-serial@vger.kernel.org
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      d9ba5737
    • R
      mfd: omap-usb-host: get rid of cpu_is_omap..() macros · 63b68901
      由 Roger Quadros 提交于 
      Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.

The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NSamuel Ortiz <sameo@linux.intel.com>
[tony@atomide.com: updated to remove plat/cpu.h]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      63b68901
    • J
      ARM: OMAP2420: Fix ethernet support for OMAP2420 H4 · 86c35960
      由 Jon Hunter 提交于 
      Ethernet is not currently working on the OMAP2420 H4 board. In commit
f6049312 (ARM: OMAP: abstract debug card setup (smc, leds)) the function
h4_init_smc91x() that initialised the ethernet controller was renamed to
h4_init_debug() but was never called when initialising the board.

Adding a call to h4_init_debug() fixes ethernet support, however,
instead of using the legacy H4 code migrate the H4 to use the
gpmc_smc91x_init() function instead and remove the legacy H4 code.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      86c35960
    • O
      OMAP2+: mux: Fixed gpio mux mode analysis · 421e8450
      由 Oleg Matcovschi 提交于 
      OMAP_MODE_GPIO() macro verified only OMAP_MUX_MODE4.
It is not correct for following platforms:
    2430 - gpio mux mode 3
    44xx - gpio mux mode 3
    54xx - gpio mux mode 6

Patch reserves first 3 bits in partition flags for storing gpio mux
mode in same format as stored in control pad register.
Modified OMAP_MODE_GPIO() macro to handle all possible cases of gpio mux mode.
Modified omap_mux_init() flags of omap34xx to include OMAP_MUX_GPIO_IN_MODE4.
Signed-off-by: NOleg Matcovschi <oleg.matcovschi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      421e8450
    • T
      OMAP: board-files: fix i2c_bus for tfp410 · ca2e16fa
      由 Tomi Valkeinen 提交于 
      The i2c handling in tfp410 driver, which handles converting parallel RGB
to DVI, was changed in 958f2717
(OMAPDSS: TFP410: pdata rewrite). The patch changed what value the
driver considers as invalid/undefined.  Before the patch, 0 was the
invalid value, but as 0 is a valid bus number, the patch changed this to
-1.

However, the fact was missed that many board files do not define the bus
number at all, thus it's left to 0. This causes the driver to fail to
get the i2c bus, exiting from the driver's probe with an error, meaning
that the DVI output does not work for those boards.

This patch fixes the issue by changing the i2c_bus number field in the
driver's platform data from u16 to int, and setting the bus number to -1
in the board files for the boards that did not define the bus. The
exception is devkit8000, for which the bus is set to 1, which is the
correct bus for that board.

The bug exists in v3.5+ kernels.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NThomas Weber <thomas@tomweber.eu>
Cc: Thomas Weber <thomas@tomweber.eu>
Cc: <stable@vger.kernel.org> # v3.5+
Signed-off-by: NTony Lindgren <tony@atomide.com>
      ca2e16fa
    • V
      ARM: OMAP2+: Fix sparse warnings in timer.c · bf85f205
      由 Vaibhav Hiremath 提交于 
      Sparse generates the following warnings when compiling mach-omap2/timer.c.

  CHECK   arch/arm/mach-omap2/timer.c
  arch/arm/mach-omap2/timer.c:193:13: warning: symbol 'omap_dmtimer_init'
  was not declared. Should it be static?
  arch/arm/mach-omap2/timer.c:213:12: warning: symbol
  'omap_dm_timer_get_errata' was not declared. Should it be static?

Add static to function declaration to fix warnings.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      bf85f205
    • J
      ARM: AM335x: Fix warning in timer.c · e0c3e27c
      由 Jon Hunter 提交于 
      When compiling the kernel with configuration options ...

 # CONFIG_ARCH_OMAP2 is not set
 # CONFIG_ARCH_OMAP3 is not set
 # CONFIG_ARCH_OMAP4 is not set
 # CONFIG_SOC_OMAP5 is not set
 CONFIG_SOC_AM33XX=y

 ... the following build warning is seen.

  CC      arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:395:19: warning: ‘omap2_sync32k_clocksource_init’
  	defined but not used [-Wunused-function]

This issue was introduced by commit 6f80b3bb (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
longer referenced by the timer initialisation function for the AM335x
device as it has no 32k-sync timer.

Fix this by adding the "__maybe_unused" compiler directive to the
omap2_sync32k_clocksource_init() function to indicate that this function
may be used for certain configurations.

Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      e0c3e27c
    • J
      ARM: OMAP2+: Fix realtime_counter_init warning in timer.c · 34cceb74
      由 Jon Hunter 提交于 
      In commit fa6d79d2 (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

  CC      arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
  defined but not used [-Wunused-function]

Commit fa6d79d2 also introduced the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
a stub function for realtime_counter_init() is defined.

For non-OMAP5 devices, there is no realtime counter and so
realtime_counter_init() function and stub function are not used for
these devices. Therefore, fix this warning by only allowing the kernel
configuration option CONFIG_SOC_HAS_REALTIME_COUNTER to be enabled for
OMAP5 devices.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by Santosh Shilimkar <santosh.shilimkar@ti.com>
      34cceb74
  19. 04 12月, 2012 1 次提交