| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Found with devel/coccinelle.
|
|
|
|
| |
Submitted by: Emmanuel Vadot <manu@bidouilliste.com>
|
| |
|
| |
|
|
|
|
|
| |
pass number to ensure that this driver is loaded before EMAC or OTG,
regardless of the order of nodes in the DT.
|
|
|
|
| |
"allwinner,sun4i-sramc", to match upstream DTS.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
number directly as an index. We create the array ourselves and nothing
can change the order of items in it, it's a simple 1:1 mapping.
|
|
|
|
|
| |
have started as collateral damage in a global search-replace, then it got
copied around when I cloned a file to begin creating a new file.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
code implemented in every interrupt controller driver running SMP.
This function returns true, if provided ISRC should be enabled on
given cpu.
|
|
|
|
|
|
| |
Reviewed by: andrew, gonzo, Emmanuel Vadot <manu@bidouilliste.com>
Approved by: gonzo (mentor)
Differential Revision: https://reviews.freebsd.org/D5752
|
| |
|
|
|
|
|
|
| |
and RPI2 where INTRNG is already enabled by default.
Differential Revision: https://reviews.freebsd.org/D5810
|
|
|
|
|
|
| |
on RPI2 by default.
Differential Revision: https://reviews.freebsd.org/D5822
|
|
|
|
|
|
|
| |
on RPI-B by default.
Reviewed by: gonzo
Differential Revision: https://reviews.freebsd.org/D5809
|
|
|
|
|
|
|
| |
with MPSAFE, some are not. Fix those.
Submitted by: Howard Su <howard0su@gmail.com>
Differential Revision: https://reviews.freebsd.org/D5755
|
|
|
|
|
|
|
| |
The PLL_X, base CPU frequency source, doesn't have a bypass switch and thus
we must use another frequency source for CPU while changing its frequency.
PLL_P is ideal for this, it runs at 480MHz and CPU can be clocked at this
frequency at any CPU voltage.
|
|
|
|
|
|
|
|
|
| |
many SoCs these two are the same, however there is no requirement for this
to be the case, e.g. on the ARM Juno we boot on what the GIC thinks of as
CPU 2, but FreeBSD numbers it CPU 0.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
| |
a child of it. This is done in conformity with Linux dts files and
as preparation for rework of BCM2836 interrupt controller for INTRNG.
Reviewed by: gonzo
Differential Revision: https://reviews.freebsd.org/D5807
|
|
|
|
|
|
|
| |
and BEAGLEBONE where INTRNG is already enabled by default.
Reviewed by: gonzo
Differential Revision: https://reviews.freebsd.org/D5806
|
|
|
|
|
|
|
| |
on BEAGLEBONE by default.
Reviewed by: gonzo
Differential Revision: https://reviews.freebsd.org/D5805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
an HDMI vendor-specific data block (VSDB) containing the HDMI 24-bit IEEE
registration ID (0x000C03).
Approved by: gonzo (mentor)
|
|
|
|
|
|
|
|
|
| |
separate driver. Add support for activating clock and hwreset resources
for these devices when the EXT_RESOURCES option is present.
Reviewed by: andrew, mmel, Emmanuel Vadot <manu@bidouilliste.com>
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5749
|
|
|
|
|
|
| |
SPI1 was chosen because SPI0 shares the gpio pins with I2C1.
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
|
|
| |
speed transfers.
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
|
|
|
|
|
|
|
|
| |
This driver works in PIO mode for now, interrupts are available only when
FIFO is enabled. The FIFO cannot be used with arbitrary sizes which defeat
its general use.
At some point we can add DMA transfers where the FIFO can be more useful.
Tested on uBMC (microBMC) and BBB.
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
|
|
|
|
|
|
| |
different ID space than the kernel. Because of this we need to read the
ID from the hardware. The hardware will provide this value to the CPU by
reading any of the first 8 Interrupt Processor Targets Registers.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D5706
|
|
|
|
|
|
| |
building for.
Sponsored by: ABT Systems Ltd
|
|
|
|
|
| |
- don't put command line without guard to kernel environment.
- kernel environment delivered from ubldr must have absolute precedence.
|
|
|
|
|
|
|
| |
- add mising 'or' in tegra_uart_attach()
Pointed by: kan
- fix indentation of tegra_softc
- remove forgoten debug printf
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- in atags
- in DT blob (by using 'fdt chosen' U-Boot command)
The command line must start with guard's string 'FreeBSD:' and can contain
list of comma separated kenv strings. Also, boot modifier strings from
boot.h are recognised and parsed into boothowto.
The command line must be passed from U-Boot by setting of bootargs variable:
'setenv bootargs FreeBSD:boot_single=1,vfs.root.mountfrom=ufs:/dev/ada0s1a'
followed by 'fdt chosen' (only for DT based boot)
|
|
|
|
|
|
| |
- Don't convert atags address passed from U-Boot. It's real physical
address (and we have 1:1 mapping).
- Size of tags is encoded in words, not in bytes
|
|
|
|
|
|
|
| |
This allow us to boot FreeBSD kernel (using uImage encapsulation) directly
from U-boot using 'bootm' command or by Android fastboot loader.
For now, kernel uImage must be marked as Linux, but we can add support for
FreeBSD into U-Boot later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
controller IPI provider.
New struct intr_ipi is defined which keeps all info about an IPI:
its name, counter, send and dispatch methods. Generic intr_ipi_setup(),
intr_ipi_send() and intr_ipi_dispatch() functions are implemented.
An IPI provider must implement two functions:
(1) an intr_ipi_send_t function which is able to send an IPI,
(2) a setup function which initializes itself for an IPI and
calls intr_ipi_setup() with appropriate arguments.
Differential Revision: https://reviews.freebsd.org/D5700
|
|
|
|
| |
Missed a bunch from r297000.
|
|
|
|
|
|
| |
Tested on BBB and uBMC.
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
|
|
| |
packets on vlan aware mode.
Sponsored by: Rubicon Communications (Netgate)
|
| |
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
| |
PR: 207728
Submitted by: Jia-Shiun Li <jiashiun@gmail.com>
|
|
|
|
| |
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
| |
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
| |
Sponsored by: Rubicon Communications (Netgate)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).
Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.
Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)
Tested PAE and devinfo on virtualbox (live CD)
Special thanks to bz for his testing on ARM.
Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In dual emac mode, the CPSW subsystem provides two independent ethernets.
This is implemented (as recommended by TI's TRM) with a mixture of switch
settings (vlans) and specific features of CPSW subsystem.
The driver was splitted to accommodate the shared parts (RX and TX rings
for example) while it still provides two independent ethernets.
Each of the ethernet ports driver has it's own set of MDIO registers among
the other private settings.
Previously this driver always operate in promisc mode, now the Switch ALE
(address table entry) is properly initialized and enabled.
The driver is also tested (and known to work) with both ports operating in
single port mode (active_slave 0 or 1).
Tested on uBMC (dual emac mode, both ports in single mode, giga and fast
ethernet) and BBB (single port, fast ethernet).
Sponsored by: Rubicon Communications (Netgate)
|