(4 in operation), 4GB ram (3.5 usable) ARM machine.
Support covers device drivers for:
- Serial Peripheral Interface (SPI)
- Chrome Embedded Controller (EC) - SPI-based version
- XHCI and USB 3.0 dual-role device PHY
Also:
- Add support for Exynos5420 in Pad module
- Move power-related functions to separate driver --
Power Management Unit (PMU)
- Enable XHCI for Chromebook1
Special thanks to grehan@ for hardware, and to
hselasky@ for r269139.
o Allow setting keymap in FDT, use hardcoded one by default
o Represent fallback keymap as a list rather than directly usable M*N array
Submitted by: Maxim Ignatenko <gelraen.ua@gmail.com>
platform code, it is expected these will be merged in the future when the
ARM code is more complete.
Until more boards can be tested only use this with the Raspberry Pi and
rrename the functions on the other SoCs.
Reviewed by: ian@
Support covers device drivers for:
- Interrupt Combiner
- gpio/pad, External Interrupts Controller (pad)
- I2C Interface
- Chrome Embedded Controller
- Chrome Keyboard
Also:
- Use new gpio dev class in EHCI driver
- Expand device tree information
and the functionality it provided into arm/exception.S. Rename the main
irq handling routine from arm_handler_execute() to arm_irq_handler() to
make it more congruent with how other exception handlers are named, and
also update its signature to reflect what has long been reality: it is
passed just a trapframe pointer, no interrupt number argument.
appropriate for each of the 'foo' in the tree. This will allow us to
compile them together (although symbol conflicts prevent us from doing
that today, this just fixes the file name collision).
it into a bunch of different .c files. Remove declarations for the unused
mptramp() function from everywhere except AramadaXP (and I think it's
really not used there either, because the code that references it appears
to be insanely does-nothing in nature).
to check the status property in their probe routines.
Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.
Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
static device mappings, rather than as the first of the initializations
that a platform can hook into. This allows a platform to allocate KVA
from the top of the address space downwards for things like static device
mapping, and return the final "last usable address" result after that and
other early init work is done.
Because some platforms were doing work in initarm_lastaddr() that needs to
be done early, add a new initarm_early_init() routine and move the early
init code to that routine on those platforms.
Rename platform_devmap_init() to initarm_devmap_init() to match all the
other init routines called from initarm() that are designed to be
implemented by platform code.
Add a comment block that explains when these routines are called and the
type of work expected to be done in each of them.
new devmap.[ch] files. Emphasize the MD nature of these things by using
the prefix arm_devmap_ on the function and type names (already a few of
these things found their way into MI code, hopefully it will be harder to
do by accident in the future).
The only remaining user was the code that allocates bounce pages for armv4
busdma. It's not clear why bounce pages would need uncached memory, but
if that ever changes, kmem_alloc_attr() would be the way to get it.
really need it. That would be almost everywhere it was included. Add
it in a couple files that really do need it and were previously getting
it by accident via another header.
included by vm/pmap.h, which is a prerequisite for arm/machine/pmap.h
so there's no reason to ever include it directly.
Thanks to alc@ for pointing this out.
