Re: Intel Atom I2C

From: Lundberg, Johannes <johannes_at_brilliantservice.co.jp>
Date: Sun, 19 Jun 2016 12:23:14 -0700
Hi Ian

Thanks for the info. I'll give it a try and see if I have more success.

I'm still uncertain about the role of the DMA controller though. If data
has to be relayed through it or if using it is optional..

Maybe some further testing will reveal the truth..

On Sunday, June 19, 2016, Ian Lepore <ian_at_freebsd.org> wrote:

> On Sun, 2016-06-19 at 11:36 -0700, Lundberg, Johannes wrote:
> > Hi
> >
> > I am trying to figure out how to get I2C support on Intel Atom x5
> > (Cherryview), which should be same for Baytrail platforms.
> >
> > On the Serial I/O device (PCI device 24) there are 8 devices.
> > #0 is DMA controller
> > #1-7 are I2C controllers (1 & 2 available on GPIO pins).
> >
> > I assume that all traffic to/from the I2C controllers must go via the
> > DMA
> > controller although I'm not 100% sure.
> >
> > In page 23 in the atom-z8000-datasheet-vol-2 there is a nice table of
> > the
> > PCI configuration space.
> >
> > On Linux they have
> > i2c/busses/i2c-designware-*
> > and
> > dma/dw/*
> > that takes care of the I2C and DMA parts.
> >
> > The ichiic (ig4) driver seems to be working on this platform and
> > looking
> > through the registers it seems to be basically the same as i2c
> > -designware
> > driver, but it doesn't not detect any devices on the I2C bus
> > (/dev/smbx).
> > (I have confirmed that the devices are recognized on Linux on the
> > same
> > device.)
> >
>
> There is no way to automatically detect devices on an i2c bus.  You
> can, with some incomplete success, detect which addresses are in use.
>  Even when you can detect there is a device at a given address, there
> is no way to figure out what that device is (and in some rare cases,
> even probing for the address being in use can perturb the device).
>
> So, in the linux case, something must be telling the OS which drivers
> to attach to which addresses.  I have no idea what that mechanism might
> be, if it's not FDT.
>
> In freebsd, you can specify i2c devices using FDT data, or hints.
>
> -- Ian
>
> > We also need a Mailbox (IOSF-SB MBI) driver and it is quite simple so
> > I
> > have already ported this.
> >
> > What is left to do I guess would be to implement a DMA driver that
> > works
> > with ig4 or create a new ig4 driver that is extended to use the DMA
> > controller, and implement the DMA controller driver.
> >
> > Implementing from scratch would be quite the undertaking. Can we
> > leverage
> > any existing DMA infrastructure for this?
> >
> > Any one interested in helping?
> >
> > I have a board called "UP" which is very similar to Raspberry Pi but
> > Intel
> > SoC. It has IC20 and IC21 available on the 40-pin connector.
> > Since it's Intel most stuff just works. Thanks to mmacy accelerated
> > graphics is also working (on separate branch).
> > It really is a great board for anyone who likes to tinker :)
> >
> >
> > References:
> > http://www.up-board.org/
> > http://lxr.linux.no/#linux+v4.6.2/drivers/i2c/busses
> > http://lxr.linux.no/#linux+v4.6.2/drivers/dma/dw
> > http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat
> > asheet-vol-1.html
> > http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat
> > asheet-vol-2.html
> >
> > Other TODO stuff:
> > Port Imer's GPIO driver from DragonFly
> > Add support for S0ix sleep states (would be useful for all new Intel
> > low
> > power laptops since Haswell)
> > And more...
> >
> > Thanks!
> > /Johannes
> >
>


-- 
Sent from Gmail Mobile

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について:この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
Received on Sun Jun 19 2016 - 17:23:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC