linux-mips
[Top] [All Lists]

Re: [PATCH] ath5k: Use mips generic dma-mapping functions to avoid seqfa

To: Nikolay Ledovskikh <nledovskikh@gmail.com>
Subject: Re: [PATCH] ath5k: Use mips generic dma-mapping functions to avoid seqfault on AHB chips
From: Jiri Slaby <jirislaby@gmail.com>
Date: Tue, 15 Feb 2011 23:18:51 +0100
Cc: "John W. Linville" <linville@tuxdriver.com>, linux-wireless@vger.kernel.org, lrodriguez@atheros.com, mickflemm@gmail.com, me@bobcopeland.com, Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=h6r3YEZJp2n6U6qDMjnnXhnUPK5O10wuvX2iHnsyczY=; b=CnnBbQ3VTWKrQoMnEzJO59IjUg3IXLTsaFB3QB71EJJlq2YSpNhhbSFLQiun/jyKdJ +nl/H4HrjsJihcco2Bg8kmglOInozfRcbDDOMlFNC/sidshoTWe6YZG1zSo5P9kzBQZX QXxoZFGrtrPaYSzYcQCo3pzMTO4h/th60aqyA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=QT/e9m+m4FqyWIiylJOdOrWknDGdVusvMgSn2VyayVsFJOFpUfLDyAcfdYgW4H10jD DaYiSF4nKF05mFtJyRmsTyBpqLgPKZ0aIqkP7VLVUYGSbZZLJ12TVH6ePWSW6aRZ0rgD FUUntLeuebZ1pI+EkxDHHARMsQy9/9kbS8Gp0=
In-reply-to: <4D5AFB3B.6080407@gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20110215220929.1cc6e9d4.nledovskikh@gmail.com> <4D5AD6A6.8090505@gmail.com> <AANLkTiks9rG2CzM2LabNerK3zgJ+R+weytQgvXxDbNe7@mail.gmail.com> <4D5AE52B.80002@gmail.com> <AANLkTinnCOEXF835yhNeJDfBdKjx_dss6TFeUmjL-Yk2@mail.gmail.com> <4D5AFB3B.6080407@gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7
On 02/15/2011 11:16 PM, Jiri Slaby wrote:
> On 02/15/2011 10:39 PM, Nikolay Ledovskikh wrote:
>>> Maybe the address you got from the platform side was already ored by
>>> KSEG1...
>>
>> I took a look at openwrt atheros platform code and suppose you are right.
>> So what we should do for now? Add pointer cast (void __iomem *)?
>> Because ioremap_nocache doesn't work as expected. I think it's better
>> to rewrote the openwrt
>> code, but not now.
> 
> So I've found:
> http://www.google.com/codesearch/p?hl=en#sayuPQDVf4c/trunk/openwrt/target/linux/atheros/patches-2.6.32/100-board.patch&q=ar231x-wmac&sa=N&cd=4&ct=rc
> 
> There, the res->start may be either of the following:
> AR531X_WLAN0 .. 0x18000000
> AR531X_WLAN1 .. 0x18500000


> AR2315_WLAN0 .. 0xB0000000

Or maybe this should be 0x10000000 in openwrt in the first place? Then
ioremap should do the right thing, right?

> I suppose you have the 3rd otherwise it should die without ORing KSEG1?
> 
> Or maybe MIPS guys will correct me? (The problem is that ioremap of one
> of the addresses above kills the box. If Nikolaj removes the ioremap and
> uses the address directly, it works for him. I'm saying it will die for
> the first 2 addresses if we remove ioremap completely -- from what I
> found in MIPS specs.)
> 
> I _think_ there should be (instead of ioremap):
> sc->iobase = (void __iomem *)KSEG1ADDR(res->start);
> 
> Then we do readl(sc->iobase) et al. in ath5k.
> 
> thanks,
-- 
js

<Prev in Thread] Current Thread [Next in Thread>