linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Xiang Wang <wangxfdu@gmail.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 12:40:23 +0300	[thread overview]
Message-ID: <1444902023.8361.629.camel@linux.intel.com> (raw)
In-Reply-To: <561F64A1.8030805@linux.intel.com>

On Thu, 2015-10-15 at 11:32 +0300, Jarkko Nikula wrote:
> On 10/15/2015 08:46 AM, Xiang Wang wrote:
> > 
> > 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.

Should it (ACPI walk) be done in PCI case as well? If so, then it needs
to be done up to i2c-core. There you may adjust the bus speed whenever
slave device is enumerated.

For PCI case you have still to have hardcoded values and it should be
maximum supported by the bus I think. When you have implemented above
algorithm you may do this safely. Am I missing something?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2015-10-15  9:40 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
2015-10-15  9:40             ` Andy Shevchenko [this message]
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=1444902023.8361.629.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=jarkko.nikula@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).