| Message ID | 1466697545-11868-8-git-send-email-jonathanh@nvidia.com |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, Jun 23, 2016 at 04:59:00PM +0100, Jon Hunter wrote: > The I2C driver core for boards using device-tree assumes any subnode of > an I2C adapter in the device-tree blob as being a I2C slave device. > Although this makes complete sense, some I2C adapters may have subnodes > which are not I2C slaves but subnodes presenting other features. For > example some Tegra devices have an I2C interface which may share its > pins with other devices and to share these pins subnodes for > representing these pins so they have be shared via the pinctrl framework > are needed. > > To allow I2C adapters to have non-I2C specific subnodes in device-tree > that are not parsed by the I2C driver core by adding support for a > 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus' > subnode is present then all I2C slaves must be placed under this subnode. > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com> > Acked-by: Thierry Reding <treding@nvidia.com> > --- > Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++ > 1 file changed, 8 insertions(+) Acked-by: Rob Herring <robh@kernel.org> -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2016-06-23 17:59, Jon Hunter wrote: > The I2C driver core for boards using device-tree assumes any subnode of > an I2C adapter in the device-tree blob as being a I2C slave device. > Although this makes complete sense, some I2C adapters may have subnodes > which are not I2C slaves but subnodes presenting other features. For > example some Tegra devices have an I2C interface which may share its > pins with other devices and to share these pins subnodes for > representing these pins so they have be shared via the pinctrl framework > are needed. > > To allow I2C adapters to have non-I2C specific subnodes in device-tree > that are not parsed by the I2C driver core by adding support for a > 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus' > subnode is present then all I2C slaves must be placed under this subnode. > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com> > Acked-by: Thierry Reding <treding@nvidia.com> > --- > Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt > index f31b2ad1552b..71bea55d4c1b 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c.txt > @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below. > - clock-frequency > frequency of bus clock in Hz. > > +- i2c-bus > + For I2C adapters that have child nodes that are a mixture of both I2C > + devices and non-I2C devices (such as a pin controller), the 'i2c-bus' > + subnode can be used for populating I2C devices. If the 'i2c-bus' > + subnode is present, only subnodes of this will be considered as I2C > + slaves. The properties, '#address-cells' and '#size-cells' must be > + defined under this subnode if present. Hmmm, those #-properties are listed above, under "Required properties", which is no longer 100% true. Maybe rephrase to slaves. The required properties '#address-cells' and '#size-cells' must be defined under this subnode instead, if this subnode is present. to make the rules (even) clearer? Cheers, Peter > + > - i2c-scl-falling-time-ns > Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C > specification. > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 27/06/16 13:04, Peter Rosin wrote: > On 2016-06-23 17:59, Jon Hunter wrote: >> The I2C driver core for boards using device-tree assumes any subnode of >> an I2C adapter in the device-tree blob as being a I2C slave device. >> Although this makes complete sense, some I2C adapters may have subnodes >> which are not I2C slaves but subnodes presenting other features. For >> example some Tegra devices have an I2C interface which may share its >> pins with other devices and to share these pins subnodes for >> representing these pins so they have be shared via the pinctrl framework >> are needed. >> >> To allow I2C adapters to have non-I2C specific subnodes in device-tree >> that are not parsed by the I2C driver core by adding support for a >> 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus' >> subnode is present then all I2C slaves must be placed under this subnode. >> >> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> >> Acked-by: Thierry Reding <treding@nvidia.com> >> --- >> Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt >> index f31b2ad1552b..71bea55d4c1b 100644 >> --- a/Documentation/devicetree/bindings/i2c/i2c.txt >> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt >> @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below. >> - clock-frequency >> frequency of bus clock in Hz. >> >> +- i2c-bus >> + For I2C adapters that have child nodes that are a mixture of both I2C >> + devices and non-I2C devices (such as a pin controller), the 'i2c-bus' >> + subnode can be used for populating I2C devices. If the 'i2c-bus' >> + subnode is present, only subnodes of this will be considered as I2C >> + slaves. The properties, '#address-cells' and '#size-cells' must be >> + defined under this subnode if present. > > Hmmm, those #-properties are listed above, under "Required properties", which > is no longer 100% true. Maybe rephrase to > > slaves. The required properties '#address-cells' and '#size-cells' > must be defined under this subnode instead, if this subnode is present. > > to make the rules (even) clearer? I see what you are saying but I wonder if the following is better ... slaves. The required properties '#address-cells' and '#size-cells' must be defined under this subnode if present and not the parent node. Cheers Jon
On 2016-06-28 10:21, Jon Hunter wrote: > > On 27/06/16 13:04, Peter Rosin wrote: >> On 2016-06-23 17:59, Jon Hunter wrote: >>> The I2C driver core for boards using device-tree assumes any subnode of >>> an I2C adapter in the device-tree blob as being a I2C slave device. >>> Although this makes complete sense, some I2C adapters may have subnodes >>> which are not I2C slaves but subnodes presenting other features. For >>> example some Tegra devices have an I2C interface which may share its >>> pins with other devices and to share these pins subnodes for >>> representing these pins so they have be shared via the pinctrl framework >>> are needed. >>> >>> To allow I2C adapters to have non-I2C specific subnodes in device-tree >>> that are not parsed by the I2C driver core by adding support for a >>> 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus' >>> subnode is present then all I2C slaves must be placed under this subnode. >>> >>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> >>> Acked-by: Thierry Reding <treding@nvidia.com> >>> --- >>> Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt >>> index f31b2ad1552b..71bea55d4c1b 100644 >>> --- a/Documentation/devicetree/bindings/i2c/i2c.txt >>> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt >>> @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below. >>> - clock-frequency >>> frequency of bus clock in Hz. >>> >>> +- i2c-bus >>> + For I2C adapters that have child nodes that are a mixture of both I2C >>> + devices and non-I2C devices (such as a pin controller), the 'i2c-bus' >>> + subnode can be used for populating I2C devices. If the 'i2c-bus' >>> + subnode is present, only subnodes of this will be considered as I2C >>> + slaves. The properties, '#address-cells' and '#size-cells' must be >>> + defined under this subnode if present. >> >> Hmmm, those #-properties are listed above, under "Required properties", which >> is no longer 100% true. Maybe rephrase to >> >> slaves. The required properties '#address-cells' and '#size-cells' >> must be defined under this subnode instead, if this subnode is present. >> >> to make the rules (even) clearer? > > I see what you are saying but I wonder if the following is better ... > > slaves. The required properties '#address-cells' and '#size-cells' > must be defined under this subnode if present and not the parent node. Naaw, I don't like that either, I associate the last "and not" with the "if present" part and not the intended "under this subnode". Then I go WTF when I fail to parse. Maybe just add an example instead... Or just forget me ever saying anything. Sorry for making a fuss over this. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> For > example some Tegra devices have an I2C interface which may share its > pins with other devices and to share these pins subnodes for > representing these pins so they have be shared via the pinctrl framework > are needed. I think the above sentence is hard to grasp. Can you split it into more sentences perhaps? > +- i2c-bus > + For I2C adapters that have child nodes that are a mixture of both I2C > + devices and non-I2C devices (such as a pin controller), the 'i2c-bus' I suggest to drop the phrase in the paranthesis. It is true for your case, but I don't think it's generic. So, it is not an obvious example like "Yes, sure, I see that a pin controller has I2C nodes and non-I2C nodes". At least for me, it was more like "It has what?"
On 28/06/16 22:32, Wolfram Sang wrote: > * PGP Signed by an unknown key > >> For >> example some Tegra devices have an I2C interface which may share its >> pins with other devices and to share these pins subnodes for >> representing these pins so they have be shared via the pinctrl framework >> are needed. > > I think the above sentence is hard to grasp. Can you split it into more > sentences perhaps? OK, yes does seem a bit of a mouthful. >> +- i2c-bus >> + For I2C adapters that have child nodes that are a mixture of both I2C >> + devices and non-I2C devices (such as a pin controller), the 'i2c-bus' > > I suggest to drop the phrase in the paranthesis. It is true for your > case, but I don't think it's generic. So, it is not an obvious example > like "Yes, sure, I see that a pin controller has I2C nodes and non-I2C > nodes". At least for me, it was more like "It has what?" OK, will drop that part. Cheers Jon
diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index f31b2ad1552b..71bea55d4c1b 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below. - clock-frequency frequency of bus clock in Hz. +- i2c-bus + For I2C adapters that have child nodes that are a mixture of both I2C + devices and non-I2C devices (such as a pin controller), the 'i2c-bus' + subnode can be used for populating I2C devices. If the 'i2c-bus' + subnode is present, only subnodes of this will be considered as I2C + slaves. The properties, '#address-cells' and '#size-cells' must be + defined under this subnode if present. + - i2c-scl-falling-time-ns Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C specification.