On Tue, Dec 22, 2015 at 02:51:13PM -0600, Suravee Suthikulanit wrote:
> So, at this point, I can re-submit the V3 and combine these changes, and we
> both can sign-off. How does that sound?
Sounds good to me :)
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of
Hi Mika,
On 12/18/2015 4:13 AM, Mika Westerberg wrote:
[]
So instead of this, what if we do not assign dev->get_clk_rate_khz at
all and then do something like below in the core driver?
I like the changes below since it is clear to see within the core file
how things are handled when get_c
On Wed, Dec 16, 2015 at 08:23:45PM -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 information.
> Instead, we ca
On 12/16/2015 8:56 PM, Loc Ho wrote:
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
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
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 directly provid
