Several Qualcomm projects will use the same Bluetooth chip, each
focusing on different features. For instance, consumer projects
prioritize the A2DP SRC feature, while IoT projects focus on the A2DP
SINK feature, which may have more optimizations for coexistence when
acting as a SINK. Due to the patch size, it is not feasible to include
all features in a single firmware.
Therefore, the 'product-variant' devicetree property is used to provide
product information for the Bluetooth driver to load the appropriate
firmware.
If this property is not defined, the default firmware will be loaded,
ensuring there are no backward compatibility issues with older
devicetrees.
The product-variant defines like this:
0 - 15 (16 bits) are product line specific definitions
16 - 23 (8 bits) are for the product line.
24 - 31 (8 bits) are reserved for future use, 0 currently
|---------------------------------------------------------------------|
| 32 Bits |
|---------------------------------------------------------------------|
| 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) |
|---------------------------------------------------------------------|
| Reserved | 0: default | 0: default |
| | 1: CE | |
| | 2: IoT | |
| | 3: Auto | |
| | 4: Reserved | |
|---------------------------------------------------------------------|
Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com>
---
.../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
index 7bb68311c609..9019fe7bcdc6 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
@@ -110,6 +110,12 @@ properties:
description:
boot firmware is incorrectly passing the address in big-endian order
+ qcom,product-variant:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ specify the product information for driver to load the appropriate firmware
+
+
required:
- compatible
--
2.25.1On 20.11.2024 10:54 AM, Cheng Jiang wrote: > Several Qualcomm projects will use the same Bluetooth chip, each > focusing on different features. For instance, consumer projects > prioritize the A2DP SRC feature, while IoT projects focus on the A2DP > SINK feature, which may have more optimizations for coexistence when > acting as a SINK. Due to the patch size, it is not feasible to include > all features in a single firmware. > > Therefore, the 'product-variant' devicetree property is used to provide > product information for the Bluetooth driver to load the appropriate > firmware. > > If this property is not defined, the default firmware will be loaded, > ensuring there are no backward compatibility issues with older > devicetrees. > > The product-variant defines like this: > 0 - 15 (16 bits) are product line specific definitions > 16 - 23 (8 bits) are for the product line. Product lines don't exist in the kernel. Please describe the actual differences between those files instead. Konrad
On 22.11.2024 1:49 PM, Konrad Dybcio wrote: > On 20.11.2024 10:54 AM, Cheng Jiang wrote: >> Several Qualcomm projects will use the same Bluetooth chip, each >> focusing on different features. For instance, consumer projects >> prioritize the A2DP SRC feature, while IoT projects focus on the A2DP >> SINK feature, which may have more optimizations for coexistence when >> acting as a SINK. Due to the patch size, it is not feasible to include >> all features in a single firmware. >> >> Therefore, the 'product-variant' devicetree property is used to provide >> product information for the Bluetooth driver to load the appropriate >> firmware. >> >> If this property is not defined, the default firmware will be loaded, >> ensuring there are no backward compatibility issues with older >> devicetrees. >> >> The product-variant defines like this: >> 0 - 15 (16 bits) are product line specific definitions >> 16 - 23 (8 bits) are for the product line. > > Product lines don't exist in the kernel. Please describe the actual > differences between those files instead. Ok, so it seems to be feature set. This definitely should be userspace-toggleable. We can always reset the device and reload firmware at runtime, so I see no point in having to educate the kernel about this. I'd say A2DP SRC is probably preferred to be the deafult, as we have people running bare upstream on laptops and other consumer devices. Konrad
On 20/11/2024 10:54, Cheng Jiang wrote: > Several Qualcomm projects will use the same Bluetooth chip, each > focusing on different features. For instance, consumer projects > prioritize the A2DP SRC feature, while IoT projects focus on the A2DP > SINK feature, which may have more optimizations for coexistence when > acting as a SINK. Due to the patch size, it is not feasible to include > all features in a single firmware. > > Therefore, the 'product-variant' devicetree property is used to provide > product information for the Bluetooth driver to load the appropriate > firmware. > > If this property is not defined, the default firmware will be loaded, > ensuring there are no backward compatibility issues with older > devicetrees. > > The product-variant defines like this: > 0 - 15 (16 bits) are product line specific definitions > 16 - 23 (8 bits) are for the product line. > 24 - 31 (8 bits) are reserved for future use, 0 currently > > |---------------------------------------------------------------------| > | 32 Bits | > |---------------------------------------------------------------------| > | 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) | > |---------------------------------------------------------------------| > | Reserved | 0: default | 0: default | > | | 1: CE | | > | | 2: IoT | | > | | 3: Auto | | > | | 4: Reserved | | > |---------------------------------------------------------------------| > > Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> > --- > .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > index 7bb68311c609..9019fe7bcdc6 100644 > --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > @@ -110,6 +110,12 @@ properties: > description: > boot firmware is incorrectly passing the address in big-endian order > > + qcom,product-variant: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + specify the product information for driver to load the appropriate firmware Nah, you have firmware-name for this. > + > + No clue why two blank lines... Best regards, Krzysztof
Hi Krzysztof, On 11/21/2024 12:47 AM, Krzysztof Kozlowski wrote: > On 20/11/2024 10:54, Cheng Jiang wrote: >> Several Qualcomm projects will use the same Bluetooth chip, each >> focusing on different features. For instance, consumer projects >> prioritize the A2DP SRC feature, while IoT projects focus on the A2DP >> SINK feature, which may have more optimizations for coexistence when >> acting as a SINK. Due to the patch size, it is not feasible to include >> all features in a single firmware. >> >> Therefore, the 'product-variant' devicetree property is used to provide >> product information for the Bluetooth driver to load the appropriate >> firmware. >> >> If this property is not defined, the default firmware will be loaded, >> ensuring there are no backward compatibility issues with older >> devicetrees. >> >> The product-variant defines like this: >> 0 - 15 (16 bits) are product line specific definitions >> 16 - 23 (8 bits) are for the product line. >> 24 - 31 (8 bits) are reserved for future use, 0 currently >> >> |---------------------------------------------------------------------| >> | 32 Bits | >> |---------------------------------------------------------------------| >> | 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) | >> |---------------------------------------------------------------------| >> | Reserved | 0: default | 0: default | >> | | 1: CE | | >> | | 2: IoT | | >> | | 3: Auto | | >> | | 4: Reserved | | >> |---------------------------------------------------------------------| >> >> Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> >> --- >> .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> index 7bb68311c609..9019fe7bcdc6 100644 >> --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> @@ -110,6 +110,12 @@ properties: >> description: >> boot firmware is incorrectly passing the address in big-endian order >> >> + qcom,product-variant: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + specify the product information for driver to load the appropriate firmware > > Nah, you have firmware-name for this. > Currently "firmware-name" is used to specifythe nvm (config) file only, we also need to specify the rampatch file (TLV). Can we re-use the "firmware-name"? add two segments like the following? firmware-name = "rampatch_xx.tlv", "nvm_xx.bin"; Or add a new property to specify the rampatch file? rampatch-name = "rampatch_xx.tlv"; Thanks! > >> + >> + > No clue why two blank lines... > > Best regards, > Krzysztof
On 21/11/2024 05:06, Cheng Jiang wrote: > Hi Krzysztof, > > On 11/21/2024 12:47 AM, Krzysztof Kozlowski wrote: >> On 20/11/2024 10:54, Cheng Jiang wrote: >>> Several Qualcomm projects will use the same Bluetooth chip, each >>> focusing on different features. For instance, consumer projects >>> prioritize the A2DP SRC feature, while IoT projects focus on the A2DP >>> SINK feature, which may have more optimizations for coexistence when >>> acting as a SINK. Due to the patch size, it is not feasible to include >>> all features in a single firmware. >>> >>> Therefore, the 'product-variant' devicetree property is used to provide >>> product information for the Bluetooth driver to load the appropriate >>> firmware. >>> >>> If this property is not defined, the default firmware will be loaded, >>> ensuring there are no backward compatibility issues with older >>> devicetrees. >>> >>> The product-variant defines like this: >>> 0 - 15 (16 bits) are product line specific definitions >>> 16 - 23 (8 bits) are for the product line. >>> 24 - 31 (8 bits) are reserved for future use, 0 currently >>> >>> |---------------------------------------------------------------------| >>> | 32 Bits | >>> |---------------------------------------------------------------------| >>> | 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) | >>> |---------------------------------------------------------------------| >>> | Reserved | 0: default | 0: default | >>> | | 1: CE | | >>> | | 2: IoT | | >>> | | 3: Auto | | >>> | | 4: Reserved | | >>> |---------------------------------------------------------------------| >>> >>> Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> >>> --- >>> .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>> index 7bb68311c609..9019fe7bcdc6 100644 >>> --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>> +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>> @@ -110,6 +110,12 @@ properties: >>> description: >>> boot firmware is incorrectly passing the address in big-endian order >>> >>> + qcom,product-variant: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: >>> + specify the product information for driver to load the appropriate firmware >> >> Nah, you have firmware-name for this. >> > Currently "firmware-name" is used to specifythe nvm (config) file only, > we also need to specify the rampatch file (TLV). > > Can we re-use the "firmware-name"? add two segments like the following? > firmware-name = "rampatch_xx.tlv", "nvm_xx.bin"; > > Or add a new property to specify the rampatch file? > rampatch-name = "rampatch_xx.tlv"; You can grow the property, it's a list. Order of items in the list must be fixed (specific), though. See other Qualcomm remoteproc PAS loaders which already use two entries. Best regards, Krzysztof
Hi Krzysztof, On 11/21/2024 3:49 PM, Krzysztof Kozlowski wrote: > On 21/11/2024 05:06, Cheng Jiang wrote: >> Hi Krzysztof, >> >> On 11/21/2024 12:47 AM, Krzysztof Kozlowski wrote: >>> On 20/11/2024 10:54, Cheng Jiang wrote: >>>> Several Qualcomm projects will use the same Bluetooth chip, each >>>> focusing on different features. For instance, consumer projects >>>> prioritize the A2DP SRC feature, while IoT projects focus on the A2DP >>>> SINK feature, which may have more optimizations for coexistence when >>>> acting as a SINK. Due to the patch size, it is not feasible to include >>>> all features in a single firmware. >>>> >>>> Therefore, the 'product-variant' devicetree property is used to provide >>>> product information for the Bluetooth driver to load the appropriate >>>> firmware. >>>> >>>> If this property is not defined, the default firmware will be loaded, >>>> ensuring there are no backward compatibility issues with older >>>> devicetrees. >>>> >>>> The product-variant defines like this: >>>> 0 - 15 (16 bits) are product line specific definitions >>>> 16 - 23 (8 bits) are for the product line. >>>> 24 - 31 (8 bits) are reserved for future use, 0 currently >>>> >>>> |---------------------------------------------------------------------| >>>> | 32 Bits | >>>> |---------------------------------------------------------------------| >>>> | 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) | >>>> |---------------------------------------------------------------------| >>>> | Reserved | 0: default | 0: default | >>>> | | 1: CE | | >>>> | | 2: IoT | | >>>> | | 3: Auto | | >>>> | | 4: Reserved | | >>>> |---------------------------------------------------------------------| >>>> >>>> Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> >>>> --- >>>> .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>>> index 7bb68311c609..9019fe7bcdc6 100644 >>>> --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>>> +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>>> @@ -110,6 +110,12 @@ properties: >>>> description: >>>> boot firmware is incorrectly passing the address in big-endian order >>>> >>>> + qcom,product-variant: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + specify the product information for driver to load the appropriate firmware >>> >>> Nah, you have firmware-name for this. >>> >> Currently "firmware-name" is used to specifythe nvm (config) file only, >> we also need to specify the rampatch file (TLV). >> >> Can we re-use the "firmware-name"? add two segments like the following? >> firmware-name = "rampatch_xx.tlv", "nvm_xx.bin"; >> >> Or add a new property to specify the rampatch file? >> rampatch-name = "rampatch_xx.tlv"; > You can grow the property, it's a list. Order of items in the list must > be fixed (specific), though. See other Qualcomm remoteproc PAS loaders > which already use two entries. Thank you for the guidance. I will follow it to submit a new change. > > Best regards, > Krzysztof
On Wed, Nov 20, 2024 at 05:54:25PM +0800, Cheng Jiang wrote: > Several Qualcomm projects will use the same Bluetooth chip, each > focusing on different features. For instance, consumer projects > prioritize the A2DP SRC feature, while IoT projects focus on the A2DP > SINK feature, which may have more optimizations for coexistence when > acting as a SINK. Due to the patch size, it is not feasible to include > all features in a single firmware. > > Therefore, the 'product-variant' devicetree property is used to provide > product information for the Bluetooth driver to load the appropriate > firmware. > > If this property is not defined, the default firmware will be loaded, > ensuring there are no backward compatibility issues with older > devicetrees. > > The product-variant defines like this: > 0 - 15 (16 bits) are product line specific definitions > 16 - 23 (8 bits) are for the product line. > 24 - 31 (8 bits) are reserved for future use, 0 currently Please use text strings instead of encoding this information into random integers and then using just 3 bits out of 32. > > |---------------------------------------------------------------------| > | 32 Bits | > |---------------------------------------------------------------------| > | 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) | > |---------------------------------------------------------------------| > | Reserved | 0: default | 0: default | > | | 1: CE | | > | | 2: IoT | | > | | 3: Auto | | > | | 4: Reserved | | > |---------------------------------------------------------------------| > > Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> > --- > .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > index 7bb68311c609..9019fe7bcdc6 100644 > --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > @@ -110,6 +110,12 @@ properties: > description: > boot firmware is incorrectly passing the address in big-endian order > > + qcom,product-variant: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + specify the product information for driver to load the appropriate firmware DT describes hardware. Is this a hardware property? > + > + > required: > - compatible > > -- > 2.25.1 > -- With best wishes Dmitry
Hi Dmitry, On 11/20/2024 6:43 PM, Dmitry Baryshkov wrote: > On Wed, Nov 20, 2024 at 05:54:25PM +0800, Cheng Jiang wrote: >> Several Qualcomm projects will use the same Bluetooth chip, each >> focusing on different features. For instance, consumer projects >> prioritize the A2DP SRC feature, while IoT projects focus on the A2DP >> SINK feature, which may have more optimizations for coexistence when >> acting as a SINK. Due to the patch size, it is not feasible to include >> all features in a single firmware. >> >> Therefore, the 'product-variant' devicetree property is used to provide >> product information for the Bluetooth driver to load the appropriate >> firmware. >> >> If this property is not defined, the default firmware will be loaded, >> ensuring there are no backward compatibility issues with older >> devicetrees. >> >> The product-variant defines like this: >> 0 - 15 (16 bits) are product line specific definitions >> 16 - 23 (8 bits) are for the product line. >> 24 - 31 (8 bits) are reserved for future use, 0 currently > > Please use text strings instead of encoding this information into random > integers and then using just 3 bits out of 32. Ack. Originally intended to make it more flexible for future use. It can be text strings for current requirement. > >> >> |---------------------------------------------------------------------| >> | 32 Bits | >> |---------------------------------------------------------------------| >> | 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) | >> |---------------------------------------------------------------------| >> | Reserved | 0: default | 0: default | >> | | 1: CE | | >> | | 2: IoT | | >> | | 3: Auto | | >> | | 4: Reserved | | >> |---------------------------------------------------------------------| >> >> Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> >> --- >> .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> index 7bb68311c609..9019fe7bcdc6 100644 >> --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> @@ -110,6 +110,12 @@ properties: >> description: >> boot firmware is incorrectly passing the address in big-endian order >> >> + qcom,product-variant: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + specify the product information for driver to load the appropriate firmware > > DT describes hardware. Is this a hardware property? It has been added to identify the firmware image for the platform. The driver parses it, and then the rampatch is selected from a specify directory. Currently, there is a 'firmware-name' parameter, but it is only used to specify the NVM (config) file. We also need to specify the rampatch (TLV file). Can we re-use the "firmware-name"? add two segments like the following? firmware-name = "rampatch_xx.tlv", "nvm_xx.bin"; Or add a new property to specify the rampatch file? rampatch-name = "rampatch_xx.tlv"; > >> + >> + >> required: >> - compatible >> >> -- >> 2.25.1 >> >
On Thu, 21 Nov 2024 at 06:02, Cheng Jiang <quic_chejiang@quicinc.com> wrote: > > Hi Dmitry, > > On 11/20/2024 6:43 PM, Dmitry Baryshkov wrote: > > On Wed, Nov 20, 2024 at 05:54:25PM +0800, Cheng Jiang wrote: > >> Several Qualcomm projects will use the same Bluetooth chip, each > >> focusing on different features. For instance, consumer projects > >> prioritize the A2DP SRC feature, while IoT projects focus on the A2DP > >> SINK feature, which may have more optimizations for coexistence when > >> acting as a SINK. Due to the patch size, it is not feasible to include > >> all features in a single firmware. > >> > >> Therefore, the 'product-variant' devicetree property is used to provide > >> product information for the Bluetooth driver to load the appropriate > >> firmware. > >> > >> If this property is not defined, the default firmware will be loaded, > >> ensuring there are no backward compatibility issues with older > >> devicetrees. > >> > >> The product-variant defines like this: > >> 0 - 15 (16 bits) are product line specific definitions > >> 16 - 23 (8 bits) are for the product line. > >> 24 - 31 (8 bits) are reserved for future use, 0 currently > > > > Please use text strings instead of encoding this information into random > > integers and then using just 3 bits out of 32. > Ack. Originally intended to make it more flexible for future use. It can be > text strings for current requirement. No, fixed-format data isn't flexible. Fine-grained properties are. Please define exactly what is necessary rather than leaving empty holes "for future expansion".= > > > >> > >> |---------------------------------------------------------------------| > >> | 32 Bits | > >> |---------------------------------------------------------------------| > >> | 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) | > >> |---------------------------------------------------------------------| > >> | Reserved | 0: default | 0: default | > >> | | 1: CE | | > >> | | 2: IoT | | > >> | | 3: Auto | | > >> | | 4: Reserved | | > >> |---------------------------------------------------------------------| > >> > >> Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> > >> --- > >> .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > >> index 7bb68311c609..9019fe7bcdc6 100644 > >> --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > >> +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > >> @@ -110,6 +110,12 @@ properties: > >> description: > >> boot firmware is incorrectly passing the address in big-endian order > >> > >> + qcom,product-variant: > >> + $ref: /schemas/types.yaml#/definitions/uint32 > >> + description: > >> + specify the product information for driver to load the appropriate firmware > > > > DT describes hardware. Is this a hardware property? > > It has been added to identify the firmware image for the platform. The driver > parses it, and then the rampatch is selected from a specify directory. Currently, > there is a 'firmware-name' parameter, but it is only used to specify the NVM > (config) file. We also need to specify the rampatch (TLV file). > > > Can we re-use the "firmware-name"? add two segments like the following? > firmware-name = "rampatch_xx.tlv", "nvm_xx.bin"; I think this is the better solution > > Or add a new property to specify the rampatch file? > rampatch-name = "rampatch_xx.tlv"; > > > > >> + > >> + > >> required: > >> - compatible > >> > >> -- > >> 2.25.1 > >> > > > -- With best wishes Dmitry
Hi Dmitry, On 11/21/2024 12:38 PM, Dmitry Baryshkov wrote: > On Thu, 21 Nov 2024 at 06:02, Cheng Jiang <quic_chejiang@quicinc.com> wrote: >> >> Hi Dmitry, >> >> On 11/20/2024 6:43 PM, Dmitry Baryshkov wrote: >>> On Wed, Nov 20, 2024 at 05:54:25PM +0800, Cheng Jiang wrote: >>>> Several Qualcomm projects will use the same Bluetooth chip, each >>>> focusing on different features. For instance, consumer projects >>>> prioritize the A2DP SRC feature, while IoT projects focus on the A2DP >>>> SINK feature, which may have more optimizations for coexistence when >>>> acting as a SINK. Due to the patch size, it is not feasible to include >>>> all features in a single firmware. >>>> >>>> Therefore, the 'product-variant' devicetree property is used to provide >>>> product information for the Bluetooth driver to load the appropriate >>>> firmware. >>>> >>>> If this property is not defined, the default firmware will be loaded, >>>> ensuring there are no backward compatibility issues with older >>>> devicetrees. >>>> >>>> The product-variant defines like this: >>>> 0 - 15 (16 bits) are product line specific definitions >>>> 16 - 23 (8 bits) are for the product line. >>>> 24 - 31 (8 bits) are reserved for future use, 0 currently >>> >>> Please use text strings instead of encoding this information into random >>> integers and then using just 3 bits out of 32. >> Ack. Originally intended to make it more flexible for future use. It can be >> text strings for current requirement. > > No, fixed-format data isn't flexible. Fine-grained properties are. > Please define exactly what is necessary rather than leaving empty > holes "for future expansion".= Got it. Thank you for the guidance. > >>> >>>> >>>> |---------------------------------------------------------------------| >>>> | 32 Bits | >>>> |---------------------------------------------------------------------| >>>> | 31 - 24 (bits) | 23 - 16 (bits) | 15 - 0 (16 bits) | >>>> |---------------------------------------------------------------------| >>>> | Reserved | 0: default | 0: default | >>>> | | 1: CE | | >>>> | | 2: IoT | | >>>> | | 3: Auto | | >>>> | | 4: Reserved | | >>>> |---------------------------------------------------------------------| >>>> >>>> Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> >>>> --- >>>> .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>>> index 7bb68311c609..9019fe7bcdc6 100644 >>>> --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>>> +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >>>> @@ -110,6 +110,12 @@ properties: >>>> description: >>>> boot firmware is incorrectly passing the address in big-endian order >>>> >>>> + qcom,product-variant: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + specify the product information for driver to load the appropriate firmware >>> >>> DT describes hardware. Is this a hardware property? >> >> It has been added to identify the firmware image for the platform. The driver >> parses it, and then the rampatch is selected from a specify directory. Currently, >> there is a 'firmware-name' parameter, but it is only used to specify the NVM >> (config) file. We also need to specify the rampatch (TLV file). >> >> >> Can we re-use the "firmware-name"? add two segments like the following? >> firmware-name = "rampatch_xx.tlv", "nvm_xx.bin"; > > I think this is the better solution Ack. Will submit a new change based on this. > >> >> Or add a new property to specify the rampatch file? >> rampatch-name = "rampatch_xx.tlv"; >> >>> >>>> + >>>> + >>>> required: >>>> - compatible >>>> >>>> -- >>>> 2.25.1 >>>> >>> >> > >
© 2016 - 2024 Red Hat, Inc.