On Wed, 2018-05-09 at 11:50 +0800, Lei YU wrote: > On Wed, May 9, 2018 at 11:43 AM, Guenter Roeck <linux@xxxxxxxxxxxx> 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. Another option is to give *both* clock sources in the DT, since in HW they both eventually reach the IP block, and have the driver select which one it wants to use (that itself can also be in the DT). That way you can select 0 if you want and still use clk_get_rate() to know how fast it's ticking. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
