From owner-freebsd-arm@FreeBSD.ORG Fri Nov 1 14:20:46 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 373856CB; Fri, 1 Nov 2013 14:20:46 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D7282058; Fri, 1 Nov 2013 14:20:45 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VcFae-000C6n-VI; Fri, 01 Nov 2013 14:20:45 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rA1EKgxV057145; Fri, 1 Nov 2013 08:20:42 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18+keEse3xf7yGOYBmADu8M Subject: Re: Wandboard support From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <1383272225.31172.60.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Nov 2013 08:20:42 -0600 Message-ID: <1383315642.31172.88.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:20:46 -0000 On Thu, 2013-10-31 at 21:58 -0700, Adrian Chadd wrote: > Hi! > > On 31 October 2013 19:17, Ian Lepore 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