summaryrefslogtreecommitdiffstats
path: root/sys/mips
Commit message (Collapse)AuthorAgeFilesLines
* Allow RT3350 CPU clock to be detected as part of RT3050/RT3052 detectionsgalabov2016-04-182-8/+12
| | | | | | | | | | | OpenWRT's dts files treat RT3050/RT3052/RT3350 within the same SoC dtsi file, so we need to distinguish between the three dynamically, mainly because the bit we use to determine the clock speed on RT3050/RT3052 can actually be floating on RT3350 and RT3350 is always at 320MHz. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5983
* Add support for boot arguments specification via fdtsgalabov2016-04-161-0/+55
| | | | | | | | | | | | Add suppport for passing boot arguments via FDT for mediatek/ralink SoCs. This was taken from kan's work on CI20. Since most OpenWRT dts files have bootargs defined, we use bsdbootargs to specify FreeBSD specific arguments. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5979
* Change MIPS_INTRNG to INTRNG in MEDIATEK_BASE configsgalabov2016-04-161-2/+2
| | | | | | | | | | Revision 298068 changed MIPS_INTRNG and ARM_INTRNG to simply INTRNG. MEDIATEK_BASE config was missed by this revision, so we change MIPS_INTRNG to INTRNG here. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5978
* Rename ARM_INTRNG and MIPS_INTRNG to INTRNG. This will help with machineandrew2016-04-155-17/+17
| | | | | | | independent code that needs to know about INTRNG such as PCI drivers. Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation
* Make NIRQ configurable for MIPSsgalabov2016-04-151-2/+6
| | | | | | | Submitted by: kan Reviewed by: kan Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5964
* Mediatek/Ralink: Get our drivers closer to OpenWRT dts definitionssgalabov2016-04-159-29/+38
| | | | | | | | | | This revision gets our Mediatek/Ralink drivers closer to OpenWRT's dts definitions, so we can reuse them with less modifications later in order to bring support for a lot of boards at once. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5961
* Remove unneeded initialization in mtk_xhci.csgalabov2016-04-151-1/+0
| | | | | | | | | This is actually initialized properly within xhci.c, so it's better to not initialize it in mtk_xhci.c Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5935
* In order to build a kernel with one of these configs the user should dosgalabov2016-04-1510-0/+411
| | | | | | | | | | | | | | | | | | | | | | | | | | | the following: 1. Give the appropriate board dts file to be used by either: 1.1. edit the SoC kernel config required (e.g., MT7620A_FDT) and include the required FDT_DTS_FILE makeoption; or 1.2. simply supply FDT_DTS_FILE="xx.dts" on the command line when building the kernel Of course, the user can also create a completely new kernel config to match the desired board and include the SoC kernel config from within it. If required, edit the MEDIATEK config file, which includes optional drivers and comment out the unneeded ones. 2.1. this would only make sense if kernel size is a concern. Even if we build the kernel with all drivers, if we lzma it and package it as a uImage, its size is still around 1.1MiB. The user will have to choose a dts file (or create a new one) from sys/gnu/dts/mips , where all Mediatek/Ralink dts files will be imported via a later revision. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5966
* mips: for pointers replace 0 with NULL.pfg2016-04-1510-10/+10
| | | | | | | | These are mostly cosmetical, no functional change. Found with devel/coccinelle. Reviewed by: adrian
* Add a new PCI bus interface method to alloc the ivars (dinfo) for a device.jhb2016-04-151-2/+2
| | | | | | | | | | | | | | The ACPI and OFW PCI bus drivers as well as CardBus override this to allocate the larger ivars to hold additional info beyond the stock PCI ivars. This removes the need to pass the size to functions like pci_add_iov_child() and pci_read_device() simplifying IOV and bus rescanning implementations. As a result of this and earlier changes, the ACPI PCI bus driver no longer needs its own device_attach and pci_create_iov_child methods but can use the methods in the stock PCI bus driver instead. Differential Revision: https://reviews.freebsd.org/D5891
* Move Mediatek/Ralink PCIe to NEW_PCIBsgalabov2016-04-122-303/+69
| | | | | | | | | | | | This revision fixes minor issues and moves the Mediatek/Ralink PCIe support to use NEW_PCIB. https://svnweb.freebsd.org/changeset/base/297849 is the other part of this changeset. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5908
* Define PCI_RES_BUS for MIPS.sgalabov2016-04-121-0/+3
| | | | | | | This is done as part of the work on D5908, but as a separate commit. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD
* Cleanup unnecessary semicolons from the kernel.pfg2016-04-102-5/+5
| | | | Found with devel/coccinelle.
* Fix MIPS INTRNG omissions, add soft/hard interrupts with different namessgalabov2016-04-081-12/+12
| | | | | | Reviewed by: kan Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5888
* Introduce better locking for mtk_gpio_v[12] driverssgalabov2016-04-082-21/+79
| | | | | | Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5887
* Introduce Mediatek/Ralink PCIe supportsgalabov2016-04-082-0/+1653
| | | | | | | | | | | This revision introduces PCIe support for the relevant Mediatek/Ralink SoCs. Currently the PCIe support is not converted to INTRNG, this may be a task for the future. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5886
* Introduce XHCI support for MT7621 SoCsgalabov2016-04-081-0/+298
| | | | | | | | | | Tested on a MT7621 board, similar to the WiTi board. More testing will be required to confirm everything is fine, but things look good so far. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5885
* Disable USB PHY slew rate calibration for Mediatek SoCs for nowsgalabov2016-04-081-1/+11
| | | | | | | | | | | | | | | USB on both MT7621 and MT7688 seems to work much better without doing slew rate calibration. These are the only two SoCs, apart from MT7628, which actually make use of the slew rate calibration routines implemented in the mtk_usb_phy driver. Since MT7628 is actually a superset of MT7688 things should be the same for it as well. We do not remove the code, we simply define it out. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5884
* Fix wrong memory mappingsgalabov2016-04-081-1/+1
| | | | | | | | | In mtk_soc.c memory is mapped incorrectly for MT7621. This revision fixes this. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5882
* Fix a copyright glitch before it gets copy-pasted again. I think this mustian2016-04-071-1/+1
| | | | | 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.
* Initial import of Ralink/Mediatek MIPS SoC support #7sgalabov2016-04-072-0/+1292
| | | | | | | | | | | | GPIO controller drivers import. As with other Ralink/Mediatek work, there are 2 versions of the GPIO controller driver, depending on the type of SoC. This revision introduces initial support for these. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5877
* Initial import of Ralink/Mediatek MIPS SoC support #6sgalabov2016-04-074-0/+834
| | | | | | | | | | SPI drivers for the various Ralink/Mediatek SoCs. There are 2 versions of the SPI controller (so far) present in the supported SoCs, hence v1 and v2 drivers. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5842
* Initial import of Ralink/Mediatek MIPS SoC support #5sgalabov2016-04-075-0/+1046
| | | | | | | | | | | | | | | | USB support This revision adds USB (EHCI/OHCI/OTG, depending on SoC type) support for various Ralink/Mediatek SoCs. Currently USB is not supported on MT7621, this will be a future addition. A USB PHY driver is also included, so that we can properly initialize the USB PHY (e.g., clocks, resets, registers where needed), before attempting to initialize EHCI/OHCI/OTG functionality. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5841
* Initial import of Ralink/Mediatek MIPS SoC support #4sgalabov2016-04-073-0/+791
| | | | | | | | | | | | | | | | | | | | UART drivers. - uart_dev_mtk.[ch] are the old-style Mediatek/Ralink-specific UART driver as also found in sys/mips/rt305x/uart_dev_rt305x.c, with minor improvements and FDT attachment enabled for the appropriate SoCs. - uart_dev_mtk_ns8250.c is the new-style ns16550a-compatible UART driver found in newer Mediatek SoCs. It uses the uart_dev_ns8250.c driver indirectly and is basically just a wrapper around it and only overrides its probe method. The reason I am not using the uart_dev_ns8250.c driver directly is because I have some code that does UART clock detection before initializing the UART, so that we don't need to hard-code the UART clock frequency in the dts files for each board. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5840
* Initial import of Ralink/Mediatek MIPS SoC support #3sgalabov2016-04-073-0/+1078
| | | | | | | | | | | | | | | | | | | | | | | Interrupt controllers found in various Mediatek/Ralink SoCs. mtk_intr_v1 and mtk_intr_v2 are basically the same at the moment, with just different register mappings. However, v1 interrupt controller has a subset of the functionality of the v2 interrupt controller, so in the future the v2 interrupt controller driver may be enhanced, if needed, with things like level/edge interrupts and soft interrupts. So, for the moment I suggest we keep them as 2 separate files. mtk_intr_gic provides very basic (similar to v1 and v2) support for MIPS GIC controllers, which currently maps all interrupts to a single core and sets them to type level, active high. In the future this may be developed into a generic GIC controller to support any new MIPS SoCs that include it. The GIC is a standard MTI interrupt controller in their multi-core line-up (e.g., 1004K, 1074K, etc.), rather than a SoC-specific controller. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5839
* Initial import of Ralink/Mediatek MIPS SoC support #2sgalabov2016-04-073-0/+409
| | | | | | | | | | | | | | This revision adds the following to the Mediatek/Ralink support: - initial support for "clocks" FDT property, currently based on fdt_clock - initial support for "resets" FDT property, currently based on the fdt_reset interface from D5826 - initial support for "pinctrl,bits" functionality via FDT. May be extended in the future to cover a better and fuller pinctrl implementation Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5827
* This revision adds the following parts:sgalabov2016-04-078-0/+1336
| | | | | | | | | | | | | | | - machine dependent low level init code - SoC clocks detection and some utility functions - Common interface to read/write/modify SoC system control registers, used by some of the other drivers and utility functions - simple FDT resets support, based on the fdt_clock implementation already in the tree. For the moment resets and clocks are managed using these implementations. I am planning to port those to the new extres framework in the future, but currently I simply don't have time to do this part too. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5826
* Bring MIPS INTRNG support back up again, in line with D5370sgalabov2016-04-072-207/+105
| | | | | | | Reviewed by: kan Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5838
* Fix the resource_list_print_type() calls to use uintmax_t.jhibbits2016-03-224-8/+8
| | | | Missed a bunch from r297000.
* Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.jhibbits2016-03-186-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix build with HWPMC_HOOKS enabled.sobomax2016-03-151-1/+6
|
* Don't assume that bio_cmd is a bitfield.imp2016-03-101-21/+22
| | | | Differential Revision: https://reviews.freebsd.org/D5591
* Second argument of the mips_timer_init_params() is boolean, sosobomax2016-03-091-1/+1
| | | | pass in "1" for true consistently.
* Let rman_init() initialize the default rman range.jhibbits2016-03-032-12/+0
| | | | | If rm_start and rm_end are both 0 on input to rman_init(), rman_init() pre-initializes them to the default range. No need to set it before.
* Make the memory size returned from fdt_get_mem_regions a 64-bit type. Thisandrew2016-03-011-1/+1
| | | | | | | | | | is the physical memory size so may be larger than a u_long can hold, e.g. on ARM with LPAE we could see an address space of up to 40 bits. On ARM u_long is only 32 bits so the memory size will be truncated, possibly to zero. Reported by: bz Sponsored by: ABT Systems Ltd
* Correct the memory rman ranges to be to BUS_SPACE_MAXADDRjhibbits2016-03-011-2/+2
| | | | | | | | | | | | | Summary: As part of the migration of rman_res_t to be typed to uintmax_t, memory ranges must be clamped appropriately for the bus, to prevent completely bogus addresses from being used. This is extracted from D4544. Reviewed By: cem Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5134
* Fix fdt_get_mem_regions() to work with 64-bit addresseswma2016-02-291-1/+2
| | | | | | | | | | | | Use u_long instead of uint32_t variables to avoid overflow in case of PA space bigger than 32-bit. Obtained from: Semihalf Submitted by: Michal Stanek <mst@semihalf.com> Sponsored by: Annapurna Labs Approved by: cognet (mentor) Reviewed by: andrew, br, wma Differential revision: https://reviews.freebsd.org/D5393
* Migrate UNCOMPRESS -> UZIPadrian2016-02-242-2/+2
|
* Obsolete mkulzma(8) and geom_uncompress(4), their functionalitysobomax2016-02-2429-80/+80
| | | | | | is now provided by mkuzip(8) and geom_uzip(4) respectively. MFC after: 1 month
* As <machine/param.h> is included from <sys/param.h>, there is no needskra2016-02-226-6/+0
| | | | | | | to include it explicitly when <sys/param.h> is already included. Reviewed by: alc, kib Differential Revision: https://reviews.freebsd.org/D5378
* As <machine/pmap.h> is included from <vm/pmap.h>, there is no need toskra2016-02-2216-16/+0
| | | | | | | include it explicitly when <vm/pmap.h> is already included. Reviewed by: alc, kib Differential Revision: https://reviews.freebsd.org/D5373
* Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.jhibbits2016-02-209-9/+9
| | | | | | | | | | | 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
* Replace several bus_alloc_resource() calls using default arguments with ↵jhibbits2016-02-191-1/+1
| | | | | | | | | bus_alloc_resource_any() Since these calls only use default arguments, bus_alloc_resource_any() is the right call. Differential Revision: https://reviews.freebsd.org/D5306
* Allow callers of OF_decode_addr to get the size of the found mapping. Thisandrew2016-02-161-1/+5
| | | | | | | | | | | | | | 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
* POSIX states that #include <signal.h> shall make both mcontext_t andkib2016-02-121-5/+5
| | | | | | | | | | | | | | | | | | | | ucontext_t available. Our code even has XXX comment about this. Add a bit of compliance by moving struct __ucontext definition into sys/_ucontext.h and including it into signal.h and sys/ucontext.h. Several machine/ucontext.h headers were changed to use namespace-safe types (like uint64_t->__uint64_t) to not depend on sys/types.h. struct __stack_t from sys/signal.h is made always visible in private namespace to satisfy sys/_ucontext.h requirements. Apparently mips _types.h pollutes global namespace with f_register_t type definition. This commit does not try to fix the issue. PR: 207079 Reported and tested by: Ting-Wei Lan <lantw44@gmail.com> Sponsored by: The FreeBSD Foundation MFC after: 2 weeks
* Include the correct header to get a phandle_t needed by ofw_bus_if.h. Whileandrew2016-02-111-3/+1
| | | | | | here only include opt_platform.h once. Sponsored by: ABT Systems Ltd
* Make bus_space_generic properly map/unmap memory (using pmap_mapdev andadrian2016-02-112-13/+24
| | | | | | | | | | | | | | | pmap_unmapdev respectively) so that resources are properly managed. This is work originally done by kan@. Stanislav picked it up as part of his Mediatek SoC work. Tested: * Carambola2, AR933x SoC Submitted by: Stanislav Galabov <sgalabov@gmail.com> Reviewed by: kan Differential Revision: https://reviews.freebsd.org/D5184
* Migrate the other MIPS24K SoC cores to use the CPU_MIPS24K option.adrian2016-02-114-4/+4
|
* Missing commit - remove MIPS fdt bus space.adrian2016-02-111-1/+0
| | | | Differential Revision: https://reviews.freebsd.org/D5184
* Remove bus space fdt for MIPS.adrian2016-02-112-206/+1
| | | | | | | | This was originall done by kan@. Submitted by: Stanislav Galabov <sgalabov@gmail.com> Reviewed by: kan Differential Revision: https://reviews.freebsd.org/D5184
OpenPOWER on IntegriCloud