fix prototype; iosf_i2c_relese -> iosf_i2c_release

add iosf(4), a driver for the Intel OnChip System Fabric

The OnChip System Fabric is mostly an implementation detail on a
bunch of Intel SoC platforms we usually don't care about, except
on some of

add iosf(4), a driver for the Intel OnChip System Fabric

The OnChip System Fabric is mostly an implementation detail on a
bunch of Intel SoC platforms we usually don't care about, except
on some of these machines there are devices shared between the
kernel and the platform that need to coordinate. The iosf(4) driver
allows the kernel to talk via a mailbox interface to take and
release a semaphore that the hardware also uses to lock around
accesses to some components.

There are two ways to talk to the mailbox interface, one via mmio
ops on an INT33BD acpi device. The other is via magic pci conf space
operations on the pci host device. This provides a generic iosf
driver with attachment glue for both acpi and pci so either can be
used. According to linux, the pci ops are a lot more reliable and
less buggy, so if both acpi and pci are available we will prefer
the pci ops after they attach.

I found this because I got a Dell Wyse 3040, which is a cherry
trail/braswell system that has an acpitz(4) which talks to a tipmic(4)
device attached to dwiic(4) on acpi. This box almost always locked
up by the time it got to showing the console login prompt, and it
turns out one of the reasons for this is because acpitz was touching
the tipmic device at the same time the powerunit on the platform
was also trying to use it. The tipmic device lists the iosf mailbox
as a dependency, and the dwiic controller has a _SEM property, both
of which indicate we should use an iosf device to coordinate iic
ops when talking to the tipmic.

This adds the code, but doesn't wire it into dwiic or the build yet.

help from patrick@ jsg@ kettenis@
ok kettenis@ patrick@

show more ...