ath10k: calibration data through Device Tree?

ath10k: calibration data through Device Tree?

[Kalle Valo]

Hi Device Tree gurus,

ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
located in drivers/net/wireless/ath/ath10k/. Currently it only supports
PCI devices.

Some of the devices store the calibration data to the host flash and the
bootloader reads the data from the flash. And now we need a method to
deliver the calibration data from bootloader to ath10k. Basically our
requirements are:

* ath10k must support any number of radios (one radio per PCI device).

* The calibration data is now 2116 bytes, in the future it might be
  longer. The data is unique for each radio and is created at the
  factory.

* ath10k must be able to reliably map the PCI device (=radio) to the
  correct calibration data. Maybe with using PCI bus and slot numbers?

We have been trying to find similar cases from other drivers but no
luck. Basically my question is how to do this properly with Device Tree?
Especially how to map the calibration data to correct PCI device? Are
there any examples which would help us to implement this?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Arnd Bergmann]

On Thursday 02 October 2014 16:14:43 Kalle Valo wrote:
> Hi Device Tree gurus,
> 
> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
> PCI devices.
> 
> Some of the devices store the calibration data to the host flash and the
> bootloader reads the data from the flash. And now we need a method to
> deliver the calibration data from bootloader to ath10k. Basically our
> requirements are:
> 
> * ath10k must support any number of radios (one radio per PCI device).
> 
> * The calibration data is now 2116 bytes, in the future it might be
>   longer. The data is unique for each radio and is created at the
>   factory.
> 
> * ath10k must be able to reliably map the PCI device (=radio) to the
>   correct calibration data. Maybe with using PCI bus and slot numbers?
> 
> We have been trying to find similar cases from other drivers but no
> luck. Basically my question is how to do this properly with Device Tree?
> Especially how to map the calibration data to correct PCI device? Are
> there any examples which would help us to implement this?

When you know the PCI bus/device/function ID of the device, you can put
a device node in the dts file that corresponds to the PCI dev, and you
can find the of_node pointer from pci_dev->dev.of_node. 2116 is probably
ok to put into a DT property of that device directly.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Kalle Valo]

Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:

> On Thursday 02 October 2014 16:14:43 Kalle Valo wrote:
>> Hi Device Tree gurus,
>> 
>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
>> PCI devices.
>> 
>> Some of the devices store the calibration data to the host flash and the
>> bootloader reads the data from the flash. And now we need a method to
>> deliver the calibration data from bootloader to ath10k. Basically our
>> requirements are:
>> 
>> * ath10k must support any number of radios (one radio per PCI device).
>> 
>> * The calibration data is now 2116 bytes, in the future it might be
>>   longer. The data is unique for each radio and is created at the
>>   factory.
>> 
>> * ath10k must be able to reliably map the PCI device (=radio) to the
>>   correct calibration data. Maybe with using PCI bus and slot numbers?
>> 
>> We have been trying to find similar cases from other drivers but no
>> luck. Basically my question is how to do this properly with Device Tree?
>> Especially how to map the calibration data to correct PCI device? Are
>> there any examples which would help us to implement this?
>
> When you know the PCI bus/device/function ID of the device, you can put
> a device node in the dts file that corresponds to the PCI dev, and you
> can find the of_node pointer from pci_dev->dev.of_node. 

For me that's easier said than done as I'm a total newbie with Device
Tree :) Can you give any pointers or examples how to do that in
practise, please? Especially "node in the dts file that corresponds to
the PCI dev" part is puzzling me.

> 2116 is probably ok to put into a DT property of that device directly.

Ok, that's good.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Arnd Bergmann]

On Thursday 02 October 2014 16:47:48 Kalle Valo wrote:
> >
> > When you know the PCI bus/device/function ID of the device, you can put
> > a device node in the dts file that corresponds to the PCI dev, and you
> > can find the of_node pointer from pci_dev->dev.of_node. 
> 
> For me that's easier said than done as I'm a total newbie with Device
> Tree  Can you give any pointers or examples how to do that in
> practise, please? Especially "node in the dts file that corresponds to
> the PCI dev" part is puzzling me.

See the recent patch "[PATCH v4] ARM: shmobile: r8a7791: link PCI USB
devices to USB PHY" where someone does the same thing to supply additional
data to a PCI device node in shmobile.

Basically you just need to add a node under your PCI host controller node
with "reg = <0x800 0 0 0 0>" (or whatever the address is and put the
properties in there. See www.openfirmware.org/1275/bindings/pci/pci2_1.pdf
for the description of how to construct the addresses.

I notice that there are no Qualcomm or Atheros PCI host controller drivers
in Linux though, so you first have to write a driver that allows probing
the PCI bus, and get the binding reviewed for that before you can add
it to the dts files. Is this for ipq8064 or something else?

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Kalle Valo]

Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:

> On Thursday 02 October 2014 16:47:48 Kalle Valo wrote:
>> >
>> > When you know the PCI bus/device/function ID of the device, you can put
>> > a device node in the dts file that corresponds to the PCI dev, and you
>> > can find the of_node pointer from pci_dev->dev.of_node. 
>> 
>> For me that's easier said than done as I'm a total newbie with Device
>> Tree  Can you give any pointers or examples how to do that in
>> practise, please? Especially "node in the dts file that corresponds to
>> the PCI dev" part is puzzling me.
>
> See the recent patch "[PATCH v4] ARM: shmobile: r8a7791: link PCI USB
> devices to USB PHY" where someone does the same thing to supply additional
> data to a PCI device node in shmobile.
>
> Basically you just need to add a node under your PCI host controller node
> with "reg = <0x800 0 0 0 0>" (or whatever the address is and put the
> properties in there. See www.openfirmware.org/1275/bindings/pci/pci2_1.pdf
> for the description of how to construct the addresses.

Excellent, thanks. I'll study these and try to learn more.

> I notice that there are no Qualcomm or Atheros PCI host controller drivers
> in Linux though, so you first have to write a driver that allows probing
> the PCI bus, and get the binding reviewed for that before you can add
> it to the dts files. Is this for ipq8064 or something else?

But now I'm lost again :) I want ath10k and this feature to work with
all possible PCI controllers, not just with Qualcomm controllers. So why
do I need to wait for Qualcomm PCI host controller driver?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Arnd Bergmann]

On Thursday 02 October 2014 17:55:57 Kalle Valo wrote:
> 
> > I notice that there are no Qualcomm or Atheros PCI host controller drivers
> > in Linux though, so you first have to write a driver that allows probing
> > the PCI bus, and get the binding reviewed for that before you can add
> > it to the dts files. Is this for ipq8064 or something else?
> 
> But now I'm lost again  I want ath10k and this feature to work with
> all possible PCI controllers, not just with Qualcomm controllers. So why
> do I need to wait for Qualcomm PCI host controller driver?

Sorry, my fault. You can definitely do this with any SoC that uses DT
for probing the PCI. I was merely assuming that you were asking about
ipq because the wifi chips and SoCs tend to come bundled from the
same manufacturer in embedded systems, and the MIPS based QCA SoCs
currently don't use DT.

For any machine that does not use DT, it would be much harder to
solve this problem though.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Mark Rutland]

Hi,

> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
> PCI devices.
> 
> Some of the devices store the calibration data to the host flash and the
> bootloader reads the data from the flash. And now we need a method to
> deliver the calibration data from bootloader to ath10k. 

What does this calibration data consist of?

What happens if you don't have the calibration data? Is it a critical
requirement for the use of the device, or does its absence simply result
in degraded performance?

What do you do on non-DT systems? Where does the information come from
in that case?

I'm somewhat puzzled as to why a discoverable PCI device would require
non-discoverable information to use.

> * The calibration data is now 2116 bytes, in the future it might be
>   longer. The data is unique for each radio and is created at the
>   factory.

Why would this change in future? Who is in charge of providing this
information, and deciding upon the format thereof?

> * ath10k must be able to reliably map the PCI device (=radio) to the
>   correct calibration data. Maybe with using PCI bus and slot numbers?

I guess we'd have to do something along those lines.

I'd like to get a better understanding of the problem before we start
figuring out how to pass an arbitrary blob of information around.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Kalle Valo]

Hi Mark,

Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> writes:

>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
>> PCI devices.
>> 
>> Some of the devices store the calibration data to the host flash and the
>> bootloader reads the data from the flash. And now we need a method to
>> deliver the calibration data from bootloader to ath10k. 
>
> What does this calibration data consist of?

>From ath10k point of view it's just a binary blob which we push to the
firmware before we start it. ath10k does not parse it in any way.

> What happens if you don't have the calibration data? Is it a critical
> requirement for the use of the device, or does its absence simply result
> in degraded performance?

>From my point of view the device should not be used if it doesn't
contain the correct calibration data. I guess it could work somehow but
there's no guarantee about the perfomance.

> What do you do on non-DT systems? Where does the information come from
> in that case?

Currently ath10k only supports having the calibration data in the OTP
area inside the QCA98XX chip. But some manufacturers want to store it on
the host file, I assume because of the flexibility it provides. And
that's why we have the need for Device Tree support.

> I'm somewhat puzzled as to why a discoverable PCI device would require
> non-discoverable information to use.

ath9k has a similar model as well, but it doesn't support Device Tree
(at least not yet).

>> * The calibration data is now 2116 bytes, in the future it might be
>>   longer. The data is unique for each radio and is created at the
>>   factory.
>
> Why would this change in future? Who is in charge of providing this
> information, and deciding upon the format thereof?

That's up to the firmare and hardware teams working on the chipsets.
Basically ath10k just needs the data and the length of the data.

>> * ath10k must be able to reliably map the PCI device (=radio) to the
>>   correct calibration data. Maybe with using PCI bus and slot numbers?
>
> I guess we'd have to do something along those lines.
>
> I'd like to get a better understanding of the problem before we start
> figuring out how to pass an arbitrary blob of information around.

I hope my answers helped.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Mark Rutland]

On Thu, Oct 02, 2014 at 02:44:26PM +0100, Kalle Valo wrote:
> Hi Mark,
> 
> Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> writes:
> 
> >> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
> >> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
> >> PCI devices.
> >> 
> >> Some of the devices store the calibration data to the host flash and the
> >> bootloader reads the data from the flash. And now we need a method to
> >> deliver the calibration data from bootloader to ath10k. 
> >
> > What does this calibration data consist of?
> 
> From ath10k point of view it's just a binary blob which we push to the
> firmware before we start it. ath10k does not parse it in any way.

Ok. So this is an arbitrary binary blob that the firmware needs.

Who is in charge of loading the firmware onto the device? Where does the
firmware come from?

> > What happens if you don't have the calibration data? Is it a critical
> > requirement for the use of the device, or does its absence simply result
> > in degraded performance?
> 
> From my point of view the device should not be used if it doesn't
> contain the correct calibration data. I guess it could work somehow but
> there's no guarantee about the perfomance.

Ok.

> > What do you do on non-DT systems? Where does the information come from
> > in that case?
> 
> Currently ath10k only supports having the calibration data in the OTP
> area inside the QCA98XX chip. But some manufacturers want to store it on
> the host file, I assume because of the flexibility it provides. And
> that's why we have the need for Device Tree support.

So currently the calibration data is stored within the device itself?

What is the rationale for overriding this? While it might be 'flexible',
that's not to say it's fantastic idea to rely upon it. This sounds like
a workaround for buggy/incomplete data in the OTP area.

> > I'm somewhat puzzled as to why a discoverable PCI device would require
> > non-discoverable information to use.
> 
> ath9k has a similar model as well, but it doesn't support Device Tree
> (at least not yet).

Ah. So currently it's possible to read calibration data from the device
itself. That sounds more like what I had expected.

Given that, why is it necessary to override this data?

> >> * The calibration data is now 2116 bytes, in the future it might be
> >>   longer. The data is unique for each radio and is created at the
> >>   factory.
> >
> > Why would this change in future? Who is in charge of providing this
> > information, and deciding upon the format thereof?
> 
> That's up to the firmare and hardware teams working on the chipsets.
> Basically ath10k just needs the data and the length of the data.

One issue I'm concerned with is the possiblity of a mismatch between the
FW (which is presumably loaded by Linux from a filesystem somewhere),
and the FW-specific(?) calibration data which comes from somewhere else.

I assume given the calibration data would otherwise come from the OTP
area that new FW must be backwards compatible with old calibration data?

I hope that even with a 'flexible' mechanism for overriding this
information, that compatibility would remain the case, so a user would
not have to update their DTB simply because they updated their userspace
and hence their firmware. Otherwise, this sounds broken to me.

> >> * ath10k must be able to reliably map the PCI device (=radio) to the
> >>   correct calibration data. Maybe with using PCI bus and slot numbers?
> >
> > I guess we'd have to do something along those lines.
> >
> > I'd like to get a better understanding of the problem before we start
> > figuring out how to pass an arbitrary blob of information around.
> 
> I hope my answers helped.

Somewhat, yes!

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Andy Lutomirski]

On 10/02/2014 06:44 AM, Kalle Valo wrote:
> Hi Mark,
> 
> Mark Rutland <mark.rutland-5wv7dgnIgG8-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
> 
>>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
>>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
>>> PCI devices.
>>>
>>> Some of the devices store the calibration data to the host flash and the
>>> bootloader reads the data from the flash. And now we need a method to
>>> deliver the calibration data from bootloader to ath10k. 
>>
>> What does this calibration data consist of?
> 
> From ath10k point of view it's just a binary blob which we push to the
> firmware before we start it. ath10k does not parse it in any way.
> 
>> What happens if you don't have the calibration data? Is it a critical
>> requirement for the use of the device, or does its absence simply result
>> in degraded performance?
> 
> From my point of view the device should not be used if it doesn't
> contain the correct calibration data. I guess it could work somehow but
> there's no guarantee about the perfomance.
> 
>> What do you do on non-DT systems? Where does the information come from
>> in that case?
> 
> Currently ath10k only supports having the calibration data in the OTP
> area inside the QCA98XX chip. But some manufacturers want to store it on
> the host file, I assume because of the flexibility it provides. And
> that's why we have the need for Device Tree support.

To give an actual concrete example that might be what Kalle is talking
about:

I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie
device.  For whatever reason (I honestly have no clue whatsoever why the
hardware works this way), the calibration data is on a host flash
partition, not on the minipcie device's ROM or flash or whatever it is.

Needless to say, the mainline ath10k driver won't load on it.  (An old
version used to load without calibration data.  It didn't work very well.)

Presuambly the idea is that, if things like this used DT (which mine
doesn't, I presume), then ath10k could get the calibration data via DT.
 And maybe some vendors of ARM-based wifi devices are planning on
playing similar games, and they do use DT.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Adrian Chadd]

On 2 October 2014 12:05, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> On 10/02/2014 06:44 AM, Kalle Valo wrote:
>> Hi Mark,
>>
>> Mark Rutland <mark.rutland-5wv7dgnIgG8-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>>
>>>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
>>>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
>>>> PCI devices.
>>>>
>>>> Some of the devices store the calibration data to the host flash and the
>>>> bootloader reads the data from the flash. And now we need a method to
>>>> deliver the calibration data from bootloader to ath10k.
>>>
>>> What does this calibration data consist of?
>>
>> From ath10k point of view it's just a binary blob which we push to the
>> firmware before we start it. ath10k does not parse it in any way.
>>
>>> What happens if you don't have the calibration data? Is it a critical
>>> requirement for the use of the device, or does its absence simply result
>>> in degraded performance?
>>
>> From my point of view the device should not be used if it doesn't
>> contain the correct calibration data. I guess it could work somehow but
>> there's no guarantee about the perfomance.
>>
>>> What do you do on non-DT systems? Where does the information come from
>>> in that case?
>>
>> Currently ath10k only supports having the calibration data in the OTP
>> area inside the QCA98XX chip. But some manufacturers want to store it on
>> the host file, I assume because of the flexibility it provides. And
>> that's why we have the need for Device Tree support.
>
> To give an actual concrete example that might be what Kalle is talking
> about:
>
> I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie
> device.  For whatever reason (I honestly have no clue whatsoever why the
> hardware works this way), the calibration data is on a host flash
> partition, not on the minipcie device's ROM or flash or whatever it is.

The hardware works this way because it's what's being chosen at
manufacturing time.

It _used_ to be this way because then the manufacturers could choose
whether to put the serial EEPROM on the wireless card or on board - or
just save that particular component and load in the same data from the
existing SPI flash chip that holds the firmware.

With OTP they'd have to include writing OTP data out to the chip as
part of the manufacturing process, rather than just "load in data via
JTAG or uboot".

It also means they can re-do the calibration or configuration space
for the device rather than the "One Time Programmable" bits which (a)
will eventually run out of space for programming, (b) occasionally may
error during programming, or (c) may end up writing the wrong data
during programming time, making a chip or a whole batch of chips
useless.

> Needless to say, the mainline ath10k driver won't load on it.  (An old
> version used to load without calibration data.  It didn't work very well.)

I'm surprised it worked at all. :)



-a
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Andy Lutomirski]

On Thu, Oct 2, 2014 at 12:28 PM, Adrian Chadd <adrian-h+KGxgPPiopAfugRpC6u6w@public.gmane.org> wrote:
> On 2 October 2014 12:05, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>> On 10/02/2014 06:44 AM, Kalle Valo wrote:
>>> Hi Mark,
>>>
>>> Mark Rutland <mark.rutland-5wv7dgnIgG8-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>>>
>>>>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
>>>>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
>>>>> PCI devices.
>>>>>
>>>>> Some of the devices store the calibration data to the host flash and the
>>>>> bootloader reads the data from the flash. And now we need a method to
>>>>> deliver the calibration data from bootloader to ath10k.
>>>>
>>>> What does this calibration data consist of?
>>>
>>> From ath10k point of view it's just a binary blob which we push to the
>>> firmware before we start it. ath10k does not parse it in any way.
>>>
>>>> What happens if you don't have the calibration data? Is it a critical
>>>> requirement for the use of the device, or does its absence simply result
>>>> in degraded performance?
>>>
>>> From my point of view the device should not be used if it doesn't
>>> contain the correct calibration data. I guess it could work somehow but
>>> there's no guarantee about the perfomance.
>>>
>>>> What do you do on non-DT systems? Where does the information come from
>>>> in that case?
>>>
>>> Currently ath10k only supports having the calibration data in the OTP
>>> area inside the QCA98XX chip. But some manufacturers want to store it on
>>> the host file, I assume because of the flexibility it provides. And
>>> that's why we have the need for Device Tree support.
>>
>> To give an actual concrete example that might be what Kalle is talking
>> about:
>>
>> I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie
>> device.  For whatever reason (I honestly have no clue whatsoever why the
>> hardware works this way), the calibration data is on a host flash
>> partition, not on the minipcie device's ROM or flash or whatever it is.
>
> The hardware works this way because it's what's being chosen at
> manufacturing time.
>
> It _used_ to be this way because then the manufacturers could choose
> whether to put the serial EEPROM on the wireless card or on board - or
> just save that particular component and load in the same data from the
> existing SPI flash chip that holds the firmware.
>
> With OTP they'd have to include writing OTP data out to the chip as
> part of the manufacturing process, rather than just "load in data via
> JTAG or uboot".

I always assumed that vendors like TP-Link bought pre-calibrated
minipcie cards from someone else.  I guess I was wrong :)

>
> It also means they can re-do the calibration or configuration space
> for the device rather than the "One Time Programmable" bits which (a)
> will eventually run out of space for programming, (b) occasionally may
> error during programming, or (c) may end up writing the wrong data
> during programming time, making a chip or a whole batch of chips
> useless.
>
>> Needless to say, the mainline ath10k driver won't load on it.  (An old
>> version used to load without calibration data.  It didn't work very well.)
>
> I'm surprised it worked at all. :)

My gf's Macbook didn't think it worked.  My supremely crappy old Intel
card thought it did, at least as well as it thought that anything
worked.  Go figure.

Perhaps unsurprisingly, the OpenWRT patch that enables it to work for
real (by shoving a file into /lib/firmware that's contains a copy of
data read from flash) hasn't made it upstream.  I assume that the
purpose of this discussion is to settle on a real solution.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Kalle Valo]

Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:

> Perhaps unsurprisingly, the OpenWRT patch that enables it to work for
> real (by shoving a file into /lib/firmware that's contains a copy of
> data read from flash) hasn't made it upstream.  I assume that the
> purpose of this discussion is to settle on a real solution.

I'm hoping to have ath10k support three different methods to get
calibration data:

1) OTP (already supported)

2) Device Tree (under discussion)

3) from a file

I'm hoping to send patches for 2) and 3) soon.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Kumar Gala]

On Oct 7, 2014, at 6:44 PM, Kalle Valo <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org> wrote:

> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
> 
>> Perhaps unsurprisingly, the OpenWRT patch that enables it to work for
>> real (by shoving a file into /lib/firmware that's contains a copy of
>> data read from flash) hasn't made it upstream.  I assume that the
>> purpose of this discussion is to settle on a real solution.
> 
> I'm hoping to have ath10k support three different methods to get
> calibration data:
> 
> 1) OTP (already supported)
> 
> 2) Device Tree (under discussion)
> 
> 3) from a file
> 
> I'm hoping to send patches for 2) and 3) soon.


As Arnd mentioned you would have something like:

pci {   
        pcie@0 {
                reg = <0 0 0 0 0>; 
                #interrupt-cells = <1>;
                #size-cells = <2>;
                #address-cells = <3>;
                device_type = "pci";

                ath10k@0,0 {
                        reg = <0x0000 0x0 0x0 0x0 0x0>;
                        device_type = "pci";
                        qcom,ath10k-calibration-data = [ 01 03 04 05 06 … ];
                };      
        };
};

On the driver side you can do something like:

	struct device_node *np;

	np = pci_device_to_OF_node(dev);

than you can do normal OF calls on ‘np’.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Kalle Valo]

Hi Kumar,

Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> writes:

> As Arnd mentioned you would have something like:
>
> pci {   
>         pcie@0 {
>                 reg = <0 0 0 0 0>; 
>                 #interrupt-cells = <1>;
>                 #size-cells = <2>;
>                 #address-cells = <3>;
>                 device_type = "pci";
>
>                 ath10k@0,0 {
>                         reg = <0x0000 0x0 0x0 0x0 0x0>;
>                         device_type = "pci";
>                         qcom,ath10k-calibration-data = [ 01 03 04 05 06 … ];
>                 };      
>         };
> };
>
> On the driver side you can do something like:
>
> 	struct device_node *np;
>
> 	np = pci_device_to_OF_node(dev);
>
> than you can do normal OF calls on ‘np’.

Ah, now I understand how this is supposed to work. Thank you very much
for providing an example.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Arnd Bergmann]

On Thursday 02 October 2014 12:05:27 Andy Lutomirski wrote:
> On 10/02/2014 06:44 AM, Kalle Valo wrote:
> > Hi Mark,
> > 
> > Mark Rutland <mark.rutland-5wv7dgnIgG8-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
> > 
> >>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
> >>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
> >>> PCI devices.
> >>>
> >>> Some of the devices store the calibration data to the host flash and the
> >>> bootloader reads the data from the flash. And now we need a method to
> >>> deliver the calibration data from bootloader to ath10k. 
> >>
> >> What does this calibration data consist of?
> > 
> > From ath10k point of view it's just a binary blob which we push to the
> > firmware before we start it. ath10k does not parse it in any way.
> > 
> >> What happens if you don't have the calibration data? Is it a critical
> >> requirement for the use of the device, or does its absence simply result
> >> in degraded performance?
> > 
> > From my point of view the device should not be used if it doesn't
> > contain the correct calibration data. I guess it could work somehow but
> > there's no guarantee about the perfomance.
> > 
> >> What do you do on non-DT systems? Where does the information come from
> >> in that case?
> > 
> > Currently ath10k only supports having the calibration data in the OTP
> > area inside the QCA98XX chip. But some manufacturers want to store it on
> > the host file, I assume because of the flexibility it provides. And
> > that's why we have the need for Device Tree support.
> 
> To give an actual concrete example that might be what Kalle is talking
> about:
> 
> I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie
> device.  For whatever reason (I honestly have no clue whatsoever why the
> hardware works this way), the calibration data is on a host flash
> partition, not on the minipcie device's ROM or flash or whatever it is.

Just to clarify: is this data specific to the design of the device and
identical for all parts in a manufacture run, or does each individual
board have to be calibrated separately?

> Needless to say, the mainline ath10k driver won't load on it.  (An old
> version used to load without calibration data.  It didn't work very well.)
> 
> Presuambly the idea is that, if things like this used DT (which mine
> doesn't, I presume), then ath10k could get the calibration data via DT.
>  And maybe some vendors of ARM-based wifi devices are planning on
> playing similar games, and they do use DT.

Yes, this makes sense. I would also very much love to see DT support for
arch/mips/ath79 in general, it seems like a nice platform that is used
in a lot of devices with good openwrt support, and using DT would make
it easier to support additional devices.

>From a system design point, it's still horrible that you have to use
DT for a device that is on a discoverable bus like PCI, but as you describe,
the reality is that products are shipping that use ath10k PCI devices
without this data in them.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Andy Lutomirski]

On Fri, Oct 3, 2014 at 8:29 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Thursday 02 October 2014 12:05:27 Andy Lutomirski wrote:
>> On 10/02/2014 06:44 AM, Kalle Valo wrote:
>> > Hi Mark,
>> >
>> > Mark Rutland <mark.rutland-5wv7dgnIgG8-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>> >
>> >>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
>> >>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
>> >>> PCI devices.
>> >>>
>> >>> Some of the devices store the calibration data to the host flash and the
>> >>> bootloader reads the data from the flash. And now we need a method to
>> >>> deliver the calibration data from bootloader to ath10k.
>> >>
>> >> What does this calibration data consist of?
>> >
>> > From ath10k point of view it's just a binary blob which we push to the
>> > firmware before we start it. ath10k does not parse it in any way.
>> >
>> >> What happens if you don't have the calibration data? Is it a critical
>> >> requirement for the use of the device, or does its absence simply result
>> >> in degraded performance?
>> >
>> > From my point of view the device should not be used if it doesn't
>> > contain the correct calibration data. I guess it could work somehow but
>> > there's no guarantee about the perfomance.
>> >
>> >> What do you do on non-DT systems? Where does the information come from
>> >> in that case?
>> >
>> > Currently ath10k only supports having the calibration data in the OTP
>> > area inside the QCA98XX chip. But some manufacturers want to store it on
>> > the host file, I assume because of the flexibility it provides. And
>> > that's why we have the need for Device Tree support.
>>
>> To give an actual concrete example that might be what Kalle is talking
>> about:
>>
>> I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie
>> device.  For whatever reason (I honestly have no clue whatsoever why the
>> hardware works this way), the calibration data is on a host flash
>> partition, not on the minipcie device's ROM or flash or whatever it is.
>
> Just to clarify: is this data specific to the design of the device and
> identical for all parts in a manufacture run, or does each individual
> board have to be calibrated separately?

Each board has separate data.  (Even the MAC address is in this blob
on my device.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Mark Rutland]

> From a system design point, it's still horrible that you have to use
> DT for a device that is on a discoverable bus like PCI, but as you describe,
> the reality is that products are shipping that use ath10k PCI devices
> without this data in them.

I'd see any DT property for this as a workaround, the use of which
should be discouraged.

A fun question that springs to mind is can the ath10k chip be removed,
and if so am I able to place it into a non-DT system (whereupon I have
no calibration data, so it won't work)?

Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Arnd Bergmann]

On Friday 03 October 2014 17:25:13 Mark Rutland wrote:
> > From a system design point, it's still horrible that you have to use
> > DT for a device that is on a discoverable bus like PCI, but as you describe,
> > the reality is that products are shipping that use ath10k PCI devices
> > without this data in them.
> 
> I'd see any DT property for this as a workaround, the use of which
> should be discouraged.

By extension though, any use of DT is really a workaround for the fact
that embedded systems and SoCs don't use discoverable buses, and it should
be discouraged. x86 SoCs actually get this right to a large degree by
making on-chip devices appear as PCI devices that can be used standalone,
although Intel's latest generation SoCs are regressing in this regard
and you still need DT (or something like it) to describe off-chip devices
there.

> A fun question that springs to mind is can the ath10k chip be removed,
> and if so am I able to place it into a non-DT system (whereupon I have
> no calibration data, so it won't work)?

Some can be removed, others cannot. If the chip is on a removable pcie
mini card and doesn't have that data on the card itself, it's already
impossible to put it into another system. I don't think we need to solve
that case.

We have similar issues with removable but nondiscoverable USB and SDIO
devices, e.g. when they are lacking the PROM for the mac address.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Andy Lutomirski]

On Fri, Oct 3, 2014 at 9:42 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Friday 03 October 2014 17:25:13 Mark Rutland wrote:
>> > From a system design point, it's still horrible that you have to use
>> > DT for a device that is on a discoverable bus like PCI, but as you describe,
>> > the reality is that products are shipping that use ath10k PCI devices
>> > without this data in them.
>>
>> I'd see any DT property for this as a workaround, the use of which
>> should be discouraged.
>
> By extension though, any use of DT is really a workaround for the fact
> that embedded systems and SoCs don't use discoverable buses, and it should
> be discouraged. x86 SoCs actually get this right to a large degree by
> making on-chip devices appear as PCI devices that can be used standalone,
> although Intel's latest generation SoCs are regressing in this regard
> and you still need DT (or something like it) to describe off-chip devices
> there.
>
>> A fun question that springs to mind is can the ath10k chip be removed,
>> and if so am I able to place it into a non-DT system (whereupon I have
>> no calibration data, so it won't work)?
>
> Some can be removed, others cannot. If the chip is on a removable pcie
> mini card and doesn't have that data on the card itself, it's already
> impossible to put it into another system. I don't think we need to solve
> that case.

Do these minipcie devices have any sort of unique identifier?  If so,
one could shove the calibration data in
/lib/firmware/ath10k/caldata_[CARDID].dat and, as long as that file
followed the minipcie card around, it would work just fine.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: calibration data through Device Tree?

[Adrian Chadd]

As far as I'm aware there's no unique identifier in the silicon. It's
all in the OTP or flash.

The NIC comes up with a standard MAC address, the same for all NICs in
the family.


-a
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html