Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
attachment of i2c devices needed by hdmi.
The hdmi init also uses an intrhook callback to defer initialization, and if
the hdmi callback runs first, the i2c devices will not yet have registered
their device_t in association with their FDT phandle, which allows cross-
device references on FDT systems.
Now the hdmi deferred init checks for the i2c device registration, and if
it's not complete yet, it registers as an eventhandler watching for newbus
attach events. When the i2c device eventually attaches, the hdmi driver
unregisters from watching further events, and continues with the hdmi init.
Because the function signatures for an intrhook callback and an event
handler callback are the same, a single function is used for both callbacks.
Reported by: Russell Haley <russ.haley@gmail.com>
Transition all boards that support arm cortex CPUs to armv7. This
leaves two armv6 kernels in the tree. RPI-B, which uses the BCM2835
which has a ARM1176 core, and VERSATILEPB, which is a qemu board setup
around the time RPI-B went in. Copy std.armv6 to std.armv7, even
though that duplicates a lot of stuff. More work needs to be done to
sort out the duplication.
Differential Revision: https://reviews.freebsd.org/D12027
attachment code for various SOCs and busses. Remove all the static and
should-have-been-static and named-differently instances of it.
This should eliminate the recently-grown build warnings about multiple
definitions when building arm kernels.
Merge in the missing devices from the IMX6 and ZEDBOARD kernel configs. The
Freescale sdma device has been renamed to fslsdma to mark it as a platform
specific driver.
Reviewed by: ian
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11564
available, in i2c controller drivers that require interrupts for transfers.
This is the result of auditing all 22 existing drivers that attach iicbus.
These drivers were the only ones remaining that require interrupts and were
not using config_intrhook to defer attachment. That has led, over the
years, to various i2c slave device drivers needing to use config_intrhook
themselves rather than performing bus transactions in their probe() and
attach() methods, just in case they were attached too early.
Sometimes it is necessary to combine several gpio pins into an ad-hoc bus
and manipulate the pins as a group. In such cases manipulating the pins
individualy is not an option, because the value on the "bus" assumes
potentially-invalid intermediate values as each pin is changed in turn. Note
that the "bus" may be something as simple as a bi-color LED where changing
colors requires changing both gpio pins at once, or something as complex as
a bitbanged multiplexed address/data bus connected to a microcontroller.
In addition to the absolute requirement of simultaneously changing the
output values of driven pins, a desirable feature of these new methods is to
provide a higher-performance mechanism for reading and writing multiple
pins, especially from userland where pin-at-a-time access incurs a noticible
syscall time penalty.
These new interfaces are NOT intended to abstract away all the ugly details
of how gpio is implemented on any given platform. In fact, to use these
properly you absolutely must know something about how the gpio hardware is
organized. Typically there are "banks" of gpio pins controlled by registers
which group several pins together. A bank may be as small as 2 pins or as
big as "all the pins on the device, hundreds of them." In the latter case, a
driver might support this interface by allowing access to any 32 adjacent
pins within the overall collection. Or, more likely, any 32 adjacent pins
starting at any multiple of 32. Whatever the hardware restrictions may be,
you would need to understand them to use this interface.
In additional to defining the interfaces, two example implementations are
included here, for imx5/6, and allwinner. These represent the two primary
types of gpio hardware drivers. imx6 has multiple gpio devices, each
implementing a single bank of 32 pins. Allwinner implements a single large
gpio number space from 1-n pins, and the driver internally translates that
linear number space to a bank+pin scheme based on how the pins are grouped
into control registers. The allwinner implementation imposes the restriction
that the first_pin argument to the new functions must always be pin 0 of a
bank.
Differential Revision: https://reviews.freebsd.org/D11810
This was submitted by Rogiel Sulzbach (thank you!) but has a few last-minute
changes by me, mostly where the code interfaces to my still-utterly-deficient
imx6_ccm clocks implementation. So blame me for any mistakes.
Submitted by: Rogiel Sulzbach <rogiel@rogiel.com>
Differential Revision: https://reviews.freebsd.org/D11177
as taking a register number, and that would get multiplied by 4 to make
a register address. But the header file that consumers have to reference
this stuff publishes register addresses, not numbers. So now everything
works in terms of register addresses.
Note that the HDMI init code was writing into the wrong register before
this change. Apparently whatever it wrote to was harmless, and apparently
HDMI was working because uboot had set up the right bits.
It turns out that this is more than a power optization. The OTG port
won't work on boards that have this property unless this setting is honored.
Also ensure that the usb phy device attaches before ehci.
This allows multiple instances of SoCs that use the pl310 driver to be
built within the same kernel:
* Add access to the platform_t object from outside platform.c
* Use this with the pl310 driver
There is a new platform_pl310 interface to replace the existing code. SoCs
need to implement the init method, and if they have special requirements to
write to the two registers we care about will also need to implement the
write_ctrl and write_debug methods.
Differential Revision: https://reviews.freebsd.org/D11546
This driver is standard rather than optional because it can always provide
time after a reboot, but it will only provide time after a power cycle if
battery power is supplied to the chip's SNVS power domain.
When a pin is set for input the value in the DR will be the same as the PSR.
When a pin is set for output the value in the DR is the value output to the
pad, and the value in the PSR is the actual electrical level sensed on the
pad, and they can be different if the pad is configured for open-drain mode
and some other entity on the board is driving the line low.
timecounter instead of the GPT timer, freeing up the more flexible GPT
hardware for other uses. The EPIT driver is a standard (always in the
kernel) driver, and the existing GPT driver is now optional and included
only if you ask for device imx_gpt.
imx6 based on a single cortex-a7 core. Other changes to imx6 drivers
and support code are needed to fully support the imx6ul.
Also fix an indentation glitch committed in the prior change.
driver for imx6. Some newer dts source puts the GIC node at the root
instead of under /soc, so look in both places. Also, sometimes the GIC
node doesn't list itself as its own interrupt-parent, allow that too.
At this point, INTRNG is not going away (the option may go away, but the
code is not), so we no longer need code to support workarounds that handled
the lack of INTRNG functionality.
calculated at runtime based on how long it takes to set up an event in
hardware. This fixes the intermittant 1-minute hang at boot on imx5
systems, and also the occasional oversleeping while running. It doesn't
affect imx6 systems, which use different hardware for eventtimers.
It turns out that it usually takes about 30 timer ticks to set up the timer
compare register, and the old hard-coded minimum period was 10 ticks. On
the rare occasions when a timeout event that short was set up, we'd miss
the event and have to wait about 64 seconds for counter rollover before
the compare interrupt would fire.
Instead of just hardcoding a new bigger value, the code now measures the
time it takes to do the register read/write sequence to set up the compare
register, scales it up by 1.5x to be safe, and calculates the minimum event
period from the result. In the real world, the minimum period works out to
about 750 nanoseconds on imx5 hardware.
It turns out to be surprisingly expensive to access the gpt hardware (on the
order of 150ns per read/write). To cut down on the overhead of setting up
each eventtimer event, eliminate read-modify-write sequences to manage the
compare interrupt enable, by keeping a shadow copy of the hardware register
and only writing to the hardware when the enable bits really change.
cleanups enabled by that:
- The only thing left in imx_gptvar.h was the softc, which IMO never
should have been in there at all. Move it into the driver, and
delete the header file.
- Remove several unneeded #includes from the driver.
- Change imx_gpt_softc from global to static (it's used by DELAY()), and
don't redundantly static-initialize it to NULL.
supply the addresses for the DPLL register blocks) by hard-coding the
addresses in the driver source code. Yes, this is just as bad an idea as
it sounds, but we have no choice.
In the early days of using fdt data, when we were making up our own data
for each board, we defined 4 sets of memory mapped registers in the data.
The vendor-supplied data only provides the address of the CCM register
block, but not the 3 DPLL blocks. The linux driver has the DPLL physical
addresses (which differ by SOC type) hard-coded in the driver, and we
have no choice but to do the same thing if we want to run with the vendor-
supplied fdt data.
So now we use bus_space_map() to make the DPLL blocks accessible, choosing
the set of fixed addresses to map based on the soc id.
be migrated to this and will allow the removal of this option.
Reviewed by: ian
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D9907
This enables the PHY circuitry for UTMI+ level 2 and 3, and sets the
flag to tell the ehci code that the root hub has a transaction translator
in it. For imx6 we can use the standard ehci_get_port_speed_portsc()
function to find out what speed device is connected to the port.
- Use new option SMP_ON_UP instead of (mis)using specific CPU type.
By this, any SMP kernel can be compiled with SMP_ON_UP support.
- Enable runtime detection of CPU multiprocessor extensions only
if SMP_ON_UP option is used. In other cases (pure SMP or UP),
statically compile only required variant.
- Don't leak multiprocessor instructions to UP kernel.
- Correctly handle data cache write back to point of unification.
DCCMVAU is supported on all armv7 cpus.
- For SMP_ON_UP kernels, detect proper TTB flags on runtime.
Differential Revision: https://reviews.freebsd.org/D9133
Replace archaic "busses" with modern form "buses."
Intentionally excluded:
* Old/random drivers I didn't recognize
* Old hardware in general
* Use of "busses" in code as identifiers
No functional change.
http://grammarist.com/spelling/buses-busses/
PR: 216099
Reported by: bltsrc at mail.ru
Sponsored by: Dell EMC Isilon
- Place const modifiers where required
- Make sure sdma device is attahched before consumers like SSI
Reviewed by: br
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8874
file and add a generic DT binding that takes advantage of the extres
framework for setting up clocks.
Reviewed by: gonzo
Differential Revision: https://reviews.freebsd.org/D8826
As cs is stored in a uint32_t, use the last bit to store the
active high flag as it's unlikely that we will have that much CS.
Reviewed by: loos
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8614
Replace them with a default handler that returns devmap_lastaddr.
Reviewed by: mmel
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D8806
Up until r295436 GPT timer in i.MX6 Dual dts used the same compatiblity
string as i.MX6 Quad. After the sync up with Linux in r295436, GPT timer
stopped getting attached on the i.MX6 Dual
MFC after: 3 days
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
