From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
To: Xiang Wang <wangxfdu@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: xiang.a.wang@intel.com, wsa@the-dreams.de,
linux-i2c@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv
Date: Thu, 15 Oct 2015 11:32:33 +0300 [thread overview]
Message-ID: <561F64A1.8030805@linux.intel.com> (raw)
In-Reply-To: <CACDNBm38bC+tP2S3WgUJJVRUppYF3=aUXvRtWfqfpM=BHapN9A@mail.gmail.com>
On 10/15/2015 08:46 AM, Xiang Wang wrote:
> 1. "bus speed mode" is a bit different from other parameters. Actually
> it can be determined by the speed setting of "i2c devices" in ACPI
> (I2CSerialBus). E.g. If i2c device uses 3MHz, we use High-speed mode
> for this i2c bus.
> 2. If we hardcode speed setting in pci driver, we lose the
> flexibility. A high-speed device may be connected to this i2c bus on
> this board, but may be connected to another i2c bus on another board
> design.
>
> In this patch, we enumerate the i2c device in ACPI table to determine
> the frequency setting. Then we set corresponding speed mode for this
> i2c controller. The ACPI stuff is common for pci and plat driver. If
> board design changes, we only change BIOS.
>
> In conclusion, we have 2 solutions to set the i2c controller speed
> mode (pci driver):
> 1) use hardcode value in pci driver
> 2) use frequency setting of "i2c device" in ACPI table (more flexible,
> but looks a bit strange)
>
> Do you have any preference/suggestions for above solutions? Thanks
I don't think we can hard code especially the high-speed mode because
most typically buses are populated with slower devices.
Things are a bit more clear when ACPI provides timing parameters for the
bus (for standard and fast speed modes at the moment in
i2c-designware-platdrv.c: dw_i2c_acpi_configure()) but still I think the
ACPI namespace walk may be needed against potential BIOS
misconfigurations. For instance if it provides timing parameters for all
speeds but there are devices with lower speed on the same bus.
I'd take these timing parameters as configuration data for bus features
but actual speed (speed bits in IC_CON register) is defined separately.
To me it looks only way to achieve that is to pick slowest device from
I2cSerialBus resource descriptors.
--
Jarkko
next prev parent reply other threads:[~2015-10-15 8:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 8:47 [PATCH 1/2] i2c: designware: add High-speed mode support wangxfdu
2015-10-09 8:47 ` [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv wangxfdu
2015-10-09 9:31 ` Andy Shevchenko
2015-10-12 7:41 ` Xiang Wang
2015-10-12 8:31 ` Andy Shevchenko
2015-10-15 5:46 ` Xiang Wang
2015-10-15 8:32 ` Jarkko Nikula [this message]
2015-10-15 9:40 ` Andy Shevchenko
2015-10-22 1:44 ` Xiang Wang
2015-10-23 20:04 ` Wolfram Sang
2015-10-09 9:29 ` [PATCH 1/2] i2c: designware: add High-speed mode support Andy Shevchenko
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=561F64A1.8030805@linux.intel.com \
--to=jarkko.nikula@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wangxfdu@gmail.com \
--cc=wsa@the-dreams.de \
--cc=xiang.a.wang@intel.com \
/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).