Wandboard support

[Ian Lepore]

On Thu, 2013-10-31 at 21:58 -0700, Adrian Chadd wrote:
> Hi!
> 
> On 31 October 2013 19:17, Ian Lepore <ian at freebsd.org> wrote:
> > As of r257489 we now have some support for i.MX6 in general and
> > Wandboard specifically.  There is much work to do, especially in the
> > area of clock and power management and pinmux control, and someone other
> > than me will have to look towards graphics and sound support (I have no
> > skills in those areas).
> >
> 
> Cool!
> 
> Can you describe what you need in the clock / power management areas?

Two things... the imx6 low-level support itself needs, well, everything.
Right now the imx5 clock support gets linked in, and while that lets the
linker resolve some references, luckily that code never runs, because
the imx5 clock stuff is too different from imx6 to share much code.
There are a couple temporary hacks in place right now for activating usb
clocks.

Taking a step back from there, we need a general clock API that isn't
SoC-specific.  Working on the imx stuff has made me realize that it
needs to be not even architecture-specific, because the Freescale SoCs
are all full of onboard devices which can be handled by drivers that are
completely architecture agnostic.  That is, the onboard ethernet on a
Freescale arm chip and a Freescale ppc chip should be handled with the
same driver.  But that will only work if that driver can make calls to
some architecture-neutral clock management code for attach, detach,
suspend, resume, get-clock-frequency, etc.

Further complicating things, we have a goal of being able to use
existing fdt data supplied by board vendors.  In practice that means
using whatever linux has cooked up for the SoC/board, because that's
what vendors always distribute; the linux bindings are the defacto
standard.  Unfortunately, that forces design choices on us to some
degree.  What the linux folks put into the fdt data is what they need
for the way they've chosen to structure their drivers and board support.
Those choices aren't always good for us.  

For things like clocks the fdt data is full of arbitrary numbers that
often amount to being simply the position of some enum or array entry in
linux code.  That is, given an fdt property such as clocks=<&clks,97>;
in the linux code the 97 turns in clock_array[97] or something similar.
It's not quite the "abstract definition of hardware" that I expected fdt
to be.  To be compatible with it, we have little choice beyond examining
the linux code and writing exactly-equivelent code (without violating
any licenses, just to keep things interesting).

-- Ian