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

[Stephen Warren]

On 11/20/2017 12:43 PM, Stefan Wahren wrote:
> Hi Dave,
> 
>> Dave Stevenson <dave.stevenson at raspberrypi.org> hat am 20. November 2017 um 15:09 geschrieben:
>>
>>
>> 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?
> 
> i'm not sure that i understood complete issue. This seems to be a RPi specific problem.
> So you want to add a new driver for a "virtual" muxing in order to use csi/dsi?
> 
> Do you think the issue could be fixed with the following DT part (example)
> 
> &i2c0 {
>          pinctrl-names = "default", "dsi_csi";
>          pinctrl-0 = <&i2c0_gpio0>;
>          pinctrl-1 = <&i2c0_gpio44>;
>          compatible = "raspberrypi,bcm2835-i2c0";
>          status = "okay";
>          clock-frequency = <100000>;
> };
> 
> and extending the i2c driver with the necessary pinctrl handling instead?

i2c-mux-pinctrl was explicitly developed to avoid the need for 
individual I2C drivers having to do this themselves. 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.