linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.ml.walleij-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Mike Rapoport <mike-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linus Walleij
	<linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Subject: Re: [PATCH] MFD: Add U300 AB3100 core support v1
Date: Mon, 18 May 2009 16:22:36 +0200	[thread overview]
Message-ID: <63386a3d0905180722u282f0dd3ua62b119a1a6a97e8@mail.gmail.com> (raw)
In-Reply-To: <4A0BF776.9030301-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>

2009/5/14 Mike Rapoport <mike-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>:

> A few comments.

First a BIG THANKS. I worked the last few days according to your and
Samuel's comments, great input!

I'll send a v2 soonish with all issues fixed as far as possible. Below
I just discuss things I haven't yet figured out how to fix properly.
(Most stuff is simply just fixed.)

>> +     /*
>> +      * A two-byte write message with the first byte containing the register
>> +      * number and the second byte containing the value to be written
>> +      * effectively sets a register in the AB3100.
>> +      */
>> +     if ((i2c_transfer(ab3100_i2c_client->adapter,
>> +                                     &msgs[0], 1)) != 1) {
>
> Is it necessary to use i2c_transfer here? Maybe i2c_master_send or even
> i2c_smbus_write_word_data would do the job?

Yep it works nicely here but...

>> +/*
>> + * The test registers exist at an I2C bus address up one
>> + * from the ordinary base. They are not supposed to be used
>> + * in production code, but sometimes you have to do that
>> + * anyway. It's currently only used from this file so declare
>> + * it static and do not export.
>> + */
>> +static int ab3100_set_test_register(u8 reg, u8 regval)
>> +{
>> +     u8 regandval[2] = {reg, regval};
>> +     struct i2c_msg msgs[1];
>> +     int err = 0;
>> +
>> +     if (!ab3100_initialized)
>> +             return -ENODEV;
>> +
>> +     msgs[0].addr = ab3100_i2c_client->addr + 1;
>> +     msgs[0].flags = 0;
>> +     msgs[0].len = 2;
>> +     msgs[0].buf = regandval;
>> +     err = mutex_lock_interruptible(&ab3100_access_mutex);
>> +     if (err)
>> +             return err;
>> +
>> +     /*
>> +      * A two-byte write message with the first byte containing the register
>> +      * number and the second byte containing the value to be written
>> +      * effectively sets a register in the AB3100.
>> +      */
>> +     if ((i2c_transfer(ab3100_i2c_client->adapter,
>> +                       &msgs[0], 1)) != 1) {
>
> i2c_master_send?

Here we have a problem. See above:
msgs[0].addr = ab3100_i2c_client->addr + 1;

So this chip actually has two addresses. A "special" address
to deal with test registers, one address up. The I2C framework
assume all devices have one and one address only (which is
of course mostly true).

Here is a special case. When the first device has registered,
you know that the other address is available as well.

You could think of several ugly solutions:

* Keep using i2c_transfer() directly as we do now.

* Make a raw copy of the i2c_device with something like
  memcpy(mock_client, i2c_client, sizeof(i2c_client);
  mock_client->addr++;
  then use i2c_master_send()

* Register a new i2c_device in board_info for the other
  address while strictly speaking it is the same device, and
  this will yield a lot of probing and synchronization code,
  because writing the test registers is used when probing the
  first device, so we have to wait for that device to be probed
  before we can probe the other one etc.

Right now I lean toward the first alternative.

Yours,
Linus Walleij

  parent reply	other threads:[~2009-05-18 14:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14  8:29 [PATCH] MFD: Add U300 AB3100 core support v1 Linus Walleij
     [not found] ` <63386a3d0905140129s5fd0f32cxde1114489678f012-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-05-14 10:50   ` Mike Rapoport
     [not found]     ` <4A0BF776.9030301-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>
2009-05-18 14:22       ` Linus Walleij [this message]
     [not found]         ` <63386a3d0905180722u282f0dd3ua62b119a1a6a97e8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-05-18 14:44           ` Jean Delvare
     [not found]             ` <20090518164440.2124a4fa-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-05-18 17:18               ` Trilok Soni
2009-05-28  8:22       ` Trilok Soni
2009-05-14 11:37   ` Samuel Ortiz

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=63386a3d0905180722u282f0dd3ua62b119a1a6a97e8@mail.gmail.com \
    --to=linus.ml.walleij-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mike-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org \
    --cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /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;
as well as URLs for NNTP newsgroup(s).