From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 13:31:47 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 D03B2C25 for ; Wed, 5 Mar 2014 13:31:47 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 952B59E9 for ; Wed, 5 Mar 2014 13:31:47 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id uq10so7717184igb.5 for ; Wed, 05 Mar 2014 05:31:41 -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:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=v3nL8+l2MOPOQwrfj7uRwzmfI/Vvjwopc6aX8ig5em8=; b=AmhIyCXn/GA5uxomwnromQJooJT8Dh4yGOO75JuuVxkBaBixIZOYBKlCoE0JCcyZQ9 H/U8t0R9Mh6XBdIraqLItBTvdu7ZQuTNMsHyQH6naj2fm+7amDV2aLNaWhO3vX05ThUz ov3DHA2yQQLQvoV7YqL9UAqlRVt0lEI35Gn4m8JnH2wkQu15ExRTgCwgT4+p16UByvi0 vVd9JnKGefdE6KYLsOfolyMA0yWsXFx5hxfGnRG6ciJKOiZngpA57vcGvnS8Yg+wIdsa nOvgebqMz6S+tyoeFmWstnhVIMddPFuJb/XqoWsJaXzNCe4SP8FQeKICNetVHt+j2jTZ voQw== X-Gm-Message-State: ALoCoQkN8GHJsl2BAQcV3on5zrtK2NU9gXXWKtDBovp2zW6sw3cI6c780nT7XG7h4WVFhNGcg+bR X-Received: by 10.50.119.132 with SMTP id ku4mr8927242igb.35.1394026300866; Wed, 05 Mar 2014 05:31:40 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id v2sm13404632igk.7.2014.03.05.05.31.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 05:31:40 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 06:31:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:31:47 -0000 On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: >=20 > 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). >=20 > 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... >=20 > * 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. >=20 > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > =20 > * I want the slot on the left to be named '1' and the right to = be > '0'. >=20 > 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. >=20 > 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. >=20 > We should be able to assign a geographic address (controllerX:slotY) = to each mmcsd device in a given system (let's ignore for now the = theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. Why is mmc so different it needs its own mechanism? Warner > That kind of approach addresses both concerns, avoids trying to = control device unit number assignment, and doesn't require any special = support from the device tree. >=20 > In the theoretically possible case of multiple MMC devices on one bus, = the next piece of identifying information in the geographic address = would have to be the RCA assigned to the card. As far as I am aware, in = such a multidrop configuration, there is generally no way for a = controller to know which RCA is assigned to which slot due to the = contention-based (that is, non-geographic) nature of the initialization = protocol, so this would be a configuration in which stable names would = not be possible without an ad-hoc, out-of-band hardware support. Does = anyone know if sharing a bus is only a possibility with MMC cards? I = *think*, but am not feeling authoritative, that SD/SDIO cards do not = support multiple devices on one bus. > =20 >=20 > 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. >=20 > -- Ian >=20 >=20 >=20