linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antti Palosaari <crope-X3B1VOXEql0@public.gmane.org>
To: Mauro Carvalho Chehab
	<mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>,
	Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>
Subject: Re: [PATCH 21/66] rtl2830: implement own I2C locking
Date: Tue, 03 Feb 2015 20:34:01 +0200	[thread overview]
Message-ID: <54D11499.6080800@iki.fi> (raw)
In-Reply-To: <20150203155301.7ba63776-+RedX5hVuTR+urZeOPWqwQ@public.gmane.org>



On 02/03/2015 07:53 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 02 Feb 2015 21:33:24 +0100
> Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> escreveu:
>
>>
>>>> Ok, this may eventually work ok for now, but a further change at the I2C
>>>> core could easily break it. So, we need to double check about such
>>>> patch with the I2C maintainer.
>>>>
>>>> Jean,
>>>>
>>>> Are you ok with such patch? If so, please ack.
>>
>> Jean handed over I2C to me in late 2012 :)
>
> Sorry for the mess... I mis-read MAINTAINERS.
>
>>> Basic problem here is that I2C-mux itself is controlled by same I2C device
>>> which implements I2C adapter for tuner.
>>>
>>> Here is what connections looks like:
>>>   ___________         ____________         ____________
>>> |  USB IF   |       |   demod    |       |    tuner   |
>>> |-----------|       |------------|       |------------|
>>> |           |--I2C--|-----/ -----|--I2C--|            |
>>> |I2C master |       |  I2C mux   |       | I2C slave  |
>>> |___________|       |____________|       |____________|
>>>
>>>
>>> So when tuner is called via I2C, it needs recursively call same I2C adapter
>>> which is already locked. More elegant solution would be indeed nice.
>>
>> So, AFAIU this is the same problem that I2C based mux devices have (like
>> drivers/i2c/muxes/i2c-mux-pca954x.c)? They also use the unlocked
>> transfers...
>
> If I understood your comment correct, you're ok with this approach,
> right? I'll then merge the remaining of this 66-patch series.
>
> If latter a better way to lock the I2C mux appears, we can reverse
> this change.

More I am worried about next patch in a serie, which converts all that 
to regmap API... Same recursive mux register access comes to problem 
there, which I work-arounded by defining own I2C IO... And in that case 
I used i2c_lock_adapter/i2c_unlock_adapter so adapter is locked properly.

[PATCH 22/66] rtl2830: convert to regmap API
http://www.spinics.net/lists/linux-media/msg84969.html

regards
Antti

-- 
http://palosaari.fi/

  parent reply	other threads:[~2015-02-03 18:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1419367799-14263-1-git-send-email-crope@iki.fi>
     [not found] ` <1419367799-14263-21-git-send-email-crope@iki.fi>
2015-02-02 20:07   ` [PATCH 21/66] rtl2830: implement own I2C locking Mauro Carvalho Chehab
     [not found]     ` <20150202180726.454dc878-+RedX5hVuTR+urZeOPWqwQ@public.gmane.org>
2015-02-02 20:23       ` Antti Palosaari
     [not found]         ` <54CFDCCC.3030006-X3B1VOXEql0@public.gmane.org>
2015-02-02 20:33           ` Wolfram Sang
2015-02-02 20:47             ` Lars-Peter Clausen
2015-02-03 17:53             ` Mauro Carvalho Chehab
     [not found]               ` <20150203155301.7ba63776-+RedX5hVuTR+urZeOPWqwQ@public.gmane.org>
2015-02-03 18:34                 ` Antti Palosaari [this message]
     [not found]                   ` <54D11499.6080800-X3B1VOXEql0@public.gmane.org>
2015-02-04 10:47                     ` Mark Brown
2015-02-02 20:56     ` Jean Delvare
     [not found]       ` <20150202215623.5e289f24-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2015-02-02 21:13         ` Antti Palosaari

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=54D11499.6080800@iki.fi \
    --to=crope-x3b1voxeql0@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=jdelvare-l3A5Bk7waGM@public.gmane.org \
    --cc=lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@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).