- 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
The gpiobus driver is attached explicitly and generally should be
at the same pass as its parent. Making it use BUS_PAS_BUS ensures
that it attaches immediately after parent adds it (assuming the
parent itself attached at BUS_PAS_BUS and above).
Submitted by: kan
Sponsored by: DARPA, AFRL
Summary:
This implements part of the gpio-poweroff and gpio-restart device tree
bindings. Optional properties are not handled currently. It also currently
only supports level-triggered reset.
Reviewed By: gonzo
Differential Revision: https://reviews.freebsd.org/D8521
- Split driver in two parts: FDT and non-FDT
- Instead of reattach gpioled nodes to GPIO bus use
gpio_pin_get_by_ofw_idx and add ofwbus and simplebus as parrent buses
Reviewed by: loos
Differential Revision: https://reviews.freebsd.org/D8233
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
Trying to build a MIPS platform that uses INTRNG needs this
for this to work right in gpiobusvar.h :
#ifdef INTRNG
struct intr_map_data_gpio {
struct intr_map_data hdr;
...
};
#endif
- Read interrupt properties at bus enumeration time and store
it into global mapping table.
- At bus_activate_resource() time, given mapping entry is resolved and
connected to real interrupt source. A copy of mapping entry is attached
to given resource.
- At bus_setup_intr() time, mapping entry stored in resource is used
for delivery of requested interrupt configuration.
- For MSI/MSIX interrupts, mapping entry is created within
pci_alloc_msi()/pci_alloc_msix() call.
- For legacy PCI interrupts, mapping entry must be created within
pcib_route_interrupt() by pcib driver itself.
Reviewed by: nwhitehorn, andrew
Differential Revision: https://reviews.freebsd.org/D7493
No, this isn't a star trek science joke - sometimes LEDs are wired
up to be active low, so this is needed.
Submitted by: Dan Nelson <dnelson_1901@yahoo.com>
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.
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
Add gpiobus_release_pin as a counterpart for gpiobus_map_pin. Without it
it's impossible to properly release pin so if kernel module is reloaded
it can't re-use pins again
- 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
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
- Get rid of hack with re-parenting gpio-leds node to gpiobus
- Use gpio_pin_set_active to enable/disable backlight, it automatically
takes care of active-low pins
Current API assumes that "gpios" property belongs to the device's node but for
some binding it's not true: gpiokeys has set of child nodes with this property.
Patch adds new argument instead of replacing device_t because device_t will be
used to track ownership for allocated pins
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D6277
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.
"how" argument is passed as value of int* pointer to callback
function but dereferenced as char* so only one byte taken into
into account. On little-endian systems it happens to work because
first byte is LSB that contains actual value, on big-endian it's
MSB and in this case it's always equal zero
PR: 207786
Submitted by: chadf@triularity.org
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
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
- Detach the gpiobus and the gpioc devices from the GPIO controller.
- Fix the leak of gpiobus IRQ rman(9) region descriptor.
- Fix the leak of child ivars and IRQ resource list.
While here return NULL (instead of 0) for a device_t that fails to allocate
the ivar memory.
Tested with gpiobus built as a module.
Sponsored by: Rubicon Communications (Netgate)
Brightness is controlled through sysctl dev.gpiobacklight.X.brightness:
- any value greater than 0: backlight is on
- any value less than or equal to 0: backlight is off
FDT bindings docs in Linux tree:
Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
adding already exists and if so just return that. The typical use case
is from identify routines, which shouldn't be adding multiple copies
of the same phandle_t to the gpiobus. Only one per phandle_t is needed
(or expected by the current code).
Differential Revision: https://reviews.freebsd.org/D2871
https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt
Without this booting the VSATV102 causes the blue "working" led to turn
off when the kernel starts up. With this the led (which is turned on by
the firmware) stays on since that's the default state specified in the FDT.
Expanded the meaning of the led_create_state state parameter in order
to implement support for "keep". The original values were:
== 0 Off
!= 0 On
The new values are:
== -1 don't change / keep current setting
== 0 Off
!= -1 && != 0 On
This should have no effect on acpi_asus_attach which only calls
led_create_state with state set to 1. Updated acpi_ibm_attach
in order to avoid surprises.
Differential Revision: https://reviews.freebsd.org/D2615
Submitted by: John Wehle
Reviewed by: gonzo, loos
There are cases when gpioled nodes in DTS come from different sources
(e.g. standard Beaglebone Black LEDs in main DTS + shield LEDs in
overlay DTS) so instead of handling only first compatible node go
through all child nodes
