From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 4 14:30:13 2014 Return-Path: Delivered-To: freebsd-embedded@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 8C790433; Tue, 4 Mar 2014 14:30:13 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EAA2CAC; Tue, 4 Mar 2014 14:30:12 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s24EPOB9027697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 15:25:25 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s24EPEvL082602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2014 15:25:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s24EPE8f038990; Tue, 4 Mar 2014 15:25:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s24EPDlY038989; Tue, 4 Mar 2014 15:25:13 +0100 (CET) (envelope-from ticso) Date: Tue, 4 Mar 2014 15:25:13 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Message-ID: <20140304142513.GH15675@cicely7.cicely.de> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:30:13 -0000 On Tue, Mar 04, 2014 at 06:21:17AM -0700, Ian Lepore wrote: > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side (whether > it's non-removable or a gpio pin). > > That alone doesn't solve the wider problem, though, which I think breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > there's a card in the left slot when I boot; I don't want it to > change. > * I want the slot on the left to be named '1' and the right to be > '0'. > > The first problem is easily solved without impacting dts in any way. We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. > > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure how > easy it would be. > > There's been talk of moving mmcsd towards using CAM. I don't know that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a specific > device/slot/whatever. CAM has wiring support. This had been the case for SCSI even before CAM was written and was vital in the days with many SCSI drives but without disk labeling support. Example from sys/conf/NOTES: hint.scbus.0.at="ahc0" hint.scbus.1.at="ahc1" hint.scbus.1.bus="0" hint.scbus.3.at="ahc2" hint.scbus.3.bus="0" hint.scbus.2.at="ahc2" hint.scbus.2.bus="1" hint.da.0.at="scbus0" hint.da.0.target="0" hint.da.0.unit="0" hint.da.1.at="scbus3" hint.da.1.target="1" hint.da.2.at="scbus2" hint.da.2.target="3" hint.sa.1.at="scbus1" hint.sa.1.target="6" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.