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.