All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Reid <preid@electromag.com.au>
To: Wolfram Sang <wsa@the-dreams.de>, Hans de Goede <hdegoede@redhat.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Jarkko Nikula <jarkko.nikula@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 09:23:07 +0800	[thread overview]
Message-ID: <f05a083c-c8d1-352f-d084-1ccf5e37e14c@electromag.com.au> (raw)
In-Reply-To: <20170829210048.mqcyep22tqn7t65l@ninjato>

On 30/08/2017 05:00, Wolfram Sang wrote:
> 
>> The speed comes from an ACPI entry describing an i2c client,
>> any compliant i2c client must at least support 100KHz, right ?
> 
> Well, due to flaky board design, you may not be able to utilize the max
> speed because of interferences etc even if the devices would support it.
> Such knowledge of flaky boards could be encoded in the ACPI tables, or?
> But probably not in the client device, hmmm...
> 
>> Alternatively I could wrap the entire round-down for loop in
>> an if (acpi_speed) {} block.
> 
> 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.


-- 
Regards
Phil Reid

  reply	other threads:[~2017-08-30  1:23 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 [this message]
2017-08-30  7:37             ` Jarkko Nikula
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=f05a083c-c8d1-352f-d084-1ccf5e37e14c@electromag.com.au \
    --to=preid@electromag.com.au \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-i2c@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.