On 29/10/2024 03:00, Ming-Jen Chen wrote: >>>>>>> + >>>>>>> + per-scale: >>>>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>>>> + description: Row Scan Cycle Pre-scale Value (1 to 256). >>>>>> Missing constraints >>>>>> >>>>>>> + >>>>>>> + per-scalediv: >>>>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>>>> + description: Per-scale divider (1 to 256). >>>>>> Missing constraints >>>>>> >>>>>> Both properties are unexpected... aren't you duplicating existing >>>>>> properties? >>>>> pre-scale: >>>>> This value configures the IC register for the row scan cycle >>>>> pre-scaling, with valid values ranging from 1 to 256 >>>>> per-scalediv:(I will change pre-scalediv to pre-scale-div) >>>> Please look for matching existing properties first. >>> I will change it to the following content: >>> >>> nuvoton,scan-time: >> Why? What about my request? > > I utilized|grep| to search for relevant properties in the|input/| folder using keywords such as|scan|,|time|,|period|,|freq|, and|interval|. > While I found some similar properties, I did not locate any that completely meet my requirements. > > For example, I found|"scanning_period"|, which is described as "Time between scans. Each step is 1024 us. Valid 1-256." > I would like to confirm if you are suggesting that I use|scanning_period| and explain my specific use case in the description, > for example: Description of these properties did not tell me much about their purpose and underlying hardware, so I don't know which fits here. It looks like you want to configure clock... but then wording confuses me - "per-scale". What is "per"? Isn't it usually "pre"? So in general I don't know what to recommend you because your patch is really unclear. Please also wrap emails according to mailing lists standards. And use proper line separation of sentences. It's really hard to understand your email. > > nuvoton,scanning-period: > type: uint32 > description: | Set the scan time for each key, specified in terms of keypad IP clock > cycles. The valid range is from 1 to 256. minimum: 1 > maximum: 256 Could you please confirm if this approach aligns with your suggestion, > or if you have any other recommended existing properties? Why this would be board dependent? Best regards, Krzysztof
