Re: Unable to read firmware registers on crash?

[Ben Greear <greearb@candelatech.com>]

On 02/03/2015 06:26 AM, Michal Kazior wrote:
> On 3 February 2015 at 14:57, Ben Greear <greearb@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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k