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. > > =E5=9C=A8 2013=E5=B9=B42=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89= =EF=BC=8C=E4=B8=8B=E5=8D=884:51=EF=BC=8CMukunda Haveri =E5=86=99=E9=81=93= =EF=BC=9A > > 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 t= he > 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 damag= e > 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" > > > --=20 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 pl= ease notify the sender by return e-mail and permanently delete this messa= ge 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 ha= s been maintained or that this communication is free of viruses, intercep= tions or interferences. = =0D 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>