Re-implement clocks for these SoC by using now standard extres/clk framework.
This is necessary for future expansion of these. The new implementation
is (due to the size of the patch) only the initial (minimum) version.
It will be updated/expanded with a subsequent set of particular patches.
This patch is also not tested on OMAP4 based boards (BeagleBone),
so all possible issues should be (and will be) fixed by ASAP once
identified.
Submited by: Oskar Holmlund (oskar.holmlund@ohdata.se)
Differential Revision: https://reviews.freebsd.org/D25118
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
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
Note that the updated comment is valid only for INTRNG. This should not
be a problem as not INTRNG code is left in place for debugging reasons
only and should not be used anymore. It's anticipated that this old
code will be removed soon.
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.
Some of FDT blobs for AM335x-based devices use pinmux pullup/pulldown
flag to setup initial GPIO ouputp value, e.g. 4DCAPE-43 sets LCD DATAEN
signal this way. It works for Linux because Linux driver does not enforce
pin direction until after it's requested by consumer. So input with pullup
flag set acts as output with GPIO_HIGH value
Reviewed by: loos
files to vendor-provided ones. It should make easier to adopt platform
code to new revisions of hardware and to use DTS overlays for various
Beaglebone extensions (shields/capes).
Original dts filenames were not changed, they're now wrappers over dts
files provided by TI. So make sure you update .dtb files on your
devices as part of kernel update
GPIO addressing was changed: instead of one global /dev/gpioc0 there
are per-bank instances of /dev/gpiocX. Each bank has 32 pins so for
instance pin 121 on /dev/gpioc0 in old addressing scheme is now pin 25
on /dev/gpioc3
On Pandaboard serial console devices was changed from /dev/ttyu0 to
/dev/ttyu2 so you'll have to update /etc/ttys to get login prompt
on serial port in multiuser mode. Single user mode serial console
should work as-is
Differential Revision: https://reviews.freebsd.org/D2146
Reviewed by: rpaulo, ian, Michal Meloun, Svatopluk Kraus
This enables the use of GPIO pins as interrupt sources for kernel devices
directly attached to gpiobus (userland notification will be added soon).
The use of gpio interrupts for other kernel devices will be possible when
intrng is complete.
All GPIO pins can be set to trigger on:
- active-low;
- active-high;
- rising edge;
- falling edge.
Tested on: Beaglebone-black
Fix the following issues:
- Removed revision from device softc, it isn't used anywhere else out of
device attach routine;
- Move the duplicated code for verification of valid banks (and pins) to
a single function;
- Use some macros to simplify the handling of some constants;
- Update some stale comments.
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.
to be present. Thsi creates a new per-SoC driver that handles probe and
setting/getting the gpio flags.
Differential Revision: https://reviews.freebsd.org/D943
Reviewed by: loos, rpaulo
MFC after: 1 week
few changes to drivers, no kernel config was added. As the SoCs are quite
old and the code is unmaintained start the process of removing support by
deleting the header file and code that depends on it along with the macro
SOC_OMAP3. Other Ti SoCs shouldn't be affected, other than for us to have
less code to maintain.
Differential Revision: https://reviews.freebsd.org/D936
Reviewed by: rpaulo, loos
While it is the recommended initialization procedure, it hangs on the reset
of the second GPIO module on pandaboard.
Removes the module reset for now as more investigation would be needed.
Reported by: jceel
On AM335x each one of the four GPIO banks has two physical interrupt
lines, so we now allocate resources and setup our interrupt handler for
all the (8) available interrupts.
On OMAP3 and OMAP4 there is only one interrupt for each GPIO bank (6
banks, 6 interrupts), but there are two set of registers where the
first one is used to setup the delivery of interrupts to the MPU and
the second set, setup the delivery of interrupts to the DSP.
On AM335x, each set of registers controls each one of the interrupt
lines.
- Remove nonexistent registers for OMAP4 and AM335x, replace their use with
the correct ones for these SoCs.
- Remove stray whitespace.
Based on OMAP3, OMAP4 and AM335x TRMs.
Tested on Beaglebone-black.
errors.
Reset the GPIO module during the initialization. This is guaranteed to be
the same as a hardware reset. Tested on AM335x (BBB) and checked against
the omap3 and omap4 TRM.
Do a better job freeing resources when there are errors and on
ti_gpio_detach().
change the gpio children can be described as directly connected to the GPIO
controller without the need of describing the OFW GPIO bus itself on the
DTS file.
With this commit the OFW GPIO bus is fully functional on BBB and RPi.
GPIO controllers which want to use the OFW GPIO bus will need similar
changes.
Approved by: adrian (mentor, implicit)
to check the status property in their probe routines.
Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.
Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.
always returning '0' for all the reads, even for the outputs. It is now
known to work with gpioiic(4) and gpioled(4).
Approved by: adrian (mentor)
Tested on: BBB
Although AM335x TRM states that GPIO_OE register is not used and just
reflects pads configuration in practice it does control pin behavior
and shoiuld be set in addition to pinmux setup
