Bug 6696

LPSS devices used to be enumerated as PCI, in PCI device instance follows the function number which is 0-based. By default LPSS supposed to be enumerated as ACPI to help all OSes, in ACPI DSDT I2C controllers are named I2C1-I2C7. While this might be confusing, at the same time this is the same scheme all BYT-based platforms follow so I'd suggest to keep it this way as it will make it less confusing for developers supporting different boards (Sharks Cove is one example).

In the hardware the two I2C devices are hardware devices 5 & 6 (zero relative, which matches the PCI enumeration).  LPSS is following the ACPI (one relative numbers).   Same devices just new designations.

The question becomes one of expectation across developers.  If there is consensus across the community, the enumeration could be manipulated to meet that consensus, but if there is some debate, then any change (or not) will not meet all expectations.  

Agreeing with Ivan on this one, the one relative count seems to be more standard across the Baytrail implementations.

Ok so this boils down to an expected change, but something that needs to get documented since all our public documentation currently refers to those as #5 and #6 respectively, correct?

Yes, I agree. I am not however sure what is the documentation for ACPI declarations. In production systems ACPI is often considered essentially self-documenting - DSDT is the documentation. But I 100% agree this can (and as we saw already) does get confusing.

There is more here than ACPI verse LPSS:

5 & 6 (the zero relative numbers) are also the designations in the schematic - per the SoC specification.  So somebody looking at the schematic could be confused as well (that is what lead me down the bunny trail).

In the documentation it should be noted that ACPI is one relative and that some devices may be designated by one value higher than the zero relative hardware designation (which is also the PCI enumeration, and could be the LPSS designation).

I agree, it's just where do we document ACPI numbering?
Despite how confusing it is, I really would prefer ACPI on MinnowBoard MAX to stay consistent with all other BYT-based programs.

Rather than worry about which numbering scheme is used for ACPI and PCI (neither of which impacts the programming interface), why not just use something that makes semantic sense to the end user, like:

"Low Speed Expansion I2C"

and

"High Speed Expansion I2C"

This is no _DDN, this is actual name if the device as in Device(XXXX) ACPI statement. Per ACPI Spec 5.3 "All names are a fixed 32 bits.", so only 4 characters can be used for the name.

Ivan, I think you are confused on where we want this statement.  Specifically we want this shown in the firmware menu, that's where this change happened.  I don't really care what's in the ACPI table, assuming that it hasn't changed as well (which it doesn't look like it has under Linux)

Right now the menu says:

LPSS I2C #5 Support  [Enable]
LPSS I2C #6 Support  [Enable]

My original question was, why did those numbers changed to 6 & 7 respectively in 0.73 (might be earlier I'm not sure)

And Darren is suggesting instead of the lines mentioned he wants

Low Speed Expansion I2C   [Enable]
High Speed Expansion I2C  [Enable]

which I've got a small modification of

Low Speed Expansion I2C (#5)  [Enable]
High Speed Expansion I2C (#6) [Enable]

Ah!
You are right, I did not get it.

Yes, makes perfect sense to me. Maybe help could mention which header it is on.
But in any case - sure, this makes sense. Sorry, I did not get it.

BIOS team Update:

Fixed. Will be available in next release. 

Item - Low Speed Expansion I2C (#5)  [Enable]
Help - I2C Controller PCI device Dev24: Func6  ; Schematic names it I2C5, ACPI table names it I2C6.

Item - High Speed Expansion I2C (#6) [Enable]
Help - I2C Controller PCI device Dev24: Func7 ;  Schematic names it I2C6, ACPI table names it I2C7.

Confirmed fixed in Firmware 0.74.