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

Eric Anholt eric at anholt.net
Fri Dec 8 13:16:14 PST 2017

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20171208/f04cf0d9/attachment.sig>

More information about the linux-rpi-kernel mailing list