| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
We want to be able to probe a few selected device drivers before hwmod
code populates the clocks in omap_hwmod_setup_all(). This allows us to
convert most of the clock drivers into regular device drivers.
We only need a few minimal clock drivers early for the system timers to
select between the 32KiHz clock and the high frequency oscillator.
With these changes, initializing the clock drivers can be just done at
core_initcall time with something like:
np = of_find_node_by_name(NULL, "plls");
if (np)
of_platform_populate(np, NULL, NULL, NULL);
And then these clocks will be available for the interconnect code to use.
Having most of the clock drivers being regular device drivers allows
us to use the nice things like devm_* functions and dev_err and dev_dbg.
As an extra bonus, this also allows us to develop the clock drivers for
new SoCs as loadable modules initially for cases where we can boot up
the system based on the bootloader configured clocks.
To do this, let's change the core_initcalls to postcore_initcall under
mach-omap2.
Cc: Felipe Balbi <[email protected]>
Cc: Grygorii Strashko <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Tero Kristo <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
This patch combines the various prm_warm_reset calls under a common
API prm_reset_system, and adds the SoC specific implementation under
prm_ll_data.
Signed-off-by: Tero Kristo <[email protected]>
Acked-by: Paul Walmsley <[email protected]>
Tested-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Preparing to move the parsing of reboot= to generic kernel code forces
the change in reboot_mode handling to use the enum.
[[email protected]: fix arch/arm/mach-socfpga/socfpga.c]
Signed-off-by: Robin Holt <[email protected]>
Cc: Russell King <[email protected]>
Cc: Russ Anderson <[email protected]>
Cc: Robin Holt <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Guan Xuetao <[email protected]>
Acked-by: Russell King <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
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: Ezequiel Garcia <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Split omap_prcm_restart() from mach-omap2/prcm.c into SoC-specific
variants. These functions need to be able to save the reboot reason
into the scratchpad RAM. This implies a dependency on both the PRM
and SCM IP blocks, so they've been moved into their own file. This
will eventually call functions in the PRM and SCM drivers, once those
are created.
Vaibhav Hiremath <[email protected]> identified an unused prototype in
the first version of this patch - now removed. Tony Lindgren
<[email protected]> noted a compile problem with some RMK Kconfigs;
resolved in this patch.
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Vaibhav Hiremath <[email protected]>
Tested-by: Vaibhav Hiremath <[email protected]>
Cc: Tony Lindgren <[email protected]>
|