| Message ID | 20170310080615.22958-1-sven.eckelmann@openmesh.com (mailing list archive) |
|---|---|
| State | Deferred |
| Delegated to: | Kalle Valo |
| Headers | show |
On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote: > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct > board data file on QCA4019 based devices. Multiple different boards share > the same values. Only the original reference designs can currently be > identified and loaded from the board-2.bin. But these will not result in > the correct calibration data when combined with the pre-calibration data > from the device. > > An additional "variant" information has to be provided (via SMBIOS or DT) > to select the correct board data for a design which was modified by an ODM. > > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> > --- > Since RFC: > > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) > - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with > more generic "device specific ids" > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > index 74d7f0af209c..3d2a031217da 100644 > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > @@ -41,6 +41,9 @@ Optional properties: > - qcom,msi_addr: MSI interrupt address. > - qcom,msi_base: Base value to add before writing MSI data into > MSI address register. > +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin > + variant list with the same bus and device > + specific ids Sounds like you should use a more specific compatible string. > - qcom,ath10k-calibration-data : calibration data + board specific data > as an array, the length can vary between > hw versions. > -- > 2.11.0 >
On Montag, 20. März 2017 10:07:33 CET Rob Herring wrote: > On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote: > > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct > > board data file on QCA4019 based devices. Multiple different boards share > > the same values. Only the original reference designs can currently be > > identified and loaded from the board-2.bin. But these will not result in > > the correct calibration data when combined with the pre-calibration data > > from the device. > > > > An additional "variant" information has to be provided (via SMBIOS or DT) > > to select the correct board data for a design which was modified by an ODM. > > > > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> > > --- > > Since RFC: > > > > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) > > - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with > > more generic "device specific ids" > > --- > > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > > index 74d7f0af209c..3d2a031217da 100644 > > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > > @@ -41,6 +41,9 @@ Optional properties: > > - qcom,msi_addr: MSI interrupt address. > > - qcom,msi_base: Base value to add before writing MSI data into > > MSI address register. > > +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin > > + variant list with the same bus and device > > + specific ids > > Sounds like you should use a more specific compatible string. Hm, this would require that each calibration data has an own compatibility string - which then has to be supported by ath10k, right? Doesn't sound like it would work well when each vendor (with an own calibration variant) would have to modify ath10k to get it working. This sounds especially odd because nothing else in ath10k has to be changed. Only the board data files which will be selected by ath10k are different on these devices. It would then up with something like this as compatibility string: * qcom,ipq4019-wifi-asus-rt-ac58u * qcom,ipq4019-wifi-fritzbox-4040 * qcom,ipq4019-wifi-netgear-whatever * qcom,ipq4019-wifi-openmesh-i-have-no-idea * ... But maybe I misunderstood what you've said. Kind regards, Sven
Vendors using ath10k will like this. I mean, I'm using ath10k, and I really like this moving forward. This will make life so much easier in the long run. Everyone else isn't using board-2.bin; they're just copying calibration/board data files over so the reference driver can assemble a board data file based on wifi0/wifi1/etc probe order, and use that. -adrian On 20 March 2017 at 09:28, Sven Eckelmann <sven.eckelmann@openmesh.com> wrote: > On Montag, 20. März 2017 10:07:33 CET Rob Herring wrote: >> On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote: >> > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct >> > board data file on QCA4019 based devices. Multiple different boards share >> > the same values. Only the original reference designs can currently be >> > identified and loaded from the board-2.bin. But these will not result in >> > the correct calibration data when combined with the pre-calibration data >> > from the device. >> > >> > An additional "variant" information has to be provided (via SMBIOS or DT) >> > to select the correct board data for a design which was modified by an ODM. >> > >> > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> >> > --- >> > Since RFC: >> > >> > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) >> > - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with >> > more generic "device specific ids" >> > --- >> > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > index 74d7f0af209c..3d2a031217da 100644 >> > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > @@ -41,6 +41,9 @@ Optional properties: >> > - qcom,msi_addr: MSI interrupt address. >> > - qcom,msi_base: Base value to add before writing MSI data into >> > MSI address register. >> > +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin >> > + variant list with the same bus and device >> > + specific ids >> >> Sounds like you should use a more specific compatible string. > > Hm, this would require that each calibration data has an own compatibility > string - which then has to be supported by ath10k, right? Doesn't sound like > it would work well when each vendor (with an own calibration variant) would > have to modify ath10k to get it working. This sounds especially odd because > nothing else in ath10k has to be changed. Only the board data files which will > be selected by ath10k are different on these devices. > > It would then up with something like this as compatibility string: > > * qcom,ipq4019-wifi-asus-rt-ac58u > * qcom,ipq4019-wifi-fritzbox-4040 > * qcom,ipq4019-wifi-netgear-whatever > * qcom,ipq4019-wifi-openmesh-i-have-no-idea > * ... > > But maybe I misunderstood what you've said. > > Kind regards, > Sven
On Montag, 20. März 2017 09:42:05 CET Adrian Chadd wrote: > Vendors using ath10k will like this. I mean, I'm using ath10k, and I > really like this moving forward. This will make life so much easier in > the long run. > > Everyone else isn't using board-2.bin; they're just copying > calibration/board data files over so the reference driver can assemble > a board data file based on wifi0/wifi1/etc probe order, and use that. Thanks for the feedback. But I am not sure what you mean by "this". Do you mean the "qcom,ath10k-calibration-variant" entry or the "qcom,ipq4019- $vendorstring" compatiblity string? Kind regards, Sven
On Mon, Mar 20, 2017 at 11:28 AM, Sven Eckelmann <sven.eckelmann@openmesh.com> wrote: > On Montag, 20. März 2017 10:07:33 CET Rob Herring wrote: >> On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote: >> > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct >> > board data file on QCA4019 based devices. Multiple different boards share >> > the same values. Only the original reference designs can currently be >> > identified and loaded from the board-2.bin. But these will not result in >> > the correct calibration data when combined with the pre-calibration data >> > from the device. >> > >> > An additional "variant" information has to be provided (via SMBIOS or DT) >> > to select the correct board data for a design which was modified by an ODM. >> > >> > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> >> > --- >> > Since RFC: >> > >> > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) >> > - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with >> > more generic "device specific ids" >> > --- >> > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > index 74d7f0af209c..3d2a031217da 100644 >> > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > @@ -41,6 +41,9 @@ Optional properties: >> > - qcom,msi_addr: MSI interrupt address. >> > - qcom,msi_base: Base value to add before writing MSI data into >> > MSI address register. >> > +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin >> > + variant list with the same bus and device >> > + specific ids >> >> Sounds like you should use a more specific compatible string. > > Hm, this would require that each calibration data has an own compatibility > string - which then has to be supported by ath10k, right? Doesn't sound like > it would work well when each vendor (with an own calibration variant) would > have to modify ath10k to get it working. This sounds especially odd because > nothing else in ath10k has to be changed. Only the board data files which will > be selected by ath10k are different on these devices. > > It would then up with something like this as compatibility string: > > * qcom,ipq4019-wifi-asus-rt-ac58u > * qcom,ipq4019-wifi-fritzbox-4040 > * qcom,ipq4019-wifi-netgear-whatever > * qcom,ipq4019-wifi-openmesh-i-have-no-idea > * ... Are these all the same board design or variations? In the latter case, you should have specific compatibles anyway. Now if the variants are the same hardware, but different configurations say for different regions or something, then I'd say a separate property is fine. We already have a "firmware-name" property. Would that work for you? Rob
On Dienstag, 21. März 2017 08:00:34 CET Rob Herring wrote: [...] > > It would then up with something like this as compatibility string: > > > > * qcom,ipq4019-wifi-asus-rt-ac58u > > * qcom,ipq4019-wifi-fritzbox-4040 > > * qcom,ipq4019-wifi-netgear-whatever > > * qcom,ipq4019-wifi-openmesh-i-have-no-idea > > * ... > > Are these all the same board design or variations? In the latter case, > you should have specific compatibles anyway. Now if the variants are > the same hardware, but different configurations say for different > regions or something, then I'd say a separate property is fine. > > We already have a "firmware-name" property. Would that work for you? Hm, maybe we should specify some names better: "qcom,ipq4019-wifi" == compatibility string for WiFi hardware inside the SoC. It is the one which ath10k supports on the Atheros Host Bus (ahb) of the QCA4019. The ath10k driver will use the information from these nodes to initialize the device. It will basically: 1. load a firmware(-5).bin from /lib/firmware/ath10k/QCA4019/hw1.0/ 2. load the pre-cal (aka first part of calibration) data from /lib/firmware/ath10k/pre-cal-* 3. do some firmware magic to identify the reference design 4. load board data "files" (BDF) for this reference design from /lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin 5. send the BDF data to the firmware to let it compute the final calibration data 6. start the actual wifi stuff The IPQ4018/4019 SoC doesn't contain the actual RF parts. There are a couple of reference designs (SoC+RF parts) from QCA which got official numbers. These numbers identify the BDFs inside the board-2.bin. And the board-2.bin is not the firmware - it is a container for multiple BDFs. To summarize: * pre-cal is some data stored in a special partition of the devices and will not be overwritten on updates * board-2.bin are multiple BDF files containing the second part of the calibration data * pre-cal + BDF (+ some OTP stuff) are getting combined to form the complete calibration data Asus RT-AC58U, Fritzbox 4040 and ZyXEL NBG6617 are products based on the same reference design. But of course, some (all?) fiddled around with the RF parts and therefore require special BDFs. They still use the same SoC and require that the closed source ath10k firmware behaves like on the official reference designs. Only the BDFs have to be different. So you could say that the wifi-chip hardware (part of the QCA4018/4019 SoC) is the same between these different products. But the hardware around the SoC is different and therefore requires a different "configuration"/calibration for the surrounding RF hardware. It is not a perfect match for your "separate property is fine" compromise. Maybe you still meant this - I let you decide. This is not only a problem on QCA4019 but also for other devices supported by ath10k. Waldemar Rymarkiewicz introduced the concept of BDF variants for this [1] and implemented the support for SMBIOS. The variant string (generated from the SMBIOS data) is then used by ath10k when it searches for the correct BDFs in the board-2.bin. Kalle Valo suggested to use the same mechanism for QCA401X based boards (which don't use SMBIOS). The "qcom,ath10k-calibration-variant" is now the (more or less) equivalent of the SMBIOS entry - but for device tree users. Let us assume that the variant string would be "RT-AC58U" for the Asus RT-AC58U and the first wifi device (bmi-board-id=16) gets initialized [2]. Then the step 4 would get splitted in following steps: 4.1. Get the the qcom,ath10k-calibration-variant content 4.2. jump to 4.5. when there is no qcom,ath10k-calibration-variant 4.3. calculate BDF search name with variant string "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U" 4.4. load BDF and when found, jump to 5. 4.5. calculate BDF search name without variant string "bus=ahb,bmi-chip-id=0,bmi-board-id=16" 4.6. load the BDF There would be no changes in ath10k when adding a new BDF calibration variant using qcom,ath10k-calibration-variant. Only the device tree node would have to be updated: * device tree (simplified): / { model = "ASUS RT-AC58U"; soc { wifi@a000000 { compatible = "qcom,ipq4019-wifi"; reg = <0xa000000 0x200000>; status = "okay"; qcom,ath10k-calibration-variant = "RT-AC58U"; }; wifi@a800000 { compatible = "qcom,ipq4019-wifi"; reg = <0xa800000 0x200000>; status = "okay"; qcom,ath10k-calibration-variant = "RT-AC58U"; }; }; }; * ath10k + ath10k-firmware <no change> This about how the calibration [insert swearword] works for "qcom,ipq4019-wifi" and why the "qcom,ath10k-calibration-variant" was used in my first implementation. But then you've suggested to "use a more specific compatible string". This information was not enough for me to understand what you've actually meant. I was therefore proposing some examples which show what you maybe could have meant. These were following things: > > * qcom,ipq4019-wifi-asus-rt-ac58u > > * qcom,ipq4019-wifi-fritzbox-4040 > > * qcom,ipq4019-wifi-netgear-whatever > > * qcom,ipq4019-wifi-openmesh-i-have-no-idea They are basically "qcom,ipq4019-wifi" + a product specific string. The first part is therefore the string which identifies the wifi device(s) in the QCA4018/4019 SoC. The product specific string is simply the part (or a variation of it) which would been used before in "qcom,ath10k-calibration-variant" - just to make it "use a more specific compatible string". I have no idea if this is really what you meant. I just wanted to give you some examples and explanations why I don't feel that this a good idea. I thought that this would help you to point me in the right direction and explain better what you've meant. Right now it looks to me like following must be done for your(?) proposal for each new board: * device tree (simplified): / { model = "ASUS RT-AC58U"; soc { wifi@a000000 { compatible = "qcom,ipq4019-wifi-asus-rt-ac58u"; reg = <0xa000000 0x200000>; status = "okay"; }; wifi@a800000 { compatible = "qcom,ipq4019-wifi-asus-rt-ac58u"; reg = <0xa800000 0x200000>; status = "okay"; }; }; }; * ath10k + ath10k-firmware - add qcom,ipq4019-wifi-asus-rt-ac58u to Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt - add qcom,ipq4019-wifi-asus-rt-ac58u to ath10k_ahb_of_match in drivers/net/wireless/ath/ath10k/ahb.c - add a mapping from qcom,ipq4019-wifi-asus-rt-ac58u to the RT-AC58U variant string somewhere in ath10k I hope this is enough to understand it a little bit better. Kind regards, Sven [1] https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?id=1657b8f84ed9fc1d2a100671f1d42d6286f20073 [2] the second wifi device for this reference design would be 17. But there are a lot more for the other reference designs from QCA
On Tue, Mar 21, 2017 at 9:33 AM, Sven Eckelmann <sven.eckelmann@openmesh.com> wrote: > On Dienstag, 21. März 2017 08:00:34 CET Rob Herring wrote: > [...] >> > It would then up with something like this as compatibility string: >> > >> > * qcom,ipq4019-wifi-asus-rt-ac58u >> > * qcom,ipq4019-wifi-fritzbox-4040 >> > * qcom,ipq4019-wifi-netgear-whatever >> > * qcom,ipq4019-wifi-openmesh-i-have-no-idea >> > * ... >> >> Are these all the same board design or variations? In the latter case, >> you should have specific compatibles anyway. Now if the variants are >> the same hardware, but different configurations say for different >> regions or something, then I'd say a separate property is fine. >> >> We already have a "firmware-name" property. Would that work for you? > > Hm, maybe we should specify some names better: > > "qcom,ipq4019-wifi" == compatibility string for WiFi hardware inside the SoC. > It is the one which ath10k supports on the Atheros Host Bus (ahb) of the > QCA4019. > > The ath10k driver will use the information from these nodes to initialize the > device. It will basically: > > 1. load a firmware(-5).bin from /lib/firmware/ath10k/QCA4019/hw1.0/ > 2. load the pre-cal (aka first part of calibration) data from > /lib/firmware/ath10k/pre-cal-* > 3. do some firmware magic to identify the reference design > 4. load board data "files" (BDF) for this reference design from > /lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin > 5. send the BDF data to the firmware to let it compute the final calibration > data > 6. start the actual wifi stuff > > The IPQ4018/4019 SoC doesn't contain the actual RF parts. There are a couple > of reference designs (SoC+RF parts) from QCA which got official numbers. These > numbers identify the BDFs inside the board-2.bin. And the board-2.bin is not > the firmware - it is a container for multiple BDFs. > > > To summarize: > > * pre-cal is some data stored in a special partition of the devices and will > not be overwritten on updates > * board-2.bin are multiple BDF files containing the second part of the > calibration data > * pre-cal + BDF (+ some OTP stuff) are getting combined to form the complete > calibration data > > Asus RT-AC58U, Fritzbox 4040 and ZyXEL NBG6617 are products based on the same > reference design. But of course, some (all?) fiddled around with the RF parts > and therefore require special BDFs. They still use the same SoC and require > that the closed source ath10k firmware behaves like on the official reference > designs. Only the BDFs have to be different. Is this always the case? There's never some variation beyond the reference design that a BDF difference can't handle? > So you could say that the wifi-chip hardware (part of the QCA4018/4019 SoC) is > the same between these different products. But the hardware around the SoC is > different and therefore requires a different "configuration"/calibration for > the surrounding RF hardware. It is not a perfect match for your "separate > property is fine" compromise. Maybe you still meant this - I let you decide. > > > This is not only a problem on QCA4019 but also for other devices supported by > ath10k. Waldemar Rymarkiewicz introduced the concept of BDF variants for > this [1] and implemented the support for SMBIOS. The variant string (generated > from the SMBIOS data) is then used by ath10k when it searches for the correct > BDFs in the board-2.bin. Kalle Valo suggested to use the same mechanism for > QCA401X based boards (which don't use SMBIOS). > > The "qcom,ath10k-calibration-variant" is now the (more or less) equivalent of > the SMBIOS entry - but for device tree users. Let us assume that the variant > string would be "RT-AC58U" for the Asus RT-AC58U and the first wifi device > (bmi-board-id=16) gets initialized [2]. Then the step 4 would get splitted in > following steps: > > 4.1. Get the the qcom,ath10k-calibration-variant content > 4.2. jump to 4.5. when there is no qcom,ath10k-calibration-variant > 4.3. calculate BDF search name with variant string > "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U" > 4.4. load BDF and when found, jump to 5. > 4.5. calculate BDF search name without variant string > "bus=ahb,bmi-chip-id=0,bmi-board-id=16" > 4.6. load the BDF > > > There would be no changes in ath10k when adding a new BDF calibration variant > using qcom,ath10k-calibration-variant. Only the device tree node would have to > be updated: > > * device tree (simplified): > / { > model = "ASUS RT-AC58U"; > > soc { > wifi@a000000 { > compatible = "qcom,ipq4019-wifi"; > reg = <0xa000000 0x200000>; > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > wifi@a800000 { > compatible = "qcom,ipq4019-wifi"; > reg = <0xa800000 0x200000>; > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > }; > }; > * ath10k + ath10k-firmware > <no change> > > > > > This about how the calibration [insert swearword] works for > "qcom,ipq4019-wifi" and why the "qcom,ath10k-calibration-variant" was used in > my first implementation. But then you've suggested to "use a more specific > compatible string". This information was not enough for me to understand what > you've actually meant. I was therefore proposing some examples which show what > you maybe could have meant. These were following things: > >> > * qcom,ipq4019-wifi-asus-rt-ac58u >> > * qcom,ipq4019-wifi-fritzbox-4040 >> > * qcom,ipq4019-wifi-netgear-whatever >> > * qcom,ipq4019-wifi-openmesh-i-have-no-idea > > They are basically "qcom,ipq4019-wifi" + a product specific string. The first > part is therefore the string which identifies the wifi device(s) in the > QCA4018/4019 SoC. The product specific string is simply the part (or a > variation of it) which would been used before in > "qcom,ath10k-calibration-variant" - just to make it "use a more specific > compatible string". It would probably be more like: "asus,rt-ac58u-wifi", "qcom,ipq4019-wifi" A more specific compatible is insurance that at some later point in time you can distinguish between 2 boards due to some difference even if now you believe they are "the same". > I have no idea if this is really what you meant. I just wanted to give you > some examples and explanations why I don't feel that this a good idea. I > thought that this would help you to point me in the right direction and > explain better what you've meant. > > Right now it looks to me like following must be done for your(?) proposal for > each new board: > > * device tree (simplified): > / { > model = "ASUS RT-AC58U"; > > soc { > wifi@a000000 { > compatible = "qcom,ipq4019-wifi-asus-rt-ac58u"; > reg = <0xa000000 0x200000>; > status = "okay"; > }; > > wifi@a800000 { > compatible = "qcom,ipq4019-wifi-asus-rt-ac58u"; > reg = <0xa800000 0x200000>; > status = "okay"; > }; > }; > }; > * ath10k + ath10k-firmware > - add qcom,ipq4019-wifi-asus-rt-ac58u to > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > - add qcom,ipq4019-wifi-asus-rt-ac58u to ath10k_ahb_of_match in > drivers/net/wireless/ath/ath10k/ahb.c > - add a mapping from qcom,ipq4019-wifi-asus-rt-ac58u to the RT-AC58U > variant string somewhere in ath10k > > > I hope this is enough to understand it a little bit better. I think the separate property is fine if this is the only one you envision needing to add. If there's 10 more properties, then I'd feel more strongly towards a board specific compatible string. Rob
On Dienstag, 21. März 2017 21:56:54 CET Rob Herring wrote: [...] > Is this always the case? There's never some variation beyond the > reference design that a BDF difference can't handle? I have no knowledge about anything which isn't handled directly by the BDF variants. But maybe Kalle can correct me here. [...] > > They are basically "qcom,ipq4019-wifi" + a product specific string. The first > > part is therefore the string which identifies the wifi device(s) in the > > QCA4018/4019 SoC. The product specific string is simply the part (or a > > variation of it) which would been used before in > > "qcom,ath10k-calibration-variant" - just to make it "use a more specific > > compatible string". > > It would probably be more like: "asus,rt-ac58u-wifi", "qcom,ipq4019-wifi" > > A more specific compatible is insurance that at some later point in > time you can distinguish between 2 boards due to some difference even > if now you believe they are "the same". [...] > I think the separate property is fine if this is the only one you > envision needing to add. If there's 10 more properties, then I'd feel > more strongly towards a board specific compatible string. Thank you. Let's wait a little bit in case someone from QCA/Codeaurora has some additional input. But your comments were really helpful. Kind regards, Sven
Hi, getting back to this old thread, here's the discussion: https://patchwork.kernel.org/patch/9615183/ https://patchwork.kernel.org/patch/9615185/ Sven Eckelmann <sven.eckelmann@openmesh.com> writes: > On Dienstag, 21. März 2017 21:56:54 CET Rob Herring wrote: > [...] >> Is this always the case? There's never some variation beyond the >> reference design that a BDF difference can't handle? > > I have no knowledge about anything which isn't handled directly by the BDF > variants. But maybe Kalle can correct me here. Currently I'm not aware of any extra properties which we would need in ath10k, having the custom board file seems to be the only requirement I have seen. >> > They are basically "qcom,ipq4019-wifi" + a product specific string. The first >> > part is therefore the string which identifies the wifi device(s) in the >> > QCA4018/4019 SoC. The product specific string is simply the part (or a >> > variation of it) which would been used before in >> > "qcom,ath10k-calibration-variant" - just to make it "use a more specific >> > compatible string". >> >> It would probably be more like: "asus,rt-ac58u-wifi", "qcom,ipq4019-wifi" >> >> A more specific compatible is insurance that at some later point in >> time you can distinguish between 2 boards due to some difference even >> if now you believe they are "the same". > [...] >> I think the separate property is fine if this is the only one you >> envision needing to add. If there's 10 more properties, then I'd feel >> more strongly towards a board specific compatible string. > > Thank you. Let's wait a little bit in case someone from QCA/Codeaurora > has some additional input. I didn't see any comments from anyone else and I think Sven's approach here is the best. Sven, can you submit v2 so that we get an ack from device tree maintainers and I can apply these? -- Kalle Valo
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt index 74d7f0af209c..3d2a031217da 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt @@ -41,6 +41,9 @@ Optional properties: - qcom,msi_addr: MSI interrupt address. - qcom,msi_base: Base value to add before writing MSI data into MSI address register. +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin + variant list with the same bus and device + specific ids - qcom,ath10k-calibration-data : calibration data + board specific data as an array, the length can vary between hw versions.
The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct board data file on QCA4019 based devices. Multiple different boards share the same values. Only the original reference designs can currently be identified and loaded from the board-2.bin. But these will not result in the correct calibration data when combined with the pre-calibration data from the device. An additional "variant" information has to be provided (via SMBIOS or DT) to select the correct board data for a design which was modified by an ODM. Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> --- Since RFC: - Split patch in DT doc and ath10k part (thanks Christian Lamparter) - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with more generic "device specific ids" --- Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++ 1 file changed, 3 insertions(+)