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

[Andrew Jeffery <andrew@aj.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

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?

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).

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]