From: Viresh Kumar <viresh.kumar@...> commit dd02a3d920083b6cb0ee4f0eaf2c599b740bf5fe upstream. OPP layer manages it now and cpufreq-dt driver doesn't need it. But, we still need to check for

From: Viresh Kumar <viresh.kumar@...> commit 896d6a4c0f41a93809b83f9e58aad73874a89d99 upstream. We have the device structure available now, lets use it for better

From: Viresh Kumar <viresh.kumar@...> commit 78c3ba5df96c875b1668e1cd3ee0a69e62454f32 upstream. OPP core supports frequency/voltage changes based on the target frequency now, use that instead

From: Viresh Kumar <viresh.kumar@...> commit 457e99e60a8f5a40b7da204c0bfc8a86ad2161b9 upstream. That's the real purpose of this field, i.e. to take special care of old OPP V1 bindings. Lets

From: Viresh Kumar <viresh.kumar@...> commit 755b888ff098c9f762717a9fbda7e05b16619069 upstream. OPP layer has all the information now to calculate transition latency (clock_latency +

From: Viresh Kumar <viresh.kumar@...> commit 391d9aef8145204e0a5d67be3bd1fc45c5396dae upstream. "clock-latency" is handled by OPP layer for all bindings and so there is no need to make

From: Viresh Kumar <viresh.kumar@...> commit 050794aaebbb9f2c2c50b340b6998273e7c64189 upstream. OPP core can handle the regulators by itself, and but it needs to know the name of the

From: Viresh Kumar <viresh.kumar@...> commit 6def6ea75e6dea45f01a16ae3cfb5b5ce48dd5e9 upstream. The core already have a valid regulator set for the device opp and the unsupported OPPs are

From: Viresh Kumar <viresh.kumar@...> commit d54974c2513f487e9e70fbdc79c5da51c53e23da upstream. OPP core has got almost everything now to manage device's OPP transitions, the only thing left

From: Viresh Kumar <viresh.kumar@...> commit 6a0712f6f199e737aa5913d28ec4bd3a25de9660 upstream. This adds a routine, dev_pm_opp_set_rate(), responsible for configuring power-supply and clock

From: Viresh Kumar <viresh.kumar@...> commit 50f8cfbd5897ca182d43f4caf19937153f17a604 uptream. V2 bindings have better support for clock-latency and voltage-tolerance and doesn't need special

Hi everyone, This is part 2 of MOXA's PM / OPP / cpufreq backport series. The whole series aims to backport patches related to PM / OPPv2 and cpufreq which were included in the v4.4 kernel from TI's

From: Viresh Kumar <viresh.kumar@...> commit 7d34d56ef3349cd5f29cf7aab6650f3414fa81b9 upstream. Disable any OPPs where the connected regulator isn't able to provide the specified

From: Viresh Kumar <viresh.kumar@...> commit 2174344765f472895c076d703c9cdc58215e1393 upstream. In few use cases (like: cpufreq), it is desired to get the maximum latency for changing OPPs.

From: Viresh Kumar <viresh.kumar@...> commit 9f8ea969d5cfdd4353d2adb004e8e2286b984369 upstream. This allows the OPP core to request/free the regulator resource, attached to a device OPP. The

From: Viresh Kumar <viresh.kumar@...> commit 655c9df961751ce21466f6e97e8033932c27a675 upstream. In few use cases (like: cpufreq), it is desired to get the maximum voltage latency for changing

All, Just wanted to document an issue as well as a/my workaround when using vagrant 2.2.8/2.2.9. After installing vagrant 2.0.2 using apt-get in Ubuntu 18.04, it complained that I had a too new

Hi Quirin, Thank you for the information. I've added the information to the following issue. https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/8 Thanks, Suzuki

Hi! Newest 4.19-rt kernel is currently v4.19.127-rt54. That's not good match for us, as -cip kernels are v4.19.128-cip28 and v4.19.130-cip29. I could do kernel based on v4.19.127-rt54 and

Hi, Chris-san, Sure, then see you at the CIP mini summit! Best regards, -- M. Kudo