From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 21:33:46 2014 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 ESMTPS id 4A15A36B for ; Sat, 8 Feb 2014 21:33:46 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by mx1.freebsd.org (Postfix) with ESMTP id 167BA1168 for ; Sat, 8 Feb 2014 21:33:45 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 165C025C063 for ; Sat, 8 Feb 2014 13:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=koffein.net; h=from:to :subject:date:message-id:mime-version:content-type: content-transfer-encoding; s=koffein.net; bh=KLIDz2cYACuXHZZxVNK rAzSWxno=; b=i0NW9igd+s8kni5XxAGwLbVEd8ZpWL0Vvnud3GZxeAw0XBjEqug TM07OTwkY9emvFbOpb23fIE5ydZSiJ/8zmTQj05nDbS+jGkbLDqqLh2KC/1vdJik +8hhg9Za2qrKHpVvzh4/W5AtJ5fAnEVJEh+FsU78FwzRG7QU+aCmNrLE= Received: from localhost (unknown [77.109.124.99]) (Authenticated sender: stl@koffein.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id 22FC025C062 for ; Sat, 8 Feb 2014 13:33:37 -0800 (PST) From: Steven Lawrance To: freebsd-arm Subject: i.MX6 on-die temperature sensor Date: Sat, 08 Feb 2014 22:32:31 +0100 Message-Id: <1391893231-sup-6174@luwak.koffein.net> User-Agent: Sup/git MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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 21:33:46 -0000 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, -- Steven Lawrance stl@koffein.net