lkml.org 
[lkml]   [2018]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] mfd: lochnagar: Add support for the Cirrus Logic Lochnagar
On Sun, Sep 16, 2018 at 06:11:08PM -0500, Rob Herring wrote:
> On Thu, Sep 06, 2018 at 03:48:34PM +0100, Charles Keepax wrote:
> > On Thu, Sep 06, 2018 at 03:46:12PM +0200, Linus Walleij wrote:
> > > On Wed, Sep 5, 2018 at 12:41 PM Charles Keepax
> > > <ckeepax@opensource.cirrus.com> wrote:
> > > It's a bit confusing, maybe you can clear it up:
> > > it appears to be an I2C device, so when you say this is a
> > > "development board" is there something like a board
> > > controller that is accessed over I2C and this is what the
> > > driver really probes to, not the board per se?
> > >
> > > I guess jamming this card into the I2C slot of any other
> > > system (would work fine with a 96Boards LS connector
> > > as it seems, actually) also involves connecting some
> > > I2S or similar on the side for high-datarate traffic?
> > >
> > > This driver seems to only concern itself with the I2C
> > > board controller per se, not the board is that right?
> > >
> >
> > Yeah I have poorly phrased that, these patches are very much
> > just dealing with the board controller chip.
>
> How would the codec I2C connect to the host? Is there one I2C bus or
> 2? The binding looks mostly fine to me, but I think we need to
> understand that part.
>

If the CODEC is I2C based then both the CODEC and the controller
IC will be on the same I2C bus. If the CODEC is connected over
SPI that is obviously a separate bus as the board controller
chip is I2C only.

There are some additional I2C interfaces but they are not
currently used on any mini-cards, and they are intended for
secondary purposes not control of the CODEC itself.

Thanks,
Charles

\
 
 \ /
  Last update: 2018-09-17 15:50    [W:0.111 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site