Date: Wed, 5 Mar 2014 14:24:57 -0700 From: Warner Losh <imp@bsdimp.com> To: Patrick Kelsey <kelsey@ieee.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, freebsd-embedded@freebsd.org, Ian Lepore <ian@freebsd.org> Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Message-ID: <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> In-Reply-To: <CAD44qMWNGPY70NMkTWoWcMTf1pywhSPGdbJpmbxxSxEdENSOJQ@mail.gmail.com> References: <CAD44qMUyqzaFtjgXdgThgHcHjPctx-oZAdhvHp4Kf0G7N4HVog@mail.gmail.com> <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <CAD44qMXe8bh0cR60tm8%2BLZ9W3WhJDuGX6xz9FLNHrzmXNd5FDQ@mail.gmail.com> <1393939277.1149.300.camel@revolution.hippie.lan> <CAD44qMWLox0yY1-%2B2bn4dQ=z0jWKow95b=mnCJEkwmSiSipf4g@mail.gmail.com> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <CAD44qMWNGPY70NMkTWoWcMTf1pywhSPGdbJpmbxxSxEdENSOJQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 5, 2014, at 11:55 AM, Patrick Kelsey <kelsey@ieee.org> wrote:
>=20
>=20
>=20
> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh <imp@bsdimp.com> wrote:
>=20
> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey <kelsey@ieee.org> wrote:
>=20
> >
> >
> >
> > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore <ian@freebsd.org> 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.
>=20
> 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.
>=20
> Why is mmc so different it needs its own mechanism?
>=20
> 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).
>=20
> What seems to be missing is geographical addressing for mmc devices.
>=20
> 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:
>=20
> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... =
controller=3D<controller_device_name_or_better_yet_devicetree_path> =
slot=3D<slot_number> rca=3D<rca>")
>=20
> and then I and the fine author of devctl and devd would be pleased.
MMC doesn=92t need anything special here. That=92s already present. =
Looking at the device tree we see on one of the platforms that=92s handy =
for me to access:
at91_mci0
mmc0
mmcsd0 at rca=3D0xb368
So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is =
ultimately the FDT node where things came from. There=92s not a =
user-defined slot associated with this (and we should have a SLOT A vs =
SLOT B as a location info for this platform, because we can have two =
cards on the one bus in the MMC case), true, but for your use case I =
don=92t think that you need it. We should be attaching the host =
controller regardless of whether the or not there=92s a card in there, =
so it will be fixed. While some additional information would be useful =
to publish, I don=92t think your use case requires it=85
Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16A5203B-B06D-4129-A54F-F34D5FA28D2B>