From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 22:11:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83490ECC for ; Sat, 8 Feb 2014 22:11:40 +0000 (UTC) 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 51B6913B0 for ; Sat, 8 Feb 2014 22:11:39 +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 1WCG7Y-00051g-LO; Sat, 08 Feb 2014 22:11:32 +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 s18MBTgx069840; Sat, 8 Feb 2014 15:11:29 -0700 (MST) (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: U2FsdGVkX18228w4e86AcAy9vahBgrc3 Subject: Re: i.MX6 on-die temperature sensor From: Ian Lepore To: Steven Lawrance In-Reply-To: <1391893231-sup-6174@luwak.koffein.net> References: <1391893231-sup-6174@luwak.koffein.net> Content-Type: text/plain; charset="us-ascii" Date: Sat, 08 Feb 2014 15:11:29 -0700 Message-ID: <1391897489.1196.60.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 22:11:40 -0000 On Sat, 2014-02-08 at 22:32 +0100, Steven Lawrance wrote: > Hi all, > > a Wandboard turned up on my desk yesterday and I thought I'd get > started with something simple -- the on-chip temperature sensor. > > A patch is attached, but I've got a few questions, mostly about FDTs: > > The driver doesn't need to reserve any resources for itself but rather > refer to two others, anatop and ocotp. How can that relationship be > represented in the FDT? > > How is the sequence of device attachments determined? Just by the > order in the FDT? The current scenario seems quite fragile if that's > the case. > > For the OCOTP (on-chip one-time-programmable memory) side of things, I > just followed the pattern in imx6_anatop.c, which is to provide public > methods for accessing its memory space. But it feels a bit dirty -- I > imagine there could be cases where you would have two similar blocks > and things would fall apart. > > cheers, > Yeah, the devices are attached in the order listed in the fdt, which is pretty horrible and affects us we get fdt data mostly from linux (the source of standard fdt data for boards), and it isn't driven by the order of things in the data. The thing I did with anatop was a quick hack to get things going because I have no idea what services that conglomeration of hardware needs to provide to other entities (yet). ocotp is another thing I haven't looked at much, but it might be easier to come up with a clean API it can provide for other imx drivers. -- Ian