#
be82b3a0 |
|
26-Dec-2023 |
Emmanuel Vadot <manu@FreeBSD.org> |
clk: Move clock code in dev/clk We've removed kernel option EXT_RESOURCES almost two years ago. While it was ok to have some code under a common 'extres' subdirectory at first, we now have a lot of consumer of it and we made it mandatory so no need to have it under a cryptic name. Reviewed by: mhorne Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D43191
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
f1334ab7 |
|
03-Jul-2022 |
Gordon Bergling <gbe@FreeBSD.org> |
freescale: Fix a typo in a source code comment - s/transistions/transitions/ MFC after: 3 days
|
#
ea538dab |
|
09-May-2022 |
John Baldwin <jhb@FreeBSD.org> |
arm/arm64 freescale: Remove unused devclass arguments to DRIVER_MODULE.
|
#
90a5fc32 |
|
11-Jan-2022 |
Emmanuel Vadot <manu@FreeBSD.org> |
imx_gpio: Make ext_resources non-optional EXT_RESOURCES have been introduced in 12-CURRENT and all supported releases have it enabled in their kernel config. MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D33831
|
#
9feff969 |
|
08-Aug-2021 |
Ed Maste <emaste@FreeBSD.org> |
Remove "All Rights Reserved" from FreeBSD Foundation sys/ copyrights These ones were unambiguous cases where the Foundation was the only listed copyright holder (in the associated license block). Sponsored by: The FreeBSD Foundation
|
#
65454883 |
|
01-Sep-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
arm: clean up empty lines in .c and .h files
|
#
94bc2117 |
|
30-Jun-2020 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
Add i.MX 8M Quad support - Add CCM driver and clocks implementations for i.MX 8M - Add GPC driver for iMX8 - Add clock tree for i.MX 8M Quad - Add clocks support and new compat strings (where required) for existing i.MX 6 UART, I2C, and GPIO drivers - Enable aarch64-compatible drivers form i.MX 6 in arm64 GENERIC kernel config - Add dtb/imx8 kernel module with DTBs for Nitrogen8M and iMX8MQ EVK With this patch both Nitrogen8M and iMX8MQ EVK boot with NFS root up to multiuser login prompt Reviewed by: manu Differential Revision: https://reviews.freebsd.org/D25274
|
#
ef4a3514 |
|
28-Nov-2019 |
Ian Lepore <ian@FreeBSD.org> |
Implement the ofw_bus_get_node method in the imx_gpio driver so that ofw_gpiobus can find its fdt metadata and instantiate child devices.
|
#
333559f2 |
|
05-Jul-2018 |
Ian Lepore <ian@FreeBSD.org> |
Fix an out-of-bounds array access... the irq data for teardown is in two arrays, as elements 0 and 1 of one array and elements 1 and 2 of the other. Run the loop 0..1 instead of 1..2 and use named constants to offset into one of the arrays. PR: 229508
|
#
d8cf9c4f |
|
04-May-2018 |
Ian Lepore <ian@FreeBSD.org> |
Properly support the GPIO_PIN_PRESET_{LOW,HIGH} options when configuring a gpio pin. If neither of the options is specified, pre-set the pin's output value to the pin's current input value, to achieve glitch-free transitions to output mode on pins that are pulled up or down at reset or via fdt pinctrl data.
|
#
e780d0fc |
|
04-May-2018 |
Ian Lepore <ian@FreeBSD.org> |
Make reading imx6 gpio pins work correctly whether the pin is in open-drain mode or not. An earlier attempt to make this work was done in r320456, by always reading the pad status register (PSR) instead of the data register. But it turns out the values in PSR only reflect the electrical level of an output pin if the pad is configured with the SION (Set Input On) bit in the pinmux config, and most output gpio pads are not configured that way. So now a gpio read is done by returning the value from the data register, which works right whether the pin is configured for input or output, unless the pin has been set for OPENDRAIN mode, in which case the PSR is read instead. For this to work, the pin must also be configured with SION turned on in the fdt pinmux data, which is a reasonable thing to require for the unusual case of reading an open-drain output pin.
|
#
286f5b4a |
|
04-Mar-2018 |
Ian Lepore <ian@FreeBSD.org> |
Switch imx_gpio to attach at BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE. Pretty much any other device might need to manipulate a gpio pin during its probe or attach routines, so these devices must be available as early as possible. The gpio device is an interrupt controller, but I didn't choose the INTERRUPT pass for that reason (it works fine as an interrupt controller as long as it attaches any time before interrupts are enabled). That just looked like the right place in the passes to ensure that it attaches before any type of device that might need gpio pin manipulations.
|
#
e1275c68 |
|
10-Sep-2017 |
Ian Lepore <ian@FreeBSD.org> |
Add gpio methods to read/write/configure up to 32 pins simultaneously. 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
|
#
c5922310 |
|
28-Jun-2017 |
Ian Lepore <ian@FreeBSD.org> |
Implement gpio input by reading the pad state register, not the data register. 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.
|
#
5002d69f |
|
18-Feb-2017 |
Ian Lepore <ian@FreeBSD.org> |
Change the naming of imx{5,6} gpio pins to exactly match the names used in the chip reference manuals: GPIOn_IOnn.
|
#
df767535 |
|
14-Nov-2016 |
Andrew Turner <andrew@FreeBSD.org> |
Stop including fdt_common.h from the arm code when it's unneeded. Sponsored by: ABT Systems Ltd
|
#
e3f2d7af |
|
26-May-2016 |
Ian Lepore <ian@FreeBSD.org> |
Add support for triggering interrupts on both rising and falling edges. Also, EOI a gpio interrupt in the post_ithread routine before re-enabling.
|
#
f7b96696 |
|
23-May-2016 |
Svatopluk Kraus <skra@FreeBSD.org> |
INTRNG - support new interrupt mapping type INTR_MAP_DATA_GPIO introduced in r298738. Reviewed by: ian
|
#
e2ff80bc |
|
23-May-2016 |
Svatopluk Kraus <skra@FreeBSD.org> |
INTRNG - use gpio generic interrupt modes definitions added in r298738. Reviewed by: ian
|
#
143d3973 |
|
22-May-2016 |
Svatopluk Kraus <skra@FreeBSD.org> |
Fix some format strings to make them either correct or uniform. No functional change.
|
#
cd642c88 |
|
05-May-2016 |
Svatopluk Kraus <skra@FreeBSD.org> |
INTRNG - redefine struct intr_map_data to avoid headers pollution. Each 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.
|
#
59c3cb81 |
|
15-Apr-2016 |
Andrew Turner <andrew@FreeBSD.org> |
Rename ARM_INTRNG and MIPS_INTRNG to INTRNG. This will help with machine independent code that needs to know about INTRNG such as PCI drivers. Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation
|
#
bcfa4e67 |
|
07-Apr-2016 |
Ian Lepore <ian@FreeBSD.org> |
Remove unecessary locking, mostly from places where a read is done of a 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.
|
#
0dbb1fc8 |
|
07-Apr-2016 |
Ian Lepore <ian@FreeBSD.org> |
Code cleanup: stop searching for a pin in the array and just use the pin 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.
|
#
8294827a |
|
07-Apr-2016 |
Ian Lepore <ian@FreeBSD.org> |
Comestic changes; when INTRNG support was added, some functions became 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.
|
#
bff6be3e |
|
04-Apr-2016 |
Svatopluk Kraus <skra@FreeBSD.org> |
Remove FDT specific parts from INTRNG. Change its interface to make it 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
|
#
2b3ad188 |
|
17-Dec-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
[intrng] Migrate the intrng code from sys/arm/arm to sys/kern/subr_intr.c. The ci20 port (by kan@) is going to reuse almost all of the intrng code since the SoC in question looks suspiciously like someone took an ARM SoC design and replaced the ARM core with a MIPS core. * migrate out the code; * rename ARM_ -> INTR_; * rename arm_ -> intr_; * move the interrupt flush routine from intr.c / intrng.c into arm/machdep_intr.c - removing the code duplication and removing the ARM specific bits from here. Thanks to the Star Wars: The Force Awakens premiere line for allowing me a couple hours of quiet time to finish the universe builds. Tested: * make universe TODO: * The structure definitions in subr_intr.c still includes machine/intr.h which requires one duplicates all of the intrng definitions in the platform code (which kan has done, and I think we don't have to.) Instead I should break out the generic things (function declarations, common intr structures, etc) into a separate header. * Kan has requested I make the PIC based IPI stuff optional.
|
#
e6c43510 |
|
18-Oct-2015 |
Ian Lepore <ian@FreeBSD.org> |
Enable ARM_INTRNG on IMX6 platforms, and make the imx_gpio driver an interrupt controller. The latter is required for INTRNG, because of the hardware erratum workaround installed by the linux folks into the imx6 FDT data, which remaps an ethernet interrupt to the gpio device. In the non-INTRNG world we intercept the call to map the interrupt and map it back to the ethernet hardware (because we don't need linux's workaround), but in the INTRNG world we lose the hookpoint where that remapping was happening, but we gain the ability to work the way linux does by having the gpio driver dispatch the interrupt.
|
#
7836352b |
|
31-Jan-2015 |
Luiz Otavio O Souza <loos@FreeBSD.org> |
Implement GPIO_GET_BUS() method for all GPIO drivers. Add helper routines to deal with attach and detach of gpiobus and gpioc devices that are common to all drivers.
|
#
876c1bd8 |
|
30-Jan-2015 |
Luiz Otavio O Souza <loos@FreeBSD.org> |
Clean up and fix the device detach routine and the failure path on GPIO drivers. This paves the way for upcoming work.
|
#
667357dc |
|
18-Nov-2014 |
Luiz Otavio O Souza <loos@FreeBSD.org> |
Moves all the duplicate code to a single function. Verify for invalid modes and unwanted flags before pass the new flags to driver.
|
#
8839e0e9 |
|
28-Oct-2014 |
Luiz Otavio O Souza <loos@FreeBSD.org> |
Make the GPIO children attach to the first unit available and not only to unit 0. It seems that this 'simplification' was copied to all GPIO drivers in tree. This fix a bug where a GPIO controller could fail to attach its children (gpioc and gpiobus) if another GPIO driver attach first.
|
#
0495dcef |
|
18-Jul-2014 |
Ruslan Bukin <br@FreeBSD.org> |
Rename gpio driver file.
|