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

[Dave Stevenson]

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.
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.

The dt-blob is maintained to be consistent with the hardware,
otherwise the firmware won't work. Any errors that have crept in have
generally been picked up and corrected quickly. (The only one I can
really think of was that the two camera GPIOs got swapped over in the
config).

  Dave