for later Cortex-A CPUs that support the Multiprocessor Extensions. This
will be needed to support both in a single GENERIC kernel while still
being able to only build for a single SoC.
Reviewed by: mmel
Relnotes: yes
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D8138
controller devices are attached. This has already been done for
bus_setup_intr().
There was no doubt that if someone wants to setup an interrupt,
corresponding interrupt controller device must already be attached.
However, the same must be valid for allocation of an interrupt resource
unless the allocation is done blindly, without any information that
such interrupt even exists. While it was done this blind way before,
it won't be possible after next INTRNG change.
of hardware. Mostly this focuses on the big changes needed for setting the
bus clock, because ESDHC is SDHCI v2.0 and USDHC is 3.0, and the number,
location, and interpretation of clock divisor bits is vastly different
between the two. This doesn't get the device all the way to functioning
on ESDHC hardware yet, but it's much closer, now getting through all the
card detection and negotiation of capabilties and speed (but it eventually
hangs on what appears to be a missing interrupt).
Another missing chunk of code for handling ESDHC's 32 bit command-and-mode
register using sdhci's pair of 16 bit writes is added.
This also does some leading whitespace cleanups and sorts some softc
struct members by size, and adds some comments (because when do I ever
touch code without adding comments?).
After r285994, sysctl(8) was fixed to use 273.15 instead of 273.20 as 0C
reference and as result, the temperature read in sysctl(8) now exibits a
+0.1C difference.
This commit fix the kernel references to match the reference value used in
sysctl(8) after r285994.
Sponsored by: Rubicon Communications (Netgate)
struct associated with some type defined in enum intr_map_data_type
must have struct intr_map_data on the top of its own definition now.
When such structs are used, correct type and size must be filled in.
There are three such structs defined in sys/intr.h now. Their
definitions should be moved to corresponding headers by follow-up
commits.
While this change was propagated to all INTRNG like PICs,
pic_map_intr() method implementations were corrected on some places.
For this specific method, it's ensured by a caller that the 'data'
argument passed to this method is never NULL. Also, the return error
values were standardized there.
implementations. Early in the boot the kernel will use an approximate,
however after the timer has been probed it will switch to a more accurate
implementation.
Reviewed by: manu
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5762
value that can't ever be in an inconsistant intermediate state even when
some other thread is in the middle of writing the value/register.
Locking of the hardware remains in the few places that do r-m-w operations.
Locking of metadata access is restricted to places using memcpy or sprintf
to modify the metadata.
oddly separated from related functionality. This just moves some blocks
of code around so that setup_intr and teardown_intr are near each other
again, and likewise for enable/disable_intr. No functional changes.
universal.
(1) New struct intr_map_data is defined as a container for arbitrary
description of an interrupt used by a device. Typically, an interrupt
number and configuration relevant to an interrupt controller is encoded
in such description. However, any additional information may be encoded
too like a set of cpus on which an interrupt should be enabled or vendor
specific data needed for setup of an interrupt in controller. The struct
intr_map_data itself is meant to be opaque for INTRNG.
(2) An intr_map_irq() function is created which takes an interrupt
controller identification and struct intr_map_data as arguments and
returns global interrupt number which identifies an interrupt.
(3) A set of functions to be used by bus drivers is created as well as
a corresponding set of methods for interrupt controller drivers. These
sets take both struct resource and struct intr_map_data as one of the
arguments. There is a goal to keep struct intr_map_data in struct
resource, however, this way a final solution is not limited to that.
(4) Other small changes are done to reflect new situation.
This is only first step aiming to create stable interface for interrupt
controller drivers. Thus, some temporary solution is taken. Interrupt
descriptions for devices are stored in INTRNG and two specific mapping
function are created to be temporary used by bus drivers. That's why
the struct intr_map_data is not opaque for INTRNG now. This temporary
solution will be replaced by final one in next step.
Differential Revision: https://reviews.freebsd.org/D5730
a DRIVER_MODULE() referencing mmc_driver has a MODULE_DEPEND() on mmc. This
is because the kernel linker only searches for symbols in dependent modules,
so loading sdhci_pci (and other bus-flavors of sdhci) would fail when mmc
was not compiled into the kernel (even if you hand-loaded mmc first).
(Thanks to jilles@ for providing the vital clue about the kernel linker.)
intr_pic_init_secondary. Replace them with a direct call. On BCM2836
and ARMADA XP we need to add this function, but it can be empty.
Reviewed by: ian, imp
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5460
slightly wrong on the others. We should just check if mp_ncpus is set to
more than one CPU as we may wish to run on a single core even when SMP is
available.
Reviewed by: ian
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5458
Linux-driven changes to the way the chip's two interrupt controllers are
defined (we only support one of them) led to no interrupt processing, so
the system would hang after device instantiation. This workaround just
rewrites the FDT data on the fly to get interrupt handling back under the
control of the main GIC device.
If/when we ever support deep sleep modes that involve powering down the
main GIC, we'll have to undo this change, write a driver for the GPC-PIC,
and somehow manage the handoff of responsibilities between the two drivers
as the chip transitions in/out of deep sleep mode.
Only L2 PIPT cache is supported for __ARM_ARCH >= 6.
In fact, this is just a pure proclamation as this option is used
only in armv4 specific files now.
Use driver settable callbacks for handling of:
- core post reset
- reading actual port speed
Typically, OTG enabled EHCI cores wants setting of USBMODE register,
but this register is not defined in EHCI specification and different
cores can have it on different offset.
Also, for cores with TT extension, actual port speed must be determinable.
But again, EHCI specification not covers this so this patch provides
function for two most common variant of speed bits layout.
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D5088
Current functionality is somewhat limited: driver assumes that there
is only one active IPU unit (IPU1) and that video output is DI0 and
video mode is 1024x768. For more advanced functionality driver requires
proper clock management which is work in progress. At the moment driver
assumes that pixel clock is configured by u-boot for 1026x768 mode.
Reviewed by: andrew, ian, mmel
Differential Revision: https://reviews.freebsd.org/D4168
The ci20 port (by kan@) is going to reuse almost all of the intrng code
since the SoC in question looks suspiciously like someone took an ARM
SoC design and replaced the ARM core with a MIPS core.
* migrate out the code;
* rename ARM_ -> INTR_;
* rename arm_ -> intr_;
* move the interrupt flush routine from intr.c / intrng.c into
arm/machdep_intr.c - removing the code duplication and removing
the ARM specific bits from here.
Thanks to the Star Wars: The Force Awakens premiere line for allowing
me a couple hours of quiet time to finish the universe builds.
Tested:
* make universe
TODO:
* The structure definitions in subr_intr.c still includes machine/intr.h
which requires one duplicates all of the intrng definitions in
the platform code (which kan has done, and I think we don't have to.)
Instead I should break out the generic things (function declarations,
common intr structures, etc) into a separate header.
* Kan has requested I make the PIC based IPI stuff optional.
I don't know what alternate universe I was inhabiting when I wrote it
originally, but apparently the basic workings of mathematics were different
than in this universe. I also can't explain how it ever worked, except "by
accident", because completely bogus values were being written into the
divisor register.
so that code shared between imx5 and imx6 can work with OIDs under that node.
Add last_reset_status (integer) and last_reset_reason (string) OIDs that
provide info about the last chip reset (power-on, software reset, watchdog
timeout).
of the SRS (software reset) bit in the watchdog control register. Despite
what the manual seems to imply, this bit DOES trigger an immediate reset, as
opposed to simply flagging the type of reset as software-triggered.
interrupt controller.
The latter is required for INTRNG, because of the hardware erratum
workaround installed by the linux folks into the imx6 FDT data, which remaps
an ethernet interrupt to the gpio device. In the non-INTRNG world we
intercept the call to map the interrupt and map it back to the ethernet
hardware (because we don't need linux's workaround), but in the INTRNG world
we lose the hookpoint where that remapping was happening, but we gain the
ability to work the way linux does by having the gpio driver dispatch the
interrupt.
the name the function will have when the new ARM_INTRNG code is integrated,
and doing this rename first will make it easier to toggle the new interrupt
handling code on/off with a config option for debugging.
Make it clearer what each one means in the comments that define them.
IIC_BUSBSY was used in many places to mean two different things, either
"someone else has reserved the bus so you have to wait until they're done"
or "the signal level on the bus was not in the state I expected before/after
issuing some command".
Now IIC_BUSERR is used consistantly to refer to protocol/signaling errors,
and IIC_BUSBSY refers to ownership/reservation of the bus.
one specific problem: the driver didn't check for ACK/NAK after writing a
slave address byte to the bus, and some slaves signal that they are busy
(such as when completing an internal write to flash memory) by sending a
NAK in response to being addressed.
While working on that problem I discovered that the driver's handling of
error conditions in general didn't match the state transition diagram in
the reference manual, and making that right resulted in a lot of code
reorganization.
Along the way various other changes also happened...
- Remove a mutex that wasn't protecting anything.
- Remove some mystery DELAY()s, document the few that remain.
- Use pause_sbt(9) to yield the processor for the bulk of the time it
takes to transfer each byte rather than busy-polling the whole time.
- Disable the controller when no transfers are in progress; since we
don't operate in slave mode, there's no reason to run the hardware.
- Remove a bunch of unecessary code from probe().
Also, follow the rules from watchdog(9) about what values to return in
various situations (especially, don't touch *error when asked to set a
non-zero timeout that isn't achievable on the hardware).
Also, move the READ/WRITE bus space access macros from the header into the
source file, and rename them to RD2/WR2 to make it clear they're 16-bit
accessors. (READ/WRITE just don't seem like good names to be in a public
header file.)
years for head. However, it is continuously misused as the mpsafe argument
for callout_init(9). Deprecate the flag and clean up callout_init() calls
to make them more consistent.
Differential Revision: https://reviews.freebsd.org/D2613
Reviewed by: jhb
MFC after: 2 weeks
This is needed with the pl011 driver. Before this change it would default
to a shift of 0, however the hardware places the registers at 4-byte
addresses meaning the value should be 2.
This patch fixes this for the pl011 when configured using the fdt. The
other drivers have a default value of 0 to keep this a no-op.
MFC after: 1 week
uart implementations, and export them using the new linker-set mechanism.
Differential Revision: https://reviews.freebsd.org/D1993
Submitted by: Michal Meloun
o Digital Audio Multiplexer (AUDMUX)
o Smart Direct Memory Access Controller (SDMA)
o Synchronous Serial Interface (SSI)
Disable by default as it depends on SDMA firmware.
Sponsored by: Machdep, Inc.
The current support for controlling i2c bus speed is an inconsistant mess.
There are 4 symbolic speed values defined, UNKNOWN, SLOW, FAST, FASTEST.
It seems to be universally assumed that SLOW means the standard 100KHz
rate from the original spec. Nothing ever calls iicbus_reset() with a
speed of FAST, although some drivers would treat it as the 400KHz standard
speed. Mostly iicbus_reset() is called with the speed set to UNKNOWN or
FASTEST, and there's really no telling what any individual driver will do
with those.
The speed of an i2c bus is limited by the speed of the slowest device on
the bus. This means that generally the bus speed needs to be configured
based on the board/system and the components within it. Historically for
i2c we've configured with device hints. Newer systems use FDT data and it
documents a clock-frequency property for i2c busses. Hobbyists and
developers are likely to want on the fly changes. These changes provide
all 3 methods, but do not require any existing drivers to change to use
the new facilities.
This adds an iicbus method, iicbus_get_frequency(dev, speed) that gets the
frequency for the requested symbolic speed. If the symbolic speed is SLOW
or if there is no speed configured for the bus, the returned value is
100KHz, always. Otherwise, if bus speed is configured by hints, fdt,
tunable, or sysctl, that speed is returned. It also adds a helper
function, iicbus_init_frequency() that any bus driver subclassed from
iicbus can initialize the frequency from some other source of info.
Initial driver implementations are provided for Freescale and TI.
Differential Revision: https://reviews.freebsd.org/D1174
PR: 195009
I originally overlooked a couple flag bits defined in the fdt binding docs.
One flag suppresses the pad configuration (pullup/pulldown/etc). The other
one requires that the SION (set input on) flag be set in the mux register.
Also, it appears from the data involved that if the input register
address in the config tuple is zero, there is no input configuration. The
old code was writing to register zero, which contains a collection of misc
control bits (having nothing to do with input configuration) that probably
shouldn't get overwritten arbitrarily. The bindings doc doesn't explictly
mention this.
unit 0.
It seems that this 'simplification' was copied to all GPIO drivers in tree.
This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.
workaround for an imx6 chip erratum. Linux works around the bug with
changes in fdt data that we can't currently handle, so to enable running
with standard vendor-supplied fdt data, this watches for an attempt to map
the gpio1_6 interrupt and remaps it back to the standard ethernet interrupt.
This can be undone when the intrng project is completed and our gpio drivers
can also be interrupt controllers.
for, or that are required to run the chip (such as busses). Turn off all
the devices we don't yet have drivers for.
Some day we will have a fully functional imx6 clock driver so that we can
manage clocks based on fdt data. This will have to do until then.
timecounter resolution is available, so ask for a 1 GHz frequency. It
won't actually get one that fast, but that'll get the fastest available
clock and use a divisor of 1 (probably 132 or 66mhz on current hardware).
bus_new_pass() handler so it doesn't happen until BUS_PASS_CPU. This allows
the anatop driver to outbid the generic simplebus driver (which the FDT
data describes as compatible).
Some day when we handle power regulators, this driver may actually
become a functional simplebus and attach the regulators as children, as
described in the FDT data.
few "general purpose registers" whose values control chip behavior in ways
that have nothing to do with IO pin mux control. Define a simple API that
other soc-specific code can use to read and write the registers, and provide
the imx51 implementation of them.
soc-wide info lives. It was under dev.imx6_anatop.0.
What does anatop mean anyway? Nobody seems to know, so it's probably
not where somebody will think to look for imx6 hardware info.
These changes prevent sysctl(8) from returning proper output,
such as:
1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.
Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
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@
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.
This adds the concept of "operating points," combinations of frequency
and voltage at which the cpu is known to work correctly. Some day these
should come from FDT data, but for now the table is hard-coded.
This also allows tuning the min and max operating frequencies. The min
frequency is what the thermal management code will slow down to if the
core temperature gets too high. The max frequency is what gets used if
the temperature is okay.
Normally the max cannot be set higher than the value burned into the
ocotp fuses as the chip's rated max, but there is now a new sysctl+tunable
cpu_overclock_enable; when set to non-zero it allows raising the frequency
above the ocotp value: USE WITH CARE! (At least one of my imx6 boards
has a cpu whose ocotp values never got set correctly; they claim a max
of 792mhz, but the physical markings on the chip say it's good to 1ghz.)
Because all these values affect the entire SoC, there is a new sysctl
node, hw.imx6, where all these values live. The values that are currently
under dev.imx6_anatop.0 should probably move to hw.imx6 too, because
"anatop" doesn't even mean anything to me, let alone to an end user.
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).
implementation in arm/machdep.c. Most arm platforms either don't need to
do anything, or just need to call the standard eventtimer init routines.
A generic implementation that does that is now provided via weak linkage.
Any platform that needs to do something different can provide a its own
implementation to override the generic one.
- Don't use spaces or dots in the eventtimer or timecounter names.
They turn into sysctl node names, and it's just confusing.
- Use comparator #3 instead of #1 for one-shot events. There's an
extra 1-cycle penalty in the hardware for accessing the registers
for comparator 1, no point in paying that penalty.
- Lower the quality of the eventtimer from 1000 to 800, because the
device can't support PERCPU timers and some other device in the system
may be able to provide that.
The temperature monitor device is enabled to sample the die temperature at
16hz. The temperature is published via sysctl. A callout routine at 10hz
monitors the temperature and throttles back the cpu if the temperature
goes over a user-settable throttle point (by default 10C less than the
critical high-point temperature for the chip). The hardware is supposed
to be able to deliver an interrupt when the temperature exceeds a settable
limit, but the interrupt never arrives so for now a callout does the job.
At attach time we read the maximum cpu frequency the chip is allowed to run
at and the cpu is set to run at that speed. It's reported at attach time.
A sysctl variable reports the current speed when queried.
New sysctl values:
dev.imx6_anatop.0.cpu_mhz: 984
dev.imx6_anatop.0.temperature: 37.9C
dev.imx6_anatop.0.throttle_temperature: 95.0C
Steven Lawrance did the initial heavy lifting on this, but I changed
enough stuff that I'm the one to blame if anything breaks.
Submitted by: Steven Lawrance <stl@koffein.net>
is attached, by establishing a temporary mapping of the registers when
necessary. This is a temporary measure to keep progress moving; in the
long run we need better control over the order in which devices attach
(better than "the order they appear in the fdt dts source").
a sub-node of nexus (ofwbus) rather than direct attach under nexus. This
fixes FDT on x86 and will make coexistence with ACPI on ARM systems easier.
SPARC is unchanged.
Reviewed by: imp, ian
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
fdtbus in most cases. This brings ARM and MIPS more in line with existing
Open Firmware platforms like sparc64 and powerpc, as well as preventing
double-enumeration of the OF tree on embedded PowerPC (first through nexus,
then through fdtbus).
This change is also designed to simplify resource management on FDT platforms
by letting there exist a platform-defined root bus resource_activate() call
instead of replying on fdtbus to do the right thing through fdt_bs_tag.
The OFW_BUS_MAP_INTR() and OFW_BUS_CONFIG_INTR() kobj methods are also
available to implement for similar purposes.
Discussed on: -arm, -mips
Tested by: zbb, brooks, imp, and others
MFC after: 6 weeks
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).
out common code related to mapping device memory into a new devmap.c file.
Remove the growing duplication of code that used pmap_devmap_find_pa() and
then did some math with the returned results to generate a virtual address,
and likewise in reverse to get a physical address. Now there are a pair
of functions, arm_devmap_vtop() and arm_devmap_ptov(), to do that. The
bus_space_map() implementations are rewritten in terms of these.
the interrupt handler. If the event callback starts a new short timeout,
the timer can fire before returning from the event callback, and clearing
the interrupt status after that loses the interrupt and hangs until the
counter wraps. Fixing all of this removes the need for the do-nothing
loop at the top of the handler which really just waited for the counter to
roll over and reach the one-shot count again.
Also add a missing return(0) in the periodic timer start case.
