From: Wolfram Sang <firstname.lastname@example.org>
To: Luca Ceresoli <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
Mauro Carvalho Chehab <firstname.lastname@example.org>,
Rob Herring <email@example.com>,
Mark Rutland <firstname.lastname@example.org>,
Sakari Ailus <email@example.com>,
Hans Verkuil <firstname.lastname@example.org>,
Laurent Pinchart <email@example.com>,
Kieran Bingham <firstname.lastname@example.org>,
Jacopo Mondi <email@example.com>,
Vladimir Zapolskiy <firstname.lastname@example.org>, Peter Rosin <email@example.com>
Subject: Re: [RFC,v2 3/6] media: dt-bindings: add DS90UB954-Q1 video deserializer
Date: Tue, 3 Sep 2019 11:34:55 +0200 [thread overview]
Message-ID: <20190903093455.GD1020@kunai> (raw)
[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]
> Not if you define enough addresses in the pool. E.g. the DS90UB954
> hardware can have 8 aliases per port, so if you have (n_ports * 8)
> addresses in the pool the problem is solved.
And then you plug-in somewhere another board with another need for ATR
and you are out of addresses.
> > And another add-on module with
> > non-repogrammable devices may occupy addresses from the defined pool
> > above.
> You mean a new device on the local (SoC-to-ATR) bus? Well, it could as
> well occupy a non-described address that the ATR has already picked as
> an alias.
Nope, I mean a seperate add-on which has a hardcoded I2C address on the
bus of the ATR parent. Then this hardcoded address needs to be removed
from the pool if it is in the wrong range.
> > I am not perfectly happy with the assumption that all undescribed
> > addresses are automatically free. That also might need DTS updates to
> > describe all clients properly. But this change only needs to be done
> > once, and it will improve the description of the hardware.
> Right, but I still suspect some users won't do their homework and
> discover address conflicts at runtime, maybe months later, in a painful
> way. Also a chip might be undocumented on a given board, so they could
> do their homework and still have problems.
Yes, we probably need a binding to mark an address as used even though
we don't know the device or don't have a driver for it.
Don't get me wrong, I know what you mean. One of my boards has a client
soldered in a way so that it is still in debug mode. That means it
listens to addresses 0x03-0x07 to provide debug information. Took me a
while to find out what is happening there.
But still, 'i2cdetect' showed all of these.
> Despite my comments, I'm not strongly against your proposal. To me it
> doesn't seem to solve any problem, while it does introduce some degree
> of risk. Could you elaborate more on but what benefit it introduces?
I'd think the risk of running out of defined addresses is somewhere
equal to running into (after a while) an unexpectedly used address.
I like the fix for the latter better because describing what is on the
bus is more helpful and generic than updating the pool-property every
time you need it. Plus, as mentioned above, other add-on hardware may
disturb your pool allocation.
I expect this topic to be one of the discussion points of the BoF.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-09-03 9:35 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-23 20:37 [RFC,v2 0/6] TI camera serdes and I2C address translation Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 1/6] i2c: core: let adapters be notified of client attach/detach Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 2/6] i2c: add I2C Address Translator (ATR) support Luca Ceresoli
2019-09-01 14:31 ` jacopo mondi
2019-09-03 7:31 ` Luca Ceresoli
2019-09-03 7:37 ` Wolfram Sang
2019-09-04 8:09 ` Peter Rosin
2019-09-08 19:40 ` Luca Ceresoli
2019-09-10 18:46 ` Wolfram Sang
2019-09-08 20:45 ` Vladimir Zapolskiy
2019-09-09 4:56 ` Vladimir Zapolskiy
2019-09-10 17:40 ` Luca Ceresoli
2019-09-09 7:22 ` Wolfram Sang
2019-09-09 15:10 ` Vladimir Zapolskiy
2019-09-09 17:48 ` Luca Ceresoli
2019-09-10 17:16 ` Wolfram Sang
2019-09-02 20:42 ` Wolfram Sang
2019-09-03 8:48 ` Luca Ceresoli
2019-09-03 9:06 ` Wolfram Sang
2019-07-23 20:37 ` [RFC,v2 3/6] media: dt-bindings: add DS90UB954-Q1 video deserializer Luca Ceresoli
2019-08-13 15:44 ` Rob Herring
2019-08-19 22:41 ` Luca Ceresoli
2019-08-20 15:44 ` Rob Herring
2019-08-21 21:50 ` Luca Ceresoli
2019-09-02 20:48 ` Wolfram Sang
2019-09-03 9:09 ` Luca Ceresoli
2019-09-03 9:34 ` Wolfram Sang [this message]
2019-09-03 11:03 ` Luca Ceresoli
2019-09-03 14:16 ` Wolfram Sang
2019-09-10 9:43 ` Sakari Ailus
2019-09-10 15:02 ` Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 4/6] media: dt-bindings: add DS90UB953-Q1 video serializer Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 5/6] media: ds90ub954: new driver for TI DS90UB954-Q1 video deserializer Luca Ceresoli
2019-07-23 20:37 ` [RFC,v2 6/6] media: ds90ub953: new driver for TI DS90UB953-Q1 video serializer Luca Ceresoli
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).