From: Ben Greear <greearb@candelatech.com>
To: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Cc: ath10k@lists.infradead.org
Subject: Re: Does the reg_addr/reg_value reading work?
Date: Mon, 08 Jun 2015 13:02:54 -0700 [thread overview]
Message-ID: <5575F4EE.9010700@candelatech.com> (raw)
In-Reply-To: <5575F0E2.202@candelatech.com>
On 06/08/2015 12:45 PM, Ben Greear wrote:
> On 06/08/2015 09:46 AM, Sebastian Gottschall wrote:
>> Am 08.06.2015 um 18:11 schrieb Ben Greear:
>>> I am not getting expected values when I try to read registers
>>> through the ath10k reg_addr/reg_value API.
>>>
>>> For instance, I tried reading a particular register 0x80e0
>>> (as defined in the firmware), and I get a zero value. With a different
>>> API that I wrote to dump some specific registers over the WMI API,
>>> I get the expected value.
>>>
>>> # echo 0x80e0 > /debug/ieee80211/wiphy0/ath10k/reg_addr
>>> # cat /debug/ieee80211/wiphy0/ath10k/reg_value
>>> 0x000080e0:0x00000000
>>> # cat /debug/ieee80211/wiphy0/ath10k/fw_regs
>>>
>>> ath10k Target Register Dump
>>> =================
>>>
>>> MAC-FILTER-ADDR-L32 0xd7ffffff
>>> ...
>>>
>>> Is there some trick I am missing?
>> 0x20000 offset makes the voodoo. you will find this offset within your firmware source too. take a look at the preconfigured register tables. these contain
>> already the ack,slot etc. settings.
>> but with a special macro surrounding it which defines that offset
>>
>> echo 0x2080e0 > /debug/ieee80211/wiphy0/ath10k/reg_addr
>
> This crashes my kernel....I instrumented the place that crashed in ath10k/pci.h:
>
> [ 100.676013] ath10k-pci-read32: ar ffff88020279ae20 ar_pci ffff88020279df08 offset: 0x2080e0
> [ 100.676016] ar_pci->mem: 0xffffc90019c80000
> [ 100.676031] BUG: unable to handle kernel paging request at ffffc90019e880e0
> [ 100.681752] IP: [<ffffffff81364ad4>] ioread32+0x9/0x2f
>
> Have you tried this on a 10.1.467 firmware?
>
> And, what kernel? I'm trying 4.0.4+
I was using the wrong address value..it should be 0x280e0. Maybe the driver should still keep us from
crashing the whole kernel (while holding locks!), but at least it works when I put in
the right value.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2015-06-08 20:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 16:11 Does the reg_addr/reg_value reading work? Ben Greear
2015-06-08 16:46 ` Sebastian Gottschall
2015-06-08 19:45 ` Ben Greear
2015-06-08 20:02 ` Ben Greear [this message]
2015-06-08 21:23 ` Sebastian Gottschall
2015-06-08 21:28 ` Ben Greear
2015-06-11 7:45 ` Michal Kazior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5575F4EE.9010700@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=s.gottschall@dd-wrt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox