Hi,
> The current driver uses input clock source frequency to calculate
> values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
> currently have a good way to provide the frequency information.
> Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used
> to
Hi Mika,
On 12/16/2015 03:42 AM, Mika Westerberg wrote:
+Jarkko and Andy
On Tue, Dec 15, 2015 at 04:38:58PM -0600, Suravee Suthikulpanit wrote:
The current driver uses input clock source frequency to calculate
values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
On Wed, Dec 16, 2015 at 08:44:34AM -0600, Suravee Suthikulpanit wrote:
> I am trying to avoid having to hard-coded clock frequency value in the
> driver. Would it be alright to not return w/ error, and just do the
> following?
>
> dev->clk = devm_clk_get(>dev, NULL);
> if
On Wed, Dec 16, 2015 at 08:11:12AM -0600, Suravee Suthikulpanit wrote:
> >The clk framework should work fine if the returned clock is NULL (which
> >I think is your case).
> >
> >The driver gates clocks when the device is suspended and on Intel LPSS
> >there actually is a clock that gets gated.
>
On 12/16/2015 08:28 AM, Mika Westerberg wrote:
On Wed, Dec 16, 2015 at 08:11:12AM -0600, Suravee Suthikulpanit wrote:
The clk framework should work fine if the returned clock is NULL (which
I think is your case).
The driver gates clocks when the device is suspended and on Intel LPSS
there
+Jarkko and Andy
On Tue, Dec 15, 2015 at 04:38:58PM -0600, Suravee Suthikulpanit wrote:
> The current driver uses input clock source frequency to calculate
> values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
> currently have a good way to provide the frequency
