Import portions of the PowerPC OF PCI implementation into new file
"ofwpci.c", common for other platforms. The files ofw_pci.c and ofw_pci.h
from sys/powerpc/ofw no longer exist. All required declarations are moved
to sys/dev/ofw/ofwpci.h. This creates a new ofw_pci_write_ivar() function
and modifies some others methods. Most functions contain existing ppc
implementations in the majority unchanged. Now there is no need to have
multiple identical copies of methods for various architectures.
Requested by: jhibbits
Reviewed by: jhibbits, marius
Submitted by: Marcin Mazurek <mma@semihalf.com>
Obtained from: Semihalf
Sponsored by: Annapurna Labs
Differential Revision: https://reviews.freebsd.org/D4879
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
Extract common code from PowerPC's ofw_pci
Import portions of the PowerPC OF PCI implementation into
new file "ofw_pci.c", common for other platforms. The files ofw_pci.c and
ofw_pci.h from sys/powerpc/ofw no longer exist. All required declarations
are moved to sys/dev/ofw/ofw_pci.h.
This creates a new ofw_pci_write_ivar() function and modifies
ofw_pci_nranges(), ofw_pci_read_ivar(), ofw_pci_route_interrupt()
methods.
Most functions contain existing ppc implementations in the majority
unchanged. Now there is no need to have multiple identical copies
of methods for various architectures.
Submitted by: Marcin Mazurek <mma@semihalf.com>
Obtained from: Semihalf
Sponsored by: Annapurna Labs
Reviewed by: jhibbits, mmel
Differential Revision: https://reviews.freebsd.org/D4879
This needs to return to the drawing board as it breaks both
PowerPC and Sparc64 build.
Pointed out by: jhibbits
This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.
This is part of, and related to, the migration of rman_res_t from u_long to
uintmax_t.
Discussed with: jhb
Suggested by: marcel
Import portions of the PowerPC OF PCI implementation into
new file "ofw_pci.c", common for other platforms. The files ofw_pci.c and
ofw_pci.h from sys/powerpc/ofw no longer exist. All required declarations
are moved to sys/dev/ofw/ofw_pci.h.
This creates a new ofw_pci_write_ivar() function and modifies
ofw_pci_nranges(), ofw_pci_read_ivar(), ofw_pci_route_interrupt() methods.
Most functions contain existing ppc implementations in the majority
unchanged. Now there is no need to have multiple identical copies
of methods for various architectures.
Submitted by: Marcin Mazurek <mma@semihalf.com>
Obtained from: Semihalf
Sponsored by: Annapurna Labs
Reviewed by: jhibbits, mmel
Differential Revision: https://reviews.freebsd.org/D4879
Resource list for devices that are not ofwbus descendants, but
got to ofwbus method via bus_generic_release_resource() call chain,
cannot be found using BUS_GET_RESOURCE_LIST() used by ofwbus.
In that case, changing device's resource list should be avoided
(will not contain resource list prepared by ofw or simplebus).
Pointy-hat to: zbb
Reviewed by: wma
Obtained from: Semihalf
Sponsored by: Cavium
Differential Revision: https://reviews.freebsd.org/D5304
will allow for code that uses the old fdt_get_range and fdt_regsize
functions to find a range, map it, access, then unmap to replace this, up
to and including the map, with a call to OF_decode_addr.
As this function should only be used in the early boot code the unmap is
mostly do document we no longer need the mapping as it's a no-op, at least
on arm.
Reviewed by: jhibbits
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5258
Currently, there is no easy way to know in advance how many entries a list parsed by
ofw_bus_parse_xref_list_alloc() in sys/dev/ofw/ofw_bus_subr.c has.
This patch:
* teaches the existing function about handling idx == -1 and returning how big
the set is; then renames it as _internal;
* create a new function that asserts idx != -1, so the old API is maintained;
* add a new function that returns just the list length.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Differential Revision: https://reviews.freebsd.org/D5043
to be 64-bit on 32-bit architectures. It is not uncommon for device trees
to use the upper 32-bits to store what effectively is an index into the
parent ranges property. In this case, when running with a 32-bit bus_addr_t
and bus_size_t, we would previously truncate the address, this may then
incorrectly match the wrong range, and return the wrong address.
Tested by: bz (earlier version)
Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.
This is step one in migrating rman to use uintmax_t for resources instead of
u_long.
Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.
This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.
Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075
Currently when the OF_getprop() function returns with error,
the caller (OF_getencprop()) still changes the buffer endiannes.
This may destroy the default value passed in the input buffer if
used on a Little Endian platform.
Reviewed by: mmel
Submitted by: Zbigniew Bodek <zbb@semihalf.com>
Obtained from: Semihalf
Sponsored by: Cavium
use of fdt_fixup_table on PowerPC and ARM. As such we can remove it from
other architectures as it's unneeded.
Reviewed by: nwhitehorn
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5013
tree parsing opt-out rather than opt-in. All FDT-based systems as well as
PowerPC systems with real Open Firmware use the CHRP-derived binding that
includes it, which makes SPARC the odd man out here. Making it opt-out
avoids astonishment on new platform bring up.
is not pci (and thus where, ironically, the whole situation is meaningless).
This was not an error in the original code, it was introduced during my
refactoring to commonize the routine. A small change a few lines above
drove the need to make this change, and the error didn't show up on the
platforms I initially tested with.
It appears that all platforms except aarch64 are getting the file via
various header pollution, and ensuring _bus.h is included before any
openfirmware headers in every consumer of ofw/fdt stuff seems like more of
a career path than a task, so I'm taking this easy way out.
into a new function that other platforms can share.
This creates a new ofw_reg_to_paddr() function (in a new ofw_subr.c file)
that contains most of the existing ppc implementation, mostly unchanged.
The ppc code now calls the new MI code from the MD code, then creates a
ppc-specific bus_space mapping from the results. The new arm implementation
does the same in an arm-specific way.
This also moves the declaration of OF_decode_addr() from ofw_machdep.h to
openfirm.h, except on sparc64 which uses a different function signature.
This will help all FDT platforms to set up early console access using
OF_decode_addr().
the #address-cells property set. For this we need to read more data before
the parent interrupt description.
this is only enabled on arm64 for now as it's not quite compliant with the
ePAPR spec. We should use a default of 2 where the #address-cells property
is missing, however this will need further testing across architectures.
Obtained from: ABT Systems Ltd
Sponsored by: SoftIron Inc
Differential Revision: https://reviews.freebsd.org/D4518
By using this functions, we can parse a list of tuples, each of them holds
xref and variable number of values.
This kind of list is used in DT for clocks, gpios, resets ...
Discussed with: ian, nwhitehorn
Approved by: kib (mentor)
Differential Revision: https://reviews.freebsd.org/D4316
learned that the Power8 and the PS3 have a mix of OFW and FDT. Both have AIM
defined. But currently they are not affected. They have no I2C devices under
OFW.
This version was tested on a Quad G5 and build tested for armv6*.
Discussed with nwhitehorn@
Reviewed by: ian@
represented in 7-bits format in DT files, but system expect it in 8-bit
format. Also, fix two drivers that locally hack around this bug.
Submitted by: Michal Meloun <meloun@miracle.cz>
On some platforms, the /cpus node contains cpu-to-cluster
map which deffinitely is not a CPU node. Its presence was
causing incrementing of "id" variable and reporting more
CPUs available than it should.
To make "id" valid, increment it only when an entry really
is a CPU device.
Reviewed by: andrew
Obtained from: Semihalf
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3216
bus_alloc_resource(), bus_release_resource() and bus_set_resource()
(bus_generic_rl_alloc_resource(), bus_generic_rl_release_resource() and
bus_generic_rl_set_resource() respectively).
Do not print the resources for nomatch devices.
Use the inherited method for bus_get_resource_list() on ofw_iicbus.c.
Submitted by: jhb and Michal Meloun (D2033)
uintptr_t may be 64-bit on some platforms, therefore when
finding xrefinfo by pointer to device the high word is being
cut off due to cast to phandle_t which is 32-bit long by definition.
Due to that we loose the high word of the address to compare with
xi->dev's address.
To fix that, first argument of xrefinfo_find() is extended to
uintptr_t and is being cast to appropriate type (phandle_t)
when compared.
Submitted by: Zbigniew Bodek <zbb@semihalf.com>
Reviewed by: nwhitehorn
Obtained from: Semihalf
duplicated code in the two classes, and also allows devices in FDT-based
systems to declare simplebus as their parent and still work correctly
when the FDT data describes the device at the root of the tree rather
than as a child of a simplebus (which is common for interrupt, clock,
and power controllers).
Differential Revision: https://reviews.freebsd.org/D1990
Submitted by: Michal Meloun
will be used with arm64 to find which cpus to enable, and could also be
used with 32-bit arm and mips for the same purpose.
Differential Revision: https://reviews.freebsd.org/D1825
Sponsored by: The FreeBSD Foundation
This will be needed by arm64 to find the value to pass to the psci (Power
State Coordination Interface) driver, among other things, used to enable
cores.
Differential Revision: https://reviews.freebsd.org/D1824
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
as the cpu id on arm64 as it may use two cells. In it's place we can use
the device id.
It is expected we will use the reg data on arm64 to enable cores so we
still need to read and store it even if it is not yet used.
Differential Revision: https://reviews.freebsd.org/D1555
Reviewed by: nwhitehorn
Sponsored by: The FreeBSD Foundation
