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
next prev 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).