public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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.

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox