* Re: ath10k: calibration data through Device Tree?
@ 2014-10-02 19:05 ` Andy Lutomirski
0 siblings, 0 replies; 44+ messages in thread
From: Andy Lutomirski @ 2014-10-02 19:05 UTC (permalink / raw)
To: Kalle Valo, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-02 19:28 ` Adrian Chadd
0 siblings, 0 replies; 44+ messages in thread
From: Adrian Chadd @ 2014-10-02 19:28 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Mark Rutland, devicetree, Kalle Valo, ath10k@lists.infradead.org
On 2 October 2014 12:05, Andy Lutomirski <luto@amacapital.net> wrote:
> On 10/02/2014 06:44 AM, 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.
>>
>>> 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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-02 19:28 ` Adrian Chadd
0 siblings, 0 replies; 44+ messages in thread
From: Adrian Chadd @ 2014-10-02 19:28 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Kalle Valo, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-02 19:35 ` Andy Lutomirski
0 siblings, 0 replies; 44+ messages in thread
From: Andy Lutomirski @ 2014-10-02 19:35 UTC (permalink / raw)
To: Adrian Chadd
Cc: Mark Rutland, devicetree, Kalle Valo, ath10k@lists.infradead.org
On Thu, Oct 2, 2014 at 12:28 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 2 October 2014 12:05, Andy Lutomirski <luto@amacapital.net> wrote:
>> On 10/02/2014 06:44 AM, 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.
>>>
>>>> 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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-02 19:35 ` Andy Lutomirski
0 siblings, 0 replies; 44+ messages in thread
From: Andy Lutomirski @ 2014-10-02 19:35 UTC (permalink / raw)
To: Adrian Chadd
Cc: Kalle Valo, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-07 16:44 ` Kalle Valo
0 siblings, 0 replies; 44+ messages in thread
From: Kalle Valo @ 2014-10-07 16:44 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Mark Rutland, devicetree, Adrian Chadd,
ath10k@lists.infradead.org
Andy Lutomirski <luto@amacapital.net> 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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-07 16:44 ` Kalle Valo
0 siblings, 0 replies; 44+ messages in thread
From: Kalle Valo @ 2014-10-07 16:44 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Adrian Chadd, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-17 12:25 ` Kumar Gala
0 siblings, 0 replies; 44+ messages in thread
From: Kumar Gala @ 2014-10-17 12:25 UTC (permalink / raw)
To: Kalle Valo
Cc: Mark Rutland, devicetree, Adrian Chadd,
ath10k@lists.infradead.org, Andy Lutomirski
On Oct 7, 2014, at 6:44 PM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Andy Lutomirski <luto@amacapital.net> 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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: ath10k: calibration data through Device Tree?
@ 2014-10-17 12:25 ` Kumar Gala
0 siblings, 0 replies; 44+ messages in thread
From: Kumar Gala @ 2014-10-17 12:25 UTC (permalink / raw)
To: Kalle Valo
Cc: Andy Lutomirski, Adrian Chadd, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: ath10k: calibration data through Device Tree?
@ 2014-10-22 12:02 ` Kalle Valo
0 siblings, 0 replies; 44+ messages in thread
From: Kalle Valo @ 2014-10-22 12:02 UTC (permalink / raw)
To: Kumar Gala
Cc: Mark Rutland, devicetree, Adrian Chadd,
ath10k@lists.infradead.org, Andy Lutomirski
Hi Kumar,
Kumar Gala <galak@codeaurora.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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: ath10k: calibration data through Device Tree?
@ 2014-10-22 12:02 ` Kalle Valo
0 siblings, 0 replies; 44+ messages in thread
From: Kalle Valo @ 2014-10-22 12:02 UTC (permalink / raw)
To: Kumar Gala
Cc: Andy Lutomirski, Adrian Chadd, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-03 15:29 ` Arnd Bergmann
0 siblings, 0 replies; 44+ messages in thread
From: Arnd Bergmann @ 2014-10-03 15:29 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: Mark Rutland, devicetree, Kalle Valo, ath10k
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@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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-03 15:29 ` Arnd Bergmann
0 siblings, 0 replies; 44+ messages in thread
From: Arnd Bergmann @ 2014-10-03 15:29 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Kalle Valo, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
2014-10-03 15:29 ` Arnd Bergmann
@ 2014-10-03 16:24 ` Andy Lutomirski
-1 siblings, 0 replies; 44+ messages in thread
From: Andy Lutomirski @ 2014-10-03 16:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, devicetree, Kalle Valo, ath10k@lists.infradead.org
On Fri, Oct 3, 2014 at 8:29 AM, Arnd Bergmann <arnd@arndb.de> 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@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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-03 16:24 ` Andy Lutomirski
0 siblings, 0 replies; 44+ messages in thread
From: Andy Lutomirski @ 2014-10-03 16:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kalle Valo, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
2014-10-03 15:29 ` Arnd Bergmann
@ 2014-10-03 16:25 ` Mark Rutland
-1 siblings, 0 replies; 44+ messages in thread
From: Mark Rutland @ 2014-10-03 16:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree@vger.kernel.org, Kalle Valo,
ath10k@lists.infradead.org, Andy Lutomirski
> 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.
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-03 16:25 ` Mark Rutland
0 siblings, 0 replies; 44+ messages in thread
From: Mark Rutland @ 2014-10-03 16:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andy Lutomirski, Kalle Valo,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
2014-10-03 16:25 ` Mark Rutland
@ 2014-10-03 16:42 ` Arnd Bergmann
-1 siblings, 0 replies; 44+ messages in thread
From: Arnd Bergmann @ 2014-10-03 16:42 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, Kalle Valo,
ath10k@lists.infradead.org, Andy Lutomirski
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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-03 16:42 ` Arnd Bergmann
0 siblings, 0 replies; 44+ messages in thread
From: Arnd Bergmann @ 2014-10-03 16:42 UTC (permalink / raw)
To: Mark Rutland
Cc: Andy Lutomirski, Kalle Valo,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
2014-10-03 16:42 ` Arnd Bergmann
@ 2014-10-03 16:54 ` Andy Lutomirski
-1 siblings, 0 replies; 44+ messages in thread
From: Andy Lutomirski @ 2014-10-03 16:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, devicetree@vger.kernel.org, Kalle Valo,
ath10k@lists.infradead.org
On Fri, Oct 3, 2014 at 9:42 AM, Arnd Bergmann <arnd@arndb.de> 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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-03 16:54 ` Andy Lutomirski
0 siblings, 0 replies; 44+ messages in thread
From: Andy Lutomirski @ 2014-10-03 16:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Kalle Valo,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-03 17:21 ` Adrian Chadd
0 siblings, 0 replies; 44+ messages in thread
From: Adrian Chadd @ 2014-10-03 17:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Mark Rutland, devicetree@vger.kernel.org, Kalle Valo,
ath10k@lists.infradead.org, Arnd Bergmann
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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: ath10k: calibration data through Device Tree?
@ 2014-10-03 17:21 ` Adrian Chadd
0 siblings, 0 replies; 44+ messages in thread
From: Adrian Chadd @ 2014-10-03 17:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Arnd Bergmann, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kalle Valo,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 44+ messages in thread