From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Wed, 08 Apr 2015 09:27:35 +0200 Subject: [U-Boot] [PATCH v2 2/3] sunxi: Complete i2c support for each supported platform In-Reply-To: References: <1428180568-28138-1-git-send-email-contact@paulk.fr> <1428180568-28138-3-git-send-email-contact@paulk.fr> <1428267390.2501.19.camel@collins> <55224744.8020703@redhat.com> Message-ID: <5524D867.8010802@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 07-04-15 22:53, Simon Glass wrote: > Hi, > > On 6 April 2015 at 02:43, Hans de Goede 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 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 >>>>> --- >>>>> 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(-) >>>>> >> >> >> >> >>>>> 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