Re: [PATCH] ath5k: Use mips generic dma-mapping functions to avoid seqfault on AHB chips

Re: [PATCH] ath5k: Use mips generic dma-mapping functions to avoid seqfault on AHB chips

[Jiri Slaby]

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

Re: [PATCH] ath5k: Use mips generic dma-mapping functions to avoid seqfault on AHB chips

[Jiri Slaby]

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

Re: [PATCH] ath5k: Use mips generic dma-mapping functions to avoid seqfault on AHB chips

[Ralf Baechle]

On Tue, Feb 15, 2011 at 11:18:51PM +0100, Jiri Slaby wrote:

> > 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?

Yes - 0xb0000000 looks like it's a virtual address which is wrong.

Rule #1: Put physical addresses in headers and code only.
Rule #2: If using one of the KSEG address and address conversion macros,
get rid of them, use ioremap.  The KSEG macros are for use by arch core
code only; for use anywhere else I reject patches these days.

  Ralf

Re: [PATCH] ath5k: Use mips generic dma-mapping functions to avoid seqfault on AHB chips

[Nikolay Ledovskikh]

So, the problems are in openwrt platform patches that should be rewriten:
1. Changes needed to avoid using code like "mem=res->start" without ioremap.
2. Changes needed to avoid using NULL in first argument of
dma_alloc_coherent and others.

Without these changes ahb patch won't get into the kernel and we'll be
lack of wisoc devices support?
Is there any chance for the patch to get into the kernel and what
should be done for it?

(PS: Sorry for my english.)