Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1869562imc; Tue, 12 Mar 2019 02:18:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqzJVaSlejgz+kOOtFJWjWPujvIG+GEX4ePYBWkaTJ/Xm+I/6Z3jUotQeHLAFmAzdxh15Sp4 X-Received: by 2002:a17:902:b493:: with SMTP id y19mr39547732plr.9.1552382327017; Tue, 12 Mar 2019 02:18:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552382327; cv=none; d=google.com; s=arc-20160816; b=eR6xyDg2sDOs3pI7xZ7ujZ6K5LCR6oU9+jNy4Ly5q1LjvY/2ZlZ79+uDGBd5IMjepj TUzoV+mK793CIGYEnjNcTzwSepUz89CE81VyFtHEI+Y6W95pXIASHshifuSIiv1E3ZXk khIeaEWVFUz72R2k1hDBoZz+I674p+VCrc8Q07ZXaC4O6RkqpvPfvIt/SpckUVKGKlpy Po3x8PPGEho2VNcII/uTeTLra+RWVd/EYbQpUNa1STXtzxXcWIF0Mxc+rj5MmIts3GmM KseXlZmWtHFNg1Ff1VaCuS79bu3F8b+TlbgKKyF8tRCoTPmkoH3Ahzw8Gx5OLHj2LA1E LxPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=HAfOAbbT5TNBfnDhUbZSSteNyRTMJHXC9FUbdwvbYqM=; b=szLsmv65NIjHbhJ6uifWUv3PYgFYnWoVjHD1kxmlH0fzz9Apeg718BuDcoUvQvsC36 jqslZ2k/y5lK3aOD0I3DZDxH/VG+sFXlGGclMLrnFGToAfD9yQ2O6XXPHLqZwXXJHV0V NF8W61o1bIOWV4zcKuJl/pzquRpaqBpF0OVhraG1TsHkvQTFnaLkeObAhJWgq1O+IarI 5hqNxQ4+/7n9tMCxivPLgmizf5J+3J57bwYMwtcslij7ZLkCICcX1LnbIegiq2NqOaZR zD4Q+jHEdW9+OQlLeMukM31Ww5QkEvSPOAgqcHu9oK8Mq9PRVreIO8HR2QU0krwfOaXh 8szQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n66si7495699pfb.62.2019.03.12.02.18.31; Tue, 12 Mar 2019 02:18:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726535AbfCLJRs (ORCPT + 99 others); Tue, 12 Mar 2019 05:17:48 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:53843 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726193AbfCLJRr (ORCPT ); Tue, 12 Mar 2019 05:17:47 -0400 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1h3dXZ-0002dH-9m; Tue, 12 Mar 2019 10:17:41 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1h3dXX-000766-ON; Tue, 12 Mar 2019 10:17:39 +0100 Date: Tue, 12 Mar 2019 10:17:39 +0100 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Yash Shah Cc: palmer@sifive.com, linux-pwm@vger.kernel.org, linux-riscv@lists.infradead.org, thierry.reding@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, sachin.ghadi@sifive.com, paul.walmsley@sifive.com Subject: Re: [PATCH v9 2/2] pwm: sifive: Add a driver for SiFive SoC PWM Message-ID: <20190312091739.fhv2hb2ll2eamdsn@pengutronix.de> References: <1552378289-27245-1-git-send-email-yash.shah@sifive.com> <1552378289-27245-3-git-send-email-yash.shah@sifive.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1552378289-27245-3-git-send-email-yash.shah@sifive.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, there are just a few minor things left I commented below. On Tue, Mar 12, 2019 at 01:41:29PM +0530, Yash Shah wrote: > +#define div_u64_round(a, b) \ > + ({typeof(b) __b = b; div_u64((a) + __b / 2, __b); }) Parenthesis around b please. I guess I didn't had them in my suggestion either, sorry for that. > +static int pwm_sifive_enable(struct pwm_chip *chip, bool enable) > +{ > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > + int ret; > + > + if (enable) { > + ret = clk_enable(pwm->clk); > + if (ret) { > + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret); > + return ret; > + } > + } > + > + if (!enable) > + clk_disable(pwm->clk); > + > + return 0; > +} There is only a single caller for this function. I wonder if it is trivial enough to fold it into pwm_sifive_apply. > +static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *dev, > + struct pwm_state *state) > +{ > + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip); > + unsigned int duty_cycle; > + u32 frac; > + struct pwm_state cur_state; > + bool enabled; > + int ret = 0; > + unsigned long num; > + > + if (state->polarity != PWM_POLARITY_INVERSED) > + return -EINVAL; > + > + ret = clk_enable(pwm->clk); > + if (ret) { > + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret); > + return ret; > + } > + > + mutex_lock(&pwm->lock); > + pwm_get_state(dev, &cur_state); > + > + enabled = cur_state.enabled; > + > + if (state->period != pwm->approx_period) { > + if (pwm->user_count != 1) { > + ret = -EBUSY; > + goto exit; > + } > + pwm->approx_period = state->period; > + pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk)); > + } > + > + duty_cycle = state->duty_cycle; > + if (!state->enabled) > + duty_cycle = 0; > + > + num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH); > + frac = div_u64_round(num, state->period); > + /* The hardware cannot generate a 100% duty cycle */ > + frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1); > + > + writel(frac, pwm->regs + PWM_SIFIVE_PWMCMP0 + > + dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP); > + > + if (state->enabled != enabled) { > + ret = pwm_sifive_enable(chip, state->enabled); > + if (ret) > + goto exit; This goto is a noop. > + } > + > +exit: > + clk_disable(pwm->clk); > + mutex_unlock(&pwm->lock); > + return ret; > +} There are a few other things that could be improved, but I think they could be addressed later. For some of these I don't even know what to suggest, for some Thierry might not agree it is worth fixing: - rounding how to round? When should a request declined, when is rounding ok? There is still "if (state->period != pwm->approx_period) return -EBUSY" in this driver. This is better than before, but if state-period == pwm->approx_period + 1 the result (if accepted) might be the same as without the +1 and so returning -EBUSY for one case and accepting the other is strange. - don't call PWM API functions designed for consumers (here: pwm_get_state) - Move div_u64_round to include/linux/math64.h Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |