exyopctl(4): Don't leak a duplicate softc on attach.

Rename of_match_compat_data() to of_compatible_match(). Similarly,
rename of_search_compatible() to of_compatible_lookup().

Standardize on of_compatible_match() for driver matching, and adapt
all c

Rename of_match_compat_data() to of_compatible_match(). Similarly,
rename of_search_compatible() to of_compatible_lookup().

Standardize on of_compatible_match() for driver matching, and adapt
all call sites.

show more ...

Use DEVICE_COMPAT_EOL.

Since we're using designated initialisers for compat data, we should
use a completely empty initializer for the sentinel.

Remove "struct of_compat_data" and replace its usage with
"struct device_compatible_entry"; they are ABI-compatible.

Fix several "loses const qualifier" bugs encountered during
this conversion.

Support Exynos 5410 GPIO

Traiing whitespace

Use PRIxBUSADDR

Add support for devices with separate "init" and "default" pinctrl states.

Make the pinctrl driver actually work.

Configure pin defaults at attach

Adjust to new pinctrl API

Add some compat strings

XU4 FDT pinctrl

Rewrite the use of pinctrl to reflect the new model from Jared.

XU4 i2c, gpio & pinctrl changes

modify exynos_gpio.c to support the new pinctrl model.
set up the new pinctrl model in exynos_pinctrl.c

Flesh out exynos_i2c.c and set it up to use the new pinctrl m

XU4 i2c, gpio & pinctrl changes

modify exynos_gpio.c to support the new pinctrl model.
set up the new pinctrl model in exynos_pinctrl.c

Flesh out exynos_i2c.c and set it up to use the new pinctrl model. NOTE:
exynos_i2c.c is still incomplete. I need to figure out what to set the
prescaler and scaler to.

show more ...

update compatible string to match exynos5422-odroidxu3.dts

XU4 GPIO Review Changes

Implement suggestions from Jared.

OF_getprop -> of_getprop_bool

XU4 GPIO Driver

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

XU4 GPIO Driver

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.

show more ...

XU4 FDT final checkpoint

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 missin

XU4 FDT final checkpoint

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.

show more ...

XU4 FDT missed files

XU4 GPIO FDT broken snapshot

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

XU4 GPIO FDT broken snapshot

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)

show more ...