Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2149375imm; Thu, 9 Aug 2018 08:05:40 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxidsbA5I6dRQVRUyBC2fICTHsqJ8P+xPoTUexm3657kTaOgOgafqb4DNkxgHrk+KF1NExC X-Received: by 2002:a63:c00b:: with SMTP id h11-v6mr2473109pgg.279.1533827120333; Thu, 09 Aug 2018 08:05:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533827111; cv=none; d=google.com; s=arc-20160816; b=Vq0IqcngbZPUQnNXdNHYqDTNUKBSs/GmATeCKFGugSKOJoydhGdxr0q8/R647uJL8s y5R4Zdpihbz6K1hqSH8tIcr5LH5q0G283gTSi6/TuZXdE+5LLEjc7Lm8myx4CgB7Co3T SkQx1DOhPH+/U7WVkXDTcZb95KSlSXcZHfmhfoT7MfJl9/xVuSlm1it0Zr7MXGU0uzj2 jcYHRJHm0qjSNvll07My0TpagUYQFPzF17OfSzona6oRPTA9K5lm10XTugfi2ga4E+vt P5YPwI+s3QERcGsTm70quEA98uaLWCJ/VO3ycZQBTliFvPY5ql+4/n2sTqEhN7Z8VG6I cuvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=JoYXYwYrwx4Hk5mk+pz/xVRveRpDx6R/CC0+ARbcRoQ=; b=U60mMO9HYADZ2DQx3ZEkRvW5Nbcqk3FVENxocmpWml09MX6gqrFBAXhBhW0BRasJOt 5wKfBHzYjay+xqNMO3wCqkdPYDII7yUCd/C4Jii1m5N5cV4kq3WR52FsbSOC7FjLPQWP Hg4oLbm14nowbjEQLC3Z/8FjaHMIQrr6eFTblvoZB0nYeIQQ7FlBjkGxT5AbD/Pl6RQ3 lbYFB5q+UnPtxLW2UDJ1aJoO2D+KwrVmol8IPWJHeVHSrYYDit6iu3IhiDRMPsgGlfxt 6zigNcK2PlVhsUJX8mg9hJrDBFC8nh/1kMrXXM5cLlZWr+J3gQ7IY8aZiAzBTLHHGcq1 irkg== 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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f40-v6si5678718plb.504.2018.08.09.08.04.57; Thu, 09 Aug 2018 08:05:11 -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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732793AbeHIR23 (ORCPT + 99 others); Thu, 9 Aug 2018 13:28:29 -0400 Received: from mout02.posteo.de ([185.67.36.142]:36049 "EHLO mout02.posteo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732603AbeHIR22 (ORCPT ); Thu, 9 Aug 2018 13:28:28 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 1130120FAE for ; Thu, 9 Aug 2018 17:03:08 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 41mWhn2tLFz9rxL; Thu, 9 Aug 2018 17:03:05 +0200 (CEST) Subject: Re: [PATCH RESEND 2/2] gpio: mvebu: Allow to use non-default PWM counter To: Andrew Lunn , Aditya Prayoga Cc: linux-gpio@vger.kernel.org, Richard Genoud , Gregory CLEMENT , Gauthier Provost , Alban Browaeys , Thierry Reding , Linus Walleij , linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org, Dennis Gilmore , Ralph Sennhauser References: <1533522556-55055-1-git-send-email-aditya@kobol.io> <1533522556-55055-3-git-send-email-aditya@kobol.io> <20180806135257.GB6584@lunn.ch> From: Richard Genoud Message-ID: <9d12abba-0be8-bce7-45d5-99659cbe0915@sorico.fr> Date: Thu, 9 Aug 2018 17:03:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180806135257.GB6584@lunn.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 06/08/2018 15:52, Andrew Lunn wrote: > On Mon, Aug 06, 2018 at 10:29:16AM +0800, Aditya Prayoga wrote: >> On multiple PWM lines, if the other PWM counter is unused, allocate it >> to next PWM request. The priority would be: >> 1. Default counter assigned to the bank >> 2. Unused counter that is assigned to other bank >> 3. Fallback to default counter >> >> For example on second bank there are three PWM request, first one would >> use default counter (counter B), second one would try to use counter A, >> and the third one would use counter B. > > Hi Aditya > > There are only two PWM counters for all the GPIO lines. So you cannot > support 3 PWM requests. You have to enforce a maximum of two PWMs. > > When i implemented this PWM code, i only needed one PWM. So it took > the easy option. GPIO bank 0 uses counter A, GPIO bank1 uses counter > B. For the hardware you have, this is not sufficient, so you need to > generalise this. Any PWM can use any counter, whatever is available > when the PWM is requested. > > Rather than have a linked list of PWM, i think it would be better to > have a static array of two mvebu_pwm structures. Index 0 uses counter > A, index 1 uses counter B. You can then keep with the concept of > pwm->pgiod != NULL means the counter is in use. The request() call can > then find an unused PWM, set pwm->gpiod, and point mvchip->mvpwm to > one of the two static instances. > > Andrew > I'm not sure that the logic: 1. Default counter assigned to the bank 2. Unused counter that is assigned to other bank 3. Fallback to default counter is the best one. I gave the code a try, and I've been a little confused. I declared: - fan1 as gpio1 22 - fan2 as gpio1 11 - fan3 as gpio0 22 and I did: echo 10 > hwmon1/pwm1 # ok echo 100 > hwmon2/pwm1 # still ok echo 200 > hwmon3/pwm1 # hey !! my fan2 is now at 200 (I can see it with the scope) # but cat hwmon2/pwm1 100 # okay, I want my fan2 back, So I turn off fan3: echo 0 > hwmon3/pwm1 # fan2 and fan3 are stopped echo 100 > hwmon2/pwm1 # not working.. fan2 is still at 0 on the scope but: cat hwmon2/pwm1 100 IMHO, I would either: - allow only 2 pwm and no more (but that's a pity) - allow lots of fans, but once 2 different speeds are set, return EINVAL for another different speed (even if it's on another bank) That way, we'll be able to switch on/off 1, 2, 3 or more fans, as long as they have the same speed. I'll give an example : echo 10 > hwmon1/pwm1 # ok echo 100 > hwmon2/pwm1 # still ok echo 200 > hwmon3/pwm1 # returns EINVAL echo 10 > hwmon3/pwm1 # ok The headache will come when we want to change the speed... echo 50 > hwmon3/pwm1 # should this change the hwmon1 as well or return EINVAL ? I'd say that it changes hwmon1 as well, as if hwmon1 and hwmon3 were tied. But, If I then do : echo 100 > hwmon3/pwm1 # fan2 was already at 100 What should happen ? Do fan1, fan2 and fan3 be set to 100 ? Or fan1 stay at 10 and fan3 at 100 ? (in this case, fan3 won't be tied to fan1 anymore, but to fan2) Hum... I don't know if anyone followed me on this... Anyway, I think I convinced myself that only allowing 2 pwm is less confusing than anything else :) Richard.