From: Lukasz Majewski <l.majewski@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/6] power: Explicitly select pmic device's bus
Date: Thu, 03 Oct 2013 18:15:59 +0200 [thread overview]
Message-ID: <20131003181559.4671f68f@amdc308.digital.local> (raw)
In-Reply-To: <524D061F.7080204@denx.de>
Hi Heiko,
Sorry for a late reply.
> Hello Lukasz,
>
> Am 02.10.2013 17:11, schrieb Lukasz Majewski:
> > Hi Leela,
> >
> >> The current pmic i2c code assumes the current i2c bus is
> >> the same as the pmic device's bus. There is nothing ensuring
> >> that to be true. Therefore, select the proper bus before performing
> >> a transaction.
> >>
> >> Signed-off-by: Aaron Durbin<adurbin@chromium.org>
> >> Signed-off-by: Simon Glass<sjg@chromium.org>
> >> Signed-off-by: Leela Krishna Amudala<l.krishna@samsung.com>
> >> Reviewed-by: Doug Anderson<dianders@google.com>
> >> ---
> >> drivers/power/power_i2c.c | 62
> >> +++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 57
> >> insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> >> index 47c606f..c22e01f 100644
> >> --- a/drivers/power/power_i2c.c
> >> +++ b/drivers/power/power_i2c.c
> >> @@ -16,9 +16,45 @@
> >> #include<i2c.h>
> >> #include<compiler.h>
> >>
> >> +static int pmic_select(struct pmic *p)
> >> +{
> >> + int ret, old_bus;
> >> +
> >> + old_bus = i2c_get_bus_num();
> >> + if (old_bus != p->bus) {
> >> + debug("%s: Select bus %d\n", __func__, p->bus);
> >> + ret = i2c_set_bus_num(p->bus);
> >> + if (ret) {
> >> + debug("%s: Cannot select pmic %s, err
> >> %d\n",
> >> + __func__, p->name, ret);
> >> + return -1;
> >> + }
> >> + }
> >> +
> >> + return old_bus;
> >> +}
> >> +
> >> +static int pmic_deselect(int old_bus)
> >> +{
> >> + int ret;
> >> +
> >> + if (old_bus != i2c_get_bus_num()) {
> >> + ret = i2c_set_bus_num(old_bus);
> >> + debug("%s: Select bus %d\n", __func__, old_bus);
> >> + if (ret) {
> >> + debug("%s: Cannot restore i2c bus, err
> >> %d\n",
> >> + __func__, ret);
> >> + return -1;
> >> + }
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
> >> {
> >> unsigned char buf[4] = { 0 };
> >> + int ret, old_bus;
> >>
> >> if (check_reg(p, reg))
> >> return -1;
> >> @@ -52,23 +88,33 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
> >> val) return -1;
> >> }
> >>
> >> - if (i2c_write(pmic_i2c_addr, reg, 1, buf,
> >> pmic_i2c_tx_num))
> >> + old_bus = pmic_select(p);
> >> + if (old_bus< 0)
> >> return -1;
> >>
> >> - return 0;
> >> + ret = i2c_write(pmic_i2c_addr, reg, 1, buf,
> >> pmic_i2c_tx_num);
> >
> > I'm wondering if setting the bus before each, single i2c write
> > (when we usually perform several writes to one device) will not be
> > an overkill (we search the ll_entry_count linker list each time to
> > find max i2c adapter names) ?
>
> Yes, maybe we could optimze this in drivers/i2c/i2c_core.c. It should
> be enough to detect the max adapter once ... but it is not a
> "search"... ll_entry_count() calculates the number ...
Yes, you are right. I've overlooked it.
With -Os compiler flag this compiles to a few ASM instructions.
Obviously it is NOT a performance killer :-) (I made unnecessary
fuzzz... sorry).
>
> Looking in i2c_set_bus_num(), I think it can be optimized ...
> lets speaking code:
>
> diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
> index d1072e8..170423a 100644
> --- a/drivers/i2c/i2c_core.c
> +++ b/drivers/i2c/i2c_core.c
> @@ -278,20 +278,22 @@ unsigned int i2c_get_bus_num(void)
> */
> int i2c_set_bus_num(unsigned int bus)
> {
> - int max = ll_entry_count(struct i2c_adapter, i2c);
> + int max;
> +
> + if ((bus == I2C_BUS) && (I2C_ADAP->init_done > 0))
> + return 0;
This looks nice.
>
> - if (I2C_ADAPTER(bus) >= max) {
> - printf("Error, wrong i2c adapter %d max %d
> possible\n",
> - I2C_ADAPTER(bus), max);
> - return -2;
> - }
> #ifndef CONFIG_SYS_I2C_DIRECT_BUS
> if (bus >= CONFIG_SYS_NUM_I2C_BUSES)
> return -1;
> #endif
>
> - if ((bus == I2C_BUS) && (I2C_ADAP->init_done > 0))
> - return 0;
> + max = ll_entry_count(struct i2c_adapter, i2c);
> + if (I2C_ADAPTER(bus) >= max) {
> + printf("Error, wrong i2c adapter %d max %d
> possible\n",
> + I2C_ADAPTER(bus), max);
> + return -2;
> + }
>
> #ifndef CONFIG_SYS_I2C_DIRECT_BUS
> i2c_mux_disconnet_all();
>
> So, first check, if we are on the correct bus, and return immediately!
> What do you think?
I think that it is acceptable.
>
> Beside of that, pmic_select() does the check, if we are on the correct
> bus too, and calls i2c_set_bus_num() only, if not ... so this is here
> no problem ...
Yes, I see.
> but exactly I want to get rid of this code as it is in
> pmic_select() someday, when all i2c drivers converted to the new i2c
> framework.
My 2 cents. I understand that pmic_select() preserves old i2c bus
number, when PMIC performs transmission. This is probably done to not
break the legacy code (where one driver assumed, that it is alone).
If this is necessary, then I'm OK with this. However I personally think,
that drivers shall call API functions from i2c core (like i2c_bus_num())
only with bus number to switch and do not store and preserve the i2c
value. This is my personal comment.
> i2c_set_bus_num() should go static then in
> drivers/i2c/i2c_core.c and i2c_read/write/... become a new "int bus"
> parameter ... but this will be a big api change ... but will prevent
> exactly such code all over the u-boot code ...
>
> bye,
> Heiko
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
next prev parent reply other threads:[~2013-10-03 16:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-01 14:32 [U-Boot] [PATCH 0/6] SMDK5420: Add S2MPS11 pmic support to SMDK5420 Leela Krishna Amudala
2013-10-01 14:32 ` [U-Boot] [PATCH 1/6] exynos: Use common pmic_reg_update() definition Leela Krishna Amudala
2013-10-02 14:49 ` Lukasz Majewski
2013-10-01 14:32 ` [U-Boot] [PATCH 2/6] power: Explicitly select pmic device's bus Leela Krishna Amudala
2013-10-02 15:11 ` Lukasz Majewski
2013-10-03 5:52 ` Heiko Schocher
2013-10-03 16:15 ` Lukasz Majewski [this message]
2013-10-04 5:23 ` Heiko Schocher
2013-10-04 8:58 ` Lukasz Majewski
2013-10-04 9:35 ` Heiko Schocher
2013-10-03 8:41 ` Leela Krishna Amudala
2013-10-03 9:44 ` Lukasz Majewski
2013-10-01 14:32 ` [U-Boot] [PATCH 3/6] FDT: Exynos5420: Add compatible srings for PMIC Leela Krishna Amudala
2013-10-01 14:32 ` [U-Boot] [PATCH 4/6] SMDK5420: S2MPS11: Adds the register settings for S2MPS11 Leela Krishna Amudala
2013-10-02 15:13 ` Lukasz Majewski
2013-10-01 14:32 ` [U-Boot] [PATCH 5/6] exynos: Add a common DT based PMIC driver initialization Leela Krishna Amudala
2013-10-01 14:32 ` [U-Boot] [PATCH 6/6] config: SMDK5420: Enable S2MPS1111111111111111111111 pmic Leela Krishna Amudala
2013-10-01 15:27 ` Leela Krishna Amudala
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=20131003181559.4671f68f@amdc308.digital.local \
--to=l.majewski@samsung.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