From: "Adamski, Krzysztof (Nokia - PL/Wrocław)" <krzysztof.adamski@nokia.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Peter Rosin <peda@axentia.se>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: Two separate i2c transfers
Date: Fri, 15 May 2020 10:51:37 +0200 [thread overview]
Message-ID: <820e15e2-9267-1bbb-0809-4e9dc19d566d@nokia.com> (raw)
In-Reply-To: <20200515075303.GA1083@ninjato>
Hi Wolfram,
W dniu 15.05.2020 o 09:53, Wolfram Sang pisze:
>
> http://patchwork.ozlabs.org/project/linux-i2c/list/?series=95793
>
> (Do you use this driver or a custom one?)
Unfortunatly not right now. For historical reasons we have a custom one but I would like to move to this upstream one in
near future.
>
> I'd think that the PCA9641 driver should return -EBUSY if another master
> is active, so we'd have the lock on that level. But I may be totally
> missing some detail here.
That is a good point however right now the logic in i2c-mux.c is like this:
ret = muxc->select(muxc, priv->chan_id);
if (ret >= 0)
ret = i2c_transfer(parent, msgs, num);
if (muxc->deselect)
muxc->deselect(muxc, priv->chan_id);
So this does not really solve my problem - even if we do get the lock by calling select(), we will simply release it as
soon as our i2c_transfer() is finished (and will let the other master take it, breaking atomicity of the two operations
I need to perform on target device) and this is exactly what I need to avoid.
BTW the deselect is called regardless of the return code of select() - even if it returns an error. I'm not sure if this
might cause some problems (unbalanced numer of select/deselect operation) but I find it a little odd. Is this deliberate?
Best regards,
Krzysztof Adamski
next prev parent reply other threads:[~2020-05-15 8:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 12:41 Two separate i2c transfers Adamski, Krzysztof (Nokia - PL/Wrocław)
2020-05-14 14:50 ` Wolfram Sang
2020-05-15 7:04 ` Adamski, Krzysztof (Nokia - PL/Wrocław)
2020-05-15 7:53 ` Wolfram Sang
2020-05-15 8:51 ` Adamski, Krzysztof (Nokia - PL/Wrocław) [this message]
2020-05-15 9:20 ` Wolfram Sang
2020-05-15 9:24 ` Peter Rosin
2020-05-15 9:31 ` Wolfram Sang
2020-05-15 9:46 ` Adamski, Krzysztof (Nokia - PL/Wrocław)
2020-05-15 8:02 ` Peter Rosin
2020-05-15 8:36 ` Adamski, Krzysztof (Nokia - PL/Wrocław)
2020-05-15 21:19 ` Peter Rosin
2020-05-17 21:32 ` Peter Rosin
2020-05-19 12:59 ` Adamski, Krzysztof (Nokia - PL/Wrocław)
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=820e15e2-9267-1bbb-0809-4e9dc19d566d@nokia.com \
--to=krzysztof.adamski@nokia.com \
--cc=linux-i2c@vger.kernel.org \
--cc=peda@axentia.se \
--cc=wsa@the-dreams.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.