Hi, On 6 April 2015 at 02:43, Hans de Goede <hdego...@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 <cont...@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 <cont...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
