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

[Stephen Warren]

On 12/12/2017 08:33 AM, Dave Stevenson wrote:
> On 11 December 2017 at 16:33, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 12/11/2017 06:55 AM, Dave Stevenson wrote:
>>>
>>> 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
>>
>>
>> Oh. I was at least partially awaiting v2 since you said there were errors
>> that needed to be fixed, so I could try and correlate it with the
>> schematics. And partially being lazy.
> 
> Ah, both waiting on each other :-/
> I was wanting some guidance as to whether anyone cared before
> investing time. It sounds like at least Eric is interested in the
> possibilities, so v2 is done.
> 
>>> 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.
>>
>>
>> On that note, can you please make sure that the schematics that the Pi
>> Foundation publishes are complete and fully consistent with that DT blob? If
>> there are errors or omissions in the schematics, that would be bad, since
>> all GPIO/pinmux/xxx work I've done, and probably many other people too, has
>> been purely based off those schematics.
> 
> Sorry, what goes into those schematics isn't my domain. They are taken
> directly from the master schematics used for manufacture, so what is
> present will be correct.

Well, I mentioned that because since you work for the Pi Foundation, you 
know who to ask to make sure the schematics can be made complete/correct.

> I will ask that future schematics do include the wiring back to the
> SoC for all GPIO connections that are exposed to the user via an
> external connector. That would clarify things like where SDA0 and SCL0
> on the camera and display connectors actually connect back to.
Great, thanks.