From owner-freebsd-drivers@FreeBSD.ORG Sun Oct 5 22:05:18 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED24BD63; Sun, 5 Oct 2014 22:05:17 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 B220D179; Sun, 5 Oct 2014 22:05:17 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wm4so3134411obc.12 for ; Sun, 05 Oct 2014 15:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=am4l1rFbm7cFrdqYbaCBDQpdYxFp0hdpgYMzii/VvXw=; b=rFUnL5db9RnlVjsiaOMddC7spE/Yh0dXlEyy1gGnWMV1MWZ/7YeGrn/NkXm8C915hK njEG1sRNK3H8eAoUWTbEMEv7hzGD95WrXvdXbHK4c7bsfek1hAZtXz9N1+oh7XKS7j9i pTbZ3VH4FCpLw6+uvuGewkGRlR4L7NNAHrYd1aho1mVa6nmUI4JTXrP6+kC7ZWFIaDNh 1qqeyjhHd9naqyo7sTwU2YayDDQRCR+oSIQR3ZR+Qr4XMAdVfOx/4GJfq4jz+xzbR1t+ +PQomb8vC6O3GWfYTKjPnauv7LFKPRDBU+W1wTXuSijNMBFLXgA6kySqk0KO6Az92S/p iD4Q== MIME-Version: 1.0 X-Received: by 10.60.61.109 with SMTP id o13mr10835719oer.13.1412546716766; Sun, 05 Oct 2014 15:05:16 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Sun, 5 Oct 2014 15:05:16 -0700 (PDT) Date: Sun, 5 Oct 2014 19:05:16 -0300 Message-ID: Subject: A few questions about SD/MMC drivers From: Martin Galvan To: freebsd-drivers@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: 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 22:05:18 -0000 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: 1) I noticed most MMC drvers allocate their memory and interrupt resources using bus_alloc_resource_any by doing something like: /* Allocate a memory window */ rid = 0; bus_alloc_resource_any(device, type, &rid, flags); /* Some code */ /*Allocate an interrupt */ rid = 0; bus_alloc_resource_any(device, type, &rid, flags); and on error handling code, they do: bus_release_resource(device, type, 0, resource); 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): "rid is the resource ID of the resource. The rid value must be the same as the one returned by bus_alloc_resource(9)." Is there any reason why we're just passing it a hardcoded 0 instead of storing the returned rid? Furthermore, why are we passing bus_alloc_resource_any a value of 0 in the first place? Looking at bus_alloc_resource(9): "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." I'm not implying the existing code is wrong, I'm just curious about why are we using those particular values. 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? 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: do { read_value = read_a_register(some_register); } while ((read_value != desired_value) && (time_before(jiffies, expire)); 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? Thanks a lot! 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-- From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 6 00:32:05 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 C9050784; Mon, 6 Oct 2014 00:32:05 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 8980614F; Mon, 6 Oct 2014 00:32:05 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wo20so3166303obc.17 for ; Sun, 05 Oct 2014 17:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O+giOanmTWavuoC8MfPqEe5Jw7wlgIirHsU+kG/okAk=; b=ePbI99RTsmOzcAYDLmpUwLmx7rY4Tyy1fYpoCRyng8id39DYl0jKTGG2fCkriW3xwo I1st7UuTQ4Kf2i5BcNQoqpWXupFLqzWxiZCgQ7/FEAibyM5zZjn/hVwfr+HqAUL2GSyc a1ZaGVFCZNGKxlF7G5WEjpVN9HiZKsJ7X6hE1K0KrPCZG1MXB+F+1fVVXNJhjr8OkSOG xHN36LgdkM+mRK73ZYW/xNhd9KYX/eym2NwY+8A3FKeMEEW3/YhdKWNS98x0OWJV53r+ fMouBCY4CSAZYCHLai67eQ6AdpXHbNMGhjgqtYejhNRrJeYCpIzdCJ3rKxVMGkuImEls pt0g== MIME-Version: 1.0 X-Received: by 10.60.39.5 with SMTP id l5mr23085322oek.23.1412555524830; Sun, 05 Oct 2014 17:32:04 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Sun, 5 Oct 2014 17:32:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 21:32:04 -0300 Message-ID: Subject: Re: A few questions about SD/MMC drivers From: Martin Galvan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 06 Oct 2014 00:32:06 -0000 Hi Warner! Thanks for your answer. 2014-10-05 20:06 GMT-03:00 Warner Losh : > On Oct 5, 2014, at 4:05 PM, Martin Galvan wrote: > >> 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=E2=80=99ll need to write the clock infrastructure for all= winner to > make this work. I don=E2=80=99t believe that it is actually there today. = Note: I=E2=80=99ve > not looked at the allwinner core code in a long time, so maybe this > has already been rectified. Well, there's a a10_clk.c file in the current tree that (sort of) takes care of the clocking for Allwinner. > clk_set_rate in Linux adjusts the produced clock frequency for a clock > that=E2=80=99s programmable in the SoC. I actually forgot to mention I'm reworking Alex Fedorov's MMC patch. While indeed there's not a function for clocking the MMC host yet in the tree, Alex's patch did include a basic clocking function in a10_clk.c that does the necessary register magic to get things working, but doesn't do any of the phase shifting. I believe I can get that done if I could find a way to implement something similar to clk_set_rate, at least for this driver. In any case, the phase shift thing seems to be mostly for speeding things up a bit (I managed to get Alex's driver working by fixing a couple of bugs here and there; it's kind of slow since it doesn't support DMA nor multiblock operations yet), and we can probably add that later. Speaking of multiblock support, I noticed at some point your at91_mci.c had multiblock operations working but then you switched to single-block only (at least I'm sure I saw a version where MMCBR_IVAR_MAX_DATA returned something other than 1). Do you remember what happened there? Again, thanks a lot for your answer. From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 6 14:44:44 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6730E790; Mon, 6 Oct 2014 14:44:44 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2689965D; Mon, 6 Oct 2014 14:44:43 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xb9Wf-0009FP-CY; Mon, 06 Oct 2014 14:44:37 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s96EiaaJ028374; Mon, 6 Oct 2014 08:44:36 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19gzCF4+mkk5FLQnpzt2wB5 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: A few questions about SD/MMC drivers From: Ian Lepore To: Martin Galvan In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-7" Date: Mon, 06 Oct 2014 08:44:35 -0600 Message-ID: <1412606675.12052.112.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s96EiaaJ028374 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: Mon, 06 Oct 2014 14:44:44 -0000 On Sun, 2014-10-05 at 21:32 -0300, Martin Galvan wrote: > Hi Warner! Thanks for your answer. >=20 > 2014-10-05 20:06 GMT-03:00 Warner Losh : > > On Oct 5, 2014, at 4:05 PM, Martin Galvan wro= te: > > > >> 2) The code I'm working on is based off the Linux driver for the sam= e > >> host, which as of today stands as the only "documentation", so to > >> speak, on that particular host. According to the Linux driver, we ne= ed > >> to do a phase shift adjustment while setting the clock in the set_io= s > >> 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=A2ll need to write the clock infrastructure for allwi= nner to > > make this work. I don=A2t believe that it is actually there today. No= te: I=A2ve > > not looked at the allwinner core code in a long time, so maybe this > > has already been rectified. >=20 > Well, there's a a10_clk.c file in the current tree that (sort of) > takes care of the clocking for Allwinner. >=20 > > clk_set_rate in Linux adjusts the produced clock frequency for a cloc= k > > that=A2s programmable in the SoC. >=20 The phase shift adjustment thing sounds like support for the Ultra rates (clocks faster than 50mhz and clocking data on both clock edges). I think people would be plenty happy to have 25 and 50mhz support without any of the ultra rates, for starters. That may let you ignore the phase tuning stuff. Maybe look at the driver in u-boot if it has one, often the u-boot drivers are simplified compared to the full linux driver. Also, it may be that if you do an "mmc init" in u-boot the driver will work without doing any more clock stuff at all, because u-boot will do all the hardware setup. It's best if our drivers can set up what they need for themselves, but letting u-boot do it is a good starting point. > I actually forgot to mention I'm reworking Alex Fedorov's MMC patch. > While indeed there's not a function for clocking the MMC host yet in > the tree, Alex's patch did include a basic clocking function in > a10_clk.c that does the necessary register magic to get things > working, but doesn't do any of the phase shifting. I believe I can get > that done if I could find a way to implement something similar to > clk_set_rate, at least for this driver. In any case, the phase shift > thing seems to be mostly for speeding things up a bit (I managed to > get Alex's driver working by fixing a couple of bugs here and there; > it's kind of slow since it doesn't support DMA nor multiblock > operations yet), and we can probably add that later. >=20 > Speaking of multiblock support, I noticed at some point your > at91_mci.c had multiblock operations working but then you switched to > single-block only (at least I'm sure I saw a version where > MMCBR_IVAR_MAX_DATA returned something other than 1). Do you remember > what happened there? >=20 > Again, thanks a lot for your answer. The at91_mci driver is full of workarounds for the buggy rm9200 hardware. When the sam9 series came out they fixed some of the silicon bugs and now the code in the driver needs reworking to match, but nobody has done it yet. Switching back to single-block IO bypasses most of the rm92 workaround code. -- Ian From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 6 14:51:33 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 354F8BE3; Mon, 6 Oct 2014 14:51:33 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 DBF977EA; Mon, 6 Oct 2014 14:51:32 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id m8so3954478obr.35 for ; Mon, 06 Oct 2014 07:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4Pvbf1YJxwya+gXEQNQ/DT4tGPC6OFotweQIyWwQpVU=; b=kQUEj3zdTDKGOSaBEgOnbrQG7R18oUYwSvMq/JdwHXFujmx8RgJFqGW4N4Kwf0KKbA ONFVuTQHxUrUMupCCk9zfUzrkoY4Gph8u8Kf5ymESMeAnsgYunD9Z0IhHBEX4tPZ+GSo UV7hvC6R5v/BZ1yNJuoi2KDuIqMlJn8v6TdWV+D/GtAYJZ1eRxfPrf6HPsm6wd0EaBEC 6FJasYQrbJy5sueFS8FcGJyW9m9WN0pl3qKfezHZ8fUCyW+d1Xn7j1Aj2HcGVo282P1c 5Xr8k9guccmQAN/4bbHhO3xjVvKQuPN9mKP/0hEDsmwP2nEHjCBJ0JktrPvP+6cbQKMj eh+A== MIME-Version: 1.0 X-Received: by 10.60.102.100 with SMTP id fn4mr28063611oeb.30.1412607092084; Mon, 06 Oct 2014 07:51:32 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Mon, 6 Oct 2014 07:51:32 -0700 (PDT) In-Reply-To: <1412606675.12052.112.camel@revolution.hippie.lan> References: <1412606675.12052.112.camel@revolution.hippie.lan> Date: Mon, 6 Oct 2014 11:51:32 -0300 Message-ID: Subject: Re: A few questions about SD/MMC drivers From: Martin Galvan To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 06 Oct 2014 14:51:33 -0000 2014-10-06 11:44 GMT-03:00 Ian Lepore : > On Sun, 2014-10-05 at 21:32 -0300, Martin Galvan wrote: >> Hi Warner! Thanks for your answer. >> >> 2014-10-05 20:06 GMT-03:00 Warner Losh : >> > On Oct 5, 2014, at 4:05 PM, Martin Galvan wrot= e: >> > >> >> 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 nee= d >> >> 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=E2=80=99ll need to write the clock infrastructure for = allwinner to >> > make this work. I don=E2=80=99t believe that it is actually there toda= y. Note: I=E2=80=99ve >> > not looked at the allwinner core code in a long time, so maybe this >> > has already been rectified. >> >> Well, there's a a10_clk.c file in the current tree that (sort of) >> takes care of the clocking for Allwinner. >> >> > clk_set_rate in Linux adjusts the produced clock frequency for a clock >> > that=E2=80=99s programmable in the SoC. >> > > The phase shift adjustment thing sounds like support for the Ultra rates > (clocks faster than 50mhz and clocking data on both clock edges). I > think people would be plenty happy to have 25 and 50mhz support without > any of the ultra rates, for starters. That may let you ignore the phase > tuning stuff. Maybe look at the driver in u-boot if it has one, often > the u-boot drivers are simplified compared to the full linux driver. I'm not sure if that's exactly the case. Quoting the author of the Linux dr= iver: "you have to clock up mmc0 mod clock and adapt the phase shift in order to compensate the delays caused by line distance on the PCB. This is done in here: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drive= rs/mmc/host/sunxi-mmc.c?id=3D3cbcb16095f916f50a5a55066fcc4be06946ce1e#n617 " > Also, it may be that if you do an "mmc init" in u-boot the driver will > work without doing any more clock stuff at all, because u-boot will do > all the hardware setup. It's best if our drivers can set up what they > need for themselves, but letting u-boot do it is a good starting point. That's a great idea, I never thought of looking at the u-boot driver. I'll try out DMA and multiblock first anyways, and if it works fast enough to at least be able to boot directly from the SD card I'll send you guys the patches. From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 6 17:15:28 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 621588C7; Mon, 6 Oct 2014 17:15:28 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA06DBAB; Mon, 6 Oct 2014 17:15:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s96HFM9w024016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 20:15:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s96HFM9w024016 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s96HFMwt024015; Mon, 6 Oct 2014 20:15:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Oct 2014 20:15:22 +0300 From: Konstantin Belousov To: Martin Galvan Subject: Re: A few questions about SD/MMC drivers Message-ID: <20141006171521.GD26076@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home 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: Mon, 06 Oct 2014 17:15:28 -0000 On Sun, Oct 05, 2014 at 07:05:16PM -0300, Martin Galvan wrote: > 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: > > do { > read_value = read_a_register(some_register); > } while ((read_value != desired_value) && (time_before(jiffies, expire)); > > 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? Look at the _intel_wait_for() in the sys/dev/drm2/i915/intel_drv.h. There is improved version of the macro in the i915 update I posted several days ago. From owner-freebsd-drivers@FreeBSD.ORG Fri Oct 10 08:16:05 2014 Return-Path: Delivered-To: drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94BA6C27 for ; Fri, 10 Oct 2014 08:16:05 +0000 (UTC) Received: from mail.techwiresolutions.com (mail.techwiresolutions.com [182.73.104.85]) by mx1.freebsd.org (Postfix) with ESMTP id EBC56632 for ; Fri, 10 Oct 2014 08:16:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.techwiresolutions.com (Postfix) with ESMTP id 77DDB22FF7 for ; Fri, 10 Oct 2014 13:38:36 +0530 (IST) Received: from mail.techwiresolutions.com ([127.0.0.1]) by localhost (mail.techwiresolutions.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3zZ_QX6x079j for ; Fri, 10 Oct 2014 13:38:30 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by mail.techwiresolutions.com (Postfix) with ESMTP id C99F0236C8 for ; Fri, 10 Oct 2014 13:02:53 +0530 (IST) X-Virus-Scanned: amavisd-new at techwiresolutions.com Received: from mail.techwiresolutions.com ([127.0.0.1]) by localhost (mail.techwiresolutions.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KdIjk8dC8jEe for ; Fri, 10 Oct 2014 13:02:53 +0530 (IST) Received: from techwiref8a865 (unknown [192.168.1.158]) by mail.techwiresolutions.com (Postfix) with ESMTPSA id 93C0B23A11 for ; Fri, 10 Oct 2014 12:43:01 +0530 (IST) From: "Jason" To: Subject: RE:Website Re-Design and Development Date: Fri, 10 Oct 2014 12:44:18 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ac/kWczIVllseqL1S8uvaS1dSaPUlA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Message-Id: <20141010071301.93C0B23A11@mail.techwiresolutions.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Fri, 10 Oct 2014 08:16:05 -0000 Hi, I Just want to confirm that did you get my last mail or not. Haven't heard back from you, just wondering are you interested in our proposal? If you are interested then I can send you our Company profile and I can share more details on the packages/action for your website with affordable quotation. I'm looking forward to your views. Best Regards, Jason _____ From: Jason [mailto:jason@techwiresoftsol.com] Sent: Tuesday, September 23, 2014 11:35 AM To: drivers@freebsd.org Subject: Website Re-Design and Development Hi, Hope you are doing well. I am Jason, Business Development Manager. I was surfing through site from your domain and came across yours Website: www.freebsd.org I have been observing various changes in trends in the industry and the types of sites other players in your domain are using. The field has grown since you last updated your website as per available records in Domain tools. There are a lot more advanced and user friendly websites which appeal to the consumer. A website determines the brand of a firm in the online world. Do let me know if you are willing to discuss a possible design/development of your website and I can send you more details on the packages/action. Kind Regards, Jason Post: - Business Development Manager Note: - Though this is not an automated email, we keep on sending out these emails to all those people whom we find eligible of using our services. To unsubscribe from future mails (i.e., to ensure that we do not contact you again for this matter), please send a blank mail, with NO as the Subject.