arm/samsung: Don't abuse child's dv_private for the parent's uses.

dv_private belongs to the device itself, i.e., the child here.

This overwrote the child's softc pointer, causing all kinds of havo

arm/samsung: Don't abuse child's dv_private for the parent's uses.

dv_private belongs to the device itself, i.e., the child here.

This overwrote the child's softc pointer, causing all kinds of havoc;
if this worked it was by an amazing accident.

show more ...

Merge thorpej-cfargs2.

Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass a

Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

show more ...

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

G/C

Use __BIT/__SHIFTOUT some more. NFCI.

Traiing whitespace

Remove some duplicate code

Make the pinctrl driver actually work.

XU4 gpio - get rid of annoying printf

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 ...

make exynos_gpio_fdt_acquire actually work, now dwcmmc properly does card detect for micro SD slot

handle active low flag, simplify bank / pin name parsing, no need to panic if bank lookup fails

XU4 gpio clean up acquire code

properly locate the bank in the acquire code. This may even work.

XU4 GPIO Review Changes

Implement suggestions from Jared.

Add fdtbus_gpio_{read,write}_raw, which tells the controller not to take
polarity into account. Tegra GPIO pin data includes pin polarity, but so
does a regulator-fixed node, so the end result was th

Add fdtbus_gpio_{read,write}_raw, which tells the controller not to take
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.

show more ...

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 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 ...

EXYNOS Rewrite step 2 of N: New exynos_gpio.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 th

EXYNOS Rewrite step 2 of N: New exynos_gpio.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.

show more ...

Trailing whitespace.

Add extra GPIO chunk for 5410

Xuhost bits for Exynos5 are located in the two top bits

RCSId police