Date: Sun, 5 Oct 2014 17:06:30 -0600 From: Warner Losh <imp@bsdimp.com> To: Martin Galvan <omgalvan.86@gmail.com> Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org Subject: Re: A few questions about SD/MMC drivers Message-ID: <FEB6A362-40F7-4418-8B28-F03506F6C365@bsdimp.com> In-Reply-To: <CAN19L9ENsuAR6_aXwJSRdfDz6UgE6kU%2BrCkGGsdK7tRcUes%2B0w@mail.gmail.com> References: <CAN19L9ENsuAR6_aXwJSRdfDz6UgE6kU%2BrCkGGsdK7tRcUes%2B0w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_7FBCF358-F6C4-4334-9D73-9136E8EA2AD7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Oct 5, 2014, at 4:05 PM, Martin Galvan <omgalvan.86@gmail.com> wrote:
> Hello everyone! I'm currently working on an SD/MMC host controller
> driver for the Allwinner A10 SoC. Looking at some other drivers such
> as at91_mci.c and lpc_mmc.c it seems most if not all of them have
> roughly the same basic structure, so I thought I'd ask you guys a
> couple of questions about them:
>=20
> 1) I noticed most MMC drvers allocate their memory and interrupt
> resources using bus_alloc_resource_any by doing something like:
>=20
> /* Allocate a memory window */
> rid =3D 0;
> bus_alloc_resource_any(device, type, &rid, flags);
>=20
> /* Some code */
>=20
> /*Allocate an interrupt */
> rid =3D 0;
> bus_alloc_resource_any(device, type, &rid, flags);
>=20
> and on error handling code, they do:
>=20
> bus_release_resource(device, type, 0, resource);
>=20
> Looking at the man pages for both functions, it seems we shouldn't be
> ignoring the returned value of rid after bus_alloc_resource_any. From
> bus_release_resource(9):
>=20
> "rid is the resource ID of the resource. The rid value must be the
> same as the one returned by bus_alloc_resource(9)."
>=20
> Is there any reason why we're just passing it a hardcoded 0 instead of
> storing the returned rid?
Because we=92re naughty and know that it will always be 0. Yes, this =
directly
contradicts the man page.
> Furthermore, why are we passing
> bus_alloc_resource_any a value of 0 in the first place? Looking at
> bus_alloc_resource(9):
>=20
> "rid points to a bus specific handle that identifies the resource
> being allocated. For ISA this is an index into an array of resources
> that have been setup for this device by either the PnP mechanism, or
> via the hints mechanism. For PCCARD, this is an index into the array
> of resources described by the PC Card's CIS entry. For PCI, the offset
> into pci config space which has the BAR to use to access the resource.
> The bus methods are free to change the RIDs that they are given as a
> parameter. You must not depend on the value you gave it earlier.=94
We know 0 is the right value because 0 is the right value for the bus
that it lives on. :)=20
> I'm not implying the existing code is wrong, I'm just curious about
> why are we using those particular values.
Changing it to save the rid would be more pedantically correct, but in
this case, it would result in no changes.
> 2) The code I'm working on is based off the Linux driver for the same
> host, which as of today stands as the only "documentation", so to
> speak, on that particular host. According to the Linux driver, we need
> to do a phase shift adjustment while setting the clock in the set_ios
> function. That involves several steps, one of which is calling
> clk_set_rate, which seems to be a function many other Linux drivers
> use. As I'm not familiar with Linux kernel internals, so far I haven't
> been able to find the equivalent for that function on BSD, so how
> should I go about this?
Most likely you=92ll need to write the clock infrastructure for =
allwinner to
make this work. I don=92t believe that it is actually there today. Note: =
I=92ve
not looked at the allwinner core code in a long time, so maybe this
has already been rectified.
clk_set_rate in Linux adjusts the produced clock frequency for a clock
that=92s programmable in the SoC.
> 3) Finally, I noticed in the Linux driver they sometimes wrap a
> register read operation around a do-while loop waiting on both the
> result of that read and a timer, like this:
>=20
> do {
> read_value =3D read_a_register(some_register);
> } while ((read_value !=3D desired_value) && (time_before(jiffies, =
expire));
>=20
> where "expire" is an unsigned long whose value is computed as the sum
> of a global called "jiffies" and the result of a call to
> msecs_to_jiffies(). This is done so after the loop they can check
> whether the register holds the desired value or a timeout occurred. Do
> we have something similar on BSD? If not, what would be a safer way to
> implement a timeout mechanism than simply decreasing a counter?
Usually FreeBSD just uses a big number for the timeout, calculated based
on the bus access speed, some kludge factor and a healthy amount of
rounding up to the next power of 10 when it doesn=92t work.
Warner
--Apple-Mail=_7FBCF358-F6C4-4334-9D73-9136E8EA2AD7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJUMc72AAoJEGwc0Sh9sBEA0h0QAJBO1EyakV4ilE4kjOleXgii
FLBRW54ChRU+112NC2eI+SUcWvPohOujZMn4XKhJ97JOeaK4/YlSywblync522OL
Ww8ytCRiwZ+iSOBj1XhF2qpMTcWm6czyPemjdJnWyglfQ529tiBJnY9DxU5h4ieb
i0IbiioRpXcNlMfWDs9rfBFMKeEzlb5rNyj4Ij1S3v9EJ+Uw8cOuNNyQYyllZuyT
okaeXoq6i6GD8n0dRJyr0bR3V60Qiw8FqjLS+bzHhuFygQ9OD1ZaP/K9oOHVHYE0
ZQcHxrskc0myCtFCBtS7zd/yy04qCSJgDCURoY22IltCC0lfo7flS7ZoD6Ah4B3+
hNRJWtvVNj6ReuboIkkbAgB198eJfodFbqh5sEA60Kw+ECmBtQjNxLiNIX+G+VGc
3zbEEIrRfjMxaaIB2Ko8msEjhWQgJxF3bdZ/hHTCO1vVu+U2X1yCOOHi2x6vwnfV
nX8S7RoFLt3vN/xUrpoMHVRCa/SlzYDC/Y+8nmmfRcnauB1aPmqt0ry30kGmCpRr
CyHBpIILbh8+HEuNdR4+8s2MJ4rdgWM6jaAW3G6V1JoK7XQkyp+VQxgPypX0whSm
wfmEfiTN4K8D7DLqCB+06SfJ1vc8h6x8+frtlyTlQ2grO7+YWi7NcDctu8SEq0za
6Ciuyj6wPhioDjPvfpCo
=8IMX
-----END PGP SIGNATURE-----
--Apple-Mail=_7FBCF358-F6C4-4334-9D73-9136E8EA2AD7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FEB6A362-40F7-4418-8B28-F03506F6C365>