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

[Dave Stevenson]

On 8 December 2017 at 21:16, Eric Anholt <eric at anholt.net> wrote:
> Dave Stevenson <dave.stevenson at raspberrypi.org> writes:
>
>> 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.
>>
>> The i2c-mux-pinctrl driver allows pinctrl setup to be used
>> to expose the GPIO sets as alternate i2c adapters. 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.
>> (This could be extended to expose all 3 options on the CM
>> and CM3, but there isn't a pressing case for that at present).
>>
>> The one quirk with the i2cmux-pinctrl driver is that the
>> parent controller still exists as an i2c adapter which
>> will be connnected to whichever pins were last requested
>> (or an optional idle setting). That adapter appears first so
>> is numbered as adapter 0, whilst the child ports end up as
>> adapters 3&4. These can be renumbered through using DT aliases
>> if we wish to retain the ordering of adapters (this will be
>> required downstream).
>>
>> Signed-off-by: Dave Stevenson <dave.stevenson at raspberrypi.org>
>> ---
>>
>> Hi All.
>>
>> Thoughts from people?
>> Do others care about access to the alternate pin muxing options for BSC0?
>> Is the location of these changes acceptable?
>> Objections on naming of nodes?
>>
>> To get back to the current adapter numbering, an aliases section
>> such as
>> / {
>>        aliases {
>>                i2c10 = &i2c0_parent;
>>                i2c0 = &i2c0;
>>                i2c1 = &i2c1;
>>                i2c2 = &i2c2;
>>                i2c4 = &i2c_csi_dsi;
>>        };
>> };
>> is needed somewhere. Yes i2c1 and i2c2 are needed otherwise they
>> become i2c11 and i2c12 as dynamically numbered adapters come after
>> all statically defined ones.
>
> I'm interested in landing this patch, so that we can use it for the
> camera and DSI support.  Do we have objections or other feedback at this
> point?  Should we include the aliases node in our DT?

I was holding off on fully reworking it for the original model A and
B's awaiting Stephen's followup from
> I haven't read and understood Dave's response to mine to see if we really do need I2C muxing, but if we do, then i2c-mux-pinctrl is certainly the correct approach to implement it.

I did about 70% of the work for it sorting the A&B, so I'll finish
that off and aim to get a v2 out tomorrow.

  Dave