Date: Wed, 27 Feb 2013 14:39:06 +0530 From: Mukunda Haveri <mukunda@pointred.co> To: "adam.huang" <sniperpr@gmail.com> Cc: freebsd-wireless@freebsd.org, freebsd-mips@freebsd.org Subject: =?UTF-8?B?UmU6IOWbnuWkje+8miBXaUZpIFRETUEgQVI3MTYxLCByZXN1bHRzIGFuZCBtb3ZpbmcgZg==?= =?UTF-8?B?b3J3YXJk?= Message-ID: <CAK3PU_Di3ZJOgRkDM_%2BWXgvud=Sve8pKNMWCZa-6ahQ=hAWT1g@mail.gmail.com> In-Reply-To: <1BB5E063EDB64336B8482336F34B0555@gmail.com> References: <CAK3PU_C9AW3xO1mofwT1iH_bgrBDYk3zJaLMJCbiRN-jakm%2BFA@mail.gmail.com> <CAJ-Vmo=eRboDNE-5JhQWq8zvsPnGt%2B7-KjZGBcw8RdQmK2q5jw@mail.gmail.com> <CAK3PU_DwXmZVR=jo-WF3DMLxaNF=hd8qWnyw6VWt0tS7iZ2XeQ@mail.gmail.com> <1BB5E063EDB64336B8482336F34B0555@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I can. Do you want to check it out yourself? That will be great. On the other hand, if you are looking to check out some thing different quickly, As I said earlier, I have not done any great deal of changes. Just checkout the head and alter a few parameters in the /sys/mips/conf file according to your hardware and compile. It just works !!! On Wed, Feb 27, 2013 at 2:25 PM, adam.huang <sniperpr@gmail.com> wrote: > hi, can you share your complex FW? > > thanks. > > 在 2013年2月27日星期三，下午4:51，Mukunda Haveri 写道： > > Hi, > > I have been trying in vain to get 2 freebsd based systems working with a > wlan-lan bridge. > > | Host A | <---> | Lan-side arge0 | <--> | AP Wlan | <--- Air ------- > > | STA Wlan | <---> | Lan-side arge0 | <--> | Host B | > > Is this functionality broken on the head? OR Am I missing something? > Appreciate if somebody can help me with scripts to setup the traffic in the > mode mentioned above. > We are using AR9280 based wireless card along with AR7161 boards from > Compex... > > Thanks, > Mukunda > > > On Tue, Feb 19, 2013 at 2:58 AM, Adrian Chadd <adrian@freebsd.org> wrote: > > On 18 February 2013 03:31, Mukunda Haveri <mukunda@pointred.co> wrote: > > > Thanks to Adrian's WiFi scripts, we were able to get the TDMA working on > > the > > Compex-AR7161 board. The results were surprising; we are able to do, > > close > > to 100 mbps one way iperf tests and 40 mbps bidirectional Iperf in > > non-TDMA > > mode. We were able to achieve this, only after disabling all the debug > options in the kernel. Porting the U-Boot to the Compex-boards did take > > lot > > of effort, but not the "FreeBsd". Many thanks to all the "scientists" who > made this possible. > > > Nice! Which wireless cards are you using? > > [ AR9280 ] > > > > Moving forward, it is observed that the TDMA throughput peaks at 9 mbps > > and > > refuses to move beyond. After reducing the slot duration to 1 ms, the > throughput increased to around 12 mbps. I was expecting the TDMA to > > yield a > > better throughput because of collision-less scheme. I would like to > understand if our observation is expected or if there's some inherent > limitation within the TDMA controller. > > It will be good to have some feedback from TDMers with similar > > experience or > > better. > > > Right now the TDMA code doesn't implement MCS rates or TX aggregation. > Thus you're not going to get 11n like throughput. > > The first thing to implement is allowing for MCS rates > (non-aggregation) and make sure all the packet duration calculations > are being done "right". > > After that, we need to implement delayed blockack support in net80211 > and the ath driver. That requires the stack to support handling BA > requests/responses and ath(4) to mark all frame descriptors in a > delayed-BA TID to be no-ack. > > Once that's done, we can tie it all together to make it work over TDMA. :-) > > Thanks, > > > Adrian > > > DISCLAIMER: > The information contained in this message (including any attachments) is > confidential and may be privileged. If you have received it by mistake > please notify the sender by return e-mail and permanently delete this > message and any attachments from your system. Any dissemination, use, > review, distribution, printing or copying of this message in whole or in > part is strictly prohibited. Please note that e-mails are susceptible to > change. PointRed Telecom Ltd (including its group companies) shall not be > liable for the improper or incomplete transmission of the information > contained in this communication nor for any delay in its receipt or damage > to your system and does not guarantee that the integrity of this > communication has been maintained or that this communication is free of > viruses, interceptions or interferences. > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > > > -- Mukunda H S V.P, Engineering mukunda@pointred.co 18/11B, Roopena Agrahara, Begur Hobli, Hosur Main Road, Bangalore - 560068. [image: Phone] Phone: +91 80 25724854 [image: Fax] Fax: + 91 80 25724856 DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. From owner-freebsd-mips@FreeBSD.ORG Thu Feb 28 22:48:47 2013 Return-Path: <owner-freebsd-mips@FreeBSD.ORG> Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD1FC792; Thu, 28 Feb 2013 22:48:47 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 22E1C7F0; Thu, 28 Feb 2013 22:48:46 +0000 (UTC) Received: from rnote.ddteam.net (12-60-135-95.pool.ukrtel.net [95.135.60.12]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id DDA49C492D; Fri, 1 Mar 2013 00:48:44 +0200 (EET) Date: Fri, 1 Mar 2013 00:48:28 +0200 From: Aleksandr Rybalko <ray@freebsd.org> To: Ian Lepore <ian@FreeBSD.org> Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130301004828.e0727064.ray@freebsd.org> In-Reply-To: <1361488675.1185.42.camel@revolution.hippie.lan> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <CAD44qMXkFH9iR=ym1XBtD88HRadpGkO=WRYvz5xhAVucEuoLEA@mail.gmail.com> <20130220174449.GB6976@cicely7.cicely.de> <CAD44qMXsdrhuNRbpA1a9ikj4BGffVfhv1WY6hsqCxHwVzQAdsg@mail.gmail.com> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <CAD44qMU6-GUDy+TUJ1Ndtcy7S42BCeSsFis0dMtj9LDOeDLwGA@mail.gmail.com> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> <1361488675.1185.42.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko <ray@FreeBSD.org>, Bernd Walter <ticso@cicely7.cicely.de>, freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org, ticso@cicely.de X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-mips>, <mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>; List-Post: <mailto:freebsd-mips@freebsd.org> List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>, <mailto:freebsd-mips-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 28 Feb 2013 22:48:47 -0000 On Thu, 21 Feb 2013 16:17:55 -0700 Ian Lepore <ian@FreeBSD.org> wrote: > On Fri, 2013-02-22 at 00:59 +0200, Aleksandr Rybalko wrote: > > On Thu, 21 Feb 2013 15:39:45 -0700 > > Ian Lepore <ian@FreeBSD.org> wrote: > > > > > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > > > > On Thu, 21 Feb 2013 17:30:03 +0100 > > > > Bernd Walter <ticso@cicely7.cicely.de> wrote: > > > > > > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey > > > > > wrote: > > > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > > > ><ray@freebsd.org> wrote: > > > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > > > > >> Bernd Walter <ticso@cicely7.cicely.de> wrote: > > > > > > >> > > > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr > > > > > > >> Rybalko wrote: > > > > > > >> > 2. teach consumers to give only correct numbers (very > > > > > > >> > nice we have only two SPI devices in tree) > > > > > > >> > > > > > > > >> > After that we will be able to make drivers for some > > > > > > >> > (potential) devices which will require bidirectional > > > > > > >> > communication. And controllers which can't do that, > > > > > > >> > will just report error in that. I believe peoples > > > > > > >> > thinks before attach such devices to controllers, so > > > > > > >> > we will not have such incompatibility. > > > > > > >> > > > > > > >> I don't think there are many devices requiring RX/TX at > > > > > > >> the same time. > > > > > > > > > > > > > > Anyway, we will be able to do that, and we don't care now > > > > > > > because don't have such drivers yet. > > > > > > > > > > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one > > > > > > wants to send meaningful data to the slave device at the > > > > > > same time one is interested in what data is returned during > > > > > > that transmission, there are such devices in use out > > > > > > there. Linear Technologies has several ADCs, such as the > > > > > > LTC2446, for which you obtain the previous conversion > > > > > > result while sending the configuration bits for the next > > > > > > conversion to be performed. > > > > > > > > > > Forgot about ADC with channel selection. > > > > > > > > > > > Although this is slightly out of focus for the specific > > > > > > issue originally raised, while on the topic of things that > > > > > > need to get done on SPI in real systems, there are also > > > > > > devices out there that require specific data or some number > > > > > > of clocks to be provided while chip select is deasserted. > > > > > > One example of the former is the LTC2404, which is a > > > > > > multichannel ADC for which the input channel for the next > > > > > > conversion is selected by the last four bits clocked in > > > > > > *before* chip select is asserted. One example of the latter > > > > > > is the spec for SPI access to MMC/SD cards, which requires > > > > > > a certain number of clocks to be applied with chip select > > > > > > deasserted in order to initialize the card. If you ever > > > > > > find yourself wondering why an SPI software interface > > > > > > provides independent bus acquisition and chip select > > > > > > control, the reason is to support these types of devices. > > > > > > > > > > With many ADC you also want probing support. > > > > > Assign CS and GPIO-read MISO for ready without clocking. > > > > > Some flash chips also work this way. > > > > > Not sure if AT45DB support this and how our driver works. > > > > > With own projects I usually ask AT45DB about ready state by > > > > > transfering a status word. > > > > > > > > > > -- > > > > > B.Walter <bernd@bwct.de> http://www.bwct.de > > > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD > > > > > Rechner uvm. > > > > > > > > Guys, I don't said it will not be supported. :) > > > > I said drivers of controllers who can't will return error in > > > > that case, but other might be ok. > > > > > > > > So, conclusion: go-go-go ray! do it please! > > > > :-D > > > > > > > > > > One other little thought to consider... since tx and rx size must > > > be the same if they're both non-zero, then could we change to > > > having a single io_size field, and pass a NULL pointer for rx or > > > tx buffer if that part of the transfer isn't needed? > > > > > > -- Ian > > > > > > > > > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 > > SPI works :) > > > > Objections? > > > > WBW > > So just to be clear... if a device driver passes a NULL tx pointer to > the controller driver, it's saying "My device doesn't care what it > receives during this transfer." If the device needs zeroes or ones > then the buffer full of them has to be provided, right? > > I'm thinking for the controller that does dma, this simplifies things > down to making a bus_dmamem_alloc() call (which is fast these days > because of the zone allocator) and it doesn't bother to set the > contents of that buffer to anything before starting the dma. > > -- Ian > > Hi hackers! Instead of implementation, new thoughts is coming :) Well, after few days of stabilization of ideas I'm beginning new round of talks. :) So, two days ago we had discussion with Ian on IRC. Things we decide: 1. Don't remove current transfer method 2. Add acquire/release methods 3. Add cs control methods 4. Add new transfer method, it will do only one xfer, and as described previously will have only size/txbuf/rxbuf fields in transfer struct. Tx and/or rx can be NULL, so even clocking without data possible. 5. Update old transfer method(spibus_transfer) to do: * acquire * enable cs * transfer cmd * transfer data * disable cs * release bus 6. Add some method which will expose hw ability (one direction at a time, independent cs control, etc.) 7. Maybe some other special methods (Ian said for SD on spi we need ability to xfer w/o CS asserted) That how I see new xfer structure: struct spi_xfer { size_t size; /* Transfer size (bytes) */ void *tx_buf; /* Buffer with TX data (NULL to not tx) */ void *rx_buf; /* Buffer for RX data (NULL for ignore) */ }; Simple and clear :) WBW -- Aleksandr Rybalko <ray@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK3PU_Di3ZJOgRkDM_%2BWXgvud=Sve8pKNMWCZa-6ahQ=hAWT1g>