On Tue, Dec 26, 2023 at 10:28:09AM +0100, Krzysztof Kozlowski wrote: > On 26/12/2023 08:25, Jie Luo wrote: > >>> + qcom,cmn-ref-clock-frequency: > >>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>> + enum: > >>> + - 25000000 > >>> + - 31250000 > >>> + - 40000000 > >>> + - 48000000 > >>> + - 50000000 > >>> + - 96000000 > >>> + default: 48000000 > >>> + description: | > >>> + The reference clock source of CMN PLL block is selectable, the > >>> + reference clock source can be from wifi module or the external > >>> + xtal, the reference clock frequency 48MHZ can be from internal > >>> + wifi or the external xtal, if absent, the internal 48MHZ is used, > >>> + if the 48MHZ is specified, which means the external 48Mhz is used. > >> > >> This does not resolve mine and Conor's concerns from previous version. > >> External clocks are defined as clock inputs. > > > > No matter the external or internal reference clock, they are the clock > > source selection for CMN, there are only 48MHZ can be external or > > internal, other clocks have the different clock rate, so the internal > > 48MHZ reference clock can be implied when the > > "qcom,cmn-ref-clock-frequency" is not defined, which is suggested by > > Conor in the previous > > comments. > > I don't think he proposed it, but maybe I missed some message (care to > point me to his message where he agreed on usage of > qcom,cmn-ref-clock-frequency?). I am pretty sure we both stayed on the > same page, that the presence of clocks defines choice of internal clock. > This property should go away. Exactly, I wanted this property to be removed. My suggestion was about defaulting to the internal clock when the "clocks" property did not contain the cmn ref clock. > It is tiring to keep discussing this. Yup.
Attachment:
signature.asc
Description: PGP signature
