Re: [PATCH 0/5] PM: domains: Add helpers for multi PM domains to avoid open-coding

2024-01-01 Thread Viresh Kumar
On 28-12-23, 12:41, Ulf Hansson wrote: > For OPP integration, as a follow up I am striving to make the > dev_pm_opp_attach_genpd() redundant. Instead I think we should move towards > using dev_pm_opp_set_config()->_opp_set_required_devs(), which would allow us > to > use the helpers that $subject

Re: [PATCH v2 3/5] thermal/cpufreq: Remove arch_update_thermal_pressure()

2023-12-25 Thread Viresh Kumar
mum freq_qos pressure on the capacity to the > scheduler, which includes cpufreq cooling device. Remove the call to > arch_update_thermal_pressure() in cpufreq cooling device as this is > handled by cpufreq_get_pressure(). > > Signed-off-by: Vincent Guittot > Reviewed-by: Lukasz

Re: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the scheduler

2023-12-13 Thread Viresh Kumar
On 12-12-23, 15:27, Vincent Guittot wrote: > @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy > *policy, > policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H); > trace_cpu_frequency_limits(policy); > > + cpus = policy->related_cpus; > +

Re: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the scheduler

2023-12-13 Thread Viresh Kumar
On 13-12-23, 16:41, Tim Chen wrote: > Seems like the pressure value computed from the first CPU applies to all CPU. > Will this be valid for non-homogeneous CPUs that could have different > max_freq and max_capacity? The will be part of different cpufreq policies and so it will work fine. --

Re: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the scheduler

2023-12-12 Thread Viresh Kumar
On 12-12-23, 15:27, Vincent Guittot wrote: > Provide to the scheduler a feedback about the temporary max available > capacity. Unlike arch_update_thermal_pressure, this doesn't need to be > filtered as the pressure will happen for dozens ms or more. > > Signed-off-by: Vincent Guittot > --- >

Re: [PATCH v4 5/7] cpufreq: qcom-hw: Implement CPRh aware OSM programming

2021-04-19 Thread Viresh Kumar
On 19-04-21, 13:52, Bjorn Andersson wrote: > On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote: > @Viresh, do you have any suggestion regarding my last comment? > > static int qcom_cpufreq_hw_driver_probe(struct platform_device *pdev) > > { > > + const struct

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-04-15 Thread Viresh Kumar
On 15-04-21, 09:28, Wolfram Sang wrote: > > > Now that we were able to catch you, I will use the opportunity to > > clarify the doubts I had. > > > > - struct mutex lock in struct virtio_i2c, I don't think this is > > required since the core takes care of locking in absence of this. > > This

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-04-15 Thread Viresh Kumar
On 15-04-21, 09:21, Wolfram Sang wrote: > > > I didn't forget this. It is a very small change. I'm not sure if the > > maintainer Wolfram > > > > has any comments so that I can address them together in one version. > > Noted. I'll have a look in the next days. Now that we were able to catch

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-04-15 Thread Viresh Kumar
On 15-04-21, 14:56, Jie Deng wrote: > > On 2021/4/15 14:45, Viresh Kumar wrote: > > On 23-03-21, 10:27, Arnd Bergmann wrote: > > > I usually recommend the use of __maybe_unused for the suspend/resume > > > callbacks for drivers that use SIMPLE_DEV_PM_OPS() or s

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-04-15 Thread Viresh Kumar
On 23-03-21, 10:27, Arnd Bergmann wrote: > I usually recommend the use of __maybe_unused for the suspend/resume > callbacks for drivers that use SIMPLE_DEV_PM_OPS() or similar helpers > that hide the exact conditions under which the functions get called. > > In this driver, there is an explicit

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-04-13 Thread Viresh Kumar
On 14-04-21, 10:07, Jie Deng wrote: > Hi maintainers, > > What's the status of this patch based on the review comments you got ? I was expecting a new version to be honest.. > Is i2c/for-next the right tree to merge it > ? It should be. -- viresh

Re: [PATCH v4 5/7] cpufreq: qcom-hw: Implement CPRh aware OSM programming

2021-04-12 Thread Viresh Kumar
On 12-04-21, 15:01, Taniya Das wrote: > Technically the HW we are trying to program here differs in terms of > clocking, the LUT definitions and many more. It will definitely make > debugging much more troublesome if we try to accomodate multiple versions of > CPUFREQ-HW in the same code. > >

Re: [PATCH v4 0/7] cpufreq-qcom-hw: Implement full OSM programming

2021-04-11 Thread Viresh Kumar
On 19-01-21, 18:45, AngeloGioacchino Del Regno wrote: > ** > ** NOTE: To "view the full picture", please look at the following > ** patch series: > ** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355 > ** This is a subset of that series. > ** > >

Re: [PATCH -next] ARM: spear: Fix build error with CONFIG_ARCH_SPEAR3XX

2021-04-08 Thread Viresh Kumar
On 09-04-21, 09:55, Chen Lifu wrote: > commit 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core") > deleted 'struct pl022_ssp_controller' member 'num_chipselect'. > We get build error when CONFIG_ARCH_SPEAR3XX is set: > arch/arm/mach-spear/spear3xx.c:42:3: error: 'struct

Re: [RFC PATCH v2 10/10] firmware: arm_scmi: Add virtio transport

2021-04-07 Thread Viresh Kumar
On Fri, Nov 6, 2020 at 2:59 AM Peter Hilber wrote: > +static int scmi_vio_probe(struct virtio_device *vdev) > +{ > + struct device *dev = >dev; > + struct scmi_vio_channel **vioch; > + bool have_vq_rx; > + int vq_cnt; > + int i; > + struct virtqueue

Re: [PATCH V8 2/8] cpufreq: mediatek: Enable clock and regulator

2021-03-31 Thread Viresh Kumar
On 31-03-21, 13:21, andrew-sh.cheng wrote: > Hi Viresh, > Yes. > As you mentioned, it will be enable by OPP core. > > Per discuss with hotplug owner and regulator owner, > they suggest that "users should not suppose other module, will enable > regulators for them". > They suggest to add

Re: [PATCH V8 2/8] cpufreq: mediatek: Enable clock and regulator

2021-03-29 Thread Viresh Kumar
On 23-03-21, 19:33, Andrew-sh.Cheng wrote: > From: "Andrew-sh.Cheng" > > Need to enable regulator, > so that the max/min requested value will be recorded > even it is not applied right away. > > Intermediate clock is not always enabled by ccf in different projects, > so cpufreq should enable it

Re: [PATCH 2/2] dt-bindings: cpufreq: update cpu type and clock name for MT8173 SoC

2021-03-25 Thread Viresh Kumar
> - compatible = "arm,cortex-a57"; > + compatible = "arm,cortex-a72"; > reg = <0x101>; > enable-method = "psci"; > cpu-idle-states = <_SLEEP_0>; > - clocks = < CLK_INFRA_CA57SEL>, > + clocks = < CLK_INFRA_CA72SEL>, >< CLK_APMIXED_MAINPLL>; > clock-names = "cpu", "intermediate"; > operating-points-v2 = <_opp_table_b>; Acked-by: Viresh Kumar -- viresh

Re: [PATCH] staging: greybus: fix fw is NULL but dereferenced

2021-03-25 Thread Viresh Kumar
On 25-03-21, 18:19, Jian Dong wrote: > From: Jian Dong > > fixes coccicheck Error: > > drivers/staging/greybus/bootrom.c:301:41-45: ERROR: > fw is NULL but dereferenced. > > if procedure goto label directly, ret will be nefative, so the fw is NULL > and the if(condition) end with

Re: linux-next: manual merge of the opp tree with the v4l-dvb tree

2021-03-25 Thread Viresh Kumar
On 25-03-21, 10:14, Stanimir Varbanov wrote: > I guess you meant this thread. > > https://lore.kernel.org/lkml/20210314163408.22292-1-dig...@gmail.com/ I actually thought some other stuff is having the merge issues (as I was expecting something to happen there) :) Anyway, you did the right

Re: [PATCH v3 14/15] media: venus: Convert to use resource-managed OPP API

2021-03-25 Thread Viresh Kumar
On 25-03-21, 10:13, Stanimir Varbanov wrote: > Hi, > > On 3/14/21 6:34 PM, Dmitry Osipenko wrote: > > From: Yangtao Li > > > > Use resource-managed OPP API to simplify code. > > > > Signed-off-by: Yangtao Li > > Signed-off-by: Dmitry Osipenko > > --- > >

Re: [V2][PATCH] cpufreq: dt: check the -EPROBE_DEFER error returned by dev_pm_opp_of_cpumask_add_table

2021-03-25 Thread Viresh Kumar
ion dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER, which needs to be propagated to the caller to try probing the driver later on. Signed-off-by: Quanyang Wang [ Viresh: Massage changelog/subject, improve code. ] Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq-dt.c

Re: [PATCH] cpufreq: dt: check the error returned by dev_pm_opp_of_cpumask_add_table

2021-03-24 Thread Viresh Kumar
On 25-03-21, 13:15, quanyang.wang wrote: > Thank you for pointing it out.  Do you mean that even if > dev_pm_opp_of_cpumask_add_table returns > > an error, dev_pm_opp_get_opp_count may still return count > 0 because > someone may call dev_pm_opp_add > > to add OPP to cpu succcessfully at

Re: [PATCH] cpufreq: dt: check the error returned by dev_pm_opp_of_cpumask_add_table

2021-03-24 Thread Viresh Kumar
On 25-03-21, 12:31, quanyang.w...@windriver.com wrote: > From: Quanyang Wang > > The function dev_pm_opp_of_cpumask_add_table may return zero or an > error. When it returns an error, this means that no OPP table is > added for the cpumask because _dev_pm_opp_cpumask_remove_table is > called to

[PATCH V4] kbuild: Add rule to build .dt.yaml files for overlays

2021-03-24 Thread Viresh Kumar
The overlay source files are named with .dtso extension now, add a new rule to generate .dt.yaml for them. Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Viresh Kumar --- V4: - Rebase over Frank's cleanup patch: https://lore.kernel.org/lkml

Re: linux-next: manual merge of the opp tree with the v4l-dvb tree

2021-03-24 Thread Viresh Kumar
On 24-03-21, 16:49, Stanimir Varbanov wrote: > Thanks Stephen! > > On 3/23/21 2:27 AM, Stephen Rothwell wrote: > > Hi all, > > > > Today's linux-next merge of the opp tree got a conflict in: > > > > drivers/media/platform/qcom/venus/pm_helpers.c > > > > between commit: > > > >

Re: [PATCH v2 1/1] dmaengine: dw: Make it dependent to HAS_IOMEM

2021-03-24 Thread Viresh Kumar
ignWare AHB DMA controller. This > @@ -18,6 +19,7 @@ config DW_DMAC > config DW_DMAC_PCI > tristate "Synopsys DesignWare AHB DMA PCI driver" > depends on PCI > + depends on HAS_IOMEM > select DW_DMAC_CORE > help > Support the Synopsys DesignWare AHB DMA controller on the Acked-by: Viresh Kumar -- viresh

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-24 Thread Viresh Kumar
On 24-03-21, 14:41, Jie Deng wrote: > > On 2021/3/24 14:09, Viresh Kumar wrote: > > On 24-03-21, 14:05, Jie Deng wrote: > > Or, now that I think about it a bit more, another thing we can do here is > > see if > > virtqueue_get_buf() returns NULL, if it does

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-24 Thread Viresh Kumar
On 24-03-21, 14:05, Jie Deng wrote: > For simplicity, the original patch sent only 1 message to vq each time . I > changed the way to send I missed those earlier discussions :) > a batch of requests in one time in order to improve efficiency according to > Jason' suggestion. I agree. > As we

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-23 Thread Viresh Kumar
On 23-03-21, 22:19, Jie Deng wrote: > +static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, > int num) > +{ > + struct virtio_i2c *vi = i2c_get_adapdata(adap); > + struct virtqueue *vq = vi->vq; > + struct virtio_i2c_req *reqs; > + unsigned long time_left; >

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-23 Thread Viresh Kumar
On 24-03-21, 12:00, Jie Deng wrote: > > On 2021/3/24 11:52, Viresh Kumar wrote: > > On 24-03-21, 08:53, Jie Deng wrote: > > > On 2021/3/23 17:38, Viresh Kumar wrote: > > > > On 23-03-21, 14:31, Viresh Kumar wrote: > > > > > On 23-03-21

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-23 Thread Viresh Kumar
On 24-03-21, 09:17, Jie Deng wrote: > I didn't see the "struct virtio_driver" has a member "struct dev_pm_ops *pm" > > It defines its own hooks (freeze and restore) though it includes "struct > device_driver" > > which has a "struct dev_pm_ops *pm". > > I just follow other virtio drivers to

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-23 Thread Viresh Kumar
On 24-03-21, 08:53, Jie Deng wrote: > > On 2021/3/23 17:38, Viresh Kumar wrote: > > On 23-03-21, 14:31, Viresh Kumar wrote: > > > On 23-03-21, 22:19, Jie Deng wrote: > > > > +static int virtio_i2c_xfer(struct i2c_adapter *adap, struc

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-23 Thread Viresh Kumar
On 23-03-21, 14:31, Viresh Kumar wrote: > On 23-03-21, 22:19, Jie Deng wrote: > > +static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, > > int num) > > +{ > > + struct virtio_i2c *vi = i2c_get_adapdata(adap); > > + struct virtq

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-23 Thread Viresh Kumar
On 23-03-21, 22:19, Jie Deng wrote: > +static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, > int num) > +{ > + struct virtio_i2c *vi = i2c_get_adapdata(adap); > + struct virtqueue *vq = vi->vq; > + struct virtio_i2c_req *reqs; > + unsigned long time_left; >

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-23 Thread Viresh Kumar
On 23-03-21, 16:33, Jie Deng wrote: > On 2021/3/23 15:27, Viresh Kumar wrote: > > > On 23-03-21, 22:19, Jie Deng wrote: > > > +static int __maybe_unused virtio_i2c_freeze(struct virtio_device *vdev) > > > +{ > > > + virtio_i2c_del_vqs(vdev); > > >

Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

2021-03-23 Thread Viresh Kumar
On 23-03-21, 22:19, Jie Deng wrote: > +static int __maybe_unused virtio_i2c_freeze(struct virtio_device *vdev) > +{ > + virtio_i2c_del_vqs(vdev); > + return 0; > +} > + > +static int __maybe_unused virtio_i2c_restore(struct virtio_device *vdev) > +{ > + return

Re: drivers/opp/of.c:959:12: warning: stack frame size of 1056 bytes in function '_of_add_table_indexed'

2021-03-23 Thread Viresh Kumar
On 23-03-21, 15:23, kernel test robot wrote: > Hi Viresh, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 84196390620ac0e5070ae36af84c137c6216a7dc > commit: 406e47652161d4f0d9bc4cd6237b36c51497ec75 opp:

Re: [PATCH] thermal/drivers/cpuidle_cooling: Fix use after error

2021-03-22 Thread Viresh Kumar
On 22-03-21, 09:08, Daniel Lezcano wrote: > On 22/03/2021 04:29, Viresh Kumar wrote: > > On 19-03-21, 21:25, Daniel Lezcano wrote: > >> When the function successfully finishes it logs an information about > >> the registration of the cooling device and use its nam

Re: [PATCH v9] i2c: virtio: add a virtio i2c frontend driver

2021-03-22 Thread Viresh Kumar
On 22-03-21, 15:53, Jie Deng wrote: > I think your optimization has problems... > > > > bool err_found = timeout; While at it, see if you want to rename this variable as well to something smaller, like "failed". I didn't touch it as it is a matter of personal choice, so leaving it to you..

Re: [PATCH v9] i2c: virtio: add a virtio i2c frontend driver

2021-03-22 Thread Viresh Kumar
On 22-03-21, 15:53, Jie Deng wrote: > On 2021/3/22 14:41, Viresh Kumar wrote: > I think your optimization has problems... > > > > bool err_found = timeout; > > > > for (i = 0; i < nr; i++) { > > /* Detach the ith request from the vq */

Re: [PATCH v9] i2c: virtio: add a virtio i2c frontend driver

2021-03-22 Thread Viresh Kumar
On 22-03-21, 21:35, Jie Deng wrote: > diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c > new file mode 100644 > index 000..316986e > --- /dev/null > +++ b/drivers/i2c/busses/i2c-virtio.c > @@ -0,0 +1,286 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > +

Re: [PATCH] thermal/drivers/cpuidle_cooling: Fix use after error

2021-03-21 Thread Viresh Kumar
On 19-03-21, 21:25, Daniel Lezcano wrote: > When the function successfully finishes it logs an information about > the registration of the cooling device and use its name to build the > message. Unfortunately it was freed right before: > > drivers/thermal/cpuidle_cooling.c:218

Re: [PATCH V6 4/4] cpufreq: CPPC: Add support for frequency invariance

2021-03-21 Thread Viresh Kumar
On 19-03-21, 17:20, Rafael J. Wysocki wrote: > Sorry for the delay. > > Acked-by: Rafael J. Wysocki Thanks. > and I'm assuming that either you or the sched guys will take care of it. Yeah, I have already queued this up. -- viresh

Re: [RFC][PATCH] sched: Optimize cpufreq_update_util

2021-03-19 Thread Viresh Kumar
On 19-03-21, 15:35, Rafael J. Wysocki wrote: > On Friday, March 19, 2021 8:37:51 AM CET Viresh Kumar wrote: > > On 18-03-21, 22:28, Peter Zijlstra wrote: > > > Also, is there a lock order comment in cpufreq somewhere? > > > > I don't think so. > > > > &g

Re: [RFC][PATCH] sched: Optimize cpufreq_update_util

2021-03-19 Thread Viresh Kumar
On 18-03-21, 22:28, Peter Zijlstra wrote: > Also, is there a lock order comment in cpufreq somewhere? I don't think so. > I tried > following it, but eventually gave up and figured 'asking' lockdep was > far simpler. This will get called from CPU's online/offline path at worst, nothing more.

Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-19 Thread Viresh Kumar
On 19-03-21, 14:29, Jie Deng wrote: > I also see example drivers/i2c/busses/i2c-xiic.c. Some people might think > this way is more clearer than > > updating each member in probe. Basically, I think it's just a matter of > personal preference which doesn't Memory used by one instance of struct

Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-18 Thread Viresh Kumar
On 16-03-21, 18:35, Jie Deng wrote: > +++ b/drivers/i2c/busses/i2c-virtio.c > +static int virtio_i2c_send_reqs(struct virtqueue *vq, > + struct virtio_i2c_req *reqs, > + struct i2c_msg *msgs, int nr) > +{ > + struct scatterlist *sgs[3],

Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-18 Thread Viresh Kumar
On 19-03-21, 13:31, Jie Deng wrote: > > On 2021/3/19 11:54, Viresh Kumar wrote: > > On 18-03-21, 15:52, Arnd Bergmann wrote: > > > Allowing multiple virtio-i2c controllers in one system, and multiple i2c > > > devices attached to each controller is clearly someth

Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-18 Thread Viresh Kumar
On 18-03-21, 15:52, Arnd Bergmann wrote: > Allowing multiple virtio-i2c controllers in one system, and multiple i2c > devices attached to each controller is clearly something that has to work. Good. > I don't actually see a limitation though. Viresh, what is the problem > you see for having

Re: [PATCH v4 1/6] soc/tegra: Add devm_tegra_core_dev_init_opp_table()

2021-03-18 Thread Viresh Kumar
On 18-03-21, 13:27, Dmitry Osipenko wrote: > 14.03.2021 19:48, Dmitry Osipenko пишет: > > Add common helper which initializes OPP table for Tegra SoC core devices. > > > > Tested-by: Peter Geis # Ouya T30 > > Tested-by: Paul Fertser # PAZ00 T20 > > Tested-by: Nicolas Chauvet # PAZ00 T20 and

Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-16 Thread Viresh Kumar
On 16-03-21, 18:35, Jie Deng wrote: > diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c > +struct virtio_i2c { > + struct virtio_device *vdev; > + struct completion completion; > + struct i2c_adapter *adap; > + struct mutex lock; > + struct

Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver

2021-03-16 Thread Viresh Kumar
On 16-03-21, 18:35, Jie Deng wrote: > +static struct i2c_adapter virtio_adapter = { > + .owner = THIS_MODULE, > + .name = "Virtio I2C Adapter", > + .class = I2C_CLASS_DEPRECATED, > + .algo = _algorithm, > +}; > + > +static int virtio_i2c_probe(struct virtio_device *vdev) > +{ > +

Re: [PATCH v7] i2c: virtio: add a virtio i2c frontend driver

2021-03-16 Thread Viresh Kumar
On 12-03-21, 13:41, Viresh Kumar wrote: > > > > +static struct i2c_adapter virtio_adapter = { > > > > + .owner = THIS_MODULE, > > > > + .name = "Virtio I2C Adapter", > > > > + .class = I2C_CLASS_DEPRECATED, &

[PATCH V3] kbuild: Allow .dtso format for overlay source files

2021-03-16 Thread Viresh Kumar
Tested-by: Geert Uytterhoeven Signed-off-by: Viresh Kumar --- This was made part of the bigger patchset earlier (most of it already got merged) whose last version was V11, but this patch was only sent twice earlier and so starting with Version 3. Changes since V2: - Add the dts -> dtbo r

Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-15 Thread Viresh Kumar
On 16-03-21, 00:36, Frank Rowand wrote: > I should have looked at patch 3/5 more carefully instead of counting on > Masahiro to check it out and simply build testing. > > Patch 3/5 does not seem correct. I'll look over all the makefile related > changes that have been accepted (if any) and patch

Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-15 Thread Viresh Kumar
On 16-03-21, 02:43, Masahiro Yamada wrote: > On Mon, Mar 15, 2021 at 3:40 PM Viresh Kumar wrote: > > On 14-03-21, 20:16, Frank Rowand wrote: > > What about doing this then in unittest's Makefile instead (which I > > already suggested earlier), that will make everything work

Re: linux-next: build warning after merge of the opp tree

2021-03-15 Thread Viresh Kumar
On 16-03-21, 11:15, Stephen Rothwell wrote: > Hi all, > > After merging the opp tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > In file included from include/linux/devfreq.h:15, > from drivers/base/power/main.c:36: >

Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-15 Thread Viresh Kumar
On 14-03-21, 20:16, Frank Rowand wrote: > On 3/12/21 11:11 PM, Frank Rowand wrote: > > On 3/12/21 1:13 AM, Viresh Kumar wrote: > >> On 12-03-21, 01:09, Frank Rowand wrote: > >>> I suggested having the .dtso files include the .dts file because that is > >>>

Re: [PATCH] cpufreq: cppc: simplify default delay_us setting

2021-03-14 Thread Viresh Kumar
On 12-03-21, 19:50, Tom Saeger wrote: > Simplify case when setting default in cppc_cpufreq_get_transition_delay_us. > > Signed-off-by: Tom Saeger > --- > drivers/cpufreq/cppc_cpufreq.c | 14 ++ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git

Re: [PATCH v3 00/15] Introduce devm_pm_opp_* API

2021-03-14 Thread Viresh Kumar
On 14-03-21, 19:33, Dmitry Osipenko wrote: > This series adds resource-managed OPP API helpers and makes drivers > to use them. > > Changelog: > > v3: - Dropped dev_pm_opp_register_notifier(). > > - Changed return type of the devm helpers from opp_table pointer > to errno. > > -

Re: [PATCH v3 11/15] drm/msm: Convert to use resource-managed OPP API

2021-03-14 Thread Viresh Kumar
+), 68 deletions(-) This patch has some updates in linux-next, which I don't have. Please get this merged with the drm tree over 5.13-rc1 later. Acked-by: Viresh Kumar -- viresh

Re: [PATCH] ia64: fix format string for ia64-acpi-cpu-freq

2021-03-14 Thread Viresh Kumar
ng unsigned int', > but argument 3 has type 's64' {aka 'long long int'} [-Wformat=] > > CC: "Rafael J. Wysocki" > CC: Viresh Kumar > CC: linux...@vger.kernel.org > Signed-off-by: Sergei Trofimovich > --- > drivers/cpufreq/ia64-acpi-cpufreq.c | 4 ++-- > 1 fil

Re: [PATCH V3] cpufreq: Rudimentary typos fix in the file s5pv210-cpufreq.c

2021-03-14 Thread Viresh Kumar
On 13-03-21, 09:19, Bhaskar Chowdhury wrote: > > Trivial spelling fixes throughout the file. > > Signed-off-by: Bhaskar Chowdhury > --- > Changes from V2: > Incoporated the findings of Tom Saeger > > drivers/cpufreq/s5pv210-cpufreq.c | 12 ++-- > 1 file changed, 6 insertions(+), 6

Re: [PATCH v2 4/5] thermal/drivers/cpuidle_cooling: Use device name instead of auto-numbering

2021-03-14 Thread Viresh Kumar
On 12-03-21, 18:03, Daniel Lezcano wrote: > Currently the naming of a cooling device is just a cooling technique > followed by a number. When there are multiple cooling devices using > the same technique, it is impossible to clearly identify the related > device as this one is just a number. > >

Re: [PATCH v7] i2c: virtio: add a virtio i2c frontend driver

2021-03-12 Thread Viresh Kumar
On 12-03-21, 15:51, Jie Deng wrote: > > On 2021/3/12 14:10, Viresh Kumar wrote: > > I saw your email about wrong version being sent, I already wrote some > > reviews. Sending them anyway for FWIW :) > > > > On 12-03-21, 21:33, Jie Deng wrote: > > &

Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-11 Thread Viresh Kumar
On 12-03-21, 01:09, Frank Rowand wrote: > I suggested having the .dtso files include the .dts file because that is a > relatively > small and easy change to test. What would probably make more sense is the > rename > the existing overlay .dts files to be .dtso files and then for each overlay >

Re: [PATCH v7] i2c: virtio: add a virtio i2c frontend driver

2021-03-11 Thread Viresh Kumar
I saw your email about wrong version being sent, I already wrote some reviews. Sending them anyway for FWIW :) On 12-03-21, 21:33, Jie Deng wrote: > diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c > new file mode 100644 > index 000..bbde8de > --- /dev/null > +++

Re: [PATCH v2 01/14] opp: Add devres wrapper for dev_pm_opp_set_clkname

2021-03-11 Thread Viresh Kumar
On 11-03-21, 22:20, Dmitry Osipenko wrote: > +struct opp_table *devm_pm_opp_set_clkname(struct device *dev, const char > *name) > +{ > + struct opp_table *opp_table; > + int err; > + > + opp_table = dev_pm_opp_set_clkname(dev, name); > + if (IS_ERR(opp_table)) > +

Re: [PATCH v2 05/14] opp: Add devres wrapper for dev_pm_opp_register_notifier

2021-03-11 Thread Viresh Kumar
On 11-03-21, 22:20, Dmitry Osipenko wrote: > From: Yangtao Li > > Add devres wrapper for dev_pm_opp_register_notifier() to simplify driver > code. > > Signed-off-by: Yangtao Li > Signed-off-by: Dmitry Osipenko > --- > drivers/opp/core.c | 38 ++ >

Re: [PATCH 1/3] thermal/drivers/cpufreq_cooling: Use device name instead of auto-numbering

2021-03-11 Thread Viresh Kumar
> > cpufreq-cpu0 > cpufreq-cpu4 > etc ... > > Signed-off-by: Daniel Lezcano > --- > drivers/thermal/cpufreq_cooling.c | 28 +++- > 1 file changed, 7 insertions(+), 21 deletions(-) For 1,3/3 Acked-by: Viresh Kumar -- viresh

Re: [PATCH V6 3/4] arch_topology: Export arch_freq_scale and helpers

2021-03-11 Thread Viresh Kumar
On 10-03-21, 10:53, Viresh Kumar wrote: > It is possible now for other parts of the kernel to provide their own > implementation of sched_freq_tick() and they can very well be modules > themselves (like CPPC cpufreq driver, which is going to use these in a > later commit).

Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-11 Thread Viresh Kumar
On 10-03-21, 20:24, Masahiro Yamada wrote: > Even without "-I dts", > >inform = guess_input_format(arg, "dts"); > > seems to fall back to "dts" anyway, > but I guess you wanted to make this explicit, correct? > > +# Required for of unit-test files as they can't be renamed to .dtso > > If

Re: [PATCH V11 0/5] dt: Add fdtoverlay rule and statically build unittest

2021-03-11 Thread Viresh Kumar
On 10-03-21, 11:05, Viresh Kumar wrote: > Hi, > > This patchset adds a generic rule for applying overlays using fdtoverlay > tool and then updates unittests to get built statically using the same. > > V10->V11: > - Update patch 4/5 to fix checkpatch warning on spaces a

Re: [PATCH V11 0/5] dt: Add fdtoverlay rule and statically build unittest

2021-03-11 Thread Viresh Kumar
On 11-03-21, 17:27, Frank Rowand wrote: > On 3/9/21 11:35 PM, Viresh Kumar wrote: > > Viresh Kumar (4): > > kbuild: Simplify builds with CONFIG_OF_ALL_DTBS > > kbuild: Allow .dtso format for overlay source files > > of: unittest: Create overlay_common.dts

[PATCH V2] opp: Don't drop extra references to OPPs accidentally

2021-03-11 Thread Viresh Kumar
Fixes: cf1fac943c63 ("opp: Reduce the size of critical section in _opp_kref_release()") Signed-off-by: Beata Michalska [ Viresh: Almost rewrote entire patch, added new "removed" field, rewrote commit log and added the correct Fixes tag. ] Co-developed-by: Viresh K

Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-11 Thread Viresh Kumar
On 11-03-21, 00:18, Masahiro Yamada wrote: > On Wed, Mar 10, 2021 at 11:48 PM Viresh Kumar wrote: > > > > On 10-03-21, 20:29, Masahiro Yamada wrote: > > > BTW, is the attached patch good for DTC? > > > > > > I do not know when '-O dtbo' is u

Re: [PATCH] opp: Invalidate current opp when draining the opp list

2021-03-11 Thread Viresh Kumar
On 10-03-21, 23:03, Beata Michalska wrote: > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > > index c2689386a906..150be4c28c99 100644 > > --- a/drivers/opp/core.c > > +++ b/drivers/opp/core.c > > @@ -1492,7 +1492,11 @@ static struct dev_pm_opp *_opp_get_next(struct > > opp_table

Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-10 Thread Viresh Kumar
On 10-03-21, 20:29, Masahiro Yamada wrote: > BTW, is the attached patch good for DTC? > > I do not know when '-O dtbo' is useful, > unless I am missing something. It is useful if we are sending the -O option all the time (I have already given more details to your patch) as outform will not be

Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-10 Thread Viresh Kumar
On 10-03-21, 20:24, Masahiro Yamada wrote: > On Wed, Mar 10, 2021 at 2:35 PM Viresh Kumar wrote: > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > > index bc045a54a34e..59e86f67f9e0 100644 > > --- a/scripts/Makefile.lib > > +++ b/scripts/Makefile.lib &g

Re: [PATCH] kbuild: remove unneeded -O option to dtc

2021-03-10 Thread Viresh Kumar
p) > $< ; \ > - $(DTC) -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \ > + $(DTC) -o $@ -b 0 \ > $(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \ > -d $(depfile).dtc.tmp $(dtc-tmp) ; \ > cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile) LGTM. Reviewed-by: Viresh Kumar -- viresh

Re: [PATCH] opp: Invalidate current opp when draining the opp list

2021-03-10 Thread Viresh Kumar
rewrote commit log and added the correct Fixes tag. ] Co-developed-by: Viresh Kumar Signed-off-by: Viresh Kumar --- drivers/opp/core.c | 48 -- drivers/opp/opp.h | 2 ++ 2 files changed, 27 insertions(+), 23 deletions(-) diff --git a/

[PATCH V11 5/5] of: unittest: Statically apply overlays using fdtoverlay

2021-03-09 Thread Viresh Kumar
checks for. These overlays will cause fdtoverlay to fail, and are thus not included for static builds. Signed-off-by: Viresh Kumar --- drivers/of/unittest-data/Makefile | 48 ++ drivers/of/unittest-data/static_base_1.dts | 4 ++ drivers/of/unittest-data/static_base_2

[PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

2021-03-09 Thread Viresh Kumar
. This is required for the source files present in drivers/of/unittest-data/, because they can't be renamed to .dtso as they are used for some runtime testing as well. Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Viresh Kumar --- scripts/Makefile.lib | 9 - 1

[PATCH V11 1/5] kbuild: Simplify builds with CONFIG_OF_ALL_DTBS

2021-03-09 Thread Viresh Kumar
We update 'extra-y' based on CONFIG_OF_ALL_DTBS three times. It would be far more straight forward if we rather update dtb-y to include all .dtb files if CONFIG_OF_ALL_DTBS is enabled. Acked-by: Masahiro Yamada Signed-off-by: Viresh Kumar --- scripts/Makefile.lib | 5 ++--- 1 file changed, 2

[PATCH V11 0/5] dt: Add fdtoverlay rule and statically build unittest

2021-03-09 Thread Viresh Kumar
arning a lot every day :) V6->V7: - Dropped the first 4 patches, already merged. - Patch 1/3 is new, suggested by Rob and slightly modified by me. - Adapt Patch 3/3 to the new rule and name the overlay dtbs as .dtbo. -- Viresh Rob Herring (1): kbuild: Add generic rule to apply fdtoverlay

[PATCH V11 4/5] of: unittest: Create overlay_common.dtsi and testcases_common.dtsi

2021-03-09 Thread Viresh Kumar
quot; node to testcases.dts from tests-interrupts.dtsi, as this node has a deliberate error in it and is only relevant for runtime testing done with unittest.c. Signed-off-by: Viresh Kumar --- drivers/of/unittest-data/overlay_base.dts | 90 +- drivers/of/unittest-data/overlay_common.

[PATCH V11 2/5] kbuild: Add generic rule to apply fdtoverlay

2021-03-09 Thread Viresh Kumar
o_base.dtb foo_overlay1.dtbo foo_overlay2.dtbo dtb-y := foo.dtb We don't want to run schema checks on foo.dtb (as foo.dts doesn't exist) and the Makefile is updated accordingly. Acked-by: Masahiro Yamada Signed-off-by: Rob Herring Co-developed-by: Viresh Kumar Signed-off-by: Viresh Kumar --

[PATCH V6 4/4] cpufreq: CPPC: Add support for frequency invariance

2021-03-09 Thread Viresh Kumar
Voinescu Tested-by: Vincent Guittot Signed-off-by: Viresh Kumar --- drivers/cpufreq/Kconfig.arm| 10 ++ drivers/cpufreq/cppc_cpufreq.c | 245 +++-- include/linux/arch_topology.h | 1 + kernel/sched/core.c| 1 + 4 files changed, 245 insertions(+), 12

[PATCH V6 0/4] cpufreq: cppc: Add support for frequency invariance

2021-03-09 Thread Viresh Kumar
the callbacks is improved, so different parts looking to provide their callbacks don't need to think about each other. - Moved to per-cpu storage for storing the callback related data, AMU counters have higher priority with this. -- Viresh Viresh Kumar (4): arch_topology: Rename freq_scale

[PATCH V6 3/4] arch_topology: Export arch_freq_scale and helpers

2021-03-09 Thread Viresh Kumar
(). Reviewed-by: Ionela Voinescu Tested-by: Ionela Voinescu Tested-by: Vincent Guittot Signed-off-by: Viresh Kumar --- drivers/base/arch_topology.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index ebcd2ea3091f..995e52b9eca4

[PATCH V6 2/4] arch_topology: Allow multiple entities to provide sched_freq_tick() callback

2021-03-09 Thread Viresh Kumar
to show that cpufreq is also acts as source of information for FIE and will be used by default if no other counters are supported for a platform. Reviewed-by: Ionela Voinescu Tested-by: Ionela Voinescu Acked-by: Will Deacon # for arm64 Tested-by: Vincent Guittot Signed-off-by: Viresh Kumar

[PATCH V6 1/4] arch_topology: Rename freq_scale as arch_freq_scale

2021-03-09 Thread Viresh Kumar
Rename freq_scale to a less generic name, as it will get exported soon for modules. Since x86 already names its own implementation of this as arch_freq_scale, lets stick to that. Suggested-by: Will Deacon Signed-off-by: Viresh Kumar --- arch/arm64/kernel/topology.c | 6 +++--- drivers/base

Re: [PATCH V5 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback

2021-03-09 Thread Viresh Kumar
On 09-03-21, 15:11, Ionela Voinescu wrote: > On Monday 01 Mar 2021 at 12:21:17 (+0530), Viresh Kumar wrote: > > diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h > > index 0f6cd6b73a61..3bcfba5c21a7 100644 > > --- a/include/linux/arch_topology.h &g

Re: [PATCH] opp: Invalidate current opp when draining the opp list

2021-03-08 Thread Viresh Kumar
On 08-03-21, 18:14, Beata Michalska wrote: > > -bool _opp_remove_all_static(struct opp_table *opp_table) > > +/* > > + * Can't remove the OPP from under the lock, debugfs removal needs to > > happen > > + * lock less to avoid circular dependency issues. This must be called > > without > > + *

Re: [PATCH 06/10] staging: greybus: spilib: use 'spi_delay_to_ns' for getting xfer delay

2021-03-08 Thread Viresh Kumar
; + gb_xfer->delay_usecs = cpu_to_le16(xfer_delay); > gb_xfer->cs_change = xfer->cs_change; > gb_xfer->bits_per_word = xfer->bits_per_word; Acked-by: Viresh Kumar -- viresh

Re: [PATCH V5 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback

2021-03-08 Thread Viresh Kumar
On 08-03-21, 14:52, Will Deacon wrote: > On Mon, Mar 01, 2021 at 12:21:17PM +0530, Viresh Kumar wrote: > > +EXPORT_SYMBOL_GPL(topology_set_scale_freq_source); > > I don't get why you need to export this in this patch. The arm64 topology > code is never built as a module. > &

Re: [PATCH] opp: Invalidate current opp when draining the opp list

2021-03-08 Thread Viresh Kumar
pp. Fixes: 81c4d8a3c414 ("opp: Keep track of currently programmed OPP") Signed-off-by: Beata Michalska [ Viresh: Rewrite _opp_drain_list() to not drop the extra count instead of depending on reference counting. Update commit log and other minor changes. ] Signed-off-

[PATCH V10 5/5] of: unittest: Statically apply overlays using fdtoverlay

2021-03-08 Thread Viresh Kumar
checks for. These overlays will cause fdtoverlay to fail, and are thus not included for static builds. Signed-off-by: Viresh Kumar --- drivers/of/unittest-data/Makefile | 48 ++ drivers/of/unittest-data/static_base_1.dts | 4 ++ drivers/of/unittest-data/static_base_2

[PATCH V10 4/5] of: unittest: Create overlay_common.dtsi and testcases_common.dtsi

2021-03-08 Thread Viresh Kumar
quot; node to testcases.dts from tests-interrupts.dtsi, as this node has a deliberate error in it and is only relevant for runtime testing done with unittest.c. Signed-off-by: Viresh Kumar --- drivers/of/unittest-data/overlay_base.dts | 90 +- drivers/of/unittest-data/overlay_common.

  1   2   3   4   5   6   7   8   9   10   >