The existing SPI support only worked for directly attached flash chips.
it didn't implement clock programming or chipselect. It also supports
transfers with unbalanced tx/rx command sizes.
Submitted by: <yamori813@yahoo.co.jp>
Differential Revision: https://reviews.freebsd.org/D20101
There may be cases where cpu_model[] may not be 32bit aligned, so it is
better to not try to access it as such in order to avoid unaligned access.
Sponsored by: Smartcom - Bulgaria AD
These SoCs have CHIPID registers, which store the Chip model, according
to the manufacturer; make use of those in order to better identify
the chip we're actually running on.
If we're unable to read the CHIPID registers for some reason we will
use the string "unknown " as a value for hw.model.
Reported by: yamori813@yahoo.co.jp
Sponsored by: Smartcom - Bulgaria AD
Change OF_getencprop_alloc semantics to be combination of malloc and
OF_getencprop and return size of the property, not number of elements
allocated.
For the use cases where number of elements is preferred introduce
OF_getencprop_alloc_multi helper function that copies semantics
of OF_getencprop_alloc prior to this change.
This is to make OF_getencprop_alloc and OF_getencprop_alloc_multi
function signatures consistent with OF_getencprop_alloc and
OF_getencprop_alloc_multi.
Functionality-wise this patch is mostly rename of OF_getencprop_alloc
to OF_getencprop_alloc_multi except two calls in ofw_bus_setup_iinfo
where 1 was used as a block size.
OF_getprop_alloc takes element size argument and returns number of
elements in the property. There are valid use cases for such behavior
but mostly API consumers pass 1 as element size to get string
properties. What API users would expect from OF_getprop_alloc is to be
a combination of malloc + OF_getprop with the same semantic of return
value. This patch modifies API signature to match these expectations.
For the valid use cases with element size != 1 and to reduce
modification scope new OF_getprop_alloc_multi function has been
introduced that behaves the same way OF_getprop_alloc behaved prior to
this patch.
Reviewed by: ian, manu
Differential Revision: https://reviews.freebsd.org/D14850
RT2880 is MIPS4Kc SoC used in many SOHO routers. This commits adds GPIO pin
control configuration of RT2880.
Submitted by: Hiroki Mori <yamori83@yahoo.co.jp>
Reviewed by: mizhka, sgalabov
Differential Revision: https://reviews.freebsd.org/D12648
* Target module have ic plus etherswitch ip175c.
* Also add etherswitch support code on rt driver.
Reviewed by: mizhka
Differential Revision: https://reviews.freebsd.org/D10336
Convert PCIe hot plug support over to asking the firmware, if any, for
permission to use the HotPlug hardware. Implement pci_request_feature
for ACPI. All other host pci connections to allowing all valid feature
requests.
Sponsored by: Netflix
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
When detaching device trees parent devices must be detached prior to
detaching its children. This is because parent devices can have
pointers to the child devices in their softcs which are not
invalidated by device_delete_child(). This can cause use after free
issues and panic().
Device drivers implementing trees, must ensure its detach function
detaches or deletes all its children before returning.
While at it remove now redundant device_detach() calls before
device_delete_child() and device_delete_children(), mostly in
the USB controller drivers.
Tested by: Jan Henrik Sylvester <me@janh.de>
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D8070
MFC after: 2 weeks
Etherswitch support is built by default on all SoCs except RT3662/RT3883
as they have no built-in switch and their configurations with external
switches are not yet supported.
Sponsored by: Smartcom - Bulgaria AD
Add more 'compatible' strings found in various LEDE DTS files.
Reviewed by: adrian
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6432
needed in later changes where we may not be able to lock the pic list lock
to perform a lookup, e.g. from within interrupt context.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
PCIe PHY needs different initialization on MT7628/MT7688 SoCs than it does
on MT7620.
However, LEDE (and OpenWRT) dts files have the PCIe node for MT7628/MT7688
as compatible with mt7620-pci.
We already can handle this properly in our driver, so we just need to add
compat strings to fbsd-mt7628an.dtsi and the PCIe driver.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6395
interface with 5 methods to mirror the 5 MSI/MSI-X methods in the pcib
interface. The pcib driver will need to perform a device specific lookup
to find the MSI controller and pass this to intrng as the xref. Intrng
will finally find the controller and have it handle the requested operation.
Obtained from: ABT Systems Ltd
MFH: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D5985
Allow output pins to be read and input pins to be set.
Fix bugs where we were trying to access the gpio softc before doing
device_get_softc.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6222
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.
The purpose of this file was to simply detect the UART speed before
attaching the actual ns8250 driver so that we don't have to specify the
UART speed in DTS files.
However, OpenWRT DTS files specify ns16550a as a compatible string in
their DTS files and this makes the original ns8250 driver attach to
the device. So we would have to edit the DTS files anyway and since this
is only the case for MT7621 and MT7628/MT7688 for now, it's better to
just add the clock-frequency property to those (UART is always clocked
by the same clock in both these SoCs, so that's fine) instead of having
a separate driver and still having to change the DTS files.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6044
This allows us to come closer to OpenWRT vanilla DTS files.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6045
This allows us to get closer to OpenWRT DTS files and minimize the diffs
a little more.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6042
Only compile what each SoC needs and get rid of MEDIATEK generic config.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5996
This revision makes the mtk_gpio_v1 driver read its register map property
from the OpenWRT dts files.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6029
The driver can read and parse the OpenWRT pinctrl dts entries.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5999
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 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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
