Unable to read firmware registers on crash?
Ben Greear
greearb at candelatech.com
Tue Feb 3 19:45:07 PST 2015
On 02/03/2015 06:26 AM, Michal Kazior wrote:
> On 3 February 2015 at 14:57, Ben Greear <greearb at candelatech.com> wrote:
>> That sounds reasonable. Do you know of any example code that accesses
>> a target register or two with the MMIO logic on the host? I think firmware
>> has some examples of how
>> to fiddle with registers, so I think I can make a stab at that part....
>
> From what I understand the MMIO space is shared between host and
> target program so there's no need for any special handling. You can
> look for FW_IND_EVENT_PENDING and FW_INDICATOR_ADDRESS usage both in
> firmware and ath10k - it's already used to notify host about a crash.
> It should be pretty straightforward. The indicator address itself
> seems to be a scratch register already and there are a few more so you
> should be able to design a ping-pong protocol to pass data.
While implementing this, I ran into a question:
From what I can tell, the ath10k_pci_read32 and ath10k_pci_write32
are treated like they return and write data in host-byte-order.
But, iowrite32 and ioread32 are defined to be pci-byte-order which
is little-endian?
http://comments.gmane.org/gmane.linux.kernel/1042371
(or is that bad info?)
Do we need to be converting values to little-endian before
writing them?
And upon, read, do we need to convert them to host order?
I guess we must not since it seems things mostly work now, but I
am not sure why that is...
Thanks,
Ben
>
>
> Michał
>
--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k
mailing list