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

Sun Apr 19 16:21:36 CEST 2015

Hi Hans,

On 8 April 2015 at 01:27, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
>
> On 07-04-15 22:53, Simon Glass wrote:
>>
>> 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.
>
>
> 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.

OK. I'm hoping that someone else can work on the OHCI conversion.

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

I mean that every new board that uses the old config method adds
conversion work, and makes it harder to move things over. So the 'tax'
is trying to get people who submit patches for new boards to move over
a few existing boards. They put a little bit more effort in to get
their patch applied, but help the overall effort.

>
> 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,
Simon