From: kernel test robot <lkp@intel.com>
To: Nylon Chen <nylon.chen@sifive.com>,
aou@eecs.berkeley.edu, conor@kernel.org,
emil.renner.berthing@canonical.com, geert+renesas@glider.be,
heiko@sntech.de, krzysztof.kozlowski+dt@linaro.org,
palmer@dabbelt.com, paul.walmsley@sifive.com, robh+dt@kernel.org,
thierry.reding@gmail.com, u.kleine-koenig@pengutronix.de,
devicetree@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev, nylon.chen@sifive.com,
nylon7717@gmail.com, zong.li@sifive.com, greentime.hu@sifive.com,
vincent.chen@sifive.com,
Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED algorithm
Date: Thu, 20 Apr 2023 22:13:22 +0800 [thread overview]
Message-ID: <202304202141.JYCKBVOQ-lkp@intel.com> (raw)
In-Reply-To: <20230420093457.18936-3-nylon.chen@sifive.com>
Hi Nylon,
kernel test robot noticed the following build warnings:
[auto build test WARNING on robh/for-next]
[also build test WARNING on thierry-reding-pwm/for-next rockchip/for-next linus/master v6.3-rc7 next-20230419]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nylon-Chen/riscv-dts-sifive-unleashed-unmatched-Remove-PWM-controlled-LED-s-active-low-properties/20230420-173619
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/20230420093457.18936-3-nylon.chen%40sifive.com
patch subject: [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED algorithm
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20230420/202304202141.JYCKBVOQ-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/f2d706bf61190a45a8f90f1f455bc943d4ac7b6e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Nylon-Chen/riscv-dts-sifive-unleashed-unmatched-Remove-PWM-controlled-LED-s-active-low-properties/20230420-173619
git checkout f2d706bf61190a45a8f90f1f455bc943d4ac7b6e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k SHELL=/bin/bash drivers/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202304202141.JYCKBVOQ-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:26,
from include/linux/clk.h:13,
from drivers/pwm/pwm-sifive.c:14:
drivers/pwm/pwm-sifive.c: In function 'pwm_sifive_apply':
include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~
include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~~~~~~~~~
include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~
include/linux/minmax.h:74:25: note: in expansion of macro '__careful_cmp'
74 | #define max(x, y) __careful_cmp(x, y, >)
| ^~~~~~~~~~~~~
drivers/pwm/pwm-sifive.c:157:18: note: in expansion of macro 'max'
157 | period = max(state->period, ddata->approx_period);
| ^~~
>> drivers/pwm/pwm-sifive.c:135:34: warning: variable 'period' set but not used [-Wunused-but-set-variable]
135 | unsigned int duty_cycle, period;
| ^~~~~~
vim +/period +135 drivers/pwm/pwm-sifive.c
129
130 static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
131 const struct pwm_state *state)
132 {
133 struct pwm_sifive_ddata *ddata = pwm_sifive_chip_to_ddata(chip);
134 struct pwm_state cur_state;
> 135 unsigned int duty_cycle, period;
136 unsigned long long num;
137 bool enabled;
138 int ret = 0;
139 u32 frac;
140
141 if (state->polarity != PWM_POLARITY_NORMAL && state->polarity != PWM_POLARITY_INVERSED)
142 return -EINVAL;
143
144 cur_state = pwm->state;
145 enabled = cur_state.enabled;
146
147 duty_cycle = state->duty_cycle;
148 if (!state->enabled)
149 duty_cycle = 0;
150
151 /*
152 * The problem of output producing mixed setting as mentioned at top,
153 * occurs here. To minimize the window for this problem, we are
154 * calculating the register values first and then writing them
155 * consecutively
156 */
157 period = max(state->period, ddata->approx_period);
158 num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
159 frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
160 frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
161 /* The hardware cannot generate a 100% duty cycle */
162 frac = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
163
164
165 mutex_lock(&ddata->lock);
166 if (state->period != ddata->approx_period) {
167 /*
168 * Don't let a 2nd user change the period underneath the 1st user.
169 * However if ddate->approx_period == 0 this is the first time we set
170 * any period, so let whoever gets here first set the period so other
171 * users who agree on the period won't fail.
172 */
173 if (ddata->user_count != 1 && ddata->approx_period) {
174 mutex_unlock(&ddata->lock);
175 return -EBUSY;
176 }
177 ddata->approx_period = state->period;
178 pwm_sifive_update_clock(ddata, clk_get_rate(ddata->clk));
179 }
180 mutex_unlock(&ddata->lock);
181
182 /*
183 * If the PWM is enabled the clk is already on. So only enable it
184 * conditionally to have it on exactly once afterwards independent of
185 * the PWM state.
186 */
187 if (!enabled) {
188 ret = clk_enable(ddata->clk);
189 if (ret) {
190 dev_err(ddata->chip.dev, "Enable clk failed\n");
191 return ret;
192 }
193 }
194
195 writel(frac, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
196
197 if (!state->enabled)
198 clk_disable(ddata->clk);
199
200 return 0;
201 }
202
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com>
To: Nylon Chen <nylon.chen@sifive.com>,
aou@eecs.berkeley.edu, conor@kernel.org,
emil.renner.berthing@canonical.com, geert+renesas@glider.be,
heiko@sntech.de, krzysztof.kozlowski+dt@linaro.org,
palmer@dabbelt.com, paul.walmsley@sifive.com, robh+dt@kernel.org,
thierry.reding@gmail.com, u.kleine-koenig@pengutronix.de,
devicetree@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev, nylon.chen@sifive.com,
nylon7717@gmail.com, zong.li@sifive.com, greentime.hu@sifive.com,
vincent.chen@sifive.com,
Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED algorithm
Date: Thu, 20 Apr 2023 22:13:22 +0800 [thread overview]
Message-ID: <202304202141.JYCKBVOQ-lkp@intel.com> (raw)
In-Reply-To: <20230420093457.18936-3-nylon.chen@sifive.com>
Hi Nylon,
kernel test robot noticed the following build warnings:
[auto build test WARNING on robh/for-next]
[also build test WARNING on thierry-reding-pwm/for-next rockchip/for-next linus/master v6.3-rc7 next-20230419]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nylon-Chen/riscv-dts-sifive-unleashed-unmatched-Remove-PWM-controlled-LED-s-active-low-properties/20230420-173619
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/20230420093457.18936-3-nylon.chen%40sifive.com
patch subject: [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED algorithm
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20230420/202304202141.JYCKBVOQ-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/f2d706bf61190a45a8f90f1f455bc943d4ac7b6e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Nylon-Chen/riscv-dts-sifive-unleashed-unmatched-Remove-PWM-controlled-LED-s-active-low-properties/20230420-173619
git checkout f2d706bf61190a45a8f90f1f455bc943d4ac7b6e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k SHELL=/bin/bash drivers/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202304202141.JYCKBVOQ-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:26,
from include/linux/clk.h:13,
from drivers/pwm/pwm-sifive.c:14:
drivers/pwm/pwm-sifive.c: In function 'pwm_sifive_apply':
include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~
include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
26 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~~~~~~~~~
include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~
include/linux/minmax.h:74:25: note: in expansion of macro '__careful_cmp'
74 | #define max(x, y) __careful_cmp(x, y, >)
| ^~~~~~~~~~~~~
drivers/pwm/pwm-sifive.c:157:18: note: in expansion of macro 'max'
157 | period = max(state->period, ddata->approx_period);
| ^~~
>> drivers/pwm/pwm-sifive.c:135:34: warning: variable 'period' set but not used [-Wunused-but-set-variable]
135 | unsigned int duty_cycle, period;
| ^~~~~~
vim +/period +135 drivers/pwm/pwm-sifive.c
129
130 static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
131 const struct pwm_state *state)
132 {
133 struct pwm_sifive_ddata *ddata = pwm_sifive_chip_to_ddata(chip);
134 struct pwm_state cur_state;
> 135 unsigned int duty_cycle, period;
136 unsigned long long num;
137 bool enabled;
138 int ret = 0;
139 u32 frac;
140
141 if (state->polarity != PWM_POLARITY_NORMAL && state->polarity != PWM_POLARITY_INVERSED)
142 return -EINVAL;
143
144 cur_state = pwm->state;
145 enabled = cur_state.enabled;
146
147 duty_cycle = state->duty_cycle;
148 if (!state->enabled)
149 duty_cycle = 0;
150
151 /*
152 * The problem of output producing mixed setting as mentioned at top,
153 * occurs here. To minimize the window for this problem, we are
154 * calculating the register values first and then writing them
155 * consecutively
156 */
157 period = max(state->period, ddata->approx_period);
158 num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
159 frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
160 frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
161 /* The hardware cannot generate a 100% duty cycle */
162 frac = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
163
164
165 mutex_lock(&ddata->lock);
166 if (state->period != ddata->approx_period) {
167 /*
168 * Don't let a 2nd user change the period underneath the 1st user.
169 * However if ddate->approx_period == 0 this is the first time we set
170 * any period, so let whoever gets here first set the period so other
171 * users who agree on the period won't fail.
172 */
173 if (ddata->user_count != 1 && ddata->approx_period) {
174 mutex_unlock(&ddata->lock);
175 return -EBUSY;
176 }
177 ddata->approx_period = state->period;
178 pwm_sifive_update_clock(ddata, clk_get_rate(ddata->clk));
179 }
180 mutex_unlock(&ddata->lock);
181
182 /*
183 * If the PWM is enabled the clk is already on. So only enable it
184 * conditionally to have it on exactly once afterwards independent of
185 * the PWM state.
186 */
187 if (!enabled) {
188 ret = clk_enable(ddata->clk);
189 if (ret) {
190 dev_err(ddata->chip.dev, "Enable clk failed\n");
191 return ret;
192 }
193 }
194
195 writel(frac, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
196
197 if (!state->enabled)
198 clk_disable(ddata->clk);
199
200 return 0;
201 }
202
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-04-20 14:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 9:34 [PATCH v3 0/2] Change PWM-controlled LED pin active mode and algorithm Nylon Chen
2023-04-20 9:34 ` Nylon Chen
2023-04-20 9:34 ` [PATCH v3 1/2] riscv: dts: sifive: unleashed/unmatched: Remove PWM controlled LED's active-low properties Nylon Chen
2023-04-20 9:34 ` Nylon Chen
2023-04-20 10:20 ` Conor Dooley
2023-04-20 10:20 ` Conor Dooley
2023-04-20 9:34 ` [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED algorithm Nylon Chen
2023-04-20 9:34 ` Nylon Chen
2023-04-20 10:04 ` Emil Renner Berthing
2023-04-20 10:04 ` Emil Renner Berthing
[not found] ` <CAHh=Yk86AV542Y7wG6rkHTc4va1Gof3uXtj84zzK5m+khL_Aiw@mail.gmail.com>
2023-04-20 10:46 ` Emil Renner Berthing
2023-04-20 10:46 ` Emil Renner Berthing
2023-04-21 6:16 ` Nylon Chen
2023-04-21 6:16 ` Nylon Chen
2023-04-21 10:09 ` Emil Renner Berthing
2023-04-21 10:09 ` Emil Renner Berthing
2023-04-20 10:28 ` Conor Dooley
2023-04-20 10:28 ` Conor Dooley
2023-04-20 14:13 ` kernel test robot [this message]
2023-04-20 14:13 ` kernel test robot
2023-04-22 13:22 ` kernel test robot
2023-04-22 13:22 ` kernel test robot
2023-05-08 9:48 ` kernel test robot
2023-05-08 9:48 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202304202141.JYCKBVOQ-lkp@intel.com \
--to=lkp@intel.com \
--cc=aou@eecs.berkeley.edu \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=emil.renner.berthing@canonical.com \
--cc=geert+renesas@glider.be \
--cc=greentime.hu@sifive.com \
--cc=heiko@sntech.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=nylon.chen@sifive.com \
--cc=nylon7717@gmail.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vincent.chen@sifive.com \
--cc=zong.li@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.