On 16/04/19 5:18 PM, Adam Ford wrote: > On Tue, Apr 16, 2019 at 3:38 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: >> >> pon., 15 kwi 2019 o 12:21 Sekhar Nori <nsekhar@xxxxxx> napisał(a): >>> >>> On 12/04/19 9:01 PM, Bartosz Golaszewski wrote: >>>> pt., 12 kwi 2019 o 15:53 Sekhar Nori <nsekhar@xxxxxx> napisał(a): >>>>> >>>>> On 12/04/19 5:41 PM, Bartosz Golaszewski wrote: >>>>>> pt., 12 kwi 2019 o 13:26 Sekhar Nori <nsekhar@xxxxxx> napisał(a): >>>>>>> >>>>>>> Hi Bartosz, >>>>>>> >>>>>>> On 08/04/19 1:29 PM, Bartosz Golaszewski wrote: >>>>>>>> From: David Lechner <david@xxxxxxxxxxxxxx> >>>>>>>> >>>>>>>> This adds a cpu node and operating points to the common da850.dtsi file. >>>>>>>> >>>>>>>> Additionally, a regulator is added to the LEGO EV3 board along with >>>>>>>> some board-specific CPU configuration. >>>>>>>> >>>>>>>> Regulators need to be hooked up on other boards to get them working. >>>>>>>> >>>>>>>> Signed-off-by: David Lechner <david@xxxxxxxxxxxxxx> >>>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> >>>>>>> >>>>>>> I remember you mentioning about some problems using OCHI and cpufreq >>>>>>> together. Are those resolved now? CPU PLL on DA850 can affect other >>>>>>> peripheral clock frequencies too. So enabling it should really be a >>>>>>> per-board decision. >>>>>>> >>>>>> >>>>>> The problems are still there. I've never been able to find the >>>>>> culprit, but it also occurs on TI BSP in the same way (a couple >>>>>> cpufreq transitions will make the controller unresponsive). >>>>> >>>>> Is that on LCDK as well? As I recall cpufreq was never enabled on LCDK >>>>> in TI BSP. >>>>> >>>> >>>> Yes, I just verified that the bug occurs on LCDK with patches from this series. >>>> >>>>> If the OHCI problem is present on LCDK, then there is a user visible >>>>> regression on mainline after this patch. Lets enable cpufreq in LCDK >>>>> only if all working peripherals keep working afterwards. >>>>> >>>> >>>> The OHCI driver doesn't register any cpufreq transition notifier >>>> callbacks. I can't really find anything in the datasheet, but I'm >>>> wondering if we shouldn't do something similar to what the driver for >>>> davinci i2c controller does. I'll try a couple things tomorrow. >>> >>> Even if OHCI issue is fixed, with a fixed regulator like on LCDK, I am >>> not sure the benefits of just frequency scaling will be justifiable enough. >>> >>> Fixing the OHCI issue may help in other boards like da850-evm use it >>> though. So that will be a good thing. >>> >> >> I've been trying different things, like suspending the device before >> the transition, resetting the controller or playing with the clock >> during transitions but it always results in the same kind of error: >> >> ohci-da8xx 1e25000.usb: frame counter not updating; disabled >> ohci-da8xx 1e25000.usb: HC died; cleaning up >> usb 1-1: USB disconnect, device number 2 >> >> If you have any idea - let me know, otherwise I'll give up. >> >> If we agree on the direction of these patches, then I can go with a >> single enabled OPP for lcdk (456 MHz) and all OPPs up to 375 MHz >> enabled for da850-evm. > > One last questions, and this probably directed at Sekhar, but what > happens if you modify the OPP for the boards with fixed regulators to > enable all the frequencies but with the only available voltage. Is > there harm is running the processor at a higher voltage than > necessary? I did some quick experiments on a different ARM board and > I saw some changes in power consumption. I would think some power > savings might be better than none, but I don't know if it causes> damage. The OMAP-L138 datasheet mentions two versions of devices in core voltage specification: Variable (1.2V-1.0V) for 375 MHz version Variable (1.3V-1.0V) for 456 MHz version If you have 375 MHz version of device, I do not think you should run at 1.3V. I don't know what "damage" it will cause or how long it takes for any of it to be visible. Keeping that aside, I doubt there will be a lot of power-saving benefit without voltage scaling. Even if you see a slightly lower power number when you reduce frequency, there is also work to be done for the scaling operation itself. Thanks, Sekhar
