Date: Wed, 5 Mar 2014 15:44:22 -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: <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> In-Reply-To: <CAD44qMU46nqsw155qqKs7DrxXqawURgaUVEAaetzDExYM2LhYg@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> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <CAD44qMU46nqsw155qqKs7DrxXqawURgaUVEAaetzDExYM2LhYg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 5, 2014, at 2:56 PM, Patrick Kelsey <kelsey@ieee.org> wrote:
>=20
>=20
>=20
> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh <imp@bsdimp.com> wrote:
>=20
> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey <kelsey@ieee.org> wrote:
>=20
> >
> >
> >
> > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh <imp@bsdimp.com> wrote:
> >
> > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey <kelsey@ieee.org> wrote:
> >
> > >
> > >
> > >
> > > 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.
> >
> > 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?
> >
> > 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=3D<controller_device_name_or_better_yet_devicetree_path> =
slot=3D<slot_number> rca=3D<rca>")
> >
> > and then I and the fine author of devctl and devd would be pleased.
>=20
> 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:
>=20
> at91_mci0
> mmc0
> mmcsd0 at rca=3D0xb368
>=20
> 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
>=20
>=20
> The reason you need something extra here is that what is there now =
breaks down whenever you don't have a one-to-one mapping between =
controllers and buses. Any controller with more than one slot can yield =
something of the form:
>=20
> sdhci0
> mmc0
> mmcsd0 at rca=3D0xabcd
> mmc1
> mmcsd1 at rca=3D0x1234
>=20
> and you have no idea what physical slot in the system mmcsd0 and =
mmcsd1 are in.
The driver isn=92t going to be able to help you, because it reports mmc0 =
based on the data it gets from slot 0 status registers, and mmc1 based =
on slot 1 status registers. Since there=92s no notion of how that maps =
to physical hardware, the driver can=92t do anything automatically. And =
since mmc on down is populated by FreeSBD, there=92s no hints in the FDT =
tree for them.
> For my immediate use case, sure, I can rely on the one-to-one =
relationship between controllers and buses. At this point, though, =
rather than skate by on that happy coincidence, I'd rather invest what =
now seems to be a rather small amount of effort adding mmcsd devctl =
notifications that would cover the multiple-slots-per-controller case as =
well, and then build the rest of what I want on top of that information =
coming out of ddvd.
Trouble is, how do we know what to send with this new notification. =
That=92s the part I=92m having trouble with. Where does that data come =
from? And how is it different than what=92s in the device tree?
> On the at91 platform cited above, that allows you to connect two MMC =
cards to the same bus (i.e., multidrop configuration), is there any way =
to distinguish which card is in which physical slot? I'm still under =
the impression that this is the one case where we aren't going to be =
able to determine the physical location of every mmcsd device.
Actually, there=92s two different configurations, I believe. One that =
supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi =
drop. The former has been tested at least once, while the latter I don=92t=
think had ever been checked.
Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC>