From owner-freebsd-drivers@FreeBSD.ORG Sun Oct 5 23:06:40 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 237277CA for ; Sun, 5 Oct 2014 23:06:40 +0000 (UTC) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAB59921 for ; Sun, 5 Oct 2014 23:06:39 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id a141so2868352oig.15 for ; Sun, 05 Oct 2014 16:06:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wMlrNUie0sz6gjBi1IB+7UPu96MSDsGVhjNJ8uHU7lE=; b=O1Sml43K1BftZ/OXSEoM8FqccTW/vRca7zajcEMsmoAcy+Ux0Jm6qAC3V5uDva6ZTy 6cLo4ParfPp8fvQfEVIqY91NwwI/Fd4KRRLoVlZO0Mj2GQlLdbKMOSGhy+SiEY9msAxh 243a+kNKD1kJiKuBIrebkFNDrQBuXdXcmoXtbdMGQ4BuefzUub7XjUsIw5zXMT8XLPGu dcCaV2dnGT+u2AepDqSQEmkZ3wd0AHUJzE5ya3K2CHz2W3W59Q8Jz8wFNUWXKFVDmyjG rbJIcBHl5xfO21/h1YlOcZgCJyzs7AGMmY4opT9hv2shwVDvnxAke5p1DMd2cewiRxLQ AhSw== X-Gm-Message-State: ALoCoQmktFm6EpgrwVI5qOND1AAakvtxcFbqG4tUJIxzFhCDcenHg7wboPdmAWE7YS+Mp9j2N8wZ X-Received: by 10.182.28.70 with SMTP id z6mr1912253obg.49.1412550392811; Sun, 05 Oct 2014 16:06:32 -0700 (PDT) Received: from bsdimp.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id w6sm8988995obz.20.2014.10.05.16.06.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Oct 2014 16:06:31 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_7FBCF358-F6C4-4334-9D73-9136E8EA2AD7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: A few questions about SD/MMC drivers From: Warner Losh In-Reply-To: Date: Sun, 5 Oct 2014 17:06:30 -0600 Message-Id: References: To: Martin Galvan X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 23:06:40 -0000 --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 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--