I2C ports

Johannes Lundberg

Hi

Can you please tell me how the 7 I2C ports are connected?
Which goes to
PMIC?
I2C0 and I2C1 on 40-pin header?
GPU?
MIPI connectors?

Johannes Lundberg

I'm gonna reply to myself here.
I've got some progress in getting *BSD up and running on UP. What I am missing the the configuration of the 40-pin header's I/O ports on the pca9555 chips. Is the source available for the pca95555/up-pinctrl drivers available or some other documentation for how these are wired?

Thanks!

[Deleted User]

HI,

I2C0 and I2C1 goes to CPLD and from there to 40pin connector; as you don't have access to CPLD code, you cannot have access to 40pin connector.
I2C6 for PMIC (Dollar)
I2C4 for HDMI
I2C2 for MIPI DSI and MIPI CSI

Johannes Lundberg

Thanks!

As I understand it my version of the board doesn't have the CPLD but instead two PCA9555's.
However, the final version will have the CPLD so this raises a concern since you say I can not use the 40 pin header without the code (firmware?).

Questions
Does this mean it is impossible to use any of the 40 pins on another operating system?
Would it work with porting the Linux driver or do I need some firmware code that is proprietary?
Is it possible to get a firmware binary to upload to the CPLD if necessary?

[Deleted User]

there is a misunderstanding (my fault)

I2C0(1.8V) and I2C1(1.8V) from CPU are sent to two separate PCA9306 (Voltage Level Translator 1.8V to 3.3V) connected to UP-board external 40-pin connector (GP); such Voltage Level Translators are driven CPLD MAX-V which is programmed by Linux/driver-CPLD
You can enable the I2C0 and I2C1 ports to the 40pins connector ONLY if you can port Linux/Driver-CPLD in BSD; but we dont provide such drivers to the community (ask for them in a separate 3D inside the SW Q/A)

All UP-board integrates CPLD which is used as Voltage Level Translator for ALL PINS/PORTs expect the I2C0 and I2C1 which uses PCA voltage level translator.

Javier Arteaga

aaeon wrote:

You can enable the I2C0 and I2C1 ports to the 40pins connector ONLY if you can port Linux/Driver-CPLD in BSD; but we dont provide such drivers to the community (ask for them in a separate 3D inside the SW Q/A)

Just to clarify here, we do provide sources for the Linux platform driver that interacts with the CPLD. What we don't provide is an official BSD port. If anyone wants to give porting a go (which would be much appreciated!), the Linux driver is available from multiple sources:

[ul]
[li]ubilinux kernel source package: from a ubilinux system, run:

apt-get source linux-ubilinux

[/li]
[li]Yocto layer repository: https://github.com/emutex/meta-up-board/tree/krogoth/recipes-kernel/linux/files[/li]
[li]Ubuntu kernel sources: https://launchpad.net/~ubilinux/+archive/ubuntu/up/+packages[/li]
[/ul]

Regards

Johannes Lundberg

Thanks guys.

This is great info. I will start working on porting when I get the v0.4 boards.

Just one question, when I configure the GPIO pins in software, like changing direction of the pin, etc, I manipulate values in the SoC's GPIO registers. Do I also have to configure the CPLD at the same time to let it know that the pin has changed direction? If so, how can I do this?

Javier Arteaga

Johannes wrote:

Just one question, when I configure the GPIO pins in software, like changing direction of the pin, etc, I manipulate values in the SoC's GPIO registers. Do I also have to configure the CPLD at the same time to let it know that the pin has changed direction? If so, how can I do this?

Yes. Take a look at /drivers/platform/x86/up_board_pinctrl.c on a patched tree for the way this is done in Linux.

Johannes Lundberg

jarteaga wrote:

Yes. Take a look at /drivers/platform/x86/up_board_pinctrl.c on a patched tree for the way this is done in Linux.

Thanks, that's great! Do you have a patched tree somewhere online or do I need to get the patches and do it myself (I have found the 5 submitted kernel patches online)?

Javier Arteaga

I don't think we serve a pre-patched tree as a repository yet.

For now, [tt]apt-get source linux-ubilinux[/tt] should generate it for you. You could also directly get the latest linux-ubilinux-source .deb package, which contains a pre-patched tarball.

Regards

Elie De Brauwer

I've been doing some experimenting by myself.
I have a recent Linux kernel (earlier 4.6 but switched to 4.7 today) and the i915 driver there provides you with 6 i2c busses on its own:

root@c:/sys/bus/i2c/devices# for i in `seq 0 6`; do echo Bus i2c-$i - name: `cat i2c-$i/name`; done 
Bus i2c-0 - name: i915 gmbus ssc
Bus i2c-1 - name: i915 gmbus vga
Bus i2c-2 - name: i915 gmbus panel
Bus i2c-3 - name: i915 gmbus dpc
Bus i2c-4 - name: i915 gmbus dpb
Bus i2c-5 - name: i915 gmbus dpd
Bus i2c-6 - name: DPDDC-D

And when I run i2c-detect on bus 2, I cant retrieve the EDID of the HDMI panel connected to my board.

I am however facing some more trouble with the *other* i2c busses and the pincontroller. I initially started by applying the patches of the yocto layer to Linux 4.7 but then ended in a situation where I was still stuck at a situation where I had only the 6 i2c buses shown above, this while some other functionality (the 3 onboard LEDs for example) connected through the CPLD are functioning, and the 28 GPIO's are appearing through sysfs. So far so good.

The problem at this point is that the 'extra' i2c busses are not appearing on the system. From ubilinux I derived that CONFIG_I2C_DESIGNWARE_PLATFORM should be the correct driver. (Although CONFIG_MFD_INTEL_LPSS_ACPI is also advertising the same IDs). Anyhow none of the above resulted in extra i2c busses on my board. The only this which does something is in the BIOS switching the mode of the I2C controllers from ACPI to PCI and enabled CONFIG_I2C_DESIGNWARE_PCI, the result is that you get a bunch of these

00:18.1 Serial bus controller [0c80]: Intel Corporation Braswell Serial I/O I2C Port 1 (rev 36)
00:18.2 Serial bus controller [0c80]: Intel Corporation Braswell Serial I/O I2C Port 2 (rev 36)
00:18.3 Serial bus controller [0c80]: Intel Corporation Braswell Serial I/O I2C Port 3 (rev 36)
00:18.5 Serial bus controller [0c80]: Intel Corporation Braswell Serial I/O I2C Port 5 (rev 36)
00:18.6 Serial bus controller [0c80]: Intel Corporation Braswell Serial I/O I2C Port 6 (rev 36)
00:18.7 Serial bus controller [0c80]: Intel Corporation Braswell Serial I/O I2C Port 7 (rev 36)

And extra busses in /sys/ , and a functioning PCI driver. However first experiments show that the designware driver does not implement the needed function to scan the I2C bus, but I also doesn't seem to pick up an i2c device I attached to it.

Anybody got any point why picking up ACPI devices seems troublesome on my system ? (I needed to apply the same trick to get the EMMC on my custom kernel to be get detected), is there some magical config option I might be missing ? And could it be that the pinctrl/pinmuxing does not play nice with the designware pci module ?

Elie De Brauwer

Okay, I got a bit further myself, this time I started from the ublinux tarball and that way I mananged to the i2c ports to work. The only extremely annoying is that the designware i2c controller does not support 'i2cdetect'.

Another issue I bumped into is when building a monolithic kernel, where the i915 module is compiled in, this fights with the 0005-i2c-designware-platdrv-use-fixed-bus-numbering-based.patch and I had to revert this. The point is that the i915 module gets loaded first, which in the end causes i2c_add_numbered_adapter to fail. This is not seen in ubilinux since i915 is loaded as a module after the i2c-0 and i2c-1 numbers are being allocated.

The effect of rolling this patch back, is that the i2c busses don't end up as 'i2c-0' and 'i2c-1' but rather i2c-11 and i2c-12, but for me that's merely cosmetic.

When I have some time I'll try to re-apply these changes on 4.7.