From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> To: "Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, "Marc Dietrich" <marvin24-Mmb7MZpHnFY@public.gmane.org> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrey Danin <danindrey-JGs/UdohzUI@public.gmane.org>, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Subject: Re: How to encode being an I2C slave in DT? Date: Wed, 06 May 2015 09:57:37 -0600 [thread overview] Message-ID: <554A39F1.9060507@wwwdotorg.org> (raw) In-Reply-To: <20150506080951.GS25193-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> On 05/06/2015 02:09 AM, Uwe Kleine-König wrote: > Hello Marc, > > On Wed, May 06, 2015 at 09:53:55AM +0200, Marc Dietrich wrote: >> Am Mittwoch, 6. Mai 2015, 08:59:28 schrieb Uwe Kleine-König: >>> On Tue, May 05, 2015 at 12:55:13PM +0200, Wolfram Sang wrote: >>>> So what about adding a new property "i2c-slave-reg"? This does not only >>>> prevent the confusion above, but also makes it very clear that this node >>>> is an I2C slave without the need to encode that somehow in the >>>> compatible property (although it probably should be described there as >>>> well, still). >>> >>> I admit I didn't follow the discussions referenced in the footnotes, but >>> I wonder if the slave part should be added to the device tree at all. >>> AFAICT it could (and so should) be completely userspace-defined which >>> slave driver is used on which address. I imagine that for most >>> controllers the bus addresses to use can be chosen more or less freely. >>> So what am I missing? >> >> if you had read the footnotes you would know :-) Our usecase is connect an >> embeedded controller via i2c to the host soc, similar to cros-ec, but here the >> ec is the i2c master. The ec connects keyboard, mouse, pwrmngt, and other >> stuff, for which the drivers are best implemented in kernel code AFAIK. > > Right, the driver might sensibly be implemented in kernel space. But I'd > vote that you still need to do the binding of these drivers to your > slave controller from userspace. Then there is no need to specify > anything in your dtb. I think the set of I2C slave devices that are implemented by the Linux system can reasonably be considered part of the HW definition. Most DT content to date has been a definition of the HW that's available to SW, but at least in this case, this I2C slave device is something that must be implemented (admittedly in conjunction with SW) using the I2C slave HW on the main SoC, in order for the overall HW to work as intended. BTW, I believe devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org was created to address subsystem-level DT schema questions like this. It's much lower volume, so perhaps the thread would get noticed by the DT maintainers if posted there (or perhaps just CC them)? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren) To: linux-arm-kernel@lists.infradead.org Subject: How to encode being an I2C slave in DT? Date: Wed, 06 May 2015 09:57:37 -0600 [thread overview] Message-ID: <554A39F1.9060507@wwwdotorg.org> (raw) In-Reply-To: <20150506080951.GS25193@pengutronix.de> On 05/06/2015 02:09 AM, Uwe Kleine-K?nig wrote: > Hello Marc, > > On Wed, May 06, 2015 at 09:53:55AM +0200, Marc Dietrich wrote: >> Am Mittwoch, 6. Mai 2015, 08:59:28 schrieb Uwe Kleine-K?nig: >>> On Tue, May 05, 2015 at 12:55:13PM +0200, Wolfram Sang wrote: >>>> So what about adding a new property "i2c-slave-reg"? This does not only >>>> prevent the confusion above, but also makes it very clear that this node >>>> is an I2C slave without the need to encode that somehow in the >>>> compatible property (although it probably should be described there as >>>> well, still). >>> >>> I admit I didn't follow the discussions referenced in the footnotes, but >>> I wonder if the slave part should be added to the device tree at all. >>> AFAICT it could (and so should) be completely userspace-defined which >>> slave driver is used on which address. I imagine that for most >>> controllers the bus addresses to use can be chosen more or less freely. >>> So what am I missing? >> >> if you had read the footnotes you would know :-) Our usecase is connect an >> embeedded controller via i2c to the host soc, similar to cros-ec, but here the >> ec is the i2c master. The ec connects keyboard, mouse, pwrmngt, and other >> stuff, for which the drivers are best implemented in kernel code AFAIK. > > Right, the driver might sensibly be implemented in kernel space. But I'd > vote that you still need to do the binding of these drivers to your > slave controller from userspace. Then there is no need to specify > anything in your dtb. I think the set of I2C slave devices that are implemented by the Linux system can reasonably be considered part of the HW definition. Most DT content to date has been a definition of the HW that's available to SW, but at least in this case, this I2C slave device is something that must be implemented (admittedly in conjunction with SW) using the I2C slave HW on the main SoC, in order for the overall HW to work as intended. BTW, I believe devicetree-spec at vger.kernel.org was created to address subsystem-level DT schema questions like this. It's much lower volume, so perhaps the thread would get noticed by the DT maintainers if posted there (or perhaps just CC them)?
next prev parent reply other threads:[~2015-05-06 15:57 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-30 20:00 [PATCH v2 0/4] arm: tegra: implement NVEC driver using tegra i2c Andrey Danin 2015-03-30 20:00 ` Andrey Danin 2015-03-30 20:00 ` Andrey Danin 2015-03-30 20:00 ` [PATCH v2 1/4] i2c: tegra: implement slave mode Andrey Danin 2015-03-30 20:00 ` Andrey Danin 2015-03-30 20:00 ` Andrey Danin [not found] ` <1427745615-5428-2-git-send-email-danindrey-JGs/UdohzUI@public.gmane.org> 2015-04-03 19:46 ` Wolfram Sang 2015-04-03 19:46 ` Wolfram Sang 2015-04-03 19:46 ` Wolfram Sang 2015-07-20 9:50 ` Wolfram Sang 2015-07-20 9:50 ` Wolfram Sang 2015-07-20 9:50 ` Wolfram Sang 2015-03-30 20:00 ` [PATCH v2 2/4] staging/nvec: reimplement on top of tegra i2c driver Andrey Danin 2015-03-30 20:00 ` Andrey Danin 2015-03-30 20:00 ` Andrey Danin [not found] ` <1427745615-5428-3-git-send-email-danindrey-JGs/UdohzUI@public.gmane.org> 2015-04-03 19:57 ` Wolfram Sang 2015-04-03 19:57 ` Wolfram Sang 2015-04-03 19:57 ` Wolfram Sang 2015-03-30 20:00 ` [PATCH v2 3/4] staging/nvec: remove old code Andrey Danin 2015-03-30 20:00 ` Andrey Danin 2015-03-30 20:00 ` Andrey Danin 2015-03-30 20:00 ` [PATCH v2 4/4] dt: paz00: define nvec as child of i2c bus Andrey Danin 2015-03-30 20:00 ` Andrey Danin 2015-03-30 20:00 ` Andrey Danin 2015-04-03 19:46 ` [PATCH v2 0/4] arm: tegra: implement NVEC driver using tegra i2c Wolfram Sang 2015-04-03 19:46 ` Wolfram Sang 2015-04-07 11:37 ` [PATCH v2 0/4] arm: tegra: implement NVEC driver using tegrai2c Marc Dietrich 2015-04-07 11:37 ` Marc Dietrich 2015-04-10 21:35 ` Wolfram Sang 2015-04-10 21:35 ` Wolfram Sang 2015-05-05 10:55 ` How to encode being an I2C slave in DT? Wolfram Sang 2015-05-05 20:07 ` Stephen Warren 2015-05-05 20:07 ` Stephen Warren [not found] ` <554922EF.3050906-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2015-05-06 16:17 ` Wolfram Sang 2015-05-06 16:17 ` Wolfram Sang 2015-05-06 17:01 ` Stephen Warren 2015-05-06 17:01 ` Stephen Warren 2015-05-19 0:37 ` Rob Herring 2015-05-19 0:37 ` Rob Herring [not found] ` <CAL_Jsq+iyeK-bV3ggcJv8Cw3EU71fkBo1wqYZnhCoh2-b_tO-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-05-19 6:16 ` Wolfram Sang 2015-05-19 6:16 ` Wolfram Sang 2015-07-16 9:03 ` Andrey Danin 2015-07-16 9:03 ` Andrey Danin [not found] ` <55A7736F.5090802-JGs/UdohzUI@public.gmane.org> 2015-07-16 18:14 ` Wolfram Sang 2015-07-16 18:14 ` Wolfram Sang 2015-05-06 6:59 ` Uwe Kleine-König 2015-05-06 6:59 ` Uwe Kleine-König [not found] ` <20150506065928.GP25193-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2015-05-06 7:53 ` Marc Dietrich 2015-05-06 7:53 ` Marc Dietrich 2015-05-06 8:09 ` Uwe Kleine-König 2015-05-06 8:09 ` Uwe Kleine-König [not found] ` <20150506080951.GS25193-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2015-05-06 15:57 ` Stephen Warren [this message] 2015-05-06 15:57 ` Stephen Warren [not found] ` <554A39F1.9060507-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2015-05-06 17:47 ` Uwe Kleine-König 2015-05-06 17:47 ` Uwe Kleine-König [not found] ` <20150506174757.GZ25193-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2015-05-06 18:35 ` Stephen Warren 2015-05-06 18:35 ` Stephen Warren
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=554A39F1.9060507@wwwdotorg.org \ --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \ --cc=danindrey-JGs/UdohzUI@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=marvin24-Mmb7MZpHnFY@public.gmane.org \ --cc=u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@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: linkBe 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.