Date: Fri, 01 Nov 2013 08:20:42 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Adrian Chadd <adrian@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: Wandboard support Message-ID: <1383315642.31172.88.camel@revolution.hippie.lan> In-Reply-To: <CAJ-VmomnBAJ0CoCQwh%2BTPo4psVkgdLE=vYsTvnaC1c4FVqgabg@mail.gmail.com> References: <1383272225.31172.60.camel@revolution.hippie.lan> <CAJ-VmomnBAJ0CoCQwh%2BTPo4psVkgdLE=vYsTvnaC1c4FVqgabg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2013-10-31 at 21:58 -0700, Adrian Chadd wrote: > Hi! > > On 31 October 2013 19:17, Ian Lepore <ian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1383315642.31172.88.camel>