[U-Boot] [PATCH v2 2/3] sunxi: Complete i2c support for each supported platform

[Simon Glass]

Hi,

On 6 April 2015 at 02:43, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi Simon and Paul,
>
> On 05-04-15 22:56, Paul Kocialkowski wrote:
>>
>> Le dimanche 05 avril 2015 à 12:31 -0600, Simon Glass a écrit :
>>>
>>> Hi Paul,
>>>
>>> On 4 April 2015 at 14:49, Paul Kocialkowski <contact at paulk.fr> wrote:
>>>>
>>>> Sunxi platforms come with at least 3 TWI (I2C) controllers and some
>>>> platforms
>>>> even have up to 5. This adds support for every controller on each
>>>> supported
>>>> platform, which is especially useful when using expansion ports on
>>>> single-board-
>>>> computers.
>>>>
>>>> Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
>>>> ---
>>>>   arch/arm/include/asm/arch-sunxi/cpu_sun4i.h |  7 +++
>>>>   arch/arm/include/asm/arch-sunxi/gpio.h      | 15 +++++-
>>>>   arch/arm/include/asm/arch-sunxi/i2c.h       | 13 +++++
>>>>   board/sunxi/Kconfig                         | 31 ++++++++++++
>>>>   board/sunxi/board.c                         | 75
>>>> ++++++++++++++++++++++++++++-
>>>>   5 files changed, 138 insertions(+), 3 deletions(-)
>>>>
>
> <snip>
>
>
>>>> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
>>>> index ccc2080..d3b5bad 100644
>>>> --- a/board/sunxi/Kconfig
>>>> +++ b/board/sunxi/Kconfig
>>>> @@ -269,6 +269,37 @@ config USB2_VBUS_PIN
>>>>          ---help---
>>>>          See USB1_VBUS_PIN help text.
>>>>
>>>> +config I2C1_ENABLE
>>>> +       bool "Enable I2C/TWI controller 1"
>>>> +       default n
>>>> +       ---help---
>>>> +       This allows enabling I2C/TWI controller 1 by muxing its pins,
>>>> enabling
>>>> +       its clock and setting up the bus. This is especially useful on
>>>> devices
>>>> +       with slaves connected to the bus or with pins exposed through
>>>> e.g. an
>>>> +       expansion port/header.
>>>> +
>>>> +config I2C2_ENABLE
>>>> +       bool "Enable I2C/TWI controller 2"
>>>> +       default n
>>>> +       ---help---
>>>> +       See I2C1_ENABLE help text.
>>>> +
>>>> +if MACH_SUN6I || MACH_SUN7I
>>>> +config I2C3_ENABLE
>>>> +       bool "Enable I2C/TWI controller 3"
>>>> +       default n
>>>> +       ---help---
>>>> +       See I2C1_ENABLE help text.
>>>> +endif
>>>> +
>>>> +if MACH_SUN7I
>>>> +config I2C4_ENABLE
>>>> +       bool "Enable I2C/TWI controller 4"
>>>> +       default n
>>>> +       ---help---
>>>> +       See I2C1_ENABLE help text.
>>>> +endif
>>>
>>>
>>> It seems wrong to me to add these when they are already in the device
>>> tree for the board. Can we not use that?
>>
>>
>> Well, Hans has a point when saying that some users may use those pins as
>> GPIO while some others may use the TWI/I2C functions, so it makes sense
>> to make this configurable via Kconfig instead of being statically
>> defined.
>>
>>> If you would rather wait until we have driver model I2C on sunxi
>>> (mvtwsi, I think) then I'd be happy to do the conversion. It's pretty
>>> easy.
>>
>>
>> I would be happy to see U-Boot on sunxi use devicetree and driver model
>> for TWI/I2C as well (provided users can still configure what busses to
>> enable). Still, I'd like to see this getting merged as a short term
>> solution.
>>
>>> How can we get sunxi moved over before there is an explosion of these
>>> sorts of things (as we have already seen with video options)?
>
>
> I fully support moving sunxi over the devicemodel + devicetree in my
> mind the following steps need to be taken:
>
> 0) Get the devicemode usb patches merged in to u-boot-dm/next
>    Then on top pf u-boot-dm/next:
>
> 1) Move all the sunxi boards over to use dm + dt like we're already
>    doing for the pcduino

This could be a bit tricky unless someone has all the boards. I
suppose if we do it at the very start of the merge window and then we
have time to fix any problems.

>
> 2) Start using dm for usb on sunxi
>
> 3) Enable ohci support on sunxi boards next to ehci

That's not currently supported, but I could perhaps take a look at it.

>
> 4) Move other stuff over on a step by step basis
>
> Note that we will likely have a mix of Kconfig + devicetree for
> quite a while though since certain things which we support in
> u-boot are not supported in the kernel yet so they do not have
> stable devicetree bindings yet, video being the big one here.

Yes that makes things tricky.

>
>> I think Hans will know better (than myself) how to do this right.
>
>
> Not really, other then having the the generic outline above in my head,
> I do not really have much experience with the devicemodel in u-boot yet,
> also I do not have all that much time to work one this, so help on
> this from you would certainly be very welcome. I can answer any sunxi
> questions you may have, and I believe it is safe to say that Simon
> can answer any device-model questions you may have.
>
> Regards,
>
> Hans
>
> p.s.
>
> Paul I'm still fine with taking your i2c patchset upstream for now,
> but I do agree with Simon that we need to move to the device model
> and the sooner we do that the better.

Yes - the problem is that no one person can pay the 'tax' of moving
over, so we need to try to spread the effort on individuals who send
patches...

Regards,
Simon