From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform
Date: Tue, 07 Apr 2015 11:09:08 +0200 [thread overview]
Message-ID: <55239EB4.30502@redhat.com> (raw)
In-Reply-To: <1428393085.2527.11.camel@collins>
Hi,
On 07-04-15 09:51, Paul Kocialkowski wrote:
> Le dimanche 05 avril 2015 ? 22:59 +0200, Paul Kocialkowski a ?crit :
>> Hi Hans,
>>
>> Le dimanche 05 avril 2015 ? 10:44 +0200, Hans de Goede a ?crit :
>>> Hi,
>
> [snip]
>
>>> Thanks for your work on this, may I request one more change ? For sunxi I would
>>> like to also see a CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / sun8i
>>> we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic there.
>>>
>>> This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp.
>>> PH2/3 (sun8i) which may be used in some other fashion.
>>>
>>> This also means making a small change to the first patch to also make registering
>>> of twsi0 #ifdef CONFIG_I2C_MVTWSI_BASE0 .
>>>
>>> Can you please make the default for CONFIG_I2C0_ENABLE y on sun4i / sun5i / sun7i and n
>>> on others?
>>
>> Ack that, it makes sense to me.
>
> Implementing this leads to build errors:
> drivers/i2c/mvtwsi.c:319:13: attention : ?twsi_i2c_init? defined but not
> used [-Wunused-function]
> drivers/i2c/mvtwsi.c:362:12: attention : ?twsi_i2c_probe? defined but
> not used [-Wunused-function]
> drivers/i2c/mvtwsi.c:388:12: attention : ?twsi_i2c_read? defined but not
> used [-Wunused-function]
> drivers/i2c/mvtwsi.c:424:12: attention : ?twsi_i2c_write? defined but
> not used [-Wunused-function]
>
> Ways to get rid of those include:
> * not building the driver at all when no controller 0 base is defined,
> which involves moving moving SYS_I2C_MVTWSI to Kconfig and selecting it
> when at least one i2c controller is selected in the sunxi Kconfig
> * having twsi0 enabled on all sunxi devices, as it was before
>
> What do you prefer?
I would prefer for the driver to not be build at all then, thank you for
working on this.
Regards,
Hans
>
>>> Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex boards
>>> which have a i2c eeprom enabling the attached i2c controller makes sense, but on the
>>> other boards the i2c pins are really just gpio pins, any daughter board can be connected
>>> including one which uses them differently. I believe that in the defconfig the i2c
>>> controllers should thus be left off. It is after all a default config, users with
>>> a daughter board which they want to use in u-boot can easily change the config after
>>> running make foo_defconfig.
>>
>> I think the right bargain here would be to enable i2c lines that already
>> have something useful for U-Boot attached (e.g. not an accelerometer
>> sensor). I concur to your point otherwise.
prev parent reply other threads:[~2015-04-07 9:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-05 7:51 [U-Boot] [PATCH v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform Paul Kocialkowski
2015-04-05 7:51 ` [U-Boot] [PATCH v3 1/3] i2c: mvtwsi: Support for up to 4 different controllers Paul Kocialkowski
2015-04-07 5:24 ` Heiko Schocher
2015-04-07 6:29 ` Hans de Goede
2015-04-07 6:35 ` Paul Kocialkowski
2015-04-05 7:51 ` [U-Boot] [PATCH v3 2/3] sunxi: Complete i2c support for each supported platform Paul Kocialkowski
2015-04-05 7:51 ` [U-Boot] [PATCH v3 3/3] sunxi: I2C/TWI configs for a few single-board-computers Paul Kocialkowski
2015-04-05 8:44 ` [U-Boot] [PATCH v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform Hans de Goede
2015-04-05 20:59 ` Paul Kocialkowski
2015-04-07 7:51 ` Paul Kocialkowski
2015-04-07 9:09 ` Hans de Goede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55239EB4.30502@redhat.com \
--to=hdegoede@redhat.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.