From owner-freebsd-arm@FreeBSD.ORG Sun Feb 9 00:04:21 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 6A9EEA09 for ; Sun, 9 Feb 2014 00:04:21 +0000 (UTC) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30CCC1B46 for ; Sun, 9 Feb 2014 00:04:20 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id j1so4373338iga.2 for ; Sat, 08 Feb 2014 16:04:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=EDAkwS88hvwdakYVGagF0fKInL9IiaoteqZm8dD2LHA=; b=LcJQxYtiq3vW5IXKNoIaJ2DqeoTDqaYPrvDGuwcgRtgTGmsl3b5eSDGsq04fXPGmye M9TweotexV9hEVkPHHyJrDitpqixFuj/0lsJTOOFJzP3FPV0aFq7UNS+K3Eb5zTKVmFf JsufczysazO29ZgcYyDN4WvJlsU/Gpr3TPzcy6I0Wbvnbip48Lhkvxca53h/vsZBgU6s 4u6bscY2ZczVThpIRpZ9dptWoGFgoyFGk1j1caKi67f2Gm2HIniG/sSo7t+TVVzO4u/G gxRtHEX9TeynX8/1JG5CCBio30AoDA0dVyujsEY0KLZEx/JF5Mho09/zZujZAYvaXq6V Ye5A== X-Gm-Message-State: ALoCoQkO927p4i5czaQcwp5SmDXxUtfbTsLHvJt9QQ1KJQ8cT0MceSN9hBTj/6rOgugr3vIyZAMt X-Received: by 10.50.176.165 with SMTP id cj5mr7128040igc.19.1391904253793; Sat, 08 Feb 2014 16:04:13 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id kz4sm25635210igb.4.2014.02.08.16.04.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Feb 2014 16:04:13 -0800 (PST) Sender: Warner Losh Subject: Re: i.MX6 on-die temperature sensor Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <52F6B861.8010908@freebsd.org> Date: Sat, 8 Feb 2014 17:04:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1391893231-sup-6174@luwak.koffein.net> <1391897489.1196.60.camel@revolution.hippie.lan> <52F6B861.8010908@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org 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: Sun, 09 Feb 2014 00:04:21 -0000 On Feb 8, 2014, at 4:06 PM, Nathan Whitehorn wrote: > On 02/08/14 16:11, Ian Lepore wrote: >> On Sat, 2014-02-08 at 22:32 +0100, Steven Lawrance wrote: >>> Hi all, >>>=20 >>> a Wandboard turned up on my desk yesterday and I thought I'd get >>> started with something simple -- the on-chip temperature sensor. >>>=20 >>> A patch is attached, but I've got a few questions, mostly about = FDTs: >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> cheers, >>>=20 >> 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. >>=20 >=20 > This isn't true. They are only attached in FDT order if your driver = does not specify an alternative. Many of these issues, although not the really complex one Nathan refers = to, I think, are solved by just deferring using the resources that = belong to other devices until you know they've all been probed. We have = a convenient place to do this which we use to enumerate usb bus = topology, known SD cards, known sata drives, etc. config_intrhook(). I = plan on using this to attach devices to the gpiobus after we know all = the gpio nodes in the tree... As for how to refer to other nodes, the clean way is to have a property = in your device node that refers to the other nodes, and we can lookup = the device_t associated with the phandle_t in the property in the FDT = tree. But I'm not sure we have that yet in the tree. Warner