[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAARXrt=ZA7sz_CvNUxHRvie3YfErU-5d5ewHry=mgxb6Uz-+TA@mail.gmail.com>
Date: Wed, 9 May 2018 11:50:34 +0800
From: Lei YU <mine260309@...il.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Jean Delvare <jdelvare@...e.com>, Joel Stanley <joel@....id.au>,
Andrew Jeffery <andrew@...id.au>,
Hardware Monitoring <linux-hwmon@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org,
linux-aspeed@...ts.ozlabs.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] hwmon: (aspeed-pwm-tacho) Use 24MHz clock
On Wed, May 9, 2018 at 11:43 AM, Guenter Roeck <linux@...ck-us.net> wrote:
>
> I am not going to accept this change, period. This is not one, it is five
> steps
> backward. If "aspeed_set_clock_source(priv->regmap, 0)" changes the clock
> speed,
> or the clock source, read it later, and attach to the correct clock. If that
> doesn't work, fix the problem in the clock subsystem. Hacking the driver is
> just
> plain wrong.
>
> Also, if the idea in DT is to provide a different clock to the watchdog on
> purpose,
> maybe the call to "aspeed_set_clock_source(priv->regmap, 0)" is wrong.
Exactly!
My first change (not sent to mailing list) is to remove the call of
"aspeed_set_clock_source(priv->regmap, 0)", instead, checking the clock
source, and use either 24M or the memory controller clock.
But that make things a bit more complicated and Aspeed suggests to use 24M
clock. So I sent this simplified change.
It's OK to not accept this change, the fix in DT will fix the issue as well.
Please drop this.
Thanks!
Powered by blists - more mailing lists