Written but untested. I'm still confused about how to handle two things:
1) at interrupt disestablishment, where do I get an interrupt number so
that I can disable the interrupt on the combiner?
2) How is interrupt multiplexing handled? I don't seem to have any sort of
interrupt dispatch routine that takes the 1 interrupt that reaches the
gic and turn it into one of eight combined interrupts to call the
established interrupt for the original uncombined interrupt source.
polarity into account. Tegra GPIO pin data includes pin polarity, but so
does a regulator-fixed node, so the end result was that the enable value
was being swapped twice. Change fregulator to use the raw APIs, and adapt
Tegra and Exynos GPIO drivers to support this flag.
This is a moderately tested working gpio driver for the Exynos based ODROID
XU4. To use this you have to edit the dtd file exynos54422-pinctrl.dtsi
and change the two occurances of 'gpz' to 'gpz0'. Otherewise it will crash
on a lookup failure.
It certainly could use a code review.
step N of N: get rid of baggage by removing whole files. What's left is in
approximately the same shape as when the FDT update started, that is mostly
broken. What's missing is most of the 76 devices recognized in the dtd. In
other words, This is barely the start of a port.
Next up, gpio then i2c, followed either by straightening out usb or getting
the sdhc driver to work -- both probably require getting the interrupt
combiner to work first. A large chunk of work is left to do on the clocks.
I barely got them attaching to fdt and didn't do anything to take advantage
of the information in the dtd.
None of the other existing drivers, such as they are, properly request gpios,
i2c or clocks, and, of course power domains are off the table.
There is a minimum conversion on the clock driver.
The USB driver needs reordering and is broken, but it was broken before.
Next up: tactical nuclear weapons
It is rather amazing that XU4 gets as far as it does, given how much of this
code simply doesn't work. Focusing now on getting everything converted to
FDT. Next up USB and clocks. After that nuke everything that's not needed
and start the port in earnest.
This is broken. exynos_gpio_bank_config and the call to it are wrong, and
the acquire function doesn't work.
But I'm in over my head and I need to discuss this:
There is a problem with the dtd: it doesn't have addresses for the individual
gpios. Do I add the addresses to it, or go back to the old version where I
have them hard coded in the driver.
There is a problem with creating the gpio device entries: I suspect I really
need to treat the pinctrl devices as busses and create the gpios as attached
to those busses, but I'm not familiar with how to do that in NetBSD. At the
minimum, a pointer to a similar situation would give me code to follow.
This is different than the usual bus attachment in that the gpios aren't
devices in the dtd (they don't have "compatible" properties) so they don't
get an attach routine called. An alternative to generating the bus
attachments might be to add "compatible" properties to the GPIO entries
in the dtd. so that they do get attached in the normal way.
If I'm going to modify the DTD, then it should be checked in, so a decision
on where to check them in would be nice, even if it does mean spreading them
all over because of license issues. (This DTD is GPL v2)
This is a mess and I don't understand why part of it works, but it passes
the basic test.
There has to be some better way to get the info that I'm grabbing from the
exynos_uarts[] array.
I'm not sure how to deal with VA != PA when the DTB contains physical rather
than virtual addresses. This is going to be an issue for all of the drivers.
The watchdog timer is the most trivial driver in exynos, from the POV of
converting to FDT, so go ahead and do it first. NOTE: There's a hack in
the driver that needs to eventually be fixed -- the clock frequency is
hardwired when it should be gotten from the clock in the device tree. I'll
come back and fix this when I'm more comfortable with the api.
I got away with not having the generic bus tags for getting minimum fdt to
work; but for real drivers have to actually have them. Make necessary
corrections.
This enables the use of FDT on the XU4 but doesn't add any drivers. However,
with this check in, XU4 becomes useless without a device tree blob from the
Linux tree, which isn't checked in anywhere.
This will work only if the patch to sysmon_wdog.c to convert it to
MODULE_CLASS_DRIVER is installed. Symptom of failure is a crash in
lockdebug because of an uninitialized mutex.
Now, on CPUs that support this feature, if the kernel tries to execute
an instruction located in userland, the CPU will trigger a page fault.
Tested on amd64 (Intel Core i5).
This adds the GPIO aliases that will be used for board-independent driver
lookup until we have FDT.
The idea here is that each pin used by any driver is given a name that
the driver knows that is independent of the gpio bank name. The mapping
from the alias to the actual gpio bank + pin number is done in this file
and a lookup function is added to exynos_gpio.c that allows a driver to
ask for a gpio pin by the alias name, blisssfully unaware that there is
an underlying GPIO bank name.
Once set up with all the drivers, it should then be possible to move to a
different vendor's board simply by modifying exynos_machdep.c
I can't bring myself to fully nuke from orbit, so there are really two
things in this checkin:
1) A major rewrite of exynos_gpio.c, based mostly on the Nvidia
tegra_gpio.c file. This is missing a major function that will be
added the first time a customer for it is integrated, which is meant to
select pins based on aliases, rather than pin bank names.
2) A small number of changes to other files that keep the tree compiling
and progressing as far as ever; except it is now 5422 specific and
will not boot on the other exynos socs, which I don't have hardware to
test.
The choice to remove functionality is always controversial, but since
we are doing a significant rewrite and I don't have either
documentation or hardware *and* none of the code really works now
anyway, I'm taking the stance that only tested functionality should be
added, and that we'll layer the other exynos socs on this once it
fully boots.
