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

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 07-04-15 22:53, Simon Glass wrote:
> Hi,
>
> On 6 April 2015 at 02:43, Hans de Goede <hdegoede@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@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@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.

If you look at:
board/sunxi/MAINTAINERS

And then the large block at the top, that lists the 30+ boards I've,
or at least it lists all the boards for which I've added support to
upstream u-boot I still have a couple which I need to add ...

Anyways, I should be able to test this on say 2 boards of each soc
generation, which should shake out most (if not all) bugs. The limit
here is not hardware access but how much time I want to spend on
testing :)

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

Correct, but it is desirable so that plugging in a usb keyboard
directly (without a usb-2 hub between the board and the keyboard)
will work.

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

Not sure what you mean by paying the 'tax' here, I'm hoping that with
the groundwork you've done moving over other boards becomes a pretty
mechanical process, other then the testing.

If someone can provide me with a git tree / branch with all boards
converted I can spend a couple of saturdays / sundays / evenings
on testing, picking boards which I know will exercise different
code paths.

Regards,

Hans