lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <202312300907.RGtYsKxb-lkp@intel.com> Date: Sat, 30 Dec 2023 10:01:55 +0800 From: kernel test robot <lkp@...el.com> To: pratikmanvar09@...il.com, thierry.reding@...il.com, u.kleine-koenig@...gutronix.de, shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com, linux-imx@....com, linux-pwm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org Cc: oe-kbuild-all@...ts.linux.dev, Clark Wang <xiaoning.wang@....com>, Jun Li <jun.li@....com>, Pratik Manvar <pratik.manvar@....com> Subject: Re: [PATCH] pwm: imx27: workaround of the pwm output bug Hi, kernel test robot noticed the following build warnings: [auto build test WARNING on thierry-reding-pwm/for-next] [also build test WARNING on linus/master v6.7-rc7 next-20231222] [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/pratikmanvar09-gmail-com/pwm-imx27-workaround-of-the-pwm-output-bug/20231229-143435 base: https://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git for-next patch link: https://lore.kernel.org/r/20231229063013.1786-1-pratikmanvar09%40gmail.com patch subject: [PATCH] pwm: imx27: workaround of the pwm output bug config: arm-randconfig-r133-20231230 (https://download.01.org/0day-ci/archive/20231230/202312300907.RGtYsKxb-lkp@intel.com/config) compiler: clang version 18.0.0git (https://github.com/llvm/llvm-project 8a4266a626914765c0c69839e8a51be383013c1a) reproduce: (https://download.01.org/0day-ci/archive/20231230/202312300907.RGtYsKxb-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@...el.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202312300907.RGtYsKxb-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/pwm/pwm-imx27.c:303:26: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] sar_last @@ got restricted __le32 [usertype] @@ drivers/pwm/pwm-imx27.c:303:26: sparse: expected unsigned int [usertype] sar_last drivers/pwm/pwm-imx27.c:303:26: sparse: got restricted __le32 [usertype] >> drivers/pwm/pwm-imx27.c:304:29: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] sar_current @@ got restricted __le32 [usertype] @@ drivers/pwm/pwm-imx27.c:304:29: sparse: expected unsigned int [usertype] sar_current drivers/pwm/pwm-imx27.c:304:29: sparse: got restricted __le32 [usertype] vim +303 drivers/pwm/pwm-imx27.c 219 220 static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm, 221 const struct pwm_state *state) 222 { 223 unsigned long period_cycles, duty_cycles, prescale, counter_check, flags; 224 struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip); 225 void __iomem *reg_sar = imx->mmio_base + MX3_PWMSAR; 226 __force u32 sar_last, sar_current; 227 struct pwm_state cstate; 228 unsigned long long c; 229 unsigned long long clkrate; 230 int ret; 231 u32 cr, timeout = 1000; 232 233 pwm_get_state(pwm, &cstate); 234 235 clkrate = clk_get_rate(imx->clk_per); 236 c = clkrate * state->period; 237 238 do_div(c, NSEC_PER_SEC); 239 period_cycles = c; 240 241 prescale = period_cycles / 0x10000 + 1; 242 243 period_cycles /= prescale; 244 c = clkrate * state->duty_cycle; 245 do_div(c, NSEC_PER_SEC); 246 duty_cycles = c; 247 duty_cycles /= prescale; 248 249 /* 250 * according to imx pwm RM, the real period value should be PERIOD 251 * value in PWMPR plus 2. 252 */ 253 if (period_cycles > 2) 254 period_cycles -= 2; 255 else 256 period_cycles = 0; 257 258 /* 259 * Wait for a free FIFO slot if the PWM is already enabled, and flush 260 * the FIFO if the PWM was disabled and is about to be enabled. 261 */ 262 if (cstate.enabled) { 263 pwm_imx27_wait_fifo_slot(chip, pwm); 264 } else { 265 ret = pwm_imx27_clk_prepare_enable(imx); 266 if (ret) 267 return ret; 268 269 pwm_imx27_sw_reset(chip); 270 } 271 272 /* 273 * This is a limited workaround. When the SAR FIFO is empty, the new 274 * write value will be directly applied to SAR even the current period 275 * is not over. 276 * If the new SAR value is less than the old one, and the counter is 277 * greater than the new SAR value, the current period will not filp 278 * the level. This will result in a pulse with a duty cycle of 100%. 279 * So, writing the current value of the SAR to SAR here before updating 280 * the new SAR value can avoid this issue. 281 * 282 * Add a spin lock and turn off the interrupt to ensure that the 283 * real-time performance can be guaranteed as much as possible when 284 * operating the following operations. 285 * 286 * 1. Add a threshold of 1.5us. If the time T between the read current 287 * count value CNR and the end of the cycle is less than 1.5us, wait 288 * for T to be longer than 1.5us before updating the SAR register. 289 * This is to avoid the situation that when the first SAR is written, 290 * the current cycle just ends and the SAR FIFO that just be written 291 * is emptied again. 292 * 293 * 2. Use __raw_writel() to minimize the interval between two writes to 294 * the SAR register to increase the fastest pwm frequency supported. 295 * 296 * When the PWM period is longer than 2us(or <500KHz), this workaround 297 * can solve this problem. 298 */ 299 if (duty_cycles < imx->duty_cycle) { 300 c = clkrate * 1500; 301 do_div(c, NSEC_PER_SEC); 302 counter_check = c; > 303 sar_last = cpu_to_le32(imx->duty_cycle); > 304 sar_current = cpu_to_le32(duty_cycles); 305 306 spin_lock_irqsave(&imx->lock, flags); 307 if (state->period >= 2000) { 308 while ((period_cycles - 309 readl_relaxed(imx->mmio_base + MX3_PWMCNR)) 310 < counter_check) { 311 if (!--timeout) 312 break; 313 }; 314 } 315 if (!(MX3_PWMSR_FIFOAV & 316 readl_relaxed(imx->mmio_base + MX3_PWMSR))) 317 __raw_writel(sar_last, reg_sar); 318 __raw_writel(sar_current, reg_sar); 319 spin_unlock_irqrestore(&imx->lock, flags); 320 } else 321 writel(duty_cycles, imx->mmio_base + MX3_PWMSAR); 322 323 writel(period_cycles, imx->mmio_base + MX3_PWMPR); 324 325 /* 326 * Store the duty cycle for future reference in cases where the 327 * MX3_PWMSAR register can't be read (i.e. when the PWM is disabled). 328 */ 329 imx->duty_cycle = duty_cycles; 330 331 cr = MX3_PWMCR_PRESCALER_SET(prescale) | 332 MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN | 333 FIELD_PREP(MX3_PWMCR_CLKSRC, MX3_PWMCR_CLKSRC_IPG_HIGH) | 334 MX3_PWMCR_DBGEN; 335 336 if (state->polarity == PWM_POLARITY_INVERSED) 337 cr |= FIELD_PREP(MX3_PWMCR_POUTC, 338 MX3_PWMCR_POUTC_INVERTED); 339 340 if (state->enabled) 341 cr |= MX3_PWMCR_EN; 342 343 writel(cr, imx->mmio_base + MX3_PWMCR); 344 345 if (!state->enabled) 346 pwm_imx27_clk_disable_unprepare(imx); 347 348 return 0; 349 } 350 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Powered by blists - more mailing lists