Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 12 1月, 2013 5 次提交
    • T
      ARM: OMAP2+: Disable code that currently does not work with multiplaform · a62a6e98
      由 Tony Lindgren 提交于 
      We still need to fix up few places for multiplatform support,
but that can proceed separately. Fix the issue by making the
problem drivers depends !ARCH_MULTIPLATFORM for now.

The remaining pieces that are not multiplatform compatible
for omap2+ SoCs are:

1. Some drivers are using custom omap_dm_timer calls

There are two drivers that are directly usign omap hardware
timers for PWM and DSP clocking: drivers/media/rc/ir-rx51.c and
drivers/staging/tidspbridge/core/dsp-clock.c. These can be
fixed for multiplatform by allowing a minimal set of hardware
timers to be accessed, and for some functionality by using the
hrtimer framework.

2. Hardware OMAP4_ERRATA_I688 needs to be fixed up

This can't be enabled for multiplatform configurations in
it's current form. It may be possible to fix it up to do
instruction replacement early on during init. Luckily it
looks like this errata does not seem to get hit with
mainline kernel code alone at least currently.

3. Legacy header needed for omap-sham.c

Looks like it still needs mach/irqs.h for omap1 that
does not exist for multiplatform systems. Just ifdef
it for now.

4. Mailbox is waiting to get moved to drivers

Disable it for now to avoid adding a dependency to the
mailbox patches.

Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>
Cc: Sean Young <sean@mess.org>
Cc: "Víctor Manuel Jáquez Leal" <vjaquez@igalia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
[tony@atomide.com: updated to disable mailbox]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      a62a6e98
    • T
      ARM: OMAP: Fix dmaengine init for multiplatform · be1f9481
      由 Tony Lindgren 提交于 
      Otherwise omap dmaengine will initialized when booted
on other SoCs. Fix this by initializing the platform
device in arch/arm/*omap*/dma.c instead.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Dan Williams <djbw@fb.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      be1f9481
    • T
      ARM: OMAP: Fix i2c cmdline initcall for multiplatform · a6cf912c
      由 Tony Lindgren 提交于 
      We only want this initcall to run when the kernel is
booted on omap SoCs. Fix the issue by initializing the
the initcall from separately for omap1 and omap2+.

This fixes the issue for omap2+ multiplatform configs
as we are using omap_subsys_initcall there.
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      a6cf912c
    • T
      ARM: OMAP2+: Use omap initcalls · b76c8b19
      由 Tony Lindgren 提交于 
      This way the initcalls don't run on other SoCs on multiplatform
kernels. Otherwise we'll get something like this when booting
on vexpress:

omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered
...
WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
_init_omap_device: could not find omap_hwmod for mpu
...
omap-dma-engine omap-dma-engine: OMAP DMA engine driver
...
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      b76c8b19
    • T
      ARM: OMAP2+: Limit omap initcalls to omap only on multiplatform kernels · 816a65ef
      由 Tony Lindgren 提交于 
      We need to make sure that multiplatform kernels don't
run omap initcalls when booted on other SoCs.

Do this by adding wrapper macros for the initcalls that
return early if soc_is_omap() test fails. This allows
us to easily change the defines later if we have SoC
specific init sections available.
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      816a65ef
  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 15 次提交
    • 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