On 2025/2/21 21:14, Sumit Gupta wrote: > > > On 19/02/25 00:53, Rafael J. Wysocki wrote: >> >> There seems to be some quite fundamental disagreement on how this >> should be done, so I'm afraid I cannot do much about it ATM. >> >> Please agree on a common approach and come back to me when you are ready. >> >> Sending two concurrent patchsets under confusingly similar names again >> and again isn't particularly helpful. >> >> Thanks! > > Hi Rafael, > > Thank you for looking into this. > > Hi Lifeng, > > As per the discussion, we can make the driver future extensible and > also can optimize the register read/write access. > > I gave some thought and below is my proposal. > > 1) Pick 'Patch 1-7' from your patch series [1] which optimize API's > to read/write a cpc register. 'patch 1-7' in [1] doesn't conflicts with [2], so can be reviewed and applied separately. I would follow this up in that series. > > 2) Pick my patches in [2]: > - Patch 1-4: Keep all cpc registers together under acpi_cppc sysfs. > Also, update existing API's to read/write regs in batch. > - Patch 5: Creates 'cppc_cpufreq_epp_driver' instance for booting > all CPU's in Auto mode and set registers with right values. > They can be updated after boot from sysfs to change hints to HW. > I can use the optimized API's from [1] where required in [2]. > > Let me know if you are okay with this proposal. > I can also send an updated patch series with all the patches combined? As mentioned above, 'patch 1-7' in [1] can be reviewed and applied separately. No need to be combined with other patches. About how to support auto selection mode in cppc_cpufreq, I think we need to sort out usecases, scenarios, and requirements from both of us before we disscus and agree on a design to implement. I am currently working on it and will sent out my thoughts later. Regards, Lifeng > > [1] https://lore.kernel.org/all/20250206131428.3261578-1-zhenglifeng1@xxxxxxxxxx/ > [2] https://lore.kernel.org/lkml/20250211103737.447704-1-sumitg@xxxxxxxxxx/ > > Regards, > Sumit Gupta >
