From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7E50C433E1 for ; Tue, 9 Jun 2020 11:29:07 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B68E720812 for ; Tue, 9 Jun 2020 11:29:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B68E720812 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4FCBF6E03F; Tue, 9 Jun 2020 11:29:07 +0000 (UTC) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 653906E03F; Tue, 9 Jun 2020 11:29:06 +0000 (UTC) IronPort-SDR: z3uNnNs1u3hjdesULGWj4DZCg16qtuSLXBhOwLTxq0Ozw8n+OFIseh88QnKw5mUPGbMuUpP8Nx 6fABO3eonGEA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2020 04:29:05 -0700 IronPort-SDR: I9ZI5hVQJ8gIbUCnBOMI/UzhZ+Gbu7ciNfFaR4ypZ3pNkt8/JldgZKH6f5wcN4DYB5hfT0N6q7 Q1OEIaoCb5DA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,491,1583222400"; d="scan'208";a="270862142" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga003.jf.intel.com with ESMTP; 09 Jun 2020 04:29:02 -0700 Received: from andy by smile with local (Exim 4.93) (envelope-from ) id 1jicRF-00Bt4F-B4; Tue, 09 Jun 2020 14:29:05 +0300 Date: Tue, 9 Jun 2020 14:29:05 +0300 From: Andy Shevchenko To: Hans de Goede Message-ID: <20200609112905.GK2428291@smile.fi.intel.com> References: <20200607181840.13536-1-hdegoede@redhat.com> <20200607181840.13536-7-hdegoede@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200607181840.13536-7-hdegoede@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Subject: Re: [Intel-gfx] [PATCH v2 06/15] pwm: crc: Fix period / duty_cycle times being off by a factor of 256 X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-pwm@vger.kernel.org, intel-gfx , "Rafael J . Wysocki" , linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org, Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Mika Westerberg , Len Brown Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Sun, Jun 07, 2020 at 08:18:31PM +0200, Hans de Goede wrote: > While looking into adding atomic-pwm support to the pwm-crc driver I > noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and > there is a clock-divider which divides this with a value between 1-128, > and there are 256 duty-cycle steps. > > The pwm-crc code before this commit assumed that a clock-divider > setting of 1 means that the PWM output is running at 6 MHZ, if that > is true, where do these 256 duty-cycle steps come from? > > This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that > seems unlikely for a PMIC which is using a silicon process optimized for > power-switching transistors. It is way more likely that there is an 8 > bit counter for the duty cycle which acts as an extra fixed divider > wrt the PWM output frequency. > > The main user of the pwm-crc driver is the i915 GPU driver which uses it > for backlight control. Lets compare the PWM register values set by the > video-BIOS (the GOP), assuming the extra fixed divider is present versus > the PWM frequency specified in the Video-BIOS-Tables: > > Device: PWM Hz set by BIOS PWM Hz specified in VBT > Asus T100TA 200 200 > Asus T100HA 200 200 > Lenovo Miix 2 8 23437 20000 > Toshiba WT8-A 23437 20000 > > So as we can see if we assume the extra division by 256 then the register > values set by the GOP are an exact match for the VBT values, where as > otherwise the values would be of by a factor of 256. > > This commit fixes the period / duty_cycle calculations to take the > extra division by 256 into account. ... > +#define NSEC_PER_MHZ 1000 This is against physics. What this cryptic name means actually? Existing NSEC_PER_USEC ? -- With Best Regards, Andy Shevchenko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx