From owner-freebsd-arm@FreeBSD.ORG Wed Mar 5 18:55:58 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 CE3E1E98; Wed, 5 Mar 2014 18:55:58 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA6F4E6D; Wed, 5 Mar 2014 18:55:57 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so1020371lbi.30 for ; Wed, 05 Mar 2014 10:55:55 -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=I7zc9OQgiYTicjrU8DpLYtH888nxwDgi952COvK+C1o=; b=KporpxlEpERvTCqkrUSvDFJBIwj1uyxHYtwkIjsuIYSjFiXq48bB983EvxOBojxHDo cbBj5uGRHJaI0cspJLd4277FJQxn9iZCjx7oq0vrygfl+DP10pXnpXMa0zMoiiOvloy1 DsmRNGsrmw6tFoeuTY2zwUfh6oxCfiHMrk/+iUzPO58XOSS3WM6OU2ym/j0K6C7DfX5p bYcb86klyryBk4oBK3E3nF8SdsZol6CVgOOAqN7YpBal14VENpcb7zdNbVM4xBqIZDAm MmgjGjFCC4nC/7AAnAk/vhXgLe2sYGBlT+MnLzrVQu9BxrUOH5PxB4u73jL6lVdoPGYs 476Q== MIME-Version: 1.0 X-Received: by 10.152.172.103 with SMTP id bb7mr2520422lac.49.1394045755731; Wed, 05 Mar 2014 10:55:55 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 10:55:55 -0800 (PST) In-Reply-To: <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> Date: Wed, 5 Mar 2014 13:55:55 -0500 X-Google-Sender-Auth: hUgRJUIBql3DzZ-hk-6J0zryuhU Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh 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-embedded@freebsd.org, Ian Lepore 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: Wed, 05 Mar 2014 18:55:58 -0000 On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > 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. > > There's 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? > I'm laying out my view of the information that would be needed and the types of actions that would have to be taken based on that information to solve the issue. I'm not saying devd can't be the piece that is used to implement the actions (indeed, I noted devd as a potential building block for a solution in my initial response). I'm also not saying mmc needs its own mechanism, I'm saying it needs /a/ mechanism, and so far there still seems to be something missing (because it's not there, or I'm still ignorant of it). What seems to be missing is geographical addressing for mmc devices. I think what you might be saying is that the existing mmcsd add/remove code could be augmented to send devctl notifications, along the lines of: devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... controller= slot= rca=") and then I and the fine author of devctl and devd would be pleased. -Patrick