356013 |
22-Dec-2019 |
kevans |
MFC r355796-r355797, r355799: kbd: defaults for get_fkeystr/diag
The genkbd version of these remains exposed for stable branches, but keyboard drivers that just want to use the defaults can simply not provide their own. There shouldn't be any unset in the wild.
r355796: kbd: provide default implementations of get_fkeystr/diag
Most keyboard drivers are using the genkbd implementations as it is; formally use them for any that aren't set.
r355797: chrome_kb: remove default get_fkeystr/diag implementations
This file was missed in r355796, but no harm would have come from this.
r355799: kbd: patch linker set methods, too
This is needed after r355796. Some double-registration of kbd drivers needs to be sorted out, then this sysinit will simply add these drivers into the normal list and kill off any other bits in the driver that are aware of the linker set, for simplicity. |
350045 |
16-Jul-2019 |
avg |
MFC r349460: gpiobus: provide a new hint, pin_list
"pin_list" allows to specify child pins as a list of pin numbers. Existing hint "pins" serves the same purpose but with a 32-bit wide bit mask. One problem with that is that a controller can have more than 32 pins. One example is amdgpio. Also, a list of numbers is a little bit more human friendly than a matching bit mask. As a side note, it seems that in FDT pins are typically specified by their numbers as well.
This commit also adds accessors for instance variables (IVARs) that define the child pins. My primary goal is to allow a child to be configured programmatically rather than via hints (assuming that FDT is not supported on a platform). Also, while a child should not care about specific pin numbers that are allocated to it, it could be interested in how many were actually assigned to it.
While there, I removed "flags" instance variable. It was unused. |
331504 |
24-Mar-2018 |
ian |
MFC r329537:
Provide a public function to acquire a gpio pin by giving the property name and index. A private function to do exactly that already existed, so this renames gpio_pin_get_by_ofw_impl() to gpio_pin_get_by_ofw_propidx() and provides a declaration for it in a public header.
Previously there were functions to get a pin by property name (assuming there would only be one pin defined for the name), or by index (asuming the property has the standard name "gpios"). It turns out there are devicetree bindings that describe properties with names other than "gpios" which can describe multiple pins. Hence the need to retrieve the Nth item from a named property. |
324755 |
19-Oct-2017 |
ian |
MFC r323392:
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 |
315329 |
15-Mar-2017 |
mizhka |
MFC r310017-r310018
r310017: [spi] reformat message and ar5315_spi minor fix
This commit corrects print of nomatch (newline was too early) and fix unit number for new child in ar5315_spi (was 0, now is -1 to calculate it according to actual system state)
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp> Reviewed by: ray, loos, mizhka MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D8749
r310018: [gpiospi] add clock delay to avoid smashing of bits
Submitted by: Hiroki Mori <yamori83@yahoo.co.jp> Reviewed by: loos, ray, mizhka MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D8749 |
309375 |
01-Dec-2016 |
gonzo |
MFC r308898, r308940, r308942, r308944, r309112
r308898: [bytgpio] Fix USB disconnect event after listsing pins on gpioc2
- Do not set input flag when reading value from GPIO pin, it is not required and for gpioc2(S5 bank) setting both input and output flags leads to some kind of electric interference (curren drop?) that causes USB devices to disconnect
- Check pad configuration when attaching device and provide IN/OUT capabilities only for pads that are configured as GPIO. Do not let user code to configure or change value of non-GPIO pads. There is no information for NC bank in intel's datasheet so for now function check is ignored for pins in it
Reported by: Frank H. MFC after: 3 days
r308940: [bytgpio] prepare bytgpio(4) for modularization
- Add detach method - module should depend on gpiobus, not gpio
r308942: [bytgpio] Add module for bytgpio(4)
MFC after: 3 days
r308944 by hiren@: r308942 broke kernel build. Add acpi_if.h to module makefile to fix it.
Submitted by: peter
r309112: [bytgpio] Fix pc98 build by disabling bytgpio module for this platform
Reported by: dim |
308666 |
15-Nov-2016 |
gonzo |
MFC r308295:
[gpio] Add GPIO driver for Intel Bay Trail SoC
Bay Trail has three banks of GPIOs exposed to userland as /dev/gpiocN, where N is 1, 2, and 3. Pins in each bank are pre-named to match names on boards schematics: GPIO_S0_SCnn, GPIO_S0_NCnn, and GPIO_S5_nn.
Controller supports edge-triggered and level-triggered interrupts but current version of the driver does not have interrupts support |
300871 |
27-May-2016 |
ian |
Don't wrap the declaration of gpio_alloc_intr_resource() in #ifdef INTRNG, wrap the implementation so that it returns an error if INTRNG support is not available. It should be possible to write a non-INTRNG implementation of this function some day. In the meantime, there is code that contains calls to this function (so the decl is needed), but have runtime checks to avoid calling it in the non-INTRNG case.
|
300392 |
22-May-2016 |
loos |
Get rid of two consumers of gpiobus acquire/release.
The GPIO hardware should not be owned by a single device, this defeats any chance of use of the GPIO controller as an interrupt source.
ow(4) is now the only consumer of this 'feature' before we can remove it for good.
Discussed with: ian, bsdimp
|
299477 |
11-May-2016 |
gonzo |
Add OF_prop_free function as a counterpart for OF_*prop_alloc
- Introduce new OF API function OF_prop_free to free memory allocated by OF_getprop_alloc and OF_getencprop_alloc. Current code just calls free(9) with M_OFWPROP memory class which assumes knowledge about OF_*prop_alloc functions' internals and leads to unneccessary code coupling
- Convert some of the free(..., M_OFWPROP) instances to OF_prop_free
Files affected by this commit are the ones I was able to test on real hardware. The rest of free(..., M_OFWPROP) instances will be handled with idividual maintainers
Reviewed by: andrew Differential Revision: https://reviews.freebsd.org/D6315
|
299475 |
11-May-2016 |
gonzo |
Add gpiokeys driver
gpiokey driver implements functional subset of gpiokeys device-tree bindings: https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys.txt
It acts as a virtual keyboard, so keys are visible through kbdmux(4)
Driver maps linux scancodes for most common keys to FreeBSD scancodes and also extends spec by introducing freebsd,code property to specify FreeBSD-native scancodes.
Reviewed by: mmel, jmcneill Differential Revision: https://reviews.freebsd.org/D6279
|
298738 |
28-Apr-2016 |
mmel |
GPIO: Add support for gpio pin interrupts. Add new function gpio_alloc_intr_resource(), which allows an allocation of interrupt resource associated to given gpio pin. It also allows to specify interrupt configuration.
Note: This functionality is dependent on INTRNG, and must be implemented in each GPIO controller.
|
295832 |
20-Feb-2016 |
jhibbits |
Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.
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
|
294883 |
27-Jan-2016 |
jhibbits |
Convert rman to use rman_res_t instead of u_long
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
|
279408 |
28-Feb-2015 |
loos |
Add ofw_gpiobus_parse_gpios(), a new public function, to parse the gpios property for devices that doesn't descend directly from gpiobus.
The parser supports multiple pins, different GPIO controllers and can use arbitrary names for the property (to match the many linux variants: cd-gpios, power-gpios, wp-gpios, etc.).
Pass the driver name on ofw_gpiobus_add_fdt_child(). Update gpioled to match.
An usage example of ofw_gpiobus_parse_gpios() will follow soon.
|
277980 |
31-Jan-2015 |
loos |
Implement a new method to retrieve the gpiobus reference from a GPIO controller.
The gpiobus is responsible to keep track of the used pins and serialize the access to pins.
Some of these features are important to devices that do not descend directly from gpiobus and as such cannot make use of its features (one classic example is gpioc that is attached to the GPIO controller and could not, until now, make use of the gpiobus locking).
|
274638 |
18-Nov-2014 |
loos |
Add basic interrupt management code to gpiobus and ofw_gpiobus.
This is the general support to allow the use of GPIO pins as interrupt sources for direct gpiobus children.
The use of GPIO pins as generic interrupt sources (for an ethernet driver for example) will only be possible when arm/intrng is complete. Then, most of this code will need to be rewritten, but it works for now, is better than what we have and will allow further developments.
Tested on: ar71xx (RSPRO), am335x (BBB), bcm2835 (Raspberry pi) Differential Revision: https://reviews.freebsd.org/D999 Reviewed by: rpaulo
|
266922 |
31-May-2014 |
loos |
Add a bounds verification to the SCL and SDA pin values.
At attach, print the SCL and SDA pin numbers.
Remove a stray blank line.
Remove the GPIOBUS locking from gpioiic_reset(), it is already called with this lock held. This fixes a crash when you try to scan the iicbus with i2c(8).
|
259036 |
06-Dec-2013 |
loos |
Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input.
Approved by: adrian (mentor)
|
227843 |
22-Nov-2011 |
marius |
- There's no need to overwrite the default device method with the default one. Interestingly, these are actually the default for quite some time (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9) since r52045) but even recently added device drivers do this unnecessarily. Discussed with: jhb, marcel - While at it, use DEVMETHOD_END. Discussed with: jhb - Also while at it, use __FBSDID.
|