Remove some other ifdefs that came in with a copy/paste that mean basically
"if this processor supports multicore stuff", because if you're starting up
an AP core... it does.
case where the controller is already enabled.
Some of the pl310 configuration registers cannot be changed while the
controller is active, so if there is any platform-specific init to be done
it must happen before enabling the controller.
The controller should not be enabled upon entry to the kernel, but u-boot
has recently developed the bad habit of leaving caches enabled when
launching the kernel, and since we have no control over that source code
we have to do our best to cope with it. The PL310 manual doesn't document
a safe sequence for disabling the controller, but the sequence used here
(force write-through mode and disable linefill allocations, then clean and
invalidate the current contents before disabling the hardware) appears to
be sound both by analysis and empirical testing.
These changes were developed and tested in collaboration with
Svatopluk Kraus <onwahe@gmail.com>.
Reviewed by: cognet@
#NO_UNIVERSE. Many of these config files are important examples, but
add little to no regresive value to the intended purpose of
UNIVERSE. We now build over 120 kernels during universe. There's
really little to no value to this over building say 60 or even 30 of
them (either is still a way too big number). This is especially true
for kernels that are nothing more than including a common base and
adding a static DTB file. Start by pruning 1/3 of the arm kernels that
add little regresion value.
Flushing the caches is required before doing a panic dump, but ARM
doesn't provide a flavor of flush that gets broadcast to other cores.
However, all cores except one are stopped before doing a dump, so this
works around the lack of a global flush/invalidate by doing it locally
on each CPU as part of stopping.
Discussed with: cognet@
This was added ca. 2004 for the purpose of ensuring the caches were in the
right state after the debugger set a breakpoint. kdb_cpu_sync_icache()
was added in 2007 to handle that situation, and now the wbinv_all is
actually harmful because the operation isn't broadcast to other cores.
using armv7_idcache_wbinv_all, because wbinv_all doesn't broadcast the
operation to other cores. In elf_cpu_load_file() use icache_sync_all()
and explain why it's needed (and why other sync operations aren't).
As part of doing this, all callers of cpu_icache_sync_all() were
inspected to ensure they weren't relying on the old side effect of
doing a wbinv_all along with the icache work.
the cpufreq code. Replace its use with smp_started. There's at least
one userland tool that still looks at the kern.smp.active sysctl, so
preserve it but point it to smp_started as well.
Discussed with: peter, jhb
MFC after: 3 days
Obtained from: Netflix
define a few imx_ccm_foo() functions that are implemented by the imx51 or
imx6 ccm code. Of course, the imx6 ccm code is still more a wish than
reality, so for now its implementations just return hard-coded numbers.
- These were needed on armv4/5 (VIVT cache), not needed on armv6.
- The wbinv_all call can't be used on SMP systems; cache operations by
set/way are not broadcast to other cores.
- The TLB maintenance operations needed for pmap_growkernel() happen in
pmap_grow_l2_bucket(), so there's no need to flush all TLB entries at
the end.
- There may not be any need for the TLB flush at the beginning of
pmap_release(), but it's left in for now pending more investigation.
Pointed out by: Svatopluk Kraus <onwahe@gmail.com>
Discussed with: cognet@
While it is the recommended initialization procedure, it hangs on the reset
of the second GPIO module on pandaboard.
Removes the module reset for now as more investigation would be needed.
Reported by: jceel
These should have been part of r264129, they are part of the overall set
of changes that got several weeks of testing. I must have fumbled them
while merging various patchsets.
On AM335x each one of the four GPIO banks has two physical interrupt
lines, so we now allocate resources and setup our interrupt handler for
all the (8) available interrupts.
On OMAP3 and OMAP4 there is only one interrupt for each GPIO bank (6
banks, 6 interrupts), but there are two set of registers where the
first one is used to setup the delivery of interrupts to the MPU and
the second set, setup the delivery of interrupts to the DSP.
On AM335x, each set of registers controls each one of the interrupt
lines.
- Remove nonexistent registers for OMAP4 and AM335x, replace their use with
the correct ones for these SoCs.
- Remove stray whitespace.
Based on OMAP3, OMAP4 and AM335x TRMs.
Tested on Beaglebone-black.
enabled. Also switch IMX6 to use SCHED_ULE.
The now-unreferenced WANDBOARD.common config will be deleted after giving
folks who may be including it a heads-up to switch to IMX6.
- Add cpu_cpwait to comply with the convention.
- Add missing TLB invalidations, especially in pmap_kenter & pmap_kremove
with distinguishing between D and ID pages.
- Modify pmap init/bootstrap invalidations to ID, just to be safe.
- Fix TLB-inv and PTE_SYNC ordering.
This combines changes submitted by ian@, cognet@, and Wojciech Macek,
which have all been tested together as a unit.
Perform sychronization (by "isb" barrier) after TTB is set. This
is done to ensure that TLB invalidation always executes after
TTB modification and operates on valid CP15 data (per specification).
Submitted by: Wojciech Macek <wma@semihalf.com>
Reviewed by: ian@, cognet@
- Don't allow high-speed mode on OMAP4 due to hardware erratum.
- Check the proper bit in the status register when waiting for the
controller to come out of reset.
- Add handling for the "non-removable" fdt property by always returning
"card is present" status.
- Add the non-removable property for the MMC card on a Beaglebone Black.
- Add the non-removable property for Pandaboard as a workaround.
For Pandaboard the card detect pin is handled by the twl6030 fpga device
which gets an interrupt on pin change and then has to query the fpga
for the actual status. We don't have code to do that yet.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
