From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 06:53:49 2014 Return-Path: Delivered-To: freebsd-embedded@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 CD21F76C; Wed, 5 Mar 2014 06:53:49 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0D09CDA; Wed, 5 Mar 2014 06:53:48 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ec20so382897lab.39 for ; Tue, 04 Mar 2014 22:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w7LcJ9uQP48xbWxPvvAoLfI8VUVFNN5THwn5WqSEtCk=; b=g86DhWM7ElFTgtbR2FBjwDsOQI1dvkLjLvct/C5XnW/Gfyys07xQtFWKC+Y2dLMzAP X3pm/j5PogPTlY41AWBGI1ZIHAHP6PMz9yu5QjQ2Pd8rDi4uSSag+YjphBxLX/DQ+Fl/ mf5h08WdIBDAv66Fl3LnvXeEziP1gCV/rKborvSP9DeLjZu9KcxqoCE8QFzhEeD7ytdq GXeTW5ZxMrf72q9jQJsLDcZoyblfAEnJRuHNSFEmcJNM87nOdAjyxGiUHwyZ2WbVx6nY k/uhWKiBA7fEjqJdgUUyH8LcMdB4NTDie2ZtZhmDll+I5/bY2M6xv8q22wOruOUMHC9+ hEnw== MIME-Version: 1.0 X-Received: by 10.112.77.138 with SMTP id s10mr110546lbw.59.1394002426743; Tue, 04 Mar 2014 22:53:46 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Tue, 4 Mar 2014 22:53:46 -0800 (PST) In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> Date: Wed, 5 Mar 2014 01:53:46 -0500 X-Google-Sender-Auth: RcUlIv0UuuCSFCW0q6fIaFcdswc Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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 List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 06:53:50 -0000 On Tue, Mar 4, 2014 at 8:21 AM, 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. > 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. > * 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. > 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. 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. 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. > > 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. > > -- Ian > > >