[PATCH 2/3] aspeed/g5: helper SCU functions for configuring aspeed I2C

[Maxim Sloyko]

On Thu, Sep 29, 2016 at 6:49 PM, Andrew Jeffery <andrew at aj.id.au> wrote:

> On Thu, 2016-09-29 at 11:23 -0700, Maxim Sloyko wrote:
> > > > +       /* Enable I2C Controllers */
> > > > +       clrbits_le32(AST_SCU_BASE + AST_SCU_RESET, SCU_RESET_I2C);
> > > > +
> > > > +       if (num < 3) {
> > >
> > > How do we enable buses number 1 and 2 when AST_SOC_G5 is not set?
> > I don't know. My guess is we don't, as in, the pins are always
> > assigned these functions. In datasheet these bits in PIN CTRL8
> > register are marked as "new in ast2500" and there is no mention of
> > sda{1,2},scl{1,2} in ast2500 datasheet.
> > Also, this part is basically taken from aspeed's sdk, this is why I
> > assume they are always on.
>
> So to clarify, the AST2400 has (SCL1, SDA1) and (SCL2, SDA2) on fixed
> function pins: (K21, K22) and (J19, J18) respectively. I don't have the
> datasheets for earlier releases of the AST SoCs, so can't speak for
> them. The AST2500 has (SCL1, SDA1) and (SCL2, SDA2) on multi-function
> pins: (M18, M19) and (M20, P20) respectively.
>
> As an aside: In AST2500 case I2Cs 1 and 2 are only multiplexed with
> GPIO and are at a higher priority, so we don't need to flip any other
> bits to enable I2C.
>
> Maybe there should be some comments along these given the code looks
> odd at first glance?
>

Added comment.


>
> Cheers,
>
> Andrew
>
> Separately: This code makes me glad I took a data-driven approach for
> the Linux pinmux driver (not to say that result is beautiful either,
> but I don't want even begin to imagine the maze of conditionals
> protecting corner cases).




-- 
*M*axim *S*loyko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161003/d6560f08/attachment.html>