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:16:27 +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=PEplgnLS1fXrsaKRy99CZkvG2sTcsdwhyYkNzRt8eOY=; b=PFnTnjHyNy2DwJaAZVLOgC40r21ooQUZbLTtBOSD2wLdZxh80O4BWI7jnYo4n8Mw4W +Ct5i4YXVrGQhZA/srNXrfuJHQBhqGpT4yzlNmY1bFNRkjwE+gcVLi5DWL40tjzWXtog k2o/Sjf7neuUoygUQRXqErWaVKWi08phzJwiE=
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=jj+w2h3+xC8ayFIAc62tWgE3oroeoVZpil/s7pjXavnp4M0Tir0hQXIaGEb6Vwv3h1 qDs/tdswXqMns5wh05Y+GqNV6Zfq1Xq9vNcXr59cKtp345tKK5YTIr8o6fOXN8PjRdqw fa4Jvy0g1vXgsfTIfR1sUkgcD769xoR7KpgWU=
In-reply-to: <AANLkTinnCOEXF835yhNeJDfBdKjx_dss6TFeUmjL-Yk2@mail.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>
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 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

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>