Date: Mon, 06 Oct 2014 08:44:35 -0600 From: Ian Lepore <ian@FreeBSD.org> 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: <1412606675.12052.112.camel@revolution.hippie.lan> In-Reply-To: <CAN19L9FudV6PtsmE359Wfb216am3eaiEJtd6ixq2eOfJDZHbkA@mail.gmail.com> References: <CAN19L9ENsuAR6_aXwJSRdfDz6UgE6kU%2BrCkGGsdK7tRcUes%2B0w@mail.gmail.com> <FEB6A362-40F7-4418-8B28-F03506F6C365@bsdimp.com> <CAN19L9FudV6PtsmE359Wfb216am3eaiEJtd6ixq2eOfJDZHbkA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com>: > > On Oct 5, 2014, at 4:05 PM, Martin Galvan <omgalvan.86@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1412606675.12052.112.camel>