Hi, On Mon, Jan 9, 2023 at 8:21 PM Rajendra Nayak <quic_rjendra@xxxxxxxxxxx> wrote: > > > On 1/10/2023 3:12 AM, Doug Anderson wrote: > > Hi, > > > > On Mon, Jan 9, 2023 at 1:36 PM Dmitry Baryshkov > > <dmitry.baryshkov@xxxxxxxxxx> wrote: > >> > >> On 09/01/2023 23:00, Doug Anderson wrote: > >>> Hi, > >>> > >>> On Tue, Dec 20, 2022 at 9:12 AM Dmitry Baryshkov > >>> <dmitry.baryshkov@xxxxxxxxxx> wrote: > >>>> > >>>> On 20/12/2022 18:20, Rajendra Nayak wrote: > >>>>> > >>>>> > >>>>> On 12/20/2022 8:00 PM, Matthias Kaehlcke wrote: > >>>>>> On Tue, Dec 20, 2022 at 10:30:32AM +0530, Rajendra Nayak wrote: > >>>>>>> > >>>>>>> On 12/16/2022 7:49 PM, Matthias Kaehlcke wrote: > >>>>>>>> On Fri, Dec 16, 2022 at 04:59:17PM +0530, Rajendra Nayak wrote: > >>>>>>>>> Add compatibles for the Pro SKU of the sc7280 CRD boards > >>>>>>>>> which come with a Pro variant of the qcard. > >>>>>>>>> The Pro qcard variant has smps9 from pm8350c ganged up with > >>>>>>>>> smps7 and smps8. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Rajendra Nayak <quic_rjendra@xxxxxxxxxxx> > >>>>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > >>>>>>>>> Reviewed-by: Matthias Kaehlcke <mka@xxxxxxxxxxxx> > >>>>>>>>> --- > >>>>>>>>> v4 changes: > >>>>>>>>> Added the zoglin-sku1536 compatible along with hoglin-sku1536. > >>>>>>>>> Zoglin is same as the Hoglin variant, with the SPI Flash reduced > >>>>>>>>> from 64MB to 8MB > >>>>>>>>> > >>>>>>>>> Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++ > >>>>>>>>> 1 file changed, 6 insertions(+) > >>>>>>>>> > >>>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml > >>>>>>>>> b/Documentation/devicetree/bindings/arm/qcom.yaml > >>>>>>>>> index 1b5ac6b02bc5..07771d4c91bd 100644 > >>>>>>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml > >>>>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > >>>>>>>>> @@ -558,6 +558,12 @@ properties: > >>>>>>>>> - const: google,hoglin > >>>>>>>>> - const: qcom,sc7280 > >>>>>>>>> + - description: Qualcomm Technologies, Inc. sc7280 CRD Pro > >>>>>>>>> platform (newest rev) > >>>>>>>>> + items: > >>>>>>>>> + - const: google,zoglin-sku1536 > >>>>>>>>> + - const: google,hoglin-sku1536 > >>>>>>>> > >>>>>>>> Is there actually such a thing as a 'hoglin-sku1536', i.e. the Pro > >>>>>>>> qcard > >>>>>>>> with 64MB of SPI flash, or do they all have 8MB of flash? > >>>>>>> > >>>>>>> The SPI flash is on the CRD mother-board and not on the qcards, so if > >>>>>>> you replace > >>>>>>> the qcards on the CRDs with 64MB flash you would need the > >>>>>>> hoglin-sku1536 to > >>>>>>> boot on those. > >>>>>> > >>>>>> With such a configuration how does the bootloader know it should pass > >>>>>> the kernel > >>>>>> the device tree for 'hoglin-sku1536' (pro) and not the non-pro > >>>>>> variant? IIUC the > >>>>>> device tree is selected based on pin strappings on the mother-board, > >>>>>> not the > >>>>>> qcard. > >>>>> > >>>>> The device tree is selected based on the pin strappings _and_ additional > >>>>> logic > >>>>> to dynamically identify modem/non-modem(wifi) as well as pro/non-pro > >>>>> SKUs which > >>>>> was added in the bootloaders. > >>>> > >>>> Just to clarify things, when you mention pro SKU, is it a separate SoC > >>>> revision (like sc7280-pro vs bare sc7280), or is it a CRD revision (CRD > >>>> Pro vs bare CRD)? > >>> > >>> I guess Rajendra never responded, but since I know the answer: it's a > > Thanks Doug for the clarifications, I seem to have missed responding to this > once I was back from vacation, > > >>> different SoC revision. ...but the SoC in this case is on a daughter > >>> card, so you could remove the daughter card containing the SoC and put > >>> a new daughtercard on. That would have the effect of making an old CRD > >>> revision have the new Pro SKU SoC. > >> > >> So, this is a new SoC. Is it 100% compatible with the sc7280? In other > >> words: does it require any additional customizations (in OPP tables, in > >> frequences, speed bins, etc)? > > Yes, the OPP differences are taken care of with no changes needed in kernel. > We describe a superset of *all* OPPs supported by a SoC family in DT and the > cpufreq driver then queries the firmware for supported OPPs on a given > SoC variant and ends up disabling the rest. I saw that Bjorn just send out a pull request but it didn't include this patch. Bjorn: are you expecting anything from Rajendra here, or did it just get missed? I think Rajendra responded to all of Dmitry's comments, but I could be mistaken. -Doug
