* [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-10 8:06 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-10 8:06 UTC (permalink / raw) To: ath10k Cc: linux-wireless, devicetree, robh+dt, mark.rutland, ext.waldemar.rymarkiewicz, kvalo, Sven Eckelmann 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 - qcom,ath10k-calibration-data : calibration data + board specific data as an array, the length can vary between hw versions. -- 2.11.0 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-10 8:06 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-10 8:06 UTC (permalink / raw) To: ath10k Cc: mark.rutland, devicetree, linux-wireless, robh+dt, Sven Eckelmann, ext.waldemar.rymarkiewicz, kvalo 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 - qcom,ath10k-calibration-data : calibration data + board specific data as an array, the length can vary between hw versions. -- 2.11.0 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-10 8:06 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-10 8:06 UTC (permalink / raw) To: ath10k Cc: mark.rutland, devicetree, linux-wireless, robh+dt, Sven Eckelmann, ext.waldemar.rymarkiewicz, kvalo 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 - qcom,ath10k-calibration-data : calibration data + board specific data as an array, the length can vary between hw versions. -- 2.11.0 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant 2017-03-10 8:06 ` Sven Eckelmann (?) @ 2017-03-10 8:06 ` Sven Eckelmann -1 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-10 8:06 UTC (permalink / raw) To: ath10k Cc: linux-wireless, devicetree, robh+dt, mark.rutland, ext.waldemar.rymarkiewicz, kvalo, Sven Eckelmann Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified on QCA4019 using bus, bmi-chip-id and bmi-board-id. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. Something similar has to be provided for systems without SMBIOS but with device trees. No solution was specified by QCA and therefore a new one has to be found for ath10k. The device tree requires addition strings to define the variant name wifi@a000000 { status = "okay"; qcom,ath10k-calibration-variant = "RT-AC58U"; }; wifi@a800000 { status = "okay"; qcom,ath10k-calibration-variant = "RT-AC58U"; }; This would create the boarddata identifiers for the board-2.bin search * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> --- Since RFC: - initialize variant pointer to have it initialized to NULL when of_property_read_string fails (thanks Christian Lamparter) - Only print warning that DT doesn't contain string ones (thanks Christian Lamparter) - Split patch in DT doc and ath10k part (thanks Christian Lamparter) - Allow to overwrite the variant string via DT and ignore that SMBIOS had written anything to it --- drivers/net/wireless/ath/ath10k/core.c | 37 +++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 0a8e29e9a0eb..e459e84afe9f 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -779,6 +779,25 @@ static int ath10k_core_check_smbios(struct ath10k *ar) return 0; } +static int ath10k_core_check_dt(struct ath10k *ar) +{ + struct device_node *node; + const char *variant = NULL; + + node = ar->dev->of_node; + if (!node) + return -ENOENT; + + of_property_read_string(node, "qcom,ath10k-calibration-variant", + &variant); + if (!variant) + return -ENODATA; + + strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); + + return 0; +} + static int ath10k_download_and_run_otp(struct ath10k *ar) { u32 result, address = ar->hw_params.patch_load_addr; @@ -1145,19 +1164,19 @@ static int ath10k_core_create_board_name(struct ath10k *ar, char *name, /* strlen(',variant=') + strlen(ar->id.bdf_ext) */ char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH] = { 0 }; + if (ar->id.bdf_ext[0] != '\0') + scnprintf(variant, sizeof(variant), ",variant=%s", + ar->id.bdf_ext); + if (ar->id.bmi_ids_valid) { scnprintf(name, name_len, - "bus=%s,bmi-chip-id=%d,bmi-board-id=%d", + "bus=%s,bmi-chip-id=%d,bmi-board-id=%d%s", ath10k_bus_str(ar->hif.bus), ar->id.bmi_chip_id, - ar->id.bmi_board_id); + ar->id.bmi_board_id, variant); goto out; } - if (ar->id.bdf_ext[0] != '\0') - scnprintf(variant, sizeof(variant), ",variant=%s", - ar->id.bdf_ext); - scnprintf(name, name_len, "bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x%s", ath10k_bus_str(ar->hif.bus), @@ -2221,7 +2240,11 @@ static int ath10k_core_probe_fw(struct ath10k *ar) ret = ath10k_core_check_smbios(ar); if (ret) - ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not set.\n"); + ath10k_dbg(ar, ATH10K_DBG_BOOT, "SMBIOS bdf variant name not set.\n"); + + ret = ath10k_core_check_dt(ar); + if (ret) + ath10k_dbg(ar, ATH10K_DBG_BOOT, "DT bdf variant name not set.\n"); ret = ath10k_core_fetch_board_file(ar); if (ret) { -- 2.11.0 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant @ 2017-03-10 8:06 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-10 8:06 UTC (permalink / raw) To: ath10k Cc: mark.rutland, devicetree, linux-wireless, robh+dt, Sven Eckelmann, ext.waldemar.rymarkiewicz, kvalo Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified on QCA4019 using bus, bmi-chip-id and bmi-board-id. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. Something similar has to be provided for systems without SMBIOS but with device trees. No solution was specified by QCA and therefore a new one has to be found for ath10k. The device tree requires addition strings to define the variant name wifi@a000000 { status = "okay"; qcom,ath10k-calibration-variant = "RT-AC58U"; }; wifi@a800000 { status = "okay"; qcom,ath10k-calibration-variant = "RT-AC58U"; }; This would create the boarddata identifiers for the board-2.bin search * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> --- Since RFC: - initialize variant pointer to have it initialized to NULL when of_property_read_string fails (thanks Christian Lamparter) - Only print warning that DT doesn't contain string ones (thanks Christian Lamparter) - Split patch in DT doc and ath10k part (thanks Christian Lamparter) - Allow to overwrite the variant string via DT and ignore that SMBIOS had written anything to it --- drivers/net/wireless/ath/ath10k/core.c | 37 +++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 0a8e29e9a0eb..e459e84afe9f 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -779,6 +779,25 @@ static int ath10k_core_check_smbios(struct ath10k *ar) return 0; } +static int ath10k_core_check_dt(struct ath10k *ar) +{ + struct device_node *node; + const char *variant = NULL; + + node = ar->dev->of_node; + if (!node) + return -ENOENT; + + of_property_read_string(node, "qcom,ath10k-calibration-variant", + &variant); + if (!variant) + return -ENODATA; + + strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); + + return 0; +} + static int ath10k_download_and_run_otp(struct ath10k *ar) { u32 result, address = ar->hw_params.patch_load_addr; @@ -1145,19 +1164,19 @@ static int ath10k_core_create_board_name(struct ath10k *ar, char *name, /* strlen(',variant=') + strlen(ar->id.bdf_ext) */ char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH] = { 0 }; + if (ar->id.bdf_ext[0] != '\0') + scnprintf(variant, sizeof(variant), ",variant=%s", + ar->id.bdf_ext); + if (ar->id.bmi_ids_valid) { scnprintf(name, name_len, - "bus=%s,bmi-chip-id=%d,bmi-board-id=%d", + "bus=%s,bmi-chip-id=%d,bmi-board-id=%d%s", ath10k_bus_str(ar->hif.bus), ar->id.bmi_chip_id, - ar->id.bmi_board_id); + ar->id.bmi_board_id, variant); goto out; } - if (ar->id.bdf_ext[0] != '\0') - scnprintf(variant, sizeof(variant), ",variant=%s", - ar->id.bdf_ext); - scnprintf(name, name_len, "bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x%s", ath10k_bus_str(ar->hif.bus), @@ -2221,7 +2240,11 @@ static int ath10k_core_probe_fw(struct ath10k *ar) ret = ath10k_core_check_smbios(ar); if (ret) - ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not set.\n"); + ath10k_dbg(ar, ATH10K_DBG_BOOT, "SMBIOS bdf variant name not set.\n"); + + ret = ath10k_core_check_dt(ar); + if (ret) + ath10k_dbg(ar, ATH10K_DBG_BOOT, "DT bdf variant name not set.\n"); ret = ath10k_core_fetch_board_file(ar); if (ret) { -- 2.11.0 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant @ 2017-03-10 8:06 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-10 8:06 UTC (permalink / raw) To: ath10k Cc: mark.rutland, devicetree, linux-wireless, robh+dt, Sven Eckelmann, ext.waldemar.rymarkiewicz, kvalo Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified on QCA4019 using bus, bmi-chip-id and bmi-board-id. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. Something similar has to be provided for systems without SMBIOS but with device trees. No solution was specified by QCA and therefore a new one has to be found for ath10k. The device tree requires addition strings to define the variant name wifi@a000000 { status = "okay"; qcom,ath10k-calibration-variant = "RT-AC58U"; }; wifi@a800000 { status = "okay"; qcom,ath10k-calibration-variant = "RT-AC58U"; }; This would create the boarddata identifiers for the board-2.bin search * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> --- Since RFC: - initialize variant pointer to have it initialized to NULL when of_property_read_string fails (thanks Christian Lamparter) - Only print warning that DT doesn't contain string ones (thanks Christian Lamparter) - Split patch in DT doc and ath10k part (thanks Christian Lamparter) - Allow to overwrite the variant string via DT and ignore that SMBIOS had written anything to it --- drivers/net/wireless/ath/ath10k/core.c | 37 +++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 0a8e29e9a0eb..e459e84afe9f 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -779,6 +779,25 @@ static int ath10k_core_check_smbios(struct ath10k *ar) return 0; } +static int ath10k_core_check_dt(struct ath10k *ar) +{ + struct device_node *node; + const char *variant = NULL; + + node = ar->dev->of_node; + if (!node) + return -ENOENT; + + of_property_read_string(node, "qcom,ath10k-calibration-variant", + &variant); + if (!variant) + return -ENODATA; + + strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); + + return 0; +} + static int ath10k_download_and_run_otp(struct ath10k *ar) { u32 result, address = ar->hw_params.patch_load_addr; @@ -1145,19 +1164,19 @@ static int ath10k_core_create_board_name(struct ath10k *ar, char *name, /* strlen(',variant=') + strlen(ar->id.bdf_ext) */ char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH] = { 0 }; + if (ar->id.bdf_ext[0] != '\0') + scnprintf(variant, sizeof(variant), ",variant=%s", + ar->id.bdf_ext); + if (ar->id.bmi_ids_valid) { scnprintf(name, name_len, - "bus=%s,bmi-chip-id=%d,bmi-board-id=%d", + "bus=%s,bmi-chip-id=%d,bmi-board-id=%d%s", ath10k_bus_str(ar->hif.bus), ar->id.bmi_chip_id, - ar->id.bmi_board_id); + ar->id.bmi_board_id, variant); goto out; } - if (ar->id.bdf_ext[0] != '\0') - scnprintf(variant, sizeof(variant), ",variant=%s", - ar->id.bdf_ext); - scnprintf(name, name_len, "bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x%s", ath10k_bus_str(ar->hif.bus), @@ -2221,7 +2240,11 @@ static int ath10k_core_probe_fw(struct ath10k *ar) ret = ath10k_core_check_smbios(ar); if (ret) - ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not set.\n"); + ath10k_dbg(ar, ATH10K_DBG_BOOT, "SMBIOS bdf variant name not set.\n"); + + ret = ath10k_core_check_dt(ar); + if (ret) + ath10k_dbg(ar, ATH10K_DBG_BOOT, "DT bdf variant name not set.\n"); ret = ath10k_core_fetch_board_file(ar); if (ret) { -- 2.11.0 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant 2017-03-10 8:06 ` Sven Eckelmann @ 2017-03-10 18:20 ` Christian Lamparter -1 siblings, 0 replies; 50+ messages in thread From: Christian Lamparter @ 2017-03-10 18:20 UTC (permalink / raw) To: Sven Eckelmann, ext.waldemar.rymarkiewicz Cc: ath10k, linux-wireless, kvalo, Aeolus Yang, Adrian Chadd [-- Attachment #1: Type: text/plain, Size: 5385 bytes --] On Friday, March 10, 2017 9:06:15 AM CET Sven Eckelmann wrote: > Board Data File (BDF) is loaded upon driver boot-up procedure. The right > board data file is identified on QCA4019 using bus, bmi-chip-id and > bmi-board-id. > > The problem, however, can occur when the (default) board data file cannot > fulfill with the vendor requirements and it is necessary to use a different > board data file. > > This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. > Something similar has to be provided for systems without SMBIOS but with > device trees. No solution was specified by QCA and therefore a new one has > to be found for ath10k. > > The device tree requires addition strings to define the variant name > > wifi@a000000 { > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > wifi@a800000 { > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > This would create the boarddata identifiers for the board-2.bin search > > * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U > * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U > > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> > --- I've attached a modified board-2.bin for the RT-AC58U variant: # ath10k-bdencoder -i board-2.bin FileSize: 48564 FileCRC32: 7ac95dfd FileMD5: 825c8e7377b0d543024dbf62f2fd29ff BoardNames[0]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U' BoardLength[0]: 12064 BoardCRC32[0]: bd216dd3 BoardMD5[0]: a12a4745c775beb5ab6ba1e4d711aea0 BoardNames[1]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16' BoardLength[1]: 12064 BoardCRC32[1]: 65a8a5b3 BoardMD5[1]: cb5dcb0337706c313ea3342587b283ae BoardNames[2]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' BoardLength[2]: 12064 BoardCRC32[2]: a7d74de3 BoardMD5[2]: 17bbd05ee0cd9099a549c835b7399b3c BoardNames[3]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=17' BoardLength[3]: 12064 BoardCRC32[3]: 4fe93ca0 BoardMD5[3]: 1aa45fad7a0d6f1c5774b251c712c67c And this is a patched ath10k loading it: [ 106.155058] ath10k_ahb a800000.wifi: boot get otp board id result 0x00004400 board_id 17 chip_id 0 [ 106.155092] ath10k_ahb a800000.wifi: SMBIOS bdf variant name not set. [ 106.155154] ath10k_ahb a800000.wifi: boot using board name 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' [ 106.155570] ath10k_ahb a800000.wifi: board name [ 106.155607] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip [ 106.155644] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- [ 106.155681] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 36 2c 76 61 72 69 61 6e 74 3d 52 54 id=16,variant=RT [ 106.155904] ath10k_ahb a800000.wifi: 00000030: 2d 41 43 35 38 55 -AC58U [ 106.155972] ath10k_ahb a800000.wifi: board name [ 106.156057] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip [ 106.156142] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- [ 106.156211] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 36 id=16 [ 106.156662] ath10k_ahb a800000.wifi: board name [ 106.156700] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip [ 106.156737] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- [ 106.156773] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 37 2c 76 61 72 69 61 6e 74 3d 52 54 id=17,variant=RT [ 106.156809] ath10k_ahb a800000.wifi: 00000030: 2d 41 43 35 38 55 -AC58U [ 106.156845] ath10k_ahb a800000.wifi: boot found match for name 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' [ 106.156876] ath10k_ahb a800000.wifi: boot found board data for 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' [ 106.156906] ath10k_ahb a800000.wifi: using board api 2 [ 106.163704] ath10k_ahb a800000.wifi: board_file api 2 bmi_id 0:17 crc32 f222ba02 [ 106.165037] ath10k_ahb a800000.wifi: boot push board extended data addr 0x0 [ 106.184867] ath10k_ahb a800000.wifi: boot cal file downloaded [ 106.184905] ath10k_ahb a800000.wifi: boot using calibration mode pre-cal-file [ 106.184945] ath10k_ahb a800000.wifi: boot upload otp to 0x1234 len 4582 for board id [ 106.205657] ath10k_ahb a800000.wifi: boot get otp board id result 0x00004400 board_id 17 chip_id 0 [ 106.205811] ath10k_ahb a800000.wifi: boot push board extended data addr 0x0 [ 106.225685] ath10k_ahb a800000.wifi: boot upload otp to 0x1234 len 4582 [ 106.252294] ath10k_ahb a800000.wifi: boot otp execute result 0 @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to the Asus RT-AC58U? I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board files to this mail as well. So, all that needs to be done is to add them to the board-2.bin on your codeaurora / ath10k-firmware project. Kalle: Can you please update the board-2.bin for the IPQ40XX on your ath10k-firmware project on github? https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA40XX/hw1.0/board-2.bin It looks like this board-2.bin has support for a few more boards. Thanks, Christian [-- Attachment #2: board-2.bin --] [-- Type: application/octet-stream, Size: 48564 bytes --] [-- Attachment #3: bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U.bin --] [-- Type: application/octet-stream, Size: 12064 bytes --] [-- Attachment #4: bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U.bin --] [-- Type: application/octet-stream, Size: 12064 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant @ 2017-03-10 18:20 ` Christian Lamparter 0 siblings, 0 replies; 50+ messages in thread From: Christian Lamparter @ 2017-03-10 18:20 UTC (permalink / raw) To: Sven Eckelmann, ext.waldemar.rymarkiewicz Cc: Aeolus Yang, Adrian Chadd, linux-wireless, kvalo, ath10k [-- Attachment #1: Type: text/plain, Size: 5385 bytes --] On Friday, March 10, 2017 9:06:15 AM CET Sven Eckelmann wrote: > Board Data File (BDF) is loaded upon driver boot-up procedure. The right > board data file is identified on QCA4019 using bus, bmi-chip-id and > bmi-board-id. > > The problem, however, can occur when the (default) board data file cannot > fulfill with the vendor requirements and it is necessary to use a different > board data file. > > This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. > Something similar has to be provided for systems without SMBIOS but with > device trees. No solution was specified by QCA and therefore a new one has > to be found for ath10k. > > The device tree requires addition strings to define the variant name > > wifi@a000000 { > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > wifi@a800000 { > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > This would create the boarddata identifiers for the board-2.bin search > > * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U > * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U > > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> > --- I've attached a modified board-2.bin for the RT-AC58U variant: # ath10k-bdencoder -i board-2.bin FileSize: 48564 FileCRC32: 7ac95dfd FileMD5: 825c8e7377b0d543024dbf62f2fd29ff BoardNames[0]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U' BoardLength[0]: 12064 BoardCRC32[0]: bd216dd3 BoardMD5[0]: a12a4745c775beb5ab6ba1e4d711aea0 BoardNames[1]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16' BoardLength[1]: 12064 BoardCRC32[1]: 65a8a5b3 BoardMD5[1]: cb5dcb0337706c313ea3342587b283ae BoardNames[2]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' BoardLength[2]: 12064 BoardCRC32[2]: a7d74de3 BoardMD5[2]: 17bbd05ee0cd9099a549c835b7399b3c BoardNames[3]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=17' BoardLength[3]: 12064 BoardCRC32[3]: 4fe93ca0 BoardMD5[3]: 1aa45fad7a0d6f1c5774b251c712c67c And this is a patched ath10k loading it: [ 106.155058] ath10k_ahb a800000.wifi: boot get otp board id result 0x00004400 board_id 17 chip_id 0 [ 106.155092] ath10k_ahb a800000.wifi: SMBIOS bdf variant name not set. [ 106.155154] ath10k_ahb a800000.wifi: boot using board name 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' [ 106.155570] ath10k_ahb a800000.wifi: board name [ 106.155607] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip [ 106.155644] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- [ 106.155681] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 36 2c 76 61 72 69 61 6e 74 3d 52 54 id=16,variant=RT [ 106.155904] ath10k_ahb a800000.wifi: 00000030: 2d 41 43 35 38 55 -AC58U [ 106.155972] ath10k_ahb a800000.wifi: board name [ 106.156057] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip [ 106.156142] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- [ 106.156211] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 36 id=16 [ 106.156662] ath10k_ahb a800000.wifi: board name [ 106.156700] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip [ 106.156737] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- [ 106.156773] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 37 2c 76 61 72 69 61 6e 74 3d 52 54 id=17,variant=RT [ 106.156809] ath10k_ahb a800000.wifi: 00000030: 2d 41 43 35 38 55 -AC58U [ 106.156845] ath10k_ahb a800000.wifi: boot found match for name 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' [ 106.156876] ath10k_ahb a800000.wifi: boot found board data for 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' [ 106.156906] ath10k_ahb a800000.wifi: using board api 2 [ 106.163704] ath10k_ahb a800000.wifi: board_file api 2 bmi_id 0:17 crc32 f222ba02 [ 106.165037] ath10k_ahb a800000.wifi: boot push board extended data addr 0x0 [ 106.184867] ath10k_ahb a800000.wifi: boot cal file downloaded [ 106.184905] ath10k_ahb a800000.wifi: boot using calibration mode pre-cal-file [ 106.184945] ath10k_ahb a800000.wifi: boot upload otp to 0x1234 len 4582 for board id [ 106.205657] ath10k_ahb a800000.wifi: boot get otp board id result 0x00004400 board_id 17 chip_id 0 [ 106.205811] ath10k_ahb a800000.wifi: boot push board extended data addr 0x0 [ 106.225685] ath10k_ahb a800000.wifi: boot upload otp to 0x1234 len 4582 [ 106.252294] ath10k_ahb a800000.wifi: boot otp execute result 0 @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to the Asus RT-AC58U? I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board files to this mail as well. So, all that needs to be done is to add them to the board-2.bin on your codeaurora / ath10k-firmware project. Kalle: Can you please update the board-2.bin for the IPQ40XX on your ath10k-firmware project on github? https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA40XX/hw1.0/board-2.bin It looks like this board-2.bin has support for a few more boards. Thanks, Christian [-- Attachment #2: board-2.bin --] [-- Type: application/octet-stream, Size: 48564 bytes --] [-- Attachment #3: bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U.bin --] [-- Type: application/octet-stream, Size: 12064 bytes --] [-- Attachment #4: bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U.bin --] [-- Type: application/octet-stream, Size: 12064 bytes --] [-- Attachment #5: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant 2017-03-10 18:20 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Christian Lamparter @ 2017-03-15 8:04 ` Sven Eckelmann -1 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-15 8:04 UTC (permalink / raw) To: Aeolus Yang Cc: Christian Lamparter, ext.waldemar.rymarkiewicz, ath10k, linux-wireless, kvalo, Adrian Chadd, john, Raja Mani, simon.wunderlich [-- Attachment #1: Type: text/plain, Size: 1536 bytes --] On Freitag, 10. März 2017 19:20:54 CET Christian Lamparter wrote: [...] > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to > the Asus RT-AC58U? > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > files to this mail as well. So, all that needs to be done is to add > them to the board-2.bin on your codeaurora / ath10k-firmware project. @Aeolus Yang / QCA, any new infos how these BDFs or similar ones can be integrated in the official [1] QCA40XX board-2.bin? OpenMesh received a board which required modified BDFs for bmi-board-id=16 and bmi-board-id=17. This BDF was generated by QCA and the ODM and of course conflicts with the bmi-board-id=16/17 file in the official QCA40XX board-2.bin. The variant string method [2,3] is currently the only way to have all these conflicting files in the same board-2.bin. Having the RT-AC58U already integrated in the official board-2.bin would be good example and would reduce the barrier for other vendors (with the same problem) a lot. For example OpenMesh could then use the same approach to get their BDFs integrated. Kind regards, Sven [1] "official" as in "part of the official repositories" * https://github.com/kvalo/ath10k-firmware * https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ [2] https://patchwork.kernel.org/patch/9615179/ [3] https://patchwork.kernel.org/patch/9615181/ [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant @ 2017-03-15 8:04 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-15 8:04 UTC (permalink / raw) To: Aeolus Yang Cc: Adrian Chadd, linux-wireless, ath10k, Raja Mani, simon.wunderlich, john, Christian Lamparter, ext.waldemar.rymarkiewicz, kvalo [-- Attachment #1.1: Type: text/plain, Size: 1536 bytes --] On Freitag, 10. März 2017 19:20:54 CET Christian Lamparter wrote: [...] > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to > the Asus RT-AC58U? > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > files to this mail as well. So, all that needs to be done is to add > them to the board-2.bin on your codeaurora / ath10k-firmware project. @Aeolus Yang / QCA, any new infos how these BDFs or similar ones can be integrated in the official [1] QCA40XX board-2.bin? OpenMesh received a board which required modified BDFs for bmi-board-id=16 and bmi-board-id=17. This BDF was generated by QCA and the ODM and of course conflicts with the bmi-board-id=16/17 file in the official QCA40XX board-2.bin. The variant string method [2,3] is currently the only way to have all these conflicting files in the same board-2.bin. Having the RT-AC58U already integrated in the official board-2.bin would be good example and would reduce the barrier for other vendors (with the same problem) a lot. For example OpenMesh could then use the same approach to get their BDFs integrated. Kind regards, Sven [1] "official" as in "part of the official repositories" * https://github.com/kvalo/ath10k-firmware * https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ [2] https://patchwork.kernel.org/patch/9615179/ [3] https://patchwork.kernel.org/patch/9615181/ [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant 2017-03-10 18:20 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Christian Lamparter @ 2017-08-21 7:11 ` Sven Eckelmann -1 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-08-21 7:11 UTC (permalink / raw) To: kvalo Cc: Christian Lamparter, ext.waldemar.rymarkiewicz, ath10k, linux-wireless, Aeolus Yang, Adrian Chadd [-- Attachment #1: Type: text/plain, Size: 745 bytes --] On Freitag, 10. März 2017 19:20:54 CEST Christian Lamparter wrote: [...] > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to > the Asus RT-AC58U? > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > files to this mail as well. So, all that needs to be done is to add > them to the board-2.bin on your codeaurora / ath10k-firmware project. > > Kalle: Can you please update the board-2.bin for the IPQ40XX on your > ath10k-firmware project on github? > > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA40XX/hw1.0/board-2.bin > It looks like this board-2.bin has support for a few more boards. Any updates on that? Kind regards, Sven [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant @ 2017-08-21 7:11 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-08-21 7:11 UTC (permalink / raw) To: kvalo Cc: Adrian Chadd, linux-wireless, ath10k, Aeolus Yang, Christian Lamparter, ext.waldemar.rymarkiewicz [-- Attachment #1.1: Type: text/plain, Size: 745 bytes --] On Freitag, 10. März 2017 19:20:54 CEST Christian Lamparter wrote: [...] > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to > the Asus RT-AC58U? > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > files to this mail as well. So, all that needs to be done is to add > them to the board-2.bin on your codeaurora / ath10k-firmware project. > > Kalle: Can you please update the board-2.bin for the IPQ40XX on your > ath10k-firmware project on github? > > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA40XX/hw1.0/board-2.bin > It looks like this board-2.bin has support for a few more boards. Any updates on that? Kind regards, Sven [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant 2017-08-21 7:11 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Sven Eckelmann @ 2017-10-27 9:34 ` Kalle Valo -1 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-10-27 9:34 UTC (permalink / raw) To: Sven Eckelmann Cc: Adrian Chadd, linux-wireless, ath10k, Aeolus Yang, Christian Lamparter, ext.waldemar.rymarkiewicz U3ZlbiBFY2tlbG1hbm4gPHN2ZW4uZWNrZWxtYW5uQG9wZW5tZXNoLmNvbT4gd3JpdGVzOg0KDQo+ IE9uIEZyZWl0YWcsIDEwLiBNw6RyeiAyMDE3IDE5OjIwOjU0IENFU1QgQ2hyaXN0aWFuIExhbXBh cnRlciB3cm90ZToNCj4gWy4uLl0NCj4+IEBBZW9sdXMgWWFuZyAvIEthbGxlIC8gUUNBOiBXb3Vs ZCBpdCBiZSBwb3NzaWJsZSB0byBhc3NpZ24gYSB2YXJpYW50IHN0cmluZyB0bw0KPj4gdGhlIEFz dXMgUlQtQUM1OFU/DQo+PiANCj4+IEkndmUgYXR0YWNoZWQgdGhlIG5lY2Vzc2FyeSBibWktYm9h cmQtaWQ9MTYgYW5kIGJtaS1ib2FyZC1pZD0xNyBib2FyZCANCj4+IGZpbGVzIHRvIHRoaXMgbWFp bCBhcyB3ZWxsLiBTbywgYWxsIHRoYXQgbmVlZHMgdG8gYmUgZG9uZSBpcyB0byBhZGQNCj4+IHRo ZW0gdG8gdGhlIGJvYXJkLTIuYmluIG9uIHlvdXIgY29kZWF1cm9yYSAvIGF0aDEway1maXJtd2Fy ZSBwcm9qZWN0Lg0KPj4gDQo+PiBLYWxsZTogQ2FuIHlvdSBwbGVhc2UgdXBkYXRlIHRoZSBib2Fy ZC0yLmJpbiBmb3IgdGhlIElQUTQwWFggb24geW91cg0KPj4gYXRoMTBrLWZpcm13YXJlIHByb2pl Y3Qgb24gZ2l0aHViPw0KPj4gDQo+PiBodHRwczovL3NvdXJjZS5jb2RlYXVyb3JhLm9yZy9xdWlj L3FzZGsvb3NzL2Zpcm13YXJlL2F0aDEway1maXJtd2FyZS9wbGFpbi9hdGgxMGsvUUNBNDBYWC9o dzEuMC9ib2FyZC0yLmJpbg0KPj4gSXQgbG9va3MgbGlrZSB0aGlzIGJvYXJkLTIuYmluIGhhcyBz dXBwb3J0IGZvciBhIGZldyBtb3JlIGJvYXJkcy4NCj4NCj4gQW55IHVwZGF0ZXMgb24gdGhhdD8N Cg0KU29ycnksIEkgaGFkIG1pc3NlZCB0aGVzZSBzb21laG93LiBJIHB1dCB0aGVtIG5vdyBiYWNr IHRvIG15IHF1ZXVlOg0KDQpodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3BhdGNoLzk2MTUx ODMvDQoNCmh0dHBzOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcGF0Y2gvOTYxNTE4NS8NCg0KLS0g DQpLYWxsZSBWYWxv ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant @ 2017-10-27 9:34 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-10-27 9:34 UTC (permalink / raw) To: Sven Eckelmann Cc: Adrian Chadd, linux-wireless, ath10k, Aeolus Yang, Christian Lamparter, ext.waldemar.rymarkiewicz Sven Eckelmann <sven.eckelmann@openmesh.com> writes: > On Freitag, 10. März 2017 19:20:54 CEST Christian Lamparter wrote: > [...] >> @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to >> the Asus RT-AC58U? >> >> I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board >> files to this mail as well. So, all that needs to be done is to add >> them to the board-2.bin on your codeaurora / ath10k-firmware project. >> >> Kalle: Can you please update the board-2.bin for the IPQ40XX on your >> ath10k-firmware project on github? >> >> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA40XX/hw1.0/board-2.bin >> It looks like this board-2.bin has support for a few more boards. > > Any updates on that? Sorry, I had missed these somehow. I put them now back to my queue: https://patchwork.kernel.org/patch/9615183/ https://patchwork.kernel.org/patch/9615185/ -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant 2017-03-10 18:20 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Christian Lamparter @ 2017-12-08 9:50 ` Kalle Valo -1 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-12-08 9:50 UTC (permalink / raw) To: Christian Lamparter Cc: Sven Eckelmann, ext.waldemar.rymarkiewicz, Aeolus Yang, Adrian Chadd, linux-wireless, ath10k Christian Lamparter <chunkeey@googlemail.com> writes: > On Friday, March 10, 2017 9:06:15 AM CET Sven Eckelmann wrote: >> Board Data File (BDF) is loaded upon driver boot-up procedure. The right >> board data file is identified on QCA4019 using bus, bmi-chip-id and >> bmi-board-id. >>=20 >> The problem, however, can occur when the (default) board data file canno= t >> fulfill with the vendor requirements and it is necessary to use a differ= ent >> board data file. >>=20 >> This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. >> Something similar has to be provided for systems without SMBIOS but with >> device trees. No solution was specified by QCA and therefore a new one h= as >> to be found for ath10k. >>=20 >> The device tree requires addition strings to define the variant name >>=20 >> wifi@a000000 { >> status =3D "okay"; >> qcom,ath10k-calibration-variant =3D "RT-AC58U"; >> }; >>=20 >> wifi@a800000 { >> status =3D "okay"; >> qcom,ath10k-calibration-variant =3D "RT-AC58U"; >> }; >>=20 >> This would create the boarddata identifiers for the board-2.bin search >>=20 >> * bus=3Dahb,bmi-chip-id=3D0,bmi-board-id=3D16,variant=3DRT-AC58U >> * bus=3Dahb,bmi-chip-id=3D0,bmi-board-id=3D17,variant=3DRT-AC58U >>=20 >> Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [...] > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant stri= ng to > the Asus RT-AC58U? What do you mean? Add qcom,ath10k-calibration-variant to that board's device tree or something else? > I've attached the necessary bmi-board-id=3D16 and bmi-board-id=3D17 board= =20 > files to this mail as well. So, all that needs to be done is to add > them to the board-2.bin on your codeaurora / ath10k-firmware project. > > Kalle: Can you please update the board-2.bin for the IPQ40XX on your > ath10k-firmware project on github? Where did you get these board files from? BTW, it seems lots of people want to add board files so I wrote instruction how I prefer them submitted: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plai= n/ath10k/QCA40XX/hw1.0/board-2.bin > > It looks like this board-2.bin has support for a few more boards. I checked and that should be in ath10k-firmware.git now: $ ath10k-bdencoder --diff ../board-2.bin board-2.bin | tail -1 0 board image(s) added, 0 changed, 0 deleted, 9 in total --=20 Kalle Valo= ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant @ 2017-12-08 9:50 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-12-08 9:50 UTC (permalink / raw) To: Christian Lamparter Cc: Adrian Chadd, linux-wireless, ath10k, Aeolus Yang, Sven Eckelmann, ext.waldemar.rymarkiewicz Christian Lamparter <chunkeey@googlemail.com> writes: > On Friday, March 10, 2017 9:06:15 AM CET Sven Eckelmann wrote: >> Board Data File (BDF) is loaded upon driver boot-up procedure. The right >> board data file is identified on QCA4019 using bus, bmi-chip-id and >> bmi-board-id. >> >> The problem, however, can occur when the (default) board data file cannot >> fulfill with the vendor requirements and it is necessary to use a different >> board data file. >> >> This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. >> Something similar has to be provided for systems without SMBIOS but with >> device trees. No solution was specified by QCA and therefore a new one has >> to be found for ath10k. >> >> The device tree requires addition strings to define the variant name >> >> wifi@a000000 { >> status = "okay"; >> qcom,ath10k-calibration-variant = "RT-AC58U"; >> }; >> >> wifi@a800000 { >> status = "okay"; >> qcom,ath10k-calibration-variant = "RT-AC58U"; >> }; >> >> This would create the boarddata identifiers for the board-2.bin search >> >> * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U >> * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U >> >> Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [...] > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to > the Asus RT-AC58U? What do you mean? Add qcom,ath10k-calibration-variant to that board's device tree or something else? > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > files to this mail as well. So, all that needs to be done is to add > them to the board-2.bin on your codeaurora / ath10k-firmware project. > > Kalle: Can you please update the board-2.bin for the IPQ40XX on your > ath10k-firmware project on github? Where did you get these board files from? BTW, it seems lots of people want to add board files so I wrote instruction how I prefer them submitted: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA40XX/hw1.0/board-2.bin > > It looks like this board-2.bin has support for a few more boards. I checked and that should be in ath10k-firmware.git now: $ ath10k-bdencoder --diff ../board-2.bin board-2.bin | tail -1 0 board image(s) added, 0 changed, 0 deleted, 9 in total -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Asus RT-AC58U boardfile (was Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant) 2017-12-08 9:50 ` Kalle Valo @ 2018-01-29 20:09 ` Christian Lamparter -1 siblings, 0 replies; 50+ messages in thread From: Christian Lamparter @ 2018-01-29 20:09 UTC (permalink / raw) To: Kalle Valo, ath10k; +Cc: Sven Eckelmann, linux-wireless [-- Attachment #1: Type: text/plain, Size: 3794 bytes --] Sven's boarddata for the OpenMesh A42 has been accepted. \o/ So let's try to get the board data for the RT-AC58U merged. On Friday, December 8, 2017 10:50:12 AM CET Kalle Valo wrote: > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > > files to this mail as well. So, all that needs to be done is to add > > them to the board-2.bin on your codeaurora / ath10k-firmware project. > > > > Kalle: Can you please update the board-2.bin for the IPQ40XX on your > > ath10k-firmware project on github? Since some time has passed since the original submission, I just stick to answering the questions in the the guide from: <https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles> > description for what hardware this is The hardware is the ASUS RT-AC58U [0]. It has a IPQ4018 SoC which hosts two ath10k wifis. <https://www.asus.com/Networking/RT-AC58U/> It's based on the qcom-ipq4019-ap.dk01.1-c2. machid: 0x8010100 . the 5GHz and 2.4GHz radio components were drastically changed and as a result, the device's wifis don't work very well with the reference board-2.bin values. The 5GHz wifi suffers the most, the max throughput tops out at 6 Mbps, even in the best possible "lab conditions". > origin of the board file (did you create it yourself or where you downloaded) These files are available in ASUS's GPL Source Code release. The source code can be downloaded from this site: <https://www.asus.com/Networking/RT-AC58U/HelpDesk_Download/> Just select "Driver & Tools" in the right frame and "Others" in the "Please select OS". It's the second tab called "Source Code": |Version 3.0.0.4.380.8119 |2017/10/30 522.32 MBytes |GPL of ASUS RT-AC58U for firmware 3.0.0.4.380.8119 (Note: If you press "Show all", it will list two older releases as well. The boarddata files I sent you back then came from the original GPL_RT-AC58U_3.0.0.4.380.6516-g6772678 release. But the boarddata_*.bin files have been updated since. So I'm attaching the new ones this time.) The zip file contains one big GPL_RT-AC58U_3.0.0.4.380.8119-gdb642b4.tgz which in turn contain these these two files. asuswrt/release/src/router/qca-wifi-fw.ipq40xx/RT-AC58U/boarddata_0.bin asuswrt/release/src/router/qca-wifi-fw.ipq40xx/RT-AC58U/boarddata_1.bin I took the liberty of renaming the files to: boarddata_0 -> bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin boarddata_1 -> bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin > ids to be used with the board file (ATH10K_BD_IE_BOARD_NAME in ath10k) Following OpenMesh A42 example of "VENDOR-DEVICE", I choose to go with: "ASUS-RT-AC58U" as the variant string: full board name (ATH10K_BD_IE_BOARD_NAME): bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U { "data": "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin", "names": [ "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U" ] }, { "data": "bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin", "names": [ "bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U" ] }, (if this is appended at the end of board-2.json, please remove the last comma) > attach the actual board file (board.bin) attached. just in case. These are the sha256sum: d9eb177737983ed320027d50711fd17fadc8057ff0a99d1d455342ef7a7bb1af \ bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin 24969cd91553fd915c51a8fe51c7b7e0e273679e1349b47d0a6c5ef4b4bb4a1b \ bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin I also verified that the ASUS' firmware for the RT-AC58U (FW_RT_AC58U_30043808119.ZIP) uses the very same files. [-- Attachment #2: bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin --] [-- Type: application/octet-stream, Size: 12064 bytes --] [-- Attachment #3: bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin --] [-- Type: application/octet-stream, Size: 12064 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Asus RT-AC58U boardfile (was Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant) @ 2018-01-29 20:09 ` Christian Lamparter 0 siblings, 0 replies; 50+ messages in thread From: Christian Lamparter @ 2018-01-29 20:09 UTC (permalink / raw) To: Kalle Valo, ath10k; +Cc: linux-wireless, Sven Eckelmann [-- Attachment #1: Type: text/plain, Size: 3794 bytes --] Sven's boarddata for the OpenMesh A42 has been accepted. \o/ So let's try to get the board data for the RT-AC58U merged. On Friday, December 8, 2017 10:50:12 AM CET Kalle Valo wrote: > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > > files to this mail as well. So, all that needs to be done is to add > > them to the board-2.bin on your codeaurora / ath10k-firmware project. > > > > Kalle: Can you please update the board-2.bin for the IPQ40XX on your > > ath10k-firmware project on github? Since some time has passed since the original submission, I just stick to answering the questions in the the guide from: <https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles> > description for what hardware this is The hardware is the ASUS RT-AC58U [0]. It has a IPQ4018 SoC which hosts two ath10k wifis. <https://www.asus.com/Networking/RT-AC58U/> It's based on the qcom-ipq4019-ap.dk01.1-c2. machid: 0x8010100 . the 5GHz and 2.4GHz radio components were drastically changed and as a result, the device's wifis don't work very well with the reference board-2.bin values. The 5GHz wifi suffers the most, the max throughput tops out at 6 Mbps, even in the best possible "lab conditions". > origin of the board file (did you create it yourself or where you downloaded) These files are available in ASUS's GPL Source Code release. The source code can be downloaded from this site: <https://www.asus.com/Networking/RT-AC58U/HelpDesk_Download/> Just select "Driver & Tools" in the right frame and "Others" in the "Please select OS". It's the second tab called "Source Code": |Version 3.0.0.4.380.8119 |2017/10/30 522.32 MBytes |GPL of ASUS RT-AC58U for firmware 3.0.0.4.380.8119 (Note: If you press "Show all", it will list two older releases as well. The boarddata files I sent you back then came from the original GPL_RT-AC58U_3.0.0.4.380.6516-g6772678 release. But the boarddata_*.bin files have been updated since. So I'm attaching the new ones this time.) The zip file contains one big GPL_RT-AC58U_3.0.0.4.380.8119-gdb642b4.tgz which in turn contain these these two files. asuswrt/release/src/router/qca-wifi-fw.ipq40xx/RT-AC58U/boarddata_0.bin asuswrt/release/src/router/qca-wifi-fw.ipq40xx/RT-AC58U/boarddata_1.bin I took the liberty of renaming the files to: boarddata_0 -> bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin boarddata_1 -> bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin > ids to be used with the board file (ATH10K_BD_IE_BOARD_NAME in ath10k) Following OpenMesh A42 example of "VENDOR-DEVICE", I choose to go with: "ASUS-RT-AC58U" as the variant string: full board name (ATH10K_BD_IE_BOARD_NAME): bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U { "data": "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin", "names": [ "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U" ] }, { "data": "bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin", "names": [ "bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U" ] }, (if this is appended at the end of board-2.json, please remove the last comma) > attach the actual board file (board.bin) attached. just in case. These are the sha256sum: d9eb177737983ed320027d50711fd17fadc8057ff0a99d1d455342ef7a7bb1af \ bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin 24969cd91553fd915c51a8fe51c7b7e0e273679e1349b47d0a6c5ef4b4bb4a1b \ bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin I also verified that the ASUS' firmware for the RT-AC58U (FW_RT_AC58U_30043808119.ZIP) uses the very same files. [-- Attachment #2: bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin --] [-- Type: application/octet-stream, Size: 12064 bytes --] [-- Attachment #3: bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin --] [-- Type: application/octet-stream, Size: 12064 bytes --] [-- Attachment #4: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Asus RT-AC58U boardfile (was Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant) 2018-01-29 20:09 ` Christian Lamparter @ 2018-10-08 8:21 ` Kalle Valo -1 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2018-10-08 8:21 UTC (permalink / raw) To: Christian Lamparter; +Cc: ath10k, linux-wireless, Sven Eckelmann Christian Lamparter <chunkeey@gmail.com> writes: > Sven's boarddata for the OpenMesh A42 has been accepted. \o/ > So let's try to get the board data for the RT-AC58U merged. > > On Friday, December 8, 2017 10:50:12 AM CET Kalle Valo wrote: >> > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board >> > files to this mail as well. So, all that needs to be done is to add >> > them to the board-2.bin on your codeaurora / ath10k-firmware project. >> > >> > Kalle: Can you please update the board-2.bin for the IPQ40XX on your >> > ath10k-firmware project on github? > > Since some time has passed since the original submission, I just stick to > answering the questions in the the guide from: > <https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles> > >> description for what hardware this is > The hardware is the ASUS RT-AC58U [0]. It has a IPQ4018 SoC which > hosts two ath10k wifis. <https://www.asus.com/Networking/RT-AC58U/> > It's based on the qcom-ipq4019-ap.dk01.1-c2. machid: 0x8010100 . > the 5GHz and 2.4GHz radio components were drastically changed and > as a result, the device's wifis don't work very well with the reference > board-2.bin values. The 5GHz wifi suffers the most, the max throughput > tops out at 6 Mbps, even in the best possible "lab conditions". > >> origin of the board file (did you create it yourself or where you downloaded) > > These files are available in ASUS's GPL Source Code release. > > The source code can be downloaded from this site: > <https://www.asus.com/Networking/RT-AC58U/HelpDesk_Download/> > Just select "Driver & Tools" in the right frame and "Others" > in the "Please select OS". It's the second tab called "Source Code": > > |Version 3.0.0.4.380.8119 > |2017/10/30 522.32 MBytes > |GPL of ASUS RT-AC58U for firmware 3.0.0.4.380.8119 > (Note: If you press "Show all", it will list two older releases as well. > The boarddata files I sent you back then came from the original > GPL_RT-AC58U_3.0.0.4.380.6516-g6772678 release. But the boarddata_*.bin > files have been updated since. So I'm attaching the new ones this time.) > > The zip file contains one big GPL_RT-AC58U_3.0.0.4.380.8119-gdb642b4.tgz > which in turn contain these these two files. > asuswrt/release/src/router/qca-wifi-fw.ipq40xx/RT-AC58U/boarddata_0.bin > asuswrt/release/src/router/qca-wifi-fw.ipq40xx/RT-AC58U/boarddata_1.bin > > I took the liberty of renaming the files to: > > boarddata_0 -> bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin > boarddata_1 -> bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin > >> ids to be used with the board file (ATH10K_BD_IE_BOARD_NAME in ath10k) > > Following OpenMesh A42 example of "VENDOR-DEVICE", I choose to go with: > "ASUS-RT-AC58U" as the variant string: > > full board name (ATH10K_BD_IE_BOARD_NAME): > bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U > bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U > > { > "data": "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin", > "names": [ > "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U" > ] > }, > { > "data": "bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin", > "names": [ > "bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U" > ] > }, > > (if this is appended at the end of board-2.json, please remove the > last comma) > >> attach the actual board file (board.bin) > attached. > > just in case. These are the sha256sum: > d9eb177737983ed320027d50711fd17fadc8057ff0a99d1d455342ef7a7bb1af \ > bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin > > 24969cd91553fd915c51a8fe51c7b7e0e273679e1349b47d0a6c5ef4b4bb4a1b \ > bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin > > I also verified that the ASUS' firmware for the RT-AC58U > (FW_RT_AC58U_30043808119.ZIP) uses the very same files. Added, thanks. But please do double check that I didn't do any mistakes. https://github.com/kvalo/ath10k-firmware/commit/4b89c2b7efef0ba663339c1a42c673e97c7562bd -- Kalle Valo ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Asus RT-AC58U boardfile (was Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant) @ 2018-10-08 8:21 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2018-10-08 8:21 UTC (permalink / raw) To: Christian Lamparter; +Cc: linux-wireless, ath10k, Sven Eckelmann Christian Lamparter <chunkeey@gmail.com> writes: > Sven's boarddata for the OpenMesh A42 has been accepted. \o/ > So let's try to get the board data for the RT-AC58U merged. > > On Friday, December 8, 2017 10:50:12 AM CET Kalle Valo wrote: >> > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board >> > files to this mail as well. So, all that needs to be done is to add >> > them to the board-2.bin on your codeaurora / ath10k-firmware project. >> > >> > Kalle: Can you please update the board-2.bin for the IPQ40XX on your >> > ath10k-firmware project on github? > > Since some time has passed since the original submission, I just stick to > answering the questions in the the guide from: > <https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles> > >> description for what hardware this is > The hardware is the ASUS RT-AC58U [0]. It has a IPQ4018 SoC which > hosts two ath10k wifis. <https://www.asus.com/Networking/RT-AC58U/> > It's based on the qcom-ipq4019-ap.dk01.1-c2. machid: 0x8010100 . > the 5GHz and 2.4GHz radio components were drastically changed and > as a result, the device's wifis don't work very well with the reference > board-2.bin values. The 5GHz wifi suffers the most, the max throughput > tops out at 6 Mbps, even in the best possible "lab conditions". > >> origin of the board file (did you create it yourself or where you downloaded) > > These files are available in ASUS's GPL Source Code release. > > The source code can be downloaded from this site: > <https://www.asus.com/Networking/RT-AC58U/HelpDesk_Download/> > Just select "Driver & Tools" in the right frame and "Others" > in the "Please select OS". It's the second tab called "Source Code": > > |Version 3.0.0.4.380.8119 > |2017/10/30 522.32 MBytes > |GPL of ASUS RT-AC58U for firmware 3.0.0.4.380.8119 > (Note: If you press "Show all", it will list two older releases as well. > The boarddata files I sent you back then came from the original > GPL_RT-AC58U_3.0.0.4.380.6516-g6772678 release. But the boarddata_*.bin > files have been updated since. So I'm attaching the new ones this time.) > > The zip file contains one big GPL_RT-AC58U_3.0.0.4.380.8119-gdb642b4.tgz > which in turn contain these these two files. > asuswrt/release/src/router/qca-wifi-fw.ipq40xx/RT-AC58U/boarddata_0.bin > asuswrt/release/src/router/qca-wifi-fw.ipq40xx/RT-AC58U/boarddata_1.bin > > I took the liberty of renaming the files to: > > boarddata_0 -> bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin > boarddata_1 -> bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin > >> ids to be used with the board file (ATH10K_BD_IE_BOARD_NAME in ath10k) > > Following OpenMesh A42 example of "VENDOR-DEVICE", I choose to go with: > "ASUS-RT-AC58U" as the variant string: > > full board name (ATH10K_BD_IE_BOARD_NAME): > bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U > bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U > > { > "data": "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin", > "names": [ > "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U" > ] > }, > { > "data": "bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin", > "names": [ > "bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U" > ] > }, > > (if this is appended at the end of board-2.json, please remove the > last comma) > >> attach the actual board file (board.bin) > attached. > > just in case. These are the sha256sum: > d9eb177737983ed320027d50711fd17fadc8057ff0a99d1d455342ef7a7bb1af \ > bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=ASUS-RT-AC58U.bin > > 24969cd91553fd915c51a8fe51c7b7e0e273679e1349b47d0a6c5ef4b4bb4a1b \ > bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=ASUS-RT-AC58U.bin > > I also verified that the ASUS' firmware for the RT-AC58U > (FW_RT_AC58U_30043808119.ZIP) uses the very same files. Added, thanks. But please do double check that I didn't do any mistakes. https://github.com/kvalo/ath10k-firmware/commit/4b89c2b7efef0ba663339c1a42c673e97c7562bd -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant 2017-03-10 18:20 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Christian Lamparter @ 2018-04-19 14:56 ` Kalle Valo -1 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2018-04-19 14:56 UTC (permalink / raw) To: Christian Lamparter Cc: Sven Eckelmann, ext.waldemar.rymarkiewicz, Aeolus Yang, Adrian Chadd, linux-wireless, ath10k Christian Lamparter <chunkeey@googlemail.com> writes: > On Friday, March 10, 2017 9:06:15 AM CET Sven Eckelmann wrote: >> Board Data File (BDF) is loaded upon driver boot-up procedure. The right >> board data file is identified on QCA4019 using bus, bmi-chip-id and >> bmi-board-id. >> >> The problem, however, can occur when the (default) board data file cannot >> fulfill with the vendor requirements and it is necessary to use a different >> board data file. >> >> This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. >> Something similar has to be provided for systems without SMBIOS but with >> device trees. No solution was specified by QCA and therefore a new one has >> to be found for ath10k. >> >> The device tree requires addition strings to define the variant name >> >> wifi@a000000 { >> status = "okay"; >> qcom,ath10k-calibration-variant = "RT-AC58U"; >> }; >> >> wifi@a800000 { >> status = "okay"; >> qcom,ath10k-calibration-variant = "RT-AC58U"; >> }; >> >> This would create the boarddata identifiers for the board-2.bin search >> >> * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U >> * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U >> >> Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> >> --- > I've attached a modified board-2.bin for the RT-AC58U variant: > > # ath10k-bdencoder -i board-2.bin > FileSize: 48564 > FileCRC32: 7ac95dfd > FileMD5: 825c8e7377b0d543024dbf62f2fd29ff > BoardNames[0]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U' > BoardLength[0]: 12064 > BoardCRC32[0]: bd216dd3 > BoardMD5[0]: a12a4745c775beb5ab6ba1e4d711aea0 > BoardNames[1]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16' > BoardLength[1]: 12064 > BoardCRC32[1]: 65a8a5b3 > BoardMD5[1]: cb5dcb0337706c313ea3342587b283ae > BoardNames[2]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' > BoardLength[2]: 12064 > BoardCRC32[2]: a7d74de3 > BoardMD5[2]: 17bbd05ee0cd9099a549c835b7399b3c > BoardNames[3]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=17' > BoardLength[3]: 12064 > BoardCRC32[3]: 4fe93ca0 > BoardMD5[3]: 1aa45fad7a0d6f1c5774b251c712c67c > > And this is a patched ath10k loading it: > > [ 106.155058] ath10k_ahb a800000.wifi: boot get otp board id result > 0x00004400 board_id 17 chip_id 0 > [ 106.155092] ath10k_ahb a800000.wifi: SMBIOS bdf variant name not set. > [ 106.155154] ath10k_ahb a800000.wifi: boot using board name > 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' > [ 106.155570] ath10k_ahb a800000.wifi: board name > [ 106.155607] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 > 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip > [ 106.155644] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 > 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- > [ 106.155681] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 36 2c 76 > 61 72 69 61 6e 74 3d 52 54 id=16,variant=RT > [ 106.155904] ath10k_ahb a800000.wifi: 00000030: 2d 41 43 35 38 55 > -AC58U > [ 106.155972] ath10k_ahb a800000.wifi: board name > [ 106.156057] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 > 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip > [ 106.156142] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 > 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- > [ 106.156211] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 36 id=16 > [ 106.156662] ath10k_ahb a800000.wifi: board name > [ 106.156700] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 > 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip > [ 106.156737] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 > 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- > [ 106.156773] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 37 2c 76 > 61 72 69 61 6e 74 3d 52 54 id=17,variant=RT > [ 106.156809] ath10k_ahb a800000.wifi: 00000030: 2d 41 43 35 38 55 > -AC58U > [ 106.156845] ath10k_ahb a800000.wifi: boot found match for name > 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' > [ 106.156876] ath10k_ahb a800000.wifi: boot found board data for > 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' > [ 106.156906] ath10k_ahb a800000.wifi: using board api 2 > [ 106.163704] ath10k_ahb a800000.wifi: board_file api 2 bmi_id 0:17 crc32 f222ba02 > [ 106.165037] ath10k_ahb a800000.wifi: boot push board extended data addr 0x0 > [ 106.184867] ath10k_ahb a800000.wifi: boot cal file downloaded > [ 106.184905] ath10k_ahb a800000.wifi: boot using calibration mode pre-cal-file > [ 106.184945] ath10k_ahb a800000.wifi: boot upload otp to 0x1234 len > 4582 for board id > [ 106.205657] ath10k_ahb a800000.wifi: boot get otp board id result > 0x00004400 board_id 17 chip_id 0 > [ 106.205811] ath10k_ahb a800000.wifi: boot push board extended data addr 0x0 > [ 106.225685] ath10k_ahb a800000.wifi: boot upload otp to 0x1234 len 4582 > [ 106.252294] ath10k_ahb a800000.wifi: boot otp execute result 0 > > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to > the Asus RT-AC58U? > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > files to this mail as well. So, all that needs to be done is to add > them to the board-2.bin on your codeaurora / ath10k-firmware project. > > Kalle: Can you please update the board-2.bin for the IPQ40XX on your > ath10k-firmware project on github? I have added them now, please check: https://github.com/kvalo/ath10k-firmware/commit/a47bcf1e58c4d8914af0951a80fd8861368b700d New: bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U Changed: Deleted: 1 board image(s) added, 0 changed, 0 deleted, 24 in total New: bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U Changed: Deleted: 1 board image(s) added, 0 changed, 0 deleted, 25 in total -- Kalle Valo ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant @ 2018-04-19 14:56 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2018-04-19 14:56 UTC (permalink / raw) To: Christian Lamparter Cc: Adrian Chadd, linux-wireless, ath10k, Aeolus Yang, Sven Eckelmann, ext.waldemar.rymarkiewicz Christian Lamparter <chunkeey@googlemail.com> writes: > On Friday, March 10, 2017 9:06:15 AM CET Sven Eckelmann wrote: >> Board Data File (BDF) is loaded upon driver boot-up procedure. The right >> board data file is identified on QCA4019 using bus, bmi-chip-id and >> bmi-board-id. >> >> The problem, however, can occur when the (default) board data file cannot >> fulfill with the vendor requirements and it is necessary to use a different >> board data file. >> >> This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. >> Something similar has to be provided for systems without SMBIOS but with >> device trees. No solution was specified by QCA and therefore a new one has >> to be found for ath10k. >> >> The device tree requires addition strings to define the variant name >> >> wifi@a000000 { >> status = "okay"; >> qcom,ath10k-calibration-variant = "RT-AC58U"; >> }; >> >> wifi@a800000 { >> status = "okay"; >> qcom,ath10k-calibration-variant = "RT-AC58U"; >> }; >> >> This would create the boarddata identifiers for the board-2.bin search >> >> * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U >> * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U >> >> Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> >> --- > I've attached a modified board-2.bin for the RT-AC58U variant: > > # ath10k-bdencoder -i board-2.bin > FileSize: 48564 > FileCRC32: 7ac95dfd > FileMD5: 825c8e7377b0d543024dbf62f2fd29ff > BoardNames[0]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U' > BoardLength[0]: 12064 > BoardCRC32[0]: bd216dd3 > BoardMD5[0]: a12a4745c775beb5ab6ba1e4d711aea0 > BoardNames[1]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=16' > BoardLength[1]: 12064 > BoardCRC32[1]: 65a8a5b3 > BoardMD5[1]: cb5dcb0337706c313ea3342587b283ae > BoardNames[2]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' > BoardLength[2]: 12064 > BoardCRC32[2]: a7d74de3 > BoardMD5[2]: 17bbd05ee0cd9099a549c835b7399b3c > BoardNames[3]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=17' > BoardLength[3]: 12064 > BoardCRC32[3]: 4fe93ca0 > BoardMD5[3]: 1aa45fad7a0d6f1c5774b251c712c67c > > And this is a patched ath10k loading it: > > [ 106.155058] ath10k_ahb a800000.wifi: boot get otp board id result > 0x00004400 board_id 17 chip_id 0 > [ 106.155092] ath10k_ahb a800000.wifi: SMBIOS bdf variant name not set. > [ 106.155154] ath10k_ahb a800000.wifi: boot using board name > 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' > [ 106.155570] ath10k_ahb a800000.wifi: board name > [ 106.155607] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 > 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip > [ 106.155644] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 > 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- > [ 106.155681] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 36 2c 76 > 61 72 69 61 6e 74 3d 52 54 id=16,variant=RT > [ 106.155904] ath10k_ahb a800000.wifi: 00000030: 2d 41 43 35 38 55 > -AC58U > [ 106.155972] ath10k_ahb a800000.wifi: board name > [ 106.156057] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 > 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip > [ 106.156142] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 > 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- > [ 106.156211] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 36 id=16 > [ 106.156662] ath10k_ahb a800000.wifi: board name > [ 106.156700] ath10k_ahb a800000.wifi: 00000000: 62 75 73 3d 61 68 62 > 2c 62 6d 69 2d 63 68 69 70 bus=ahb,bmi-chip > [ 106.156737] ath10k_ahb a800000.wifi: 00000010: 2d 69 64 3d 30 2c 62 > 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board- > [ 106.156773] ath10k_ahb a800000.wifi: 00000020: 69 64 3d 31 37 2c 76 > 61 72 69 61 6e 74 3d 52 54 id=17,variant=RT > [ 106.156809] ath10k_ahb a800000.wifi: 00000030: 2d 41 43 35 38 55 > -AC58U > [ 106.156845] ath10k_ahb a800000.wifi: boot found match for name > 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' > [ 106.156876] ath10k_ahb a800000.wifi: boot found board data for > 'bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U' > [ 106.156906] ath10k_ahb a800000.wifi: using board api 2 > [ 106.163704] ath10k_ahb a800000.wifi: board_file api 2 bmi_id 0:17 crc32 f222ba02 > [ 106.165037] ath10k_ahb a800000.wifi: boot push board extended data addr 0x0 > [ 106.184867] ath10k_ahb a800000.wifi: boot cal file downloaded > [ 106.184905] ath10k_ahb a800000.wifi: boot using calibration mode pre-cal-file > [ 106.184945] ath10k_ahb a800000.wifi: boot upload otp to 0x1234 len > 4582 for board id > [ 106.205657] ath10k_ahb a800000.wifi: boot get otp board id result > 0x00004400 board_id 17 chip_id 0 > [ 106.205811] ath10k_ahb a800000.wifi: boot push board extended data addr 0x0 > [ 106.225685] ath10k_ahb a800000.wifi: boot upload otp to 0x1234 len 4582 > [ 106.252294] ath10k_ahb a800000.wifi: boot otp execute result 0 > > @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to > the Asus RT-AC58U? > > I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board > files to this mail as well. So, all that needs to be done is to add > them to the board-2.bin on your codeaurora / ath10k-firmware project. > > Kalle: Can you please update the board-2.bin for the IPQ40XX on your > ath10k-firmware project on github? I have added them now, please check: https://github.com/kvalo/ath10k-firmware/commit/a47bcf1e58c4d8914af0951a80fd8861368b700d New: bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U Changed: Deleted: 1 board image(s) added, 0 changed, 0 deleted, 24 in total New: bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U Changed: Deleted: 1 board image(s) added, 0 changed, 0 deleted, 25 in total -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant 2018-04-19 14:56 ` Kalle Valo @ 2018-04-20 19:50 ` Christian Lamparter -1 siblings, 0 replies; 50+ messages in thread From: Christian Lamparter @ 2018-04-20 19:50 UTC (permalink / raw) To: Kalle Valo Cc: Sven Eckelmann, ext.waldemar.rymarkiewicz, Aeolus Yang, Adrian Chadd, linux-wireless, ath10k On Donnerstag, 19. April 2018 16:56:36 CEST Kalle Valo wrote: > [...] > I have added them now, please check: > > https://github.com/kvalo/ath10k-firmware/commit/a47bcf1e58c4d8914af0951a80fd8861368b700d Yes, The RT-AC58U is now working much better. The updated RT-AC58U board-data is here: <http://lists.infradead.org/pipermail/ath10k/2018-January/010770.html> Regards Christian ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant @ 2018-04-20 19:50 ` Christian Lamparter 0 siblings, 0 replies; 50+ messages in thread From: Christian Lamparter @ 2018-04-20 19:50 UTC (permalink / raw) To: Kalle Valo Cc: Adrian Chadd, linux-wireless, ath10k, Aeolus Yang, Sven Eckelmann, ext.waldemar.rymarkiewicz On Donnerstag, 19. April 2018 16:56:36 CEST Kalle Valo wrote: > [...] > I have added them now, please check: > > https://github.com/kvalo/ath10k-firmware/commit/a47bcf1e58c4d8914af0951a80fd8861368b700d Yes, The RT-AC58U is now working much better. The updated RT-AC58U board-data is here: <http://lists.infradead.org/pipermail/ath10k/2018-January/010770.html> Regards Christian _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant @ 2017-12-08 9:27 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-12-08 9:27 UTC (permalink / raw) To: Sven Eckelmann Cc: ath10k, mark.rutland, devicetree, linux-wireless, robh+dt, ext.waldemar.rymarkiewicz Sven Eckelmann <sven.eckelmann@openmesh.com> writes: > Board Data File (BDF) is loaded upon driver boot-up procedure. The right > board data file is identified on QCA4019 using bus, bmi-chip-id and > bmi-board-id. > > The problem, however, can occur when the (default) board data file cannot > fulfill with the vendor requirements and it is necessary to use a differe= nt > board data file. > > This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. > Something similar has to be provided for systems without SMBIOS but with > device trees. No solution was specified by QCA and therefore a new one ha= s > to be found for ath10k. > > The device tree requires addition strings to define the variant name > > wifi@a000000 { > status =3D "okay"; > qcom,ath10k-calibration-variant =3D "RT-AC58U"; > }; > > wifi@a800000 { > status =3D "okay"; > qcom,ath10k-calibration-variant =3D "RT-AC58U"; > }; > > This would create the boarddata identifiers for the board-2.bin search > > * bus=3Dahb,bmi-chip-id=3D0,bmi-board-id=3D16,variant=3DRT-AC58U > * bus=3Dahb,bmi-chip-id=3D0,bmi-board-id=3D17,variant=3DRT-AC58U > > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> > --- > Since RFC: > > - initialize variant pointer to have it initialized to NULL when > of_property_read_string fails (thanks Christian Lamparter) > - Only print warning that DT doesn't contain string ones (thanks Christi= an > Lamparter) > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) > - Allow to overwrite the variant string via DT and ignore that SMBIOS ha= d > written anything to it [...] > --- a/drivers/net/wireless/ath/ath10k/core.c > +++ b/drivers/net/wireless/ath/ath10k/core.c > @@ -779,6 +779,25 @@ static int ath10k_core_check_smbios(struct ath10k *a= r) > return 0; > } > =20 > +static int ath10k_core_check_dt(struct ath10k *ar) > +{ > + struct device_node *node; > + const char *variant =3D NULL; > + > + node =3D ar->dev->of_node; > + if (!node) > + return -ENOENT; > + > + of_property_read_string(node, "qcom,ath10k-calibration-variant", > + &variant); > + if (!variant) > + return -ENODATA; > + > + strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); Kbuild bot found a warning here: drivers/net/wireless/ath/ath10k/core.c: In function 'ath10k_core_check_d= t': >> drivers/net/wireless/ath/ath10k/core.c:877:2: warning: ignoring return v= alue of 'strscpy', declared with attribute warn_unused_result [-Wunused-res= ult] strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I guess warn_unused_result in strscpy() is a recent addition and that's why you didn't see it. --=20 Kalle Valo= ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant @ 2017-12-08 9:27 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-12-08 9:27 UTC (permalink / raw) To: Sven Eckelmann Cc: mark.rutland, devicetree, linux-wireless, ath10k, robh+dt, ext.waldemar.rymarkiewicz Sven Eckelmann <sven.eckelmann@openmesh.com> writes: > Board Data File (BDF) is loaded upon driver boot-up procedure. The right > board data file is identified on QCA4019 using bus, bmi-chip-id and > bmi-board-id. > > The problem, however, can occur when the (default) board data file cannot > fulfill with the vendor requirements and it is necessary to use a different > board data file. > > This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. > Something similar has to be provided for systems without SMBIOS but with > device trees. No solution was specified by QCA and therefore a new one has > to be found for ath10k. > > The device tree requires addition strings to define the variant name > > wifi@a000000 { > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > wifi@a800000 { > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > This would create the boarddata identifiers for the board-2.bin search > > * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U > * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U > > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> > --- > Since RFC: > > - initialize variant pointer to have it initialized to NULL when > of_property_read_string fails (thanks Christian Lamparter) > - Only print warning that DT doesn't contain string ones (thanks Christian > Lamparter) > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) > - Allow to overwrite the variant string via DT and ignore that SMBIOS had > written anything to it [...] > --- a/drivers/net/wireless/ath/ath10k/core.c > +++ b/drivers/net/wireless/ath/ath10k/core.c > @@ -779,6 +779,25 @@ static int ath10k_core_check_smbios(struct ath10k *ar) > return 0; > } > > +static int ath10k_core_check_dt(struct ath10k *ar) > +{ > + struct device_node *node; > + const char *variant = NULL; > + > + node = ar->dev->of_node; > + if (!node) > + return -ENOENT; > + > + of_property_read_string(node, "qcom,ath10k-calibration-variant", > + &variant); > + if (!variant) > + return -ENODATA; > + > + strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); Kbuild bot found a warning here: drivers/net/wireless/ath/ath10k/core.c: In function 'ath10k_core_check_dt': >> drivers/net/wireless/ath/ath10k/core.c:877:2: warning: ignoring return value of 'strscpy', declared with attribute warn_unused_result [-Wunused-result] strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I guess warn_unused_result in strscpy() is a recent addition and that's why you didn't see it. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant @ 2017-12-08 9:27 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-12-08 9:27 UTC (permalink / raw) To: Sven Eckelmann Cc: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-wireless-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, ext.waldemar.rymarkiewicz-++hxYGjEMp0AvxtiuMwx3w Sven Eckelmann <sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org> writes: > Board Data File (BDF) is loaded upon driver boot-up procedure. The right > board data file is identified on QCA4019 using bus, bmi-chip-id and > bmi-board-id. > > The problem, however, can occur when the (default) board data file cannot > fulfill with the vendor requirements and it is necessary to use a different > board data file. > > This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8. > Something similar has to be provided for systems without SMBIOS but with > device trees. No solution was specified by QCA and therefore a new one has > to be found for ath10k. > > The device tree requires addition strings to define the variant name > > wifi@a000000 { > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > wifi@a800000 { > status = "okay"; > qcom,ath10k-calibration-variant = "RT-AC58U"; > }; > > This would create the boarddata identifiers for the board-2.bin search > > * bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U > * bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U > > Signed-off-by: Sven Eckelmann <sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org> > --- > Since RFC: > > - initialize variant pointer to have it initialized to NULL when > of_property_read_string fails (thanks Christian Lamparter) > - Only print warning that DT doesn't contain string ones (thanks Christian > Lamparter) > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) > - Allow to overwrite the variant string via DT and ignore that SMBIOS had > written anything to it [...] > --- a/drivers/net/wireless/ath/ath10k/core.c > +++ b/drivers/net/wireless/ath/ath10k/core.c > @@ -779,6 +779,25 @@ static int ath10k_core_check_smbios(struct ath10k *ar) > return 0; > } > > +static int ath10k_core_check_dt(struct ath10k *ar) > +{ > + struct device_node *node; > + const char *variant = NULL; > + > + node = ar->dev->of_node; > + if (!node) > + return -ENOENT; > + > + of_property_read_string(node, "qcom,ath10k-calibration-variant", > + &variant); > + if (!variant) > + return -ENODATA; > + > + strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); Kbuild bot found a warning here: drivers/net/wireless/ath/ath10k/core.c: In function 'ath10k_core_check_dt': >> drivers/net/wireless/ath/ath10k/core.c:877:2: warning: ignoring return value of 'strscpy', declared with attribute warn_unused_result [-Wunused-result] strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I guess warn_unused_result in strscpy() is a recent addition and that's why you didn't see it. -- Kalle Valo ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant 2017-03-10 8:06 ` Sven Eckelmann (?) @ 2017-03-20 15:07 ` Rob Herring -1 siblings, 0 replies; 50+ messages in thread From: Rob Herring @ 2017-03-20 15:07 UTC (permalink / raw) To: Sven Eckelmann Cc: ath10k, linux-wireless, devicetree, mark.rutland, ext.waldemar.rymarkiewicz, kvalo 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 > ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-20 15:07 ` Rob Herring 0 siblings, 0 replies; 50+ messages in thread From: Rob Herring @ 2017-03-20 15:07 UTC (permalink / raw) To: Sven Eckelmann Cc: mark.rutland, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz, kvalo 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 > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-20 15:07 ` Rob Herring 0 siblings, 0 replies; 50+ messages in thread From: Rob Herring @ 2017-03-20 15:07 UTC (permalink / raw) To: Sven Eckelmann Cc: mark.rutland, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz, kvalo 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 > ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant 2017-03-20 15:07 ` Rob Herring (?) @ 2017-03-20 16:28 ` Sven Eckelmann -1 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-20 16:28 UTC (permalink / raw) To: Rob Herring Cc: ath10k, linux-wireless, devicetree, mark.rutland, ext.waldemar.rymarkiewicz, kvalo [-- Attachment #1: Type: text/plain, Size: 2644 bytes --] 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-20 16:28 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-20 16:28 UTC (permalink / raw) To: Rob Herring Cc: mark.rutland, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz, kvalo [-- Attachment #1.1: Type: text/plain, Size: 2644 bytes --] 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 [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-20 16:28 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-20 16:28 UTC (permalink / raw) To: Rob Herring Cc: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8, ext.waldemar.rymarkiewicz-++hxYGjEMp0AvxtiuMwx3w, kvalo-sgV2jX0FEOL9JmXXK+q4OQ [-- Attachment #1: Type: text/plain, Size: 2671 bytes --] 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-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org> > > --- > > 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant 2017-03-20 16:28 ` Sven Eckelmann @ 2017-03-20 16:42 ` Adrian Chadd -1 siblings, 0 replies; 50+ messages in thread From: Adrian Chadd @ 2017-03-20 16:42 UTC (permalink / raw) To: Sven Eckelmann Cc: Rob Herring, ath10k, linux-wireless, devicetree, Mark Rutland, Waldemar Rymarkiewicz, Kalle Valo 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> wro= te: > On Montag, 20. M=C3=A4rz 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 cor= rect >> > board data file on QCA4019 based devices. Multiple different boards sh= are >> > 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 da= ta >> > 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,ath10= k.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 devi= ce >> > + specific ids >> >> Sounds like you should use a more specific compatible string. > > Hm, this would require that each calibration data has an own compatibilit= y > string - which then has to be supported by ath10k, right? Doesn't sound l= ike > it would work well when each vendor (with an own calibration variant) wou= ld > have to modify ath10k to get it working. This sounds especially odd becau= se > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-20 16:42 ` Adrian Chadd 0 siblings, 0 replies; 50+ messages in thread From: Adrian Chadd @ 2017-03-20 16:42 UTC (permalink / raw) To: Sven Eckelmann Cc: Mark Rutland, Rob Herring, devicetree, linux-wireless, ath10k, Waldemar Rymarkiewicz, Kalle Valo 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant 2017-03-20 16:42 ` Adrian Chadd @ 2017-03-21 7:29 ` Sven Eckelmann -1 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-21 7:29 UTC (permalink / raw) To: Adrian Chadd Cc: Rob Herring, ath10k, linux-wireless, devicetree, Mark Rutland, Waldemar Rymarkiewicz, Kalle Valo [-- Attachment #1: Type: text/plain, Size: 648 bytes --] 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-21 7:29 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-21 7:29 UTC (permalink / raw) To: Adrian Chadd Cc: Mark Rutland, Rob Herring, devicetree, linux-wireless, ath10k, Waldemar Rymarkiewicz, Kalle Valo [-- Attachment #1.1: Type: text/plain, Size: 648 bytes --] 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 [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant 2017-03-20 16:28 ` Sven Eckelmann (?) @ 2017-03-21 13:00 ` Rob Herring -1 siblings, 0 replies; 50+ messages in thread From: Rob Herring @ 2017-03-21 13:00 UTC (permalink / raw) To: Sven Eckelmann Cc: ath10k, linux-wireless, devicetree, Mark Rutland, ext.waldemar.rymarkiewicz, Kalle Valo 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-21 13:00 ` Rob Herring 0 siblings, 0 replies; 50+ messages in thread From: Rob Herring @ 2017-03-21 13:00 UTC (permalink / raw) To: Sven Eckelmann Cc: Mark Rutland, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz, Kalle Valo 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-21 13:00 ` Rob Herring 0 siblings, 0 replies; 50+ messages in thread From: Rob Herring @ 2017-03-21 13:00 UTC (permalink / raw) To: Sven Eckelmann Cc: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, ext.waldemar.rymarkiewicz-++hxYGjEMp0AvxtiuMwx3w, Kalle Valo On Mon, Mar 20, 2017 at 11:28 AM, Sven Eckelmann <sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org> 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-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org> >> > --- >> > 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 -- 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] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-21 14:33 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-21 14:33 UTC (permalink / raw) To: Rob Herring Cc: ath10k, linux-wireless, devicetree, Mark Rutland, ext.waldemar.rymarkiewicz, Kalle Valo [-- Attachment #1: Type: text/plain, Size: 7312 bytes --] 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-21 14:33 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-21 14:33 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz, Kalle Valo [-- Attachment #1.1: Type: text/plain, Size: 7312 bytes --] 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 [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-21 14:33 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-21 14:33 UTC (permalink / raw) To: Rob Herring Cc: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-wireless, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, ext.waldemar.rymarkiewicz-++hxYGjEMp0AvxtiuMwx3w, Kalle Valo [-- Attachment #1: Type: text/plain, Size: 7312 bytes --] 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant 2017-03-21 14:33 ` Sven Eckelmann @ 2017-03-22 2:56 ` Rob Herring -1 siblings, 0 replies; 50+ messages in thread From: Rob Herring @ 2017-03-22 2:56 UTC (permalink / raw) To: Sven Eckelmann Cc: ath10k, linux-wireless, devicetree, Mark Rutland, ext.waldemar.rymarkiewicz, Kalle Valo 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-22 2:56 ` Rob Herring 0 siblings, 0 replies; 50+ messages in thread From: Rob Herring @ 2017-03-22 2:56 UTC (permalink / raw) To: Sven Eckelmann Cc: Mark Rutland, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz, Kalle Valo 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant 2017-03-22 2:56 ` Rob Herring @ 2017-03-22 7:20 ` Sven Eckelmann -1 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-22 7:20 UTC (permalink / raw) To: Rob Herring Cc: ath10k, linux-wireless, devicetree, Mark Rutland, ext.waldemar.rymarkiewicz, Kalle Valo [-- Attachment #1: Type: text/plain, Size: 1367 bytes --] 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-03-22 7:20 ` Sven Eckelmann 0 siblings, 0 replies; 50+ messages in thread From: Sven Eckelmann @ 2017-03-22 7:20 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz, Kalle Valo [-- Attachment #1.1: Type: text/plain, Size: 1367 bytes --] 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 [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant 2017-03-22 7:20 ` Sven Eckelmann (?) @ 2017-12-08 9:22 ` Kalle Valo -1 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-12-08 9:22 UTC (permalink / raw) To: Sven Eckelmann Cc: Rob Herring, Mark Rutland, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz SGksDQoNCmdldHRpbmcgYmFjayB0byB0aGlzIG9sZCB0aHJlYWQsIGhlcmUncyB0aGUgZGlzY3Vz c2lvbjoNCg0KaHR0cHM6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wYXRjaC85NjE1MTgzLw0KDQpo dHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3BhdGNoLzk2MTUxODUvDQoNClN2ZW4gRWNrZWxt YW5uIDxzdmVuLmVja2VsbWFubkBvcGVubWVzaC5jb20+IHdyaXRlczoNCg0KPiBPbiBEaWVuc3Rh ZywgMjEuIE3DpHJ6IDIwMTcgMjE6NTY6NTQgQ0VUIFJvYiBIZXJyaW5nIHdyb3RlOg0KPiBbLi4u XQ0KPj4gSXMgdGhpcyBhbHdheXMgdGhlIGNhc2U/IFRoZXJlJ3MgbmV2ZXIgc29tZSB2YXJpYXRp b24gYmV5b25kIHRoZQ0KPj4gcmVmZXJlbmNlIGRlc2lnbiB0aGF0IGEgQkRGIGRpZmZlcmVuY2Ug Y2FuJ3QgaGFuZGxlPw0KPg0KPiBJIGhhdmUgbm8ga25vd2xlZGdlIGFib3V0IGFueXRoaW5nIHdo aWNoIGlzbid0IGhhbmRsZWQgZGlyZWN0bHkgYnkgdGhlIEJERg0KPiB2YXJpYW50cy4gQnV0IG1h eWJlIEthbGxlIGNhbiBjb3JyZWN0IG1lIGhlcmUuDQoNCkN1cnJlbnRseSBJJ20gbm90IGF3YXJl IG9mIGFueSBleHRyYSBwcm9wZXJ0aWVzIHdoaWNoIHdlIHdvdWxkIG5lZWQgaW4NCmF0aDEwaywg aGF2aW5nIHRoZSBjdXN0b20gYm9hcmQgZmlsZSBzZWVtcyB0byBiZSB0aGUgb25seSByZXF1aXJl bWVudCBJDQpoYXZlIHNlZW4uDQoNCj4+ID4gVGhleSBhcmUgYmFzaWNhbGx5ICJxY29tLGlwcTQw MTktd2lmaSIgKyBhIHByb2R1Y3Qgc3BlY2lmaWMgc3RyaW5nLiBUaGUgZmlyc3QNCj4+ID4gcGFy dCBpcyB0aGVyZWZvcmUgdGhlIHN0cmluZyB3aGljaCBpZGVudGlmaWVzIHRoZSB3aWZpIGRldmlj ZShzKSBpbiB0aGUNCj4+ID4gUUNBNDAxOC80MDE5IFNvQy4gVGhlIHByb2R1Y3Qgc3BlY2lmaWMg c3RyaW5nIGlzIHNpbXBseSB0aGUgcGFydCAob3IgYQ0KPj4gPiB2YXJpYXRpb24gb2YgaXQpIHdo aWNoIHdvdWxkIGJlZW4gdXNlZCBiZWZvcmUgaW4NCj4+ID4gInFjb20sYXRoMTBrLWNhbGlicmF0 aW9uLXZhcmlhbnQiIC0ganVzdCB0byBtYWtlIGl0ICJ1c2UgYSBtb3JlIHNwZWNpZmljDQo+PiA+ IGNvbXBhdGlibGUgc3RyaW5nIi4NCj4+IA0KPj4gSXQgd291bGQgcHJvYmFibHkgYmUgbW9yZSBs aWtlOiAiYXN1cyxydC1hYzU4dS13aWZpIiwgInFjb20saXBxNDAxOS13aWZpIg0KPj4gDQo+PiBB IG1vcmUgc3BlY2lmaWMgY29tcGF0aWJsZSBpcyBpbnN1cmFuY2UgdGhhdCBhdCBzb21lIGxhdGVy IHBvaW50IGluDQo+PiB0aW1lIHlvdSBjYW4gZGlzdGluZ3Vpc2ggYmV0d2VlbiAyIGJvYXJkcyBk dWUgdG8gc29tZSBkaWZmZXJlbmNlIGV2ZW4NCj4+IGlmIG5vdyB5b3UgYmVsaWV2ZSB0aGV5IGFy ZSAidGhlIHNhbWUiLg0KPiBbLi4uXQ0KPj4gSSB0aGluayB0aGUgc2VwYXJhdGUgcHJvcGVydHkg aXMgZmluZSBpZiB0aGlzIGlzIHRoZSBvbmx5IG9uZSB5b3UNCj4+IGVudmlzaW9uIG5lZWRpbmcg dG8gYWRkLiBJZiB0aGVyZSdzIDEwIG1vcmUgcHJvcGVydGllcywgdGhlbiBJJ2QgZmVlbA0KPj4g bW9yZSBzdHJvbmdseSB0b3dhcmRzIGEgYm9hcmQgc3BlY2lmaWMgY29tcGF0aWJsZSBzdHJpbmcu DQo+DQo+IFRoYW5rIHlvdS4gTGV0J3Mgd2FpdCBhIGxpdHRsZSBiaXQgaW4gY2FzZSBzb21lb25l IGZyb20gUUNBL0NvZGVhdXJvcmENCj4gaGFzIHNvbWUgYWRkaXRpb25hbCBpbnB1dC4NCg0KSSBk aWRuJ3Qgc2VlIGFueSBjb21tZW50cyBmcm9tIGFueW9uZSBlbHNlIGFuZCBJIHRoaW5rIFN2ZW4n cyBhcHByb2FjaA0KaGVyZSBpcyB0aGUgYmVzdC4gU3ZlbiwgY2FuIHlvdSBzdWJtaXQgdjIgc28g dGhhdCB3ZSBnZXQgYW4gYWNrIGZyb20NCmRldmljZSB0cmVlIG1haW50YWluZXJzIGFuZCBJIGNh biBhcHBseSB0aGVzZT8NCg0KLS0gDQpLYWxsZSBWYWxv ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-12-08 9:22 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-12-08 9:22 UTC (permalink / raw) To: Sven Eckelmann Cc: Mark Rutland, Rob Herring, devicetree, linux-wireless, ath10k, ext.waldemar.rymarkiewicz 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant @ 2017-12-08 9:22 ` Kalle Valo 0 siblings, 0 replies; 50+ messages in thread From: Kalle Valo @ 2017-12-08 9:22 UTC (permalink / raw) To: Sven Eckelmann Cc: Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-wireless, ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, ext.waldemar.rymarkiewicz-++hxYGjEMp0AvxtiuMwx3w 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2018-10-08 8:21 UTC | newest] Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-10 8:06 [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant Sven Eckelmann 2017-03-10 8:06 ` Sven Eckelmann 2017-03-10 8:06 ` Sven Eckelmann 2017-03-10 8:06 ` [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant Sven Eckelmann 2017-03-10 8:06 ` Sven Eckelmann 2017-03-10 8:06 ` Sven Eckelmann 2017-03-10 18:20 ` Christian Lamparter 2017-03-10 18:20 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Christian Lamparter 2017-03-15 8:04 ` [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant Sven Eckelmann 2017-03-15 8:04 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Sven Eckelmann 2017-08-21 7:11 ` [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant Sven Eckelmann 2017-08-21 7:11 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Sven Eckelmann 2017-10-27 9:34 ` Kalle Valo 2017-10-27 9:34 ` Kalle Valo 2017-12-08 9:50 ` Kalle Valo 2017-12-08 9:50 ` Kalle Valo 2018-01-29 20:09 ` Asus RT-AC58U boardfile (was Re: [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant) Christian Lamparter 2018-01-29 20:09 ` Christian Lamparter 2018-10-08 8:21 ` Kalle Valo 2018-10-08 8:21 ` Kalle Valo 2018-04-19 14:56 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Kalle Valo 2018-04-19 14:56 ` Kalle Valo 2018-04-20 19:50 ` Christian Lamparter 2018-04-20 19:50 ` Christian Lamparter 2017-12-08 9:27 ` [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant Kalle Valo 2017-12-08 9:27 ` [PATCH 2/2] ath10k: search DT for qcom, ath10k-calibration-variant Kalle Valo 2017-12-08 9:27 ` [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant Kalle Valo 2017-03-20 15:07 ` [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant Rob Herring 2017-03-20 15:07 ` Rob Herring 2017-03-20 15:07 ` Rob Herring 2017-03-20 16:28 ` Sven Eckelmann 2017-03-20 16:28 ` Sven Eckelmann 2017-03-20 16:28 ` Sven Eckelmann 2017-03-20 16:42 ` Adrian Chadd 2017-03-20 16:42 ` Adrian Chadd 2017-03-21 7:29 ` Sven Eckelmann 2017-03-21 7:29 ` Sven Eckelmann 2017-03-21 13:00 ` Rob Herring 2017-03-21 13:00 ` Rob Herring 2017-03-21 13:00 ` Rob Herring 2017-03-21 14:33 ` Sven Eckelmann 2017-03-21 14:33 ` Sven Eckelmann 2017-03-21 14:33 ` Sven Eckelmann 2017-03-22 2:56 ` Rob Herring 2017-03-22 2:56 ` Rob Herring 2017-03-22 7:20 ` Sven Eckelmann 2017-03-22 7:20 ` Sven Eckelmann 2017-12-08 9:22 ` Kalle Valo 2017-12-08 9:22 ` Kalle Valo 2017-12-08 9:22 ` Kalle Valo
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.