From: Wolfram Sang <wsa@the-dreams.de> To: Luca Ceresoli <luca@lucaceresoli.net> Cc: linux-media@vger.kernel.org, linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Mauro Carvalho Chehab <mchehab@kernel.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Sakari Ailus <sakari.ailus@linux.intel.com>, Hans Verkuil <hverkuil-cisco@xs4all.nl>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Kieran Bingham <kieran.bingham@ideasonboard.com>, Jacopo Mondi <jacopo@jmondi.org>, Vladimir Zapolskiy <vz@mleia.com>, Peter Rosin <peda@axentia.se> Subject: Re: [RFC,v2 3/6] media: dt-bindings: add DS90UB954-Q1 video deserializer Date: Tue, 3 Sep 2019 11:34:55 +0200 Message-ID: <20190903093455.GD1020@kunai> (raw) In-Reply-To: <63d99d6d-ecdd-7dd8-0dcb-126bfd89b258@lucaceresoli.net> [-- 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 index 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
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=20190903093455.GD1020@kunai \ --to=wsa@the-dreams.de \ --cc=devicetree@vger.kernel.org \ --cc=hverkuil-cisco@xs4all.nl \ --cc=jacopo@jmondi.org \ --cc=kieran.bingham@ideasonboard.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=luca@lucaceresoli.net \ --cc=mark.rutland@arm.com \ --cc=mchehab@kernel.org \ --cc=peda@axentia.se \ --cc=robh+dt@kernel.org \ --cc=sakari.ailus@linux.intel.com \ --cc=vz@mleia.com \ /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
Linux-Media Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-media/0 linux-media/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-media linux-media/ https://lore.kernel.org/linux-media \ linux-media@vger.kernel.org public-inbox-index linux-media Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-media AGPL code for this site: git clone https://public-inbox.org/public-inbox.git