From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
To: Phil Reid <preid@electromag.com.au>,
Wolfram Sang <wsa@the-dreams.de>,
Hans de Goede <hdegoede@redhat.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-i2c@vger.kernel.org
Subject: Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest supported clk
Date: Wed, 30 Aug 2017 10:37:33 +0300 [thread overview]
Message-ID: <6757ad09-e78d-8d36-3ae7-e2377971a0d4@linux.intel.com> (raw)
In-Reply-To: <f05a083c-c8d1-352f-d084-1ccf5e37e14c@electromag.com.au>
On 08/30/2017 04:23 AM, Phil Reid wrote:
> On 30/08/2017 05:00, Wolfram Sang wrote:
>> I don't know enough about real-world ACPI tables to suggest a best
>> practice here. I just wanted to add that busses < 100 kHz are legal from
>> how I read the specs.
>>
>> Oh well, Jarkko liked the patch, so let's all sleep over this patch and
>> if nothing else comes up, I'll apply it tomorrow or so...
>>
>
> My understanding is 100k is what the client must support.
> But sometimes buses need to be run slower.
> Particularly when using range extenders.
>
> eg: I have an i2c bus running over a 10m cable that needs to run at
> about 40k
> to be reliable.
>
I acked the patch because I see it as a possibility for a regression if
we blindly accept slower than 100 kHz speed from ACPI without validating
does that result working setup and timing parameters.
It is better to have an another patch explicitly adding support for
< 100 kHz speeds when needed.
--
Jarkko
next prev parent reply other threads:[~2017-08-30 7:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-29 12:08 [PATCH] i2c: designware: Round down ACPI provided clk to nearest supported clk Hans de Goede
2017-08-29 12:22 ` Andy Shevchenko
2017-08-29 12:52 ` Hans de Goede
2017-08-29 14:12 ` Jarkko Nikula
2017-08-29 20:18 ` Wolfram Sang
2017-08-29 20:27 ` Hans de Goede
2017-08-29 21:00 ` Wolfram Sang
2017-08-30 1:23 ` Phil Reid
2017-08-30 7:37 ` Jarkko Nikula [this message]
2017-08-31 18:29 ` Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6757ad09-e78d-8d36-3ae7-e2377971a0d4@linux.intel.com \
--to=jarkko.nikula@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=hdegoede@redhat.com \
--cc=linux-i2c@vger.kernel.org \
--cc=preid@electromag.com.au \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).