[RFC] ARM: dts: Add i2cmux-pinctrl config to Raspberry Pi i2c-0

[Dave Stevenson]

Hi Stephen

On 20 November 2017 at 17:05, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 11/20/2017 07:09 AM, Dave Stevenson wrote:
>>
>> The first i2c controller on the Raspberry Pi family can
>> be pinmuxed to either GPIOs 0&1, 28&29, or 44&45.
>> The default has always been 0&1 as those are exposed on
>> the 40 pin GPIO header of the more recent models.
>> GPIOs 28&29 on Pi 0/1/2/3 and GPIOs 44&45 on Pi3 are
>> used for i2c to the DSI display and the camera module.
>
> On the model A and B at least, pins 28/29/44/45 are used for other purposes,
> and cannot be used as I2C. It's hard/impossible to tell on the more recent
> Pis since the schematics are obscured:-( This change appears to add the I2C
> pinctrl mux to the original A/B, so at the very least needs to be modified
> not to do that. More investigation is needed to tell whether it's
> appropriate for the later models or not.

The best reference is the pin config that the firmware uses -
https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts

On the very original model A (128MB) and B (256MB), yes the camera is
on BSC1 and GPIOs 2&3 so needs to be fixed.

>> The i2c-mux-pinctrl driver allows pinctrl setup to be used
>> to expose the GPIO sets as alternate i2c adapters.
>
> Yes, i2c-mux-pinctrl does exist. However, the intent is not to expose I2C
> buses for every possible pinmux configuration, but rather to allow exposing
> multiple mux'd I2C buses /if/ there's a specific need; if it makes sense to
> do so. As far as I know, the Pi HW is designed to have a specific static
> pinmux configuration for each of the I2C controllers.
>
> Put another way: What user benefit does making this change create?

Specific case is kernel drivers for the DSI display and camera whilst
retaining the ability to use i2c0 via the main GPIO header (GPIOs
0&1).

Eric had been bitbashing I2C on 28&29 to talk to the DSI display
controller - https://github.com/anholt/linux/commit/e80d09ef0d05490296e30e33c7494f56407d7573
I have a kernel driver for talking to the CSI2 receiver block (Unicam)
that needs I2C comms to the sensor/source board. (I need to sort out
the next revision for the mailing list).

> If a user has modified their HW and changed what the pins are connected to,
> that's something user-specific. They should modify the DT themselves to
> match that HW change. However, the default/standard DT shouldn't be
> modified, since not all users will have made that HW change.
>
>> This
>> patch configures that driver to expose two adapters -
>> i2c0 on GPIOs 0&1, and i2c_csi_dsi on the correct GPIOs for
>> the camera and display.
>
>
> Looking at the schematics for the original A/B Pi, the camera should be
> controlled by the second I2C controller on GPIO pins 2/3, and the DSI port
> has no I2C. On the B+ schematics, both CSI and DSI use the same I2C
> controller, which must use some GPIOs in the second GPIO bank (and I believe
> the second I2C controller) since they aren't shown on the schematic. The 2nd
> I2C controller is typically under firmware not Linux control.

The original A/B are the exception in using BSC1 / GPIOs 2&3. All
other variants are using BSC0 on either 28&29 or 44&45 (Pi3 only). For
the original A&B we need to revert to a simple mapping of i2c0 to 0&1,
and i2c1 to 2&3.

All three I2C controllers are defined as enabled in Linux by the
default upstream DT -
http://elixir.free-electrons.com/linux/v4.14/source/arch/arm/boot/dts/bcm2835-rpi.dtsi#L47.
The firmware uses BSC0 / i2c0 for talking to the camera, display, and
HAT EEPROM (boot time only). If there is any desire for upstream to
support the camera or display then it needs to be able to communicate
with them.
The default muxing for i2c0 (the one the firmware normally uses) is to
GPIOs 0&1. If that is to remain a supported option and talk to the
display/camera then either you bit bash one of the interfaces (please
no), or need i2c-mux-pinctrl.

  Dave